On Working Fast

Many discussions regarding software tooling had me facing the argument that while my suggestions might decrease the duration required for the task at hand to some degree, the magnitude or quantity of the savings were not sufficiently significant, that they would not amortize. Despite acknowledging a taste of truth to that, I typically felt that there was an aspect to the topic escaping the debate.

The relevance of speed in workflows always carried conviction to me. After some reflection I believe my intuition’s root cause is twofold. On the one hand I believe that the former argument is built on a flawed assumption. On the other hand it’s just great fun to feel fast.

More concretely, said argument goes as follows: ‘The conventional approach for atomic task X would take duration D. Your suggestion would take (1 - epsilon) D. The savings of epsilon D are too insignificant, given N executions of X, which disfavors the investment into the adoption of your suggestion.’

Informally I believe that the flaw of this train of thought lies in not considering quality of time and its downstream effects. More formally, it relies on the assumption that the (expected) output generated at time interval T is invariant of the speed of workflow from previous time intervals.

While it is not exactly shocking to make assumptions that can be proven to be unsound in conventional decision-making, this assumption seems particularly flawed to me. On the contrary, I would argue for the output from time interval T being heavily dependent on and sensitive to the workflow of previous time intervals. I would think of this as a self-reinforcing feedback loop, a spiral or a multiplicative (in lieu of an additive) effect.

A slightly faster pace sets the tone; gives gratification as it feels fast and challenging. This is stimulating. A slightly lower pace always introduces small gaps of idleness, whereas the mind often has a hard time to actually be idle. This invites distraction, it deviates focus and hence lulls the programmer. Worse, it could even just establish the precedent of getting used to not performing at one’s best, which seems both sad on a personal level and wasteful on a professional level. Moreover such a slowdown can easily cause frustration, lead to a lack of drive, lower patience and less tolerance for work overall.

Actual output aside, it’s just intrinsically fun to be fast while working, as with so many other things.

Some things that often make me feel slow, without order, mutual exclusivity or exhaustion:

• Mice and arrow keys
• GUIs
• IDEs
• Non-tiling window managers
• Web apps

Some things that often make me feel fast without order, mutual exclusivity or exhaustion:

• Most keys of a keyboard
• Quite a few CLIs
• Emacs
• Tiling window managers
• Org mode :)
• Reading documentation