Choose the Right Tool for the Job

I have a handyman that comes to my house every so often to help with some little projects around the house that I'm either too lazy or too unskilled to do myself. When the appointment arrives, the handyman knocks on my door and we do a walk-thru of everything I want accomplished. He takes notes, then departs, and calls a few days later with an estimate. If I'm comfortable with the estimate, we set up a time for him to return to do the work. And when that work day arrives, he shows up with his toolbox, any new hardware he may need, and he does the job.

If the handyman showed up on the walk-thru day with a screwdriver and a few screws, and I asked him to add a new outlet in the kitchen, he'd be screwed. The tools he brought wouldn't help him get the job done—at least not done well.

That is obvious, though, isn't it? Every handyman listens to the requirements of a job before deciding which tools they will use to do the work. The process would be exactly the same if it were a landscaper, or a construction worker, or the fucking cable guy.

So why doesn't it work that way with developers?

The Comfort of Focused Expertise

I'm currently working at an agency that has previously billed itself as a Rails shop. The client wanted a marketing website? Cool. We'll use Rails. They wanted a business application to manage their inventory? Rails. They wanted a landing page for a month-long promo? You guessed it—Rails.

In the web development world, it's easy to suggest that every project falls into one big bucket—everything is just a website. And while that may be true to an extent, the shape, size, and overall requirements for any given site can vary greatly.

We're also living in a time when it seems like there's a new tool available every day. A few years ago if you wanted to build a single-page app, you were probably going to use Angular. Nowadays there is React and Vue (or a thousand others/). A few years ago services like Firestore and DocumentDB weren't as prevalent as they are today—it seemed just as easy to spin up a PostgreSQL database on a Digital Ocean box. A few years ago we didn't have Netlify.

The tendency for a developer to choose the tool they are going to use to build the solution before they know what the solution should be (or even what the problem is) is a comfortable one. There's a lot to know across all of web development. It seems reasonable to be really good at one thing and to be able to offer great value to your clients when you're using that one thing. I totally get that. It takes a lot of time and effort to get into a new technology, and it's a risk when you don't know if that new thing is a novelty or if it'll stick around.

Be The Handy(wo)man

Consider the handyman again. If the handyman only knew how to use a screwdriver, he wouldn't be able to do very many jobs well. He could figure out how to make a screwdriver work like a hammer—he could use it to pound nails in (when used backwards) and to pry them out. But in reality, every handyman knows how to use a screwdriver and a hammer because they each have a specific purpose that the other can't do as well.

So, my handyman has a hammer in addition to his screwdrivers. But how many hammers do you think he has? One. And it's his favorite hammer brand. He doesn't have a Stanley and a Craftsman and Dewalt. Just one. The brand of hammer my handyman chose solves the same problems other hammers solve. It just feels a little different to use. It may be a little heavier or wider or have a stickier grip. The handyman simply picked his favorite.

You, as a developer, should be like a handyman (or handywoman). You don't need three hammers, you just need one. But you should try them all out to know what they feel like and which one you like best. You'll also want a set of screwdrivers, too.

WTF am I talking about?

You don't need to be an expert in Angular, React, and Vue. But you should be familiar with each of them. You should play around with each one, and then hang on to the one you like the most because there may come a time when it will be the best tool for the job. But you don't want to have only the ability to build single-page apps. You should also understand and have a favorite static site generator. And you probably want to know at least one full-stack web application framework (e.g. Ruby on Rails, Django, Laravel).

And when comparing single-page app frameworks with full-stack frameworks with static site generators, you'll prefer one over the others. That's absolutely understandable. But, each one of those three types of tools doesn't solve every web problem.

You should equip yourself—fill your toolbox—with a good variation of tools. And when you get a job, keep your toolbox closed until you know which tool(s) will work best for that job.