Charlie Meyer's Blog

Code Doesn't Happen to You

tags: cs-education

(This post is now also published on the Pickcode blog)


While teaching new programmers, I have observed two attitudes:

  1. A machine deterministically executes source code according to language semantics and existing library code. Programs achieve the goal of the programmer when they produce correct outputs on all valid inputs.
  2. When executed, source code causes a machine to produce a myriad of unpredictable results. With enough empirical data we can attempt to understand the behavior of the code based on how a machine “decides what to do”.

Attitude 2 is what I refer to as “the code happening to me”, as it minimizes the agency that a programmer has as they attempt to create software. This post is in no way meant to be a judgment on anyone with Attitude 2 or a proclamation that students who quickly adopt the Attitude 1 are somehow superior. Our goal is to understand the cause of "the code is happening to me" attitude and to give our students tools to overcome it.

Selected Bad Metaphors for Programming

“Learning to program is like learning a foreign language”

The process

Key features

“Learning to program is like putting together a puzzle”

The process

Key features

Why Does the Code Happen to Me

Given these bad metaphors (and they likely hear many more), what should a new programmer believe? Elements of each of the preceding metaphors are instructive, but they paint a very poor picture of the full process that the student will be engaging in. Misapplication of these metaphors is a primary cause of the “code happens to me” phenomenon.

Foreign language learning

Programming does require knowledge and application of technical vocabulary and application of structural rules that loosely resemble the grammars of natural languages. However, the receiver of the translated ideas is not a conscious agent, and most errors result in an unrecoverable failure of a program.

Python, gcc, the JVM, or the Scratch cat do not have the ability to think or feel. They do not “decide” to be pleased by your choice of parameters to a method call or choice of brackets. As Dijkstra put it, “The question ‘Can machines think?’ is regularly raised; we can —and should— deal with that by pointing out that it is just as relevant as the equally burning question 'Can submarines swim?'”.

Puzzle solving

Programming does require the decomposition of a problem and the subsequent composition of smaller solutions into a complete one. However, there are many correct ways to assemble a program. While puzzle solving and programming both require trial and error in assembling a solution, only the programmer can exercise significant creativity.

The puzzle solving metaphor is possibly more pernicious than that of foreign language learning. While solving a puzzle, two pieces belong together in the solution if and only if they fit together. (The Puzzle Theorem) “Getting the puzzles to fit together" is best mapped to the programming task of writing syntactically correct code. While block based programming successfully leverages the puzzle metaphor for helping reduce syntax errors, a learner can become quickly confused when faced with the falsehood of The Puzzle Theorem while trying to code. “Making the pieces fit” is only one piece of the puzzle (pun intended), and more crucially, there is no one correct way to implement a program in code. If one expects programming to be a journey towards a single correct answer by rearranging puzzle pieces, they are in for quite a long ride. (Google “combinatorial explosion”)

To give students the ability to succeed, we must provide them the proper context for the role of programming in the creation of software.

A Better Model for Programming

The process

Key features

The primary cause of the “code is happening to me” phenomenon is confusion as to where the programmer can exercise creativity and how a program is deemed to be correct. Many beginning programmers produce code and ask “is this right?” without once testing it. If one is translating Chinese to German or building a puzzle, this question is at least sensible, but in the context of programming this question demonstrates a categorical misunderstanding.

In programming, the source code is the primary independent variable under the programmer’s control. Without a means of assessing whether a change to that variable has a positive or negative effect, programming will feel at best mysterious, and at worst a useless exercise in the arbitrary arrangement of abstract symbols. Once the relationship between code and program behavior is identified and understood, the learning process is far from over, but without that understanding I don’t think it can even begin.

Proposed Interventions