Digital Education

Joss Winn / March 3, 2014 / Education, Learning Landscapes, Projects, Student as Producer

Late last year, I worked with colleagues to propose a way forward for implementing the university’s ‘Digital Education Plan‘. Here’s the document that went through university committees and is currently being put into action. A significant investment is being made at Lincoln to support and develop teaching and learning, teacher education and student engagement, under which the recommendations below will be resourced. I continue to have input into all four areas of work recommended. I am leading on the proposed Masters research degree, based on the idea of ‘the university as a hackerspace’, which I have written about previously.

Implementation of the Digital Education Plan

Introduction

This paper sets out four areas of work to enhance and support digital education at Lincoln. These activities are derived from the university’s Digital Education Plan (May 2013), a report following an HEA/Leadership Foundation consultancy (July 2013) and ongoing discussions by the Digital Education Strategy Core group. The implementation of a digital education plan at Lincoln is grounded in two institution-wide projects undertaken over the last five years: Student as Producer and Learning Landscapes. Both of these major projects, as well as other related initiatives, inform the approach and objectives for implementing the Digital Education Plan. In summary, the four areas of work are:

A cross-university digital education group
Incentives and recognition
A multidisciplinary Masters research programme
A framework for re-engineering space and time

A cross-university digital education group

Digital education at Lincoln requires on-going co-ordination and support. A cross university group focusing on innovation and support for technology for education should be established within CERD, with formal membership from across the Colleges and key service departments. This group will build on knowledge gained and lessons learned from the LNCD group.^{^[1]}

As well as some existing staff from CERD, the group should have three newly established ‘Digital Education Developer’ posts who are attached to each college. Staff from ICT, Estates and the Library should also be formally attached to the group. These core staff would engage with colleagues and students from across the university. They would encourage and support wider efforts across Colleges to undertake applied research and development into digital education. This ‘hub and spoke’ model of co-ordinating support, innovation, research and development across institutions is widespread in the sector.^{^[2]}

A core principle of the group will be that students and staff have much to learn from each other and that students as producers can be agents of change in the use of technology for education.

Incentives and Recognition

Next, we propose to focus on developing ‘digital literacy’ and ‘digital scholarship’ across the staff and student population of the university. These are broad, inclusive terms that encompasses a range of skills, experiences and critical approaches required for teaching, learning and research, effectively providing the groundwork for any successful implementation of the digital education plan. Digital education at Lincoln should engender an environment whereby students and staff are encouraged and supported in being not just consumers of technology but rather productive, critical, digitally literate social individuals. In this view, technology is inclusive and understated, advocated by the institution primarily to develop the individual’s critical, social understanding and abilities which they apply to their learning and in this way technology does not become an end in itself. In the development of critical, digital literacy, we can raise awareness of the nature and effects of inequitable digital practices and in doing so, encourage socially responsible individuals who are then able to challenge exclusive practices and ensure inclusive ways of living in society.

To help achieve this, we will develop optional, accredited modules for both staff and students:

Continuation of the existing 30 credit module, Teaching and Learning in the Digital Age (TELEDA). This has been developed for staff by Sue Watling (CERD) and was successfully piloted in 2012-13. Its primary focus is how online communication and collaborative group work can enable critical thinking and reflection.
An accredited module for staff and students will be developed which is formally aligned with the new ‘Mozilla Web Literacy Standard’^{^[3]} and other appropriate models.^{^[4]} This will be made available to any student from September 2014 as part of the Lincoln Award and available to staff as part of CPD.
A 30 credit module in digital scholarship will be developed for staff and post-graduate students. Taken in addition to the TELEDA module, this would lead to a Post-Graduate Certificate for staff. It will also be available as an optional module for the MA in Education (in development).

In addition to accredited taught modules, the proposed digital education group will offer support and incentives to staff and students who wish to engage with digital education at the university, through annual Internships, research grants/bursaries and internal and external applications for funding. Through our experience of the Fund for Educational Development (FED) and Undergraduate Research Opportunity Scheme (UROS) funds, we know this is an effective method of engaging staff and students in research and development that produces tangible research outcomes and will help further the critical development of digital education at Lincoln.

A multi-disciplinary Masters research programme

In addition to the digital education group, we propose a new academic programme which will act as a focal point for teaching, research and development of new technologies that maintain Lincoln at the cutting edge of digital education and technology culture. Influenced by the rapidly emerging ‘hackerspaces’^{^[5]}, the programme will seek to learn from what we see happening in hacker culture: new reputational models, ‘fablabs’ and ‘hacklabs’, commons-based peer-production, and new methods of innovation funding. This research-based, postgraduate programme should be cross-disciplinary and always experimental in its form and content; a sandpit for innovation, engaging academics and students in the sciences, arts, media and humanities to think deeply about the way technology is used for research, teaching and learning and the social good.

This cross-disciplinary research programme will allow students with different disciplinary backgrounds and interests to spend their degree in a physical university space, working together on ideas of their own under the guidance of experienced staff. To bootstrap the Programme, the first intake of 10 students should be recruited with a wide range of artistic, technical and scientific experience and they would pay no tuition fees. In following years, tuition fees would be payable but waivable depending on the accomplishments and impact of the student’s work. Impact could be measured in a variety of ways: technical, commercial, societal and educational. Over time, successful alumni would help attract more students to the programme, developing a culture of hackers and successful startups attached to the research programme. To further attract and incentivise students, ‘angel funding’ should be available on a competitive basis for student projects which show further potential.^{^[6]}

The programme combines cross-disciplinary research and development, teaching, learning and enterprise, but it recognises that those processes are changing and that hackers and entrepreneurs are 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, university culture is still a place where the hacker ethic (respect for good ideas, meritocracy, autonomy, curiosity, fixing things, anti-technological determinism, peer review, perpetual learning, etc.) remains relevant and respected.

A framework for re-engineering space and time

Finally, we propose to develop a framework for staff and students to analyse and re-engineer the use of space and time at the University of Lincoln. To create this, we will undertake a comprehensive investigation into the form and content of a large, lecture-based module and its objectives and constraints. In doing so, we will provide staff and students with a toolkit for evaluating and re-designing the space-time of their own programmes through better use of teaching and learning time and the blended use of the physical and virtual space of the university. This guided evaluation would also be built into one or more of the above mentioned teacher education modules so that staff reflect on the way technology may change the way their modules are designed and delivered.

The virtual space – cyberspace – allows us to think critically and imaginatively about the idea and form of university we desire. This approach was central to the Learning Landscapes project, highlighting how critical pedagogy can be used as a design principle, a resource in the design and construction of a counter-space, providing critical tools with which we ‘reverse imagineer’ the university. The ‘edgelessness’^{^[7]} of cyberspace allows for ‘Utopian thinking’ through which the constraints of traditional hierarchies of research, teaching and learning become “manifest as entirely different spatial forms and temporal rhythms.”^{^[8]} Arguably, we’re already seeing this Utopian thinking in the forms of the Open Data, Open Access and Open Education movements.

Based on the recommendations of the original Learning Landscape project, we propose the following overarching objectives for digital education at Lincoln:

Drive research into the effective design and development of digital education
Provide support to teachers and students for Utopian thinking and experimentation on the web
Include students as clients and collaborators in the design of university digital services
Be academically credible. Digital education should not simply be a technical exercise removed from the academic rigour of the university
Understand the relationship between space and time: it’s not just ‘cyberspace‘, but space-time
Articulate the institution’s vision and mission as a connected, networked whole
Create incentives. Recognise and reward innovation across all staff and students
Create formal and informal management structures that support strategic experimentation and imagineering (e.g. ‘think tanks’, ‘sand pits’, ‘skunk works’)
Avoid stereotyping. Bring people together from across subject areas and professions so as to avoid an ‘us and them’ attitude
Intellectualise the issues. Generate debate on the nature of academic values and the role and purpose of higher education: the idea of digital education is synonymous with the idea of the university.

In essence, digital education points to a learning landscape that is designed to engender capable, confident and critical individuals engaged in research, teaching and learning, so that they are active producers of their own social world.

Recommendations

We ask that the Education Committee recommends the following:

Urgent recruitment of three Digital Education Developer posts
The development of two further modules of study relating to digital literacy and digital scholarship
The development of a cross-disciplinary Masters level research programme
Research and development into the re-engineering of lecture space-time
On-going investment to support these initiatives.

^{^[1]} http://lncd.lincoln.ac.uk and https://joss.blogs.lincoln.ac.uk/2011/05/16/technology-for-education-a-new-group/

^{^[2]} Walker, Voce and Ahmed (2012) Survey of Technology Enhanced Learning for higher education in the UK, UCISA. p.91

^{^[3]} https://wiki.mozilla.org/Learning/WebLiteracyStandard

^{^[4]} e.g. SCONUL Seven Pillars of Information Literacy (2012)

^{^[5]} https://en.wikipedia.org/wiki/Hackerspace

^{^[6]} The Y Combinator (http://ycombinator.com) model of angel funding is a good example of this already happening, where students and recent graduates receive a small amount of funding and lots of support, in return for just a very small share of their enterprise. JISC are also experimenting with this style of ‘angel’ funding in their Summer of Student Innovation programme. http://elevator.jisc.ac.uk

^{^[7]} http://www.demos.co.uk/publications/the-edgeless-university

^{^[8]} Harvey, David (2000) Space of Hope, University of California Press, 237-8

The university as a hackerspace

Joss Winn / March 16, 2012February 8, 2013 / Education, Hacking, PhD, Student as Producer

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.

Institutional approaches to openness

Joss Winn / March 8, 2012February 8, 2013 / Hacking, Open Access, Open Education, Open Source, PhD, Projects, Student as Producer

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.

Read the case study: Hacking the university

Learning a craft

Joss Winn / February 25, 2012February 8, 2013 / Education, Hacking, Hardware, Open Source, PhD, Projects, Software, Student as Producer

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).

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.

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.

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.

DevXS: Improve, challenge, positively disrupt

Joss Winn / December 7, 2011February 8, 2013 / Conferences, Fun, Hacks, Mashups, Open Source, PhD, Student as Producer

No place like 127.0.0.1 — Even student hackers need to rest

I’ve spent the last five months helping to organise and host DevXS, a national student developer conference. The conference on 11-13th November was fully booked and a great success. Over 170 students attended from across the UK, representing 37 universities, as well as a further 20 tutors and developer mentors working in the Higher Education sector.

You can read more about DevXS on the conference blog which was updated throughout the weekend by a superb team of media students. There are lots of videos and presentation slides on the blog as well as pictures and information about the prize winners and their applications.

It was a really exhausting and satisfying experience to be involved in and not only was it the first conference of its kind in the UK but it looks like it will become an annual event hosted by a different university each year and organised by the JISC-funded DevCSI project.

You can read a report about the conference on the DevCSI website. The Guardian also published an article (originally titled ‘Hacking the Academy’) in the run up to the conference, which I wrote with Mike Neary.

http://youtu.be/DO_tlvy0qs8

The Aberdeen team raised sponsorship to attend

The venue — The Engine Shed, where we lived for two days.

data.lincoln.ac.uk

Joss Winn / December 7, 2011 / Data, Hacks, Mashups, Projects, Software, Student as Producer, Web

Recently, I posted on the LNCD blog about our work on data.lincoln.ac.uk. You might find it interesting.

One of the by-products outcomes of our recent ‘proper’ projects is data.lincoln.ac.uk. This is simply a site that documents the data we are warehousing in our MongoDB datastore (called ‘Nucleus’), and the programatic methods by which we (and the public) can access that data. Most of the data is licensed for public use, but where appropriate (e.g. personal data), a secure access token must be requested. Currently, outside of our own projects, the only people needing/wanting secure access tokens are some third year computer science students who are using data.lincoln.ac.uk as the basis for their dissertation projects and require access to their own personal event data.

Our approach to publishing open data at the University of Lincoln has been to do so in a way that was immediately useful to the work we were doing…

Read more about ‘an open platform for development‘.

Hacking the Academy

Joss Winn / October 23, 2011February 8, 2013 / Hacks, PhD, Publications, Student as Producer

An article I wrote with Mike Neary for the Guardian was published last week. It relates to my recent note about Hacking as an Academic Practice and is part of a longer journal article that I’m hoping to have finished by the end of the year about the importance of university culture to the history of hacking.

The publication of the article was nicely timed to coincide with DevXS, the national student developer conference we’re hosting next month. Last week there was a surge of registrations and we’re now fully booked. It should be a great event.

Hackers are vital to the university culture of openness and innovation

Have you noticed anything missing from the ongoing phone hacking scandal involving the News of the World? There are no hackers involved. This is the latest example of hacking’s troubled history with the mainstream media, which confuses the “playful cleverness” of expert computer programmers with the malicious meddling of computer crackers and criminal journalists. With this confusion, the rich and fruitful history of the true hackers is diminished and a thriving intellectual culture focused on problem solving, self-directed learning and the free exchange of knowledge is undermined.

Much has been written about hackers and hacking, but rarely is it contextualised as part of the scholarly tradition. Yet careful reading of the history of hacking reveals that it is very much a part of the work and values of universities and that the hacker ethic is shared, in part at least, by most academics working today.

Joss Winn / October 23, 2011February 8, 2013 / Open Education, PhD, Presentations, Projects, Student as Producer

Mike Neary and I were in New York City from the 11-16th October, speaking about Student as Producer. We held seminars at Adelphi University, Baruch College CUNY and were part of a panel at the Mobility Shifts Conference at The New School. Here is a recording of the CUNY event, where we had the pleasure of sharing the seminar with Jim Groom, someone who’s been an inspiration for my work on the university WordPress platform.

Category: Student as Producer