| Contents |

6 Right Tool for the Job

“What’s the best programming language?”

It’s a common question from people getting started in programming. And commonly people do have an opinion, especially when they’re starting out.

But anyone who has been in the field a while will tell you that there is no “best” programming language without knowing the context of the problem you’re solving.

I don’t know anyone who would declare that Bash scripting27 is the best programming language. But there are definitely problems for which is actually is the best solution!

Let’s analogize! What’s better: a screwdriver or a hammer? Trick question! They’re both the best tool, but only in the context of the job they were designed for.

Different programming languages have different strengths and weaknesses. It’s your job as a developer to choose the hammer for nails and the screwdriver for screws, and to be proficient with both those tools. “I’m not familiar with the table saw and I don’t really like it, so I’m going to use this hammer to cut that plywood” is not the solution your boss is looking for.

My scuba instructor had some advice for me. I was looking at buying some kit and was deciding between standard fare and DIR28-style equipment.

He said, “Be the best diver you can be in any equipment. I don’t care if you’re diving with a 1960s horse collar and J-valve tanks.”

The best developers have a lot of tools in their belt, and they know how to use them.

So when you find yourself saying, “This language sucks and I hate it compared to that other language that I love!” consider the use cases for that language that you hate. Because it was created for a reason, and identifying it can let you know when you should use it.

And since you’re dying to know, my favorite language is Rust.

Or Python. Or C. Or JavaScript. Or SQL. Or AWK. Or Bash. Or… well, it just depends on what problem I’m solving!

6.1 Be Opinionated

Didn’t I just finish telling you that you should give all languages a fair shake and not play favorites?

Yes. But I swear this doesn’t contradict that.

Why be opinionated? It’s because you should be deliberate and well-informed in the choices you make. And a good way to make that happen is to be opinionated with a rationale. It forces you to dig into the strengths and weaknesses of various technologies, and that helps you choose the best tool from your kit for a particular job.

None of this is meant to imply that you should be a jerk about it. It’s not about who’s right or wrong—nowhere is any of this written in deific stone. Everyone is both right and wrong at the same time. It’s very Schrödinger of us.

You should be opinionated about the tools that you choose. Out of everything at your disposal, you chose this language and build system to use. You chose this editor or that library. You should have a rationale for why they are the best, even though plenty of other languages or tools would have sufficed.

You should be opinionated about the data structures you choose. Coding is a creative endeavor—you can make everything a Turing machine29 if you wanted and solve the problem that way, but there are a lot of other options. Choose the best ones and have a rationale for why you chose them out of all the other options available.

You should be opinionated about the algorithms you choose. Mergesort, right? Just use that. But there are actually times that lowly insertion sort is better! Binary search? Why use it if linear search is good enough for the job? Have a rationale as to why you chose that algorithm when you could have used another one.

When deciding, you might be considering things like performance, or maybe readability of the code, or development time required, or tool cost, or what tech the existing codebase uses, or all kinds of other factors.

You must always be willing to learn more. No matter what you choose with your rationale, half the Internet is going to disagree with you. And you know what? Your future self might even disagree with you!

As you learn more, you will learn specific cases where some particular technology is best, where before you thought it wouldn’t be. Be open to learning, and change when appropriate. This can be something as big as the choice of framework for the product that defines your entire company, or something as small as whether or not array variables are plural.

With growth, your choices will change. And, as long as you have a rationale behind it, that’s a good thing.

6.2 Chapter Reflection


| Contents |