Last year a dozen friends or so approached me, wanting to know my opinion about how useful would it be for them to learn computer programming. The common feeling was that the job market was demanding that type of skills, particularly for roles on data science, and learning them could open some attractive doors. However, the over-abundance of books, online courses, and videos on the topic clutters the view and makes it difficult to decide where to begin. “Which are the good courses?”, “What language to learn?”, “How long would it take?”, and more importantly, “Would it be worth it?”

To answer these questions, I find it useful to distinguish two activities that are related but are not the same: coding and programming. People tend to use both words interchangeably, but lack of awareness in the distinction between them can cause confusion and misguide expectations. My impression is that many of those new jobs, advertised on the back of the data science and machine learning revolution, are looking for people with programming skills, not just coding skills. That doesn’t mean that learning how to code for its own sake wouldn’t be useful and even quite exciting.

Coding and programming are associated with the process of making a machine do something for you. In this specific context, the “machine” is a computer, and the way of “making it do something for you” is through a computer program. It is important to clarify that point because if you stick to the strict definition, you could say that you can “program” your alarm to wake you up in the morning, but that is not what we are talking about here. The emphasis of coding is in the “code” part, which refers to a specific set of instructions that you write in a computer language. The emphasis of programming is in finding the solution to a problem using a machine.

In one way or another coding and programming have in common four intertangling stages: Designing the solution; writing computer code; debugging; and documenting your code. A very narrow view of coding would argue that it refers exclusively to the second stage, writing computer code. I think of it differently, more like a simplified version of programming. But before highlighting the differences, let me briefly describe these four stages shared by both activities.

• Designing the solution to your problem involves decomposing it in a series of smaller ones that you can solve by executing a series of mechanical steps, i.e., you find an algorithmic solution. Whenever I’m thinking of how to tackle the problem, I avoid sitting in front of the computer and prefer to take a notebook where I draw diagrams and write in plain English the different operations and calculations that the computer will need to do. For me, this is by far the best stage in the process, and in my ideal world, I would dedicate 99% of the time to think about the problem and 1% to the next three stages.
• Writing the code is merely putting together the commands in a computer language. It may require anything between a dozen lines or thousands of lines, in which you use various procedures to access the memory, retrieve and create data, or execute statements to control the computer. Newcomers may think programming is all about writing codes, which admittedly sounds a bit boring, oblivious that there are more enjoyable stages, like the previous, or more nerve-wracking, like the following.
• Debugging, i.e., looking for errors in your code, is a humbling experience that eats part of your soul and can push you to the limits of madness. It is astonishing how much time you can spend doing it, and the worst part is that you don’t know a priori how long it will take. From the time you run your program for the first time, to the moment you declare it is bug-free, it can take anything from one second to a few months.
• Finally, documenting is simply writing what the code is doing and how to use it. It ranges from some commented lines in the code to full manuals of operations. Pretty much as flossing, this not an exciting thing to do but it isn’t optional, and it has ugly consequences if you don’t do it.

A good way of framing the coding vs. programming distinction is by asking who is going to be the user: is it you, or is it someone else. When coding, the user is the same person writing the computer program; when programming the user is someone else. If you are writing code that is helping you automatize or speed up a particular process that you need to do at home or in the office, and you are not planning anyone else to use it, then we are talking about coding. On the other hand, if you write software that you expect will be used by your team or company in the long run, or by external users, then that is programming.

This way of viewing both activities brings to the surface the many considerations that you require for one but not for the other, and they become more clear when evaluating what they imply for the four stages that I described before.

• When coding, you look for a quick solution to your problem, and you might be satisfied with one that tackles the particular conditions that you have. When programming, you need to think of a more general solution that can handle all sorts of cases and scenarios. Speed, memory, compatibility, all these become quite relevant. When programming, not only you solve the problem, but you need to do it in the best possible way.
• The choice of a programming language when coding – mainly when you are a beginner – should not be a matter of too much thinking. Any of the usual suspects (Python, R, Ruby, Java, C, Matlab, Perl,…) will work fine. True, some languages are more appropriate to solve some types of problems than others, but the reality is that at this level there is not too much harm in adhering to the old Law of the Instrument (“if all you have is a hammer, everything looks like a nail”). Everything becomes more complicated when programming though, as you need to align many considerations: sustainability, the speed of development, interconnectivity with other tools, expertise, costs, etc. Most likely you find there is no perfect language and you end up relying on more than one.
• The script of debugging when coding goes like this: run your code; if it crashes look for the bug and fix it; go back to step one. If it feels like you are playing an excruciatingly painful game of whack-a-mole, then you are probably doing it right. There are a few ways of making the process slightly more manageable, but honestly, it doesn’t get too much better than that. When programming, your approach is systematic, testing in parallel all types of scenarios and understanding how your program deals with them, improving it step by step. Good practices include running a battery of tests periodically and keeping a detailed list of the errors and features not yet resolved.
• When coding, documenting means adding a few lines here and there in case you need to revisit it in the future. I don’t think you need to be too obsessed about it, perhaps a description of what the code is doing and a note on any critical steps is good enough. On the other hand, when programming, you cannot wait for the Muses to inspire you to write the documentation and, just as the previous stages, it should be done methodically and with other programmers and users in mind. As a rule of thumb, no matter how much you have documented your code, it is still incomplete.

Learning to code can be pretty enjoyable, and if you work in an office environment, it is always going to be an incredibly powerful skill to have under your belt. Unfortunately, Excel has become the Swiss knife of the corporate world, spreading the belief that spreadsheets are the only way for the layman to use a computer. But that could play in your favor if you decide to learn to code, as you will be able to do things that your colleagues just can’t. Keep in mind that all the educational material that promises that you will learn to program in only 48 hours, is only promising that you will learn the basics of coding, and even then you will need to spend much more time solving real problems before coding sinks in your mind.

Learning to program is something that probably takes thousands of hours, hundreds of thousands of lines, and many years. You will need to learn more than one computer language, and I would recommend that at least one of them is a low-level compiled program like C, which will give you a better understanding of how computers work. A good way of getting yourself immersed in the programming experience is by actively contributing to any of the thousands of open source projects that you can find in GitHub, forcing you to adopt many of the practices of the trade.

Programming is more a career than a skill, and it is ok if you decide that you don’t need to go down that route. Coding could be a brilliant hobby to cultivate, a sharp weapon to have in an office working environment, and a beautiful way of appreciating more the digital world where we live nowadays.