Skip to main content
PawCast with GeePaw Hill

PawCast with GeePaw Hill

By GeePaw Hill

GeePaw is a software development coach with over 30 years in the field. His unique understanding of how to enact lasting change among teams has established him as a leader of the agility concept known as "Change-Harvesting". Here you can find his weekly podcasts.
Listen on Spotify
Where to listen
Amazon Music Logo

Amazon Music

Apple Podcasts Logo

Apple Podcasts

Castbox Logo

Castbox

Google Podcasts Logo

Google Podcasts

iHeartRadio Logo

iHeartRadio

Overcast Logo

Overcast

Pocket Casts Logo

Pocket Casts

RadioPublic Logo

RadioPublic

Spotify Logo

Spotify

Stitcher Logo

Stitcher

Slowing Decisions Down | #147
Slowing Decisions Down | #147
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! 
04:29
November 11, 2022
What About Failure? | #146
What About Failure? | #146
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!
05:31
November 09, 2022
Can We Be Honest? | #145
Can We Be Honest? | #145
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!
05:50
October 28, 2022
Slash the Load | #144
Slash the Load | #144
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!
05:18
October 25, 2022
Joy Project: FGNO Plotter | #143
Joy Project: FGNO Plotter | #143
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! --
05:27
October 07, 2022
Against Automated Macrotests | #142
Against Automated Macrotests | #142
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! --
11:33
October 04, 2022
Some TDD History | #141
Some TDD History | #141
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! --
09:46
September 30, 2022
On Over-Coding | #140
On Over-Coding | #140
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! --
06:03
September 27, 2022
Ten I-Statements About Change | #139
Ten I-Statements About Change | #139
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! --
07:34
June 29, 2022
Trade Collapse Begins? | #138
Trade Collapse Begins? | #138
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! --
04:19
June 16, 2022
On Not Knowing | #137
On Not Knowing | #137
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! --
05:03
May 17, 2022
The Shadows of Software Design | #136
The Shadows of Software Design | #136
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! --
09:18
February 15, 2022
Me, Gary, and TDD | #135
Me, Gary, and TDD | #135
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! --
04:43
February 08, 2022
MMMSS - The Pin-Making Floptimization | #134
MMMSS - The Pin-Making Floptimization | #134
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! --
13:56
December 28, 2021
MMMSS - The Shortest-Distance Floptimization | #133
MMMSS - The Shortest-Distance Floptimization | #133
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! --
12:56
December 21, 2021
MMMSS - The Intrinsic Benefit of Steps | #132
MMMSS - The Intrinsic Benefit of Steps | #132
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! --
12:06
November 09, 2021
Random Coaching Tips | #131
Random Coaching Tips | #131
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! --
04:58
November 02, 2021
MMMSS - A Closer Look at Steps | #130
MMMSS - A Closer Look at Steps | #130
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! --
12:49
October 26, 2021
Many More Much Smaller Steps - First Sketch | #129
Many More Much Smaller Steps - First Sketch | #129
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! --
07:53
September 28, 2021
Ten I-Statements About Refactoring | #128
Ten I-Statements About Refactoring | #128
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! --
08:26
August 17, 2021
Get Stronger With Geek's Night Out | #127
Get Stronger With Geek's Night Out | #127
Programmers will ask me how they can become stronger at programming. A very good way, one I use currently, is to get together once a week with a handful of geek friends of varying talents, interests, and projects, for a casual geekery-sharing session. -- 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! --
06:24
August 10, 2021
Ten I-Statements About TDD | #126
Ten I-Statements About TDD | #126
Folks, I see a lot of ideas and opinions about TDD fly around, passed off as holy writ. By way of counter, I offer you Ten I-Statements About TDD. -- 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! --
06:56
August 03, 2021
On (Not) Using Mocking Frameworks | #125
On (Not) Using Mocking Frameworks | #125
Coaching Pro-Tip: Don't fall -- or get pushed -- into the trap of being responsible for a team's targets. Your mission as a coach is to care for the health of your team, it's not to hit a deadline. -- 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! --
06:24
July 13, 2021
Three Short Coaching Pro-Tips | #124
Three Short Coaching Pro-Tips | #124
Coaching Pro-Tip #1: Everything good about agility is rooted in relationship, so everything good about coaching is, too. As coaches, we usually start from negative trust, and our central priority has to be reversing that position. Coaching Pro-Tip #2: When the developers act like testing the code is a time-wasting checkbox that costs a great deal and rewards very little, they are usually right, and one has to find out why, and tackle that, before pressing them to test more. Coaching Pro-Tip: Sometimes it's just chemistry. One advanced coaching skill is understanding when you're not some team's cup of tea, and seeing when the right thing to do is help them find someone they can relate to. -- 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! --
10:17
July 06, 2021
Two Mantras, One Theme | #123
Two Mantras, One Theme | #123
Two recurring phrases in my work are 1) It is like this because we built it to be like this. 2) The code works for you, you don't work for the code. Two sides of one page, phrased on the front as negative critique, and on the verso as positive encouragement. -- 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! --
09:15
June 15, 2021
Path-Focused Design | #122
Path-Focused Design | #122
"Path-focused design", of stories, architecture, code, is design that understands that we can only reach a distant City on the Hill by taking one stride-limited shipping step at a 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! --
10:48
May 25, 2021
Big Batch Releases | #121
Big Batch Releases | #121
Big-batch releases, coordinated and controlled by a central intelligence, fail, and fail frequently. Several aspects of this are fascinating, because of the interplay of hard mathematical reality with human frailty. Let's take a swing. - 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!)
10:40
May 18, 2021
Sharing Configurations | #120
Sharing Configurations | #120
You can put all your configuration in a shared library and eliminate just about every mis-configuration in your multi-process application. It's not free, but it's cheap, and it kills a lot of minor pain. Let's take a gander. 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!
07:04
May 11, 2021
Re-Orienting Around Backsteps | #119
Re-Orienting Around Backsteps | #119
When large teams struggle with trunk-based development (TBD) or continuous integration/deployment (CI/CD), a good strategy is to re-orient how the teams face "backsteps", moments in our workflow where a discovery forces us to re-open a stage we thought was closed. Large teams & projects often pre-date the use of modern synthesis techniques like TBD or CD, and during adoption, intermixing their Before with this new After can produce quite a bit of discomfort. If it gets bad enough, it can even kill off the improvement effort. What to do?  --- 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.
09:32
May 04, 2021
On Agile Methods | #118
On Agile Methods | #118
A couple of days back, I tweeted about SAFe. It created some stir on the timeline, which was great, as I got to see a lot of perspectives. I want to use that tweet as an excuse to talk about something much larger. This will be a long one. :)  --- 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.
10:14
April 27, 2021
Standup Braindump | #117
Standup Braindump | #117
The standup is a short recurring meeting used to (re-)focus the team-mind on effectively moving stories through our workflow. Here's my recommended approach to having standups be useful and brief. The general sequence is 1) address team-wide emergency issues, 2) work story-by-story, 3) distribute new work, 4) address team-wide non-emergency issues. Note that, quite often, there is no part 1, and no part 4. Sometimes there's not even a part 3. Some general tips, then: --- 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.
05:56
April 20, 2021
The UI Monolith Making App | #116
The UI Monolith Making App | #116
The ultimate making app for a shipping multi-service system is actually a one-machine monolith with a UI. If your team is experiencing the most common pains from working in a large SOA environment, the productivity payback will be enormous. We've talked a lot about the idea of having a shipping app for our customers and a making app for us. We can use the same source base to make multiple binaries. We target customer needs with one of those, and we target developer needs with the rest. The economics of this approach are straightforward: As long as a making app's benefit — improved productivity on the shipping app — is less than its cost — the time spent working on something we don’t ship — we get a net gain in productivity. --- 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.
10:45
April 13, 2021
Rice & Garlic & More Smaller Steps | #115
Rice & Garlic & More Smaller Steps | #115
My rice'n'garlic advice, "take many more much smaller steps," can be said another way: reject any proposed path that requires a step size larger than the limit you've set for that particular domain of activity. "Rice'n'garlic advice" is blind advice, for when people ask you what to do, but you're not there & can't see. You have to guess. A professional chef I know, when asked to give blind advice, always says this: 1) That's too much rice. 2) That's not enough garlic. This kind of advice isn't expressing a universal law. (It is difficult to do, but you *can* have too much garlic, after all.) Nevertheless, for most people doing the asking, most of the time, that's a pretty good hipshot, applicable to most of her actual audience. My blind advice, in that same spirit, is this: Take many more much smaller steps. It's not a universal law. It's just a shot from the hip, and I find it's generally good advice, for most of the people asking, most of the time. Here's how it works. --- 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.
08:29
April 06, 2021
A Making-App UI | #114
A Making-App UI | #114
Once armed with the idea of a shipping app and a making app, a whole range of possibilities open up. Among the most powerful: give your making app a UI just for making. A "making app" is when we take the same sourcecode from the program we're shipping, and use it for another program at the same time. That program is one we develop and tailor expressly to enable us to work more effectively on the shipping app. We tend to overlook it, but when we run our unit tests, for instance, we're actually running a making app. Whole great swathes of the code are exactly the same code we ship, just put together in a different way. But there's no reason to have just one making app, and no reason to limit its capability to only running our microtests. We can do all sorts of cool things in a making app. --- 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.
08:45
March 30, 2021
Scenario Builders | #113
Scenario Builders | #113
In a data-rich environment, we can use the Builder concept to make DSL's for our Making application. This often makes testing the hard business core of our code both faster and easier. We've spoken in the past about using our codebase to do more than one thing. We always use it to create our shipping app. But we can and do use it for an app that improves our *making* process. We call that the making app. When you're running your microtests, it doesn't necessarily look or feel like you're running an app, but you are. And that app uses much of the same source-code that what you ship does. It just uses it in a very different way. Some applications manipulate a whole lot of intricately connected data. In the world of healthcare, for instance, an app might have literally dozens of classes, all rooted to and connected with a Patient. And the business logic is quite thick, with many cases and variants. --- 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.
07:57
March 23, 2021
Humans & Mistakes | #112
Humans & Mistakes | #112
Approaches in software development -- or anything else -- that don't take ordinray human failings as their starting point are prone to dramatic failure. "The Impossible Human" is, well, noticeably uncommon. Let's dig in on that. Some years back, I made content for a CMS that had a whole lot of overlapping parts, each with its own special language. I found it very difficult to express myself quickly & cleanly, and, it being me, I complained about it a lot. And very often, the responses I received were in the form of "It's easy, just remember X." It still being me, I became sullen and resentful, and was largely unproductive for long stretches. "It's easy, just remember these 371 simple rules" is a formula for disaster, because it's an approach based on "The Impossible Human". Ordinary humans don't remember 371 simple rules about anything they haven't already mastered. --- 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.
07:45
March 11, 2021
Web-To-Database Potshots | #111
Web-To-Database Potshots | #111
"It puts the database on its browser skin, or else it gets the hose again." This task occupies the daily life of a great many programmers. Today, I want to throw out some random sparks of advice for people working in that setting. In enterprise IT, it is commonplace for backend folks to work on problems shaped like this: there's a web endpoint controller on the top, a database on the bottom, and some simple or complicated business logic in the middle. I watch people working in this kind of environment quite a bit, and I have to tell you, most of what I see is them having a lousy time doing boring work in a tedious and time-consuming fashion. These ideas I want to toss at you are something of a grab-bag. They're just little seeds, not worked out answers, but my goal in offering them is to jiggle a mind or two: to get folks thinking about how they could do this kind of work in a way that *wasn't* a boring drag. And I spoze that's the meta-seed: "You don't have to live like this." --- 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.
09:06
March 03, 2021
An Early TDD Experience | #110
An Early TDD Experience | #110
When we talk about transitioning to microtest TDD, we have to figure out how to provide the right experiences in the right order. That's why I propose we start by getting the experience of changing a well-microtested graceful class. "Create Experiences, Not Arguments" is one of the core habits of change-harvesters. We want to take that slogan very seriously when we approach any significant change to our practice. And microtest TDD, believe me, is a significant change. A would-be TDD coach or instructor nearly always carries an implicit belief that her victims do not have, drawn from lived experience that they don't have. It is this: "What we are doing now is much more unpleasant and unproductive than what we'll be doing when we TDD." --- 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.
08:10
February 23, 2021
Technique & Transition | #109
Technique & Transition | #109
Microtest TDD is a "way of coding", not an after-market bolt-on to old-school approaches, and as a result, we have to constantly intertwine our conversation about technique with our conversation about transition. Technique, skills, philosophy, theory, all of these are tremendous delights to me. I love to muse & mull & illustrate & analyze & argue & point, and I greatly enjoy doing it on the topic of the modern synthesis in software development. But all of this explication & analysis is about a framework of related ideas. And that body of knowledge is a "there", a point on the time horizon we can orient towards. We, the trade, well, we're "here". How do we move from here to there? Because it doesn't matter what color the walls are painted in the City on the Hill if we can't find a path that takes us toward it. --- 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.
07:57
February 16, 2021
Awkward & Graceful | #108
Awkward & Graceful | #108
In microtest TDD, we describe collaborations as "awkward" or "graceful". The distinction is critical to understanding how the Steering premise and the Pieces premise work together to make TDD a productivity tool. Let's dig in. We talked the other day about understanding & manipulating dependency in microtest TDD. The awkward/graceful distinction is at the heart of this. It can be a long journey to get it all, but it *starts* as soon as you take TDD for a spin in your day job. To get into this, let's take two classes most of us are familiar with: String and File. (I'm thinking in Java, but I suspect much of what we see will apply in most languages.) String is graceful. File is awkward. Let's see what that means. --- 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.
08:20
February 12, 2021
TDD's Goldilocks Challenge | #107
TDD's Goldilocks Challenge | #107
Successful microtest TDD depends on our ability to solve a goldilocks challenge: when we test our code pieces, do we isolate them too much, too little, or just right? Finding the sweet spot will mean letting go of rulesets & purity. The five premises we've been over: value, judgment, correlation, steering, and pieces, guide us in a complicated dance of software design. At the center of that dance is our awareness of -- and our manipulation of -- "dependency", how one part of the code uses other parts of it. From the moment you wrote your first program, you produced a high-structure high-detail text that *depends* on the output of other high-structure high-detail text. --- 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.
08:34
February 09, 2021
Learning TDD w/ Four Mentors | #106
Learning TDD w/ Four Mentors | #106
Because microtest TDD is more a "way of geeking" than a technique or a received body of knowledge, building one's faculties is a long and sometimes perilous effort. Let's talk about learning. I want to approach the question(s) of learning TDD in some ways that are a little different from others I've seen. I've written two TDD curricula myself, and am involved currently in helping with two more. I see all of them, including the current ones, as "interesting failures". At first, learning/teaching TDD seems like a road, then over time it seems to become a tree, and ultimately it feels much more like a spreading activation network, including lots of external triggers, plateau periods, and transformative experiences. (I'm open to the possibility that this is what *any* judgment-centric skill looks like, but for now I just want to talk about TDD.) --- 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.
10:42
February 05, 2021
TDD As Change Strategy | #105
TDD As Change Strategy | #105
Microtest TDD is an effective change strategy because it dramatically improves our performance at comprehension, confirmation, and regression detection, all critical factors in handling change quickly & safely. We've covered a lot of ground in considering TDD recently. The five premises, the need for a change strategy, the increasing collaboration, complication, and continuity of modern software, and some high-level less-obvious aspects of the practice itself. I want to put some of these pieces together, and show you how TDD adds up to an effective change strategy. It doesn't "boil down" very well: as with most conversations around complex systems, the effect is multi-sourced and multi-layered. This may take us a little while. :) --- 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.
08:50
February 02, 2021
On Political Content | #104
On Political Content | #104
I got one of those messages I sometimes get from a reader, telling me that including my politics in my muses/blogs is off-putting. As a general rule, I don't bother to respond to these. I gain and lose followers all the time, everyoen who makes content does, for all sorts of reasons, and that's just one more. Today, though, surrounded by all of this, I feel like I want to give a more full statement on the matter. --- 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.
04:18
January 29, 2021
Aspects of TDD Practice | #103
Aspects of TDD Practice | #103
Before we can make the case that microtest TDD is an effective change strategy, there's a few high-level aspects of it that we need to highlight. We tend to take these for granted in our case, but newcomers won't already know them. Today, I'm writing for the newcomer. It's going to be a little rambly, because the ideas aren't partitioning a single conceptual level into its component parts. Think of me as going over a text with a yellow highlighter, bringing out some points newcomers might not readily see. Twinning: When we do TDD, we are working in a single textual codebase that we use to produce two entirely separate applications, each serving a different purpose. The one app will be the one we ship. The other app will be a primary tool for producing the first app more quickly. --- 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.
08:59
January 26, 2021
Why Have a Change Strategy? | #102
Why Have a Change Strategy? | #102
Microtest Test-Driven Development is a strategy for *change*. To understand the case, we need to answer two questions: 1) Why have a strategy for change? 2) How does TDD provide one? Let's take up the first question today. Why is having a change strategy so urgent? The TL;DR is dead simple: Because continuous ongoing change is at the base of all software development, both before and after our software is in the field. --- 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.
07:60
January 22, 2021
The Value Premise | #101
The Value Premise | #101
Today it's microtest TDD's Value Premise: TDD ships more value faster when that value depends on changing our branching logic safely & quickly. Let's dig in. I am frequently presented with declarations that TDD is fine for plebs like me, but useless for software of type X. I've heard every variety of app type or coding specialty or domain substituted for that X. In other parts of the forest, I hear that the purpose of TDD is high quality, and if you don't care about that, you don't need TDD. Or that it's for satisfying personal or professional ethics, and if you don't care about that you don't need TDD and you're a bad person. The Value premise says that TDD is an instrument for productivity, and its effectiveness depends on how much of our work requires us to change our branching logic, which it lets us do with greater speed and lower risk than non-TDD methods. --- 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.
09:10
January 19, 2021
The Correlation Premise | #100
The Correlation Premise | #100
Today, let’s take on microtest TDD’s Correlation Premise: Internal software quality (ISQ) and productivity are directly correlated. They go up together, and they go down together. The correlation premise lies in direct opposition to the widespread but grossly over-simple analysis that suggests we can “go faster” by shorting the internal quality of our code. It says, on the contrary, the lower that internal quality, the lower our productivity. Start by noting that we’re talking about internal software quality (ISQ), not external software quality (ESQ). What’s the difference? ISQ is the attributes of the program that we can only see when we have the code in front of us. ESQ is those attributes a user of the program can see. --- 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.
06:52
December 25, 2020
The Judgment Premise | #99
The Judgment Premise | #99
Today, let’s talk about microtest TDD’s Judgment Premise: “We are absolutely and permanently reliant on individual humans using their individual judgment in TDD.” The judgment premise emphasizes the human in test-driven development. There are no known non-humans practicing TDD, so it may seem a odd that we have to talk about this, and yet, we do. As software geeks, we work with the most rigid deterministic systems conceivable, and we do much of that work in abstract mental space. To say that our target systems are machine-like is to say too little, really: they’re more machine-like than any real-world machine. The uber-mechanical material of our job can lead us to seeing every aspect of the job as if it were the same as that material, a phenomenon the French call “deformation professionelle”. Put simply: working with uber-machines all day, we imagine uber-machines everywhere. --- 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.
05:26
December 22, 2020
The Steering Premise | #98
The Steering Premise | #98
Microtest TDD's Steering Premise is quite simple, which may be why it sometimes meets furious opposition. It says "Tests and testability are first-class citizens in design." Let's talk that over a little. There are, for any software problem, an infinite number of functionally correct designs. If implemented, they will work. But we don't *implement* an infinite number of designs. Why not? Because though they may be functionally correct, they still don't fit our context. We reject designs -- more often we reject individual choices in designs -- for a variety of reasons: reliability, cost of hardware, poor fit to our toolset, and so on. Those reasons are the "citizens" of the design process. And the steering premise says that one of the citizens -- not a secondary or minor or ex post facto consideration -- is whether that design can be tested. To probe at it: If you brought us a functionally correct design that required our app to run on a million AWS instances, we'd casually say "no, that's not valid." So obvious is this conclusion, that no one ever does it. Designs don't even get that far with such an issue. --- 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.
06:26
December 11, 2020
The Pieces Premise | #97
The Pieces Premise | #97
The Pieces Premise says, "To get the whole thing to do what you want, start by getting each piece of it to do what you want. It's one of the basic underpinning of microtest TDD. The idea behind the pieces premise is actually pretty straightforward. All programs are divided into pieces, separate parts, each of which performs some behavior the program needs. If the pieces don't work, the whole won't work. I have seen a lot of struggling TDD efforts in my time. A great many of them start off well and end poorly, and it's very often because the Pieces Premise is not sufficiently understood by the would-be practitioners. Imagine a class. (Or a function, or a subroutine, or a module, or whatever level of decomposition you use in your environment.) Let's call it S, for "Simple". Its guts use only basic logic and primitives from your language. Classes like this are what we start nearly all first-time TDD'ers on. You write a test, you make it pass, you design it optimally. Rinse, lather, repeat. And when you do this, I'll be damned, you find that TDD is pretty cool. --- 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.
08:07
December 08, 2020
Collaboration, Complication, Continuity | #96
Collaboration, Complication, Continuity | #96
I was recently asked, by two different groups, two seemingly different questions, but I gave them both the same answer: Collaboration, Complication, and Continuity. Let's mull that situation over. I spoke at a user group recently, on their choice of topic. They, ever so gently, pointed out that I'm old as dirt and have been a geek for forty years. And their question was how has programming changed since the caveman days of the '80s? In another part of the forest, I gave a university lecture last month, and because I was the industry expert, one of the speaking prompts they gave me was, my words not theirs: "What's the difference between the pro game and the college game in the sport of geekery?" Maybe to you those two questions seem obviously "the same", but to me they seemed very different. After all, I didn't start out in geekery as a college student, but as a (weak but enthusiastic) pro. I didn't graduate from college, and in any case didn't study programming there. --- 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.
07:22
December 01, 2020
Old Coach at the End of the Bar | #95
Old Coach at the End of the Bar | #95
I am supposed to be shooting the next Real Programmer episode today, but I had a really good wrap-up meeting that was important, and I'm waiting for one more piece I need to send a first invoice to a new client, and I want to talk about coaching. In another part of the forest, some folks are discussing the frustrations of what is, by whatever name we call it, coaching. And the long and the short of it is "they won't even try what I want them to do". These sorts of conversations are pretty much standard "coaches-at-the-bar" talk. After all, getting people to try things we want them to is pretty much the job. All jobs are like this. I can't imagine what my doctors, quaffing an icy one after work, say about *me*, for instance. "This idiot spends his entire adult life ignoring every aspect of his body's needs, and he won't even *try* taking a fifteen-minute walk every day. Now he whines at me all the time cuz his back hurts!" And so but anyway, you know what? Today, I'm that old doctor who sits down at the far end of the bar, sipping his scotch, watching Jeopardy, and occasionally throwing out some snarly annoying meta-commentary. --- 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.
05:03
November 27, 2020
Change Harvesters Iterate Change | #94
Change Harvesters Iterate Change | #94
Human, local, oriented, taken, and iterative, these are the change-harvester's bywords. In iterative change, we not only accept the reality of gradual stepwise refinement -- changing what we've already changed before -- we actually anticipate it and take advantage of it. With iteration, I think a great starting point for the concept is to watch just about any youtube video where a skilled artist draws a realistic rendering. What you will see almost inevitably is a direct implementation of iterative change. The strokes begin quite broadly, faintly indicating the broad contours of the subject. Experience is relevant here: those who are most familiar with drawing that particular kind of subject, will make contours that seem "right" more quickly than those less experienced. --- 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.
08:48
November 24, 2020
Change Harvesters Take Change | #93
Change Harvesters Take Change | #93
In change-harvesting, we use this word "taken" in multiple senses, but to put it in a single sentence: the change-harvester takes both the substance of and the approach to change from what is already there. We *take* our changes from here, we don't *give* our changes to there. To go from A to B, it is easy to focus all of our attention on B. The change-harvester is saying we can't make effective changes unless we see them as *changes*, as transformations to A. And that implies paying a great deal of attention to what that A is and how it works now. Although "taken" may seem a little shaded or obscure, it's actually at the very center of what it means to change a thing, as opposed to building one. We've touched many times on the difference between greenfield & brownfield. With taken change we see that difference in action. --- 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.
07:18
September 25, 2020
Change Harvesters Orient Their Changes | #92
Change Harvesters Orient Their Changes | #92
Locality drives us to steps that are nearby, within our ready grasp, & therefore inherently small. But our *vision* isn't small, our program isn't, it's quite large. We can't get to it in one local step. How do we reconcile this? Oriented, taken, & iterative, each have an angle. Oriented is as simple as this: After every local step, we take a second and simply turn our selves back towards our distant target before we choose or take the next step. Humans are actually quite good at this. You do it when you cross a busy road. There, it happens so quickly you hardly notice it. More consciously, you do it when you navigate to your vacation or tourism spot. Take a step, face the landmark, take a step, face the landmark. --- 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.
08:20
September 22, 2020
Change Harvesting Makes Local Changes | #91
Change Harvesting Makes Local Changes | #91
We change-harvesters say human, local, oriented, taken, and iterative. We talked about human a couple of day ago, let's take on local. A quick sketch of the idea, and a couple of cases will do, yeah? When we say that we want our changes to be "local", what do we mean? I think in terms of two nearby metaphors, "neighborhood" and "reach". We want our changes to be in the neighborhood, and we want them to be in easy reach. Of course, "small" comes to mind right away, but it has its problems, most notably that it almost immediately prompts one to think of numbers, which tends to fire us off into a numbers game that distracts from the fluidity and flex of the idea. The contrasting approach to local is global. Remember the early eco slogan, "think globally, act locally"? That notion of locality is what we're aiming at. (When we get to oriented change, we'll see the other half in action, too.) --- 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.
08:33
September 18, 2020
Change Harvesting Emphasizes The Human | #90
Change Harvesting Emphasizes The Human | #90
Human, local, oriented, taken, and iterative: this is how change-harvesting in software development approaches change in most contexts in the trade. Let's take "human" today, and see where it leads us. When we use that word "human", change-harvesters are getting at the fact that, in systems involving humans, machines, and procedures, the humans are the most powerful force. When we seek change while ignoring human factors, we go awry quite rapidly. Human emphasis, in this usage, opposes both procedural and mechanical emphases. A common form of the problem is to implement a system using simple logic and uni-directional causality, abstracting away the complexity and sophistication of how humans actually perform at their best. --- 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.
07:06
September 15, 2020
The Cost of Rework Avoidance Theory | #89
The Cost of Rework Avoidance Theory | #89
To make the case for Change Harvesting as an approach, it's important to understand that the cost of Rework Avoidance Theory isn't imaginary or subtle, but both concrete & quite high. The most essential aspect of the RAT (Rework Avoidance Theory) is its emphasis on the endpoint: the City On The Hill we call it. The central concept: define the City rigorously, optimize building it off-line, move in to it only when it's done, and never change it again. In the RAT's idea of efficiency, changing a thing is waste. After all, why did we build it all if we're just going to turn around and change it to get to the City on the Hill? Why not just build it that way to begin with? This idea, that change is bad, that we should avoid having to change our systems, absolutely permeates the culture of software development, to the point where it is less an intellectual construct and more of a gut-level instinct. The RAT seems to actually *fear* change. --- 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.
08:03
September 11, 2020
CHT Means Different Design Imperatives | #88
CHT Means Different Design Imperatives | #88
Change-harvesting software design centers "online" brownfield development: change-centric thinking. Most older sets of design imperatives are based in "offline" greenfield development: build-centric thinking. The differences can -- and should -- lead to design disagreements. The significance of "online brownfield" vs "offline greenfield" is hard to overstate, in all areas of software development, but especially so when we talk about what makes a design "good" or "bad". In four decades, I've read countless books about software design. I've had my favorites, and I'm sure you've had yours. Some of my favorites really don't stand the test of time, of course, they were just "right time right place" for me to absorb their ideas and put them into play. The majority of these books present examples and arguments from a standing start, a blank page, a green field. The author presents a "design problem", more or less rigorously, then shows one or more solutions to it. --- 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.
08:35
September 08, 2020
Human-less Change Fails | #87
Human-less Change Fails | #87
A lot of the reasons that change fails, inside & outside technical organizations, come down to one broad statement: the people who have to make the changes are humans, and the people who want them to make the changes have not successfully taken this into account. People ask me why the change they're trying to make doesn't happen. The questions come from all levels of an org, from the very top to the very bottom. "Why won't they change?" It's often accompanied by an implicit theory. It's often aimed at me because I have had some success. I should say: being a successful change-enabler doesn't mean batting 1.000 anymore than being a successful batter does. .300 is damned good. It means one fails 70% of the time. Making sticky change looks a lot easier than it is, *especially* when the looker ignores humanness. Here's the thing: whatever brilliant new arrangement I have in mind, I am very rarely the one who's going to have to make it. (Sometimes, I'm *one* of the ones who'll have to make it, but that's not quite the same thing.) Who makes it? The humans do. --- 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.
06:24
September 04, 2020
CHT-Style Implementation | #86
CHT-Style Implementation | #86
When we did our compare & contrast of the working models underpinned by Change-Harvesting theory (CHT) vs Rework Avoidance Theory (RAT), we temporarily sidestepped the specific differences of the implementation part. Let’s drill in on that today. It was quite a sidestep: other than the implementation part of the two models, they have much in common, with the key difference being the highly iterative nature of CHT’s approach. If we squint a little, & we don’t talk implementation, we can see the CHT model as being a daisy-chain of RATs. Each step is a “mini-RAT”, on a scale of a couple of team-days each. But that’s only if we ignore implementation differences. And they’re too big to ignore. In fact, I’ll venture out on a limb a little: ignoring the tremendous difference between RAT implementations & CHT implementations amounts to the second-biggest reason most “agile transformations” fail to bring actual improvements. --- 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.
08:58
September 01, 2020
Change Harvesting vs Rework Avoidance | #85
Change Harvesting vs Rework Avoidance | #85
Let's compare and contrast the RAT (Rework Avoidance Theory) model of software development with the CHT (Change Harvester Theory) model. The differences are multiple and pronounced, so this may take us a while. I want to talk not so much about the theories today, as about the working models they underpin and lead to. Those models are a kind of inner core of making software, shaping our activities of course, but also our solutions, and even the problems. The RAT model sees software development as an off-line program-construction activity composed of these parts: defining, decomposing, estimating, implementing, assembling, and finishing. We'll get to the parts in a second, but the CHT model's lead-in statement is already markedly different. The CHT model sees software development as an interactive and on-line program-alteration activity. --- 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.
09:05
August 28, 2020
Iterative User Value in Flows | #84
Iterative User Value in Flows | #84
A flow app, one that steps the user through an acyclic graph, typically gathering info at each stage, can be built to provide iterative user value by gradual refinement. Let's look at how that's done. The standard flow app is when we walk the user through a complex operation, and we gather the pieces step by step. Though it looks like a straight line to any given user, the answers in previous steps actually shape the following steps, hence the directed graph under the hood. In most web environments, flows are page-to-page. In desktop apps, they're set up like wizards. It doesn't matter, the key is that we're stepping the user down a single path in the directed graph. They neither know nor care whether there are other nodes that don't concern them. I start by identifying my "cop-out". --- 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.
06:11
August 25, 2020
The Correlation Principle | #83
The Correlation Principle | #83
The correlation principle says that our productivity is tightly correlated with the internal quality of software. The two go up together, and they go down together, and you can't trade away the one to get more of the other. The basic idea of the correlation premise is actually pretty simple, but when we introduce it, we generally get a chorus of yabbits. ("Yeah, but...") There are several confusions common to most of that chorus, so let's look at them one at a time. Confusion: mixing up internal software quality and external software quality. The yabbit takes this form: "Yeah, but we can get it done faster if we settle for it working less well." See, here's the thing: that's generally true. We *can* deliver more quickly by settling for a lower level of value. The trick is to understand the yabbit as being about *external* software quality, not *internal* software quality. --- 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.
10:41
August 21, 2020
Iterative User Value | #82
Iterative User Value | #82
How do we iterate user value? How can we follow the "more smaller steps" approach and still deliver a positive experience for the user? Today let's look at some ways to approach this problem. The problem. We want our work to come in stories of about one team-day and a half, but that's not much time, and we need to provide a steady flow of value to our users. The truth is, most of us have been trained away from even *trying* to do this. It's no wonder it's not obvious how to do it now. I want to throw out some avenues for your consideration. Some of these you'll already know about, or we've already talked about, others, not so much. First, two strategies that are outside the scope of this conversation, but are critical to getting the ball rolling: 1) fat-trimming in the first place, and 2) resisting the RAT (rework avoidance theory). --- 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.
09:01
August 18, 2020
Pathing: A Style of Laying Out Work | #81
Pathing: A Style of Laying Out Work | #81
I do “pathing” when I project my work into the future: laying out a sequence of work steps, where each step ends with the code in a shippable state. More than design, and more than planning, pathing is a kind of work-style, and it brings me several benefits. When we're pathing, we're really just decomposing a problem, breaking it into several smaller problems. What makes me call it pathing -- instead of design or planning -- are two requirements we want each sub-problem to meet before we're satisfied with it: size and shippability. I use the pathing workstyle most frequently in two related but different tasks: in close-up coding at the keyboard, and in near-term feature layout around the meeting room. These are different scales, with different sizes that will satisfy, but shippability is the same in both. --- 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.
07:13
August 14, 2020
Embrace Change: Modern Geekery Practices | #80
Embrace Change: Modern Geekery Practices | #80
We *change* software, therefore we want everything around us to support that: code, technique, tools, controls, tracking, planning, infrastructure, and above all, culture. The last two decades have added a broad assortment of change-enabling elements to the trade. To get an idea of this breadth, let's do a little enumeration. Change, how do we embrace thee? Let me count (some of) the ways...Three broad features will emerge, so I'm going to call them out now before we get to details. These are a very much heightened focus on collaboration, iteration, and confirmation. They work together and separately to underpin many of the actual techniques & patterns we advocate. --- 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.
08:43
August 11, 2020
Pedagogy In The Trade: Changing Emphasis | #79
Pedagogy In The Trade: Changing Emphasis | #79
I want to start talking about teaching in the geek trades. Today in particular, I want to talk about "emphasis", what our style & materials stresses or underlines about the path to mastery for our up and coming geeks. I am by nature an analyst, a theorist, and a person driven to critique. That makes me pretty negative-seeming at times. That's not accidental. I find that I often can't find a way forward until I have thoroughly identified what I don't like about where I am now. Of course, while one does this, one also shares it, often enough in snarky asides. I recently tossed one out about the damage done by crummy pedagogy. It was with respect to TDD, but that's irrelevant. I actually feel the same way about most of our teaching in the trade. A respondent asked me to say more about how we could change -- for the better --professional teaching and learning in the trade. This is my first swing at a more positive response. --- 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.
09:18
August 07, 2020
Retrospectives: Variety Is Key | #78
Retrospectives: Variety Is Key | #78
I strongly recommend high variation in both format and facilitator of retrospectives. So let me sketch, as quickly as possible, the retro-scheme I see the most of, and don’t care for. It’s got four columns. "Didn’t go well". "Went Well", "Action Items", "Kudos". Sometimes they change the text of the columns. One person, the same person each time, leads the meeting, by gathering stickies, virtual or otherwise, and plunking them on a board in the right column. That person typically groups the ones that seem closely related. Now we "process" them. This involves reading them each out loud, looking around the room, sometimes identifying the author and asking them what they meant. We get a chorus of "yes" or a cluster of "no", sometimes a little discussion. Very occasionally, an active disagreement. --- 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.
08:51
August 04, 2020
TDD Tests Are First-Class Code | #77
TDD Tests Are First-Class Code | #77
My standards for TDD microtests are the same standards I have for shipping code, and I follow them in microtests for the same reason I follow them in shipping code: they make me faster. I go out in the field, and I inspect a lot of tests, and I have to say, lousy factoring, bad naming, massive duplication, and low signal-to-noise are pretty much the order of the day out there. This often holds true even when the shipping code is comparatively well made. I suspect a lot of this comes from the "chore" outlook that's so prevalent around tests. That's heightened, of course, by the tendency of orgs to try to get to TDD by fiat. I am sympathetic to all persons everywhere who don't perform well when they're voluntold to do chores. --- 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.
09:51
July 31, 2020
Re-Balancing Made, Making, and Makers | #76
Re-Balancing Made, Making, and Makers | #76
Some years back I realized my most beloved parts of our software movement could be characterized as re-balancing our approach towards the triad of Made, Makers, and Making, and away from a prior focus only on the Made. Let's schmooze about this. First of all, what do I even mean, about this adjustment of focus? For easy writing and reading, I'll treat this as a Before & After thing, even tho I know full well that's a fiction, for two reasons. First, although "Agile" is the buzzword of the decade, it's still not a majority or even plurality in market share. That is, a great many orgs haven't even tried to step into this After. Second, *because* "Agile" is the buzzword of the decade, a great many orgs claim "Agile" with very little of actual agility in their world. "Agile" has succeeded modestly by becoming, in many cases, a silly re-naming effort rather than an actual embrace of change. But I'm sticking with Before/After, tho it's fictional, just to try to lay out what I'm talking about at all. --- 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.
09:10
July 28, 2020
Microtest TDD is Gray-Box | #75
Microtest TDD is Gray-Box | #75
In the '70's, an important movement developed in testing theory, called "black box" testing. The idea is straightforward: We can prove our software works by treating it as a closed opaque container with only some knobs and meters on the front of it, a "black box". The tests we write don't know what 's inside the box, they only know the specification of how the surface controls are supposed to work. If they don't work tht way it's a fail, if they do work that way it's a pass. This idea has great merit under certain circumstances. It also has a kind of intellectual simplicity and purity that is profoundly pleasing to both the theorist and the newcomer. "It's just that simple." It also received considerable backing from the sociotechnical circumstances surrounding it. It allows a division of labor, for instance: there are testers and there are developers, and never the twain shall meet. And at the time, it was also by and large *viable*. We could do it. --- 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.
10:51
July 24, 2020
Understanding Incremental Switchover | #74
Understanding Incremental Switchover | #74
The incremental switchover approach is my default response to any transformation problem I can't resolve in an hour. It's the secret to successful brownfield development, but it's not widely understood & used. Let's take some time to understand it. Incremental switchover might be called "the art of the path". At its simplest, given two points A, where we are, and Z, where we wish we were, incremental switchover concerns itself with B, C, D, and so on, the route we take. We talked about RAT a couple of days ago: Rework Avoidance Theory. RAT is also concerned with path, but it applies its logic to a series of simple premises that are not reliable at scale. Because its premises are so often invalid, so are its conclusions. --- 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.
10:15
July 21, 2020
The RAT: Rework Avoidance Theory | #73
The RAT: Rework Avoidance Theory | #73
Rework Avoidance Theory is a cluster of related ideas seeing a change as having a clear start-point & end-point and a straight & stable path between them. It draws its inspiration largely from logic based in relatively straightforward metaphors to the physical world. One metaphor is that of a footrace. The change is a well-marked track with one runner. It assumes 1) linear cost of step regardless of size, 2) stability and perfect knowledge of path and endpoints, and 3) indifference to post-footrace consequences. A second metaphor is that of seeing the change as a finished product, built in standard parts by isolated individuals, assembled at the end. It makes similar assumptions to the footrace idea, but also assumes free cost of parallelism and high bonuses from specialization. --- 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.
08:56
July 17, 2020
Turning Implicit into Explicit | #72
Turning Implicit into Explicit | #72
An implicit understanding is anything a skilled geek would have to be told before being set loose in your codebase to make a change. Implicit understandings take lots of different forms, but at their simplest, they often involve hidden correlations. Probably the most common form of implicit understanding is related to the smell we call primitive obsession. You'll see a series of methods, and each method takes the same three arguments, an int for the ID, a string for the descriptor, and a decimal for the amount, let's say. Those three arguments are actually correlated: together, they uniquely identify a line item on an invoice. But there's no "LineItem" thing. Instead, we just pass and pass and pass those three arguments. *We* know they're correlated, but the code doesn't *say* they're correlated. The fix here is pretty straightforward: Make a LineItem, and pass those instead. Now, my senior geek doesn't need to be told about that correlation, it's right there in the code. We have made our implicit understanding of the code into something direct and explicit. --- 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.
09:17
July 14, 2020
Model-View, The Desktop, and TDD | #71
Model-View, The Desktop, and TDD | #71
The basic idea behind all Model/View schemes, and there are several of them, is just this: draw a thick line between what your program does and how your program shows what it does. In other words, it's a compositional heuristic, guidance for how we break our problems into smaller problems. Give some objects/modules the responsibility for doing the work, and give other objects/modules the responsibility for showing the work. Tho it was originally conceived in the smalltalk world, there are many modern usages of the idea. Nearly all UI-centric frameworks take the Model/View split as their starting point. --- 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.
11:00
July 10, 2020
Helping Your Downstream Collaborators | #70
Helping Your Downstream Collaborators | #70
Let's talk about ways to make life easier for downstream developers, be they front-end or dependent back-end people. Whether you have a bunch of front-end folks driven from your monolith, or you live in service-mesh land with dozens of microservices, the people downstream from you have to use your output to make their output. They are, in fact, a kind of customer. We've talked at some length about the Made, the Making, and the Makers, and how the trade is normally over-obsessed with the Made, and under-emphasizes both Making and Makers. Here are some ideas, no particular order, for ways we can make our small part of the system be useful not just to the end-user, but to the other makers. After all, tho they don't pay for the privilege, they are, per call, heavier users of our service than any others. --- 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.
08:14
July 07, 2020
Metrics and Three Traps | #69
Metrics and Three Traps | #69
In twenty years of coaching software development teams, I've seen maybe a hundred or more orgs try to figure out how to measure their process, and the majority of them have fallen into some mix of three traps: 1) the more trap, 2) the objectivity trap, 3) the rollup trap. Years ago I heard the non-standard saying that "the road to hell is lined with great parking spaces". I see these traps that way: they seem to suck us in more or less thoughtlessly, and once in them, we seem to fight noisily about decorating them, but never consider leaving 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.
06:30
July 03, 2020
The Right Step | #68
The Right Step | #68
A lot of folks spend a great deal of time arguing about which step is the right step. A change-harvester would say to stop worrying about this so much. The right step to take is 1) small, 2) not definitely backwards, and 3) not the last one. Let's take up "not the last one". A lot of thinking about change comes with the baked-in idea that there will be an end to it, a "finish line", if you will. We will make a change, or some changes, and in so doing we will cross a finish line, after which change stops. This finish-line metaphor -- I'm tempted to call it a theology -- provides a great deal of fuel to the "right step" arguments. It's so deeply embedded in our thinking it often goes quite unseen: it's a premise at the bottom of huge towers of reasoning. --- 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.
08:14
June 30, 2020
More on Small Steps | #67
More on Small Steps | #67
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.
06:30
June 26, 2020
Pull & Swarm | #66
Pull & Swarm | #66
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.
08:28
June 23, 2020
Microtest TDD: Economics | #65
Microtest TDD: Economics | #65
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.
08:04
June 19, 2020
Hitting On Speakers (Rant-y) | #64
Hitting On Speakers (Rant-y) | #64
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 must not do this. It is rude, unprofessional, and hurtful to many people. Stop it. --- 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.
06:31
June 16, 2020
Microtest TDD: More Definition | #63
Microtest TDD: More Definition | #63
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.
07:10
June 12, 2020
Microtest TDD: The Big Picture | #62
Microtest TDD: The Big Picture | #62
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.
05:40
June 09, 2020
The Jump To Microservices | #61
The Jump To Microservices | #61
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.
04:47
June 05, 2020
An Intro to Spikes | #60
An Intro to Spikes | #60
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.
09:30
June 02, 2020
Steps, Value, and Change-Harvesting | #59
Steps, Value, and Change-Harvesting | #59
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.
10:57
May 29, 2020
My Best Bug | #58
My Best Bug | #58
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.
06:35
May 26, 2020
Juniors & Seniors | #57
Juniors & Seniors | #57
Lotta inspiration for junior geeks stuff floating around. I'm having a low productivity day today because, well, you know all of that, so I'll take a minute nd pitch in. Do you know what I did for about twelve elapsed hours of coding time? I solved a problem. Cuz, you know, I got mad skillz, and have been geeking for forty years, and am even, in a couple of microdomains, a bona fide citable expert. I'll tell you the problem I solved, next tweet, but before we take the dive, I need you to just, relax, okay? Explaining this problem I solved might get a little heavy. I mean, for reals, yo, I'm a master geek and this took me twelve hours to solve, it's prolly gonna be daunting. --- 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.
07:04
May 22, 2020
Using the Strategy Pattern | #56
Using the Strategy Pattern | #56
The strategy pattern lets you make "pluggable algorithms", so clients have different behavior without having different code themselves. We often use it to capture the "consequence in code" of some condition, which we can then let other code use without re-testing the condition. Here's a little java snippet: dimension = horizontal ? width : height If you're not familiar with ternary operations, what this says is "if horizontal is true, use the width, otherwise use the height". That snippet occurs in the context of a SplitPane (from JavaFx). A SplitPane holds N other panes, and its job is to lay them out in a row (or column!) with a draggable divider between them. The user drags the divider, and the child panes resize accordingly. If you think about that job, you realize that all the layout math is basically identical for horizontal splitters or for vertical ones, with the only difference being whether its all based on the widths of things or all based on the heights of things.  --- 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.
09:57
May 19, 2020
Dealing with Nulls | #55
Dealing with Nulls | #55
Another refactoring topic today: dealing with nulls. There are a bunch of techniques, but they amount to a) don't, and b) do but only one time ever. The basic idea: a null always occurs in a particular context, and in that context, it has a meaning. When we pass it up or down our call-stack, we are *changing* contexts, and hence changing meanings. We're using the same symbol to mean different things at different times. Using the same generic symbol to mean different things in different contexts is anti-signal. It represents a loss of meaning.  --- 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.
09:49
May 15, 2020
Refactoring Strategy: Move It Where You Can Test It | #54
Refactoring Strategy: Move It Where You Can Test It | #54
When I can't test it where it is, I look to move it somewhere else, where I can test it. Today's notion isn't so much a single refactoring as it is a strategy that can be achieved in different ways (and different multiple steps). A modern and frequently occurring case: using a cool framework to expose service endpoints, we write a function and then we annotate it and poof, it's an endpoint. This is how Java+Swing works, or Python+Flask. When we give that function a body, it will be a body of "our branching logic" (OBL). We've already discussed that OBL is the main target of our tests, so we definitely want to test that function. Sadly, testing that usually involves one or more of three owwies. We'll have to either/or/and 1) fire up the app, 2) fire up the framework's test rig, 3) instantiate the class containing the method. Most of the time, none of these three choices is a fountain of geek joy. The problem, in all three choices, is in the weight of that framework. And it's not a problem that's avoidable: we chose that framework precisely cuz it does so much for us. Of course it's heavy. --- 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.
07:49
May 12, 2020
Refactoring: Invert Dependency With Observer | #53
Refactoring: Invert Dependency With Observer | #53
Another refactoring today: Use the observer pattern to invert an infelicitous dependency. In and of itself, this is a modest refactoring, but its smell often co-presents with others, and unravelling it all can be tricky. (Note: We aren't remotely done talking about first and second-order refactorings, there are plenty more to go. But I'm not writing a catalog, I'm working a project, so when a hefty one like this comes along, that's when I'm talking about it. You're gettin' em as I'm doin' em.) "Infelicitous dependency", eh? What could make a dependency an unhappy one? There are a lot of possibilities, but for me they usually amount to one of two cases: 1) an important abstraction is dependent on an unimportant detail, 2) it keeps me from writing a test I want to write. A concrete example might help, and I have just the infelicitous dependency we need for this, because it fits both bills, being both a "wrong direction" dependency and an inherently anti-testing class. Aren't we just terribly terribly lucky? --- 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 about GeePaw's Camerata.
10:45
May 08, 2020
Refactoring: Demeter-Wrapping | #52
Refactoring: Demeter-Wrapping | #52
Demeter violations are places where a client accesses not just an upstream service, but that service's upstream services, or even that service's service's upstream services. It's a common problem in evolving code, and left untended, a classic source of unchangeable code. Demeter calls look this: a.getB().getC().doSomething(). a is getting a B, but is using that B expressly to get a C, then finally calling some method on the C to do something. (The getX()'s could as easily be exposed fields rather than methods: depends on idiom & language.) I want to stave off some potential confusion. 1) You might be used to thinking that any chain of '.'s like these is just "fluent". 2) You might, alternatively, be thinking that any chain of '.'s like these is inherently evil. Neither of these assumptions is necessarily valid. --- 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 about GeePaw's Camerata.
07:37
May 05, 2020
Refactoring: Keep It Running | #51
Refactoring: Keep It Running | #51
A key value for those who take up the change-harvesting approach: "keep it running". This is actually a direct result of human, local, oriented, taken, iterative, and argues against many finish-line efficiency approaches. Think of a change as a point A, with an arrow coming out of it and ending at a point B. At the two points, we have a running system, but along the arrow, we don't: our change is in flight. The change-harvester seeks to keep those arrows as short as possible. I say seeks, but that's a little weak, actually: the change-harvester obsesses over the length of that arrow, and will do a whole lot of things to keep it short, including purposefully stepping away from an idealized straight line towards a target on the horizon. --- 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 about GeePaw's Camerata.
06:01
May 01, 2020
Chunking & Naming | #50
Chunking & Naming | #50
In our continuing conversation about refactoring, I want to go a little abstract today, and talk about chunking and naming. Naturally, a topic this important has already been addressed by a stupid joke in the movie Airplane!, so we'll start there. A passenger is approached by a steward, asking if he might be able to help with a problem in the cockpit. He says, "The cockpit! What is it?". She says, "It's the little room at the front of the plane where the pilots sit, but that's not important right now." The number of things one can hold in one's head at one time -- mental bandwidth -- is quite small. If the things are entirely unrelated to one another, it's on the order of 4-6 things. By contrast, the number of things one can need to hold in one's head at one time -- context bandwidth -- is ridiculously large. If the context is "reality", it's effectively infinite. But far smaller contexts than reality, everyday ones, still dwarf mental bandwidth.  --- 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 about GeePaw's Camerata.
07:58
April 28, 2020
Large-Scale Transformation and the Bias for Action | #49
Large-Scale Transformation and the Bias for Action | #49
Change-harvesting takes the stance that our most reliable strategy for change is a highly iterative process of act-look-think, in roughly equal proportions, repeated in small local cycles. We oppose that approach to look-think-act, emphasis on think, in large global cycles.  This opposition is, of course, not a philosophical light-switch, an all-or-none thing. If you abstract away the locality factor, a series of five a-t-l's looks like an a followed by a series of four t-l-a's, followed by a final t-l. :)  So the difference between these issues has to do with the locality and its implications and the relative proportions of the thinking, looking, and acting. The change-harvester wants maximum locality, and wants equal effort applied to the thinking, the looking, and the acting.  When we contrast the two approaches, the change-harvester and the more standard trade approach, we use one as the base and one as the difference, and this leads us to the language saying "bias for action".  Episode 49 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.
08:09
April 24, 2020
Large-Scale Refactorings | #48
Large-Scale Refactorings | #48
First things first, "large scale refactoring" is really a colloquial expression, a shorthand we sometimes use, but in my experience there is no such thing, for two reasons. The first reason is definitional. Remember, refactoring doesn't mean "changing my design", it means "changing my design without changing its function". We almost never do this at large scale.  The marvel and the horror of this trade is the extraordinary demand pressure it operates under. Anyone who's done time in the silicon mines knows this. It is the origin of nearly every bad process in the trade. "Takin' it off, here, boss!" says Cool Hand Luke. They pay us to change function. They don't pay us to change design, except in so much as it is required to transform function or to improve function-transformation process.  So from a practical perspective, it basically just doesn't happen. One doesn't get large blocks of time where one is only transforming design, not function. Episode 48 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.
09:10
April 21, 2020
Second-Order Refactoring: Narrow The Question | #47
Second-Order Refactoring: Narrow The Question | #47
Another small second-order refactoring for you today. I call it "narrow the question". 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.
05:32
April 17, 2020
Second-Order Refactoring: Swap Supplier and Supply | #46
Second-Order Refactoring: Swap Supplier and Supply | #46
As a hardcore user of TDD and refactoring, there are a number of what I think of as "second tier" refactorings that I use quite frequently. 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.
07:28
April 14, 2020
Working By Stories - A Change Harvester's Take | #45
Working By Stories - A Change Harvester's Take | #45
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.
10:36
April 10, 2020
Iterative Change - What and Why | #44
Iterative Change - What and Why | #44
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.
04:04
April 07, 2020
Taken Change - What and Why | #43
Taken Change - What and Why | #43
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.
06:40
April 03, 2020
Oriented Change - What and Why | #42
Oriented Change - What and Why | #42
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.
04:27
March 31, 2020
Local Change - What and Why | #41
Local Change - What and Why | #41
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.
05:21
March 27, 2020
Human Change - What and Why | #40
Human Change - What and Why | #40
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.
08:06
March 24, 2020
Multivalence for Change Harvesters | #39
Multivalence for Change Harvesters | #39
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.
05:57
March 21, 2020
Lining It Up That Way (Rant) | #38
Lining It Up That Way (Rant) | #38
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.
02:57
March 18, 2020
TDD On The Front End | #37
TDD On The Front End | #37
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.
12:46
March 10, 2020
The Change-Harvester's Value | #36
The Change-Harvester's Value | #36
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.
06:34
March 06, 2020
Readability and Scannability | #35
Readability and Scannability | #35
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.
08:20
March 03, 2020
My Direction Forward | #34
My Direction Forward | #34
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.
04:30
February 28, 2020
Kontentment and Human Arcs | #33
Kontentment and Human Arcs | #33
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.
08:56
February 25, 2020
Frames In The Software Trade: An Example | #32
Frames In The Software Trade: An Example | #32
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.
07:23
February 21, 2020
The Kontentment Project | #31
The Kontentment Project | #31
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.
06:51
February 18, 2020
The Cost of Changing Microtests | #30
The Cost of Changing Microtests | #30
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.
08:33
February 14, 2020
How I Work (Test-Driving Mix) | #29
How I Work (Test-Driving Mix) | #29
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.
11:05
February 11, 2020
Discipline: A Short Rant | #28
Discipline: A Short Rant | #28
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.
03:12
February 07, 2020
Programming Interviews For Dummies | #27
Programming Interviews For Dummies | #27
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.
06:39
February 04, 2020
Frames: Build, Race, and More | #26
Frames: Build, Race, and More | #26
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.
10:44
January 27, 2020
Change-Harvesting: The How | #25
Change-Harvesting: The How | #25
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.
08:44
January 22, 2020
Change-Harvesting and the Dynamic Unity | #24
Change-Harvesting and the Dynamic Unity | #24
"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.
06:40
January 18, 2020
RAMPS - Affecting Safety | #23
RAMPS - Affecting Safety | #23
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. 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? 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. 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.
10:24
January 13, 2020
The Camerata is Launched! | #22
The Camerata is Launched! | #22
"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.
04:08
January 05, 2020
If All You Have Is a Hammer | #21
If All You Have Is a Hammer | #21
"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.
09:20
December 30, 2019
RAMPS - S is for Safety | #20
RAMPS - S is for Safety | #20
"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.
05:14
December 23, 2019
How I Work - Preaching And Practicing | #19
How I Work - Preaching And Practicing | #19
"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.
07:00
December 17, 2019
RAMPS - Ways to Affect Purpose | #18
RAMPS - Ways to Affect Purpose | #18
"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.
08:20
December 11, 2019
RAMPS - Purpose is Service to a Greater | #17
RAMPS - Purpose is Service to a Greater | #17
"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.
06:43
December 07, 2019
RAMPS - Ways to Affect Mastery | #16
RAMPS - Ways to Affect Mastery | #16
"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.
10:47
December 04, 2019
RAMPS - Mastery is Opportunity to Grow | #15
RAMPS - Mastery is Opportunity to Grow | #15
"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.
06:01
December 03, 2019
RAMPS - Ways to Affect Autonomy | #14
RAMPS - Ways to Affect Autonomy | #14
"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.
08:30
November 30, 2019
How I Work - Just Programming Mix | #13
How I Work - Just Programming Mix | #13
"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.
11:28
November 28, 2019
RAMPS - Autonomy is Freedom to Move | #12
RAMPS - Autonomy is Freedom to Move | #12
"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.
06:22
November 25, 2019
TDD Pro-Tip: Suspect Sentinel Returns | #11
TDD Pro-Tip: Suspect Sentinel Returns | #11
"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.
05:51
November 21, 2019
RAMPS: Ways to Affect Rhythm | #10
RAMPS: Ways to Affect Rhythm | #10
"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.
10:14
November 20, 2019
Change Pro-Tip: Reset | #9
Change Pro-Tip: Reset | #9
"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.
05:16
November 18, 2019
RAMPS - Rhythm is Tension and Release | #8
RAMPS - Rhythm is Tension and Release | #8
"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.
10:14
November 15, 2019
RAMPS - A Way I Approach Motivational Puzzles | #7
RAMPS - A Way I Approach Motivational Puzzles | #7
"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.
10:00
November 13, 2019
Stories about Stories | #6
Stories about Stories | #6
"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.
07:58
November 10, 2019
How Stories Change Things | #5
How Stories Change Things | #5
"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.
06:10
November 07, 2019
What I'm Up To | #4
What I'm Up To | #4
"I don't know what will thicken the software making trade's culture. But I know (part of) what I'm trying to do: tell the story of us, re-tell it, and re-tell it again, as many times as it takes, until that story is the story of a community of kindness and creativity." Episode 4 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. 
03:40
November 05, 2019
Thin Culture and Stories | #3
Thin Culture and Stories | #3
Episode 3 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. 
06:28
November 01, 2019
Easiest Nearest Owwie First (ENOF) | #2
Easiest Nearest Owwie First (ENOF) | #2
When facing especially weak code, it’s easy to feel daunted; there just seems so much wrong with it. To get my mojo on, I find the simplest infelicity to fix, I fix it. Then I do it again. Everyone encounters code from time to time that she does not understand. This is true for the noob and equally so for the olb. It is a fact of being a geek. Early in one’s refactoring career, one tends to blame oneself. While it must be said that you have a certain peculiar charm, you feel basically stupid, and that you are at fault and not the code. Slowly, over time, you will begin to suspect otherwise, and you’ll start to realize the code works for you, you don’t work for the code. Congratulations! That is the correct attitude. READ THE FULL TRANSCRIPT HERE: https://www.geepawhill.org/refactoring-pro-tip-easiest-nearest-owwie-first/
07:12
October 28, 2019
When to Start TDD | #1
When to Start TDD | #1
First Episode of the GeePaw Podcast is now live! These episodes will be posted every Monday morning and will go hand-in-hand with either an old or new blog post on the website GeePawHill.Org. If you love it, sign up to the GeePaw Weekly newsletter to receive updates on all blogs and podcasts straight to your inbox.
08:53
October 21, 2019