thoughts about burnout

in the last 18 months, i burnt out around 3 times. there were quite a few reasons why this happened, and to be honest, i don’t think i’ve fully learnt from these incidents. i don’t even know if burnout is the right term to use here. degraded productivity, fighting the urge to kick back and chill instead of getting shit done and slop reviews were the common themes during these occurences.

here i try to unpack some of the reasons leading to it, and hey, maybe this resonates with you too.

keeping up

when one joins a new team, there is this “pressure” that makes you want to be productive from day 0. i say day 0, because every single time i have joined a new team, i make sure to onboard on my own time before the official start date. this behaviour compounds positively, your team members appreciate the quick onboarding, management is impressed, and is an excellent demonstration of your capabilities and agency. this is quite a slippery slope though, because you need to keep this momentum going, otherwise, it seems that your productivity is slipping. if one was to think about this in terms of effort vs impact, there is an inflection point where no matter how much more effort you put in, the impact tends to remain the same / or have minimal gains. one of two things can happen here - either one realizes that putting in more effort is not correlated with impact anymore, and try to provide impact in other ways (i.e improve developer experience, improve perf, find gaps in the product and fix it solo), OR one is oblivious to this new pattern, and they keep putting in more effort (i.e longer hours, larger pieces of work, sacrificing personal life) to no avail.

of course, i have been a long-standing advocate of pushing the needle wherever it counts, but after a point, there’s just diminishing returns to keep pushing yourself. you’re capped by intellectual ability and cognitive load. a lot of engineers struggle with this realization, because it means that they might have reached a threshold that seems uncrossable. however, one may notice that their best work is often coupled with less stress, true love for the craft, and exercising emptiness (i.e allowing your brain to take a break). this seems like the only sustainable way to have a self-improvement loop.

ambiguity / evolving business conditions

engineers should thrive in ambiguity, this allows them to express their abilities the best. however, due to miscommunication/misunderstanding from management, this can cause a certain kind of strain. imagine creating a pull request, only to have to rework it 5 times because the goalpost keeps moving. one could chalk it down to a skill issue of the engineer, but it’s a skill issue on both parties here. businesses continually evolve, but that does not justify good idea jockeys to treat engineers like an llm. the engineer could account for the business evolving, but when the component they’re working on is complete, and won’t probably change for a while, someone looking at the code would wonder why there are so many abstractions and indirections, prompting another refactor to clean things up. this is the engineering lifecycle, and probably has been for decades at this point :)

being dialed in all the time to address evolving business conditions isn’t sustainable either, the engineer ends up taking on the burden that should’ve been addressed earlier in product strategy. the engineer must develop some product sense of their own in order to refute / push back on certain business decisions which would just cause churn. i don’t think that scrum/agile solves this, you’re just kicking the can down the road. that being said, in a lot of cases, it is very exciting to work with ambiguity, it definitely allows one to level up.

context switching

there’s two ways to think about context switching, it’s healthy when controlled, unhealthy when uncontrolled. by controlled, i mean that one has a clear idea of the repositories and running services they need to maintain and keep alive. this can be healthy, it allows one to take a break from monotonous work and be engaged. however, uncontrolled context switching is what happens when the person responsible for a given component / service does not maintain it anymore, and the responsibility falls on the person who needs to keep it alive to avoid downtime. a lot of this can add up, and prevent one from working on parts of the code they clearly own, delaying their output, and worsen their productivity. in my opinion, the way to mitigate this is to have atleast a surface level understanding of all code in the repository, and having the ability to dig deeper if required, tooling helps here. clearer, defined boundaries between team members when it comes to maintenance of a service is good too, otherwise it causes an imbalance in the team, which hampers inter-personal relationships, causing a whole slew of issues.

taking a break

two approaches to fix this kind of burnout have emerged:

• do deep work, avoid context switching, work on something that doesn’t have an overly strict timeline on it
• take time off, allow your brain to rest :)

burnout isn’t that bad when one realizes that certain patterns / behaviours can be mutated to make it easier to overcome it.