Take time for an occasional high level look at your code

Do you ever sit down and look at your own code, or anyone else's? Code always looks so different on paper than it does in a text editor or an IDE, the desperation of copy-and-paste code, and too-busy methods with 60 or more characters of indentation becoming just that much more obvious.

Code reviews seem a little less popular in this test-happy era, but just because your code passes tests, does that mean it's well written? Horribly written, baffling code could pass its automated tests just fine... and yet be practically impossible to maintain or expand. A set of eyes on the code can keep a project on the rails.

Problem is, as Srivaths Sankaran points out:

Conducting a code review, however, can also be a costly proposition, due to the involvement (interruption) of several individuals and their loss of productivity. With the context switch and the cost to the project as a whole, code reviews can add a sizable lengthening of the project timeline. The purist may point to the benefits of identifying, diagnosing, and fixing problems early in the project lifecycle.

So when and how should you do a review? Sri's Feature Article, Code Reviews looks at the purpose and process of code reviews, and considers just how often you should do reviews and what you can hope to get out of them. Citing examples from published sources on software development and project management, this is a set of habits you might not initially be in a hurry to embrace, but that promises to improve the ultimate quality of your software.