I assume the customer doesn't know what they want, they only know what they <i>think they want</i>. It takes iterations to get things right. Get a minimum viable product in front of them, and let them use it for a bit... you'll immediately get a raft of new requirements, and this is the perfect time to ask about ideas you thought of on the way, and what they think of them. It is also the right time to say "it would be hard to do X, but if I could do X' instead, would that be ok?"<p>Iterate, iterate, iterate.<p>---<p>Get users unfamiliar with the program, have them try to do X, Y, Z... ask what they are looking for, if they get confused... work hard to get your mind into the space of someone unfamiliar with the system you've created.<p>---<p>Keep your databases as simple as possible. Don't ever have a way to put in N of something... it's either none, one, or infinitely many with a related table.<p>---<p>Always have a way to get help visible to the user.<p>---<p>In forms, don't enable the "Submit" or "OK" button until all the preconditions are set. Same with other fields. Make it impossible to submit invalid data, if at all possible.<p>---<p>Never make a user type something more than once... each time data is entered is another opportunity for error.<p>---<p>Old advice: Make sure the program can be used completely without a mouse, using only they keyboard.<p>New advice: Make sure the program can be used completely without a keyboard, using only the touchscreen.<p>---<p>If you're doing a data transfer to an external device, what happens if the connection fails in the middle of the transaction? Test it, and make it fail-safe.<p>---<p>Use GIT to keep history, and take the time to make your commit messages meaningful to yourself and others in the future. (It sure beats the heck out of a folder of versionNNN.ZIP files)<p>---<p>O(n) - If you don't know about O(n) notation, learn it and its importance. A program that works fine with a toy dataset <i>will</i> become unusable if there is an O(n^3) operation in there somewhere.<p>A few hours of optimization an testing can outperform decades of Moore's law.<p>---<p>Structured programming - Break down things into pieces as small as is <i>reasonable</i> to work with, but no smaller. Put related code into modules (units in Pascal)<p>---<p>Information Hiding - Keep your interfaces strict, don't work around them to get at the internal state of objects. Doing so will limit your future options, and is a huge source of technical debt.<p>---<p>Documentation: It should be possible to effectively use your program with only the manual, and some time and effort. If not, the program isn't done.<p>---<p>Hardware: Intermittent hardware should be treated as hazardous waste, and disposed of as quickly as possible. - Mike's law of intermittent hardware.<p><a href="http://mikewarot.blogspot.com/2007/10/mikes-law-of-intermittent-hardware.html" rel="nofollow">http://mikewarot.blogspot.com/2007/10/mikes-law-of-intermitt...</a><p>---<p>Hardware: SSD drives are a great way to speed up an older system, but don't let them get full, or they will slow down.