What Code Culture Actually Is
Code culture is everything a software team knows that is not in the repository: how the morning meeting goes, what you say when the build breaks, which day you do not deploy, and the jokes that tell a newcomer they have been accepted. It is learned by standing next to people, not by reading. That is why it travels as phrases.
The phrases are the interesting part. Nobody designed "works on my machine" or "it's always DNS". They crystallised, the way folk songs do: a situation repeated often enough that someone named it, the name landed, and from then on the name did the work of the explanation. A ritual produced a sentence, and the sentence became a legend that outlived the ritual.
This guide follows twelve of those rituals in roughly the order a developer meets them, from the first program to the first argument with a language model, and traces where each legend came from. Dates and names are given where they exist. Where the origin is genuinely lost, it says so, because that is part of the story too: the most durable things in code culture tend to have no author.
Hello, World!
The first ritual is shared by every developer alive: make the machine say hello. It dates to 1972, when Brian Kernighan used "hello, world!" as the example in A Tutorial Introduction to the Language B, an internal Bell Labs document for the language that preceded C. The 1974 C tutorial reused it, and the 1978 Kernighan and Ritchie book put it on page six.
The B version is worth seeing, because it explains why the phrase is lower case and oddly punctuated. A character constant in B held at most four ASCII characters, so the greeting had to be split into three variables, 'hell', 'o, w' and 'orld', and printed one at a time. The comma and the exclamation mark survived the limitation; the capital letters were never there to begin with.
What makes it a ritual rather than an example is that it never went away. Fifty years on, the first thing anyone does with a new language, framework or board is still to print the greeting, and the first thing a tutorial does is still to show it. It is the handshake of code culture, and it was written by someone who was only trying to demonstrate external variables.
The Daily Standup
The daily standup is the ritual most juniors meet first, and the one code culture has argued about longest. Ken Schwaber and Jeff Sutherland presented Scrum at the OOPSLA conference in Austin in 1995, with a short daily meeting at its centre: same time, same place, fifteen minutes, standing up so it would not run long.
For twenty-five years the meeting had a liturgy. Each person answered three questions: what did I do yesterday, what will I do today, what is blocking me. The questions were in the Scrum Guide, and in time they were in every team's muscle memory. In the November 2020 revision the guide removed them, in the name of being less prescriptive. The teams did not notice. They still go round the circle, still say "yesterday, today, blockers", and still have the one person who gives a status report to the manager instead of a sync to the team.
The standup is also where the most expensive sentence in software is spoken. "It's just a small change" is said with full sincerity, in the fifteen-minute meeting, by someone who has not yet opened the file. The phrase has no inventor; it has several million. Sprint planning gave it a home, and the collection of scrum t-shirts gave it a chest to live on.
Code Review and LGTM
Code review began as a formal, scheduled, almost ceremonial inspection, and ended as four letters typed under a diff. Michael Fagan published "Design and code inspections to reduce errors in program development" in the IBM Systems Journal in 1976: a meeting with defined roles, a moderator, a reader, a checklist, and a rule that the author does not defend the code.
Thirty-two years later GitHub launched, in April 2008, and the pull request turned the inspection into a conversation in the margins. The roles vanished, the checklist vanished, and what remained was a verdict. "LGTM", looks good to me, is the smallest unit of approval in software, and everyone has typed it on something they did not fully read. Its honest cousin is "LGTM, but I didn't run it", which is a confession disguised as a review.
The review is also where the oldest legend in this guide lives. When the reviewer's checkout fails and the author's passes, the author says the thing. "Works on my machine" has been said since the 1990s, got its badge from Jeff Atwood in 2007, and survived the tool, Docker, that was built in 2013 to make it impossible. That post tells the whole story; the short version is that environment parity is a technical problem with a social cause, and the phrase is the social cause talking.
The Commit Message
Linus Torvalds started writing Git on 3 April 2005, after the Linux kernel lost its free use of BitKeeper, announced it on 6 April and had it hosting its own source the next day. He named it the way he named Linux. "I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git," he said, which is as good a founding document as code culture has.
Git made the commit message a daily ritual for every developer on earth, and the ritual produced its own folklore almost immediately. The canonical record is xkcd 1296, "Git Commit", from 27 November 2013: a log that starts with "created main loop & timing control" and decays, over fourteen hours, through "misc bugfixes", "more code", "here have code" and "aaaaaaaa" to "my hands are typing words". The title text is the merge commit: Merge branch 'asdfasjkfdlas/alkdjf' into sdkjfls-final.
Everyone recognised it because everyone has the same log. "Fixed stuff", "fix", "fix fix", "final", "final_v2", "actually final". And then there is the one piece of text that every developer has seen while their heart rate rose: <<<<<<< HEAD, the merge conflict marker, which is less a message than a ransom note. The git t-shirts in Commits & Mayhem are mostly about that moment.
The Rubber Duck
Rubber duck debugging is the ritual of explaining your code, line by line, to something that cannot answer, because the explanation is what finds the bug. It is the one practice in this guide that works exactly as advertised, and it was named after an actual duck.
The name comes from The Pragmatic Programmer, the 1999 book by Andy Hunt and Dave Thomas. They tell of a research assistant, Greg Pugh, who carried a rubber duck and addressed his explanations to it. The mechanism is simple: you cannot explain a line you do not understand, so the act of narrating forces you to read what the code does rather than what you meant it to do. Somewhere around the third sentence the problem, as the book puts it, leaps off the screen and announces itself.
The duck became a desk object, then a conference giveaway, then a meme, and in the AI era it became a job description: a lot of what developers now do with a model is rubber ducking with a duck that talks back. The duck in the picture at the top of this post is there for a reason. Every team has one. Nobody admits to using it.
Never Deploy on Friday
"Never deploy on Friday" is the only rule of code culture that has been argued about on every continent and written into exactly zero official processes. It has no origin. It emerged, independently, everywhere, from the same experience: a change shipped at 16:00 on a Friday, a weekend spent in a terminal, and a Monday spent explaining it.
The rule hardened into a ritual, read-only Friday, with its own tribal markers. Teams that observe it treat the Friday deploy as a dare. Teams that do not observe it have a counter-argument that is also a boast: if you cannot deploy on a Friday, the problem is your pipeline, not the calendar. Both camps are describing the same fear from different distances.
The fear has a second legend attached. The developer who deploys on Friday is also, usually, the developer who skipped staging, and that one has its own confession on a shirt. "I test in prod" is a meme with a history, from the Most Interesting Man template to the feature flag, and the post on it explains why the sentence is both a joke and, in a lot of modern teams, simply true. The people who get paged for it are the ones in devops shirts.
On-Call and the DNS Haiku
On-call is the ritual of sleeping with a phone face up. It is older than software, inherited from doctors and the pager, and it got its modern shape when PagerDuty turned the rota into a product in 2009. It is also the ritual that produced the most perfect three lines in code culture.
It's not DNS.
— a haiku nobody has managed to attribute
There's no way it's DNS.
It was DNS.
The haiku has no reliable author. It circulated on Reddit and sysadmin blogs, was reposted on Twitter more times than the original could ever be found, and ended up on conference slides as if it were scripture. It is a genuine three-line incident report: denial, reasoning, resolution. The reason it is funny is that it is a prediction. Every engineer who has been on-call for more than a year has lived the exact sequence, and most of them have lived it more than once.
The on-call ritual has a second legend, from the other side of the ticket. "Have you tried turning it off and on again?" was handed to the world by The IT Crowd, which first aired on Channel 4 on 3 February 2006, with Roy answering the support line from a tape recording. The joke was that the line was a brush-off. The deeper joke, which the show understood, is that it works.
The Blameless Postmortem
The blameless postmortem is the ritual that follows the DNS haiku: the meeting after the incident where the question is "how did the system let this happen" rather than "who did it". It is the most grown-up thing in code culture, and the one most often promised and least often practised.
The idea has an author and a date. John Allspaw, then running engineering at Etsy, published "Blameless PostMortems and a Just Culture" on the Code as Craft blog on 22 May 2012. The argument was that an engineer who fears punishment will hide the details you most need, so a postmortem that assigns blame destroys its own evidence. Google's Site Reliability Engineering book carried the idea into the industry's standard reading list in 2016, and "blameless" became a word teams say about themselves whether or not it is true.
The incident itself has a mascot. The dog in the burning room, saying "This is fine", is from KC Green's webcomic Gunshow, a 2013 strip called "On Fire". The first two panels escaped onto Reddit and Imgur in September 2014, and have been pasted into incident channels ever since, usually by the person who is not on-call. The jokes about the fire are in debugging and QA t-shirts; the postmortem is the part you have to do yourself.
Technical Debt
Technical debt is a metaphor that became a ritual: the quarterly conversation in which a team admits what it owes. Ward Cunningham coined it in 1992, in an OOPSLA experience report on the WyCash portfolio management system, and his sentence has outlived most of the software it described.
"Shipping first time code is like going into debt."
— Ward Cunningham, The WyCash Portfolio Management System, 1992
The metaphor spread because it let engineers explain to finance people why the fast version has a cost. Developers then did what they always do and turned the concept into a pair of phrases. "We'll fix it later" is the loan being taken out. "Don't touch it, it works" is the loan being quietly defaulted on. Between them sits the legacy system: the service nobody understands, that nobody dares to restart, that every new hire is told about on the first day with the tone normally reserved for a haunted house.
The comedy of technical debt is that it is always someone else's. The person who wrote the hack has moved on, the person who inherits it writes the comment that says // do not remove, breaks everything, and that comment becomes a load-bearing part of the architecture. The funny programmer shirts in Syntax & Sarcasm are, to a surprising degree, about this.
Marked as Duplicate
For fifteen years the central ritual of code culture was not writing code but searching for someone who had already written it. Jeff Atwood and Joel Spolsky launched Stack Overflow on 15 September 2008, and for a generation of developers it was the first tab opened after the error message.
It produced two legends. The first was "copy, paste, it works, move on", which is less a joke than a description of how most software was assembled between 2008 and 2022. The second was "marked as duplicate", the moderator's stamp that greeted a question you had phrased slightly differently from one answered in 2011, with an answer that no longer applied to the current version. The stamp was the site's way of being helpful. It landed as a door closing.
Both legends are now historical. Developers still open the tab, but the answer they paste increasingly comes from a model that read the same site, and the question count has been falling for years. Stack Overflow taught code culture that the answer exists somewhere; the AI era taught it that the answer can be generated on demand, and that the two are not the same thing.
The Hackathon
The hackathon is code culture's festival: the ritual of building something in a room full of pizza, with no process and a deadline measured in hours. The word is from 1999, used twice that summer. OpenBSD held a cryptography development event in Calgary on 4 June, ten developers in one place to stay clear of American export rules, and Sun Microsystems used the same word at JavaOne that month for a challenge to write a Palm program over infrared.
The ritual's legend is "built in 24 hours", a boast that carries its own warning. The thing built in 24 hours is a demo. The thing shipped afterwards is the demo plus eighteen months of the technical debt from the chapter above. Everyone in the room knows this and holds the hackathon anyway, because the point was never the product. It was the night.
The most-told hackathon story is Facebook's Like button, which the company's own engineering notes say was conceived at a hackathon. The story is told at every hackathon since, usually at around two in the morning, by someone who is about to build a chat app.
The AI Era
The newest ritual of code culture is arguing with a language model, and it is already producing legends faster than any ritual before it. It also has numbers, because it is the first ritual to arrive while the industry was surveying itself.
Fig. 1 · how often developers use AI tools, 2025
| Frequency | Share |
|---|---|
| Daily | 47.1% |
| Weekly | 17.7% |
| Monthly or less | 13.7% |
| Planning to | 5.3% |
Source: Stack Overflow, 2025 Developer Survey, AI section
Eighty-four percent of developers use or plan to use AI tools, and half of professional developers use them daily. The same survey found that 66% are frustrated by answers that are "almost right, but not quite", and that more developers distrust the output's accuracy (46%) than trust it (33%). That gap, between using the thing every day and not believing it, is where the new legends come from.
Source: Stack Overflow, 2025 Developer Survey, AI section
The first legend is three words. "You're absolutely right" is what the model says immediately before reversing the position it defended a moment ago, and the post on it explains why the models were trained to do that. It became a meme within months because every developer had read it in the same tone: polite, confident, and about to change the code again.
The second legend has a date. On 2 February 2025 Andrej Karpathy described a way of working where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists", and called it vibe coding. Collins named it Word of the Year on 6 November 2025. In between, code culture produced "let AI cook", a phrase that is either a workflow or a surrender depending on who says it. The 2024 DORA report had already measured the surrender: more AI adoption came with an estimated 1.5% drop in delivery throughput and a 7.2% drop in stability.
Source: Google Cloud, Announcing the 2024 DORA Report, 2024
None of this stopped anyone. The AI era is the only ritual in this guide where the legend arrived before the ritual had settled, and the ai shirts are keeping up as fast as the models change their minds.
How Code Culture Remembers
Code culture remembers in sentences because sentences survive tooling. Docker solved environment parity in 2013, and "works on my machine" is still said daily. The Scrum Guide dropped the three questions in 2020, and teams still answer them. The duck never needed to work, and it is still on the desk.
That is the pattern across all twelve chapters. A ritual appears because a situation repeats. The ritual produces a phrase, because people need a short way to say the long thing. The phrase detaches from the ritual and becomes a legend, which from then on is how the next generation learns that the situation exists. Juniors learn "it's always DNS" before they have ever edited a zone file. They learn what the phrase means the first time they are the one saying it at three in the morning.
Legends also do a quieter job: they mark who belongs. Say "it was DNS" in a room of engineers and a certain number of people will laugh before the sentence is finished. That is the entire mechanism of code culture, and it is why the phrases end up on things people wear. A shirt that says "I test in prod" is not a confession to strangers. It is a signal to the people who will get it, in the same way the joke in the standup is. If you know someone who says all twelve, the gift guide for programmers is sorted by exactly which ones they say.
Four Legends You Can Wear
Four of the legends in this guide exist as designs, each one the phrase and nothing else. They are listed in the order the chapters tell them, which is also, roughly, the order in which a developer earns the right to wear them.
Works On My Machine
The code review legend, with the 2007 badge and the shrug that attached itself later. Worn by people who have typed the phrase into a ticket and meant it.
I Test In Prod
The Friday deploy legend, worn as a confession by people who skipped staging and as a flex by people whose feature flags make staging unnecessary. Both readings are correct.
It Was DNS
The on-call legend, reduced to the third line of the haiku. The first two lines are implied, and anyone who has carried a pager will supply them on sight.
You're Absolutely Right
The AI era legend, and the youngest design in the store. Three words the model says before every U-turn, worn by the people who have to review the U-turn.
FAQ
What is code culture?
Code culture is the shared set of rituals, phrases and inside jokes that software teams pass on by repetition rather than documentation: how the standup runs, what is said when the build breaks, which day nobody deploys. It is distinct from engineering culture in the management sense, which is about values and process. Code culture is the folklore that grows around the process.
Where does "never deploy on Friday" come from?
Nowhere in particular. The rule has no documented origin and appears to have emerged independently in many teams from the same experience: a Friday afternoon release followed by a weekend of firefighting. It became a ritual, "read-only Friday", and a counter-argument, which holds that a team that cannot deploy on Friday has a pipeline problem rather than a calendar problem.
Is it really always DNS?
No, but it is DNS often enough that the joke predicts the outcome. DNS sits under almost everything, its failures look like something else, and caches mean a wrong record can keep breaking things after it has been fixed. The haiku, "It's not DNS, there's no way it's DNS, it was DNS", is a compressed incident report that most on-call engineers have lived through at least once.
What is a blameless postmortem?
A blameless postmortem is an incident review that asks how the system allowed a failure rather than who caused it. John Allspaw set out the practice at Etsy in May 2012: engineers who fear punishment hide the details an investigation needs most, so blame destroys the evidence. The review assumes everyone acted reasonably on the information they had and fixes the system instead.
Which of these phrases are on a shirt?
Four of the twelve legends exist as designs: Works On My Machine, I Test In Prod, It Was DNS and You're Absolutely Right. Each carries the phrase and nothing else, which is the point: the people who get it do not need the explanation.