7 ms·
Programmer, interrupted (2013)
- Kenji 10y agoThis might be somewhat off-topic but do we really always have to conduct a study first before we can acknowledge and solve a problem that is obvious if you have any common sense?
- cholantesh 10y agoSeemingly common sensical notions can be wrong. The hope is that empirical study is less so.
- Kenji 10y agoI agree with that notion completely, but I think one can overdo it and get lost in pedantry and bureaucracy. Imagine you would program your software and do a benchmark test on every single line. That is what it feels like.
- sanderjd 10y agoI've always liked the warning to not let perfect be the enemy of good. But I also think it's easy to rationalize too much guessing and too little evidence gathering. I find it a really hard balance to strike.
- rhizome 10y ago"Common sense is not so common." --Voltaire
- ramblenode 10y agoThe field of modern Psychology exists because introspection is unreliable.
- 12010981 10y agoSo introspection is replaced by studies that mostly focus on a single aspect of a complex system, analyzed by people who don't know MANOVA and just do p-value fishing in Excel. I'm with Feynman on Psychology.
- maerF0x0 10y ago@joshka, add a 2013 tag
- mjevans 10y agoThe first part of this seems to well describe the problem. Then it looks like it goes in to a sales pitch for 'solutions' to that problem?
- partycoder 10y agoI write down my thoughts so if I get interrupted I can resume from where I was. Then, I try to encourage people I deal with to use the issue tracker as much as possible. "Hey, how is this task going?" -> go to JIRA "Hey, are you blocked?" -> go to JIRA "Who is working on this?" -> go to JIRA Then I check JIRA when I have the time.
- happyslobro 10y agoNot sure why this is getting downvoted. Distractions suck - having a system to manage them is good. Pushing people to use it is necessary.
- CaptSpify 10y agoI hate jira, but I agree with your point. I always have notes that i can reference. More to reference = less time to get back up to speed
- Bahamut 10y agoCould be worse - you could be using Rally.
- XorNot 10y agoOr a giant board of post-it notes.
- MaulingMonkey 10y agoThe only thing worse than keeping JIRA constantly up to date is keeping interrupting managers up to date when I already keep JIRA constantly up to date with the thing they're asking about. It gets amusing when I'm deep down enough into the technical weeds that I've forgotten the exact high level task I'm working on (the thing the manager actually cares about), and refer to JIRA myself to answer the question of what I'm working on.
- ghostintheshell 10y agogood mate
- infodroid 10y agoFYI the original article has much better readability, formatting, and references: http://blog.ninlabs.com/2013/01/programmer-interrupted/ http://blog.ninlabs.com/2013/01/programmer-interrupted/
- j_koreth 10y agoCan mods change links to this?
- moonshinefe 10y agoSeconded, this is way, way easier to read and actually has references in it.
- yoha 10y agoAlternatively: http://www.gamasutra.com/view/feature/190891/programmer_interrupted.php?print=1 http://www.gamasutra.com/view/feature/190891/programmer_inte...
- libliflin 10y agoI'll offer the dissenting opinion. Let's say the ratio is worse: 10x less productive; 10x more error prone. I will still interrupt my coworkers who are working on the wrong thing. 1/10th of a thing that makes 100x more money is better than 1x of a thing. I want that nonsense flushed from their working memory. I understand that makes me a micro-manager; but I'd rather have more productive coworkers that help keep our business alive. My coworkers appreciate it (most of the time) because it helps them grow.
- programmarchy 10y agoWhy would they be working on the wrong thing in the first place? Sounds like bad management, poor communication.
- jackmaney 10y agoPlease tell me where you work. I don't ever want to be on the same team as you.
- MaulingMonkey 10y ago> I will still interrupt my coworkers who are working on the wrong thing. How common is this, how can you tell, and why were they working on it in the first place? How often do you interrupt them when they were working on the right thing, as an unfortunate side effect? I've wasted time and energy on dead ends and it is one of the most frustrating things, even when it was understandable, sanctioned, and a desired exploration of the problem space. I'm all for trying to avoid unnecessary waste. > I understand that makes me a micro-manager; That this is your understanding would concern me greatly, though. I'd rather be macromanaged - have the big picture explained to me, in a way that I can understand and buy into, that I can then approach in the ways that best suits my own talents and abilities. Where I can contribute my own insights and ideas to the collaboration, where I don't start working on the wrong shit in the first place. Not just... along for the ride, like floatsam, being told I've been doing it wrong a hundred times and do it this other way because I've been told to, without any deeper insight to correct the underlying problem. Or even worse, without any real underlying problem in need of actual correction.
- ww520 10y agoI found this help explain to others how programming work. http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/ http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-...
- bbarn 10y agoI see so much of this arguing against being interrupted, or context switching. I suffer from it, most of us do, but I think everyone's trying to solve the wrong problem. The problem isn't that we get interrupted and our concentration suffers, it's that we keep trying not to be interrupted. Good developers are people who knit things together. The myth of the savant coder who just cranks out beautiful amazing stuff has to die. What makes a great developer are soft skills, and gluing together other code, not cranking on something for hours alone. Just like every other industry, you have to deal with other human beings, email, and the rest of life. We don't NEED to be cranking out code for hours on end, we need to integrate and interact with other people.
- mattnewton 10y agoI think there is a time and a place for both modes (and it also depends on personality). What's wrong with private exploration / development after a period of research on the problem?
- Roboprog 10y agoThis makes a good case for having both some "core hours" for sharing, and some "crank stuff out" time.
- bluejellybean 10y agoI think a 1 on 1 off day could be interesting. Normal week but every other day is worked from home in quiet, maybe include some IRC.
- AdieuToLogic 10y agoThe problem isn't that we get interrupted and our concentration suffers, it's that we keep trying not to be interrupted. For a programmer, frequent interruptions are a major problem. Interruptions break a person out of the mindset required in order to solve problems. This is why managing interactions within an organization is one of the primary foci of project management. What makes a great developer are soft skills, and gluing together other code, not cranking on something for hours alone. Soft skills are certainly beneficial in a team. But what "makes a great developer" are not soft skills. What makes a great developer is providing solutions within the constraints and expectations of the organization (time, functionality, cost, etc.) for the problem at hand.
- AdieuToLogic 10y agoThis phenomenon is not constrained to programming. It's sometimes referred to as flow[0] and has been documented as taking somewhere between 15 and 20 minutes[1] to regain after an interruption. Programmers may be more sensitized to its disruption than most due to the nature of the work, but the net effect is the same. If a person is required to concentrate in order to perform their job, interruptions will cause performance to degrade. 0 - https://en.wikipedia.org/wiki/Flow_%28psychology%29 https://en.wikipedia.org/wiki/Flow_%28psychology%29 1 - http://grahamchastney.com/2011/10/axiom-interruptions-cost-20-minutes/ http://grahamchastney.com/2011/10/axiom-interruptions-cost-2...
- failrate 10y agoSome days I can barely even get started working, because I am already anticipating interruption. Wearing headphones doesn't help. I think it should be a clear social signal, but other people do not. In fact, they talk to me as if I can hear them (I cannot) and have to repeat whatever their introduction sentence was when I finally take them off. Why is this normal?
- escherize 10y agoWhy don't you ask those people? Or explain your signaling mechanism a bit more.
- jdiez17 10y agoOne way to do this would be to buy (e.g) a bunch of white caps and tell your coworkers to wear them when they need to concentrate, and to not disturb others when they are wearing them. I know of at least one company that does this and it works well for them. You can also do this with headphones, just tell your coworkers politely.
- deleted 10y ago[deleted]
- moonshinefe 10y agoThe article makes some good points, and nobody likes constant interruptions and context switching. Especially in particularly complex parts of the coding process. I also agree that it often takes ~10 minutes after a significant distraction to get back into things. I think non-programmers could definitely benefit from this article. But I also think it's a two way street and there are certain steps you can take to minimize the damage done. Some things I at least try to do: - This may not go over well at everyone's companies, but just being honest with your coworkers sometimes. Send a message or email indicating you need to put your head down for a while to address priority tasks, and that you'll be logging out of Slack/IRC/whatever and can be contacted by email if anything urgent comes up. A healthy work environment should allow for it. - If headphones on is a 'signal' to others not to bother you, just politely mention it to them if they keep interrupting you during. Invite them to email you with any non-critical issues and you'll get back to them when your higher priority work is done. - Getting knocked out of the "zone" and it taking 15 minutes to get back... this definitely happens. But most meetings are scheduled. If your coworkers know your signal not to be bothered unless it's important, you can then work around the scheduled meetings. Do the less complicated coding tasks if possible leading up to the meeting so you don't need so long to get back in the zone after. If that isn't happening, at least keep a text editor open and jot down some notes to remind you of where your thought process was. A checklist is even better. - Use bookmarks. A lot of editors / IDEs have them, and if you bookmark all the areas of interest, if you do actually have come back and 'get back in the zone' without notes, you can at least hop around the pertinent areas quickly to regain context. Anyway, just some thoughts on what's helped me at least reduce that issue. I'm not sure it can completely go away.
- jakobegger 10y agoWhile interruptions are bad for your own productivity, they may really boost the productivity of the person doing the interrupting. I'd rather have a junior dev interrupt me when he needs a quick answer to a question instead of spending an hour googling and copy-pasting a dangerous hack from Stack Overflow. What's the point of sitting in an office when you don't collaborate? The trick I use to reduce the effect of interruptions is to not respond right away if I'm in the middle of something. I just say "I'm in the middle of something, let me just finish this!" and then I get back once I'm at a point where my "mental load" is reduced.
- deleted 10y ago[deleted]
- vendakka 10y agoThis is something I definitely agree with. I've sometimes found that taking a few seconds to cache state in a notepad before responding to the interruption helps a lot. Having times of day dedicated to meetings also helps reduce fragmentation. At the risk of being overly self-promoting, solving problems with fragmented work days is something my cofounder and I are working on now with TimeFerret (https://www.timeferret.com https://www.timeferret.com).
- CarolineW 10y agoAlso discussed at length here: https://news.ycombinator.com/item?id=9515613 https://news.ycombinator.com/item?id=9515613
- Osiris30 10y agoCharlie Stross has also Chimed in on this: http://www.antipope.org/charlie/blog-static/2016/08/writer-interrupted.html http://www.antipope.org/charlie/blog-static/2016/08/writer-i...
- dasmoth 10y agoThis makes a really interesting comparison. It's noteworthy that (fiction) writing hasn't gone down the "collaboration is part of the job"/"don't trust the coder hacking away by herself" wormhole that seems to be swallowing the software world at the moment.