I really don't get this exaggeration about interruptions ...
Programmers, teach non-geeks the true cost of interruptions (2014)
71–80 of 253 posts
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#72> Your non-techie peers just don’t get it, no matter how many times you try to make them understand. We really need to get past this smug idea that tech work is uniquely difficult in a way that no one else can understand. Any deep work suffers from interruptions, and programming isn't the only type of work that has significant mental context. This idea that programmers are uniquely vulnerable does no favors when tryi…
> Any deep work suffers from interruptions, and programming isn't the only type of work that has significant mental context. This idea that programmers are uniquely vulnerable and no one else can understand doesn't help the situation. We seem to be the only profession that cares then. It is only developers who get why you Slack people you are sitting next to.
> We seem to be the only profession that cares then.
Our profession seems to be one where it is not obvious to others that we're in a flow or in deep working mode, since there is no visible difference between work-isolation mode, browsing the internet for random programming or browsing for fun, from four feet away.
My uncle is a neuro plastic surgeon, he is prone to disruptions in more ways than I am (if I talk to him while he's cooking about a decision he needs to make, he loses track of the recipe), but I assume he is never disrupted by someone asking something unrelated while he's working.
My partner too is clearly in an uninterruptible state when practicing the piano or painting something, even writing skeleton work is done on a book instead of a computer.
But I get why it is hard to notice a programmer in isolation over other professions of deep work - I don't put on a lab coat or scrubs , to communicate that clearly to others in a familiar "at work" situation.
I'm trying with a "at work" desk light, but I'm still not consistent enough with it & this is very much forced.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#73I agree with the destructiveness of meetings and interruptions. Many times the only productive work takes place after 5pm.
I find creating protected time is a good solution that helps, but you cant have this every day when you work for an enterprise.
So you just learn to work while the meetings are running.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#74> Your non-techie peers just don’t get it, no matter how many times you try to make them understand. We really need to get past this smug idea that tech work is uniquely difficult in a way that no one else can understand. Any deep work suffers from interruptions, and programming isn't the only type of work that has significant mental context. This idea that programmers are uniquely vulnerable does no favors when tryi…
I agree with the general point of the article. When you're deep coding you have a tentative model containing a lot of variables about the problem. You haven't committed them to memory yet, because it's all workings out that are undecided. Once you make some conclusions, that can be remembered because the end theory is simpler than the path to get there. Nobody else constructs models in their minds that are almost pur…
I basically switched from programming to writing (= for humans) and the need for concentration is rather similar. The model of the text-to-be is not as mechanic, but consists of so many threads that need to be woven together that you can easily lose track.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#75I Don’t get it.
I certainly get grumpy when I get knocked out of flow state, but it’s more about having to cut my direct feed to the universe than any measurable loss of productivity.
Maybe I’m lucky to be able to get into flow quickly, or maybe people are misrepresenting the cost. Even 10 minutes of lost context/flow ramp seems like more than I’d estimate for the cost of one distraction.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#76I'm a quantitative finance / actuarial programmer. I've flipflopped between the programming and business side a few times in my life. At one stage I was in the Actuarial Valuations team, responsible for the periodic valuation of a set of life insurance books. Timelines were very tight, input data was a mess, the products themselves were complex. This wasn't easy stuff. During valuation time all of us were on edge.
But for some reason, being interrupted then didn't cause nearly as much damage to my mental house of cards as they do now, where my day job involves translating messy actuarial spreadsheets to code.
I can't put my finger on it. Both tasks were complex. Maybe the fact that actuarial valuations (like most financial roles) are based on spreadsheets and you have a visual model right in front of you, or accessible within a few clicks. I think that relieves some pressure on the mental model.
Programming, on the other side, even with all the IDE tools like a watch list and call stack, seems to require a larger mental stack, given the same complexity in another field.
Side note: work from home has been a dream come true in terms of the disappeance of interruptions. But I do miss the coffee breaks with colleagues (or what others would call water cooler conversations).
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#77Earlier quoted context omitted.
Architects, lawyers... EDIT: Removed writers. Architects and lawyers don't have as much room for mistakes and technical detail matters more in their work.
Intuitivists. They might take their time to refine their thoughts but they aren't programmers. Type one thing wrong and your novel is still a novel.
type one thing wrong and my code is still code, but the meaning changes, just like the meaning in the novel changes.
with many novels, the author may have intended X, but readers are often encouraged to bring their own views and interpretations to the work, and those may often be useful to others in understanding the work. that's not as true for most software I've worked on though.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#78Earlier quoted context omitted.
Architects, lawyers... EDIT: Removed writers. Architects and lawyers don't have as much room for mistakes and technical detail matters more in their work.
Intuitivists. They might take their time to refine their thoughts but they aren't programmers. Type one thing wrong and your novel is still a novel.
[deleted]
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#79I Don’t get it. I certainly get grumpy when I get knocked out of flow state, but it’s more about having to cut my direct feed to the universe than any measurable loss of productivity. Maybe I’m lucky to be able to get into flow quickly, or maybe people are misrepresenting the cost. Even 10 minutes of lost context/flow ramp seems like more than I’d estimate for the cost of one distraction.
I think you're lucky to be able to get into flow that quickly. I certainly can't.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#80> Your non-techie peers just don’t get it, no matter how many times you try to make them understand. We really need to get past this smug idea that tech work is uniquely difficult in a way that no one else can understand. Any deep work suffers from interruptions, and programming isn't the only type of work that has significant mental context. This idea that programmers are uniquely vulnerable does no favors when tryi…
> Instead, communicate like peers: "Sorry, I'm in the middle of something important. Can you come back at lunch time?" That's already too late though. At this point I've already lost what I was doing.
I feel like if your mental model of the program is so fragile that even saying "Sorry, I'm in the middle of something important" breaks it, then it may be worth working out how to ground more of it.
When I find myself six or seven levels deep in a stack, I often realize I need to open up a new coding window and write myself some quick notes.