Code reviews are an essential part of software development. To be good at the craft, we should be able to review the craftsmanship of others. The more you read, the better you write; the more code you review, the better you code.
In this post, I’ll be sharing a 12-item code review checklist. This is a breadth-first traversal, not depth; each item is presented at an extremely high-level and deserves more of your attention.
If you’ve ever hit the tables in Vegas, you’re no stranger to the infamous mathematics surrounding house edge. What is this phenomenon? House edge is a built-in advantage, designed into every game, that guarantees the casinos make their money. This edge can be very small, 1% or less, yet it pays for opulent hotels and endless rows of lobster buffet. As the saying goes, the house always wins.
Any developer, with any level of experience, has the potential to be what I call “dangerous.” This is the accidentally negligent junior who can’t grok the ripple effect of his or her changes. It could just as easily be the senior engineer rampaging through the codebase with re-writes.
Before diving further into this topic, a manager’s perspective must be given. It’s unfair to assign blame directly to an individual. In the rare case where an individual’s presence at an organization becomes a disservice to the business, then that person needs to go. Bad apples aside, we should always remember that responsibility is bubbled up through management. It’s not your fault if your broken code gets through to production. Incidents in production are your team’s fault, your boss’s fault, and ultimately, the company’s fault—so actually, no one’s fault. At a company, success and failure are never attributable to any one individual; success and failure are attributable to teams. It’s important to remember this.
Anyway, let’s go over these bad habits. Here are my top 10 bad software developer habits. We’ve all been guilty of these.