Skip to content

Instantly share code, notes, and snippets.

@rvazquezglez
Forked from peterkeen/ward.txt
Created October 21, 2013 19:25
Show Gist options
  • Save rvazquezglez/7089428 to your computer and use it in GitHub Desktop.
Save rvazquezglez/7089428 to your computer and use it in GitHub Desktop.
Subject: Re: [pdxruby] Re: Complex return value anti-pattern?
From: Ward Cunningham <[email protected]>
Date: Thu, 29 Nov 2012 08:23:26 -0800
Pair programming is often misunderstood.
To understand pairing one must examine the world views of programmers. For
many (perhaps all programmers historically) programming is difficult and re
quires skill and concentration to be successful. For others, and here we fi
nd 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 th
e student. The mentor's judgement is used to decide when the student is ski
lled 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 mandato
ry concentration interfere with imagination, both in the individual and esp
ecially within the pair. When hard problems surface, the easy programmer's
strategy is to reframe the problem so as to keep imagination working. (I wo
uld 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 fab
ulous view. The experience remains personal.
Easy programming feels like drifting a river. The fabulous views are all al
ong the way and they are best enjoyed with others.
We know more about hard programming than easy programming. Most of us learn
ed our craft by tackling harder and harder problems. The hardest problems h
ave intricate dependencies among many resources and yield only when the pro
grammer can reason about all of them at once. As we become more practiced a
t this we discover that we are pretty much alone.=20
Easy programming isn't about solving easy problems. It's roots are in the m
ost difficult problems: artificial intelligence. We can assume that just th
inking thinking through isn't going to work. Instead, just discovering a ne
w approach that brings some leverage to the problem is success. A new appro
ach, a new abstraction, will make your problem easier and everyone else's p
roblems easer too. This is how the great AI labs worked. Techniques spread
quickly there. The programmers were powerful, but the power didn't spread f
ar beyond Stanford or MIT because there was too much technique to learn out
side of those communities.
The internet made easy programming, well, easy.
Techniques now spreads quickly within the communities of practice that bubb
le up continuously on the net. An old hand at programming like myself will
find that they are as likely to learn a new technique from an intern as an
expert. Its all very exciting but a little scary too since nothing ever get
s 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 ju
st 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 b
y the mere presence of Calagator and the upcoming Winter Social. Portland m
ight 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.
Best regards. -- Ward
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment