It’s a serious issue when there's a shortage of skills in a particular labour market. Where DO we find tomorrow’s specialists? And it was the topic of a joint EngineeringUK/Gatwick Diamond Initiative forum in Horsham, Sussex in December 2017 attended by schools, businesses, enterprise partnerships and the professional institutions. The forum considered the problem of finding tomorrow's digital engineers - but the ideas that were discussed and the ideas within this blog are common to many other domains. It’s an issue in which Government expresses interest and one that any firm seeking people to write computer code knows all too well. But collective expression of interest and concern is not enough. It needs an answer.

Universities no short-term fix

This blog answers – though inevitably, the answer can only be that interested parties must re-structure the profession and re-think their hiring practices. The system of competency development through universities – processing young people with technology interest - is unlikely to offer a fix any time soon.

So, first, what is a digital engineer?

Professor Stuart Harmer of the University of Chichester, in an introduction at the Horsham forum, made a good start at explaining. The central concept was that a digital engineer works with software.

To understand Stuart’s description, it’s essential to understand something of the wold of computers. In essence, a processor at the heart of a computer reads instructions from a software program. The processor processes instructions, applying algorithms to process data accessed from inputs to present that processed data at outputs. The processor reads machine code – a low level computer language.

The world of programming

A human writes the program. Writing lines of machine code is inefficient. It’s better to write in a high-level language where one line of that language generates many lines of machine code. A compiler translates the high-level language to machine code once the human coder is happy with the quality of the program.

The program contains logical instructions. Before the age of the computer, this logic would be constructed with discrete electronics – resistors, capacitors and transistors. And the first humans writing computer code for small scale systems were often electronics engineers.

Defining an engineer

An engineer is someone who creates a system using engineering rigor and an engineering lifecycle. Generally, this just means that there is some need that’s expressed and the engineer works to meet that need over a number of defined stages or lifecycle.

As computers became pervasive in systems, a new breed of worker was born – the software engineer. But he or she was a rare breed. In the late 1980s there were few universities with software courses and few electronics engineers prepared to convert. English graduates, and indeed those of other disciplines too, were put though bespoke training like that pioneered by Edward Yourdon. Yourdon was a pioneer of structured programming. English graduates were considered as having a good foundation since they had a good grounding in language origin, structure and syntax.

Today, those ‘digital’ or software engineers are generally trained to write code right from primary school through university to employment.

More to software than code

But software engineering is not just all about coding. The Horsham forum was united in this. And this is the clue to where the future ‘digital’ or software engineers are to come from.

Creation of any system needs five elements in the lifecycle – and it’s the same for any form of lifecycle from ‘waterfall’ to ‘Agile’ and all flavours between. We discuss these in a separate blog. Someone must interact with the system user and the various stakeholders. Another must translate this interaction or analysis into a specification defining the algorithms, processes and interfaces. And then someone must code. And it doesn’t stop there. Someone must assure the user that the system is as they need. And of course, someone must bring the system into use with the user. The essential human competencies and behaviours in those five are different and manifold.

So, software engineers of the future are not the introverted male nerds who like coding. The profession must attract those with diverse competencies and traits.

Problem: demand exceeds supply

But the UK’s academic institutions are not turning out enough software engineers. In big broad terms about 11,000 software practitioners graduate each year from the institutions. EngineeringUK put the shortfall at about 6,000 – so about 17,000 new graduates are currently needed each year.

Demand significantly exceeds supply.

The obvious solution for the future must be to train more young people in software engineering. But this is simpler said than done and is certainly no short-term fix. A quick look at the statistics show that 50% of young people take STEM subjects at GCSE but less than 10% graduate in engineering and technology. There’s quite an attrition from initial interest through to graduation that will take time and energy to rectify.

Solution in the detail

For hiring managers to find a solution, we need more definition. If software engineering comprises five diverse activities, only one of which involves actually writing code, then part of the solution to the supply problem must be to identify and acknowledge the other four specialisations. And if these require diverse traits, we need to characterise each so that the search can begin.

Let’s start with the business end of software engineering – business analysis and product ownership (on behalf of the user). This requires a good general education, high social skills and good knowledge of the user’s business activities. Business graduates with further training could do this role.

Then there’s system specification and algorithm development. Few studying software engineering at university will have covered the depth needed in this and arguably this is best left to mathematicians and those in specialisms like operational research.

On the far side of the lifecycle comes test and quality assurance. This is often where software engineers start because it is a bounded, highly structured environment where mistakes are controlled. Here perhaps those with foundation degrees could contribute.

And finally, when the software reaches the user, there’s a role for trainers and implementers. Here perhaps any structure-centred graduate could learn what’s needed to have the user get the most out of the solution. Perhaps here, geographers and other humanities and social scientists can play.

So, by surrounding the sandwich filling of coding with other disciplines, the available pool is made considerably larger.

Necessary change of thinking

But for this thinking to be successful, hiring companies must kick the idea that the only person who can contribute to a software project is someone who can write code – the stereotypical introverted male nerd who grew up coding. Perhaps a software engineer need never actually write code? Perhaps he or she can live in pseudo-code, in diagramming, modelling and plain English? Perhaps a coder writes code?

Managers need to understand that coding can also be learned. And the future of programing languages that are simpler, faster, more efficient and that enable code with fewer bugs supports this. Toolkits and reuse of code in libraries avoid reinventing the wheel. And efficiency is enhanced in the general trend towards ever higher and more specific languages like MATLAB and R.

This approach is akin to recruitment in many other fields. Hiring managers in other fields seek those who can reason, not those who can already do a narrowly specified job like coding. So, we find that tax accountants are mathematicians and even economists. Statisticians are people who have studied and achieved higher degrees (in any subject) that demanded the processing of data.

Hire for profile: coding can be learned

The key thing then is to hire those with the right profile to enter the firm, contribute and learn. Profiling of personal characteristics must take precedence over high-level statements like ‘must be proficient in coding in MS.NET’.

Software engineers with differing competencies and traits can be employed across the lifecycle – and even in coding, languages can be learned.

Now, some may yell that this is already happening. To some extent that’s true. Big software users (with hundreds of software engineers on a project) such as banks and major systems integrators are indeed splitting the role. Subject matter experts behave as analysts and testing of multi-million lines-of-code programs is a specialist science. And coders are coming from a variety of disciplines, re-training through post-graduate conversion courses.

But the argument above is that these concepts should be adopted by all firms as a means of overcoming insufficient numbers of digital or software engineers in the labour market.

The final word on hiring specialists

Whenever there's a sortfall, greater flexibility and openness to new approaches on the part of hiring managers are essential to avoid long-term vacancies and their associated business problems. The mantra of ‘transferable skills’ must be embraced and hiring managers must be prepared to invest to develop talent.