You know that guilt you feel when you write a script to automate a task that would’ve taken ten minutes by hand? When you refuse to sit through another sprint planning meeting because the code is already forming in your head? When you look at a codebase and think, I could rewrite this better in a weekend?
Stop feeling guilty. Larry Wall — the creator of Perl — said those instincts aren’t flaws. They’re the three great virtues of a programmer: laziness, impatience, and hubris.
And he wasn’t being cute. He was being right.
The best code ever written came from people who were honest about being lazy, not from people disciplined enough to pretend they weren’t.
Let’s break this down, because the modern software industry has spent two decades trying to convince you the opposite.
Laziness: The Quality That Makes You Write Effortless Code
Wall defined laziness as “the quality that makes you go to great effort to reduce overall energy expenditure.” You write a library once so you never have to solve the same problem twice. You build abstractions that let future-you copy-paste without thinking. You document your code so nobody — including you — has to reverse-engineer it six months later.
This isn’t slacking. This is optimization at the cognitive level. The lazy programmer looks at repetitive work and says: this should not exist. Then they eliminate it.
Now look at your average enterprise engineering org. Stand-ups. Sprint retros. JIRA tickets with acceptance criteria written by someone who’s never touched the codebase. Process documentation. Compliance reviews. Architecture decision records that nobody reads.
The corporate machine isn’t fighting laziness — it’s institutionalizing the opposite of laziness. It’s making work that doesn’t need to exist and calling it ‘best practice.’
Impatience: The Anger That Builds Better Tools
Wall called impatience “the anger you feel when the computer is being lazy.” It’s what makes you rip out a slow query. It’s what makes you build a hot-reload pipeline because waiting thirty seconds for a compile is unacceptable. It’s the fuel behind every great developer tool.
Impatience is user empathy in disguise. The impatient programmer feels the pain of slow software viscerally — and because they feel it, their users never will.
But in 2024, we’ve pathologized impatience. We tell developers to “trust the process.” We normalize CI pipelines that take forty minutes. We accept that opening a large repo in our IDE means going to get coffee. We’ve been trained to tolerate bad software by the very systems that claim to improve software quality.
Every time you accept a slow build, a sluggish test suite, or a deploy process that requires a checklist — you’re betraying the user you’re supposed to be serving.
Hubris: The Pride That Refuses to Ship Garbage
Hubris, Wall said, is “the quality that makes you write and maintain code that others won’t complain about.” It’s the voice that says this isn’t good enough yet. It’s the developer who refactors a working function because the naming is off. It’s the engineer who rejects a merge request not because it breaks tests, but because it’s ugly.
Hubris is ownership. It’s the refusal to let your name be attached to something mediocre.
But here’s where it gets uncomfortable: hubris is an individual virtue. It requires a person who cares about their craft enough to stake their reputation on it. And the modern engineering culture — with its anonymous commits, its team-owned codebases, its “no heroes” mantra — has systematically stripped programmers of the personal stake that makes hubris possible.
When nobody owns the code, nobody is proud of the code. When nobody is proud of the code, nobody protects it from rot.
The Twist Nobody Sees Coming
Here’s what almost everyone misses about Wall’s three virtues: they’re not about personality at all. They’re a first-principles framework for optimizing around human cognitive limits.
Laziness acknowledges that human attention is finite — so we should build systems that require less of it. Impatience acknowledges that human frustration is a signal — so we should treat slow software as a bug, not a fact of life. Hubris acknowledges that humans care about reputation — so we should design engineering cultures where individual craftsmanship matters.
These virtues work precisely because they embrace our natural tendencies rather than fighting them with discipline. They’re anti-fragile. You don’t need willpower to be lazy — you just need to be honest. You don’t need training to be impatient — you just need to feel. You don’t need a framework to be hubristic — you just need to care.
Meanwhile, the agile-industrial complex asks you to fight your nature every single day. Be disciplined about ceremonies. Be patient with process. Be humble enough to dissolve your identity into the team. It’s exhausting — and the software it produces is, charitably, mediocre.
The best code doesn’t come from programmers who’ve been disciplined into compliance. It comes from programmers who’ve been given permission to be themselves — lazy, impatient, and proud.
What This Means for You
If you’re a developer drowning in process, here’s the liberating truth: your instincts are not the problem. The system that tells you to suppress them is the problem.
That script you wrote to automate away your boring tasks? That’s laziness working. That rage you feel when the build takes too long? That’s impatience doing its job. That refusal to ship code you’re not proud of? That’s hubris — and it’s the reason your code is better than the stuff coming out of the twelve-person team that ‘owns’ everything collectively.
Larry Wall wrote these virtues in 1991. The internet was barely born. Perl was a scrappy scripting language. And a single programmer’s craft could outshine corporate dogma.
Thirty-three years later, we’ve built a multi-billion-dollar industry dedicated to telling you that your natural instincts are wrong. That you need frameworks. Processes. Ceremonies. Maturity models.
But the code that changed the world — Linux, Git, SQLite, Redis — was written by lazy, impatient, hubristic individuals who refused to accept the status quo.
The next great piece of software won’t come from a team that followed process perfectly. It’ll come from a programmer who was honest enough to be lazy, angry enough to be impatient, and proud enough to be hubristic.
Be that programmer. The world doesn’t need another compliant engineer. It needs you — flaws, virtues, and all.
FAQ
Q: Isn't 'laziness' just an excuse for writing sloppy, unmaintainable code?
A: No — Wall's laziness is the opposite of sloppiness. It's the drive to invest effort upfront so you never have to deal with the same problem again. The lazy programmer writes better abstractions, better documentation, and better tests — because doing so means less work later. Sloppy code creates MORE work, which is the antithesis of laziness.
Q: How do these virtues scale in a team of 50+ engineers?
A: They scale by being designed into the system, not policed by process. Make it easier to do the right thing than the wrong thing (laziness). Make slow builds and broken pipelines physically painful to maintain (impatience). Give individuals ownership and credit for specific components (hubris). The virtues don't replace process — they inform what process is worth having.
Q: Isn't this just romanticizing the lone-wolf hacker archetype that doesn't exist anymore?
A: Partially — and that's the point. The lone-wolf hacker produced Linux, Git, SQLite, and Redis. Modern collaborative engineering produces... JIRA tickets. The contrarian truth is that individual craftsmanship scales better than collective mediocrity, and the software industry's obsession with process has coincided with a decline in code quality, not an improvement.