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.
My personal take on the difference between what these terms stand for is that the software engineer has a significantly bigger toolbox to draw upon than the coder. For the software engineer, the toolbox contains such things as process, a common language (terminology), and a big collection of methods which have been tried and tested.
None of this is the exclusive domain of the software engineer, the coder can use these tools, too. The thing is, if you practice software development professionally and enjoyed a professional education, you acquire this toolbox and it becomes part of your daily work. The coder has to work harder on acquiring it, and chances are that he won't be exposed to tools which a software engineer winds up finding in his toolbox as part of his education that at the time when they show don't seem to matter much. Only lateron some of their value may become apparent, and then it's often of crucial importance. A coder may not see the immediate value and discard that tool.
This sounds pretty abstract, so I'd like to give an example of such a tool that might show up one day and prove its value lateron: software configuration management (SCM), using tools such as SCCS, RCS, CVS, SVN, git, you name it. One can make backups of the source code as one maintains and modifies it, and that may be sufficient if the code base is small and the changes are sufficiently small as to be manageable. But one might cross the threshold when this is no longer the case, and if one hasn't picked up the habit of using an SCM, one may not realize how much work and effort it saves in the long run.
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.
Somebody might argue that a coder can accomplish the same thing through grit and determination alone
The big difference here may be in that you learn to use tools to do the work for you which the coder still has to do all by himself, using his brains alone. If a task can be performed through automation, it is reasonable to assume that it can be done more quickly in this form than a human could, and it's probably quite boring to begin with. It will save you time and effort which you can spend elsewhere. Instead of combing your code for problems, testing it one problem fix at a time, you can focus on different and more complex aspects of the software.
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 know all too well to what you refer to
What always gets me is how programmers can be so confident and effective in making their lives not just harder, but really miserable by working without the assistance of simple tools which others use regularly.
You certainly can create code with a simple text editor, without using an SCM, test the code manually without even using a debugger, crank out code which makes testing hard, makes the code hard to read, etc. but it's not going to make you happier or make it easier to collaborate with your collleagues. You'll probably just end up spreading the misery.
Yet this is par for the course for many programmers you are going to meet. It's not just that they work like they do, by rejecting just about every tool you have been using to great effect in the past 20 years, they tend to insist that you have to work like them because they find it difficult to understand why anybody would even bother using different tools and methods than they do. Things tend to get difficult at this point
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.
This sounds painfully familiar
My personal impression is that if you are going to have a life and a job writing code, then you'd better make writing the code a task which does not impinge on your life. That means having a plan for dealing with the task at hand (a process) and a big enough tool box to draw upon when facing the unexpected. If you are going to slip and fall, you ought to be able to stand up and try again.
