In Praise of Good Tooling October 29, 2024

I’ve been working for a over a year now, and I’ve generally enjoyed it; I think I’ve learned a lot and been fortunate to have some great coworkers. (Although I’ve also regrettably not had as much time to blog.) One interesting meta-thing that I’ve learned embarrassingly late: good tooling (in the sense of programs that you use to write code) is actually surprisingly powerful.

To give some context, I’ve historically been a bit of an arrogant Luddite when it comes to tooling. My editor journey has been quite straightforward: when I first discovered programming, I tried a few editors but mostly just used Github’s Atom (long since discontinued). Then, sometime around the middle of high school, I discovered Vim and never looked back.¹ My thesis was always this: the bottleneck in coding is generally thinking, not typing, and so I should choose a simple, lightweight editor. In my mind, the ideal editor was really good at manipulating text and simply got out of my way otherwise. The obvious winner here was Vim.² I coupled this editor preference with a general tendency toward the so-called Unix philosophy that each program should do one thing and do it well. The job of an editor should be to edit text well; if you want to compile programs, you should manually invoke a compiler.

I still think that there’s a lot of merit to this philosophy; learning to use the classic Unix tools passably well is something that pays surprisingly large dividends in productivity as a software engineer. But I’ve increasingly come to appreciate the sophistication of modern tooling, and that nice toys are not only fun, but actually make you more productive. Perhaps I first conceded this point in hardware: pretty soon after starting full-time work, the number of monitors in my home setup conspicuously multiplied, and I became a zealous convert to the world of split keyboards after discovering how much more ergonomic they are.

I think it took me much longer to accept this fact in the world of software. You see, having “grown up” with Vim, when I first interned at my firm, I naturally chose to write all my code in Vim and do all my code review on the command line. This is a bit of an unusual setup at my firm (though certainly not unprecedented); the majority of developers here both write and review code in Emacs. Partially as a consequence of this widespread usage, there’s a particularly robust integration between Emacs and a lot of the firm’s internal tooling around code review.³ Eventually, I found this integration with the rest of the firm’s infrastructure compelling, and I switched over to a hybrid setup, in which I continue to write code in Vim, but I review it in Emacs.

Maybe it’s surprising how long it took for me to embrace more complex tooling, given how quickly I embraced types and functional programming. (And even there, I can readily appreciate how much more difficult it would be to write complex OCaml programs without the assistance of Merlin’s type inference.) I’m not too wedded to this analogy, but in some sense you can think of the type system as a complicated tooling system to help you write correct code.

Note that this isn’t to say that shiny, modern things are always the answer. For a counterexample to that, consider another tooling change that made its way from my work setup to my home setup: I’ve become a believer in i3 as a window manager. It’s not shiny or new, but I think it’s a genuine improvement over my previous Xfce (which I’d settled on after deciding that Gnome was way too heavyweight—why did it need that much memory?). The point is not that I should always embrace fancier toys, but that tooling is an area in which I’ve historically underinvested as a result of a Luddite philosophy and feeling too comfortable in the status quo; there are likely exciting gains to be had by investing a little more time in tuning my setup. One example that comes to mind is merge conflict resolution—I still just open up the files in Vim, search for conflict markers, and manually edit the files until they end up in the state that I want.⁴ It is, of course, very easy to err in the opposite direction and spend all your time tweaking your editor config and none of your time actually writing code, but I think I have generally made the mistake of not thinking enough about my editor config and similar things.