Changing one thing at a time

"[What's it take to be a good programmer?]"

Thinking like a scientist; changing one thing at a time.

That's according to Brad Fitzpatrick in Coders at Work. Arguably one of the best programmers around. It's one of those statements that's profound because of its simplicity. To build complex systems, you must make incremental changes serially that get you where you need to go.

It wasn't obvious to me before I became someone who programs a lot that you couldn't parallelize this. Fitzpatrick's approach is inherently serial; change one thing, then change another thing, then change another thing. That loop should become as fast as possible, but parallelization of changes is extremely risky when you're dealing with something complex. Any program worth your time is too complex to hold in your head all at once. The amount of the program you need to hold in your head at a time when trying to solve problems A and B in parallel is more than the sum of the amounts needed for each of A and B alone. In fact, it's probably super-linear; all kinds of pair-wise complexity starts showing up with big programs.

I know people who say they work in a multi-threaded manner. When each thread is lightweight, this is probably possible. It's unlikely that any of them are programming all day (or at least, not well).

One more skill implied with this framing: turning a desired 'direction' into a series of small changes. To be honest, I still struggle with this. Especially when I feel distracted. On days where I've programmed, I doubt that all of the time spent at the keyboard was moving me in the direction I intended to head in at the beginning of the day.

The way this usually manifests is spending all day fixing or refactoring random things that seem catch my eye. It's easy to find problems to solve without a direction, but important work only happens when there's a direction.

I'm not quite ready to make the obvious generalization that relates the memory-intensiveness of work to its parallelizability, but the case seems clear with programming.

Thanks Brad.