Archive

Archive for the ‘Psychology of Engineering’ Category

Emotional Coding

March 4, 2013 1 comment

The “five stages of grief” is an oft-referenced model of human behavior when faced with a significant loss. As programmers, we face losses and resolute adversities on daily basis, from bugs that simply refuse to be revealed, to horrible software, and missed deadlines. Having worked as a software engineer for the past 6 years, no doubt I have experienced the five stages of grief in my work, as have so many others. But I have also noticed other predictable progressions in the mental and emotional states of myself and my fellow software engineers (No, we don’t cry all the time… unless we are testing against IE). It’s interesting to consider how we come by our mental states and how they affect the quality of the software we produce. Happier coders code more better right?

Of course there are innumerable external factors that influence how we feel and behave on a daily basis, but taking a step back it’s not hard to see patterns. It seems to me that software developer mental states are highly correlated with the state of the system they work within. This includes the state of the company (whether it’s profitable), the state of the products (under design, development, or maintenance), the upcoming software release, family life, the weather, if there were enough donuts for breakfast, and so on.

First of all, there’s a natural progression for software projects. First venturing into the unknown, working with new technologies, learning, and making new discoveries. If you’re lucky and the project wasn’t already behind by the time it was started, this is a really fun time. Optimism reigns. If you hadn’t already, your team soon picks a direction. Momentum builds after a few weeks as do doubts in some of the original choices. Internal or customer demos approach and tensions grow. Things should work, but hey this is software, and something always goes wrong before (or during) a demo. But as usual, the team makes it through, so the heads go back down and the hacking resumes. A momentous day arrives – customer order numero uno! Your hopes grow that this whole endeavor hasn’t been a complete waste of time. But orders mean deliveries which means more testing and good grief are you’ve never seen so many bugs. A frenzy of activity, long work days bleeding 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 resuming the software development rat race.

Feel free to adapt the above to a spiral software development model if that suits you better.

But what level of detail are we focusing on? Progressions are happening at every level, each with its own set of 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. Hell, you’d even volunteer to work on the test framework or that ridiculous proposal to write your own database rather than use a real one. Anything to change it up!

Zooming in to the next level, you can see there’s a progression attached to the products you make. If your company is anything like mine, you might see major new products being developed then released every few years. If you’re lucky, there are times of discovery, hard work, perseverance, and celebration when the product starts raking in the dough. On the other hand, most of us have seen products go belly up, with the team left downtrodden or disbanded.

Next, I’d say there’s the software release progression, which is often tightly defined. Planning, coding, testing, release. We all are familiar with the moods throughout that cycle.

As my blood pressure reaches dangerously high levels thanks to IE 9, I am ready to reconsider my commitment to this profession…

But, perhaps most importantly, what are the predictable states I find myself in? A programmer’s effectiveness is tightly coupled to his or her state of mind. Software systems reflect the structure of the companies that design and build them (Conway’s Law). Likewise, code reflects the workings of the mind that conceives it. To what degree does our state of mind affect the code we produce, the designs we draw, and the clarity of the interfaces we formulate?

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 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.

Why oh why did we decide to split the records across two databases???

Maybe the team leader just made a hasty decision because he was uncomfortably full from that breakfast burrito.

On the other hand, mistakes can be made when you’re feeling good too. Presumably self-confidence of individuals or the team is involved with the Second-System Effect.

As a programmer that now works remotely, I have the distinct pleasure of hearing my own internal monologue mostly interrupted throughout the day. I’m distinctly more “in touch” with my own mental state now as compared to when in the office surrounded by activity and other people. I’m equally free to curse loudly when intermittent bugs refuse to be found and to jump and hoot when I finally get asynchronous speech recognition notifications to the python actors working.

Being in touch with the emotions of yourself and of your teammates makes you a better engineer. If you’re at the end of your wits, take a break if you can. If the QA folks are going insane because 3 software releases are going on in parallel, plan better for the future. If your team needs to blow off some steam, buy a pool table and ping pong table for the office like us. If you’re bored off your ass browsing the internet all day, are you sure you’re at the right company?

We should all strive to be happier coders. A little introspection can go a long way.

Effects of Ownership in Software Engineering

September 18, 2011 11 comments

What do you own? A home? Car? Quad-core computer? No matter what it is, you’ll probably agree with the statement:

“When you own something, you treat it differently.”

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

Depending on your personality and what “it” is, ownership might mean you put more OR less effort into upkeep. If it’s 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 pick up after yourself a little more. On the other hand, you might always schedule regular oil changes for your vehicle, because you could very well have it for the next decade if you don’t get that raise. With rental cars, why not “gun it” to get the RPMs up to 6K? After all, you’re not going to be held accountable for the early engine problems.

Clearly ownership affects human behavior in a number of ways, both positive and negative. And ownership is not a binary state. There are a range of possibilities, each having a unique effect on a person. You might own it, your family, your friend, or a rental company. Further complicating things, accountability and visibility matter. If others can easily prove misuse or negligence and hold you accountable for it, through fees, public humiliation, or otherwise, and if you’re aware of that possibility, you will modify your behavior accordingly.

The matter of ownership and its effects on human behavior are very 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 label as “proactive owners”. If John B. Coder authored a particular module and someone observes a bug in it, John takes notice, cares, and sees to it that the issue is resolved. At the other end of the spectrum are engineers who default to a “not my problem” attitude.

I believe engineers should take ownership of their work and an engineering company’s culture, process, and management should encourage and facilitate ownership. Specifically,

  • Module authors should write tests for their modules and be responsible for fixing the tests when/if they start failing.
  • An author should expect to be the owner for the lifetime of the product. By knowing they will be responsible for the long term maintenance and support of their work, they will put more thought and effort into it up front. Naturally people have their own interests closest to heart. Through long term ownership, a company can ensure its engineers individual interests are most closely aligned to those of the company. Programmers will work hardest to prevent bugs when they know that they personally will have to deal with the customer problems if they occur.
  • Management should push for this complete ownership even at the expense of short term efficiency gains.
  • When hiring, prefer engineers that demonstrate ownership and a “buck stops here” attitude.
  • Some of these ownership concepts are discussed at my company from time to time. But I don’t believe it is implemented as fully as it should be. Everything can always use improvement!