Why Boring Tools Keep Us Productive

I like new things. I try them early. I break them, curse them, poke at their edges until I learn something. But I don’t deploy them in production unless they earn it.

And when I say production, I’m not talking about size or scale-I’m talking about responsibility. It doesn’t matter if it’s my personal setup or a corporate environment. If something matters enough that its failure wakes someone up, it’s production. If it breaks trust, it’s production. It’s not defined by the size of the server room, but by the promise it carries.

“Production isn’t a scale. It’s a promise. If I rely on it, it better not flake out just because someone pushed a minor update.”

We’ve glamorized complexity. Somewhere along the way, engineers stopped solving problems and started auditioning for their next job. Simplicity became something to be avoided. Predictability? Unfashionable. Resume-driven architecture? Everywhere.

“Sometimes the stack isn’t built for the system. It’s built for the engineer’s next interview.”

We replace cron jobs with pipelines invoking containers triggering webhooks calling Lambdas. We turn basic pages into multi-framework frontends with state sync, and five layers of abstraction-all to display 600 words and a cat picture. It’s not engineering. It’s cosplay.

This isn’t a rant against modern tech. I use ripgrep because it respects my time. I use Semgrep because it adds actual value during reviews. I try bleeding edge stuff. I like new tools. I’m not allergic to modernity-I just ask one thing of it:

There’s a difference between progress and movement. Progress makes things easier. Movement just makes them different. And I’m not in this game to stay busy. I’m here to get things done.

“New doesn’t scare me. Unjustified new does.”

Old tools had releases. Milestones. Predictability. New tools have changelogs. Breaking changes. Surprise regressions because a maintainer decided to change how defaults behave. I don’t want to spend my weekends reading semantic version patch notes like horoscopes. I want stability.

“Old tech eventually went stable. New tech just moves the goalpost every few weeks.”

I use WordPress for my blog. It’s not minimalist. It has JS. It has quirks. But it works. And most importantly : it lets me publish. Static sites are great, but if I’m not updating them because the pipeline broke or I got lost in my own cleverness, then what’s the point?

“A simple blog that gets updated beats a perfect one that never ships.”

I also use a static site (no or minimal JS) for other parts of my site. Not because I hate JavaScript, but because I don’t need it there. I care about content reaching people more than I care about what stack renders it. That’s the part many miss.

“I don’t want delightful. I want done.”

I’ve seen what overengineering does to projects. And to people. I’ve seen systems so fragile no one wants to touch them. I’ve seen teams pour months into infrastructure that looks great on a slide deck but adds no real value to the end user. Worse-I’ve done it myself.

“We build complexity not to solve problems, but to prove we can survive it.”

The boring tools? They don’t need to be explained in interviews. They don’t require architectural justifications. They work. And when they don’t, they fail plainly. Honestly. And most importantly : they’re easy to debug.

“Boring tools don’t promise the moon. They just promise they’ll run-and they do.”

That’s why I default to them. Not because I’m a minimalist. But because my cognitive energy is finite. My time is limited. And my sleep matters. I want infra I can debug at 2AM. I want workflows that don’t unravel when one upstream package sneezes.

“I try a lot of things-but only the ones that earn their place get deployed.”

I don’t need a structured quadrant to tell me what to use. My rule is simpler: if it makes my life easier and doesn’t wake me up at night, it stays. If it introduces more questions than answers, it goes. Tools should be judged on how they behave on a bad day, not just how they shine in a demo.

This isn’t a manifesto against innovation. It’s a reminder that not everything needs to scale to a billion users-or even a thousand. Most systems won’t make it that far, and that’s okay. You don’t need a microservice architecture to serve a few hundred people. You need something you understand, something that lasts. Sometimes, the smartest thing you can do is build something that just works.

Ship boring. Sleep better.