Home Epic Stories

Not coding makes me cranky (Fight for the right to code)

Author: Melanie R.

By Melanie Robertson with Warren Volkmann
HP Inc.

I get so much enjoyment from solving problems and writing code. When I am deep into a challenge, with the full context held in my mind, the code begins to flow. When I get “in the zone” for hours, I am not only highly productive, I am also very satisfied with my work.

Sadly, I am often frustrated by interruptions.

One day, when a string of interruptions left me staring blankly at the screen trying to figure out where I left off, I grabbed a pen and wrote, “Not coding makes me cranky.”

I didn’t post it, but a passing coworker noticed it and chuckled. The note itself caused an interruption, but I kept it around. It made me more aware of interruptions – how they happened, why they happened, where they came from and who they came from.

As patterns emerged, I began to seriously analyze the interruptions and how switching contexts impacted my coding productivity. After a few weeks, I had created not an app, but rather a Powerpoint slide deck titled:

Fight for the Right to Code

Context Switching Avoidance Patterns

I presented it at a Tech Talk and found I am not the only one who gets cranky. Interruptions and irritation are almost universal.

Coding is interrupt driven

Coding is by nature interrupt driven. It has been from the start. (Anyone remember batch processing on tape?) You work on one thread: testing, creating, refining, and deploying until you are satisfied. Then you switch to another thread, hoping that the first thread is complete, but knowing that it may come back to you in the future in the form of a defect or refactor need.

We all end up juggling code. It’s in the nature of what we do.

With human interruptions, the types of interruptions and the ways you can deal with them are more complex. Studies have shown that an unplanned interruption in the middle of a coding task will cost you about 30 minutes. It is worse for planned interruptions, like meetings. As I tracked what got in the way of coding, I discovered that I sometimes arrange my entire day around planned interruption. A day filled with meetings really kills my productivity.

One study, which first appeared in Game Developer magazine in 2013 under the title Programmer, Interrupted, looked at sub-vocal utterances during a programming task to find different levels of memory load during programming tasks. It showed that when you have a lot in your mind – a high memory state – it takes a long time to get everything back after an interruption.

Help Reddit

I turned to Reddit to see what kind of tips and tools I could use to fend off interruptions. I found two key points:

  • Push for better communication, not more communication
  • Fostering communication should mean that you make it easier for people to speak up rather than make it easy to be interrupted.

Interrupt Handling

As a technologist, I had to apply technology to the problem. I found this Interrupt Handler:

bit flag;
#pragma interrupt_handler ISR
void ISR(void)
{
   flag=1;
}
void main()
{
   --
   --
   while(1)
   {
          --
          --
          /* Wait for the ISR to set the
          * flag; reset it before
          * taking any action. */
          if (flag)
          {
          flag = 0;
          /* Perform the required action here */
          }
   }
}

If only interrupt handling for humans was so simple. We don’t (yet) have dedicated software for handling human interrupts.

Here are four less technical things you can do to take control of interruptions:

  • Be aware of your interruptions. Keep track of what interrupts your coding and how long it lasts. This is what my “I feel cranky” note helped me do. 
  • Comment before you quit: When interrupted, take 15 seconds and comment where you were, and what you were going to do next, before you dump your context and engage the interrupter.
  • Prioritize tasks: Know what is most important. Don’t interrupt important work for unimportant things.
  • Have a bouncer: For a team of coders, designate someone who decides when developers can be interrupted.

Email – Don’t get sucked in

My biggest source of interruptions is email. Emails pop up all day every day, tugging for attention. This pits me against myself. I like to keep my inbox clean. To take control of email interruptions, I had to let go of the dream of an empty inbox.

Here are ways to cut time on email:

  1. Schedule purging times
    Set aside time every day to clean out emails. You’ll have to decide when the best time is. It may not be first thing in the morning.
  2. Let go of the dream of an empty inbox
    I do like to have an empty inbox. To do that I put things in a quarterly folder. I don’t read everything before I move it to the folder. I just can’t.
  3. Differentiate by priority
    As humans, we tend to try to give everything equal priority. The reality is that not all things are equal. They’re just not. When a new task interrupts, ask yourself if it is really, really, really important. If it is, then give it a flag, and be diligent about anything with a flag.
  4. Don’t feel pressured by immediacy
    You don’t have to respond immediately.
  5. Save more by doing less
    Teams have succeeded in reducing the amount of email they generate. The amount of time that they have taken back has been significant. When you start to write an email, think about what you want from the person you are sending it to. Then ask yourself, “Can I make it as short as a tweet?”  Sometimes I will write a complete email, then I don’t send it. I rewrite that entire email in a tweet format – 140 characters – then send that. I know they will appreciate how concise and precise my message is.
  6. Personalize to familiarize
    Use templates wherever you can. Have a signature block saved, which you can paste at the end of a message. Have an Out-of-Office message saved. Technology could really help us here. Are there bots that we can write that can triage email that is coming in – not just filtering, but actually handle things that we know are coming? (My colleague William Hertling wrote a science fiction book called Avogadro Corp., about an email optimization program that becomes self-aware.)
  7. Targeted email over blast-o-grams
    If you are being asked to go to a meeting, there is a tendency to return and want to share the meeting by sending slides to your whole team. That is not productive. Your colleagues are probably working on separate stories. Their thoughts are not shared. Consider other ways to share. Perhaps a quick 15-minute huddle? Then give more in depth feedback to someone who needs it. If we are just email blasting, you are causing others’ productivity to slide.

Team Communication

I highly recommend using a team communication tool –  Hipchat, Slack, or Campfire – even though they are a source of constant interruptions. These types of interruptions are more relevant for the team than email because they surface immediate productivity blockages like, “Who has the test thing-a-ma-jigger?” It may be disruptive, but this is appropriate disruption. It keeps a team connected in a way that can be highly productive. I would still be cautious and sometimes turn off my team communication app when focus is crucial.

To stay productive with these new always-on tools, we need to develop a culture that recognizes that not everyone needs to know everything. When you need to seclude yourself to focus on your code, you should be able to check out, but remember to notify others so they won’t worry. You might send a message like, “I’m going solo for the next two hours. I will check messages before I leave.”

Healthy Patterns

Since I wrote that yellow sticky note to myself, I have adopted these behaviors for my own work. I hope these healthy patterns will help you avoid context switching and the damage it does to your productivity and work satisfaction.

  1. Do one thing at a time
  2. Keep stories as small as possible
  3. Keep things out of email, when possible, and keep emails short
  4. Ensure that you are not interrupted if you need to get something done
  5. Accept that you cannot do everything
  6. “Agile” is not a code word for interruption-friendly
  7. Pull interrupters into the dirt

Into the dirt

That last point refers to a clever photo that has been going around on programming forums and tweets. (Who knows who to credit and thank for the original?) It shows a programmer digging a hole, working hard, doing his job. He is surrounded by a supervisor, project manager, product development manager, IT manager, marketing manager. You get the idea.

Each one of those people has an interest in the digger’s progress, but if each interrupts the programmer, no digging will get done. So what’s a programmer to do?

Try pulling interrupters down into the hole. Let them help move some dirt. Ask them to pair with you on a story. Programmers need to be help interrupters understand the impact of disruptions. Then, perhaps, they will think twice before they interrupt.

References

Here are some of the best studies and resources I found on taking control of interruptions:

Other popular posts on the HP Developer Portal