– Gather all the requirements from clients up front. Schorr recommends thinking of these in terms of “stories” as “it’s more in line with how the non-developer thinks.”
– Clarify what is necessary and what’s just “nice-to-have.”
– Refuse to reproduce lousy code. In other words, turn down work if you’re going to be asked to reproduce a poorly designed system – unless you are being given the freedom to do it right. (This begs the question, of course: How do you define “lousy code”?)
– Reject unrealistic timelines
– Out-engineer user-error as much as possible. “In other words,” writes Schorr, “never trust that the user will do what you expect, especially when entering data.”
– Be open to including other languages and technologies where appropriate.
– Don’t reinvent the wheel.
– Review your code for speed, stability, security, and usability.
– Have non-technical people do real-world testing on your product.
– Revisit old code periodically and see what you would’ve done differently.