GeePaw

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

TDD Pro-Tip: Iterations Aren’t Increments

TDD Pro-Tip: TDD depends heavily on a view that accepts and even values iteration. TDD is an I&I style of work: iteration and increment are both involved. Nearly everyone gets "increment": an increment is an improvement, an enhancement, a detectable step forward in value. Each increment is a pass over the code, during which we add to its function. TDD noobs take "increment", then, to mean "add a passing test". On the one hand, that’s great. On the other hand,

TDD Pro-Tip: Iterations Aren’t Increments See Full Post

My Agility 2: The Made-For?

This entry is part [part not set] of 3 in the series Defining Agile

Seen a few soft murmurings about the idea that the made, the making, and the maker includes the made-for. That’s good. If the idea doesn’t work, let’s change it so it does. I do want to toss some grist into the mill that might have impact. In some of what i’m seeing, "children" could easily be substituted for "made-for". As in, "think of the chiiiiiildren". Others are a tad more hard-nosed, if not quite mercenary about it: they say "made-for"

My Agility 2: The Made-For? See Full Post

Scroll to Top