For people not involved in software development, programming and coding sound like the same thing — except they’re not, and it can be important to look at the differences between the two.
Coding is just one part of programming
Coding is basically the process of writing code from one language to another, whereas programming is the process of developing a program so that human inputs and machine outputs are in sync.
In other words, programming deals with the bigger picture, while “coding is the easy part of programming,” Leslie Lamport told ZME Science during an interview at the 2019 Heidelberg Laureate Forum (HLF) in Germany, an annual event that brings together the world’s foremost mathematicians and computer scientists.
“Programming can be divided into roughly 3 sub-tasks. The first thing is deciding what the program should do. If you don’t think carefully about that, it’s going to wind up not doing something that it probably should do or you wind up with an ‘absolute bug-free program’. Because to have a bug, you have to have some notion of what it means for the program to be operating correctly. And there is no precise definition of what it means for the program to be correctly operating — so, well, no bugs. Not a very good situation,” said Lamport, who is best known for his seminal work in distributed systems and the development of the document preparation system LaTeX.
Leslie Lamport was the recipient of the 2013 Turing Award for imposing clear, well-defined coherence on the seemingly chaotic behavior of distributed computing systems, in which several autonomous computers communicate with each other by passing messages.
He loves clean code and good algorithms — and he loves to highlight the difference between coding and programming.
| Coding | Programming |
|---|---|
| The process of writing code from one language to another | The process of developing a program so that human inputs and machine outputs are in sync |
| Deals with the smaller picture | Deals with the bigger picture |
| The easy part of programming, according to Lamport | Divided into roughly 3 sub-tasks: deciding what the program should do, deciding how the program should do it (algorithm level), and coding it in a programming language |
| Focuses on the syntax and structure of code | Focuses on the algorithm and how it is done before writing code |
| Requires knowledge of programming languages | Requires knowledge of algorithms and mathematical thinking |
| Can be done without understanding the algorithm or problem-solving skills | Requires understanding the algorithm and good problem-solving skills |
| Less emphasis on thinking and planning | Requires more thinking and planning before writing code |
“The second part is deciding how the program should do that. And that’s what I would call the algorithm level rather than the code level. If you take something like Euclid’s algorithm and you write Euclid’s algorithm in English, there’s no programming language involved. It’s an algorithm. It’s not a piece of code.”
“The easy part is taking that algorithm and encoding it in some particular programming language. But imagine trying to invent Euclid’s algorithm. If you were thinking about it in terms of code, you know, gee, should I have a procedure here? Should this be an assignment statement? You’d never discover Euclid’s algorithm.”
“So, you should be thinking about the algorithm — the basic how it’s done — before you start writing code.”
In other words, according to the esteemed computer scientist, coding is just one of three major pillars of programming. Programming can be viewed as the higher level stage of software development in which a system is designed and throughout, whereas coding is the last stage of the overall process in which the software is actually written.
Too many young software developers focus their time and attention on learning new programming languages and frameworks, but tend to neglect their education in algorithms and math. While learning how to code is important and a big part of a programmer’s life, there is much more to it.
Good software is first and foremost easily understood by people in everyday language, which should make it even easier to compile by machines.
“You don’t understand something until you’ve written it down carefully — carefully enough to explain it to somebody else. And if you haven’t done that, you’re just thinking you understand it,” Lamport said at HLF 2019.
“The ‘what a program should do’ should be at a level of detail so that somebody could use the program just based on that description. They shouldn’t have to look at the code to see what the program does. It’s absolutely disgraceful that it has become common practice that if somebody writes a program and somebody else wants to use it, he has to read the code to find out what the algorithm does.”
How to design software and write code with clarity
So what can a programmer do to write more clearly and improve their software development skills? This is where TLA+ comes in.
Lamport designed TLA+ as a set of tools for specifying and modeling algorithms. It consists of the TLA (Temporal Language of Actions) specification and PlusCal algorithm language, as well as a set of associated tools for writing and modeling. Many liken its use to drawing blueprints for software systems.
“Unlike most languages that engineers use, this is completely mathematical. My goal is, in addition to providing a tool that engineers can use to find errors in their designs, it also improves their thinking about the systems they’re building. Ultimately it leads them to build better systems,” Lamport said.
“By describing it mathematically, you’re able to get closer to the essence of what the algorithm is without having programming language constructs get in the way. It’s something that’s not easy for engineers to learn. Changing the way they think part — that takes time,” he added.
As an anecdote to illustrate the power of mathematical thinking in system design, Lamport once solved the algorithm for digital signatures — which form the backbone of secure online communications — on a piece of napkin.
Many software engineers are petrified of mathematical equations, but by Lamport’s reasoning, they’re doing a disservice to themselves by not employing mathematical thinking in their system design. Oftentimes, you don’t need code — you just need the algorithm.
Think of it this way: writing is a way of revealing how fuzzy your thinking is. In this context, coding is just a small part of programming where real thinking takes place.
The world needs good coders, and it also needs good programmers — and it’s better for everyone if we understand the difference between the two.
