2017

I’ve got more to say about interactions between humans at that level just above behavior and just below openings, lots more. But I’m going to jump ahead, then circle back. I want to list a bunch of things I do during my coaching days. It’s likely only a partial list, and as always, I reserve the right to change my mind pretty much at will. This list is made of gerunds. Gerunds are verbs turned into nouns for grammatical ease. […]

I spoze today is as good a day as any for me to start talking about what coaching is, about what I do and how and why. Tho I have these conversations in private, I have put off doing it here. I think it’s a mix of factors. Two amusing ones: i’m not very sure I have words for it. And i’m not sure I want to argue about it. 🙂 I am a software development coach. What I do

We spoke of always-small-always-improve (ASAI), arguing for it as strategy against big-bang-change (BBC). In another part of the forest, someone has asked the question, "what if the cost of delay for starting small instead of going big is extreme?" A situation where a BBC is better because the cost of delay implementing ASAI is extreme is an "on paper" situation, not an "in practice" one, and it only works on paper because we’ve embedded it in a nest of un-true-to-life

A little coaching theory today, eh? Coaches seek to change how things go. They see what is here and they think it could be better. In fact, they usually think it could be rather dramatically better — not worth the trouble of being a coach if not. And our clients want us to make things better, too. Tho it must be said, they usually don’t understand what that better is or how it will work or the rather kind of

This branching thing. The idea behind branching is that it provides advantages in situations where a code change is large. The idea behind non-branching is not to enter those situations. These two views seem very difficult to reconcile. I am a non-brancher. I push to head, I pull from head, I test on head, I ship from head. Let’s take a second to consider the arguments against living like this. First, a whole team that lives like this is constantly

I mentioned endpointing yesterday. I’m always using geepaw-isms & expecting people to know what I mean. Endpointing is over-focus on eventual destination. In s/w, it’s seeing development as a long trip to a known destination on a known map. John Winthrop, a few centuries back, used "the city on the hill" to describe an endpoint, in his case for the puritan colony. The metaphor, of a trip to a place, is as natural as any human expression. But it contains

Of all the bad advice the geek trades inherit from over-simplified manufacturing & engineering, perhaps the worst: "avoid changing code". Take a minute, and think of all the things the trade does to avoid changing code. Virtually every element of "big design up front" policy is based in this view. Long stretches for analysis, longer ones for design. Planning cycles that extend years into the future. Years. I am not exaggerating for effect. Years. Contract-like specifications, database designs that start