12 ms·

Programmer Interrupted

366 points by Off 14y ago

guard-of-terra 14y ago
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.
fennecfoxen 14y ago
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. (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.)
- lawnchair_larry 14y ago
  I see it as one giant interruption. I'm not sure what I dislike more, "pair programming" or "open concept".
  - fennecfoxen 14y ago
    Indeed: Pair programming does not work for all programmers or all programming shops. It is possible to do it wrong, especially by making it mandatory for people who do not want to do it. Depending on its implementation it may have other negative properties that render it unsuitable for any given purpose. Its suitability for any particular purpose is a broad question which cannot be adequately addressed in the context of this little conversation! But. In my experience, when I was pair programming, and the pair programming was effective to begin with, then: when there were interruptions, the interruption-recovery process was significantly streamlined. I infer that this is one of the ways through which teams that actually already do pair programming manage to improve their productivity enough (relative to singleton-programming) to justify the arrangement.
  - zaptheimpaler 14y ago
    As a college student, I do a lot of pair programming. IMO, the efficiency of pair programming comes down to how well matched the two are in skill, and how well they can communicate with each other. Depending on those two variables, it can be much more productive than a single programmer, or a huge roadblock to getting anything significant done.
    - fokov 14y ago
      The problem is the business isn't paying for a single programmer's value, it is paying for two. The only time I have known pair programming actually worked pretty good was when a senior would take a junior under their wing when the junior was first hired. This would facilitate quick ramp-up for the junior to know all practices and the vast amount of things that are not documented (or updated). Keep in mind this only lasted a couple of months max, and not necessarily every day.
MattRogish 14y ago
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. http://blog.fogcreek.com/the-price-of-dev-happiness-part-two/ http://blog.fogcreek.com/the-price-of-dev-happiness-part-two... http://www.joelonsoftware.com/items/2006/07/30.html http://www.joelonsoftware.com/items/2006/07/30.html http://www.joelonsoftware.com/articles/fieldguidetodevelopers.html http://www.joelonsoftware.com/articles/fieldguidetodeveloper...
- trggrer 14y ago
  Like life, balance is everything. If you want total privacy, better work from home but if you need physical presence/collaboration, regular cubicles in rooms/areas of 8-10 cubicles + a boardroom looks like a win-win to me. I guess it depends on the kind of programming you're doing and the teams composition.
  - MattRogish 14y ago
    It has nothing to do with "privacy" and everything to do with un-necessary distraction. Yes, face-to-face, voice-based collaboration can be a good thing, but very rarely do you need it 100% of the time. Need someone to look at your code? Ask them to come over and look at it. Need to chat with someone to discuss the design of some code? You can still do that. Why folks somehow tolerate "everyone gets bothered by any side conversation" is beyond me, especially when you can have perfectly fine collaboration without open-plan offices. It's incomprehensible why companies with "communication problems" think that will be solved by throwing everyone into one room. I bet good money the problem isn't that Jane isn't overhearing Joe and Bob's conversation. It's some deeper disfunction that is being exposed as "communication problems".
- majormajor 14y ago
  I've been a developer with a private office and I've also been on a small (< 10 person) team in an open office plan. Give me the open office any day. If there's a side conversation not of interest to me, I tune it out. But frequently there are ones that are of interest to me that I'm able to either contribute to or learn something from. It's great for group troubleshooting of sudden issues, too.
ericHosick 14y ago
The best work I've done is when I start in the morning and go for a break only to see it is now dark out.
danso 14y ago
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. Of course, one could argue that the monotony of writing tests is what keeps me from being fully engaged to begin with :)
hkmurakami 14y ago
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. 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). 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...)
- DrJokepu 14y ago
  Curiously enough, in my experience, the vast majority of interruption I receive is not from "external sources" but rather from other developers, typically junior members of the team seeking advice or guidance. I wonder how you would address that?
  - epochwolf 14y ago
    I sit right next to a tester and he is a constant source of distraction.
    - skrebbel 14y ago
      Did you ever bring it up?
      - epochwolf 14y ago
        Several times. I was told to allow him to interrupt me. :/
  - gpcz 14y ago
    Part of that depends on the type of advice or guidance. Some of it might be a symptom of the project's bus factor being too low (inadequate documentation, ambiguities or holes in processes, etc), which your organization can fix by paying down some of that technical/process debt. Other forms of advice (career-related, higher-level tech stuff, etc) would seem more like a mentor role. For that stuff, you may want to schedule "mentor time" in a slot advantageous for yourself, such as the last hour of the day.
maximumsteve 14y ago
Does instant messaging and email in and of themselves count as interruptions? If I'm asked to be pulled off a task, then it is a problem. However, if it is a short question, no memory is paged out and it is insignificant. I ask this because some developers do not want to be available on IM because they feel it is distracting. However, I feel like it causes more interruptions and difficulty in communication because every little thing needs to be voiced and requires full attention at the exact time the question is asked.
grecy 14y ago
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: 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 only 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. 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. 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. AFAIK they still do it today
- bifrost 14y ago
  This is actually pretty standard ops methodology. You designate an "intake" person, and then the rest of the group works productively while only one person gets harrangued with interrupts. Its very effective.
- MatthewPhillips 14y ago
  Don't you find it distracting listening to people ask the consultants questions all day? Often times about projects you work on? I don't think there is any cure for interruptions other than no at-desk meeting rules or private offices.
  - grecy 14y ago
    > Don't you find it distracting listening to people ask the consultants questions all day? People are very respectful of the shared space and keep the noise down. Also, it's nice when you are not consulting to actively ignore whatever is being said to the consultants, so you can be more in the zone. > I don't think there is any cure for interruptions other than no at-desk meeting rules or private offices. That's what we do at my current company (try to limit drive-bys) and it's horrible - I just get people booking time in my calendar every 20 mins, so that it's not a drive-by when they want to interrupt me.
dickeytk 14y ago
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.
stevewilhelm 14y ago
Are there any studies that quantify the impact of Google Talk on programmer productivity?
KeyBoardG 14y ago
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.
- geophile 14y ago
  Our scrums are typically 1-2 hours long, due to an accumulation of topics for "after-meetings". What a soul-sucking waste of time.
  - vpeters25 14y ago
    You guys seem to be using the daily scrum as a planning meeting, I would suggest to add all the after-meeting stuff to the backlog and discuss them in the next sprint planning. Daily scrums should not take longer than 15 mins. A good scrummaster will keep them under 5 mins in average for a 12 member team. One thing I usually do when daily scrums start getting out of hand is to politely mention long meetings as a blocker to get my job done. After repeating the same for a few days it will start to sink in...
jgj 14y ago
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.
- muhuk 14y ago
  This would also communicate you are being interrupted and it's not nothing. I would expect it to at least filter the stuff that can wait.
rkb 14y ago
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...
_Benjamin_ 14y ago
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.
- K2h 14y ago
  1) As part of a budget I am charged for the floor space that my team uses in the facility. I would welcome open space and closed space, but don't have the space in this facility to make closed spare look like more than a closet - something most won't respond well to working in. 2) Many tasks (especially engineering that deals with work in the physical domain) require tools, items, equipment of more than just a computer. While we can do shared lab space for development - it does get tricky when you need certain hardware or test setups to do design/work. It did take me time to adjust outside of academia too.
- switch007 14y ago
  Money. They'll dress it up in many other ways, but it's all down to money.
agentultra 14y ago
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. The best, "snake-oil," solutions I have are: 1. Well-delineated boundaries for interlocutors. 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. 2. Write everything down. 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. 3. Never leave a thought unfinished. 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." 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.
- ww520 14y ago
  I think working at home doesn't mean you work while babysitting your kids. It should be like working at office, minus the commute and seeing your colleagues. If you need to babysit the kids for a while, do that as it is then make up for the development time later on. I found org-mode to be great in tracking todo items, general note taking, and organizing thought.
houshuang 14y ago
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). 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. 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. 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? 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.
noknockers 14y ago
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. 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). 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.
pbiggar 14y ago
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: http://news.ycombinator.com/item?id=4993738 http://news.ycombinator.com/item?id=4993738
rachelbythebay 14y ago
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. 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. 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, away from the people they supported. On a third 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?" 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.
- swah 14y ago
  Did you try telling the guys they were loud?
  - rachelbythebay 14y ago
    Those guys didn't listen when I told them our servers were being hit too hard due to <thing> and <other thing>, so I don't imagine that raising a purely social/meatspace concern would have done any good.
strictfp 14y ago
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. 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.
rjzzleep 14y ago
there you go, scientific proof that the whole microsoft enterprise stack is counterproductive. every debugging step involves 20 distractions.
potomak 14y ago
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). [1] http://tomato.es http://tomato.es
n3rdy 14y ago
Do these numbers get inflated for a programmer with ADHD? 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.
follower 14y ago
I found this section of the article of particular interest: "A code narrative is an episodic memory aid that helps a developer recall contextual details and the history of programming activity." I created Labradoc (http://labradoc.com/ http://labradoc.com/) to encourage a form of manual "code narrative" (e.g. a form of development journal). Here's an example from one of my personal projects: http://www.labradoc.com/i/follower/p/android-arduino-handbag http://www.labradoc.com/i/follower/p/android-arduino-handbag I find it really valuable for context-switching between projects.

366 points by Off 14y ago

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.

fennecfoxen 14y ago

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

lawnchair_larry 14y ago
I see it as one giant interruption. I'm not sure what I dislike more, "pair programming" or "open concept".
- fennecfoxen 14y ago
  Indeed: Pair programming does not work for all programmers or all programming shops. It is possible to do it wrong, especially by making it mandatory for people who do not want to do it. Depending on its implementation it may have other negative properties that render it unsuitable for any given purpose. Its suitability for any particular purpose is a broad question which cannot be adequately addressed in the context of this little conversation! But. In my experience, when I was pair programming, and the pair programming was effective to begin with, then: when there were interruptions, the interruption-recovery process was significantly streamlined. I infer that this is one of the ways through which teams that actually already do pair programming manage to improve their productivity enough (relative to singleton-programming) to justify the arrangement.
- zaptheimpaler 14y ago
  As a college student, I do a lot of pair programming. IMO, the efficiency of pair programming comes down to how well matched the two are in skill, and how well they can communicate with each other. Depending on those two variables, it can be much more productive than a single programmer, or a huge roadblock to getting anything significant done.
  - fokov 14y ago
    The problem is the business isn't paying for a single programmer's value, it is paying for two. The only time I have known pair programming actually worked pretty good was when a senior would take a junior under their wing when the junior was first hired. This would facilitate quick ramp-up for the junior to know all practices and the vast amount of things that are not documented (or updated). Keep in mind this only lasted a couple of months max, and not necessarily every day.

MattRogish 14y ago

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. http://blog.fogcreek.com/the-price-of-dev-happiness-part-two/ http://blog.fogcreek.com/the-price-of-dev-happiness-part-two... http://www.joelonsoftware.com/items/2006/07/30.html http://www.joelonsoftware.com/items/2006/07/30.html http://www.joelonsoftware.com/articles/fieldguidetodevelopers.html http://www.joelonsoftware.com/articles/fieldguidetodeveloper...

trggrer 14y ago
Like life, balance is everything. If you want total privacy, better work from home but if you need physical presence/collaboration, regular cubicles in rooms/areas of 8-10 cubicles + a boardroom looks like a win-win to me. I guess it depends on the kind of programming you're doing and the teams composition.
- MattRogish 14y ago
  It has nothing to do with "privacy" and everything to do with un-necessary distraction. Yes, face-to-face, voice-based collaboration can be a good thing, but very rarely do you need it 100% of the time. Need someone to look at your code? Ask them to come over and look at it. Need to chat with someone to discuss the design of some code? You can still do that. Why folks somehow tolerate "everyone gets bothered by any side conversation" is beyond me, especially when you can have perfectly fine collaboration without open-plan offices. It's incomprehensible why companies with "communication problems" think that will be solved by throwing everyone into one room. I bet good money the problem isn't that Jane isn't overhearing Joe and Bob's conversation. It's some deeper disfunction that is being exposed as "communication problems".
majormajor 14y ago
I've been a developer with a private office and I've also been on a small (< 10 person) team in an open office plan. Give me the open office any day. If there's a side conversation not of interest to me, I tune it out. But frequently there are ones that are of interest to me that I'm able to either contribute to or learn something from. It's great for group troubleshooting of sudden issues, too.

ericHosick 14y ago

The best work I've done is when I start in the morning and go for a break only to see it is now dark out.

danso 14y ago

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. Of course, one could argue that the monotony of writing tests is what keeps me from being fully engaged to begin with :)

hkmurakami 14y ago

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

DrJokepu 14y ago
Curiously enough, in my experience, the vast majority of interruption I receive is not from "external sources" but rather from other developers, typically junior members of the team seeking advice or guidance. I wonder how you would address that?
- epochwolf 14y ago
  I sit right next to a tester and he is a constant source of distraction.
  - skrebbel 14y ago
    Did you ever bring it up?
    - epochwolf 14y ago
      Several times. I was told to allow him to interrupt me. :/
- gpcz 14y ago
  Part of that depends on the type of advice or guidance. Some of it might be a symptom of the project's bus factor being too low (inadequate documentation, ambiguities or holes in processes, etc), which your organization can fix by paying down some of that technical/process debt. Other forms of advice (career-related, higher-level tech stuff, etc) would seem more like a mentor role. For that stuff, you may want to schedule "mentor time" in a slot advantageous for yourself, such as the last hour of the day.

maximumsteve 14y ago

Does instant messaging and email in and of themselves count as interruptions? If I'm asked to be pulled off a task, then it is a problem. However, if it is a short question, no memory is paged out and it is insignificant. I ask this because some developers do not want to be available on IM because they feel it is distracting. However, I feel like it causes more interruptions and difficulty in communication because every little thing needs to be voiced and requires full attention at the exact time the question is asked.

grecy 14y ago

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: 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 only 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. 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. 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. AFAIK they still do it today

bifrost 14y ago
This is actually pretty standard ops methodology. You designate an "intake" person, and then the rest of the group works productively while only one person gets harrangued with interrupts. Its very effective.
MatthewPhillips 14y ago
Don't you find it distracting listening to people ask the consultants questions all day? Often times about projects you work on? I don't think there is any cure for interruptions other than no at-desk meeting rules or private offices.
- grecy 14y ago
  > Don't you find it distracting listening to people ask the consultants questions all day? People are very respectful of the shared space and keep the noise down. Also, it's nice when you are not consulting to actively ignore whatever is being said to the consultants, so you can be more in the zone. > I don't think there is any cure for interruptions other than no at-desk meeting rules or private offices. That's what we do at my current company (try to limit drive-bys) and it's horrible - I just get people booking time in my calendar every 20 mins, so that it's not a drive-by when they want to interrupt me.

dickeytk 14y ago

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.

stevewilhelm 14y ago

Are there any studies that quantify the impact of Google Talk on programmer productivity?

KeyBoardG 14y ago

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.

geophile 14y ago
Our scrums are typically 1-2 hours long, due to an accumulation of topics for "after-meetings". What a soul-sucking waste of time.
- vpeters25 14y ago
  You guys seem to be using the daily scrum as a planning meeting, I would suggest to add all the after-meeting stuff to the backlog and discuss them in the next sprint planning. Daily scrums should not take longer than 15 mins. A good scrummaster will keep them under 5 mins in average for a 12 member team. One thing I usually do when daily scrums start getting out of hand is to politely mention long meetings as a blocker to get my job done. After repeating the same for a few days it will start to sink in...

jgj 14y ago

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.

muhuk 14y ago
This would also communicate you are being interrupted and it's not nothing. I would expect it to at least filter the stuff that can wait.

rkb 14y ago

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

_Benjamin_ 14y ago

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.

K2h 14y ago
1) As part of a budget I am charged for the floor space that my team uses in the facility. I would welcome open space and closed space, but don't have the space in this facility to make closed spare look like more than a closet - something most won't respond well to working in. 2) Many tasks (especially engineering that deals with work in the physical domain) require tools, items, equipment of more than just a computer. While we can do shared lab space for development - it does get tricky when you need certain hardware or test setups to do design/work. It did take me time to adjust outside of academia too.
switch007 14y ago
Money. They'll dress it up in many other ways, but it's all down to money.

agentultra 14y ago

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. The best, "snake-oil," solutions I have are: 1. Well-delineated boundaries for interlocutors. 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. 2. Write everything down. 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. 3. Never leave a thought unfinished. 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." 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.

ww520 14y ago
I think working at home doesn't mean you work while babysitting your kids. It should be like working at office, minus the commute and seeing your colleagues. If you need to babysit the kids for a while, do that as it is then make up for the development time later on. I found org-mode to be great in tracking todo items, general note taking, and organizing thought.

houshuang 14y ago

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

noknockers 14y ago

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

pbiggar 14y ago

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: http://news.ycombinator.com/item?id=4993738 http://news.ycombinator.com/item?id=4993738

rachelbythebay 14y ago

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. 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. 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, away from the people they supported. On a third 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?" 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.

swah 14y ago
Did you try telling the guys they were loud?
- rachelbythebay 14y ago
  Those guys didn't listen when I told them our servers were being hit too hard due to <thing> and <other thing>, so I don't imagine that raising a purely social/meatspace concern would have done any good.

strictfp 14y ago

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

rjzzleep 14y ago

there you go, scientific proof that the whole microsoft enterprise stack is counterproductive. every debugging step involves 20 distractions.

potomak 14y ago

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). [1] http://tomato.es http://tomato.es

n3rdy 14y ago

Do these numbers get inflated for a programmer with ADHD? 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.

follower 14y ago

I found this section of the article of particular interest: "A code narrative is an episodic memory aid that helps a developer recall contextual details and the history of programming activity." I created Labradoc (http://labradoc.com/ http://labradoc.com/) to encourage a form of manual "code narrative" (e.g. a form of development journal). Here's an example from one of my personal projects: http://www.labradoc.com/i/follower/p/android-arduino-handbag http://www.labradoc.com/i/follower/p/android-arduino-handbag I find it really valuable for context-switching between projects.