Why I am excited about Light Table
I remember the first time I sat next to a real programmer and watched him work. This dude (with whom I was doing my first programming class assignment) was typing C code in Emacs at typewriter speed. I don't remember him ever looking down at the keyboard. He was in a state of total immersion, fingers flying all over the keyboard. He was the archetypal programming whiz-kid: self-taught, coding since he was 14, and a blend of hubris and limitless curiosity.
He impressed the shit out of me.
He taught me my first programming lesson: that programming is closely linked to navigating files and applying selective attention. Focusing on a spot inside the file, then another, then zooming out to evaluate the changes in a broader context. Thinking on the go, running the code often, and merciless editing. Edit, run, think, edit.
This “ready, fire, aim” style of work came as a minor shock to me, as I had imagined programming as being this slow-paced, methodical activity in which one gets to write out code line by line in a linear, deliberate fashion.
It became clear that to be effective in this line of work, I must be able to type at the speed of thought. And to that end, had to make the tool — the editor — an extension of my fingers and brain.
Over the years that followed I've been trying out different editors and programming environments; this has led me to distill my expectations to an editor in a few key points.
First though, let's set the stage:
You don't need a menu bar. It's just a crutch placed there for disoriented newbies. You also don't need a toolbar with big happy icons, nor do you need a scrollbar. All of these things are for losers, and they are just taking up precious screen real-estate.
The 3 principles an editor must implement
When evaluating an editor for the first time, I look for three things. If the editor doesn't comply with the first two out of the box, it is discarded immediately. If three doesn't come out of the box, I look for ways to enable it. The list:
- Consistency with the host OS
- No coupling between files and projects
- Launchable from the command line.
Let's look at eachone in turn.
Principle 1: Consistency with the host OS.
An editor needs to behave consistently with the defaults and conventions employed by the host OS (and shared by the majority of other applications). This means that the most common keyboard shortcuts must also work in the editor.
Here are the shortcuts I test for:
Dragging a file from a location on disk (say, Desktop) onto the editor's application icon (which for me sits on the Dock on my Mac). Does the editor just pop up with the file open?
Dragging a file from a location on disk (say, Desktop) into the open editor window. The editor may or may not have other files open. Does the dragged file just open in a new window?
Using the default OS text and file navigation keyboard shortcuts with the editor. The main ones I test for are:
A. Jump at the end / start of line:
CMD + right / left arrow;B. Jump at the end / start of word:
ALT + right / left arrow;C. Jump at the end / start of file:
CMD + up / down arrow.
Another one I test for is CTRL+Tab for switching between tabs.
These keyboard shortcuts represent 20% of the actions that cover 80% of text editing. If the editor responds to these commands, it usually means that I can get my job done fairly seamlessly.
The point is that I can trust my editor to predictably respond to the same keyboard commands that I use across all other workflows on that machine. When I hit CTRL+Tab, from either a browser window, the Terminal, or editor, all these applications respond in a uniform way: I switch between tabs. This enables me to navigate a wide array of open applications using the exact same keystrokes — a clear productivity win.
I don't like to have to go through special training in order to be able to use an editor. The process of editing text is uniform enough across domains to have a standard set of operations. Convention over configuration makes all the sense here. Hence, I don't use Vim with its different “modes” and I don't use Emacs because I don't like the verbosity of CTRL+X CTRL+S when all I need to save a file is just CMD+S.
A little aside: can you imagine talking to someone using “communication modes”?
— Hey Bob, enter polite ask mode. Pass me the salt please.
— Hey Alice, enter bit of useful information mode. I'll be out of the office until 12.
Did that sound silly? So does the notion of using a specialized language to communicate with a text editor. A small core of universal keystrokes (and a high degree of configurability to accommodate special demands) should be enough.
Principle 2: No coupling between files and projects.
This one is huge. IDEs like IntelliJ IDEA, Netbeans, and others don't allow me to work on files, requiring instead that I create a project first. They are negating one of the most common workflows in programming: editing a single, standalone file of code.
Projects often start life as small scripts (grown iteratively in a console), or as compact, prototype programs. Over time, these prototypes expand in size and scope, until at some point we feel compelled to introduce config files, scripts for system-level tasks, and a formal file structure characteristic of a project.
Files can and do exist outside of projects; not the other way around.
An IDE that is unable of functioning as a plain file editor is negating the way programmers work — and is a shit job in my world.
Principle 3: Launchable from the command line.
The editor must fit into a command-line driven workflow. No need to “point and click” — just launch it with a file or directory argument (like subl . or subl filename) for Sublime Text.
Some Interaction Design
In her book Designing Interfaces, Jenifer Tidwell describes 14 “universal user behaviors” — patterns in which users interact with interfaces in the widest sense (devices, apps, etc). So these patterns are about users themselves, rather than interfaces. Analyzing developer tools (such as editors) through the lens of these common behaviors is an interesting exercise.
I found the following six patterns are particularly relevant to the topic at hand.
Instant Gratification. I want to achieve something meaningful when interacting with the tool, as early as possible.
Satisficing. I don't want to put a huge up-front effort into learning or customizing my environment, tool, or process. I'm willing to trade off advanced superpowers (which take time and effort to acquire) for basic fluency, at least in the beginning.
Deferred choices. Don't force me to make all the decisions up-front. Enable me to start with a minimal functioning setup; allow me to come back and customize my settings later.
Incremental construction. Building software is complex, involves many steps, and calls for a non-linear workflow. Hence, I want to be able to progress in small steps, while getting immediate feedback with each one.
Keyboard Only. Self-explanatory, especially of you're a programer.
Habituation. An interactive environment (such as a computer) provides the user with a core set of conventions (visual identifiers, commands, shortcuts, workflows, etc) that enables the user to use the environment (these are also called "affordances"). Once we have habituated that environment to a level of basic proficiency, we expect our newly acquired skills to “work” across all of its hosted applications — to transfer across workflows.
Each of the criteria for evaluating editors I outlined above (consistency with the host OS; no coupling between files and projects; launchable from the command line) maps to these intraction design patterns through some particular aspect of a programmer's workflow.
In conclusion
When developing in Ruby and friends, I use Sublime Text — because right now and for that coding environment, it ticks all the boxes.
The future, as I see it, belongs to editors that are as interactive and immersive as they are fast, minimalist, and responsive. Code environments that:
- learn about the code I'm writing in real time
- provide me with immediate feedback
- bring to the forefront the things that matter, helping me focus.
To develop such tools, we need to shift our focus from editor features to developer productivity — a fascinating topic that merits its own treatment. For now, I'll just say that I'm enormously excited by the promise of Light Table.
Edited September 2022.