No Best Tool For The Job

How do you choose the best tool for the job?

Suppose you want to plant a tree in your backyard and need to dig a hole. You go to the nearby hardware supply store and see these options:

You don’t have to be a PhD in Gardening to know which tool is best for the job. It’s self-evident from the size of the tool and its cost.

The next day you decide to build a web app. You go to a catalog of website-building tools and you see this:

Let’s imagine for a moment that you are relatively new to programming. How would you pick the best tool for the job here?

All these programming tools look the same

Unlike tools for digging holes, all these websites look the same. They all promise the same thing — build your web app. It’s not clear why you’d pick one tool over the other. So you dig a little deeper…

Infinite fractal of categorization

…and discover an almost infinite amount of specialization. With hardware tools, the categories are more defined: here’s a shovel, and here’s an excavator. There’s nothing in between. With programming languages and frameworks, for any two tools, there seems to be another tool in between.

The job of evaluating the tools becomes harder than the job of actually using the tool.

You could just pick any tool and get started, but…

Too easy to choose the wrong tool

With hardware tools, the price and the size of the tool give you a strong hint of what it is best for. Sure, using an excavator to dig a hole for a tree sounds like a ton of fun, but buying or renting one is way too expensive. Plus, you need to learn how to drive one, get a license, and it definitely doesn’t fit into your backyard.

With software tools, it costs almost nothing to choose the wrong tool for the job. They all optimize for getting started quickly. Building a static website with GraphQL — easy. Use Kafka for a one-person backoffice app — no problem. You can spin up both in under 5 minutes, for free.

So how are you supposed to make a good choice for your web app? Well, you could search for some advice on Reddit, X, or HackerNews…

Advice overload

…and get overwhelmed with the amount of opposite opinions. “React is the best” / “React is the worst”, you should always render things on the server, you should make a single page app, use static types, use dynamic types, functional programming is the way, functional programming is too slow. The list of contradictions goes on and on.

The people shouting the advice sound extremely confident. If you dig deeper, some of them are actually employed by the tech stack they are preaching, but even outside of obvious economic incentives, it’s just too much noise to sort through.

Meta advice is just as polarized. “Pick a tool you already know” vs “learn new things”, “choose a popular tech stack with a large community” vs “choose niche tech stack with a great community”, “focus on clean code” vs “focus on business outcomes”.

—

So my mind gets stuck on this one. How do you pick the best tool for the job?

The only way out of this pickle situation I found so far is to turn around and face the question itself. What does “the best” even mean?

Back to the tree planting, the choice is simple, so it’s obvious which tool is the best. In programming, we no longer have that luxury, thus maybe the concept of “the best” doesn’t work anymore. The options are just too close, too nuanced, and the consequences are too fuzzy. Even if you are an expert in these tools, there are still enough unknowns to make the choice non-trivial.

When the options can’t be plotted on a single axis with clear “good” and “bad” fits, there’s no “best”. There’s only “good enough”. And if we give up chasing “the best tool for the job”, we might just free up enough mental space to use “the good enough tool” to actually plant that tree.

Related posts:

No constraints, no fun

Why side projects are hard

Plotting ideas