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, never even looking down at the keyboard. He was the archetypal programming whiz-kid: self-taught, coding since he was 14, and a blend of cockiness and endless curiosity.

He impressed the shit out of me.

He taught me my first programming lesson: that programming is closely linked to navigating a file and 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, methodical activity in which one gets to write out code line by line in a linear, deliberate fashion.

That exposure also made it clear that to be effective in this line of work, I'd need to be able to type and edit at the speed of thought. And to that end, I'd need 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; eventually, this has led me to crystallize my expectations to an editor in a few key points.

But first, let's set the stage in a proper way:

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 embody

When evaluating an editor for the first time, I look for 3 things. If the editor doesn't comply with 1 and 2, it is immediately discarded. If 3 doesn't come out of the box, I look for ways to enable it. The list:

  1. Consistency with the host OS
  2. No coupling between files and projects
  3. Launchable from the command line.

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:

  1. 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?

  2. 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?

  3. Using the default OS text and file navigation keyboard shortcuts with the editor. The main ones I test for are:

    1. Jump at the end / start of line: CMD + right / left arrow;

    2. Jump at the end / start of word: ALT + right / left arrow;

    3. 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.

The point is that I can trust my editor to predictably respond to the same keyboard commands that I use to navigate all other applications. When I hit CTRL+Tab, from either a browser window, the Terminal, or editor, the applications respond in a unified way and I switch between tabs. This saves me mental clock cycles, enabling me to navigate a wide array of open applications using the exact same keystrokes. A clear productivity win.

I don't like 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 really is CMD+S.

A little aside: can you imagine talking to someone using “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 special language to communicate with a text editor. A small core of universal keystrokes (plus endless configurability) 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 files that are just... files.

As for projects, often they too start life as small-scale scripts (often grown iteratively in some sort of an interactive console), or as compact, prototype programs. Over time, these prototypes expand in size, complexity, and scope, until at some point a more formal project organization starts to make sense.

The programmer may then decide to organize these loose collections of files into a project with a definite directory structure (that may or may not follow a certain convention), supporting files (system scripts, configuration files etc), and all the other infrastructure and plumbing typical of projects.

Files can and do exist without projects; not the other way around.

An IDE that is unable of functioning as a plain editor is doing a very poor 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” — ways in which we interact with interfaces across the widest spectrum (devices, apps, etc). These patterns are therefore used to describe users, not interfaces. It's an interesting exercise to analyze developer tools (such as a code editor) through the prism of these behavioral patterns.

The following six patterns are particularly relevant to the topic at hand:

Instant Gratification. I want to achieve something meaningful as early as possible in my interaction with the tool.

Satisficing. I don't want to put a huge up-front effort into learning or customizing my environment, tool, or process. I'm usually 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. Do allow me to start with a minimal setup and come back to tweak or expand my settings as my work progresses.

Incremental construction. Although writing and running software involves many steps, I want to be able to work at it in small chunks that provide me with immediate feedback, using a non-linear workflow. Because that's the way I work.

Keyboard Only. Self-explanatory, especially of you're a programer.

Habituation. An interactive environment (a computer) will have a core set of usage conventions (shortcuts, commands, workflows, visual identifiers, etc) for users to navigate it. Once we achieve a level of proficiency within that environment, we expect our habits to “work” across its hosted components and applications, especially if they are comparable in nature (text editors come to mind).

Each of the principles for judging editors I described above (consistency with the host OS; no coupling between files and projects; launchable from the command line) maps to these universal user behaviors through some particular aspect of a programmer's workflow.

In conclusion

When developing in Ruby & 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 as I'm writing it; provide me with immediate feedback; and gently 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 belongs in its own article. For now, let's just say that I'm enormously excited by the promise of Light Table.