Every working system carries two histories. One is the history people tell out loud: the first release, the rewrite, the clever decision taken at exactly the right moment. The other is the history nobody writes down, and it is a long, patient record of small repairs that kept the first history true. The second one is the real account, and it is almost entirely made of maintenance.
Maintenance has a presentation problem. It produces nothing to announce, it photographs badly, and the better it is done the less there is to see. A dependency brought up to date on a quiet Tuesday. A log line made legible. A confusing message rewritten so that the next person does not lose an afternoon to it. None of that will appear in anybody's summary of the year. Leave it undone for eighteen months, though, and the system that looked so assured on the day it shipped becomes the one nobody volunteers to touch.
What strikes me is how much judgement the work actually asks for. Repairing something is frequently harder than making it, because the person repairing it did not choose the constraints. They inherit a decision taken three years ago by someone who had good reasons and no time to record them. They have to reconstruct the reasoning, work out which parts of it still hold, and then change precisely as much as is needed and not a line more. That is engineering in its strictest sense: establishing what is load bearing before you remove anything.
There is a useful test for a team, and it has nothing to do with speed. Ask what happens when something fails at an awkward hour. In a healthy team the answer is dull. Somebody reads an error that says in plain language what went wrong. Somebody finds the short note left by whoever met the same problem last spring. The repair takes twenty minutes and a paragraph written up afterwards. In an unhealthy team the same question produces a story, and stories of that kind are expensive.
Maintenance also shapes what gets made next. Teams that carry their own repairs design more carefully, because they know exactly who will be answering the telephone. They pick plainer tools. They write the instructions while the reasons are still fresh. They decline the extra feature that would be delightful for a week and awkward for a decade. None of that registers as output in a quarter, and all of it registers over five years.
It changes who is willing to join, too. Careful engineers can read a codebase the way a surveyor reads a roof. They can tell within a morning whether a place respects the work of keeping things upright, and they make their decisions accordingly.
The habit worth copying is modest. Treat the repair log as a design document. Give the unglamorous work the same standing in a review as the new thing. Thank the person for the fix that nobody noticed, because nobody noticing was the entire point of it.
Nicole Junkermann keeps the shorter observations in the tech notes and the working jottings in the notebook. The companion piece on the unglamorous work of October makes the seasonal version of the same argument, and fewer things, finished properly is where the autumn planning begins.