Re:Define good code (Score 1)

All this hand waving is completely worthless until you concretely define what "good code" is. Most people just assume that if it has no horrible hacks, is formatted ok, and has some documentation, then it is good code.

This is a very good point. Here's my opinion, for what it's worth. "Good" code depends a lot on the following:

1. Knowing who the customer is
Much code that ends up labeled as "bad" tends to have been written almost in a vacuum, without the real involvement of the people who end up using the system.

2. Defining what is being asked to be built
I think it is simplistic to assume that the key to programming is either technical skill or people skills But I think the saying "there is no silver bullet" is quite approrpiate in this context. It's nice if you happen to be mystically talented to the point of mind-reading in determining what users will need in a system, but for normal people it is more likely that better code will come only when the requirements for the project are better defined, which may take several rounds of going back and asking for clarification on things -- even things that may seem obvious to you. Sometimes, though, you will need to be sensitive to what the management is leaning toward in terms of whose requests (and what technologies or methodologies) are higher priority, i.e., how you should be spending your time, and hopefully you can be asked to work on those projects more often.

3. Skill at modeling or abstracting
This may be considered a kind of technical skill, but in I think it is somewhat independent. People of all walks of life have the ability to distill things down to the important central core. I think this is indispensable in software development, especially the ability to do it quickly. There is just too much written information in the IT world to expect to read all the right books in order to learn everything. Don't get me wrong, there is a lot of reading involved, but you also have to be good at thinking on your feet.

4. Experience helps a lot
Being in the position to work on smaller projects, with a mentor, seems to me the ideal starting point, particularly if one can get into good habits quickly and learn a little about why they are good. Failing that, you have to make the best of what you learn, including trial and error. Again, the books have some of the information but they can't give you every answer. For better or worse, software development is the hardest of all worlds -- it demands high technical skills, high creative skills, high people skills, and high political skills. But it can help to learn as much as you can from each problem or project, and record what you learned so you can refer back to it later.