Programmers, teach non-geeks the true cost of interruptions (2014)

https://daedtech.com/programmers-teach-non-geeks-the-true-cost-of-interruptions/

by davikrr • 5 years ago

293 235 5 years ago

daedtech.com

satya71• 5 years ago

I’m going to use this.

1-6• 5 years ago

Actually, HN is more of a distraction to me than random people popping by.

lkbm• 5 years ago

I choose when to open HN. It might be more often than is ideal, but it's not mid-thought.

bell-cot• 5 years ago

HN has a few features which might help:

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

paxys• 5 years ago

The fact that you are able to pick your own time to get distracted makes all the difference. I read HN when I'm blocked on something, waiting on a compile, on the loo, on a coffee break. The costs of context switching in these cases is very low compared to when I'm deep into debugging or writing code.

pcbro141• 5 years ago

I use SelfControl on Mac to block sites for deep work: https://selfcontrolapp.com

notatoad• 5 years ago

HN feels like a distraction, but i find that when i don't have some sort of distraction i'm less productive. if i'm deep into solving some problem i don't have any motivation to check HN or other time wasters.

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

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

jaggederest• 5 years ago

You can use dual n-back as a systematized way to do this. Get them to do it for a bit uninterrupted, and then use a random beep generator to generate interruptions. Most people will score drastically lower with random interruptions.

werber3• 5 years ago

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

thaumasiotes• 5 years ago

I had a discussion with other people on my team recently and realized I was the only extroverted person on the team.
I wish respecting communication preferences was more respected. Asynchronous and non intrusive messaging seems so much better for the majority of my coworkers

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

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

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

werber3• 5 years ago

For me, I have colleagues that have made it clear they prefer email to a slack or call. I don’t care either way so I think it’s on the person who doesn’t have a preference. It makes professional relationships better to do those Tiny things and not expect immediate communication.

spideymans• 5 years ago

I’m one of the worst developers on the team but being able to context switch is unfairly rewarded and gives business people the impression I’m way more competent than I am

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

werber3• 5 years ago

I work with developers who are better than me that make less money. I’m ok with being aggressive In negotiations and it bothers me that people who provide more value are taken advantage of. I’m getting to the point in my career where I don’t want to do anything more technical and I love meetings and communicating with people and trying to figure out how to go into a po/pm or developer advocate role

harrisonjackson• 5 years ago

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

blockmeifyoucan• 5 years ago

This is brilliant!

austinjp• 5 years ago

Okay, I'm stealing this. I'm going to prepare a broken sudoku and ask my partner/colleague/whoever to debug it, then interrupt them to ask when they'll be finished :)

calderwoodra• 5 years ago

I like to explain it like you're building Ikea furniture, but every time you're interrupted, you have to start from the beginning.

peakaboo• 5 years ago

This article is why I'm not a programmer anymore. It's just impossible to be a programmer in the office while also trying to be social. I don't want to sit in an office surrounded by other people and get frustrated because it's not quiet or calm. I rather talk to people and have fun.

For me, programming only works when working from home and I'm alone.

monkey_monkey• 5 years ago

This is my favorite cartoon about the cost of interrupting developers.

https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt...

PragmaticPulp• 5 years ago

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.

MattGaiser8• 5 years ago

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.

ViViDboarder• 5 years ago

I think we’re one of the few that requires nearly entirely deep work yet also often work in an environment that isn’t conducive to it.

Many other professionals that do this kind of work have private offices. Painters, architects, lawyers, etc. Meanwhile we cram ourselves together, surround ourselves with physical and digital distractions, and expect near immediately responsiveness from peers.

I’m glad to have my team working from home now.

uxp1002• 5 years ago

I guess I consider it part of my Job to be there and answer questions, assist other developers, etc.

(Also please do not slack me when you're sitting right next to me, it's like, more disruptive and annoying than just talking to me. But mostly just use Email, please.)

gopalv• 5 years ago

We seem to be the only profession that cares then.

Our profession seems to be one where it is not obvious to others that we're in a flow or in deep working mode, since there is no visible difference between work-isolation mode, browsing the internet for random programming or browsing for fun, from four feet away.

My uncle is a neuro plastic surgeon, he is prone to disruptions in more ways than I am (if I talk to him while he's cooking about a decision he needs to make, he loses track of the recipe), but I assume he is never disrupted by someone asking something unrelated while he's working.

My partner too is clearly in an uninterruptible state when practicing the piano or painting something, even writing skeleton work is done on a book instead of a computer.

But I get why it is hard to notice a programmer in isolation over other professions of deep work - I don't put on a lab coat or scrubs , to communicate that clearly to others in a familiar "at work" situation.

I'm trying with a "at work" desk light, but I'm still not consistent enough with it & this is very much forced.

GuB-42• 5 years ago

I think development is a profession where it is not obvious when you are interruptible. In fact one of the best manager I had outright ask me "are you interruptible?", because she doesn't know if I am deep into a complex problem or just cleaning up stuff or waiting for my code to compile.

Manual labor also require focus, but when you are occupied tends to be obvious. If you are under a car, messing around with a tool in your hand, everyone knows it is not the best time to interrupt you. In safety-critical jobs, like in the case of pilots, there are mandatory protocols that explicitly forbit interruptions during critical moments.

People usually know enough not to barge in when the manager is having an talk with his higher up or when the salesman is negotiating with a customer unless it really is urgent.

But programmers just stare at the screen all day, and most of the work happens in their head, so how do you know if they can be interrupted or not. Bad managers assume "always", because themselves only stare at the screen during their "off" time, so they assume programmers are always "off".

wheelinsupial• 5 years ago

Not really. It’s probably more likely that developers are the ones who are able to create blogs and voice their opinions more easily on the internet.

My step-dad works in logistics and likes to quote “a single interruption takes a person 15 minutes to get refocused”. He blocks specific hours for his field staff to stay away from the office staff, so they can process the critical daily work without interruptions.

Google searching seems to say it’s closer to 23 minutes these days. Industrial engineers seem to have studied interruptions on work in the late 90’s and maybe even earlier.

As a further anecdote, when I worked in manufacturing I would end up having to come in on the weekends to do cognitively demanding work. Designing tooling, creating and optimizing CNC programs, and checking parts using coordinate measuring machines while getting interrupted by the quoting department to “just give me a quick estimate what you think this part will cost for us to make for the customer”, or production saying “we need you to quickly trouble shoot the defective parts we are producing because otherwise we will be late and get a fine for missing the shipping date” results in costly errors that can’t be fixed by recompiling code.

Pressure, interruptions, and bad management are not unique to software development. And yes, other professions do care about production high quality work.

leephillips3• 5 years ago

I think the issue is that, in a typical workplace that employs some programmers, they are in fact the only ones who will be doing deep work that requires sustained focus. The typical office does not contain, in addition to programmers, poets, painters, and mathematicians. If it did, those people would understand. Instead, aside from the programmers, you have mostly salesdroids and managers, who have absolutely no concept, because they have never done any real work.

rhyswallace• 5 years ago

Instead, aside from the programmers, you have mostly salesdroids and managers, who have absolutely no concept, because they have never done any real work.

And this helps the argument not one bit. I'm sure it's very comforting to condescendingly look down on other professions, but you're doing nothing but further proving the point in the comment above.

stingraycharles• 5 years ago

I agreed with you until your last sentence. I think the goal we want to achieve here is to be more understanding of what each other’s work involves; I absolutely don’t envy the manager who is constantly being interrupted, or the sales person who is doing some next level persuasion and working months to get this customer to sign that contract.

If you’re dismissive of their work, how can you ever expect them to be understanding of yours?

testudovictoria• 5 years ago

Instead, aside from the programmers, you have mostly salesdroids and managers, who have absolutely no concept, because they have never done any real work.

Wow. This is exactly what the top comment was talking about with the opening sentence. These people may not need deep concentration to be successful, but that doesn't mean they don't do real work.

haswell4• 5 years ago

Instead, aside from the programmers, you have mostly salesdroids and managers, who have absolutely no concept, because they have never done any real work.

Honest question - how many years of professional experience do you have?

Have you ever been on a team that didn’t have enough devs and needed to grow? Have you been on a team that addressed that by hiring more devs? What about funding for software and other tools to do your job?

This obviously varies from company to company, but often, especially at companies that promote from within, the managers around you very likely started doing exactly what you’re doing.

Managers also have their own kinds of deep work, like careful and detailed proposals to increase funding so your team can grow, just to name one.

If you expect the people you work with / who manage you to understand you and the challenges posed by distractions, taking some time yourself to truly understand them is just as important.

I should add a disclaimer: I’m not a people manager.

juliansimioni• 5 years ago

because they have never done any real work

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.

lordnacho7• 5 years ago

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.

camjohnson26• 5 years ago

I’ve noticed that I have a lot less trouble with interruptions deeper in my career than starting out because those mental models are refined and intuitive now. The example presented in the article where the programmer has a carefully constructed recreation of a null reference bug could probably be broken up into a series of steps that don’t require keeping as many variables in your head.

I agree that interruptions are annoying but they’re unavoidable, and we can develop strategies to make them less impactful. Passive aggressively trying to make somebody else feel your pain is guaranteed not to work and will just make them resentful and make you look petty.

isbvhodnvemrwvn2• 5 years ago

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

Have you ever worked in sales or as a manager?

jolmg5• 5 years ago

Nobody else constructs models in their minds that are almost purely mechanical and specific to a small problem. Every model the sales guy or manager uses has very few knobs to twist

What about mechanical engineers, electronic engineers, etc.?

caconym_• 5 years ago

Nobody else

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.

inglor_cz• 5 years ago

I basically switched from programming to writing (= for humans) and the need for concentration is rather similar. The model of the text-to-be is not as mechanic, but consists of so many threads that need to be woven together that you can easily lose track.

haliskerbas• 5 years ago

Nobody else constructs models in their minds that are almost purely mechanical and specific to a small problem. Every model the sales guy or manager uses has very few knobs to twist and are mostly intuitive models for which everyone has a template and practices use of every day: emotions, status, hierarchy, urgency, etc.

When we get to this sort of absolute perspective. I like to think “either everyone before me is/was an idiot, or maybe I’m missing an unknown unknown”

I’m sure other technical fields of non programming require holding more than one thought in the head at once.

Perhaps anyone constructing anything that depends on an intricate set of rules may experience the same thing.

haswell4• 5 years ago

Every model the sales guy or manager uses has very few knobs to twist and are mostly intuitive models for which everyone has a template and practices use of every day: emotions, status, hierarchy, urgency, etc.

The fundamental issue I have with this argument is that it assumes the role of “sales guy” and “manager” are always the same.

I’ve spent quite a few years in the Enterprise software space, and I can assure you that the knobs to twist on a massive deal are numerous, highly complex, and would paralyze some devs in their tracks.

It’s easy to trivialize these roles because they often appear to be full of “busy work”. If you have the opportunity, go spend some time with the sales team! Listen in on some calls. Get involved in a hiring round. Participate in a marketing meeting about establishing positioning for your next product/feature.

thrower123• 5 years ago

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.

MattGaiser8• 5 years ago

I learned to hide at a past company. I would book small meeting rooms for long periods and work in there. Or go work in the cafe. Even that is superior as while there are lots of small distractions, nobody specifically wants your attention. In the summer I would work outside under a tree.

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

JoeAltmaier• 5 years ago

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.

Toutouxc• 5 years ago

People are different. Back at the office my boss would be distracted every few minutes by someone else on the team and still be productive. I, on the other hand, cannot really concentrate if my GF is in the same room, silent, browsing the web on her computer.

ngc2482• 5 years ago

Exactly ...multi-tasking only works for shallow/low impact work. The expectation of multi-tasking for all forms of work is simply ludicrous.

Dudeman112• 5 years ago

Recovering quickly from interruptions is a skill that can be developed and learned.

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

comeonseriously• 5 years ago

Instead, communicate like peers

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.

jbluepolarbear3• 5 years ago

I got so tired of defending my time at a previous job that I just started saying “Is that what our producers needs me to do?” Shuts them up every time. Generally, the people that interrupted me were people that had no authority to ask me to do anything: marketers, ad agents, sales.

phkahler• 5 years ago

> If you ask them if that will work, they'll tell you they need the answer immediately most of the time.

The question "Will that work" is optional. You need to be polite when dismissing someone, but the goal here is to offer 2 messages "I'm busy now" and "I'll get to you as soon as this busyness passes" The discussion needs to end as quickly as possible so as to not lose your focus, but also without making them angry. Asking questions in that case is probably a bad idea.

pc862• 5 years ago

You don't have the context of the entire business, and sometimes they have an actual need to interrupt you, and you need to stop what you're doing.

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

jbluepolarbear3• 5 years ago

How about you respect my time on the job and I’ll respect yours. A distraction cost me time needed to do my job. If someone doesn’t respect my time, I let their managers know.

randomdata• 5 years ago

Any deep work suffers from interruptions, and programming isn't the only type of work that has significant mental context.

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.

xwdv• 5 years ago

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.

lowercased2• 5 years ago

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.

lmilcin• 5 years ago

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.

hinkley2• 5 years ago

I think I'd mostly be okay going back to in-office work if I had an office door, which of course I won't.

Zababa2• 5 years ago

Instead, communicate like peers: "Sorry, I'm in the middle of something important. Can you come back at lunch time?"

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

SamBam2• 5 years ago

I feel like if your mental model of the program is so fragile that even saying "Sorry, I'm in the middle of something important" breaks it, then it may be worth working out how to ground more of it.

When I find myself six or seven levels deep in a stack, I often realize I need to open up a new coding window and write myself some quick notes.

tharkun__• 5 years ago

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!

snarf212• 5 years ago

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.

MattGaiser8• 5 years ago

At least on the teams I have been on, we didn't physically interrupt people. We sent Slack and Teams messages for all of that stuff about merges and staging.

ElFitz• 5 years ago

We expect co-workers to get back to us right away so that WE are no longer blocked.

Perhaps you do, but I and some of the people I’ve had the pleasure to work with do not.

Personally, I’ve almost always worked asynchronously.

If I have a question, I send it on the proper Slack channel and either keep going on what I was doing if isn’t blocking, or do something else when it is. Tasks are usually large enough for that.

Regarding Slack interruptions, all my notifications aside from a handful of phone numbers are disabled.

Things rarely are urgent, and can usually wait an hour or even until the next break.

dkarl• 5 years ago

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.

hinkley2• 5 years ago

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.

dennisgorelik• 5 years ago

We don't want to debate the relative importance of these two tasks. If we do then the interrupter wins

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

The interrupter will not necessarily win from your loss.

alasdair_• 5 years ago

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.

wisty• 5 years ago

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.

naavis• 5 years ago

I don't know what kind of places you have worked in, but I have rarely bumped into disrespectful jerks as coworkers in my jobs. If you work with many jerks, maybe there is an opportunity to improve the recruitment process there.

pjerem• 5 years ago

You should find a better working environment.

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.

rendall2• 5 years ago

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

dpritchett2• 5 years ago

Firming up your tests, logging, observability, and debugging practices really does help here.

The only time I enter a desperate fugue state juggling too many disparate code modules in my head is when the system is a poorly factored enterprise monolith.

Those aren’t uncommon but I reflexively avoid jobs that make those the majority of my work.

philipswood• 5 years ago

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.

jimnotgym2• 5 years ago

As an accountant and developer I can tell you that many accounting tasks are very similar to coding. I have spent years having to prepare management accounts in an open office and it is exhausting trying to maintain the focus required. And yes people interrupt you just like any other day because their roles require timely responses.

I have an office now and it helps a bit, but normally I hide at home and turn off email and put Teams into dnd for these tasks

sabbour• 5 years ago

Thank you, you sound like an adult.

ngc2482• 5 years ago

There are more like different classes of work,

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.

vjdingdong5• 5 years ago

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.

Abhinav2000• 5 years ago

Great advice

bentcorner• 5 years ago

I probably interrupt myself more than anyone else.

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

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

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

Think of it like frequently committing in git.

sagivo• 5 years ago

This also applies to remote interruptions like slack and email messages. The difference is you can control these interactions better by hitting the "do not disturb" mode. Just make sure people understand why you're not responding right away.

dekhn• 5 years ago

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.

ntrz• 5 years ago

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.

brutal_chaos_• 5 years ago

Probably in person it would be a bit different. I have a feeling this is a quickly whipped up example. Contrived and silly, sure, but the point is made.

mxfh• 5 years ago

With the added danger of just handing an easy win to an oldschool accountant type, who surely knows how to do trivial carry addition and can remember 4 digits at time.

Spooky23• 5 years ago

If some dev decided to teach me these lessons, I would be tempted to go out of my way to bug the dude as much as possible.

evilotto• 5 years ago

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.

xaedes• 5 years ago

That sounds like this line of thinking:

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

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

itqwertz• 5 years ago

People are generally selfish and focused on their own goals. Everyone has their stress and tries to relieve it either by working machines or working people.

Due to the unpredictable hours of salary positions, programmers should be defensive and stand up for themselves more often. Being walked all over is typically a sign to find a better work culture elsewhere.

This article is a fantasy situation that would never play out in the real world. PMs don’t have time to mess around with a stupid mental exercise, nor would the lesson change their reality.

“Just get it done”

jrockway• 5 years ago

I think pg explains this better: http://www.paulgraham.com/makersschedule.html

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

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

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

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

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

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

clipradiowallet• 5 years ago

Are managers interrupting your work and making it hard to concentrate? Try working at home with young twin children. Great article though.

hahamrfunnyguy• 5 years ago

should be: Programmers, Teach Non-Geeks the True Cost of Interruptions (2014)

ebiester• 5 years ago

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.

charles_f• 5 years ago

Related to this, I love this comic, because it so much exactly what happens when you get interrupteurs https://pics.onsizzle.com/focus-poof-hey-do-you-have-isec-ne...

teddyh• 5 years ago

Whenever this comes up, I usually link to this:

Don't Wake Up the Programmer!

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

Wistar• 5 years ago

At Microsoft, it was easy to see which teams were in crunch mode: the closed doors had "email only" signs on them.

eggy6• 5 years ago

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

lostphilosopher• 5 years ago

FWIW I think you could write an interesting book.

rendall2• 5 years ago

I would read the hell out of that book. Or blog

eggy6• 5 years ago

Thank you. I've been torn about a private vs. public life. I have always enjoyed the immediacy of the moment in life having lost friends while still in my teens. I am very tech savvy, and I love GoPros and smartphones for what they are, but I rarely film or photo myself. I do journal, so perhaps when I stop playing around, I'll try writing a book for my children.

thayne• 5 years ago

Yes, I think it applies to any technical work, not just coding.

dgeiser13• 5 years ago

I think it would be unfair to limit it to technical work. I think people who excel in any "think heavy" work would prefer not to be interrupted while they think. Not all "think heavy" work is technical.

dagurp• 5 years ago

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.

easygenes• 5 years ago

Yup, and you can be very grateful for their decisions in that period as well. The most hairy flight I’ve been on involved trying to land in Kampala in the midst of a terrible thunderstorm. Turbulence like I’d never felt before (after hundreds of flights). A hushed stillness in the cabin, people grabbing their loved ones. From the amount of time you’ve been descending and the feeling of the flight you know you’re on final approach. Then wham, it feels like the plane fell out of the sky, and it’s still black out the window. A moment more calm. You look around; you thought what you felt before was the worst turbulence ever but now you’re surprised the plane is in one piece still. Then the pilot aborts approach at full throttle and you’re pushed back in your seat with unusual force.

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

sokoloff• 5 years ago

That’s the so-called “sterile cockpit rule” and it exists, is generally for ground operations and flight ops (other than level cruise) at/below 10K feet, which isn’t 30 minutes before landing, but rather a third to half of that, typically.

vjdingdong5• 5 years ago

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.

eggy6• 5 years ago

I do love Haskell too, but I am only a dilettante. I played with Euterpea[1], and I like it's mathematical bent like J and APL. I could probably get more practical work done with Haskell, but I like the way J and APL make me iterate on a short piece of code until it is a diamond. I should look at Haskell again...

I sometimes write J by hand on paper.

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

H8crilA2• 5 years ago

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.

eggy6• 5 years ago

First, solve the problem at hand. Second, then make your grievances. Always take the high road, and debate later, unless it's a life or death situation. Principles before personalities.

nathias• 5 years ago

I really don't get this exaggeration about interruptions ...

1ris• 5 years ago

Me neither. I actually like to have some random human-to-human interaction from time to time. If I don't, I will start to feel lonely. Like actually sad.

mikesabbagh• 5 years ago

I agree with the destructiveness of meetings and interruptions. Many times the only productive work takes place after 5pm. I find creating protected time is a good solution that helps, but you cant have this every day when you work for an enterprise.

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

nkingsy• 5 years ago

I Don’t get it.

I certainly get grumpy when I get knocked out of flow state, but it’s more about having to cut my direct feed to the universe than any measurable loss of productivity.

Maybe I’m lucky to be able to get into flow quickly, or maybe people are misrepresenting the cost. Even 10 minutes of lost context/flow ramp seems like more than I’d estimate for the cost of one distraction.

ryukafalz• 5 years ago

I think you're lucky to be able to get into flow that quickly. I certainly can't.

igitur• 5 years ago

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

kokey• 5 years ago

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.

jpindar• 5 years ago

"Papers, Please" but for programming.

aroundtown• 5 years ago

You know what helps:

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.

aynsof• 5 years ago

I agree on note taking.

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

avmich2• 5 years ago

Nah, you don't understand. Even saying "get lost, I'm thinking" requires focus of Feynman, so by that time many already suffered. Keeping notes - good luck with that, if you thinking about something sufficiently vague, as in like 90+% cases happens to many - programmers. So stopping being passive aggressive is tantamount to cleverly preventing those distractions from happening in the first place - see e.g. Graham's piece with different time of work advice. And in those rare cases when you do need to drop everything - well, that'd better happen at most once a year, or you'll lose more than a few hours each time.

arthurjj• 5 years ago

Note taking is underrated especially because when you're junior you don't get interrupted and you can keep everything in your head. People think "If I could just not get interrupted" I wouldn't need to take notes.

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

Besides basic note taking I suggest two additions to it.

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

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

bob1029• 5 years ago

Taking notes is the superweapon for mitigating distractions in my experience. It doesnt eliminate the immediate impact, but it allows you to get back to a productive state so much more quickly.

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

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

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

jpeloquin• 5 years ago

If I'm interrupted while I have a lot of unstructured thoughts floating in short-term memory, I try to ask for a "couple seconds" and scribble down some key words on a post-it before switching attention. Looking at the post-it later brings most everything back.

beaugunderson• 5 years ago

I do this so often just by adding temporary comments in the code and files that I'm debugging. If I get interrupted I can just `git diff` and see the entire chain of files that got me where I was. When the problem is solved, I just `git checkout -p` and discard any of the temporary comments while keeping whatever the fix was (or inverting this, with `git add -p` and then `git checkout`).

SamBam2• 5 years ago

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.

Popegaf• 5 years ago

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.

varjag2• 5 years ago

A blunt pencil is better than sharp memory.

Doxin• 5 years ago

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.

Vaslo• 5 years ago

This reminds me of the scene in The Shining when Wendy disturbs Jack. I can’t tell you how many times I’ve wanted to do Jack’s reaction when someone interrupts me.

lamontcg3• 5 years ago

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

titzer2• 5 years ago

This is the most annoying question in the world.

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

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

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

lamontcg3• 5 years ago

You can't triage the unknown

rreyes1979• 5 years ago

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.

bigbillheck• 5 years ago

All else being equal, I think that 'being unable to handle interruptions' is grounds for self-improvement, in the same way that 'cannot cook' or 'cannot drive a car' are.

rStar• 5 years ago

i like to remind people that it’s their time they’re paying for it, but my time starts at 4pm and thats when I’ll be exiting the elevator into the parking lot.

cratermoon3• 5 years ago

Do programmers really need to have the skill of "Holding a Program in One's Head"? http://www.paulgraham.com/head.html

guskel• 5 years ago

I wish I could be so lucky to be interrupted for work relevant things and not discussions about Adam Sandler movies or the neighbors dog when I’m clearly focused and typing into my IDE.

hboon• 5 years ago

To those advocating writing (more notes) to help context switching, just a thought — do chess players keep notes during a running game?

---

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.

andrewzah• 5 years ago

I don't find it very valuable personally and I play 3-day correspondence chess.

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

tephra• 5 years ago

FIDE rules bar you from writing down notes. You are only allowed to write down the moves of the game.

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

j4yav• 5 years ago

It is forbidden in tournament play, but I absolutely keep notes for correspondence games that play over the course of multiple days (a chess sprint?) and LiChess even has notes as a built in feature.

kqr• 5 years ago

I agree interruptions are expensive for personal productivity.

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

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

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

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

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

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

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

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

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

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

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

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

tomjuggler• 5 years ago

Love the description of the problem in the article, so familiar.

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

ideamotor3• 5 years ago

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.

abnercoimbre• 5 years ago

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?

pedro2• 5 years ago

My guess would be he felt depleted emotionally and psychologically after spending too much time working.

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

random_kris• 5 years ago

Yeah this happens for me as well. I can feel the high of being productive but now as I gained expirience I also feel the dread of next day being almost like hungover

itronitron• 5 years ago

I find that I have to put myself in a state of deep dissatisfaction in order to develop the motivation to dive in. If I get interrupted before accomplishing anything then I'll remain in a bad mood. And if I think I am going to be interrupted then I won't even start the first dissatisfaction step because I don't want to be stopped halfway. One workaround for that is to define the work in smaller pieces so that interruptions are less likely, but that also takes work.

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

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

ideamotor3• 5 years ago

No it was from being in the zone, which eventually caused me anxiety about doing it. I would spend 10-12 hours getting a major project done, barely taking a break. Wrist issues, back issues, and a kind of agoraphobia afterwards if I was in too long that accumulated with lack of sleep as well.

mtsr• 5 years ago

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.

the_other3• 5 years ago

I used to use an app that had both a timer and a notepad. It was helpful for sketching out pointers to where I’d reached. A quick scan before restarting the next 25min, especially after a meeting or lunch, was very helpful. Being in the same app helped connect it to each session.

smcl• 5 years ago

Yeah good point. I think it's also different since the interruption is on your own terms - you've deliberately given yourself 5 minutes break from some task so that you be more focused over the lifetime of that task. You're (hopefully) not getting other tasks thrown at you which can take up precious mental resources or destroy context you've been slowly building up in your head.

john-tells-all• 5 years ago

Seconded. Pomodoro is wonderful for engineers: it rapidly teaches us to build up a "focus muscle". We start focusing at the beginning of a 25 min cycle, and consciously relax the focus at the end. If I walk around for 5 minutes and do low-impact things like dishes/laundry it helps.

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

vjdingdong5• 5 years ago

gained insane last minute skills

Nice way to put it.

tgv• 5 years ago

The first level of interruption rarely bothers me. I can get back to what I was doing almost instantly. The second level, when the interruption gets interrupted, or comes very quickly after the first one, that's the one stresses me and make me slowly forget details of the original task that makes it costly to go back. Not everyone reacts the same, I guess.

cesaref• 5 years ago

It's true that interruptions are a source of significant cost for programmers, but the other side of the coin is that talking through problems and design decisions with other programmers can generate a massive gain in productivity.

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

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

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

camhart• 5 years ago

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.

dave_sullivan• 5 years ago

This is a very good analogy.

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

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

faeyanpiraat• 5 years ago

Some people can fall asleep almost instantly even when there is significant noise around

gego• 5 years ago

...what is described here for programming is the case for most creative work where we weave something into a tight compact whole... also in academic writing, where you build up to the moment of writing by copying all the papers you need into your head... and any disturbance empties the cache and sets you back the 30-40 mins again...

wruza• 5 years ago

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)

PicassoCTs• 5 years ago

Similar experience in automation. When the factory was prone to that behavior or the project we got was already "escalated", we had a 2nd guy working as a "Linebacker" who would stop the whole shenanigans, allowing the first guy to work and concentrate.

mmarq3• 5 years ago

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.

the_other3• 5 years ago

This is one of the things scrum is meant to help fix. In your daily scrum, tell your team you need X hours that day w/out interruptions and explain why. If your Scrum Master doesn’t protect you from interruptions by others, they’re not mastering their Scrum effectively. Ideally knowledge of the codebase would be spread around your team already such that other people can handle the interruptions I think it would be fair not to request this “no interruptions” every day.

mmarq3• 5 years ago

I don't want to get into a debate on the "true scrum", but in my experience non-technical scrum masters/POs/PMs who don't write code (randos in my previous comment) are generally detrimental to the productivity of a development team. Software developers who act as scrum masters and whatnot, while also writing code, are way better.

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

daedalus_f• 5 years ago

I have not worked in software development but I do work in healthcare. At least in my country, management of hospitals has largely been taken away from healthcare professionals and given to career managers whose background is usually administration, HR or finance. They largely display the same irritating traits as you describe and increasingly interfere in clinical decision making while remaining largely unaccountable - unlike everyone else who works in healthcare they have no professional standards body.

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

mmarq3• 5 years ago

That may or may not be a problem. For instance a career manager may be better suited to make strategical decisions than practitioners.

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

vjdingdong5• 5 years ago

That's a pretty disfunctional state of affairs you describe in Health-care. A little bit like what we have in Tech. Where career managers/MBAs/PMPs control execution of projects with various levels of technical complexity - essentially Tech projects where the project succeeds inspite of the powers-that-be.

NewEntryHN• 5 years ago

The problem is that sitting in front of a computer gives no indication of business. You wouldn't interrupt a surgeon during an operation, or a pilot landing a plane, or a crane operator moving some load on a construction site, or a carpenter currently doing woodwork; because you can very visibly see them being focused on their work. Sitting in front of a computer is the default position of the modern office workplace, which makes it a meaningless signal.

novaleaf• 5 years ago

required viewing: https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt...

(circa 2013)

Programmers, teach non-geeks the true cost of interruptions (2014)

Related Stories