How to write code with interruptions?
July 18, 2011 9:06 PM   Subscribe

When I'm writing code but keep getting interrupted, how do I keep calm and carry on efficiently?

I'm doing web development but getting interrupted every two hours or so. It's usually someone with a question or another small task. But it gets harder for me to get back into the zone every time and I'm becoming short tempered.

If I can't do anything about the interruptions, what are some tricks I can use to quickly get back into the zone?
posted by jyorraku to Computers & Internet (17 answers total) 12 users marked this as a favorite
 
Well hopefully you can convince people to at least put it in an email if they're literally popping up at your desk and demanding attention.

But if that's what you're stuck with, maybe just go with the flow a little bit. Accept that you have been distracted, and you can't just jump right back in. Get up, take a walk, clear your head. Every two hours is a pretty reasonable schedule for a break anyway- I find I work much better when I walk away periodically.
posted by drjimmy11 at 9:20 PM on July 18, 2011 [1 favorite]


Ugh. I am very familiar with this problem.

One trick I've tried that kind of helps is to keep a paper pad next to me and write down exactly what I'm about to do ("Implement action to handle xyz form input" "Write test for bla bla bla" "Figure out which line is causing this error." etc.)

You may prefer a text file to a paper pad. The principle is the same.

Then when there's an interruption, somehow just the fact that I wrote it down allows me to snap back to the task more quickly. I usually don't actually refer to what I wrote. It's simply the writing that does it.

There's a time cost, obviously. But it seems to pay off in concentration over the course of the day.
posted by eeby at 9:22 PM on July 18, 2011 [1 favorite]


Man - every two hours? I'm jealous. I'm lucky if I can get 30-45min uninterrupted at work. It's a pain in the butt but a fact of web-dev life, so seriously, consider yourself lucky you're getting what you're getting. But that doesn't answer the question, so...

Earphone - good quality ones. My question asking about them is here. They do two things - people are less likely to bug you if they see them in, and two, if all I hear is my specifically chosen background noise (my personal choices are Groove Salad at somafm, or just simple white noise) I find it much easier to get back into the zone.

Also, when I'm distracted, the first thing I do once the distractee has left is write down (i use a skickies app on my desktop) a couple notes on where I was, what I was doing, and what my train of thought was. The process of actually writing things down seems to help me focus.

Additionally, completely ignore your email and IM while you're in the zone. Check it after your train of thought has been broken, but don't let it be the thing that zapped it.
posted by cgg at 9:30 PM on July 18, 2011 [5 favorites]


I believe you when you say (implicitly) that you can't do anything about the interruptions. But to the greatest extent possible, encourage people to use email for trivial or non-urgent questions.

One way to do that is to follow that practice yourself and maybe after a while some of them will start to emulate you.

Also, wear gigantic silver headphones even when you aren't actually listening to music. (Find some cheap ones on Craigslist.) That will deter a few of the easily deterred.

I'm not claiming that will solve it, but it might buy you a little relief.
posted by eeby at 9:36 PM on July 18, 2011


Best answer: It's hard for non-programmers to understand sometimes. For example, I've tried to explain to my wife, that when I'm programming it's like I'm following a noodle on a plate of spaghetti using only my eyes. My goal was to be able to say, Not now honey, I'm following the noodle. As should have been predictable, this has only resulted in hard feelings because I'm "ignoring her".

In an office environment, the only thing I've found that actually works is an office with a door. Barring that, I've had good luck with a "programming hat". This involves wearing a hat while programming, the more ridiculous the better, and letting people know that if you're wearing the programming hat, you mustn't be interrupted for anything less important than firefighting. Then while wearing the hat, give anybody trying to talk to you the full ignore. It's important not to abuse the hat though, and only wear it when you need full concentration.

posted by ob1quixote at 9:42 PM on July 18, 2011 [12 favorites]


I don't code, but when I'm deep in a dense thicket of prose in dire need of editing, I have been known to stick a sign on my cube that reads INTERRUPT ONLY IF BUILDING IS ACTUALLY ON FIRE.

I love the hat idea.
posted by rtha at 9:58 PM on July 18, 2011 [1 favorite]


Back in my halcyon days of web coding, I taped a simple sign that said CODING! to the back of my chair, and got frustrated when that didn't work at all. I made a joke police tape barrier for my cube that was totally ignored.

I had to show my boss that getting large uninterrupted chunks of time coding was worth far more to the project in the long run than she was getting from me answering moderately simple web questions all day.
posted by Sphinx at 10:00 PM on July 18, 2011


Wow, I thought it was just me. :)

Seriously though, I too write things down in a text file. I also like to keep certain files in my IDE for the specific project I'm working on.

The best one is, work at home. This only works if your boss approves. Though, my previous boss literally told me to go work at home because she saw how much more work I got done there. My current boss let's me work at home because I'm just that good and I don't live in the same city as the company. If you can do it, try working at home or at the library for a couple hours even to see how much better you can focus.

Good luck!
posted by minx at 10:05 PM on July 18, 2011


Ah, hack mode.
Some aspects of hacker etiquette will appear quite odd to an observer unaware of the high value placed on hack mode. For example, if someone appears at your door, it is perfectly okay to hold up a hand (without turning one's eyes away from the screen) to avoid being interrupted. One may read, type, and interact with the computer for quite some time before further acknowledging the other's presence (of course, he or she is reciprocally free to leave without a word).
You need to try to shift your incoming communication to something that you can respond to asynchronously (skype, irc, email, etc). If people approach you in person definitely give them the "1 minute" hand signal (index finger extended) and try to reach a stopping point before addressing them. Ameliorate with a quick "sorry, was right in the middle of something."

Anything beyond that is dangerously close to posting a huge, blinking "GENIUS AT WORK" sign above your desk. Signs, police tape, and hats will only hurt the image of the engineering department in a cross functional organization.

Some organizational strategies for maximizing contiguous programmer time are:
  • one or more designated work from home days per week
  • one or more designated days where meetings are not scheduled
  • scheduling meetings only during a small portion of the mid day (for example, between 11 and 3)

  • posted by outlaw of averages at 11:17 PM on July 18, 2011


    Best answer: Joel Spolsky is good on this topic:
    We all know that knowledge workers work best by getting into "flow", also known as being "in the zone" [...] The trouble is, getting into "the zone" is not easy [...] With programmers, it's especially hard. Productivity depends on being able to juggle a lot of little details in short term memory all at once. [...]

    Here's the simple algebra. Let's say (as the evidence seems to suggest) that if we interrupt a programmer, even for a minute, we're really blowing away 15 minutes of productivity. [...]

    Mutt can't remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he's sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds).
    So, pass that article on for a start?
    posted by AmbroseChapel at 11:40 PM on July 18, 2011 [4 favorites]


    Code in set chunks of two hours or less, taking a 20 minute break in between. Working constantly is bad for productivity. You need to take breaks, so why not try and time them so that you're interrupted when you aren't programming?
    posted by dougrayrankin at 12:37 AM on July 19, 2011


    One of my tricks is to get into the habit of not answering people immediately. When somebody comes up to your desk, say "hold on a minute." Then finish a couple more lines of code -- enough to get through a method, say -- and write yourself a comment about what comes next. Only then do you turn around and talk to the person.

    If the person is not familiar with you doing this, then this is the moment to give them the spiel ("Sorry, if I don't spend a moment tying up loose ends and writing down what I was doing then I'll be lost when we're done talking. What's up?") After that first time, don't mention it again -- expect them to remember it.

    This might help you regain your concentration a little when you're done with the interruption. But that's not the entire goal. The goal is to force the interrupter to stand around for a moment. It's a little bit like a slowban for that person. With some luck the person will say something like "let me know when you're a bit less busy, we need to discuss something" and walk away. For me, it also satisfies that urge to become testy since it's just a teeeeny bit mischievous.
    posted by rouftop at 12:41 AM on July 19, 2011 [4 favorites]


    Headphones.
    posted by sophist at 1:33 AM on July 19, 2011


    Always self-comment and document as you go. Get into the habit of writing some kind of flowchart for whatever you are working on, and check off the steps as you complete them.

    Relying on getting in the zone or in the flow, and then cursing interruptions, leads to lower productivity.
    posted by gjc at 5:43 AM on July 19, 2011


    There are two approaches here. The common one is to avoid interruptions if at all possible. Set up a rotating support schedule among your team, and make it clear to passers by who is "on support". This won't avoid any interruptions, but there's at least a chance that they'll queue up on the person who wasn't coding, and there's an explicit time budgeting for interruptions. Beyond that, tune your notification settings for email / twitter / rss / wtfever.

    The less practiced method is to reduce the price of interruptions. I really like Mylyn for this purpose. It's an eclipse task plugin that models what part of your code is interesting to the task at hand as you work. Since this varies by task, each one gets a model that you can suspend and resume. There's also a time tracker feature and connectors to pull tasks bug trackers and share models over. So when you close a bug and it gets reopened, you can quickly pull up the working set. I feel this sort of thing is only just beginning.

    Beyond that, try setting up virtual desktops for "programming" and "interruptions". You probably have a pretty good idea what sorts of programs / websites you'll need to have open deal with phone calls and drop-ins, so prepopulate the workspace seperately from your development and let it sit. For example, you might have a window open to the "new ticket" screen of your helpdesk support tool, to document it happened and has been dealt with. Then when you're done you can just hotkey back to the development workspace and everything's in order.
    posted by pwnguin at 10:47 AM on July 19, 2011


    Here's another option, coming from someone who has been the interrupter (when I was at an internship, and there were company-specific questions that could not be answered by Googling or looking at internal docs). When I needed to bother one of the devs, I'd write my name on the whiteboard next to a 10-minute timeslot that they chose, and worked on something else in the meantime. This worked for them because they could plan out their time better, and it gave me a chance to vary my workload a bit.

    Another option is instant messaging. Tell folks that you are only available through IM and wear headphones (preferably whole-ear ones like the HD280s or more comfortable Beyers) as a sort of do-not-disturb sign.
    posted by spiderskull at 1:08 PM on July 19, 2011


    I am CM/build support first and dev second so getting more than 20 minutes at a time is rare. It's probably a bit harder to do in a web development situation but in a straight coding environment I swear by test-driven development. It's more work up front, but the failing unit test will always tell you right where you were before you were interrupted. The approach also forces you to break up tasks into easily digested units of work. A lot of small tasks are easier to address in a distracting environment that a few monoliths.

    If that isn't enough, you also get your unit tests written as you go along instead of scrambling at the end of the project (you do write unit tests, right??!?). TDD also gives you an arena where you can refactor with a high level of confidence that you're not going to unintentionally break something downstream.

    If you're not a lone wolf in your organization, set up a system of "office hours" between your coworkers. For example, I share a great deal of overlap with one of my teammates. He is on point for questions that come in between midnight and noon. I'm on point for questions that come in between noon and midnight. We have trained our "customers" to send requests to an email list so we have a shared work queue. Not to say we still don't get drive-bys, but having all of these small pieces in place gets us as much interruption-free time as possible.
    posted by Fezboy! at 3:18 PM on July 19, 2011


    « Older Is this suicidal?   |   I need new glasses. Can you help me pick some out? Newer »
    This thread is closed to new comments.