Also known as “develop and use your muscle memory to the fullest”.
Assuming you know how to drive a car, imagine that your car was one fine day stripped of its pedals, steering wheels, levers, and buttons, and you now had to drive the car by using a mouse and clicking various buttons and moving around sliders on a screen. This should sound like a nightmare scenario. You need to aim your mouse, so the screen sucks in your attention, leaving you unable to watch the road. By the time you move the mouse to the “horn” button and press it, you’ve already collided with the unfortunate jaywalker. Reacting to yellow lights in intersections is impossible. Parking is a nightmare.
Nobody in their right mind would accept driving the car with a screen and mouse. The problem is twofold. First, there’s the problem at attention — you need to look at the screen in order to know what you’re pressing, so you can’t pay attention to the road. Second, there’s the problem of bandwidth — the number of commands you can execute in a fixed span of time. It’s unacceptably low for a screen-and-mouse interface.
What makes regular car user interfaces so successful in their domain is their reliance on a great strength of humans — muscle memory. After the initial learning curve, drivers neither think how to drive nor use their eyes on the user interface in the car. The muscles remember how much to turn the steering wheel to get the car to go in the desired direction, where the air conditioner button is, how to turn on your blinkers, and how hard to press the brake pedal in order to stop at the yellow light (or how hard to press the gas to make it through before it’s red). The conscious part of the brain is hardly involved, and the eyes are focused on the road.
If you watch professional designers, artists, or architects at work, you’ll notice that they barely use the user interface of Illustrator, Photoshop, SketchUp. It is simply impractical to get much good quality work done unless you commit all the keyboard shortcuts to memory. The number of commands that need to be executed is simply too large to be point-and-clicking. A symptom of this is that if you watch over the shoulder of one of these professionals at work, you’ll have no idea what’s happening — they never select tools from the tool palette.
This is one reason why dynamic, context-based keyboards are not much of a thing in the professional world. Because they adjust to context, and also because they most often offer no tactile feedback, they break muscle memory. You can’t use them effectively by feel[1].
Like drivers and designers and digital artists, programmers must also aim for high bandwidth interaction between them and the text editor. It’s vitally important for productivity to design your workflow for momentum, and it’s a shame when typing is what’s slowing you down. So set aside some patience, set your mouse far enough that you need to stretch to use it, and invest in your typing skills. As with many things in this book, it’ll require you to slow down in order to speed up. It’s an upfront investment, which will pay huge dividends.
The skills that you’ll need to commit to muscle memory fall into three categories. First, you need to get to a file you want to edit — “cross-file navigation”. Then, within that file, you need to get to the place you want to edit — “local navigation”. And finally, the actual “editing”.
Cross-File Navigation
The key observation regarding cross-file navigation is the following:
In most cases, you already know what file you want to edit, you just need to get there.
So now you have a few choices:
- look at the file system tree, find the file there, and click on it
- scan your open tabs, and click on the file if it’s already open
- use the “open anything” dialog that most editors and IDEs have
When you know the file you want to edit, it is by far faster to hit the keyboard shortcut for “open anything”, and type a few characters to get the current fuzzy match on the filename you want to open. It takes getting used to, but really speeds you up in the long term. I would recommend completely hiding both the file tree view, and the tabs, and use the “open anything” dialog exclusively for manual cross-file navigation.
There’s one domain-specific example of cross-file navigation that’s worth mentioning. If you have abstractions that consist of the same multiple files, like React components consisting of a .ts file for the logic, .scss file for the styles, and .render file for the render function template, it can be hugely time-and-brain-cycle-saving to configure (or build) a “cycle through files” sort of plugin, that will cycle through the three file types in a deterministic order.
One more tool for cross-file navigation is “go to definition”. Learn the keyboard shortcut for it, as well as one for “navigate back”, and code exploration will become effortless and mouse-less.
Local Navigation
Now that we can get to the file we want to edit, how do we get around within the file? You’ll want to learn, practice, and commit to muscle memory the shortcuts for the following operations:
- go to line by number
- go the beginning/end of current line
- jump left/right by word
- next/previous instance of an arbitrary sequence of characters (lightweight search)
Additionally, learning the following commands make for a much more pleasant editing experience:
- bring current line into the middle of the viewport
- bring current line to the top of the viewport
This stuff is so basic, you should never need to think about how to get to a point on screen where you’re looking. This will take a bit of effort to develop, but will really pay off.
Editing
Now that we know how to move around a file, it’s time to actually make edits. First, some basics that you need to commit to muscle memory:
- delete current line
- delete from cursor until end of line
- duplicate current line
- make a new line above current and move the cursor there
- make a new line below current and move the cursor there
Next, you need to develop selection skills. In most cases they are the same as navigation, but performed while holding shift.
And finally, time for superpowers. Learn multi-cursor (aka multiline) editing. It is difficult to understate how much of a productivity boost it gives you. Code invariably has a lot of structure to it, and multiline editing allows you to capitalize on that structure by parallelizing similar edits. Specifically, these are the commands you’ll need to commit to muscle memory:
- add a cursor on the line below
- add a cursor on the line above
- reset back to one cursor
- add a cursor at the next instance of selection
Then you’ll need to get a good feel for how navigation around the text works in the context of multiple cursors.
I can’t overstate the importance of being competent at editing code. It’s really painful to watch people take minutes to make the simplest edits, or simply give up on cleanup and refactoring tasks because the perceived edit cost is too high. The effects on overall quality of work are surprising.
And if nothing else, developing new basic muscle memory skills feels good (after feeling bad), in the same healthy way you feel after going for a gym for the first few times in ages.
[1] That, and given how crappy software generally is, they are also unreliable. When Apple removed the hardware Escape key and replaced it with that crappy dynamic bar with no tactile feedback, I knew that one fine day the Escape button will not be there or will not work when I need it. And even though I never owned one of these MacBook Pros, I used one for infrequently testing my code on Windows at work, and sure enough, one fine day the Escape key indeed did not work when I very much needed it. After a number of years, Apple has finally returned the hardware Escape key. Moral of the story is that you don’t just mess with something as fundamental as muscle memory used for basic operation of the main work tool.
Comments
Post a Comment