Top 20 Programming Lessons I've Learned in 20 Years

1. Break it down. A whole project - even an ostensibly simple one - is overwhelming to contemplate and leads to defensive procrastination. Always take the time at the beginning to break the project into manageable components. Then work through the steps until complete. Be sure to review and revise the list of steps as your requirements change.

2. Your requirements will change. Accept it. Embrace it. Understand that the final product will be better if you're willing to change your mind when the facts change.

3. Obey Gall's Law. When coding a project, take the shortest path to a simple application that works, even if it's only a fractional subset of the total project requirements. Then incrementally add functionality, testing as you go, until the project is completed.

4. Document as you go. This includes both code comments and external documentation for application and/or API users. Every time you add or change a feature, update the documentation to reflect the change. Just make it a core part of your workflow. If you wait until you've finished coding to start documenting, it will end up looking forced, rushed, and incomplete. Ideally, include your documentation right in your version control.

5. Use version control. Disk space is cheap and abundant, so commit early and commit often. Make sure your commit comments reflect what you're capturing in each snapshot.

6. Backup and restore. This should be a no-brainer. You need a proper, reliable, redundancy-tested offsite backup, and you need to test regularly that you can restore from your backups. No, a RAID array is not a backup solution.

7. Leave your code in a working state at the end of every day. Don't walk out on code that won't run. It's surprisingly demoralizing to come to work the next day knowing that a broken build is waiting for you. If you have to roll back or comment out a half-finished code block, do it.

8. If you can't figure out a problem, walk away. For small to medium-sized problems, I find a good brisk walk is enough to break the logjam in my mind and see through to a solution. For big problems, I may have to pull out the big guns: a good night's sleep.

9. Fix bugs first. Don't introduce any new features while any identified bugs are still outstanding.

Thanks Hacker News! You're my smart way of receiving my technology news :-) My own knowledge is fairly narrow (at least relatively speaking), C#/.NET and Python/Django for the most part, but reading about all of the stuff going on elsewhere in the tech world at least helps me to know what I don't know.

A language is a language is a language

Perhaps I am simply not yet experienced enough, but I find which language I am working with makes a great deal of difference.

I know that some of it is personal preference and knowledge of the languages, but at the same time some of it seems to be that some languages are better suited for some tasks than others, and yes it at least looks like some languages are all around better than others.

Personally, I generally choose Python as my general purpose programming language and prefer it for most projects, and I get a lot more done in than I do in Java. I use C# for many types of projects on Windows, but I use VB.Net only if forced. If I ever decided to write an OS as an exercise I would probably start with C and if I needed to do something heavily statistical I would seriously look at learning R.

  1. Start with the answer, then work back.
  2. Name your variables so that anyone will know what they are.
  3. Name your functions so that anyone will know what they do.
  4. Never write the same line of code twice.  Use functions.
  5. Assume the user doesn't know what they want.
  6. Even if the user knows what they want, assume they can't verbalize it.
  7. The user always knows what they don't like.  Prototype often.
  8. Be prepared to dig down as many levels of detail as needed to understand.
  9. When you're stuck, turn off your computer.
  10. Don't turn your computer on until you have a specific task.
  11. Beauty is important, but delivery is more important.
  12. No variable should be fully contained within another variable.
  13. All variables should be at least 3 characters long.
  14. Use the right tool for the right job.
  15. Almost any tool can do the job.  Some are better than others.
  16. Benchmark often in order to learn what happens under the hood.
  17. Try something that's never been done.  It may be easier than you thought.
  18. Remember the patterns you've used before. You'll use them again.
  19. Keep it extremely simple at first.  Complexify as you go.
  20. Code every day.

Also it is a good idea to avoid too much software architecting from the top down. I made this mistake early on, because "divide and conquer" was how the books said it should be done. Often a more bottom up approach works better, and is more adaptable to mid-project changes in requirements.

I've seen lots of people, even experienced coders get overwhelmed when they make a change, screw up the syntax and see screens and screens full of errors show up.