The Empathy Box blog has "
5 Principles For Programming," which details six fairly popular ideas in one handy reference: fail fast, write less code (and don't repeat yourself), computer programs are for people, do the right thing, reduce state, and know your 'stuff.'
Failing fast refers to causing large, visible, impossible-to-ignore exceptions when things go wrong, to get rid of the possibility of subtle bugs persisting through various QA cycles.
Writing less code (which should be fairly obvious!) includes benefits like making the problem you're trying to solve very clear.
Computer programs being for people refers to literate programming, meaning that the consumers of code aren't compilers, but
other people:
We know that c/java/lisp/haskell have not one bit of power that isn't in simple assembly langauge–they only allow us to express the ideas more clearly and prevent certain kinds of stupid mistakes. There is no program that can be written in one that can’t be written in another, and all end up as machine instructions sooner or later (some at compile time, some at run time, but no matter). Given this fact it should be obvious that the only reason to have a programming language is to communicate to a person. Don Knuth wrote about this idea, calling it Literate Programming, and created a system called WEB which was a great idea mired in a terrible implementation. The idea was to embed the program in an essay about the program that explained how it worked.
Doing the right thing refers to actually coding a solution rather than hacking through something that apparently works.
I know the best solution but it requires changing things. In my experience every single factor in the software development process will argue for doing the wrong thing: schedules, managers, coworkers, and even, when they get involved, customers. All of these groups want things working as soon as possible, and they don’t care what is done to accomplish that. But no one can see the trade-off being made except for the programmers working on the code. And each of these hacks seems to come back like the ghost of Christmas past in the form of P0 bugs, and I end up doing the right thing then under great pressure and at higher cost then I would have done it before.
Reducing state refers to simplifying code, especially with respect to concurrency, which can have strange implications with code like x.equals(x), which can return false in some circumstances (depending, of course, on how x.equals(Object) is coded.)
Finally, "know your stuff":
Just as the workable solution is always the last thing you try, the impossibly to diagnose bug is always in the software layer you don’t understand. You have to understand all layers that directly surround your code—for most programmers this begins with the OS. If you do low level programming you better know about computer architecture too. But this idea is bigger that just catching obscure bugs, it has to do with finding the solution to hard problems. Someone who is familiar with the internals of an OS has enough of the big ideas under their belt to attack most large software problems.
Any additions to these?
