As I mentioned a few weeks ago, while attending Dev8D, I surveyed developers working in or for universities. Here are the results. Click on the images below to view them full size. The data can be downloaded (minus email addresses and institutional affiliation).
What does the survey tell us? Well, it’s only 35 people out of about 250 that attended the conference. I also posted the link on Twitter, so it was open to abuse (it certainly wasn’t under controlled conditions!), but looking through the data, I don’t think it was spammed.
The last question shows that about two-thirds of respondents are keen to remain working in the sector and just under half of respondents are not looking for promotion. I expected that to be higher, given that a similar number have only worked in HE for 0-5 years, but maybe they’re entering at a level where promotion is less important to them. About a quarter of people said it was their first proper job. Other people are entering the sector from both public and private organisations in equal measure. A large majority of respondents are or have been in line management positions. Just under a third of developers can see themselves moving into management positions, away from day-to-day development, while a similar number aren’t sure.
In terms of how long they have been writing code, there was an even spread across the range of years and a corresponding response to whether people consider themselves novices, experienced or expert. Two thirds of respondents studied programming at university, but a larger number consider themselves self-taught. The two responses are not exclusive of course. The majority of people prefer web development and the choice of programming languages reflects that, too. There’s lots of use of source control applications, about half of people are using formal development frameworks and fewer people are using Continuous Integration.
Two thirds of people said that they work autonomously, are proud of the work they do, and get on with their colleagues, which is nice to hear 🙂 However, only a third of people think they are paid pretty well and just under a half said that they enjoy their responsibilities 🙁
About two thirds of respondents feel that their work forces them to learn new things all the time. While others only learn new things occasionally or on side projects. The majority of people learn from figuring it out on their own, but many people also learn from web articles, forums, books and colleagues. Training opportunities also seem to be available and, not surprisingly given we were at Dev8D, about half of respondents are encouraged to go to conferences and workshops. Of course, time and money keep people from attending such events, but more worryingly, there’s evidence that at some institutions, it’s ‘not the done thing’.
From my own work, I was interested to see that there’s little culture of involving students in the work of developing services for HEIs, with two-thirds of people saying they never or rarely employ students.
There’s more detail in the numbers, so do have a look for yourself. For me, this was a useful first attempt to get a sense of the motivation, opportunities, interests and challenges for hackers working in universities. I intend to follow it up with a more formal and controlled survey, as well as observation of teams across the country. If you’d like to invite me to observe and interview you and your team, please do let me know 🙂
Comments about the survey and the results are welcome below, too. Thanks.
I spend most of my time working with students and recent graduates. At first Alex, then Nick and Jamie, and in a week or two, Dale and Harry will join us. Dale and Alex are finishing up their final year in Computer Science and work as part-time Developers in ICT Services. Nick, Jamie and Harry graduated last year from studying Computer Science and work with me on JISC-funded projects. They’re all in their early to mid twenties. I learn a lot from them. Sometimes they make me feel old. I’m only 38.
In a year or so, they’ll probably move on to other things. Alex and Nick already have their own company and a business plan. Jamie wants to do a PhD. If I can secure us interesting and useful work, maybe Dale and Harry will stay on for a while longer, I don’t know. I hope they will stay but it needs to be for a good reason otherwise I would encourage them to look for new challenges.
These days I wonder how we (‘the university’) can support young hackers like the bunch I work with. Career progression for developers working in universities is not great. Paul Walk recognised this as does the JISC-funded DevCSI project, run by Mahendra Mahey. Without their work, which highlights the importance of local developers, I think the HE sector would be a pretty barren place for hackers to commune. No Dev8D, no DevXS, fewer hack days and developer workshops. Along with several other people, I was invited to be on the Steering Group for DevCSI today, which I am very pleased about, and I look forward to working with the project more closely in the future.
There are a few things I’d like to focus on with DevCSI, based on my experience working with young hackers: the first is about how hackers learn. As I see it, this requires research into the history of hacking in universities, the role of undergraduate and graduate students in funded research, from ARPANET to Total ReCal, hacking as a cognitive craft that has its own learning communities and learning environments, that creates tools which help improve the effectiveness of learning and how those tools eventually shape the tools the rest of us use to learn.
The second thing I’d like to focus on, is how universities can learn from what we see happening in hacker culture: new reputational models, fablabs and hackerspaces, peer-production, and new methods of funding. On this last point, I’d like to develop an academic programme that attracted hackers and graduated start-ups. I think the Y Combinator model is a good example of this already happening, where students and recent graduates are receiving a little funding and lots of support, while asking for just a very small cut of the company.
Finally, I’d like to think about how we can break down the distinction between developers working in professional services and developers working on research projects and remind ourselves that we all work in universities: autonomous institutions for research, teaching and learning, and that when companies want to instill a culture of innovation, they often emulate the research culture of universities. I’d like to work towards developers in HE knowing there was the opportunity to be paid the same as professors when they clearly add similar value to the institution, which I think is easily possible. I see no reason why great hackers – experienced software craftsmen and women – working in universities shouldn’t be paid £100K or more, just as professors and other senior staff can be. Of course, working in a university, they would teach other hackers, run software development projects, contribute to the strategic direction of the university and produce superb software for the institution, too. Would they be on an academic or a non-academic contract? I don’t know. At that level, I don’t think it matters, but at the junior and middle periods of their careers it remains a divisive distinction that affects people’s aspirations.
Being great hackers, they would attract students that aspire to be great hackers, too. Just as I decided which graduate school to study at based on the reputation of a single professor working there, so young hackers would want to work with and learn from great hackers in universities, even more so if their programme of study included a Y Combinator style opportunity for angel investment.
I’d like to see an academic programme led by experienced software craftsmen with reputations to match, where students from different disciplines spend their degree in a university space that resembles a hackerspace or dojo, working together on ideas of their own under the guidance of more experienced staff, leading to potential angel investment at any point in their degree. Those that don’t get funded, leave with a degree, a valuable experience and a network of alumni contacts. Those that do get funded are given the support they need to develop their work into a real product or service. Sometimes, it might be one that the university would use itself, but not always. Over time, successful alumni would help attract more students to the programme, developing a culture of hackers and successful startups attached to the degree programme.
What excites me about this is that it’s a mixture of what universities always say they are about: research, teaching, learning and enterprise, but it recognises that those processes are changing and that hackers are already developing a model that is replacing these functions of the university: the opportunities for learning, collaboration, reputation building/accreditation and access to cheap hardware and software for prototyping ideas, can and are taking place outside universities, and so they should. However, I think that university culture is still a place where the hacker ethic (respect for good ideas, meritocracy, autonomy, curiosity, fixing things, against technological determinism, peer review, perpetual learning, etc.) remains relevant and respected. A university is a place where people come to learn from each other and we should be creating these new spaces and programmes that recognise the value of developers in universities.
Like any programme of study, work and investment, it needs careful thinking about how to set it up right, but from where I stand, it feels like a gaping hole in higher education that needs to be filled. Do you know of any examples that are already running? A ‘MIT Media Lab lite’ could be close to what I have in mind, but I have no experience of how it’s run and whether it breaks down the distinction between academic and non-academic staff to the extent I have in mind.
During my attendance at Dev8D last week, I used the time to start pulling together some ideas I’ve been knocking around for a few months now. Most of the projects I’ve helped set up or led over the last three years have involved working closely with developers working in higher education and ever since JISCPress, we’ve been growing a culture where student developers, either on bursaries, employed part-time or full-time recent graduates (i.e. their first ‘proper job’) are core contributors to the project. My point here is that through these projects I have been able to observe how young hackers learn their craft and make the transition from a formal education in Computer Science to learning on the job (i.e. apprenticeship).
DevXS http://devxs.org
I use the word ‘craft’ deliberately. I think our work is much more closely aligned with craftsmanship than with engineering but I was unsure how to articulate this until I read Pete McBreen’s Software Craftsmanship. McBreen argues that a focus on craftsmanship is to return to the roots of software development:
Good software developers have always understood that programming is a craft skill. Regardless of the amount of arcane and detailed technical knowledge that a person has, in the end, application development comes down to feel and experience.
McBreen distinguished software craftsmanship from software engineering and computer science, not as their opposites but as a different tradition “that happily coexists with and benefits from science and engineering.” He compares the software craftsman to the blacksmith, both of whom transcend science and engineering and benefit from improvements in their tools, materials and understanding. For McBreen, GNU/Linux is an example of software craftsmanship that thrives due to the dedication, skill and craft of the people who contribute to the development of the operating system.
‘Software engineering’ was born out of a so-called ‘software crisis’, identified at a NATO conference in 1968. It was determined that the way out of that crisis was to apply an engineering approach to large scale state of the art defence projects. Since that time, argues McBreen, “the needs of the US Department of Defence have dominated the conversation about software engineering.”
software engineering is not all that relevant to many projects. Software engineering was created to solve the problems of really large groups working on multiyear projects. Most modern software development, however, is done in relatively small teams.
Not surprisingly, the practise of software craftsmanship is often allied with agile development, which emphasises the human aspects of software development, the creative and variable processes involved in creating software that meets human needs. Both share a concern with quality and both encourage continual reflective critique of one’s work in order to improve the software and oneself. In his book on Crystal Clear, for example, Alistair Cockburn identifies ‘reflective improvement’ and ‘osmotic communication’ as two of the three minimum requirements for a Crystal Clear project. In practice, reflective improvement refers to workshops and end-of-iteration discussion about how the work is going and how it might be improved. Osmotic communication refers to how flows of information between developers should be unobstructed by locked doors, walls and corridors. It’s about sitting developers in the same or adjacent rooms so that they absorb information about the project with as few barriers as possible. Access to information, a safe environment where people can respectfully speak their minds and close collegial working are highly valued. At times, developers will program side-by-side or in pairs at one workstation, so as to review each others’ work. He refers to this as ‘peer code peering’.
Both reflective improvement and osmotic communication can be enhanced by the choice of tools developers use and the feedback they provide to her. Craftsmen in all trades rely on their tools to provide feedback – a joiner’s plane, a responsive power drill, etc. Many craftsmen will make their own tools to improve their responsiveness. Cockburn notes that one of the most important tools developers can use is an automated regression test suite, which allows the team to continuously test their work and provides feedback to each developer about the quality of their code. Feedback from a Continuous Integration (CI) suite of tools can be usefully presented by ‘information radiators’, dashboards which typically provide status information of servers, the number of use cases delivered and the number of tests passed. Although, Cockburn doesn’t use the term, I think that reflective improvement and osmotic communication refer to the ‘learning environment’ that the software craftsman creates so as to improve their understanding of their work and further develop their craft.
References to the importance of learning from others and from one’s work are made throughout McBreen’s book, as well as an entire chapter at the end of the book called ‘Perpetual Learning’. There, he outlines how to create a ‘learning environment’ by building a library of books for developers to read, as well as ensuring that they take time out each week to practice or learn something new. Like Cockburn, he emphasises the importance of workshops and a series of seminars where developers discuss their work. In addition, McBreen suggests that developers are encouraged to attend and present at conferences and write papers about their work as well as take on the role of instructor where they are able to do so. Craftsmen continually undertake self-directed learning, preferring non-proprietary, open source tools that are sustained by a community and made freely available to learn from, but more importantly, software craftsmen learn from each other, with master craftsmen mentoring journeymen and apprentices.
In a more recent book on software craftsmanship, Apprenticeship Patterns, Hoover and Oshineye also devote a chapter to ‘Perpetual Learning‘, offering further practical advice to aspiring software craftsmen. They list the following:
Expand your bandwidth: Read books and articles, engage with your peers via conferences, social media and mailing lists, join user groups, study from open educational materials on the web
Practice, practice, practice: Take the time to practice your craft without interruptions, in an environment where you can feel comfortable making mistakes. i.e. ‘deliberate practice’ They borrow the term ‘code katas’, whereby programming exercises are repeated again and again until they become ingrained in the individual.
Breakable toys: Budget for failure by designing and building toy systems that are similar in toolset, but not in scope to the systems you build at work. i.e. build something personal to you, that you will learn from. Develop your own CMS or game that you can afford to break while learning.
Use the source: Seek out other people’s code and read it. Start with the applications and tools you use every day.
Reflect as you work: Become a reflective practitioner of software development. This involves regular introspection into how you are working.
Record what you learn: Keep a record of your journey in a journal, personal wiki, or blog. A chronological record of the lessons you have learned can provide inspiration to those you mentor, since it makes your journey explicit, but it can also give you a vital resource to draw upon.
Share what you learn: Early in your apprenticeship, develop the habit of regularly sharing the lessons you have learned. i.e. keep a blog, run workshop sessions, be part of a community of learners.
Create feedback loops: Create mechanisms for regularly gathering more or less objective external data about your performance. i.e. automated regression tests, information radiators, exams and certifications, pair programming, and asking your peers what they think.
Learn how you fail: Seek to identify the ways in which you tend to fail and try to resolve those that are worth fixing.
In his book, The Craftsman, Richard Sennett chooses to focus on open source software development as a modern form of craftsmanship (“the skill of making things well”). The value of Sennett’s book is its breadth of scope. While making no reference to McBreen’s earlier book, Sennett situates open source hacking and the development of GNU/Linux within the social and economic history of craftsmanship and our relationship with technology. For Sennett, Linux is a “public craft” and open source hackers are a “community of craftsmen.” In terms of learning this public craft, he compares ancient pottery making with open source hacking and finds that only the speed between problem finding and problem solving differentiates the two. In programming, and especially open source programming, the velocity at which we can learn can be much greater than in traditional, material crafts. Our tools and the open, distributed nature of developer communities enhance our opportunities for learning. ((Sennett’s observations also help us consider software craftsmanship together with learning theories such as cognitive apprenticeship, situated learning, and constructivism.))
In The Nature and Art of Workmanship, David Pye does not make reference to software development but does develop a very useful framework for identifying and understanding craftsmanship, which complements much of what Sennett and McBreen describe. For Pye, craftsmanship is the workmanship of risk; that is, work that is constantly at risk of error in the process of creation. A simple example of this is writing with a pen. In contrast to the workmanship of risk (craftsmanship) is the workmanship of certainty; that is, workmanship where the quality is always pre-determined and is usually found in quantity production, and always in fully automated work. An example of this would be modern printing. The workmanship of certainty is most common in modern, industrial society, but has existed in some form for hundreds, if not thousands of years. All types of workmanship exist somewhere on the axis between risk and certainty and furthermore are subject to varying degrees of regulation or freedom.
Workmanship
What distinguishes the degree of risk or certainty for Pye is the extent to which the workman’s tools regulate his work. Pye argues that a pure form of workmanship of risk is hardly ever seen in any trade; for centuries people have developed tools to help regulate their work in some way (e.g. jigs) and guarantee some degree of certainty in the quality of their work. Regulation of work does not necessarily lead to certainty as some tools such as a lathe can be used in combination with a free hand, producing unique objects that are nevertheless regulated in some respects such as their size but not their form.
A simple way of asking whether it is workmanship of risk or certainty is to ask, “is the result predetermined and unalterable once production begins?”
In the drawing above, I have speculated that software craftsmanship as McBreen describes it, would be called workmanship of risk by Pye, with regulation introduced by tools such as Integrated Development Environments (IDE), Continuous Integration (CI) suites and the general operating system environment the developer is working with. Although regulated, like almost all workmanship of risk, the software craftsman often produces something bespoke to the users’ requirements, iteratively working towards the desired result through the writing and refactoring of code. Agile software development recognises that the result of most software development cannot be predetermined and that projects run best when they remain responsive to the users’ feedback. Software Engineering, on the other hand, aims to eliminate as much of the risk as possible and pre-determine the outcome of the design and programming effort, which both McBreen and Pyritz both identify as a form of Taylorism.
The Institute of Electrical and Electronics Engineers defines software engineering as “the application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software”. Pyritz questions whether the Taylorist model of scientific management is even viable in software development, quoting Humphrey, who asked ‘Why don’t they practice what they preach?’
The general practices of industrial software engineers are poor by almost any measure”. Why? “The educational system does not provide graduates with the practical skills they will later need. . . . Few software organizations are willing or able to provide the remedial training their new engineers need. Today’s software organizations have few if any role models who consistently demonstrate effective work habits and disciplines.
In learning to become software craftsmen we need role models, too. Both McBreen and Sennett emphasise the importance of apprenticeship and slowly learning by doing with others. This is what JISC’s DevCSI offers to the sector, running regular hack days, DevXS and the annual Dev8D conference. This year over 250 developers attended Dev8D to learn from each other.
Learning from each other at Dev8D
While I was at Dev8D, I issued an informal survey asking developers a number of questions about their working environment, how they learn their craft, the tools they use and an assessment of their skills. I shall provide a summary of the responses in another post [UPDATE: here it is], but I am encouraged to do further research in determining how developers (working in tertiary education) learn their craft and how opportunities for learning might be improved.
Another related project I started while at Dev8D was Hacking the University, a simple website intended to collect short interviews with developers working in universities. It is inspired by The Setup and I hope that over time, it will provide a record of the people working in this community and add to the recognition of the work they do, how they learn and how their working environment impacts upon their work and learning.
If you are a developer working in a university, please consider contributing to Hacking the University and telling others about your approach to your craft.
