Easy Programming

A conversation among Ruby programmers got me thinking about why some people are drawn naturally to pair-programming and others aren't. It has to do with their worldviews: programming is either easy or hard.

Pair-programming is often misunderstood.

To understand pairing one must examine the worldviews of programmers. For many (perhaps all programmers historically) programming is difficult and requires skill and concentration to be successful. For others, and here we find roots in dynamic languages, programming is easy but requires imagination and interpretation to find success.

When two people work together on hard programming their expectation is that skills will be transferred but there will not be sufficient concentration to perform more than educational tasks. Normally there is the mentor and the student. The mentor's judgement is used to decide when the student is skilled enough to work alone.

When two people work together on easy programming their expectation is that flights of imagination will be transferred. Long bouts of deep and mandatory concentration interfere with imagination, both in the individual and especially within the pair. When hard problems surface, the easy programmer's strategy is to reframe the problem so as to keep imagination working. (I would famously ask Kent, what is the simplest thing that could possibly work?)

I like both kinds of programming.

Hard programming feels like climbing a mountain. There is a goal with a fabulous view. The experience remains personal.

Easy programming feels like drifting a river. The fabulous views are all along the way and they are best enjoyed with others.

We know more about hard programming than easy programming. Most of us learned our craft by tackling harder and harder problems. The hardest problems have intricate dependencies among many resources and yield only when the programmer can reason about all of them at once. As we become more practiced at this we discover that we are pretty much alone.

Easy programming isn't about solving easy problems.

Easy programming has roots in the difficult problems of artificial intelligence. One can assume that just thinking through "intelligence" isn't going to work. Instead, in this field, just discovering a new approach counts as success. Also, a new approach will make both your problem and everyone else's problems easer.

This is how the great AI labs worked. Techniques spread quickly there. The programmers were powerful, but the power didn't spread far beyond Stanford or MIT because there was too much technique to learn outside of those communities.

The internet made easy programming, well, easy.

Techniques now spreads quickly within the communities of practice that bubble up continuously on the net. Old hands at programming like myself will find that they are as likely to learn a new technique from an intern as an expert. It's all very exciting but a little scary too since nothing ever gets mastered, or so it seams.

Matz channeled Alan Kay and Larry Wall when he set out to give us all easy programming. DHH showed us easy programming could be a business and that just believing that programming could be easy is a barrier to entry. Imagine that?

City leaders wring their hands about venture funds drawing our best talent south. I wonder if the "great man" theory that all VCs hold isn't negated by the mere presence of Calagator and the upcoming Winter Social. Portland might just be the next great easy programming laboratory. Our willingness to work together could be the juice that will push computers forward. We will all have to master pair-programming (not just mentoring) to make this work. It will be awesome.

The precipitating conversation took place on the Portland Ruby list in November, 2012. post

Robb Shecter suggested a programmer new to Ruby "be assigned to another programmer for pair-programming until she's "got it".

Sam Livingston-Gray observed, "It's the best for her, for you, but mostly, for your organization.

Sam went on, "I wouldn't say I've "got it" -- not by a long shot -- but I'm a reasonably competent developer who's been using Ruby for six years... and even now, the code I commit while pair programming is noticeably better than the code I hack out by myself. There are some tasks that really just don't need a pair, but I'm curious why pairing seems to be framed here as a temporary or remedial measure, instead of being the norm (or at least *a* norm)?