> But I do think that you can improve your resilience to interruptions if you: > 1. Come up with a solution to a problem before you start writing code, and thi

> But I do think that you can improve your resilience to interruptions if you: > 1. Come up with a solution to a problem before you start writing code, and think about which parts of the system that solution will impact. The problem is, for me, that “come up with a solution” is the part that is at most risk of getting derailed by distraction. Writing the code, after I’ve come up wth a solution, is quite a minor aspect of programming for me (almost trivial, often). The hard part is understanding the problem, its contraints and requirements, the context within which it lives and all of the different things that I need to take into account to create a solution. That often takes a lot of working through things in my mind: visualising input data, transformations and output, visualising dependencies, simulating the algorithms and processes in my head. Determining what affects what and if that has any impact on something else. That’s the hard part. Actually coding it is usually not so hard nor is it usually particularly sensitive to interruptions.