The first thing is, most of us are coding as house painters rather than as Rembrandt. So it needs to do the industrial job. I tend to put as much effort into documentation and style for my personal code as for working code.
If the code is for a micro-controller in C then the emphasis might be more on raw efficiency and preciseness. A command line utility run ad hoc with low resource usage can afford to be a little less efficient and more readable. Code for an online transaction system needs the efficiency, perhaps as a tradeoff to readability but in most cases hopefully not.
I have written code and products and have had to go back to stuff I wrote 15 years ago. So I learned a long time ago to document as clearly as possible for the poor sod in the future (i.e. me) who will have to come back and make sense of everything. Mostly I succeed here but sometimes I fail.
I also supported other people's assembler code for a few years. That provides lots of what not-to-do's.
If you are coding examples for a book or website then the rules and aesthetics can be changed again. Maybe think more Rembrandt here.
Functionally, document everything, use meaningful and consistent naming conventions, catch errors, log, provide trace capabilities where needed, be as generic as possible and think about reusability but don't obsess over it (depends on the context as always).