Exploration Through Example

Enrique Comba Riepenhausen (@ecomba on twitter) has been demonstrating an interesting style of making a living. He travels around the world, working with companies as a programmer. When he’s done, he tells them to pay him what he was worth. That’s pretty much it.

I like strange ideas and relationships more personal than transactional, so I’d like to do this too. Here’s what I’m thinking:

• I’d like to program for you as a temporary, on-site member of the team. I prefer that to coaching these days, though the latter isn’t out of the question. I’m not bad at Clojure and Ruby¹, and my Java skills are adequate. Because I’d expect to spend a lot of time pair programming, the language isn’t nearly as much of an issue as it would be for solo work.

• I’d prefer to be in one place for one to three weeks, though longer or shorter is also possible.

• I’d like you to commit to paying for travel. (If I’m visiting more than one place on a trip, I’d divide up the responsibility.) I prefer you pay for lodging, but I’m also willing to couch surf (especially on shorter trips).

• I don’t care all that much about working on cool technology or products. I do care about the atmosphere of the team, because their mood strongly affects my own. I’m looking for teams that are optimistic, enthusiastic, context-driving and cheerfully naive in the way I talk about in this video. That rules out a large number of Enterprise teams, who so often seem incredibly burdened by the institution. (Though that does mean that the rare optimistic etc. enterprise team would be particularly tempting.)

• I have a chance to run my Top-down TDD in Clojure workshop in Oslo, Norway, in September, so I’m especially interested in European companies so that I can spend a month over there.

If you’re interested, please mail me.

¹If you’d like to see a sample of my Clojure work, here’s Midje. I can’t show you the Ruby code I’m happiest with, but you can look at Critter4Us.

I’ve been speaking about the desirability of what I call the stance of reaction in software development. Now it’s time to think about how to learn it. Since one of my inspirations for it is tango, I’ll first talk about how tango is learned. (This post may be tedious for people who don’t care about tango or teaching physical actions.)

Dawn and I took a tango lesson last night. It’s a just-beyond-beginner course concentrating on the milonga and vals, two alternate tango rhythms, but it was also teaching new figures to many of the students.

Here’s the first figure, which is one you can repeat an arbitrary number of times as you proceed sideways down the floor:

Joe and Carlotta (the instructors) began by demonstrating the figure, then explained just a few things to attend to. (Joe will usually say something about which part of the leader’s body signals the next movement to the follower. Carlotta usually talks about where and how the follower’s feet should land so as to be ready for the next step.)

What happened next was typical: everyone practiced the movement separately with Joe and Carlotta making a few comments. We moved quickly to direct practice in a mixer: you meet a partner, go sideways down the floor, separate, meet up with a new partner, and continue. Most of us aren’t confident enough to correct our partners, but it’s usually pretty easy to tell how you’ve gotten it wrong and correct it yourself. It’s also easy to tell by feel when you’ve gotten it right.

Joe and Carlotta observed, as usual. After two or three songs finished, they pointed to some things most of us could have done better. I don’t think we practiced this figure again; sometimes we do.

That typical practice session finished, they then introduced a new figure that can be combined with the first one. Instead of going backwards after the second step, the leader can take the couple to the right for one or more steps, then backward:

This figure makes it harder for the follower. After two steps, she has to be prepared either to step forward or to her left. The leader signals this mostly by just moving in the direction he wants the couple to go, which I think the follower detects mostly via her arm on his shoulder.

We went quickly into another mixer. In this one, leaders were encouraged to switch between the two figures at unexpected moments. So the followers were learning to detect the lead, and the leaders were learning to make it clear enough to be detectable.

The next figure starts at the same position but deviates in a different direction. Instead of stepping forward once, bringing the feet together, and then changing direction, the leader repeats the first two steps:

After that, he can take the couple backwards (as in the original figure), to the right (as in the second) or, if there’s room, continue diagonally forward with the first two steps.

At this point in the lesson, I think we danced several songs in the normal “line of dance” (in a rough counterclockwise circle around the room, rather than down a straight line), switching partners between songs or at most once a song. (Tango songs are usually in the 2-4 minute range.) Using the line of dance approaches non-practice dancing more closely: there’s more time to adjust to a particular partner, and also the leader must avoid more collisions than in a line. (Learning to react to events while preserving your musicality is an important part of tango.)

All that lasted about a half an hour. Then there was open practice. Dawn and I concentrated somewhat on the figures we’d just practiced, but I threw in other variations and also figures that don’t start with the same step. These figures were easy enough that we could just have fun.

Dawn and I also practice in our basement and on our driveway (which I’m sure the neighbors think is terribly cute). We concentrate on what we’ve learned recently. (All these variations are hard to remember!) We’ll often practice the fine points of steps and body orientation in slow motion, then at normal speed. We also just plain dance, though the two spaces aren’t very good for that.

There are weekly to biweekly come-one-come-all practice sessions that Dawn and I usually attend. We do the same sort of practicing as above, but we have the advantage of experienced people we can ask for tips.

After almost a year, we should probably be dancing at real dances, but they’re usually pretty crowded and we’re not so experienced in the steps that work in that kind of a crowd. Also, neither of us is a particularly social animal.

The Constant Reader is surely aware I have a childish resentment of the dominance, in software coaching, of theories that change-is-managing-a-crisis-imposed-from-the-outside. It’s not that I deny the existence of such situations; it’s that I hate the ubiquity of the theory. That’s especially so because humans are so reflexive: our theories about our behavior affect our behavior, reinforcing our theories. If the only model you have for change is crisis, then every change is seen as a crisis, and there is less room for inner-motivated change.

Over the years, I’ve convinced… oh, I’d say, about… no one of my point. So perhaps it’s time to bring out the big guns and fight metaphor with metaphor. The dominant metaphor of change is drawn from family therapy and analogizes the group in change to the family in crisis. My new metaphor of change analogizes change to the adolescent primate leaving its group.

Oops, I’ve just oversimplified:

It is no longer accurate to state that one or the other sex disperses at sexual maturity; dispersal in primates is much more complicated than that. — Katherine M. Jack, Lynn A. Isbell

Nevertheless, it’s the case that our closest animal relatives do follow patterns where the (mostly) young leave one group and, despite considerable risk, join another. The typical explanation is something deterministic like incest avoidance. The summary link above claims that explanation, too, is an oversimplification. The behavior of social primates is complex and, to my layman’s eyes, often defies simple linear “Because of X, the animal does Y” explanations.

Although it’s probably dangerous to anthropomorphize even close relatives like chimpanzees, I’ve read articles (none of which I can dig up) that tell stories of ape dispersals that invite us to attribute emotions other than fear to this huge life change. The young ape is curious about another group, finds them tantalizing. It sneaks around watching them, hesitantly getting closer and closer, scampering back to the safety of the home group if threatened, but gets increasingly brave over time. At some point, it makes a commitment and joins the group, despite a typically unfriendly early reception and often ending up as the lowest status animal.

Change here is desirable and motivated internally. Rather than a move forced out of desperation, it’s one important enough to “save up for”:

Instead, female emigration was predicted by dietary quality, suggesting that females wait to have sufficient energy reserves to buffer the high costs of dispersal. — A summary of a longer article.

I think that makes a good metaphor for the kind of change that we can seek, not avoid, in software development: change that is risky, yes, but change that we are impelled to try, because of our nature.

Are you saving up for the next change that’ll tantalize you, that you just have to try? What? You’re not expecting one? You haven’t been tantalized by the possibility of big change since you-can’t-remember-when? You are violating your primate heritage. Perhaps you should align with the Porifera.

Here’s an app that’s used to reserve teaching animals at the University of Illinois vet school:

A user selects procedures to perform by clicking in the leftmost window; animals to perform them on in the rightmost window. Clicking moves the procedure or animal to the corresponding center window and can also narrow down the possible choices. For example, some procedures can only be performed on horses. If you pick one of them, all the cows disappear from the rightmost window.

The first user interface didn’t look like this. It used three windows instead of four, and drag-n-drop instead of clicking. It was heavily tested using a mock-centric style like that of Growing Object-Oriented Software. The switch to a new interface broke all those tests. Bummer!

However, I discovered an interesting thing while dealing with the broken tests. None of them applied directly to the new user interface. However, each of them had some original purpose; each captured an issue that had been important. The exact issue was no longer important, but usually one very like it applied to the new UI. So the broken tests became something of a checklist and spur to the imagination. Rather than just fixing them, or throwing them away, I used them to ask questions: “What user intention or user safeguard does this test represent? How would that intention be exercised in the new UI? [And what test should be written?] Is there a similar danger in the new UI? [And what test would show that the user is protected from it?]”

It was something of a revelation. Allofasudden, maintaining the tests had actual value. Yes, mock-heavy tests do require more maintenance. No, that doesn’t bother me.

Being prone to grandiose statements, that’s led me to proclaim the dawning of the Third Age of Programmer Testing.

The First Age

In the first age, the vast majority of programmers thought testing was boring, pointless, beneath them, and a big waste of time. A much smaller number of programmers thought it was worth doing, although virtually no one was happy with it. I think we all realized, at least unconsciously, that something was wrong with our practice.

The Second Age

Around the beginning of this century, the practice of programmer testing took a big jump forward. Things like one-test-then-just-enough-code are, in part, mental tricks: avoiding one big chunk of testing (at either the beginning or, more usually, at the end) fools our lizard brains into thinking that we’re programming the whole time, so it knows not to be bored. We know much better how to write code that’s easy to test, avoiding tedious and time-consuming test-writing (especially setup). And so on.

Many, many programmers are still stuck in the First Age, but I don’t particularly care. I don’t have to work with them. There are plenty of Second Age folk around.

However, an interesting thing about Second Agers: the vast majority of them think test maintenance is boring, pointless, beneath them, and a big waste of time. A tiny minority (maybe just me?) embraces it.

The Third Age

Just as test-writing took a big leap forward in the past 12 or so years, I predict test-maintaining will do the same over this decade. We’ll develop mental tricks, coding and testing strategies, and tools that will make maintenance as much a thinking-about-design activity as test writing is today.

In response to my earlier “A common conception of gift economies (that is wrong),” a correspondent writes:

The fact that you mention “cheating the system” in your post tells me that you realize this: that even in a “real” gift economy or high-trust economy, there still exists an expectation of some type of quid pro quo. Whether you call it status, whuffie, social mores/expectations, karma, honor, or simply a fulfillment of the givers’ desire to bring the world more in line with their own vision, this counterbalancing force exists. If it did not there would be no motivation for the gift in the first place.

Water runs off a cliff. Politicians run for office. Rabbits run away from dogs. That the same word is used doesn’t mean it’s the same action, or has the same consequences.

Consider the recent Rubygems brouhaha. In my reading, the feeling people had of being cheated stems from reasons that would make no sense in a transactional economy.

• Rubygems users felt their gifts (patches, pull requests) were refused and belittled. That makes sense in a gift economy, in which there’s a continuing obligation and relationship between givers. It makes no sense in transactional or “whuffie-flavored” gift economy: how could my giving you something produce any sort of obligation that I then take from you?

• Rubygem versions came too often and required committers to other projects to make frequent changes. Again, from a transactional point of view, their feeling of being cheated is unjustified. They got something for free before, graciously given by high whuffie committers to a core part of the Ruby ecosystem. Why are those givers now obligated to work extra hard to make the recipients entirely satisfied with the next gift? Isn’t that presumptuous and grasping on the part of J. Random Committer?

  I’m reminded of Graeber’s comment about a reaction of missionary physicians to African gift societies. If I remember it right, the missionaries were surprised that natives got offended when asked for payment. The missionaries thought of the natives as cheaters, trying to get something for nothing. But the natives had a different view: by saving lives that would otherwise be lost, the physicians demonstrated their great whuffie. By asking for payment, they’re pretending to be lesser than they are, to need gifts that they don’t actually need. That’s cheating.

In sum, gifting produces an expectation of a “quid pro quo” in only the loosest and (I feel) misleading sense. Rather than a “what for what”, gifting produces a social relationship that—like all social relationships—captures expectations about future behavior. But that relationship is not an exchange (even deferred) of things. Rather than “quid pro quo”, the phrase should be whatever the Latin is for “[behaves] how because of how [she or someone else behaved].”

As the ground rushes up to meet him, Kevin thinks about missiles again. One missile in particular, a shoulder-fired anti-aircraft missile, blasted from a tube balanced on the bump where some guy’s clavicle meets his scapula. What guy—a Saudi? An Egyptian? A Yemeni? Some pissed-off Arab anyway, kneeling in the back of a dinged-up pickup truck with Texas plates, or crouching on the springy backseat of a rented convertible on a track just outside the airport fence. One of those portable weapons from Afghanistan, back when Afghanistan was somebody else’s problem, called… something, a Slammer or a Tingler or something like that. Kevin recalls that it’s the same name as a cocktail—a Whiskey Sour? A Tom Collins? A shoulder-fired Banana Daiquiri? No a Stinger, that’s it! Four parts brandy to one part crème de menthe in a cocktail glass, or a fat olive-green tube that farts flame out the back while the missile erupts from the front, its backside trailing a wobbly spiral of smoke until the missile gets its bearings and climbs like a sonuvabitch in a long smooth curve into the heat-hazy Texas sky toward the sleek underbelly of Kevin’s plane, a Pringles can with wings, packed full of defenseless Pringles.

That’s the first paragraph of James Hynes’ novel, Next. If its style grabs you: the modern stream of consciousness, the use of detail to capture a scene, the exaggeration of situation and low-culture references (”Pringles can with wings”), you’ll likely find the first two parts of the book readable enough to get to the payoff in the third.

I say that because the first two parts take place mostly in the protagonist’s head as he wanders, Leopold Bloom-style, around Austin Texas killing time before a job interview.

Kevin is a typical Hynes protagonist: take Woody Allen’s Alvy Singer character from “Annie Hall“, subtract Jewish culture, add in whitebread American culture, and substitute actual failure for imagined failure. Hynes’ job as a novelist is to make such a character something other than a dreary collection of white whines. He’s always done that by making the whines clever and well written, as above, but I think he’s also relied on the nature of the books around the characters. With the exception of his first, they’ve been satires that toss the protagonists into wildly exaggerated situations. (In Kings of Infinite Space, the lead character is a failed academic with a temp job at the Texas Bureau of Motor Vehicles—who’s haunted by a malevolent ghost cat and runs into a small problem involving human sacrifices.)

In Next, Hynes sets himself a harder job: to explore such a character more deeply but keep the reader balanced between dislike and sympathy, while also discarding crutches like human sacrifices chosen at karaoke parties or knife-throwing English professors. Indeed, the secondary characters in Next are more fully human than in previous Hynes novels, and (to me) it’s clear that any cardboard-y aspects are because we’re seeing them through Kevin’s eyes and it takes a jolt for Kevin to pay attention to other people long enough to flesh them out.

The plot starts simple. Kevin thinks of himself as “an underachiever in every way he can imagine, professionally, personally, financially.” He’s a book editor with a marginal job at an academic press, a failed marriage behind him, a girlfriend he probably doesn’t love and may not even like. He’s fifty, so he’s flown to Austin for a job interview, telling no one, with thoughts of making a clean break:

It’s not a real choice so much as it’s a choice between two equally risible clichés: Count Your Blessings, or Follow Your Dreams. Look it up (\mid-lif kri-ses\ n) and find a line drawing of Kevin Quinn in a sporty little convertible, with his perky young — well, younger — girlfriend beside him, her hair loose in the breeze. See MIDDLE-AGED MAN.

The plot’s set in motion when Kevin gets an absurd crush on his airplane seatmate (a much younger Asian-American woman) as she walks down the jetway away from the safely-landed plane:

Kevin cannot help but admire the enormously fetching way she moves, a sort of well-lubricated slouch by which she lets her shoulders droop and leads with her hipbones. It’s not an aggressive catwalk strut, it’s much less self-conscious and much more feral, and as Kevin follows her into the filtered light and cathedral echo of the terminal itself, into the delta of debarking passengers fanning across the carpet and onto the cool marble, he thinks, I know that walk, I’ve seen that walk before. And for one thrilling moment, his heart swells with the possibility that I know that girl! But of course, he couldn’t possibly—she’s twenty-five, maybe thirty years younger than him, he’s never seen her before in his life, and if he had, he’d have remembered. But by God he knows that walk, someone else used to walk that way, he’s felt that walk up close, he’s curled his fingertips around those hipbones from behind, and then his heart fills up again, only this time with honest-to-God hundred-proof middle-aged melancholy. It’s Lynda, he realizes, Lynda used to slink like that, Lynda used to glide away from his touch just like that. Lynda on the dance floor, Lynda à la plage, Lynda on the railing.

It’s a later chance sighting of the same woman that takes Kevin out on his Ulysses-like wandering around Austin instead of staying where he belongs, waiting in a Starbucks. (Don’t worry, though: this isn’t a Woody Allen movie. They don’t “meet cute”, he doesn’t get the girl, and she disappears from the story well before the end.)

So, another possible warning: the first two parts mix Kevin’s mild misadventures and his reactions to them with his recollections of, and musings on, the four key women in his life. Those musings increase to the point where a cabbie warns him “You need to pay attention, man.” Kevin does not, which sets him up for Part 3, which is fifty devastating pages.

I won’t spoil the sudden shift, or the pages that follow. Just let me say this: I found myself in a Pringles can over the Atlantic with tears running down my cheeks for Kevin and two other characters, even though I kind of think I despise him, even though I stopped reading every few paragraphs to focus on the in-flight movie until I collected myself.

So: it seems I recommend this book. It’s worth noting that I’m in many ways like Kevin. I’m peripherally academic. I examine my life too much. I’m the same age (though I claim my midlife crisis started at 28 and never stopped.) I too can get set back on my heels by the accident of a woman’s stance. In a later bit of the book, Kevin thinks back to a single devastating sentence a woman said to him, one that may have changed his life, and I’ve had a similar experience. So it’s possible I’m too much Hynes’ ideal reader. Perhaps I should read this to Dawn and see what she thinks.

Context for cluelessness: I was a reviewer for the first paper on mock objects. I completely missed the point. Indeed, it took me most of a decade to finally get it. Now that I have, it’s become my preferred approach to TDD. I’ve carried my preference over to Clojure, going so far as to write a tool, Midje, that supports it (as well as the more-common “state-based” style of TDD).

Given my history, you’d think I’d be smart enough not to expect that people would immediately and completely understand top-down design in Clojure. Nevertheless, I had exactly that expectation. Oops. It seems I must do more than write a tool and record a screencast or two.

I write this in Stockholm. Earlier this week, I taught/facilitated a course/workshop on TDD in Clojure, hosted by the fine folk at Agical. It went well, and it inspired me to do it again. So here’s my proposal.

The course. The course is two days. It’s loosely structured. It consists of my demonstrating how I’d solve a problem, Randori Kata where everyone works on a problem, individual pairs working on a problem, all punctuated by discussions of issues and questions that come up during the day.

The organization. Although I’m calling this a “tour”, it’s actually a series of trips. Ideally, I’d take the train(*) around the USA, stopping to do courses. I could also do the same in Europe or other continents.

My minimum requirement for teaching the course is that I not lose money. What that means, most likely, is that some local company, user group, or person commits to host me, advertises the course locally, and charges other people at least enough to cover expenses. (”Expenses” includes up to two days of extra room and board. I have some hope that teaching the course will lead to something that’ll fill those two days.)

I’ve become fond of Enrique Comba Riepenhausen’s idea of visiting some people, doing some work with them, and saying “Pay me what you think it was worth.” (I did that for the first time today, when I gave a talk to Valtech Stockholm and told them to tell me after the talk what I should invoice them for.) If we could organize that kind of payment so that I’d actually make money on the course, I’d be happy. However, delivering the course and spreading the word is more important to me.

If this intrigues you, contact me.

(*) I’m a “million mile member” of the American Airlines AAdvantage program, but flying has gotten so unpleasant that I’ll take the train when I can.