Detail: The thing that strikes me over and over again, in my own work style, in my Friday group’s analytics, in Ron’s long-running Kotlin and short-running Gilded Rose series, is how much attention high-skill geeks pay to some of the smallest details in the code.
An example. I was doing Gilded Rose the other day, first time in years, and we start with the ugly method, which we’re asked to add a feature to, following certain constraint rules to make it feel more like legacy.
There are no starting microtests. I’m a TDD’er so I started in.
I bounced back and forth looking at the code and looking at the spec — there are mismatches, on purpose — and decided that the point was to simulate a legacy setting, and in that setting, the code is always right. (There’s another article for that conversation somewhere.)
And I took the easiest case I saw, code+spec, and I wrote my first microtest for it, and it looked like this.
First test:
GitHub Gist: instantly share code, notes, and snippets.
https://gist.github.com/GeePawHill/6d64d0dbf10de60b5491c56b0ec9cf67
And that’s a legitimate test. In fact, both the rules and the code say that this sulfuras item I put in this array with that sellIn and quality values should come out exactly the same as it went in.
So I reworked the test a little before I even wrote another one. Why? Detail: this test has a lot of noise. We’re not really interested in the array, but in the item. And we’re gonna be doing this over and over again.
I could copy/paste the original test to get the next one. But my detail sense was bothering me. If we’re not interested in the array, why are we talking about the array?
The rework looked like this:
Second rework of test:
Second rework of test. GitHub Gist: instantly share code, notes, and snippets.
https://gist.github.com/GeePawHill/4ccd8718129723be636e324808f54682
That’s better. It’s Item-centric now. But it still has a lot of noise. The real thing here with these tests is that they are 1) all single-item, and 2) never are gonna change the name of the item, and 3) are about how and whether those two numeric fields change. Every time.
I wrote more tests using this version of the code. And then, again, detail: why is this so tedious? I am still not happy with the expression of the test.
Really, I just want to give you the three item parts for the before, and I want to compare the two of them with after values.
So after the third test, I finally rewrote the test support code again, and this time I focused my little eye on the simplest possible expression of what the test was about. It looks like this:
Third Version of Test Code:
Third Version of Test Code. GitHub Gist: instantly share code, notes, and snippets.
https://gist.github.com/GeePawHill/e37fac2a11604801a617061b77a03f6f
Bingo. Now all the tests I have, and all the tests I will have for a while, have the exact same one-liner form. It’s a little heavy, with those four numeric arguments, but the IDE labels them, so I never get lost when I’m writing/reading the test.
One line of text for what the test tests. One line of text for the actual assertion, and it’s all almost pure signal.
(In the end, I wound up with about 20 of these one-liner microtests to cover the existing code to my satisfaction.)
Now there’s three points we might draw from this example, so let me make them in ascending order of abstraction.
First, I treat test code the same way that I treat shipping code, with as much focus on signal as on actual function. This is the TDD’er in me, even tho of course I was working test-after in this legacy setting.
Second, I don’t RORA my code. RORA means "runs once, run away". I stay with it, even after I have it working, until I am satisfied with it. I write working code, and then change it fifteen minutes later without altering its function, all the time.
Third, and this is my real point for the writing, I pay a great deal of attention to detail. Much more than most of the juniors I work with, and even some of the seniors.
Look, this is 15 crummy tests, who cares if they’re 90 lines of code or 15 lines of code? What a very small thing for me to worry about. What a detail. And yet I did, and I find that, when I am at my most productive, I am nearly always doing so.
I don’t consciously pick and choose when to obsess over detail, not for the most part. I just do it like that, that’s how I program, by having this kind of weird focus on little tiny things that seem like they "don’t matter", to many or even most geeks.
And the weirdest part, I am actually an extremely productive programmer. Working in this nit-picky way, you’d think that I would be slow. You might praise me for my focus on quality, were you feeling kindly.
But I actually ship more new function than most people do.
I think there are three things going on at once, and I think that they represent three features of all high-skill geeks, perhaps not in close-up which-step-when ways, but in the higher level of description.
- When I’m done fiddling with my detail, the box I had open to fiddle with it can be closed. I stop thinking about it, and am completely confident in what that box’s label means about what’s inside it.
- I absolutely hammer on maximizing signal. Sometimes, even, when I already know how I will make a thing work, before I even start it, I start wondering how to make the signal as loud and clear as possible.
- I take the attitude, at a very deep level, that the code works for me, I don’t work for the code. If me and the code disagree about how things should be, the code loses, every time, and I win.
So this, I think, is the beginning of an occasional series, about "detail". About the real-life examples of this kind of microfocus, and about the building of that faculty and drive, and how to go about it.
A foretaste: I had four lines of code, all independent, whose gist was "change X, change Y, change X, change Y", in front of Ron Jeffries the other night. He said, "wait." Make it "change X, change X, change Y, change Y".
What a tiny detail!
And he was right, that was better.
Does the GeePaw Blogcast add value?
If so, consider a monthly donation to help keep the content flowing. You can also subscribe for free to get weekly posts sent straight to your inbox. And to get more involved in the conversation, jump into the Camerata and start talking to other like-minded Change-Harvesters today.