- Good programmers know what to write. Great ones know what to rewrite (and reuse). (#2) You often don't need to create a solution from scratch. A pretty good partial solution might be out there.
You don't understand a problem until you try to implement a solution. Don't be afraid to discard something in pursuit of a better end result.
Plan to throw one away; you will, anyhow. -Fred Brooks (#3)
Smart data structures and dumb code work better than the other way around. Brooks expressed a similar idea as "Show me your [code] and conceal your [data structures], and I shall continue to be mystified. Show me your [data structures], and I won’t usually need your [code]; it’ll be obvious." (#9)
If you design your tables or your objects well, your code will be simple.
Some of the best solutions come from rephrasing the problem, not reworking the solution. (#12)
This can be especially helpful if you've hit a wall on what to do next. Often it takes a fresh pair of eyes to help you see the assumption you need to question.
You may find that your program is doing non-essential things which are over-complicating your code.
"Perfection (in design) is achieved not when there is nothing to add, but rather when there is nothing to take away." -Antoine de Saint-Exupéry (#13)
- Any tool should be useful in the expected way. A great tool lends itself to unforeseen uses. (#15)
It's hard to design for this ahead of time, but if an unforeseen use arises you should take it as affirmation that your design was good. Assuming it's not a hacky use of your tool, of course, since that usually indicates a feature that doesn't exist but should.