Some time ago, I had to do a high availability installation for a customer. That installation made me realize that sometimes very important; I tend to throw new tools at a problem instead of learning the old one. Let’s put a bit of context first with how that story went. Those type of installation usually entails multiple (3 to 9) machine configured mainly the same way. For this reason, we created scripts that set up everything for the installation then we need to finish it manually with some extra information. This time was different, though; the customer wanted an installation in their servers for security reasons. That means we don’t have our setup done in advance. So I went at it manually. After the thirds server, I realized it wouldn’t work. Even with just copy-paste, there was too much to keep track across all nine. So I tried and found tools to help me, as one does. None of our usual tools were able to work either, for the same security reason. But then I accidentally found out tmux can actually do what I needed. I sat there dumbfounded that this tool I’ve been using all day long every day was the answer to my problem all along. Then my brain went back to the days I lost over the years, fiddling with other inferior tools trying to get this thing to work.
Mastery first
Often the first reflex, when we hit a problem, is to try to find a tool to help us. That’s pretty natural, especially in IT, as we tend not to want to spend too long on a problem. But I’m arguing here instead our first reflex should be to look at the tools we already have. Especially with UNIX/Linux system, many of the standard tools have extensive and surprising features. Tools like SSH, AWK, SED, Grep can do a near-infinite number of things in their respective area. If you decide to take the time to master your tools instead of just using them for one thing, you will be surprised. This might seems to clash with the ethos “Write programs that do one thing and do it well.”, but only on the surface. The main reason those tools have a single purpose is that they are to be used in a chain of commands. But that purpose is often extensive and open, SED, for example, is used to manipulate text. Whether its text from a configuration, a script, a shell output doesn’t matter. If you want to edit text, you can master SED and use it on all your text. That’s the only tool to learn instead of one tool for scripts, one tool for text, etc.
How deep does the rabbit hole go
Mastery of a tool can mean a wide variety of things, depending on the context and the tool. Some tools probably can’t be mastered unless you spend countless hours of research and practice, I’m looking at you AWK. But if you know the core features of the tools and have a good knowledge of its use in your situation, it’s enough. You mastered the tools for your job. If this situation change, then you try to learn the tool for that new situation. The idea is to expand your knowledge and mastery. Master the tools as much as possible, instead of increasing the number of tools.
Tools minimalism
Mastery of your current set of tools also fits well with minimalism in some respect. If you master a small number of tools to do most of your work, it’s a form of minimalism. A smaller set of tools also create less overhead in most situation. You don’t have to install new things. You don’t have to keep track of its update, upgrade and security patch. There’s no added configuration overhead. Those things are not always painful, but they add up over time. Mainly if you use this new addition for just one purpose or scenario in your work. A wide range of tools also makes it harder for other people to use the same system. The more tools you have, the more they will also have to install and learn to do the same thing you do. If those tools are not cross-platform, that also creates a different set of problems. The worst problem is if you get into a habit of “oh shiny!”, where you switch tools all the time for a minimal gain. All of the issues listed above will quickly exponentially increase as you keep changing tools around and the benefit will be negated.
Using different tools
Sometimes, even if you have a good mastery of your toolset, there could be a situation where none fit. It might be the case that the use-case for the tool is new or completely different from what you usually do. It could also be that this feature you require is only available in one specific application. Those are good reasons to add a new tool to your system. There could also be an external reason, like in my story, where customer security measures restricted me. In my case, it turned out to be useful since it made me discover a new facet of tmux. It could also be that what you’re currently using doesn’t work anymore. But those cases should be the exception of adding new things. I’m not saying you should stay “stuck” with the same tool forever, that’s just as bad as the other extreme. What should happen is, stop adding new tools for every new problem, unless you see a real need and then be mindful.
