That's an interesting question - what defines a coder vs. a software engineer. Hadn't thought of it in those terms until now.
My personal revelation from my own growth experience is I feel software engineering is more about code development process than knowledge of design patterns/languages, etc. Of course those are important too but I think without good process you are going to have far more problems than you should with your resulting code.
A might think a coder writes code without really caring too much how they get something done as long as they get their immediate problem/feature working. They have their own way of working that they feel works for them.
A software engineer employs a large number of long standing good practices that help in creating large and complex programs that contain few bugs.
I would say for the first 15 years of my career I was more of a coder. In the last 10 years I feel I'm more of a software engineer. I evolved because people that were smarter/more experienced than me were brought in to make a concerted effort to increase code quality in our large development studio.
While there are many processes I have learned and employed to write better code, the main differences that saw me evolve were moving to test driven development and automated testing. Hackers always avoid this as they feel it is too much work and will slow down development (they are usually too busy fighting fires due to their undiscovered bugs to have "time" to make the switch).
I'm tempted to write all sorts of stuff describing this but I don't want to waste time, Google it if interested. All I can say is since adopting these practices, only maybe one or two minor bugs a year are found by my customers in the code that I write. It's not that I am super smart or write perfect code, it's just that I find all my bugs before I release my code by writing thorough tests (using code coverage tools, etc.) - and I only have to press one key to run thousands of tests across all sorts of platforms and configurations - something that is always done before code is checked into source control. It gets to the point where this becomes a safety net you cannot live without. If I need to change some existing code I don't even need to think the ramifications through much - my main question will be, does it pass my existing tests? Oh it does? Code is probably good then. To think of trying that without test scares the crap out of me now.
Now when I see other people just coding something up, running some quick manual test that covers maybe 20% of the code paths, and just "figuring the rest will work because it should because I am smart" I have to shake my head. Sadly I work on a team where the other coders still do this. They are constantly chasing bugs, and frustratingly my tests in my code area run into all sorts of their bugs in their areas (these are large complex projects), and it is unbelievably expensive to have to continually communicate the problems and schedule fixing when they could have just found the bug while writing their code so that I didn't have to waste hours dealing with something they have to fix anyway.
I think it is to the point where if I am ever interviewing for a job again, I will interview them about their coding department's software engineering processes before I accept an offer. I will refuse to work with "coders" again.
Anyway, that's just my personal view on it, maybe not some well defined definition, but that's how I feel.
