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.

Effects of Ownership in Software Engineering

When you own something, you treat it differently.

It’s a simple concept, but one that I believe is incredibly important and under-appreciated in software engineering.

Depending on your personality and what “it” is, ownership might mean you put more or less effort into upkeep. If “it” is your car and you don’t mind a bit of trash here and there, you might let it go, but if it was a friend’s car maybe you’d be more proactive about picking up after yourself. If you know you plan to own your car for years to come, you may choose to keep on top of maintenance so that you have fewer issues down the road.

Clearly ownership affects human behavior in a number of ways, both positive and negative. Ownership is not a binary. There are a range of possibilities, each having a unique effect on the person. Accountability and visibility also matter. If an individual’s actions are visible to the team, the person may modify their behavior accordingly. The team as a whole has ownership of their project and should maintain discipline in how the software evolves.

The matter of ownership and its effects on human behavior are quite evident in software engineering. In this context, I’m talking about ownership of both lines of code and the resulting products. Many of the best engineers I’ve worked with I would describe as “proactive owners”. On the other end of the spectrum are folks with a “not my problem” attitude.

Consider how ownership should factor into the work your team does. Potentially the team taking ownership of their work, collectively, is most important. But for that to work the individuals on the team have to step up as well.

If the team is to be responsible for the long term maintenance and support of the product they build, and are conscious of that, they will be more inclined to invest thought and effort throughout the project.

It’s motivating to know that, when a bug arises with a customer, that you’re going to be the one that has to deal with the problem. End-to-end ownership may have a dramatic effect on the overall results that your team can achieve.

When hiring, consider whether you should be looking for candidates that demonstrate taking ownership in their past work.

Some of these ownership concepts are discussed at my company from time to time, but I think we should consider them more frequently.