Ler em português
5 min read

Thoughts on good software

Notes on the qualities that, for me, separate software I tolerate from software I keep reaching for.

People keep asking me what I actually do with the software I love. "You use Warp. What do you customize? What workflows? What extensions?" And every time, my honest answer is: not much. I open it. I use it. I don't bend it into a personal IDE. I don't have a curated wall of keybindings. It just works.

That answer used to bother me, because it sounded boring. But the more I sit with it, the more I think it's actually the whole point. The software I love doesn't ask me to do much with it. It slides into the way I already think and gets out of the way.

I want to write down what that means. Not as a checklist for what software should be, because I don't think I get to decide that for anyone else, but as the small set of traits I keep noticing in the tools I reach for, again and again. Maybe naming them helps other people notice what they reach for too.

Patience

The first thing is: it lets you stay shallow.

Take Raycast. You can install it, use it as an app launcher, and never write a single extension. Months can pass. It still earns its place on the dock every day. The depth is there: extensions, scripts, AI, snippets, custom commands. But nothing pulls you down into it before you're ready. The tool meets you where you are and waits.

Obsidian is the same. You can use it as a plain markdown notes app forever. Plugins, graph view, dataview, templates, custom CSS. They exist, they're available, but the tool never shames you for ignoring them. Strong defaults, but never coercive. The depth is opt-in.

Tools that don't have this trait announce themselves immediately. They demand a setup ceremony. They want you to learn their model before you can do anything useful. They make you feel like you're failing them on day one.

Anticipation

The second trait is harder to name, but I felt it the first time I used Railway. The whole infrastructure rendered as a canvas. Services as nodes, connections drawn between them, every config a click away. Nothing to translate. What I was thinking was what the screen was showing me.

That's the feeling: the interface and the mental model are the same shape. You don't spend effort mapping one onto the other. The tool already knew what you came to do.

This is the trait that flips cleanly to the builder's side, too. The pleasure of writing a well-designed API is the exact mirror image of using a well-designed tool: whatever problem someone throws at it, the API feels like it already knew that problem would come. The change you didn't predict has an obvious place to land. Nothing has to be rewritten to accommodate it; it just fits.

When I build something that has that quality, I notice. It's the most satisfying feeling I get from this work. It doesn't happen often, and that's probably the point.

Adaptability

I'm different from everyone else. So is everyone. We all work alone in how we actually work, even when we're working on the same thing.

Good software is good for all of us, somehow.

It isn't that the tool becomes a chameleon. The tools I love have a clear center that doesn't move, and a generous edge that does. The center is what makes the tool itself. The edge is what makes it yours.

Your Raycast doesn't look like mine. Your Obsidian doesn't look like mine. Same launcher, same notes app, completely different shapes underneath. And neither of us is doing it wrong.

Imperfection

Good software will have bugs. I don't think that's even up for debate.

The difference is the kind of bug. The software I love either ships a fix within days, sometimes hours, or the bug is small enough that I don't really care: a cosmetic glitch, a weird scrollbar, something that doesn't block me from doing the thing I came to do. There are paper cuts and there are walls. Good software has paper cuts.

What you're really measuring there, I think, is trust in the maker. You assume they're paying attention. You've seen them fix things before. The bug is annoying, but it isn't a sign that nobody is home.

Familiarity

I keep coming back to a food metaphor and I don't fully trust it yet.

It feels right: good software is like that moment at the end of a long day when you just want a burger. You're not looking for novelty. You want the thing you already know, the bite that already makes you happy. That's how I feel about the tools I keep returning to.

But there's a darker edge to that thought I'm still chewing on. Comfort closes you off. If I'm just reaching for the burger every time, am I missing the next thing that could be better? Is "good software" for me just a polite name for things I've stopped questioning?

I don't have a clean answer. Maybe the honest version is: comfort isn't the goal, but it's a signal. When software earns enough trust that I stop shopping, it has done something right. The danger isn't in the comfort itself. It's in forgetting to occasionally look up.

Inventory

So that's the list, for now: patience, anticipation, adaptability, imperfection, familiarity.

I don't think this is what good software is. I just think it's what good software is for me. The version of this list you'd write would be different. I'd be curious to read it.