Developer Burnout
Anyone who writes software for the love of it knows, or will eventually know, burnout. Writing code is mentally taxing work. Fun work but work nonetheless.
Fun things in excess will eventually create a personal conflict. Even without a wildly successful project I have found myself questioning why I spend evenings and weekends writing code rather than playing video games, watching TV, making friends or interacting with my family and child. Is code really what life is about?
It’s perfectly normal to question yourself after spending multiple 16 hour days at a computer screen. Eventually something will snap. The stress reaches a level that warrants a break, and when there is too much stress it can trigger a full on burnout which cannot be remedied by a short vacation.
Many prominent developers have described their experience with burnout. These stories are a symptom of the underlying problem of being overworked, but also a cause of additional risk.
When a prominent open source contributor abandons their projects we all suffer. The code may continue to live on, but the most knowledgeable person is no longer helping to steward its development. In the examples I’ve seen, the project coasts for a while until it becomes apparent that something serious breaks, then it gets forked by someone new to continue development. CanCan is an example of that. The knock on costs of this can be high. The public discourse on StackOverflow may have references to the stale project for years. Developers unaware of the fork will continue to use potentially buggy code in their projects which in turn puts their users at risk. The man hours it might take to patch all the projects using abandoned and buggy libraries can easily run into the millions and perhaps hundreds of millions of dollars.
Within a business the cost of burnout is different. Overworked employees are more likely to leave, increasing turnover and taking their knowledge with them. Experience is an underrated productivity booster in tech. I have seen time and time again developers spend hours or days, sometimes weeks trying to track down bugs, or make improvements on a code base they’re unfamiliar with. Someone familiar with it may often be able to accomplish the same thing in minutes. This 1000x improvement in productivity comes from knowing the code — something you will not get from a fresh developer, regardless of how senior they are. In the knowledge economy, when a business looses knowledgeable employees it hurts the bottom line.
What can we do to prevent burnout?
Burnout is caused by a combination of stress and fatigue. Both of which can be addressed on a person by person basis. More money, fewer hours, or scheduled breaks could be simple things to help alleviate the problem. If you’re feeling burned out or close to it, let management know — they may not be aware of the problems.
If you are burning out on personal projects, find something to break up the work like doing some exercise, or learn to delegate some of it. Consider what external factors might be increasing your stress and address those causes.
Causes are systematic, that is to say any fix cannot be a one-time event. Going on vacation for a week, or watching a movie will not address the underlying cause of the stress and fatigue. A change to the system is required.
Finally, if you start to feel burned out, do something about it early. The last thing we want to see is more abandoned projects and employees quitting.
