By Jack Ganssle

Coders Vs Programmers

Published 11/02/2001

I get ticked off whenever a manager uses the word "coder".

Historically "coder" means someone who translates a very detailed design to C, C++ or whatever language is used. In the old IBM "chief programmer" days coders were an important part of the development team, but were at the bottom of the pyramid. It was assumed these folks were trainees or had little expertise, so they slaved at more or less rote translation activities. Coders were analogous to draftsmen, those skilled technicians who render engineering concepts into the important but dull drawings needed to actually build something.

Let's face it: any idiot can write code. Even teenaged hackers do a workmanlike job building (mostly) simple systems. UML advocates often demonstrate that the machine itself can write the code from a sufficiently-detailed design.

The challenge we engineers face is designing a solution to a particular problem. I believe the real fun is in inventing the solutions, not in the dreary coding process. For me the most exciting and creative part of a project is doing the rough system design, figuring out what should be done in hardware and what in the firmware, and then blocking out the overall approach.

Coding is most fun when there's not much of a design; when we're putting the C and the structure together at the same time. A lot of people might recoil in horror at this statement, since we "know" we're supposed to design first and implement second. But, right or wrong, the vast majority of developers work from an incomplete spec and design.

In fact, the only complete design spec tends to be the code. There are a hundred little decisions we make as we type in C statements, from oddball exception handling to what happens if some really weird combination of inputs happens. In my experience virtually no design document captures every essence of what the program will really do.

In the embedded world there are few true coders. We're highly trained engineers who code and design together, or who create the structure and then implement it in firmware. Perhaps we'd be more efficient if we did separate designers and coders, but this seems unlikely to happen. It's certainly valuable to keep ones hands in the dirty business of actually making the system and getting it to work. The crucible of making things work always teaches us a lot about the limits of what we can actually build.

The "coders" word is usually used by managers who view software as a necessary evil, rather than a critical part of the value delivered to the customer. These oh-so-common dinosaurs doom projects and frustrate their staff.

Desktop developers embrace "programmer" as a job description. Perhaps that adequately captures the limited range of skills needed to crank out a Windows app. Me, I prefer "engineer", a moniker that better describes the breath of experience needed for embedded systems, where hardware and software seamlessly blend together to yield a product.