Hacknot - Developers are from Mars, Programmers are from Venus

Joel Liu's personal annotations on this page

Joel bookmarked on 2006-10-10 career developer programmer

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.
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 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.
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.

This link has been bookmarked by 19 people . It was first bookmarked on 09 Oct 2006, by Chris Harbert.

08 Nov 06

Viktor Dolezel
programming
29 Oct 06

Jamie
development programming software
13 Oct 06

Art ist
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". . .

development programming
12 Oct 06

craig hancock
Article career code coding comparison consulting criticism culture dev developer development engineering essay essays Geek hack hiring interesting job Methodology philosophy productivity programmer programmers programming project read reading resources So
11 Oct 06

Doug McCaughan
programming developer programmer software development article comparison
Melodie Neal
coding software People Perception Finance Development
Sumukh S
generally difference between programmer and a developer.

developer programmer
Ryan LaNeve
development
10 Oct 06

Matt Vance
JNM
development
Joel Liu
career developer programmer
- 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.
- 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.
- 2 more annotations...
- - 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.
  - 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.
moosbruxxer
Articles
- Developers are from Mars, Programmers are from Venus
- Developers are from Mars, Programmers are from Venus
cstrap
OTHER
09 Oct 06

Chris Harbert
programming
- 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.
- Developers know that the exacting nature of programming means that "more haste" often leads to "less speed."
- 6 more annotations...
- - 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.
  - 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.
  - 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.
  - 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.
  - Developers like to code as well, but they see it as being only a part of their job function.
  - A modern programmer loves cutting code - and only cutting code.