4 ms·

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 ta

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
bob1029 5y ago
Taking notes is the superweapon for mitigating distractions in my experience. It doesnt eliminate the immediate impact, but it allows you to get back to a productive state so much more quickly. As a team leader in a 7 person company, I am not entitled to any degree of dedicated focus time during the work week. Everything is ultimately my responsibility and I have to answer some important questions immediately. Being aware that you are going to be disrupted and building in some mechanisms to deal with this reality is probably the more practical path. Trying to convince your PMs that distractions are lethal and that developers need to be protected in some anechoic chamber 8 hours a day is never going to fly. It is total fantasy. I personally try to minimize the distractions that I as a developer incur upon other developers, but I cannot change the natures of other team members or artificially inhibit their interactions. People are just going to have to learn to get along and develop boundaries naturally. Don't be afraid to stand up for yourself, but also realize you are almost certainly not a special unicorn and that eventually you will have to interact with your teammates (the ones who don't browse HN) for the business to extract any value out of you. An additional strategy is to try and decompose your work effort into smaller steps before you begin. Trying to eat the whole elephant in 1 sitting is how you wind up in a lot of these "interrupted" situations to begin with.
jpeloquin 5y ago
If I'm interrupted while I have a lot of unstructured thoughts floating in short-term memory, I try to ask for a "couple seconds" and scribble down some key words on a post-it before switching attention. Looking at the post-it later brings most everything back.
beaugunderson 5y ago
I do this so often just by adding temporary comments in the code and files that I'm debugging. If I get interrupted I can just `git diff` and see the entire chain of files that got me where I was. When the problem is solved, I just `git checkout -p` and discard any of the temporary comments while keeping whatever the fix was (or inverting this, with `git add -p` and then `git checkout`).

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

bob1029 5y ago

Taking notes is the superweapon for mitigating distractions in my experience. It doesnt eliminate the immediate impact, but it allows you to get back to a productive state so much more quickly. As a team leader in a 7 person company, I am not entitled to any degree of dedicated focus time during the work week. Everything is ultimately my responsibility and I have to answer some important questions immediately. Being aware that you are going to be disrupted and building in some mechanisms to deal with this reality is probably the more practical path. Trying to convince your PMs that distractions are lethal and that developers need to be protected in some anechoic chamber 8 hours a day is never going to fly. It is total fantasy. I personally try to minimize the distractions that I as a developer incur upon other developers, but I cannot change the natures of other team members or artificially inhibit their interactions. People are just going to have to learn to get along and develop boundaries naturally. Don't be afraid to stand up for yourself, but also realize you are almost certainly not a special unicorn and that eventually you will have to interact with your teammates (the ones who don't browse HN) for the business to extract any value out of you. An additional strategy is to try and decompose your work effort into smaller steps before you begin. Trying to eat the whole elephant in 1 sitting is how you wind up in a lot of these "interrupted" situations to begin with.

jpeloquin 5y ago

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

beaugunderson 5y ago

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