The main TDD disabler we’ve already met: a broken or too-slow build/run/result flow. If your team has that issue, throw all your weight at it, and do not try to launch TDD itself.

It’s very important that the team’s initial experiences with TDD are not blocked by externalities. Whether its easy or hard to roll the first few microtests, the difficulty needs to be focused on the pre-TDD code, not the process itself.

If you have a disabler, your coaching story is clear: we can’t do TDD until we fix it. Once the disabler(s) are cleared, we need to turn to the various factors that don’t quite stop the show: the inhibitors.

Inhibitors

An inhibitor doesn’t block TDD, it just makes it harder to apply.

(Don’t relax: if you pile a few of them on, you’ll long for a good old-fashioned disabler, because it would at least have kept you off the TDD road until  you tackled it.)

Inhibitors are usually about technique.

(And still don’t relax: you can’t simultaneously introduce 82 slightly different variants of technical solutions.)

Let’s take one detailed example, then sketch a few others with their related solutions.

The Promiscuous Database

The promiscuous database is an inhibitor I’ve found very common, especially in IT shops. It’s easy to spot: just grep the source for “SELECT” and inspect the results. In a typical nightmare, virtually every source file will contain explicit SQL.

(Sometimes there is some awful framework in place, that makes the grep not look so bad, because the actual SQL is in some bizarre xml file. Same problem, different grep.)

The promiscuous database does its damage by forcing all microtests to rig up the database and then connect to it. How do you spell heartache?

Moving The Database Out

The solution is straightforward: extract each SQL statement, or each hardwired database statement, into a separate class named for the intention of its calls. Now we can easily use a hand-rolled or automagic fake.

Some details:

• Name the class for its intention, e.g. GetOutstandingLoans, not ComplexSQLCmdWithThreeParameters.
• Pass the parameters in the constructor.
• Return typed containers.
• Discover, don’t pre-implement, shared code to pull up.
• Consider a hierarchy based on command return-type rather than ‘tables touched’
• You may want to use a factory approach for getting the actual command.
• You certainly want some way easy way to slip a fake in. This can be done at the caller’s constructor, or just use a factory method that can be overridden.
• Wonderful side-effect, it often shows you more dup than you thought was present.

I hope this solution isn’t too telegraphic. If so, holler at me in the comments. The real point here is that we’re talking about learning and using programming technique to solve most inhibitors.

Readily != Painlessly

It is readily possible to solve the promiscuous database using coding technique. But readily doesn’t mean painlessly in the beginning.

Everyone who’s got work in the caller-class has to be able and willing to do these extractions. It can be done, but until a few tries are under a noob’s belt, it will feel like a useless formalism.

This is the general tenor of working against TDD inhibitors.

Let’s sketch a few more inhibitors and their solutions.

The Very Large GUI Of The World

GUI classes that do frighteningly complex work are the bane of any team working legacy TDD.

The problem here is tremendous and obvious: you can’t test the functionality without launching the GUI itself. Say goodbye to rapid feedback.

The answer is easy, or easy-esque: create a class whose lifetime is exactly coterminous with the GUI class, then rework your GUI class so that all non-graphical work is done by the shadow class. Turn the GUI class into a specialist who removes GUI-isms before passing on to worker, then puts GUI-isms back in on the way out.

The Hardware Distraction Layer

Direct calls into the hardware are everywhere. This is a hallmark of the embedded scene. Look for globals.

Solution: You need an adapter that fronts just the calls that this particular client needs. Work to make that adapter really hide the underlying dependencies. Once done, you can readily fake the adapter as needed.

The In-House Framework Of Universal Despair

The colossal ass-hattery known as “our in-house framework” is often an inhibitor par excellence.

The framework provides needed services, such as a database connection, that we don’t know how to get access to without launching the framework.

In this case, usually we’re seeing significant work done in a class that derives off of something from the framework. The trick here is just another variation on the theme of ‘take away frameworkisms on the way in, and put them back on the way out’.

Coaching On Inhibitors

The meta-pattern for inhibitors is simple.

Coach two or three teammates through the process of working around a given inhibitor.

This will give you two key advantages: the ability to show multiple instances of ‘problem-solved’, and the support of the teammates who actually lived through the solution.

So? Use lottery learning, or some other meeting, to introduce the problem and its solution. Show them the two or three. (Without the show you’re just being an abstract chatterer.)

In early days, just make the team aware you want to be tripling any time that problem comes up.

Ultimately, early days pass, and you can say with some confidence that your whole team knows how to finesse the solved problem.

After that time, and only after it, the team can raise their standard of excellence to say “files like this are hereby declared TDD’able”.

Inhibitors Are Crushed By Experiences

Go To It

You should.

For those who haven’t yet, a code retreat is a long day of programming, constrained in such a way as to create an open-ended opportunity to learn.

The formula is simple: we do six sessions of paired TDD. Each one is on the same problem, but with a different partner. The code is destroyed at the end of each session. That is, each session starts entirely from scratch.

That’s all there is to it, or so I thought going in.

Getting Hooked

The remarkable effect of the constraints is to focus a very high intensity onto the problem domain and its potential solutions.

You care.

The problem itself is readily understandable, but its potential solutions are really not. They are just one hair too complex to hold in your head all at one time, which is brilliant.

A toy challenge would not work nearly as well.

On the other hand, if the challenge were harder, you wouldn’t, or at least I wouldn’t, approach it with the easy certainty that you know the solution already. The experience wouldn’t be nearly as valuable without the scorched arrogance.

Test First vs Test Driven

The certainty of solution starts boiling off in the first round, and somewhere in the third it runs out altogether.

This is good, partly because the smell of burning ego is good for the soul, but also because it makes it much easier to open one’s heart and mind to learning.

Once I got opened, I learned many things, some small and some not-so-small.

After the sessions, we talked about what, if any, lessons were learned. Perhaps the single most common statement was that the participant learned that having a pre-formed solution in mind could cause lots of pain.

Corey Haines calls this ‘pre-conceived solution’ thing ‘test first’, as opposed to ‘test driven’. It’s an excellent distinction.

The idea is that in test first you solve the problem in your head, then write a test to force that solution, then type it in. Truly driving by tests, on the other hand, means typing in the test with beginner’s mind, and starting to solve it only after you’ve written it.

That’s exactly how it should be in our daily work.

Old Friends and New

It was fun to see some old friends, my pal George Dinwiddie, and my until-now-twitter-only-friend John Stoneham. I knew Corey Haines from the scene, but mostly also on twitter, and it was a blast to get so much good time with him.

But it wasn’t just my old friends. Many of the folks there came from one or more of the sponsors. The local hosts, Gustin Prudner’s Entryway, did an amazing job. They procured and prepared two excellent venues for our sessions, and everything went off without any hitch.

I won’t list the new friends I made, but I was delighted to hang with so many people who clearly care about excellence in software development.

Geek Joy — *Shared*

The most important lesson was one I re-learned rather than encountering for the first time: to share geek joy is delightful, intense, and absolutely revitalizing.

I feel like I need to rush right out and do good geek work today.

I’m already on record for saying that what the industry needs most is to learn how to intertwine geek joy with business value. But to be reminded so forcefully is just terrific.

Go Sign Up Now

It’s Cheap And Amazing!

Me, Hunting For Yabbits

Ever get the yabbits when introducing a new idea?

Oh, wait, maybe I better define my terms first.

Yabbitting is when people go through a sequence of resistance statements, where each statement begins with the words, “Yeah, but…”.

Like this: “Yabbit, our shop does shrinkwrap, so what works for some web app isn’t gonna work here.” or “Yabbit, we all work 80 hours a week, so we don’t need slack.” or “Yabbit, if you write tests + code, that’s more code than if you just write code”.

Let’s try again: Ever get the yabbits when introducing a new idea?

Yes, I thought so.

Aren’t Yabbits Annoying?

Yabbits can get a person down.

Worse, if the person has GeePaw-ish tendencies, yabbits can really bring out the sarcastic asshole:

“Wow, you’re right. No one ever mentioned that to me before. I should probably leave, now. Thank you. Thanks, thank you. You’ve saved me a lot of wasted time. Uhh, bye.”

But responding to yabbits like this is a grave error. (Trust me on this.)

A noob coach usually sees yabbits as a huge annoyance at best, and a wall of resistance at worst, but this is a big mistake.

Getting yabbits should please you. They sound like they represent resistance, but they actually indicate just the opposite.

The Economics Of  Thinking

How many times a day do humans choose one thing over another? Certainly hundreds, if not thousands or tens of thousands. Which socks? Left or right? Coke or Pepsi? and on and on.

Many of these choices are somewhat automagic: the answers to them have typically been made way in the past, and are not really ‘re-chosen’ every time the question comes up.

Others, on the contrary, are the result of full and thorough efforts to consider variant choices, project their results, and decide how we feel about them.

So some choices are virtually free, and others are quite expensive.

So what’s the most frequent choice made by a human?

It’s the meta-choice, of course. Whether you make a cheap choice or a pricey one is itself a choice. Cheap or expensive?

Yabbits Are A Heuristic

Yabbits are actually a tool for making the meta-choice. It works like this:

If an idea can’t defend itself against simple one- and two-sentence arguments, then it certainly can’t handle any serious ones, so I don’t need to investigate in depth.

Yabbits don’t always, or even usually, represent real resistance to change. On the contrary, they are probes, whose intent is to test an idea’s prima facie validity.

A person who offers you yabbits is typically more open to an idea than a person who says nothing at all.

Responding To Yabbits

The most obvious aspect of your response is just to note that, since yabbits are a good thing rather than a bad, you should prolly refrain from indicating displeasure.

Now, I can’t say you should smile when you get a yabbit, because that can easily look like smugness. But you can respond positively. Never hack at a yabbit. Instead, relax, and calmly show exactly how your idea doesn’t suffer from any trivial  flaws.

The rest of this page is just a set of common yabbits, pulled from various practices in the agile toolkit.

Notice that each one is just a few lines long. That’s on purpose: don’t overload a yabbit with a long response. That’s using big guns on small quail.

Yabbit, We Want 100% Load

Actually, no you don’t.

100% load means full stop for most of the team. Don’t believe me? Think about the last traffic jam you were in. The optimal load of cars for a highway is far less than 100%. More cars != more throughput.

What you really want is optimal load, which is the highest load for which actual throughput continues to rise.

Yabbit, It’s Just Until The Release

I always ask teams about their last release.

So what happened? You shipped the release, then everyone took two or three weeks off to catch up with their families, or take care of their mental or physical health? No?

For some teams, shipping on Friday means coming in Monday and starting the next release.

For many, maybe even most, shipping on Friday means coming in Monday and immediately jumping in to hot-patch mode.

Yabbit, No Pressure Means No Production

You mean, you hired a bunch of people who won’t work if you don’t constantly harass them? What a drag. Next time choose different people.

Of all the bizarre taylorisms in bad management practice, this one is the least connected to reality. We are called geeks precisely because we take so much joy from our work.

You don’t have to force geeks to do geek work, you have to get out of their way.

Yabbit, How Can We Assess Merit?

This one tickles me, too. The idea is that the marathon and village principles seem to work against the easy assignment of rewards to individuals. If we pair all the time, rotate pairs all the time, and all sit together and work, then how can management tell who to reward and who to punish?

You can assess merit by a) working with the individual, or b) watching the individual when she is at work, or c) asking the people she works with.

It is trivially the case that everyone on a team has a complete ordering of merit for everyone else on that team. Gather the orderings (not the votes, the orderings) anonymously, and you will certainly see a pattern. Use that pattern as the basis for your assessment.

Yabbits Are Your Friends

It is easy to think of yabbits as temporary distractions from the real game of changing behavioral patterns, but that’s a mistake. Answering yabbits won’t change anyone’s mind, but it will build confidence and support for your ideas.

Yabbits Are On The Road To Success

Use all of the coaching pillars to help instill the message:

• Situate by teaching and explaining the beliefs.
• Model by living them publicly.
• Invite by having fun writing microtests.
• Sort by leaving time for skill development.
• Release by letting them manage the ‘must-test’ list.

Required Understandings

Each of the sections below is a statement of belief we want all of our developers to be conversant and comfortable with.

Imagine your teammates talking to members of a non-TDD team. If they can spontaneously explain and defend their behaviors using these beliefs, we’ll have won most of the battle.

We’re In This For Productivity

You know my rant on this one. TDD is not about quality, it’s about speed.

I often use the comical fact of ‘night-coding’, i.e. programming for your own amusement.

When I’m night-coding, I rarely write storytests. Storytesting is expensive on code not built for it, and besides, storytests are really a collaborative tool. I already collaborate well with me, so I skip storytesting. (Some agilists are disappointed with me about this. I tell them to go to the back of the complaints line.)

On the other hand, I always use microtests, even for night-code. Driving development by microtesting is a productivity tool. Even when I’m in the privacy of my own back porch, I want productivity. Everybody wants productivity.

There’s No Free Lunch

But don’t kid yourself. TDD is not free.

Some ideas are simple facts, really. Once a C++ programmer learns why she should default to ++i rather than i++, it’s pretty easy to just always do it without much thought. Simple facts deliver their value instantly.

TDD is not a simple fact, it’s a whole way of programming.

Ask people how long it took for them to learn programming in the first place. The good news is that it will take much less time to learn TDD, because they already know the syntax, the tools, and the problem domain. This time they just have to understand a loose cluster of a couple dozen techniques.

But it ain’t free. Your team is going to have to practice practice practice. Make them — and their managers — completely relaxed about this.

We’ll Adopt TDD Sanely

Remember the sit-in-your-own-lap transition? How can we get TDD all-at-once-a-little-at-a-time?

We make a list of classes called the ‘must-test list’. If a developer is going to touch a must-test class, she has to use full-on TDD: microtests written before changes, the ol’ red-green-refactor-integrate cycle, the whole kit and caboodle.

Over time, we grow the must-test list in two ways.

First, we grow it by turning more and more classes into ‘must-tests’. We do that by fixing awkward dependencies, either at the class doing the calling, or the class being called.

Second, we grow it by learning the patterns of refactoring that can make a non-testable become a readily-testable. Each time we get the whole team to perform a new refactoring, we can add classes that would be testable if only we knew that refactoring.

Let’s do an example: many teams have yet to recover from the singleton pattern, so they have classes that depend heavily on global data. Using alternate constructors is a simple  pattern that can solve this problem. An hour of study and one successful attempt, and you’re good to go. Once the team has that pattern, we can add to our must-test list classes that would be readily testable except for their use of globals.

The must-test list starts life as a list you control. Think in terms of adding two classes a week in the beginning. Make the changes in the must-test list at the iteration break, say, during the planning. As the team builds their experience and excitement about TDD, you can gradually hand over management directly to the team.

Coach The Inner Game
Give Their Minds The Right Stance

Sometimes I do it by itself, as in the DoubleDawg. Mostly, though, I do it inline as part of the TDD discipline. I love it either way, and I can’t explain why.

Loving refactoring so openly is good good good when I’m coaching: other people can’t help but watch what I’m doing and then try to see if it’s really as fun as all that. (It is.)

But once a team jumps into the act itself, there’s a question that just has to pop into some minds, especially the ones who feel it’s very important to, you know, ship:

How Do I Know When I’m Done Refactoring?

“You’re done refactoring when the code meets our current standard of coding excellence.”

I’m always surprised when someone just nods their head to this and turns away, as if I’ve actually given an answer. I guess questions can sometimes be pro forma gestures, too.

Anyway, that’s a terrible answer, but on good days it leads right to the next question: What’s our current standard of coding excellence?

The Challenges Of Standard-Setting

Setting standards seems to cry out for the clarity and detail of a perfectly written set of rules. Ya know? If we just sat down and carefully listed all the things you can do, and all the things you can’t do, using maximum simplicity and maximum clarity, we’d have a perfect standard.

Then there are those of us who have either studied law, or babysat a truculent nine-year-old, or both.

1. We want our rules to cover everything, but only a small handful of situations can really be described that way.
2. We want our rules to be stable, but time and experience make mockery of our earlier attempts, time and again.
3. We want our rules to be axiomatic, but as Kurt Godel demonstrated, any such that are sufficiently powerful to be of interest are also suffiicently powerful to contain undecidable propositions.
4. We want our rules to be simple and no-nonsense, but as any handy nine-year-old can demonstrate, when it comes to misinterpretation, where there’s a will there’s a way.

So? What to do?

The Simplest Thing That Could Possibly Work

When I first studied the XP process, I was struck by Kent Beck’s ability to construct rules that were as perfectly detailed as they could be, but no further.

“Do The Simplest Thing That Could Possibly Work” is a wonderful example of this.

Without a rigorous definition of simplest, possibly, and work, a computer would find this rule absolutely empty. All the important words in the rule are left to individual human judgment. Defining them would take years and years and would still fail. (Read the XP list some time.)

But the rule works in spite of the uncertainty, because it contains an implicit ‘you’ for each of the ambiguous words. Simplest means simplest-to-you, and possibly means possibly-to-you, and work means work-the-way-you-want.

Notice that this kind of rule completely evades the problems list from above. Clever.

My Rule For Refactoring

You are done refactoring when you’re ready to project the code onto the wall for the whole team to see.

This rule works just like the XP ones: it is full of opinion, judgment, and you-ness.

This rule works best when its coupled with actual code projection, along the lines of a lottery learning session.

I like that we simultaneously release the team, empowering them to decide for themselves what’s enough, and also situate them, showing them that their coding standard is going to be super-local, theirs and theirs alone.

I also love that I get to watch the actual meaning of that rule change. Every actual projected code session makes changes to the underlying meaning, and so do most pairing sessions between a junior and a senior.

Use The Projector Rule

To Identify The Moving Target Code Standard

The automation principle is  one sentence long, but it points a dozen directions at once.

Teams are usually all-or-nothing in automation. Once a team realizes how lovely it is to not-think on no-thinking-required tasks, they jump right in and build or tune all their tools for maximum advantage.

Don’t you worry, I’m just sure your team will be one of those easy ones. If that’s the case, you can just skip this article and make a cash donation to the charity of your choice.

Urgency + Automation

Ahhh, yes, not one of the lucky ones, eh?

Your first challenge is just to decide what your first challenge is. The sheer number of possible automation stories is daunting: it’s one of the biggest reasons I advocate the half-and-half transition. A sizable portion of your energy can then be given just to tackling automation stories.

The Inner Cycle

The inner TDD cycle is always the most urgent target for automation.

We need a single-step for “save my changes, compile/link/copy, and if there are no errors, launch the microtests-of-interest”.

• Save my changes: Many almost-ready automation sequences shortchange this step, but it’s important. You never want to run your microtests against the code before your changes.
• Compile/Link/Copy: The two most important issues are the 100% problem (for optimal builds), and for some teams, the need to take binaries and put them in the ‘right’ place for running.
• Run Microtests-Of-Interest: some teams stumble here. The final step of the inner cycle is to run and examine the microtest results. Starting the actual program running is not a necessity.

It’s important to understand that we are not looking for three separate gestures here. We want all of the above action to happen with a single gesture.

Integrate It!

Next after the inner cycle is integration. This time, it’s not a single gesture:

• Show Me Everything I Changed: The output should be in the identical tree shape of the source. If you made some changes you don’t want, revert them here.
• Merge Out: Bring me everyone else’s changes, with a merge system for each collision between my changes and theirs.
• Run Inner Cycle: We’re not done merging out until the microtests run green.
• Commit Everything I Changed: Usually there’s another round of show-me here, followed by the actual commit.

When we can do all four of these actions with simple and thoughtless gestures, we’re in good shape.

The Trap Trio

The integration automation is a good place to consider the three most likely coaching difficulties, as they each can be found there. These are all noob problems: an experienced automater sees these situations all the time, but doesn’t fall for them.

All-Or-Nothing-At-All: Engineers, yo. They get trapped here because they can’t think of an automated solution that solves every conceivable variant. This is an easy one to resolve: teach them how to implement their scripts and macros as fail-fast. If our scripts can establish that it’s a situation they can’t handle, then they can fail right out. Sometimes 91.5% is just fine.

Mind-In-The-Middle: Automation can’t work because there are some sub-steps that absolutely require human intervention. No, that’s not quite it. It’s because there are a bunch of mind-needed sub-steps, spread throughout the process. This problem might fall as in all-or-nothing: automate what you can, don’t sweat what you can’t. But more likely, a clever person can smoosh the sub-steps in time, so that the mindful parts are all in the same place. Then we just leave that single hole in our automation and have everything else mechanical as can be.

More Controls = More Control: This one’s endemic. Folks who couldn’t code a fucking for-loop sitting in front of the jet cockpit of a universally-mandated fabulously-expensive entirely-wasted version control system like they have some clue what they’re doing. These systems justify their wretched excess on the theory that they give you every conceivable control over your integrations. Agilists in particular should not buy this theory. The resolution? It’s a combination of the two that just came: rearrange mindful steps, and settle for less than perfect solutions. In particular, don’t be afraid to write front-end scripts that quietly drive the VCS for the most typical variant.

A Radically Simplified VCS

Leading Automation Efforts Is

Perfect Releasing!

To me, the most amazing thing about the urgency principle is how I ever managed to live without it.

As an individual, it reminds me to stop screwing around doing stuff that is anything less than the most important thing. This works for me whether I am coaching, coding, writing, blogging, or doing home repair.

The quantity of empirical data that says multi-tasking is inefficient staggers a researcher’s mind. No one advocates doing two things at the same time. It follows, then, that if I’m not doing two things at once, I have to choose which one of those two is most important and do that one.

As For The Team

As a team, the urgency premise is all about sorting user stories – software development for the business – into a literal stack, where the most important story is at the top and the least important at the bottom, and every story between is more important than the one below it and less important than the one above it.

Many companies bucketize their work. They pick some small integer, usually 4, and divide all their stories into those buckets. They’re usually called “Must-Have”, “Should-Have”, “Like-To-Have”, and “Optional”. This technique has the rather remarkable property that it does not work in any way. Every customer voice in such an organization knows that the only way to get something actually done is to get it into Must-Have, and even that isn’t always enough to guarantee its inclusion. Optional is always empty, and Like-To-Have has one or two token stories.

Coaching Urgency

The key to coaching urgency successfully is to help the team understand why story-size is so important. Granularity is key, here. We want them to understand why we shrink the granularity of stories as small as we possibly can.

Take a look at these features (large stories) sorted by importance:

It’s pretty easy here to say that we should do our work 1-2-3-4, yes?

Same Order, Smaller Stories

But what if we take those same four features, but this time broken into smaller stories. Everything in the figure below that isn’t in light blue is lost value. If we follow the 1-2-3-4 strategy, we’re going to implement B and C before we implement D, and that’s clearly sub-optimal.

The Actual Optimal Order

The final figure below shows the same work as before, this time sorted absolutely by value. Do you see that by splitting and re-sorting we have dramatically changed our implementation order? So will your customer team.

The shape here is called the diminishing value curve. Producing stories A-D-B-G-E-H-F-J-C-I-K-L is far better suited as a strategy. If that’s not obvious, let’s take the same diagram and add a shipping date:

There’s room here for another whole conversation about the shape of a user-story. Soon, soon. For now, this will do:

Choose One Story, Hammer It. Repeat

Me, Talking While Someone Hands Me A Beer

If I asked you a question about our process, would you be ready to stand up and pronounce, right on the spot?

Talking in front of groups is so obviously part of coaching that it’s easy to underestimate its importance. If you’re going to be a great coach, you’re going to have to be a good off-the-cuff speaker.

The Basics: Practice Practice Practice

No matter what style of coach you are, there are a handful of basics that always apply:

• Speak to everyone, one person at a time: make eye contact, one by one, with everyone you’re speaking to. Practice this until you do it without thinking.
• Learn to pause without sound. Uhhs, ya knows, likes, and so on feel like they’re helping, but they’re not. People like that you take time to formulate your words, even before you say anything at all.
• Punch the message. All of my worst speaking experiences have been when I lost my message, then dribbled off into pathetic uselessness. Outside the NBA, nobody likes a dribbler.
• Master saying I don’t know. There are several different good ways to say this. Again, people like that you sometimes don’t know. It builds trust and confidence for when you do know.

If you’re just getting into this bizarre gig, and you don’t feel happy when you have to stand up and give talks, it’s easy to get basic training. I strongly recommend Toastmasters International. They will help enormously.

In any case, keep practicing. Study doesn’t really repay much when you’re just getting started. It’s the practice that counts.

Intermediate: Only Connect!

When E.M. Forster wrote Only connect!, he was talking about humans making contact with each other.

Yes, of course, connect with your audience. Use your empathy and your experience to feel your way into subtexts, fears, and so on.

Excellent talking includes another kind of connecting: the kind where you tie what you’re saying now to what you have already said, or better still, what the team has already done. I use the principles of agile development constantly when I coach, and I try to tie every idea or judgment back to them.

Perhaps the last intermediate skill would be the delicate demurral. It is the way of things that you will be asked as a coach to publicly evaluate baseless, bizarre, bogus, and bad proposals. Let ‘em down easy. Kindness knows no shame.

Mastery: Watch, Study, Learn.

Some suggest that masters of public speaking have no fear. I doubt it. Masters have fear, but they harness it to help them deliver intensity and passion, and that’s a wonderful thing to see. Watch the best speakers around you.

Eventually, you may want to study rhetoric. I find that Silvia Rhetoricae is an awesome site for discovering the figures of speech. A figure of speech is a kind of language design pattern. Fascinating stuff

Read speeches. For an amazing read, try Gary Wills’s Lincoln at Gettysburg. His analysis of the Gettysburg Address will make you hunger for more.

One More Thing:

Use This Power For Good

Among my favorite books about writing was The Art of Fiction: Notes on Craft for Young Writers by John Gardner. It was the first time I learned about profluence.

Me, At The End Of My Profluence

Is This Going Somewhere?

Think of the most recent time you told someone a story.

I’m not talking here about telling a fairy tale or a novel. Most stories are just a few sentences long, and they are ubiquitous in human conversation. Take a glance back up at the first paragraph of this article. That paragraph consists of three sentences, and I am clearly telling a story.

Not much of a story, but compare that to the next paragraph:

Last night, we had dinner out, and Virginia was chatting with the folks sitting next to us at the bar. The music playing was Thai pop.  Thai pop is kinda icky if you ask me.

What’s Missing?

What is missing is profluence.

Profluence is the sense that we are getting somewhere. It’s one of those aspects of human interaction that usually hides in plain sight. The next time you find yourself justifying some action, listen to yourself creating flow. Each sentence of your explanation takes the story a little further.

Human beings constantly create narratives as they go. The neurologist William Calvin once remarked that we should be called homo seriatim instead of homo sapiens: We do way more stories than we do wisdom.

Why Profluence Matters To A Coach

Simple.

The Harvard Business Review offers this key finding from a multi-year study of over

Having just completed a multiyear study tracking the day-to-day activities, emotions, and motivation levels of hundreds of knowledge workers in a wide variety of settings, we now know what the top motivator of performance is [...] It’s progress.

They go on to explain that when workers have a sense they’re making headway, or when they get support that helps them overcome obstacles, thats when they are most highly motivated.

Using Profluence To Coach

Knowing this tremendous power, we can jump in as coaches and create or heighten the profluence in our teams:

• Identify poorly motivated folk and re-frame their story as progress.
• Use big visible charts with data that changes every other day.
• Find victories for every standup, and make sure they rotate the credit.
• If a whole team is off, help them create the story in which they’re profluent.

Creating profluence for your team is an act of both situating and inviting. Don’t go for a huge outpouring all at once. Instead, look for two or three events per week that you can weave into your ongoing progress.

Keep Your Team’s Story Moving,

And They’ll Keep The Project Moving.

I finished the book, set it aside, and cried for a while.

After maybe 15 minutes, I opened the book and started over at the beginning.

Rebel With No Appreciable Cause

The greatest tool in the hands of the oppressor is the mind of the oppressed. – Steve Biko

I love that quote. It’s ludicrous of me to use it. Far from being oppressed, I am a white American male programmer born just in time to ride the great digital wave. That’s called “tall cotton” where I come from.

Still, neither nerd, nor geek, nor dork, nor the several others, were originally intended as terms of approval. I don’t like nerd. The k’s in the other two ring the Anglo-Saxon bell, but nerd just has a snot-nosed-ness about it that I don’t find appealing.

I’m actually multidorktual, myself. Computers, history, literature, music. Last year a guy in one of my classes used a particularly lovely phrase: he said I was a renaissance dork.

What Is A Geek, Anyway?

If you surf  around a little, you’ll gather a reasonably accurate tag-cloud for these words. Mostly the focus is on “poor social skills”, or “obsessive behavior around things technical”, and so on. Gross generalizations blah-blah-blah, but yeah, I know what they’re talking about.

Geek originated as a slang word to describe a “wild man” act at a carnival sideshow. The act typically climaxed when the geek tore the head off a live chicken with his teeth. I get it.

Anyway, they miss the point.

They spend a lot of energy noting how different we are from them, but they never mention the thing that stands out most clearly to me.

It’s The Joy, Stupid

It is the joy, you know.

They don’t mention it so much: “Oh, look, it’s those awful joy people again!”

You don’t have to be a geek to see it, you just have to look closely. Go find some dorks hanging out together, working on something, and just watch and listen. They sure do seem to be having a good time.

Geek Joy, Excellence, Business Value

If you want the heart of my coaching philosophy, there it is. I believe that if we can connect business value to geek joy, the result will be excellence.

Whenever I try to help a team, the first two threads I start are:

• How can we get more geek joy?
• How can we know what’s valuable to the business?

The rest is just tactics.

Those twin tracks will consistently take you to the heart of the coaching enterprise.

(Did You See That?)

A Hero Of Mine

Heh.  I totally just did GEB back up there. Heh.

I’m no Hofstadter, though, so that’s prolly the last time you’ll see me do that.

Douglas Hofstadter is the greatest geek of the last fifty years. I couldn’t carry his slide rule.

Oh, the crying?

Up until that time, I thought I might be the only one of us.

Silly Child.

They’re Everywhere.