PawCast with GeePaw Hill – Détails, épisodes et analyse

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!

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! --

If you're asking an object for data, ask for exactly what you want to know, instead of what you'd need to compute what you want to know. A very simple example: the PlayerView wants to disable/enable some of its controls when the Player is actively playing. In the "before" code, PlayerView asks the Player for its PlayerState and decides, based on its value, whether that means the Player is playing or not.In the "after" code, PlayerView just directly asks the Player if it is playing. This is such a tiny change: literally cut/paste the condition out of PlayerView and wrap it in a new function in Player. Multi-class refactoring doesn't get much simpler than this. But the impact is real. In the Before, PlayerView has to know about PlayerState, and it has to know the meaning of Player having certain PlayerState values. In the after, PlayerView just has to know that a Player knows whether or not it's playing. 

Episode 47 is live! If you are interested in becoming a part of the conversation, Click here to join the Change-Harvesting Camerata Today!

---

If you have any feedback you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. You can also read the full transcription of this podcast over on GeePawHill.org.

In one's first intro to refactoring, one sees a lot of "rename", "re-order", "inline", and "extract". These are pretty potent tools, don't get me wrong, but I think of them as, idunno, atoms. I think of these "second order" refactorings as small inorganic molecules. An example of this would be one I call "swap supplier & supply". Let's take a look, in this case, at a real one. 

Episode 46 is live! If you are interested in becoming a part of the conversation, Click here to join the Change-Harvesting Camerata Today!

---

If you have any feedback you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. You can also read the full transcription of this podcast over on GeePawHill.org.

Let's talk about "Working By Stories" for this first one. I'll describe what I/we mean by that, and then we'll try to look at it through our change-harvesting lens. I had thought to do TDD & Refactoring first. But working by stories has some advantages. It's a smaller topic, it doesn't involve us in a lot of technique arguments, and it seems to be more widespread in adoption. Change-harvesting is expressly not limited in scope to code & coding. It's not a new technique for programming, it's an outlook and a concomitant strategy for successful change in complex adaptive systems. Using stories as our topic seems just right.

Episode 45 is live! If you are interested in becoming a part of the conversation, Click here to join the Change-Harvesting Camerata Today!

---

If you have any feedback you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. You can also read the full transcription of this podcast over on GeePawHill.org.

The heart of the iterative approach is assuming change. We embrace it, we plan for it, we expect it, we encourage it, we enjoy it, we see it as the central act that defines what we are and what we do. A dynamic unity is a unity because it stays "the same", it persists across time. But it's also wildly dynamic: it is undergoing constant change, in its parts, their arrangement, the flows, even its boundary. The single unchanging aspect of a dynamic unity? The changing itself. You are a dynamic unity. Notice two things: 1) Many of your parts are also dynamic unities. 2) The day you stop changing is the day you stop altogether. So, too, with your organization. It's a DU made partly of other DU's, and it only stops changing when it dies.

Episode 44 is live! If you are interested in becoming a part of the conversation, Click here to join the Change-Harvesting Camerata Today!

---

If you have any feedback you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. You can also read the full transcription of this podcast over on GeePawHill.org.

To get to there, we want to start from, work with, adjust, and nurture what we have right here. A couple of examples might tighten this right up for you. We'll take one from changing code and one from changing process. In the early days of a coding project, everything is new. We're working with a blank page, and our creation-act is almost entirely about adding to that page. One has tremendous range of motion, the freedom to spitball, to write whatever we want however we want it. In fairly short order, though, our project thickens, with new capabilities, different-but-related tasks, additional datasets, and so on. The page isn't blank anymore, and everything we add to it must still fit with and connect to what we already have.

Episode 43 is live! If you are interested in becoming a part of the conversation, Click here to join the Change-Harvesting Camerata Today!

---

If you have any feedback you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. You can also read the full transcription of this podcast over on GeePawHill.org.

We've said that leaning in to the humans in our systems leads us to locality pretty directly. We say "find the smallest easiest nearest change with detectable outcome and make it". But this gives us a puzzle: there are often a lot of such changes. How do we decide between them? The change-harvester's "oriented" says don't sweat it too much: turn to face your non-local goal, and grab any change that doesn't make it further away. Don't spend a lot of cycles deciding which change aims precisely, take anything that's not definitely wrong and do it. Goals that are outside what we can do in one step -- non-local goals -- live out there on the horizon. The change-harvester orients herself towards the horizon, then acts, without much fuss. And that's what that word "oriented" means.

Episode 42 is live! If you are interested in becoming a part of the conversation, Click here to join the Change-Harvesting Camerata Today!

---

If you have any feedback you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. You can also read the full transcription of this podcast over on GeePawHill.org.

The change-harvester uses these five words to describe the properties of successful change: human, local, oriented, taken, and iterative. Let's talk about "local".

Episode 41 is live! If you are interested in becoming a part of the conversation, Click here to join the Change-Harvesting Camerata Today!

---

If you have any feedback you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. You can also read the full transcription of this podcast over on GeePawHill.org.