Document everything and document first
Reflections on the usefulness of documentation, in life and code.
Document everything and document first
Dear Young Tim,
Happy New Year and welcome to 2021! As with every new year, January has brought a flurry of change. And with change comes growing pains.
Specifically, both at work and at home, I experienced a series of intermittent, system failure incidents. These incidents were caused by both changing circumstances and lack of sufficiently robust preventative measures. Moreover, the failures have been widespread, including everything from home plumbing systems, to time management systems, to software systems. As the old saying goes, “when it rains, it pours.”
When responding to the simultaneous failure of many systems, what I often need the most is to know an algorithm: (1) what to do, and (2) step-by-step instructions of how to do it. Indeed, when the spout in my bathroom is leaking heavily, all I want is to know how to fix it—quickly.
Curiously, the need for knowing what and how to do things exists outside of incident response. For instance, to collaborate well with others, it’s helpful if I am clear about what I will do and how I will do it. Likewise, to successfully delegate a task to someone else, both I and the person doing the task need to be completely clear on what the task entails and how it should be done.
Even when only considering how I work, as opposed to how I work with others, it is helpful to be clear about what I should do and how I do them. In particular, if I want my products and services to be of high quality, by default, then I likely need to standardize my processes around pre-determined methods that yield high quality results. Similarly, if I want to accurately plan my time and projects, standardizing around a set of procedures for what and how to do something allows apples-to-apples comparisons and estimates of how long that and similar tasks will take in the future. And finally, if I want to improve my process for doing something, having a standardized process simplifies matters greatly compared to an erratic process. It’s hard to tell signal from noise when the variance is high!
Young Tim, you will always deal with problematic systems; you will always accomplish more by working with others than alone; and you will always be busy planning and trying to improve yourself. Accordingly, you should meticulously record the procedures for all tasks that are necessary for the correct functioning of any systems that you are responsible for.
Why? Because if you document the algorithms and procedures for doing everything needed to keep your systems working, then you can live with greater peace knowing that when something breaks, you’ll have knowledge to fix it. Additionally, you’ll be more excited about life when you can take an otherwise abstract process that isn’t working well, and visibly transform it into a process that you expect to be better. Finally, if you diligently make use of your documented procedures and if you track your time while doing so, then you’ll be able to make better decisions and plans because you will have more usable information (i.e. standardized / cleaned) and more useful information (i.e. apples-to-apples with less missing data).
Okay if above sounds reasonable and you want some lighthearted reinforcement, or if you want a pictorial, minimal-word TL;DR, see the following presentation:
Lastly, see the following template for writing how-to guides as a starting point for documenting your own procedures and algorithms.
Till next time,