by Ashok Menon

Access is a hurdle that the computing industry has been struggling to overcome for many years. With no mandatory teaching in schools and tangentially related subjects, like ICT, providing a skewed and often unfavourable impression of the subject, many leave school with at best a mild disinterest and at worst an active hostility towards the subject. On the bright side, though, these past few years have heralded a renaissance in the education of the wider public as to what computers really are, what is achievable with them, and how to go about achieving it. Moreover, particular emphasis is rightly being placed on addressing the diversity issues that are still present in the software engineering industry.

“In our modern society, everybody should know how to code”

As computing becomes more of a going concern in the collective public consciousness, it has also received a proportional increase in media interest. This is by all accounts a great thing, but whilst the increased attention is welcome, it does tend to create a ‘grapevine’ effect: as the word ‘computing’ passes from person to person, it is reworded, rejigged and distilled, until it is no longer quite what was originally intended.

‘In our modern society, everybody should know how to code’. That is the message that comes to us down this particular grapevine. Ostensibly it may seem that our message has survived virtually intact, but is coding really the be all and end all of computer science?

In fact, for every ‘problem’, there are a number of steps computer scientists consider before ever getting round to the act of coding, which always comes last.

Think about the problem

First we have to make sure we have a good idea of what the problem before us actually is, and what a solution might look like. This is something a lot of people forget! Without organising our thoughts in this way, we may end up solving a completely different problem than the one we intended.

Break the problem into component parts

Next we have to find a good enough solution. This often involves breaking things down into smaller and smaller pieces until the solutions to each of those pieces are attainable. Then we build up our solution to the main problem by recombining these sub-problems. The real art here lies in knowing how to break the problem down. The pieces need to be made small enough to solve, but not at the expense of making it impossible to recombine them.

Look for patterns

Ideally, our solution should also be flexible so that it can be applied to related problems. Suppose we are tasked with both sorting a list of words in alphabetical order and sorting a list of numbers in numeric order. Instead of writing two different solutions, by breaking the problem down, we see that if we have a way to compare one element of a list with another, the rest of the work is the same in both cases whether we are comparing numbers or words. Once we identify a pattern, we can think about exactly what is the same and what is different when sorting words and sorting numbers.

Be precise

A computer will not accept any ambiguity in one’s description. This forces us to think about every possible corner case that might be thrown at us. If we don’t, and the computer is presented with such a corner, it will not use its initiative and will not “know” what to do. Our solution should also be clear. Whilst a computer will follow your instructions to the letter, the next person who reads them might not – even if that next person is you.

Then we can code

Out of all the steps, coding appears in only one, and it is the last. Only with all these concerns dealt with may we translate our solution into a format that a computer can understand and act on.

Or don’t code

But what remains if this last step is omitted? Essentially, this whole process is just one of solving problems, something we do every day. So why fixate on computers?

“We do not have to obey the constraints of physical systems”

Harold Abelson, Professor at MIT, writes, ‘Computer Science is like an abstract form of engineering. The kind of engineering where you ignore the constraints that are imposed by reality…. The constraints imposed in building large software systems are the limitations of our own minds.’

If you have an itch and a computer’s the right tool to scratch it, then, by all means, learn to code. However, it is worth remembering that programming languages constantly evolve, and the one you learn today may have already changed in a year’s time.

What computers truly afford us is a platform on which we may create solutions that do not have to obey the constraints of physical systems. This is a tantalising and powerful concept. In such an environment, where it is possible to break goals down or generalise solutions according to any pattern, we may also practise problem solving at its purest. It is, in short, a new way to think. I invite you to embrace it!

***