3 ms·

What about embracing interruptions, in the spirit of anti-fragility? If you can't get back to coding productively after an interruption, it probably means that

by norswap 10y ago

What about embracing interruptions, in the spirit of anti-fragility? If you can't get back to coding productively after an interruption, it probably means that your code or your process isn't really up to snuff (or more charitably, that it could be improved). I try (and do not always succeed) in coding like this, privileging tiny changes, keeping a backlog of tasks to complete, avoiding "recursive tasks" (starting a task in the middle of another because it would help), putting in a lot of helpful comments. It also entails refactoring early and often, sometimes rewriting. I work on highly sophisticated programs (compilers) and if I didn't do that, I'd get nothing done. I also do this for my side-project. I optimize them for "re-starting". When I open them after a few weeks of inactivity, I don't want to get discouraged, and want to be able to start being productive as fast as possible.

gumoro 10y ago
Good point. While I still don't think this general idea can be applied universally, lately I've come to realize it can help a lot. But I feel I only have a blurry/incomplete understanding of what exactly "it" is or entails to, and would love to hear other ideas or insights. For now I have: - write down everything: tasks, discussions & conclusions, etc (you said "keep a backlog of tasks") - when interrupted while coding, insert a //TODO with a few words that will help rebuild context on resuming, maybe with a statement that does not compile to quickly get back there (if the interruption leads you to navigate away from that file/editor) - if a few seconds are not enough, explain "I need a few minutes to write down stuff and I'll get back to you". This is always accepted without issue. Although it's difficult when the person politely waits behind you :) - if you figure you really cannot be interrupted on the spot, make great effort to explain this as gently as possible, and offer to get back to them later: again, always accepted by peers (in my experience). If the interaction stays below a few seconds, AND I stayed agreeable & polite, I have little problem getting back in the flow. When I reply too curtly or let the slightest trace of anger show, then I fail to get back in, because my thoughts are polluted with remorse & guilt. - over time, learn to identify in advance when you are about to enter a "really-really-no-interrupt zone", and then wear audio gear or something to signal this. And don't do it too often. - I also noticed "recursive tasks" are a challenge. You suggest to avoid them when they are just ideas that help the previous task, but what if they are impediments that MUST be fixed? (Google "malcolm hal fixing light bulb" for hilarious illustration). For this I only have "write down everything", but it gets frustrating with the feeling I'm getting slow due to constant swapping, and could be faster if I could count on short term memory alone (and no interruptions...). Anwyay... would love to read more about "embrace interruptions" & "optimize for re-starting".
dntrkv 10y ago
I've never understood these complaints about being interrupted. Unless someone is walking over to your desk every 5 min, you should be able to handle the few interruptions you get in a day. Also this idea that a "layperson" doesn't understand why someone shouldn't be interrupted while in the middle of something is laughable. Like programmers are the only ones that concentrate.
- Nadya 10y ago
  Many professions have more `write` than `read`. You're doing more and not needing to keep everything in your head at once in order to understand what you are doing. As a cook you can clear your mind of steps that have already happened - you only need to worry about the next steps in the recipe and not everything that came before it. I don't have to worry about preheating the oven as I'm flipping something that is already in the oven. It has already happened - I can forget about it! Programmers can't forget about things that have already happened because those are the most important things to remember. I'd argue the closest profession would be lawyers. Lawyerese casts "variables" (collective) all the time and you need to remember what each collective means while reading through a verbose document that could span multiple pages and references itself constantly (see the exceptions listed in §2.7 and §4.2b). You have to keep the entire document in your mind at a single time to actually be able to read and understand it properly. The "layperson" understands not to interrupt a lawyer they see reading through a stack of 100 pages on their desk. They don't understand not to interrupt the coder who has 12 lines of code open in their IDE.
SomeStupidPoint 10y ago
Ive switched to using Pomodoro timers just for my own personal reasons. I find that constantly switching back and forth on a task forces me to be more explicit and keeps me fresher. It takes some adjusting, but I've found that I can do pretty high level stuff that way, and keep it in my head just fine as long as I schedule distractions. (Ex: I've recently been working through knot/tangle theory, to try and get up-to-snuff so I can work on higher dimension TQFTs.) It also lets me just ignore people who interrupt me during one with a quick "I'm busy, I'll be with you in (X<25)" or "Ask me in (X<25)". Sometimes the response they get during that break-time convo is that I'll get back to them even later, I need to think about it. But it's surprising how quickly people will pick up that if they bother you on the hour or half past, you'll respond and othertimes you'll blow them off.
dlwdlw 10y ago
I agree, while there certainly are tasks that can be similar to building a tower of cards, most programmers who have a no interruptions attitude come across as arrogant. This creates schisms for new developers and non-developers. Seeds of truth often grow cargo cults of self importance around them.

by norswap 10y ago

gumoro 10y ago

Good point. While I still don't think this general idea can be applied universally, lately I've come to realize it can help a lot. But I feel I only have a blurry/incomplete understanding of what exactly "it" is or entails to, and would love to hear other ideas or insights. For now I have: - write down everything: tasks, discussions & conclusions, etc (you said "keep a backlog of tasks") - when interrupted while coding, insert a //TODO with a few words that will help rebuild context on resuming, maybe with a statement that does not compile to quickly get back there (if the interruption leads you to navigate away from that file/editor) - if a few seconds are not enough, explain "I need a few minutes to write down stuff and I'll get back to you". This is always accepted without issue. Although it's difficult when the person politely waits behind you :) - if you figure you really cannot be interrupted on the spot, make great effort to explain this as gently as possible, and offer to get back to them later: again, always accepted by peers (in my experience). If the interaction stays below a few seconds, AND I stayed agreeable & polite, I have little problem getting back in the flow. When I reply too curtly or let the slightest trace of anger show, then I fail to get back in, because my thoughts are polluted with remorse & guilt. - over time, learn to identify in advance when you are about to enter a "really-really-no-interrupt zone", and then wear audio gear or something to signal this. And don't do it too often. - I also noticed "recursive tasks" are a challenge. You suggest to avoid them when they are just ideas that help the previous task, but what if they are impediments that MUST be fixed? (Google "malcolm hal fixing light bulb" for hilarious illustration). For this I only have "write down everything", but it gets frustrating with the feeling I'm getting slow due to constant swapping, and could be faster if I could count on short term memory alone (and no interruptions...). Anwyay... would love to read more about "embrace interruptions" & "optimize for re-starting".

dntrkv 10y ago

I've never understood these complaints about being interrupted. Unless someone is walking over to your desk every 5 min, you should be able to handle the few interruptions you get in a day. Also this idea that a "layperson" doesn't understand why someone shouldn't be interrupted while in the middle of something is laughable. Like programmers are the only ones that concentrate.

Nadya 10y ago
Many professions have more `write` than `read`. You're doing more and not needing to keep everything in your head at once in order to understand what you are doing. As a cook you can clear your mind of steps that have already happened - you only need to worry about the next steps in the recipe and not everything that came before it. I don't have to worry about preheating the oven as I'm flipping something that is already in the oven. It has already happened - I can forget about it! Programmers can't forget about things that have already happened because those are the most important things to remember. I'd argue the closest profession would be lawyers. Lawyerese casts "variables" (collective) all the time and you need to remember what each collective means while reading through a verbose document that could span multiple pages and references itself constantly (see the exceptions listed in §2.7 and §4.2b). You have to keep the entire document in your mind at a single time to actually be able to read and understand it properly. The "layperson" understands not to interrupt a lawyer they see reading through a stack of 100 pages on their desk. They don't understand not to interrupt the coder who has 12 lines of code open in their IDE.

SomeStupidPoint 10y ago

Ive switched to using Pomodoro timers just for my own personal reasons. I find that constantly switching back and forth on a task forces me to be more explicit and keeps me fresher. It takes some adjusting, but I've found that I can do pretty high level stuff that way, and keep it in my head just fine as long as I schedule distractions. (Ex: I've recently been working through knot/tangle theory, to try and get up-to-snuff so I can work on higher dimension TQFTs.) It also lets me just ignore people who interrupt me during one with a quick "I'm busy, I'll be with you in (X<25)" or "Ask me in (X<25)". Sometimes the response they get during that break-time convo is that I'll get back to them even later, I need to think about it. But it's surprising how quickly people will pick up that if they bother you on the hour or half past, you'll respond and othertimes you'll blow them off.

dlwdlw 10y ago

I agree, while there certainly are tasks that can be similar to building a tower of cards, most programmers who have a no interruptions attitude come across as arrogant. This creates schisms for new developers and non-developers. Seeds of truth often grow cargo cults of self importance around them.