Programming: What Exactly Is It

Computer Science is a misnomer. A science is the study of a particular subject with the aim of building a body of knowledge through observation, experimentation and prediction. Physics is a science; we've worked to understand the natural laws that govern material objects, their movement and their interaction with each other.

In contrast, a programmer does not study and try to understand a set of laws inherent to an existing, mysterious system. A programmer creates. The computer does not cease to function if you put everything into the global namespace or create a God object. It's just a bad judgement call. Science doesn't have judgement calls. It's either true and testable, or it isn't.

So programming is a craft. A craft is something that requires skilled labor. Unlike art, it generally produces something practical and usable. Unlike unskilled labor, one of the worker's responsibilities is to make judgement calls that greatly affect the quality of the result.

A programmer named Dan North wrote a winding and controversial article defending his opinion that programming is not a craft but a trade. I don't feel like picking apart his entire article, but here are a couple points:

• He doesn't argue in terms of concepts. Depending on your take on the words "craft" and "trade" (which, according to some dictionaries, are synonyms), you may agree or disagree with him. That's a shaky basis for an argument.
• He focuses on the attitude of some programmers who claim to be craftsmen. He has more of an issue with conceited posers than good programmers who consider their work a craft.
• He says that clients don't care how well-crafted the code is; they simply want it to do what they want it to do. That's true, but they also want to save time and money in the long-run.

Unskilled labor can be unskilled because they've been given a design formulated by someone else; there are few or no judgement calls left to be made. E.g., an assembly line worker who bolts pre-stamped parts to a car or a worker in an electronics factory who solders components to a board according to a schematic. Unless you have a software architect who spells out every class, every package, every method and every interaction, you make hundreds of judgement calls every day as you code, and those decisions affect the long-term viability of the software.

No matter what features our bosses or clients want from us, we're the programmers. We're responsible for knowing how to implement those features in a way that will benefit the company or client, not just right now, but in the long-run. If your only focus is to get the code to do what the the client wants, I pity the developer who has to maintain it and the client who has to foot the bill to extend it. That's where craftsmanship comes in. We're paid by clients to craft a quality product that they will continue to be pleased with.