Software engineers: avoid burn out by breaking your sh*t down!

The Zeigarnik Effect

“The Zeigarnik Effect states that people tend to remember unfinished or incomplete tasks better than completed tasks.

The effect was first observed by Russian psychologist Bluma Zeigarnik, who noticed that waiters in a café could recall the orders they had not yet delivered better than those they had delivered”

– Cynthia Vinney, Thought Co.

This got me thinking about the links with software engineering, and why so many of us experience brain fog and ultimately burn out. Many have come to accept this as a side effect of being a software engineer, but does it really need to be like this?

Burn out

As software engineers the more we mature into our roles the more information we hold in our heads at any one time on a day to day basis. This is because we often operate within a sphere of incomplete tasks and according to The Zeigarnik Effect, we remember the intricacies of these tasks much more vividly than those we have already delivered.

This makes sense to me as in order for us to contemplate, conceptualize, design and develop solutions, we need to keep our deep trail of thoughts fresh and running. Otherwise, we would forever be interrupting ourselves stifling our innovation and productivity.

A consistent, intricate and vivid trail of thought requires immense mental energy most notably in the prefrontal cortex, which is widely considered as our ‘working memory’. If our working memory is always operating at this level, every day, week in week out then we’re bound to end up developing brain fog and burning out.

So then the question becomes, how can we use our working memory less to relieve the stresses from overloading it whilst at the same time keeping our productivity consistently high?

Break out…

The answer is to come back to the age old adage of ‘divide and conquer’. We need to divide up our tasks into smaller deliverable chunks so in the day-to-day we are only ever focused on that one unit of work, easing up on our working memory.

The benefits of doing this are far-reaching. If you’re focused on a small unit of work, then your team is able to digest your interactions much more easily. Rather than having dialogue about A,B,C and X, Y and Z, you’re only ever talking about A. Reducing the risk of brain fog and improving the quality of shipped product.

…and break your sh*t down to get the best results

So before planning to submit that 50 change pull/merge request, stop and think about breaking it down. Take care of your working memory (and that of the reviewer!).

Build this into a habit and you’re undoubtedly on the road to avoiding burn out.

The most productive engineers I have come across intuitively understand this very well and if you put a team of these engineers together, you have a real force to be reckoned with.

Happy coding!

Read more about the day-to-day life of a developer at Bidnamic

How we replaced daily stand-ups and increased productivity.