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 wrote, senior management increasingly consists of these “war heroes”. The system does not just ignore prevention. It selects against it.
Healthcare has been wrestling with the same pattern. Patient safety has traditionally been managed by counting what goes wrong and stamping it out. The resilience engineering researchers Erik Hollnagel, Robert Wears and Jeffrey Braithwaite call this Safety-I, and they have argued for a shift to Safety-II: moving from making sure “as few things as possible go wrong” to making sure “as many things as possible go right”. Their most quoted line deserves a spot above every engineering team’s desk: given how complex the work is, “the surprise is not that things occasionally go wrong but that they go right so often.” The catch, as one patient safety researcher put it, is that measuring success is harder than measuring failure. Software has the same problem. We have dashboards for incidents. We have nothing for the ten thousand ordinary days when nothing broke because someone was careful.
These developers also carry context no talk can capture. They know why the retry logic has that strange delay, which customer depends on the undocumented field, what broke the last time someone touched the scheduler. That knowledge is load-bearing, and it lives in people who rarely have time to explain it to anyone outside the building.
Open source shows what happens when that knowledge sits with one person and nobody is watching. In 2014, the Heartbleed bug exposed a flaw in OpenSSL, the library that secures a huge share of web traffic. The project, it emerged, had one full-time developer and took in less than $2,000 a year in donations. Within weeks, Amazon, Google, Microsoft, Facebook and others committed millions to a new fund for critical open source projects. It took a near-catastrophe to make the work visible enough to pay for.
Ten years later it nearly happened again. XZ Utils, a compression library found on almost every Linux system, had been maintained by one person, Lasse Collin, since he wrote it in 2009. In 2022 he wrote on the project’s mailing list that his ability to care had been “fairly limited mostly due to longterm mental health issues”, adding: “It’s also good to keep in mind that this is an unpaid hobby project.” Accounts that were almost certainly fake pressured him to hand over control. A helpful new contributor, “Jia Tan”, gained his trust, became a maintainer and spent the following year planting a backdoor in the software. It was caught in March 2024 by Andres Freund, a Microsoft engineer who, in his spare time, noticed the new version was using more processing than it should. One invisible worker, burnt out. Another, curious. That was the margin.
These were not a couple of unlucky projects. In Tidelift’s 2024 survey of 437 open source maintainers, 60% said they were not paid for their work, and almost 60% had quit or considered quitting. Unpaid maintainers were also more likely to be working alone.
And the measurement systems around builders mostly miss it. Promotions, job offers and reputations lean on what can be seen and counted. A conference talk is countable. A follower number is countable. “The system did not fall over this year” is not, even when it is the most valuable thing that happened.
So the builders have a fair grievance. A lot of real effort goes unrecognised simply because it does not produce anything people outside the team can point to.
Invisible work is not evenly distributed
There is a second layer to the builder’s grievance: who ends up doing the invisible work in the first place.
In 2019, Tanya Reilly gave a talk called “Being Glue” that named something many engineers recognised straight away. Glue work is the onboarding, the roadmap updates, the questions on design documents, the noticing of things that got dropped. It is “the less glamorous, and often less-promotable, work that needs to happen to make a team successful.” Her warning was blunt. Managed deliberately, glue work builds technical leadership. Left unconscious, “it can be career limiting. It can push people into less technical roles and even out of the industry.”
Economists have measured this. Linda Babcock, Lise Vesterlund and colleagues ran experiments on who takes on tasks that everyone wants done but nobody wants to do. In mixed-gender groups, women volunteered roughly 50% more often than men, and both men and women were more likely to ask women to do them. In single-sex groups the gap disappeared, which suggests it comes from expectations, not preference. In one professional services firm they studied, women logged 200 more hours a year on non-promotable work than men.
So “good work gets noticed eventually” is not just optimistic. It costs some people more than others.
The case for the public developer
But the dismissive version of this argument, that speakers are all talk, falls apart quickly.
Many of the developers you see on stage are deep builders. The talk exists because they solved something hard and then did a second hard thing: they made it understandable. Anyone who has tried to explain a gnarly production problem to a room of strangers knows clarity is its own skill. You have to strip the problem to its essence without lying about it, anticipate the questions, and survive the person in the third row who knows more than you.
Tanya Reilly’s talk is the best example. Glue work existed long before she named it. Thousands of engineers were doing it, unseen. One person on a stage giving it a name did more to get that work recognised than years of it being done quietly. I would not call that all talk. I would call it leverage.
Public work also scales in a way private work cannot. A fix inside one company helps one company. A clear write-up of how that fix works can save weeks for thousands of teams who will never know your name. In Stack Overflow’s 2024 developer survey, 82% of developers said online resources were how they learned to code, with technical documentation (84%) and Stack Overflow (80%) the most used. Every one of those answers, docs pages and write-ups exists because somebody chose to explain their work instead of just doing it. Some of the most useful things I have learned as an engineer came from people like that. If they had kept their heads down, I would have paid for those lessons myself, slowly.
Builders rarely hear this, but the visible side has its own invisibility problem. In the 2024 State of DevRel report, the people whose job is literally public developer work said their biggest challenge was proving impact with data and metrics (60.7%), with burnout and mental health close behind (37.6%). A talk gets applause. Whether it changed what anyone built is almost impossible to show. Being seen is not the same as being valued, even for the people who are seen the most.
So the public developers have a fair point too. Teaching is work. Explaining is work. The industry would be poorer without it.
Where each side gets it wrong
The builder’s mistake is assuming good work will be noticed on its own. It usually will not. Not because people are unfair, but because they cannot see it. The sociologists Susan Leigh Star and Anselm Strauss put it precisely in 1999: “No work is inherently either visible or invisible. We always ‘see’ work through a selection of indicators.” If you never supply the indicators, you are asking others to do the job of understanding your work for you, and most of them are busy.
Legible does not mean loud. It can be a two-line note to your manager: “I found why checkout failed under load and fixed it. It would have hit us during the next sale.” That sentence turns invisible work into something a decision-maker can remember. Julia Evans made the same case in her post on keeping a “brag document”: some kinds of important work are simply more memorable than others, and the fuzzy work, like improving code review culture or making on-call easier, is the most likely to slip under the radar unless you write it down.
The public developer’s mistake is quieter. Visibility can slowly become the job. The talks get better while the building gets thinner. Applause starts to feel like feedback on the code, when it is really feedback on the performance. Will Larson has a word for the extreme version: “preening”, doing low-impact, high-visibility work. He warns that many companies “conflate high-visibility and high-impact so strongly that they can’t distinguish between preening and impact.” Being public is fine. Being public about work you have stopped doing is the problem.
What the world actually measures
The world does not measure effort. It never has. It measures what it can see, and it uses proxies: talks, followers, GitHub stars, titles, the size of the company on your CV.
Those proxies shape behaviour. Google is the textbook case. For years, engineers inside and outside the company described launching something new as the easiest way to get promoted, compared with maintaining what already existed. In 2022, Sundar Pichai told staff productivity was “not where it needs to be” and changed promotion incentives to push for more customer focus. Zach Lloyd, a former Google engineering lead, described the result of promotion-driven culture plainly: new, internally competing products get launched while existing products languish, “because one of the best ways to get promoted is to launch something new.” Larson makes the same point about a single team: starting a new database is easy, finishing the migration off the old one is hard, and only one of those tends to make a good promotion story.
Visibility also compounds. In 1968 the sociologist Robert Merton described the “Matthew effect” in science: credit for joint or simultaneous discoveries flows disproportionately to people who are already famous. The rich get richer. Tech works the same way. Once you are the person who gives talks, your next talk is easier to land, your posts travel further, and your ideas get taken more seriously than the same idea from someone nobody has heard of.
Measuring harder does not fix it. When McKinsey published “Yes, you can measure software developer productivity” in 2023, Kent Beck and Gergely Orosz responded with a simple model: effort, output, outcome, impact. Their warning was that whatever you measure, people will game. Measure effort and you get busywork. Measure output and you get whatever output is easiest. Their advice was to aim for team outcomes and impact, and to use effort and output only to debug problems. It works as a test for your own work too. “I spent three weeks on the payment flow” is effort. “Duplicate charges went to zero during peak sales” is impact. Only one of those survives a promotion meeting.
So the proxies are crude. They reward the visible over the valuable. But they are not random either. Over a long career, the developers I have seen do best are rarely at either extreme. They do deep work, and then they make it legible. A design note that explains a decision. An internal write-up after an incident. A short summary for leadership that turns a technical win into a business one. Occasionally, a public post or a talk.
Translating the work without replacing it
If the skill is translation, here is what it looks like in practice, roughly from least effort to most.
Write the counterfactual. Prevention work leaves nothing behind to show, so give it something. “Without this, X would have happened, and here is how we know.” That one sentence is the difference between “did some refactoring” and “removed the cause of last year’s two biggest outages.”
Keep a running record. A brag document, updated every couple of weeks, is not vanity. It is evidence you will not be able to reconstruct from memory at review time.
Move each piece of work one rung up the effort, output, outcome, impact ladder before you share it. Your manager can usually take it the rest of the way.
Write internally before externally. An incident write-up or design note reaches the people who decide your career and helps your team. Very often it is also a public post waiting to be edited.
If you are doing glue work, say so, out loud, to your manager. Ask whether it counts toward where you want to go. If it does not, get it recognised or hand it to a rota.
And if you are the speaker, keep a build log. Check that the thing you talk about is still something you do. If your last three talks are about work from three years ago, pay attention to that.
I do not think of any of this as self-promotion. It is closer to documentation: making sure the people who need to understand what happened actually can.
The question underneath
None of this is unique to software. A nurse who quietly catches medication errors is doing work that rarely appears in any report, which is exactly what the Safety-II researchers were trying to change. An accountant whose reconciliations stop a problem before the audit gets no credit for the crisis that did not happen. Meanwhile, the colleague who presents well at the quarterly meeting gets remembered. Every profession has its builders and its speakers, and every profession struggles to see the first group clearly.
The research keeps landing in the same uncomfortable place. Organisations reward the visible fix over the invisible prevention. They hand the invisible work to the people least likely to say no. Then they are surprised when the systems that depended on that work start to crack, whether it is a factory line, a hospital ward or a compression library on every Linux server in the world.
So I will leave you with the question I keep asking myself, whichever side of the line I happen to be standing on that day:
If the work you are proudest of disappeared tomorrow, who would notice first: the people who depend on it, or the people who decide what happens to your career next? And if those are two different groups, which one have you been working for?
Sources
- Repenning, N. & Sterman, J. (2001). “Nobody Ever Gets Credit for Fixing Problems that Never Happened.” California Management Review 43(4). https://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.pdf
- Hollnagel, E., Wears, R. & Braithwaite, J. (2015). From Safety-I to Safety-II: A White Paper. https://www.england.nhs.uk/signuptosafety/wp-content/uploads/sites/16/2015/10/safety-1-safety-2-whte-papr.pdf
- PSNet interview with Ellen Deutsch on Safety-I and Safety-II. https://psnet.ahrq.gov/perspective/resilient-healthcare-and-safety-i-and-safety-ii-frameworks
- Perlroth, N. (2014). “OpenSSL and Linux: A Tale of Two Open-Source Projects.” New York Times. https://archive.nytimes.com/bits.blogs.nytimes.com/2014/04/18/openssl-and-linux-a-tale-of-two-open-source-projects
- PCWorld (2014). Core Infrastructure Initiative launch. https://www.pcworld.com/article/438906/after-heartbleed-tech-giants-commit-to-supporting-critical-open-source-projects.html
- Schneier, B. (2024). “Backdoor in XZ Utils That Almost Happened.” https://www.schneier.com/essays/archives/2024/04/backdoor-in-xz-utils-that-almost-happened.html
- Collin, L. (8 June 2022). xz-devel mailing list. https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html
- Tidelift (2024). State of the Open Source Maintainer Report, summarised by Sonar and Socket. https://www.sonarsource.com/resources/library/open-source-maintainers and https://socket.dev/blog/the-unpaid-backbone-of-open-source
- Reilly, T. “Being Glue.” https://noidea.dog/glue
- Babcock, L., Recalde, M., Vesterlund, L. & Weingart, L. (2017). “Gender Differences in Accepting and Receiving Requests for Tasks with Low Promotability.” American Economic Review 107(3). https://www.aeaweb.org/articles?id=10.1257/aer.20141734
- Harvard Kennedy School WAPPP (2025). Interview with Lise Vesterlund. https://www.hks.harvard.edu/centers/wappp/research/research-insights-impact-stories/hidden-costs-helping-conversation-lise
- Stack Overflow Developer Survey 2024. https://survey.stackoverflow.co/2024/developer-profile
- State of Developer Relations Report 2024. https://www.stateofdeveloperrelations.com/2024devrelreport
- Star, S. L. & Strauss, A. (1999). “Layers of Silence, Arenas of Voice: The Ecology of Visible and Invisible Work.” CSCW 8. https://link.springer.com/article/10.1023/A:1008651105359
- Evans, J. (2019). “Get your work recognized: write a brag document.” https://jvns.ca/blog/brag-documents
- Larson, W. (2020). “Work on what matters.” https://lethain.com/work-on-what-matters
- Amadeo, R. (2022). “Google CEO Sundar Pichai says productivity is ‘not where it needs to be’.” Ars Technica. https://arstechnica.com/gadgets/2022/08/google-ceo-calls-for-a-more-focused-and-efficient-google
- Lloyd, Z. (2022). “The Google Incentive Mismatch: Problems with Promotion-Oriented Cultures.” https://www.warp.dev/blog/problems-with-promotion-oriented-cultures
- Merton, R. K. (1968). “The Matthew Effect in Science.” Science 159(3810). https://fbaum.unc.edu/teaching/PLSC541_Fall06/Merton_Science_1968.pdf
- McKinsey (2023). “Yes, you can measure software developer productivity.” https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity
- Orosz, G. & Beck, K. (2023). “Measuring developer productivity? A response to McKinsey, Part 2.” https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity-part-2