First, let's start off with the definitions. A programmer is someone who programs, the same way that a writer is someone who writes. The existence of compiled, running code is all that is necessary from a programmer's perspective. A software engineer is someone who solves an engineering problem. There is a very big difference; most software engineers are programmers, but not all programmers are software engineers.
There are a number of good software engineers who just are not interested in programming. Programming for them is a means to an end. Conversely, there were a number of projects where the engineers were more than happy to write a solution, even if doing so didn't actually solve the problem. Typically, the bad engineers would look for a problem they'd already solved and then try to apply that over again.
When I first saw this in action, I was surprised. After I'd seen it for the tenth or fifteenth time I became aware of how much context is assumed from past experience, and how much that was leading people astray. The difference between a good software engineer and a bad software engineer is not a matter of programming technique or hard core geekery. A good software engineer determines the right problem to solve, and solves it using the right tools.
So how do you know that you're a good software engineer? I'd say the answer is that your clients are happy. The reason a client has hired an engineer is because they know there is a problem, but they don't know exactly where it is or how to fix it. They can guess at the problem. They may even want you to write a hack which will prevent the problem from causing too much damage. But this isn't what they really want. To coin a phrase, they "want a six inch hole in the wall, not a six inch drill." Until you know why the client wants a drill, you may end up creating another problem for another engineer to solve.
Of course, this answer is both obvious and meaningless. Strunk and White's edict to Omit Needless Words. Richard Gabriel talked about the dilemma behind this edict in his Writing Broadsides. What words are needless? What is the right problem? What is the right solution? And at what point do you know that you have the right solution for the right problem?
I think an answer to this dilemma can be found by looking at the results of the bad engineers. Most engineers get attached to problems that they have already solved, and like to work with the tools that they know. This is why in University, the lecturers like to enforce good style to the students, before any bad habits have a chance to take root. Using the tools that they have been given, most engineers will fix the same sorts of problems in the same sorts of ways.
This is a problem which is facing me personally. As I become more experienced and build up more of a store of knowledge, I can do more work in less time, with less thought. I can recognize a pattern, pull out the appropriate tool from my toolchest, fix it, and save my heavy thinking for bigger problems. This makes my life convenient, and makes me look good with minimal effort.
The problem with this approach is that it makes me a slave of my tools. If I only attack the problems that I know how to fix with my tools, eventually the tools will take over and I will stop thinking entirely. Animals like the Giant Panda have specialized in this manner -- they are so perfectly suited for their evolutionary niche that they are useless outside of it.
This would be fine if the environment were static. But it isn't. There are better solutions to problems every year, and the nature of the problems facing us change as well. By the time a perfect solution is found, the original problem may not exist.
Take, for example, the Web. In 1993, the idea of the World Wide Web was an innovation, and the idea of having a home page was cool. It was only until 1995 that people started thinking seriously about the problem of generating web content dynamically. In 1998, creating "database driven web design" became cool. These days, the technology is prevalent enough that even home pages use databases for blogging. The general problems involved in content management and creating web applications have been learned and relearned. It would seem that Web Pages Are It.
However, the Web isn't forever. More specifically, HTML isn't forever. HTML is a solution to the problem of human communication, but it's not the first and it won't be the last. It's kind of astounding how much technology and effort is involved at producing an HTTP response to a client, but at some point in time clients will evolve past the point where two-dimensional text on a page really does it any more. About the only thing you can do about this is to recognize at some point that this too shall pass.
As does all things. I had an interesting conversation with an engineer comparing software lifetimes. Mike's father was an architect who designed buildings (as opposed to software). In his lifetime, he's designed dozens of buildings, and every single one has been torn down and scrapped in less than twenty years for new development. It's a mistake to get too attached to anything, whether it be a neat piece of code, a technical approach, a programming language, or a way of thinking about the world.
In other words, good and bad engineering isn't just about the project or the client at hand. It's about flexibility in tools, willing to learn new tools and throw away old ones. In some cases, you may have to do this even if the new tools have some rough edges and don't work quite as well as the old ones. It means giving up the idea of being a tools expert, and learning to identify the threads behind the immediate problems and solutions and becoming an engineer in approach. It's about taking a step back and asking the right question.
That's what I think a good engineer is.
Edit: Read the following:
How to be a Programmer
Teach yourself programming in 10 years
Qualities of Top Notch Software Developers