Refactor Your Tests

TDD Pro-Tip: I spend considerable effort making it possible not only to implement a test I want, but to make that test easy to read, to write, to run, and to debug. I’ve talked a lot about five premises of TDD. The money premise, the steering premise, and the chaining premise all get involved when we come to the coding of the tests. We do TDD to ship more value faster, the money premise. What makes it able to do […]

Refactor Your Tests See Full Post

Create Experiences Not Arguments

Change Pro-Tip: When I can give people an experience, I get dramatically better results than when I give them reasoning. I’mo tell you one of my stories. Twenty years ago, with a considerable amount of "Shut up, I’m the pro from Dover", I got permission to do TDD in a corner of the app I was working on, an app that walked remote groundstations through reconfiguration using a "console". My buddy and boss Gary was unimpressed, but I had permission,

Create Experiences Not Arguments See Full Post

Refactoring: Side-by-Side v. In Situ

Refactoring Pro-Tip: As soon as I move beyond small-scope refactorings, I ask whether my change would be easiest side-by-side or in situ. Before we even start this conversation, remember remember remember: easiest nearest owwie first, and keep repeating it. This conversation happens after we’ve found everything we can do in a scope of one or two classes. We write code iteratively in the modern synthesis. Our designs don’t burst Athena-like from our heads, fully-grown and ready to provide wisdom to

Refactoring: Side-by-Side v. In Situ See Full Post

From Procedural to Human

Yesterday, we talked about Alice’s City On The Hill and her approach to getting there. I offered, instead of the Alice approach, an approach that was Human, Taken, Local, and Iterative. Today, let’s consider this business of Procedural -> Human. Every system for making software is a mixed system, with three kinds of thing in it: the human kind, the artifact kind, and the procedural kind. Humans are, you know, persons. Artifacts are things like the code, the tools, the

From Procedural to Human See Full Post

Alice’s Approach To Change

Change Pro-Tip: It’s common, but mistaken, to believe that some change I want to make will be procedural, given, sweeping, and final. Let’s imagine someone, we’ll call her Alice. Alice is a mid-level manager, a department head let’s say, neither quite at the top nor quite at the bottom. She’s got some power, but not all the power, and she has a very strong desire to change how her organization works. You see, Alice has a vision — inspired perhaps

Alice’s Approach To Change See Full Post

What We Can’t Change

Change Pro-Tip: We can’t (purposefully) change what we don’t sense, what we don’t talk about, or what we assume can’t be changed. I remind myself of this one a lot, because it’s easy to forget in the middle of the circus that passes for professional software development. Changing things means going from A to B in, idunno, operational space. For me to do that well, I need awareness of A. I have to be able to sense what I or

What We Can’t Change See Full Post

Change Pro-Tip: Lining Up The Betters

Changing Pro-Tip: When I remember to line up the"betters", so my "better" is their "better" is his or her "better", my changes go a lot better. A refresher, my definition of coaching is "Creating or exploiting openings through which individuals, including sometimes myself, can step closer to who they wish they were." This is all about "better". When I am being paid to make changes in organizations, there are always a bunch of these "betters" floating around. There’s almost always

Change Pro-Tip: Lining Up The Betters See Full Post

Change Pro-Tip: All The Knobs A Little, All The Knobs A Little

Change Pro-Tip: All the knobs a little, all the knobs a little, over and over again, is how I’ve make my most successful changes, in code and organizations alike. A while back, I mused first about "Always Small, Always Improve" and I later elaborated "Always Small, Always Better, Always Wrong". Lo these two decades ago, we characterized eXtreme Programming as turning all the knobs to 11. I’ve always loved that metaphor, and I still believe in it. But my strategy

Change Pro-Tip: All The Knobs A Little, All The Knobs A Little See Full Post

Geekery Pro-Tip: Think Less, Sense More

Geekery Pro-Tip: I frequently remind myself: Think Less, Sense More. It’s advice I give to me all over the place, from the most technical parts of the sociotechnical fractal to the most social parts of it. It’s an odd thing to say, so we better dig in to it a little. I’ve recently come from a conference. This was a good one for me, full of old friends and new, smart crazy passionate people coming together to figure out what

Geekery Pro-Tip: Think Less, Sense More See Full Post

Scroll to Top