Thread by @GeePawHill

Changing Pro-Tip: All the knobs a little, all the knobs a little, over and over again, is how I've make my most successful changes, in code and organizations alike.

A while back, I mused first about "Always Small, Always Improve" geepawhill.org/always-small-a… and I later elaborated "Always Small, Always Better, Always Wrong" geepawhill.org/always-small-a…

Lo these two decades ago, we characterized eXtreme Programming as turning all the knobs to 11. I've always loved that metaphor, and I still believe in it. But my strategy for changing from "where the knobs are today" to "all at 11" has been through a great many revisions.

Nowadays, and this is just a restatement in some ways of "always small, always better, always wrong", I see the job of creating change -- in code and in orgs alike -- as turning all the knobs a little, all the knobs a little, over and over again.

Imagine I'm working with an org that is working on software that's already in production. It's modest, maybe a dozen geeks, maybe 50KLOC. And for whatever reason, they feel they want to change how they do things.

They investigate the techniques of the modern synthesis -- working by stories, TDD, refactoring, CI/CD, optimal collaboration, psychological safety, and so on. All of these are knobs we can turn up to 11.

After all, those of us who are committed to this movement believe in that idea, and we pitch it, and we pitch it well. It is totally thrilling to us that some team wants to try our way of thinking.

The natural thing for them to do is simple and straightforward: first thing Monday morning, it's all knobs eleven all the time, go big or go home.

This big-bang approach is natural. It is simple, straightforward, and direct. It is *bracing*, and it's energizing, and it's every good thing.

It also nearly always ends in a great deal of useless and ineffective pain.

There are several reasons why this is so, but I don't want to delve too deep into that, so I'll see if I can enumerate them right quick and keep going, cuz I want to get to the good part.

1) missing skills. 2) unseparable effects. 3) prerequisite subtext. 4) human resistance to shock. 5) re-tooling. 6) unfinishability. 7) change bandwidth. 8) consensability.

You can ask about these, or maybe there's another muse in the wings, but let's move on for now, because I'd rather talk today about what I *have* found to work well rather than what I haven't or why.

All the knobs a little: what I try to do is change any given knob just the slightest tweak upward in a way that will do just three things: 1) still work well with other knob settings. 2) not be definitely in the wrong direction. 3) pay off in actual experience in days or weeks.

A very technical case: the microtest knob and internal quality knob. It may be that my team is rolling partially greenfield code to add to the base. It may be that we're bug-fixing or performance-buffing code we already wrote. Either way is an opening to tweak these knobs.

I use different ways at different times, but I think the gist, in this case, is to give them the experience of working in ENOF mode. ( See: "Easiest Nearest Owwie First" geepawhill.org/pro-tip-refact… )

There will likely be only one or two small cases. It doesn't matter how many. What matters is that it's easy for them to do and easy for them to experience the "better" of doing it.

When it works, two knobs have moved, in parallel, a little tiny bit. Rinse, lather, repeat. After a few passes, some skill-building will have happened in those areas. That's great, but something else will have happened: skills and willpower will have grown in *other* areas, too.

Remember collaboration and psychological safety? The time I spend with them getting a tad of microtesting and a tad of internal code quality is time I spend with them. And when I'm doing that, I'm building collaboration skills and a sense of safety, both directly & via modeling.

"All the knobs a little" really is just a restatement of "Always small, always better, always wrong."

It reminds me to make small changes, the smallest ones whose effect can be felt. It reminds me that that feeling must be a feeling of better-ness. It reminds me that there is no city on the hill, there's just making things better every day over and over again.

Now here's a funny thing: imagine that there *is* a perfect way for a perfect company's perfect programmers to solve perfect problems for the perfect customer. Let's call that Method P.

As a change-r, I don't have to know Method P. I don't have to teach Method P. I don't have to pitch Method P. I just have to help my team learn how to enjoy inching towards it. If it's there, they'll find it. If it's not, they'll still find "better". It's a win either way.

So, I just keep tweaking knobs, all the knobs a little, all the knobs a little, and all of my most successful changes have happened in that way.

Have a cool-breeze Thursday night, and we'll catchya later.