The Tools We Use Shape How We Think

There’s a quote often attributed to Abraham Maslow: “If all you have is a hammer, everything looks like a nail.” It’s become a cliche, but like most cliches, it persists because it’s true.

I’ve been thinking about this lately in the context of software development. The frameworks we adopt, the languages we write in, the editors we use — they don’t just help us build things. They shape the kinds of things we imagine building.

The editor as a lens

When I switched from a heavy IDE to a minimal text editor, something shifted. I started writing smaller functions. I relied less on auto-complete and more on memory. My code got simpler — not because I was trying to write simple code, but because the tool encouraged it.

The opposite happens too. Give someone a powerful ORM and they’ll model everything as a database relation. Give them a message queue and suddenly every problem is an event.

Choosing constraints

The interesting move is choosing your constraints deliberately. Instead of reaching for the most powerful tool, sometimes the right choice is the most limited one.

A static site generator forces you to think about what actually needs to be dynamic. A language without exceptions forces you to handle errors explicitly. A deploy pipeline without rollbacks forces you to test more carefully.

These aren’t limitations — they’re design decisions that ripple outward.

What I’m trying to do about it

Lately, I’ve been making a conscious effort to rotate my tools. Not for the novelty, but to keep my thinking flexible. Write some code in a language I don’t usually use. Try a different approach to a problem I’ve solved before.

It’s uncomfortable, and it’s slower. But the code that comes out the other side tends to be more thoughtful.

The tools we use shape how we think. It’s worth being intentional about which ones we pick up.