My personal tips about programming

These are some ad-hoc rules of thumb about programming. I'm sure they are not true all of the time. I'd like to hear if your experiences are different - or the same.

In no particular order:

1. Keep it simple, stupid!
2. Don't add code hooks for extension unless they are going to be used in this project and there is a definite need.
3. Often getting something working quickly (call it prototyping if you like) can tell you how you should design something.
4. When on a deadline, in a large project (longer than a week) doing the unknown stuff first will allow you to re-plan if something goes wrong and it's going to take longer than you think. This can apply even when you are not on a tight deadline if you want to finish the project.
5. To avoid programmer block or programming avoidance, save something small and easy for the start of a programming session. Ideas are an easy bug fix or a simple class. It should only take a short amount of time and should get you going.
6. On any project there will be interesting sections and boring sections. If you want to complete the project then you need to do both. Have a strategy to cope.
7. For other people to use something, the end of the project involves getting a lot of non-design, non-programming stuff done. Everyone can't be a finisher and there will people who find this dull. But the project won't be done unless it's done.
8. It's difficult (impossible?) to really measure maintainability. Sometimes you need to redesign things though - a good rule is when the module has been tested three times and it still doesn't work. Looking horrid is not unmaintainable.
9. If it works then it's probably OK no matter how you dislike it. To finish a project you have to put up with a lot of non-ideal solutions. Nearly always there isn't the time to fix things that probably don't need fixing (because they work). In software success is almost always working product not 100% beautiful code.
10. Hacking up a solution might be horrid and rot your soul but long development times will kill the project. That does more damage to your soul!
11. Doing things quickly doesn't mean not trying to do things elegantly. Elegance is not complexity.
    
12. You learn in design and programming by doing. Books are always good - but without doing you will not know and understand. Don't worry about having a horrid design or having horrid code - you learn from doing that as well.
13. Learn to read others code. It's hard, perhaps harder than writing code. But you will learn a lot.
14. Debugging is the art of spotting the symptoms and estimating where the bug might be. Evidence that falsifies that conclusion is better than evidence that collaborates it - even though it causes more work. Don't discard evidence without reason.
15. Debugging teaches you something about how to design. Don't avoid it.
16. Single-stepping code can be good at understanding what you have written and learning about how to write. Don't even be shy of it.
17. There is more to debugging that using a debugger. Both skills are critical - inside the debugger and outside.
18. Sometimes it's one bug. Sometimes it's more than one.
19. If the symptoms you have can be explained by more than explanation, what you need to more evidence. Devise tests to find out which it is.
20. The longer a document is, the less likely it is to be read.
21. Good design documents are often written for yourself to clarify your thoughts, although they might be read by others who don't know the subject - including yourself at a later time.