As you may have gleaned by perusing some of my other posts, I’m kind of a stickler when it comes to words. Words are the basic tools we use to understand things and shape the way we think about them. Thank you, Sapir-Whorf…
In this post I’d like to look at the words “coding”, “programming”, and “engineering” and how they differ. To me, these three terms define a series of refinements on some basic themes but are often treated interchangeably. And sometimes that can cause harm.
“Coding” is a term used to describe the mechanics of creating a program in one of the myriad languages available to us. It is concerned with syntax and language semantics, with the micro-structure of the program. (A synonym often used is “hacking”, although depending on the context that term adds ethical overtones.) It is the essence of program implementation.
Coding is certainly a base-level skill of all practitioners, and it is an aspect of working with computers that can be accessible to the masses. The recent movement to educate computer users to become more literate in the technology focuses on these skills.
“Programming” refers to coding, but adds in a view of the program at a macroscopic level. It is concerned with the mechanics of components, dependencies, layering of APIs, and integration with other systems. It is a layer of concerns on top of those found in coding and is looking at the program as an entire unit. It is, in many ways, the focus of program design.
It isn’t that the concerns of “programming” are more important than those of “coding”, but they are different. They require attention to different details than those associated with coding and involve the practitioner in a different way.
When “coding” is viewed as “programming”, it elevates the activity beyond what it really is, and ignores the existence of the issues that “programming” is concerned with. Depending on the context this may not be an issue: someone’s toy web-site can certainly be coded without too much concern for overall design issues, but would it be appropriate to be so laissez-faire in creating an enterprise support application?
Engineering is programming, but it is also about systems, tradeoffs, and practicality. It views a program as one part of the computing ecosystem and is concerned with how that part will last or evolve over time. It is concerned with schedule and costs, and vendor longevity, and — dare I say it? — architecture.
Above all, engineering is about weighing pros and cons and finding the viable balance-point between them. In the realm of coding, there may be clear-cut right vs. wrong answers to problems (I emphasize may) but that is rare in the realm of engineering. There are a many ways to engineer a solution, and the “correct” one will depend on the judgement of the engineers when weighing all the architectural, systemic, and project constraints.
I think it is great to spread the lore of coding to the masses. If nothing else it will benefit everyone to understand just how stupid computers really are. But coding skills do not imply programming skills, and they are a far remove from engineering skills.
It may seem nit-picky, but as I said at the top, the words we use frame the way we think about an idea. When we equate coding with programming with engineering we lose the important nuances in meaning and context, and either elevate the simple beyond its merits, or over-simplify the complex.