Check for undocumented assumptions about input and output.
Every point of interaction with an external system is a potential point of data integrity violation.
Refactoring code can be an excellent way to resolve issues. Code should evolve over time.
If there are pieces of code that are not clear, make them more clear.
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
C.A.R. Hoare
It helps to have a second set of eyes examine code. What takes hours for one to see may be observed by another in moments, even if the two have similar levels of skill.
Check for interactions involving dates and times. Operations involving time involve more factors and have greater potential for error than almost any other interactions one can implement.
Make sure that adequate mechanisms are in place for gracefully handling errors.
Test coverage is helpful, but it does not guarantee that code will work as expected in real world scenarios; user interactions and external factors can greatly influence application performance.
Clarity and simplicity are central considerations in code quality.
Are you reinventing things that should not be reinvented? Ruby gems (for example) can provide significant functionality for free that would otherwise require significant development effort.
Deliberately try to break your application. If you test and do not find issues, first assume that there must be something wrong with your testing. The goal of testing is to find bugs, and bugs there will almost certainly be.
If you are a nontechnical founder, become technical. Especially if you’re bootstrapped. Otherwise you will be unable to evaluate the merit of technical decisions.
Programmers who have moved into the realm of understanding always suspect their own work first because they know that they cause 95 percent of errors. Understand the role of each line of code and why it’s needed. Nothing is ever right just because it seems to work. If you don’t know why it works, it probably doesn’t—you just don’t know it yet.
Bottom line: A working routine isn’t enough. If you don’t know why it works, study it, discuss it, and experiment with alternative designs until you do.
Steve McConnell in Code Complete
Compiling before you’re sure your program works is often a symptom of the hacker mindset. If you’re not caught in the hacking-and-compiling cycle, compile when you feel it’s appropriate. But be conscious of the tug most people feel toward “hacking, compiling, and fixing” their way to a working program.
Steve McConnell in Code Complete
The vicious cycle of hacking and (in the case of web development) refreshing is highly tempting, but it does not foster development excellence.
The best way to prepare for future work is not to design extra layers of base classes that “might be needed someday;” it’s to make current work as clear, straightforward, and simple as possible. That means not creating any more inheritance than is absolutely necessary.
Steve McConnell in Code Complete
Code is read far more times than it's written, even during initial development. Favoring a technique that speeds write-time convenience at the expense of read-time convenience is a false economy.
Steve McConnell in Code Complete
I must heed this prudent counsel more frequently.