Psychology of Programming Interest Group : work in progress meeting: Day 1
Tuesday, 10 Feb 2015, 10:25
Visible to anyone in the world
Edited by Christopher Douce, Monday, 10 Jul 2023, 16:42
On 8 January 2015 I went to a mini-workshop: the Psychology of Programming Interest Group (PPIG) Work in Progress meeting. I’ve had an affiliation with PPIG for what must be at least fifteen years and I try to visit their meetings whenever I can. In some sense, returning to the PPIG meetings is like returning to a comfortable academic home: you regain enthusiasm for the research interests that you once held (and have an opportunity to say hello some familiar faces too).
This 2015 WIP event (as it is colloquially known) was held at the University of Middlesex in Hendon Town Hall and skilfully organised by Richard Bornat, who is a PPIG community regular. This short series of two blog post aims to summarise what were my own highlights.
Keynote talk: Thomas Green
The opening keynote was by Thomas Green, who is one of the founders of the group. Thomas told us what the group was about and emphasised the point that the group doesn’t just discuss research into programming, but also the activities that surround programming (and psychology too). Subjects for investigation have involved pair programming and explorations into the sociological and anthropological. Other research subjects have included computer science education and pedagogy, and studies into the relationship between personality and programming.
Thomas is known for creating (or discovering) the cognitive dimensions of notations framework (Wikipedia). His framework can be used to help us think about programming language design and user interfaces. Thomas described it as ‘ambitious in scope, [and a framework that] addresses any kind of information artefact’. Simply put, Cognitive Dimensions is a set of principles that helps us to think about stuff.
To explain, Thomas gave us a couple of examples. One of the dimensions is viscosity (which is my personal favourite!) Viscosity is, of course, an attribute of liquids: the higher the viscosity, the harder it is to push you hand through a liquid (for example) – I think I’ve got that the right way round! When it comes to the dimensions, this can be understood in terms of ‘changes’ to something (or, to move a system from one state to another). To make one change (to an information artefact), you might have to do a whole bunch of smaller changes before you get to your desired outcome.
Another dimension is: hidden dependencies. An example of this is the links or connections that might exist between the different cells of spreadsheets. You can’t immediately see what the connections between different cells might be, but you need to understand them if you’re going to understand and work with a spreadsheet.
This is all very well and good, but how does this relate to programming that we find in the real world? Thomas gave us a number of examples of computer code used with a content management system (CMS). Why study content management systems? Thomas had some good answers: they were widely used, often are pretty difficulty to get your head around (which is certainly true!), and they haven’t been studied very much.
If you’re interested in content management systems, this Wikipedia page presents an amazing list of different content management systems (Wikipedia). On the same subject of geek lists, this is another favourite of mine: comparison of web application frameworks (Wikipedia). You can spend hours looking though these different pages. These two summary links clearly show how big the ‘CMS space’ is. (As an aside, if you have too much time on your hands, there’s also a List of Cakes and a List of Lists)
An interesting point that Thomas made (which is one that resonates with my own experience), is that they all claim they are ‘easy to use’. Two examples that were spoken about were Wordpress (Wikipedia) and Drupal (Wikipedia). For the purposes of Thomas’s presentation, we looked at the Perch (CMS website), a CMS that I had never heard of before. The point was clear: Thomas’s framework can be used applied to study CMS’s and web frameworks.
After being mildly baffled with screens filled with code that used lots of angle brackets, there was a brief question and answer session. I think I made a comment that I chose a CMS based on the quality of the on-line tuition videos. My decisions were not based on language efficiency, but how easily I could see how to create something that similar to what I wanted to do. (I’ve often wondered about whether we could look to the murky world of media studies to learn about why some tools become more popular than others: there’s a whole other dimension of CMS systems that could be explored). There was also brief discussion about design patterns, since many of them make use of the model-view controller pattern.
It was pretty thought provoking stuff. When it comes to content management systems, I can’t help but think there’s an opportunity to use them as a vehicle to conduct research into the creation, development and sustainability of software communities.
Active error: examining error detection and recovery in software development
Tamara Lopez gave the first talk of the day, and within minutes of starting her talk, I had started to remember some research I looked at over fifteen years ago. Tamara’s research was all about human error and programming. As Tamara was speaking, I thought to myself, ‘I wonder whether she has heard of a researcher called James Reason. The answer came within minutes: of course she had.
Reason wrote a book called Human Error and carried out research into active errors (mistakes that happen in ‘real time’) and latent errors (which remain undetected within a system or product for considerable time). Have you ever bought a chocolate bar, unwrapped it from its wrapper and then thrown the chocolate bar away? Have you ever walked into a room and immediately thought, ‘why am I here?’ I recently put my keys in my fridge for no apparent reason. These, I guess, are examples of active errors.
The aim of Tamara’s research was to perform a naturalistic observation of error in programming, and gather reports of error occurrence. Understanding the characteristics of error can, of course, allow us to understand more about it and why error arises.
Tamara used a great method. She was studying pair programming data videos that had been published on the internet through a website called Pairwith.us (website). The developers were working on a project to adapt some kind of testing tool. Tamara analysed the errors in terms of incidents and themes. Some keywords that I picked up from Tamara’s talk were temporal, material and social. A good talk and interesting research.
Visual Analytics as End-User Programming
The second research talk was by Advait Sarkar who had travelled from the University of Cambridge. Advait gave a demonstration of some software that he had put together. The focus of his prototype appeared to relate to the area of data analytics, specifically, how the area of machine learning might be connected to a spreadsheet environment.
Following this session (and Advait’s demonstration) there was there quite a bit of discussion about different machine learning approaches such as decision trees and neural networks; subjects that I hadn’t really touched on or explored in any great depth since I was an undergraduate. Advait’s presentation wasn’t really in my area of expertise but it’s good to be exposed to different areas.
SQ and EQ and programming, revisited
The next talk was by Melanie Coles from Bournemouth University. I remember Melanie from other PPIG events, so it was great to see her again. It was interesting to hear that her talk related to some earlier research that she presented at PPIG back in 2007 (if I’ve understood this correctly).
The title of her talk was: ‘SQ and EQ and programming’ So, what exactly does SQ and EQ mean? I understand them as rough and broad measures of personality. EQ is an abbreviation for Empathy Quotient. Simply put, EQ is a measure of someone’s drive to identify with other peoples’ feelings and emotions. SQ, on the other hand, means Systemising Quotient. It is the extent to which people have a drive to understand rules governing things.
I’ve made a very rough note that Melanie related both measures to work carried out by Simon Baron-Cohen, who works in the area of autism research. I’ve made another note in my notepad that there are tensions between these traits, along with the sentence, ‘scientists score higher in AQ than non-scientists’.
Some studies seem to suggest a correlation between the role of programming and these traits. Other studies, on the other hand, don’t show anything. The message coming through is that you don’t have to be high on the AQ scale to become a programmer.
I don’t know that this means, but I’ve made another note that reads ‘polite grumpiness about sterotypes’ which might have been scribbled down during the question and answer session. I have no idea who was expressing polite grumpiness, or which stereotypes were being discussed. I do, however, feel that this expression should still stand and has some validity. A sensible rule is that if you’re going to take issue with stereotypes, you’ll go a lot further if you politely disagree rather than go around shouting about them. I should also add, that I have no idea how this paragraph relates to Melanie’s very good (and very clear) presentation. All this said, some really interesting ideas and (some exceedingly polite) discussions.
Psychology of Programming Interest Group : work in progress meeting: Day 1
On 8 January 2015 I went to a mini-workshop: the Psychology of Programming Interest Group (PPIG) Work in Progress meeting. I’ve had an affiliation with PPIG for what must be at least fifteen years and I try to visit their meetings whenever I can. In some sense, returning to the PPIG meetings is like returning to a comfortable academic home: you regain enthusiasm for the research interests that you once held (and have an opportunity to say hello some familiar faces too).
This 2015 WIP event (as it is colloquially known) was held at the University of Middlesex in Hendon Town Hall and skilfully organised by Richard Bornat, who is a PPIG community regular. This short series of two blog post aims to summarise what were my own highlights.
Keynote talk: Thomas Green
The opening keynote was by Thomas Green, who is one of the founders of the group. Thomas told us what the group was about and emphasised the point that the group doesn’t just discuss research into programming, but also the activities that surround programming (and psychology too). Subjects for investigation have involved pair programming and explorations into the sociological and anthropological. Other research subjects have included computer science education and pedagogy, and studies into the relationship between personality and programming.
Thomas is known for creating (or discovering) the cognitive dimensions of notations framework (Wikipedia). His framework can be used to help us think about programming language design and user interfaces. Thomas described it as ‘ambitious in scope, [and a framework that] addresses any kind of information artefact’. Simply put, Cognitive Dimensions is a set of principles that helps us to think about stuff.
To explain, Thomas gave us a couple of examples. One of the dimensions is viscosity (which is my personal favourite!) Viscosity is, of course, an attribute of liquids: the higher the viscosity, the harder it is to push you hand through a liquid (for example) – I think I’ve got that the right way round! When it comes to the dimensions, this can be understood in terms of ‘changes’ to something (or, to move a system from one state to another). To make one change (to an information artefact), you might have to do a whole bunch of smaller changes before you get to your desired outcome.
Another dimension is: hidden dependencies. An example of this is the links or connections that might exist between the different cells of spreadsheets. You can’t immediately see what the connections between different cells might be, but you need to understand them if you’re going to understand and work with a spreadsheet.
This is all very well and good, but how does this relate to programming that we find in the real world? Thomas gave us a number of examples of computer code used with a content management system (CMS). Why study content management systems? Thomas had some good answers: they were widely used, often are pretty difficulty to get your head around (which is certainly true!), and they haven’t been studied very much.
If you’re interested in content management systems, this Wikipedia page presents an amazing list of different content management systems (Wikipedia). On the same subject of geek lists, this is another favourite of mine: comparison of web application frameworks (Wikipedia). You can spend hours looking though these different pages. These two summary links clearly show how big the ‘CMS space’ is. (As an aside, if you have too much time on your hands, there’s also a List of Cakes and a List of Lists)
An interesting point that Thomas made (which is one that resonates with my own experience), is that they all claim they are ‘easy to use’. Two examples that were spoken about were Wordpress (Wikipedia) and Drupal (Wikipedia). For the purposes of Thomas’s presentation, we looked at the Perch (CMS website), a CMS that I had never heard of before. The point was clear: Thomas’s framework can be used applied to study CMS’s and web frameworks.
After being mildly baffled with screens filled with code that used lots of angle brackets, there was a brief question and answer session. I think I made a comment that I chose a CMS based on the quality of the on-line tuition videos. My decisions were not based on language efficiency, but how easily I could see how to create something that similar to what I wanted to do. (I’ve often wondered about whether we could look to the murky world of media studies to learn about why some tools become more popular than others: there’s a whole other dimension of CMS systems that could be explored). There was also brief discussion about design patterns, since many of them make use of the model-view controller pattern.
It was pretty thought provoking stuff. When it comes to content management systems, I can’t help but think there’s an opportunity to use them as a vehicle to conduct research into the creation, development and sustainability of software communities.
Active error: examining error detection and recovery in software development
Tamara Lopez gave the first talk of the day, and within minutes of starting her talk, I had started to remember some research I looked at over fifteen years ago. Tamara’s research was all about human error and programming. As Tamara was speaking, I thought to myself, ‘I wonder whether she has heard of a researcher called James Reason. The answer came within minutes: of course she had.
Reason wrote a book called Human Error and carried out research into active errors (mistakes that happen in ‘real time’) and latent errors (which remain undetected within a system or product for considerable time). Have you ever bought a chocolate bar, unwrapped it from its wrapper and then thrown the chocolate bar away? Have you ever walked into a room and immediately thought, ‘why am I here?’ I recently put my keys in my fridge for no apparent reason. These, I guess, are examples of active errors.
The aim of Tamara’s research was to perform a naturalistic observation of error in programming, and gather reports of error occurrence. Understanding the characteristics of error can, of course, allow us to understand more about it and why error arises.
Tamara used a great method. She was studying pair programming data videos that had been published on the internet through a website called Pairwith.us (website). The developers were working on a project to adapt some kind of testing tool. Tamara analysed the errors in terms of incidents and themes. Some keywords that I picked up from Tamara’s talk were temporal, material and social. A good talk and interesting research.
Visual Analytics as End-User Programming
The second research talk was by Advait Sarkar who had travelled from the University of Cambridge. Advait gave a demonstration of some software that he had put together. The focus of his prototype appeared to relate to the area of data analytics, specifically, how the area of machine learning might be connected to a spreadsheet environment.
Following this session (and Advait’s demonstration) there was there quite a bit of discussion about different machine learning approaches such as decision trees and neural networks; subjects that I hadn’t really touched on or explored in any great depth since I was an undergraduate. Advait’s presentation wasn’t really in my area of expertise but it’s good to be exposed to different areas.
SQ and EQ and programming, revisited
The next talk was by Melanie Coles from Bournemouth University. I remember Melanie from other PPIG events, so it was great to see her again. It was interesting to hear that her talk related to some earlier research that she presented at PPIG back in 2007 (if I’ve understood this correctly).
The title of her talk was: ‘SQ and EQ and programming’ So, what exactly does SQ and EQ mean? I understand them as rough and broad measures of personality. EQ is an abbreviation for Empathy Quotient. Simply put, EQ is a measure of someone’s drive to identify with other peoples’ feelings and emotions. SQ, on the other hand, means Systemising Quotient. It is the extent to which people have a drive to understand rules governing things.
I’ve made a very rough note that Melanie related both measures to work carried out by Simon Baron-Cohen, who works in the area of autism research. I’ve made another note in my notepad that there are tensions between these traits, along with the sentence, ‘scientists score higher in AQ than non-scientists’.
Some studies seem to suggest a correlation between the role of programming and these traits. Other studies, on the other hand, don’t show anything. The message coming through is that you don’t have to be high on the AQ scale to become a programmer.
I don’t know that this means, but I’ve made another note that reads ‘polite grumpiness about sterotypes’ which might have been scribbled down during the question and answer session. I have no idea who was expressing polite grumpiness, or which stereotypes were being discussed. I do, however, feel that this expression should still stand and has some validity. A sensible rule is that if you’re going to take issue with stereotypes, you’ll go a lot further if you politely disagree rather than go around shouting about them. I should also add, that I have no idea how this paragraph relates to Melanie’s very good (and very clear) presentation. All this said, some really interesting ideas and (some exceedingly polite) discussions.
A great end to the first day!