We’ve been conditioned to accept the terms “Programmer, “Software Developer”, and “Software Engineer” as synonymous. Want ads and internal job titles tell us so. When someone gets paid to fill a human-sized hole, they’re going to use the most marketable term that can be attached to a three sentence description, so these terms are used almost interchangeably. We can’t trust that a company hiring for a “Developer” actually needs the skills that make a “Developer” different from a “Programmer”.

However, despite rampant misuse, the differences between the term “Developer” and “Programmer” still have value.

The Programmer vs. the Developer

To start with we have to accept that these titles represent different things. That neither of these titles are better than the other. In fact I would be willing to bet most of us have the wrong titles, both as a description of what the business thinks it needs from us and a reflection of our own particular skill sets and personalities. We’re going to ignore all that for the moment.

Ignored? Good.

The defining difference between “Programmer” and “Developer” is one of scope, of depth vs. breadth.

The Programmer

The programmer writes code. The programmer knows the ins and outs of language, programming constructs, programming theory, and so on. The skill level of a programmer is reflected in their ability to write the best, most efficient, bug free code possible and to write that code for a well-defined purpose. The focus of a programmer is to deliver working code, skills outside of this focus serve as communication bridges to people with responsibilities for high level design, testing, project management, support, and so on. The Programmer has depth.

The Developer

The Developer produces a finished solution for a murky business definition. Along that path from nothing to something there is programming, but also end user communications, business analysis, architecture, documentation, testing, project management, and so on. A Developer has a base level of skill in all of these, some stronger than others. No two developers will have exactly the same skill levels, but their overall ability as a developer is reflected in how accurately the end solution meets the customer’s needs. The Developer has breadth.

The Overlap

There is overlap. Obviously both roles are expected to write code, though I would expect a Senior Programmer to write better code than a Senior Developer. A Programmer might also have some experience with Unit Testing and Technical Documentation, but a Developer should take that further and have experience with end user documentation, integration testing, and manual testing. A Programmer is expected to have a certain level of design knowledge, but the Developer should be able to help the business or customer create requirements and design a system that fulfills those requirements.

For another comparison, check out Small ISVs: You need Developers, not Programmers by Eric Sink (blog|twitter)

Which Is Better?

It Depends. (yeah, I said it)

The Developer is a Swiss Army Knife with a vague set of specializations while the Programmer is a power drill, specialized to write code. A good group of developers will have complementary skill sets that allow them to take a project from vague business problem to solution with built-in redundancy for responsibilities. A great programmer will write better code than a great developer but have limited or no skill at translating business problems into business requirements, defining technical requirements, interacting with the customer, and designing the high-level architecture.

And this is important, why?

So back to where we started. Job ads and job titles cannot be counted on to accurately represent what a business needs or expects. However understanding what the company actually expects and where our own skills and preferences lie can have a drastic effect on how well or poorly we will do and like our jobs. Are we the Swiss Army Developer or the specialist (programmer, BA, QA, architect, PM, etc)?

Job titles may be unreliable indicators of company expectations, but the terms still provide a useful starting point. Framing the company expectations and our own preferences is an important part of doing well at our jobs and in finding enjoyment in what we do.