Coaching

I am supposed to be shooting the next Real Programmer episode today, but I had a really good wrap-up meeting that was important, and I’m waiting for one more piece I need to send a first invoice to a new client, and I want to talk about coaching. In another part of the forest, some folks are discussing the frustrations of what is, by whatever name we call it, coaching. And the long and the short of it is "they […]

  A lot of the reasons that change fails, inside & outside technical organizations, come down to one broad statement: the people who have to make the changes are humans, and the people who want them to make the changes have not successfully taken this into account. Before we proceed: Changing a software development process is kind of a sideshow to me right now. Changing the world out on the streets is the real story. Black lives matter. Please go

More seriously, the first piece of advice I’d give a monolith-owner about converting to microservices would be to work very hard to factor their monolith well. Interestingly, across dozens of cases, I’ve never seen that advice taken. There’s always a well-dressed person with excellent powerpoint who is happy to give a compelling case for a technical solution to a problem that isn’t technical. If you can’t factor the monolith, you won’t be able to factor your microservices. All of the

Lotta inspiration for junior geeks stuff floating around. I’m having a low productivity day today because, well, you know all of that, so I’ll take a minute nd pitch in. Do you know what I did for about twelve elapsed hours of coding time? I solved a problem. Cuz, you know, I got mad skillz, and have been geeking for forty years, and am even, in a couple of microdomains, a bona fide citable expert. I’ll tell you the problem

Now we’ve seen these basic ideas, human, local, oriented, taken, and iterative. I want to use them in a particular way for a bit. Let’s take some practices we know we like, and work backwards, seeing if/how these "known-goods" relate to those ideas. Let’s talk about "Working By Stories" for this first one. I’ll describe what I/we mean by that, and then we’ll try to look at it through our change-harvesting lens. I had thought to do TDD & Refactoring

TIme to take up “iterative”, the last, but by no means least, of the bywords of the change-harvesting worldview: human, local, oriented, taken, and iterative. Previous Posts in This Series Here: Human Change Local Change Oriented Change Taken Change The heart of the iterative approach is assuming change. We embrace it, we plan for it, we expect it, we encourage it, we enjoy it, we see it as the central act that defines what we are and what we do.

Human, local, oriented, taken, and iterative, those are the hallmarks of the change-harvester’s approach. This morning I want to tackle “taken”, which is about grounding the substance and approach of our changes to the situation that is already there. Want to catch up? Previous articles in the series here: Human Change Local Change Oriented Change Taken has several layers of meaning to the change-harvester, but the simplest way to say it is just this: To get to there, we want

The change-harvesting approach has these elements at its base: human, local, oriented, taken, and iterative. Today, I want to talk about what that adjective “oriented” means. Prior muses on human and local are here: Human Change: What and Why Local Change: What and Why We’ve said that leaning in to the humans in our systems leads us to locality pretty directly. We say “find the smallest easiest nearest change with detectable outcome and make it”. But this gives us a