I’m quite pleased; the tension I was feeling over the behaviorist/cognitivist point of view was, primarily, my wondering what would come of conversation with my supervisor. But we were in complete agreement on what I thought was the right way to proceed; as such, I’m going to concentrate my efforts on exploring the role of timing in novice programmer compilation behavior from a behavioral perspective.

As for teaching, I will probably end up teaching what I know, but I did make a request to be kept in mind if anything “interesting” comes along. We’ll see what happens, but at worst, I know what I’m dealing with, and will have that much more time to focus on my research. That can’t be all bad.

The Programmer

I’ve been wrestling with behaviorism for the last few weeks. Granted, most of that time was also time spent travelling, but while on the plane, the train, or other “dead” times, I’ve been trying to wrap my head around a behaviorist’s view of compilation. This post is a “think-aloud” that I can point a few friends at and ask them to weigh in with some thoughts as well.

Compilation is how a computer program gets changed from something people can read (arguably) to something a computer can run. Most code written today is compiled, and certainly all introductory students use a compiler of some sort. Typically, students encounter their first compiler as part of an “Integrated Development Environment” like BlueJ or DrScheme: a pedagogical piece of software that wraps up all the tools necessary to write and run code in one language or another.

I’d like to focus my research on the way students use the compiler. Literally, in many environments, this means I want to know when and why do students press the button that compiles (and runs) their code? That might not even be it, though; a substantial goal of any first course in computing is to provide students with some facility to express core concepts of computing in code. We are, at some level, concerned with producing a facile programmer… but I’m about to get ahead of myself.

I need a picture.

Students working on code go through a cycle of Editing code, Compiling code, and Executing code. Each of these represent a set of activities; so, Editing implies typing in new code, fixing old code, searching through the documentation regarding part of their code, etc. Any one program undergoes iteration after iteration as students work towards, say, completing a homework set for an introductory course in computing.

If I were playing the part of a cognitivist, I’d (perhaps?) be interested in what is going on in the student’s head. For example, I’d want to understand how each incremental change of source code (each “code delta” that took place between compiles) mapped onto some kind of plan or schema the student might have for solving a particular problem, how change episodes manifested themselves (and the relation of their mental state during the changes they made to that particular episode type), or any of a host of other questions trying to get inside the Thought Bubble in the picture above.

However, Compilation is a behavior.

Assuming the editing takes place in the boxes, the arrow indicates the place where the student presses a button, telling the computer to do some work proofreading the student’s code, making sure all the semicolons and parentheses are in the right places, etc. As a result of this automated process, either: A) success occurs (and the program is executed for the student, or some indication that the program can be executed is given), or B) a whole mess of garbage comes back.

A few things for the casual reader:

1. It is likely that most introductory students don’t actually understand (in any significant way) what is going on when they compile (and execute) their code.
2. Compilers are typically written for use by professional programmers. For example, many novices use Java in their first course in computing. The Java compiler they use (the one provided by Sun Microsystems) is NOT designed for use by my mother. It is designed for use by a trained software engineer. Therefore, the
   1. method of invoking the compiler (running it) may be obtuse, as well as
   2. the vocabulary and necessary interpretation of the error messages it produces.

All this said, the Environment the student is working with while programming (the operating system, text editor, the room they’re working in, the music they’re listening to, etc.) is very complex. The compiler makes up part of this environment, and it is, while programming, most likely the primary agent a student is interacting with. And the pattern is roughly:

1. Edit some code.
2. Press the button.
3. Be rewarded with success, or punnished with failure.

This is a classic behavioral loop. That couldn’t stop me, of course, from taking a cognitivist’s view of the process; I could explore how code changes from Edit episode to Edit episode, and attempt to map the mental states of the programmer in some way.

Or, I could take a behavioral perspective, and begin by doing a behavioral analysis of novice programmers in classroom settings (and perhaps home settings as well), attempting to identify what behaviors are associated with Editing, Compiling, and Executing code. Once these behaviors are identified, I can then begin exploring the behavior of Compilation systematically, and attempt to identify the key Antecedents that lead to Behaviors with positive Consequences.

A : B -> C

Put another way, I can begin looking for the environmental conditions that engender compilation behaviors with desirable outcomes, where desirable is defined (perhaps?) as a compilation event with no errors.

There are lots of problems here, certainly. For example, perhaps a desirable outcome would instead be any compilation event where there were fewer errors than during the previous compilation event. I could also challenge a commonly held view that student’s don’t think enough before compiling their code: from a behavioral perspective, you can actually force the issue of time, and make it impossible for students to compile any more frequently than, say, every 3 minutes. (Assume for the moment I’m discussing laboratory, not classroom conditions.) From a behavioral perspective, there are many controllable variables with respect to compilation that could be explored, and I’m getting bogged down in them.

Once upon a time, I had a hard time coming to grips with qualitative research methods, perhaps because of my background in Physics. Among other things, I think I’m rebelling against the behaviorist’s mindset, which is that we can explain a great deal about Earth’s creatures from a purely behavioral perspective, including (gasp!) people. Leaving a cognitivist framework for my research seems… I don’t know. I feel like I”m just putting students in a box with a lever and a food-pellet slot when I start thinking along behaviorist lines. But, at the same time, the analogy between the two is clean, and there have been few behaviorist studies of programmers and programming behavior. Almost all of the research in CS Education to date takes a cognitivist approach, and attempts to understand the mind of the programmer, and largely ignores the behavior.

Hmm. Comments welcome.