5 ms·

> Developers can’t easily go back to where they were right > before an interruption. They need to get into the mindset > for development and then slowly trace

> Developers can’t easily go back to where they were right > before an interruption. They need to get into the mindset > for development and then slowly trace back to where they > left off. And every fellow developer knows that. I used to think like that too, but after 10 years programming in many environments, now I'm inclined to disagree. If I cannot refocus immediately after interruption - I know I'm doing something wrong. Maybe the thing is too complex and must be cut down to smaller pieces, maybe I didn't keep enough notes or thinking through - anyhow nowadays I cannot work without a clear understanding of what simple piece of what complex piece I'm doing and where I've written down the other pieces I should do next.

hnbroseph 8y ago
> Maybe the thing is too complex and must be cut down to smaller pieces i suspect that for many, it's not necessarily their fault Thing is 'too complex' (though perhaps this is tangential); nor are they necessarily provided the opportunity, time or even permission to 'cut down to smaller pieces'. piles of work, looming deadlines and all that.
ianstallings 8y ago
One of the things I do to offset possible interruptions is to write things out or visualize them in some way. It helps me pick back up on the track I was interrupted from, but also has the added benefit of helping visualize the problem, which often leads to a greater understanding. It's a little bit of overhead that can pay off.
lolc 8y ago
To me that just sounds like you don't have tasks that require deep thought. And that you've developed habits to cope with interruptions, such as note-taking. To turn a complex thing into a list of simple things can be done by experience as well as by deep thought. But don't think you could get that experience in 5-minute chunks of thinking. To get the experience you need deep thought. Maybe set your sights higher if it's all easy to you? Or enjoy the fruits of experience, of course.
- stcredzero 8y ago
  To me that just sounds like you don't have tasks that require deep thought. If everything you do requires deep thought, this is possibly a sign of bad code design.
  - Insanity 8y ago
    Not _everything_ but a large part of what I do does involve rather deep thought. But indeed, what helps me is to pick one of the things that is easy to 'refocus'.
    - stcredzero 8y ago
      Not _everything_ but a large part of what I do does involve rather deep thought. Anyone's ability to think deeply and pull out feats of clever is a limited resource. A well designed project tries to optimize this. Think of it as martial arts. It's good to be strong. The techniques are there to use your strength more efficiently. I was once in an Aikido class with someone who lifted. He had to constantly remind himself to use the technique and not just strength. (As Ramsey Dewey likes to point out, technique plus strength is pretty darn awesome.)
  - lolc 8y ago
    Haha, could be yes. And at the opposite end: If everything I do can be achieved without thinking hard I'll be replaced with a tiny shell script written by someone who does.
    - stcredzero 8y ago
      https://xkcd.com/1445/ https://xkcd.com/1445/
stcredzero 8y ago
If I cannot refocus immediately after interruption - I know I'm doing something wrong. This can be a sign that code needs to be reorganized. I've seen a number of really good coders in their 20's who are admirable for brilliant insights. However, they fall into this pattern of thinking of themselves as invincible, and they take on tasks where they are doing the "heavy lifting" of remembering tons of details all at once. If you can lift 400 X's by hand, then you could easily lift 4000 X's with the right tool. One of my bosses kept a stack, explicitly, and used that to keep track of his excursions into sub and side tasks. I used to say that being a good programmer was being a professional forgetter as much as a professional memorizer. Basically, you should be constantly reorganizing your code as you go, so that there's no danger that forgetting a detail will result in an error. In a way, it's like people who work on high platforms who take precautions so that one drop or one slip won't result in injury or fatality. In other words, work smarter, not harder.
neilv 8y ago
Being able to reliably refocus after interruptions is an enviable skill. I've learned some of that (especially when I was an intern divided 50/50 between development and interrupt-driven sys-admin :), but for me, interrupt cost seems to vary widely with the demands of the task and the nature interruption. Web/GUI front-end work is usually very interruptible for me, for example. Usually, most of the time, I have in mind "I want to get to roughly this, and I just need to spend time getting or making the tools get there", and it's often easy to see where I left off. Coding seems usually mostly proceeding along a series of small tasks ("those controls are done, and next is that control"), or iterative refinement ("these two elements could be combined", or "this part of the layout is poor when rotated"), which are often very visible, and easy to get into. However, if, for example, I'm in the middle of designing an algorithm, and trying to cover every case in a good form, and trying see opportunities, and I've mentally "paged in" a lot of domain-specific information and scenarios and such... an interruption at that moment with something that requires a very different domain to be paged in, and substantial thought... could really ruin the roll I was on with the algorithm. Even if I have a tentative skeleton with quick comments sprinkled through it, for the current thinking and known questions/opportunities. I'm simply not smart enough that I can't sometimes lose something with a big interruption at the wrong moment. There's also the theory and meme of "flow" [1], but I don't understand it well enough to say whether it covers the impressions above. [1] https://en.wikipedia.org/wiki/Flow_(psychology) https://en.wikipedia.org/wiki/Flow_(psychology)
ozim 8y ago
I agree, right now I find it hmm weak excuse. If someone is junior then OK, but if someone is claiming 5yrs of experience I am not getting those kind of excuses from that person.
munchbunny 8y ago
I've found that the issue of re-acclimating to context has more to do with the quality of my notes than with the complexity/simplicity of the question. In the course of figuring out something complicated, it's sort of like a tree traversal. If I take good notes on the leaf nodes I need to fill out, then it's easy to just resume right at the leaf node. If I don't take good notes, I have to retrace the rest of the tree.

hnbroseph 8y ago

> Maybe the thing is too complex and must be cut down to smaller pieces i suspect that for many, it's not necessarily their fault Thing is 'too complex' (though perhaps this is tangential); nor are they necessarily provided the opportunity, time or even permission to 'cut down to smaller pieces'. piles of work, looming deadlines and all that.

ianstallings 8y ago

One of the things I do to offset possible interruptions is to write things out or visualize them in some way. It helps me pick back up on the track I was interrupted from, but also has the added benefit of helping visualize the problem, which often leads to a greater understanding. It's a little bit of overhead that can pay off.

lolc 8y ago

To me that just sounds like you don't have tasks that require deep thought. And that you've developed habits to cope with interruptions, such as note-taking. To turn a complex thing into a list of simple things can be done by experience as well as by deep thought. But don't think you could get that experience in 5-minute chunks of thinking. To get the experience you need deep thought. Maybe set your sights higher if it's all easy to you? Or enjoy the fruits of experience, of course.

stcredzero 8y ago
To me that just sounds like you don't have tasks that require deep thought. If everything you do requires deep thought, this is possibly a sign of bad code design.
- Insanity 8y ago
  Not _everything_ but a large part of what I do does involve rather deep thought. But indeed, what helps me is to pick one of the things that is easy to 'refocus'.
  - stcredzero 8y ago
    Not _everything_ but a large part of what I do does involve rather deep thought. Anyone's ability to think deeply and pull out feats of clever is a limited resource. A well designed project tries to optimize this. Think of it as martial arts. It's good to be strong. The techniques are there to use your strength more efficiently. I was once in an Aikido class with someone who lifted. He had to constantly remind himself to use the technique and not just strength. (As Ramsey Dewey likes to point out, technique plus strength is pretty darn awesome.)
- lolc 8y ago
  Haha, could be yes. And at the opposite end: If everything I do can be achieved without thinking hard I'll be replaced with a tiny shell script written by someone who does.
  - stcredzero 8y ago
    https://xkcd.com/1445/ https://xkcd.com/1445/

stcredzero 8y ago

If I cannot refocus immediately after interruption - I know I'm doing something wrong. This can be a sign that code needs to be reorganized. I've seen a number of really good coders in their 20's who are admirable for brilliant insights. However, they fall into this pattern of thinking of themselves as invincible, and they take on tasks where they are doing the "heavy lifting" of remembering tons of details all at once. If you can lift 400 X's by hand, then you could easily lift 4000 X's with the right tool. One of my bosses kept a stack, explicitly, and used that to keep track of his excursions into sub and side tasks. I used to say that being a good programmer was being a professional forgetter as much as a professional memorizer. Basically, you should be constantly reorganizing your code as you go, so that there's no danger that forgetting a detail will result in an error. In a way, it's like people who work on high platforms who take precautions so that one drop or one slip won't result in injury or fatality. In other words, work smarter, not harder.

neilv 8y ago

Being able to reliably refocus after interruptions is an enviable skill. I've learned some of that (especially when I was an intern divided 50/50 between development and interrupt-driven sys-admin :), but for me, interrupt cost seems to vary widely with the demands of the task and the nature interruption. Web/GUI front-end work is usually very interruptible for me, for example. Usually, most of the time, I have in mind "I want to get to roughly this, and I just need to spend time getting or making the tools get there", and it's often easy to see where I left off. Coding seems usually mostly proceeding along a series of small tasks ("those controls are done, and next is that control"), or iterative refinement ("these two elements could be combined", or "this part of the layout is poor when rotated"), which are often very visible, and easy to get into. However, if, for example, I'm in the middle of designing an algorithm, and trying to cover every case in a good form, and trying see opportunities, and I've mentally "paged in" a lot of domain-specific information and scenarios and such... an interruption at that moment with something that requires a very different domain to be paged in, and substantial thought... could really ruin the roll I was on with the algorithm. Even if I have a tentative skeleton with quick comments sprinkled through it, for the current thinking and known questions/opportunities. I'm simply not smart enough that I can't sometimes lose something with a big interruption at the wrong moment. There's also the theory and meme of "flow" [1], but I don't understand it well enough to say whether it covers the impressions above. [1] https://en.wikipedia.org/wiki/Flow_(psychology) https://en.wikipedia.org/wiki/Flow_(psychology)

ozim 8y ago

I agree, right now I find it hmm weak excuse. If someone is junior then OK, but if someone is claiming 5yrs of experience I am not getting those kind of excuses from that person.

munchbunny 8y ago

I've found that the issue of re-acclimating to context has more to do with the quality of my notes than with the complexity/simplicity of the question. In the course of figuring out something complicated, it's sort of like a tree traversal. If I take good notes on the leaf nodes I need to fill out, then it's easy to just resume right at the leaf node. If I don't take good notes, I have to retrace the rest of the tree.