I was gratified by the response to my first "detail" article. But I did note that many persons praised my article for its commitment to the long game. Framing the commitment, for a geek, to detail, as a long game, seems right, sounds right, cuz after all, we only ever care about quality in the long game. And this is why y’all can’t convince anyone to do this or think this or feel this. When does a bad variable name […]
Detail: Not The Long Game See Full Post
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
Detail: Series Intro See Full Post
TDD Pro-Tip: I advocate against automated macro-tests — those whose base is entire running programs –, as their cost is high and their benefit is doubtful. I very rarely write them. There is a bewildering variety of terminology out there around what I’m calling macro-tests, so let’s poke around a little. The central idea of "macro-test" is that we write code that launches an entire subject program and probes its behavior "from the outside". There are often multiple programs in
TDD Pro-Tip: Against Automated Macrotests See Full Post
Let’s talk for a minute about "over-coding". Over-coding, when you’re a TDD’ist, is writing more code than you (intended to) have test to cover. But I will offer a few thoughts on this to non TDD’ers and TDD’ers alike. Many people, pro-TDD and con- both, seem to think of TDD as the name for a collection or rigorous mechanical rules. TDD is a kind of jack-in-the-box, where you sit there and turn the handle, circle circle circle, and out pops
