September 2018

The Correlation Premise: Redux

This entry is part [part not set] of 9 in the series Underplayed Premises

My five TDD premises stuff has been well-received over the months since I put it out, but one of them seems still very underplayed, even by many died-in-the-wool TDD’ers: the correlation premise. The correlation premise says that the internal quality of our code correlates directly with our productivity. When the internal quality goes up, productivity goes up. When it goes down, productivity goes down. All of the premises were formulated in part to undercut dangerous misunderstandings about what TDD is […]

The Correlation Premise: Redux See Full Post

TDD Pro-Tip: Start Builders & Partial Comparators Early

TDD Pro-Tip: Prevent complex test data from spiraling out of control by going to builder & custom comparator early on. The push-to-small, coupled with SOLID, coupled with things like third normal form, all lead us to a place of wanting to compose domain objects into potentially very rich dependency graphs. A card in a address-tracking subsystem sounds at first blush like a class with about 5 simple strings in it, and we certainly start there when we first approach it.

TDD Pro-Tip: Start Builders & Partial Comparators Early See Full Post

Acculturation: A Little Deeper

I’ve mentioned "acculturation" a couple of times lately. Let’s dig in a little deeper on that. In our trade, we make much of "education", training and learning and skills inventories and such-like. I say we make much of it, well. That’s an overstatement, of course. Companies talk about it a great deal. But i’m often struck by fabulously wealthy companies who are utterly dependent on and desperately needful of geek skills and won’t pay a dime to improve them. But

Acculturation: A Little Deeper See Full Post

TDD Pro-Tip: ‘No, Smaller.

TDD Pro-Tip: "No, smaller." In TDD, almost without exception, we want everything: a test, a method, a class, a step, a file, really, almost everything, to be as small as it can be and still add value to what we’re doing. This is the most common gaping hole in the practice of the noob, and it’s a constant obsession for the olb. But it’s not just an old-timer’s tic, like the way my lips purse when someone uses the word

TDD Pro-Tip: ‘No, Smaller. See Full Post

Slinging Advice and Where I Come From With It

So, I’m out there slinging advice about how to change the world of being a professional programmer. Maybe y’all need to hear some things about that, that might not have occurred to you. I am just some schmoe. I am having a successful life in the world of geekery. There are a host of causes for that, among them my dumb luck, and also among them the way I approach and enact the work. I like to talk about this,

Slinging Advice and Where I Come From With It See Full Post

TDD Pro-Tip: TDD & Refactoring Are Intertwined Life-Game

TDD Pro-Tip: TDD and refactoring are permanently intertwined activities, neither of which can be grasped all at once, so start learning how to write tests at the same time you’re learning how to change code w/o adding bugs to it. Some activities are what I think of as "life games". The better you get at it, the more there is to learn. I call them games, cuz my first two noticed experiences of this were in the games of pool

TDD Pro-Tip: TDD & Refactoring Are Intertwined Life-Game See Full Post

TDD Pro-Tip: They Work For You, Not You For Them

TDD Pro-Tip: remember who works for who, and shape your tools to your hand, not your hand to your tools. (Btw, these tips are in no particular order. If you want to know the truth, i’m musing them as I do them. People always know more than they can say, and i’m no exception, but i’m digging at what I do over and over, and sharing it.) One difference I see over and over between noobs and olbs is the

TDD Pro-Tip: They Work For You, Not You For Them See Full Post

Scroll to Top