How efficient are you at utilizing your interface’s communication bandwidth? As programmers, we communicate our intentions through our keyboard/mouse and into a text editor. Similar to writers, we primarily use the keyboard, and have 10 fingers to rapidly convert our thoughts to text. Traditional writing is typically very linear: write what’s on your mind, and go back and edit it afterward.
Programming is non-linear: it branches, and it’s highly iterative. We rapidly jump lines, files, tests, go in and out of a call stack, and are often looking at several things at once. This is very demanding physically. As soon as we reach for the mouse, we’ve introduced lag between what we want, and what we’re doing. We use a mouse because it can get us from A to B very quickly, allowing a far higher resolution (accuracy), while also capturing things like speed and acceleration. That is invaluable when drawing, or when playing video games, but not when editing text. Those few extra dots per inch do not matter, as text is probably 10pt large anyway.
With a modern mouse and a full keyboard, there is an enormous amount of input bandwidth. Professional gamers work several hours per day to try and maximize (and sustain) their utilization. Typically, they anchor their left hand on the left side of the keyboard, dedicated for movement and hotkeys; and the right hand planted on the mouse for perspective and precision. It can be very efficient, and we see some of them hitting up to hundreds of actions per minute. They have mastered their interface for insanely high speed and accuracy. As programmers, we should strive to reach a similiar level of mastery, but are we even set up correctly?
In the efforts of minimizing the cost of switching to the mouse, many have switched to using a trackpad on their laptop (or rather, not using an external keyboard). While this helps, it sacrifices most of the benefits of even using the mouse: the high bandwidth input. If you are still using an external mouse, here’s an experiment: move your mouse another 12-18 inches further away, and you’ll start to notice how awkward that transition is.
Okay, so that’s input, how about output? Are we actually making good use of the rich GUI that our IDE provides? The typical setup is either a full screen of code (text), perhaps with splits, or one primary pane and one or two small sidebars for a file tree or code outline. Arguably, we’d collapse them when we don’t want them, but that’s just too much work. But, basically, we’re still just looking at columns of text.
What is the alternative? A crappy terminal, and a text editor that is 30+ years old (or at least a modern updated version of it). Really.
By working in a program designed for low interface bandwidth, you can utilize a lot more of it without taking your hands off the home row. I like to compare this with first learning to type: when you are pecking, it’s very hard to be consistently fast. You may be able to peck certain combinations rapidly, but it’s not sustainable and it’s not very efficient overall. By learning to use the entire keyboard properly, you can move up to a consistent 80wpm+ if you work at it.
When I use a graphical text editor, I can really feel this difference. I’m typing really fast, things are going great, and then I’m stopped in my tracks when I have to go back and change something. It’s not natural, but we are used to it because we’ve been trained to type that way. It’s very disruptive to achieving flow (if you believe in that sort of thing). Worse, it can deter us from wanting to make changes because we’re either in the middle of something, or because making proper changes is physically awkward.
In an editor like vim, you can use movements that are more natural and contextual (jump to next function, delete argument, change line, etc.) rather having to manually do it as raw text. And you can make these change as you go just as fluidly as if you never stopped typing. It feels very natural. You can also repeat, combine or even script these actions together, and ultimately create your own crafted editor. Mouse movement is replaced with keyboard movement, which is much more predictable and reliable. Getting up to the same level of efficiency may take a few days or a few weeks, but you’ll get there, and you’ll be glad you did.
The output bandwidth hasn’t been so different either. At an average font size of, say, 10pt, you can fit nearly the same amount of information on the screen. You can differentiate syntax or interface elements with 256 colors and a variety of symbols to create boundaries, draw tables, or highlight information. You lose a little bit of space on the drawing side, but that loss is easily gained back many times over with the highly dynamic nature of it.
However, the even cooler thing is you can put whatever you want on the screen. You’re not limited by your editor’s plugins; you can create or use any scripts wherever you want, and the barrier to entry is much lower for creating your own. You can jump to different workspaces or views, just as you can in something like Eclipse, but dropping the enormous CPU and memory footprint. You can configure and save these, essentially creating a responsive IDE that you can bend to your will with just the keyboard. You can manage all of those splits, information panes, or windows on the fly, instead of having them always wasting screen real-estate.
Now, because that interface bandwidth is so low, we can easily pipe it through the network. You can perform your work over SSH on a low powered device over the air. If you are working on the go, this will greatly increase your battery life, or at the very least free up resources for your device for more important things. You can also set up pair programming or screen sharing without any special tools (just SSH), which means it is much faster than RDP or VNC. You can also package and version your unique setup, and use it on any machine. This way, it’s an investment that you can keep refining.
I understand that working from a terminal is not for everyone, but I think everyone should give it one serious try. It’s healthier for your wrists, and at least for me, has been much more efficient and more condusive to maintaining flow when programming. It has also given me a much deeper appreciation and understanding for how linux works. That alone has made it worth it.
