Make it boring

Fri, 27 Mar 2026 13:00:00 -0300

There is a moment I recognize by now. I am moving through a codebase — fixing something, reviewing something, sometimes just reading — and a corner of it catches my attention. Not because it is broken. Because it bothers me. A pattern that could be cleaner, an abstraction waiting to exist, a decision that made sense two years ago and no longer does. The code is not stopping me. But it is talking to me, and I am starting to listen.

I have learned to notice when this happens, because what comes next is expensive. The mind shifts. The original task — the product problem, the user-facing thing that actually needed solving — moves to the background. What fills the foreground is the code itself. And the code, I have to remind myself, is not the product.

This distinction sounds obvious until you watch how rarely it governs decisions. Most teams treat code quality as a proxy for product quality, and up to a point that is not wrong. Poorly maintained code slows you down, introduces risk, makes the next decision harder than it needs to be. The correlation is real. But the relationship is not symmetric. A clean, elegant, architecturally satisfying codebase can coexist with a product nobody wants. The code can be a pleasure to work in and still be building the wrong thing.

Time and attention are finite. Every hour spent on an abstraction that was never causing pain is an hour not spent understanding why users are dropping off, or what the next feature should actually do, or whether the current direction still makes sense. These are not equivalent trade-offs. One of them compounds into product understanding. The other compounds into a codebase that feels good to its authors.

What I have come to believe is that the right goal is not a beautiful codebase. It is a boring one.

Boring means predictable. It means a developer can open a file they have never seen and understand what it does without effort. It means patterns are consistent, names say what they mean, the structure does not surprise. It means the code has no personality — no clever solutions, no idiosyncratic choices that reflect a particular developer’s taste on a particular afternoon. Boring code does not ask to be noticed. It simply works, and then it gets out of the way.

This is harder to build than it sounds, because the instinct moves in the opposite direction. Developers are problem solvers by disposition, and a codebase is a permanent, visible surface full of problems to solve. The senior ones know better, mostly — they have seen enough to understand that cleverness has a cost, that the brilliant abstraction you are proud of today becomes the thing a new teammate cannot decipher six months from now. But knowing better does not make the pull disappear. It just makes you more conscious of it when it arrives.

A boring codebase is not something you build once and move on from. It is something you maintain, in small acts, continuously. The naming convention you enforce in a review even when it feels pedantic. The refactor you decline because the existing code, however imperfect, is clear enough. The new pattern you resist introducing because the old one, however unsexy, is what everyone already knows. These are not passive choices. They are the daily work of keeping the code uninteresting — of preventing it from accumulating the kind of complexity that starts to demand attention it was never supposed to receive.

The discipline is in knowing what you are protecting. You are not protecting the code. You are protecting the attention that would otherwise go to it.

When a codebase is genuinely boring, something shifts. The non-obvious decisions become visible again. Not the ones about which pattern to use or how to structure a module, but the harder ones: what this feature should actually do, whether this is the right problem to be solving, what the user is really asking for underneath what they said. These are the decisions that determine whether the product works. They require the same cognitive resources the code was consuming, and they deserve them more.

I still feel the pull. I probably always will. But I have come to understand it as a signal worth questioning rather than following — a reminder that the codebase is trying to become interesting again, and that my job, in that moment, is to make it boring.

In praise of brutal software

Sat, 31 Jan 2026 11:00:00 -0300

Recently I’ve been watching a lot of content about architecture. Not software architecture, but actual buildings. There’s something about the way physical structures are designed and constructed that resonates deeply with how I think about software engineering.

Architecture, at its essence, is about crafting spaces where people can live, work, and connect. A building might be visually stunning or elegantly simple, but its true success lies in its livability. If it cannot be inhabited, it has missed its purpose. It might qualify as art, but it ceases to be architecture.

Engineering isn’t so different It’s easy to get caught up in abstractions, patterns, and the excitement of creating. We often fall in love with the craft: the cleverness of a design, the precision of an implementation, the elegance of the code. But elegance without purpose is just ornamentation. What we build isn’t meant to be admired from afar; it’s meant to be used, trusted, and integrated into people’s lives.

We create products through software, not the other way around. Our role isn’t to make technology fascinating — it’s to make it practical, reliable, and impactful. A system that’s technically impressive but disconnected from its purpose is like a museum exhibit: it might be admired, but it cannot be lived in.

That’s why true ownership begins long before the first commit, or even before the first line of code is written. It starts with understanding the problem, questioning the assumptions, and ensuring that what we’re building is worth building. Code may be the most visible part of the system, but clarity and purpose form the foundation that holds everything together.

And just like in architecture, we don’t build in isolation. Collaboration with design, product, and business teams is essential. Each perspective contributes to shaping a structure that is not only functional but also resilient and aligned with its purpose.

Over time, this mindset brings clarity to what engineering truly entails. It’s not about invention for the sake of novelty. It’s about creating something that earns its place, something people can rely on without ever needing to understand its inner workings.

Maybe that’s why I find myself drawn to architecture, especially brutalism.
There’s an honesty in its raw concrete, unadorned surfaces, and exposed structures. Brutalism doesn’t seek approval or admiration. It exists to fulfill its purpose, which is to provide shelter, stability, and longevity. And in that steady commitment to function, it reveals a quiet, understated beauty.

Brutalist buildings often evoke strong emotions, but their appeal is incidental, not intentional. Their beauty lies in their authenticity: every element has a purpose, and nothing is superfluous.

Good software shares the same essence.
It doesn’t rely on decoration or fleeting trends. Instead, it is purposeful, straightforward, and honest about its intent. If beauty emerges, it’s a byproduct of its authenticity, not a deliberate attempt to dazzle.

We don’t create to impress. We create to be used.
Code is merely the framework; the product is the structure it supports.
The finest architecture — whether physical or digital — is the kind that quietly fulfills its purpose, enduring long after its creator has stepped away.

Gabriel Teles

Make it boring

In praise of brutal software