TDD pro-tip: any "time" u refer to a clock, be on the lookout. It’s a time — I just can’t help myself — to seriously microtest your way through. If you have to talk about "now", consider whether you want to be able to pass a clock rather than call the system. For the price […]
TDD Pro-Tip: Time Needs Technique Read More »
We spoke of two questions in the recent re-visiting of the money premise. How/why does TDD make changing layered branching logic faster? What’s the capital outlay to change to it? I’ll stall a little further on 2, but let’s do 1. Some provisos before we get started, and they’re pretty important. Proviso #1 We are
How TDD Makes Change Faster Read More »
Time, this morning, to return to the underplayed TDD premise called the money premise. In one phrase: "We’re in this for the money." What does that mean? In the software business, like every other business in a long period of very high demand, we make more money when we ship more value faster. Please be
We’re In TDD For The Money Read More »
So, for those following along, the other day I had to decide whether to roll my own parser for boolean expressions involving tags, like "(stinky & doofus) | (ugly)". Very standard stuff. In the end, I rolled my own, and I have to tell you, I just had a really wonderful time. A parser for
Parsing Expressions, TDD, and the Big Why Read More »
So, in recent muses, i’ve tried to establish that our next step is a) restructuring economy to b) grow & keep geeks. How? What changes do I make in my org, assuming that I have restructured the economy to give me space to do so, to increase the org’s ability to grow and keep geeks?
How to Grow and Keep Geeks Read More »
From yesterday’s dark muse, this: i need stronger geeks. But I can't *get* stronger geeks without attending first and foremost to *growing* them and *keeping* them. — Michael D. Hill (@GeePawHill) August 12, 2018 #### Let’s go there. I believe we are consistently failing in the geek trade. By failing, I mean that we who
Growing and Keeping Geeks Read More »
It seems to me that a very great deal of "agile" advice has an implicit prefix, "assuming your team is close to healthy," you should … The assumption of reasonable health just — to put it as gently as I can manage — doesn’t seem like the sort of assumption we should be making. The
Restructuring the Debts In The Geek Trade Read More »
Coaches, let’s talk about fear and — not the team — fear and the coach. I get to meet and speak with a lot of coaches, which pleases me. Because i’m an introvert with a taste for authenticity, I am also lucky enough to quite often get them in small groups or one-on-one where folks
Fear, Coaches, and the Will To Fail Read More »
Yesterday’s irritated blurt was a matter of feels, not an attempt to offer insight or ideas. I got some queries about it, so let me wipe that slate and be a little less irritated. For now, anyway. 🙂 In geekery — in all tool use beyond a certain point, but my focus here is on
Decomposition Rage Tweet Explained Read More »
Let’s talk a little bit about showing your working code to your product person. A basic recommendation, which will seem strange and likely freak you out the first time you hear it. Look to show your new stuff every day or two. I want to address here both the how and the why. The why
Showing Code Every Day Or Two Read More »
