How Often Should We Sharpen Our Tools?

Blog archive

[there was a] lumberjack who said that if his life depended upon his ability to cut down a tree in five minutes he would spend three minutes sharpening his axe.

Often ascribed, though inaccurately, to Abraham Lincoln, this aphorism neatly captures the idea that, in order to efficiently reach a direct goal we sometimes need to spend time on improving indirect factors such as our tools. In computing, we have access to a wide array of tools, but each takes effort to learn, to customise, and even, if necessary, to create. While our life rarely depends on sharpening our tools, the question implicitly posed by the aphorism is no less important for it. Rather than try and grapple with this question abstractly, I’m going to give an example of how and when I’ve chosen to sharpen some of my tools, and the consequences of doing so.

I spend a huge portion of every day programming or writing in a text editor. For at least 15 years I used NEdit, since that was the closest Unix match to the first (non-Unix) editor I had used, StrongED. When I started using it, NEdit felt modern, powerful, and evolving in the right direction — but, for the last 5 or more years of my use, it was unmaintained and gradually suffering from bit rot. I put some effort into keeping it running on OpenBSD, including fixing crashing bugs. This greatly amused my Vim-using colleagues and I was the butt of many jokes — something that didn’t worry me, because I was secretly convinced that I was right not to waste my time on Vim’s bizarre editing style.

However, as time went on, I became less sure about my choice. It wasn’t just that Vim crashed less often — my colleagues were gradually gaining access to more sophisticated features, mostly through the emerging system of Vim plugins. At first, the differences were minor, but slowly it became clear to me that they were able to work more efficiently than me. I thus realised that I had to make an explicit choice about my tools: should I stick with NEdit or “sharpen my editor” and migrate to another tool?

In the “stick” camp were two arguments. I knew how to use NEdit effectively, and I was bound to be less productive for a period of time in another editor. My todo list hasn’t been empty for many years, and it’s difficult to choose a course of action that causes it to fill up further, even if only temporarily [1]. Less obviously, part of my identity was bound up in my long-term use of NEdit. Admitting that it was no longer the right choice felt a bit like admitting that it had never been the right choice. It’s easy to dismiss issues like this as muddle-headed thinking, but motivational issues are an important factor in all our lives.

Intellectually I knew that the question I should be asking was: if I invest X hours into migrating to a new editor, will I make those X hours back in increased productivity, and over what time period Y? While a precise answer to this isn’t possible, we can often make decent guesses. However, in this case I’d spent so long telling myself that I wasn’t a Vim person that I worried that I’d never become productive in it. An infinite value for Y would make changing foolhardy, but it also seemed quite possible that I was completely wrong and Y might be both finite and manageable.

To resolve my quandary, I eventually decided that I needed some data to inform my time estimates. Thus in late 2014, I announced to my colleagues that I would try Vim for two working days: if I couldn’t be approximately as effective in it as I was in NEdit by that time, I’d go back to NEdit and spend the rest of my days laughing at Vim users.

Surprised by my volte-face, my colleagues kindly gave me pointers to various Vim tutorials that promised to help me remember all the many combinations of Vim commands. That was the obvious place to start because I only knew the ‘a’, ‘i’, ‘dd’, ‘q!’, and ‘w’ commands, knowledge which I had begrudgingly acquired when trying to rescue mistakes I’d made in OpenBSD installations.

However, Vim’s commands weren’t really what had convinced me to waver from NEdit: it had been the plugins I had seen. So, instead of using Vim, I spent almost the entire first day discovering how to configure Vim. In particular, I tried a large number of plugins first to get a sense of what I was looking for generally, and second to see which which specific plugins I might want to use. By the end of the day I had a customised version of Vim that was surprisingly similar to NEdit in basic operation, but which gave me access to all sorts of modern features underneath. For example, I quickly realised that the biggest productivity boon was fuzzy file finding [2].

In the second day, I slowed down my configuration efforts, and started using Vim for some real tasks. I still didn’t know a great many Vim commands, but I now had a powerful, highly usable text editor at my fingertips. It was almost immediately obvious that I was more productive overall, even though some basic things caused me to pause and think. My colleagues, at first bemused by my configuration-first approach, had within a day or two started requesting copies of my configuration. Within a few months I had recouped the time cost of migrating from NEdit and become a moderately effective Vim user [3].

Over the next few years, however, Vim started to emulate one of the things that had driven me away from NEdit: its development seemed slow and sometimes rejected clear improvements for no obvious reason. I wasn’t the only person who felt like this: a motivated group of developers eventually forked Vim to create Neovim.

At first, I was not greatly tempted by Neovim. Migrating from Vim to Neovim looked like it would take almost as much time as migrating from NEdit to Vim, but with many fewer benefits (since, relative to Vim, Neovim wasn’t as fundamental a change as Vim was from NEdit). Slowly, though, a colleague who had taken the plunge convinced me that Neovim had two features that made life better: asynchronous actions (nearly everything in Vim blocked the UI) and the ability to use Lua (rather than the horrors of VimScript).

In early 2019 I decided to migrate my Vim configuration to Neovim. I chose to take on two burdens as part of this: porting neovim-qt to OpenBSD [4]; and migrating my VimScript configuration to Lua. The former turned out to be easy, the latter rather harder: Neovim’s Lua support was not sufficiently documented and there weren’t enough examples on the web for me to crib from. Still, eventually I managed to do so.

Unfortunately, I soon came to regret my choice: I hadn’t gained many advantages but I had unwittingly accepted several disadvantages. For example, Neovim’s API was in flux. Not only did each new version break things, but some of my plugins would adapt to these changes before release, so my configuration would break unexpectedly. My productivity barely changed, and might even have dipped slightly — the chances of recouping my costs looked slim.

The mistake I made was that I hadn’t put enough thought into thinking about how much benefit I would gain from migrating from Vim to Neovim. Indeed, I hadn’t put much thought into what Neovim was. I should have realised that a reasonably recent fork of any program is likely to either offer very little change, or to be in a semi-continual state of flux as major changes are made. Not only did I jump in too fast, but when I encountered warning signs that Neovim wasn’t yet right for me, I ignored them.

There is, however, a happy ending to this story. After a year or so of my starting to use it, Neovim’s Lua-based plugin ecosystem began to bloom — better, often much faster, alternatives to old Vim plugins were now available for Neovim. My tool sharpening moved to a series of changes to my Neovim configuration, which gradually settled into shape. In particular, Telescope and nvim-cmp, in conjunction with LSPs such as rust-analyzer made me a noticeably more productive programmer. I’m very grateful to the Neovim, and plugin, developers, who saved my stupidity from costing me! As this shows, timing and sequencing can be important when thinking about tool sharpening — I might spend 3 minutes sharpening my axe now, cut down the tree, then spend another 2 minutes further sharpening my axe.

Summary

Tool sharpening in computing comes in various guises. Sometimes there is, at least at the moment, no amount of tool sharpening that would be worthwhile. For example, I’ve invested 25 years in using and understanding Unix — another operating system would have to be significantly better for a migration to be worthwhile. Instead I invest small amounts of time here and there improving my understanding, and configuration, of my favoured Unix, OpenBSD.

I also think that there is a place for sharpening one’s tools just for its own sake. Especially as we get older, and our responsibilities increase, anything related to our work can start to feel like a burden. Sometimes even a small amount of time invested in sharpening our tools can bring a bit of joy and restore motivation.

Whatever the outcome we’re looking for from tool sharpening, it seems to me that the most important factor is to think explicitly about why we’re doing it, and what we hope to achieve in so doing. We are lucky to work and play in a field that offers us much scope for improvement, but we also have to make progress in higher-level tasks. Balancing those two factors isn’t easy, but is always worth thinking about.

Acknowledgements: Thanks to Edd Barrett for comments.

Footnotes

Comments