August 2017

On Pedagogy In The Geek Trades

I find 4 major failings in both how & what we teach in geekery. We mostly don’t. That is, actual teaching of actual geekery-for-a-living is almost non-existent. We suffer in attitude & content & structure from the trivially flawed “information transfer” view of what teaching & learning is. We purport to more knowledge than we actually have, teaching crude guesses as if they were writ, and aphorisms as if they were Euclid. We withdraw the field, abrogating our responsibility and […]

On Pedagogy In The Geek Trades See Full Post

Reversible Raincoat Tests

Let’s review "reversible raincoat tests." Sometimes, we build systems in which a downstream collaborator must interface with an upstream one. The two apps are by separate teams, on separate servers, developed at separate times, and still both in development. A reversible raincoat test is a script with two sides. Think in terms of a literal script, like in a play. "Mike: hi mom. Mom: hi son. Mike: is today tuesday? Mom: no, doofus, it’s thursday. Mom: gotta go, basement is

Reversible Raincoat Tests See Full Post

On One Ring To Rule Them All?

Yesterday I mused about explanation privileging, where one always reaches for one ring to rule them all in their explanations of behavior. This morning I am thinking about the reasons that happens. Don’t be alarmed, i’m not gonna suggest there’s just one reason for it every time it happens, i’m circular, every argument is circular, true enough, but i’m not that circular. It takes more than one step. 🙂 one reason it happens is biology. There are huge biological reasons

On One Ring To Rule Them All? See Full Post

Choosing A Coaching Story To Work

Still feeling it, so, a sidebar on choosing which coaching stories to work… I was raised in XP, and as such, I imbibed the concept of "most important story" heavily. When I’d show up at these shops, I’d be replete with the wonder of myself, and I’d look out on the horizon of broken things, and I’d pick. And I picked "the most important story". To me, that meant the thing that is most ruining their ability to ship. But

Choosing A Coaching Story To Work See Full Post

Why Do We Seek One Ring To Rule Them All?

I’m thinking of this thing called "justifcation privileging," or alternatively "explanation monism". Or even, short hand and jokily, "one ring to rule them all." One constantly sees tweets, blogs, even books, where someone boils down staggeringly complex and ill-understood processes to one factor. Today I saw "people don’t make decisions rationally, they make them emotionally." Now, set aside for the moment that no one even knows what those words mean other than at some vague gut-check level, even then, it’s

Why Do We Seek One Ring To Rule Them All? See Full Post

The First Coaching Days

I can’t over-emphasize for new coaches the importance of rampant opportunism. Until you’ve established your miracle powers in a team, you won’t be able to move big levers, only small ones. Which small levers will bring you the biggest bang of trust & faith the fastest? Some possible openings: we find a bug that’s an exemplar of a family of bugs, and we refactor so it never can occur again. Or we have an untestable, if they’ve started TDD’ing, and

The First Coaching Days See Full Post

Shifting Certainties

Shifting certainties. This is where i’m headed these days. Without belaboring criticism, what i’m seeing is that we have a trade with a whole stack of roles and humans to fill them, and, of necessity, they have assembled a varied, sometimes compatible sometimes not, set of certainties by which they navigate. The trouble is that, even when the certainties align with one another, they, ummm, aren’t. That is, they aren’t certainties at all. Neither our data nor our experience actually

Shifting Certainties See Full Post

Refactoring Testless Code

Refactoring in testless code is hard. It’s the perfect demonstration of the manglish "agency" of code. It is simply not possible to change testless code and guarantee you’ve done no damage. It’s one of the most delicate operations geeks do. There are principles, yes. There are tricksy techniques, too. But mostly, there is experience & judgment. The deep trick is to turn every mistake you make into a microtest that would keep it from ever happening again. A key insight:

Refactoring Testless Code See Full Post

How I Don’t Apply XP, or Scrum, or Anything

These wrangles over system seem mis-focused. Moreover, they seem part of the surface of the elephant i’ve been trying to describe. A system is inherently an abstraction. It compresses, filters, selects, features from an experienced reality. We formulate systems for at least 3 reasons. First, so we can establish commonality. That is, we can use one system to describe a bunch of "different" local realities. We can say, "yes, that’s python and the web, that’s c and the pacemaker, but

How I Don’t Apply XP, or Scrum, or Anything See Full Post

Why I Write A Test

My intent in writing a test is to satisfy myself by the cheapest means possible that the code does exactly what I think it does. I stress that this is my intent. Believe me, fifteen minutes on the internet will reveal to you a barrage of other possible intents. Surely, by now, it will be clear to you that i’m not an essentialist, but an extreme pragmatist w/strong existentialist leanings. My intent is to use the test to underpin my

Why I Write A Test See Full Post

Scroll to Top