Student Response to Teaching of Memory Cues and Resumption Strategies in Computer Science Classes (director's cut)
by Noah John

The seminar on memory cues and resumption strategies

Each participant attended one seminar. In order to accommodate the fifteen participants' schedules, there were five seminars held by the same instructor. There were one to four participants in each seminar. The format was informal, students were encouraged to interrupt with questions, and a white board was heavily used by the instructor. All seminars covered the same material, and lasted 30 to 40 minutes depending on the number of student questions.

Effect of Interruptions

The seminar began with the instructor asking students about their knowledge of memory cues and resumption strategies, which was immediately followed by the instructor introducing the fact that there had been extensive research into the effect of interruptions and their cost to programmers. The major fact highlighted was that research had shown, on average, a programmer requires 15 minutes to refocus after being interrupted.

Memory Cues and Resumption Strategies

The instructor continued by describing various types of interruptions: in-person questions, phone calls, text messages, emails, social media alerts, and self-imposed breaks (like going to bathroom or getting food). Then, he introduced the fact that, in addition to the research on the effect of interruptions, there had also been research that had asked programmers how they minimize the effect of interruptions. Students were told that memory cues and resumptions strategies were ways programmers refocus faster. While they were shown to be helpful, there was no one technique that was better than another. Choosing a useful technique depended on the programmer's personal preferences. Hence, according to the instructor, the goal of seminar was to share some of those techniques with students.

Brain Dump

Before going into specific memory cues and resumption strategies, the instructor first discussed the high-level idea behind them, which he called a 'brain dump'.

"At its core," he said,"the idea is to dump the contents of your brain before you stop working in such a way that you can easily digest it and reload it into your brain when you resume. This is analogous with what an operating system does when it switches processes; it saves off (or dumps) the values of all the memory registers of the current process so its state is saved for when it runs again. While this example is very mechanical, conceptually it parallels this notion of a brain dump."

Resist Coordinating Interruptions Immediately

The instructor also stressed that, whenever possible, students should resist the temptation to address an interruption immediately and take a short period of time (even a few seconds would suffice) to do something that could help them refocus faster when they resumed. As an example, he mentioned that when asked a question while working, students could reply "give me a few moments" and use the time to mark their work and progress, as this could be helpful to them, yet also acceptable in the social context.

Note Taking

The first technique presented was note taking. "Notes can assume different forms," the instructor said. "They can be a list on a piece of paper or a collection of diagrams. It completely depends on the preference and style of the programmer."

He continued with a personal example, "When I worked in industry, I had a whiteboard at my desk. I would maintain an ordered list of tasks and reminders to help keep my focus. I would go so far as to give commands to my 'future-self'. For example, I would write something like 'after lunch, look at the file player.cpp and add speed logic on line 198 in the function MovePlayer()'. Many times, when following one of my directions, I would start by wondering why I wrote what I did, only to realize and remember thirty seconds later."

Code Commenting

The next technique covered was commenting code. While at first glance this seemed identical to note taking, the instructor pointed out that code commenting is sometimes preferred by programmers because it gives them the ability to annotate within the context of the code itself. They can insert TODOs without having to describe where in code to work. They can use pseudo-code to quickly outline an algorithm while it is fresh in their mind. They can scaffold entire blocks of code before actually implementing them, and use the scaffold to direct their work. The instructor also mentioned that commenting code has the advantage of being something quick and dirty for marking progress, but can be less effective if the memory cues need to cover multiple source files and/or if the editor has to be closed. A programmer might not remember what he or she commented before leaving, and hence not benefit from the comments when resuming.

Window Arrangement

Continuing that thread, the next technique was spatial window arrangement. The technique involved positioning all relevant windows (code editors, compiler output, internet reference material, etc.) in a way that highlighted the task at hand and the current state of the programmer's work. The instructor commented that this was a risky strategy because it assumed the computer's state would not change and because there were many ways the position of the windows could be disrupted without the programmer's control or knowledge. However, depending on the format of the information in each window and the ability of the programmer to associate position with the information's priority, it could serve as a good visual memory cue for remembering the previous work state.

Roadblock Cues

Roadblock cues were the next technique introduced in the seminar. This term was used by Parnin (paper link), and usually refers to when a programmer intentionally inserts a compile error into his code before turning his attention away from his work. Then, upon returning to work, the programmer compiles out of habit to help regain his context. In addition to presenting students this example, the instructor also pointed out how this technique does not rely on the programmer's workspace to be static during a break. The goal of mentioning this detail was to impart the differences among various memory cues and resumption strategies so students could better evaluate which ones could suit their programming style.

Selective Suspension

The final technique focused on selecting a good moment to stop working. Borrowing from a technique Ernest Hemingway employed as a writer (article link), students were told that some find it advantageous to avoid stopping at the end of something (e.g. in the case of writers, after completing a chapter) and instead of stopping in the middle of something. Meaning, if a student finished a task, it followed that he should begin the next task before ultimately stepping away. The logic behind this technique is that it is easier for a person in the middle of a task to remember what he was doing and harder for a person that has finished a task to remember what he did and determine what the next step should be. To relate to programming work, the instructor likened a chapter in a book to an encapsulated chunk of code in a program.

Student Questions

Given the informal nature of the seminar, students asked questions and other related topics were covered. One topic that was discussed in all the seminars was using white noise to help maintain focus while programming. Another topic that came up was the use of rituals to help prime the brain. By establishing a habit when performing a task, one could associate this ritual with a given task and thus facilitate a certain mindset by performing the ritual. The instructor did not affirm or deny the validity of the related topics that arose during discussions in the seminar.

Concept Maps

To conclude the seminar, the instructor introduced participants to concept maps and their relation to the brain. To start, he wrote the course name 'CS253' on a whiteboard and asked students to give him concepts that they thought of when thinking of their CS253 course. After a few answers, the whiteboard contained the following nodes: 'CS253', 'C++', 'classes', 'objects', 'pointers', and 'const'.

The instructor continued with the example, "So idea is that we can draw lines between related concepts. For example, when I think of pointers, I also think of objects because pointers can point to objects. Hence, I draw a line between the two. Also, I know we can have const pointers so I'll draw a line between those two as well. As you can imagine, concept maps can grow large quickly and have many connections. However, what this suggests is that people learn, at least in part, by associating new concepts with concepts that have already been learned."

The instructor then wrote 'Java' on the whiteboard, "In reality, when you started learning C++, you already had learned a lot of similar concepts already when you studied the Java programming language. You didn't have to build this from scratch."

Final Words

Finally, the instructor summarized what they had covered and mentioned that the core idea was that by knowing how the brain works, one can leverage that knowledge to help oneself when performing cognitive tasks, namely refocusing and concentrating. Before leaving, students were told that they would receive a follow-up questionnaire after they had completed their next programming assignment.

back to top