Can we be honest? If we're going to be successful change midwives, honesty is very important. In this technique card from Leading Technical Change, I talk about some of the ins & outs of this complicated topic. --- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --- Send in a voice message: https://anchor.fm/geepawhill/message

The people who hire me ask me to help their teams make changes. Most of the time, my first step is to see how I can slash those teams' load. To me, this is dreadfully obvious, but for a lot of folks seeking change, it comes as a completely shocking idea. The weirdest part, though, is that it not only improves our ability to change, it usually also increases our actual productivity. Let's talk about the change effect of that first, then the productivity effect. --- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --- Send in a voice message: https://anchor.fm/geepawhill/message

Joy project: Today's a comparatively light work day, so I'm gonna lay out what I'm actually trying to do with this project. The source, btw, is at: https://github.com/GeePawHill/fgno-plotter.  -- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! -- --- Send in a voice message: https://anchor.fm/geepawhill/message

TDD Pro-Tip: I advocate against automated macro-tests -- those whose base is entire running programs --, as their cost is high and their benefit is doubtful. I very rarely write them. There is a bewildering variety of terminology out there around what I'm calling macro-tests, so let's poke around a little. -- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! -- --- Send in a voice message: https://anchor.fm/geepawhill/message

I spoze the historic and ongoing inability/unwillingness of the software trade to grasp and adopt test-driven development (TDD) is one of the most frustrating & demoralizing events of my forty-two years as a professional geek. -- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! -- --- Send in a voice message: https://anchor.fm/geepawhill/message

Let's talk for a minute about "over-coding". Over-coding, when you're a TDD'ist, is writing more code than you (intended to) have test to cover. But I will offer a few thoughts on this to *non* TDD'ers and TDD'ers alike. -- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! -- --- Send in a voice message: https://anchor.fm/geepawhill/message

Here's ten I-Statements about change, in the geek trades, and beyond. My hope is that it will give you a richer sense of where I'm coming from in my blogs, talks, videos, and courses.  -- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! -- --- Send in a voice message: https://anchor.fm/geepawhill/message

I've oft mentioned how the twin cost-revolutions in geekery warped & nearly destroyed our trade. Then wondered if we'll get to a place where it's no longer profitable for most companies to write bad software poorly. This morning I wonder if I'm seeing the beginning of it. -- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! -- --- Send in a voice message: https://anchor.fm/geepawhill/message

I was a good programmer because I was a *terrific* memorist: I could learn things by heart, and I could organize them in my mind in such a fashion that I could get to them whenever I needed them. It is the nature of humans that whatever they have had so far, they assume they will have forever. There's a default assumption that whatever's going on will continue to go on, ad infinitum. This applies to the good things they have, and also the bad things, of course, and is a defining property of humans, in my view. -- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! -- --- Send in a voice message: https://anchor.fm/geepawhill/message

On the cover of Hofstadter's famous _Godel, Escher, and Bach_, there's a photo of an artifact he made, called a "trip-let". The trip-let, when lit from three different angles, produces shadows that spell out "G", "E", and "B". Let's talk about software design. -- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! -- --- Send in a voice message: https://anchor.fm/geepawhill/message