I had a realization the other day while searching for my ½ to ⅜ socket adapter. I had lost it somewhere on my bench top in the ever growing pile of tools that I tend to accumulate during a project rather than just putting each tool away once I’m done with it. Unfortunately, the realization was not that I should just keep my workspace clean while I’m working (still waiting for that one). The reason I was looking for my adapter is because most of my sockets are ⅜ drive, but I have at some point in time long forgotten lost my ⅜ socket wrench, so I end up using my ½ wrench instead, thus requiring the adapter. My first thought (also not the realization) was that I should really keep a spare adapter handy just in case. I pretty quickly realized that wouldn’t actually solve the real problem and that what I really needed to do was just buy a new ⅜ drive socket wrench (that is actually a lie, I had another idea prior that I should buy a whole new set of ½ sockets).
My actual realization was this - more often than I care to admit, I find myself reaching for the tool that is right in front of me rather than stopping to think about what the right tool for the job should be. I suspect I’m not the only one either. As engineers it is part of our job to know the best tool for any given job, but oftentimes we see just the opposite. Systems built with components that create undue complexity because that is what the developer was comfortable with. Development workflows that introduce friction, but developers just accept as the way things have always been. Tooling decisions and refactors made based on the current hype cycle without regard for actual needs and requirements.
Unlike a simple socket adapter, most of the time the problem sets we encounter in our day to day jobs don’t have easy solutions. Knowing what the right tool is for any given situation can be difficult and require significant amounts of context, experience, and knowledge. This is because the right tool for any given job is based on a variety of internal and external factors such as cost, complexity, effectiveness, availability, just to name a few. Over or under valuing one of these factors at the expense of the others can lead to locally optimal solutions that are globally sub optimal. Most engineers will acknowledge that the cheapest tool isn’t necessarily the best. Perhaps more subtly, a team that chooses a database backend because it is technically the most efficient for a certain problem, but is one that has a high licensing cost and is unfamiliar to most of the team can have significant downstream impacts on speed to market, stability of customer facing production systems, legal/licensing concerns, or any number of issues that ultimately negatively impact revenue.
There is no one size fits all strategy for knowing how to select the best tool for a given problem. Sometimes there really is only one tool and there is no decision to be made. In the times where that isn’t the case, it helps to have a framework for how to approach the decision. I’ve outlined a few general principles that I like to use and have served me well, but you should add to and tailor them based on your own preferences, experiences and situations.
- Master the basics. Any good builder should be proficient in the fundamentals before moving on to more esoteric tools. A woodworker that has mastered a hand plane, chisel, hammer, saw, and drill can probably build the vast majority of things they need.
- Start general purpose and move to more tailored tools as required. This is really an extension of the first point which is to say that you should default to the fundamental tools and move to more specific tools as size/scale requires. It can be tempting to overfit tools to a problem, but this runs the risk of ballooning architectures that are overly complex and brittle to small changes. I like to have a set of go-to tools that act as my defaults to get me moving quickly on most general purpose solutions.
- Keep up to date on industry standards and best practices. There is no singular ‘best practices’ guidebook, but staying knowledgeable on what tools other teams are using to solve similar problems gives a good starting point. Strive to be aware of the larger tooling ecosystem across your industry. Chances are you won’t need to use the vast majority of them, but being aware of what is available prevents you from reinventing a wheel that has already been built.
- Always be aware of the broader business context. Politics, budgets, timelines - we don’t like to admit it, but these are significant factors that can change the calculus of what the right tool might be. The way I like to think about it is that within the technical scope of a project we have a fairly intuitive understanding that everything is a tradeoff - a bigger screen on a phone means more power requirements which means either a bigger battery (larger phone) or shorter battery life - the same is true across the non technical domains and ultimately human systems that comprise your organization. Understanding these tradeoffs will help you make better technical decisions.
There will be plenty of times when the best tool for the job really is the one you are most comfortable with and is right in front of you. In fact, as you develop your skills and hone your instincts you’ll find that you naturally build up a toolbox that fits a wide variety of problems and serve as reliable defaults for most situations. What separates the good engineers from the great ones is the consistent evaluation of the tools in that box. Are they comfortable because they fit, or because we’ve used them so long we don’t know anything better? Do they still effectively solve the problems we encounter, or are we forcing them to do things they weren’t built for? Are those annoying inefficiencies unavoidable, or are there better options? The important thing is that when we go to grab that familiar tool we continue to ask ourselves ‘is this the best tool for the job?