Psychology of Programming Workshop

It's been well over a month since I last posted. I've been away for a few weeks on vacation and attending the Psychology of Programming Workshop in Ireland. The workshop lasted three days and was very interesting. I'm going to provide summaries of the papers that I found to be of particular interest, starting with the first paper, 'Aspects of Cognitive Style and Programming' by Rebecca Mancy and Norman Reid of the University of Glasgow, UK.

Rebecca Mancy presented research that she has done as part of her PhD work on Computer Science Education. She investigated the effect of two cognitive characteristics, working memory space and field dependency on the abilities of students to achieve pass rates in introductory programming courses. Working memory is a fairly well known concept - it holds information that needs to be paid attention to immediately and processes that information such that it can be stored into long term memory for later retrieval. Field dependency is not a concept that I was familiar with. It measures the extent to which a person is capable of extracting relevant information from a larger set of both relevant and irrelevant information.

 

Rebecca used standard techniques to measure both working memory and field dependence for a group of students who were studying an introductory programming course and then correlated the results with the students exam results throughout the academic year. Her objective was to identify the effect that working memory and field dependence have on exam results and to describe ways that teaching methods might accommodate this. She found no correlation between working memory and exam results but did find a strong correlation between field dependency and exam results. She explains the lack of a correlation between results and working memory by suggesting that the exams and lecture materials had already taken working memory into account and did not overly burden the students working memories. The field dependency correlation is of interest though. While much programming research identifies the ability to recognize clichéd programming patterns or plans as one of the differences between expert programmers and novices, it is not clear how this can be taught or how development environments can aid novice programmers in recognizing this.

 

It seems that the only way to improve a person’s field dependency is through experience. For example, only after significant exposure to certain programming idioms and patterns will a developer be able to chunk large pieces of a program together in their head and thus be more able to reason about the behavior of the whole program. If someone approaches a programming problem that requires them to be able to recognize certain patterns but they have not yet developed the expertise to be able to do so, they may not be able to solve the problem and instead of pursuing it further, they may simply give up. What aids can the development environment, programming language and APIs provide to make this easier for developers and to reduce the drop out rate?

It seems that the development environment would be the most fruitful place to provide aids in this matter. For example, color coding helps distinguish between keywords, variables, string literals, comments etc. Indentation is another way to help recognize patterns. However, it is less clear how a programming language or API can be designed in such a way that people with low field dependency can still recognize patterns of usage that the API requires. The first thing that comes to mind is to minimize the amount of clutter in the API to begin with. With less clutter, it might be easier to pull out the relevant information for a given task. However, this isn’t something that I have thought long and hard about – it would be good to spend more time on this and to understand better how it affects the way that people use an API. I'd also be really interested in thoughts or feedback from anyone else on this matter.

Comments

• Anonymous
  April 18, 2004
  >However, it is less clear how a programming
  >language or API can be designed in such a way
  >that people with low field dependency can
  >still recognize patterns of usage that the
  >API requires.
  
  As you mention, organization of the API material is a big plus. This would, ideally, include appropriate cross references (to accound for the different ways people think of these ideas), many examples of how to use the API, and interaction of a specific API to other related calls. If you manage to stumble upon the exact API you're looking for, but can't reason the full solution based on the material provided, this additonal barrier might encourage you to give up.
  
  To go with the experience factor, I'd also include the ability to ask questions. Some can reason out the functionality of an API based solely on reading the documentation. However, many need a place to sound out their thinking. Certainly there are places to do so, but not everyone knows about them or is comfortable approaching an established group. Perhaps an ability to "ask an expert" in a one-on-one situation (even if the "expert" is forwarding the issue on to a larger group) would help mitigate this uncomfortability.