Programmers write code. They may do other things (especially as seniors) but the only thing that's implied by their title is that they write code.
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.
Edited by Bearhugger, 02 June 2013 - 08:03 PM.