4 ms·

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 ne

by 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.
solipsism 5y ago
// FIXME(properly document this is row major) Rig up a precommit hook that rejects changes containing the string "FIXME" That simple technique doesn't solve everything, but it goes a long way.

by kolbe 5y ago

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.

solipsism 5y ago

// FIXME(properly document this is row major) Rig up a precommit hook that rejects changes containing the string "FIXME" That simple technique doesn't solve everything, but it goes a long way.