Navigating Burnout in the Software Engineering World: Strategies for Success

Melchor Tatlonghari

Burnout is an affliction in the software engineering world that not everyone is comfortable speaking about. The hustle culture we are currently in has implied that engineers should always be passionately building a side project that could be the next Google or Amazon. Add globalization into the mix, where you are competing with fresh grads from MIT and tech geniuses in Silicon Valley, and you have a recipe for disaster on your mental health. Below are most common causes of burn out in the Engineering world.

Keeping Up with Evolving Technology

The lightning speed at which technology evolves almost always renders your past experience useless a couple of years down the road. Have you mastered jQuery/Ajax? Nobody uses that now; it’s all about React/Angular/Vue/Svelte or whatever JS framework is trending now. Did you work with Java 8 a couple of years back? It’s now Java 20. Your experience does not count anywhere; it is either Python, JavaScript, Golang, Rust, or whatever backend language is trending now.

Throughout my career, regardless of whether I was still a junior, senior, or even a principal engineer, there was always a need for “tech refresh”. Everything I knew at one point became completely obsolete.

The challenge becomes the time allowed for you to upskill becomes much shorter as you become more senior. As a junior, people expect you to learn a technology for a couple of months before expecting high-quality work; as a senior, it becomes weeks; as a principal engineer, you should’ve already known that yesterday.Regardless of your level of expertise, this hamster wheel of implicit requirement never ends. This endless cycle could be demoralizing after a couple of years and especially as you grow older.

The Interview Process Challenge

Another main source of burnout is how each engineer goes through interviews. Only in Software Engineering is the interview process so far apart from the actual job. I’ve told this to multiple engineers that I mentored: going to job interviews is a skill. It’s a skill that you need to hone.

Engineers have to go through several rounds of scrutiny to test their skills, ranging from 3–8 rounds, depending on which position you are applying for and how prominent the company is. The main caveat really is how each of these interview rounds, more often than not, is not something you do in your day-to-day regular job. For example, in an interview round, a panelist of senior engineers could ask you to solve a problem and code on a whiteboard. In all my experience as an engineer (and I have more than a decade of experience), I have never once needed to code on a whiteboard. The sheer disconnect of coding on a whiteboard could throw even the most experienced engineer off guard.

Another example is asking to solve a highly complex architectural problem in a 30-minute conversation, even if you are only a mid-to-senior engineer. In reality, architecture decisions are mostly made by software architects, principal engineers, or chief technology officers and handed down to senior engineers and tech leads for implementation. There is rarely a chance where junior engineers have the opportunity to solve complex problems. Do you think mid-to-senior engineers solve architecture problems in big corporations? In most cases, they are hired to maintain or add features to an existing application; rarely is it a greenfield project where they can test out their architectural knowledge and for good reason! I would be really scared if I found out that the bank that I use had implemented a new architecture design by a mid engineer or if they constantly changed their architecture. Conglomerates have good stable architectures that rarely change, and engineering in startups rarely requires the scale needed to maintain a larger user base.

So where do we expect these engineers actually test and hone such skills? But in each interview at tech companies, these are considered must-knows, so we end up with engineers with book knowledge gained from having to upskill without experience, only up to the point where you can convince the interviewer that you know such things.

Proving Mastery in an Abstract Field

How do you compare one engineer to another? How do you know if one engineer is 8–10% better than the other?

Is it the number of lines of code they produce? Which, by the way, is a very dangerous metric to use. There are multiple ways to overinflate code with boilerplate code and on the other end of the spectrum, multiple ways to shorten code to the point that it can’t be understood. Lines of code are never a way to measure proficiency.

Is it the number of hours they work? Unlike blue-collar jobs, working overtime does not mean value for the company. One engineer could work 16 hours in one day but not finish anything or introduce a lot of bugs. They can work 1 hour and solve the biggest problems the company has ever had by, for example, optimizing a critical part of the codebase. Time is also not a way to measure proficiency.

I could go on and on about all the different dimensions you can choose from to measure an engineer’s proficiency, but there will always be a case where it isn’t so. You can argue well; we can use story points. If they can finish, for example, 10 story points in a week. For those of you who are unaware, story points are given to each task by the whole team in a planning session. The team convenes and gives certain points depicting each task to somehow illustrate complexity. A really complex task could have 5 points and a simpler task could be 1 point. This pointing system is usually refined by the team as weeks go on depending on how well they progress on the project; for example, they become better at pointing a ticket based on the previous task. This is also flawed for a multitude of reasons. For one, the system does not consider social systems at play here. If I was a newcomer and I started to point tickets as smaller points even if the others think otherwise, illustrating to the team that certain tasks are really easy, I could be looked down on by the team. I would not know if there are any unspoken rules that exist so that the team is not in a state of crunch. I would also be unaware of how well this particular team measures against different teams with completely different tech stacks or how complex the existing systems are based on other constraints such as technical debt, current architecture complexity, and any social norms.

The main point being, unlike other industries, software engineer’s proficiency is not something obvious to measure. Add non-technical managers into the mix and you have a recipe for disaster. Non-technical managers anchor on certifications to use as measurements of success. It’s not obvious how skilled an engineer is, and so the easiest way to measure progress is just to ask them to do certifications. The caveat being these certifications again rely heavily on theory rather than application and some even just memorization. This is not true mastery; this is knowing for knowing’s sake. The lessons learned could easily be forgotten once you finish taking the certification exam.

The Rise of Automation and Obsolescence

On top of all that — the hamster wheel of always being up-to-date, always being questioned, unable to demonstrate any form of proficiency to non-technical people — you are also up against tools and frameworks designed to make you obsolete. With the rise of Artificial Intelligence, No-Code platforms that allow applications to be built without the need for engineers, and the rise of Software as a Service; it then becomes a race to the bottom for engineers. It becomes either becoming part of the top 20% of the best engineers across the world or becoming obsolete at one point and being unable to find a job.

Strategies for Avoiding Burnout

The odds are stacked against you as an engineer, and the only way to stay relevant and stay in the game is to outsmart the system itself. Here are some tips to help you avoid burnout as a software engineer:

1. Embrace lifelong learning: Accept that technology is constantly evolving, and your knowledge and skills will need to keep up. Instead of feeling overwhelmed by the need to constantly learn new things, view it as an opportunity for growth and development. Stay curious, explore new technologies, and continuously update your skillset.

2. Prioritize self-care: Take care of your physical and mental health. Make sure to get enough sleep, exercise regularly, eat well-balanced meals, and practice stress-relief techniques such as meditation or mindfulness. Taking breaks and disconnecting from work is crucial for maintaining your well-being.

3. Set realistic expectations: Understand that you can’t know everything, and it’s okay to ask for help or admit when you don’t have all the answers. Avoid putting too much pressure on yourself to be a “superstar” engineer who knows everything. Focus on doing your best and continually improving.

4. Find a balance between work and personal life: It’s essential to have interests and activities outside of work that bring you joy and fulfillment. Make time for hobbies, spending time with loved ones, pursuing personal projects, or simply relaxing. Finding this balance will help prevent burnout by providing you with a sense of fulfillment beyond your professional life.

5. Seek support from peers: Connect with other software engineers who might be experiencing similar challenges or concerns. Join online communities or attend industry events where you can share experiences, ask questions, and learn from others’ insights.

6. Advocate for yourself: Communicate openly with your managers about workload expectations, project timelines, or any concerns related to burnout. Discuss ways in which they can support you in maintaining a healthy work-life balance.

Remember that burnout is not solely your responsibility; organizations should also strive to create a supportive work environment that promotes employee well-being.