The Case for Slow Programming

My dad used to say, “Slow down, son. You’ll get the job done faster.”

I’ve worked in many high-tech startup companies in the San Francisco Bay area. I am now 52, and I program slowly and thoughtfully. I’m kind of like a designer who writes code; this may become apparent as you read on :)

Programming slowly was a problem for me when I recently worked on a project with some young coders who believe in making really fast, small iterative changes to the code. At the job, we were encouraged to work in the same codebase, as if it were a big cauldron of soup, and if we all just kept stirring it continuously and vigorously, a fully-formed thing of wonder would emerge.

It didn’t.

Many of these coders believed in the fallacy that all engineers are fungible, and that no one should be responsible for any particular aspect of the code; any coder should be able to change any part of the code at any time. After all, we have awesome services like github to manage and merge any number of asynchronous contributions from any number of coders. As long as everyone makes frequent commits, and doesn’t break anything, everything will come out just fine. 


You can’t wish away Design Process. It has been in existence since the dawn of civilization. And the latest clever development tools, no matter how clever, cannot replace the best practices and real-life collaboration that built cathedrals, railroads, and feature-length films.

Nor can any amount of programming ever result in a tool that reduces the time of software development to the speed at which a team of code monkeys can type.


The casualty of my being a slow programmer among fast programmers was a form of dysrhythmia – whereby my coding rhythm got aliased out of existence by the pummeling of other coders’ machine gun iterations. My programming style is defined by organic arcs of different sizes and timescales, Each arc starts with exploration, trial and error, hacks, and temporary variables. Basically, a good deal of scaffolding. A picture begins to take shape. Later on, I come back and dot my i’s and cross my t’s. The end of each arc is something like implementation-ready code. (“Cleaning my studio” is a necessary part of finishing the cycle). The development arc of my code contribution is synonymous with the emergence of a strategy, a design scheme, an architecture.

And sometimes, after a mature organism has emerged, I go back and start over, because I think I have a better idea of how to do it. Sometimes I’m wrong. Sometimes I’m right. There is no way to really know until the organism is fully formed and staring me in the face.

Anyway, back to the cauldron-soup-programmers. The problem is this: with no stasis in the overall software ecosystem – no pools of stillness within which to gain traction and apply design process, how can anyone, even a fast coder, do good design?


Any coder who claims that fast programming is the same as slow programming (except that it’s fast), doesn’t understand Design Process. For the same reason that many neuroscientists now believe that the fluid-like flow of neuronal firing throughout the brain has a temporal reverberation which has everything to do with thought and consciousness, good design takes time.

The Slow Programming Movement

According to Wikipedia: “The slow programming movement is part of the slow movement. It is a software development philosophy that emphasises careful design, quality code, software testing and thinking. It strives to avoid kludges, buggy code, and overly quick release cycles.

Wikipedia also says this about “Slow Software Development”: “As part of the agile software development movement, groups of software developers around the world look for more predictive projects, and aiming at a more sustainable career and work-life balance. They propose some practices such as pair programmingcode reviews, and code refactorings that result in more reliable and robust software applications.”

Venture-backed software development here in the San Francisco Bay area is on a fever-pitch fast-track. Money dynamics puts unnatural demands on a process that would be best left to the natural circadian rhythms of design evolution. Fast is not always better. In fact, slower sometimes actually means faster – when all is said and done. The subject of how digital technology is usurping our natural temporal rhythm is addressed in Rushkoff’s Present Shock.

There’s another problem: the almost religious obsession with technology – and a fetish-like love for tools. People wonder why software sucks (and yes, it sucks). Software sucks because of navel-gazing. Fast programmers build hacky tools to get around the hacky tools that they built to get around the hacky tools that they built to help them code.

This is why I believe that we need older people, women, and educators INSIDE the software development cycle. More people-people, fewer thing-people. And I don’t mean on the outside, sitting at help desks or doing UI flower arranging. I mean on the INSIDE – making sure that software resonates with humanity at large.

I’m Glad I’m not a Touch-Typist.

A friend of mine who is a mature, female software engineer made an interesting quip: “software programming is not typing”. Everyone knows this, but it doesn’t hurt to remind ourselves every so often. Brendan Enrick discusses this. The fact that we programmers spend our time jabbing our fingers at keyboards makes it appear that this physical activity is synonymous with programming. But programming is actually the act of bringing thought, design, language, logic, and mental construction into a form that can be stored in computer memory.

My wife often comes out into the yard and asks me: “are you coding?” Often my answer is “yes”. Usually I am cutting twigs with a garden clipper, or moving compost around.

Plants, dirt, and clippers have just as much to do with programming as keyboards and glowing screens.

We are transitioning from an industrial age and an economic era defined by growth to an age of sustainability. Yes, new software and new businesses need to grow. But to be sustainable, they need to grow slowly and with loving care. Like good wine. Like a baby.

GIT: a Nightmare of Mixed Metaphors

Are you a regular user of the popular software version control system, git? If so, do you love it? If you do, then you are a perfect example of the miracle of neuroplasticity. Your brain – through an initially painful process – has grown new connections and adapted to a set of habits and associations that are twistedly unnatural in the scope of all tools created by homo sapiens.


Consider the following clash of metaphors:

“pulling from upstream”, “fetch”, “cherry pick”, “filter branch”, “untracked”, “symlink”, “rebase”, “tag”, “HEAD”, “working copy”, “head”, “path”, “stash”, “clone”, “submodule”, “fast-forward”, “merge”, “origin/master”, “staging area”.

Unless you are a surrealist poet, you will have a hard time generating anything of value with these terms. Alas…software developers are generally not interested in spinning narratives or crafting metaphorical microworlds. Of course, many programmers are interested in designing intuitive, self-consistent language in their tools. This would be awesome if they didn’t suck at it so very badly. In the case of git, it’s original creator, Linus Torvalds, appears to have demonstrated the classic negligence of an anti-design geek who has no time for wordsmithing.

Here’s the problem: if you are designing command-line tools, then wordsmithing is all you’ve got. It’s all just language.


I must admit: when someone sits down and explains how git works, and why it’s such a great concept, I see the light. These explanations are often accompanied by tree diagrams and arrows. This is encouraging.

And then I sit down and start using it. And the nightmare begins. All over again. Because the obscure language and cryptic behavior of git is impossible to remember, unless you use it every day. And who uses it every day? Git-lovers, of course. Their brains are soaking in the Koolaid from yesterday’s day on the job. There’s no mystery here.

Am I alone in my hate for git? Witness:

Here’s Mike Taylor on how opaque git can be, and why it is so confusing, especially to people who have not finished tying their brains into knots (i.e., they are still normal).

Here’s Steve Bennett, who says this about git: “What a pity that it’s so hard to learn, has such an unpleasant command line interface, and treats its users with such utter contempt.”

Here are some git-haters on Amplicate

Scott James Remnant sez: “I’ve had a few ex-boyfriends hang up on me before, and they were gits too.”

As I have always thought about version control systems in general: what is so very missing are good interactive visual tools that express the states and dynamics of a repository, and provide natural affordances. Mark Lodato is one of a small set of  explainers making an attempt to turn this cryptic language-pretzel into something that we can wrap our brains (and eyes) around:

But I think it will take more than just good visual-interactive tools to make version control a natural, pleasant part of programming with a distributed team. It will take a cultural shift in software development society. The people who are best-suited to design effective development tools are the very ones who are confused by the current pathological state of affairs, or repelled by it, or never even learned to program in the first place. I can’t blame them.