When you think what you do is special, you will only look to other 'special' people for solutions to your problems. If you understand that many disciplines have the same problems, you can crib ideas from them. It's a major reason I push people to have extracurriculars.
Most of my crisis management skills came from volunteering at public events for clubs. Your kitchen renovation guy could fill a book on how to manage customer expectations.
> Instead, communicate like peers: "Sorry, I'm in the middle of something important. Can you come back at lunch time?" > Or: "Is this urgent? I can't really stop what I'm doing right now, but I can stop by your office around 3PM. Will that work?"
You're trying to avoid dumping brain state, so the more open ended the question is, the more state you lose. They start bringing up related facts that your brain expects to hold onto in order to fulfill social obligations, and each fact wipes out more of your train of thought. Asking the person if it's urgent invites them to monologue. Your smarter peers will see these questions as equivalent, the rest of your coworkers won't. Don't ask them to decide. Make them decide.
"Can you come back in X minutes/at time Y?" is short. Invites little commentary. If the answer is, "No you're late for a customer meeting" or "The building is on fire can't you hear the alarm?" then you were going to be interrupted anyway. We don't want to debate the relative importance of these two tasks. If we do then the interrupter wins, whether they deserve to or not.
You, probably, meant that "you lose [your current task mental context]".
The interrupter will not necessarily win from your loss.
This is absolutely true. I no longer mind interruptions. I don't love them, but they aren't devastating productivity crashes either. Weirdly enough, friendly, helpful answers to the query seems to reduce interruptions. I think people don't mind interrupting grumpy programmers.
Also, adopting contemporary coding practice helps. Keeping functions to a single purpose. Not mutating data. Restricting side effects. Automated testing. Acquiring complete understanding of your tools and frameworks. These things help you grasp at a glance more quickly what's happening.
In short, committing to allow people to interrupt can alter your approach and work flow to accommodate interruptions
The only time I enter a desperate fugue state juggling too many disparate code modules in my head is when the system is a poorly factored enterprise monolith.
Those aren’t uncommon but I reflexively avoid jobs that make those the majority of my work.
PMs, scrum masters and sales or business development types don't usually have the same kind of focus requirements during day to day. Sure, they also need deep focus when drawing up a detailed budget or doing roadmap planning or whatnot, but usually their day requires less focus and a broader contextual awareness instead.
So, obviously physicists, plumbers, bookkeepers, surgeons, mathematicians, all manner of creatives, designers, engineers, chemists and evolutionary biologists also need not to be disturbed while working. But their workplace is often cognisant of the fact.
Programmers often complain because the default setup in which they work (some kind of open plan office) and the roles they often interact with don't get the basics of what's needed.
If I needed to work on site, I'd regard an seperate office as a significant perk.
I have an office now and it helps a bit, but normally I hide at home and turn off email and put Teams into dnd for these tasks
If you were agreeing with him and just adding to the argument, then my apologies.
Bookkeeping and management accountancy are not really similar professions. A bookkeeper is focused on data entry, and tends to be a small company generalist, adding up invoices, receipts and sales tax etc. I have been a purchaser ledger clerk (processing supplier invoices en masse) and it requires a different kind of concentration entirely. I am rubbish at that kind of work now, I think your mind changes as you progress to the more supervisory work. A management accountant is trying to turn the outputs of this work (amongst other things) into coherent management information, filling in the gaps and making judgements and estimates.
We seem to be the only profession that cares then. It is only developers who get why you Slack people you are sitting next to.
Manual labor also require focus, but when you are occupied tends to be obvious. If you are under a car, messing around with a tool in your hand, everyone knows it is not the best time to interrupt you. In safety-critical jobs, like in the case of pilots, there are mandatory protocols that explicitly forbit interruptions during critical moments.
People usually know enough not to barge in when the manager is having an talk with his higher up or when the salesman is negotiating with a customer unless it really is urgent.
But programmers just stare at the screen all day, and most of the work happens in their head, so how do you know if they can be interrupted or not. Bad managers assume "always", because themselves only stare at the screen during their "off" time, so they assume programmers are always "off".
At the time we were in a pretty cramped office in a co-working space, so I appreciated anything that could help cut down on distractions even a little.
My step-dad works in logistics and likes to quote “a single interruption takes a person 15 minutes to get refocused”. He blocks specific hours for his field staff to stay away from the office staff, so they can process the critical daily work without interruptions.
Google searching seems to say it’s closer to 23 minutes these days. Industrial engineers seem to have studied interruptions on work in the late 90’s and maybe even earlier.
As a further anecdote, when I worked in manufacturing I would end up having to come in on the weekends to do cognitively demanding work. Designing tooling, creating and optimizing CNC programs, and checking parts using coordinate measuring machines while getting interrupted by the quoting department to “just give me a quick estimate what you think this part will cost for us to make for the customer”, or production saying “we need you to quickly trouble shoot the defective parts we are producing because otherwise we will be late and get a fine for missing the shipping date” results in costly errors that can’t be fixed by recompiling code.
Pressure, interruptions, and bad management are not unique to software development. And yes, other professions do care about production high quality work.
Many other professionals that do this kind of work have private offices. Painters, architects, lawyers, etc. Meanwhile we cram ourselves together, surround ourselves with physical and digital distractions, and expect near immediately responsiveness from peers.
I’m glad to have my team working from home now.
This actually happened to me once. Some big investor was coming one day, so we were all to be in our seats for a certain time to show that we were productive.
You may have hit the crux of the problem. Programmers aren't uniquely dependent on deep work, but tech companies seem to be uniquely determined to do everything they can do to make the office as hostile as possible to that. Add to that the expectation of instant availability via whatever messaging and it's clear even among tech company deep workers, programmers have worse conditions.
Our profession seems to be one where it is not obvious to others that we're in a flow or in deep working mode, since there is no visible difference between work-isolation mode, browsing the internet for random programming or browsing for fun, from four feet away.
My uncle is a neuro plastic surgeon, he is prone to disruptions in more ways than I am (if I talk to him while he's cooking about a decision he needs to make, he loses track of the recipe), but I assume he is never disrupted by someone asking something unrelated while he's working.
My partner too is clearly in an uninterruptible state when practicing the piano or painting something, even writing skeleton work is done on a book instead of a computer.
But I get why it is hard to notice a programmer in isolation over other professions of deep work - I don't put on a lab coat or scrubs , to communicate that clearly to others in a familiar "at work" situation.
I'm trying with a "at work" desk light, but I'm still not consistent enough with it & this is very much forced.
(Also please do not slack me when you're sitting right next to me, it's like, more disruptive and annoying than just talking to me. But mostly just use Email, please.)
I was about to say the same. Slack disruptions are often worse than in person interruptions. Email isn't.
And do you enable Slack notifications? I don't. I just look for the glow of the icon.
However, there really are things I want someone to have the ability to notify immediately for. Narrow time slots on in demand hardware like prototypes or FPGAs, change of team location in a lunch room or a big lab, and drop what you’re doing and debug this when it makes sense.
Maybe I just don’t focus as deep as others.
Make two tables of 10 rows and 3 columns on a piece of paper. Column one is letters. Column 2 is roman numerals. Column 3 is numbers.
Your task is simply to write down the letters from A to J, roman numerals from I to X and numbers from 1 to 10.
You will do this twice and you will time yourself with a (cellphone) stopwatch. First time around in the first table you will fill each _row_ first. So you will write A in first row, first column, I into first row second column, 1 first row third column. B into second row first column and so forth until you're done.
The second time around you fill out columns first. I.e. A in first row first column, B in second row first column, C ...
It's a really nice game and you can even play it just against yourself or let your boss play it against himself if he wants you to multitask. If the other person says "well that's because I didn't know my roman numerals by heart any longer!" they can play it again. You can get better at it of course but it still shows the effects of context switching just from letters, to numerals to numbers. Can't get simpler than that!
The other thing I don't see being discussed is that maximizing LoC per day may not be the thing that provides the most value to the company. It is tough though because those things aren't necessarily concrete and don't give us the same kind of satisfaction and feedback. We can't point to a new class or module or page that is now done, even if what it does isn't actually the result needed from the business. Sometimes the most important value you can provide to a business is thinking about what you are working on or what the newest requests from the business side are.
Chat systems aren't (yet?) dependent on ad revenue, so they don't need to copy the behavior of social media, but, possibly because they use the same operating-system level notification APIs, that's how they act.
Perhaps you do, but I and some of the people I’ve had the pleasure to work with do not.
Personally, I’ve almost always worked asynchronously.
If I have a question, I send it on the proper Slack channel and either keep going on what I was doing if isn’t blocking, or do something else when it is. Tasks are usually large enough for that.
Regarding Slack interruptions, all my notifications aside from a handful of phone numbers are disabled.
Things rarely are urgent, and can usually wait an hour or even until the next break.
I agree, however...
> "Is this urgent? I can't really stop what I'm doing right now, but I can stop by your office around 3PM. Will that work?"
I would just say:
"I can't really stop what I'm doing right now, but I can stop by your office around 3PM."
If you ask them if that will work, they'll tell you they need the answer immediately most of the time. People want instant gratification. But, by leaving it off, you have still given them something and you've gotten your time back.
In my experience the vast majority of people are reasonable, especially in a professional environment.
The question "Will that work" is optional. You need to be polite when dismissing someone, but the goal here is to offer 2 messages "I'm busy now" and "I'll get to you as soon as this busyness passes" The discussion needs to end as quickly as possible so as to not lose your focus, but also without making them angry. Asking questions in that case is probably a bad idea.
The few times in my career when I haven't had a door I could close, I did all of my deep work from home and only came into the office for meetings (which I compressed into 1-2 days).
The delicate social dynamics described in these threads sound incredibly expensive. I can't imagine paying someone a quarter or half million dollars and then draining away their productivity on this sort of thing.
They have no problem doing that. Do it often enough and the people learn to just come straight to me instead.
The only people that I’ve worked with that were intrusive, pushy, and demanding of engineers immediate time were the people that were trying to go around the producer because they already knew their issue was low priority for the team.
Agreed. Interruptions aren't nearly as annoying when my immediate reply is "waaait, let me write down some stuff"
Is that the only possible reason they wouldn't understand? The etiquette around interruption is different in different professions, and programming seems to be on an extreme edge of a spectrum. There are professions where people work together in offices and interrupt each other all the time, without restraint. I am not smarter than them. They are doing jobs I would not be good at. Something must be different.
Maybe the work is different in some way than most other jobs, or maybe we're defective. Honestly, I think the people who are best at accommodating this difference are alpha management types who look down on programmers. They aren't surprised that we don't cope well with interruptions, just like they're not surprised that their dog is afraid of fireworks. "Stay away from my programmers. They work better when nobody talks to them."
It's people who think we're really smart, or who rely on empathy to relate to us, who keep interrupting, because they can't wrap their heads around the idea that it's hard for us. Good communication is not a magic solution for this. Every time you try to explain, they'll translate it into something that feels reasonable and relatable to them. PragmaticPulp told me that interruptions are super bad for his productivity... so whenever I have questions I'll just pop in and out really quickly. PragmaticPulp told me that interruptions are super bad for his productivity... because I should have taken that question to John instead. PragmaticPulp told me that interruptions are super bad for his productivity... because he's been under a lot of stress this week. PragmaticPulp told me that interruptions are super bad for his productivity... because he doesn't like me and doesn't like talking to me.
The idea that what we're saying is a straightforward expression of something we actually experience is way more bizarre and unlikely to them than the idea that we're trying to say something else and it's coming out in a garbled or passive-aggressive way.
I think that's why, as misguided as the article's suggestion is, the idea of allowing people to experience what we experience is so appealing. If they could experience it firsthand, then when we talked to them about it, they could accept it at face value.
Seems to be the only one that is both deep work and treated like an assembly line, though.
Interruptions aren’t that bothersome when you aren’t under that kind of pressure to produce.
The problem is that when a surgeon is cutting a brain with a scalpel, it's pretty obvious that now is not the time to ask them the status of their TPS report. There isn't the same sense of gravitas when it comes to a deep debugging session because it looks the same as when we are checking email.
I don't know what the solution is, aside from being blunt about setting expectations and fierce when those expectations are violated trivially. Or exiting to a remote location where one can do work without interruption.
Or as I didn't want a promotion at another company, would come in very early and leave early.
We don't really have to. It is far better for us to keep selling the image that programming is something tantamount to wizardry than to make it seem like it can be understood on the same level with other kinds of work. For one, it's not really true. Programming requires a depth of focus you don't find in most other fields, and certainly within a single company no one has to work as deeply in their minds as the programmers do.
I sort of agree, but... I do think there are orgs where folks do deep thought work who aren't labelled 'programmers', but... they're probably doing the same 'type' of thinking, at some level, as folks doing coding.
I'm certain 'developers' aren't the only folks who do deep thinking work, but we seem to be ... the ones treated the most like we're not, at various companies. In law firms I've been in, all the lawyers get doors, and those doors are closed when they're doing 'deep work' (planning, writing, talking to clients, etc). That's ... deep work, and they're getting billed out at hundreds of dollars per hour.
20+ years ago, I was doing dev work getting billed out at $180/hr, and was stuck in a cube next to project managers who were on the phone all the time. Wearing headphones was seen as "rude" by colleagues around me, but them talking on the phone for 5+ hours per day 6 feet from me was... totally AOK.
Making a disrespectful jerk do some stupid Sudoku problem to teach them about interruptions isn't overcoming their lack of perspective, it's just letting them know that they were a disrespectful jerk (which they probably already kind of know, but they're used to it so it doesn't bother them all that much).
Of course, you can be more upfront. Just hold out a palm towards their face and say 'just 5 minutes, I'm busy'. Yeah that's rude as hell, but sometimes you have to speak their language.
While I totally struggle with interruptions (and I have the ADHD bonus points), they always come from team mates that I globally appreciate. I hate interruptions and I do complain about it frequently to my coworkers, but that says absolutely nothing about them being jerks.
When you work in a team, you are frequently blocked and need someone else to give you an answer, even as a programmer. That’s an organizational problem that have to be tackled, for sure, but it rarely have something to do with individuals.
I once had a « PM » that liked to put its laptop on my desk to see what I was doing and to « pair » with me while I was programming. But he knew nothing about programming. THAT is wrong. I left that company.
As to communicating when you don't want to be interrupted -- I am still working from home, and even my kids know that when the door to the office is closed they can't interrupt.
When I was still working at the office I was telling people that headphones == do not disturb.
Obviously, you need to provide them some way to send you the message. I try to keep my office doors open and headphones off when not necessary. I also tell people shoot an email and I will respond when I can.
That's already too late though. At this point I've already lost what I was doing.
When I find myself six or seven levels deep in a stack, I often realize I need to open up a new coding window and write myself some quick notes.
Nobody else constructs models in their minds that are almost purely mechanical and specific to a small problem. Every model the sales guy or manager uses has very few knobs to twist and are mostly intuitive models for which everyone has a template and practices use of every day: emotions, status, hierarchy, urgency, etc.
The programmer is building a house of cards and startling him means he needs to start over.
I agree if you're not deep coding, eg doing a bit of cleanup or documenting, it's not such a big problem.
EDIT
I seem to have ruffled some feathers with the absolute sounding "nobody else" phrasing.
I'm sure you'll run into someone else who has to think like a programmer, but I also tend to think such people to the extent they exist actually are programmers in some sense: either they happen to have a different title, or under the hood they are pretty much doing the same thing.
Now for some more about the nature of programmer's complexity. The thing about being a coder is you end up working on multiple abstraction levels, and they are all still your domain. If your app has some networking issue and you're wiresharking the packets, that's still you. If the front end is slow because you're calculating a lot on the GUI thread, that's still you. If the database is returning strange results, that's still programming. These are all areas that require a huge amount of work, in particular reading about existing conventions and tools, to understand.
In addition, programming has the capacity for you to create your own, local abstractions. Not only is the computer capable of remembering everything you made up, it also computes the interactions that you didn't consider. You have to interface these with the firmament. It is this creation of your own little menagerie and connecting it to the existing world that throws up an enormously large space for weird things to happen.
The thing that I need to point out is that there's no general human intuition for a lot of these things. Yes, you can use a bit of drawing diagrams to help you. But we don't get that intuitive, natural feel that you get in the rest of your life, particularly around emotions, that is I think called system 1 somewhere.
I also don't mean domain specific intuition, which is really just a form of learned knowledge.
Programmers are far from the only people who do creative work that involves building complex models in a mental "buffer" and then streaming them out into some persistent form.
Maybe most people on HN are programmers, and maybe most programmers work in offices where they're the only people who do this kind of work. But that's the kind of exceptionalist tech-centric point of view that can only make it more difficult to communicate our struggles to our non-programmer co-workers, who might actually be very familiar with similar struggles in different (possibly non-professional) contexts.
The fundamental issue I have with this argument is that it assumes the role of “sales guy” and “manager” are always the same.
I’ve spent quite a few years in the Enterprise software space, and I can assure you that the knobs to twist on a massive deal are numerous, highly complex, and would paralyze some devs in their tracks.
It’s easy to trivialize these roles because they often appear to be full of “busy work”. If you have the opportunity, go spend some time with the sales team! Listen in on some calls. Get involved in a hiring round. Participate in a marketing meeting about establishing positioning for your next product/feature.
Have you ever worked in sales or as a manager?
My manager's day is filled with stuff in 15 minute to 1.5 hour increments.
It's a different side of the same coin.
I agree that interruptions are annoying but they’re unavoidable, and we can develop strategies to make them less impactful. Passive aggressively trying to make somebody else feel your pain is guaranteed not to work and will just make them resentful and make you look petty.
As for managing the interruptions, I tend to think of it that a deep session needs maybe 3 hours from one end of the pool to the other. Break it and you might need to start over, depends on how checkpointy you can make it, so try to make a way to not get interrupted for that length of time. That's a real senior coder skill BTW, making your own exploration recoverable. You already mentioned one thing you can do, which is to not try the really long crossings.
If you're a programmer, and you're telling me that every time you work you have to reconstruct the state of a system so large you can barely hold it in your head, maybe you should invest in learning about modularity, abstraction, or just... taking notes?
You can try to refactor everything into a perfect state but business isn't going to wait.
What about mechanical engineers, electronic engineers, etc.?
EDIT: Removed writers. Architects and lawyers don't have as much room for mistakes and technical detail matters more in their work.
Type one thing wrong and your novel is still a novel.
[1] - https://www.bbc.com/worklife/article/20180723-the-commas-tha...
Obviously I can't know about what every profession does, not even my own. But I've interacted with enough professionals of various sorts to say I don't think the intricacy is the same.
Ymmv
The real problem is that, culturally, most people aren't ready to accept software development as a high wire, professional, activity. That still would disturb this fantasy they have about tech being "intuitive" or managable in any meaningful way for non-experts. Those of us on the inside know that's b.s.
with many novels, the author may have intended X, but readers are often encouraged to bring their own views and interpretations to the work, and those may often be useful to others in understanding the work. that's not as true for most software I've worked on though.
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 act of saying "Sorry, ..." is enough to derail a deep debug session. Having a manager hover over your shoulder is enough. And if that's not believable, then clearly one of us hasn't been there, and has a naive view about programming.
1. interruptible work 2. non-interruptible work
With interruptible work, you can get interrupted and get back to doing what you were doing with no/minimal disruption.
With non-interruptible work, it really disrupts you flow and may take some time to get back on track, disruptions just increase the Signal/Noise ratio.
And as the others saying, not only programming, but any kind of work can be disrupted by interruptions.
Wow. This is exactly what the top comment was talking about with the opening sentence. These people may not need deep concentration to be successful, but that doesn't mean they don't do real work.
They didn't claim that. They claimed that the fact that these people don't do real work means that they don't need deep concentration to be successful. A implies B, not B implies A. (For example, off the top of my head, plumbers (unlike salesdroids and managers) clearly do real work, but very little if any of it involves a deep mental model that would take significant time to rebuild if interrupted.)
FWIW, I don't actually agree with that implication as such - it would imply that, eg, playing Factorio is "real work" - but the problem is less stupid than "doesn't need deep concentration => doesn't do real work".
Parent comment’s take was actually more charitable to the GP by at least leaving room for the possibility that managers do real work (they do, and hopefully this isn’t controversial).
And I’d go a step further and argue that even within the managerial role, there are tasks that demand focus and deep work.
I mean, I'd hope it's uncontroversial that any general statement about people has exceptions, but I assumed it was clear that we were talking about typical managers and salesdroids, not making blanket universalisms. If it wasn't I apologize for the confusion.
If you’re just talking about managers that are bad at their jobs, call that out. If you’re advocating for a change in the actual management structure itself, call that out.
Maybe “typical” narrows the net ever so slightly, but the definition of typical is “having the distinctive qualities of a particular type of person or thing”.
Either “typical” is applied to managers broadly and then the negative characteristics you find fault with are inherent to the management role itself (and not necessarily the manager)…
Or “typical” is used to describe a specific type of manager, either characterized by certain common negative traits, job duties assigned to the manager, etc.
In either case, there’s something critically missing from a dismissal of “typical” managers without proper classification of “typical”.
Yes.
> and then the negative characteristics you find fault with are inherent to the management role itself (and not necessarily the manager)
In the same sense that "typical" could be applied to, say, pickpockets broadly, and the associated negative characteristics are inherent to the pickpocketing role itself (and not necessarily the pickpocket)... sure? I don't really see why that would be a useful distinction, but I agree that it seems like a distinction you could make.
Honest question - how many years of professional experience do you have?
Have you ever been on a team that didn’t have enough devs and needed to grow? Have you been on a team that addressed that by hiring more devs? What about funding for software and other tools to do your job?
This obviously varies from company to company, but often, especially at companies that promote from within, the managers around you very likely started doing exactly what you’re doing.
Managers also have their own kinds of deep work, like careful and detailed proposals to increase funding so your team can grow, just to name one.
If you expect the people you work with / who manage you to understand you and the challenges posed by distractions, taking some time yourself to truly understand them is just as important.
I should add a disclaimer: I’m not a people manager.
If you’re dismissive of their work, how can you ever expect them to be understanding of yours?
A good sales person can make the business money (you know, the thing that keeps them from disappearing) without _any_ product yet existing at all. Programmers who build something rarely bring in money by its mere existence.
Be careful who you insult because its unlikely you could do what they do, and it's not guaranteed that you'd keep your job ahead of them if it comes to it.
A good 419 scammer can make the business money without any product ever existing at any point in time - that doesn't mean they're doing anything useful.
Not just unlikely—practically impossible. I don’t have the skills of a good salesperson or manager¹. But that’s orthogonal to what I was talking about, and to the subject of the fine article.
[1] And neither do most people employed in these positions.
And this helps the argument not one bit. I'm sure it's very comforting to condescendingly look down on other professions, but you're doing nothing but further proving the point in the comment above.
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.