In a departure from my usual obsession with politics and current events, this blog is about my efforts over the years to “learn to code”, and my personal opinion on whether or not everybody else should bother. The short answer is no, but to understand why I think that, I’m afraid you’ll have to read on.
Has there ever before been a term that is quite so ubiquitous while also being utterly meaningless? We are exhorted to “learn to code” as though it is a finite skillset, akin to riding a bike, or driving a car – a skill we can always manage without if we absolutely must, but which is becoming so universally engrained in our everyday lives that we risk being left behind and cast out into the technological dark ages if we fail to learn it.
It all seems so much more complicated than it was when I was at school, learning to write simple programmes in BASIC on the Apple II. Okay, so those programmes couldn’t do much beyond printing words and characters on the screen, and even fairly simple programmes required what seemed a fairly ridiculous number of lines of code, but at least there was only one language!
I wasn’t sufficiently enamoured of BASIC programming to stick with it beyond what I was taught in school, and my next exposure to “learning to code” was at university, studying for my Bachelor of Commerce in Information Systems, where we were taught the principles of object-oriented programming using COBOL. I use the term “taught” loosely – I hated COBOL, couldn’t get my head round object-oriented programming and can remember absolutely nothing of that particular part of the course apart from the fact that it bored me to tears. A friend, studying engineering, openly laughed at the idea that we were learning “a dead language” – he was learning C as part of his course, which I later realised would have been a far more useful language to try to learn. But by this stage I’d already concluded that I clearly didn’t have the right aptitude to be a software developer, and that I’d be better suited to a slightly less technical role.
But computers have always fascinated me, and while I may not have been able to make any headway with programming, I found the early Microsoft Office applications to be a revelation. Excel and Access, in particular, struck me as wondrous – here were two applications that with a few simple keystrokes or just a little clicking and dragging, could magically churn through masses of data and provide results that would have taken hours to collate manually. I earned massive kudos in an early job in banking when I was tasked with compiling the monthly sales desk reports, a tedious job that involved pulling in data from numerous Excel spreadsheets, sorting and aggregating it to produce various summary reports and charts. It usually would take a good half a day to complete and would always fall to the newest member of the team who would have to do it every month until either someone new joined (we had fairly high turnover within the team) or until sufficient number of months had passed for our manager to agree it was time to hand it over to someone else.
After being shown the process, I immediately recognised that much of the manual effort could be automated within Access, and set about creating a database that would pull in the various spreadsheets and, via a few simple queries, spit out the resulting reports and charts. After a bit of trial-and-error, I had the process down to about 30 minutes of effort – and was a hero among the team.
But my ingenuity came at a cost. I may have been a bit of a whizz with MS Access, but the rest of the team were not. So when I went on holiday, and the reporting fell to another member of the team, he found himself completely confused by the instructions I had left, and reverted to the old manual process. The problem, of course, was that by this stage everyone had come to expect the process to take half an hour, so nobody was happy that it was once again taking half a day – least of all the poor bloke having to do it. It was decided that rather than wasting further time having me train the rest of the team in MS Access, I would continue to own the process until such time as it could be properly automated by the IT team – from memory this was a further 6-9 months. And there was a fair bit of unhappiness from middle management that I had been allowed to go beyond the remit of my job by re-engineering a process in a way that had created such a “key-person dependency”.
There is a point to this story, beyond happy reminiscence. Over the last couple of years, I have once again dipped my toe into the world of “learning to code”. The website Udemy.com has literally hundreds of cheap online courses, of varying quality, in absolutely every coding language you could imagine – if you buy them during one of their many sales, you can pick up a course for as little as £12, and it’s yours for a lifetime. My eye was drawn to a course called “Automate the boring stuff with Python” – a course that is supposedly aimed at non-techy people such as office administrators, who wish to learn how to automate mundane office jobs that would normally take a few hours to do, and that can be done in minutes via Python. This sounded like the perfect course for me, so I dove in.
And to be fair, it is a great course. It teaches the basics of Python programming in clear, simple terms, and then goes on to teach the learner how to use regular expressions to search for particular text patterns within documents or on web pages, and how to perform basic operations on Word, Excel and PDF documents.
But here’s the rub. Before you can do anything in this course, you have to install Python on your machine. You also, later on in the course, need to be able to create and run batch files. Fine if you’re learning on your own machine at home, as I am, but not so great if you’re an office administrator wanting to write a Python script to automate a job you’ve been given at work. Any company with even a basic level of IT security awareness, will have controls in place that prevent employees from installing any kind of software on their machine. Sure, you could ask the IT team to install it for you but they will almost certainly ask why you want it installed – and unless your job title is “software developer” or something similarly techy, your request is almost certain to be denied – not only because you won’t be trusted not to introduce bugs into the system, but also because your managers will almost certainly wish to avoid a “key person dependency” situation whereby anybody else needing to be able to do your job will require the same level of technical proficiency, not previously a requirement of the role. You’ll be left in the maddening position of knowing that you could automate this process if only you were allowed to – and there is nothing more annoying than knowing a quicker way to perform a task but being prevented from doing so.
The other issue I am finding is that learning to code in any language, is just like learning to speak another language – you can learn the basics fairly easily, but you will need to use it again and again and again in order for it to become even vaguely second-nature. And that’s just the basic stuff. I’ve been at this on and off for a few months now and while I may have completed this one course, I keep having to go back over sections to remind myself how different concepts work, and the entire course has barely scratched the surface of what can be done in Python.
Personally, what I’ve found most useful about the Udemy courses has been the fact that in among the various coding concepts, have been high level explanations that have demystified so much about computer programming that I had previously struggled with. Concepts such as what is a batch file, what is a library, what’s the difference between front-end and back-end programming, what do people mean by the term “technology stack”, and what do terms like PAAS, SAAS and IAAS mean? And what are all those programming languages used for, and why are there so many?
What I’d love to see, is a course that explains computing concepts without necessarily going into the details of actually learning to write code. I completed a “home maintenance skills” course a couple of years ago at my local college and it was the single most beneficial course I’ve ever done. Over the course of six evening sessions, we learnt the basics of plumbing, lock fitting, joinery, painting, and bricklaying, and were introduced to all the key tools and materials used in each. That course taught me two things – firstly, that unless you absolutely love a particular trade and want to devote lots of time and effort to mastering it, it is far easier to hire a qualified tradesperson to do the job for you. But secondly, and most importantly, how to talk confidently to that tradesperson and know when they are trying to pull the wool over your eyes about how complicated or expensive a particular job is.
In the same way that I don’t believe everybody needs to learn plumbing, or joinery, or bricklaying, I don’t believe everybody needs to learn to code. I think those who have a particular aptitude for, and love of, coding, absolutely should learn to code – and those, like myself, who have a bit of a geeky side and like to explore, would also benefit from learning the basics. But the majority of people, who have no intention of ever becoming software developers, and whose interests lie in other areas, will be best served by learning just enough about computers to be able to speak confidently to the experts and to know when those experts are trying to pull the wool over their eyes about just how complicated a job actually is.
“Learn how to talk about coding” – now that’s a course I really can see a demand for. Shame it doesn’t have quite such a catchy ring to it.