At my last company us developers complained that we were getting interrupted too much, so the boss asked us to keep a list of interruptions. By lunch on the first day we all had 3+ pages, so he believed us and we implemented the following:<p>Each week, one pair of programmers would be designated the "consulting developers", and a big sign would be put above their desk. They were the <i>only</i> developers that could be interrupted for the week, allowing the rest of us to get a lot of work done. If the consulting developers needed to ask something of other developers, we tried to save it up for lunch, as we mostly all ate together anyway.<p>This made an enormous difference to our productivity, which everyone in the company took notice of when the number of "development days" we got done each week increased dramatically.<p>At the start we thought of "sacrifice one for the good of all" and we didn't look forward to our turn. As time went on it actually turned out differently. We usually enjoyed the "consulting" time as it meant a break from the routine of working on endless tickets, and it also kept us in touch with what the rest of the company was doing with regards to deploys, environments, configs, etc. etc.<p>AFAIK they still do it today
I'm a PM, and I consider it my most important responsibility to prevent interruptions from reaching developers. By redirecting inwards-bound interruptions to myself, I've probably reduced developer interruptions by 80% since I started.<p>What I've found is that the typical developer/engineer is really bad at saying "no" or "not now" to others. The solution then is to work the other side (sales, marketing, etc) to interrupt someone else (me) instead. Even if it's a relatively simple technical question from sales, I can convert the in-person active interruption to a passive email notice (at the very least).<p>The typical office environment (and system) is not productive, so at this point it's up to the individuals to reduce the impact of the system on the team's productivity. (which is a sad reality...)
I wonder how much money is wasted via lost productivity due to open office plans. On a per-year per-programmer basis private offices are not very expensive.<p><a href="http://blog.fogcreek.com/the-price-of-dev-happiness-part-two/" rel="nofollow">http://blog.fogcreek.com/the-price-of-dev-happiness-part-two...</a>
<a href="http://www.joelonsoftware.com/items/2006/07/30.html" rel="nofollow">http://www.joelonsoftware.com/items/2006/07/30.html</a>
<a href="http://www.joelonsoftware.com/articles/fieldguidetodevelopers.html" rel="nofollow">http://www.joelonsoftware.com/articles/fieldguidetodeveloper...</a>
I would like to point out in my experience that I've found pair-programming to provide excellent interruption-recovery capabilities. Even if both people in the pair are interrupted, they're very good at getting each other back on task and filling in the gaps left in each others' trains of thought.<p>(Disclaimer. The broader applicability, appropriateness, and overall desirability of pair programming, Extreme Programming, and other agile methodologies, or any of the other implications thereof, are not addressed in this post. Void where prohibited. No warranty, express or implied.)
Most of the comments are discussing interruptions in general, and could have been posted on any article about programmer working situation etc, but I think some of the most interesting in this blog post is the attempt to measure cognitive/memory load (both retrospectively, in a research situation, and perhaps eventually live).<p>Imagine something like the ubiquitous sleep trackers for mobile devices which can track your sleep pattern, and both give you feedback on how you sleep, and also select the best time to wake you up within a certain boundary.<p>Could we imagine something similar for engineers? We already have very rough tools to provide feedback on productivity, like RescueTime, but a context-aware tool that can model cognitive activity based on edits, switching from one function to another, viewing two files simultaneously, git commits, etc, is far more advanced.<p>Perhaps if you wanted to ask a programmer a question, you could ask for him to be interrupted sometime during the next half hour, and the system would choose the time where it would be least disruptive?<p>And I'm also interested in the discussion of ways in which it would be easier to remember/reestablish context. I wonder if some of this is transferable to other domains, for example deep academic "knowledge work" - working with annotated articles, several windows of notes, trying to synthesize ideas etc.
I find it hard ever to program for hours straight, no matter what the external stimuli is. However, I've found that test-driven development has worked to get me back on task after I've strayed. The physical act of just entering in "rake test" and seeing "Tests passed" can be enough of a trigger for me to get back into coding...and if I've left some broken tests for me to fix, I have a much easier time remembering what I needed to do next...without the extra overhead distraction of finding my to-do list.<p>Of course, one could argue that the monotony of writing tests is what keeps me from being fully engaged to begin with :)
I saw an interesting situation at Google many years ago. There was a "bullpen" in which 8-10 people sat. That was for my team, a bunch of pager monkeys with a rotating on call rotation. We were operation-oriented as you would expect. Not too far away, the developers for one of our services had their desks.<p>At least one of the ops people on my team and at least one of the devs on the other team were, well, loud. I don't know if they had hearing issues or what, but they were significantly louder than most people. You know the type. That's just how they are.<p>Immediately over the cube-wall from us on the other side was a bunch of technical writers. They couldn't get any work done because of the racket from us. We got complaints. My boss used to keep a tally on one of his whiteboards. This is the thing where you go |||| and then put a slash across for the fifth for those who aren't familiar (is this a local culture thing?). I think they ultimately tried to get moved to another building, <i>away</i> from the people they supported.<p>On a <i>third</i> side, there was a bunch of project managers. This was back in 2007, so OpenSocial was the "big thing" then. So we had to deal with the blathering coming out of them most afternoons: "what if this person is friends with this person on this service, but isn't friends with this person on this other service, and then this third person shares this thing to the second person, does the first person get to see it?"<p>I'm surprised ANYTHING got done there. Come to think of it, that might explain a few things. Another team up in that same space was the Lively group, and everyone knows what happened with that project.
Even though I rarely use headphones, the idea that there are actually companies that don't allow engineers to work with headphones blows my mind. I thought I worked in some pretty strict places, but never anything that extreme.
I don't understand why companies don't try an approach more like what Universities provide their students. If you need a quiet place to study, you can go to the library, where you may often find private rooms for even more seclusion and quiet. If you prefer someplace busier, try the student union or the food court. Right after getting my CS degree, my boss pointed me towards a desk in an open office environment and I was supposed to start cranking out value for the company in that one environment. Sometimes I like it, I like the impromptu conversations with fellow developers. But other times I need to shut out all distractions and outside noise and movement but I don't have that option.
Unnecessary or poorly planned meetings are probably the biggest interruption here. God-forbid the pre-meeting meeting. I tend to stick to small, mundane work until a part of the day where I can focus for while. You can get more done instead of frustratingly failing to get deep into larger projects.
Whenever possible, I delay interruption by taking 15-30 seconds to cache my current train of thought while holding up a "one moment" finger at the perpetrator. Just distilling my train of thought into a sentence or two, or a mnemonic device of sorts, helps me get back into what I was doing quicker.
The interruption issue has plagued me for the last 10 years. Firstly working at home with flatmates or wife, then with children and now at an office next to the marketing team.<p>Instead of trying to fight the interruptions themselves, I decided to try and become better/faster at context switching by training myself to compartmentalize the jobs on hand (programming/helping kids/answering questions).<p>It took a while to figure it out and i'm still getting better at it, but so far it works pretty well and I can jump between contexts much better than i could before. When I get interrupted, I'll take a snapshot of where i am, store it away and 'switch' to the new issue.
When talking about productivity, it's important to acknowledge the difference between speed and progress. While working uninterrupted is great for development speed, it might also lead you down the rabbit hole, working with irrelevant features of your liking. I find that regular interruptions helps setting a new course before going too far in the wrong direction.<p>This is one of the reasons why agile methods work so well. Small tasks limits the scope of concentrated work, reducing the risk of going astray. Pair programming offers a watching party, who can guide and direct while you are busy tunnel-visioning some small method.
Working from home can be the worst (especially so if you have kids). There is nothing more frustrating than not being able to concentrate on a task for more than 45 minutes when your, "warm-up," time is about half that time... effectively giving you 20-some-odd minutes of actual work at a time. In fact it can be down-right torture.<p>The best, "snake-oil," solutions I have are:<p>1. <i>Well-delineated boundaries for interlocutors.</i> This means scheduling my, "off-limits," time and communicating those boundaries to the people around me. Concessions are made by appointment and I try to plan out my time a few days to a week in advance depending on how busy I am.<p>2. <i>Write everything down.</i> I try to be methodical about this but I am characteristically spontaneous and disorganized. Therefore I keep notebooks nearby when I'm not at the computer, I have a whiteboard near my computer, and I have a very organized filing system on my computer where all of my thoughts eventually end up. I find that having different mediums that I can switch between very helpful -- many an algorithm has been conceived of in the shower, doodled on a piece of graph paper (I'm a very visual thinker) over breakfast, and eventually compiled before lunch after I've finished with my emails for the day. Having record of it in multiple places seems to reinforce my memory and after reading this article I suspect I now have an inkling as to why.<p>3. <i>Never leave a thought unfinished.</i> This can be frustrating both for myself and my spouse sometimes when it's near the end of the day and I'm only half-way through something important. However I cannot enjoy myself and let my mind wander if I have some half-finished thought still rummaging around in my head. It's easier to let the mind relax and be creative if you can finish each thought... even if it's simply writing the rest of it out or hammering out all of the test cases you can think of. As long as there is some record of it in its entirety my mind seems to be able to be satisfied with it and leave it alone. It also helps so that when I get back to work on the problem that I'm able to get up to speed and not having to, "finish my own sentences."<p>After reading this article I began to wonder if there were any cognition-enhancing tools that are integrated with popular development environments for assisting programmers in remembering where they were in a large refactoring or what they still have yet to do in various locations of a code-base, etc.
This might not be the appropriate thread for a job post, but if you are the kind of programmer who likes library voices, quiet concentration, and no interruptions, this is something we're trying to cultivate for ourselves at CircleCi. Job post here: <a href="http://news.ycombinator.com/item?id=4993738" rel="nofollow">http://news.ycombinator.com/item?id=4993738</a>
Interesting blog post presenting different types of memory and the use of these types by programmers. However, the introduction of the piece feels a bit off, and the overall coherence is somewhat lacking. It is as if the writer was being interrupted continuously while writing it...
I seem to be much interruption-tolerant than all those articles imply.
On other hand, I'm lucky if I get any code to write at all, because it's mostly communication, planning, system support and debugging that consume time.
I found this section of the article of particular interest:<p>"A code narrative is an episodic memory aid that helps a developer recall contextual details and the history of programming activity."<p>I created Labradoc (<a href="http://labradoc.com/" rel="nofollow">http://labradoc.com/</a>) to encourage a form of manual "code narrative" (e.g. a form of development journal).<p>Here's an example from one of my personal projects: <a href="http://www.labradoc.com/i/follower/p/android-arduino-handbag" rel="nofollow">http://www.labradoc.com/i/follower/p/android-arduino-handbag</a><p>I find it really valuable for context-switching between projects.
I think Pomodoro Technique works well against interruptions or at least against unintended interruptions. That's why I made and use regularly Tomatoes[1] pomodoro time tracker (now I'm on my long break).<p>[1] <a href="http://tomato.es" rel="nofollow">http://tomato.es</a>
Do these numbers get inflated for a programmer with ADHD?<p>I find it takes me much longer to get back on track after interruptions. I work from home and deal with a ridiculous amount of interruptions. After 9am, I usually have to just give up for the day.