> 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 trying to address the problem.
Interrupted work is common to everyone, so use that commonality to your advantage when politely navigating interruptions.
Also, I hope nobody takes the author's fantasy literally:
> Well, worry not, because I think I have a way that you can actually demonstrate to them just how devastating interruptions are to your productivity compared to, say, theirs. In other words, here’s how to make someone understand that, for you, an interruption isn’t just a delay after which you can get right back to work but a complete total of your efforts up to that point. Here’s how. Invite the PM/manager/sales/whatever person to sit at his desk and tell him to humor you. Open up notepad and type a series of 3 or 4 digit numbers in sequence, like so:
Better advice is to learn how to communicate professionally. Real adults don't sit each other down and force them to add up a long list of 3-digit numbers while peppering them with interruptions to make a point.
Instead, communicate like peers: "Sorry, I'm in the middle of something important. Can you come back at lunch time?"
Or: "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?"
Don't be afraid to assert yourself in the conversation. Communicate the concern ("I'm in the middle of something important") and propose an alternative that would work better for you ("Can this wait until lunch time?"). Scale the assertiveness up or down depending on who's interrupting you. We all know some people who will take the hint and disappear, and we all know other people who will try to ignore your concerns and press forward anyway. Adjust accordingly.
Finally - Recovering quickly from interruptions is a skill that can be developed and learned. Obviously, you can't negate the damage of interruptions entirely. However, making an effort to gather your thoughts and return to work after interruptions goes a long way to limiting the damage. The worst thing you can do is pop open HN or Reddit or Twitter after an interruption because you're already out of the groove. Knowing how to manage yourself and get back into the groove as quickly as possible is a valuable skill.
> We really need to get past this smug idea that tech work is uniquely difficult in a way that no one else can understand.
When you think what you do is special, you will only look to other 'special' people for solutions to your problems. If you understand that many disciplines have the same problems, you can crib ideas from them. It's a major reason I push people to have extracurriculars.
Most of my crisis management skills came from volunteering at public events for clubs. Your kitchen renovation guy could fill a book on how to manage customer expectations.
> Instead, communicate like peers: "Sorry, I'm in the middle of something important. Can you come back at lunch time?"
> Or: "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?"
You're trying to avoid dumping brain state, so the more open ended the question is, the more state you lose. They start bringing up related facts that your brain expects to hold onto in order to fulfill social obligations, and each fact wipes out more of your train of thought. Asking the person if it's urgent invites them to monologue. Your smarter peers will see these questions as equivalent, the rest of your coworkers won't. Don't ask them to decide. Make them decide.
"Can you come back in X minutes/at time Y?" is short. Invites little commentary. If the answer is, "No you're late for a customer meeting" or "The building is on fire can't you hear the alarm?" then you were going to be interrupted anyway. We don't want to debate the relative importance of these two tasks. If we do then the interrupter wins, whether they deserve to or not.
> Recovering quickly from interruptions is a skill that can be developed and learned
This is absolutely true. I no longer mind interruptions. I don't love them, but they aren't devastating productivity crashes either. Weirdly enough, friendly, helpful answers to the query seems to reduce interruptions. I think people don't mind interrupting grumpy programmers.
Also, adopting contemporary coding practice helps. Keeping functions to a single purpose. Not mutating data. Restricting side effects. Automated testing. Acquiring complete understanding of your tools and frameworks. These things help you grasp at a glance more quickly what's happening.
In short, committing to allow people to interrupt can alter your approach and work flow to accommodate interruptions
Firming up your tests, logging, observability, and debugging practices really does help here.
The only time I enter a desperate fugue state juggling too many disparate code modules in my head is when the system is a poorly factored enterprise monolith.
Those aren’t uncommon but I reflexively avoid jobs that make those the majority of my work.
Responding to the first point: In a "normal" software context, developers are usually faced with other roles that usually don't have the same focus requirements.
PMs, scrum masters and sales or business development types don't usually have the same kind of focus requirements during day to day. Sure, they also need deep focus when drawing up a detailed budget or doing roadmap planning or whatnot, but usually their day requires less focus and a broader contextual awareness instead.
So, obviously physicists, plumbers, bookkeepers, surgeons, mathematicians, all manner of creatives, designers, engineers, chemists and evolutionary biologists also need not to be disturbed while working. But their workplace is often cognisant of the fact.
Programmers often complain because the default setup in which they work (some kind of open plan office) and the roles they often interact with don't get the basics of what's needed.
If I needed to work on site, I'd regard an seperate office as a significant perk.
As an accountant and developer I can tell you that many accounting tasks are very similar to coding. I have spent years having to prepare management accounts in an open office and it is exhausting trying to maintain the focus required. And yes people interrupt you just like any other day because their roles require timely responses.
I have an office now and it helps a bit, but normally I hide at home and turn off email and put Teams into dnd for these tasks
It looks to me like you’re wanting to make a counterpoint to the person you’re responding to, but he did put ”bookkeepers” in the same category of people who tend to need deep focus and not be disturbed. Do you agree that not every role shares that quality, and that the parent comment has a point?
If you were agreeing with him and just adding to the argument, then my apologies.
I am agreeing with the sentiment that there are many jobs that require deep focus and do not get special circumstances.
Bookkeeping and management accountancy are not really similar professions. A bookkeeper is focused on data entry, and tends to be a small company generalist, adding up invoices, receipts and sales tax etc. I have been a purchaser ledger clerk (processing supplier invoices en masse) and it requires a different kind of concentration entirely. I am rubbish at that kind of work now, I think your mind changes as you progress to the more supervisory work. A management accountant is trying to turn the outputs of this work (amongst other things) into coherent management information, filling in the gaps and making judgements and estimates.
> 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 development is a profession where it is not obvious when you are interruptible. In fact one of the best manager I had outright ask me "are you interruptible?", because she doesn't know if I am deep into a complex problem or just cleaning up stuff or waiting for my code to compile.
Manual labor also require focus, but when you are occupied tends to be obvious. If you are under a car, messing around with a tool in your hand, everyone knows it is not the best time to interrupt you. In safety-critical jobs, like in the case of pilots, there are mandatory protocols that explicitly forbit interruptions during critical moments.
People usually know enough not to barge in when the manager is having an talk with his higher up or when the salesman is negotiating with a customer unless it really is urgent.
But programmers just stare at the screen all day, and most of the work happens in their head, so how do you know if they can be interrupted or not. Bad managers assume "always", because themselves only stare at the screen during their "off" time, so they assume programmers are always "off".
I'm a mathematician. I spend a lot of time staring into space and mumbling to myself. Sometimes, though, when I'm just zoned out, my wife would ask: "Are you working on something?"
At a prior job we actually little LED RGB light tabs that would stick on our monitors, and set them to red or green to indicate exactly this. Uptake and responses were somewhat mixed, but it was nice to have an explicit signal, beyond just putting my headphones on, that I was not going to be welcoming of interruptions for the next few hours.
At the time we were in a pretty cramped office in a co-working space, so I appreciated anything that could help cut down on distractions even a little.
I have problems building habits going out of deep work. It's like the problem is less getting dumped from my mind and more slowly filtering out, and since my mind is still occupied, I'll move on reflex and perpetually forget to flip the switch.
Not really. It’s probably more likely that developers are the ones who are able to create blogs and voice their opinions more easily on the internet.
My step-dad works in logistics and likes to quote “a single interruption takes a person 15 minutes to get refocused”. He blocks specific hours for his field staff to stay away from the office staff, so they can process the critical daily work without interruptions.
Google searching seems to say it’s closer to 23 minutes these days. Industrial engineers seem to have studied interruptions on work in the late 90’s and maybe even earlier.
As a further anecdote, when I worked in manufacturing I would end up having to come in on the weekends to do cognitively demanding work. Designing tooling, creating and optimizing CNC programs, and checking parts using coordinate measuring machines while getting interrupted by the quoting department to “just give me a quick estimate what you think this part will cost for us to make for the customer”, or production saying “we need you to quickly trouble shoot the defective parts we are producing because otherwise we will be late and get a fine for missing the shipping date” results in costly errors that can’t be fixed by recompiling code.
Pressure, interruptions, and bad management are not unique to software development. And yes, other professions do care about production high quality work.
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 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.
Happened to us at a small agency. Allowed WFH days were standardized to specific days of the week so we could show a full house on days when we had client visits.
You may have hit the crux of the problem. Programmers aren't uniquely dependent on deep work, but tech companies seem to be uniquely determined to do everything they can do to make the office as hostile as possible to that. Add to that the expectation of instant availability via whatever messaging and it's clear even among tech company deep workers, programmers have worse conditions.
> 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.
Instead of the at work light, keeping notes on paper is somewhat obvious, and tied to actually doing the work. Plus, you can do a pretty clear mental dump when somebody wants you to context switch, and they can see you doing it
I guess I consider it part of my Job to be there and answer questions, assist other developers, etc.
(Also please do not slack me when you're sitting right next to me, it's like, more disruptive and annoying than just talking to me. But mostly just use Email, please.)
> (Also please do not slack me when you're sitting right next to me, it's like, more disruptive and annoying than just talking to me. But mostly just use Email, please.)
I was about to say the same. Slack disruptions are often worse than in person interruptions. Email isn't.
I do, though it’s not just that, it’s also the read and typing notifications and stuff I don’t like. Disabling it would make it more tolerable though.
However, there really are things I want someone to have the ability to notify immediately for. Narrow time slots on in demand hardware like prototypes or FPGAs, change of team location in a lunch room or a big lab, and drop what you’re doing and debug this when it makes sense.
Absolutely true, nothing unique about programming there. In fact, a game I like to play with people to show how bad context switching is, is the letters, numbers, roman numerals game.
Make two tables of 10 rows and 3 columns on a piece of paper. Column one is letters. Column 2 is roman numerals. Column 3 is numbers.
Your task is simply to write down the letters from A to J, roman numerals from I to X and numbers from 1 to 10.
You will do this twice and you will time yourself with a (cellphone) stopwatch. First time around in the first table you will fill each _row_ first. So you will write A in first row, first column, I into first row second column, 1 first row third column. B into second row first column and so forth until you're done.
The second time around you fill out columns first. I.e. A in first row first column, B in second row first column, C ...
It's a really nice game and you can even play it just against yourself or let your boss play it against himself if he wants you to multitask. If the other person says "well that's because I didn't know my roman numerals by heart any longer!" they can play it again. You can get better at it of course but it still shows the effects of context switching just from letters, to numerals to numbers. Can't get simpler than that!
Interruptions are annoying but I think people are going a little overboard with this vitriol. I would wager that we are all just as guilty of doing the same to our team members who are deep in thought on something. "Did you merge that git branch?", "Is the staging server down for you?", "Can you take a look at this query and see if you notice anything?"; things like this are batted around between co-workers without thinking much about what someone else is doing. We expect co-workers to get back to us right away so that WE are no longer blocked. If someone is showing offline, we'll just ping the next person and so on until we get an answer. The difference is that the other engineers are on our team, we are in it together. The others aren't and they don't "deserve" to interrupt us.
The other thing I don't see being discussed is that maximizing LoC per day may not be the thing that provides the most value to the company. It is tough though because those things aren't necessarily concrete and don't give us the same kind of satisfaction and feedback. We can't point to a new class or module or page that is now done, even if what it does isn't actually the result needed from the business. Sometimes the most important value you can provide to a business is thinking about what you are working on or what the newest requests from the business side are.
At least on the teams I have been on, we didn't physically interrupt people. We sent Slack and Teams messages for all of that stuff about merges and staging.
How disruptive depends on company culture. If the expectation is to respond immediately, it's no different than a physical interruption. On the other hand, I leave Slack notifications off and only use it through the browser. Usually, I only notice the tiny glowing favicon once I'm largely out of the zone anyway.
There's definitely an issue with notifications in things like Slack/Discord/Teams, but it's a symptom of a larger problem software where everything is competing for attention. Social media apps do it because it's part of their business model and built in to the addictive-by-design need to get eyes on ads.
Chat systems aren't (yet?) dependent on ad revenue, so they don't need to copy the behavior of social media, but, possibly because they use the same operating-system level notification APIs, that's how they act.
This weird preference on here for Slack interruptions is just another manifestation of generational call vs text divide. It's more about cultural context and personal anxiety than real disruptive effect.
> We expect co-workers to get back to us right away so that WE are no longer blocked.
Perhaps you do, but I and some of the people I’ve had the pleasure to work with do not.
Personally, I’ve almost always worked asynchronously.
If I have a question, I send it on the proper Slack channel and either keep going on what I was doing if isn’t blocking, or do something else when it is. Tasks are usually large enough for that.
Regarding Slack interruptions, all my notifications aside from a handful of phone numbers are disabled.
Things rarely are urgent, and can usually wait an hour or even until the next break.
> "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 gratification. But, by leaving it off, you have still given them something and you've gotten your time back.
>> If you ask them if that will work, they'll tell you they need the answer immediately most of the time.
The question "Will that work" is optional. You need to be polite when dismissing someone, but the goal here is to offer 2 messages "I'm busy now" and "I'll get to you as soon as this busyness passes" The discussion needs to end as quickly as possible so as to not lose your focus, but also without making them angry. Asking questions in that case is probably a bad idea.
The few times in my career when I haven't had a door I could close, I did all of my deep work from home and only came into the office for meetings (which I compressed into 1-2 days).
The delicate social dynamics described in these threads sound incredibly expensive. I can't imagine paying someone a quarter or half million dollars and then draining away their productivity on this sort of thing.
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.
Then you’d be the kind of person I’d say this to. I am very open and accommodating for individuals on my project that are trying to get their task done. I’ll sit down and help, guide, whatever is needed. I won’t allow a marketer, ad agent, or sales person to demand that I stop everything I’m doing and address the issue they have, only to tell them that it isn’t going to be done this sprint and you’ll have to talk to our producer to get that task.
The only people that I’ve worked with that were intrusive, pushy, and demanding of engineers immediate time were the people that were trying to go around the producer because they already knew their issue was low priority for the team.
> We really need to get past this smug idea that tech work is uniquely difficult in a way that no one else can understand
Is that the only possible reason they wouldn't understand? The etiquette around interruption is different in different professions, and programming seems to be on an extreme edge of a spectrum. There are professions where people work together in offices and interrupt each other all the time, without restraint. I am not smarter than them. They are doing jobs I would not be good at. Something must be different.
Maybe the work is different in some way than most other jobs, or maybe we're defective. Honestly, I think the people who are best at accommodating this difference are alpha management types who look down on programmers. They aren't surprised that we don't cope well with interruptions, just like they're not surprised that their dog is afraid of fireworks. "Stay away from my programmers. They work better when nobody talks to them."
It's people who think we're really smart, or who rely on empathy to relate to us, who keep interrupting, because they can't wrap their heads around the idea that it's hard for us. Good communication is not a magic solution for this. Every time you try to explain, they'll translate it into something that feels reasonable and relatable to them. PragmaticPulp told me that interruptions are super bad for his productivity... so whenever I have questions I'll just pop in and out really quickly. PragmaticPulp told me that interruptions are super bad for his productivity... because I should have taken that question to John instead. PragmaticPulp told me that interruptions are super bad for his productivity... because he's been under a lot of stress this week. PragmaticPulp told me that interruptions are super bad for his productivity... because he doesn't like me and doesn't like talking to me.
The idea that what we're saying is a straightforward expression of something we actually experience is way more bizarre and unlikely to them than the idea that we're trying to say something else and it's coming out in a garbled or passive-aggressive way.
I think that's why, as misguided as the article's suggestion is, the idea of allowing people to experience what we experience is so appealing. If they could experience it firsthand, then when we talked to them about it, they could accept it at face value.
>We really need to get past this smug idea that tech work is uniquely difficult in a way that no one else can understand.
The problem is that when a surgeon is cutting a brain with a scalpel, it's pretty obvious that now is not the time to ask them the status of their TPS report. There isn't the same sense of gravitas when it comes to a deep debugging session because it looks the same as when we are checking email.
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.
I learned to hide at a past company. I would book small meeting rooms for long periods and work in there. Or go work in the cafe. Even that is superior as while there are lots of small distractions, nobody specifically wants your attention. In the summer I would work outside under a tree.
Or as I didn't want a promotion at another company, would come in very early and leave early.
> 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.
> and certainly within a single company no one has to work as deeply in their minds as the programmers do.
I sort of agree, but... I do think there are orgs where folks do deep thought work who aren't labelled 'programmers', but... they're probably doing the same 'type' of thinking, at some level, as folks doing coding.
I'm certain 'developers' aren't the only folks who do deep thinking work, but we seem to be ... the ones treated the most like we're not, at various companies. In law firms I've been in, all the lawyers get doors, and those doors are closed when they're doing 'deep work' (planning, writing, talking to clients, etc). That's ... deep work, and they're getting billed out at hundreds of dollars per hour.
20+ years ago, I was doing dev work getting billed out at $180/hr, and was stuck in a cube next to project managers who were on the phone all the time. Wearing headphones was seen as "rude" by colleagues around me, but them talking on the phone for 5+ hours per day 6 feet from me was... totally AOK.
Disrespectful jerks are a problem in any workplace. Programmers complain about it online a lot, because programmers complain about everything online.
Making a disrespectful jerk do some stupid Sudoku problem to teach them about interruptions isn't overcoming their lack of perspective, it's just letting them know that they were a disrespectful jerk (which they probably already kind of know, but they're used to it so it doesn't bother them all that much).
Of course, you can be more upfront. Just hold out a palm towards their face and say 'just 5 minutes, I'm busy'. Yeah that's rude as hell, but sometimes you have to speak their language.
While I totally struggle with interruptions (and I have the ADHD bonus points), they always come from team mates that I globally appreciate. I hate interruptions and I do complain about it frequently to my coworkers, but that says absolutely nothing about them being jerks.
When you work in a team, you are frequently blocked and need someone else to give you an answer, even as a programmer. That’s an organizational problem that have to be tackled, for sure, but it rarely have something to do with individuals.
I once had a « PM » that liked to put its laptop on my desk to see what I was doing and to « pair » with me while I was programming. But he knew nothing about programming. THAT is wrong. I left that company.
I don't know what kind of places you have worked in, but I have rarely bumped into disrespectful jerks as coworkers in my jobs. If you work with many jerks, maybe there is an opportunity to improve the recruitment process there.
I think the reason this is more damaging to developers because as a developer you probably can't produce anything without focusing.
As to communicating when you don't want to be interrupted -- I am still working from home, and even my kids know that when the door to the office is closed they can't interrupt.
When I was still working at the office I was telling people that headphones == do not disturb.
Obviously, you need to provide them some way to send you the message. I try to keep my office doors open and headphones off when not necessary. I also tell people shoot an email and I will respond when I can.
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.
That's a fair point and good advice, however the full quote was "Sorry, I'm in the middle of something important. Can you come back at lunch time?", which can then start being a full conversation to find a time that fits both of you. I think a good way to respect other people time is to use asynchronous means of communication as long as what you ask isn't urgent.
I tend to use slack this way. Writing out my thought process helps to clarify things, even if I don't ever hit the send button. And if I do hit send, then it gives a good sense of what has been done, and how.
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.
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.
> 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 fundamental issue I have with this argument is that it assumes the role of “sales guy” and “manager” are always the same.
I’ve spent quite a few years in the Enterprise software space, and I can assure you that the knobs to twist on a massive deal are numerous, highly complex, and would paralyze some devs in their tracks.
It’s easy to trivialize these roles because they often appear to be full of “busy work”. If you have the opportunity, go spend some time with the sales team! Listen in on some calls. Get involved in a hiring round. Participate in a marketing meeting about establishing positioning for your next product/feature.
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.
> 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
And yet even with these 15 minutes you have to immediately mentally reconstruct the context of this meeting and then actively listen to what the other person says, figure out if they actually mean what they ask (quite commonly the issue is different), and then immediately jump into another meeting, and you can't just forget what happened during that 15 minutes. You have to carry this mental model of conversation and context (typically multiple ones) all the day with you. Then you have to actively prioritize across the various contexts and deliver value for all of them, while being in the meetings for the better part of the day.
I’ve noticed that I have a lot less trouble with interruptions deeper in my career than starting out because those mental models are refined and intuitive now. The example presented in the article where the programmer has a carefully constructed recreation of a null reference bug could probably be broken up into a series of steps that don’t require keeping as many variables in your head.
I agree that interruptions are annoying but they’re unavoidable, and we can develop strategies to make them less impactful. Passive aggressively trying to make somebody else feel your pain is guaranteed not to work and will just make them resentful and make you look petty.
As for managing the interruptions, I tend to think of it that a deep session needs maybe 3 hours from one end of the pool to the other. Break it and you might need to start over, depends on how checkpointy you can make it, so try to make a way to not get interrupted for that length of time. That's a real senior coder skill BTW, making your own exploration recoverable. You already mentioned one thing you can do, which is to not try the really long crossings.
That's one of my pet peeves in this (recurring) discussion.
If you're a programmer, and you're telling me that every time you work you have to reconstruct the state of a system so large you can barely hold it in your head, maybe you should invest in learning about modularity, abstraction, or just... taking notes?
The luxury of being able to design every system you work on isn't shared by many. Being able to hold the details of a complex process is one of the key traits that will allow you to succeed with legacy codebases or difficult languages.
You can try to refactor everything into a perfect state but business isn't going to wait.
> 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.?
Describing a lawyer as an "intuitivist" is pretty hilarious. Their work, especially surrounding contract work, can be extremely programming like, with very particular language, highly technical and specific terms/wording, and there absolutely are many cases where typing one thing wrong (such as a misplaced comma) can (and has[1]) completely change the meaning of crucial sections of contracts.
Obviously I can't know about what every profession does, not even my own. But I've interacted with enough professionals of various sorts to say I don't think the intricacy is the same.
It is. Before becoming a sysadmin I was a lawyer for 12 years. Never had trouble with interruptions while on my feet in court (except for my adversary, or the judge), but it was a real problem when drafting contracts or auditing complex estate accounts. Sure, you could multitask easily in a real estate closing or a trial settlement conference. But a lot of the work required shutting the private office door and asking the staff to "hold all calls". To be fair, sysadmin work was a lot less stressful and more rewarding -- except when it came time to write or debug code. That, and troubleshooting WebLogic services, Apache threads, the network team's firewall rules or database performance.
The real problem is that, culturally, most people aren't ready to accept software development as a high wire, professional, activity. That still would disturb this fantasy they have about tech being "intuitive" or managable in any meaningful way for non-experts. Those of us on the inside know that's b.s.
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.
And when I mentioned writers, I was thinking of the work that's probably required to build the plot, even before writing it. I'm not a writer, but I would imagine it involves holding a world and timeline in their head and tweak it while making sure they're not introducing plot-holes. I imagine quite a bit of research is involved, too.
As if programming can't involve intuition. There isn't one way to do things nor do we operate with strictly defined rules to follow. We need a fair amount of intuition from experience to make the decisions that will be more beneficial for the future development of our projects.
The point is others tend to rely more on intuitive structures that are everyday. Crystallised intuition about a specific domain doesn't count because of course everyone who is a specialist is going to have their own local knowledge. Calling it domain intuition might make more sense.
What kind of intuition do they rely so much on to call them intuitionists that is everyday in nature rather particular to their domain, but that programmers don't also rely on? Are we talking "everyday" like "I need to buy groceries" type of intuition? I don't understand what you're trying to say.
> 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.
When we get to this sort of absolute perspective. I like to think “either everyone before me is/was an idiot, or maybe I’m missing an unknown unknown”
I’m sure other technical fields of non programming require holding more than one thought in the head at once.
Perhaps anyone constructing anything that depends on an intricate set of rules may experience the same thing.
In a lecture Lamport once talked about the difference between mathematical equation (where half a page is a lot) and a program (which is a sort of math, only many pages long).
> I’m sure other technical fields of non programming require holding more than one thought in the head at once.
That's not a good enough comparison. You don't see the qualitative difference.
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, and has a naive view about programming.
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.
The author describes a context while he's debugging. I think an analogy would be a chess game, where the player has built/planned your stack of several 'look ahead' moves. And then you get interrupted. That can be indeed be very disruptive for a human brain. A computer can save that 'stack' and resume, not so for a human brain to recover your context. Programming has its unique things. Not to deny the other unique situations (underwater panel, clinician's analysis etc) that have been mentioned in the various threads of this discussion.
How about you respect my time on the job and I’ll respect yours. A distraction cost me time needed to do my job. If someone doesn’t respect my time, I let their managers know.
With interruptible work, you can get interrupted and get back to doing what you were doing with no/minimal disruption.
With non-interruptible work, it really disrupts you flow and may take some time to get back on track, disruptions just increase the Signal/Noise ratio.
And as the others saying, not only programming, but any kind of work can be disrupted by interruptions.
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 concept, because they have never done any real work.
>Instead, aside from the programmers, you have mostly salesdroids and managers, who have absolutely no concept, because they have never done any real work.
Wow. This is exactly what the top comment was talking about with the opening sentence. These people may not need deep concentration to be successful, but that doesn't mean they don't do real work.
> These people may not need deep concentration to be successful, but that doesn't mean they don't do real work.
They didn't claim that. They claimed that the fact that these people don't do real work means that they don't need deep concentration to be successful. A implies B, not B implies A. (For example, off the top of my head, plumbers (unlike salesdroids and managers) clearly do real work, but very little if any of it involves a deep mental model that would take significant time to rebuild if interrupted.)
FWIW, I don't actually agree with that implication as such - it would imply that, eg, playing Factorio is "real work" - but the problem is less stupid than "doesn't need deep concentration => doesn't do real work".
Which, interestingly shines a light on just now reductive the original comment was.
Parent comment’s take was actually more charitable to the GP by at least leaving room for the possibility that managers do real work (they do, and hopefully this isn’t controversial).
And I’d go a step further and argue that even within the managerial role, there are tasks that demand focus and deep work.
> the possibility that managers do real work (they do, and hopefully this isn't controversial).
I mean, I'd hope it's uncontroversial that any general statement about people has exceptions, but I assumed it was clear that we were talking about typical managers and salesdroids, not making blanket universalisms. If it wasn't I apologize for the confusion.
I don’t think it’s even possible to define - and it’s certainly not fair to summarily dismiss - typical managers.
If you’re just talking about managers that are bad at their jobs, call that out. If you’re advocating for a change in the actual management structure itself, call that out.
Maybe “typical” narrows the net ever so slightly, but the definition of typical is “having the distinctive qualities of a particular type of person or thing”.
Either “typical” is applied to managers broadly and then the negative characteristics you find fault with are inherent to the management role itself (and not necessarily the manager)…
Or “typical” is used to describe a specific type of manager, either characterized by certain common negative traits, job duties assigned to the manager, etc.
In either case, there’s something critically missing from a dismissal of “typical” managers without proper classification of “typical”.
> and then the negative characteristics you find fault with are inherent to the management role itself (and not necessarily the manager)
In the same sense that "typical" could be applied to, say, pickpockets broadly, and the associated negative characteristics are inherent to the pickpocketing role itself (and not necessarily the pickpocket)... sure? I don't really see why that would be a useful distinction, but I agree that it seems like a distinction you could make.
> Instead, aside from the programmers, you have mostly salesdroids and managers, who have absolutely no concept, because they have never done any real work.
Honest question - how many years of professional experience do you have?
Have you ever been on a team that didn’t have enough devs and needed to grow? Have you been on a team that addressed that by hiring more devs? What about funding for software and other tools to do your job?
This obviously varies from company to company, but often, especially at companies that promote from within, the managers around you very likely started doing exactly what you’re doing.
Managers also have their own kinds of deep work, like careful and detailed proposals to increase funding so your team can grow, just to name one.
If you expect the people you work with / who manage you to understand you and the challenges posed by distractions, taking some time yourself to truly understand them is just as important.
I should add a disclaimer: I’m not a people manager.
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?
A good sales person can make the business money (you know, the thing that keeps them from disappearing) without _any_ product yet existing at all. Programmers who build something rarely bring in money by its mere existence.
Be careful who you insult because its unlikely you could do what they do, and it's not guaranteed that you'd keep your job ahead of them if it comes to it.
A good 419 scammer can make the business money without any product ever existing at any point in time - that doesn't mean they're doing anything useful.
Not just unlikely—practically impossible. I don’t have the skills of a good salesperson or manager¹. But that’s orthogonal to what I was talking about, and to the subject of the fine article.
[1] And neither do most people employed in these positions.
> 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.
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.
Interrupted work is common to everyone, so use that commonality to your advantage when politely navigating interruptions.
Also, I hope nobody takes the author's fantasy literally:
> Well, worry not, because I think I have a way that you can actually demonstrate to them just how devastating interruptions are to your productivity compared to, say, theirs. In other words, here’s how to make someone understand that, for you, an interruption isn’t just a delay after which you can get right back to work but a complete total of your efforts up to that point. Here’s how. Invite the PM/manager/sales/whatever person to sit at his desk and tell him to humor you. Open up notepad and type a series of 3 or 4 digit numbers in sequence, like so:
Better advice is to learn how to communicate professionally. Real adults don't sit each other down and force them to add up a long list of 3-digit numbers while peppering them with interruptions to make a point.
Instead, communicate like peers: "Sorry, I'm in the middle of something important. Can you come back at lunch time?"
Or: "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?"
Don't be afraid to assert yourself in the conversation. Communicate the concern ("I'm in the middle of something important") and propose an alternative that would work better for you ("Can this wait until lunch time?"). Scale the assertiveness up or down depending on who's interrupting you. We all know some people who will take the hint and disappear, and we all know other people who will try to ignore your concerns and press forward anyway. Adjust accordingly.
Finally - Recovering quickly from interruptions is a skill that can be developed and learned. Obviously, you can't negate the damage of interruptions entirely. However, making an effort to gather your thoughts and return to work after interruptions goes a long way to limiting the damage. The worst thing you can do is pop open HN or Reddit or Twitter after an interruption because you're already out of the groove. Knowing how to manage yourself and get back into the groove as quickly as possible is a valuable skill.