I recently began a course mentoring some colleagues in Java development. They have passed the SCJP and are beginning the SCJD project. The question of the difference between a Programmer and a Developer came up, and has been a question floating around the web for some time. Erik Sink has written about the difference here, for example: http://www.ericsink.com/No_Programmers.html
I had some thoughts on the matter, and while the terminology itself is not interesting, it proves useful as a function. So here is what I have come up with:
Programmers specialize in writing code. Developers contribute in multiple, diverse ways to a project’s success. Developers write documentation and specs, perform analysis, and work comfortably throughout the tiers of complex applications.
Programmers make programs that compile and run. Developers make programs that are elegant. Developers make it elegant because beautiful is better than ugly. Because creating a beautiful thing is personally meaningful. Because elegance means "succinctly yet completely expressive". That makes elegant code easier to understand for the programmer who will inherit our code. Because programs that use a small amount of intuitive code to great effect are superior to programs that use a large amount of code that is difficult to understand to achieve the same effect. Because elegance is useful theoretically. Because elegant is inviting. Because elegance means unusually effective and simple. Because in Western culture, elegant means consistent, and focused on the basic qualities, and those are viewed as beautiful. Beautiful is desirable for no reason.
Developers know the difference between complicated and complex, and reject complication.
Programmers want to show everyone their activity. Developers know that it is only progress that matters.
Programmers run their code to find out if it works. Developers write automated test cases to make sure that it works. Developers regression test when code changes.
Programmers rely on QA to find out what is wrong with their code. Developers rely on QA as a sanity check to ensure that their code works equally well in unexpected circumstances.
Developers participate actively in Code Reviews as both the Coder and the Reviewer. Developers know that you often learn as much by teaching as you do by learning. Developers mentor every chance they get.
Programmers hire other programmers and worry they will be outshone. They like to be the best. Developers see everyone’s strengths, and surround themselves with more skilled people than themselves.
Programmers consider only their current algorithm, or method, or class. Or perhaps their current use case. Developers consider their entire system, and consider their system as a small piece of a universe of systems that will all have to live together. Developers consider how their system impacts that universe. Programmers think locally. Developers think globally and act locally.
Developers read to push the boundaries of their craft because they understand that they are not just making a program, but adding to the complexity of the entire IT ecosystem that includes other systems, hardware, networks, and more. They are not satisfied being good coders. They must be good IT citizens.
Developers demand to always and only tell the truth in their design, no matter what. That means that their code reflects the real world—not a part of the real world that is modified to work in some program’s use case. Developers do not view the programming problem before them as fixed. Developers know it is fluid, and they are not afraid to change the programming problem if it is necessary in order to tell the truth.
A Programmer’s program is a private language; it uses every bit of the language, and is rigid. It cannot be translated. You can translate a Developer’s program to plain English, and it reads like a children’s book.
Programmers are afraid of what will break in their program when the business rules change. Developers know that when the business rules change, their program will absorb it, because their program tells the truth about the world, and the world makes sense. Extending their program is no more strange or difficult than adding a hobby to your life.
Developers know when code becomes legacy code—the moment it is committed to the repository. Legacy doesn’t mean old—it means existing in the world, so someone will have to determine what is true about it—what it does, doesn’t do, how it works, why it exists, how it relates to other things. Developers are very careful to make legacy code, because they know how expensive it is.
Developers write clear, concise, helpful, correct, updated, cross-referencing documentation. They feel silly doing it, because their code is so simple, expressive, and only ever does one thing—the one thing for which it is named.
Programmers do what the customer asks for. A programmer is a passive receptacle for the customer’s "requirements". Developers refuse to accept a passive role in the customer relationship. Developers know that customers typically describe solutions when they think that they are describing requirements. Developers are brave enough to design the program, and not allow the customer to do what he is not qualified to do.
Programmers listen to what the customer says and believe they are doing their job to simply make what is described. Developers refuse this, because they know it hurts the customer. The Developer hears what the customer says, and also hears what they don’t say. The Developer gets the customer to divulge the problem, not the solution. The Developer does this by knowing the right questions to ask. Only in this way can the Developer get the customer to talk less and say more.
The Programmer is a mirror for the customer’s text. The Developer provides the solution based on true active listening. The Developer interprets the customer’s script, and directs a film.
The Programmer enjoys gathering requirements, because they are finding out what they get to make. They feel their power as they think of ways to implement the requirements. The process excites the customer, because everyone enjoys expressing his desires. The Developer knows nothing is more boring than requirements. The Developer knows his role in the process is to break down everything the customer says until there are no more assumptions, but only many hundreds or thousands of tiny, raw, simple, undeniably true statements about the world. Each of these statements is as interesting as the entries in a phone book.
Programmers feel that they are smart, and focus on programming the customer’s solution exactly as outlined. Developers forget what they have to program. They work hard to maintain only a foggy idea about the business rules. Programmers work in photographs. Developers work in rough chalk sketches. Developers actively do their best to remain dumb about the business rules, and continually express gratitude for the patience of those working with them. Developers stay dumb about the rules in order to stay general. Developers know that rules are at once like commandments—the most important thing, the only thing, the law—and yet also as worthless as gossip on the most trivial breeze. Developers at once respect the rules simultaneously as law and as gossip. The Programmer cares too much for the rules, and he will write a world where the rules are the only true things. The Developer stays dumb about the rules, and so he will write a world where the rules can be true. Because he knows he cannot remember and understand them all, they must be adhered to with utmost precision. But only indirectly. The Developer understands there is a paradox in free will. He does not make mistakes about causation.
The Programmer writes a program that represents the business solution. He loves his solution because he is married to it, and he must guard it jealously from change. The Developer writes a world that the solution inhabits. The Developer knows that his solution is incidental, and has no particular feeling for it. He admires its beauty, because it is something in the world that is pretty, like a leaf.
The Programmer’s program is a room. He cares deeply about the walls, the ornaments, the flooring, the treatments, the colors, the dimensions, and everything about the room. He is delighted when his customers see it. He wants his customers to use what he has made, to feel the textures of the rich fabrics. He will be praised for such richness. The Developer wants the customer to achieve her goal. He knows that his program is successful when it is invisible. He knows it is not the walls and floors and windows that the customer lives in, but the empty space in the room that the customer lives in. He will not be praised, because the customer will believe that the Developer has done nothing--the software appears to have been there all along.
Programmers only ever see one choice before them. Developers have many choices before them. They know they have found the right choice when it comes to appear as if they only ever had one choice all along.
Programmers like programming, and will accept programming work in order to have the pleasure of making a program. Developers ask what interest the program serves. Developers know they are always serving an interest, and their pleasure derives from being in the service of that interest. A Developer knows that it is the interest that matters, and not the program. The fact that he happens to be the person who writes the code is interesting only to him, and is not interesting to anyone else, and is not intrinsically interesting. Developers like complex problems, and are not interested in uninteresting things, such as the fact that they are developers.
Programmers are hired for a job. Developers cannot be hired. Developers must be trained to be Developers from the inside.
Programmers like it that people think they are smart. Developers like it when they know they have been useful. They know they are no smarter than a painter or a cat.
Programmers care intensely about their view of a project. They are agreeable and flexible, and change their views as the business appears to require. Developers know that their view of a project is not interesting to anyone but them. Yet they never compromise on what is required to make the project successful, even if it is unpopular. They do not have to compromise, because they cannot be hurt.
Programmers do not ask questions, because they are afraid of revealing what they do not know. Developers ask questions because they are in love with learning.
Programmers know everything. Developers know they don’t know anything at all. You become a Developer when you give away to others everything you know and everything you do not know.