Author: admin


Interface Bandwidth Utilization

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.


Intelligence as a Handicap

Programmers live in a bizarre world where laziness is rewarded and intelligence is a handicap. Let me explain.

Most of us have accepted that the best programmers are lazy. They will complain whenever they encounter non-automated repetition or searching (you know, the stuff computers were built for). Instead, we can work smarter by automating tasks that pass a magical threshold where the time to automate it is less than the doing it manually X times. Old news.

There’s a complexity threshold that each of us can work within efficiently. Sometimes, we push ourselves and work a little over it, but we are only fooling ourselves thinking that it’s sustainable. When teams are working at different levels, collaboration can be very frustrating (too obvious or too confusing).

If the workplace is busy, or we are personally strained, we are not able to work at that same level. If we push ourselves by always working at our maximum, we are hindered when we’re not at our best.

I’ve been able to appreciate this recently. While working on some old legacy projects, rebuilding the mental model is much more complex with fresh eyes. Add any deadline stress or personal fatigue to the mix, and I can only touch it after hours with absolute focus. That is not sustainable, nor desirable. The result is hopelessly trying to make sense of things: shooting in the dark until things “click” – if they ever do. This may last a few minutes, hours, or even months on a large project. It’s absolutely demoralizing.

This is why TDD works. The amount we need to load into memory is always so small, our personal constraints will never be the bottleneck. It leaves clear next steps, and code the entire team can understand, and even better: write.

Break things down so they are stupidly obvious, and progress becomes fluid and predictable. If you don’t, you are relying on a hero to save the day. That’s a lot of weight to carry.


Build Your Own Tools

There’s a certain draw to finding the perfect tools that magically match your list of requirements and save you lots of time and money. If you’re lucky, you may find some that fit, and it’ll be wonderful. Until they don’t.

One of the best parts of being a programmer is the ability to build your own tools. You don’t necessarily have to build your own raw tools, but you should be able to wire them together. Spending a little extra time understanding the tools you use everyday can have major pay-offs.

The more I develop on a unix-based system, the more I appreciate this philosophy. Leveraging a wide array of simple tools, and orchestrating your own solutions will allow you to naturally evolve your workflow as your requirements change.

The alternative is being enslaved to SaaS systems which lease tools to toolmakers purely because they solve your problems for you and hide the complexity. As a developer, it’s our job to embrace and ultimately overcome those complexities.

I see it almost every day…

  • How can I automate deployment with
  • How can I integrate my VCS with MegaEditorIDE?
  • How can I get CI for my language?
  • How can I run tests when the filesystem changes?

All of these features add a ton of complexity to the solutions they integrate with, and the kicker is, none of them are necessary.

  • Your host has SSH access. That’s all you need.
  • Learn Git from the command line. Any GUI will get you 80% there and then suffocate you.
  • CI just needs to run a script. Whether it’s node, java or PHP is irrelevant.
  • Your operating system has mechanisms that can tell you when files change. Use that (and leverage it in your toolset).

Master your raw building materials. They’ll help you far more than the pre-packaged solutions that you are being sold.