19 ms·

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

293 points by davikrr 5y ago

satya71 5y ago
I’m going to use this.
1-6 5y ago
Actually, HN is more of a distraction to me than random people popping by.
- lkbm 5y ago
  I choose when to open HN. It might be more often than is ideal, but it's not mid-thought.
- paxys 5y 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.
- bell-cot 5y ago
  HN has a few features which might help: https://news.ycombinator.com/item?id=814695 https://news.ycombinator.com/item?id=814695
- pcbro141 5y ago
  I use SelfControl on Mac to block sites for deep work: https://selfcontrolapp.com https://selfcontrolapp.com
- notatoad 5y 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 5y 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.
werber 5y 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
- phaemon 5y ago
  Wow maximal wines!
- thaumasiotes 5y 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?
  - werber 5y 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 5y 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.
harrisonjackson 5y 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 5y ago
  This is brilliant!
- austinjp 5y 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 5y 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 5y 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 5y ago
This is my favorite cartoon about the cost of interrupting developers. https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/ https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt...
PragmaticPulp 5y 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.
- MattGaiser 5y 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.
bentcorner 5y 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 5y 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 5y 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 5y 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_ 5y 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 5y 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 5y 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 5y 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 5y 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.
doublejay1999 5y ago
People have jobs where they need to concentrate ? and...people prefer not to be interrupted when concentrating ? oh. my. god. The author looks old enough to know better than to propagate software development as some kind of novelty role in an organisation, and also old enough to know that cultivating the image of the tortured prima dona, who must not be disturbed while creating his masterwork, does a lot more harm to the profession than good. If you need to work without interruption, pull on your big boy pants, take your code and your laptop, and go work somewhere where there are none. If what you are working on is so intricate and volatile, get funding and build your own fucking lab like scientists have been doing for years. Otherwise, you're part of an organisation, on a salary, like everyone else. So play your part. Idiot.
- dang 5y ago
  Could you please not post in the flamewar style to HN, cross into personal attack, or call names in arguments here? The site guidelines ask you not to do any of that. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and sticking to the rules when posting, we'd be grateful.
  - doublejay1999 5y ago
    The submitted article is a flame war against non-developers and promotes the same attitude in the workplace. Other people have jobs too. It's condescends : "Your non-techie peers just don’t get it, no matter how many times you try to make them understand." Demeans : "Tell him that you bet him lunch he can’t get it done in five minutes, only getting one shot at getting the answer right. Maybe he’ll stop laughing and get to work." ..and insults : "complete with ridiculous buzzword BS bingo and sports metaphors about “closing out the game in the endzone” or something. By the time the dust settles and you’ve been Six-Sigma-ed into submission by 3rd degree black belts", As long as HN keep accepting such submissions, I'll keep giving them the treatment they deserve, which I think is fair.
    - dang 5y ago
itqwertz 5y 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 5y ago
I think pg explains this better: http://www.paulgraham.com/makersschedule.html 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 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 5y ago
Are managers interrupting your work and making it hard to concentrate? Try working at home with young twin children. Great article though.
Wistar 5y ago
At Microsoft, it was easy to see which teams were in crunch mode: the closed doors had "email only" signs on them.
hahamrfunnyguy 5y ago
should be: Programmers, Teach Non-Geeks the True Cost of Interruptions (2014)
ebiester 5y 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 5y 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-nevermind-what-was-41938227.png https://pics.onsizzle.com/focus-poof-hey-do-you-have-isec-ne...
teddyh 5y ago
Whenever this comes up, I usually link to this: Don't Wake Up the Programmer! https://alexthunder.livejournal.com/309815.html https://alexthunder.livejournal.com/309815.html
deleted 5y ago
[deleted]
eggy 5y 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 5y ago
  FWIW I think you could write an interesting book.
  - rendall 5y ago
    I would read the hell out of that book. Or blog
    - juststeve 5y ago
      back of an envelope would be fine also
  - eggy 5y 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.
barry27 5y ago
I'm bored of this whiny prima donna fallacy that interrupting a programmer is worse than interrupting anybody else.
- barry27 5y ago
  wtf i got downvoted for this? that's the final straw. fuck all of you HN wankers. so far up your own arses.
  - barry27 5y ago
    and this too! glorious, hit me again you fucks. let's see if someone can have negative reputation on this bullshit site.
nathias 5y ago
I really don't get this exaggeration about interruptions ...
- 1ris 5y 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 5y 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 5y 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 5y ago
  I think you're lucky to be able to get into flow that quickly. I certainly can't.
igitur 5y 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 5y 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 5y ago
  "Papers, Please" but for programming.
aroundtown 5y 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 5y 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.
- avmich 5y 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 5y 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
SamBam 5y 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 5y 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 https://www.ics.uci.edu/~gmark/chi08-mark.pdf The effects of notes weren't quantified, but if you have a study on that, I'd be happy to read it.
- varjag 5y ago
  A blunt pencil is better than sharp memory.
- Doxin 5y 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 5y 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.
lamontcg 5y 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.
- titzer 5y 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.
  - 5y ago
rreyes1979 5y 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 5y 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 5y 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.
cratermoon 5y ago
Do programmers really need to have the skill of "Holding a Program in One's Head"? http://www.paulgraham.com/head.html http://www.paulgraham.com/head.html
guskel 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y ago
Love the description of the problem in the article, so familiar. I do my best work at night, when everyone is asleep.
ideamotor 5y 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 5y 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 5y 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.
    - abnercoimbre 5y ago
      > Like when you need to spend some time in a dark silent room That resonated, and it's the best example for me to come to grips with this.
  - 5y ago
tgv 5y 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 5y 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 5y 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 5y 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 5y ago
    Some people can fall asleep almost instantly even when there is significant noise around
    - deleted 5y ago
      [deleted]
gego 5y 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 5y 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 5y 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.
mmarq 5y 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_other 5y 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.
  - mmarq 5y 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 5y 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.
NewEntryHN 5y 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 5y ago
required viewing: https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/ https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt... (circa 2013)

293 points by davikrr 5y ago

satya71 5y ago

I’m going to use this.

1-6 5y ago

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

lkbm 5y ago
I choose when to open HN. It might be more often than is ideal, but it's not mid-thought.
paxys 5y 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.
bell-cot 5y ago
HN has a few features which might help: https://news.ycombinator.com/item?id=814695 https://news.ycombinator.com/item?id=814695
pcbro141 5y ago
I use SelfControl on Mac to block sites for deep work: https://selfcontrolapp.com https://selfcontrolapp.com
notatoad 5y 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 5y 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.

werber 5y 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

phaemon 5y ago
Wow maximal wines!
thaumasiotes 5y 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?
- werber 5y 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 5y 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.

harrisonjackson 5y 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 5y ago
This is brilliant!
austinjp 5y 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 5y 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 5y 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 5y ago

This is my favorite cartoon about the cost of interrupting developers. https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/ https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt...

PragmaticPulp 5y 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.

MattGaiser 5y 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.

bentcorner 5y 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 5y 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 5y 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 5y 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_ 5y 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 5y 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 5y 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 5y 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 5y 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.

doublejay1999 5y ago

People have jobs where they need to concentrate ? and...people prefer not to be interrupted when concentrating ? oh. my. god. The author looks old enough to know better than to propagate software development as some kind of novelty role in an organisation, and also old enough to know that cultivating the image of the tortured prima dona, who must not be disturbed while creating his masterwork, does a lot more harm to the profession than good. If you need to work without interruption, pull on your big boy pants, take your code and your laptop, and go work somewhere where there are none. If what you are working on is so intricate and volatile, get funding and build your own fucking lab like scientists have been doing for years. Otherwise, you're part of an organisation, on a salary, like everyone else. So play your part. Idiot.

dang 5y ago
Could you please not post in the flamewar style to HN, cross into personal attack, or call names in arguments here? The site guidelines ask you not to do any of that. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and sticking to the rules when posting, we'd be grateful.
- doublejay1999 5y ago
  The submitted article is a flame war against non-developers and promotes the same attitude in the workplace. Other people have jobs too. It's condescends : "Your non-techie peers just don’t get it, no matter how many times you try to make them understand." Demeans : "Tell him that you bet him lunch he can’t get it done in five minutes, only getting one shot at getting the answer right. Maybe he’ll stop laughing and get to work." ..and insults : "complete with ridiculous buzzword BS bingo and sports metaphors about “closing out the game in the endzone” or something. By the time the dust settles and you’ve been Six-Sigma-ed into submission by 3rd degree black belts", As long as HN keep accepting such submissions, I'll keep giving them the treatment they deserve, which I think is fair.
  - dang 5y ago

itqwertz 5y 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 5y ago

I think pg explains this better: http://www.paulgraham.com/makersschedule.html 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 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 5y ago

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

Wistar 5y ago

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

hahamrfunnyguy 5y ago

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

ebiester 5y 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 5y 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-nevermind-what-was-41938227.png https://pics.onsizzle.com/focus-poof-hey-do-you-have-isec-ne...

teddyh 5y ago

Whenever this comes up, I usually link to this: Don't Wake Up the Programmer! https://alexthunder.livejournal.com/309815.html https://alexthunder.livejournal.com/309815.html

deleted 5y ago

[deleted]

eggy 5y 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 5y ago
FWIW I think you could write an interesting book.
- rendall 5y ago
  I would read the hell out of that book. Or blog
  - juststeve 5y ago
    back of an envelope would be fine also
- eggy 5y 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.

barry27 5y ago

I'm bored of this whiny prima donna fallacy that interrupting a programmer is worse than interrupting anybody else.

barry27 5y ago
wtf i got downvoted for this? that's the final straw. fuck all of you HN wankers. so far up your own arses.
- barry27 5y ago
  and this too! glorious, hit me again you fucks. let's see if someone can have negative reputation on this bullshit site.

nathias 5y ago

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

1ris 5y 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 5y 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 5y 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 5y ago
I think you're lucky to be able to get into flow that quickly. I certainly can't.

igitur 5y 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 5y 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 5y ago
"Papers, Please" but for programming.

aroundtown 5y 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 5y 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.
avmich 5y 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 5y 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

SamBam 5y 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 5y 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 https://www.ics.uci.edu/~gmark/chi08-mark.pdf The effects of notes weren't quantified, but if you have a study on that, I'd be happy to read it.
varjag 5y ago
A blunt pencil is better than sharp memory.
Doxin 5y 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 5y 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.

lamontcg 5y 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.

titzer 5y 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.
- 5y ago

rreyes1979 5y 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 5y 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 5y 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.

cratermoon 5y ago

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

guskel 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y ago

Love the description of the problem in the article, so familiar. I do my best work at night, when everyone is asleep.

ideamotor 5y 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 5y 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 5y 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.
  - abnercoimbre 5y ago
    > Like when you need to spend some time in a dark silent room That resonated, and it's the best example for me to come to grips with this.
- 5y ago

tgv 5y 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 5y 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 5y 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 5y 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 5y ago
  Some people can fall asleep almost instantly even when there is significant noise around
  - deleted 5y ago
    [deleted]

gego 5y 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 5y 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 5y 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.

mmarq 5y 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_other 5y 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.
- mmarq 5y 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 5y 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.

NewEntryHN 5y 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 5y ago

required viewing: https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/ https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt... (circa 2013)