Ask HN: Programmers vs. Developers vs. Engineers
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 ] threadhttp://lifehacker.com/comment/26433104/
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.
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 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.
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.
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.
Computer Science: Writing Code
Computer Engineering: Designing Stateful Circuits
Electrical Engineering: Designing Stateless Circuits
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 :)
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.
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.
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.
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 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.
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.
Not true if you have lots of users, just ask Twitter. Fortunately, a Twitter outage does not cause massive ecological damage.
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.
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.
Software development is a form of design engineering.
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.
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.
"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.
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.
Graybeard: much respect
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.
'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.
An engineer solves real world problems by using a methodology. e.g. the engineering method. http://www.eric.ed.gov/PDFS/ED276572.pdf, http://openlibrary.org/books/OL2558084M/Definition_of_the_en...
A developer specializes in product development.
A programmer writes programs, uses programming languages.
I have never seen any reason that a person cannot be any combination of these, or none.
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).
It's an HR thing, really.
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#...
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.
http://www.skorks.com/2010/03/the-difference-between-a-devel...
I agree that there isn't a standardized definition.