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.

Today, let's talk about the change-harvesters use of the concept-cluster we describe with the adjective "human". We advocate that both the what and the how are best centered around the humans in our systems. The change-harvester looks at changes -- in code, in individuals, in teams, in process & flows, in organizations -- and sees that ,successfully applied change is human, local, oriented, taken, and iterative, often enough to adopt it as a general approach. So let's do "human".

Episode 40 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.

Monovalence is creating a kind of value "one ring to rule them all" then either coercing any other type of value into that one ring or ignoring it when the decision-maker can't figure out how, or just as commonly, forgets. In fact, there's lots of value in a dynamic unity that creates software that is not visible to the customer. Some of it's easily coercible, the kind of acts we call "axe sharpening". Some less so, things like enabling humans to work at all. 

Episode 39 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 reason it's so important for you to see 100 lines of code on your screen is that you have arranged the code so that 100 lines seems like a sane quantity. What you're doing is working against your own capability.

Episode 38 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.

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

A recurring respondents' theme is "TDD is irrelevant in front-end code". It's easy to offer/receive this comment combatively, but I think a little more rich discussion of the factors involved might bring us to new and different positions about UI and TDD.

Most folks who offer that are living in some sort of JS world: their code is client-side scripts attached to html pages to render various contents received from another application. Their browsers are in effect frameworks, inside of which all their code runs.

(Aside: One of the most prevalent trade problems caused by the explosive demand for software is the inexperience of your average geek on the street. It's easy to fall in to the "infinite now" and the "infinite here": assumptions that what one does now is what all do always.)

I want to step back from that JS world for a minute. Instead, I want to consider a bog-standard old-school single-computer single-program application, one that one user uses on one computer to perform multiple tasks, some of which are reasonably but not insanely complex.

Episode 37 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's take on "value" is quite different from the software trade's "standard" view. To get at that difference will take us a little time.

Three differences stand out for me just now, and they have to do with 1) definition, 2) distribution schedule, and 3) temporal stability. I want to take a look at these in a particular context: "the long story".

(Aside: I'm mildly sick today, so it's gonna spill out a little more slowly. It's dumb to work when you're sick, but you don't understand: I want to go out for dinner & drinks this evening, so I need to override the "too sick to go to school, too sick to play" tape in my head.)

I'll characterize this long story as a chunk of work that is six weeks long. I actually think a long story is any story the team can't deliver in "a good day and a half", but I'm not looking to debate that for now, so I'm picking six weeks.

Episode 36 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.

I distinguish quite strongly between "readability" and what I call "scannability". I think that our trade's pedagogues, even our very good ones, conflate the two, and in so doing inaccurately describe programming and ineffectively prescribe remedies.

Maybe the way to approach the idea is through your experience of seeing. Humans -- most vertebrates, in fact -- rely heavily on "seeing". The fabric of our experience is richly visual. A large portion of our neocortex is given over to it. Its use as metaphor is ubiquitous.

(Age 12, I had an older uncle-figure, blind from birth, was telling him about something, and I said, "See how it works?" Then I realized to my adolescent horror what I'd just said, fumbled & apologized. He laughed. "Relax, kid, I know what you meant, I *do* see how it works.")

Our visual experience looms large. And most of us carry around a straightforward concept of how it all works.

Episode 35 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.

Here's a thing that happens: "We tried your advice by not trying your advice except partly where we did what we want but gave it your labels and it didn't work and therefore you are wrong."

Now, if you've given that advice for many years, and followed it in your own endeavors, and you, your teams, and many others have succeeded with it, what are you to make of such a statement?

Well. Let's not hedge, the world has too much hedging, the truth is the first fifty times one experiences this one is likely to assume the statement-maker is some kind of fool.

"Doofuses gonna doofus."

Episode 34 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.

Aight. I been away from programming for a couple of months, but there was a reason I started talking the other day about the kontentment project: I’m wanting mucho change in it. For a talk I’m giving, I want the ability to draw human arcs, with the same ease with which I can draw human lines. So I set out today to get that in. Human straight lines start with a line segment AB. Pick two random locations on that line, so we got 4 points. Now jiggle all four points a little — that’s official terminology — and make them the four points of a cubic bezier: start. handle1, handle2, end. I “invented” this algorithm by going to a live JS site that lets me play with cubics visually and, uhhh, goofing around with them. At that time, I didn’t know how to interpolate cubics, but learning that was part of it, too.

Episode 33 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 talked about frames adding up to worldviews adding up to cultures, but it all feels pretty vague in its possible importance. We need some informal sense of how this works in practice. In the immortal words of Brian Marick, "an example would be handy right about now." Continuous Integration (CI) is the practice of frequently cycling code through the source vault. People practicing CI do this several times a day. In "git" terms, they both pull/merge/push, depending on language & task, once every 15-90 minutes.

Episode 32 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.

If you look at my videos, like the "Lump Of Coding Fallacy" for instance, they are basically two-layered. At the back, you got me as a talking head. In front, you got text, lines, and images. Stuff fades in and fades out, and the lines, in particular, "draw" as I blah-blah-blah. It's almost as if I were talking while sitting behind a large glass pane that was being drawn upon in bright very "human-ish" ways. Essentially, every video is a composite of two video sources, a transparent (color keyed as we say) one atop an opaque one. kontentment is the program I use to make that frontmost transparent layer.

Episode 31 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.

Here's one: a respondent says, "If I write a lot of small tests and I change how a feature works, I have to change or throw out all those microtests, which is a lot of work." (The respondent proposed an answer for this problem, and it's not a bad one, but raises some other questions we might get to later.) The one-liner response: "For me, it's *significantly* less work to do that than to work in any other way I've tried to date." I'm not gonna stop with the one-liner, cuz this is actually pretty important and we need to work it out in some detail.

Episode 30 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.

A decade ago I coined the term "microtest" for the kind of tests I write (or 95% of them). I found it easier to give people a new word than to try to parse the wildly variable meaning of any of the old words then in play, or even more inefficiently, argue definitions. I still do. A microtest is a short, precise, descriptive, fast, grok-at-a-glance, executable and persistent demonstration that what I said is what the computer heard is what I meant.

Episode 29 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.

People use the word "discipline" reasonably often when they talk about the software trade. I tend to avoid that word, and I wish more folks followed me in that policy. Most of those folks are not meaning anything untoward. They might easily use "orderly", "consistent", "persistent", "systematic", and so on, instead of "discipline", and as I say, I wish they would. "Discipline", in other parts of the forest, is an ordinary part of the vocabulary of extrinsic motivation by punishment that is a common element in command-and-control arrangements. "Discipline", in that part of the forest, is also used as a verb. Its meaning is usually "punish" or "sanction", and pretty much always implies "coerce" and "control".

Episode 28 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.

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

Before anything else, there's the series titles, and I'm going to make a joke: I always wanted to write "Low Self-Esteem For Dummies!" and see how many copies I could sell. There's a serious thought behind the joke. I don't like "...For Dummies", and I never buy one or recommend one. I am not a dummy. People who are asking for info aren't dummies. People who are learning to do a thing aren't dummies. People who ask dumb questions aren't dummies. When I was a kid, I asked one. A grownup said to Mom, "He sure asks a lot of dumb questions." Mom replied, "He sure as hell does, all day long." Then she said, , bless her heart, "You notice, tho, he never asks the same one twice." Every great thinker you know, every philosopher, every scientist, every writer, every artist, everyone whose mind you respect? Every single one of them got there by asking dumb questions. They weren't dummies, they were curious and thoughtful and courageous.

Episode 27 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.

When we talked about "if all you have is a hammer", we mentioned frames, and I mentioned Race, Build, and More, but then we kept right on going. I want to circle back now, because our heavy reliance on these causes a lot of confusion. They tend to block change-harvesting. A "frame" is a kind of crystallized chunk of experience. One wants to slide quickly to "idea" or "concept", but resist that pull: ideas & concepts are far more chosen, more conscious. Frames are -- to use a lovely geek phrase -- much closer to the metal. The word has two flavors in it, both important. First, think of a frame as a rigid structure that holds things together. Your car's frame, for instance. Second, think of a frame as a boundary, with an inside & outside. When we speak of a painting's frame, we use that flavor.

Episode 26 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 central concept of a dynamic unity is change-harvesting: make a change, harvest its value, use that value to make another change, over and over, change after change, world without end. We spoke the other day about how tools shape *problems*. "If all you have is a hammer, all you will see are nails." It was a conversation about *mental* tools: frames, worldviews, culture.  My contention is that our trade's standard frames, worldviews, and culture are failing us, and that we need something different. Change-harvesting is my attempt to get at that something different.  As a worldview, a cluster of *mental* tools, change-harvesting has several serious consequences, at the level of solving problems and, as we discussed before, at the level of experiencing them in the first place.

Episode 25 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 call a thing a "unity" because we experience it as a whole thing. It has an inside and an outside and a border. It might be made up of other parts, other unities, even, and the border might actively exchange parts from outside & inside, but still we see it as a whole thing.  We call a thing "dynamic" because of the extent to which it changes over time. The more often it changes, the more ways it changes, the more dynamic it is.  When we put those words together, we get a whole thing that is changing a lot. From one point of view, it's a persistent thing -- the *same* thing from moment to moment. From the other point of view, it's undergoing almost constant change."

Episode 24 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.

1. Emphasize open disputation. If we disagree, that's a *good* thing, not a bad one. It means we have more than one idea in the room, and we're in the idea business.
2. Don't underestimate the power of laughter -- for good or ill. What your team thinks is funny, and how, when, and where it expresses that, these are strong clues to the level of safety. Is your team humor mean? Is it open, an everyday thing? Who isn't laughing, and why not?
3. Do things together. A lot of the weight or mass of health is in the bonds the team forms. Do them on work. Do them at work. Do them outside of work. Aim for being parent-friendly and sober-friendly. Service -- charity -- can be as powerful as fun. Mix and match.
4. Find the sweet spot in team agreements between too many and too few. A rough guide: same number of agreements as members. Write them on the wall, and include safety in them.

Click here to join the Change-Harvesting Camerata!

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.

"A camerata -- h/t Jess Kerr for that term -- is a group of people working on a common problem, both together and separately. Part salon, part clubhouse, part Republic of Letters, part continuous colloquium, it provides a kind of interactive operational base for that community. A camerata is centered around acts of creation, invention, and experiment that occur in a kind of hothouse composed of people who are 1) alike enough to grasp those acts and 2) different enough to shape those acts, and 3) energized enough to engage with those acts."

I've launched my Camerata project and it's already starting to fill with members. Click here to Join the Camerata Now!

---

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.

"Nearly all significant change in human behaviors, individual or group, depends on three things: a new technique, a new mindset, and a path that can reach both. The geek trades generally overvalue the technique, undervalue the mindset, and ignore the path altogether. If we’re to change the trajectory of the trade, we need to attend to mindset and path both. A rough understanding of the ideas of frame, worldview, and culture will be very useful in that endeavor. That begins with the meaning(s) of that well-known aphorism. When we have a problem, we come up with a solution using our tools. That’s about as dictionary-straightforward as one can possibly be. The tools shape the solution that we come up with. But that is not what that saying means."

Episode 21 is now live. 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 the podcast over on GeePawHill.org.

"When people feel unsafe, there are usually only two reactions. One is total silence. The other is defensive anger. I have been in workplaces where 100% of the discourse was either one of these or the other. Because safety is so often at risk when people are angry about their differences, there's a kind of knee-jerk thinking that suggests we should never be angry or never display our difference. Both of these approaches are quite common. Both fail routinely, in different ways. "

Episode 20 is now live. 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 the podcast over on GeePawHill.org.

"A respondent asks, "Are you always able to practice what you preach? I don't mean intentionally dropping but unintentionally as your mind is sloppy. I have great difficulties in applying 100% of my "knowledge" 100% of the time." Sometimes questions open up huge areas with lots of issues and subtexts and angles, and this is one. It's too big to fit in one or two tweets. First, the direct answer: Oh, *hell* no. I am definitely not always able to practice what I preach. (I'm excluding externalities or conscious intent.) The cause can be any number of factors rooted deep within my human-ness and, in truth, far outside my agency."

Episode 19 is now live. 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 the podcast over on GeePawHill.org.

"I try to seek both multiplicity and diversity in the purposes we offer to the individuals around us. Both of those words matter. We want many available purposes. And we want them to be different from each other. The most common scenario one sees in an organization is the selection of one big overriding purpose, and underneath it a host of instrumental purposes, likely each of them with further sub-instrumental purposes attached, forming a nested hierarchy. The idea is that we're *all* part of one thing, that one thing is really Important[tm], it can be decomposed hierarchically into many things, and then the lucky motivate-ee's can plug themselves in until all the purpose-slots are covered."

Episode 18 is now live. 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 the podcast over on GeePawHill.org.

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

"Those who rate this band of the motivational spectrum highly can be go-to workhorses, but only if we keep them connected to their valued greater. If rhythm is largely focused on the distribution of "feels good" through one's working life, purpose works to carry us through the "feels bad" part of it, by transforming the local discomfort into an instrument for the higher goal. Have you ever been helped by a four-year-old, maybe in the kitchen, or with the yardwork? Your young friend is seeing a greater end than her own. She's finding a role for herself within it. She's transforming tedium into fuel. She's *helping*, and manifesting purpose-in-action."

Episode 17 is now live. 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 the podcast over on GeePawHill.org.

"We talked about the widespread pernicious conceptual cluster we call "finish-line efficiency": the idea that software development is basically a race, w/a start, a well-marked track, and a precise finish line some distance away. Overturning this is central to engaging mastery. I'm always chary of simple mappings from software development to the physical domain. But if it resembles anything like "getting from here to there", the thing it most resembles is an exploratory expedition across an unknown continent. In a simple race, we tune to be running machines: perfect stride, optimal pathing, minimal awareness. Don't move laterally or in reverse. Don't find shortcuts. The target stays still. Fuel up before & after. We *follow* the path, we don't *create* it."

Episode 16 is now live. 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 the podcast over on GeePawHill.org.

"When my motivational spectrum calls for a high degree of mastery, I do my best work when it is just a little over my head. People sometimes confuse the drive for mastery with a drive to know everything. But it's not the knowing, per se. It's not *catching* the skill, it's *chasing* the skill. My own spectrum rates mastery the highest, 9 on the scale of 10 for me. I am never more driven than when I've got some challenge I *think* I can do but I'm not *sure* I can do."

Episode 15 is now live. 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 the podcast over on GeePawHill.org.

"The more we need creative technical work, the more we have to concern ourselves with providing the humans who do it the adequate autonomy to do it well. Machines can't give us what we need, and the extent we build machine-like things made up of people is exactly the extent to which we handicap our ability to get what we need. At the same time, we take a risk. After all, if *anything* goes, some very Bad Things[tm] can go. We need to find ways to consciously manage our risk while still getting the best advantage we can from our use of those pesky non-machines whose human-ness is exactly what we value."

Episode 14 is now live. 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 the podcast over on GeePawHill.org.

"As a pure code monkey, my greatest asset is unquestionably my ability to organize, to rapidly arrange and re-arrange ideas out there in mind-stuff, where the Platonic forms live. To do that, I have to know where things are now, what kind of things they are, their size & shape. But situating myself isn't just remembering what's there. It's ultimately formulating some kind of change-plan. I do that by doing things that amount to a kind of labeling: "blocker", "detail", "totally irrelevant", "bingo", "scary", "hackable"."

Episode 13 is now live. 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 the podcast over on GeePawHill.org.

"As the nature of work has become a matter of workers interactively navigating complex adaptive systems -- ecologies, really -- processes that center their focus on mechanical/procedural uniformity fade into irrelevance. What is needed isn't a body and a rulebook, it's a human who can use ongoing situational awareness to operate largely *beyond* mechanism. And the thing is, that gal who does that well? I guarantee you she got good at it because she enjoyed it. Take that away and you lose her."

Episode 12 is now live. 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 the podcast over on GeePawHill.org.

"Now, there are no bad dogs. Sentinel returns aren't inherently evil: there are two reasons why they're ubiquitous down there at the bottom of your stack, a cut or two above the metal...But every sentinel return in your code is a guaranteed explicit branching construct in that code. In the string find case, for instance, you can never use the answer blindly. You *have* to branch around the possibility of the sentinel saying "no love here". I don't desire explicit branches. They make me think, and mama dint raise no thinkers. When I *can* find a way around them, I do. The trick, as with most coding constructs one's unhappy with, is to see if you can wrap it so that it works in your context but so the branch is effectively hidden from view almost immediately, level-wise." 

Episode 11 is now live. 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 the podcast over on GeePawHill.org.

"Getting good Rhythm, a well-tuned distribution of "feels good" over time, is incredibly difficult to achieve through formula. This is exactly because it reaches us at such a deep level. But reaching us so deeply is what makes it such an important topic."

Episode 10 is now live. 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 the podcast over on GeePawHill.org.

"A reset like that is a kind of mutual suspension of distrust. It's a "play like", as in "play like we haven't built up all this cruft between us". To really work, it seems like it has to cut both ways, it has to be a joint decision. Of course, a *genuine* *total* reset is virtually impossible. Human memory is in human bodies, and one can't will it away by simple fiat. What one *can* do is make a conscious effort to end the old game and start a new one."

Episode 9 is now live. 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 the podcast over on GeePawHill.org.

"Rhythm is about sequences of alternating tension and release. Noticing, orchestrating, and managing the levels and timing of those sequences is one way I can affect the motivation of myself and others...During the stretch, you bring some of your muscles into tension, and at the end of it, you release them, and it feels good. A tension & release like that good stretch, I’m gonna call’em t&r’s, is a one-off. But rhythm is about creating groups of overlapping, multi-modal t&r’s, and using them to keep oneself in a reliable state of “feels good”.

Episode 8 is now live. 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 the podcast over on GeePawHill.org.

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

"So, too, in this perhaps overblown metaphor, I'm taking what we call "motivation", and treating it like light, breaking it into component bands, and thinking about the various motivational puzzles one encounters in dealing with oneself and with others. There are two key aspects to this metaphor. 1) Every person's bar-chart, spectrum, motivational signature is different. 2) The closer the setting is to a person's motivational signature, the more motivated they are, and the further, the less so."

Episode 7 is now live. 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 the podcast over on GeePawHill.org.

"There is no story in the history of the English monarchy that could not be readily re-framed as the story of mobsters and their heirs wielding raw power and vying for the legitimacy that would clothe its violent, cunning, often psychopathic, murderous, intemperate behavior."

Episode 6 is now live. 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 the podcast over on GeePawHill.org.

"When I say tell and re-tell the story of us until it becomes the story we want, bringing us together in a culture of kind and creative community, I am not being mystical, airy, saintly, hippie-esque, poetic, or intellectual. I am talking about straight-up hardcore pragmatism."

Episode 5 is now live. 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 the podcast over on GeePawHill.org.