It is a continuously evolving learning environment created by the learners themselves. The learning model adopted by hackers has many advantages. In the hacker world, the teachers or assemblers of information sources are often those who have just learned something.
… this hacker model resembles Plato’s Academy, where students were not regarded as targets for knowledge transmission but were referred to as companions in learning (synetheis). In the Academy’s view, the central task of teaching was to strengthen the learners’ ability to pose problems, develop lines of thought, and present criticism. As a result, the teacher was metaphorically referred to as a midwife, a matchmaker, and a master of ceremonies at banquets. It was not the teacher’s task to inculcate the students with pre-established knowledge but to help them give birth to things from their own starting points.
It is ironic that
the current academy tends to model its learning structure on the monastic sender-receiver model. The irony is usually only amplified when the academy starts to build a ‘virtual university’: the result is a computerised monastery school.
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.
How much does a student hacker need to develop a good idea to the point that it attracts further investment?
I’ve been thinking about this recently for a couple of reasons. I was reading the early Y Combinator site, via the Wayback Machine, about how they reckoned on $6,000 per person for their first Summer Founders Program. Each new startup could expect to receive less than $20K (the average is $17,000 / £10,000), with two or three friends being the ideal number of founders per company. The Summer Founders Program was aimed at undergraduate or graduating students.
I’ve also been looking at JISC’s Elevator funding programme, where people working in UK universities and colleges (with a *.ac.uk email address), are able to pitch an idea to receive up to £10,000 funding from JISC. That’s the same amount of money Y Combinator seeds their successful applicants with. I think the JISC Elevator is a great idea, but looking at the proposals that have been submitted so far, I’m surprised and disappointed that there aren’t any proposals where the money goes directly to students to develop ideas of their own. Maybe students haven’t been told? I’ll admit I’ve not publicised it at Lincoln, having been busy bidding forother JISC funds (where graduating 3rd year students are the main contributors to the projects) and awarding funds to projects of our own (where students receive most of the money). Still, I feel bad about not supporting JISC Elevator more. I have voted for one proposal.
I asked Alex, an undergrad and co-worker, how much a student who is hacking on an idea all day, every day, needs to live on in Lincoln, and he reckons about £600/month. That sounds harsh to me, so let’s assume they need £800/month and that there are three of them, because after all, if you can’t persuade a couple of friends that an idea is worth working on, then it probably isn’t a very good idea (or so says Y Combinator). On a related note, Google’s Summer of Code provides students with a $5000/£3000 stipend for the summer.
When I first heard about the JISC Elevator, my immediate thought was that the £10K maximum per project isn’t very much to attract FEC costed projects involving staff, but is perfect for offering to students as bursaries. A bursary, as I understand it, is supposed to cover the costs of living, rather than being seen as a wage, so they’re similar in purpose to the GSoC and Y Combinator funds. On our DIVERSE project, almost all of the money received went to paying the fees and bursaries of two MRes students. We are also prepared to contribute a larger percentage of the overall cost. Our recently funded beBOP project is an example of this, with a recent graduate being employed on grade 4, and the funding from JISC covering only 65% of the overall cost, compared to the maximum 80%.
I’ll admit, I don’t really understand how FEC works and where a lot of the money actually goes, but for the kinds of projects that the JISC Elevator is trying to attract, as well as JISC’s Rapid Innovation calls, I do wonder whether the GSoc or Y Combinator model of funding is a more cost-effective one. Pay students to hack over the summer, with a member of staff overseeing their work and call that the institutional contribution. £10K will pay for three students to hack over the summer, travel to a conference to talk about their work and pay for some servers on Rackspace for a few months. The tools to develop software in the early stages are cheap (a basic Linux stack on Rackspace is £7/month and there are enough open source tools available to explore ideas and develop prototypes, even if the ideal tool happens to be a proprietary one.
At Lincoln, we recognise that, given the opportunity and mentorship, undergraduate students have much to contribute. They’re not simply consumers of education. Like other universities, we’ve been running funding programmes each year that fund students to work on a research project with a member of staff over the summer. At Lincoln, it’s called UROS, the Undergraduate Research Opportunity Scheme. The Student as Producer UROS call was announced a few days ago. The LNCD group, which I co-ordinate awarded five projects £1000 each last week, which focus on the use of technology for education (more info on those projects soon). For the UROS and LNCD funded projects, almost all of the £1000 goes on undergraduate student bursaries. In my experience, undergraduate hackers can produce good work. Work that’s worth funding. Y Combinator thought so, too, and they’re now the most admired angel fund among young hackers. Each Y Combinator funded start-up is now guaranteed $150,000 as follow on funding by another investor. If you go Wayback to the first Summer Founders Program FAQ, you’ll see this:
Why are you doing this?
Partly because we feel guilty that we all got rich almost seven years ago, and still haven’t yet given seed money to new startups; partly because we think it is an interesting hack; and partly because we think it may actually make money.
We suspect that students, and particularly undergrads, are undervalued. Twenty years ago the idea of grad students starting companies would have seemed odd. Not after Yahoo and Google. And if grad students can do it, why not undergrads too?
I agree. Undergraduates can do it and I think institutions, together with JISC, should be thinking about our own Hatchery for Hackers.
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.
As part of open education week, JISC commissioned a series of case studies on ‘institutional approaches to openness’. For Lincoln, I wrote that our approach to openness can be best understood in relation to our Student as Producer initiative.
Since 2010 a project called Student as Producer has been adopted as the de facto teaching and learning strategy for the University of Lincoln. This is an attempt to engage undergraduate students in research, and to make research part of the teaching process. It is also a vehicle for demonstrating the value of openness – an idea bolstered by the establishment of numerous other open access initiatives at the university.
In my previous post, I mentioned a small on-going project I have started to collect short interviews with developers working in universities. It is inspired by The Setup and relates to my interest in hacking in the academy. I hope that over time, it will provide a record of the people working in the developer community and add to the recognition of the work we do, how developers learn and how their working environment impacts upon their work and learning. Here’s the initial announcement I made at Dev8D. Please spread the word.
Calling all Developers working in Higher Education!
I’m setting up a site based on http://usesthis.com but focusing on Developers working in HE. It’s part of a research project I’m embarking on to understand how software developers (in universities) learn their craft.
It would be great if you could send me something. It will be published here http://hackingtheuniversity.net/ It shouldn’t take more than about 15 mins to write and about 5 mins to read (although longer is OK). Over time, I hope to compile a rich profile of developers who happen to work in universities.
How you answer is up to you; browse the site and read other people’s contributions. Alternatively, I’d be happy to accept something different, like this: http://why.usesthis.com/ You don’t need to hyperlink to your software and hardware. I will do that, in many cases automagically!
Here are my interview questions. If you don’t feel like writing, I’d happily accept an audio file to transcribe.
=======
Who are you, and what do you do?
foo
Who taught you how to do what you do?
bar
What tools do you use?
foo
Describe your dream working environment.
bar
========
I need a nice image of you, too, at least 500×335 pixels.
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.
