On Being Passionate About Tools
Get to work. Grab a cup of coffee, some water. Possibly breakfast.
Sit down at my desk. Log into my computer, looks at i3wm.
Launch a new terminal session. ranger. Enter. Navigate to project. nvim. Enter.
space f. Use fzf to open necessary file.
This is a daily workflow for me. Before I start typing code, I use about four tools to get to it. Notice, I haven’t mentioned touching the mouse once yet; Because I haven't touched the mouse yet.
Throughout my academic and professional career as a software engineer, I spent a lot of time using tools. Trying new tools. Searching for tools. Customizing tools[1].
Although this might be a commendable feat, it is often met with skepticism. A lot of skepticism.
I’ve had at least a hundred conversations with people about tools, about why they advocate against using such tools. These conservations were with other students, senior software engineers, and tenured professors; and generally, almost all of them fell into three, distinct buckets of people.
It’s a waste of time.
There is by far the worst yet best counterargument against investing so heavily into tools; and the reasoning is in the trailing, three words.
waste. Better tools will objectively help one write more code. If there is a modification that needs to be made at the end of the file, it takes one keystroke to jump to that positions in Vim. Picture doing this, but 100s of time a day.
of time. There is a time commitment, a big one. And there is a learning curve, and it is steep. So, one would have to justify the reasons for learning it. And I’ve done so below.
What I have works just fine.
I’m deeply skeptical of the “If it’s not broken, don’t fix it” mentality. There’s always room for improvement, and there’s nothing more I love to see than improvement.
It’s why we buy new phones. It’s why we like nice, new cars. It’s why we, as civilization, love progress.
Even if it’s a marginal increase, say 5% more code a week. With a 100 lines of code written a week, that can be a about 250 additional lines of code written a year. A marginal increase, sure; but a welcomed one.
It doesn’t really make you a better programmer.
I generally have three core reasons against this, and they are as follows.
It’ll help write more code, faster. It is objectively faster to type more code if your hands never leave the keyboard. It’s faster to navigate a filesystem without having to focus on where a cursor is. It’s ridiculously faster to open a file to just type out parts of the filename apposed to navigating to it.
It’s healthier. Legitimately. Minimizing hand travel will significantly put less strain on your hands, wrists, and arms.
It’ll make you a better programmer. As programmers, we have to learn things all the time. New programming languages, new paradigms, new company software. Learning a new tool keeps a mind sharp by reinforcing how to learn something. Plus, the skill is fluid. Learning to navigate in vim will help navigate in ranger. Learning regular expressions can be used in fuzzy searches. The skill are transferable.
So, where might one start? Again, there are three areas I see that can have the most benefit from improving your workflow.
Your operating system. Whether it’s Windows, MacOS, or Linux, you have to use an operating system. Get good at it. Learn the paradigms of the system. Learn how the file explorer works in Windows. Learn advanced features in MacOS like a spotlight alternative or simple hot corners. Or learn how to set up your WiFi drivers in Linux.
Your text editor. Choose one’s that portable. I use NeoVim. Many people have success with Emacs. Some people prefer a visual editor like Sublime Text or Atom. Learn their workflows. Learn the shortcuts of Emacs. Learn how to edit text in Normal Mode using Vim. Install packages in Sublime or Atom. You spend most of your time here anyway, might as well get familiar with it.
The intermediary layer between your operating system and your text editor. By this, I usually mean the shell, like Bash or ZSH. Learn how to grep or navigate around. Install packages to make tasks easier. It’s well worth it.
So, yes, I am a strong advocate of using advanced tools. Established tools. Great tools. And I hope I’ve convinced you to do the same.