Programmer Interrupted (2013)(blog.ninlabs.com)
blog.ninlabs.com
Programmer Interrupted (2013)
http://blog.ninlabs.com/2013/01/programmer-interrupted/
15 comments
Amazing that none of the solutions involved trying to cut down interruptions.
He did mention trying most of the standard techniques for that. From an individual perspective, I think that's a reasonably well-explored space.
If the problem statement is "interruptions cause me to be unproductive for some time after one occurs", there's a lot of value to working on cutting down "some time" as well as simply trying to avoid interruptions. Some interruptions are unavoidable, as well: bathroom, RSI-induced rest breaks, loud noises from outside.
I moved away from programming a couple years ago, and I've found that there are non-programming tasks that require the same amount of "load-up" that development does. Writing comes to mind. Programming is unique, though, because there are far more digital artifacts you have to navigate while you do it. That makes these sorts of techniques particularly interesting. How do we take advantage of the fact that there are so many markers in the code, instead of making their complexing the problem?
If the problem statement is "interruptions cause me to be unproductive for some time after one occurs", there's a lot of value to working on cutting down "some time" as well as simply trying to avoid interruptions. Some interruptions are unavoidable, as well: bathroom, RSI-induced rest breaks, loud noises from outside.
I moved away from programming a couple years ago, and I've found that there are non-programming tasks that require the same amount of "load-up" that development does. Writing comes to mind. Programming is unique, though, because there are far more digital artifacts you have to navigate while you do it. That makes these sorts of techniques particularly interesting. How do we take advantage of the fact that there are so many markers in the code, instead of making their complexing the problem?
Sadly, this is becoming less and less of a viable option, if you wish to participate in the workforce. Open offices where your visibility is valued more than your performance, the expectation to respond immediately to chat and email, and the rise of the phone call all create the potential for interruptions.
Whenever this comes up, I usually link to this:
Don't Wake Up the Programmer!
http://alexthunder.livejournal.com/309815.html
Don't Wake Up the Programmer!
http://alexthunder.livejournal.com/309815.html
Discussed at the time: https://news.ycombinator.com/item?id=5092589.
People say get headphones :-) at our company there is only a 1 ear-piece policy.
I find headphones are great when you know what you are doing and churning out more code. However when I am needing to read documentation and learn something new then I find them a hindrance.
I find myself wearing my headphones even when I am not listening to anything. It acts as a signal.
This is rubbish. You are not children.
If a coworker needs to talk to me, he sends me a message. If he really needs to talk to me, he waves his hand in front of my screen. If we are pairing on something, I obliviously don't wear the headphones or we both do and simply communicate using chat.
If a coworker needs to talk to me, he sends me a message. If he really needs to talk to me, he waves his hand in front of my screen. If we are pairing on something, I obliviously don't wear the headphones or we both do and simply communicate using chat.