NOTE DOWN ALL BUGS
Always note down anything that happens that needs to be fixed - because in early stages you'll encounter many more bugs than you can fix, many of them minor.
You can't solve them all on the spot - so make sure to note them down, however minor or you'll forget. Then gradually work through the list, still adding notes about any new bugs you find as you fix the old ones. And document what you did for all the fixes unless really minor, either in the code or in an external log file as appropriate.
EASY WAY TO SAVE ALL CURRENT SETTINGS SO BUGS CAN BE REPRODUCED
Make sure my programs have an option to save all current settings as a .ini file or project even if end user rarely needs this, same as when you exit and restart the program.
- then when testing if I encounter anything anomalous I immediately save it as a project, called "bug ...." whatever it is that went wrong.
I know that there are more sophisticated commercial ways of doing it - but this does fine also - at least for the bugs I've encountered, nearly all can be reproduced so long as you can reproduce the program settings for them.
FREQUENT FULL BACKUPS OF ALL THE CODE
Keeping multiple backups of all my code - and doing a full backup of everything every day or two or whenever I have done a significant amount of editing - makes it much easier to roll back to a known previous good configuration of the code and do diffs.
I tired SVN - but it didn't work for me - the methods I use already were a little simpler, but for many SVN would be a solution but if you do again make sure you have key points each day or every few days where everything was working fine to roll back to.
GET YOUR HANDS DIRTY IF YOU HAVE AN IDEA FOR A CHANGE OF ARCHITECTURE
Not to be scared of changing entire architecture of the program - to try it out. Do a backup first, try out your idea for a new architecture for a day or two - and if it doesn't work out ,just roll back again. I've done that often and you learn a lot more from getting your hands dirty trying out to see what happens if you change the code than just thinking about it.
POSTPONE THAT COOL NEW FEATURE AND WORK ON ROUTINE STUFF AS THE IDEA MATURES, ACCUMULATE OTHER RELATED WISHES
But - the other way around - as others say here, give yourself plenty of time to just think things over.
If you want to code something or your users ask you to code it - unless it is really easy and obvious - rather than dive in right away - I add it to a wish list. Then may accumulate several closely related wishes before I start coding it - that way - you have a more multi-dimensional idea of what you want to code, and less likely to need to rewrite the whole thing to accomodate some new desired feature - and often find you can program several wishes at once.
So - if you've got the choice of routine stuff or programming some cool new feature, is a great tendency to go for the exciting new feature. But - can sometimes be an idea to just write down the idea for it, and think over it, and accumulate new ideas for cool new features - while you continue to work on the routine stuff and debugging - and then do it when your ideas for it are a bit more mature.
Lots of other things - especially - listening to users, and paying attention to accessibility at all stages of the process - but thought those might be good to share.
See also: Robert Walker's answer to How do top programmers work, e.g., Fabrice Bellard?
About the Author
Robert Walker
Writer of articles on Mars and Space issues - Software Developer of Tune Smithy, Bounce Metronome etc.Studied at Wolfson College, Oxford
Lives in Isle of Mull
4.8m answer views110.4k this month
Top Writer2017, 2016, and 2015
Published WriterHuffPost, Slate, and 4 moreHuffPost, Slate, Forbes, Newsweek, Business Insider, and Science 2.0