Editors: Roman Bednarik and Chris Douce

Contents

Editorial by Roman Bednarik

PPIG 2009 Workshop Report by Jim Buckley

PPIG 09 Competition Rules by Dermon Shinners-Kennedy

Work in progress 2009 workshop - by Gabriela Pavel

Spotlight on PPIGers
Andres Moreno, University of Joensuu
Chris Martin, University of Dundee
Sami Pietinen, University of Joensuu

Calls for papers
Forthcoming PPIG Workshops
PPIG WIP 7-8 January 2010: call for papers.
PPIG 2010
2010 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC'10)
Special issue: IEEE Software Special Issue on the Cooperative and Human Aspects of Software Engineering

The journals PPIGers can submit to (and get eventually accepted) by Marian Petre

Book Review: Studying Programming by Sally Fincher and the Computing Education Research Group by Chris Douce

Connected links  by Chris Douce and Roman Bednarik

Mailing Lists

Acknowledgements

Editorial - Finally

by Roman Bednarik

Welcome to the first issue of PPIG newsletter in 2009, and let me apologize for the extended period of silence of this periodic since October 2008. We seemed to have some hiccups with this issue, for several reasons: first and mainly, the new editor is a chaotic procrastinator. Second, he likes to take long vacations in one block to help him forget the tasks to do. Third, every now and then he tries to elicit contributions to cover up his procrastination, but to no avail - neither he receives enough contributions nor the primary problem of hanging back is suppressed.

But then, only under the constant pressure from the active part of the PPIG community, we managed to squeeze out what you can find below. This number features, among others, a review of PPIG 2009 meeting as well as of the WIP little PPIG. In a highlight of this issue, Marian Petre gives a word of advice for those who look for venues to publish PPIG-related research, this time she concentrates on journals.

We all will agree that Chris Douce was doing a great job with this newsletter since 2001 and he deserves big thanks. Thank you Chris! This newsletter would not exist without the contributions, so thanks go namely to the Chris’s, Jim, Gabriela, Marian, Andrés, Sami, and to others for help and feedback. Enjoy reading and send me feedback about the newsletter to roman.bednarik (at) cs.joensuu.fi

PPIG 2009 Workshop Report

by Jim Buckley

The 21st PPIG was held in the University of Limerick from the 24th to the 26th of June this year. Surprisingly, the sun shone for the whole 3 days of the conference, a sequence of dry weather that hasn’t been seen in Limerick since 1427.

The competition for the workshop this year was to develop a Limerick about your PPIG presentation or about PPIG in general. Many took to this task very enthusiastically (thanks Lutz), and this workshop report is interspersed (littered?) with their efforts.

As regards the workshop itself, day one opened up with the doctoral consortium, followed by lunch and a Keynote from Michael Kolling, detailing his attempts to resurrect programming. Most recently his efforts have focused on the development and usage of his Greenfoot ‘you-wouldn’t-even-know-you’re-programming’ programming environment, with the aim of enthusing novice programmers:

Motivation is really the key
It’s what everyone seemed to agree
‘Least what they told us
Before they enrolled us
But I still got a lousy degree
(Michael Kölling)

After this keynote there was a session dedicated, appropriately enough, to education. In this we heard about the huge efforts made to instil problem-solving skills into students (Orna Muller). Afterwards, Saeed Dehnadi presented on how he substantially refined his empirical study of “consistency as a predictor of programming prowess” in the light of the reviews he received when he presented his work at an earlier PPIG. His work was best summed up by his Limerick:

Iranian student Saeed
Said students can guess what they need
And those who guess wrong
Will never grow strong
So teaching can never succeed
(Saeed Dehnadi)

The final activity of day one was a Panel discussion on whether good programmers are created by forces of nature or nurture. The panel members were Peggy Storey, Chris Exton, Judith Good, Keith Gallagher, Thomas Green and Marian Petre. Heated discussion led to a charged atmosphere – so charged in fact that the lights went out and left the lecture hall in total darkness for several minutes. However, the debate eventually gave way to the following consensus:

So nurture not nature is key
But don’t just take it from me
The eminent panel
After lots of flannel
Seemed, at least, on this point to agree
(Dermot Shinners-Kennedy)

Or did it…

Is programming skill about nature,
Or is it about nurture?
I think that the rub
Lies in the ‘or’ nub
And it’s never so simple a picture
(Marian Petre)

After this draining debate, the delegates retired to the ‘CoffeeBean’ and enjoyed an evening of traditional Irish music, with finger food and a drink or two.

Day 2 started with a session which asked if software development was truly a collaborative, social activity. Collaboration in programming was the dominant theme in this session with 2 papers focussed on characterizing paired and side-by-side programming. Roman Bednarik, for example, reported on work that aimed to characterize paired programmers’ eye movements and Lutz Prechelt used a phenomenal 18 Limericks (an astounding one every 1.12 minutes) to characterise cooperation in side-by-side programming. Here is just a small taste of the offerings that kept Lutz up until 3:30 the preceding night:

Pair Programming is fine
for quality, learning, and time,
but it can be boring
or overly soring,
so try Side-by-side 5 til 9. \

We want to describe what they do
when people pair up as a crew.
Want to see what goes well
and what goes to hell,
to advise, to make promises true. \

There are some slides that are really hard
to put in a Limerick Format
This is one of these
so please stay at ease
if it is not quite as informative and as well-structured as the others
(Lutz Prechelt)

Other papers in this session reported on the types of questions posed to colleagues on Open Source mailing lists and the responses they typically obtained (Khaironi Yatim Sharif) and on determining if programming languages are really improving as a communication medium for programmers (Gilles Dubochet).

After tea, Keiron Nicholson gave a memorable paper that echoed back to the ‘abstract is an enemy’ paper presented at PPIG ’08. This paper served to refine ‘abstracting’ practice to address the concerns voiced in the original ’08 paper. However, Keiron’s paper was dwarfed by his magnificent contribution to the Limerick competition, a contribution that resulted in the award of a special prize during the closing ceremony. Keiron won the ‘36th place’ award for his effort (a considerable achievement considering we only had 34 entries):

Asked to concoct a limerick
I attempted to write a limerick
I picked out some rhymes
And used up my rhymes
In the process of writing the limerick
(Keiron Nicholson)

Kieron was followed by a presentation given by Jim Buckley on the cognitive levels employed by programmers while maintaining and evolving software systems. This work was originally carried out by Tara Kelly for her doctorate degree. The associated Limerick that Jim presented was, due to its total disregard for rhyme, structure (and in some cases semantics), a strong contender for the coveted ‘36th place’ Limerick award:

There was a young fellow called Bloom,
Who’s passion, him did consume
His resulting ability
To categorize cog dexterity
For exams, and learning outcomb
(….and process?)
(Jim Buckley)

The session concluded with a paper by Agata Vitale, discussing the procedures used for training and testing abstract comparative relations: relations that appear frequently in source code and reflect a core cognitive ability required of programmers and maintainers.

The final session of the day focused on source code. Michael English looked at the structural features of the code to identify differences between C++ and Java language usage. Daniel Delorey discussed the application of corpus-linguistic techniques to source code and, in the third presentation, Chris Exton reported on a simple, yet powerful, visualization tool developed by Michael Desmond:

A system with so many lines of code
meant such a cognitive load
So a tool was invented
So the load might be circumvented
So now all of you shall behold!!
(Chris Exton)

Day 2 concluded with a tutorial on Greenfoot by Mikael Kolling, and the conference dinner in the picturesque village of O’Brien’s bridge.

Day 3 started of with the 2nd Keynote of PPIG 2009, given by Keith Gallagher. Keith took an introspective look at the things that cause him grief as a programmer and presented some alternatives that he thought might alleviate his (and other programmers’) load. Keith’s agenda to ‘make sparks fly from rubbing ideas together’ is well captured by his Limerick:

We have floats, we have ints, e’en a bit
But it’s what’s in our heads doesn’t fit
To get “us” in “there”
I really don’t care
So I hope that this talk stirs some sh*t!
(Keith Gallagher)

The final session of papers looked at different aspects of software engineering, from end-user programming, through software architecture to testing. Ruth McKeever discussed named ranges in Spreadsheets, and their implications for bug fixing:

For a spreadsheet developer
To make them seem clever
A pipe dream maybe
If it works hopefully
They should make not one error!
(Ruth McKeever)

This was followed by 2 talks on software architecture. One, by Jacek Rosik, discussed how it might be possible to keep the implemented architecture consistent with the designed architecture over the lifetime of systems. The other, by Jack Downey, characterized the software developers who specialize in defining software architecture.

The final paper of this years PPIG was presented by Tuula Paakkonen and discussed the improvements in testing protocols in communication software. PPIG was then rounded off with the final prize-giving ceremony and lunch in Kieran’s vegetarian Restaurant. The Prize for the best ‘in presentation’ Limerick went to Michael Kolling for the Limerick presented above. The most ‘Gestalt’ Limerick prize this year went to Rebecca Yates and I will sign off this PPIG workshop report with her entry:

I travelled on buses and trains
To PPIG to talk about brains
And coding and pairing
And teaching and sharing
And code that is hard to maintain

At the conference (my very first)
Found the speakers were speaking in verse
And to my surprise
A pig is the prize
Is this normal, or quite the converse?
(Rebecca Yates)

PPIG 09 Competition Rules

by Dermot Shinners-Kennedy

To complement the end results of PPIG Limerick for Limerick competition, I must to share an abridged version of the competition rules.  Many thanks to Dermot Shinners-Kennedy for composing this fine opus.

To participate you must try writing verse for a while
Adhering to a special type of rhythm and rhyming style
Because of these tricks
The verses are called limericks
And really good ones can make people break into a smile

The PPIG community has people with all sorts of degrees
And maybe some of them can pen limericks with ease
But by way of example
We offer this little sample
As a guide, or for some maybe a tease

Technically speaking these sample verses are not right
They rhyme correct but have rhythm errors that are slight
So write just for fun
Five rhyming lines of pun
And we promise to keep verse-pedants well out of sight

It would be great if from every attendee
We received works we could call literary
So we invite you to submit
Stylish verses with some wit
About the 21st psychology of programming jamboree

To “PPIG things” the verse should try to make reference
Well to begin with that is definitely our preference
But we will not inhibit
A literary exhibit
Which to our guidelines shows a degree of indifference

For example, when listening to an inspired paper or keynote
It may trigger recollection of an amusing anecdote
Just jot down five lines
With appropriate rhymes
If people like it you have our permission to gloat

Or maybe you are a conference paper presenter
With the insight of a creative inventor
In your presentation implant
A rhyming five-line rant
That encapsulates what your presentation has as its centre

There is no limit to the number of entries you can submit
But try to keep them all amusing and if possible literate
For tenure they won’t count
But depending on the amount
You may discover you have a compulsive verse writing habit

Rewarding the best entries is a problem that arises
And for this the conference organisers are offering two prizes
One for verse in presentations
The other for gestalt observations
The best wordsmiths can look forward to some little surprises

It’s the judge’s decision that will finally end it
And unfortunately some entrants may be offended
If you need to whinge or moan
Please try to do it when alone
Because we want to make sure the prize-winners feel totally splendid

So whilst in Limerick indulging your favourite research antic
Having travelled across or towards the Atlantic
Use all your common sense
Exploit real or artificial intelligence
And let’s make the number of verse submissions absolutely gigantic

Work-in-progress 2009

by Gabriela Pavel

http://kmi.open.ac.uk/people/member/gabriela-pavel

The last edition of the work-in-progress meeting of the Psychology of Programming Interest Group was held by The Centre for Research in Computing, at the KMI Podium, The Open University, Milton Keynes. The meeting was a chance for discussions between professionals and students in both computing and psychology fields. Editorial guidance was provided by Maria Kutar, from the University of Salford, and Thomas Green  who is affiliated with the University of Leeds.

The work in progress workshop occurred on the 8th and 9th of January 2009 with a group of approximately sixteen participants from and led to interesting discussions.

The workshop started with the talk on software visualization, given by the invited speaker, Dr. Jim Buckley from the University of Limerick. Dr. Buckley. Jim gave a talk entitled ‘Software Visualization: Did anyone ask what the software developers want?’ and treated members of the audience with a range of tantalizing visualisations and spoke about his collaborations with industry.  It was great to hear comments about developers from industry clearly benefiting directly from PPIG related research.  Software visualisation, along with related areas of visual programming languages and algorithm animation represent strong themes that have been addressed and considered by different PPIG researchers.

The programme continued with six presentations distributed over three sessions and contained presentations from software development and cognition.

Christopher Martin presented an ethnographic study on the solving of programming problems. The presentation highlighted the importance of understanding the programmer in its environment to select the software development tools who have the advantages to support the programmer in his work. The work environment was also the topic of the presentation given by Christopher Douce who focused on understanding the IT worker in his work place.

Software development implies also the understanding of cohesion and the correct use of identifier names. Steve Counsell studied cohesion metrics and found that cohesion improvement is dependant of the size of the code analysed. Simon Butler investigated the link between readability of the source code and the quality of the the identifier names.

Within the cognition-based part of the workshop, Maria Kutar proposed a theoretical framework for cognitive dimensions.  Rather than presenting foundations based upon or within psychology or cognitive psychology, Maria proposed the possibility of philosophical foundations. The third presentation of the morning session was by Gabriela Pavel who focused on understanding the question of how to support the learning of concepts from images.

The work-in-progress meeting provided interactivity during the presentations but also during the three interesting workshop sessions. Thomas Green and Luke presented the Inform language (wikipedia) to demonstrate how the computer can help the programming by using a set of sentences written in natural language. Luke Church reviewed the rules of building games and participants had the chance to image games for given rules. Marian Petre focused on the nature of evidence, reflected in how people present their contribution to knowledge and what methods are to be used for this purpose.

The first day continued the workshop discussions during the dinner at the Ye Olde Swan, to whom we thank for the menu and the hostpitality. We also have to mention the reception of the Berril Building for the lunch and to KMI admin team for the coffee breaks provided. We are grateful to the participants who made this workshop an opportunity to discuss matter of interest for people from the PPIG.

The work-in-progress event was an interesting experience thanks to the participants, the admin teams from Computing and KMI departments of the University, and the organizers. I thank especially to Prof. Marian Petre, Prof. Thomas Green and Dr. Maria Kutar whose help was very important before and during the workshop.

http://kmi.open.ac.uk/events/wip-ppig-2009/programme.html

Spotlight on PPIGers

We welcome announcements and introductions about your current research, projects, openings and stuff interesting for the PPIG-community.

Andrés Moreno, University of Joensuu

I found myself teaching programming in Tanzania some time ago. My previous teaching experience included assisting a programming teacher in England. At England I started to analyzing how students use and understand the automatic visualization of programs provided by Jeliot 3 (1), which I helped to develop. The first results indicated that students were not able to properly process the repeated animations of common operation like string concatenation. More complex operations, like object creation, resulted in puzzled students that knew what an object was and how to use it but could not describe the steps shown in the animation tool (2).

In Tanzania I tried to work out a experiment to get a better insight in what happens when students try understand Jeliot’s animation, and how their knowledge changes after repeated visualizations. The number of participants was low (6), but some of the initial findings point out that some of the students fail to benefit from the visualization alone. They also could not describe the running animation properly, but improved slightly when they wrote down the meaning of snapshots taken from the animation. I will submitting the results for publication soon.

As part of the research I have created a modification of Jeliot 3 that automatically introduces mistakes in the animation. That is, correct source code will produce incorrect animations; and it is students’s task to spot the error if there were any. The goal is to force the students to visualize carefully the animation and check their knowledge (or lecture notes) constantly. As well, critical thinking should be promoted. You can give it a go at 3.

1 http://cs.joensuu.fi/jeliot

2 http://dx.doi.org/10.1016/j.entcs.2007.01.033

3 http://cs.joensuu.fi/jeliot/oop/

Chris Martin, University of Dundee

I work as a researcher in the School of Computing University of Dundee. I’m currently employed on a collaborative project called MATCH (Mobilising Advanced Technology for Care at Home) which is exploring how technology can prolong and enhance the independent living of older adults and disabled people living in their own home. The team in Dundee are particularly interested in supporting the dialogue of care between the cared for and the complex network of stakeholders that surround them. A key focus of this is understanding people and the relationships that exist between them, as this is vital when augmenting these relationships with technology in an effective and appropriate way. We have employed existing method such as questioners and focus group work as well as more novel methods including live forum theatre to focus and stimulate multi stake holder debate.

My personal research (working towards a PhD) is concerned with understanding the role of tools to support creativity and problem solving in programming tasks. I seek to employ rich user engagement methods to understand current practice, tools and technique in commercial software house. The analysis of this data should provide the information required to produce tools that fit the domain, users and context of use.

These disparate activities are joined by a strong motivation to develop better methods to understand the people we write software for; Enabling software to not just work but ‘fit’ the user and the context of use.

Sami Pietinen, University of Joensuu

I focus in my research on the problem of software development productivity that has been in great interest for several decades now. There has not been any silver bullet -pardon the cliché- in the form of robust solution to meet the ever growing demand for software and I see it very unlikely to surface in the near future, though I would surely be gladly surprised if it did.

The solution to productivity problem is multidimensional, because in addition to raising programming productivity by developing more efficient integrated tools, the human cognition needs to be also better supported. On top of these, outcomes of software projects are group efforts and as contemporary software systems are more complex in structure and size, we need multiple developer teams and solutions to the restriction in efficient knowledge sharing in distributed environments. In other words, we need new solutions to the “usability of software engineering”.

I search the solution to the underlying productivity problem by combining software process improvement, cognitive usability and eye-tracking. My current interests include, among others, improving pair programming protocol and supporting shared attention in distributed software development by superimposed eye-movements. All things considered, I see productivity as a combination of challenges related to human factors, process factors and supporting tools, bundled with proper theories to build on. For further details and discussion, please contact me at sami (dot) pietinen (at) joensuu (dot) fi.

Calls for papers

Forthcoming PPIG Workshops

PPIG WIP 7-8 January 2010: call for papers

submission of extended abstracts (1 to 2 pages)

16th November 2010

Hello all,

The Psychology of Programming Interest Group (PPIG) invites software engineers and researchers to submit abstracts for its 6th Work-in-Progress meeting, to be held at the School of Computing at the University of Dundee, Scotland. The PPIG work-in-progress workshop is a forum in which researchers at all levels can present and discuss current work, recent results and developments concerned with psychological aspects of software development. A feature of the PPIG workshops has been their openness to a wide spectrum of concerns related to programming and software engineering, from the design of programming languages to communication issues in software teams and from computing education to high-performance professional practice. Similarly, PPIG encourages a broad spectrum of research approaches, from theoretical perspectives drawing on psychological theory to empirical perspectives grounded in real-world experience.

Please email your abstracts to me directly at cjmartin@computing.dundee.ac.uk before the 16th of November.

PPIG 2010

Madrid, Spain, September 2010

PPIG 2010 will be collocated with VL/HCC'10 in Madrid! A great opportunity to participate in both. In accordance with PPIG tradition PPIG 2010 will be a place where psychologists, ethnographers, software engineers, computer scientists and just about anyone who is interested in furthering our understanding and application of the psychology of programming, can present and discuss their recent work. We look forward to the typical lively discussions between experienced researchers, practitioners and doctoral students. Students will also be able to attend the PPIG Doctoral Consortium, a special session where they can present and receive feedback on their PhD research. A full call for papers will be coming out soon.

2010 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC'10)

Madrid, Spain, 21-25 September 2010

http://dei.inf.uc3m.es/vlhcc10/

From the beginning of the computer age, researchers and computing practitioners have sought ways to make interactions with computers more human-oriented. For example, visual languages have long been used to provide effective communication between humans and computers. Visual languages have been successfully employed for end-user programming, modeling, and rapid prototyping; they have supported design activities by people of many disciplines and backgrounds including architects, artists, children, engineers, and scientists. In the last few years, a number of languages and technologies have incorporated visual interfaces to facilitate human-human communication through Web technology and electronic mobile devices.

The IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC) is the premier international forum for researchers and industrial practitioners to discuss the theory, applications and evaluation of technologies, visual and otherwise, that make computing more accessible to humans. Established in 1984, the mission of the IEEE Symposium on Visual Languages and Human-Centric Computing is to support the design, formalization, implementation, and evaluation of computing languages that are easier to learn, easier to use, and easier to understand by a broader group of people.

This includes all research aimed at the above mission, regardless of whether it uses entirely visual technology, text, sound, virtual reality, the Web, or other technologies. Examples of research addressing this problem include, but are not limited to, language and environment design and implementation; theory and empirical studies that support the many media used toward this goal; and software comprehension (including software visualization), modeling, and engineering, especially as they are applied toward the above goal.

We solicit original, unpublished research papers that focus on one or more aspects of human-centric computing technology–for instance visual programming or interaction, text, sound, virtual reality, the Web, or other multimedia technologies.  Research papers may address cognitive, social, cultural and design aspects, underlying theories, formal methods, taxonomies, implementation efforts, tool support, and empirical studies. We also solicit short papers that present work in progress or demonstrations of tools. Areas of interest include, but are not limited to, the following:

• Visual languages for programming, modeling, and communication
• Visual domain-specific languages
• End-user software development
• Computer-mediated human-human communication
• Empirical studies of human-centric software technologies
• Languages and tools for domain-specific software development
• Multimodal interaction
• Sketch and Gestural Computing
• Software visualization and algorithm animation
• Visual or multidimensional model-driven development
• Visual and Spatial/Temporal Reasoning
• Visual Query Languages and Databases
• Visual Techniques for Business Processes and Workflow

Important Dates:

Workshop/Tutorials:

• Informal “intention to submit” email: 4 January 2010
• Submission of proposals by email: 11 January 2010
• Notification of acceptance: 1 February 2010

Abstract submission: 22 February 2010

Paper submission: 8 March 2010

Notification of decision: 18 May 2010

Camera-ready copy: 14 June 2010

Special issue: IEEE Software Special Issue on the Cooperative and Human Aspects of Software Engineering

Although the paper deadline has now passed, an IEEE Software special issue has requested ‘high quality examples of multi-disciplinary research and practice that explore how cooperative and human aspects affect how software is created and evolved, both in terms of the challenges and the successes which arise when the human aspect is considered. We are looking for papers with practical reliable insights that can be applied in real-world software development contexts’.

It is interesting to note that the call for papers have requested that submissions should have a practical orientation, and be written in a style accessible to practitioners.

The anticipated publication date is between November and December 2009.  We look forward to learning more about the special issue when it is released.

The journals PPIGers can submit to (and get eventually accepted)

by Marian Petre, The Open University

In this article Marian Petre offers great advices for those who do research on PPIG-related issues and are wondering which publication forum they should go for.

**Figuring out where to publish: **

• Look at the journals you’re reading.

• Look at the journals you’re citing.

• Look at the journals in which your research colleagues (including your PPIG colleagues) are publishing.

• Look at the publishing history of someone you would like to emulate – where do they publish, and where did they publish early in their career?

• You might want to glance at the acceptance rates, impact factors, and circulation figures – but don’t be overwhelmed by them. 

• Figure out what you want to accomplish with the publication.  Sometimes a wider readership is more important than refereeing; sometimes the reputation of the journal matters to you more than readership; sometimes you’ll be looking for a niche market. 

Targeting a journal:

• Read the journal’s editorial policy or statement of aims and scope:  does your topic match the focus of the journal?

• Look at the editorial board:  who is shaping the journal’s policy?

• Many journals also publish a list of reviewers.  Who would be reviewing your submission?

• Consider the audience.  Does the journal have the readership you wish to reach?  Would the journal’s readership have an interest in your material?

• Look at what’s been published in the journal in the past year or two.  Consider not just the topics that are covered, but also the form, content, and scope of the articles, the type of studies, the literature they cite, and so on.  Is your paper comparable in type and style?

• Look to see if the journal has a target turn-around time.  Some journals publish submission dates with each paper – look to see what the interval is between submission and publication.  Often, monthly journals have a quicker turn-around than those published more frequently, but this does not mean that they have a higher acceptance rate.

• Read the guidelines for contributors (you’d be surprised how many authors neglect to do so, sigh). Pay attention to details like word limits, constraints about figures and tables,

Taking initiative:

• Some journals have a mentoring scheme for young researchers; email the editor and ask.  If the journal doesn’t have such a scheme, you might ask a wise, experienced, friendly researcher to play such a role for you.

• Some editors will offer advice prior to formal submission.  You might contact the editor asking politely for advice about whether the paper is ‘in scope’ and appropriate, and how best to present it for the readership.  But be warned:  some editors will send the manuscript to referees at this point.  Also take care:  if you ask for advice, then you’d best treat it seriously.

• Ask someone who has published in the journal about their experience with it. Again, take care:  theirs is but one experience.

• Do keep track of the process.  Find out what the timeline is, and then ask politely about progress at appropriate intervals, if you haven’t heard from the editor.

Publishing is a process:

• Aim high.  Why not?  You may succeed, and if you don’t succeed, you’re likely to learn something.

• Learn from the process.  Rejection is not an end, just a step along the way.  If you can’t be objective about the referees’ reports, then get someone to go through them with you.  Take note of the compliments as well as the criticisms. 

• Work through referees’ comments systematically.  Referees can genuinely help to improve papers, so it’s best to assume that they’re acting in good faith (and to avoid thinking of them as idiots).  If the referee misunderstood, then it’s the author’s responsibility to make the text clearer. 

Notes:

The following list is by no means complete.  The titles offered are ones that have published papers of the sort cited by PPIG authors, or papers cited in such papers. The information is offered in good faith, based on a meander around the internet. I apologise in advance for any inaccuracies, which are inadvertent.

Italics indicate the journals my students most often target.

Programming languages / software engineering:

HCI

CSEd / Education

Design

MIS

Journal of Systems Management

MIS Quarterly

Psychology

British Journal of Psychology

Cognition

Cognitive Psychology

Computers in Human Behaviour (0747-5632 bi-monthly; 2007 impact factor 1.344)

European Journal of Cognitive Psychology

Irish Journal of Psychology

Journal of Applied Behaviour Analysis

Journal of Applied Psychology

Journal of Experimental Psychology

Journal of Eye Tracking Studies

Journal of Memory and Language

Journal of Occupational Psychology

Memory and Cognition

Organisational Behaviour and Human Performance

Personnel Psychology

Psychology

Psychology Review

Quarterly Journal of Experimental Psychology

The Psychological Record

Note: Psychology journals have a style all of their own, and often politics to match. Do your homework before submitting – work out exactly what sorts of paper the journal publishes, who the referees are, and what sorts of credentials they expect.

Book Review: Studying Programming by Sally Fincher and the Computing Education Research Group

by Chris Douce

I discovered this book completely by accident when I was looking for a completely different book on programming.  I found what I wanted, but I also decided to take this book out too.  I don’t know the underlying processes that made the university library choose this particular text, but I have to confess that I do approve of their choice.

This book isn’t directly written for educators or those involved with teaching programming.  Instead, as it’s title indicates, it is book that is aimed at those who are studying computing or trying to get to grips with what programming.  The first chapter elucidates by stating that the book is, ‘for students in the final two years of school, in Further Educational colleges or the first year of university; as well as those who support such students’.

Studying Programming is completly language agnostic - an decision that I totally commend.  The second chapter has a title as well as a number.  The title is in the form of a question that asks, ‘what is programming?’  Interstingly, this second chapter delves into the world of mysterious (and interesting!) notations, mentioning music, knitting notation and the language and rules of heraldry http://en.wikipedia.org/wiki/Heraldry, something that I had never heard of before.  Very interesting!  This important chapter concludes by presenting some ‘real’ code after introducing the concepts of instruction sequent, selection and interaction.

A nice touch was the title of the third chapter: everyone makes mistakes.  Presenting a whole chapter to tell students of programming, ’that you will make a whole raft of different mistakes, and this is okay!’ is a great idea.

One thing that programming text books and manuals don’t really tend to present is guidance about how to learn.  The next chapter is entitled, ‘before you start’ and contains a useful section entitled, ‘getting the most out of your teaching’.  Learning strategies are just as important as programming (and debugging) strategies.  Sometimes you need little tips or nudges to allow you to learn how to get the best out of the resources that you have at your disposal.  This chapter is all about how to do just this.  An implicit point being (in my opinion) is, ‘your learning is your responsibility’.  You could, of course, extend this point by also saying, ‘go ahead and learn from your mistakes, and try to have fun in the process’.

The chapter about your first program introduces the notion of ‘hello, world’, alongside descriptions of the tools of the trade.  Of course, a single program doesn’t make a programmer, so further chapters cover writing your ’nth program’, introduces object-oriented programming and explores issue relating to debugging and testing.  The often challenging issue of paradigm (and the related question of ‘why are there different languages?’ are address.  Attributes are not only discussed in terms of classes, but also in terms of the programmer and how students may step towards forming a career in programming or developing their interest further.

All in all, a fun, easy book to read that presents a lot of material in a friendly and accessible way.  In some respects, I will always continue to be a student of programming, but I do feel that I have internalised some of the pearls of wisdom that ‘studying programming’ clearly presents.  When I was reading it, I asked myself the question, ‘would this book have been useful to me if it had been available when I picked up my first interpreter or compiler?’  My answer is an undoubtable ‘yes’.  I would even go as far saying that had this text been on the shelves when I was learning, it would have probably helped a lot.  The trick is, of course, having other people, i.e. your parents, teachers and lecturers telling you what is good for you.  I hope that many early students of programming are recommended this text.

Studying Programming is published by Palgrave MacMillan.

www.skills4study.com

ISBN 1-4039-4687-6

Connected links

by Chris Douce and Roman Bednarik

Somehow I don’t think this song, Let’s sing about recursion, will feature highly on the iTunes download charts, but I have to commend the idea of using a multimodal approach to the teaching of a difficult subject.

This is quite a fun article: Old school programming techniques that you probably don’t miss and I have to confess I was rather surprised to see that the first two entries featured as assignments within my undergraduate degree (writing of sorting algorithms and coding of graphical user interfaces).  I do, however, have a sense that time spent learning the magic of binary sort was time well spent, along with the trials and tributions of using a DOS based graphics API that I have never seen or, nor heard of since.

On a similar note, I learnt about a blog post entitled: Should Fortran be taught to undergraduates?

My gut instinct is to say ‘yes’, since this is something that I had to go through when I was an undergraduate.  I remember the delight in the eyes of the lecturers when they said, ‘you will be asked to make changes to a 40KLOC Fortran project - we will hand you the specifications on two sides of A4 paper…’  I found it to be a formative experience.  All undergraduates should be presented with a similar (or equivalent) challenge: it builds moral fibre.

Jumping from the old, to the new, another blog post is entitled: Does parallel processing require new languages?

The article mentions two languages that I have not heard of: Chapel and X10 (wikipedia)

On the topic of new languages, I recently was directed to an article about a new programming language called R  (Wikipedia).  The article, published on the New York times website, is entitled: Data Analysts captivated by R’s power

More information is available from the R Project website.

The article, What do you consider “readable” code? considers an oft repeated question.  I personally found the discussions to be quite readable. Some language inspire debate regarding the issue of readability, and Perl is no exception. 

Last year Computer World had a series of articles about different programming languages. The article that describes Perl is entitled Culture and community go hand-in-hand with Perl programming. A (quite old, circa 2007) connected link is the following YouTube video, which is entitled: Clay Shirky on Love, Internet style. It’s ten minutes in length, and is a part of a conference keynote. It’s very watchable (and very quotable). One that made me smile was, “we had a fight about which programming language to use. It’s like ‘hello’ between techies”.

Information and system security represent important issues that software developers and designers should pay close attention to.  I recently discovered a List of the top 25 programming errors.

One way to reduce errors is to remove to functions which are implicated in causing or creating nasty effects.  This approach is demonstrated in the article: Memcpy() banished in Redmond.

But how do we ‘get into the zone’ to battle against these errors?  I have heard about football supporters having superstitions like the wearing of lucky pants, the same pants that were worn when the supported team won a big tournament.  Do software developers have rituals or superstitions?  Apparently, some of them may have, as an article entitled Programming magic: Rituals and habits of effective programmers /a>.

But what if your ’error’ wasn’t really an error?  What if you were a programmer who created some software that might have caused other kinds of problems.  I really liked the slideshow (and the writing) in the article My Manhattan Project : How I helped build the bomb that blew up Wall Street.

Ideally, I would like my development environments to be easy to use.  You develop a easy to use toolset, there is a likelyhood that there may be more developers inclined to use it, which I why I found the article Sony: PS3 is hard to develop for - on purpose.

Joh Hunt, a ppig regular and software development XP ethnographer has sent me an interesting blog post: 10 Papers Every Programmer Should Read (At Least Twice). My confessions is that althrough I recognise almost all of the writers, I have not read some of these papers (even once). It looks like I’ve got some catching up to do.

The draft version of this newsletter was written using an on-line document editing and collaboration tool which provided some of the functionality that can be found within popular word processing programs.  For quite a while now, web based applications that make use of the ‘cloud’ has been a fashionable subject - but could there be a new generation of software development tools that could use functionality offered through a web browser? 

The following article: Web-based IDEs to become mainstream? asks this question and tantalises us with the possibility of ’effortless collaboration’, through the sharing of the configurations of different software development tools.

Computer science education is a perennial PPIG topic.  I recently saw this article: Bjarne Stroustrup on Educating Software Developers. I encourage you to read the final section of this article which presents some advice to new (and not so new) programers.  These, I feel, are wise words.

And finally… I should end with a link that is a combination of funny and inspiring: Apple I BASIC as a Mac OS X Scripting Language. If you do a bit of digging in this blog you will be able to find other gems, such as a scripting language inspired by Commodore 64 Basic, and a copy of the Apple Lisa Operating System Reference manual.  It’s amazing the things you learn about through Twitter!

PPIG Mailing Lists

As many of you may be aware, the name of the PPIG mailing lists have changed.  All members who were subscribed to the old mailing list are now members of the new mailing lists.  The new lists are hosted and managed by the Open University Institute of Educational Technology. There are two lists:

• ppig-announce-list@open.ac.uk - This list is used for announcements, such as calls for papers and information about conferences and workshops.  If you wish to be kept up to date about when the next PPIG workshop is occurring, this the the one to subscribe to.

• ppig-discuss-list@open.ac.uk - The discuss list is a list used to ask for information and debate ppig-related issues. 

Both lists are relatively low volume. To subscribe to either mailing list, visit the PPIG Lists page.

Acknowledgements

I thank you all for being so kind,
Your files make a newsletter to help us unwind,
When the page is prepared
And are rhymes are declared
We can celebrate what we divined.
(Chris Douce)