If you’re a professional developer, and chances are since you’re reading this article, you are, you’ve likely been given a deadline that felt unreasonable or a task that felt insurmountable, or a project that seemed like it was set up to fail from the start. I don’t think I’ve met any developer who hasn’t had this happen. However, if this doesn’t describe you, I’d like to meet you and learn about your place of employment.

Introduction

For many developers, dealing with poor projects and bad project managers is an unfortunate reality. They are given work to do with no input into what it will take to get done or how long and then when it takes longer than expected, it’s the fault of the developer. This is no good. Fortunately, there’s a solution, but we’ll get to that in a bit.

A Personal Story

When I was interviewed for my current position, one of the first questions I was asked was if I could, or more likely, would, fire a particular developer on the team. Now it just so happened that this developer happened to be the one who recommended me for the job. Fast-forward to today, those two individuals are no longer employed with us, but the developer who I was supposed to fire is still here and kicking. However, that’s not the story I wanted to tell, so we’ll jump back several years to my interviews.

One of the next things that happened in the interviews was I was told by a number of different individuals, including the project manager, how much of a mess the development team was. I asked for the project manager to elaborate and tell me about what was going on.

The project manager told me the development team never got anything done on time, they were constantly late, the software was buggy and required constant hot-fixes and maintenance between scheduled releases.

I asked this individual if the developers understood what they were building and if they had an idea of the big picture. The PM told me that the the big picture was understood by the PM and that each of the developers was told the bits that the PM had determined they needed to know. Furthermore, the PM didn’t have the time to explain all of this to “those d@$% developers.”

So now knowing the developers didn’t have any idea about what they were building, I asked how the time estimates were made. Did the developers assigned to each piece of work come up with estimates on their own, or did one developer come up with estimates for everyone?

I was told that neither of these were correct, and in fact, the project manager came up with all the estimates and made all the work assignments without any input from the developers. I asked if the PM had ever developed software or done web development. I was told that, “I didn’t understand that s@#$.”

At this point, with many of my instincts telling me to run away, I decided to see if I could learn any more. I asked if this process had worked out well so far. I was told that the developers were always late, always building the wrong thing (ya’ think?). I asked how the PM was expecting this to work considering their complete lack of experience actually building software, the fact that the developers had never been consulted about what it would take to build, not to mention they had no idea about what they were building beyond the myopic view of the software that the PM deemed worthy to share with them. Obviously, I didn’t word things quite like that, it was an interview after all.

My view on what the major cause of the problem was, was not the same as theirs, to say the least. Clearly though, there’s a problem when the development team has no input in the process and has no idea what they are building or how it even fit into the big picture.

Changing The Culture

Long story slightly shorter, I still ended up taking the job. I’ve had an interesting career so far, ranging from jobs where I was doing way less than I was capable of, to others where I was doing much more than I should be. After experiencing a wide range of cultures that I didn’t feel were conducive to being a well-adjusted, productive developer, and having no real way to make any positive changes, moving into management seemed like a way I could make a difference for a lot of developers who may end up having a better start to their career than I had.

Over the last few years, we’ve made a number of improvements. We’ve moved from SVN to Mercurial, we’ve move from FlySpray (a bug tracker that was on the third page of Google results when I searched for it by name) to Rally and then Jira. We’ve started to move to continuous deployment/delivery, to say nothing of continuous integration which we’ve been happening for years. Unit testing is the norm now, and TDD is happening more and more frequently. However, all these things by themselves do not help with changing the attitude of a company that sees developers as replaceable cogs in a machine, who turn ideas into code and code into money factories.

Only a change in culture will help with that, and it’s one that we are continuing to work on and change. Moving away from a culture that looks at the 40 hour work week as the bare minimum is not easy, but in order to get away from the death marches and the poorly planned and executed projects, it must be done. Developers have agreed to give up some of their time in exchange for a paycheck, but cultures where it is expected that developers eat, breathe, sleep and bleed code is toxic and it must be changed. If you cannot change it, and you don’t trust your managers to change it, for your own sake, please consider working elsewhere. There are plenty of places looking for developers that do have a healthy culture with a good balance between work and life.

Knowledge is powerful. One of the most empowering changes we were able to make is to turn work into a learning friendly place. We encourage people to try out new techniques and technologies, learn about them and how they might help make our products better and even how they may open up new opportunities for new business and new products. Some managers are worried about training their people because then the employees are more valuable and more likely to be snatched up or enticed by a better offer elsewhere. This is true. Employees that train and learn new things are more valuable, and some of them will leave. On the other hand, if they are not learning, they are stagnating. Perhaps it’s worse that those who are stagnating don’t leave?

What Was the Point?

I started out writing this article thinking that I’d write about burnout and how to recognize it and avoid it and possibly how to recover from it if you find out that it’s happening to you. And I will still end up talking about that. It’s funny too as this past week I’ve seen quite a lot of talk on Twitter about burnout and related topics. Perhaps it’s no more than usual and I’ve just been more sensitive to it lately as burnout has been on my mind. I also feel like I may be one of the worst people to talk about that topic (hooray Impostor Syndrome) since I’m most likely to tell my employees that they should not work extra time or outside of work to figure something out even if it would help a project get done sooner, while simultaneously doing the opposite. Do as I say, not as I do, right?

Never, in the time I’ve been here have I asked my team to work a holiday or weekend in order to get something done. That’s not to say that holiday or weekend or evening work hasn’t happened. But at this point any work outside normal hours is happening without me asking for it. All this leads me to another story, hopefully one that won’t get me into too much trouble, but in any case, here goes.

The Story of Face Punch Day

Going into the end of the year, 2010, we had a deadline dictated to the team (the culture was still completely broken at this time as I’d only been on the job for a couple of months) that we were going to get a new portion of one of our main products built and we were going to get some 14,000 new clients on it by the end of the year. The end of the year happened, and the product wasn’t done, so the deadline moved to February. February came and went, then April, then May. May 30th, 2011 was memorial day and the entire team was required to be at work, on a holiday, to hopefully complete this project that had no chance of getting done that day. Tensions were high, but we did our time and surprise, surprise, when we left for the day, there was still work to be done.

“Face Punch Day” was actually the following day, Tuesday morning, and a few of us had gotten in rather early to try to get a head start on this project that was really nowhere near completion. Early in the morning, a rather heated discussion happened between two rather high level individuals (both executive level) regarding a decision that had been made a few months prior, but one that apparently upset the VP. This turned into a screaming match that traveled across the length of the building, heading towards the front door and with threats including “I’m going to punch your *@#$ing face off” being yelled.

Once the yelling died down and both individuals were sent home, the rest of the team was left with a lot of uncertainty and worry, both with what, if anything, did this altercation, or near altercation, mean to their continued employment, as well as what was to become of the individuals involved. Eventually their fate was decided, but it was clear that a toxic environment combined with stress and ego lead to an explosion of emotions, words, and a display that should have been handled in a much better way. No actual punching of faces actually happened, but we continue to observe a day of remembrance each Tuesday after memorial day.

Rarely do dysfunctional teams have such a unifying event as this to make it very clear that the current path is extremely broken and must be fixed. This still took some time, but since then, I don’t think there has been an instance I’m aware of, of our developers being required to work overtime. Many aspects of our culture have improved drastically since then, but in many ways, both culturally and technologically, we’re still quite a ways from where I’d like us to be.

Where We Are Today

While we’ve come a long way, I don’t feel we’ve come nearly far enough. And all of this brings me back to the topic of burnout and how it happens. Last week I attended one of my team’s retrospectives. I asked a few questions that I thought were pointed but not accusatory. I wanted to find out how I would be able to know where the team was on the path to completing certain features and functionality that had been requested and when they thought it would be done. From my perspective, it wasn’t a big deal, but it was only my perspective and there are others to consider.

Others in the meeting thought I was being abrasive and confrontational. Being abrasive or confrontational had never been my intent. I just wanted to see that the team is striving to continue to improve and that there was ideally some way for me, as the manager, to know about what was being worked on and how long the team thought it would take to complete. But the way I was being perceived and coming across was not something the team was used to seeing. I was called out in private later, asked what was going on, and why I was acting how I was. I didn’t think I’d done anything wrong, but again, that was my perspective and not what everyone else was seeing. After some yelling and contemplating, I apologized to the team and continued to talk a bit with the developer who had confronted me (the same person who brought me in to take the job).

Really, this confrontation was out of concern for me. My behavior, to him, was uncharacteristic of my normal behavior. Typically, I am calm and level-headed, hard to frustrate and not easily perturbed. He asked me a few questions about my mood, feelings and general demeanor. My answers lead him to suggest that I might have burnout since my answers apparently matched up with WebMD. (And yes, it also likely suggests leukemia. I’m convinced that as long as you have any symptoms at all, WebMD will provide leukemia as a potential diagnosis, so I try to avoid it.)

Burnout and YouMe

Knowing the symptoms of burnout is just a start. Wikipedia lists twelve phases of burnout and mentions that they don’t necessarily happen to the order listed. Take a look and determine if you might be suffering from any of them or on a path to burnout.

The compulsion to prove oneself. - This is one I definitely identify with. Between striving to be a good manager and protect the people that work with me, while still attempting to show I have the coding chops to keep up with the new up-and-comers, trying to prove myself has been a constant. Taking on too much almost always follows along with this, so this one was no surprise to me.
Working harder. - Again, I definitely identify with this. While I’ve fought very hard to make sure that no one that works for me has to work any more than 40 hours per week, I’ve been terrible at keeping to this for myself. I haven’t done the math lately, but I’d be surprised if my average work week since 2006 has been much lower than 60 hours. Last year I worked 9-10 hours per day in the office and then went home and put in an extra ~700 hours. I’ve lost track of the number of times I’ve told employees to take their own time away from work as their own and not work on work projects while completely doing to opposite. Perhaps some of this comes from having a position where I’m essentially a manager full-time as well as a full-time developer. This is something I need to work on. No pun intended.
Neglecting your own needs. - This one also hits close to home. I’ve spent uncountable evenings and weekends working on work when I could have been playing video games or hanging out with my wife and family. I normally don’t have issues with guilt when spending time with my family, but often playing video games or doing other activities that I enjoy has brought on a sense of guilt that I’m not spending that time being “productive” and working through work issues.
Displacement of Conflicts - This is essentially being able to identify that there’s a problem but not seeing the source of the problem. It may very well be where I was a week ago.
Revision of Values - This is a stage where there is isolation from others, and denying basic physical needs. Work becomes everything and all they have time for. I don’t think I hit this stage, but likely only because my friend called me out. I can definitely see that this was where I was heading.
Denial of Emergent Problems - At this stage, the person suffering from burnout becomes less social and to outsiders can be seen reacting more often with sarcasm and aggression. I can see progressing quickly from one of the previous stages to this one, but I’m hoping that identifying the problem and working to correct it will prevent it from continuing into this stage.
Withdrawal - At this level, social interaction is minimized and drugs and alcohol are often sought as a coping mechanism. Feelings of lacking hope and direction are common. Some of this does resonate.
Obvious Behavioral Changes - The people closest to the person suffering from burnout cannot help but notice changes in behavior. This means coworkers, family, and friends.
Depersonalization - At this level the person starts to lose contact with themselves and don’t see themselves or others as valuable. There is even further lack of taking care of personal needs and their actions tend toward a series of mechanical actions.
Inner Emptiness - At this stage, there’s a feeling of emptiness and the person may try to fill this emptiness with sex, drugs and alcohol, often at an exaggerated level.
Depression - Often burnout is accompanied by depression. The person is exhausted, hopeless, indifferent and doesn’t believe there is a future for them. This can be extremely dangerous. Many developers tend towards some of these stages naturally with a higher than average number of developers falling somewhere on the Aspberger’s/Autism spectrum, which leads to withdrawals from social interaction and often depression.
Burnout Syndrome - This is an emotional and physical collapse and the individual should seek medical attention. If depression is involved, thoughts of suicide may be involved and may be seen as the only way to escape the situation.

Clearly, burnout is a big deal. Additional side effects caused by many of these symptoms can also be a big deal. Chronic lack of sleep can lead to brain damage and the onset of Alzheimer’s. Through much of my career and most of my life, I’ve felt that there was something big I need to do with my life, but I’ve not really ever felt that I know exactly what that is, or what it looks like. I remember at twelve years old having a minor panic attack because I was already 20% of the way to being 60 and hadn’t accomplished anything with my life yet.

The reality is that for almost every single one of us, nobody is going to die if our project doesn’t get done this evening, or this weekend. For almost all of us, nobody is going to lose their job. But even if that’s not the case, we need to take a step back and determine if the trade-off we are making for work is worth it. Is it worth trading away sleep now for potential brain damage or a shortened life? Is it worth giving up your life for a company or a project that is poorly managed? I don’t think it is. Rushing to finish projects that were under staffed or poorly planned doesn’t help anyone. It causes undue and unnecessary stress on the developers and QA testers and is likely to cause more bugs and errors anyway. It’s amazing how many times it seems that companies don’t have time to do it right in the first place, but somehow find the time to screw it up and fix it over and over. Numerous studies have shown that working over 40 hours (and I mean just barely over, not crazy numbers) may lead to short term gains, but continued work at that pace leads to poor software quality, more burnout and more turnover.

So in that case, how do we burn the candle at both ends to get the understaffed and poorly planned projects done on time? I suggest that we don’t. There is no safe way to burn the candle at both ends. Push for changes in the culture of your company if you’re working in a situation like this. Strive for better planning and staffing a project appropriately for when they desire it to be done. It will be better for you, better for your coworkers, better for your company, and better for your project. It’s not easy to bring about these changes either, but it’s worth it.

Conclusion

Many times I see developers bragging and/or complaining about how many hours they put in during a week or how late they worked or some other extreme and dangerous behavior. Startup culture seems to be rife with these examples. Just a few days ago I saw this quote: “I was being a bad co-founder and sleeping.” Now, I don’t know if this was intended facetiously or not, but I’ve seen messages come in from this same person at 3 or 4 in the morning, so I suspect it was serious.

We need to strive towards balance between work and the rest of our lives – myself included. If your company doesn’t support sustainable practices, I encourage you to work towards change. If that’s not possible, I encourage you to find a place that does support good planning and good practices. I would also like to hear your feedback and stories on this topic. Please let me know what you thought of this article and what sort of things you deal with at your job. See you next month.

Leveling Up: How to Burn the Candle at Both Ends