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.

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata.

Pull & Swarm is a technique for approaching the workload in front of a small team. It amounts to pulling one story from our queue at a time, and throwing all of our resources and humans at the same story at the same time. P&S can be useful to Scrum-based teams, but also to any small team using any method. Some teams I have worked with have done *pure* P&S. No planning as a group at all, no ceremonies, just make a queue with a half-dozen things in it, pull one, finish it, on to the next. But even within a Scrum framework, P&S is valuable: in that context it's more about how we work between sprint planning and sprint review. 

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata.

The economic aspects of microtest TDD are inextricably tied to the operational aspects of it. If we concentrate only on the artifacts involved, we will lose the picture and misunderstand the value proposition. As a professional geek, the heart of my job is changing rigidly structured imperative text in collaboration with other humans, in order to meet a variety of locally or temporally aligned goals. That's fancy talk for "I change code, in community, for money." The central event is the *changing* of code. (It's remarkable to me how very little attention we pay to this in the trade. Instead, we focus almost exclusively on getting to a state -- usually imaginary -- where no changing occurs.) So, if changing code's the thing, there are some factors, in the actual operation of changing the code, that seem to loom extra large when I talk about production or efficiency or economics.

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata.

I want to talk about this thing where you see someone on stage/screen presenting material about geekery, you decide you're attracted, and you send them mail or dm hitting on them.

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata.

What's a microtest, anyway? I write a ton of tests as I'm building code, and the majority of these are a particular kind or style of test, the microtest kind. Let's talk about what I mean by that, today, then we'll talk later about how that turns out to help me so much. A microtest is a small, fast, precise, easy-to-invoke/read/write/debug chunk of code that exercises a single particular path through another chunk of code containing the branching logic from my shipping app. Microtests are first-class source code, maintained and kept side-by-side in the vault with the source code that makes up the shipping app. They are maintained with the same level of attention, the same standard of excellence, as the production source is.

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata.

I think of my style of coding as "microtest TDD". That can be misleading for folks, so let's take a walk over a few of the ideas, implicit and explicit, that make up the approach. First things first, bear the money premise in mind in all that follows, to wit: "I'm in this for the money." In the software trade, we make money by shipping more value faster. This is why I adopt these practices, because when I do them, I go faster. In particular, I don't do them out of a fondness for artistry, intellectual purity, common decency, perfectionism, or theory. I do them because they are the best way I've discovered, so far, to ship more value faster.

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata.

More seriously, the first piece of advice I'd give a monolith-owner about converting to microservices would be to work very hard to factor their monolith well. Interestingly, across dozens of cases, I've never seen that advice taken. There's always a well-dressed person with excellent powerpoint who is happy to give a compelling case for a technical solution to a problem that isn't technical. If you can't factor the monolith, you won't be able to factor your microservices. All of the same forces will be in play, all of them, with the difference that in a monolith excellent factoring is extremely important, but in microservices, excellent factoring is mandatory. 

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata.

I use spikes, periods of code-changing activity that end with no pushes, all the time, at small scale and large, as a way to develop my path. It's a vital technique, and it's often underplayed, so let's spend some time with it. What's a spike? A spike is a stretch of time I spend mucking about in code, and that stretch of time has one rule: "Do anything you want, because you can't keep it." We originally used the term to describe a certain kind of story. We'd be facing some task without the slightest clue of how to perform it. So we'd put a story in place whose goal was "figure out how to do X". But we explicitly separated "figure out how" from "do". The rationale here was based around our sense that practicing XP meant a certain rigor in our behavior. But maintaining that XP level of self-control can be difficult at times, and the most particularly difficult times to do that were times when we felt we had literally no clue. 

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata.

Let's talk about steps and value. Out in the world, folks make a lot of decisions involving these ideas, they reason about them. We want to make sure our reasoning is based on a thorough understanding of the implicit premises. What's a step? A step is a gap or space, in time and activity, in between two points, a Before point and an After point. At the Before point, a system is "ready". At the After point, a system is "ready". In between, during the step, the system is "unready". That idea, of ready or unready, needs a little elaboration. Remember that the change-harvester's vision applies to lots of different contexts where change is sought. And ready or unready really only have meaning in the particular context in which we're making changes.

Today, I'm going to limit my context to seeking changes in a codebase that is already shipping. Later in the thread, we'll wonder about different contexts, but for now, let's just narrow our focus.

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata.

I shipped a word processor that formatted the hard drive every 1024 saves. Must have '84 or '85. I was a bright 25-year-old with about five years in the game. I was one of two programmers who wrote & maintained a suite of apps kinda like Office: spreadsheet, wp, database, plotter, such like. We customized everything for three or four vertical markets. So I wrote most of the wp. This was in Forth, on a variety of OS/CPU combinations. Young'uns don't necessarily know this, but in those fays there'd be a new microcomputer with a custom OS and one of several CPU's every *month* or so. Forth used block-based disk i/o. Each block was 1kb in length, and to save anything larger than 1kb, you ended up with a file master block that would contain offsets to the blocks that had the data, basically a pair of lists, allocated and none. To initialize that file master, I'd fill it with zero's. And away we go!

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata.