Software without anger: managing yourself

After our first two articles ( Software without anger: managing the development team and Software without anger: managing vendor relationship ) in this series of anger management in software projects we got a lot of feedback asking us about how to manage anger on a personal level. What can we, as software professionals, do to reduce anger in software project? Be it within the team, with stakeholders and even with ourselves ( this last one becomes obvious when you think about how many times you’ve wanted to bang your head on the table when you realized that you should’ve written that generalized class to validate the data before an insert or something along those lines… ).

So today’s article is about us. Us the software professionals (ahem).

We know we can do a lot (and we should’ve done a lot) to make software projects anger and stress free. Maybe we have our own list of those to-dos. Here’s our attempt at that list…

1. Expect and accept anger as normal in software development.

This one is the same for all of the articles... Since the situation is the same, so I’ll do another ctrl+C and ctrl+V from the first article:

In any endeavor where there is a lot of unknowns and yet the risks and cost of getting things wrong are big, anger is natural. Anger is actually sometimes a good sign in software projects - it shows people involved in the process are emotionally attached to what they are doing and they care enough to voice things out. It is the negative aspects of anger like the blame game, shutting off channels of communications, creating bias, etc. that are destructive that you have to be worried about. If you expect and accept the fact that there will be anger, you can take steps to reduce it, manage it or channel its energy to a creative force.

It is the sudden rush of anger that you don’t expect in the otherwise calm and civil workplace (well for some I hear) that makes us go off balance. Instead of managing it we fumble and make it worse by being irrational and in many a case damage our relationships with others in the team and damage the chances of success in a software project.

The moment you expect anger as a natural outcome, you’ll be able to address it with strategies you know that work for you in other circumstances in your life. The particular strategy that works is very personal. Some people just takes a deep breath, someone I know takes a toilet break! For me the best thing is to stop saying whatever I was saying for a minute or so.

But expecting anger as a natural expected “artifact” doesn’t only mean that you can snuff it out when it comes. It also means that you can take steps to make sure situations that create anger do not happen, I discuss some such ideas below. And apart from snuffing it out, or avoiding it completely, anger can be channeled for the good of the project too! Anger is in essence passion and there is always a good use of passion in software projects! Good project managers us this passion all the time in situations like brainstorming or technical architecture discussions.

2. Prioritize, prioritize and prioritize

This is probably the most important single step you can do on a personal level to manage anger in your software project. There will always be way too many tasks coming towards you and there will always be a looming deadline that’s just too close for comfort. The only way to reduce stress (your own and the team’s when others are waiting for your work for theirs to be done) is to know what tasks are the most important.

Prioritize your tasks. Discuss them with your tech lead or manager. Discuss them in your daily stand-up. Scream (ok, maybe not scream in anger, that would defeat things ) if you feel you’ve been told to do something that you feel should not be high priority. Setting the priority of you tasks should be your highest priority :)

3. Read the spec!

OK, I probably mean understand what you are supposed to do in a task before jumping in to code it or test it. This might mean just reading the task ticket, or watching a video that explains things. But investing a little time to understand the task properly saves a lot of your time later on. It sounds very obvious, but I think we all know that we can be drifting with the flow on a lot cases and just jumping in to the code feels a lot easier sometimes rather than talk to a product manager about something that’s confusing. But that is a recipe for a heated conversation somewhere down the line. Not worth it.

4. Keep an open mind

Nothing in our field is set in stone. No technology is the final word and nothing is perfect. And today’s greatest stack will be the trash of tomorrow. That’s how our space is like, we knew it when we got into this. So there is absolutely no reason at all to be a staunch supporter of a technique, stack, idea, “pattern”, DB, __ (fill in the blanks). If you keep reminding yourself this fact then keeping an open mind is easy, and then discussions and debates about technology becomes finding out good solution for the problem at hand with the currently available skills and technology - rather than a religious war that these discussions sometimes warp into :)

5. Remember that there is always a next version

There will always be scope in your work. You will never be able to finish all the things you wanted to do. Scope your work, do what’s needed now and plan the rest for the next iteration. This helps move the project forward, keeps your boss and your teammates happy and you out of anger.

I’ll keep to the pattern of this series of articles by using a 3 stooges picture. This just one of them.