muse

Coaching is X-ing: Things I Do When I Coach

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. …

Coaching is X-ing: Things I Do When I Coach Go to Post »

Coaching: What I Actually Do

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 …

Coaching: What I Actually Do Go to Post »

ASAI: What If That Takes A Long Time?

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 …

ASAI: What If That Takes A Long Time? Go to Post »

Always-Small-Always-Improve: A Coaching Vision

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 …

Always-Small-Always-Improve: A Coaching Vision Go to Post »

Drive, Sustenance, Collaboration, Stepping, And Narrative

Take for granted for a minute that professional software development is a complex problem, in the sense of complexity theory. I have in recent months been fretting, then, at how to optimize for s/d given that fundamental complexity. Problems that are merely intricate have the property that when you strike them sharply they break into smaller pieces. You get problem-shards, smaller ones, and hence more soluble, less intricate. Rinse, lather, repeat, and they eventually get "’easy". Complex problems don’t have …

Drive, Sustenance, Collaboration, Stepping, And Narrative Go to Post »

The Baseless Critique Of Living Branchlessly

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 …

The Baseless Critique Of Living Branchlessly Go to Post »

Endpointing vs. Next-Stepping

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 …

Endpointing vs. Next-Stepping Go to Post »

“Avoid Changing Code” Should Be Avoided

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 …

“Avoid Changing Code” Should Be Avoided Go to Post »

Using Strategy & Function-Specific To Attack Large Classes

In IT work — "it puts the database on its browser skin" — we often face sooner or later the problem of the gigantic object. Some systems, especially "global monolith reboots", just start there. Others just grow and grow and insensibly slide into it over time. The problem is that there are one or a few objects that are just plain central to the domain. To forestall ron and his marick quote, I’ll use the classic ‘order’ as my example …

Using Strategy & Function-Specific To Attack Large Classes Go to Post »

Idols of the Schema: Ignoring Data While Overvaluing Ideas

The ‘idols of the schema’ is a geepaw-ism, and deserves some background & explanation. When we value the simplicity & clarity of an idea over the complexity & muddiness of its referent, we’re caught in an idol of the schema. Sir Francis Bacon was an english noble, a famous lawyer, and author of the Novum Organum, one of the seminal texts of empirical method. He wrote among many other things, of the ‘idola mentis’: idols of the mind, and offered …

Idols of the Schema: Ignoring Data While Overvaluing Ideas Go to Post »

Scroll to Top