Thread by @GeePawHill

Folks, I've been pretty quiet about geekery lately. I wrote about using my geekery content as a small dose of comfort food. I'm going to offer a little more, today.

We can geek out a little, for relief, because you gotta care for yourself to care for others. But this is not any kind of "return to normal". We don't *want* to return to normal, we want to press forward.

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

Black lives matter.

The single most important thing my years of doing XP helped me learn, specifically TDD and refactoring, is about the size of the steps. When I started it, I had in mind "small steps" that were, well, they weren't really small at all, just "comparatively less gigantic".

Graybeards like me came up a certain way. We relied heavily on 1) large and well-organized memory, 2) a facility for rapid transition back and forth between high-structured high-detail imperative text and ordinary meaning, 3) an ability to imagine large transformations "whole".

It's a curious contradiction, to me, that these attributes were what enabled me to be a good geek, but ultimately, my universal and heavy reliance on them actually prevented me from stumbling into mastery.

One needs those attributes in some amount, no question. But for me, they're made far less important by a fourth attribute, one I didn't have forty years ago when I joined the rodeo: the ability to imagine, see, trust, take, organize, and confirm easy little steps.

The question I now take up every day all the time, in almost everything I do as a geek (and some of what I do as a person), is this:

"What is the smallest possible step I could take that would change this situation in a way that I can detect?"

In code, "small" means something I can do in a few minutes, maybe as many as 20. When I say "do", I mean pull, change, commit, push. I mean that when it's done, I can keep going or walk away.

It's quite a constraint. Limiting my steps to such a small size dramatically shapes my process, beginning & middle & end. Let's talk about some of the ways it does this.

The first and most obvious change I wrote about the other day: I use many many more spikes than I ever did when I was merely good.

geepawhill.org/2020/06/02/an-…

The reason: spike-time lets me develop a sense of path -- which steps to take and what order to take them in -- and a sense of confidence. When you're taking tiny steps in order to make a big transition, confidence that you're headed in a viable direction really matters.

The second, closely related, but useful to me even in step-time, I reset a lot. That is, I value the typing of code far less than I once did. Typing in code is the easy part of my job. Knowing where I'm going is the hard part.

The third change: I *really* value the confirmation process: the part where I confirm that the step I just took (or when I'm TDDing, that I'm about to take) really took effect and really did what I wanted it to.

I get really irritated when I'm forced to work w/o that confirmation. Sadly, so few of the tools, frameworks, and libraries we operate with actually give us that confirmation in any simple way.

Speed of confirmation, especially, really drives me. I hung w/some friends last night while they coded a small thing, and it made me batty how long we had to take to confirm the value of our steps. It slowed everything down, caused much more theorizing and distraction.

The fourth change: seeking tiny steps like these has made me jiggle my sense of progress. I used to try to limit myself to changes the *user* could detect. That made my steps have to be larger. Now I just worry about whether *I* can detect the change.

Sure, I'm aiming to add value for the user. And every N number of steps, we get to such a state. But N can be fairly high, and it doesn't trouble me. Sooner or later, the steps will mature into more value, and I trust this.

Getting past this "a step is only a step if it pleases a user" thing was hard, but it's really important. It makes it far easier to find steps. I need to please a user every day or two, but I don't need to do it 20 times a day.

A fifth change, also related to value, is that it's okay for me to take steps sometimes when I'm not sure they're on a straight line towards the shipping of a story. "Might" or "seems likely", as opposed to "must" or "definitely" is very useful in step selection.

Renaming a method or class, re-ordering lines, lots of this kind of small refactoring, these are "seems likely" steps. They don't earn their keep by being on the definitive path to a given story, they earn it by raising the signal/noise ratio.

I get stuck sometimes, because I can't see a path to the transition I want. But just today, for instance, I made a couple of renames, and *poof*, almost like magic, I suddenly saw the way forward, for no other reason than because I had a better name.

I was like, "Oh! It's *not* an aspect ratio, it's an aspect ratio *constraint*. The ratio is a different thing!!" Now I got another fifteen or twenty steps in my head, all because changing the damned thing's name let me see what it meant.

Anyway, these five changes, and likely some more I'm not thinking of right now, all derive from just one thing, my submission to that single constraint: what's a change I could do in a few minutes, including confirmation, that might make my situation better?

I got to a certain place in geekery by focusing on "knowing everything". I got past that point by focusing on "taking really tiny steps". The change has startling effects. I think I'm not just a little better at geekery than I was 20 years ago, but several times better.

If you like my content, do me two solids:

1) Subscribe to the blogcast. It's free, it's spam-free, and it helps me.

2) Keep pushing for change, in geekery, and far beyond it. Black lives matter.

geepawhill.org/subscribe/