I grew up as the youngest of three kids. If you've ever been the last born, you know the drill. Every chore you skip gets noticed. Every shortcut gets called out. "You're so lazy" wasn't just feedback in my house - it was practically my nickname.

So I carried that word around like a weight for years. Lazy.. or as I heard it growing up: Ọ̀lẹ. In Yorùbá culture, being called ọ̀lẹ isn't just casual teasing - it cuts deep. It's not just "you're lazy," it's closer to "you're useless, you're a waste." It carries the weight of a community that values hard work as moral currency.

Isé̩ l'oògùn ìsé̩ - "work is the antidote to poverty"

That's not just a saying - it's practically a commandment. So when your aunties, your parents, your older siblings look at you and say ọ̀lẹ, they're not just commenting on your work ethic. They're questioning your character.

It meant you weren't pulling your weight. It meant you were the one who needed to try harder, do more, prove you belonged at the table with the older kids who seemed to have it all figured out.

Then I became a software engineer. And something funny happened.

The thing I'd been told my whole life was my biggest flaw turned out to be my superpower... sort of. So much so that for over ten years, the tagline on my website read: "A lazy Software Engineer.". Every technical interview I walked into, someone would bring it up. Sometimes with a smirk, sometimes with genuine curiosity: "So... you're lazy huh?" And every time, it became the most interesting conversation of the entire interview. Not the system design questions. Not the algorithm challenges. The conversation about laziness - and why I wear it as a badge of honour.

Redefining Lazy

Now, let me be honest - sometimes they were right. Sometimes I genuinely just did not want to do the dishes. No hidden optimisation strategy, no secret efficiency hack. Just plain, unproductive laziness. I won't romanticise that part.

But the other kind of laziness? The kind where I figured out that if you soaked the pot of ègúsí soup overnight, you didn't have to stand there scrubbing for twenty minutes. Soaking the beans for mọ́ínmọ́ín extra long so the skin slipped right off instead of sitting there peeling each one by hand while everyone else suffered through it. That wasn't cutting corners. That was a kid engineering solutions - I just didn't have the vocabulary for it yet.

That instinct - the refusal to accept tedious work as inevitable - is the exact same instinct that builds great software.

Larry Wall, the creator of Perl, famously named laziness as one of the three great virtues of a programmer - alongside impatience and hubris. He wasn't joking. He defined laziness as:

"The quality that makes you go to great effort to reduce overall energy expenditure."

When I first read that, I felt seen. The thing my family had been side-eyeing for years - the thing that made the aunties shake their heads and mutter ọ̀lẹ yìí under their breath - was, in the right context, a virtue. That single idea explains half of computing history - and, honestly, half of my childhood too.

Laziness Built the Tools You Use Every Day

Think about the tools that define modern software development. Nearly every one of them was born because someone was too lazy to keep doing things the hard way.

CI/CD pipelines exist because someone got tired of SSHing into a server, pulling code, running tests, and deploying manually at 2 AM. The lazy response was obvious: automate the entire thing.

Docker exists because "it works on my machine" was a problem lazy developers refused to debug one more time - so they packaged the entire environment instead.

Same energy, different scale.

Laziness Is Creativity in Disguise

Here's the thing most people miss: laziness and creativity are deeply connected. When you refuse to accept a tedious process, your brain is forced to find an alternative. That constraint - "I will not do this manually" - is one of the most powerful creative forces in engineering.

A diligent developer might write the same boilerplate code across fifty microservices without complaint. A lazy developer writes a code generator and never thinks about it again. The diligent developer did more work. The lazy developer created more value.

That's exactly why I built Kiln - a tool that generates an entire Go API from a database schema - because I was too lazy to keep writing the same CRUD handlers, validation logic, and OpenAPI specs by hand for every new project.

Laziness forces you to think in systems rather than instances. Instead of solving the problem in front of you, you solve the category of problems. That shift from specific to general is the foundation of every abstraction, framework, and platform ever built. It's also why the youngest sibling somehow ends up becoming the family's universal tech support.

Laziness Fights Complexity

Over-engineering is the enemy of good software, and it's usually caused by developers who are too industrious. They add features nobody asked for. They build abstractions for problems that don't exist yet. They create elaborate inheritance hierarchies because they have the energy to do so.

Lazy developers don't have that energy. They build exactly what's needed and stop. They pick the simplest solution that works. They resist adding layers because every layer is something they'll have to maintain, debug, and explain.

We've all seen it. The teammate who spends three weeks building a "flexible, extensible framework" for a problem that needed a thirty-line script. The pull request with four new abstractions for a feature that touches two files. That's not diligence - that's restlessness disguised as productivity. A lazy developer looks at that and thinks: huh...why?

The result? Cleaner code. Fewer bugs. Systems that are easier to understand and modify. Laziness naturally produces minimalism in design.

How to Be Productively Lazy

Being a good lazy developer isn't about doing less. Productive laziness isn't the absence of effort - it's the refusal to waste effort. It's about refusing to do the wrong work.

Here's how to cultivate it:

Develop an allergy to repetition. If you've done something manually more than twice, your brain should start itching. That itch is your laziness talking, and you should listen to it.

Question every process. "We've always done it this way" is the enemy of the lazy developer. Ask why. Ask if it's still necessary. Ask if there's a way to make it disappear.

Invest in automation early. The best time to automate is before you're drowning in manual work. Lazy developers front-load effort so they can coast later.

Read before you write. Before building something from scratch, search for existing solutions. The laziest line of code is the one someone else already wrote, tested, and maintained.

Optimize for future-you. Future-you is even lazier than current-you. Write clear code, good commit messages, and useful documentation - not because you're diligent, but because future-you will be too lazy to reverse-engineer what you meant.

The Paradox of Lazy Excellence

There's a beautiful paradox here: the laziest developers often produce the best work. By refusing to tolerate friction, they smooth the path for everyone. By refusing to repeat themselves, they create reusable tools. By refusing to do things manually, they build systems that scale.

The hardest-working developers are sometimes the least effective, because they pour energy into fighting problems that shouldn't exist. They push through pain instead of eliminating its source. They're too busy working to stop and think about whether the work itself is necessary.

Laziness is the pause that asks: "Is there a better way?" And the answer, more often than not, is yes.

Embrace Your Laziness

I spent years trying to outwork the ọ̀lẹ label. Trying to prove I could grind harder than my siblings, my classmates, my colleagues. And you know what? The grinding never produced my best work. My best work came when I stopped fighting my nature and leaned into it.

The script that saved my team hours of work per week? I wrote it because I was too lazy to keep doing the task manually. The architecture that scaled to ten times our traffic? I designed it because I was too lazy to keep firefighting performance issues. The project documentation that developers actually read? I wrote it because I was too lazy to keep explaining how the project works over and over again.

So the next time someone calls you lazy - whether it's your family, your manager, or that voice in your own head - consider the possibility that they're identifying your greatest asset.

The history of software engineering is written by people who were too lazy to accept the status quo - and too creative to settle for manual solutions.

Be lazy. Automate everything...with caution. Question every process. Build tools instead of doing tasks. Write code that writes code.

The world's best software wasn't built by the hardest workers. It was built by the laziest ones - who then worked incredibly hard to make sure they'd never have to do it again.

The truly lazy developer doesn't just solve today's problem. They eliminate the entire category of problems, then take a nap. That's not slacking - that's engineering at its finest.

And if my siblings are reading this: I told you I wasn't being an ọ̀lẹ. I was practicing.