I found this cool article differentiating between a “developer” and a “programmer” and thought to share the same with all of you. The article was taken from HackNot. Read it for yourself and distinguish whether you are a “developer” or a “programmer”. Luckily I am neither a “developer” nor a “programmer”.
Developers are from Mars, Programmers are from Venus
Many of us use the terms “programmer” and “developer” interchangeably. When someone asks me what I do for a living I tend to describe my vocation as “computer programmer” rather than “software developer”, because the former seems to be understood more readily by those unfamiliar with IT. Even when writing pieces for this site, I tend to swap back and forth between the two terms, to try and avoid sounding repetitive. But in truth, there is a world of difference between a computer programmer and a software developer.
The term “programmer” has historically referred to a menial, manual input task conducted by an unskilled worker. Predecessors of the computer, such as the Hollerith machine, would be fed encoded instructions by operators called “programmers”. Early electro-mechanical, valve and relay-based computers were huge and expensive machines, operated within an institutional environment whose hierarchical division of labor involved, at the lowest level, a “button pusher” whose task was to laboriously program the device according to instructions developed by those higher up the technical ladder. So the programmer role is traditionally concerned only with the input of data in machine-compatible form, and not with the relevance or adequacy of those instructions when executed.
A modern programmer loves cutting code - and only cutting code. They delight in code the way a writer delights in text. Programmers see their sole function in an organization as being the production of code, and view any task that doesn’t involve having their hands on the keyboard as an unwanted distraction.
Developers like to code as well, but they see it as being only a part of their job function. They focus more on delivering value than delivering program text, and know that they can’t create value without having an awareness of the business context into which they will deploy their application, and the organizational factors that impact upon its success once delivered.
More specifically …
Developers have some knowledge of the domain and the business
Programmers like to stay as ignorant as possible of the business within which they work. They consider the problem domain to be the realm of the non-technical, and neither their problem or concern. You’ll hear programmers express their indifference to the business within which they operate - they don’t care if it’s finance, health or telecommunications. For them, the domain is just an excuse to exercise a set of programming technologies.
Developers view the business domain as their “second job.” They work to develop a solid understanding of those aspects of it that impact upon their software, then use that knowledge to determine what the real business problems are that the application is meant to be solving. They make an effort get inside the heads of their user base - to see the software as the users will see it. This perspective enables them to anticipate requirements that may not have occurred to the users, and to discover opportunities to add business value that the users may have been unaware was technically possible.
Developers care about maintenance burden
Programmers crave new technologies the way children crave sweets. It’s a hunger that can never be satiated. They are forever flitting from one programming language, framework, library or IDE to the next; forever gushing enthusiastically about the latest silver bullet to have been grunted out by some vendor or open source enthusiast, and garnished with naive praise and marketing hype. They won’t hesitate to incorporate the newest technology into critical parts of their current project, for no reason other than that it is “cool”, and all the other kids are doing it. They will be so intent on getting this new technology working, and overcoming the inevitable troubles that immature technologies bring, that there will be no time to spare for documentation of their effort. Which is exactly how they like it - because documentation is, they believe, of no use to them. Sure, it might be useful to future generations of programmers, but who cares about them?
Developers have a much more cautious approach to new technology. They know that a new technology is inevitably hyped through the roof by those with a vested interest in its success, but that the reality of the technology’s performance in the field often falls short of the spectacular claims made by proponents. They know that a technology that is new is also unproven, and that its weaknesses and shortcomings are neither well known or publicized. They know that part of the reason it takes time for the negative experiences with technologies to become apparent is that many developers will be hesitant to say something critical amongst that first flush of community enthusiasm, for fear that they will be shouted down by the newly-converted zealots, or dismissed as laggards who have fallen behind the curve. So developers know to stand back and wait for the hype to die down, and for cooler heads to prevail. Developers also know the organizational chaos that can result from too many changes in technical direction. A company can quickly accumulate a series of legacy applications, each written in a host of once-popular technologies, that few (if any) currently on staff possess the skills to maintain and extend. Those that first championed those technologies and forced them into production may have long since moved onto other enthusiasms, perhaps other organizations, leaving behind the byproduct of their fleeting infatuation as a maintenance burden for the organization and future staff to bare.
Developers know that work methods are more important than technical chops
Programmers often focus so intently upon the technologies they use that they come to believe that technology is the dominant factor influencing the ultimate success or otherwise of their projects. The mind set becomes one of constantly looking over the horizon for the next thing that might solve their software development woes. The expectation becomes “Everything will be better once we switch to technology X.”
Developers know that this “grass is greener” effect is a falsehood - one often promulgated by vendors, marketers and technology evangelists in their quest to sell a product. The dominant factors influencing the quality of your application, and ultimately its success or otherwise, are the quality of the people doing the development and the work methods that they follow. In most cases, technology choice is almost incidental ( the one possible exception being where there is a generational, revolutionary change in technology, such as the transition from low level to high level programming languages). Therefore developers frequently posses an interest in QA and software engineering techniques that their programmer counterparts do not.
Programmers try to solve every problem by coding
It is characteristic of the programmer mentality that every problem they encounter is perceived as an opportunity to write more code. A typical manifestation is the presence of a “tools guy” on a development team. This is the guy who is continually writing new scripts and utilities to facilitate the development process, even if the process he is automating is only performed once in a blue moon, meaning that there is more effort expended in writing the tool than the resulting automation will ever save.
Developers know that coding effort is best reserved for the application itself. After all, this is what you are being paid to produce. They know that tool development is only useful to a point, after which it becomes just a self-indulgent distraction from the task at hand. Typically, a retreat sought by those with a love of “plumbing” and infrastructure-level development. Developers know that there are many development tasks that it is simply not worth automating and, where possible, will buy their development tools rather than roll their own, as this is the most time- and cost-efficient way of meeting their needs.
Developers seek repeatability, programmers like one-off heroics
If development were an Aesop’s fable, then programmers would be the hares, and developers the tortoises. Programmers, prone to an over-confidence resulting from excessive faith in technology’s ability to save the day, will find themselves facing impending deadlines with work still to go that was meant to be made “easy” by that technology, but was unexpectedly time-consuming. Not surprisingly, the technology doesn’t ameliorate the impact of too little forethought and planning. These last-minute saves, and the concentrated effort they require, are later interpreted as evidence of commitment and conviction, rewarded as such, and thereby perpetuated.
Developers are very aware that there are no silver bullets, be they methodological or technological. Rather than pinning their hopes on new methods or tools, they settle down to a period of detailed analysis and planning, during which they do their best to anticipate the road ahead and the sorts of obstacles they will encounter. They only proceed when they feel that they can do so without entertaining too much risk of making faulty assumptions, and having to later throw work away.
Programmers like complexity, developers favor simplicity
It’s not uncommon for programmers to deliberately over-engineer the solutions they produce, simply because they enjoy having a more complex problem to solve. They may introduce requirements that are actually quite unnecessary, but which give them the opportunity to employ some technology that they have been itching to play with. Their users will have to bear this extra complexity in their every interaction with the system; maintenance programmers will have to wade through it in every fix and patch; the company will have to finance the extensions to the project schedule necessary to support the additional implementation effort; but the programmers care about none of this - as long as they get to play with a shiny new tech toy.
Developers continually seek the simplest possible resolution to all the design forces impinging on their project, regardless of how cool or trendy the technology path it takes them down. If the project’s best interests are served by implementing in Visual Basic, then VB is what you use, even though VB isn’t cool and may not be something you really want to see on your CV. If the problem doesn’t demand a distributed solution, with all the scalability that such an architecture provides, then you don’t foist a distributed architecture upon the project just so you can get some experience with the technologies involved, or just because it is possible to fabricate some specious “what if” scenario to justify its usage, even though this scenario is never likely to occur in a real business context.
Developers care about users
Programmers often view their user base with disdain or even outright contempt, as if they are the ignorant hordes to whose low technical literacy they must pander. They refer to them as “lusers”, and laugh at their relative inexperience with computing technology. Their attitude is one of “What a shame we have to waste our elite programming skills solving your petty problems” and “You’ll take whatever I give you and be thankful for it.” Programmers delight in throwing technical jargon at the user base, knowing that it won’t be understood, because it enables them to feel superior. They are quick to brush off the user’s requests for help or additional functionality, justifying their laziness by appealing to “technical reasons” that are too involved to go into.
Developers don’t consider users beneath them, but recognize and respect that they just serve the organization in a different capacity. Their contribution is no less important for that. When speaking with users, they try to eliminate unnecessary technical jargon from their speech, and instead adopt terminology more familiar to the user. They presume that requests for functionality or guidance are well intended, and endeavor to objectively appraise the worth of user’s requests in terms of business value rather than personal appeal.
Developers like to satisfy a need, programmers like to finish
Programmers tend to rush headlong into tasks, spending little time considering boundary conditions, low-level details, integration issues and so on. They are keen to get typing as soon as possible, and convince themselves that the details can be sorted out later on. The worst that could happen is that they’ll have to abandon what they’ve done and rewrite it - which would simply be an opportunity to do more coding and perhaps switch technologies as well. They enjoy this trial and error approach, because it keeps activity focussed around the coding.
Developers know that the exacting nature of programming means that “more haste” often leads to “less speed.” They are also mindful of the temptation to leap into coding a solution before having fully understood the problem. Therefore they will take the time to ensure that they understand the intricacies of the problem, and the business need behind it. Their intent is to solve a business problem, not just to close an issue in a bug tracking system.
Developers work, programmers play
Many software developers enter the work force as programmers, having developed an interest in software from programmer-like, hobbyist activities. Once they learn something of the role that software plays in an organizational context, their sphere of concern broadens to encompass all those other activities that constitute the difference between programmer and developer, as described above.
However, some never make the attitudinal transition from the amateur to the professional, and continue to “play” with computers in the same way they always have, but do so at an employer’s expense. Many will never even appreciate that there could be much more to their work, if only they were willing to step up to the challenge and responsibility.
Software engineering, not yet a true profession, places no minimum standards and requirements upon practitioners. Until that changes, hobbyist programmers will remain free to masquerade as software development professionals.
It is the developers that you want working in your organization. Programmers are a dime a dozen, but developers can bring real value to a business. Wise employers know how to tell the difference.
