Dear smart geeks: stop worrying so much about whether you’re gonna get it wrong, you definitely are gonna get it wrong. How do I approach this? Hmmmm. Okay, I see a couple of threads that need to be pulled together. This one’s gonna be clunky, I fear. Ahhh well. I’m definitely gonna get it wrong, too, I spoze. 🙂 the drive to be right is a powerful one. For some of us, perhaps, too powerful. But it does come naturally. …
Think about your last huge unrequited crush. A real one, I m talking. A crush so big you go to sleep thinking of your future together, and wake up, ummm, guilty. The kind of crush that great romantic stories are made from, and for. The wobbly-knee d kind. And a complete non-starter: when I say unrequited, I m being clinical in an effort to minimize the likelihood of breaking out into laughter, as doctors and nurses in every ER around …
A microtest has the following properties: It is short, typically under a dozen lines of code. It is *always* automated. It does not test the object inside the running app, but instead in a purpose-built testing application. It invokes only a tiny portion of the code, most usually a single branch of a single function. It never *reaches* inside an object’s boundaries, though the tester may certainly *look* inside them. It is coded to the same standard as shipping code, …
I’ve been mulling over what I do as a coach, for lo these many years, actually, and I feel like sharing some of it. I coach: I create or exploit openings through which individuals, including sometimes myself, can step closer to who they wish they were. I came to coaching early on in the movement. I was already a teacher and tended to be a leader in teams. I glommed onto XP immediately, and just as immediately started promulgating it …
When I think about teams, I think about them with a strange mixture of metaphors. First I see a thing that is in some respects like one of our classic pictures of an atom. There’s some particles in the middle, and some others that seem somewhat clearly "outside" like the electrons in their clouds. But that metaphor slips a little. In atoms, the electrons & protons & neutrons are separate and separated. In teams, it’s more like a swarm. So …
Friend Matt asked me to elaborate on "the noobification of everything" in the geek trades. This is a floppy vague one as yet, so be prepared to play fast and loose. The so-far endless demand for new software has created a poor skills distribution curve into the trade. Divide ever-so-arbitrarily our ranks into 5, dreyfus-style or thereabouts. 1’s know where to put semi-colons. 5’s know as much as we all know about geekery. We have way too many 1’s for …
Thinking this morning about strange borders, led there by a typically weird geepaw route. If u didn’t know, coaches sit around all the time and bitch about their clients. This is perfectly ordinary and maps onto all jobs I think. Such behavior is "good thing, but". It’s important to do and it’s risky as hell. Bitching about clients brings a mixed lot of positive benefit and negative ill. Co-bitching is bonding, for instance. A way for us share, a kind …
Today’s muse, another damned geepawism: RORA technique. RORA means "Runs Once, Run Away". It is the standard technique in a great many software dev environments. A developer is tasked with some story. She codes it using a variety of half-assed techniques, including mostly GAK testing. More geepawism: GAK means "geek at keyboard" testing. You know the GAK drill: run the code. Look at the output. Fire up the debugger. Look at the output. Bless it. Ship it. RORA includes not …
I often say "how am I gonna test this?" but — language being what it is — my meaning in asking that is not likely graspable by a noob. To get at what i’m really wondering when I ask this, I may have to take a few asides & detours. First. Why am I writing a test at all? What is the test doing for me? This touches a mantra you’ll hear me mutter over and over. "i don’t work …
Alrighty-then. This Hard-tdd vs Soft-tdd thing. A couple of days ago, I worked through some underplayed premises of TDD here. Along the way, I touched on what I call Hard TDD vs Soft TDD. The terms derive from AI, where proponents differ on soft-AI vs hard-AI. A semantic association, not a real analogy, so i’ll skip that. Hard vs soft here isn’t about technique, it’s about what we believe the value of the technique includes. And don’t be confused, there …
