4 ms·

Aside of the critique that already appeared there about the fact that if you believe that you suffer from being interrupted it does not mean at all that you thi

Aside of the critique that already appeared there about the fact that if you believe that you suffer from being interrupted it does not mean at all that you think you're any kind of special, there's one thing this note completely fails to mention. One of the most mentally demanding parts of programming (and the part that I personally enjoy the most) is debugging. In small, managable chunks it probably takes most of one's time, while the bigger sessions of finding a particularly nasty bugs are more rare, yet awfully demanding. You can't "come up with a solution to a problem before you start writing code" nor "divide the solution you came up with into small chunks", as your whole job there is to slowly unravel the interconnectedness of all things and produce a mental model of how the code works, how it should work and where the expectations differ from reality. It just requires a lot of concentration, just as any other job that suffers greatly from interruptions. (also, I fail to see how "come up with a solution to a problem before you start writing code" changes anything. You will still lose your train of thought when being interrupted while coming up with a solution before starting coding - and it will be even harder to justify being annoyed at interrupting party when you can't even show them your IDE on your screen :P)

mannykannot 9y ago
Divide-and-conquer approaches are very effective in debugging. When you are debugging, you don't break down the problem before starting the process; breaking it down is the process. With debugging, you have a concrete implementation and a specific problem to work with. In development, you have to try to anticipate every problem, and coming up with a concrete implementation is the goal, not a given. These complications, IMHO, make design ultimately harder than debugging. If your progress on something is dependent on a mental image that collapses with the slightest interruption, then you are working at the limits of your ability. To go beyond that, you need to be able to record what you know so that you are not limited by your mental working storage. I am interrupted by sleep every day, and the first thing I do the following morning is to review any notes I made on the previous day. Interruptions are certainly disruptive, but your claim that these techniques will not mitigate the problem does not mesh with my experience.
- seba_dos1 9y ago
  Your post matches what I meant - you don't do these mentioned things before doing "proper" work; your work is doing there things, so there's nothing to actually learn from the article. The interruptions will be just as painful (or not) for you as they were before reading it. Sure, notes are useful, but your mental representation of the issue is your cache. With lots of cache misses, you are much slower ;)
megaman22 9y ago
In a similar vein, trying to reconstruct a reported error from application logs or crash dumps is, in my experience, murderous when combined with interruptions. You're trying to piece together why this unexpected error occurred, cross-checking source code, multiple log files, screenshots, and fragmentary narratives provided with the report, to build a mental model of what the state of the system was when things went south. Then somebody pings you with some completely unrelated urgent thing, and poof! goes your mental model out of working memory.

mannykannot 9y ago

Divide-and-conquer approaches are very effective in debugging. When you are debugging, you don't break down the problem before starting the process; breaking it down is the process. With debugging, you have a concrete implementation and a specific problem to work with. In development, you have to try to anticipate every problem, and coming up with a concrete implementation is the goal, not a given. These complications, IMHO, make design ultimately harder than debugging. If your progress on something is dependent on a mental image that collapses with the slightest interruption, then you are working at the limits of your ability. To go beyond that, you need to be able to record what you know so that you are not limited by your mental working storage. I am interrupted by sleep every day, and the first thing I do the following morning is to review any notes I made on the previous day. Interruptions are certainly disruptive, but your claim that these techniques will not mitigate the problem does not mesh with my experience.

seba_dos1 9y ago
Your post matches what I meant - you don't do these mentioned things before doing "proper" work; your work is doing there things, so there's nothing to actually learn from the article. The interruptions will be just as painful (or not) for you as they were before reading it. Sure, notes are useful, but your mental representation of the issue is your cache. With lots of cache misses, you are much slower ;)

megaman22 9y ago

In a similar vein, trying to reconstruct a reported error from application logs or crash dumps is, in my experience, murderous when combined with interruptions. You're trying to piece together why this unexpected error occurred, cross-checking source code, multiple log files, screenshots, and fragmentary narratives provided with the report, to build a mental model of what the state of the system was when things went south. Then somebody pings you with some completely unrelated urgent thing, and poof! goes your mental model out of working memory.