I've spent much of the last 23 years doing things that involved having to read and comprehend code so I could fix bugs, add features, or port it to another operating system. Here are a few things I've learned...
Write your code for the next poor soul that has to work on it.
In commercial software, unless you're writing a one-time-use throwaway program, somebody, sometime, will have to mess around in your code. If your code is hard to understand, it will make their life much harder, and their opinion of you will be much less kind than, "Wow, this guy must have been really smart to write such obscure code."
A lot of people think code should be self-documenting. I'm cool with that when it's possible, but it's not always. And I figure more information is always better than less, so I often add comments anyway. If comments save you a couple of minutes a few times a day, that can be the difference between making it home on time and having to explain to your spouse why you're staying late at the office again.
When this really hits home is when you are the poor soul having to fix some software you wrote five years before, and you can't figure out what you were doing.
Avoid cleverness. Or if you must be clever, explain it in comments.
I'm writing this while in the middle of fixing a bug in some old code where file names were getting truncated unexpectedly.
The original author could have worked with the file path strings using strcpy() and so on, and everything would have been fine. But for reasons I can only guess at - I suspect they were a misguided attempt at speeding up the code - he's doing some funkadelic stuff with pointers and remembering locations of specific characters and so on. And yes, he probably saved a few microseconds at the beginning of saving... a 27 GB file to a hard drive, which typically takes about 10-20 minutes. Any optimization he got from that cleverness has about as much practical effect on the program execution time as a pebble on the surface of Pluto perturbs the interior of your pancreas.
And, of course, it doesn't work. Actually, it works great as long as the file name is 29 characters or less. But due to the cleverness, at 30 characters, whack! Chopped off filename. Bug. And it could have easily been avoided by simply using standard C library functions.
There are times when you need to write clever code. If you find a performance bottleneck, sometimes clever code is the only way to fix it. But in that case, make sure it really works, and for heaven's sake, add some comments to explain what you did and why. The next poor soul who has to look at it will thank you.
Be human, and humble.
One of my favorite code comments ever was in the GTK+ sources. I can't find it - they may have fixed the underlying problem - but it basically ran, "This code works but it's fragile. So many people have added so many things to this and related routines that nobody really understands how it all works any more. We really ought to rewrite this someday." I think very kindly of those folks.