Software as Craftsmanship: Finding Pride in the Unseen Backend

A pull request I opened last month changed four lines. The diff was a connection-pool size and a retry cap on a worker that talks to a third-party CAD service. The description under it ran twelve paragraphs: why the old cap of zero meant a stuck job retried forever and pinned a Swoole worker, how I found it, what I measured before and after, and the two fixes I considered and why I took the smaller one.

Nobody outside the team will ever read that PR. The CAD upload still takes the same three seconds it took before. From the outside, nothing happened. The work mattered and left no trace. That gap is what I want to write about.

Backend work is unseen by design. When a queue drains cleanly, when a Redis key expires on the right schedule, when a Postgres query that used to do a sequential scan starts hitting the index, the reward is that nobody notices. The user clicks the button and gets their answer. They never feel the difference between a 40ms response and a 900ms one until the 900ms one shows up, and then they only feel annoyance. They never feel its absence on the good days. You are paid, in part, to produce nothing visible.

I learned the shape of this in aerospace, where the standard is the same. A 737 walkaround is a checklist of things you hope to find boring. Tire wear, hydraulic lines, pitot covers stowed, no fuel weeping at the wing root. A good inspection produces no story. The reward for doing it well is an uneventful flight, which feels like the inspection did nothing. The mechanic who torques a B-nut to spec and safety-wires it gets no thanks from passengers, who never learn the part exists.

So pride has to come from somewhere other than applause. For me it sits in the part of the work that has a right answer and a wrong one, where I can know which I produced. The retry cap is correct or it is not. The lock around a distributed job either prevents the double-run or it does not, and I can prove which by reading the code and the logs, not by waiting for a complaint. That is a cleaner kind of satisfaction than shipping a feature, because a feature can succeed for reasons that have nothing to do with whether I built it well.

The trap is that unseen work invites cutting. If nobody will notice the index, nobody notices its absence either, for a while. That pool setting sat wrong for months because the system mostly worked. The discipline is to do the part that has no witness: write the migration so it reverses, name the queue so the next person knows what is in it, handle the timeout you are fairly sure will never fire. I handle it because I have watched the never-fire path fire, and the distance between a logged, caught failure and a silent corrupt write is most of the job.

I stopped trying to make this work visible. For a while I wanted credit, wanted the pool fix to land somewhere a manager would see it. That want made me write worse code, because I was building for the demo instead of the system. The code got better when I let it stay invisible and moved the judgment inward.

One thing you can change. Next time you open a pull request that touches almost nothing on the surface, write the description for one reader: yourself in a year, staring at this exact line the day it finally breaks, with no memory of why it was written. Put the measurement in. Put the option you rejected in, and why. That paragraph is where the unseen work becomes legible to the one person who will need it, and you keep it whether anyone else reads it or not.