I code in C and other languages as well, so no offense to those who work mainly with scalars ;)

A couple of minutes pass. You’re still ascending. The pilot announces you’ll circle for another 20 minutes waiting for the storm to pass, and if not they will have to return to the port of departure.

APL and J : Agreed. Haskell is my refuge when Python starts getting verbose. Even if you're interrupted, there's a slim chance with concise languages that you could carry that line in your head even as you are dragged away from your context.

I sometimes write J by hand on paper.

[1] https://www.euterpea.com/haskell-school-of-music/

Love this.

Similarly, if you are interrupted in the middle of a "solve" it may be difficult to jump back in - especially if the puzzle hasn't been created correctly and you are trying to "debug" which numbers conflict. Some puzzles are harder than others. At times you don't have a pen and paper so you have to keep a mental model of the whole puzzle in your head which makes an interruption that much more jarring.

Not a perfect analogy, but close enough to get me a 15 minute buffer at the end of the day and fewer knocks on the office door :D

What I am facing however, is a related issue. Perhaps because I have not been doing much programming lately, I find it increasingly difficult to actually get and be in the zone. When I go in, I go all in, and enter a kind of fugue state where the hours slip away. While for some this may sound advantageous, in the past, it has been associated with some bad physical and psychological health outcomes. Now, I actually have anxiety about going into such a state, and try to piece meal my problems, and focus on the non-programming work and thinking.

Situations change, and I am about to be in one where I do really need to perform a lot of coding myself. I suppose I am answering my own question, but I need to split up my work and take notes to reduce the numbers of abstracted layers upon which I am working. Take more breaks with confidence I can return.

I suspect this technique can help ease the burdens of interruptions as well, but it does come at a cost in time. For me, the severe crunch time requirements and gained insane last minute skills should still be less necessary for some time. This is likely called being in a startup and getting older and, well, recognizing long-term limitations.

I’ve discovered I’m much more in touch with my mental and emotional state and even a five minute break will really relieve some of the pressure you put on your mind and body. Also because it’s just for 25 minutes anyway, it’s much easier to get started again, even with unfun work.

Edit: In case you’re worried this will make things worse, because of the regular interruption, I’ve found it to not be so bad with the exception of some types of debugging. The mind is pretty good at mulling over the problem while you’re taking a break and often I’m more effective afterwards. But the 25/5 isn’t a hard requirement and should be changed depending on preference and type of work.

My channel has a short talk recommending Pomodoro for engineers, including using it with Agile. The methods are extremely similar. https://www.youtube.com/channel/UC0PGaH-sVPGIdFUC88FgMmw

Starting a new job and that may finally be enough of a change to trigger me actually trying this after all these years of hearing about it.

I'm reminded of a scene from the movie 'Never Cry Wolf' where the bush pilot, while flying the plane, puts himself into a state of rage before stepping outside to fix the problem.

https://youtu.be/9i90_-HpVz0?t=120

Like when you need to spend some time in a dark silent room before filling like having fun or do house chores or do the cooking.

That resonated, and it's the best example for me to come to grips with this.

Nice way to put it.

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.

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.

You, probably, meant that "you lose [your current task mental context]".

The interrupter will not necessarily win from your loss.

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

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.

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.

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

If you were agreeing with him and just adding to the argument, then my apologies.

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.

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.

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".

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.

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.

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 working from home now.

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.

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.

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.

(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.

And do you enable Slack notifications? I don't. I just look for the glow of the icon.

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.

Maybe I just don’t focus as deep as others.

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!

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.

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.

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.

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 gratification. But, by leaving it off, you have still given them something and you've gotten your time back.

In my experience the vast majority of people are reasonable, especially in a professional environment.

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.

They have no problem doing that. Do it often enough and the people learn to just come straight to me instead.

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.

Agreed. Interruptions aren't nearly as annoying when my immediate reply is "waaait, let me write down some stuff"

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.

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.

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.

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.

Or as I didn't want a promotion at another company, would come in very early and leave early.

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.

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.

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.

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.

That's already too late though. At this point I've already lost what I was doing.

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.

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.

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.

Have you ever worked in sales or as a manager?

My manager's day is filled with stuff in 15 minute to 1.5 hour increments.

It's a different side of the same coin.

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.

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?

You can try to refactor everything into a perfect state but business isn't going to wait.

What about mechanical engineers, electronic engineers, etc.?

EDIT: Removed writers. Architects and lawyers don't have as much room for mistakes and technical detail matters more in their work.

Type one thing wrong and your novel is still a novel.

[1] - https://www.bbc.com/worklife/article/20180723-the-commas-tha...

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.

Ymmv

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.

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.

> 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.

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.

1. interruptible work 2. non-interruptible work

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.

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.

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".

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.

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.

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”.

Yes.

> 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.

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.

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.

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.

1. Stop being passive aggressive about being interrupted.

2. Take notes.

Dealing with [1]: it is ok, to interrupt some one who starts talking to you, tell them "Hang on", "Just a minute", "Come back in an hour". You have to put your foot down if you are working, even with bosses.

Note taking[2]: early in my career I kept too much information in my head, including debugging. Life is so much better with notes. Nowadays, I work problems out on the paper and not in my head. It's harder to start doing, but once you start you have a paper trail of where you have been and where you are going. Sometimes, you do need to drop everything and go be part of the action. When that happens, notes will get you back where you were quickly.

As a team leader in a 7 person company, I am not entitled to any degree of dedicated focus time during the work week. Everything is ultimately my responsibility and I have to answer some important questions immediately. Being aware that you are going to be disrupted and building in some mechanisms to deal with this reality is probably the more practical path.

Trying to convince your PMs that distractions are lethal and that developers need to be protected in some anechoic chamber 8 hours a day is never going to fly. It is total fantasy. I personally try to minimize the distractions that I as a developer incur upon other developers, but I cannot change the natures of other team members or artificially inhibit their interactions. People are just going to have to learn to get along and develop boundaries naturally. Don't be afraid to stand up for yourself, but also realize you are almost certainly not a special unicorn and that eventually you will have to interact with your teammates (the ones who don't browse HN) for the business to extract any value out of you.

An additional strategy is to try and decompose your work effort into smaller steps before you begin. Trying to eat the whole elephant in 1 sitting is how you wind up in a lot of these "interrupted" situations to begin with.

It has the added benefit of day to day it can help you remember what you're doing. Also if you save your notes if you come back to the project in a few months you have a refresher.

Besides basic note taking I suggest two additions to it.

1. Keep it in reverse chronological order. For multiday or multiweek projects this makes it easier

2. Add the links to sites you were using instead of trusting browsing history

On putting your foot down - some bosses react really badly to that. I choose not to work for bosses like that anymore, but I'm in a position where I can do that. Not everyone is, though.

In my opinion this is more common to software development only because software developers, at laest in Europe, do not have the same social recognition as other professionals. An undisciplined PM/PO interrupting everybody to get estimates to update their GANTT chart will be as disruptive in an operating theater or in a legal office as they are in a software development team. Society just decided to not allow randos (as in people with no medical training) in operating theaters while welcoming them (as in people with no development training) in software development teams. Worse than that, these randos often have more power than the professionals doing the work. Surgeons would be complaining and people would be dying, if scrum-certified noisy "servant-leader" PMs were allowed to decide how to carry out operations.

I think the wider problem is a conflation of administration and leadership and a tendency for healthcare professionals to not be good at the politics that comes with leadership positions.

I don't necessarily have a problem with a non-technical leadership or with non-technical people cooperating with the development team (the latter is often essential for the team to work on meaningful tasks). What I have a problem with is scrum masters, project managers and their like entering an operating theater to distribute candies and pizza, to ask people questions about an unassigned Jira card stuck in the "To Do" swimlane, and generally treat professionals with 10-20 years of experience as if they were a bunch of partially-socialized four-year-old children.

In my past 10 years of experience (as a tech lead, principal and dev manager), the single change that always increased productivity has been to get rid of PMs/SMs and take over their roles. A brain surgeon coordinates brain surgery, a software developer coordinates software development.

"Why can't I write anything down?"

"Because when I'm seven to ten levels deep in a stack of issues, I never write anything down, I need to keep it all in my head."

"But why?"

"Well... I have a whole mental model constructed. I couldn't possibly write it all down."

"But it seriously wouldn't help you to keep some notes while you work? And perhaps add to the skimpy comments in the codebase while you're doing it?"

"I seriously don't see how that would help."

"You literally just said you've written down the code '8xZ204330Kd' and now you have no idea what it was for. Did you imagine you'd be guaranteed to remember it between writing it down and finally solving the bug? Why didn't you at least write some context about what that string was?"

Seriously, just like most kids somewhere between the ages of four and ten goes from "I know I will remember this!" to "I should write this down so I don't forget," programmers could stand to recognize that sometimes taking some notes can help clear their brain when they're too many levels deep in a stack.

This study claims it takes >20 minutes to get back on track: https://www.ics.uci.edu/~gmark/chi08-mark.pdf The effects of notes weren't quantified, but if you have a study on that, I'd be happy to read it.

I do take notes, but it's almost invariably simple stuff like todo items or row IDs I'll need for a lookup.

> I wish respecting communication preferences was more respected. Asynchronous and non intrusive messaging seems so much better for the majority of my coworkers

I'm interested in this second point. You've provided an interpretation of what respecting your coworkers' communication preferences might mean.

- What would it mean for them to respect your communication preferences?

- If two people are going to communicate, and they have conflicting preferences, who gets accommodated?

Why do you say you're being unfairly rewarded? Your communication skills are a genuinely useful skill to have.

I wore these shoes, but one case was special. I was being young, debugging some live show-stopping issues at the client side (the sales department of a plastics factory, a part of a lingered project) when their production manager who I didn’t even know approached and asked in a very demanding tone when the entire project will be done. I distracted and politely redirected them to our PM only to hear a tirade about me doing nothing for months, despite the fact that all the work was thrown on me only recently, after our low-skilled part of the office managed to create enough mess. I politely explained that (omitting the “mess” part) and repeated what I’ve said before, again to no avail. And then my ego decided that it is reasonable to elevate my tone a little and ask them to please not interrupt me at this part of work, because it doesn’t make it easier. God, that hit him unexpectedly hard. Management is never ready for that sort of a dialogue, as I learned later. He left in rage and never greeted me again. (To not look too grumpy, I must say that everyone else, including some high-profile nose-up positions there, sort of adored me for solving their needs at least partially after a long time and for being not yet another silent display-peering guy.)

Wasn’t long before the story was relayed to our PM. I was criticized and expected to apologize but I refused because morally I didn’t feel guilty and to that moment I understood that this project was unlikely to succeed anyway. Few days later I just took the costs of my time and a fellow developer’s at my own expense and left this project completely. It was worth it.

No moral here, but another example that they don’t really understand the difference between a grinder operator and a developer. Also, I may play sir-vs-peasant games with management, but I still don’t get it as a human and will bite back if they play too much. Nothing is worth losing your dignity, unless you’re seriously leveraged. (And in my experience 99% of the client employees never exploited it anyway for personal attacks or sort of that)

Engineering Managers understand this too. And the goal is to minimize interruptions - and meetings are an interruption!

The problem is that the time pressures on someone on a manager's schedule are such that they do not get the information needed to make the necessary decisions. As such, Managers are in a trilemma:

* The PM makes the decision without the information necessary, and the team goes "why didn't you get me involved?" The PM or EM (Often working 50+ hours a week) then has to do rework and is not ready for the team. * The PM or EM interrupts someone on the team, reducing the team's ability to do useful work and being frustrated about how many meetings they have. * The PM/EM waits and is in a continual multitasking situation themselves, unable to do the creative work because they do not have the information necessary at the time they can do the work. (This also lends itself to long post-standups, and long hours for the PM.) Or, it turns into a "slack in a general channel and wait" situation. Slack is the same interruption in most organizations, even when not using direct mentions.

I've tried to constrain the times I meet my team around other necessary meetings, and it throws out my day trying to accommodate, and even then I can't always do it.

As an engineer, which do you prefer? (It's always great when the PM and EM are on a 7pm call because that's the only time we can do it, let me tell you.) Some engineers say that everything should be on paper from the PM, but that does not account for the extra time that it takes to put documentation together that may be based on faulty assumptions.

It's a fundamentally hard problem. Let's not treat it as trivial to solve.

Getting hit, falling off, and climbing back on the bike takes a lot of effort, and you have to rebuild your momentum each time it happens. The more times you're knocked off in a day, the more tired you get of climbing back on.

Rebuilding the momentum when programming can take 30 minutes or so. Then you just get whacked with another stick.

A similar one I have heard before is "It's like falling asleep... It takes a while to get into sleep mode and if someone interrupts you, you have to start the process again." Most people can understand how annoying it would be to be interrupted all night and not get a good night sleep.

Though riding a bike makes programming sound more active than sleeping, which is good.

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 reputation as an ass.

but without some way to distract myself in small increments when i need a break, i end up "focusing" on unimportant tasks that aren't material to the actual task i need to complete, which end up wasting more of my time than a couple minutes of scrolling through HN or twitter.

the problem isn't the wasted time, it's the interruption while you're trying to focus. there's nothing wrong with taking a break from focusing.

https://news.ycombinator.com/item?id=814695

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).

---

And I added this part later, just to frame the question in case it suggests that I think notes are useless here:

I have been writing and keeping notes of my work for more than a decade, mostly writing them as I go.

In correspondence it is bit different and there I usually try and write down lines.

When I make a move I spend a few mins replaying the moves to make sure I recall my current plan and that I'm not missing anything obvious, before I start analyzing possible moves.

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.

If you had to use a piece of software that ran lengthy operations and you had to wait very long for the results, would it be more effective to wait for the results or fix the program so it runs faster?

I.e. Some feature needs too long to be implemented? Ok lets fix these slow workers, send all the devs to a workshop for time-management and speed-coding or whatever.

This is the most annoying question in the world.

I usually want to respond "probably sometime before the heat death of the Universe, but honestly that could slip".

Until I write the fix I have no idea that the direction I'm taking will actually work. Very often I discover some $SADNESS while trying to actually do the fix. Some test may blow up in some way I never expected (often on some platform that I'm not actively testing until I run it through CI because I don't have an AIX virt on my laptop). That could derail me for a week or two.

Then there's CI itself which breaks quite often due to how complicated it needs to be (we have to support AIX builds and things like that). I can't give you an estimate on that because I don't know how that is going to fail or how long it'll take to fix it, but if I tell you we can fix it next week that's exactly the time CI gets broken in some way that'll take 2 weeks (often for a different team that I don't have any control over) to sort out all the mess.

The realistic estimate is often closer to 4 weeks for something that might seem like it'll only take a few days at the start. And it doesn't matter how vitally important it is to some customer. I'll try to get it out in a few days / next week, but it might slip for a month due to the unknown-unknowns and breakage outside of my direct control.

But this is exactly the information that other people need to plan around to get on with their own work. You need to see things from their perspective. The inner workings of your processes and the long-winded explanation, from their side, is "the most annoying" response in the world.

It's a simple question. The ETA is the only information that is actionable for them. If the answer is "anywhere from a couple days to a month", then flat out say that. If you think that sounds wishy-washy and absurd and that it must then require a long-winded explanation to soften, chances are that it does sound absurd and the long-winded explanation will not soften it, but instead the person may start to think that you are unorganized and clueless. They might start to cringe at the thought of their next interaction with you. Just give them a straight answer.

FWIW, I don't know anything about your system, but it sounds like you need to invest in making triage in your system more efficient.

I spent years working on V8 and we consistently invested in tools, tests, processes, and best practices to help us fielding the thousands of production issues over the years.

Again, I don't know anything about your system, but my advice would be to be more serious and diligent about the requests you field instead of treating them as annoyances. Take a look at your processes and dispassionately try to figure out why it takes you so long to know anything about anything.

External dependencies changing without warning at the worst possible times. And many of them we can't arbitrarily prune because when you boil it down they ultimately support things which have a contract value associated with them. The system is large and complicated, mostly necessarily so, which makes it brittle. We spent time making it less brittle and attacking the complexity, but its still large and brittle. We don't get to go back to startup square 1 where we don't have those kinds of contracts and get to reconsider the business decisions that have been made over the past decade.

These days I have to actually look at my calendar and pay attention to where my family is and force myself to drop work at certain times. Further, I've begun not starting deep work until I know that I am not likely to be interrupted for hours at a time. I still get calls hours into that, "hey somebody else's plans changed at the last second, I need to drive 20 minutes to get somebody and then drive them home and feed them" which is basically gonna kill my productivity for 3X as long as it takes.

But my strategy for overcoming this with long and involved investigations is to write my thinking down in a stream-of-consciousness format.

Write down all my thinking, dead ends I went down, why certain assumptions can or cannot be made, everything.

Then if I have an interruption it's much easier picking everything up again, even if I have to start over from scratch with a new set of IDs or whatever.

Think of it like frequently committing in git.

Let's say you are struggling with a design choice, or something in the production system looks screwy, how do you know who you can approach to discuss this?

Well, the way i've worked in the past (when we used to all sit in an open plan office which seems like an age ago) was that you signalled 'do not disturb' for those times when you needed to be in the zone by putting headphones on. You weren't necessarily listening to music, some of us did, some didn't, but it was used as a clear signal that you shouldn't be disturbed.

The result of the headphone rule works pretty well. I've worked places where there's been a full production meltdown, serious money being lost (well, not earned) due to the downtime, and all sorts of people and teams being pulled in to help identify and resolve the issue, meanwhile on the same desk someone in headphone mode being totally unaware of the problem.

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.

So you just learn to work while the meetings are running.

Don't Wake Up the Programmer!

https://alexthunder.livejournal.com/309815.html

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”

I think it's important to make sure you have the infrastructure in place to support your team's productivity. It isn't something that won't happen without work:

1) Have an escalation flow, and have someone dedicated to handle escalations. The example about the order API crashing should never hit anyone except the person who is on call that week, and that person shouldn't have any project work assigned. (They can be doing project work, but your planning should assume they're AFK the entire week. Sometimes on-call weeks are like that, and sometimes nothing comes up. Don't aim for the 50%-ile on that variance, aim for the 99.9%-ile, or your projects will be set-back 50% of the time instead of 0.01% of the time. And you'll burn out the on-call engineer.)

2) Forbid DMs. All questions should be posted to a public channel. (I guess people still use email, but I haven't seen it anywhere I've worked for several years, so it might be one of those things that's dead now.) Many questions that are directed at a specific engineer can easily be answered by the manager or lead who is probably on a "manager's schedule" and not a "maker's schedule". Forcing someone else to investigate also spreads the knowledge around on the team. (If there's only one person who knows how something works, they can't go on vacation, will get burned out, and quit; leaving you with 0 people that know how something works.)

3) Most meetings should be very targeted and be predicated on pre-work, and have an agenda. For example, if you're a product manager, you shouldn't invite 10 random engineers and say "hey can I have X by next Monday?" Write a PRD, solicit comments asynchronously, and then have a 1 hour working session to resolve the comments that require high-bandwidth discussion. Once the PRD is ready, eng leads can prioritize the feature, and assign resources to write a design document, and treat that as normal project work. Assigning people underspecified work just leads to disappointment on both sides -- the PM doesn't get the feature they want, the engineer has to delete the code they spent a month on. (It's also important for product to not change their mind too often: https://apenwarr.ca/log/20171213#slide13)

4) If you can get software to bin-pack meetings, you should. There are very few cases where the exact time of the meeting matters -- what matters is making sure that the global interruption cost is minimized. (This is NP-complete, but there are still services that will do it for you. Great is the enemy of good here, and "Everyone is free on 2pm Thursday" is the worst possible way to schedule meetings.)

5) Don't have status meetings. If you want a daily slot to discuss issues that come up, that's totally fine, but going around the room to ask what you did yesterday is a colossal waste of time. It's always "today I'm working on the same thing that I worked on yesterday", because nothing that is worth paying someone $200,000 a year to do is done in a day. (How do you know if someone is done with their high-impact project? Don't worry, they'll tell you.)

I do my best work at night, when everyone is asleep.

(circa 2013)

However, these discussions very often commit a big mistake: the Ford mass production mistake of being too myopic, optimising too locally.

In an organisation there are many people working complex problems toward a common goal. You can optimise for local productivity, i.e. one programmer steams ahead, ignoring the rest of the organisation, and gets a lot done. But when local productivity is optimised at the cost of shutting down quick communication between people, the organisation will grind to a halt.

The programmer will, eventually, make the wrong things, in the wrong amount, and at high cost -- not to mention how the other people that needed help from the programmer will just hover around and not know what to do.

Or worse, but more likely: they'll improvise an incorrect solution to the problem. Eventually that solution will blow up and the programmer will have even more work to do to fix it.

This is similar to the problems Ford made for himself with the mass production paradigm, in that you can install a machine to really efficiently make parts for a car at a rate of 1,000 per second -- but if it needs to make them in batches of 50,000 and it takes hours to set up the batch, you're adding so many hidden costs to the process. Local optimisation can easily kill global optimisation. (Entire books have been written about this, so I won't expand too much on it.)

If you truly want good results, you can't take a myopic view of optimisation and only look at your personal ability to crank out solutions to what you think are the right problems.

For good results, you need to optimise the productivity of the entire system, and the entire organisation is a good start. (Later, you should include suppliers and other peripheral entities in your optimisation process.)

The inefficiencies of the organisation is, in my experience, almost never the ability of a programmer to crank out solutions to what they think are the important problems.

In my experience, the inefficiencies are almost always lacking communication. Failure to understand the important problems. Slow feedback. Code lying around not making things better for the users. Code written for a problem someone decided were no longer important. Bad documentation and internal support. Bad teamwork, especially across division and team boundaries.

Essentially all the problems we know from the old bad days of manufacturing.

Please, realise that the person interrupting you definitely think they are doing it for a good reason, and they are probably trying to spare you from meaningless work -- now, or in the future.

If that's not the case, then the discussion must be centered around organisational productivity, not just the idea that personal productivity is more important than anything else.