Noel Rappin Writes Here

Look, I said it was a weird trick, not necessarily an effective trick…

Every day, it seems, I get a digest from Medium that has a bunch of articles that are all titled “9 VS Code Extensions That Will Change Your Life”. To be completely honest, I read a lot of them, and I actually do find some useful tips. But I want to back up a second and talk about developer tools in general.

You should know this: I’m something of an outlier when it comes to developer tools. I don’t, and have never, used Vim. (Okay, I tried it once and didn’t care for it.) I use (and have basically always used) dark text on a light background, which I think is roughly true of about 1% of other developers I have worked with.

Every Monday, I start my week by selecting a VS Code font and color theme at random from a list of good ones that I have. This is a completely ridiculous thing to do, and I don’t recommend it, except that it makes me happy. (I also randomly pick a new accent color for the Mac OS system, which is even more ridiculous, and probably makes me even happier.)

With all that said, I still think I have useful advice about developer tools. But if I haven’t made it clear, you should take it all with a grain of salt. The important thing to realize is that programming is a very complex cognitive skill and different people approach it in different ways and different tools make things easier for different people. That said, if you have a bunch of coworkers who use Vim/Tmux or whatever and the like and it just does not click in your brain, here are some of my tricks.

(Sidebar statement for open debate: the success of Vim means there is something that we, as a community deeply do not understand about what makes a tool usable, in that there is no conventional user experience path that would lead you to end up with Vim, and yet it is beloved by its users.)

The point of developer tools is not so much to make you faster, but to reduce the cognitive load of development. The idea is to make relevant information and commands available without you having to break your concentration to think about them. Lightening your cognitive load should make you faster, but it’s a different kind of faster than you’d get by, say, mapping shortcut keys to your most commonly typed commands.

(Another sidebar: I currently own four different keyboard shortcut utilities and I use a bare fraction of their abilities. I do have Better Touch Tool wired to make a three-fingered swipe move the open window to the other monitor, and that’s kind of fun)

A big influence on how I think of my developer environment came from when I used to professionally study user design. Turns out that way back in the early years of the Mac, Apple did a bunch of studies that showed the following:

• Users regularly self-reported that keyboard shortcuts were faster than a mouse.
• A stopwatch regularly found that the mouse was faster than keyboard shortcuts.

The reason for this, bluntly, was that using the mouse was boring and did not interrupt thinking but that using the keyboard shortcut required a high-level decision that did interrupt thinking and also threw off users’ subjective experience of how much time had passed.

We can quibble about these results until the cows come home, leave for work again, and come back, and I certainly acknowledge that the computing environments of 2020 are different than 1984. (Although nobody was as good at arcane keyboard shortcuts than people who did word processing on pre-1984 word processors. Look up Word Perfect keyboard overlays…)

My practical takeaway from this is that keyboard shortcuts are faster if and only if they become so ingrained that they are cognitively boring to activate. I personally find there’s a pretty hard limit on how many of those I can keep in my brain, and that limit is about 10, give or take. Given the results above, I’ve tended to try to optimize for environments where I can see or search for all my options rather than tools that require me to memorize. Even if the visual search seems slower, I can do it with less disruption.

A sidebar here is that in my official position as The One Person Who Likes The Mac TouchBar, I have customized the Touch Bar for VS Code to put in about a dozen things I do commonly, but can’t remember the shortcut for (like show the current file in the tree view). This gives me my dozen shortcuts, but I don’t have to memorize anything.

For example, Git.

Git is an extremely powerful tool with a command-line structure that can charitably be described as Byzantine, and there’s no shortage of people willing to show you shortcuts to commonly used or uncommonly used features.

I bypass nearly all of that, almost the only thing I do on the command line is reload the master branch. Everything else, I do in a GUI, these days I use Fork.app. Not only does this mean I don’t have to memorize arcane commands, but I also have a nice visualization of the Git log, and I have the ability to discover Git features that are a huge pain from the command line (like interactive rebases).

I have one genuinely weird Git use case (the source code for the books is structured in a series of sequential branches, which is not what a normal project looks like), and Fork makes it way easier to manage the structure.

While I do have a number of command line aliases defined, I find that they have the same issue as keyboard shortcuts in that there are only so many that I can keep in my head and use without thinking about it, maybe about a half-dozen.

What I do instead is use some tools optimized for offloading my memory. In ZShell, I use the Oh My ZSH history substring search plugin, so for most complex commands I only need to type in the part I remember, hit the up-arrow, and find the last time I type the command. I do this all the time. For example, I’ve never been able to keep a shortcut to run RSpec in my head, I usually type the command for a specific file I’m working on once, then keep up-arrowing every time I need to run it again. I also tend to use a separate terminal application rather than using the terminal inside VS Code or RubyMine or whatever. I find I prefer the overlapping full windows to the single display of half windows.

Where I do use aliases, it tends to be for things where I’m afraid of errors when I type, not that I’m afraid that I’m typing the command too slowly. A related note is how much I like Emmet for typing HTML, not because it’s less typing, but because it ensures accurate syntax.

I’ve also long been an outlier in using a larger screen font for code than most everybody I’ve ever worked with – 20 - 24 points depending on the font. These days you could just say it’s fading eyesight, but I’ve always done it, and actually my close up eyesight is still pretty good.

I’ve always found it easier to concentrate on larger type, and I think doing so guides me to shorter lines and shorter methods in a way that works for me.

What’s important, though, isn’t what works for me, it’s what works for you. Try new things. One reason I keep reading all those Medium articles is the hope that I will find something that really does fit my brain and make my work life just a tiny bit easier.

Thanks for reading all the way to the end. I’d love to hear about your developer tools — I’m fascinated by how different coders work.