The Right Hour, Or Some Nits With Hour Of Code
3 min read
I'm normally not a fan of RadioLab - it reminds me of baked sophomores trying to be profound - but over the weekend, they had an interesting piece about cooperation. One segment of this piece included a story about an experiment and contest on the prisoner's dilemma. The contest was run by Robert Axelrod - to compete, selected participants mailed programs in (this was pre-internet days), and the programs would be entered into a computer. Once all submissions were entered, each program would play every other program two hundred times.
The relevant section begins at 6 minutes in, and the specific transcript below begins at 10:00.
Narrator: Did you have a hunch as to which would be the most successful program?
Robert Axelrod: Well, I didn't know, which is why I wanted to do it, but I did have a hunch that thousands or tens of thousands of lines of code would be needed to have a pretty competent program.
N: So when the mailman delivers the fattest envelope to your house, were you like, "Well, this could be the one?"
RA: Yes. Right. Now it didn't turn out that way.
N: When it was all said and done, when he loaded all the programs into the computer, when they had all played each other 200 times, the program that won?
RA: It was really two lines of code.
Listen to the whole piece; it's worth the time. But when I heard this, I immediately thought of the Hour of Code. While I appreciate the desire to help people understand the technology that exists within the world, learning how to develop software involves more than just software development. In the example from the Radiolab story, incredibly intelligent people devoted countless person hours - and thousands of lines of code - to solving a problem that could be effectively addressed with two lines of code.
In software development - and, in just about every other creative endeavor - real work is required to get results. But, in many cases, the nature of the "work" doesn't always involve what we traditionally consider work. A person seated in a chair at a desk doesn't guarantee productivity, and the same person spending two separate hours writing code can produce work of drastically different quality. Often, we don't need 1000 lines of code to solve a problem - as in the RadioLab example, the problem was solved effectively with two lines of code.
In the RadioLab example - and in many real world situations - the "work" involved understanding the problem well enough to know the right two lines of code to write. That's a more difficult skill to teach; having people spend an hour writing code doesn't necessarily bring us closer to that understanding.
