How to explain to a layperson why a developer should not be interrupted? (2011)

What has worked was showing her the bill for a monthly office lease. I said I cannot do this any longer so I rented my own office outside of home. First she was very angry that I spent money like that "because you can work from home!", but I said that I can't because she doesn't respect I can't be interrupted. She promised that she will try not to do that if I cancel it. I did cancel (although I lost the deposit), but she stopped doing this. We agreed that I cannot be interrupted between 9 to 5 except lunch time.

Classic example when money talks :)

One answer on the actual post that I found interesting was the analogy to falling asleep. For most people, that takes X minutes. Let's pretend that is 10. It seems pretty relatable to say that if I am falling asleep and you engage me with questions about something that this timer resets. It will now take me X+ minutes to fall asleep. Everyone has been interrupted when trying to fall asleep so I think at the least it would provide empathy even if they can never fully "get it" as to why it takes 10 minutes to get into the zone.

I think the other thing that people could understand is that part of developing involves moving the code and systems you are working on into a complete and active model in your brain. This is why the loading time is required so you can then leverage this model to plan and make changes.

Going to a coffee shop and putting headphones can be more productive

I don't remember any of it afterward, no idea what I said, but apparently it's good enough and coherent to get people off my back. "Yes, tea please."

Dr. Stephanie: "So what did you do today?"

Leonard: "Well, I'm a physicist, so... I thought about stuff."

Dr. S: "Is that all?"

L: "I wrote some of it down."

Working from home and having three kids between 6 and 10 months, the onus is on my to manage my expectations and my spouses expectations for when I'm going to be working, what work is interruptible, and what's most important to me. Given that my priorities go: family, friends (spouse included here), work, volunteering, that means that if the family isn't functioning well, that's where my attention goes until we're in a good place.

I've seen a lot of people either neglect their personal priority list or simply not have one, and then wonder why their life is falling apart around them, or they from time to time feel void or uninspired.

All this to say, productivity for productivity's sake is the behavior of cancer. If I have an un-productive day from a work perspective, it's usually because I was tending to higher priorities in my life, and thus it is hardly the end of the world, and I make a plan for getting things back on an even keel there so tomorrow or the next day I will have a more productive day, and make sure to communicate this to my supervisor in my next 1:1.

Skype, steam and slack do not flash, beep or pop up when I get messages, they just put a discreet number on the taskbar. I've learned to ignore that number until I'm ready.

As a result, I'm always online on my chat programs but my responses can take anywhere between 30 seconds and 4 hours depending on what I'm doing. If it was really that important, people would walk over to my desk. That only happens about once a week.

I use it sparingly to good results.

You're not a good PM if you've done this. The alternative from a good manager:

"Hello... I need you to input your time on Kimble"

What about my Skype status "async mode on" don't they understand?

OP doesn't dismiss all accountants, it is an example picked at random. If OP only said "that funny guy", would you say "as if guys didn't need to concentrate!"?

This comic is the perfect explanation of interrupting the thought process.

It also lets me just ignore people who interrupt me during one with a quick "I'm busy, I'll be with you in (X<25)" or "Ask me in (X<25)". Sometimes the response they get during that break-time convo is that I'll get back to them even later, I need to think about it.

But it's surprising how quickly people will pick up that if they bother you on the hour or half past, you'll respond and othertimes you'll blow them off.

For now I have:

- write down everything: tasks, discussions & conclusions, etc (you said "keep a backlog of tasks")

- when interrupted while coding, insert a //TODO with a few words that will help rebuild context on resuming, maybe with a statement that does not compile to quickly get back there (if the interruption leads you to navigate away from that file/editor)

- if a few seconds are not enough, explain "I need a few minutes to write down stuff and I'll get back to you". This is always accepted without issue. Although it's difficult when the person politely waits behind you :)

- if you figure you really cannot be interrupted on the spot, make great effort to explain this as gently as possible, and offer to get back to them later: again, always accepted by peers (in my experience). If the interaction stays below a few seconds, AND I stayed agreeable & polite, I have little problem getting back in the flow. When I reply too curtly or let the slightest trace of anger show, then I fail to get back in, because my thoughts are polluted with remorse & guilt.

- over time, learn to identify in advance when you are about to enter a "really-really-no-interrupt zone", and then wear audio gear or something to signal this. And don't do it too often.

- I also noticed "recursive tasks" are a challenge. You suggest to avoid them when they are just ideas that help the previous task, but what if they are impediments that MUST be fixed? (Google "malcolm hal fixing light bulb" for hilarious illustration). For this I only have "write down everything", but it gets frustrating with the feeling I'm getting slow due to constant swapping, and could be faster if I could count on short term memory alone (and no interruptions...).

Anwyay... would love to read more about "embrace interruptions" & "optimize for re-starting".

Seeds of truth often grow cargo cults of self importance around them.

It is a known inside joke among Brazilian programmers to call ourselves "garoto de programa", which means "program's boy" - laymen therefore think we are referring to male prostitution.

One is a value function, which is best described by Tilly-Odlyzko: v = n * log(n)

(Tilly would be @tilly on HN, BTW.)

The "log(n)" factor means that as you add additional elements, the positive benefit decreases as n increases.

The other is a cost function, which is probabalistic between any two nodes. It's actually closer to the old (and incaccurate) Metcalfe rule: c = k * n^2

Where k is some cost constant. The larger k, the smaller the productive size of the network, the smaller k, the larger the network can grow. Hence: network size is constrained by the cost constant.

What you're observing is the cost constant of team size as a factor of interruptions. Since any member might interrupt you at any time, and those interruptions all have roughly equal cost, but the positive contribution a team member can make is limited by their ability to provide useful inputs, and the k factor is relatively large, few technical teams seem to scale much beyond about 6-12 members.

(Larger teams are almost always subdivided into smaller effective working groups.)

The manager's priority should be organisational productivity; he's managing a team of people for the purpose of contributing to the greater organisation, not for the personal seclusion and self-fulfillment of each team member. Those are, sadly, secondary or tertiary goals.

If other people in the organisation can't be productive because he's blocking them from validly interrupting one of his reports then he needs to change.

"The needs of the many", and all that stuff. Sometimes the most productive days are those spent helping other people to be productive.

The problem is (my theory) that programming work looks like any other work/play done in front of a computer: you're sitting there, typing and clicking, looking at some windows with text and menus and stuff. Some people seem unable to grasp that it's breaking flow to interrupt.

I have a friend, let's call him "Jeff", who cannot seem to understand that he can't talk to me when I'm using the computer to work. He was my roommate for awhile in a small place where he had to pass my workstation to get to the kitchen. I got in the habit of just closing the laptop when I heard him coming, because he was going to interrupt me and that was as close as I could get to saving my mental state while I waited for him to go away again. I tried to explain it to him several times. I got a t-shirt that said "Don't talk to me when I'm not listening". Still, he kept interrupting me while I'm trying to work.

Finally, one morning he comes in to where I am, sits down with his bowl of cereal, and starts playing some earworm cat song on his phone. I lost it and yelled at him, and now he thinks I'm the jerk. I moved out.

Some people just don't get it, it's a problem, and the OP was just asking for help dealing with that.

I think a better question is why, of all the kinds of "flow"-based knowledge work, has programming become so strongly associated with the idea that interruptability and collaboration should take precedence over sitting down and working through the problem?