14 ms·

Why interruptions are frustrating to developers

138 points by vitabenes 5y ago

commandlinefan 5y ago
I predict this post (like every other post about not interrupting programmers) is going to trigger an avalanche of "shut up and do your jobs and stop complaining, you spoiled lazy coddled whiny programmers". It seems to be lost on negative commenters that giving programmers (or anybody else for that matter) the freedom to do their jobs well benefits everybody. I sometimes suspect that the interruptions, like the horrible open offices and pointless standup meetings, are put in place not because anybody even perceives them to be a benefit, but as a "muscle flex" to remind the workers who's boss, regardless of how detrimental is it to everybody, including the boss.
- andi999 5y ago
  It depends, doesnt it. Two billable hours might be considered better than one billable hour.
- dkdbejwi383 5y ago
  I've got no problem with having standup and other such things, but wish that all meetings (standup, backlog refinement, brainstorming sessions, etc) were scheduled all in one morning or one whole day out of the week, so that I could then have good 4-5 hour uninterrupted blocks for the rest of the days, instead of having an hour to work, a 20 minute meeting, 40 minutes of work, a 45 minute meeting, 15 minutes of "work", lunch, 30 minutes of work, another meeting, etc.
  - sombremesa 5y ago
    I tried to advocate for this at my current workplace but got a lot of pushback from people who said they didn't want to spend their whole day in meetings (even if it's just one working day out of 10). Others said they had so many meetings they couldn't possibly find enough time to have that many meetings in a day (doesn't make sense to me but that's a direct quote). Clarified here: https://news.ycombinator.com/item?id=27316534 https://news.ycombinator.com/item?id=27316534 Now I'm realizing my job is actually to attend meetings. I should ask for a raise! Though in reality I'm just going to quit soon. The sweet irony is that this meeting heavy company of 50ish people uses Zoom without pro accounts...it's enough to make a grown man cry.
    - commandlinefan 5y ago
      > my job is actually to attend meetings. It's probably not, though - or, at least one of those meetings is the one where you have to showcase/demonstrate what you "accomplished" in spite of all the interruptions. You do have to produce something in spite of all the time wasted in meetings. I've unironically been told that that's what the weekends are for.
      - sombremesa 5y ago
        The 'my job is actually to attend meetings' was tongue-in-cheek - perhaps that wasn't as obvious as I thought. These days I code during the meetings, since it doesn't seem to make a difference whether I pay attention. > I've unironically been told that that's what the weekends are for. This kind of rings true, I've only been here around 3 months. I did spend a couple of weekends on code in the first month, but overall this company (and my comp) really isn't worth that kind of effort, so I've stopped. I really only joined this company because I wanted a better work life balance (joke's on me) and my business isn't yet profitable, but I'm actually financially independent so it's tough to muster up motivation to work overtime for free.
        ipaddr 5y ago
        Have you ever tried just not showing up. Or pitting two managers against each other? I would love to attend your meeting but this other team needs this. Let them schedule it out for you?
        gregmac 5y ago
        I went on a kick of replying (and sometimes declining) meetings without agendas, asking "what is the agenda for this?" And sometimes with an agenda, I will try to reply and resolve whatever it was about asynchronously. There have been several meetings avoided when I replied with something like "this sounds like known bug #1234" or "here's the wiki page documenting this: is there something else not covered?". My # meetings went down after I started doing this. Maybe it changed the culture in a good way, or maybe people got tired of me and stopped inviting me to meetings.. but either way seems like success.
  - thrower123 5y ago
    My least favorite, and all too common, kind of day is one that gets bracketed with meetings. The most usual form of this is the 10:30 AM standup/status meeting, paired with the 3 pm also standup/status/testing session. Assuming that you eat lunch, this is almost perfectly designed to make sure that you can't actually accomplish anything in the course of a 9-5 work day.
  - karaterobot 5y ago
    Completely agree with this in principle. I've passive-aggressively kept a spreadsheet that tracks how much time I spend in meetings, and it's averaged between 25% and 30% over the course of a couple years. That's frustrating in its own right, but what's worse is that nobody ever factors it into scheduling estimates. If your team is getting 6 hours of work done in an 8 hour day, that's the equivalent of the whole team taking a day off every week and expecting everything to still get done on schedule. Except it's worse, because it makes you less efficient all the time rather than just one day a week. On the other hand, I don't think that trying to fit all weekly meetings into a single day would solve the problem either. It's often the case that decision makers — the people you need to have at a lot of meetings — are involved in different areas of a business or product, so they'd have overlapping demands on their time. Where I work, there are a few people who are like this, and their schedule shapes how meetings are planned for everyone else. When any of these people have conflicting meetings scheduled, one or more of those meetings have to be rescheduled for another day. So now everyone else has 2 half days of meetings a week, rather than one full day. And then, what happens if you learn new information and have to make a decision? Do you wait a week to talk about it? Probably not. So, you'd probably have a couple heavy meeting days, and then a number of ad hoc meetings scattered over the week. This is not the improvement we were looking for, and I think at a certain point the team would just drift away from the initial vision, and settle into the former pattern. Not saying it's a good thing!
    - ipaddr 5y ago
      I do, I'll add in meetings in the estimate you should too. I love contracting where you charge the client for each meeting, itemize the list by date/duration and suddenly meetings become shorter.
    - tharkun__ 5y ago
      Story points to the rescue. It sounds to me like you guys are estimating in hours, thus you give an 8 hour estimate, they expect something to be done 8 work hours after you started work. Everyone knows you have 80 hours in a two week period so they expect you do finish 10 of these 8 hour tickets. Compare that to Story Points. Your velocity over a two week sprint is auto adjusting for the typical/average meeting load and other interruptions. If you estimate a ticket at 8 story points and your velocity is 24 story points then everyone should expect you to finish 3 of these tasks per sprint. This is obviously all 'on average' and there might be a production incident that means this time you didn't get it all done or maybe the other way around, someone got sick and 3 large meetings didn't happen and you got a 4th ticket through. Also note that I chose 8 story points at random. 8 story points is specifically NOT to be equated with 8 hours. Story points are just uses as a relative complexity measure, meaning something with 3 story points is roughly a third as complex as that 8 pointer. Many managers and even people that claim to be Scrum Product Owner or even Scrum Masters don't really understand that.
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- mjburgess 5y ago
  The culture here is fascinating. I comment (sincerely, and thoughtfully) in one topic criticising naive interpretations of AI -- heavily downvoted. OK, we're AI fanatics here: programmers are gods. Intelligence is just a program we're yet to write. So in this thread I comment to defend how demanding programming is on the intellect. Again, many downvotes. I have no idea what this community is.
  - slingnow 5y ago
    It's a community of people with thoughts that sometimes differ from yours. It doesn't seem that confusing.
    - mjburgess 5y ago
      Indeed: isn't that precisely a good reason to reply rather than downvote? I have maybe downvoted a handful of times in a decade of being on this site: only for spam or grossly misleading comments. Increasingly I see seas of downvoted comments as-if this were reddit. I think that might just be it: the community has grown so large, it has attracted enough of those types who vote-their-emotions.
      - slingnow 5y ago
        I think I agree with you in general, and to be fair I didn't downvote your original comment. My takeaway was that you were taking the unpopular opinion (programming is uniquely hard/creative/etc) and attempting to reinforce it by unfairly reducing the creative act of painting to no more than paint on a canvas. That's my best guess.
  - loopz 5y ago
    You'll fare much better trying for constructive and introspective perspectives. Often you'll receive downvotes immediately anyway, but the tide might turn as other people might recognize something in what you write over time. This is a startup/founder-centric forum, and creative people usually have less time for criticism and negative viewpoints, that then need to be translated into something worthwhile.
- deleted 5y ago
  [deleted]
- amozoss 5y ago
  Author here: My intention wasn't to whine or anything. In fact, 2 of the 4 tips I gave was how I protect against interruptions from myself. The comments have inspired me to write a follow up, titled something like "My number one source of interruptions is myself", and maybe it'll avoid the mess of flame.
- 908B64B197 5y ago
  > I sometimes suspect that the interruptions, like the horrible open offices and pointless standup meetings, are put in place not because anybody even perceives them to be a benefit, but as a "muscle flex" to remind the workers who's boss, regardless of how detrimental is it to everybody, including the boss. Microsoft had a culture of offices with a door, to allow more focus. But it's not the only thing they did differently (and the companies valuation speaks for itself).
  - Arainach 5y ago
    That's not quite the data point you think it is. Their valuation stayed roughly constant from 2001-2016, and the huge spike since then corresponds to a huge shift away from offices with doors - all new buildings after 2010 or so were that way, and most of main campus has been torn down to be rebuilt as open office floorplans.
- akomtu 5y ago
  I did some cat herding in past and the sole reason I run morning stand-ups is to know what everyone is doing. In other words, I was afraid to appear clueless when higher ups ask me about progress. It wasn't a muscle flex, but it wasn't for the team's benefit either. And yes, open spaces are wonderful for such low-effort managing activity.
- nly 5y ago
  Try it when your company spans America, Europe and Asia and you have meetings between teams in all of them
NovemberWhiskey 5y ago
This is not just about developers; it's really true for many kinds of knowledge work - for example, writing. It's just that in most of the other disciplines where these concerns are relevant, no-one would think of constructing a work environment that was so incredibly distraction-filled.
- tapan_jk 5y ago
  > it's really true for many kinds of knowledge work I would argue not just knowledge work. Imagine a painter or a tattoo artist or a pilot or many others who are trying to concentrate and someone constantly interrupts them.
- kolbe 5y ago
  I've always found the mental processes used in writing and coding are quite similar. Architecture as well. I'm sure it's not a coincidence that we borrowed from their disciplines' vocabularies to describe our work as well.
BurningFrog 5y ago
My contrarian view on this: If you need extreme focus to work with your code, that code is garbage. Well written and well factored code is easy to get work done in, and you don't need to keep a zillion things in mind to navigate it. Of course, reality is that the code most people work in is some level of garbage, and maybe there isn't much you can do about that. Either because you're not in charge, or you don't have the skills to improve the code.
- commandlinefan 5y ago
  > or you don't have the skills to improve the code. Don't have the skills or don't have the time? Predicting, down to the hour, how long every programming task will take before you undertake it has been a staple of programming professionally as long as I've been doing it. I have the skills to simplify a codebase to any level you can define, but I can't do it in an hour.
  - BurningFrog 5y ago
    I have programmed professionally since 1984. Never had to predict by the hour, but occasionally by day/week. After I got into the agile/XP world ~15 years ago, there are no deadlines, and if I need to take a day to improve some code, I do. I'm not saying this to brag about my great life, but to tell you there are other kinds of jobs out there. That said, a good number of pro developers do not have the skills to write well factored code. Or the interest, frankly.
- oauea 5y ago
  Cool, how do you get there? And you realize some work is simply non-trivial?
- deepsun 5y ago
  Sometimes you cannot write an easy code -- e.g. low-level heavily optimized code.
- adkadskhj 5y ago
  > If you need extreme focus to work with your code, that code is garbage. Maybe _i_ am garbage? Sometimes i need focus to solve the problem in a way that's easy to reason about. So no code exists, nothing you could critique, so perhaps your critique would be just about me?
hashkb 5y ago
After sharing this view for many years, I now realize how selfish it is. Now that I am a consultant working directly for entrepreneurs, it's clear that my job is to both deliver software AND to be as available as possible. You can build tools and strategies to get back to what you were doing. If you are that fragile, you've got some growing to do.
- dent9876543 5y ago
  Yep. Couldn’t agree more. There really is a time and efficiency cost to all the task switching g. But equally, and as another poster said already, software development really does require having meetings to get a good outcome. I think it’s missed by many people that see meetings as an inconvenience, but very very often I have found that a meeting has radically altered the goal, or the plan, or the context. Pushing back against the meeting would be a crazy thing to do.
  - hashkb 5y ago
    Inevitably, the "no meetings, no interruptions" devs are the same people complaining they don't have a voice in the larger org and that business doesn't care about their opinions. But no, they can't do a weekly 30 minute standing meeting. Edit: and they'll happily point out the hypocrisy of the sales, marketing, and executive teams on coffee walks.
    - commandlinefan 5y ago
      > weekly 30 minute standing meeting. I've been doing 30 minute standing meetings pretty much every day since the XP folks coined the term "stand up", which was about 20 years ago. Every single one has consisted of the boss talking for 28 minutes (sometimes back and forth with one team member) while everybody else stands around, followed by, "ok, does anybody else have anything?" If anybody says yes, it's "we're almost out of time for this meeting, so let's take it offline". 20 years, five different employers, exact same experience every time, every day. Human psychology doesn't fit this structure the way you want it to.
dahfizz 5y ago
Something really annoys me about developers acting like we are the only people on earth who have to think and focus to get work done. I'm not convinced programming is sufficiently different from any other skilled job. Whining about how your "flow state" can't be interrupted because of how extraordinarily creative and artistic you are is just pretentious.
- deepsun 5y ago
  Many other professions react strongly to interruptions. E.g. from what I know: writers and mathematicians react even strongly.
  - pc86 5y ago
    The difference is that writers and mathematicians aren't typically expected to stand up every morning and explain to their colleagues and a manager who never did their job what they did yesterday, what they will do today, and what their roadblocks are. They're given a task and allowed to work for days, weeks, even months, with little or no interruption and largely self-guided. They're also not typically creating things directly that provide as much business value as developers are.
    - sirsinsalot 5y ago
      They also arent creating output that has to be simultaneously harmonic with other peoples work in an often quickly changing landscape.
    - hinkley 5y ago
      You can interpret Hemingway’s writing process such that he really could tell you what he did yesterday and what he’s going to do today. Not that I’m particularly fond of this current incantation of Agile.
  - deleted 5y ago
    [deleted]
- mjburgess 5y ago
skadamat 5y ago
I'm surprised Cal Newport's recent book, A World Without Email wasn't mentioned! https://www.amazon.com/gp/product/0525536558/ https://www.amazon.com/gp/product/0525536558/ He takes ideas from Deep Work and builds on them by scaling up the ideas to how an organization should work, coordinate, and collaborate. Specifically, he looks at how to build organizations that are designed to support how our brains have evolved to think & work (without frequent context switches!)
- jedimastert 5y ago
  I mean, I check my email twice a day, once at the beginning and once right after lunch. Not usually a disruptive context switch. It's why I usually prefer it.
G4BB3R 5y ago
Once in a cowork space we had the golden rule to never call someone that is on headphone, unless it is urgent. I miss that.
- sumtechguy 5y ago
  If I am 'in the zone' and someone walks up to me I hold up my hand and say 'wait a min I need to get this down'. Then I write a note to myself to myself back where I was. I then help them. If someone says 'can you come back later' I always respect it. I also sometimes just tell people 'not right now I will get back to you in a bit' and it works surprising well. But make sure you come back to them at some point or they will not respect it next time. My personal biggest issue is self interruptions. Mostly web sites that are distracting.
tengbretson 5y ago
Interruptions are so frustrating to developers in particular because their skills are in sufficiently high demand that they can behave like immature divas.
- commandlinefan 5y ago
  > can behave like immature divas I remember reading once that Mike Myers, while filming the movie "Wayne's World", came out of his dressing room, found that there was no non-dairy butter for his bagel on the catering table, flipped the table over in anger and returned to his dressing room for the rest of the day. That sounds like "immature diva" behavior to me. Saying "you want me to deliver the best product possible, and I want that too. In order to do that so that we can both come out ahead, I do my best when I can focus on making sure I get every detail right" seems far less immature. But maybe that's just me?
- jk20 5y ago
  You sound like a scrum master.
mkl95 5y ago
I work remotely 4 days a week these days. I only spend about 45 minutes a week in meetings, and interruptions are extremely rare. I'm happy and very productive. I have previously worked at places where I was interrupted several times a day, and I think it has a lot to do with a company's culture. Unfortunately, many companies in my country are dominated by sales people, and these people couldn't care less about software developers. Make sure you will be considered a first class citizen before accepting a job offer.
twodave 5y ago
I see this kind of rhetoric often, whether at work or here on HN. I think some important factors are typically left out, however: 1. Business value isn’t always a measure of coding velocity. Interruptions are often gifts in disguise. 2. The ability to work in a way that allows for interruption is a skill that can be learned. As a younger programmer who loved nothing more than to sling vast amounts of code, interruptions were killers. Over the years I’ve learned to recognize interruptions as opportunities to re-assess my priorities. I’ve also learned to write code in a way that reduces cognitive load so that interruptions aren’t so disruptive to my productivity. I’m not going to try and say these are universal principles or that any business can apply them, but as highly skilled workers I think this is an area where we tend to put in relatively little effort to overcome obstacles.
- G4BB3R 5y ago
  I agree with you, but that doesn't apply when someone interrupts in the middle of a thought.
- sackerhews 5y ago
  I'm interested in your point number 2. Do you have any links that back it up?
  - hinkley 5y ago
    I don’t think XP could have worked at all without Refactoring, because everyone is sitting together and asking questions. With conventional coding, if your house of mental cards falls, you may potentially lose all of your work. By working from working code to working code, even if you lose your train of thought you get to keep most of your work so far. A number of other techniques also allow you to work more from working memory than memorization. This helps when writing code a little bit, but most of the payoff is for readers or subsequent additions. The thing with DRY is that code reuse means that a breakpoint most likely can fire from multiple paths, which makes it hard to trace why you’re getting null/undefined instead of an empty array as your second argument. Conditional breakpoints can help for some of these scenarios, but it’s better if the code in the middle of the call stack tries to be as contained and organized as leaf node methods eventually become. You can’t modify code if you can’t read it, and if it’s difficult to read then interruptions become more problematic, because both the cost of interruption and the likelihood of interruption go up when thinking time increases. The cleverest code is the code which is easiest to understand.
amozoss 5y ago
Wow thanks for the surprise in traffic this morning. Author here: I really wanted to illustrate the "why" it's frustrating. A more complete visual of what is actually in my head. Also I didn't get a chance to pull it out as much as I'd like, but I'm my own worst enemy when it comes to interruptions. So I broke my tips into 3 categories: 1. Protect against myself (2 tips) 2. Protect against day to day working cycle (1 tip) 3. Help teams work together to help each other (1 tip) hence why I catered 2 of the 4 tips to myself.
- commandlinefan 5y ago
  As I suspected, your post has brought a barrage of "deal with it" dissenters. This is as predictable as it is frustrating: the contrarians themselves seem to accept that an uninterrupted programmer is a better programmer and that an uninterrupted programmer will produce a better result - but they _still_ insist that we just deal with the (mostly unnecessary, non-value-add, easy to remove) interruptions anyway.
  - amozoss 5y ago
    My hope was that it would cause self reflection on what types of interruptions are causing us the most grief. For example, in tip 3, I realized I obsessively check my business metrics to the point where I could never lay the foundation of a focus tower. So I decided to put it in a red tab group in chrome to remind myself not to go there.
- MarkLowenstein 5y ago
  I liked your suggested mitigations. Well-designed to accommodate human motivation, and simple enough to be practical.
kolbe 5y ago
I feel like this misses the point of why interruptions are frustrating to me. To me, I have so many things that I'm cramming into my short-term memory that I need to have access to while doing a certain task. If I'm in the middle of writing the contents of a loop, and then I note that I'm operating in row-major, and I need to go make sure that the inputs are row-major and that this is documented. So, instead of breaking my concentration on the loop itself, I just cache that knowledge and go back to it after I've finished the loop body. If I'm then interrupted, or worse, drawn away to something for a while, it's easy for that information to have fallen out by the time I return to finishing the code. I ultimately need to keep a log of every single task (even if I plan on doing it in a minute) in order to thwart this. I don't like it, but that's just what I have to do to keep from introducing "interruption bugs" in my code. I think another thing that is irksome is that the same people who are hounding you to finish some task in X amount of time are the ones making it go to 2X with their interruptions.
- amozoss 5y ago
  Author here: I totally agree! That's why I wrote tip number 4 "Record context as you go". I have a bash script that has the current command I'm working on (usually it's running a single test). I use it as a way to record notes and to quickly pick up where I left off.
  - kolbe 5y ago
    Pen and paper for me! One big flaw is I occasionally can't read my own handwriting.
  - euroderf 5y ago
    Also record context as the last thing you do before you go out the door at the end of the workday. Makes it much easier the next day to pick up where you left off. A quickie brain dump - a couple of lines, a couple of paragraphs.
- hinkley 5y ago
  There are tools that can help with reducing the amount of working memory you need, but it’s a bit like kerning, in that once you see it you can’t unsee it, and your peers won’t understand why you are upset with their work.
postalrat 5y ago
I think learning to work around interruptions is a skill that can be developed over time. Just watch some coding streamers on twitch. They can start and stop their coding while interacting with their viewers. In many ways it's the similar for gamers on twitch. Try holding a conversation while playing a game. Over time they learn to be good at both simultaneously. There are going to be some programming tasks that are harder to start and stop. But for most programmers those are going to be the exception.
- warvariuc 5y ago
  This applies only to routine tasks. Those coding a game while streaming, do a known type of app. But when you do something new, which requires focus, research, it's a different story. IMO.
loopz 5y ago
What did the developer do to avoid being interrupted, ie. why is it necessary for others to disturb said developer?
- amozoss 5y ago
  Author here: Glad you asked I laid out 4 tips that have helped me focus better. I purposely made 2 of the 4 tips directed directly at myself. I create the most interruptions to my day. My team has worked together to reduce unnecessary interruptions (see tip 1) as a courtesy to help me with my bad habits. The key point here is small interruptions are okay, but often not worth it, because I'll go off and do something else. If I could easily bounce back to what I was doing, I'd be much less frustrated at the interruption. My frustration lies with my inability to quickly go back to what I was working on, not the interruption itself. Notice that I'm not passing the blame at others, I know my weakness. If I open chrome to check Slack, I'm gonna check HN, I'm gonna look at my email. This is something I need to work on personally
TacticalCoder 5y ago
When I'm in the zone, here's something that happens: SO asks a question and somehow I hear the question but I don't process it, the question/event goes on some kind of stack. Then 5 or 15 minutes later I answer the question. External stimuli is simply processed differently. There can even be a phone ringing for minutes, driving SO and kiddo mad. Yet I don't hear it: or at least it doesn't disturb me. It even happens, rarely, that I get out of the zone and notice SO is gone and I'm a bit lost then I have to "focus" on the stack now: "ah yup, she said she went to pick her mom for she eats with us tonight". I honestly don't know how to describe that as something else than being in some kind of zone. I've seen friends studying for exams being in the same kind of state. I like being there and I'm convinced I'm doing better work when I'm there. EDIT: and there's something I do like in TFA: I separate my computer in "virtual desktops" assigned to different things. The main coding virtual desktop / workspace is ads-free for example (got a browser open but only for dev / for testing the (ad-free) thing I'm working on). I've got a "private email" virtual desktop, a "professional email" one (which is separate from the main coding virtual desktop), etc. It just makes sense to me.
euroderf 5y ago
The metaphor of the cards is spot on. But the Flow has its own Rhythm, and there are Very Bad times to interrupt and then there are Merely-OK times to interrupt. But what I found after many years of coding for a living is that the drive to reach a checkpoint and push context spills over into private life. I catch myself snarling at my SO if I'm not given a minute or two to finish whatever it is I'm in the middle of. Even when doing everyday things like making food or doing housework. Is this typical ? Is this sort-of OK, or just self-absorbed and conceited ?
thomastjeffery 5y ago
The frustration with interruptions is that they introduce a sudden increase in required working memory. It's the same frustration that people with ADHD experience regularly, because they have less available working memory in the first place. Managing an inadequate amount of short term memory - whether caused by a deficiency in memory or overload of stimulus - is done mainly by restructuring your surroundings so they don't interrupt you. Software development tends to be very appealing to neurodivergent people (including those with ADHD), so a strong distaste for interruption at work is to be expected.
- dan_quixote 5y ago
  > The frustration with interruptions is that they introduce a sudden increase in required working memory I've wondered the same - though never been able to put it into such concise words. I formerly worked as a Mechanical/Controls engineer and did not feel the same frustration with interruptions at the time despite being an equally challenging industry (as far as my experience went). My conclusion is that the hard constraints of a physical system keep the problem space (and thus the required working memory) relatively small in the physical world. When you're writing software that has no physical manifestation, the problem space is typically massive since the constraints are fewer.
- screye 5y ago
  > because they have less available working memory Tangential, but you contextualization ADHD as the lack of working memory is a light bulb moment for me. I was diagnosed with ADHD this year out of other suspicions. (I've always suspected it, but avoided getting diagnosed because I thought I would use it as an excuse for being lazy). My working memory also happens to be incredibly low, to the point that some of my friends call me a goldfish. (My long term memory is excellent in comparison) I never put two and two together, but it makes so much sense. I really should go for the long-overdue- prescription meeting I keep avoiding. :\
  - thomastjeffery 5y ago
    > Tangential, but you contextualization ADHD as the lack of working memory is a light bulb moment for me. It was for me, too. I've recently been reading about ADHD and people's experience with it. I've always had my suspicions, but never in a serious enough context to make any decisions about it. Reading people's experiences feels like talking to a long lost friend from a parallel universe. I certainly have had opportunities to get an actual diagnosis, especially during my childhood, but the onus was always placed on me or my parents to take action. My parents were unmotivated by stigma and I was unmotivated by my ADHD symptoms. So here I am, 28 and trying to motivate my ADHD brain to navigate America's absurd - and unnecessarily confrontational - healthcare system so I can get a diagnosis and medication/therapy. > I really should go for the long-overdue- prescription meeting I keep avoiding. :\ I can't speak for the experience of people who have been using medication, but as someone who has spent decades without it, I would strongly encourage you to do that. Good luck getting your ADHD brain to do the follow through!
bryanrasmussen 5y ago
I don't mind interruptions, unless I've been working on something for a couple hours and I can't figure out what could be going wrong with it - then I'm a real jerk!
deleted 5y ago
[deleted]
atum47 5y ago
focus tower? what happened to train of thought?
gioele 5y ago
In far fewer words: https://heeris.id.au/trinkets/ProgrammerInterrupted.png https://heeris.id.au/trinkets/ProgrammerInterrupted.png
- gdsdfe 5y ago
  lool I got pissed just imagining this happening
- amozoss 5y ago
  Love it! I was really tempted to include this in my article, but it didn't quite fit since it's so tall :)
- lou1306 5y ago
  There is a very similar one wandering around the internet, e.g., here: https://twitter.com/boagworld/status/971328648048447490?s=20 https://twitter.com/boagworld/status/971328648048447490?s=20
SkyPuncher 5y ago
I have recently stepped back into the realm of dealing with leadership and executives. The juxtaposition relative to a bunch of recent programming has made me realize why leaders don't fully understand why interruptions are so difficult - the type of work is fundamentally different. * When dealing with Ops work or leadership, much of my work is thin and wide. In other words, I spend my time on a LOT of different things, but rarely need to deep dive. When I do need to deep dive, I'm looking at a timebox measured in hours. I can be interrupted because none of my thoughts are difficult to rebuild. * When I'm programming, I'm working thin and deep. I have a very narrow problem that requires diving into something very deeply. There are often a lot of little details that are potentially blockers. All of that needs to be in active thinking memory - or at least very close to it. When I get interrupted while programming, those auxiliary details go "poof". Sometimes they're hard, if not impossible to get back.
deleted 5y ago
[deleted]
karmakaze 5y ago
It's amazing when pair programming in-person with the same person for a couple weeks how easy it is to resume working state after an interuption or lunch break. Same goes for much less lull time being unproductive, even if not doing something else but unconsciously working quite slowly.
pontifier 5y ago
I need a 1 page synopsis that I can just post up everywhere and/or hand to someone every time they try to distract me. I'm in the mode where I can't even start programming anymore because interruptions have trained me it is useless to even try. I'm gradually trying to re-train myself to be productive, but it requires extreme measures.

138 points by vitabenes 5y ago

I predict this post (like every other post about not interrupting programmers) is going to trigger an avalanche of "shut up and do your jobs and stop complaining, you spoiled lazy coddled whiny programmers". It seems to be lost on negative commenters that giving programmers (or anybody else for that matter) the freedom to do their jobs well benefits everybody. I sometimes suspect that the interruptions, like the horrible open offices and pointless standup meetings, are put in place not because anybody even perceives them to be a benefit, but as a "muscle flex" to remind the workers who's boss, regardless of how detrimental is it to everybody, including the boss.

andi999 5y ago
It depends, doesnt it. Two billable hours might be considered better than one billable hour.
dkdbejwi383 5y ago
I've got no problem with having standup and other such things, but wish that all meetings (standup, backlog refinement, brainstorming sessions, etc) were scheduled all in one morning or one whole day out of the week, so that I could then have good 4-5 hour uninterrupted blocks for the rest of the days, instead of having an hour to work, a 20 minute meeting, 40 minutes of work, a 45 minute meeting, 15 minutes of "work", lunch, 30 minutes of work, another meeting, etc.
- sombremesa 5y ago
  I tried to advocate for this at my current workplace but got a lot of pushback from people who said they didn't want to spend their whole day in meetings (even if it's just one working day out of 10). Others said they had so many meetings they couldn't possibly find enough time to have that many meetings in a day (doesn't make sense to me but that's a direct quote). Clarified here: https://news.ycombinator.com/item?id=27316534 https://news.ycombinator.com/item?id=27316534 Now I'm realizing my job is actually to attend meetings. I should ask for a raise! Though in reality I'm just going to quit soon. The sweet irony is that this meeting heavy company of 50ish people uses Zoom without pro accounts...it's enough to make a grown man cry.
  - commandlinefan 5y ago
    > my job is actually to attend meetings. It's probably not, though - or, at least one of those meetings is the one where you have to showcase/demonstrate what you "accomplished" in spite of all the interruptions. You do have to produce something in spite of all the time wasted in meetings. I've unironically been told that that's what the weekends are for.
    - sombremesa 5y ago
      The 'my job is actually to attend meetings' was tongue-in-cheek - perhaps that wasn't as obvious as I thought. These days I code during the meetings, since it doesn't seem to make a difference whether I pay attention. > I've unironically been told that that's what the weekends are for. This kind of rings true, I've only been here around 3 months. I did spend a couple of weekends on code in the first month, but overall this company (and my comp) really isn't worth that kind of effort, so I've stopped. I really only joined this company because I wanted a better work life balance (joke's on me) and my business isn't yet profitable, but I'm actually financially independent so it's tough to muster up motivation to work overtime for free.
      - ipaddr 5y ago
        Have you ever tried just not showing up. Or pitting two managers against each other? I would love to attend your meeting but this other team needs this. Let them schedule it out for you?
        gregmac 5y ago
        I went on a kick of replying (and sometimes declining) meetings without agendas, asking "what is the agenda for this?" And sometimes with an agenda, I will try to reply and resolve whatever it was about asynchronously. There have been several meetings avoided when I replied with something like "this sounds like known bug #1234" or "here's the wiki page documenting this: is there something else not covered?". My # meetings went down after I started doing this. Maybe it changed the culture in a good way, or maybe people got tired of me and stopped inviting me to meetings.. but either way seems like success.
- thrower123 5y ago
  My least favorite, and all too common, kind of day is one that gets bracketed with meetings. The most usual form of this is the 10:30 AM standup/status meeting, paired with the 3 pm also standup/status/testing session. Assuming that you eat lunch, this is almost perfectly designed to make sure that you can't actually accomplish anything in the course of a 9-5 work day.
- karaterobot 5y ago
  Completely agree with this in principle. I've passive-aggressively kept a spreadsheet that tracks how much time I spend in meetings, and it's averaged between 25% and 30% over the course of a couple years. That's frustrating in its own right, but what's worse is that nobody ever factors it into scheduling estimates. If your team is getting 6 hours of work done in an 8 hour day, that's the equivalent of the whole team taking a day off every week and expecting everything to still get done on schedule. Except it's worse, because it makes you less efficient all the time rather than just one day a week. On the other hand, I don't think that trying to fit all weekly meetings into a single day would solve the problem either. It's often the case that decision makers — the people you need to have at a lot of meetings — are involved in different areas of a business or product, so they'd have overlapping demands on their time. Where I work, there are a few people who are like this, and their schedule shapes how meetings are planned for everyone else. When any of these people have conflicting meetings scheduled, one or more of those meetings have to be rescheduled for another day. So now everyone else has 2 half days of meetings a week, rather than one full day. And then, what happens if you learn new information and have to make a decision? Do you wait a week to talk about it? Probably not. So, you'd probably have a couple heavy meeting days, and then a number of ad hoc meetings scattered over the week. This is not the improvement we were looking for, and I think at a certain point the team would just drift away from the initial vision, and settle into the former pattern. Not saying it's a good thing!
  - ipaddr 5y ago
    I do, I'll add in meetings in the estimate you should too. I love contracting where you charge the client for each meeting, itemize the list by date/duration and suddenly meetings become shorter.
  - tharkun__ 5y ago
    Story points to the rescue. It sounds to me like you guys are estimating in hours, thus you give an 8 hour estimate, they expect something to be done 8 work hours after you started work. Everyone knows you have 80 hours in a two week period so they expect you do finish 10 of these 8 hour tickets. Compare that to Story Points. Your velocity over a two week sprint is auto adjusting for the typical/average meeting load and other interruptions. If you estimate a ticket at 8 story points and your velocity is 24 story points then everyone should expect you to finish 3 of these tasks per sprint. This is obviously all 'on average' and there might be a production incident that means this time you didn't get it all done or maybe the other way around, someone got sick and 3 large meetings didn't happen and you got a 4th ticket through. Also note that I chose 8 story points at random. 8 story points is specifically NOT to be equated with 8 hours. Story points are just uses as a relative complexity measure, meaning something with 3 story points is roughly a third as complex as that 8 pointer. Many managers and even people that claim to be Scrum Product Owner or even Scrum Masters don't really understand that.
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
mjburgess 5y ago
The culture here is fascinating. I comment (sincerely, and thoughtfully) in one topic criticising naive interpretations of AI -- heavily downvoted. OK, we're AI fanatics here: programmers are gods. Intelligence is just a program we're yet to write. So in this thread I comment to defend how demanding programming is on the intellect. Again, many downvotes. I have no idea what this community is.
- slingnow 5y ago
  It's a community of people with thoughts that sometimes differ from yours. It doesn't seem that confusing.
  - mjburgess 5y ago
    Indeed: isn't that precisely a good reason to reply rather than downvote? I have maybe downvoted a handful of times in a decade of being on this site: only for spam or grossly misleading comments. Increasingly I see seas of downvoted comments as-if this were reddit. I think that might just be it: the community has grown so large, it has attracted enough of those types who vote-their-emotions.
    - slingnow 5y ago
      I think I agree with you in general, and to be fair I didn't downvote your original comment. My takeaway was that you were taking the unpopular opinion (programming is uniquely hard/creative/etc) and attempting to reinforce it by unfairly reducing the creative act of painting to no more than paint on a canvas. That's my best guess.
- loopz 5y ago
  You'll fare much better trying for constructive and introspective perspectives. Often you'll receive downvotes immediately anyway, but the tide might turn as other people might recognize something in what you write over time. This is a startup/founder-centric forum, and creative people usually have less time for criticism and negative viewpoints, that then need to be translated into something worthwhile.
deleted 5y ago
[deleted]
amozoss 5y ago
Author here: My intention wasn't to whine or anything. In fact, 2 of the 4 tips I gave was how I protect against interruptions from myself. The comments have inspired me to write a follow up, titled something like "My number one source of interruptions is myself", and maybe it'll avoid the mess of flame.
908B64B197 5y ago
> I sometimes suspect that the interruptions, like the horrible open offices and pointless standup meetings, are put in place not because anybody even perceives them to be a benefit, but as a "muscle flex" to remind the workers who's boss, regardless of how detrimental is it to everybody, including the boss. Microsoft had a culture of offices with a door, to allow more focus. But it's not the only thing they did differently (and the companies valuation speaks for itself).
- Arainach 5y ago
  That's not quite the data point you think it is. Their valuation stayed roughly constant from 2001-2016, and the huge spike since then corresponds to a huge shift away from offices with doors - all new buildings after 2010 or so were that way, and most of main campus has been torn down to be rebuilt as open office floorplans.
akomtu 5y ago
I did some cat herding in past and the sole reason I run morning stand-ups is to know what everyone is doing. In other words, I was afraid to appear clueless when higher ups ask me about progress. It wasn't a muscle flex, but it wasn't for the team's benefit either. And yes, open spaces are wonderful for such low-effort managing activity.
nly 5y ago
Try it when your company spans America, Europe and Asia and you have meetings between teams in all of them

NovemberWhiskey 5y ago

This is not just about developers; it's really true for many kinds of knowledge work - for example, writing. It's just that in most of the other disciplines where these concerns are relevant, no-one would think of constructing a work environment that was so incredibly distraction-filled.

tapan_jk 5y ago
> it's really true for many kinds of knowledge work I would argue not just knowledge work. Imagine a painter or a tattoo artist or a pilot or many others who are trying to concentrate and someone constantly interrupts them.
kolbe 5y ago
I've always found the mental processes used in writing and coding are quite similar. Architecture as well. I'm sure it's not a coincidence that we borrowed from their disciplines' vocabularies to describe our work as well.

BurningFrog 5y ago

My contrarian view on this: If you need extreme focus to work with your code, that code is garbage. Well written and well factored code is easy to get work done in, and you don't need to keep a zillion things in mind to navigate it. Of course, reality is that the code most people work in is some level of garbage, and maybe there isn't much you can do about that. Either because you're not in charge, or you don't have the skills to improve the code.

commandlinefan 5y ago
> or you don't have the skills to improve the code. Don't have the skills or don't have the time? Predicting, down to the hour, how long every programming task will take before you undertake it has been a staple of programming professionally as long as I've been doing it. I have the skills to simplify a codebase to any level you can define, but I can't do it in an hour.
- BurningFrog 5y ago
  I have programmed professionally since 1984. Never had to predict by the hour, but occasionally by day/week. After I got into the agile/XP world ~15 years ago, there are no deadlines, and if I need to take a day to improve some code, I do. I'm not saying this to brag about my great life, but to tell you there are other kinds of jobs out there. That said, a good number of pro developers do not have the skills to write well factored code. Or the interest, frankly.
oauea 5y ago
Cool, how do you get there? And you realize some work is simply non-trivial?
deepsun 5y ago
Sometimes you cannot write an easy code -- e.g. low-level heavily optimized code.
adkadskhj 5y ago
> If you need extreme focus to work with your code, that code is garbage. Maybe _i_ am garbage? Sometimes i need focus to solve the problem in a way that's easy to reason about. So no code exists, nothing you could critique, so perhaps your critique would be just about me?

hashkb 5y ago

After sharing this view for many years, I now realize how selfish it is. Now that I am a consultant working directly for entrepreneurs, it's clear that my job is to both deliver software AND to be as available as possible. You can build tools and strategies to get back to what you were doing. If you are that fragile, you've got some growing to do.

dent9876543 5y ago
Yep. Couldn’t agree more. There really is a time and efficiency cost to all the task switching g. But equally, and as another poster said already, software development really does require having meetings to get a good outcome. I think it’s missed by many people that see meetings as an inconvenience, but very very often I have found that a meeting has radically altered the goal, or the plan, or the context. Pushing back against the meeting would be a crazy thing to do.
- hashkb 5y ago
  Inevitably, the "no meetings, no interruptions" devs are the same people complaining they don't have a voice in the larger org and that business doesn't care about their opinions. But no, they can't do a weekly 30 minute standing meeting. Edit: and they'll happily point out the hypocrisy of the sales, marketing, and executive teams on coffee walks.
  - commandlinefan 5y ago
    > weekly 30 minute standing meeting. I've been doing 30 minute standing meetings pretty much every day since the XP folks coined the term "stand up", which was about 20 years ago. Every single one has consisted of the boss talking for 28 minutes (sometimes back and forth with one team member) while everybody else stands around, followed by, "ok, does anybody else have anything?" If anybody says yes, it's "we're almost out of time for this meeting, so let's take it offline". 20 years, five different employers, exact same experience every time, every day. Human psychology doesn't fit this structure the way you want it to.

dahfizz 5y ago

Something really annoys me about developers acting like we are the only people on earth who have to think and focus to get work done. I'm not convinced programming is sufficiently different from any other skilled job. Whining about how your "flow state" can't be interrupted because of how extraordinarily creative and artistic you are is just pretentious.

deepsun 5y ago
Many other professions react strongly to interruptions. E.g. from what I know: writers and mathematicians react even strongly.
- pc86 5y ago
  The difference is that writers and mathematicians aren't typically expected to stand up every morning and explain to their colleagues and a manager who never did their job what they did yesterday, what they will do today, and what their roadblocks are. They're given a task and allowed to work for days, weeks, even months, with little or no interruption and largely self-guided. They're also not typically creating things directly that provide as much business value as developers are.
  - sirsinsalot 5y ago
    They also arent creating output that has to be simultaneously harmonic with other peoples work in an often quickly changing landscape.
  - hinkley 5y ago
    You can interpret Hemingway’s writing process such that he really could tell you what he did yesterday and what he’s going to do today. Not that I’m particularly fond of this current incantation of Agile.
- deleted 5y ago
  [deleted]
mjburgess 5y ago

skadamat 5y ago

I'm surprised Cal Newport's recent book, A World Without Email wasn't mentioned! https://www.amazon.com/gp/product/0525536558/ https://www.amazon.com/gp/product/0525536558/ He takes ideas from Deep Work and builds on them by scaling up the ideas to how an organization should work, coordinate, and collaborate. Specifically, he looks at how to build organizations that are designed to support how our brains have evolved to think & work (without frequent context switches!)

jedimastert 5y ago
I mean, I check my email twice a day, once at the beginning and once right after lunch. Not usually a disruptive context switch. It's why I usually prefer it.

G4BB3R 5y ago

Once in a cowork space we had the golden rule to never call someone that is on headphone, unless it is urgent. I miss that.

sumtechguy 5y ago
If I am 'in the zone' and someone walks up to me I hold up my hand and say 'wait a min I need to get this down'. Then I write a note to myself to myself back where I was. I then help them. If someone says 'can you come back later' I always respect it. I also sometimes just tell people 'not right now I will get back to you in a bit' and it works surprising well. But make sure you come back to them at some point or they will not respect it next time. My personal biggest issue is self interruptions. Mostly web sites that are distracting.

tengbretson 5y ago

Interruptions are so frustrating to developers in particular because their skills are in sufficiently high demand that they can behave like immature divas.

commandlinefan 5y ago
> can behave like immature divas I remember reading once that Mike Myers, while filming the movie "Wayne's World", came out of his dressing room, found that there was no non-dairy butter for his bagel on the catering table, flipped the table over in anger and returned to his dressing room for the rest of the day. That sounds like "immature diva" behavior to me. Saying "you want me to deliver the best product possible, and I want that too. In order to do that so that we can both come out ahead, I do my best when I can focus on making sure I get every detail right" seems far less immature. But maybe that's just me?
jk20 5y ago
You sound like a scrum master.

mkl95 5y ago

I work remotely 4 days a week these days. I only spend about 45 minutes a week in meetings, and interruptions are extremely rare. I'm happy and very productive. I have previously worked at places where I was interrupted several times a day, and I think it has a lot to do with a company's culture. Unfortunately, many companies in my country are dominated by sales people, and these people couldn't care less about software developers. Make sure you will be considered a first class citizen before accepting a job offer.

twodave 5y ago

I see this kind of rhetoric often, whether at work or here on HN. I think some important factors are typically left out, however: 1. Business value isn’t always a measure of coding velocity. Interruptions are often gifts in disguise. 2. The ability to work in a way that allows for interruption is a skill that can be learned. As a younger programmer who loved nothing more than to sling vast amounts of code, interruptions were killers. Over the years I’ve learned to recognize interruptions as opportunities to re-assess my priorities. I’ve also learned to write code in a way that reduces cognitive load so that interruptions aren’t so disruptive to my productivity. I’m not going to try and say these are universal principles or that any business can apply them, but as highly skilled workers I think this is an area where we tend to put in relatively little effort to overcome obstacles.

G4BB3R 5y ago
I agree with you, but that doesn't apply when someone interrupts in the middle of a thought.
sackerhews 5y ago
I'm interested in your point number 2. Do you have any links that back it up?
- hinkley 5y ago
  I don’t think XP could have worked at all without Refactoring, because everyone is sitting together and asking questions. With conventional coding, if your house of mental cards falls, you may potentially lose all of your work. By working from working code to working code, even if you lose your train of thought you get to keep most of your work so far. A number of other techniques also allow you to work more from working memory than memorization. This helps when writing code a little bit, but most of the payoff is for readers or subsequent additions. The thing with DRY is that code reuse means that a breakpoint most likely can fire from multiple paths, which makes it hard to trace why you’re getting null/undefined instead of an empty array as your second argument. Conditional breakpoints can help for some of these scenarios, but it’s better if the code in the middle of the call stack tries to be as contained and organized as leaf node methods eventually become. You can’t modify code if you can’t read it, and if it’s difficult to read then interruptions become more problematic, because both the cost of interruption and the likelihood of interruption go up when thinking time increases. The cleverest code is the code which is easiest to understand.

amozoss 5y ago

Wow thanks for the surprise in traffic this morning. Author here: I really wanted to illustrate the "why" it's frustrating. A more complete visual of what is actually in my head. Also I didn't get a chance to pull it out as much as I'd like, but I'm my own worst enemy when it comes to interruptions. So I broke my tips into 3 categories: 1. Protect against myself (2 tips) 2. Protect against day to day working cycle (1 tip) 3. Help teams work together to help each other (1 tip) hence why I catered 2 of the 4 tips to myself.

commandlinefan 5y ago
As I suspected, your post has brought a barrage of "deal with it" dissenters. This is as predictable as it is frustrating: the contrarians themselves seem to accept that an uninterrupted programmer is a better programmer and that an uninterrupted programmer will produce a better result - but they _still_ insist that we just deal with the (mostly unnecessary, non-value-add, easy to remove) interruptions anyway.
- amozoss 5y ago
  My hope was that it would cause self reflection on what types of interruptions are causing us the most grief. For example, in tip 3, I realized I obsessively check my business metrics to the point where I could never lay the foundation of a focus tower. So I decided to put it in a red tab group in chrome to remind myself not to go there.
MarkLowenstein 5y ago
I liked your suggested mitigations. Well-designed to accommodate human motivation, and simple enough to be practical.

kolbe 5y ago

I feel like this misses the point of why interruptions are frustrating to me. To me, I have so many things that I'm cramming into my short-term memory that I need to have access to while doing a certain task. If I'm in the middle of writing the contents of a loop, and then I note that I'm operating in row-major, and I need to go make sure that the inputs are row-major and that this is documented. So, instead of breaking my concentration on the loop itself, I just cache that knowledge and go back to it after I've finished the loop body. If I'm then interrupted, or worse, drawn away to something for a while, it's easy for that information to have fallen out by the time I return to finishing the code. I ultimately need to keep a log of every single task (even if I plan on doing it in a minute) in order to thwart this. I don't like it, but that's just what I have to do to keep from introducing "interruption bugs" in my code. I think another thing that is irksome is that the same people who are hounding you to finish some task in X amount of time are the ones making it go to 2X with their interruptions.

amozoss 5y ago
Author here: I totally agree! That's why I wrote tip number 4 "Record context as you go". I have a bash script that has the current command I'm working on (usually it's running a single test). I use it as a way to record notes and to quickly pick up where I left off.
- kolbe 5y ago
  Pen and paper for me! One big flaw is I occasionally can't read my own handwriting.
- euroderf 5y ago
  Also record context as the last thing you do before you go out the door at the end of the workday. Makes it much easier the next day to pick up where you left off. A quickie brain dump - a couple of lines, a couple of paragraphs.
hinkley 5y ago
There are tools that can help with reducing the amount of working memory you need, but it’s a bit like kerning, in that once you see it you can’t unsee it, and your peers won’t understand why you are upset with their work.

postalrat 5y ago

I think learning to work around interruptions is a skill that can be developed over time. Just watch some coding streamers on twitch. They can start and stop their coding while interacting with their viewers. In many ways it's the similar for gamers on twitch. Try holding a conversation while playing a game. Over time they learn to be good at both simultaneously. There are going to be some programming tasks that are harder to start and stop. But for most programmers those are going to be the exception.

warvariuc 5y ago
This applies only to routine tasks. Those coding a game while streaming, do a known type of app. But when you do something new, which requires focus, research, it's a different story. IMO.

loopz 5y ago

What did the developer do to avoid being interrupted, ie. why is it necessary for others to disturb said developer?

amozoss 5y ago
Author here: Glad you asked I laid out 4 tips that have helped me focus better. I purposely made 2 of the 4 tips directed directly at myself. I create the most interruptions to my day. My team has worked together to reduce unnecessary interruptions (see tip 1) as a courtesy to help me with my bad habits. The key point here is small interruptions are okay, but often not worth it, because I'll go off and do something else. If I could easily bounce back to what I was doing, I'd be much less frustrated at the interruption. My frustration lies with my inability to quickly go back to what I was working on, not the interruption itself. Notice that I'm not passing the blame at others, I know my weakness. If I open chrome to check Slack, I'm gonna check HN, I'm gonna look at my email. This is something I need to work on personally

TacticalCoder 5y ago

When I'm in the zone, here's something that happens: SO asks a question and somehow I hear the question but I don't process it, the question/event goes on some kind of stack. Then 5 or 15 minutes later I answer the question. External stimuli is simply processed differently. There can even be a phone ringing for minutes, driving SO and kiddo mad. Yet I don't hear it: or at least it doesn't disturb me. It even happens, rarely, that I get out of the zone and notice SO is gone and I'm a bit lost then I have to "focus" on the stack now: "ah yup, she said she went to pick her mom for she eats with us tonight". I honestly don't know how to describe that as something else than being in some kind of zone. I've seen friends studying for exams being in the same kind of state. I like being there and I'm convinced I'm doing better work when I'm there. EDIT: and there's something I do like in TFA: I separate my computer in "virtual desktops" assigned to different things. The main coding virtual desktop / workspace is ads-free for example (got a browser open but only for dev / for testing the (ad-free) thing I'm working on). I've got a "private email" virtual desktop, a "professional email" one (which is separate from the main coding virtual desktop), etc. It just makes sense to me.

euroderf 5y ago

The metaphor of the cards is spot on. But the Flow has its own Rhythm, and there are Very Bad times to interrupt and then there are Merely-OK times to interrupt. But what I found after many years of coding for a living is that the drive to reach a checkpoint and push context spills over into private life. I catch myself snarling at my SO if I'm not given a minute or two to finish whatever it is I'm in the middle of. Even when doing everyday things like making food or doing housework. Is this typical ? Is this sort-of OK, or just self-absorbed and conceited ?

thomastjeffery 5y ago

The frustration with interruptions is that they introduce a sudden increase in required working memory. It's the same frustration that people with ADHD experience regularly, because they have less available working memory in the first place. Managing an inadequate amount of short term memory - whether caused by a deficiency in memory or overload of stimulus - is done mainly by restructuring your surroundings so they don't interrupt you. Software development tends to be very appealing to neurodivergent people (including those with ADHD), so a strong distaste for interruption at work is to be expected.

dan_quixote 5y ago
> The frustration with interruptions is that they introduce a sudden increase in required working memory I've wondered the same - though never been able to put it into such concise words. I formerly worked as a Mechanical/Controls engineer and did not feel the same frustration with interruptions at the time despite being an equally challenging industry (as far as my experience went). My conclusion is that the hard constraints of a physical system keep the problem space (and thus the required working memory) relatively small in the physical world. When you're writing software that has no physical manifestation, the problem space is typically massive since the constraints are fewer.
screye 5y ago
> because they have less available working memory Tangential, but you contextualization ADHD as the lack of working memory is a light bulb moment for me. I was diagnosed with ADHD this year out of other suspicions. (I've always suspected it, but avoided getting diagnosed because I thought I would use it as an excuse for being lazy). My working memory also happens to be incredibly low, to the point that some of my friends call me a goldfish. (My long term memory is excellent in comparison) I never put two and two together, but it makes so much sense. I really should go for the long-overdue- prescription meeting I keep avoiding. :\
- thomastjeffery 5y ago
  > Tangential, but you contextualization ADHD as the lack of working memory is a light bulb moment for me. It was for me, too. I've recently been reading about ADHD and people's experience with it. I've always had my suspicions, but never in a serious enough context to make any decisions about it. Reading people's experiences feels like talking to a long lost friend from a parallel universe. I certainly have had opportunities to get an actual diagnosis, especially during my childhood, but the onus was always placed on me or my parents to take action. My parents were unmotivated by stigma and I was unmotivated by my ADHD symptoms. So here I am, 28 and trying to motivate my ADHD brain to navigate America's absurd - and unnecessarily confrontational - healthcare system so I can get a diagnosis and medication/therapy. > I really should go for the long-overdue- prescription meeting I keep avoiding. :\ I can't speak for the experience of people who have been using medication, but as someone who has spent decades without it, I would strongly encourage you to do that. Good luck getting your ADHD brain to do the follow through!

bryanrasmussen 5y ago

I don't mind interruptions, unless I've been working on something for a couple hours and I can't figure out what could be going wrong with it - then I'm a real jerk!

deleted 5y ago

[deleted]

atum47 5y ago

focus tower? what happened to train of thought?

gioele 5y ago

In far fewer words: https://heeris.id.au/trinkets/ProgrammerInterrupted.png https://heeris.id.au/trinkets/ProgrammerInterrupted.png

gdsdfe 5y ago
lool I got pissed just imagining this happening
amozoss 5y ago
Love it! I was really tempted to include this in my article, but it didn't quite fit since it's so tall :)
lou1306 5y ago
There is a very similar one wandering around the internet, e.g., here: https://twitter.com/boagworld/status/971328648048447490?s=20 https://twitter.com/boagworld/status/971328648048447490?s=20

SkyPuncher 5y ago

I have recently stepped back into the realm of dealing with leadership and executives. The juxtaposition relative to a bunch of recent programming has made me realize why leaders don't fully understand why interruptions are so difficult - the type of work is fundamentally different. * When dealing with Ops work or leadership, much of my work is thin and wide. In other words, I spend my time on a LOT of different things, but rarely need to deep dive. When I do need to deep dive, I'm looking at a timebox measured in hours. I can be interrupted because none of my thoughts are difficult to rebuild. * When I'm programming, I'm working thin and deep. I have a very narrow problem that requires diving into something very deeply. There are often a lot of little details that are potentially blockers. All of that needs to be in active thinking memory - or at least very close to it. When I get interrupted while programming, those auxiliary details go "poof". Sometimes they're hard, if not impossible to get back.

deleted 5y ago

[deleted]

karmakaze 5y ago

It's amazing when pair programming in-person with the same person for a couple weeks how easy it is to resume working state after an interuption or lunch break. Same goes for much less lull time being unproductive, even if not doing something else but unconsciously working quite slowly.

pontifier 5y ago

I need a 1 page synopsis that I can just post up everywhere and/or hand to someone every time they try to distract me. I'm in the mode where I can't even start programming anymore because interruptions have trained me it is useless to even try. I'm gradually trying to re-train myself to be productive, but it requires extreme measures.