Thread by @GeePawHill

My rice'n'garlic advice, "take many more much smaller steps," can be said another way: reject any proposed path that requires a step size larger than the limit you've set for that particular domain of activity.

Time for Sunday geek comfort. It's meant to be respite. There are more important things than geekery, so please remember to think outside the monitor.

Stay strong, stay safe, stay angry, stay kind.

Black Lives Matter.

"Rice'n'garlic advice" is blind advice, for when people ask you what to do, but you're not there & can't see. You have to guess. A professional chef I know, when asked to give blind advice, always says this:

1) That's too much rice.
2) That's not enough garlic.

This kind of advice isn't expressing a universal law. (It is difficult to do, but you *can* have too much garlic, after all.) Nevertheless, for most people doing the asking, most of the time, that's a pretty good hipshot, applicable to most of her actual audience.

My blind advice, in that same spirit, is this:

Take many more much smaller steps.

It's not a universal law. It's just a shot from the hip, and I find it's generally good advice, for most of the people asking, most of the time. Here's how it works.

Most of us have goals that are beyond our immediate reach. Faraway targets, horizon targets, are important, after all. But, as soon as you adopt one, you're instantly stuck with a puzzle: how do I get there? What path do we take to get, not from A to B, but from A to Z?

And the answer, of course, is that we will do it in steps. My advice, then, is about how we choose those steps. And since "steppyness" is so important, let's take a minute to poke at the question of what a step even *is*.

A step is an activity, a span of time, an investment of energy & money, that stretches between two points of "readiness". It is the making of a change to a system. Before the change, we're "ready". After the change, we're "ready". In between, during the step, we're "unready".

The meaning of "ready" is different in every domain of activity. I'll tie it to the trade here in a second, but think about me working on my bicycle on this lovely Sunday morning.

The bike starts ready. But it has boring handlebars. I want *chopper* handlebars, with ribbons. I loosen the nut, we're not ready. I swap in the new ones, I adjust them, which takes time & energy & money. I tighten them down, and we're ready again. (And I have the coolest bike.)

And that stretch of unreadiness, that time when I could not ride my bike, that money and effort I spent then? *That's* the step.

A step is a gap between two states of being able to use my system.

In TDD coding, a step is the time when the tests fail. In product, it's when you can't ship. In process, it's when the flow is clogged. In persons, it's when you can't do the old way because you're learning the new way.

The step is the time when the system isn't ready.

A path -- remember our faraway horizon goal -- is just a sequence of steps we think will get us there. And for any given horizon goal, there's an effectively infinite number of paths between here and there. Each path's a unique combination of steps (including ordering).

We have to choose amongst this bewildering arrray of possible paths. And how will we do it? The rice'n'garlic advice says, "pick the path that has the smallest steps in it".

We stand at an odd point, here in the trade. Back in the day, most projects most of the time were *one* step. It was "Nothing. Everything. Move On". This worked more or less well, because the horizon goals weren't really that far away.

But as demand increased, as physical computing plummeted in cost, then -- round 2 -- as distribution cost plummeted in cost, the size and complexity of projects skyrocketed. One-step projects lost their glamour in the stretch leading up to the oughties. They're quite rare now.

And further, the trade has begun to recognize that the horizon is in the eye of the beholder. We used to think of our target as a finish line, the "Move on" part. But now we see it much more as a breathing point, a viable pause between steps.

This is good, very good. But we still haven't fully integrated step-size into our calculus. Everywhere I go I see people, yes, breaking things into steps, but no, not breaking them into steps that are small enough. Hence my advice.

You don't really need me to rehearse the argument for "fewest steps" rather than "smallest steps". It's *everywhere*. And as I have blah-blah-blah'd extensively about it, it's a theory based on logic that is shot through with patently false, often *trivially* false, premises.

What even is the "size" of a step? It's a squishy vague notion, one for which we have a variety of stand-in numbers, but nothing perfectlly concrete. Size-assessments take judgment, and judgment takes experience, and experience takes mistakes.

But, assuming a step is taking up most of our attention over a span of time, the length of that span is a somewhat half-assed but still viable measure of its size. So what sizes are we talking about. When we say "take smaller steps", how small are we talking about?

When I'm TDD coding, my step-size is nearly always well under an hour. When I'm changing product, i.e. working-by-story, I am aiming for stories that take under a day and a half of team effort. When I'm changing process, under a week.

That gives you a sense of just how small we can go. And I'll tell you, I want even smaller. That is, I am not remotely convinced that I have found the smallest possible steps in any of these domains. My practice is still a work-in-progress, and every time I see shorter I take it.

Surely, reductio being so absurdumating, I will hit a bottom size, below which I will not go. It must be so. But in the domain I know best, coding, I must have told myself I was at the limit fifty times in twenty years, and then I see another way and am forced to recant. :)

Lemme wrap this up with a few key insights that make it possible to start thinking this way, what I call the change-harvesting approach.

1) Finding paths with smaller steps isn't usually that hard. The hard part is teaching yourself to actually look for them.

Working with product teams, I'll throw out some half-baked small-step idea, and instantly, the team will produce 20 *better* paths with *smaller* steps. The only reason they hadn't done so before is because they weren't looking for that. They thought fewer steps was better.

2) It doesn't matter if I step-left-step-forward-step-right in my path. If those three steps are three smaller steps than the straight line, we'll get there faster.

I see this in refactoring all the time. Kerievsky's _Refactoring to Patterns_ does a lot of this. Instead of doing this in one large manual step of an hour, these six automatic refactorings will do it in a minute, even tho they amount to left-forward-right-right-forward-left.

3) Human performance doesn't degrade linearly with step-size. That curve has a sharp knee, gently sloping for a little ways as the step-size grows, then diving towards hell in a nearly vertical line.

Git doesn't care if your changeset mixes different kinds of change in different files for different purposes. Its performance degrades linearly. But the human? Oh, the human cares very much about that.

So.

1) That's too much rice.
2) That's not enough garlic.
3) Take many more much smaller steps.

It's a shot from the hip, I'm not there and I can't really see. But it's good blind advice, and I give it to anyone who asks.

Thanks for reading! Consider subscribing. Free, spam-free, full-text or podcast.

geepawhill.org/subscribe

And outside the code, or the trade? Please keep working for change. Especially, just now, please oppose voter suppression at every opportunity.

Black Lives Matter.