Ask HN: Programmers vs. Developers vs. Engineers

22 points by kylelibra ↗ HN
I've done some basic Google searches on the subject, but I'm curious for the HN take on the situation.

What are the main differences between programmers, developers vs. engineers in the industry? Is there that big of a difference between the three? Based on what I've read there does not appear to be any consistency to which title applies to which type of job. It seems to be preference.

Thoughts?

57 comments

[ 3.1 ms ] story [ 111 ms ] thread
I think that those are too generic terms and that those terms cover a wide area of work. They can overlap very much. Most notably engineers can be engineers in very different areas, also a developer can develop kernel level C code, HTML pages or database queries, which can also be done by a programmer. That's why in general the job titles are more detailed (database administrator, software engineer, website developer, etc.).
In my job, if I'm not writing code, I'm not making money. Call it whatever you want.
Engineer usually assumes corresponding degree from a certified school. Granted, "Software Engineer" is thrown around a bit loosely, especially considering how debatable the very existence of engineering in software is.

Programmer is more casual term, you usually don't put it on your business card. Developer sounds both solid and without any superfluous claims.

In reality of course none of it really matters.

There's a skillset that goes with that degree too.

Ignoring job titles and just talking about skillsets :

programming : taking a specification and coding it up, for example build this b-tree, web-app, whatever.

developing software : typically, this implies more participation in the design process. Developers don't just make software work, they help decide what it does.

software engineering : Writing a quick prototype for anything is easy. Writing a software system that is well tested and stands up under load requires engineering.

I would take an opportunity to disagree with your definition of software engineering. It is not easy to write a quick prototype for many, many things out there. Nor there is an accepted engineering practice following which allows us to build arbitrary, robust (in say, civil engineering sense of "robust") products.
I'm sure there are some things that are difficult to prototype, but typically you can special case the difficult parts. Regardless, if the prototype is difficult the product will be even harder.

I think there are basically accepted practices. If the software has a UI, use MVC and separate all the UI bits. Test coverage gives a good metric for product quality and everything but the UI should be well covered. Reasonable performance tests should cover multiple users, load etc.

I'm not sure what civil engineer considers robust, but I think this approach basically works.

Meh. I don't like these questions.

What's the difference between geeks and nerds?

There really is no consistency because, in my opinion, we didn't come up with these terms ourselves. It almost seems like people outside our industry or people who don't understand technology in our industry (Dilbert's bosses, for example) came up with these terms.

It's like the whole geek/nerd fiasco. People started calling others those two terms and now we're asked what they mean. The truth is that different people will like to be called different things. I for example prefer the word nerd. But, the really really correct truth is that it doesn't matter. That's the bottom line.

Sorry for the long-winded answer. But it's a pet peeve of mine when people focus on their titles more than their actions. I don't care if Zuckerberg is defined as a programmer, developer, or engineer. Because, honestly, they can't even be defined. I care a whole lot more about what he's done.

(comment deleted)
These questions have a very deep and important meaning. They also are an occasion to make an attempt at defining the qualities of our jobs. On par with naming your variables correctly, defining what are the jobs and what they mean is important.

Here in Quebec, to be an engineer, that is to bear the title, you need proper training and you need to pay your due to the corporation that legislate the profession. The reason backing that is that engineer have a legal liability into what they build. They must take responsibility for their decision.

I don't believe that programming at large as attain this level yet. Perhaps hacking at Mars Rovers for the NASA approaches or is it, but in web dev I think we are far from that.

As for programmer and developers, I'd venture the following:

A programmer is someone that implement the big picture created by someone else. That doesn't deprive her of expertise or quality, she just works at a different level than an engineer.

A developer is a loose term to qualify "working in the field". It's used in every which way to mean: "Hey, this is the far-west, one of the few knowledge work field where you can learn by yourself and reach heights which are regulated and unattainable in other knowledge fields". I definitely am a developer.

http://en.wikipedia.org/wiki/Nerd vs http://en.wikipedia.org/wiki/Geek. I'm not saying this is the only explanation - languages evolve - but it's an accepted definition and has an history.

Language exists for a reason, precise language denote precise thinking, what is not defined we should strive to define correctly.

A geek's technical obsession translates directly into commercial relevance. A nerd's does not.
For those who've gone a bit downvote-happy, this is a reference to Douglas Coupland's Microserfs which you all ought to have read...
My quick take on a similar subject:

Computer Science: Writing Code

Computer Engineering: Designing Stateful Circuits

Electrical Engineering: Designing Stateless Circuits

Computer Science != Writing Code, not by a long shot.
Be careful with "engineer", I hear it's a legally protected term in some places (but obviously not California).
In norway everyone can call themselves "engineer", but the specific titles are protected (for instance "civil engineer").
From what I've read it appears to be the same in the U.S., but there is no consistent ruling. It varies state to state as the previous person mentioned.
I think the titles represents jobs that are that similiar that it's hard to say why we are trying to differantiate them. I guess it would've been a boring and uniform industry if everyone had the same title.
Let me take the example of constructing a very difficult bridge...

Engineer designs a very elegant solution to the bridge problem keeping in mind the weather of the place, the location, the type of foundation etc... He is also supposed to be looking at society & the way the bridge is going to impact the society and be able to design a solution to carry certain number of vehicles/people across the bridge etc... He is also aware of the different types of materials purely from a design perspective...

Developer would be more like a mason who would come with enormous expertise on how to get the design implemented... He would know what kind of concrete would work with what kind of water or weather more than the engineer... The engineer would be aware of it but the developer would be able to really know the tool of the trade... Engineer would have understood it conceptually...

Programmer would be good at execution... He will know what to get done in what order so that it can be done in the least amount of time in the best possible way... In the case of a bridge, a programmer would be the project manager...

In the case of tech folks, I guess the line gets blurred as software development allows for incremental developments & testing cycles.. Imagine building a bridge in the same way of building a software shudders :)

You mention two important aspects of engineering that I think is missing from the discussion: the bridge (metaphorically speaking) between society and science and the detail of planning and problem solving to meet a large set of criteria.

I've spent about 11 years "programming" and have recently returned to school to get an engineering degree and this is what has been sticking out the most to me. We are expected to do much more than just code in our engineering projects with a lot of weight being placed on how we come up with our solution and it's broader reaching effects.

Finally, in Canada, we have a "professional engineer" designation (P.Eng). Once you have obtained an engineering degree you can spend an additional four years working under the tutelage of another P.Eng and take some more courses to get the designation. This designation sort of places the role of the engineer in the class of doctors and lawyers in the sense of having a duty to society. This, to me, is also a key separation.

(comment deleted)
I was watching the Discovery Channel this weekend about the efforts gone into plugging the Deep Horizon leak. They interviewed an oil rig engineer there who (for me) epitomized the difference between 'proper' engineering and software engineering. He said 'you have to remember, we're doing something here that we've never done before!' as if doing something that has not been done before is a grandiose, magical feat.

I'm not claiming that all software development is completely new or magically creative, god knows the despair of someone writing their 100th shopping cart or linked list. Still to me it reflected the cultural differences between 'proper' engineers who are strict and rigorous and like to stick to proven solutions and people in software who are, in general, more wild west and in favor of change for change's sake.

In "real" engineering, every project is slightly different. If they were the same, you wouldn't need an engineer. The engineer knows about many projects involving similar components, the details and the way they are put together will be different on each project.

Wholly new software projects are not as common as you seem to suggest. Genuinely new stuff gets published in journals (just like "real" engineering), not many software engineers are creating new type systems, file systems, concurrency models, etc.

Some engineering disciplines may move more slowly than others, especially those for which the cost of failure is extremely high, but it's not as radically different as you suggest.

Correct.

Also, what a lot of posters are forgetting is that software is involved in "real" engineering. The work BP is doing isn't happening by the seat of their pants; real numbers are being crunched, supplies are moving along the chain and simulations are running. It's not happening with slide rules and ledgers either: there are software applications enabling all this work they're doing.

A significant portion of physical engineering these days is delegated to software and it needs to engineered properly just like the rest of the system. If the software controlling a chlorine extraction process fails and vents toxic gas, the result is every bit as tragic as if a mechanical engineer had specified the wrong pipe material and that was the fault that released the gas.

I would like to point out that systems that control physical equipment frequently fall into the domain of electrical engineering as much as they do software.
I'm not sure what you mean by this.

I write code that directly controls physical equipment. I work specifically for the Software Development department and we are the only people who have control & responsibility for software. While the electronic aspect of the systems are controlled by our EEs, Software has complete responsibility for the code.

The stuff "real" engineers do is at the limits of what is possible for human beings as a species to do - go higher, go faster, go deeper, be stronger, last longer. That's what he means by "never been done before". He means "wasn't physically possible for anyone on the planet yesterday". Is that not magical?

And if it goes wrong, it really goes wrong, as the Deep Horizon leak illustrates. If your "novel" RoR application doesn't work, no-one cares, you tweak a line of code and try again. Big deal.

> If your "novel" RoR application doesn't work, no-one cares,

Not true if you have lots of users, just ask Twitter. Fortunately, a Twitter outage does not cause massive ecological damage.

I think comparing software development to traditional civil, mechanical or electrical engineering is flawed (apples and oranges).

When this guy claims they are doing something that has never been done before, they are taking orders-of-magnitude higher risks than any new sort of traditional software development project.

When's the last time you started a new software project thinking "gee, I wonder if this will explode into a giant fireball if my calculations are off?" No. You probably write your code, then run it, and if you see a problem you make changes and then repeat.

Does the fact that they are drilling for oil a mile below the surface of the ocean strike you as something quite magical? I'd say the entire drilling platform is an amazing engineering feat, and it likely requires a lot of wild-wild west engineering to make it a viable product.

I work on nuclear reactor monitoring software...

So, "melt into a superheated puddle of neutron-emitting slag", while not quite as dramatic as "explode into a giant fireball", is quite possible if the senior software and methods engineers at my company (and the many, many people the NRC involves in verifying and validating our code packages) collectively screw up.

Very true, but if that's the case you're probably writing some code that requires engineering (i.e. a control system or requiring an understanding of the engineering system that you're writing code for). If that's the case then you're probably wearing the hat of an engineer.
The "oil rig engineer" sounds like not a actual rig designer, but engineer in the sense of "sanitation engineer" or such.

Software development is a form of design engineering.

I think this is a mis characterization. Mechanical engineering is a much older, much more mature field than computer science/software engineering. As a field of engineering study matures, many of the solutions to possible problems become commonplace, or at least they become trivial. New problems to solve are less and less frequently actually new, but rather just novel deviations from a commonly solved type of problem. However, capping the well is a completely new type of problem. It is one that has not been solved so many times that accounting for all of the variables is easy. Think about that next time before you criticize other disciplines.
There isn't any consistency in the industry and any attempts to find some are doomed to failure.

The IEEE takes a fairly hard-line approach to the difference between "software engineers" and "software developers" or "programmers". (Here is one characteristic article: http://www.computer.org/portal/web/buildyourcareer/careerwat... ) They are one of the few groups that actually feel that way, though. I sympathize with the concept, but, in reality, our field is still so new that I think everyone is still trying to figure out what it is. I personally feel that it currently falls squarely in the "craftsman" domain, but that may change to "engineer" as our field and techniques become more refined -- but it may not. Having a brief exposure to formal methods in software development, I feel that we are a long way from the sort of rigorous analytical design that accompanies traditional engineering.

That said, we may not even need it except for in very specific domains (aircraft control, health systems, etc).

So, in answer to your question, there are bigger differences between what you do at one company to the next in the industry than there is between titles. One "software engineer" may do the same thing as a "web developer" at another company. Some companies have well defined roles, some are more jack-of-all-trades-style roles.

Software engineer is a programmer and a developer, since he applies ideas and knowledge to develop software using programming as a tool.
I think they're more or less interchangeable at that level.

One might think of an engineer as someone who designs an application / product, but offhand I cannot think of any methodologies that explicitly have someone "design" a system without building at least some of it with the exception of business owners / analysts.

On the flipside, my current job title is "programmer," yet often I am involved in fully designing AND developing the piece of the program I am currently working on - that literally covers from business rules to support, including relevant documentation.

I would consider developers to be in the same bucket as a programmer, as (in my head at least) there are far more similarities between the two than from developer to engineer.

Ideally I would expect the following assignments: Engineer: High level of expertise, designs system at a very granular / technical level for:

Developer: The person(s) who builds the specified system, but whose role is mostly overseeing the build process. Also high level of expertise, something of a managerial role, but also knowledge library for use by:

Programmer: Person(s) who build the system. Relevant documentation can be delegated to the developer possibly, depending on actual involvement.

The feedback channel would just reverse this order. Programmer -> Developer -> Engineer.

Also before anyone gets all crazy about it, this is completely off-the-cuff based on my experience in school / the industry.

I've been programming for forty-five years. I've always called myself a programmer.

"Developers" are people who build subdivisions. Anything else is pretentious.

"Engineers" are people who, if they make a mistake, other people die. Engineers need to be formally trained, and licensed. Other than X-ray machines, aircraft and space shuttle software, not a lot of programmers can make this claim.

"programmer" is good enough for most of us.

I work on aircraft software. We call our people "engineers", though no-one has a license. I'm not aware of a license we could usefully get.

However, the aircraft software industry is deeply immersed in process and layers of review. Rather than licensing our engineers, we "license" our product, through internal reviews, customer reviews, and FAA reviews.

As a side note, I believe it is illegal to call yourself an engineer in Canada unless you are licensed.
I've been programming for forty-five years.

Graybeard: much respect

I call myself a programmer. I can't control what other people call me.

In the past I've been called a consultant, developer, programmer, engineer, and architect. I'm currently called a "site reliability engineer".

Ironically the guy who sits next to me, with the same job title, is a real electrical engineer. (His engineering degree is from Cambridge..as is his PhD.) When I compare myself to him, I feel a little embarrassed to be called an "engineer" of any sort.

In the vein of GnarfGnarf's comment I want to add, the term 'egineer' omits a certain aspect of programming, namely that it is, IMHO at least, also a craft.

'Developer' and 'Egineer' work better if you use it to name a sub-field instead of a person. 'Software Egineering' points clearly to the software architecture part of building software. 'Software Development' gives a hint of the fact that building a piece of software is a process.

In the end it really doesn't matter, partly because nobody just 'develops software'. We all work in certain industries on specific problems and what we have in common is mainly the fact that we punch in the code - programming the processor.

There is no evidence to suggest that software can be engineered, therefore someone who is a "software engineer" is selling snake-oil.
If by "engineer", you mean "software engineer", then I say they are all the same. They all seem to be used interchangeably in job postings and job titles across different companies.
That is actually exactly what I was thinking.
At the risk of confusing the question more: what about "Software Architect," "Enterprise Architect," and "Business Analyst?" They are used to cover widely disparate jobs and their meaning has become mangled.
I think if you encounter any of these titles (except maybe Business Analyst?), you should run. Aren't business analysts the people who talk to the end users of enterprise software and try to extract their needs? That at least seems somewhat valid. Bla bla Architects on the other hand are the people who draw UML diagrams instead of programming.
Engineers are constrained by physics. Programmers are constrained by logic. Developers are programmers.
The dictionary definition seems to answer this clearly for me.

Engineer - A person who, given a problem and a specific set of goals and constraints, finds a technical solution to the problem that satisfies those goals within those constraints. The goals and constraints may be technical, social, or business related.

The distinction between "computer scientist" and "software engineer" is a much more interesting one, that between developer/programmer and "software engineer" (which feels like a variation of degrees).

No difference. If you did some thorough research you will notice that the responsibilities of programmers, developers and engineers are mostly the same.

It's an HR thing, really.

Let's do a connotation reduction. Programmer, Developer, and Engineer all end in -er but have a significant root word in the meaning, thus evoking similarly specific large activities with 'attached' occupations.

Programmer evokes programs. I.e., that our job basically comes down to code. In some ways this is the most humble of wordings because although true to a certain extent, it's rather like saying a writer is a word smith, or a doctor is a good health-er, etc. It leaves unexplained how such programs are written, but it somewhat correctly indicates how foresight and planning is key to creating these end products. Also, read the Alan Perlis foreword to SICP.*

Developer evokes, in my mind, real estate developers and business development developers and all that. Bridge developers. People who oversee the completion of medium to large-scale work. This evokes a certain level of experience and responsibility on their part. Granted the term is applied to anyone who has created a website, etc. But it does sort of evoke that they have completed something. They've 'developed' it. It's closely linked to 'architect' too. And probably has objectivist leanings. It also, and in my opinion even more importantly, reminds the developer that a lot of what he or she does is re-development, and even more importantly, self-development. Whereas programmer doesn't evoke how the programs are made, developer evokes that the business of writing programs is largely about how to oversee requirements, code reviews, test cases, etc, and whatever makes 'development' more efficient. That it's mostly about what you bring to the table with experience. The programming itself is just part of the implementation.

Engineer, contrary to Fred Brooks, evokes the idea that you can put 20 people on a project. Because of how this works in other fields where engineers are used. It also evokes the long history of engineering which is a very privileged association, and one we should be lucky to have. It evokes that figuring out how the programs work, in addition to doing the actual programming itself (programmer), or supervising the completion of the task (developer), is very often at the heart of what we do. It is the closest probably to the term 'hacker' (although this is debatable and most hackers would consider themselves programmers, I think, because of the generality of the term and the understated quality to it), in that it's about hacking on thought problems and ingenuity. On the other hand, it evokes the 'disciplines' in other engineering fields. But originally it gets its connotation from the fact, through hundreds of other fields' use of the term, that the engine is the heart of the train, car, system, etc.

Overlayed on top these connotations are what businesses decide for job titles. And that, quite like with postmodernism and its relativistic approach to connotations, affects things also; however it is there to serve the purposes of the business first, and other long-term qualities second.

* http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-5.html#...

I work for a company who calls the guy managing the exchange server a Software Engineer(Which I think is odd). These terms are thrown around alot today without knowing what or who they are. I think people say 'oh they are in technology they must be a Programmers, Developers, Engineers but they really don't know what they are talking about.

My degree is in Computer Engineering and I work as a Software Engineer(Which is what I call myself). I used to work for Raytheon a large defense contractor, which called everyone an Engineer, didn't matter if they had a Computer Science degree, Computer Engineering Degree, or used to be a school teacher who taught them self how to code. I would like a clear definition but like someone else said that this is such a new area that the boundaries can be very low for what it takes to enter the field.

I don't feel like you should limit calling someone an Engineer or Programmer or Developer based on degrees(Because I think the whole education system is flawed) but I would like to see some consolidation.