The most challenging class I ever took was an English course taught by Professor Lionel Basney. I entered that class thinking I was a decent essayist; I exited with a handful of Cs, average at best. I also exited a much more thoughtful writer.
Aside from being tough, Professor Basney was also an infamous Luddite—that is, someone who intentionally eschewed technology.
I have vivid memories of him clacking away on the typewriter in his office. Basney was friends with another well-known Luddite author, Wendell Berry. Both shared a philosophy that, through Basney’s class, I came to appreciate.
From Berry’s 1988 essay for Harper’s Magazine, “Why I Am Not Going to Buy a Computer," this list excerpt summarizes his approach to evaluating technology:
- The new tool should be cheaper than the one it replaces.
- It should be at least as small in scale as the one it replaces.
- It should do work that is clearly and demonstrably better than the one it replaces.
- It should use less energy than the one it replaces.
- If possible, it should use some form of solar energy, such as that of the body.
- It should be repairable by a person of ordinary intelligence, provided that he or she has the necessary tools.
- It should be purchasable and repairable as near to home as possible.
- It should come from a small, privately-owned shop or store that will take it back for maintenance and repair.
- It should not replace or disrupt anything good that already exists, and this includes family and community relationships.
In the tech industry, our work is often characterized as “faster, more automated.” At first glance, this approach seems at odds with the standards above, which I’d characterize as “slower, more thoughtful.” What lessons, if any, might we learn from those who see the world through such a radically different lens?
A pattern for automating a process
Over my career, I’ve developed a pattern for automating a process:
- Do the process. Manually. Many times. Over and over and over and over again. The repetition lets the process sink deep into my bones; I become intimate with all the nooks and corners. I learn where small changes can produce big productivity gains. I also learn, through hard experience, where the pain points are.
- Document the process, for myself. Coding is just writing, so committing steps to the written word is the first step towards an algorithm. Since I am my audience, I don’t (yet) have to worry about my biases or the shortcuts I take without even realizing. The point is to solidify the process into a concrete series of repeatable steps. I can test the documentation by following it without thought, almost as a computer would.
- Document the process, for others. Now we shine the light on my biases, looking for skipped steps and assumptions. Once others can repeat the process with regularity, we’re finally ready for the last step…
- Set the process to code. By this point I have a battle-tested set of steps written up that easily translates to code.
This pattern often produces something that adheres to Berry’s standards: cheaper, smaller, more energy-efficient, and clearly better than what it replaces.
When the urge to automate strikes, take a moment to slow down. Stroll through each step slowly, observing how all the pieces fit. Note where complexity lurks. Revel in the mindless repetition that springs from thoughtfully-considered documentation.
When the time comes, leverage all those lessons learned into tightly-crafted code.
Finally, watch hours dissolve into seconds of work and take a final moment to fully appreciate the beauty of drudgery.
