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
Where to listen
Apple Podcasts Logo

Apple Podcasts

Breaker Logo

Breaker

Castbox Logo

Castbox

Google Podcasts Logo

Google Podcasts

Overcast Logo

Overcast

Pocket Casts Logo

Pocket Casts

RadioPublic Logo

RadioPublic

Spotify Logo

Spotify

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:02
November 27, 2020
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
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
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:19
September 22, 2020
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
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
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
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 8, 2020
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:23
September 4, 2020
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:57
September 1, 2020
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:04
August 28, 2020
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:10
August 25, 2020
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:40
August 21, 2020
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:00
August 18, 2020
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
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:42
August 11, 2020
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:17
August 7, 2020
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 4, 2020
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:50
July 31, 2020
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
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
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:14
July 21, 2020
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:55
July 17, 2020
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:16
July 14, 2020
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
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:13
July 7, 2020
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 3, 2020
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:13
June 30, 2020
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:29
June 26, 2020
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
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
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:30
June 16, 2020
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:09
June 12, 2020
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 9, 2020
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 5, 2020
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:29
June 2, 2020
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:56
May 29, 2020
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
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:03
May 22, 2020
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:56
May 19, 2020
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:48
May 15, 2020
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
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:44
May 8, 2020
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:36
May 5, 2020
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:00
May 1, 2020
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:57
April 28, 2020
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:08
April 24, 2020
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:09
April 21, 2020
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:31
April 17, 2020
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
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:35
April 10, 2020
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 7, 2020
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 3, 2020
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:26
March 31, 2020
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:20
March 27, 2020
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:05
March 24, 2020
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
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
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:45
March 10, 2020
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 6, 2020
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:19
March 3, 2020
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:29
February 28, 2020
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
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:22
February 21, 2020
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
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
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:04
February 11, 2020
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:11
February 7, 2020
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 4, 2020
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
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
"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
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
"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 5, 2020
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
"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
"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
"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
"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:42
December 7, 2019
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:46
December 4, 2019
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 3, 2019
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
"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
"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
"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
"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
"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
"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:13
November 15, 2019
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
"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
"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 7, 2019
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 5, 2019
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:27
November 1, 2019
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
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