A very strange thing happens when you have been in the business of software development for more than thirty(!!) years and when you subsequently (re-)encounter your own source-code (in whatever language it may be)...
It is: the work of a magnificent stranger.
On the one hand, you recognize it to be excellent and thorough work. On the other hand, you do not recognize it as your work at all.
No matter what sort of work we are doing, and no matter in what context, there is always a combination of “concerns” that present themselves to us ... and they are indeed very different:
- Temporal concerns: In order to “get the job done,” at this particular moment with this particular tool (be it Perl or what-have-you...), these are “the immediate concerns of the moment and of the context.” These are “the hoops that I am obliged right-now to jump through, just in order to Get The Job Done.™”
- Universal concerns: It does not matter one whit what language I am using at the moment ... in order to solve “this sort of problem,” I must attend to “this.”
When we are writing computer software “in the language, in the moment,” we naturally tend to become absorbed in the first group of concerns. But, my Meditation is, perhaps we ought to be more concerned with the second group.
I shall simply take it for granted that anyone to whom I am speaking “routinely” shifts his or her attention during the course of any particular day i(a)/i between any one of several different programming languages, and i(b)/oi between software that is new and familiar, and software that is old and decidedly not.
“Temporal” concerns, as we well know by now, might be swept-away by a mere “vendor software upgrade.” Someone out there up-and-decides that “the old way” is oldy-moldy and that “the new way” does everything including the making of Julienne Fries, and ... suddenly, we have lots of work to do. Meanwhile, the (Universal...) purpose of the application has not changed one whit.
Temporal concerns, we also know all too well, can simply be erased by memory. All of us have only so much capacity between our ears, and as we grow older we become more and more aware of just how small that space can be. We switched-away from project-X, which we wrote, to project-Y, which we also wrote, and now we must switch back, and ... (!!!)
What, then, can we do with a project, “as we leave it behind,” to make it somehow less “the work of a stranger” when we are obliged to take it up again?
Another, equally valid, way of looking at this problem is as follows. When we set the problem aside the first time, we did so because at that time we thought it was “complete.” And so, the reason why we are now taking it up again at a later date is because those requirements have now changed.” Given that this, indeed, is a fact of business life ... what ought we have done, when writing the code the first time, to expedite the process of re-preparing ourselves to make proper changes to it, some (months|years) later?