Most programmer jokes are not about code at all. They are about the gap between how software is supposed to work and how it actually behaves once real people, real deadlines and real servers get involved. Once you know a dozen of them, you can follow almost any developer's grumbling, and laugh in the right places.

We collected 101 of these moments in HR-Approved Ways to Say What Programmers Are Really Thinking. This guide is the glossary behind them: what each joke refers to, and why it lands so hard with people who write software for a living.

Jokes about bugs

"It works on my machine"

The classic developer defence. A bug report comes in, the developer runs the program on their own laptop, and it works perfectly. The joke is that this proves almost nothing: a laptop has one user, fresh test data and none of the network, timezone and configuration quirks of the live system. "Works on my machine" is said with a straight face and heard as a confession.

"It's not a bug, it's a feature"

When something behaves strangely for long enough, customers start relying on the strange behaviour, and fixing it would break them. At that point the bug has, in a sense, become a feature. Developers say this line ironically about their own mistakes, and seriously, with a small sigh, about old ones they are no longer allowed to fix.

The bug that vanishes when you look at it

Some bugs disappear the moment you add logging or step through the code with a debugger, because observing the program changes its timing. Developers nicknamed these "heisenbugs", after the physicist Werner Heisenberg. The book's version: "I added one print statement and the bug disappeared." The developer translation adds that shipping the print statement is being seriously discussed.

Rubber duck debugging

Explaining a problem out loud, line by line, often reveals the answer before the listener says a word. So some developers keep a rubber duck on the desk and explain the bug to it. The idea was popularized by the book The Pragmatic Programmer. It sounds like a joke. It works embarrassingly often.

Jokes about old code

Legacy code

Code written years ago, often by people who have since left, that the business still depends on. Nobody fully understands it, so nobody wants to touch it. Developer humor about legacy code tends to involve comments left by long-gone authors, such as a warning that simply says // DO NOT, with no explanation, which everyone obeys.

"Temporary" fixes and TODO comments

A TODO is a note a programmer leaves in the code to fix something later. "Later" rarely comes. A large codebase can contain thousands of them, some older than the newest people on the team. The joke is never the TODO itself, but its date.

Jokes about the team

LGTM

"Looks good to me." The standard approval in a code review, where a colleague checks your changes before they go live. The joke is the review that approves 900 lines of changes in thirty seconds, which is to say, without reading them. If you want the serious side of reviews, see our guide on how to write code review comments that don't start a fight.

"Nit"

Short for nitpick: a reviewer's label for a tiny, optional suggestion. The joke is the "nit" that isn't one. In the book's words, "nit: this whole approach is wrong" is not a nit. It's a rejection wearing a small hat.

Standups that don't stand up

Many teams hold a short daily meeting, the standup, where everyone says what they did yesterday and what they will do today. It is supposed to take fifteen minutes. The joke writes itself on the days it takes forty.

Story points

Teams often estimate work in abstract "points" instead of hours, on purpose, because hours are hard to predict. Then someone builds a spreadsheet that converts the points back into hours. Developers find this funnier than anyone else does.

Jokes about production

"Production" is the live system that real customers use, as opposed to a developer's laptop or a test environment. Most of the darkest programmer humor lives here.

Never deploy on a Friday

Deploying means releasing a new version. If a Friday afternoon release breaks something, someone spends the weekend fixing it. So "who deploys on a Friday?" is half joke, half genuine team policy.

"It's always DNS"

DNS is the internet's phone book: the system that turns a name like a website address into the numeric address a computer can connect to. When it is misconfigured, things fail in confusing ways that look like everything except DNS. Teams lose hours ruling out every other cause before discovering it was DNS all along. Hence the joke, and the book's version of it: "We spent three hours proving it wasn't DNS. It was DNS."

"Have you tried turning it off and on again?"

Restarting a misbehaving system often fixes it, and nobody always knows why. Developers joke that the root-cause analysis remains ongoing until it happens again, at which point they will restart it again.

The three "laws" developers quote

Software folklore has a handful of named laws. They are observations, not physics, but they come up in meetings with remarkable regularity.

  • Brooks's Law. "Adding manpower to a late software project makes it later." From Fred Brooks's 1975 book The Mythical Man-Month. New people need training, and training takes time from the people already doing the work.
  • Hyrum's Law. With enough users, every observable behaviour of a system will be depended on by somebody, whatever the documentation promises. It is the serious version of "it's not a bug, it's a feature".
  • The ninety-ninety rule. "The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." Usually credited to Tom Cargill of Bell Labs. It is why "almost done" makes developers wince. (For the serious side of it, see how to push back on an unrealistic deadline.)

Hyrum's Law as stated by Hyrum Wright at hyrumslaw.com. Brooks's Law from Frederick P. Brooks Jr., The Mythical Man-Month (1975).

Why these jokes land

Almost every joke above has the same shape: a polite, official version of events, and the version everyone on the team actually knows to be true. That gap is the whole format of our book. Every page gives the thing a developer wants to say, the HR-approved version they actually say, and a developer translation of what is really going on.

If you are buying for a programmer and wondered whether they would get it: they will get it. If you are wondering whether you will, you now know the vocabulary. For more ideas, see our guide to gifts for programmers that developers actually like.