Geekery

Refactoring Pro-Tip: Terrible Code Doesn’t Mean Terrible People

Refactoring Pro-Tip: Terrible code is not a good excuse to be mean, because terrible code is not well-correlated with having been written by terrible people. Look, y’all, it’s me, here. I love a good rant as much as the next Old Testament prophet, surely you know this. But . . . but . . . When I work with a new team, a key element of what I do is figure out how to integrate my line of advice, which […]

Refactoring Pro-Tip: Terrible Code Doesn’t Mean Terrible People See Full Post

Bring The Whole Geek!

I’ve made mention here and there of "the whole geek". I’d like to take a little time and lay out the idea. (There’s a video coming, too, expect it to be strange.) In our conversations about geek culture, I’ve tried to make my sense of its thinness as clear as I can. One of the key aspects of that thinness is the way in which it decides what belongs in our discourse and what doesn’t. In particular, the trade today

Bring The Whole Geek! See Full Post

Refactoring Pro-Tip: Easiest Nearest Owwie First

Refactoring Pro-Tip: "Easiest Nearest Owwie First". When facing especially weak code, it’s easy to feel daunted; there just seems so much wrong with it. To get my mojo on, I find the simplest infelicity to fix, I fix it. Then I do it again. Everyone encounters code from time to time that she does not understand. This is true for the noob and equally so for the olb. It is a fact of being a geek. Early in one’s refactoring

Refactoring Pro-Tip: Easiest Nearest Owwie First See Full Post

Culture Starch: Thick and Thin Redux

The geek trades suffer from an extreme paucity of culture, and a great many of the issues we see are the direct result of that cultural thinness. Culture is the air we breathe. Though we’re often quite unaware of it, it surrounds us, it shapes what we see & think & feel, and it is vital to our continued existence. It is multi-layer, multi-current, multi-flavor. It is at the center of and at the periphery of what is human. It

Culture Starch: Thick and Thin Redux See Full Post

Pro-Tip (Refactoring): Prioritize Reading Code

Pro-Tip (Refactoring): Prioritize reading the code over learning about the application domain. Not so long ago, I worked with a team that was hacking a humongous (>3mloc) perl codebase with their main focus being performance. I set out to show them that the crazy crap I was showing them about TDD and refactoring would be useful. The critical call was to a method that had to update patient status using a variety of pretty complex logic. We’d brought just that

Pro-Tip (Refactoring): Prioritize Reading Code See Full Post

Pro-Tip (TDD): Focus on Our Branching Logic

TDD Pro-Tip: What we TDD most rigorously and faithfully is our branching logic. This is the insight one needs to start gaining TDD’s massive productivity benefit. All three terms are important, "our", "branching", and "logic", so let’s take them one at a time. Remember as we forge in to this: there is no free lunch, but if there were a free lunch, writing a test ain’t it. Every test we write costs something and benefits something. We need that benefit

Pro-Tip (TDD): Focus on Our Branching Logic See Full Post

Coding Well And Peopling Well

Working with people who don’t code very well is always a big anti-pairing boogeyman for folks, but working with people who don’t people very well is very much more difficult. Is there a skill-factor in pairing well? Sure there is: it’s the skill your mom invoked when she said, "Use your words, honey, use your words." The hardest pair partners are the ones who don’t speak. My favorite pairs are just like me, they say what they think, whether they’re

Coding Well And Peopling Well See Full Post

Pro-Tip (Meta): Grasp the Judgment Premise First

TDD (Meta) Pro-Tip: Grasp the judgment premise by the horns and do not let it go, in every single one of these pro-tips. Here is the judgment premise, taken from Five Underplayed Premises Of TDD: "We happily rely on individual humans using their individual judgment." Imagine if there was a formulaic way to program computers. Imagine there was a procedure you could invoke that would algorithmically create software to order, software with no bugs, no inefficiencies, only pure crystalline value

Pro-Tip (Meta): Grasp the Judgment Premise First See Full Post

TDD Pro-Tip: Wrap Containers Early & Often

TDD Pro-Tip: Wrap framework collection classes early and often. The Primitive Obsession smell is ubiquitous around collections, and not seeing and fixing it can greatly hamper productivity. In HollywoodSimulator, a common act of every Person is to spend time manipulating their little black book — the collection of the contacts they have. The first-pass way to represent this would be to use a framework collection class. In Java/Kotlin, that’s List<Person>. List<Person> is not a primitive, far from it, in Java

TDD Pro-Tip: Wrap Containers Early & Often See Full Post

TDD Pro-Tip: Test-Before Is Operationally Different

TDD Pro-Tip: Because the power of TDD is operational rather than artifactual, test-before provides several benefits over test-after. Sometimes folks propose the writing of tests after the code is written. The idea here is that the point of the game is to have the tests, and that it makes no difference whether we do them before we write the code or after. This idea is flawed: it centers TDD around the artifact — the made test — rather than the

TDD Pro-Tip: Test-Before Is Operationally Different See Full Post

Scroll to Top