When we talk about transitioning to microtest TDD, we have to figure out how to provide the right experiences in the right order. That's why I propose we start by getting the experience of changing a well-microtested graceful class.
Folks, my ideas about changing code are thoroughly entangled with my ideas about changing the world, a topic of far greater importance. Let's geek out, by all means, but let's also act outside the monitor.

Black Lives Matter.
"Create Experiences, Not Arguments" is one of the core habits of change-harvesters. We want to take that slogan very seriously when we approach any significant change to our practice. And microtest TDD, believe me, is a significant change.
A would-be TDD coach or instructor nearly always carries an implicit belief that her victims do not have, drawn from lived experience that they don't have. It is this:

"What we are doing now is much more unpleasant and unproductive than what we'll be doing when we TDD."
Now, we can *argue* that case, God knows I mis-spent my coaching youth doing just that. And that's a start, it really is. Moving from the implicit to the explicit is generally a useful thing to do. But argument -- reasoning, logic, bullet-points, verbal charm -- has limits.
There's a thing that has many fewer limits than any logic, however passionately, articulately, charmingly, presented: having an experience that ends with you saying one sentence:

"Hey! This feels better!"
I learned to shoot pool seriously back in the middle '80s. And the most useful book about it I ever read, in the intro, said that the most useful book to read about shooting pool seriously was _The Inner Game of Tennis_ by Timothy Galway.
Galway starts noobs like this: After showing them how to hold the racket, he stands 20' away underhand throwing tennis balls to their forehand, one-bouncing them, carefully aiming, and letting them swing.
He's watching them, as he does it, aiming the ball just so, until they hit it three times in a row how he wants. When they finally do:

"That's it! That's what it feels like when it's right."
"This is what it feels like when it's working."

That's the experience I want to create in the early days of transitioning. Here's the thing tho, as soon as I have that thought, I'm hammered by figuring out what the word "it" should be.
Doing TDD well is like competing successfully in the small-town tournament. It's a long way from knowing how a well-stroked forehand feels to being able to play against that skinny mean-spirited 70 year old dude who's been out there every day hitting tennis balls since he was 4.
(That illustration is taken from life. The city tennis courts in Parsons, Kansas are named for that guy. I watched him, growing up, and he was like the ancient master from a thousand classic old kung-fu movies.)
So then, can we give them the feel of TDD done right?

I'll prolly get some grief for this, but hey, live free or die:

The answer is "No."

It's a bridge too far.

Or . . . the answer is "Not yet."
Well, what *can* we give them? What's an early "feels like this when it's right" experience? I have tried a lot of different ones, asked a lot of questions, failed many times at creating viable experiences.
But then I had a brain-fart:

What do programmers *do*, right now, all the time, in their day job? What do they do that is much more unpleasant and unproductive than when TDD is worrking well for them?
Programmers change brownfield code, typically code they didn't write, or maybe wrote a while back, typically code that's okay-but-not-great, typically on relatively modest domain problems, typically under a fair amount of pressure.
That's what programmers do, much or most of the time they're programming.

If TDD was working well for them, would doing that feel better?

Oh. *Hell* yeah it would.
That's the early -- maybe earliest -- experience I want them to have: change modest-problem, okay-but-not-great, brownfield code, when that code has strong microtests around it.
A lot of my threads are implicitly about what you should do. But this one, from here forward, is about what *I* *will* do. I want to make a sample of what it is I'm talking about, a kind of "reference architecture" of it, if you will.
I want something modest but not too tiny, with multiple classes, in a domain I can explain pretty readily. No awkwards in the code that must change. My ideal of coverage. Idiomatic in the chosen language.
I want the change to be bigger than a one-liner but smaller than a breadbasket. I want them to be able to determine whether their change worked or not without testing. In fact, I'm entirely indifferent to the question of whether they TDD their change or even test-after it.
The experience isn't "this is how you TDD" or even "this is how you test-after". The expereince is "this is how it feels to change code that's graceful and has strong microtests around its BEFORE.
I'm wanting this to take between 1 hour and 2. Longer, we lose interest. Shorter, it's too toy-like. The answer should not be too obvious, but also not be rocket-science, or require a clever language-corner.
I have a candidate domain, but not a candidate change yet. I think my next step is just to TDD it up stand-alone, operational to a certain point, then consider the possible interesting change.
Short domain description: you have items. Items have tags -- single words associated with them, many-to-many. Type a query string, ands, ors, nots, and tags, get back the items satisfying it.
(This is from my current night-coding project, called tagster, but as I say, I'll do it standalone for this purpose.)
Concept: Ship a rev of the code without a change, let my friends play with it a little in its working form, and mine *their* ideas for what the good change will be.
Concept: TDD it to the same story-test level *twice*, but using a different implementation each time. Take the tests away from one of them as a NO-TESTS experience to contrast with the TESTS experience.
If we're going to help people unfold TDD, we're going to have to attend to their experiences along a fairly long path. One proposed experience: change modest brownfield code in the presence of excellent microtests and see how it feels.
Thanks for hanging in. I got some code to write. :)

If you like my stuff, subscribe. Free, spam--free, full-text or audio.


And please, please, embrace change, in the code, yourself, the team, the org, the trade, and the world.

Black Lives Matter.

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with GeePaw Hill

GeePaw Hill Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @GeePawHill

20 Feb
@AlexandraErin If I just tweet this to you, does it count?
@AlexandraErin Hmmm. Apparently that's legal.
I have a lot of respect for you, have followed you for a while, and tho there's quibbles here or there, no matter.

Not being able to reply to you, in favor or opposed, makes me feel I should move on. I didn't come here for radio stations I can't interact with?
Read 6 tweets
20 Feb
Here's A Tribe Called Quest, "Can I Kick It".

There's no quest but quest.
Funny! Smart! Tradition-enriched!

Strong as *shit*.
Read 5 tweets
20 Feb
This a nice "I'm Confessin'". Lizz Wright.

One of her takes that just features her voice more than her sense of style.
Wright has a lovely not-quite-contralto, but what I really like in general is the richness of her voice connecting, both with the tradition she pulls from and the combo she plays with.
Read 4 tweets
20 Feb
Richard "Rabbit" Brown, "James Alley Blues".

It came up, swear to God, I didn't hand-pick, even tho I know it's an overplay.
This is one of my most most most favorite blues songs. I listen to a lot of music, and a lot of it I don't even know where it comes from, and it pleases me this much or that, and I move on.
Read 4 tweets
19 Feb
Heh. Somebody arguing that remote work is less efficient and citing the last year. Cuz, you know, *that* was the one variable, and everything else was the same as two years ago.
NB: I am not arguing the case for or against remote work. I am arguing the case against the all too typically inane suggestion that the key difference between 2019 efficiency and 2020 efficiency was having to use Zoom.
Yes. We did a lot more remote work in 2020 than 2019. We also stayed in our tiny unprepared spaces with our parents and children and pets, in some cases 24/7 for days on end, endlessly stressed in concern for everything from our livelihood to our life.
Read 4 tweets
19 Feb
Ray Price, "For the Good Times".

Kristofferson wrote it, and released it on his own debut album, but I've always been incredibly partial to this Ray Price take.
There's a time in Carmen McRae's career where her voice has finally begun to shred from whiskey & smoke, but only just so. Something about Price's voice here feels the same. He had a controlled crackle in his tone that few crooners, country or otherwise, could handle.
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!