The fact that you are able to pick your own time to get distracted makes all the difference. I read HN when I'm blocked on something, waiting on a compile, on the loo, on a coffee break. The costs of context switching in these cases is very low compared to when I'm deep into debugging or writing code.
HN feels like a distraction, but i find that when i don't have some sort of distraction i'm less productive. if i'm deep into solving some problem i don't have any motivation to check HN or other time wasters.
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.
You can use dual n-back as a systematized way to do this. Get them to do it for a bit uninterrupted, and then use a random beep generator to generate interruptions. Most people will score drastically lower with random interruptions.
To add to this, there’s a lot of neurodiversity in the programming world. A lot of people have brilliant brains that just don’t work well with interaction. I had a discussion with other people on my team recently and realized I was the only extroverted person on the team. I think it’s also worth saying I personally think I’m one of the worst developers on the team but being able to context switch is unfairly rewarded and gives business people the impression I’m way more competent than I am. Furthermore, to me COVID was the worst thing in the world in terms of social isolation and a majority of my team mates loved it. I wish respecting communication preferences Was more respected. Asynchronous and non intrusive messaging seems so much better for the majority of my coworkers
> I had a discussion with other people on my team recently and realized I was the only extroverted person on the team.
> 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?
For me, I have colleagues that have made it clear they prefer email to a slack or call. I don’t care either way so I think it’s on the person who doesn’t have a preference. It makes professional relationships better to do those Tiny things and not expect immediate communication.
>I’m one of the worst developers on the team but being able to context switch is unfairly rewarded and gives business people the impression I’m way more competent than I am
Why do you say you're being unfairly rewarded? Your communication skills are a genuinely useful skill to have.
I work with developers who are better than me that make less money. I’m ok with being aggressive In negotiations and it bothers me that people who provide more value are taken advantage of. I’m getting to the point in my career where I don’t want to do anything more technical and I love meetings and communicating with people and trying to figure out how to go into a po/pm or developer advocate role
The example I like to use is sudoku. Often, after a day of programming, it takes me a while to "come out of it" and I explain that to my SO as if she'd been doing hours of sudoku and then had to jump into a social situation.
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
Okay, I'm stealing this. I'm going to prepare a broken sudoku and ask my partner/colleague/whoever to debug it, then interrupt them to ask when they'll be finished :)
This article is why I'm not a programmer anymore. It's just impossible to be a programmer in the office while also trying to be social. I don't want to sit in an office surrounded by other people and get frustrated because it's not quiet or calm. I rather talk to people and have fun.
For me, programming only works when working from home and I'm alone.
> 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.
> Any deep work suffers from interruptions, and programming isn't the only type of work that has significant mental context. This idea that programmers are uniquely vulnerable and no one else can understand doesn't help the situation.
We seem to be the only profession that cares then. It is only developers who get why you Slack people you are sitting next to.
I think we’re one of the few that requires nearly entirely deep work yet also often work in an environment that isn’t conducive to it.
Many other professionals that do this kind of work have private offices. Painters, architects, lawyers, etc. Meanwhile we cram ourselves together, surround ourselves with physical and digital distractions, and expect near immediately responsiveness from peers.
I 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.
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.)
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.
> (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.
> 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 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".
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.
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?"
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 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.
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.
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?
>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.
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.
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.
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.
> 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.
> 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.?
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.
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.
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.
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.
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.
> 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.
> 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.
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.
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.
> "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.
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.
>> 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.
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.
> 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.
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.
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.
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.
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.
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.
> 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.
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.
>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.
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.
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.
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.
> 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.
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.
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.
I probably interrupt myself more than anyone else.
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.
This also applies to remote interruptions like slack and email messages. The difference is you can control these interactions better by hitting the "do not disturb" mode. Just make sure people understand why you're not responding right away.
Hahahah. I tried this with my wife and she said I was being an asshole and go feed the kids.
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.
The suggested `adding game' in the article seems pretty smug and patronizing to me.
Surely explaining the situation to the `culprit' like an adult would do just as well without stooping to the ``I'm interrupting you! I'm interrupting you! See how annoying it is?'' solution. If someone has such little regard for you that a normal conversation won't work, I feel like that `demonstration' is likely to just garner you a reputation as an ass.
Probably in person it would be a bit different. I have a feeling this is a quickly whipped up example. Contrived and silly, sure, but the point is made.
With the added danger of just handing an easy win to an oldschool accountant type, who surely knows how to do trivial carry addition and can remember 4 digits at time.
If you had to use a piece of software that ran lengthy operations and had to start over from the beginning if it was interrupted for any reason, would it be more effective to prevent interruptions as best you can and hope they never happen, or to fix the program so it saves its work along the way and can restart after an interruption? There are a lot of reason why you can get interrupted, not all of which are your boss stopping by for an update.
This article is exactly why programmers are seen as whiny prima donnas. Too many refuse to work in a way that accommodates working with other people.
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.
People have jobs where they need to concentrate ? and...people prefer not to be interrupted when concentrating ?
oh. my. god.
The author looks old enough to know better than to propagate software development as some kind of novelty role in an organisation, and also old enough to know that cultivating the image of the tortured prima dona, who must not be disturbed while creating his masterwork, does a lot more harm to the profession than good.
If you need to work without interruption, pull on your big boy pants, take your code and your laptop, and go work somewhere where there are none.
If what you are working on is so intricate and volatile, get funding and build your own fucking lab like scientists have been doing for years.
Otherwise, you're part of an organisation, on a salary, like everyone else. So play your part.
Could you please not post in the flamewar style to HN, cross into personal attack, or call names in arguments here? The site guidelines ask you not to do any of that. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and sticking to the rules when posting, we'd be grateful.
The submitted article is a flame war against non-developers and promotes the same attitude in the workplace. Other people have jobs too.
It's condescends :
"Your non-techie peers just don’t get it, no matter how many times you try to make them understand."
Demeans :
"Tell him that you bet him lunch he can’t get it done in five minutes, only getting one shot at getting the answer right. Maybe he’ll stop laughing and get to work."
..and insults :
"complete with ridiculous buzzword BS bingo and sports metaphors about “closing out the game in the endzone” or something. By the time the dust settles and you’ve been Six-Sigma-ed into submission by 3rd degree black belts",
As long as HN keep accepting such submissions, I'll keep giving them the treatment they deserve, which I think is fair.
Whether that's true or not, you (i.e. everyone here) need to follow the rules whether someone else is breaking them or not. Any other approach guarantees a downward spiral, because it always feels like the other person started it and did worse. To put it in terms that many will remember from their mothers: two wrongs don't make a right.
Perhaps you don't the article author (or whoever the other person may be) any better, but you owe this community better if you're participating in it.
The nature of the article is hardly in question. It is the headline, and purpose of the piece.
My best advice would be to apply your vigilance to submissions as diligently as you do to the comments, nipping it in the bud, as it were. That's what I'd do, if I was interested in maintaining standards as your profess to be.
People are generally selfish and focused on their own goals. Everyone has their stress and tries to relieve it either by working machines or working people.
Due to the unpredictable hours of salary positions, programmers should be defensive and stand up for themselves more often. Being walked all over is typically a sign to find a better work culture elsewhere.
This article is a fantasy situation that would never play out in the real world. PMs don’t have time to mess around with a stupid mental exercise, nor would the lesson change their reality.
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.)
PMs explicitly know the issue with interruptions. Most PMs I know work 1-2 hours either before or after business hours precisely because this is the only time they can get work done.
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.
I have been programming since 1977/78, and sometimes for work, but most of the time for fun. As someone who does technical work at heights with rope access, and many years of technical diving on hydraulics, pneumatic, and electrical equipment, I can say it all depends on your ability to shut out interruptions and get to a good stopping point. I get frustrated when I am programming and I am interrupted, but my most frustrating experience was troubleshooting a technical issue at heights, underwater, or on the deck during a show with almost 2000 patrons getting impatient, while a COO/CFO wants an estimate on when you will solve the as-yet-unidentified issue. They call the show off if you can't get an estimate to repair or resume after 15 min. and they expect you to hold to your time-to-repair or resume estimate. Oh, and half a million to one million USD are at stake! You might be standing in front of a controls cabinet with hundreds of wires and devices and some indications of where to look, or 10m underwater trying to find a source of the fault. I think interruptions suck for any person who is focused on doing a good job - bus drivers, pilots (yes, I know - autopilot!), soldiers in combat, air traffic controllers, chefs, almost any job. This is why I never took a job coding full time. It is always secondary to my actual job even if it is important. And, I like J and APL for the very reason that you are looking at a few lines of code vs. a few pages of for loops ;)
I code in C and other languages as well, so no offense to those who work mainly with scalars ;)
Thank you. I've been torn about a private vs. public life. I have always enjoyed the immediacy of the moment in life having lost friends while still in my teens. I am very tech savvy, and I love GoPros and smartphones for what they are, but I rarely film or photo myself. I do journal, so perhaps when I stop playing around, I'll try writing a book for my children.
Please do. Having lost my dad somewhat unexpectedly I would have loved something like this. I have 2 kids now and think besides financial security, journals, letters etc might be one of the most valuable things I could give them. That way they know me whether I’m here to tell them or not
Yes, it would be a primary motivation for me to memorialize my life for my children. It's tough losing a parent; my condolences on your father's passing. A friend I've known for 39 years is currently dying of ALS. It's crazy how fast it is taking him. He was just rennovating a house a year ago. He started a second family before being diagnosed, and he has a three year old. I remembered the Michael Keaton movie, My Life, where he makes videos of a bunch of things to teach his child when he is gone. I am horrible at the whole photo/video thing of myself. I guess it's the focus of being in the moment, and not sufficiently planning for it, so I am grateful my wife takes photos and videos once and a while with me in them.
I think it would be unfair to limit it to technical work. I think people who excel in any "think heavy" work would prefer not to be interrupted while they think. Not all "think heavy" work is technical.
Airline pilots have a very high workload when landing and it requires intense focus starting about 30 minute before. They are not allowed to talk about anything unrelated in that period.
Yup, and you can be very grateful for their decisions in that period as well. The most hairy flight I’ve been on involved trying to land in Kampala in the midst of a terrible thunderstorm. Turbulence like I’d never felt before (after hundreds of flights). A hushed stillness in the cabin, people grabbing their loved ones. From the amount of time you’ve been descending and the feeling of the flight you know you’re on final approach. Then wham, it feels like the plane fell out of the sky, and it’s still black out the window. A moment more calm. You look around; you thought what you felt before was the worst turbulence ever but now you’re surprised the plane is in one piece still. Then the pilot aborts approach at full throttle and you’re pushed back in your seat with unusual force.
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.
Yes I've been in that situation (as a passenger, not a pilot!) Incredible how much power the aircraft has at full throttle. A lot of people freak out or panic in that situation, because it's so abrupt, but it's a sign that the pilot(s) are trying to go from a very dangerous/tricky situation to a much safer scenario.
For me, the situation was a horrific and violent summer thunderstorm in Dallas. But the pilots handled it and we landed safely the 2nd time.
That’s the so-called “sterile cockpit rule” and it exists, is generally for ground operations and flight ops (other than level cruise) at/below 10K feet, which isn’t 30 minutes before landing, but rather a third to half of that, typically.
Your interruptions/work-context are way out there in terms of stress/impact etc.
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 do love Haskell too, but I am only a dilettante. I played with Euterpea[1], and I like it's mathematical bent like J and APL. I could probably get more practical work done with Haskell, but I like the way J and APL make me iterate on a short piece of code until it is a diamond. I should look at Haskell again...
Wow, what made you keep a job with such unreasonably high stress from the upper management? I would've told them to fuck off at some point, probably the second or third time someone is being this unreasonable.
First, solve the problem at hand. Second, then make your grievances. Always take the high road, and debate later, unless it's a life or death situation. Principles before personalities.
What grievances? I just mean there's a ton of jobs out there and some of them come with high management pressure, while others don't. And I'm trying to figure out why would specific people take the more stressful kind, for example is there something that compensates for that? Maybe a generous vacation schedule / low workload most of the time?
In my case, foreign travel and living, very good pay, and I guess I am an adventure junkie. Diving, ropes, bungee jumping, motorcycles, and many other things take my fancy, but sometimes just living somewhere that takes me outside myself. How do you put a value on that? Also, when there's a high signal to noise ratio, the truth tempers it for me no matter who or how much they bluster. For somebody, breaking a finger nail can be a full day ordeal, and that's not being totally sarcastic, but realizing that you need to understand what perspective the other person has. The COO/CFO is looking at managing the fallout of your immediate emergency, so they have other things on their minds, and perhaps they don't maintain a professional persona that day, but hey, I have my bad days too, and I'd like to get through it as smoothly as possible. When you are fast to point your finger at someone, remember, there are three of your own fingers pointing right back at you!
253 comments
[ 5.5 ms ] story [ 282 ms ] threadhttps://news.ycombinator.com/item?id=814695
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.
> 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.
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
For me, programming only works when working from home and I'm alone.
https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt...
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 seem to be the only profession that cares then. It is only developers who get why you Slack people you are sitting next to.
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.
(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.)
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.
I was about to say the same. Slack disruptions are often worse than in person interruptions. Email isn't.
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.
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.
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.
If you’re dismissive of their work, how can you ever expect them to be understanding of yours?
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.
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.
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.
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.
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.
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.
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.
[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.
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.
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.
> 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 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 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.
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.
Agreed. Interruptions aren't nearly as annoying when my immediate reply is "waaait, let me write down some stuff"
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.
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.
They have no problem doing that. Do it often enough and the people learn to just come straight to me instead.
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.
In my experience the vast majority of people are reasonable, especially in a professional environment.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
oh. my. god.
The author looks old enough to know better than to propagate software development as some kind of novelty role in an organisation, and also old enough to know that cultivating the image of the tortured prima dona, who must not be disturbed while creating his masterwork, does a lot more harm to the profession than good.
If you need to work without interruption, pull on your big boy pants, take your code and your laptop, and go work somewhere where there are none.
If what you are working on is so intricate and volatile, get funding and build your own fucking lab like scientists have been doing for years.
Otherwise, you're part of an organisation, on a salary, like everyone else. So play your part.
Idiot.
It's condescends :
Demeans : ..and insults : As long as HN keep accepting such submissions, I'll keep giving them the treatment they deserve, which I think is fair.Perhaps you don't the article author (or whoever the other person may be) any better, but you owe this community better if you're participating in it.
https://news.ycombinator.com/newsguidelines.html
My best advice would be to apply your vigilance to submissions as diligently as you do to the comments, nipping it in the bud, as it were. That's what I'd do, if I was interested in maintaining standards as your profess to be.
https://news.ycombinator.com/newsguidelines.html
then do so, my friend. then do so.
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.)
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.
Don't Wake Up the Programmer!
https://alexthunder.livejournal.com/309815.html
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.