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.

Before we begin: Folks, I know many are celebrating last week's results . I see them as one small pass towards the change I seek. Take a short break, then it's back to work?

Black lives matter.
Voting rights matter.
Women matter.

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

(And a *second* prefatory note: I've been not writing for six weeks. It was a combination of several factors, including illness, distraction, and the need to finish a gig. I'm happy to be back at content, now, but also very nervous. Bear with me while I regain my sea legs.)

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.

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.)

Microtest Test-Driven Development is a strategy for *change*. To understand the case, we need to answer two questions: 1) Why have a strategy for change? 2) How does TDD provide one? Let's take up the first question today.

(Before we begin, I remind you of the relative unimportance of geekery to me just now. This is just respite.

Please work for change and support the others who are doing so.

Black lives matter.

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

Why is having a change strategy so urgent?

The TL;DR is dead simple:

Because continuous ongoing change is at the base of all software development, both before and after our software is in the field.

When I read old-school software ideas, or for that matter what is being taught in our colleges for the most part today, I'm struck over and over again by the "timeless" aspect of the material. It is concerned almost entirely with the static and atemporal aspects of software.

In these approaches, applications spring Athena-like from the heads of our pantheon-worthy programmers. The designs emerge in an instant and once emerged they are final. The process looks like 1) Nothing. 2) Everything. 3) Move on.

Today, let's talk about microtest TDD's Judgment Premise: "We are absolutely and permanently reliant on individual humans using their individual judgment in TDD."

Folks, in these times, I gain respite in thinking & writing about geekery, and I hope you do, too. But there are more important stories, and this is just a break.

Stay safe. Stay strong. Stay angry. Stay kind.

Black lives matter.

Voting rights do, too.

The judgment premise emphasizes the human in test-driven development. There are no known non-humans practicing TDD, so it may seem a odd that we have to talk about this, and yet, we do.

As software geeks, we work with the most rigid deterministic systems conceivable, and we do much of that work in abstract mental space. To say that our target systems are machine-like is to say too little, really: they're more machine-like than any real-world machine.

The uber-mechanical material of our job can lead us to seeing *every* aspect of the job as if it were the same as that material, a phenomenon the French call "deformation professionelle". Put simply: working with uber-machines all day, we imagine uber-machines everywhere.

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.