mechanics, social interaction, language, and so on, to learn the
turtle’s microworld and learn new programming skills.
But there’s a downside to looking for similarities.
You learn a new programming language relative to the concepts
you knew from the last programming language. That’s why in years
past we saw so much C++ code that looked like C, so much Java
code that looked like C++, so much Ruby code that looked like
Java, and so on. It’s a natural transition from one set of skills to
the next.
Report erratum
Prepared exclusively for Jose Luis Loya
gggggggggggggggg
this copy is (P2.0 printing, January 2009)
EMBED FAILING IN PRACTICE
199
The danger lies in not completing the transition and sticking with
the hybridized approach instead of fully embracing the new skill.
You need to unlearn just as much as you need to learn. Exam-
ples include moving from the horse and buggy to the automobile,
from the typewriter to the computer, from procedural programming
to object-oriented programming, and from single programs on the
desktop to cloud computing. For each of these transitions, the new
way was fundamentally different from the old way. And where they
were different, you had to let go of the old way.
TIP 34
Learn from similarities; unlearn from differences.
Another danger is that your notion of a “similar” previous prob-
lem may be completely wrong. For instance, when trying to learn
a functional programming language, such as Erlang or Haskell,
much of what you’ve previously learned about programming lan-
guages will just get in the way. They aren’t similar to traditional
procedural languages in any way that’s helpful.
Failure lurks around every corner. And that’s a good thing, as we’ll
see next.
7.3 Embed Failing in Practice
A man’s errors are his portals of discovery.
James Joyce, 1882–1941
Debugging is a part of life—not just software. Lawyers have to de-
bug the law, mechanics debug cars, and psychiatrists debug us.
But let’s not be coy about it; we’re not removing “bugs” that some-
how mysteriously crept into the system when we weren’t looking.
Debugging means solving problems, generally of our own making.
We’re identifying errors, mistakes, and oversights, and we’re cor-
recting them. The value lies in learning from the error, which Papert
sums up nicely: “Errors benefit us because they lead us to study
what happened, to understand what went wrong, and, through
understanding, to fix it.”
Perversely enough, failure is critical to success—not just any ran-
dom failure; you need well-managed failure. You need the support
Report erratum
Prepared exclusively for Jose Luis Loya
gggggggggggggggg
this copy is (P2.0 printing, January 2009)
EMBED FAILING IN PRACTICE
200
of a good learning environment so you can more easily gain and
apply experience from both your failures and your successes.
Not all mistakes arise from things you
“I don’t know” is a good
do; others come from things you didn’t do
start.
but should have done. For example, you’re
reading along and come across the word
rebarbative or horked, and you wonder what on Earth it means.
Or perhaps you see a reference to a new technology you’ve never
heard of or a famous author in your field you’ve never read. Look
it up. Google it. Fill in the blanks. “I don’t know” is a fine answer,
but don’t let it end there.
We tend to think of failure or ignorance in a very negative light, as
something to be avoided at all costs. But it’s not important to get
it right the first time; it’s important to get it right the last time. In
any nontrivial endeavor, you will make mistakes.
Exploration is “playing” in unfamiliar territory. You need to be able
to explore freely in order to learn. But that exploration has to be rel-
atively free from risk; you don’t ever want to be held back because
you’re afraid to try something. You need to be able to explore even
if you’re not sure where you’re headed. Similarly, you need to be
free to invent—comfortable in the knowledge that what you cre-
ate might not work out. Finally, you need to be able to apply what
you’ve learned in your day-to-day practice. An efficient, supportive
learning environment should allow you to do three things, safely:
explore, invent, and apply.3
TIP 35
Explore, invent, and apply in your environment—safely.
Create an Exploratory Environment
However, you can’t explore, invent, or apply ideas within the envi-
ronment of practice (on the job) until you make it safe for yourself,
for your team, and for your organization. You wouldn’t want your
heart surgeon to start your operation with, “Hmm, I’m going to try
doing this left-handed today and see what happens.”
3.
Explore, Invent, and Apply [Bei91].
Report erratum
Prepared exclusively for Jose Luis Loya
gggggggggggggggg
this copy is (P2.0 printing, January 2009)
EMBED FAILING IN PRACTICE
201
That wouldn’t be safe; a live and unsuspecting patient is not the
right context for experimentation.
You can experiment out of the line of corporate fire, for instance,
at home on an open source project. That at least reduces the risk
of negative consequences. But that alone is not enough to create a
positive learning environment for you. Whether it’s on a corporate
team or a solo experiment in the dark watches of the night, you
need the following:
Freedom to experiment
Few problems have a single, best solution. You could imple-
ment this next feature this way or that way; which do you
choose? Both! If time is tight (and when isn’t it?), try at least
a prototype each way. That’s experimentation, and you want
to encourage it. Consider it part of “design time” when giving
an estimate. You also need to make sure this experimentation
doesn’t adversely affect anyone else on the team.
Ability to backtrack to a stable state
Safety means that when the experiment goes awry, you can go
back to the halcyon days of last Tuesday, before you started
making those dreadful changes. You want to revert to a previ-
ous, known state of your source code and try again. Remem-
ber, you want to get it right the last time.
Reproduce any work product as of any time
Backtracking to a previous version of the source code isn’t
quite enough; you probably need to actually run the program
(or work with any derivative work product) as of any point in
history. Can you run a version of the program from last year
or last month?
Ability to demonstrate progress
Finally, you can’t get anywhere without feedback. Did this
; experiment or that invention work better than the alterna-
tives? How do you know? Is the project progressing? Do more
functions work this week than worked last week? Somehow,
you need to demonstrate fine-grained progress—to yourself as
well as to others.
Report erratum
Prepared exclusively for Jose Luis Loya
gggggggggggggggg
this copy is (P2.0 printing, January 2009)
EMBED FAILING IN PRACTICE
202
In software development, it’s pretty simple to set up an infrastruc-
ture to address these needs. It’s what we call the Starter Kit: ver-
sion control, unit testing, and project automation.4
• Version control stores every version of every file you work with.
Whether you’re writing source code, articles, songs or poetry,
version control acts as a giant Undo button for your work.5
Newer distributed version control systems such as Git or Mer-
curial are well-suited to support private experimentation.
• Unit testing provides you with a fine-grained set of regression
tests. You can use unit test results to compare alternatives,
and you can use them as a solid indication of progress.6
In any endeavor, you need objective feedback to measure
progress. This is ours.
• Automation ties it all together and ensures that the trivial
mechanics are taken care of in a reliable, repeatable manner.7
This Starter Kit gives you the advantage of freedom to experiment,
with comparatively little risk.
Of course, your team practices and culture have to allow this
approach to exploration and invention. A supporting environment
can make or break learning for anyone. Thich Nhat Hanh reminds
us of the fundamental attribution error (described in Chapter 5,
Debug Your Mind, on page 124); the problem is more often the envi-
ronment, not the individual.
When you plant lettuce, if it does not grow well, you don’t blame the
lettuce. You look for reasons it is not doing well. It may need
fertilizer or more water or less sun. You never blame the lettuce.
Thich Nhat Hanh
4.
In fact, Dave Thomas and I felt that the idea of the Starter Kit was so important that those were the very first books we published as the Pragmatic Bookshelf.
5.
See Pragmatic Version Control using Git [Swi08], Pragmatic Version Control Using Subversion [Mas06], or Pragmatic Version Control Using CVS [TH03] for particular systems.
6.
See Pragmatic Unit Testing In Java with JUnit [HT03] and Pragmatic Unit Testing In C# with NUnit, 2nd Ed. [HwMH06].
7.
See Pragmatic Project Automation. How to Build, Deploy, and Monitor Java
Applications [Cla04] as well as Ship It! A Practical Guide to Successful Software Projects [RG05] for a good overview of these topics in a team context.
Report erratum
Prepared exclusively for Jose Luis Loya
gggggggggggggggg
this copy is (P2.0 printing, January 2009)
LEARN ABOUT THE INNER GAME
203
Next Actions
! If your software project isn’t set up with a safety net (version
control, unit testing, and automation), you need to get that
implemented right away. Put the book down. I’ll wait.
! Your personal learning projects need to have the same safety
net—whether you are writing code, learning to paint, or
exploring a colossal cave. Put the infrastructure and habits
in place to make your project safe to explore.
! Do you know what halcyon means? Anthropomorphism? Ever
hear of Nhat Hanh? Did you look them up? If not, what do
you need to do to make this happen? (On the Mac, you can
often Control-click [or right-click] a word and have the option
to look it up in the dictionary or search using Google for that
word. It’s quite handy.)
7.4 Learn About the Inner Game
There are two types of failure. There are the failures that are good
for us that we can learn from. But there are failures that aren’t good
for us. This second type of failure doesn’t produce any learning: it
keeps us from learning in the first place, or it shuts down our
learning in mid-experience.
To recognize and overcome this second type of failure, you need to
be aware of the inner game. Understanding the inner game will help
you eliminate interference that gets in the way of learning, and it
emphasizes the right kind of feedback to help you learn.
In 1974 the popular book The Inner Game of Tennis [Gal97] intro-
duced a generation to a whole new level of feedback and self-
awareness. It spawned a number of follow-on books including The
Inner Game of Music [GG86] and those about skiing, golf, and more.
The Inner Game series helps further the point of learning from
your own experience. In this series of books, Timothy Gallwey and
other authors differentiate the obvious, “outer” game that you are
engaged in and explore the subtleties of the more critical “inner”
game. A big part of improving learning comes from Gallwey’s idea
of reducing failure-inducing interference and using feedback.
In a famous example, the author takes an older subject, a woman
in her late fifties or so, who has never played tennis or indeed
Report erratum
Prepared exclusively for Jose Luis Loya
gggggggggggggggg
this copy is (P2.0 printing, January 2009)
LEARN ABOUT THE INNER GAME
204
engaged in any significant physical activity for the past twenty
years. The challenge was to teach her to play tennis in just twenty
minutes. There’s no way to succeed at this challenge using a tra-
ditional approach. But Tim Gallwey had a better idea—one that
didn’t involve any lengthy lectures or extended demonstrations.
First, she was to just watch the ball and say out
loud “Bounce” and “Hit” as Gallwey hit the ball.
A minute or so of this, and it was her turn: just
say “Bounce” and “Hit.” Don’t try to hit the ball;
just say “Hit” when it seems about the right time, and swing when
you feel like it. The next exercise was to listen to the sound of the
ball hitting the racket. If you’ve never played, the ball makes a
particularly sweet, clear sound when it hits just the right spot on
the racket. This fact wasn’t made explicit; our student was merely
told to listen.
Next, it was time to serve. First, she was to just hum a phrase while
watching Gallwey serve in order to get the rhythm of the motion. No
description of the movements; just watch and hum. Next, she tried
the serve—humming the same tune and focusing on the rhythm,
not the motions. After twenty minutes of this sort of thing, it was
time to play. She made the first point of the game and played a very
respectable, lengthy set of volleys.8
In another example, you hit balls across the court where a chair
is sitting. The idea is not to try to hit the chair but to simply note
where the ball lands in relation to the chair. So while hitting balls,
you would verbalize observations such as “Left,” “Right,” “O
ver,”
and so on.
The Inner Game series teaches us that it
We learn best by
can be very difficult to teach a skill by
discovery, not
putting it into words; we learn better by
instruction.
discovery, not instruction. This notion is
embodied in the chair example, where the
learner is getting real-time feedback in the context of the situation.
8.
See Alan Kay’s videotaped lecture entitled Doing with Images Makes Symbols: Communicating with Computers for actual footage of the event.
Report erratum
Prepared exclusively for Jose Luis Loya
gggggggggggggggg
this copy is (P2.0 printing, January 2009)
LEARN ABOUT THE INNER GAME
205
Cultivate Situational Feedback
Situational feedback is the primary inner game technique that
allows you to learn more efficiently by eliminating any interference.
In the tennis example, the subject wasn’t inundated with rules of
the game; buried with minutiae of proper grip, footwork, and so
on; or forced to learn “dance facts” before dancing. Instead of all
those distractions, she was able to concentrate on a very simple
feedback loop. Hit the ball like this, and it lands here. Hit the ball
like that, and it lands over there. Follow this rhythm. It’s nonverbal
learning, for a nonverbal skill, with a tight feedback loop and short
feedback gap.9
Consider an example from skiing. I’ve had a handful of ski lessons
over the years, and invariably they turn out the same. I’m hurtling
down the face with some instructor named Hans close by, issuing
instructions at a frantic pace with an unidentifiable accent:
• “Keep you elbows een!”
• “Bend your knees!”
• “Tips together!”
• “Lean eento the curve!”
• “Watch your pole!”
• “Look out for the tree!”
Now I’m trying to listen to everything this guy is saying, but of
course the verbal processing centers (L-mode) are on the slow side
of the house. I’m back on tucking in my elbows and starting to
think about my knees, and already the tree is looming close. At a
certain point (and usually pretty quickly), your brain just fries with
the constant barrage of instructions and stops attending. Brain
freeze. It’s too much to remember and keep track of all at once.
Pragmatic Thinking and Learning Page 25