These lessons are pretty basic, but they have served me well over the years. When I find myself getting lost in a project, it helps to go back to the basics and get some perspective.<p>1. <i>Break it down.</i> 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.<p>2. <i>Your requirements will change.</i> Accept it. Embrace it. Understand that the final product will be better if you're willing to change your mind when the facts change.<p>3. <i>Obey Gall's Law.</i> 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.<p>4. <i>Document as you go.</i> 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.<p>5. <i>Use version control.</i> 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.<p>6. <i>Backup and restore.</i> 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.<p>7. <i>Leave your code in a working state at the end of every day.</i> 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.<p>8. <i>If you can't figure out a problem, walk away.</i> 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.<p>9. <i>Fix bugs first.</i> Don't introduce any new features while any identified bugs are still outstanding.