However, to talk about the "real" answer, let me start by saying that I've been doing this for a little over 20 years now. When I first started out, my job title was "Computer Programmer".
After awhile, my title (and those of all my peers) changed to "Software Developer". After a laughably short period of time, it stretched into "Senior Software Developer".
After I'd been doing that for some years, my job title changed to "Software Architect".
After awhile, the industry decided to stop pretending that most architects do full-time architecture for a living. So my job title changed to "Staff Engineer", and then "Principal Engineer" when I started making too much money.
I don't know that the day-to-day activities of my job have actually changed all that fundamentally. I have a LOT more influence with Product Managers and executive leadership than I did in my early years, and I find myself doing more mentorship and informal leadership. But by and large, I think this industry just changes job titles every so often because: (1) it wants to stay trendy and copy whatever Google is doing, and (2) technology and H.R. play games with each other over salary bands. So I wouldn't meditate too deeply on it.
At least we're not ops or QA. It feels like those poor souls re-brand every six months, chasing after pay parity with the devs.
* the engineer can work with other developers/engineers
* the engineer writes code that is maintainable
* the engineers code has an architecture
* the engineer can find a solution to problems that don’t have a lib or stackoverflow entry
In other words:
A Developer is more likely to work on smaller codebases, most likely alone, that are comprised of known problems. If you are lucky there will be some sort of rough architecture.
An Engineer is more likely to work on larger codebases, most likely in a team, that has a core of problems that are specific to the product or a domain and need to be implemented by the Engineer. The code architecture exists to facilitate maintainability and cooperation between Engineers.
Now and then I like to use "programmer" in informal conversation, because it feels refreshingly direct, and sometimes I think we forget that whilst developers need non technical skills, the technical stuff is still the critical part!
But for hiring, etc., they're all just synonyms.
Like some others, engineer suggests someone who works in an environment that has rules and constraints while developer operates in a more unrestricted environment or on less defined problems. But then, hacker was the best title and it could NEVER be claimed, merely demonstrated.
Ideally engineer would require an engineering degree and encapsulate more engineering skills such as fault analysis, risk analysis / mitigation, requirement capture and traceability, design capture and verification, etc. Things that are done in traditional engineering capacity that is required in a regulated environment.
I keep saying we need a real engineering discipline in software and not the "arts & crafts" it currently is. A real engineer can tell you whether a steel beam will support a given load; a software developer has no clue what load her software supports.
I went to an engineering school (for computer science) and everyone faculty and students was very particular about this.
Some jurisdictions have legal requirements on calling yourself an engineer.
The correct term is software developer. Some bigcos who are a juicy enough target for NSPE or government agencies have been reached out to, which is why we see the job titles change now and then.
Nobody really cares, so long as you can do the job you claim to. If you say "software engineer" but can't do more than add jQuery plugins to a web form, they're going to politely tell you that the interview is over.
If your resume says "senior software engineer" and you apply for a job that just needs someone to add jQuery to a form, they aren't even going to call you.
So far as I'm concerned, the title only matters on your resume, and is just for getting the right kind of attention.
On a resume, "developer" is going to speak to lower and mid-level developer jobs, and "engineer" is going to be for jobs where you have to spend significant amounts of time designing systems that need to be maintained for a long time. If you think you're up for it, go ahead and use it. If you misrepresent yourself on your resume, you'll either not get the job, or you'll fail at the job when you get it, so it's up to you to get it right.
I think there is a small distinction in the act of engineering vs. developing, but we all cross that line without noticing. Software engineering is the process of finding the most efficient solution within your constraints by leaning on algorithm/datastruct fundamentals. For example, you don't look at a tool's marketing page, you look at what it's built upon, how it operates, and based on these fundamentals you understand how performance, reliability, and cost will scale. If the fundamentals are too complex, you might have to do some measuring. If you evaluate or build new tools on this basis, you engage in some software engineering. I don't think this has to be some sort of superior gate-kept thing. It's just a kind of work.
We could make a stretch and claim that there's also "fundamental analysis of maintainability", but I firmly believe[1] that maintainability is subjective. We don't call writers "story engineers", and I wouldn't call any immeasurable and subjective work "engineering".
Edit with additional thought: I think there is a perception downside to both: developer and engineer. The "developer" downside is that you're more likely to be perceived as someone who doesn't care about fundamental analysis, and you focus on getting things to work only in the conditions you're familiar with (i.e. on my machine). The "engineer" downside is that you're more likely to be perceived as someone so fixated on the measurable, that you completely ignore the taste and maintainability aspect (falling into the McNamara fallacy). If you can't measure it, it's not worthy of your time.
There are just perceptions, not reality. Naming is hard.
Do you evaluate solutions quantitatively, like "This solution will require n times more memory, and it'll run m times faster". Or "this is how many nodes we need to guarantee a typical latency of < x milliseconds assuming y active users per minute"
Or do you say "let's try this and see what happens"? The latter approach is very common in the software industry, but (thankfully) not in bridge-building or space exploration. So there ought to be terminology that distinguishes these practices from each other.
Right now my title is "Software Development Engineer" so I basically have both. My previous contracts stated "Software Developer" or "Software Engineer" in the past, and it was the same job.
If there's a difference, I've somehow missed out on learning what it is after >20 years in industry/academia and that lack of knowledge has never been a problem.
I honestly don't care about titles. I don't even know what mine is without looking it up.
Developer is someone who develops, who makes/transforms things. Software developer is someone who makes/transforms software.
Engineer is someone who studied engineering, a career. Software engineer is someone who studied the software engineering career.
So, at least in Spanish, a software engineer is someone who has a degree in software engineering, no matter what his job is. And a software developer is someone who writes code, no matter what his studies are.
Usually those terms intersect, but not necessarily. I think it's a similar different of a particular teacher vs a professional professor.
In my experience the titles are interchangeable in practice. I can see how one might make a spirited argument that there should be a meaningful difference and how that could be useful in hiring.
Taking a look at Google Trends for both terms it is interesting note seeming regional preferences: https://trends.google.com/trends/explore?date=all&q=software...
https://web.archive.org/web/20111025230504/http://www.geocit...
People may use them in different ways to make the job sound more or less impressive, but in the end none of them are well defined and in practice they more or less amount to the same thing.
I usually refer to myself as an "engineer," but "developer," in my opinion, works better with less technical folks, and is less alienating.
Programming is the act of writing programs, and is a skill like any other. Some folks are good at it; some people struggle with it; most people can do some of it if they learn and try hard enough. Programming is what creates value for 95% of the jobs in the tech industry, and if you get good at programming (and programming on a whiteboard) you'll do exceedingly well.
Computer science is the theory of computing; it is a branch of mathematics. Djikstra is famously (wrongly) attributed with saying "Computer Science is no more about computers than astronomy is about telescopes." Many (but not all) amazing computer scientists that I've worked with are terrible programmers and software engineers, but their value has been outsized. Any good programmer can integrate a Raft library into your code for consensus. The computer scientists are the ones that not only apply the correct CDRT theory to your custom-built database, but can prove that it converges consistently.
Software engineering is the practice of delivering the right software on time and on budget; good software architects think in terms of software engineering. In the 1980s, when computers were going in to _everything_, military projects were at the forefront because Reagan ensured that we were spending mad cash there. It was like the dot com boom of the 2000s; you just couldn't go wrong bidding computerized systems. Because they were new, the contracts were cost-plus, and the military-industrial complex screwed the federal government blue with cost overruns. Anything with software on it typically had budget overruns in the 500%+ range. Not wanting to be screwed blue, the Feds reached out to CMU and said "How do we stop this?" So together they built the Software Engineering Institute to put some science and best practices around delivering software. And the SEI screwed them blue, coming up with CMM and a bunch of other bad ideas, but also some good ones along the way.
When thinking about the skill sets of the teams I'm putting together, those are some primary aspects I look at, and the ontology by which I think about them. Of course, there are lots of specialties in each of them, and many people have experience and skills in several of them.
It depends who you're talking to, of course. The goal of language is to create shared understanding, so you need to have shared definitions, whatever they are. Nobody else shares my definitions, so I mostly keep them to myself if I'm not pontificating.
If you're speaking to a recruiter, you are whichever one of them pays the highest. If you're speaking to an academic, you're a computer scientist (perhaps a mediocre one). If you're telling your mom what you do, you're a software engineer because it makes her feel good.