Women are a minority in the software industry but throughout the research I was conscious of my gender only when people asked me “are you looking at gender differences?” This question never came from participants and I never felt that they treated me differently for my gender. The fact that only two interviewees were female serves to underline the fact that I am inevitably used to being a non- stereotypical programmer. I wear this lightly and in these interviews my salient identity was simply that of programmer, but I should consider the possibility that gender stereotypes may have made it easier for participants to share their thoughts with a good listener with whom they can discuss things that have gone wrong without loss of face. If so, it was not to the detriment of the research. In a later conversation with a participant he agreed when I likened the process to “therapy for developers”. If finding me easy to talk to was a factor, it was a positive one that encouraged participants to share what was on their minds. It thus enhanced the contribution of the research by faciliting a rich understanding of the issues that are important to developers.
My age did not appear to be a factor in the interviews either. Given their considerable experience in the industry many of the participants were of a similar age to me, but there was little discernible difference between the age groups except the greater degree of reminiscing from the older participants. However it is possible that my age (and thus experience) interacted beneficially with gender. Women in technology do sometimes experience credibility barriers. For example: “I had a client where I had to bring a guy to every meeting, with detailed notes on what he should say. The client ignored everything that came out of my mouth, so I got a myself a dude as a frontman” (Aas, 2019). While I have never resorted to such a drastic solution, the problem is an all too familiar one.
A personal characteristic that I do believe was very important is that I am an experienced programmer myself. Participants in the Exploratory Study were aware of this; it was mentioned on the information sheet they received before taking part, I talked about it at the start of the interview when explaining the motivation for the research, and in some cases they had first met me as a programmer. They all spoke to me as a peer, using our shared technical vocabulary in ways that would not have been possible had I not been an experienced programmer. They opened up as to a discreet peer who shares their profession but not their workplace. It struck me as a kind of conversation they could rarely have so freely: at work, what they can say is constrained by the necessity of maintaining a good working relationship or reputation; elsewhere, it is limited by commercial confidentiality and the extent to which friends and family understand and are interested in the subject. The participants appeared relaxed about speaking to me, talking freely about companies, products and colleagues, including people they knew I was interviewing.
I was concerned that my own experience might influence the discussion too much. In the event it was more of a benefit than an intrusion. Rapley (2004) argued that an interview is a cooperative work of both parties, and that sharing one’s own stories can facilitate the conversation. The benefit was evident in the technical nature of stories I heard, told in specialist language (e.g., acronymns such as IDE; words with context- specific meanings such as kernel, commit and front end) which would have required clarification if I had not understood them. This would have broken the flow if done at the time or risked failure to accurately identify the concept if attempted later from the recordings. Occasionally sharing anecdotes with participants was helpful in establishing my credentials as a fellow traveller and often elicited recognition or further anecdotes from them.
My own programming knowledge certainly informed many of my requests for clarification or elaboration in the form “oh, do you mean this?” questions that
only a programmer could have asked. Participants did not passively go along with my interpretation. They frequently either elaborated on my version, or corrected it and elaborated. My own experience accords with Miller and Glassner (2004, p.130): “interviewees will tell us, if given the chance, which of our interests and formulations make sense and non-sense to them”.
The subject of the discussions was close to my heart. I think my efforts to prevent this from detracting from the quality of the research were successful. I was vigilant from the start and adjusted course when I caught myself talking too much in some of the early interviews. I learned from this - an important realisation was that people will say some really interesting things if I shut up and let them think. For most of the interviews the balance between my roles as a peer and a research seemed right. The peer role was, I think, as important as the researcher role; it is hard to imagine such rich, detailed and reflective conversations taking place between a software developer and someone who does not share their knowledge. Being an experienced programmer myself was instrumental in getting thorough and meaningful answers to my research question RQ1: “What is the perception of experienced programmers on the peer behaviours that help or hinder them in their own tasks?”
5.10 Conclusion
None of the findings of the Exploratory Study contradict the material in textbooks,
academic curricula and conference programs. But perhaps such sources focus
on practices that are less difficult to prescribe and measure, and on the hard technological problems — programming is, after all, not a simple task. There may also be some truth in the assertion that “the idea of the programmer as a human being is not going to appeal to certain types of people” (Weinberg, 1998, p.279). Walz, Elam, and Curtis (1993, p.74), observing that “We have historically valued both technical and communication skills in software designers”, suggested there is a need for companies to take measures to develop both in more depth. While tools and training exist for the technical skills, there is still no obvious equivalent for the communication skills, leaving plenty of scope for work that addresses this need.
Chapter 6
Evaluation study: Peer impact workshops
for software developers
6.1 Introduction
Research Question 2: Can experienced programmers’ accounts of the peer
behaviours that most help or hinder them in their own tasks be used to help others in their practice?
This chapter describes how the detailed design of the Evaluation Study introduced in Chapter 3 was developed in order to address Research Question 2, which is repeated above for convenience. The researcher’s observations and the participants’ feedback on the conduct of the Exploratory Study influenced the design. These ideas (§6.2) were evaluated in three pilot studies (§6.3 to §6.5) which tested and refined aspects of the workshop to inform its final design (§6.6).
The Evaluation Study tested the final workshop design for its ability to help professional software developers stop and consider a selection of peer behaviours, focus on those that most resonated with them, and explain the positive or negative impact locally. Based on the results of the pilot studies the workshop format used direct quotations from the interviews, representative of themes collected in the Exploratory Study, as its central material. The usefulness of the workshop to its target audience in helping them to constructively review their own practice was evaluated by obtaining feedback — both immediate impressions and later reflections — from the participants themselves. The results are reported in Chapter 7.