The Best Developers I Know Are Lazy

Let me introduce you to the most productive engineer I've ever worked with.

He closed more tickets than the rest of the team combined. His PRs were small. Suspiciously small. The kind of four-line diff that quietly fixes a bug three senior engineers had been blaming on "flakiness" for a week. He logged off around 5. He took real lunches. He had hobbies, plural.

By every visible signal, he was the laziest person in the building.

He was also, by an embarrassing margin, the best developer in it.

It took me an irresponsibly long time to understand why, and the answer still sounds like something you'd put on a motivational poster as a joke: the best developers I know are lazy. Not careless. Not coasting. Lazy in the specific, almost spiritual way that makes a person physically incapable of doing work that doesn't need doing.

And our entire industry is built to make those people feel guilty about it.

We Decided Effort Was the Metric

At some point we collectively agreed that the unit of a good developer is suffering.

We clap for the person who pulled the all-nighter to ship the feature. We never ask the obvious follow-up, which is: why did a feature need an all-nighter, and whose architecture did that to us. We're impressed by the 800-line PR and weirdly suspicious of the 12-line one, as if fewer lines meant less thinking, when it usually means more.

Walk through any engineering org and you'll find the same idols getting worshipped:

• Lines of code, as a proxy for value. As though shipping more code were an asset and not a mortgage you just signed on behalf of every future maintainer, including, hilariously, yourself.

• Hours online, as a proxy for commitment. The person typing at 11pm is "dedicated." The person who solved the same problem at 2pm and went outside is, apparently, slacking off.

• Calendar density, as a proxy for importance. Back-to-back meetings, forty open tabs, a Jira board that looks like a crime scene. Motion cosplaying as progress.

• The green squares. A GitHub contribution graph you treat as a daily performance review run by a judge who is also you, where a blank Saturday lands somewhere between "lazy" and "moral failing."

Not one of these measures the only thing that actually matters, which is so boring to say out loud: did the problem get solved, and will it stay solved while you're on vacation.

Effort Is a Cost, Not a Trophy

Here's the reframe that fixed my brain.

Effort is not an achievement. Effort is a bill. It's what you pay to get an outcome, and like any bill, the goal is to pay less of it, not to frame it and hang it in the hallway.

Once you see it that way, a lot of "impressive" work stops being impressive. I wrote a whole post about the 600-line component that does everything and knows nothing, the one assembled by saying "now add a search bar" to an AI forty times in a row. That thing is drenched in effort. Hours of prompting, debugging, vibing. It is also worse than the 40 lines it should have been. The effort didn't turn into value. It turned into surface area for bugs and a git blame nobody wants their name on.

This is the trap nobody warns you about: when you reward effort, you get effort. You do not get outcomes. You get people heroically reinventing Array.prototype.map, hand-rolling a date library the language already shipped, and erecting cathedral-grade abstractions for what was honestly three if-statements. And then they get a high-five for how hard it was.

The lazy developer reads the same ticket and asks the only question that matters: what is the absolute least I can get away with here? Asked seriously and in good faith, that's one of the sharpest tools in engineering. Asked while reaching for coffee, it's also just very funny.

"Laziness" Has a Surprisingly Prestigious Resume

Before the comments fill up with "this is just cope": I didn't make this up.

Larry Wall, the guy who created Perl, literally listed the three great virtues of a programmer as laziness, impatience, and hubris. And he defined laziness as the quality that drives you to write labor-saving programs and then document them so nobody ever has to ask you about it twice. That isn't avoidance. That's effort spent now to delete effort forever. It's lazy the way a power tool is lazy.

There's also the line usually pinned on Bill Gates, probably apocryphally, about giving a hard job to a lazy person because they'll find an easy way to do it. Doesn't matter who actually said it. It's annoyingly correct.

So no, when I say the best developers are lazy, I don't mean they don't care. I mean they care so much about the outcome that they refuse to waste a single keystroke getting there. Here's what that looks like in the wild.

Lazy Move 1: They Delete Code

The best PR I reviewed last quarter was -340 / +0.

Someone found a "clever" caching layer that three engineers were scared to touch, proved it was doing precisely nothing the framework wasn't already doing, and deleted the entire thing. No replacement. Just gone, like it owed them money. The app got faster. The bundle got smaller. A whole genre of future 2am pages quietly ceased to exist.

Deleting code is harder than writing it, which is exactly why nobody wants to do it. Writing feels great. You end the day with more, like a productive little hamster. Deleting requires you to actually understand the system well enough to know what's load-bearing and what's just a load. It's the negative diff, the most valuable code you'll ever write, and it will earn roughly zero applause because it doesn't look like anything happened.

This is the same instinct behind "delete your useMemo and useCallback" and "CSS has won." The flex isn't doing something cleverer. The flex is doing nothing and being completely right about it.

Lazy Move 2: They Refuse to Build It

The fastest, safest, most maintainable code in any system is the code that does not exist. It has no bugs. It needs no tests. It cannot page you at night. It is perfect.

A lazy developer's first reaction to a ticket isn't "how do I build this," it's "wait, do we actually need this." Not to be difficult. To be correct. A horrifying percentage of any backlog is solving a problem exactly one person hit once, or rebuilding something that already lives three menus deep, or could be a config flag instead of a sprint.

The hardworking dev takes the ticket at face value and starts typing immediately, like a good soldier. The lazy one spends ten annoying minutes asking questions and discovers the whole thing can be cut from the sprint. One of them looks busier. The other one just handed the team two weeks back.

Lazy Move 3: They Let the Platform Do the Work

This is my favorite lazy move, because it's the one that masquerades as knowledge. To skip the work, you have to know the platform already did it, and the platform keeps quietly doing more of it every year while everyone's distracted arguing about frameworks.

Here's a thing I keep finding in PRs written by people who are Working Very Hard:

js

function groupByCategory(products) {
  const groups = {};
  for (const product of products) {
    if (!groups[product.category]) {
      groups[product.category] = [];
    }
    groups[product.category].push(product);
  }
  return groups;
}

It works. It's fine. It also comes with tests, a name, a home in your utils file, and a lifelong maintenance subscription you didn't know you signed up for. Here is the lazy version:

js

const groups = Object.groupBy(products, p => p.category);

Shipping in every major browser since 2024. No utility file. No tests for your artisanal grouping logic, because it isn't yours anymore. The lazy developer wrote one line because they happened to know the platform already wrote the other fifteen, and tested them harder than your team ever will.

Same energy everywhere: structuredClone instead of a hand-grown deep clone with three subtle bugs in it. Intl.RelativeTimeFormat instead of fifty lines of "2 hours ago" branching that detonates the instant a timezone gets involved. A native <dialog> instead of a modal library and the 30KB of someone else's opinions it drags in. Every one of these is a developer being too lazy to write code the browser will write for free, and being completely right to be.

Lazy Move 4: They Automate the Thing They Hate

There's a beautiful, petty flavor of laziness where someone does a tedious task exactly one time, takes it personally, and vows to never do it by hand again.

Setup scripts. A real CLAUDE.md so they stop re-explaining the same five conventions to an AI that forgot them between Tuesday and Wednesday. A git alias. A snippet. The catch, and it's a real one, is the failure mode where you blow three hours automating something that took three minutes a year and then call it "tooling." (The xkcd "Is It Worth The Time" chart should be printed on the back of every laptop.) The skill is telling the difference between the task you'll do fifty more times and the one you're just procrastinating on with extra steps.

The diligent person does the boring thing carefully, every single time, and feels noble about it. The lazy person does it once, badly, makes a machine do it forever, and goes to lunch.

Lazy Move 5: They Say No

Leverage is mostly a list of things you didn't do.

The lazy senior says no to the premature abstraction, no to the fourth state management library this quarter, no to the meeting that was visibly an email in a trench coat, no to "while we're in here, let's also refactor auth." Every no is energy unspent, complexity unborn, surface area that never existed to break in the first place.

It's the hardest move, because "no" makes you look unhelpful for about ten seconds and saves the codebase for about ten years. A codebase is shaped as much by what you refuse to let in as by what you build. The people guarding it best are usually the ones saying no the most, and getting mildly disliked for it.

"Okay, This Is Just You Justifying Cutting Corners"

I can hear it, because I'd think it too. Isn't this just negligence with a nicer haircut? The vibe coder who ships a 600-line mess without reading it is also "lazy." You can't have it both ways.

Fair. Both people are dodging work. The whole question is which work.

The bad-lazy developer dodges the thinking. Skips understanding the problem, skips reading the output, skips the judgment, and produces exactly the dumpster fire I complained about for three thousand words once. That's not leverage. That's just hoping, in an IDE.

The good-lazy developer dodges the typing. They shove all the effort upstream, into understanding the problem so thoroughly that the solution turns out small and boring. They do the hard part on purpose so the rest can be easy. The work doesn't vanish. It moves from your fingers to your brain, where it's worth about ten times more.

So it was never laziness versus diligence. It's two different things to be lazy about. Bad-lazy is lazy where it counts and busy where it doesn't. Good-lazy is the exact opposite, and the opposite is the entire game.

You Have to Earn This

One honest caveat, before some junior reads this, concludes that fewer lines automatically means better code, and ships a four-line PR that takes down prod.

It does not work like that. The lazy senior is lazy because they already did the boring reps. They can delete the caching layer because they understand what it was pretending to do. They reach for Object.groupBy because they know it exists, know its edge cases, and know the one situation where it'll bite. They say "we don't need this" because they've personally been burned building it anyway.

You earn the short version by writing the long version enough times to know it's safe to skip. So if you're early: write the boring, explicit, slightly-too-long thing. Do the reps. The laziness is a reward you unlock later, not a shortcut you take now.

How to Get Lazy on Purpose

If you want the productive kind of lazy, the kind that ships small and sleeps through the night, here's what actually moves the needle. None of it is clever. All of it is a habit you have to defend.

Ask if it should exist before you build it. Ten minutes of irritating questions can delete a two-week ticket. The cheapest code is the code you talked someone out of.

Default to the platform. Before you npm install or hand-roll a util, check whether the browser, the language, or the framework already ships it. In 2026 the answer is "yes" embarrassingly more often than the instincts you formed in 2019 want to admit.

Count problems solved, not lines shipped. A blank diff that closes a ticket is a win. A thousand-line diff that opens three new ones is a group project.

Make deleting a reflex. Look for something to remove on every pass. Celebrate the PR that's mostly red. It's the highest-leverage code you'll ever not write.

Automate the second time, not the first. Don't pre-tool everything like a doomsday prepper. But the moment a task shows up twice and threatens to show up fifty more, hand it to a machine.

Guard your no. Treat every abstraction, library, and "while we're here" you successfully refused as real, shippable work. Because it is.

The Part Where Someone Calls Me Lazy in the Comments

Yes. I'm a developer writing several hundred words to argue that working less is good. The irony is noted. Roast away, you've earned it.

But the point was never that effort is bad. The point is that effort was always a stand-in for the thing we actually wanted: problems solved, software that keeps working, teams that move fast without slowly drowning in their own code. Somewhere along the way we fell in love with the stand-in. We started rewarding visible struggle, and visible struggle is exactly what you get from people who reinvent wheels for a living.

The best developers I know quietly opted out of that game. They're not doing less because they care less. They're doing less because they got disturbingly good at telling the difference between work that matters and work that just looks like it does, and they flatly refuse to spend their one short life on the second kind.

Anyway. Go delete something.

---

If you want the dark mirror of this post, I also wrote about how vibe coding is producing the worst codebases I've ever reviewed. Same coin, other side: that one's about being lazy with the thinking, which is the kind that actually burns you.

If this made you want to go delete something, go do it, then tell me what it was. Drop your best "smallest PR, biggest win" in the comments. I'm collecting them, and the current champion is a one-character change that fixed a production outage. You can almost certainly do better.