I learned the basics of writing code out of necessity. This was the way things were done in the early days of the “personal computer’. It took a while before many commercial programs were available and it was just kind of fun. I started with the books provided by Apple and some books that I purchased. Then there were the magazines. Do people still buy subscriptions to magazines that come in the mail once a month? Let’s see. There was Nibble (that is half a byte – old computer joke – try wikipedia for more information). Nibble was for the 6502 CPU or Mac only. There was BYTE – a magazine for the generalist. And, there was a magazine that I think was named Softtalk. It was basically mostly programs. You read the description in the magazine and you entered them into the computer and saved them to disk. 5.25 disks I might add. I remember what a tremendous bargain it was when a box (10) of Elephant brand 5.25 single side disks went on sale for $20. Anyway, I digress (actually this entire post is a digression).
Most of the time the program you entered from the magazine would not execute. It was very difficult to enter all of the code exactly. And then, there was this long list of numbers at the end of the BASIC code that would be poked into memory and then peeked when executed. This was the lower-level machine code that could do things BASIC commands could not. Understanding the numbers was hopeless. I did later learn to write some rudimentary assembly code that would be compiled into machine code. That type of coding was really beyond me and I learned just enough to understand and modify subroutines written by others. You learn a lot by puzzling over a small program that does not work. Looking for errors, debugging, can be quite educational. I learned to program by attempting to understand my keyboarding errors and by making programs that did fundamental things more and more complex. There must be some cognitive principles at work here and possibly some important educational lessons. When you are motivated and having a good time, mistakes are just opportunities for learning.
I published a paper in 1984 with Steve Mann based on the first sophisticated set of programs I was able to develop. It was a reading “game” called Master Detective focused on a cognitive skill called metacomprehension. When we read we sometimes misunderstand. This is normal for all readers, but more prevalent in less capable readers. What is important is whether we notice. Rereading is an effective remedy, but one must notice and then identify what must be reread. Researchers had been investigating this skill by purposefully creating flawed texts and then having young readers attempt to locate the errors. It was sometimes called the “proof reader” paradigm. It was a task that did reliably differentiate more and less skilled readers, BUT who actually reads anything looking for errors? Proof readers and teachers and maybe really critical people might look for errors, but not fourth grade readers. So, I wanted to create a game in which looking for errors made some sense.
I decided that one setting in which statements might be expected to be flawed would be in the interrogation conducted by a criminal investigator. And so, the game “master detective” was conceived. A detective read statements made by potential criminals and decided which statements were flawed and which were not. Flaws could be factual contradictions or cross sentence inconsistencies. Statements were 3, 5 or 7 sentences long. Each game consisted of two rounds. In the first round, the participant read 10 statements (5 of which were inconsistent) and in the second round there were 5 statements with one inconsistency. Get 8 out of 10 in the first round and make no mistakes in the second round and you were rated as a master detective. When the game focused on inconsistencies, you first identified a statement as flawed and then used the arrow keys to move from the beginning of one sentence to the next and had to press the space bar for the two sentences that were inconsistent. There were 10 suspects each with two acceptable and two flawed statements. The culprit, 5 individuals making flawed statements, and statements were randomly selected at the beginning of each game so you could play the same game multiple times and the experience would vary some. I also wrote a programwith my then student Steve Mann that recorded the data for participants and determined when a participant should move on to the next level of difficulty (determined by paragraph length). The operating system and the scheduling/data collection disk went into one floppy drive. The student started the computer and booted this drive. The student entered his/her name and the computer then told the student which game to play. The student located this game (floppy) in the box of disks, put this disk in the second drive, and played the game.
I placed four computers in an open setting housing two classes of fourth graders and it was a data generating machine. The schools had no computers at this time, the students seemed to enjoy the activity, and I could do research over an extended period of time with a population of real interest (translated – someone other than the college students we so often use in our studies).
If this sounds complex, I now think in describing it that it really was. I probably took me a year of fooling around to get to the point that I could write programs that would accomplish what I have just described and probably another year to complete the research. It was a different time. I probably published only a couple of studies out of this effort and pressure for publication would now make the effort I invested a foolish commitment. Still, it was something completely different from what anyone else was doing at the time or since as far as I know.
I have kept with this general approach throughout the last 20 years of my career – write your own code and conduct long term studies with real students in real learning environments. It is my plan and I am sticking with it.
