Read on Twitter
I think of my style of coding as "microtest TDD". That can be misleading for folks, so let's take a walk over a few of the ideas, implicit and explicit, that make up the approach.
First things first, bear the money premise in mind in all that follows, to wit:
"I'm in this for the money."
In the software trade, we make money by shipping more value faster. This is why I adopt these practices, because when I do them, I go faster.
"I'm in this for the money."
In the software trade, we make money by shipping more value faster. This is why I adopt these practices, because when I do them, I go faster.
In particular, I don't do them out of a fondness for artistry, intellectual purity, common decency, perfectionism, or theory. I do them because they are the best way I've discovered, so far, to ship more value faster.
Next, though I call what I do "microtest TDD", that's really a shorthand for a whole bundle of practices. A more accurate name would be something that captures, in the big picture, working in the smallest ready-to-ready steps I can formulate. That's a lot of words, tho. :)
The practices include things that are "coding", and they also include things that are "collaborating". Professional software developers have to do both, all the time, freely intermixed. Strong pro's do both of those *well*.
Some coding-centric practices I do: microtesting, refactoring, frequent commits, trunk-based development, spike-pathing, evolutionary development.
Some collaboration-centric practices I do: pairing, mobbing, haykumeer protocol, direct customer involvement, continuous integration, standups, retrospectives, pull and swarm.
I don't pay much attention to the distinction: they're all practices, and I employ all of them, and occasionally some outliers, too, in my efforts to find and implement ready-to-ready steps.
Next, I can divide my work into roughly two modes. Sometimes I am "path-finding", which means looking for sequences of smallest-ready-to-ready that get me what I want. Sometimes I am "path-following", which means actually implementing those sequences.
An easy way to distinguish: when I'm path-finding, I throw away way more typing than I commit. When I'm path-following, I commit way more typing than I throw away. There are borders between these, gray transition-y areas, but mostly I'm well inside one mode or the other.
I spend significantly more time path-finding than path-following. It is the hardest work I do, far harder than path-following. But it's also, for me, the heart of the job.
Occasionally, with very small problems, the finding and the following are happening at the same time: I roll little tests I don't know how to pass but I'm sure I can get to pass, and then I pass them. That's hardly rare, but it's not my most common case, either.
Next, I believe that my productivity is generally dominated by two terms of the production equation. 1) The internal quality of the code I start with. 2) The size of the steps. Correspondingly, I obsess with both of those concerns. :)
The two *biggest* terms in the production equation are "how skilled am I" and "how hard is the domain". But the thing is, both of those are out of my ready and direct control. Not that I can't change them, but I can't usually change them at a time-scale that matters.
But the next two biggest terms are internal quality and step-size. And those are far more directly controllable by me, so that's where I give my attention.
The practices I use to keep internal quality high are primarily TDD in the narrow sense and refactoring in the narrow sense. My experience has been that my style of TDD almost *forces* a certain level of internal quality, and the refactoring either enables that or refines it.
And the step-size? Well, for *that* my main practice is what I call spike-pathing. It means that I use path-finding code-I-don't-commit to discover the path-following code-I-commit.
So that odd rambling muse is it for now, but I see it as setting a context in which I can discuss in much greater detail, each of the practices, how I use them, and how they relate.
I have written or spoken at one time or another about nearly all of these practices. I intend to do so again, and to do so in greater depth, practice by practice.
In the meantime, though, since you so graciously read all the way to the end of this:
AMA.
I love talking and thinking about this stuff, and if anything I've said here triggers your curiosity, well, ask me about it.
AMA.
I love talking and thinking about this stuff, and if anything I've said here triggers your curiosity, well, ask me about it.
Oh, a double-pitch:
First: most of these twitter muses turn in to blogcasts, so if you don't want to miss them, or you hate tweet threads, or your love audio, subscribe.
It's free, it's spam-free, it's audio or text, and it helps me when you subscribe! https://geepawhill.org
First: most of these twitter muses turn in to blogcasts, so if you don't want to miss them, or you hate tweet threads, or your love audio, subscribe.
It's free, it's spam-free, it's audio or text, and it helps me when you subscribe! https://geepawhill.org
Second: Ya wanna see the old fart in action? I have a town-hall meeting next Friday at noon. It's two hours, a talk intermixed with breakouts and de-briefs.
It's fun and it's free, but you gotta register in advance, cuz we limit the size. https://geepawhill.org/town-halls
It's fun and it's free, but you gotta register in advance, cuz we limit the size. https://geepawhill.org/town-halls
