GeePaw

Optimize for Our Humans

Change, Change Harvesting, Leading Technical Change / / 6 minutes of reading

Leading Technical Change is a small, live, remote seminar aimed squarely at a single topic: Real Change in the Real World. A new cohort is open now: March 11,12,14, & 15, 10am to noon Eastern (UTC-5). There are just six seats available, so we can drill down on the actual situations in which you’re seeking change. https://www.geepawhill.org/courses/leading-technical-change/ To give you some of the flavor, let’s talk today about one of the key planks in the LTC trio of strategies: Optimize […]

Optimize for Our Humans See Full Post

Why Only Change Frames?

Uncategorized, Leading Technical Change / / 4 minutes of reading
This entry is part 3 of 3 in the series Changing The Frame

Today I want to answer a question that, honestly, almost no one ever asks. Why are we changing frames, instead of getting rid of them altogether? Talking about change in the geek trades is a joy for me, but I’m even more interested in seeing change out in the world. Please think outside the monitor. Black Lives Matter. Why are we only changing frames, and not breaking them, destroying them, ridding ourselves of them? First, lemme answer the question. Then,

Why Only Change Frames? See Full Post

The Frame-Changing Triad

Uncategorized, Leading Technical Change / / 5 minutes of reading
This entry is part 2 of 3 in the series Changing The Frame

We started with the concept of the mental frame, a comparatively rigid & invisible construct which structures and guides nearly all our behaviors. Today, let’s take up the triad of powerful forces that we can use to change frames: community, narrative, and experience. https://www.geepawhill.org/2023/01/20/changing-the-frame/ As ever with me, though considering change in the geek trades is a pleasure, it is not the main story. I remind you that we need change-in-the-world at least as much as we do change-in-the-code or

The Frame-Changing Triad See Full Post

Slowing Decisions Down

Leading Technical Change / / 3 minutes of reading
This entry is part 5 of 5 in the series Leading Technical Change

Here’s another technique card from my seminar, “Leading Technical Change”. We first get into midwifing change precisely because we want it to be smoother, easier, and faster. But sometimes, a coach needs not to rush a decision through, but to slow it down. It’s so exciting when our proposed change starts to catch fire, especially when major influencers in our team suddenly “get it”, and want the whole team doing it. “Winning.” And it is winning. But when you start

Slowing Decisions Down See Full Post

What About Failure?

Leading Technical Change / / 4 minutes of reading
This entry is part 4 of 5 in the series Leading Technical Change

If we’re going to enable and support change, we’re going to fail, more often than we succeed, and we want to bake that idea in, early on, lest we fail both more often, and potentially more disastrously. Here’s some thoughts around this NOT DEPRESSING topic. 🙂 The weirdest thing about all this: it’s actually rather hard to tell when you’ve failed vs succeeded, working as midwife to change. I’ve had what I thought were successes backfire horribly, inadvertently leading teams

What About Failure? See Full Post

Joy Project: FGNO Plotter

How I Work / / 4 minutes of reading

Joy project: Today’s a comparatively light work day, so I’m gonna lay out what I’m actually trying to do with this project. The source, btw, is at: GitHub – GeePawHill/fgno-plotter Playtime project for the fgno meetup. Contribute to GeePawHill/fgno-plotter development by creating an account on GitHub. Feel free to poke around. There are a bunch of simultaneous missions going on with fgno-plotter, which is why it’s a joy and learning project. "fgno", btw, is an abbreviation of "Friday Geek’s Night

Joy Project: FGNO Plotter See Full Post

TDD Pro-Tip: Against Automated Macrotests

Programming, TDD, How I Work, Coding / / 9 minutes of reading

TDD Pro-Tip: I advocate against automated macro-tests — those whose base is entire running programs –, as their cost is high and their benefit is doubtful. I very rarely write them. There is a bewildering variety of terminology out there around what I’m calling macro-tests, so let’s poke around a little. The central idea of "macro-test" is that we write code that launches an entire subject program and probes its behavior "from the outside". There are often multiple programs in

TDD Pro-Tip: Against Automated Macrotests See Full Post

Some TDD History

TDD / / 7 minutes of reading

I spoze the historic and ongoing inability/unwillingness of the software trade to grasp and adopt test-driven development (TDD) is one of the most frustrating & demoralizing events of my forty-two years as a professional geek. I believe there are several related factors in play, ranging in abstraction level from pressures of global ieconmics to mistakes in local human interaction. Studying this large-scale failure, even while having some small-scale successes, underlies much of my work on change. Because, while the overall

Some TDD History See Full Post

On Over-Coding

TDD, Programming, How I Work, Coding / / 4 minutes of reading

Let’s talk for a minute about "over-coding". Over-coding, when you’re a TDD’ist, is writing more code than you (intended to) have test to cover. But I will offer a few thoughts on this to non TDD’ers and TDD’ers alike. Many people, pro-TDD and con- both, seem to think of TDD as the name for a collection or rigorous mechanical rules. TDD is a kind of jack-in-the-box, where you sit there and turn the handle, circle circle circle, and out pops

On Over-Coding See Full Post

Scroll to Top