What is Elegant Code to me?

This question keeps popping up around here (“around here” being the loose conglomeration that makes up the Elegant Code group).  It isn’t easy to describe.  And really, the notion of what constitutes elegance in code changes over time.  There is no static “this is good code” test, and I doubt there ever will be.  Plus, what makes good code in one language, may not apply to the next.

So let me state for the record: today’s elegant code is tomorrow’s drivel.  Don’t feel bad, many writers have the same problems.  What was super amazing back in the day is now rubbish or near unreadable.  I am thinking of the Victorian writing that Hemingway usurped, and now Hemingway himself is almost unreadable (to me anyway).  Tastes change with the times.  That is a simple fact.

So what can you do about this?  As I say that old writing sucks to read (read Washington Irvine lately?), great works of literature still abound (for instance, Hemingway is still a great writer — even if I prefer Tolkien) .  So take some notes from them, and from other crafts in looking for the answer.  If you want a cliff notes version of what this is going to tell you, it is this: you must always push yourself to get better.

1. Find a good teacher.  Nothing is better than sitting at the feet of a master who can nudge you along in the right direction.  While early mistakes can often be corrected easily with a little bit of guidance, after they have had some time to fester all bets are off.  I believe a fare number of “Anit-patterns” were created by self taught developers (find SQL Ejaculation on this site). 
2. Read.   Good writer are first good readers.  Start with Code Complete, move into a good Patterns book, get MSDN Magazine, find some bloggers your like, but keep moving.  You will NEVER be done reading.  I imagine that even Martin Fowler has a “to read” booklist a mile long.
3. Read code.   There are a plethora of open source project just waiting to be read — do so.  This is the single best way to expand your coding repertoire, find things your language can do that you didn’t even know about..   Scott Hanselman has recently popularized this idea, and I thank him for it.
4. Practice.  This means writing small applications at home.  You get an idea that you want to try out — do it.  I don’t mean you have to write finished applications, just have some exploring time.  I remember talking with an 80 year old master woodworker (he lives down the street from me), who was telling me how many time he would practice making dovetail joints before he felt competent.  It was years worth.
5. Pay Attention.  Being good at anything really amounts to that.  And don’t just pay attention when reading, writing, or talking about code.  Inspiration come from everywhere, any good artist will tell you that.  Pay attention when you cook, when you work on the car, when you are wood working, playing an instrument, whatever it is that you do.  This will help you in the end, event if it is just learning the amount of dedication it really takes to become good at something.
6. Beware of preferences.  Any time I hear someone start a statement with “I prefer code to …” you know things are going downhill.  If you find someone who cares more about how your code is formatted then how it is written you have found yourself in a mess.  More importantly, beware of them in yourself.   Having code style standard is important, but it isn’t worth loosing sleep over.  This also pertains to inheritance, patterns, use of particular classes (e.g. always using the generic list class in C# when a Dictionary would be better). 
7. No Sacred Cows. Believe no single source of information.  This means not thinking that Microsoft, Sun, IBM, Richard Stallman, or anyone else will have all of the correct answers.  Apply the scientific method and do some research, experiment, and question the authority.   There should be no sacred cows in programming.
8. Talk with others.  Join a user group, show up every now and then, heckle the presenter, and -maybe- speak.  You want a broad range of people who you can talk to and bounce ideas off of.  This will help you from becoming that crazy guy in the corner who vehemently states that all your code should be in one file.  Having a mentor (mentioned earlier) is great, but having people around to push you from multiple directions is also good.
9. Learn languages.  This gets back to the “read code” idea. Make that multiple types of languages as well.  If you know C# or Java and SQL, learn Python or Ruby, get really good at JavaScript.  If you want something really out there, learn MDX.  This is also a repertoire thing.  Seeing how other languages work will make you rethink your ideas about what your current code, in whatever languages you are working in, should look like.
10. Keep Thinking!!!  That is possibly the most important point.  Keep thinking.  Don’t just evaluate something once and never return, go back and reevaluate. Did the technique work?  How could it have been better?   The idea is continual improvement.
11. Switch jobs every now and then.  When I announced I was leaving my first programming job out of college, the VP of R&D had me sit down with him and talk.  He wasn’t trying to keep me (he knew I was moving to be closer to family), he wanted to give me some advice.  He told me to change jobs every three years.  After you have been with a place for three years you have probably learned everything you are going to learn and it time to move on.  This doesn’t mean changing companies either.  I’ve been with the same company now for four years, but I’ve had three different jobs.  If you have been writing commercial applications, become a consultant – or vise-versa, become a test engineer, expand your boundaries.  Again, this is about pushing yourself to be better.
12. Have a Hobby. But don’t ask about me, I have too many.   Creating software is about creating things.  So I suggest picking a hobby that involves creating something.  Popular hobbies amongst programmers I know include: cooking, music, woodworking, beer making, and BBQ (which is different than cooking).  But don’t discount sports (golf is always popular), computer games, and board games.  Anything that promotes the development of skill levels can’t be a bad thing.

And I’m stopping there.  This is my beginner’s guide to how to become the writer elegant code.  If you have others you think I missed, add them too the comments.