By day I build hospital software. Most of what I do will never be seen by anyone outside my team: a fix to a data import that quietly stopped failing, a migration that went so smoothly nobody remembers it happened, a review comment that stopped a bad pattern spreading. By evening I write in public. A post takes me a few hours and can reach more people in a day than my best code will ever touch directly. Only one of those shows up when someone searches my name. So which one is the real work? It is tempting to pick a side, and plenty of people do, loudly. I think both sides are partly right, and the more interesting question sits underneath them. Researchers have been poking at that question for decades, in car factories, hospitals, universities and open source mailing lists, and what they found is more useful than either side's slogan. The case for the buried builder Some of the most important engineering work is invisible by design. When it goes well, nothing happens. No outage, no incident, no story to tell. The engineer who spends three weeks making a payment flow idempotent has prevented a disaster that will never be written about, because it never occurred. In 2001, two MIT researchers, Nelson Repenning and John Sterman, studied why process improvement programmes kept failing in manufacturing and product development. Their paper took its title from something an engineer at a car company told them: "Nobody ever gets credit for fixing problems that never happened." What they found was a loop. Organisations that rely on firefighting end up rewarding and promoting the people who save the day through heroic effort, rather than the people whose quiet improvement work means there is no fire to fight. Over time, they