If some dev decided to teach me these lessons, I would be tempted to go out of my way to bug the dude as much as possible.
Programmers, teach non-geeks the true cost of interruptions (2014)
21–30 of 253 posts
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#22If you had to use a piece of software that ran lengthy operations and had to start over from the beginning if it was interrupted for any reason, would it be more effective to prevent interruptions as best you can and hope they never happen, or to fix the program so it saves its work along the way and can restart after an interruption? There are a lot of reason why you can get interrupted, not all of which are your boss stopping by for an update.
This article is exactly why programmers are seen as whiny prima donnas. Too many refuse to work in a way that accommodates working with other people.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#23> 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 purely mechanical and specific to a small problem. Every model the sales guy or manager uses has very few knobs to twist and are mostly intuitive models for which everyone has a template and practices use of every day: emotions, status, hierarchy, urgency, etc.
The programmer is building a house of cards and startling him means he needs to start over.
I agree if you're not deep coding, eg doing a bit of cleanup or documenting, it's not such a big problem.
EDIT
I seem to have ruffled some feathers with the absolute sounding "nobody else" phrasing.
I'm sure you'll run into someone else who has to think like a programmer, but I also tend to think such people to the extent they exist actually are programmers in some sense: either they happen to have a different title, or under the hood they are pretty much doing the same thing.
Now for some more about the nature of programmer's complexity. The thing about being a coder is you end up working on multiple abstraction levels, and they are all still your domain. If your app has some networking issue and you're wiresharking the packets, that's still you. If the front end is slow because you're calculating a lot on the GUI thread, that's still you. If the database is returning strange results, that's still programming. These are all areas that require a huge amount of work, in particular reading about existing conventions and tools, to understand.
In addition, programming has the capacity for you to create your own, local abstractions. Not only is the computer capable of remembering everything you made up, it also computes the interactions that you didn't consider. You have to interface these with the firmament. It is this creation of your own little menagerie and connecting it to the existing world that throws up an enormously large space for weird things to happen.
The thing that I need to point out is that there's no general human intuition for a lot of these things. Yes, you can use a bit of drawing diagrams to help you. But we don't get that intuitive, natural feel that you get in the rest of your life, particularly around emotions, that is I think called system 1 somewhere.
I also don't mean domain specific intuition, which is really just a form of learned knowledge.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#24> 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 think the issue is that, in a typical workplace that employs some programmers, they are in fact the only ones who will be doing deep work that requires sustained focus. The typical office does not contain, in addition to programmers, poets, painters, and mathematicians. If it did, those people would understand. Instead, aside from the programmers, you have mostly salesdroids and managers, who have absolutely no con…
> Instead, aside from the programmers, you have mostly salesdroids and managers, who have absolutely no concept, because they have never done any real work.
And this helps the argument not one bit. I'm sure it's very comforting to condescendingly look down on other professions, but you're doing nothing but further proving the point in the comment above.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#25The suggested `adding game' in the article seems pretty smug and patronizing to me. Surely explaining the situation to the `culprit' like an adult would do just as well without stooping to the ``I'm interrupting you! I'm interrupting you! See how annoying it is?'' solution. If someone has such little regard for you that a normal conversation won't work, I feel like that `demonstration' is likely to just garner you a…
Probably in person it would be a bit different. I have a feeling this is a quickly whipped up example. Contrived and silly, sure, but the point is made.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#26> 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…
It doesn't matter that you explain that they're interrupting and wrecking your chain of thought; they're just going to keep doing it, and the train has already gone off the rails.
I don't know what the solution is, aside from being blunt about setting expectations and fierce when those expectations are violated trivially. Or exiting to a remote location where one can do work without interruption.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#27> 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 think the issue is that, in a typical workplace that employs some programmers, they are in fact the only ones who will be doing deep work that requires sustained focus. The typical office does not contain, in addition to programmers, poets, painters, and mathematicians. If it did, those people would understand. Instead, aside from the programmers, you have mostly salesdroids and managers, who have absolutely no con…
I agreed with you until your last sentence. I think the goal we want to achieve here is to be more understanding of what each other’s work involves; I absolutely don’t envy the manager who is constantly being interrupted, or the sales person who is doing some next level persuasion and working months to get this customer to sign that contract.
If you’re dismissive of their work, how can you ever expect them to be understanding of yours?
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#28People have jobs where they need to concentrate ? and...people prefer not to be interrupted when concentrating ?
oh. my. god.
The author looks old enough to know better than to propagate software development as some kind of novelty role in an organisation, and also old enough to know that cultivating the image of the tortured prima dona, who must not be disturbed while creating his masterwork, does a lot more harm to the profession than good.
If you need to work without interruption, pull on your big boy pants, take your code and your laptop, and go work somewhere where there are none.
If what you are working on is so intricate and volatile, get funding and build your own fucking lab like scientists have been doing for years.
Otherwise, you're part of an organisation, on a salary, like everyone else. So play your part.
Idiot.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#29People are generally selfish and focused on their own goals. Everyone has their stress and tries to relieve it either by working machines or working people.
Due to the unpredictable hours of salary positions, programmers should be defensive and stand up for themselves more often. Being walked all over is typically a sign to find a better work culture elsewhere.
This article is a fantasy situation that would never play out in the real world. PMs don’t have time to mess around with a stupid mental exercise, nor would the lesson change their reality.
“Just get it done”
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#30Actually, HN is more of a distraction to me than random people popping by.
The fact that you are able to pick your own time to get distracted makes all the difference. I read HN when I'm blocked on something, waiting on a compile, on the loo, on a coffee break. The costs of context switching in these cases is very low compared to when I'm deep into debugging or writing code.