What are the key differences between software engineers and programmers?
-
1Joel has already asked this question This isn't an easy question to answer and I'm not sure if there is a clear answer. But I do know that Joel has already posed that question.– DenaemSep 17, 2010 at 20:49
Comments disabled on deleted / locked posts / reviews
|
10 Answers
When hiring, we look for a distinction between someone who is going to be able to help us architect our system, define processes, create technical specifications, implement advanced refactoring, etc. and someone who is going to help us complete programming tasks off a checklist. I believe you could call the former a Software Engineer and the latter a Programmer.
It's up to the company really, as I don't think there's a legal framework to enforce a denomination or another, or at least not that I am aware of and this might vary from country to country (for instance, the use of the term "engineer" is actually fairly regulated in France, but there are variants that are allowed for the "abusive" cases).
That being said the general trend goes like this:
A programmer position is usually the one of a professional hired to to produce the code of a computer program. It will imply that you know how to write code, can understand an algorithm and follow specifications. However, it usually stops there in terms of responsibility.
A developer position is usually considered a super-type of the programmer position. It encompasses the same responsibilities, plus the ability to design and architect a software component, and to write the technical documentation for it (including specifications). You are able to - at least technically - lead others (so, programmers), but not necessarily a team (there comes the fuzz...)
An engineer position would usually imply that you are a developer who has a specific type of degree, some knowledge of engineering, and is capable of designing a system (as in: a combination of software components/modules that together form a whole software entity). Basically, you see a wider picture, and you are capable of designing and explaining it and separating it into smaller modules.
However, all this is arguable, and as I said, there's no legal requirement that I am aware of in US/UK countries. That being said, in France you can only call yourself an "engineer" if you come from an engineering school (recognized by the Commission des Titres d'Ingenieurs or something like that). You cannot say that you have an "Engineer Degree", but you can say that you have a "Degree in Engineering" if you have studied a discipline that falls under the portemanteau of engineering and technologies.
It might be that some countries have a similar distinction, I just don't really know.
Back to the software engineer title... Once, one of my teacher told our class - and rightly so - that there's no such thing, as of today, as so-called "software engineering". Because engineering something (be it a building, a vehicle, a piece of hardware...) means you are capable of envisioning its design and all the phases of its production, and to predict with accuracy the resources you will need, and thus the cost of the production.
This is true of most "true" engineering disciplines. There are fluctuations, of course (the prices of the materials will vary over time, for instance), but there are very finite theoretical models (for design and planning) and empirical models (for pretty much keeping any of the former within accessible constraints) that allow you to predict the termination date of a project and its resource usage.
The major problem with software is that it is not there yet. We want to aim for software engineering, but we're not there yet, really. Because we have a very fluid and dynamic environment, very variable constraints for projects, and still a lack of maturity in retrospect in our processes. Sure we could say we get better at it (highly arguable with hard-data, though), but we've only been at it since the 60s (earlier projects were actually closer to hardware-only computers, thus closer to real engineering, ironically). Whereas we've been building motored vehicles for more than a century, vehicles in general for a few millennias, and building for even more millennias (and have been pretty damn good at it actually in some part of the world, making you feel like we're ridiculous kids playing with our new flashy software toys in comparison).
We fail to systematically predict deadlines accurately, we fail to systematically predict costs accurately, we fail to systematically identify and mitigate inherent and external risks efficiently and deterministically. The best we can manage to do is produce good enough guesstimates, and accommodate for some buffer, while trying our best to optimize the processes to reduce cycles and overhead.
But see, maybe that's what engineering is. And that's what, when someone talks about a "software engineer", they should think of and aim for.
So that seems hardly interchangeable with the simple act of programming routines, or the more advanced act of developing applications.
Still, everything is a matter of trends. Lately it's pretty common to have an horizontal dev team where everybody on the team is a Senior Software Developer (yes, capitals, because that makes us feel special, doesn't it?), without real distinction of age (fair enough, in my opinion) and not so much distinction of skills (uh-oh...) and responsibilities (now that can't be good, apart purely for PR buzz).
It's also sometimes just a force of habit and specific to an industry's culture and jargon. More positions for embedded software production use titles for software engineers. Mostly because it would probably imply that you will always have to deal to a certain extent with the hardware as well in this field, so you obviously deal with other aspects of the production and of the whole "system" you produce. Not just the bits going nuts inside it. On the other hand of the spectrum, you don't really see the term engineer being used in financial software production positions. It's either because is a mimetic evolution of this industry from one of its predecessors (say, embedded engineering find its roots in automobile engineering, for instance), or because they just want to give more or less credit/weight to a position.
And to be sure to loose everybody in the fog, you'll then find other titles mixing both (like "Software Development Engineer" or "Software Engineer in Test"!), and then other ones emphasizing even more crazy bridges with other domains (think of "Software Architect" and how "software architecture" might be a shameless theft of vocabulary). And keep them coming: Release Engineer, Change Development Manager, Build Engineer (that one goes ffaaarrrrrr out there as well). And sometimes just simply "engineer".
Hope that helped, though it's not really an answer.
Oh, and that means your new company is either trying to lure you in with a new title or that they don't really care about titles, or that you really are going to have a higher-level position. The only way of knowing is to read your job spec, talk to them and eventually give it a shot and judge for yourself. I'd hope it's the latter option and that you're happy with it (and potentially cash more in on it). ;)
-
12The book "The pragmatic programmer" also sais that software is not like engineering. While you can plan a house or a skyscraper, such as an analogy for software engineering can hardly be used. They state: Software is more like gardening. Plan the garden, plant the plants. Then see whats growing, remove weeds and plant new plants.– FalconAug 8, 2011 at 6:02
-
6"Once my teacher told our class that there's no such thing, as of today, as so-called "software engineering". Because engineering something means you are capable of envisioning its design and all the phases of its production, and to predict with accuracy the resources you will need". That was likely untrue at the moment it was written. Like architecture, we can't predict costs without knowing requirements (how much does a skyscraper cost? I won't tell you how high it must be before you start building...). But we can predict costs afterwards, given a mature software development group.– MSaltersAug 8, 2011 at 9:45
-
1@MSalters: Sure, you can turn this around: like architeture, we can't predict costs without requirements. But unlike architecture, even with well defined requirements (though ours are often more fluid because they're harder to foresee or we have a tendency to allow them to change), we cannot predict the cost. You can do this in normal engineering to a very accurate level of precision, AND we're currently more able to identify costs for extra-ordinary circumstances than in SE. We only do (fairly rough) guesstimates. We're getting better at making them, but they're still pretty much guesses.– haylemAug 8, 2011 at 23:54
-
3@haylem: That's the norm in software development. But if you've worked at a CMM level 4/5 company, you'll notice that they can predict costs, and often attach 95% confidence levels to them. They understand their software base well enough, and have good enough requirements, that roadblocks are rare. And the cost of roadblocks is lower when you've got the experience to deal with them.– MSaltersAug 9, 2011 at 7:46
-
1@pcurry: note I don't claim this to be "my taxonomy". It's just quite commonly regarded like this by recruiters and corporate payrolls, and is also how it's often regarded in CS ot IT courses. They tend to take shots at each others. So I guess I listed the view that's adopted by (so-called) Software Engineers more than by (self-described) programmers, obviously. Doesn't really matter what you call yourself, it's more what people will consider you that matters. And it only matters if you care about that sort of things. Honestly, personally I don't care to be one or the other, doesn't change me.– haylemJun 12, 2013 at 16:41
Software engineers are people who work at companies that call the people who write software for them "software engineers."
Programmers are people who work at companies that call the people who write software for them "programmers."
There are also developers, or software developers. They are people who work at companies that call the people who write software for them "developers" or "software developers," respectively.
-
26
So there is the "Software Engineer", the "Programmer", and also the "Developer", "Coder" and you can never forget the "SOA expert"
These are all marketing terms for people who cannot say something meaningful in their CV, such as their actual role (not just job-title) in previous positions.
On job ads, the difference is down to the HR person.
Bottom line: every person has his own take on "what makes a good employee-that-works-with-code", and some like to associate such and such skills with such and such titles.
What you need to do? Job ads should be descriptive about the required skills, and CVs should explain the candidate's experience details.
No differences. They are the same thing. Companies, though, may have formal job descriptions using the terms, and then there may be some company-specific meaning to the term.
answered Sep 17, 2010 at 20:47
Programming is about the code. Software engineering is about the end product.
In some jurisdictions, "Engineer" carries with it the requirement of being a professional engineer, that is having an P. Eng. desigation among one's credentials. However, in other areas there may not be such a difference as I was a "Softwere Design Engineer" working in Washington state some years ago.
That really depends on how the company defines the positions. It may be that as a software engineer you will have more design decision opportunities, whereas as a developer they would give you UML diagrams and you would write the program.
But, there is no real set definition so that based on the title will people know what you do, or how experienced you are.
When I was an architect/developer, my title was computer scientist, but I would just tell people I was a programmer, as the first two are not easily defined, but most people know what a programmer does.
If a title is important to you then accept the new one, as engineer sounds higher than a developer.
I don't think there is any "official differences", for my experience that could mean:
- Some companies uses software engineers and software developers to referring to the same thing. They just use their favorite term.
- Other uses both terms for different inside positions, but the roles vary from company to company! In some could be just a difference on the function (a soft. engineer will work on maintenance and improvement of the systems while a developer will work on the product of the company), or could be hierarchical (engineer is above developer), or even the engineer is really dependent on Q&A!
Also, are also fashion terms that changes... First the term was "programmer", then "software engineer" and now appears to be "developer"...
It's better to read the job description or to someone on the specific company
Software Engineers tend to work on systems that are very large taking many man years to develop e.g. 5 to 16 years for instance. Programmers tend to have this stereotype of just coding and nothing else. But it really depends on the organization you work and how HR are marketing the role as explained above. They are essentially the same thing. Just don't get too attached to a title because it is synonymous.