Emotional Coding

The “five stages of grief” is a model of human behavior when faced with a significant loss. Software developers regularly face losses and adversities, from troublesome bugs, to poorly designed software, and missed deadlines. Is there a predictable progression in mental and emotional states in engineers working on software projects? How does that affect the quality of the software we produce and how does the individual affect the broader team?

There’s a natural progression for new software projects. First we venture into the unknown, work with new technologies, learn, and make discoveries. This can be a really fun time, especially if the project wasn’t already behind by the time it started. Optimism reigns. Momentum builds, but so do doubts in some of the original choices. Stakeholder demos approach and that is accompanied by some tensions. This is software, and something always goes wrong before (or during) a demo. But the team makes it through and heads go back down and hacking resumes. A momentous day arrives – the first customer order. Your hopes grow that the whole endeavor hasn’t been a waste of time. But orders mean deliveries and after some more testing you realize you’ve never seen so many bugs. A frenzy of activity, long work hours that bleed into the weekends, then boom! It’s done, delivered, shipped. Let out a little steam, have a beer, and relax for what seems like 15 minutes before the race resumes.

Progressions are happening at every level, each with its own ups and downs.

At a high level, consider your overall job happiness. Maybe things were great at first but now you’ve been doing the same thing for what seems like forever and you’d give anything to switch to another project.

Zooming in to the next level, you can see there’s a progression attached to the products you make. If you are at a product focused company, that is. As new products are conceived of and then mature the nature of the work changes over time and some phases have more appeal than others, depending on your interests. Alternatively, a product that never matures due to an unsuccessful launch or otherwise may leave the team downtrodden or disbanded.

Then there’s the software release progression. Plan, design, code and test, then release. This cycle probably has an associated typical emotional progression for each team member, with a simple example being the stress of crunch time leading up to the end of the sprint.

Is an engineer’s effectiveness tightly coupled to his or her state of mind? Software systems reflect the structure of the company that built them (Conway’s Law). Software modules reflect the mental model of the engineer that built them. It would be logical that an engineers state of mind also affects the code produced, the designs drawn, and the clarity of the interfaces that are formulated.

If you’re not on your game, if your family life is a mess, or if you’re distracted by pictures of cats, how much more likely are you to forget to convert units correctly in that equation you’re working on?

It’s interesting in software engineering how decisions or omissions at key points in time can have such dramatic consequences down the road.

Of course, mistakes are made when you’re feeling good too. Isn’t self-confidence and over-optimism relevant to the Second-System Effect?

As someone that works remotely, I have the “pleasure” of hearing my own internal monologue throughout the day, which has put me more in touch with my own mental state throughout the day as compared to when in an office full of activity and other people.

Being in touch with your emotions and those of your teammates makes you a better engineer. Recognize that if you’re at the end of your wits, take a break. If you are enthusiastically sprinting on some code, make sure you look up every now and then to make sure you aren’t missing something due to excess optimism. A little introspection goes a long way.