Last week I was giving a keynote at the annual workshop PPIG2008 of the Psychology of Programming Interest Group. Before I went I was politely pronouncing this pee-pee-eye-gee … however, when I got there I found the accepted pronunciation was pee-pig … hence the logo!
My own keynote at PPIG2008 was “as we may code: the art (and craft) of computer programming in the 21st century” and was an exploration of the changes in coding from 1968 when Knuth published the first of his books on “the art of computer programming“. On the web site for the talk I’ve made a relatively unstructured list of some of the distinctions I’ve noticed between 20th and 21st Century coding (C20 vs. C21); and in my slides I have started to add some more structure. In general we have a move from more mathematical, analytic, problem solving approach, to something more akin to a search task, finding the right bits to fit together with a greater need for information management and social skills. Both this characterisation and the list are, of course, a gross simplification, but seem to capture some of the change of spirit. These changes suggest different cognitive issues to be explored and maybe different personality types involved – as one of the attendees, David Greathead, pointed out, rather like the judging vs. perceiving personality distinction in Myers-Briggs.
One interesting comment on this was from Marian Petre, who has studied many professional programmers. Her impression, and echoed by others, was that the heavy-hitters were the more experienced programmers who had adapted to newer styles of programming, whereas the younger programmers found it harder to adapt the other way when they hit difficult problems. Another attendee suggested that perhaps I was focused more on application coding and that system coding and system programmers were still operating in the C20 mode.
The social nature of modern coding came out in several papers about agile methods and pair programming. As well as being an important phenomena in its own right, pair programming gives a level of think-aloud ‘for free’, so maybe this will also cast light on individual coding.
Margaret-Anne Storey gave a fascinating keynote about the use of comments and annotations in code and again this picks up the social nature of code as she was studying open-source coding where comments are often for other people in the community, maybe explaining actions, or suggesting improvements. She reviewed a lot of material in the area and I was especially interested in one result that showed that novice programmers with small pieces of code found method comments more useful than class comments. Given my own frequent complaint that code is inadequately documented at the class or higher level, this appeared to disagree with my own impressions. However, in discussion it seemed that this was probably accounted for by differences in context: novice vs. expert programmers, small vs large code, internal comments vs. external documentation. One of the big problems I find is that the way different classes work together to produce effects is particularly poorly documented. Margaret-Anne described one system her group had worked on that allowed you to write a tour of your code opening windows, highlighting sections, etc.
I sadly missed some of the presentations as I had to go to other meetings (the danger of a conference at your home site!), but I did get to some and was particularly fascinated by the more theoretical/philosophical session including one paper addressing the psychological origins of the notions of objects and another focused on (the dangers of) abstraction.
The latter, presented by Luke Church, critiqued Jeanette Wing‘s 2006 CACM paper on Computational Thinking. This is evidently a ‘big thing’ with loads of funding and hype … but one that I had entirely missed :-/ Basically the idea is to translate the ways that one thinks about computation to problems other than computers – nerds rule OK. The tenet’s of computational thinking seem to overlap a lot with management thinking and also reminded me of the way my own HCI community and also parts of the Design (with capital D) community in different ways are trying to say they we/they are the universal discipline … well if we don’t say it about our own discipline who will …the physicists have been getting away with it for years 😉
Luke (and his co-authors) argument is that abstraction can be dangerous (although of course it is also powerful). It would be interesting perhaps rather than Wing’s paper to look at this argument alongside Jeff Kramer’s 2007 CACM article “Is abstraction the key to computing?“, which I recall liking because it says computer scientists ought to know more mathematics 🙂 🙂
I also sadly missed some of Adrian Mackenzie‘s closing keynote … although this time not due to competing meetings but because I had been up since 4:30am reading a PhD thesis and after lunch on a Friday had begin to flag! However, this was no reflection an Adrian’s talk and the bits I heard were fascinating looking at the way bio-tech is using the language of software engineering. This sparked a debate relating back to the overuse of abstraction, especially in the case of the genome where interactions between parts are strong and so the software component analogy weak. It also reminded me of yet another relatively recent paper on the way computation can be seen in many phenomena and should not be construed solely as a science of computers.
As well as the academic content it was great to be with the PPIG crowd they are a small but very welcoming and accepting community – I don’t recall anything but constructive and friendly debate … and next year they have PPIG09 in Limerick – PPIG and Guiness what could be better!
The USP for Dabble DB amongst other online data sharing apps, is that it appears to really be a complete database solution online … and its USB amongst conventional databses is the way they seem to have really thought about real use. This focus on real use by ordinary users includes dynamically altering the structure of the data as you gradually understand it more. The model they have is that you start with plain table data from a spreadsheet or other document and gradually add structure as opposed to the “first analyse and then enter” model of traditional DBs.
