After our first teaching workshop of our review of undergraduate programmes we had some intial thoughts about what students in 2025 might be like, and what they might learn.

I’d like to unpack the framing that Carl Jones came up with after that workshop, presenting the complimentary but perhaps also conflicting elements that might make up a future Computer Science or Software Engineering graduate, as a series of points along a set of different dimensions:

CS/SE Specific

• Fabricators v Assemblers (or White-box v Black-box)
• Low-level v High-level
• Work with computers v work with people

General/Transferable Skills

• Work alone v work with others
• Rigidly structured vs. Flexible learning
• Research-aligned v industry-aligned

With apologies to Carl for anything I get wrong, and with apologies to Computer Scientists and Software Engineers for the cliches and gross generalisations, here’s how I think this works and where it might fit in developing or redeveloping degree programmes:

Fabricators Vs Assemblers

Fabricators build the bits that the Assemblers put together to build the products.

Fabricators work at the level of components and services, they design and implement algorithms, APIs and interfaces. Their work is often about implementing the theoretical ‘new’.

Assemblers take the components and services and put them together into applications and products. They architect solutions to problems using existing code and technologies, sometimes with little (or no) coding. They are focused on the solutions, and the trade-offs that must be made to achieve them.

Low-level vs. High-level

At the low-level the focus is on efficiency, speed, memory consumption, CPU cycles, power usage. They work close to the algorithms and the data. They are often delivering marginal gains that translate to larger gains at higher levels.

At the high-level the focus is more on wider systems, with concerns for system reliability, data consistency and coherence, uptime and response.

At both high-level and low-level there is an explicit understanding of the trade-offs and impact that the design decisions made at that level have on the project/product/output.

Work with Computers vs. Work with People

At the computer end of the scale, we are familiar with a wide range of languages, tools and environments. We write code, we are on the command line and in the text editor.

At the human end of the scale, we talk to lots of different people - our colleagues, our clients, the stakeholders. We can translate and communicate between these groups.

Work alone vs. Work with others

Working alone is not about the solo coder, at home in the garage delivering a project single-handedly, but is about autonomy, independence and self-direction. It is about being able to align yourself with the goals of the project and team but to determine your own direction along that alignment.

Working with others is about collaboration and communication. It is about sharing of all kinds (ideas, time, respect) and about being an effective colleague, offering and responding to feedback, and keeping the teams goals in sight and mind.

Research aligned vs. Industry aligned

Research aligned work focuses on the cutting edge of CS and SE in both the pure theoretical and applied senses. It may not yet have practical applications in industry but will be pushing at the boundaries of the subject area.

Industry aligned links CS and SE to a more practical applied sphere, delivering necessary skills for the digital economy and powering the wider adoption of CS and SE technologies across business and society.

So what?

If we have these six dimensions (there may be more, or we may need to lose some…) what does this mean for our teaching and our degree programmes?

To me, this is a framework within which our teaching sits. It could even be considered a menu. There are clearly overlaps between some of these areas, and I don’t really think a student would get away with only sitting at one end or the other of any one of these dimensions without at least knowing about the other end. However, I can envision a student coming out of Year 1 of a degree scheme, a solid grounding in core skills under their belt, having experienced both ends of the scales, and now they are making the decisions about where to specialise and using these dimensions as a guide for some of those decisions. Perhaps they are leaning towards being a high-level fabricator type who works with people … so we steer them towards modules that cover or lead towards those areas. Perhaps they are a low-level assembler who is very research-aligned, and so again, we steer them in the direction of the modules that will enable those sorts of outcomes.

I think this is a model we’ll come back to as we continue to explore the space surrounding our degree programmes, and it will be interesting to discover the other dimensions, if there are any, and to see if this remains a useful metaphor to base some of the programme design decisions on.