I think that you make a very important point about discontinuity. It made me think about how I could reduce the inertia of refamiliarization when I resume editi

I think that you make a very important point about discontinuity. It made me think about how I could reduce the inertia of refamiliarization when I resume editing some program after some interruption. I find that I can concentrate for about four hours before my ability to maintain a mental model of the salient aspects of whatever subsystem I am modifying break down and I start to make unconscious mistakes that I fail to notice due to the effort required to direct my little remaining drip of concentration on those aspects that were associated with the initial goal. I suppose one could estimate how much time it would take to make a given change and only attempt it if you knew that you had an ample block of time to complete it without pause, but I somehow feel that this is wishful thinking and that you don't necessarily know what you are getting yourself into when you resume editing some part of a complex system. Those prone to procrastination will find that the advice to "do a little every day" isn't all that helpful if the task requires the previous day's (partially unfinished) changes to be comprehended before you can pick up where you left off, mental model now reconstructed. There is also a temptation to rewrite this unfinised, untested, undebugged code as unentangled, "fresh", code is easier to write than that which is burdened with interdependencies, observed protocols, ceremony and context-dependent assumptions. Without refamiliarization there is a danger of blundering blindly into damaging changes with subtle, far reaching repurcussions, due to your naive comprehension of the system dynamic. Given that refamiliarization is exhausting, I wondered if there were remedies that could reduce the time and effort it required each day: * Allow the visualisation of the project with a number of domain specific Projectional Editors - derived from an Abstract Syntax Tree * Use SSA symbolic variables - imperative programs are hard to understand because they support the reassignment of named data cells * If you have to have state defer changes to a globally synchronised Superstep - also support the Command/Query Separation Principle * Use a live programming debugger to play with the system and refamiliarise yourself with its dynamical behaviour in a safe sandbox * It may help to use a language that scores well on the Halstead complexity measure to reduce overall development effort - Python * Use a WHY directed outline for code - that explains its goals through a folding text editor that supports literate programming * Avoid fragile base classes - there is very little point having encapsulation if you hack the heritage of an object's genealogy * Use Go style interfaces If all that fails: * Revert to the previous working version and redo up to the point of interruption or pause - as it's easier to write entangled stuff I welcome anyone's opinions on these suggestions, or suggestions of their own...