Difference between software engineer and programmer

Software engineering is a broad field that contains knowledge about programming, but also about architecture, design, testing, planning, configuration, etc... A software engineer is someone who has studied this field.

A programmer is someone who writes code. They may be a software engineer, but they might also just be a hobbiest with a programming book, or a mathematician, or a computer scientist, or an electrical engineer, etc ;)

It used to be the case that companies would hire a small number of "architects" to design programs, and then a large numbe of "programmers" to implement them. In my experience, this structure is very outdated. I've only been in one job that worked this way, and it was horrible (the senior programmers were better architects than the "architect")...

The formal education curriculums that produce "programmers" these days also include a lot of SoftEng/CompSci knowledge, so companies these days usually hire jack of all trades "programmers" that can do both their own architecting and implementing. Large-scale architectural choices are typically made by a senior programmer, rather than some dedicated architect who doesn't actually write code...

(the senior programmers were better architects than the "architect")...

when you say than the "architect" are you referring to an architect that has a background in architecture? when you say "better architects" are you referring to a software architect? So is it because their college degrees are different?

It means software architecture.

I'll try to answer it with a different direction.


There are people who generate code. That is a programmer. It doesn't necessarily take a lot of skill or talent, so it is very broad and inclusive.

There are people who generate systems. These are generally software engineers. Such a system can include code, but it also can include more complex features, such as being easily reused and extended, or being able to handle interdependencies in useful ways. For example, a software engineer might be responsible for a networking component in a single game.

There are people who build systems of systems. These are generally senior software engineers, software architects, or principle programmers. The things they build are more than a single system, they build an ecosystem of many different things going on at the same time. They are generally the leaders on the team who know how all the systems work together.

It means software architecture.

I'll try to answer it with a different direction.


There are people who generate code. That is a programmer. It doesn't necessarily take a lot of skill or talent, so it is very broad and inclusive.

There are people who generate systems. These are generally software engineers. Such a system can include code, but it also can include more complex features, such as being easily reused and extended, or being able to handle interdependencies in useful ways. For example, a software engineer might be responsible for a networking component in a single game.

There are people who build systems of systems. These are generally senior software engineers, software architects, or principle programmers. The things they build are more than a single system, they build an ecosystem of many different things going on at the same time. They are generally the leaders on the team who know how all the systems work together.

Is there a CS course or a book tailored to be able to build systems of systems? When you say things going on at the same time, are you referring to concurrency? Or is building systems largely a skill? The closest I have to building a system is for a hobby game project that has a simple health system that is scale able with the character maximum life value and a simple inventory that contained one item along with it in a arcade shooter game

The "system" isnt just the software. The system might include aspects of the environment where the software works. Say, If you have a software for managing a depot, your system might not only be the piece of software you have to develop, but also the bigger system, the entire depot, who might depend on other systems, say, administrative sector, maybe there is another piece of software for sales that needs to interact with the depot's software, or even maybe a non-software part, like the dudes who work in there and do specific tasks that the depot system has to control.

A part of Software Engineering is system's engineering and system analysis. Which deals with how to tackle these kind of things. There is also project management, like deciding on what development technique fits best with the software you have to develop, do you need a non-functional prototype working in two weeks to get the client's feedback on it? Or you can present it on a few months with some functional parts already implemented? How many people you got? Have they worked on a similar project before? If its the case, can you reuse some of that code on this project? Does the client has the hardware needed to run the software you're developing? And a big etc.

Its a big topic, and entire degrees based around it, and all of them can teach it from different perspectives.

Take a look at the answers to a similar question on Programmers StackExchange:

What are the key differences between software engineers and programmers?

http://programmers.stackexchange.com/questions/4951/what-are-the-key-differences-between-software-engineers-and-programmers

I wouldn't pay too much attention Dijistra quote :D It's an example of the quarrels that go between scientists and engineers (also engineers vs artists).

Its your typical "Well, with only fancy theory you won't build the stuff we're building!" and then "But without the "fancy theory" you wouldn't have stuff to build!" Or on more simpler terms, the "practical stuff vs theoretical stuff" debate.

Its a bunch of nonsense really. They're all high up in their clouds looking down their noses...

I remember reading a whole youtube page full of comments arguing if the Linux Kernel IS the OS or simply a part of it.

I agree with TheChubu, those two words are so related, they are almost interchangable. They add nothing to any conversation, calling a Programmer a Software Engineer makes no difference whatsoever. Better yet, the usage of the words tend to change with time and culture. In my Region for example, you tend to call Programmers with a Bachelor/Master in Computer Science a Software Engineer.

IMO there are better ways to waste your time than with irrelevant word definitions.

Is there a CS course or a book tailored to be able to build systems of systems? When you say things going on at the same time, are you referring to concurrency? Or is building systems largely a skill? The closest I have to building a system is for a hobby game project that has a simple health system that is scale able with the character maximum life value and a simple inventory that contained one item along with it in a arcade shooter game

There are some books dedicated to working with systems, but the skill is developed by many years of experience. It is also a trait, some people just happen to be really good at understanding and improving complex systems.

In a sufficiently large group of programmers, there are some who are 'go-to' people that everyone asks for help when something goes wrong. It doesn't matter if it goes wrong in networking, graphics, audio, UI, AI, resource management, concurrency, or anywhere else; people still say "Hey Bob, could you help with this?" These are the ones who tend to know how every system works and how they all work together.

The U.S. Bureau of Labor Statistics agrees with your assessment and there's about a $20K difference in median annual salary that reinforces the distinction.

Programmer Median Salary: $71,380

Software Engineer Median Salary: $90,530¹

_{1. Note: "Software engineer" redirects to "software developer."}

I worked for 11 years writing and maintaining programs, so I called myself a programmer. That doesn't mean that I was limited to implementing some detailed specification into code. I participated in every aspect of the project, which often required understanding the system from the lowest level (data alignment, reproducibility of floating-point operations...) to the highest (the interaction between large blocks of the system and how they relate to our business). The job involved networks, mathematical optimization, user interfaces, designing mechanisms to monitor the behavior of a very complex trading system, statistical analysis, automating lots and lots of tasks, troubleshooting problems at any time of the day or night (with a lot of money on the line)... The job paid extremely well, but it never felt like anything other than programming.

Software engineers design the software architecture, define the requirements, plan the testing and QA strategies, probably manage a team of programmers and might report directly to the CEO, etc. In small places, they're sometimes both programmers and software architect. They can also be responsible of implementing standards when required by their superiors. A programmer may certainly be good at all of those, but a software engineer is *required* to be good at those as part of their job. A software engineer that's a bad software architect is a bad software engineer, period, whereas a programmer that's a bad software architect can still be a very good programmer. (Maybe he's a genius with algorithms, maybe he can see potential bugs miles ahead and writes very few bugs, maybe he has a great mastery of the programming languages he uses, etc.)

As I see it, a good programmer *may* be a good software engineer, but a good software engineer *is* a good programmer. I think that those who were not programmers before being software engineers tend to cause a lot more harm than good in a project, at least from my personal experience. I had a couple of jobs and have heard a lot of stories where the software engineer came from unrelated disciplines and it never went well. Not that they weren't smart, they simply lacked real-world experience and had no idea how it would be to actually implement their designs. In one job, the designs the engineer produced were completely unrealistic and impossible to follow for programmers. A software engineer with a solid background in programming has a good idea of the kind of work she/he is giving to the programmers. Unfortunately, one year and a half of purely academic Java programming is not enough to give a software engineer a solid background in programming...

The problem with software engineering that makes it unlike most other engineering discipline is that programming software is both a craft (or an art) and a technical discipline. (Which is why we have the aberration where software is both copyrightable and patentable. But I disgress...) An engineer in other fields will design a bridge or an engine, draw the plans in AutoCAD, simulate it in something like Inventor, and then he knows exactly all the pieces it will take and has a very good idea of how it will cost to build it. Writing software is not like that, because even if you have the plans for all the systems, it's extremely hard to predict with reasonable precision how much the project will cost and how long it will take. You can't test and predict the robustness of your design until the programmers have actually written the program, and then once it's done you'll almost certainly have adjustments to do. This is the part where programming software is more like a craft or an art than a technical discipline. Of course, sometimes bridges collapse or cost 10 times more than what it was planned, but it is much more rare than a software crashing or going overbudget. (For that reason, software engineering is not recognized as a real engineering field in some states.)

Another difference between software engineers and programmers is that in some places (some Canadian provinces, for example) the "engineer" profession is protected and you can only call yourself a software engineer if you actually have a degree in an engineering discipline, so if you see a software engineering jobs in those places (big army or government jobs sometimes require software engineers) you can't take the job if you are not an engineer, even if you have a Ph. D in computer science. (Which is kind of silly because an engineer in mechanics or chemistry could theorically take it.)

When it comes to creating interactive games, I'm not sure what kind of benefit software engineers bring. I don't work for a game company, but from what I understand, games have to be released fast and on strict schedule, and the failure of entertainment software is not exactly catastrophic. (The game crashes and you lose like 5~10 minutes of entertainment. Well, suck to be you.) So I'm not sure what benefit a game company would gain by hiring a software engineer to design big software systems, implement thorough QA strategies, force meticulous testing strategies, etc. I figure that implementing something like ISO/IEEE 12207 standard on software engineering and lifecycle would probably be too much effort and constraints for a game company that wants to produce games fast. (Those standards are usually for critical systems.) But again I don't work for a game company, so if a software engineer working for a game company would like to comment this I would be very interested.

Software engineers design the software architecture, .....

The problem with software engineering that makes it unlike most other engineering discipline is that programming software is both a craft (or an art) and a technical discipline.

The problem with software engineering is that it's not engineering. Hence, these questions keep coming up. The goal posts keep moving.

If software engineers design the software architecture, then what do software architects do?

It's interesting that a lot of people make these distinctions. In a lot of companies I have worked at the terms are interchangeable.
Programmer
Software Engineer
Software Developer
Solutions Architect

All used by management to describe the same people. Maybe there are seperatly defined roles at the outset but as people progress it seems that they have to wear many hats.

In my experience people use the terms interchangeably.

I refer to myself as a software-engineer, I think my official job title is software-developer, management refer to us as "the devs" and I spend the majority of my working day programming. We have no model where "architects" come up with a technical spec that "programmers" scurry off to implement, rather we all chip in to all aspects of requirements capture, design, implementing, testing, bug-fixing and even support. We make decisions on our own or collectively, with senior members (or louder / more persuasive people) of course having more of a say.

When hiring, I/we generally only consider people with a degree in software engineering or computer science (although we have taken physics too). At my university the two were identical courses. I gather there are game-dev degrees that may or may not be worth something too.

Generally speaking, you want to get a compsci/softeng degree under your belt. Whether you fancy yourself more of an architect or programmer, the barrier to entry is a decent university degree. After that your professional experience will pave the way (which does mean you can be successful without a degree if you manage to break in somehow and build up that experience).

Generally speaking, you want to get a compsci/softeng degree under your belt. Whether you fancy yourself more of an architect or programmer, the barrier to entry is a decent university degree. After that your professional experience will pave the way (which does mean you can be successful without a degree if you manage to break in somehow and build up that experience).

Still working towards a computer science degree. In terms of a portfolio to show for, I have written a simple arcade shooter game working with several features(animations,health system and inventory system). It took me a little over 4 months from not knowing anything about how to make it to completing the ideas I had in my mind. I did have 2 years of experience of programming in Visual Basic, Java(graphics & GUI) and really basic parts of C++ which helped throughout the process. And this community guide me pretty well. Hope this portfolio makes me stand out.

Job title inflation, imo.

http://www.bbc.co.uk/news/magazine-18983009

It's like calling a toilet cleaner a 'sanitation engineer'.

Software engineering is a broad field that contains knowledge about programming, but also about architecture, design, testing, planning, configuration, etc... A software engineer is someone who has studied this field.

A programmer is someone who writes code. They may be a software engineer, but they might also just be a hobbiest with a programming book, or a mathematician, or a computer scientist, or an electrical engineer, etc ;)

It used to be the case that companies would hire a small number of "architects" to design programs, and then a large numbe of "programmers" to implement them. In my experience, this structure is very outdated. I've only been in one job that worked this way, and it was horrible (the senior programmers were better architects than the "architect")...

The formal education curriculums that produce "programmers" these days also include a lot of SoftEng/CompSci knowledge, so companies these days usually hire jack of all trades "programmers" that can do both their own architecting and implementing. Large-scale architectural choices are typically made by a senior programmer, rather than some dedicated architect who doesn't actually write code...

This, I tend to frown up those so called architects who doesn't have a clue on how to materialize the envisioned into a real, usable system. A system architect should not (IMO) be a job title, but a role that a software engineer (usually the most senior) embraces.

I don't think there's really even a de facto standard for the kind of distinction you're looking for. It all comes down to what you know and what people will pay you to do.

A degree doesn't even help make the distinction. A degree is really just a title that a group of people have decided fits what you've studied. For example, before the Wright brothers, there was no such field as aerospace engineering. All of the relevant study was a subset of mechanical engineering. As the discipline grew, some universities created a specific study path and handed out degrees with "aerospace engineering" on it. If you studied the same courses at a university without an aerospace program, you won't get an aerospace degree even though it doesn't mean you know any less than an "aerospace" engineer. Since people get hung up on titles, companies began posting jobs with "aerospace engineer" in the title because they need people with that subset of knowledge to do some work, but that doesn't mean you need a degree in aerospace to do it. Typically, "aerospace engineers" get paid about $10k/yr more than "mechanical engineers", but that's really a function of what companies will pay based on the generally accepted set of knowledge that falls into those categories. I know engineers with a mechanical engineering degree that do aerospace work and they get paid more than engineers with an aerospace degree because of their knowledge base.

I don't think software is different in that regard. I've built some websites before, but I wouldn't call myself a web designer or developer (and neither did the companies I worked for). Someone who can architect large software systems can get hired as a programmer, and you can call them a programmer, but that's not necessarily all they do or can do. Vice versa, you can call someone who only knows how to code a software engineer, but that doesn't mean they can construct a workable or maintainable software system. As well, a company might refer to everyone who works on the software a "software developer", even if each person's tasks are really more specialized than just "developing the software".

In my opinion, the title thing is really just what you call yourself. Just make sure you are what you're telling everyone else you are.