Sdílet prostřednictvím


Say That Again in English

One of the first things I do in the morning is check Twitter. I start with my calendar and my email of course. You never know what your boss may have sent you overnight when they are three time zones away. But after that I look at Twitter. Yesterday I saw the following message from Brian Hanks of Fort Lewis College in Colorado.

@hanks_b  Trying a new question type on next Java quiz: "Explain the following code in plain English". Can students see the forest for the trees?

In most programming classes what we do is present a description of a problem in English or some other natural language and ask students to translate it into computer code. After all isn’t that what programming is all about? We convert a problem, or rather an algorithm that solves a problem, into language the computer can understand. We worry about making sure the computer understands us. And that is fine as far as it goes but how do we check ourselves? How do we know that the individual statements (the trees) result in a result (the forest) that we are looking for?

The normal and perhaps the lazy person way is to run the code and see what results. But how often do we make the effort to translate the code back to English (or your natural language of choice)? I keep bringing up reading code as a way to make sure we understand what is going on and this is another way to do it. If we have students explain code in their own words we can check two things. One, and this is why it is useful on a quiz, is to make sure that students really understand what code does. We are checking that they are not just randomly (or semi-randomly) adding code in hopes that things will work.

Secondly we are also verifying that an algorithm works – that it does what we think it does. If a second person translates some code we’ve written into a description we don’t recognize there is a good chance that the computer will not do what we expect either. Good code is readable by people as well as the compiler. Good code is clear and unambiguous.

Of course this second point places a burden on a test/quiz writer. Are we modeling good coding practices in the code we ask students to describe? Or are we taking too many shortcuts in order to make the code “manageable” for the students? That’s an important question. It is not always (or perhaps even often) easy to show complex code constructs without creating an artificial code example. As instructors we have an obligation to make sure students know the difference between good code and artificial examples. Even still we risk falling into the “do as I say not as I do” trap. This is a problem for almost any type of student code project though.

I’ve often used the “explain what this code does” or the “what does this code print out” sort of question on quizzes and tests. I think it works best on small code that explores the fundamentals of coding. For example “how many times does this loop execute?” But at the same time I like the idea of having students examine and explain larger pieces of code. Perhaps that is a form of essay question we could use with programming and computer science students? Something to think about.

Comments

  • Anonymous
    March 01, 2010
    Hi Alfred, Glad my tweet got you thinking... Anyhow, this is not my idea. It comes out of work done by the BRACElet group in Australia, and I've been thinking about trying it for a while. If your curious to learn more, here are a couple of references:
  1. Venables, A., Tan, G. and Lister, R. (2009) A Closer Look at Tracing, Explaining and Code Writing Skills in the Novice Programmer. The fifth International Computing Education Research Workshop (ICER 2009), Berkeley, California, August 10-11, 2009.  http://doi.acm.org/10.1145/1584322.1584336
  2. Whalley, J, Lister, R, Thompson, E, Clear, T, Robbins, P, Prasad, C (2006) An Australasian Study of Reading and Comprehension Skills in Novice Programmers, using the Bloom and SOLO Taxonomies.  Australian Computer Science Communications 52: 243-252. http://crpit.com/confpapers/CRPITV52Whalley.pdf