Three reasons to learn to code

There’s no point in learning to code: In a few years’ time, we won’t need programmers any more.

I’ve heard people say that a lot in the last couple of years. But that’s nothing new: I’ve heard people say this every year throughout a long career in technology.

On my very first day in my very first paid programming job, I was told that we wouldn’t need programmers any more, because fourth generation languages (4GLs) would enable us to express user requirements in a structured way. In that case, ‘expressing user requirements in a structured way’ turned out to mean using clumsy abstractions that needed to be supplemented with code. Thirty years later, that particular 4GL is forgotten, but we still produce billions of lines of code.

I don’t believe that the AI tools that, once again, are leading to predictions of the death of programming, will fade away in quite the same way that the 4GLs of the 80s and 90s have faded away: I think that they will become a part of our coding practices. But I think that the world will need more people who can code every day for the rest of my life.

I also think that everybody should learn to code, even if they never earn a living from it, and never produce anything worth releasing into production. For many people, this is not a welcome suggestion: they find the prospect of coding daunting, challenging or just boring. For such people, the idea that there is no point in learning to code, or that, if there is a point, it is best left to the experts, is comforting: why bother to learn a challenging skill if it is soon to be obsolete, or if other people can do it better?

I’d like to offer three reasons for everybody to learn to code, all driven by the idea that learning to code is an essential part of understanding the modern world.

It changes your view of what a computer is

Computers affect the lives of everybody in the world today. Even people who do not have access to mobile phones or the Internet are subject to decisions made by governments and organisations who use computers to help make those decisions.

Yet, for most people, computers are literal black boxes: they see the user interface, but have no mental model of how the user interface controls what is going on inside the box. That’s not their fault: we have designed things that way, to hide the inner workings of systems so that they are as easy to use as possible.

The first time that you enter a line of code into a computer, and see the computer follow the instructions, this all changes. The computer is no longer an impenetrable mystery with unfathomable behaviour: it is something that we can instruct and control. It is a tool that we can shape, rather than something that shapes our behaviour.

It demonstrates the fragility of software

If our first line of code teaches us that computers are something we can control, our second or third line of code will teach us humility - because we’ll get something wrong and cause an error or a crash.

We also quickly learn not to feel bad about this: errors are a ubiquitous part of coding. Code is a collection of logic assembled by humans, and humans make mistakes all the time. I’ve been coding for over forty years, and it is still common for me to make three errors in three lines of code.

Once we learn this lesson, we don’t just look at computers differently, we look at software differently. Those bright icons and colourful user interfaces invite confidence: surely we can trust systems which are so compelling and easy to use. But a few hours of programming leads us to realise that behind the scenes is an assembly of logic built by humans subject to the same mistakes and weaknesses as the rest of us. It teaches us to appreciate software as an invaluable tool - but not an infallible one.

It helps you understand the software business

It’s been suggested that learning to code is like learning to maintain a car: useful in the days when cars were unreliable and manual repair was possible; less relevant in a time when cars work most of the time, and engines are sealed units which need special diagnostic tools.

I think that this suggestion would be correct if the software business was like the automotive business, where there are many more customers than producers: most of us are not in the business of making cars. However, those of us who work for modern organisations are all in the software business.

Sometimes we are in the software business because we buy and assemble off the shelf packages or services. Sometimes we are in the software business because we build specialist bespoke solutions that meet our special needs. But we are in the business of deploying and maintaining the software that runs our organisations.

The software business has its own rhythms and practices, and those rhythms and practices are determined by the most fundamental activity: humans assembling pieces of logic in the form of code. However we wrap this activity in project management, product management, user research, design, architecture and other activities, it all comes down to this: one line of code at a time, one keyboard press at the time.

You will understand your business better if you understand the software business, and you will understand the software business better if you write some lines of code.

There are many other reasons to learn to code. I think it is fun and rewarding, and I find it relaxing and absorbing (even if it can also be infuriating and frustrating). Not everyone will feel that way, but, even if you don’t, learning to code will help you to understand the computers that touch your life, to appreciate that software is a human construct, and to understand the business that you are in.

(Views in this article are my own.)