How I Failed, Failed, and Finally Succeeded at Learning How to Code
By James Somers
The programming website Project Euler provides a plan for how to
learn anything in fun, discrete steps
When Colin Hughes was about eleven years old his parents brought
home a rather strange toy. It wasn't colorful or cartoonish; it
didn't seem to have any lasers or wheels or flashing lights; the
box it came in was decorated, not with the bust of a supervillain
or gleaming protagonist, but bulleted text and a picture of a QWERTY
keyboard. It called itself the "ORIC-1 Micro Computer." The package
included two cassette tapes, a few cords and a 130-page programming
manual.
On the whole it looked like a pretty crappy gift for a young boy.
But his parents insisted he take it for a spin, not least because
they had just bought the thing for more than £129. And so he did.
And so, he says, "I was sucked into a hole from which I would never
escape."
It's not hard to see why. Although this was 1983, and the ORIC-1
had about the same raw computing power as a modern alarm clock,
there was something oddly compelling about it. When you turned it
on all you saw was the word "Ready," and beneath that, a blinking
cursor. It was an open invitation: type something, see what happens.
In less than an hour, the ORIC-1 manual took you from printing the
word "hello" to writing short programs in BASIC -- the Beginner's
All-Purpose Symbolic Instruction Code -- that played digital music
and drew wildly interesting pictures on the screen. Just when you
got the urge to try something more complicated, the manual showed
you how.
In a way, the ORIC-1 was so mesmerizing because it stripped computing
down to its most basic form: you typed some instructions; it did
something cool. This was the computer's essential magic laid bare.
Somehow ten or twenty lines of code became shapes and sounds; somehow
the machine breathed life into a block of text.
No wonder Colin got hooked. The ORIC-1 wasn't really a toy, but a
toy maker. All it asked for was a special kind of blueprint.
Once he learned the language, it wasn't long before he was writing
his own simple computer games, and, soon after, teaching himself
trigonometry, calculus and Newtonian mechanics to make them better.
He learned how to model gravity, friction and viscosity. He learned
how to make intelligent enemies.
More than all that, though, he learned how to teach. Without quite
knowing it, Colin had absorbed from his early days with the ORIC-1
and other such microcomputers a sense for how the right mix of
accessibility and complexity, of constraints and open-endedness,
could take a student from total ignorance to near mastery quicker
than anyone -- including his own teachers -- thought possible.
It was a sense that would come in handy, years later, when he gave
birth to Project Euler, a peculiar website that has trained tens
of thousands of new programmers, and that is in its own modest way
the emblem of a nascent revolution in education.
* * *
Sometime between middle and high school, in the early 2000s, I got
a hankering to write code. It was very much a "monkey see, monkey
do" sort of impulse. I had been watching a lot of TechTV -- an
obscure but much-loved cable channel focused on computing, gadgets,
gaming and the Web -- and Hackers, the 1995 cult classic starring
Angelina Jolie in which teenaged computer whizzes, accused of
cybercrimes they didn't commit, have to hack their way to the truth.
I wanted in. So I did what you might expect an over-enthusiastic
suburban nitwit to do, and asked my mom to drive me to the mall to
buy Ivor Horton's 1,181-page, 4.6-pound Beginning Visual C++ 6. I
imagined myself working montage-like through the book, smoothly
accruing expertise one chapter at a time.
What happened instead is that I burned out after a week. The text
itself was dense and unsmiling; the exercises were difficult. It
was quite possibly the least fun I've ever had with a book, or, for
that matter, with anything at all. I dropped it as quickly as I had
picked it up.
Remarkably I went through this cycle several times: I saw people
programming and thought it looked cool, resolved myself to learn,
sought out a book and crashed the moment it got hard.
For a while I thought I didn't have the right kind of brain for
programming. Maybe I needed to be better at math. Maybe I needed
to be smarter.
But it turns out that the people trying to teach me were just doing
a bad job. Those books that dragged me through a series of structured
principles were just bad books. I should have ignored them. I should
have just played.
Nobody misses that fact more egregiously than the American College
Board, the folks responsible for setting the AP Computer Science
high school curriculum. The AP curriculum ought to be a model for
how to teach people to program. Instead it's an example of how
something intrinsically amusing can be made into a lifeless slog.
I imagine that the College Board approached the problem from the
top down. I imagine a group of people sat in a room somewhere and
asked themselves, "What should students know by the time they finish
this course?"; listed some concepts, vocabulary terms, snippets of
code and provisional test questions; arranged them into "modules,"
swaths of exposition followed by exercises; then handed off the
course, ready-made, to teachers who had no choice but to follow it
to the letter.
Whatever the process, the product is a nightmare described eloquently
by Paul Lockhart, a high school mathematics teacher, in his short
booklet, A Mathematician's Lament, about the sorry state of high
school mathematics. His argument applies almost beat for beat to
computer programming.
Lockhart illustrates our system's sickness by imagining a fun
problem, then showing how it might be gutted by educators trying
to "cover" more "material."
Take a look at this picture:
<lockhart's triangle.png>
It's sort of neat to wonder, How much of the box does the triangle
take up? Two-thirds, maybe? Take a moment and try to figure it
out.
If you're having trouble, it could be because you don't have much
training in real math, that is, in solving open-ended problems about
simple shapes and objects. It's hard work. But it's also kind of
fun -- it requires patience, creativity, an insight here and there.
It feels more like working on a puzzle than one of those tedious
drills at the back of a textbook.
If you struggle for long enough you might strike upon the rather
clever idea of chopping your rectangle into two pieces like so:
<lockhart's triangle with vertical.png>
Now you have two rectangles, each cut diagonally in half by a leg
of the triangle. So there is exactly as much space inside the
triangle as outside, which means the triangle must take up exactly
half the box!
This is what a piece of mathematics looks and feels like. That
little
narrative is an example of the mathematician's art: asking simple
and elegant questions about our imaginary creations, and crafting
satisfying and beautiful explanations. There is really nothing else
quite like this realm of pure idea; it's fascinating, it's fun, and
it's free!
But this is not what math feels like in school. The creative process
is inverted, vitiated:
This is why it is so heartbreaking to see what is being done
to
mathematics in school. This rich and fascinating adventure of the
imagination has been reduced to a sterile set of "facts" to be
memorized and procedures to be followed. In place of a simple and
natural question about shapes, and a creative and rewarding process
of invention and discovery, students are treated to this:
<triangle area formula picture.png>
"The area of a triangle is equal to one-half its base times its
height."
Students are asked to memorize this formula and then "apply" it
over and over in the "exercises." Gone is the thrill, the joy, even
the pain and frustration of the creative act. There is not even a
problem anymore. The question has been asked and answered at the
same time -- there is nothing left for the student to do.
* * *
My struggle to become a hacker finally saw a breakthrough late in
my freshman year of college, when I stumbled on a simple question:
If we list all the natural numbers below 10 that are multiples
of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.
Find the sum of all the multiples of 3 or 5 below 1000.
This was the puzzle that turned me into a programmer. This was
Project Euler problem #1, written in 2001 by a then much older Colin
Hughes, that student of the ORIC-1 who had gone on to become a math
teacher at a small British grammar school and, not long after, the
unseen professor to tens of thousands of fledglings like myself.
The problem itself is a lot like Lockhart's triangle question --
simple enough to entice the freshest beginner, sufficiently complicated
to require some thought.
What's especially neat about it is that someone who has never
programmed -- someone who doesn't even know what a program is --
can learn to write code that solves this problem in less than three
hours. I've seen it happen. All it takes is a little hunger. You
just have to want the answer.
That's the pedagological ballgame: get your student to want to find
something out. All that's left after that is to make yourself
available for hints and questions. "That student is taught the best
who is told the least."
It's like sitting a kid down at the ORIC-1. Kids are naturally
curious. They love blank slates: a sandbox, a bag of LEGOs. Once
you show them a little of what the machine can do they'll clamor
for more. They'll want to know how to make that circle a little
smaller or how to make that song go a little faster. They'll imagine
a game in their head and then relentlessly fight to build it.
Along the way, of course, they'll start to pick up all the concepts
you wanted to teach them in the first place. And those concepts
will stick because they learned them not in a vacuum, but in the
service of a problem they were itching to solve.
Project Euler, named for the Swiss mathematician Leonhard Euler,
is popular (more than 150,000 users have submitted 2,630,835
solutions) precisely because Colin Hughes -- and later, a team of
eight or nine hand-picked helpers -- crafted problems that lots of
people get the itch to solve. And it's an effective teacher because
those problems are arranged like the programs in the ORIC-1's manual,
in what Hughes calls an "inductive chain":
The problems range in difficulty and for many the experience is
inductive chain learning. That is, by solving one problem it will
expose you to a new concept that allows you to undertake a previously
inaccessible problem. So the determined participant will slowly but
surely work his/her way through every problem.
This is an idea that's long been familiar to video game designers,
who know that players have the most fun when they're pushed always
to the edge of their ability. The trick is to craft a ladder of
increasingly difficult levels, each one building on the last. New
skills are introduced with an easier version of a challenge -- a
quick demonstration that's hard to screw up -- and certified with
a harder version, the idea being to only let players move on when
they've shown that they're ready. The result is a gradual ratcheting
up the learning curve.
Project Euler is engaging in part because it's set up like a video
game, with 340 fun, very carefully ordered problems. Each has its
own page, like this one that asks you to discover the three most
popular squares in a game of Monopoly played with 4-sided (instead
of 6-sided) dice. At the bottom of the puzzle description is a box
where you can enter your answer, usually just a whole number. The
only "rule" is that the program you use to solve the problem should
take no more than one minute of computer time to run.
On top of this there is one brilliant feature: once you get the
right answer you're given access to a forum where successful solvers
share their approaches. It's the ideal time to pick up new ideas
-- after you've wrapped your head around a problem enough to solve
it.
This is also why a lot of experienced programmers use Project Euler
to learn a new language. Each problem's forum is a kind of Rosetta
stone. For a single simple problem you might find annotated solutions
in Python, C, Assembler, BASIC, Ruby, Java, J and FORTRAN.
Even if you're not a programmer, it's worth solving a Project Euler
problem just to see what happens in these forums. What you'll find
there is something that educators, technologists and journalists
have been talking about for decades. And for nine years it's been
quietly thriving on this site. It's the global, distributed classroom,
a nurturing community of self-motivated learners -- old, young,
from more than two hundred countries -- all sharing in the pleasure
of finding things out.
* * *
It's tempting to generalize: If programming is best learned in this
playful, bottom-up way, why not everything else? Could there be a
Project Euler for English or Biology?
Maybe. But I think it helps to recognize that programming is actually
a very unusual activity. Two features in particular stick out.
The first is that it's naturally addictive. Computers are really
fast; even in the '80s they were really fast. What that means is
there is almost no time between changing your program and seeing
the results. That short feedback loop is mentally very powerful.
Every few minutes you get a little payoff -- perhaps a small hit
of dopamine -- as you hack and tweak, hack and tweak, and see that
your program is a little bit better, a little bit closer to what
you had in mind.
It's important because learning is all about solving hard problems,
and solving hard problems is all about not giving up. So a machine
that triggers hours-long bouts of frantic obsessive excitement is
a pretty nifty learning tool.
The second feature, by contrast, is something that at first glance
looks totally immaterial. It's the simple fact that code is text.
Let's say that your sink is broken, maybe clogged, and you're feeling
bold -- instead of calling a plumber you decide to fix it yourself.
It would be nice if you could take a picture of your pipes, plug
it into Google, and instantly find a page where five or six other
people explained in detail how they dealt with the same problem.
It would be especially nice if once you found a solution you liked,
you could somehow immediately apply it to your sink.
Unfortunately that's not going to happen. You can't just copy and
paste a Bob Villa video to fix your garage door.
But the really crazy thing is that this is what programmers do all
day, and the reason they can do it is because code is text.
I think that goes a long way toward explaining why so many programmers
are self-taught. Sharing solutions to programming problems is easy,
perhaps easier than sharing solutions to anything else, because the
medium of information exchange -- text -- is the medium of action.
Code is its own description. There's no translation involved in
making it go.
Programmers take advantage of that fact every day. The Web is teeming
with code because code is text and text is cheap, portable and
searchable. Copying is encouraged, not frowned upon. The neophyte
programmer never has to learn alone.
* * *
Garry Kasparov, a chess grandmaster who was famously bested by IBM's
Deep Blue supercomputer, notes how machines have changed the way
the game is learned:
There have been many unintended consequences, both positive and
negative, of the rapid proliferation of powerful chess software. Kids
love computers and take to them naturally, so it's no surprise that the
same is true of the combination of chess and computers. With the
introduction of super-powerful software it became possible for a
youngster to have a top- level opponent at home instead of needing a
professional trainer from an early age. Countries with little by way of
chess tradition and few available coaches can now produce prodigies.
A student can now download a free program that plays better than
any living human. He can use it as a sparring partner, a coach, an
encyclopedia of important games and openings, or a highly technical
analyst of individual positions. He can become an expert without
ever leaving the house.
Take that thought to its logical end. Imagine a future in which the
best way to learn how to do something -- how to write prose, how
to solve differential equations, how to fly a plane -- is to download
software, not unlike today's chess engines, that takes you from
zero to sixty by way of a delightfully addictive inductive chain.
If the idea sounds far-fetched, consider that I was taught to program
by a program whose programmer, more than twenty-five years earlier,
was taught to program by a program.
http://www.theatlantic.com/technology/archive/2011/06/how-i-failed-failed-and-finally-succeeded-at-learning-how-to-code/239855/
