At Microsoft, it was easy to see which teams were in crunch mode: the closed doors had "email only" signs on them.
Programmers, teach non-geeks the true cost of interruptions (2014)
51–60 of 253 posts
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#52I have been programming since 1977/78, and sometimes for work, but most of the time for fun. As someone who does technical work at heights with rope access, and many years of technical diving on hydraulics, pneumatic, and electrical equipment, I can say it all depends on your ability to shut out interruptions and get to a good stopping point. I get frustrated when I am programming and I am interrupted, but my most frustrating experience was troubleshooting a technical issue at heights, underwater, or on the deck during a show with almost 2000 patrons getting impatient, while a COO/CFO wants an estimate on when you will solve the as-yet-unidentified issue. They call the show off if you can't get an estimate to repair or resume after 15 min. and they expect you to hold to your time-to-repair or resume estimate. Oh, and half a million to one million USD are at stake! You might be standing in front of a controls cabinet with hundreds of wires and devices and some indications of where to look, or 10m underwater trying to find a source of the fault. I think interruptions suck for any person who is focused on doing a good job - bus drivers, pilots (yes, I know - autopilot!), soldiers in combat, air traffic controllers, chefs, almost any job. This is why I never took a job coding full time. It is always secondary to my actual job even if it is important. And, I like J and APL for the very reason that you are looking at a few lines of code vs. a few pages of for loops ;)
I code in C and other languages as well, so no offense to those who work mainly with scalars ;)
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#53> 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…
> 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
What about mechanical engineers, electronic engineers, etc.?
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#54> 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…
> Nobody else
Programmers are far from the only people who do creative work that involves building complex models in a mental "buffer" and then streaming them out into some persistent form.
Maybe most people on HN are programmers, and maybe most programmers work in offices where they're the only people who do this kind of work. But that's the kind of exceptionalist tech-centric point of view that can only make it more difficult to communicate our struggles to our non-programmer co-workers, who might actually be very familiar with similar struggles in different (possibly non-professional) contexts.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#55> 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.
Seems to be the only one that is both deep work and treated like an assembly line, though.
Interruptions aren’t that bothersome when you aren’t under that kind of pressure to produce.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#56> 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…
> 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 trying to address the problem.
We don't really have to. It is far better for us to keep selling the image that programming is something tantamount to wizardry than to make it seem like it can be understood on the same level with other kinds of work. For one, it's not really true. Programming requires a depth of focus you don't find in most other fields, and certainly within a single company no one has to work as deeply in their minds as the programmers do.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#57Earlier quoted context omitted.
> 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.
I think we’re one of the few that requires nearly entirely deep work yet also often work in an environment that isn’t conducive to it. Many other professionals that do this kind of work have private offices. Painters, architects, lawyers, etc. Meanwhile we cram ourselves together, surround ourselves with physical and digital distractions, and expect near immediately responsiveness from peers. I’m glad to have my team…
I forget where I read it, but there was a blog post that mentioned how open offices basically turn developers into furniture as part of the job is appearing busy like bees.
This actually happened to me once. Some big investor was coming one day, so we were all to be in our seats for a certain time to show that we were productive.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#58Earlier quoted context omitted.
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…
> 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 What about mechanical engineers, electronic engineers, etc.?
They are programmers. They even use programming tools to do their work.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#59> 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 I agree, however... > "Is this urgent? I can't really stop what I'm doing right now, but I can stop by your office around 3PM. Will that work?" I would just say: "I can't really stop what I'm doing right now, but I can stop by your office around 3PM." If you ask them if that will work, they'll tell you they need the answer immediately most of the time. People want instant gratificati…
I got so tired of defending my time at a previous job that I just started saying “Is that what our producers needs me to do?” Shuts them up every time. Generally, the people that interrupted me were people that had no authority to ask me to do anything: marketers, ad agents, sales.
Re: Programmers, teach non-geeks the true cost of interruptions (2014)
#60> 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…
Sounds like a manager talking. The problem with programmers is, they haven't learn how to multitask! A few youtube videos and maybe a seminar and voila! They'll no longer be derailed by buzzword bingo and backseat driving. The act of saying "Sorry, ..." is enough to derail a deep debug session. Having a manager hover over your shoulder is enough. And if that's not believable, then clearly one of us hasn't been there,…
People are different. Back at the office my boss would be distracted every few minutes by someone else on the team and still be productive. I, on the other hand, cannot really concentrate if my GF is in the same room, silent, browsing the web on her computer.