“There are only two hard things in Computer Science: cache invalidation and naming things.” The line is attributed to Phil Karlton, an engineer who worked at Netscape and earlier at Silicon Graphics. Karlton never published the saying himself in a form that survives, so the primary written record of it is Martin Fowler’s bliki page TwoHardThings, where Fowler collected the quote and its many variants. Because the originator left no canonical text, Fowler’s page functions as the closest thing to a source of record for the joke.
The aphorism endures because both halves are genuinely hard and rarely treated as such. Cache invalidation is the problem of knowing when a cached copy of some data has gone stale and must be discarded or refreshed. Caches make systems fast by avoiding repeated work, but they introduce a second copy of the truth, and keeping that copy correct as the underlying data changes is one of the most error-prone tasks in systems programming. Many subtle production bugs trace back to serving data that should have been invalidated.
Naming things is the second hard problem, and it is hard for a different reason: it is a problem of human communication wearing the costume of a technical task. A good name compresses intent so that a future reader, often the author months later, understands what a variable, function, or module is for without reading its implementation. Bad names mislead, and misleading names are worse than no names at all. Unlike most engineering problems, naming has no test suite that can tell you whether you got it right.
The line’s real comedy is that it is delivered with mock precision: it claims there are exactly two hard things, then lists two problems that are both about uncertainty and judgment rather than algorithmic difficulty. Fowler’s page documents how the format became a template. Leon Bambrick extended it with an off-by-one joke, listing “cache invalidation, naming things, and off-by-1 errors” as the two hard things. Mathias Verraes recast it for distributed systems with deliberately mangled ordering and a duplicated item.
The endurance of the quote, more than a quarter century after Karlton coined it, says something about how the field sees itself. The hardest parts of building software are not usually the parts that look hard. The flashy algorithmic challenges have known solutions in textbooks. The chronic pain comes from keeping copies consistent and from making code legible to other humans, and those two problems never go away.