Home | Archive | Courses | Talks | YouTube | EmacsCast | Bookshelf | Twitter | RSS
I don’t think there are formal definitions for either “coding” or “programming” or even “software engineering”, even though the latter is used in formal contexts like academia and human resources. They are vague, pliable terms which mean different things to different people. I want to share how I sometimes think of them.
Programming is solving explicit problems in a verifiable manner.
It is similar to mathematical proofs. “Find an element in a sorted sequence” is a problem. A binary search algorithm is a solution. You can prove its validity. You can even try to prove or disprove whether it is the best possible solution in terms of efficiency.
A better word for programming is computing, which isn’t a new area at all, but rather a part of mathematics. For programming (computing), code is not relevant, algorithms are. Only essential complexity exists on this level, and no accidental complexity is a concern.
The goal of programming is to create an algorithm (or show it can’t be done).
Coding is expressing a programming solution in a formal language.
Coding is simultaneously easier and harder than programming. It is easier because coding assumes the problem is already solved. It is harder because to encode a mathematical algorithm into a real-world system is to solve a non-explicit problem in a hardly verifiable manner (e.g. “make the app run on all devices”).
In a perfect world, coding would be strictly easier than programming. In our world, a lot of accidental complexity comes from coding.
The goal of coding is to write valid code.
Software engineering is building a product for the real world.
It is similar to civil engineering. It encompasses both programming and coding, as well as other areas, such as:
Depending on historical, cultural or political context, software engineering might expand to include more responsibilities. The majority of accidental complexity comes from SE.
The goal of software engineering is to solve real world problems.
I’d say for many devs, the following is true:
Since a regular, normal career in tech is a combination of the three fields, many people come back even after severe burnouts. We love programming. Burnouts originate from engineering and maybe coding, but rarely programming. We all dream of the world where we create algorithms in the perfect, mathematical universe, then implement them in a perfect language for a consistent, well designed system. But reality requires us to deal with inconsistent formats, ambiguous requirements, needless complexity, infrastructure, deployment, delivery, relationships, communication, politics, finance, etc.
These definitions aren’t helpful in everyday life. For the most part, we all use these words interchangeably, and we usually encompass everything under “programming”.
I find it valuable to differentiate between the three in times of reflection. When I feel energized and motivated, I want to know what drives me. I want to clearly see the position I’m in. When I feel depressed or burned out, I want to know the causes.
The differentiation is also helpful when you ask yourself: what area do you enjoy the most? There are no wrong answers: programming isn’t sacred, software engineering isn’t dirty, coding isn’t an afterthought.