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 ;)
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.
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.
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.
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
Interruptions are very challenging with any deep work that takes hours. This is true.
What I am facing however, is a related issue. Perhaps because I have not been doing much programming lately, I find it increasingly difficult to actually get and be in the zone. When I go in, I go all in, and enter a kind of fugue state where the hours slip away. While for some this may sound advantageous, in the past, it has been associated with some bad physical and psychological health outcomes. Now, I actually have anxiety about going into such a state, and try to piece meal my problems, and focus on the non-programming work and thinking.
Situations change, and I am about to be in one where I do really need to perform a lot of coding myself. I suppose I am answering my own question, but I need to split up my work and take notes to reduce the numbers of abstracted layers upon which I am working. Take more breaks with confidence I can return.
I suspect this technique can help ease the burdens of interruptions as well, but it does come at a cost in time. For me, the severe crunch time requirements and gained insane last minute skills should still be less necessary for some time. This is likely called being in a startup and getting older and, well, recognizing long-term limitations.
I would recommend trying the pomodoro method: 25 minutes of work, 5 minute break away from screens, repeat. 30 minute break after a few cycles.
I’ve discovered I’m much more in touch with my mental and emotional state and even a five minute break will really relieve some of the pressure you put on your mind and body. Also because it’s just for 25 minutes anyway, it’s much easier to get started again, even with unfun work.
Edit: In case you’re worried this will make things worse, because of the regular interruption, I’ve found it to not be so bad with the exception of some types of debugging. The mind is pretty good at mulling over the problem while you’re taking a break and often I’m more effective afterwards. But the 25/5 isn’t a hard requirement and should be changed depending on preference and type of work.
Are you saying getting into that "in the zone" state affected your mental health. Interesting. Any examples of the side effects? Is it hard to put into words?
> Your non-techie peers just don’t get it, no matter how many times you try to make them understand.
We really need to get past this smug idea that tech work is uniquely difficult in a way that no one else can understand. Any deep work suffers from interruptions, and programming isn't the only type of work that has significant mental context. This idea that programmers are uniquely vulnerable does no favors when trying to address the problem.
Interrupted work is common to everyone, so use that commonality to your advantage when politely navigating interruptions.
Also, I hope nobody takes the author's fantasy literally:
> Well, worry not, because I think I have a way that you can actually demonstrate to them just how devastating interruptions are to your productivity compared to, say, theirs. In other words, here’s how to make someone understand that, for you, an interruption isn’t just a delay after which you can get right back to work but a complete total of your efforts up to that point. Here’s how. Invite the PM/manager/sales/whatever person to sit at his desk and tell him to humor you. Open up notepad and type a series of 3 or 4 digit numbers in sequence, like so:
Better advice is to learn how to communicate professionally. Real adults don't sit each other down and force them to add up a long list of 3-digit numbers while peppering them with interruptions to make a point.
Instead, communicate like peers: "Sorry, I'm in the middle of something important. Can you come back at lunch time?"
Or: "Is this urgent? I can't really stop what I'm doing right now, but I can stop by your office around 3PM. Will that work?"
Don't be afraid to assert yourself in the conversation. Communicate the concern ("I'm in the middle of something important") and propose an alternative that would work better for you ("Can this wait until lunch time?"). Scale the assertiveness up or down depending on who's interrupting you. We all know some people who will take the hint and disappear, and we all know other people who will try to ignore your concerns and press forward anyway. Adjust accordingly.
Finally - Recovering quickly from interruptions is a skill that can be developed and learned. Obviously, you can't negate the damage of interruptions entirely. However, making an effort to gather your thoughts and return to work after interruptions goes a long way to limiting the damage. The worst thing you can do is pop open HN or Reddit or Twitter after an interruption because you're already out of the groove. Knowing how to manage yourself and get back into the groove as quickly as possible is a valuable skill.
> We really need to get past this smug idea that tech work is uniquely difficult in a way that no one else can understand.
When you think what you do is special, you will only look to other 'special' people for solutions to your problems. If you understand that many disciplines have the same problems, you can crib ideas from them. It's a major reason I push people to have extracurriculars.
Most of my crisis management skills came from volunteering at public events for clubs. Your kitchen renovation guy could fill a book on how to manage customer expectations.
> Instead, communicate like peers: "Sorry, I'm in the middle of something important. Can you come back at lunch time?"
> Or: "Is this urgent? I can't really stop what I'm doing right now, but I can stop by your office around 3PM. Will that work?"
You're trying to avoid dumping brain state, so the more open ended the question is, the more state you lose. They start bringing up related facts that your brain expects to hold onto in order to fulfill social obligations, and each fact wipes out more of your train of thought. Asking the person if it's urgent invites them to monologue. Your smarter peers will see these questions as equivalent, the rest of your coworkers won't. Don't ask them to decide. Make them decide.
"Can you come back in X minutes/at time Y?" is short. Invites little commentary. If the answer is, "No you're late for a customer meeting" or "The building is on fire can't you hear the alarm?" then you were going to be interrupted anyway. We don't want to debate the relative importance of these two tasks. If we do then the interrupter wins, whether they deserve to or not.
> Recovering quickly from interruptions is a skill that can be developed and learned
This is absolutely true. I no longer mind interruptions. I don't love them, but they aren't devastating productivity crashes either. Weirdly enough, friendly, helpful answers to the query seems to reduce interruptions. I think people don't mind interrupting grumpy programmers.
Also, adopting contemporary coding practice helps. Keeping functions to a single purpose. Not mutating data. Restricting side effects. Automated testing. Acquiring complete understanding of your tools and frameworks. These things help you grasp at a glance more quickly what's happening.
In short, committing to allow people to interrupt can alter your approach and work flow to accommodate interruptions
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.
> 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.
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.
> "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.
> We really need to get past this smug idea that tech work is uniquely difficult in a way that no one else can understand
Is that the only possible reason they wouldn't understand? The etiquette around interruption is different in different professions, and programming seems to be on an extreme edge of a spectrum. There are professions where people work together in offices and interrupt each other all the time, without restraint. I am not smarter than them. They are doing jobs I would not be good at. Something must be different.
Maybe the work is different in some way than most other jobs, or maybe we're defective. Honestly, I think the people who are best at accommodating this difference are alpha management types who look down on programmers. They aren't surprised that we don't cope well with interruptions, just like they're not surprised that their dog is afraid of fireworks. "Stay away from my programmers. They work better when nobody talks to them."
It's people who think we're really smart, or who rely on empathy to relate to us, who keep interrupting, because they can't wrap their heads around the idea that it's hard for us. Good communication is not a magic solution for this. Every time you try to explain, they'll translate it into something that feels reasonable and relatable to them. PragmaticPulp told me that interruptions are super bad for his productivity... so whenever I have questions I'll just pop in and out really quickly. PragmaticPulp told me that interruptions are super bad for his productivity... because I should have taken that question to John instead. PragmaticPulp told me that interruptions are super bad for his productivity... because he's been under a lot of stress this week. PragmaticPulp told me that interruptions are super bad for his productivity... because he doesn't like me and doesn't like talking to me.
The idea that what we're saying is a straightforward expression of something we actually experience is way more bizarre and unlikely to them than the idea that we're trying to say something else and it's coming out in a garbled or passive-aggressive way.
I think that's why, as misguided as the article's suggestion is, the idea of allowing people to experience what we experience is so appealing. If they could experience it firsthand, then when we talked to them about it, they could accept it at face value.
>We really need to get past this smug idea that tech work is uniquely difficult in a way that no one else can understand.
The problem is that when a surgeon is cutting a brain with a scalpel, it's pretty obvious that now is not the time to ask them the status of their TPS report. There isn't the same sense of gravitas when it comes to a deep debugging session because it looks the same as when we are checking email.
It doesn't matter that you explain that they're interrupting and wrecking your chain of thought; they're just going to keep doing it, and the train has already gone off the rails.
I don't know what the solution is, aside from being blunt about setting expectations and fierce when those expectations are violated trivially. Or exiting to a remote location where one can do work without interruption.
> 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.
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 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 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.
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.
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.
1. Stop being passive aggressive about being interrupted.
2. Take notes.
Dealing with [1]: it is ok, to interrupt some one who starts talking to you, tell them "Hang on", "Just a minute", "Come back in an hour". You have to put your foot down if you are working, even with bosses.
Note taking[2]: early in my career I kept too much information in my head, including debugging. Life is so much better with notes. Nowadays, I work problems out on the paper and not in my head. It's harder to start doing, but once you start you have a paper trail of where you have been and where you are going. Sometimes, you do need to drop everything and go be part of the action. When that happens, notes will get you back where you were quickly.
> Your non-techie peers just don’t get it, no matter how many times you try to make them understand
In my opinion this is more common to software development only because software developers, at laest in Europe, do not have the same social recognition as other professionals. An undisciplined PM/PO interrupting everybody to get estimates to update their GANTT chart will be as disruptive in an operating theater or in a legal office as they are in a software development team. Society just decided to not allow randos (as in people with no medical training) in operating theaters while welcoming them (as in people with no development training) in software development teams. Worse than that, these randos often have more power than the professionals doing the work. Surgeons would be complaining and people would be dying, if scrum-certified noisy "servant-leader" PMs were allowed to decide how to carry out operations.
> Now, tell him to add those numbers in his head. He can look at the screen and talk/whisper/mutter to himself, but he can’t write anything down and he can’t type anything.
"Why can't I write anything down?"
"Because when I'm seven to ten levels deep in a stack of issues, I never write anything down, I need to keep it all in my head."
"But why?"
"Well... I have a whole mental model constructed. I couldn't possibly write it all down."
"But it seriously wouldn't help you to keep some notes while you work? And perhaps add to the skimpy comments in the codebase while you're doing it?"
"I seriously don't see how that would help."
"You literally just said you've written down the code '8xZ204330Kd' and now you have no idea what it was for. Did you imagine you'd be guaranteed to remember it between writing it down and finally solving the bug? Why didn't you at least write some context about what that string was?"
Seriously, just like most kids somewhere between the ages of four and ten goes from "I know I will remember this!" to "I should write this down so I don't forget," programmers could stand to recognize that sometimes taking some notes can help clear their brain when they're too many levels deep in a stack.
Notes still require you to build context. Additionally, they have to be useful and up to date. I can't speak for others, but even with notes, it takes a while to get back into the flow.
This study claims it takes >20 minutes to get back on track: https://www.ics.uci.edu/~gmark/chi08-mark.pdf
The effects of notes weren't quantified, but if you have a study on that, I'd be happy to read it.
I feel like a large problem is that serializing mental state when programming is incredibly lossy and slow. Doing a serialize-deserialize cycle to paper is going to take me a lot longer than just trying to figure it out from the code I already wrote while solving the problem.
I do take notes, but it's almost invariably simple stuff like todo items or row IDs I'll need for a lookup.
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
Re-diving is not only hard but also demotivating and morally tiring. You spend the same efforts again and again and at the fourth try you just stop understanding why they need you, a deep-analyzing guy, in the first place, when they could just hire a “friday ETA at any cost, boss” guy and ship whatever they could do right at friday evening.
I wore these shoes, but one case was special. I was being young, debugging some live show-stopping issues at the client side (the sales department of a plastics factory, a part of a lingered project) when their production manager who I didn’t even know approached and asked in a very demanding tone when the entire project will be done. I distracted and politely redirected them to our PM only to hear a tirade about me doing nothing for months, despite the fact that all the work was thrown on me only recently, after our low-skilled part of the office managed to create enough mess. I politely explained that (omitting the “mess” part) and repeated what I’ve said before, again to no avail. And then my ego decided that it is reasonable to elevate my tone a little and ask them to please not interrupt me at this part of work, because it doesn’t make it easier. God, that hit him unexpectedly hard. Management is never ready for that sort of a dialogue, as I learned later. He left in rage and never greeted me again. (To not look too grumpy, I must say that everyone else, including some high-profile nose-up positions there, sort of adored me for solving their needs at least partially after a long time and for being not yet another silent display-peering guy.)
Wasn’t long before the story was relayed to our PM. I was criticized and expected to apologize but I refused because morally I didn’t feel guilty and to that moment I understood that this project was unlikely to succeed anyway. Few days later I just took the costs of my time and a fellow developer’s at my own expense and left this project completely. It was worth it.
No moral here, but another example that they don’t really understand the difference between a grinder operator and a developer. Also, I may play sir-vs-peasant games with management, but I still don’t get it as a human and will bite back if they play too much. Nothing is worth losing your dignity, unless you’re seriously leveraged. (And in my experience 99% of the client employees never exploited it anyway for personal attacks or sort of that)
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.
Programming is like riding a bike. It takes time to get on the bike, to get momentum going. Interruptions are like someone hitting you with a stick while you ride.
Getting hit, falling off, and climbing back on the bike takes a lot of effort, and you have to rebuild your momentum each time it happens. The more times you're knocked off in a day, the more tired you get of climbing back on.
Rebuilding the momentum when programming can take 30 minutes or so. Then you just get whacked with another stick.
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.
I'm a quantitative finance / actuarial programmer. I've flipflopped between the programming and business side a few times in my life. At one stage I was in the Actuarial Valuations team, responsible for the periodic valuation of a set of life insurance books. Timelines were very tight, input data was a mess, the products themselves were complex. This wasn't easy stuff. During valuation time all of us were on edge.
But for some reason, being interrupted then didn't cause nearly as much damage to my mental house of cards as they do now, where my day job involves translating messy actuarial spreadsheets to code.
I can't put my finger on it. Both tasks were complex. Maybe the fact that actuarial valuations (like most financial roles) are based on spreadsheets and you have a visual model right in front of you, or accessible within a few clicks. I think that relieves some pressure on the mental model.
Programming, on the other side, even with all the IDE tools like a watch list and call stack, seems to require a larger mental stack, given the same complexity in another field.
Side note: work from home has been a dream come true in terms of the disappeance of interruptions. But I do miss the coffee breaks with colleagues (or what others would call water cooler conversations).
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.
The only way I could explain this to my wife was telling her that programming is like falling asleep. And people asking stuff while you try to program is as destructive as people asking you stuff while you are trying to fall asleep (or sleeping already): if you asked and I answered, damage is already done. No matter how small the response or how simple the question was.
> "Any chance I can get an ETA on having that fixed?”
This is the most annoying question in the world.
I usually want to respond "probably sometime before the heat death of the Universe, but honestly that could slip".
Until I write the fix I have no idea that the direction I'm taking will actually work. Very often I discover some $SADNESS while trying to actually do the fix. Some test may blow up in some way I never expected (often on some platform that I'm not actively testing until I run it through CI because I don't have an AIX virt on my laptop). That could derail me for a week or two.
Then there's CI itself which breaks quite often due to how complicated it needs to be (we have to support AIX builds and things like that). I can't give you an estimate on that because I don't know how that is going to fail or how long it'll take to fix it, but if I tell you we can fix it next week that's exactly the time CI gets broken in some way that'll take 2 weeks (often for a different team that I don't have any control over) to sort out all the mess.
The realistic estimate is often closer to 4 weeks for something that might seem like it'll only take a few days at the start. And it doesn't matter how vitally important it is to some customer. I'll try to get it out in a few days / next week, but it might slip for a month due to the unknown-unknowns and breakage outside of my direct control.
I've been tempted to hack together a web based game. It will be some simple puzzles requiring working memory, like that addition of numbers example. It could even be word problems with multiple choice answers, but the questions has to be relatively wordy with several data points to consider.
Periodically it will get interrupted, by several things, but mainly a face with a speech bubble, asking various questions like "are you busy?", "can I ask you a question?", "how much longer do you think you will take to complete this?".
This will completely take over the screen and you won't see your last question. You can select some answers (yes, no, 5 minutes, etc.) and some answers will lead to more questions especially if you give wrong answers. Also questions that you need to visualise to come up with an answer, like comparison of sizes or distances of things you don't often compare (bus vs yacht)
After each interruption you will return to your puzzle game.
The first interruption will only kick in after a while so you get used to how easy it is without interruptions, but then they'll start to kick in frequently but also randomly so you have some breaks sometime but never know for how long.
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.
[+] [-] eggy|4 years ago|reply
I code in C and other languages as well, so no offense to those who work mainly with scalars ;)
[+] [-] dagurp|4 years ago|reply
[+] [-] lostphilosopher|4 years ago|reply
[+] [-] thayne|4 years ago|reply
[+] [-] vjdingdong|4 years ago|reply
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.
[+] [-] H8crilA|4 years ago|reply
[+] [-] harrisonjackson|4 years ago|reply
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
[+] [-] ideamotor|4 years ago|reply
What I am facing however, is a related issue. Perhaps because I have not been doing much programming lately, I find it increasingly difficult to actually get and be in the zone. When I go in, I go all in, and enter a kind of fugue state where the hours slip away. While for some this may sound advantageous, in the past, it has been associated with some bad physical and psychological health outcomes. Now, I actually have anxiety about going into such a state, and try to piece meal my problems, and focus on the non-programming work and thinking.
Situations change, and I am about to be in one where I do really need to perform a lot of coding myself. I suppose I am answering my own question, but I need to split up my work and take notes to reduce the numbers of abstracted layers upon which I am working. Take more breaks with confidence I can return.
I suspect this technique can help ease the burdens of interruptions as well, but it does come at a cost in time. For me, the severe crunch time requirements and gained insane last minute skills should still be less necessary for some time. This is likely called being in a startup and getting older and, well, recognizing long-term limitations.
[+] [-] mtsr|4 years ago|reply
I’ve discovered I’m much more in touch with my mental and emotional state and even a five minute break will really relieve some of the pressure you put on your mind and body. Also because it’s just for 25 minutes anyway, it’s much easier to get started again, even with unfun work.
Edit: In case you’re worried this will make things worse, because of the regular interruption, I’ve found it to not be so bad with the exception of some types of debugging. The mind is pretty good at mulling over the problem while you’re taking a break and often I’m more effective afterwards. But the 25/5 isn’t a hard requirement and should be changed depending on preference and type of work.
[+] [-] abnercoimbre|4 years ago|reply
[+] [-] vjdingdong|4 years ago|reply
Nice way to put it.
[+] [-] PragmaticPulp|4 years ago|reply
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.
[+] [-] hinkley|4 years ago|reply
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.
[+] [-] rendall|4 years ago|reply
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
[+] [-] philipswood|4 years ago|reply
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.
[+] [-] MattGaiser|4 years ago|reply
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.
[+] [-] tharkun__|4 years ago|reply
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!
[+] [-] snarf21|4 years ago|reply
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.
[+] [-] comeonseriously|4 years ago|reply
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.
[+] [-] Dudeman112|4 years ago|reply
Agreed. Interruptions aren't nearly as annoying when my immediate reply is "waaait, let me write down some stuff"
[+] [-] dkarl|4 years ago|reply
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.
[+] [-] randomdata|4 years ago|reply
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.
[+] [-] alasdair_|4 years ago|reply
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.
[+] [-] thrower123|4 years ago|reply
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.
[+] [-] xwdv|4 years ago|reply
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.
[+] [-] wisty|4 years ago|reply
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.
[+] [-] lmilcin|4 years ago|reply
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.
[+] [-] Zababa|4 years ago|reply
That's already too late though. At this point I've already lost what I was doing.
[+] [-] lordnacho|4 years ago|reply
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.
[+] [-] JoeAltmaier|4 years ago|reply
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.
[+] [-] vjdingdong|4 years ago|reply
[+] [-] aroundtown|4 years ago|reply
1. Stop being passive aggressive about being interrupted.
2. Take notes.
Dealing with [1]: it is ok, to interrupt some one who starts talking to you, tell them "Hang on", "Just a minute", "Come back in an hour". You have to put your foot down if you are working, even with bosses.
Note taking[2]: early in my career I kept too much information in my head, including debugging. Life is so much better with notes. Nowadays, I work problems out on the paper and not in my head. It's harder to start doing, but once you start you have a paper trail of where you have been and where you are going. Sometimes, you do need to drop everything and go be part of the action. When that happens, notes will get you back where you were quickly.
[+] [-] mmarq|4 years ago|reply
In my opinion this is more common to software development only because software developers, at laest in Europe, do not have the same social recognition as other professionals. An undisciplined PM/PO interrupting everybody to get estimates to update their GANTT chart will be as disruptive in an operating theater or in a legal office as they are in a software development team. Society just decided to not allow randos (as in people with no medical training) in operating theaters while welcoming them (as in people with no development training) in software development teams. Worse than that, these randos often have more power than the professionals doing the work. Surgeons would be complaining and people would be dying, if scrum-certified noisy "servant-leader" PMs were allowed to decide how to carry out operations.
[+] [-] SamBam|4 years ago|reply
"Why can't I write anything down?"
"Because when I'm seven to ten levels deep in a stack of issues, I never write anything down, I need to keep it all in my head."
"But why?"
"Well... I have a whole mental model constructed. I couldn't possibly write it all down."
"But it seriously wouldn't help you to keep some notes while you work? And perhaps add to the skimpy comments in the codebase while you're doing it?"
"I seriously don't see how that would help."
"You literally just said you've written down the code '8xZ204330Kd' and now you have no idea what it was for. Did you imagine you'd be guaranteed to remember it between writing it down and finally solving the bug? Why didn't you at least write some context about what that string was?"
Seriously, just like most kids somewhere between the ages of four and ten goes from "I know I will remember this!" to "I should write this down so I don't forget," programmers could stand to recognize that sometimes taking some notes can help clear their brain when they're too many levels deep in a stack.
[+] [-] Popegaf|4 years ago|reply
This study claims it takes >20 minutes to get back on track: https://www.ics.uci.edu/~gmark/chi08-mark.pdf The effects of notes weren't quantified, but if you have a study on that, I'd be happy to read it.
[+] [-] varjag|4 years ago|reply
[+] [-] Doxin|4 years ago|reply
I do take notes, but it's almost invariably simple stuff like todo items or row IDs I'll need for a lookup.
[+] [-] werber|4 years ago|reply
[+] [-] wruza|4 years ago|reply
I wore these shoes, but one case was special. I was being young, debugging some live show-stopping issues at the client side (the sales department of a plastics factory, a part of a lingered project) when their production manager who I didn’t even know approached and asked in a very demanding tone when the entire project will be done. I distracted and politely redirected them to our PM only to hear a tirade about me doing nothing for months, despite the fact that all the work was thrown on me only recently, after our low-skilled part of the office managed to create enough mess. I politely explained that (omitting the “mess” part) and repeated what I’ve said before, again to no avail. And then my ego decided that it is reasonable to elevate my tone a little and ask them to please not interrupt me at this part of work, because it doesn’t make it easier. God, that hit him unexpectedly hard. Management is never ready for that sort of a dialogue, as I learned later. He left in rage and never greeted me again. (To not look too grumpy, I must say that everyone else, including some high-profile nose-up positions there, sort of adored me for solving their needs at least partially after a long time and for being not yet another silent display-peering guy.)
Wasn’t long before the story was relayed to our PM. I was criticized and expected to apologize but I refused because morally I didn’t feel guilty and to that moment I understood that this project was unlikely to succeed anyway. Few days later I just took the costs of my time and a fellow developer’s at my own expense and left this project completely. It was worth it.
No moral here, but another example that they don’t really understand the difference between a grinder operator and a developer. Also, I may play sir-vs-peasant games with management, but I still don’t get it as a human and will bite back if they play too much. Nothing is worth losing your dignity, unless you’re seriously leveraged. (And in my experience 99% of the client employees never exploited it anyway for personal attacks or sort of that)
[+] [-] ebiester|4 years ago|reply
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.
[+] [-] camhart|4 years ago|reply
Getting hit, falling off, and climbing back on the bike takes a lot of effort, and you have to rebuild your momentum each time it happens. The more times you're knocked off in a day, the more tired you get of climbing back on.
Rebuilding the momentum when programming can take 30 minutes or so. Then you just get whacked with another stick.
[+] [-] ntrz|4 years ago|reply
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.
[+] [-] 1-6|4 years ago|reply
[+] [-] igitur|4 years ago|reply
But for some reason, being interrupted then didn't cause nearly as much damage to my mental house of cards as they do now, where my day job involves translating messy actuarial spreadsheets to code.
I can't put my finger on it. Both tasks were complex. Maybe the fact that actuarial valuations (like most financial roles) are based on spreadsheets and you have a visual model right in front of you, or accessible within a few clicks. I think that relieves some pressure on the mental model.
Programming, on the other side, even with all the IDE tools like a watch list and call stack, seems to require a larger mental stack, given the same complexity in another field.
Side note: work from home has been a dream come true in terms of the disappeance of interruptions. But I do miss the coffee breaks with colleagues (or what others would call water cooler conversations).
[+] [-] hboon|4 years ago|reply
---
And I added this part later, just to frame the question in case it suggests that I think notes are useless here:
I have been writing and keeping notes of my work for more than a decade, mostly writing them as I go.
[+] [-] evilotto|4 years ago|reply
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.
[+] [-] rreyes1979|4 years ago|reply
[+] [-] lamontcg|4 years ago|reply
This is the most annoying question in the world.
I usually want to respond "probably sometime before the heat death of the Universe, but honestly that could slip".
Until I write the fix I have no idea that the direction I'm taking will actually work. Very often I discover some $SADNESS while trying to actually do the fix. Some test may blow up in some way I never expected (often on some platform that I'm not actively testing until I run it through CI because I don't have an AIX virt on my laptop). That could derail me for a week or two.
Then there's CI itself which breaks quite often due to how complicated it needs to be (we have to support AIX builds and things like that). I can't give you an estimate on that because I don't know how that is going to fail or how long it'll take to fix it, but if I tell you we can fix it next week that's exactly the time CI gets broken in some way that'll take 2 weeks (often for a different team that I don't have any control over) to sort out all the mess.
The realistic estimate is often closer to 4 weeks for something that might seem like it'll only take a few days at the start. And it doesn't matter how vitally important it is to some customer. I'll try to get it out in a few days / next week, but it might slip for a month due to the unknown-unknowns and breakage outside of my direct control.
[+] [-] kokey|4 years ago|reply
[+] [-] dekhn|4 years ago|reply
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.