Skip to content

How to best teach programming—a comment from Hacker News

June 14, 2011

This comment from slashdot bubbled up on Hacker news a few days ago:

Re:Depends on who is hiring (Score:5, Insightful)
by wrook (134116) on Tuesday May 31, @01:44AM (#36293622) Homepage
A bit off topic, but you triggered something I’ve been thinking about for a couple of years. That “spark” is fluency.

I swtiched jobs from being a computer programmer to being an ESL teacher in Japan. Japan is somewhat famous for churning out students who know a lot *about* English, but can’t order a drink at Mac Donald’s. We used to have a name for those kinds of people with regard to programming languages: language laywers. They can answer any question you put to them *about* a programming language, but couldn’t program to save their life. These people often make it past job interviews easily, but then turn out to be huge disappointments when they actually get down to work. I’ve read a lot about this problem, but the more I look at it, the more I realise that these disabled programmers are just like my students. They have a vocabulary of 5000 words, know every grammar rule in the book but just can’t speak.

My current theory is that programming is quite literally writing. The vast majority of programming is not conceptually difficult (contrary to what a lot of people would have you believe). We only make it difficult because we suck at writing. The vast majority of programmers aren’t fluent, and don’t even have a desire to be fluent. They don’t read other people’s code. They don’t recognise or use idioms. They don’t think *in the programming language*. Most code sucks because we have the fluency equivalent of 3 year olds trying to write a novel. And so our programs are needlessly complex.

Those programmers with a “spark” are programmers who have an innate talent for the language. Or they are people who have read and read and read code. Or both. We teach programming wrong. We teach it the way Japanese teachers have been teaching English. We teach about programming and expect that students will spontaneously learn to write from this collection of facts.

In language acquisition there is a hypothesis called the “Input Hypothesis”. It states that *all* language acquisition comes from “comprehensible input”. That is, if you hear or read language that you can understand based on what you already know and from context, you will acquire it. Explanation does not help you acquire language. I believe the same is true of programming. We should be immersing students in good code. We should be burying them in idiom after idiom after idiom, allowing them to acquire the ability to program without explanation.

I’m not sure these are the most profound thoughts ever written about teaching computer science, and it’s been a while since I tried to formally teach the subject myself. But it does seem like a good idea to spend more time having students read and interpret good code, rather than just throwing them into to write their own code. As I’m starting to develop this curriculum for teaching computational modeling, I’m very interested in helping students to understand not just physics, but also computational thinking and good practices in computer science.

I know there are a number of great computer scientists out there who occasionally read this blog, so I’d appreciate any feedback in how to proceed.

4 Comments leave one →
  1. June 14, 2011 1:10 pm

    There is one big problem with this idea—finding good code for students to read. It is an exceedingly rare commodity.

    Also, it is difficult to get students to pay attention to reading and apply the ideas to writing. The Japanese students of English spend a lot of time reading English, without developing much ability to construct new sentences.

    Certainly it would benefit the students learning to program to have more examples of good code, but there must be a reason for them to read them. (See, for example, the excellent series of blog posts on Mylène’s blog about technical reading.)

    • June 14, 2011 6:31 pm

      Thanks for the reminder about Myele’s great posts on technical reading—i didn’t make the connection that that could equally apply to reading code as well. Not that the code I wrote and modified is much good, but I’m thinking that I will be able to get students to read it by asking them questions that require them to dig and make sense of my code, as well as modify it to make small changes before we really get into all of the syntax that they’ll need to know.

  2. June 16, 2011 4:19 pm

    I also have a gut feeling that this is a reading comprehension issue. Take this with a grain of salt — due to my recent obsession, everything looks like a reading comprehension issue. But maybe there’s something to it.

    Thinking explicitly about reading comprehension could help students crack the secret typographical conventions of the help file, or distinguish between a “how comment” (really a transliteration into English, which can help you read) and a “why comment” (the one you will need when you forget why you put that line there in the first place).

    However, there is this basic problem: many of the best practises in software engineering are intended to make code perform more reliably or be more maintainable. These are solutions to problems that only occur over the long term. Trying to force students to adopt conventions that won’t be all that useful until you need to modify this code next year, or until your 10 lines of code get reused in a 5000 line project… that’s a tough sell.

    Is there a way to make it necessary for students to incorporate or modify each others’ code? That’s when bad practises start to make you cranky. In my previous life as a software developer, my team once opened some source code and found that all the variables were named after Star Trek characters. Who knew computer geeks could so quickly become homicidal?

    I agree that having students make small changes can be a great way to explore syntax. Also, if their first exposure is to highly readable code, they are likely to become impatient with anything less. (Unfortunately, textbooks with their meaningless examples and arbitrary variable names are not a great example).

    Good luck, keep us posted!

    • June 19, 2011 9:13 pm

      Thanks for the great feedback. I’m totally with you on how difficult it is to teach software engineering principles that make 10,000 lines programs manageable—I found all those naming conventions and other rules to be silly when I first stared to learn programming myself.

      I like your idea of having students use other students’ code. I think we could do something where I give students another student’s program and have the modify it. This is a great idea. I could also see this working in a problem solving session, where each group were working on a problem on a whiteboard, and then I simply had groups rotate and pick up where the other group left off. It might be a fun experiment to try.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: