We’ve heard it a thousand times already. “Use the right tool for the job”. It’s a very popular phrase between developers. Just look at the number of times it has been mentioned on HackerNews. Or search the internet and see enormous number of articles that DuckDuckGo or Ecosia or any other search engine have on the topic. While it sounds nice and useful, let’s first see some issues with this saying, and also what I recommend you to do when feeling paralyzed by the multitude of tools that people preach are the right ones.
It’s highly subjective
Once upon a time, I’ve had a team lead who was preaching “use the right tool for the job”. Why, of course, who in their right mind would use the wrong tool for the job? Such a person would for surely be a very bad or incapable software developer. There had been only one teeny tiny problem in this case — the right tool was the one he would have chosen to do the job. If any other team member would have chosen a different one… well, tough luck, it’s a wrong tool! Depending on personality type you have to deal with, these situations could either be ironed out or quickly lead to pointless arguments, severely disturbed team atmosphere or something even worse.
Everybody wants different tools
There’s actually a pretty good chance that you are the only person in the world that is a master of some unique combination of tools. To you, those tools you know deeply are the right ones for the job, and you will finish that job faster with them than by using some other tools. But to somebody else, it’s the tools they know best that will allow them to finish the same job faster.
Leonard Lisper would want to use Lisp and functional programming for everything. To him, it’s as natural as swimming is for fish. John Javaman will reach for Java or Kotlin or clojure first. Pete Python will smash a quick prototype using python 3 REPL. Uncle Unixy will think in terms of sed, awk, xargs and pipes to create a shell one-liner. Is any of them wrong? I would say no! Each one of them will finish that job faster then if they learn new tool(s) specifically for this one-time task. I am decidedly not against learning new tools, just against the “there is one and only one best tool for everyone in the world” attitude.
Number of tools to choose is close to unlimited
Your engineering toolbox should contain a number of tools, of course. But there’s no way one can become a master of all of: fzf, m4, httpie, curl, wget, jq, fd, bat, rg, ag, grep, stow, sed, awk, git, GitUp, GitTower, SourceTree, svn, vim, emacs, Atom, Notepad++, bash, fish, zsh, iTerm2, kitty, tmux, cmder, python, Lisp, Java, Haskell, brew, npm, yarn, jEnv, pyenv, IntelliJ IDEA, CodeBlocks, Eclipse, VSCode, gradle, maven, webpack, bower, gulp, docker, Kubernetes, puppet, Chef, Ansible, JUnit, TestNG, mocha, jest, jasmine and a myriad of others! Here I have enumerated almost 60 tools and there’s a minimum of 50 others I have used at least once in the past. Please note that becoming a master of X is very different from “oh, I know how to start X, and I will search the internet on how to use it”. It’s the difference between LeBron James and your weekend basketball buddy. If you don’t know them already, you will spend more time evaluating and choosing the tool than doing the job! Of course, in the long run becoming a master of a wider set of tools will pay you more dividends than becoming a master of a smaller set. And that’s why my actionable advice is…
Choose a few good tools and master them!
My recommendation is simple — choose a few tools (one or two tops for each category that’s important to you) and master them! Sharpen your axe regularly by using them, trying new command-line switches, solving problems with them, reading and re-reading their manual, seeing where the limits are. If you experience some problems in usability, performance, or some other area that is important to you, only then try to find a better one from the same category. If you do this consistently you’ll soon have your own selection of “right tools for the job” that suits you best. And that’s the only thing that’s important. You can and should spread the knowledge about them to your colleagues, friends, acquaintances. Just please don’t force your choices upon them.
Dear fellow developer, thank you for reading this article about fallacies of choosing the right tool for the job. Until next time, TheJavaGuy saluts you!
Comments