Programmers will ask me how they can become stronger at programming. A very good way, one I use currently, is to get together once a week with a handful of geek friends of varying talents, interests, and projects, for a casual geekery-sharing session.

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

Folks, I see a lot of ideas and opinions about TDD fly around, passed off as holy writ. By way of counter, I offer you Ten I-Statements About TDD.

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

Coaching Pro-Tip: Don't fall -- or get pushed -- into the trap of being responsible for a team's targets. Your mission as a coach is to care for the health of your team, it's not to hit a deadline.

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

Coaching Pro-Tip #1: Everything good about agility is rooted in relationship, so everything good about coaching is, too. As coaches, we usually start from negative trust, and our central priority has to be reversing that position. Coaching Pro-Tip #2: When the developers act like testing the code is a time-wasting checkbox that costs a great deal and rewards very little, they are usually right, and one has to find out why, and tackle that, before pressing them to test more. Coaching Pro-Tip: Sometimes it's just chemistry. One advanced coaching skill is understanding when you're not some team's cup of tea, and seeing when the right thing to do is help them find someone they can relate to.

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

Two recurring phrases in my work are 1) It is like this because we built it to be like this. 2) The code works for you, you don't work for the code. Two sides of one page, phrased on the front as negative critique, and on the verso as positive encouragement.

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

"Path-focused design", of stories, architecture, code, is design that understands that we can only reach a distant City on the Hill by taking one stride-limited shipping step at a time. 

-- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --

Big-batch releases, coordinated and controlled by a central intelligence, fail, and fail frequently. Several aspects of this are fascinating, because of the interplay of hard mathematical reality with human frailty. Let's take a swing.

- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack!)

You can put all your configuration in a shared library and eliminate just about every mis-configuration in your multi-process application. It's not free, but it's cheap, and it kills a lot of minor pain. Let's take a gander.

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack!

When large teams struggle with trunk-based development (TBD) or continuous integration/deployment (CI/CD), a good strategy is to re-orient how the teams face "backsteps", moments in our workflow where a discovery forces us to re-open a stage we thought was closed. Large teams & projects often pre-date the use of modern synthesis techniques like TBD or CD, and during adoption, intermixing their Before with this new After can produce quite a bit of discomfort. If it gets bad enough, it can even kill off the improvement effort. What to do? 

---

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

A couple of days back, I tweeted about SAFe. It created some stir on the timeline, which was great, as I got to see a lot of perspectives. I want to use that tweet as an excuse to talk about something much larger. This will be a long one. :) 

---

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