Here's another technique card from my seminar, "Leading Technical Change". We first get into midwifing change precisely because we want it to be smoother, easier, and faster. But sometimes, a coach needs not to rush a decision through, but to slow it down.

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! 

If we're going to enable and support change, we're going to fail, more often than we succeed, and we want to bake tht idea in, early on, lest we fail both more often, and potentially more disastrously. 

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack!

Can we be honest? If we're going to be successful change midwives, honesty is very important. In this technique card from Leading Technical Change, I talk about some of the ins & outs of this complicated topic.

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack!

The people who hire me ask me to help their teams make changes. Most of the time, my first step is to see how I can slash those teams' load. To me, this is dreadfully obvious, but for a lot of folks seeking change, it comes as a completely shocking idea. The weirdest part, though, is that it not only improves our ability to change, it usually also increases our actual productivity. Let's talk about the change effect of that first, then the productivity effect.

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack!

Joy project: Today's a comparatively light work day, so I'm gonna lay out what I'm actually trying to do with this project. The source, btw, is at: https://github.com/GeePawHill/fgno-plotter. 

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

TDD Pro-Tip: I advocate against automated macro-tests -- those whose base is entire running programs --, as their cost is high and their benefit is doubtful. I very rarely write them. There is a bewildering variety of terminology out there around what I'm calling macro-tests, so let's poke around a little.

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

I spoze the historic and ongoing inability/unwillingness of the software trade to grasp and adopt test-driven development (TDD) is one of the most frustrating & demoralizing events of my forty-two years as a professional geek.

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

Let's talk for a minute about "over-coding". Over-coding, when you're a TDD'ist, is writing more code than you (intended to) have test to cover. But I will offer a few thoughts on this to *non* TDD'ers and TDD'ers alike.

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

Here's ten I-Statements about change, in the geek trades, and beyond. My hope is that it will give you a richer sense of where I'm coming from in my blogs, talks, videos, and courses. 

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

I've oft mentioned how the twin cost-revolutions in geekery warped & nearly destroyed our trade. Then wondered if we'll get to a place where it's no longer profitable for most companies to write bad software poorly. This morning I wonder if I'm seeing the beginning of it.

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

I was a good programmer because I was a *terrific* memorist: I could learn things by heart, and I could organize them in my mind in such a fashion that I could get to them whenever I needed them. It is the nature of humans that whatever they have had so far, they assume they will have forever. There's a default assumption that whatever's going on will continue to go on, ad infinitum. This applies to the good things they have, and also the bad things, of course, and is a defining property of humans, in my view.

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

On the cover of Hofstadter's famous _Godel, Escher, and Bach_, there's a photo of an artifact he made, called a "trip-let". The trip-let, when lit from three different angles, produces shadows that spell out "G", "E", and "B".

Let's talk about software design.

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

True story: Eighteen or so years ago, I had a gig rolling code at an engineering company. We were writing a windows app using Microsoft Foundation Classes to drive a TTY interface to a box of various radio hardware junk.

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

In our efforts to optimize the Many More Much Smaller Steps (MMMSS) path, we've tried and rejected the "shortest-distance" floptimization. Today, let's take up the "pin-making" floptimization, in which we create specialists, stations, and hand-offs.

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

We've built ourselves a positive case for "Many More Much Smaller Steps" (MMMSS). There's a counter-case, tho, based in a trio of proposed optimizations. Sadly, those optimizations usually flop. Today, let's take up the "Shortest Distance" floptimization.

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

We've covered the MMMSS idea a couple of times now. This time we want to consider the key element of the case in favor: the remarkable intrinsic value we receive from Many More Much Smaller Steps. It's not immediately obvious, so let's take our time.

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

As a person who has been successfully coaching software development teams for twenty years, let me throw out a few ideas to chew over. With luck, maybe one of them will jiggle the frame enough for you to find a next step.

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

Earlier, we sketched out MMMSS, Many More Much Smaller Steps, laying out the bare bones. Cool, cool, but now we need to thicken our sense of the idea. Today, let's close in a little more on what "step" means to us.

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

The first plank of my take on fixing the trade is MMMSS: If you want more value faster, take Many More Much Smaller Steps. Today I want to start laying this out for folks. This isn't gonna happen in one thread, but let's get started.

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

In the spirit of my Ten I-Statements about TDD, here's ten more, this time about refactoring. I'm not covering everything, just hitting some of the high points of my refactoring activity here.

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --