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 (editor’s note: aka engineer and there is also a difference with a software architect).
Developers Are from Mars, Programmers from Venus
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
36 Comments
2006-10-10 4:50 pm
2006-10-10 7:29 pm
2006-10-10 9:17 pm
-
2006-10-10 9:35 pm
Very funny descriptions.
2006-10-10 9:46 pm
2006-10-10 11:24 pm
I always thought Steve Balmer was Martian like. This is the confirmation I need!
Developers, developers, developers…
Edited 2006-10-10 09:38
Although quite a bit polarized, I think this description of two different types of “software producers” (trying to find a term fitting both) is quite accurate. Personally, I’m more of a software developer, looking at the overall architecture design first, but with a tendency to sometimes focus too much on the low-level code quality/optimization at times.
Most people working with software probably falls somewhere in between here, which is a good thing.
Edited 2006-10-10 10:19
I see a “software programmer” as more of a black box programmer, writing modules based on set i/o and other requirements. I see a “software developer” as someone who’s more involved in the whole development life cycle.
The roles of developer and programmer are not different at all. The differences that he’s come up with there are the particular skills and drawbacks that he’s listed as to whether someone is a developer or programmer. These are all related directly to the sort of person they are. As such, the role you have is what you make it to be.
Programmers sit there and code, and developers sit there and code, actually think about the implications of what they’re coding and take action and ask questions accordingly in order to improve the general quality of everything. This is why many decent hackers have gone on to head software projects and strangely turned them into right dogs’ breakfasts. That sums up the article.
Developers care about business knowledge and functionality and whether it makes sense, they care about maintaining the code, they care about binary compatiblity and other methods to keep existing versions of software working while an update is in progress etc. etc. The difference between programmers and developers can be summed up even shorter, with one word – care.
This is why people like Joel Spolsky and Eric Sink tell you to hire developers, and not programmers or hackers, especially in a small business – no matter how good the programmers or hackers are. Developers should also know their stuff and be able to hack well though, which makes them as rare as hen’s teeth or rocking horse sh**.
Yea but Paul Graham and Steve Yegge tell you to hire hackers and not developers
. Well, not in so many words, I believe what they say is that you shouldn’t hire Java developers you should hire Python and Lisp developers (but I hope we can all see how that turns into developers and hackers).
Anyway, I don’t think there’s a real difference in the terms.
Programmer – What lay people call developers.
Developer – What many developers call developers.
Software engineer – What other developers call themselves.
Software architect – This is actually different, but you could probably still call them developers (although I imagine they’d be offended by being called a “programmer.”) They still “develop” software.
Damn. I was really hoping upon clicking the link that i’d get an interested article about the difference in goals between the two terms, and instead got little more than “Software Developer = Good, Programmer = Bad”.
I’m not sure what happened to the author to prompt this self-righteous mess, but i’ll never find out because i won’t be revisting.
The term ‘developer’ was established in the 90s as a political-correct version of ‘programmer’, in order to make programming a better-sounding job than what it is…before that, no one spoke about ‘developers’. The trend to use buzzwords and important-sounding words has been going on ever since. I have kept many IT magazines from 80s, and there is no ‘developer’, ‘technology’, ‘architect’, ‘platform’ etc buzzwords in them.
Whenever people ask me what is my job, I always say ‘programmer’, even if it includes making design decisions and writing design documents; because, in the end, it is still programming, even if it is on paper.
You’d be inclined to think that, however, it could also be just a result of the changing resposibilities tasked to IT personnel.
“Developers know that this “grass is greener” effect is a falsehood”
But what if the switch is a change of mindsets that avoids the problems listed out in the article? In that case, the grass is greener, isn’t it?
Many folks don’t like the support/maintenance side of a programmer/analyst’s job, which is where a lot of time is spent on any production shop.
Some shops will actually split their people into development and support people, something I think is a mistake (folks who have to support a product will have a vested interested in making the code more maintainable, and support folks who actually design and write the software will be more intimately familiar with it).
The article casts programmers as excitable, technology-craving, over-engineering geeks against developers who are focused, business-oriented pragmatists. IMHO, workers that tend to either extreme are a bad thing.
In my experience, developers that lack interest in technology will often create home-grown solutions to problems that have already been solved in open-source or commercial libraries. Talk about a maintenance burden!
I have also found that developers that are focused on solving only current business problems and “getting it done” tend to be inclined towards cut-and-paste coding and under-engineered solutions, creating a platform that makes it difficult to sustain developer productivity over time.
Workers who are able to successfully fuse a love of technology with an understanding of the business and a pragmatism that reaches beyond solving immediate problems are what I call “architects”, and I firmly believe that one can become an architect via either the “programmer” or the “developer” path.
P.S. – In reality, one of the biggest differentiators between “programmers” and “developers” is that the latter, by virtue of their interest in the business-side of things, tend to get much more positive exposure to management, which brings obvious career benefits and a better public image.
I hate to be snooty here but developer and engineer are not interchangable. The volume of formal training that an engineer gets to graduate with their degree is monsterous. Most people don’t realize that writing code is just the final step in the whole design. An engineer put +80% of the total work in before he/she fires up an editor or IDE. The 80% includes not only the design but also takes into account the involvement in the business plus much more.
Software Engineering programs are generally a joke in terms of engineering rigor. There is what I would call real software engineering, but it’s a pretty small market compared to the legions of “get it done” employers.
The volume of formal training that an engineer gets to graduate with their degree is monsterous. Most people don’t realize that writing code is just the final step in the whole design.
Well my title is Software Engineer. Sure I learned the “proper way” to do requirements capture, followed by proper design, incorporating reuseable code, followed by rigirous testing.
Unfortunately in all but one job I have been employed in, budgets, and timescales do not permit it. People don’t know what they want untill you have implemented something, and people always just want a quick fix to the existing solution.
…but it’s much harder to pretend to be a computer programmer.
That’s why application development is in the dismal state it is in today.
There are waaaay too many folks involved in software development who have no business to be in it. Especially management positions.
Everyday, at my clients, I come across situations such as peeps that have HR backgrounds, who are suddenly leading a team to devise a company’s data centre strategy.
It’s much harder for these folks to masquerade as computer programmers, though.
IT departments are rife with unqualified management acting as software developers.
I often thought that the market meltdown just after Y2K was good for the industry…that it would act as a massive douche of the rank and file of IT.
Sadly, this hasn’t happened.
Paul Graham wrote a great essay about the differences between computer science and programming. Although it’s not quite the same as what’s discussed here, I couldn’t help but think of it when reading the heading.
Software development is a very technical field where one has to possess a very sharp mind to be able to accomplish the tasks that are frequently presented. Yet, is the title of “engineer” well placed when reffering to computer science people? The scientific, technical and methodical aspect which is the basis of true engineering, let alone the accountability, simply isn’t present in software developing, at least as it is present in true engineering fields.
You’re right, we don’t pay an admissions fee as software developers to an engineering group, well, other than the ACM or IEEE.
There’s a lot of engineering methodology in software development, and it gets ignored often: Which isn’t surprising, because, you’re right, it’s not really engineering.
But it’s definitely not science.
It’s really not math.
I think it falls closest to engineering.
I don’t think the term “engineer” should be used by any programmer unless they’ve actually completed an accredited engineering program of some sort.
My job title has usually been a variant of programmer/analyst, which describes the position well — I analyze business issues, do high-level and detailed software/system design, do coding, design and perform test plans, implement the code in production, and support the software once it is loaded and running.
It ain’t just “programming”, but it isn’t just “development” either…
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
Completely clueless! How very 20th century – the guy obviously wants to employ cubicle drones. Fun. What’s that? The Hacker Ethic? Never heard of it.
I’m currently stuying to become an “Master of Science, specialisation Systems Analysis”, one of the first thing they threw at us was a course whith pretty much the same message.
Tha programmers are grunt workers doing the coding, software architects are the REAL problem solvers. The course book read almost eactly as this article. (The Software Architect’s Profession by Sewell and Sewell) The major difference, though, was that they made the seperation based on profession, rather than attitude.
Me, I don’t see the difference. Wheter you code in assembly and let the computer translate it into machine readable code or you code in UML and let humans translate it into Java, you are still a programmer, solving a programmers problems: Designing a system to do a task in the best way possible.
It’s not the difference between programmers and developers. It’s the difference between good programmers and bad programmers.
“The programmers are grunt workers doing the coding, software architects are the REAL problem solvers”
Actually, one of the biggest things I’ve come to realize after graduating and working is the superficial distinction between ‘design’ and ‘implementation’. I know the difference, but it’s been misused too much. This is where you get those failed outsourcing bids of “we’ll design it here, and India can implement it”
I like to say, there is no implementation. The compiler is the dumb assembly line worker. Everyone else is a designer. Some doing highlevel stuff. Others doing low-level stuff. An architect is definitely needed, but every level of design needs to be good. Even a simple for loop is design and needs to be done well.
Of course, you only need to read a few paragraphs to realise where the author’s heart lies – programmers and developers are not two sides of a medal, or two types of people employed in software development who team up to complement their skills – no, developers are everything programmers are and then a lot, or, put another way, programmers are like developers that lack certain key insights and are generally a bit stupid.
Thus, the post goes on to attribute every desirable trait of of people working in software development to the term “developer” and label people who lack these traits “programmer”. That is a nonsensical way of categorising people. Since the author apparently intends his treatise to be advice to managers in charge of hiring for software projects, what he’s essentially saying is that there is a group of people who have all the right skills and knowledge and attitude, and there’s a second group of people who have all the wrong ones. So, if you manage to employ a software developer, you will have someone on your team who puts the right value on work methods, keeps his sight on the maintenance burden, favours simplicity, “adopts terminology more familiar to the users” when talking to them, etc. etc. If you accidentally employ someone from the wrong faction, you’ll get none of this.
If you are a personnel manager and believe this rubbish, then you probably won’t be a personnel manager much longer.
It’s pretty typical for interweb personas, though. They describe the ideal super being in contrast to the common lowly blub person, and then the reader for whatever reason assumes that they are the topic of discussion and goes, “YEAH!”
I think the difference between a programmer, developer and software engineer is mindset. For programmers code is all that matters. Software developers are programmers that have evolved to understand that code is almost insignificant to the success of a project. Developers see themselves as maintainers or managers of a project. Developers think at the project level. Software engineers are a breed of developers that apply scientific order to the process of running a project. They observe, document, experiment, measure and research everything. Engineers think in terms of reliability and accountability. Of all the mindsets, the engineer is the most evolved. For an engineer everything is a problem that needs to be solved efficiently and effectively, not just writing code. In the past, I too fell into the trap of thinking a programmer is a programmer and nothing more. But overtime I’ve come to realize there are different breeds of programmers based entirely on mindset.
Software developers are programmers that have evolved to understand that code is almost insignificant to the success of a project.
Only it isn’t. All the high-level, “big picture” thinking, modeling, architecting, etc. will get you nowhere if you don’t get someone to sit down and write quality code. Well, I suppose there are some projects that are all about figuring out the right SAP modules to plug together, or something. I think the Programmers [TM] can live with the knowledge that they are not the right people for those jobs.
But let’s assume, for example, that you’ve been hired by a public transportation company to implement a timetable website, where you can enter your place and destination and it’ll find a route for you. The business side of this is dead easy to understand, even one of them dim-witted Programmers could get it. But writing a program that finds routes is – how shall I put this – not something you can read up in a design pattern book. Good luck to the Developers [TM], who have understood that code is almost insignificant to their success, implementing that system.
From what I’ve seen, there are many aspects to being a good programmer/developer/architect.
One of these that constantly gets missed by the self-taught crowd is some of the fundamentals of the mathematical foundations of CompSci. By and large, these skills are only taught at university. The information is available on the ‘net (and is frequently more readable than the text books) but most people who are self taught, will not bother to learn.
This includes things like knowing why the difference between O(x^10) and O(x^x) and where it is important, how to convert between a regular expression and Finite State Machine, understanding the limits of IEEE 754, and knowing what graph theory is and how it helps in pathing searches.
Business knowledge, appreciating the value of integration and common standards go a long way as well. The amount of systems that roll their own authentication system astounds me – as do the number of systems – and programmers – that can’t differentiate between authentication and authorization.
That said, even people with this knowledge can and do stupid things – like setting a standard in a large PHP project of returning zero for a successfully run function. (PHP usually validates zero to boolean false).
It seems to me that the difference is between those who are willing to do things properly – and those who are simply too lazy. I don’t think we need any more labels than that.
I agree that labels of developer and programmer are inappropriate. I have truly talented friends who are clearly some of the most conscientious and knowledgeable developers I have ever known who didn’t even finish college. Conversely, I know individuals who have done well in a university computer science program who I would likely never hire. Although they learn the information for a test, they never really cared about anything other than getting a good paycheck upon graduation and their attention to truly understanding the knowledge being taught was simply not there.
Most nearly all of this relates to the effort you put into something. You get out of school what you put into it. Likewise on the subject of the evolution of the programmer, I feel that evolution is perhaps a poor choice of terminology as it has a rather derogatory connotation. As a younger man, programming was more interesting to me because I did not have a larger context to place it in. As the years have gone on, I have had the joy of building out products and seeing users appreciate them. I feel that anyone who cares about what they are doing and gains good experience will tend to migrate from the extrema towards the middle.
Final Thought: It takes some of both extrema to be successful. Good communication and a mutual respect for what the “other half” does can make for a very effective team that gets excellent coverage of both the design and the technological issues when they work together.
A few days ago, a programmer sent me a patch he didn’t test. When he told me that, I knew the code won’t work. I was right. The fact that the code did not work had nothing to do with the programmer’s competence. It had everything to do with his mindset. Any developer or engineer knows how moronic doing something like that is. You don’t learn this in college either.
I agree with the author about the two types, but I think his choice to use “developer” for one and “programmer” for the other is arbitrary and does not reflect actual language usage, which uses these terms interchangeably, along with “engineer”. The only distinction which exists “in the wild” is “developer/engineer/programmer” on the one hand vs. “architect” on the other.
Again, I’m talking about how people actually talk. I agree with him that the two types exist, but not that they have the labels he ascribes to them.
What, I think, the author is clumsily aspiring to is the well-known, well defined management 101: ‘Team Management Profile’ method.(