Because microtest TDD is more a "way of geeking" than a technique or a received body of knowledge, building one's faculties is a long and sometimes perilous effort. Let's talk about learning.

(I, too, feel a little relief just now, tho not as much as some, because recent events aren't an ending, they're the beginning of a lot of work.

Black Lives Matter.

Stay safe, stay strong, stay angry, stay kind.

Let's keep changing this.)

I want to approach the question(s) of learning TDD in some ways that are a little different from others I've seen. I've written two TDD curricula myself, and am involved currently in helping with two more. I see all of them, including the current ones, as "interesting failures".

At first, learning/teaching TDD seems like a road, then over time it seems to become a tree, and ultimately it feels much more like a spreading activation network, including lots of external triggers, plateau periods, and transformative experiences.

(I'm open to the possibility that this is what *any* judgment-centric skill looks like, but for now I just want to talk about TDD.)

I got one of those messages I sometimes get from a reader, telling me that including my politics in my muses/blogs is off-putting.

As a general rule, I don't bother to respond to these. I gain and lose followers all the time, everyoen who makes content does, for all sorts of reasons, and that's just one more.

Today, though, surrounded by all of this, I feel like I want to give a more full statement on the matter.

So.

To Whom It May Concern:

Please regard 100% of what I write as deeply infused with the spirit of my positions on philosophy, politics and society, as I certainly do.

The software trade has a great many problems, but among the most debilitating and dangerous is the steadfast refusal to adequately incorporate the humanity of the makers into its culture, organization, and reasoning.