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.

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.

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.

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with GeePaw Hill

GeePaw Hill Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @GeePawHill

2 Apr
q: how many ways are there to partition a 5x5 tile square into 5 pieces, each containing 5 orthogonally contiguous tiles?
(Asking for a self who is considering a brute-force algorithm.)
I figure there's a tree. Every such partition has [0,0] in A. There are only three one-steps away, [0,1] in A, [1,0] in A, or both. And so on. If we mapped that tree one time, we'd have a number of cases. Times 4 for rotational symmetry. Times 2(?) for diagonal symmetry?
Read 5 tweets
28 Mar
Once armed with the idea of a shipping app and a making app, a whole range of possibilities open up. Among the most powerful: give your making app a UI just for making.
It's Sunday, which is geek comfort food day for me. Remember, tho, to think and feel and work outside the monitor. Please help me in opposing the multiple ongoing efforts to suppress the votes of millions of American citizens.

Black Lives Matter.
A "making app" is when we take the same sourcecode from the program we're shipping, and use it for another program at the same time. That program is one we develop and tailor expressly to enable us to work more effectively on the shipping app.
Read 39 tweets
28 Mar
My friend Steve, I was spozed to be the pro from dover, told me this thing, and for, idunno, 17 years or so(?), I've been holding on to it. He said it boils down to two things. Don't waste time. Accept the whole person.
NB: It doesn't mean "accept everyone". It means, if you accept my geek chops, or you accept my sex appeal, or you accept my brilliant theorizing, you gotta accept my (considerable) doofusness.
You can't take my good days and not accept my bad ones. And if you can't handle my awful, why are you prepared to cash in on my valuable?
Read 5 tweets
21 Mar
In a data-rich environment, we can use the Builder concept to make DSL's for our Making application. This often makes testing the hard business core of our code both faster and easier.
Folks, I love sharing my geekery with you. For me, it brings much comfort. I hope, tho, you'll join me in working for change that isn't just about code, but about the larger world.

Black Lives Matter.
We've spoken in the past about using our codebase to do more than one thing. We always use it to create our shipping app. But we can and do use it for an app that improves our *making* process. We call that the making app.
Read 33 tweets
19 Mar
Honestly, y'all should read WCW more seriously before you gimme the parody.

Not hating. Just saying.

This dude rang the bell a dozen times in his career.

Imagine that.
My favorite WCW, my top-five poem of forever, is this one.…
So. Love you, do love you, for real. But your fridge plum thing is old and tired and disrespectful of a poet who shakes the world.
Read 5 tweets
19 Mar
Here my Stevie, rescuing me as he does surprisingly often. "Heaven Is 10 Zillion Light Years Away".

My heroes show up, randomly, just in time.
This was the song that helped me grasp the difference between anger and hate.
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!