It would be an easy mistake to assume an engineer is merely a subordinate reflection of his tools. There is a dialogue, in most unconscious and in few conscious, between the engineer and the means he uses to will ideas into existence. This dialogue is painful. It presupposes the willingness to abandon what’s comfortable, to say “I fucked up. I took a wrong turn back there somewhere.” It demands the humility to pack up your keyboard and mouse into a duffel bag with a few cinderblocks and cast them into the ocean if that’s the necessary sacrifice to get the process right for tomorrow, maybe even a year from now.

The degree to which this dialogue becomes conscious for an engineer linearly correlates with how much the work they are doing matters. What matters in soft ware? I once met an engineer who was working at Meta. He had only recently begun working on the ranking algorithm for Facebook’s news feed over a decade after its creation. I love learning how the sausage gets made so I inquired about the specifics - What levers were there to pull? How granular were the modifications? What was considered “improvement” and how was it measured? To my last question on measurement, he responded that metrics were gathered over months, usually only deviating from the norm by fractions of a percent. Changes to the algorithm were largely planned by what seemed to me like hunches, inklings, intuitions… The engineers working on the ranking algorithm had no idea how their changes would affect the output result. Even using metrics to measure these changes could anyone say that movement by a fraction of a percentage point was anything more than temporary noise in the general patterns of users? The work did not matter. It was not solid. Action could be taken by modifying the algorithm but no consequence of the action could be directly pointed to or even said to have improved things.

My wife will be the first to tell anyone that I am always a bit annoying when we are stopped at a Tesla Supercharger because I always say the same thing. “I don’t remember if I’ve told you this but my friend Rock wrote code that runs on that Supercharger.” Rock is the kind of engineer who builds things that matter. Not all ephemeral glyphs on the screen are made the same. The code that Rock writes often finds its way towards intersection with the physical world, things that matter, things that have real consequences, not mere “fraction of a percentage point” consequences, if they go right or wrong. This constraint nurtures an egoless pragmatism in engineers and it’s evident in Rock. When performing such work, very few things can be brushed under the rug, or rationalized by pointy-hair MBAs, it’s obvious how the result is working, if at all. I didn’t want to make a big deal about the objectified meaning of the name Rock so it will suffice to say that sometimes symbolism in reality is truly better composed than in fiction.

Rock graciously got deep into the weeds in our conversation about his process and tools. I believe that his setup is a deep reflection of not only the work he does but how he thinks about engineering problems. He has struggled greatly as evidenced by the painstakingly wrought shape of his setup. You might think some of the choices Rock has made are great or ridiculous and this is valuable information for the reader to pay attention to, noting possible modifications to their setup. The truth that I understood from our interview however was that Rock’s setup fits Rock’s way of working perfectly, without unnecessary decoration or cruft. Let’s begin, as is fitting for this interview, with hardware.

The Hardware

Rock’s primary input devices include a Logitech MX Master 3 mouse and a Kyria split ergonomic keyboard.

At first glance, I was confused by the mouse choice. It’s a quite complex mouse for an engineer that prioritizes efficient keyboard-first workflows. Rock doesn’t merely use the mouse for pointing and clicking, instead, every button is mapped to specific, oft-repeated actions. One example of this is tab switching. Rock prefers using tabs in his workflows. Tab-switch key combos aren’t always very comfortable on the fingers. On a regular Mac keyboard, OS windows are toggled with CMD + TAB, my hands naturally fall to my thumb and ring finger for this combo, not bad. Other apps use a diminutive form of this for tab switching, typically CTRL + TAB, which for my hands could be thumb and ring finger again, but I’ll find my pinky getting involved for CTRL if I’m moving fast or if I’m adding the SHIFT key to tab in the opposite direction. Rock has brilliantly mapped his mouse’s thumb scroll wheel to this function so he can just scroll through tabs in either direction. Pretty sleek.

His mouse layout transcends 1-to-1 mappings as well. Using Logitech’s MX software he has customized the mouse to support various “gestures”. When the thumb flange button is activated (sort of a thumb down towards the desk motion) and the mouse is moved, other mappings are kicked off based on the motion pattern of the mouse while the thumb flange is depressed. This allows for a massive number of additional mappings. Rock has also done some mapping work on his MacBook Pro trackpad via the jitouch app. The MX mouse gestures seem to be in the same spirit.

Rock’s Kyria keyboard was a custom build from a template. The construction of the keyboard began with ordering some parts from splitkb.com some from typeractive.xyz, and some from Amazon. Next up was a full day’s worth of soldering and assembly of the case and keycaps. Finally, the difficult part, customizing the keys. The keyboard has only 48 keys and two dials, one smooth turning and one with clicky positions. If you have a standard keyboard you can get an approximate mental image of how many keys that is by visually eliminating the following from a full sized keyboard; no numberpad or associated keys (numpad +, numpad =, etc.), no function row, and no number row. The keys that remain are rearranged into vertical columns instead of being staggered. No key is wider than a standard letter key so you get 6 keys crammed into your thumb areas, which makes a bunch of sense because your thumb is very dexterous (thanks smartphones) and strong - a point I’ve made before.

The ergonomics of the Kyria are excellent. The keyboard is split which helps to minimize internal rotation of the shoulders. Most importantly, the typist is prevented from doing dumb things with their hands like stretching too far or drifing hand positions because both of these things are mostly impossible. Rock pointed out that if a user’s fingers are in the home position, there is no key that they can go to that is more than one key-distance away - with the obvious exception of the thumbs. Rock mentioned that he had never learned to touch type before switching to the Kyria. I suspect that this is due at least in part to the ability of hand position to drift left and right across a contiguous keyboard. On the Kyria, there is no drifting over center because there is no center.

As always, the challenge with so few keys is mapping. Keyboards with so few keys typically employ a feature called “layers” in order to simulate more keys. If you have ever typed a capital letter on your keyboard you have used layers whether you knew it or not. When you press the J key you get “j” yet when you hold shift you get what is, to the computer, an entirely different character, “J”. One key, multiple functions depending on which “layer” is engaged. Shift temporarly enables this “capitals” layer as long as you are holding it down. Caps Lock toggles this layer until Caps Lock is pressed again. Expand that concept out a few dimensions and you get the layers required for a keyboard such as this. Imagine what would happen if holding down the Pg Up button changed all of your keys to emoji, or if double tapping the right arrow skipped to the next track in Spotify, the possibilities are endless.

Rock’s keyboard contains a few tried-and-true layer mappings such as the grid of nine keys surrounding the right middle finger turning into a numpad. His layers also include some really thoughtful and unique solutions that I’ve been gradually trying out on my own keyboard since the interview. One of these I thought was brilliant was taking all of the symbols produced by holding Shift + [number row key], e.g. !@#$, and putting these across the home row keys on a layer. In this mapping, A = !, S = @, and so on. This is a pretty cool mapping for a few reasons; these combos are a bit stretchy (I have a dedicated number row on my keyboard), you use them A LOT in programming, and, for me at least, I have a sense of where they are spatially, but I’d have a hard time telling you that & is Shift + 7, I just know what finger presses the number. Rock’s mapping preseves the spatial memory and eliminates a bad stretch, huge fan. It’s worth perusing the full layout for inspiration. I drank some of the Kool-Aid and am thinking about building my own Kyria as a result of our conversation.

I’m always curious about how someone travels with their keyboard. I have a smaller version of my daily driver that I take with me to coffeeshops and on business trips. The Kyria, being quite small already, travels well. Rock used a case from Amazon with a pick-and-pluck-foam interior to create a custom travel case for his keyboard and mouse. To further optimize keyboard use in cramped areas, he uses the Karabiner Elements app to completely disable his laptop’s keyboard when the Kyria is connected so that he can put his keyboard directly on top of his laptop keys without them registering errant keypresses. Very cool hack.

The Software

I was very keen to get Rock’s input on Helix Editor since I know he is a regular user and I am Helix-curious or even Helix-questioning if I could be so bold. I was initially surprised to hear that he liked using Helix. He walked me through the main propagandist talking points that are anathema to my Vim sensibilities such as easy configuration (he’s right) and better defaults (also correct). What was interesting and unexpected though was his endorsement of the selection -> action model employed by Helix. Every other part of Rock’s workflow seemed to suggest that he knows precisely what he thinks first and then interacts with his tools as a formality to express his ideas so I was surprised that he would opt for an editor workflow that selects first and then acts on the selection afterwards. Maybe it’s not so crazy given that this is how virtually every other text editing application works from Microsoft Word to VSCode.

The Helix configuration is spectacular. There’s really not much to detail there. You’re responsible for installing your own LSPs, formatters, etc. which dodges any half-baked contrivances such as Mason in Neovim. Configuration just works and if it doesn’t you may be required to point to the location of your LSP/formatter/??? that you’re trying to integrate.

For a terminal multiplexer Rock uses Zellij. The dumb question I asked in response to learning this was “Why not tmux?” It’s a dumb question because every developer reading this immediately had at least a couple hundred answers to this question pop into their head even if they’ve never heard of Zellij. Rock’s setup builds on top of Zellij to add a few neat features. One that stuck out to me was a temporary terminal. The workflow is like this - you pop open a new Zellij session and start editing some code in Helix for your server application. Things are looking good so you decide to fire it up and see if it runs. In Rock’s setup you’d press Alt + w to get a floating terminal window on top of your code. Start the server, looks good. Alt + w again hides the pane but allows the process to continue. I can see a lot of value in this workflow especially for long-running processes that you only want to visually see output for occasionally.

After our chat I installed Zellij. It’s superior in every way that I can tell to tmux. Old habits die hard though and it will take me a good amount of time to learn the standard keybindings or develop my own.

OS and Closing Notes

Rock develops on his Macbook Pro but primarily uses it to SSH into various other machines. Those other machines typically use NixOS. His system configuration can be viewed here. I greatly admire those that daily drive NixOS. They’re generally the engineers that are willing to make a massive initial time investment for an infinite return on that investment. Once you get your configuration.nix to a good state, simply install NixOS, bring in your configuration and run sudo nixos-rebuild switch, after install you are now operating in a system environment that is configured identically to any other systems with the same config file.

In order to set up a useful configuration.nix you need to have a very clear idea of which base-level tools you need and how they should be arranged. NixOS is an environment that penalizes frivolity and indecisiveness. It is a technology that force multiplies craftsmen and breaks casuals. It’s clear that Rock is the former; he is a craftsman. He didn’t wake up one morning and have a clear vision of how engineering should be done, he developed it through being in the process authentically, having the humility to admit that previously made decisions aren’t always the best ones, and listening to his body when it indicated a tool wasn’t well adapted to him. Through these experiences Rock earned his keyboard, mouse, editor, and configuration.nix.

You can see some of Rock’s code on GitHub and get in touch with him on LinkedIn