Never Compromise
Are you a good developer? It’s not just the code you’ve checked in, it’s the code that you’ve allowed to be checked in too.
When someone sends you code for review, it is your duty to make sure it’s up to the quality bar set for your team. Compromise on this will and you will set yourself back farther in the future than the time it would take the sender to fix the code in the first place.
Be insistent. I have argued with developers more senior than I am on how a particular change should be made and the weaknesses in what they have sent out for review . This has landed me some particularly pointed emails. It's tough love. Not everyone will deal with criticism well so be prepared for a boxing match sometimes.
But let me say that the worst that can happen in a code review is the other developer forwarding your email to your manager and complaining about how you were such a jerk when it came to reviewing their code. “Chris insisted on this and that and wasted a bunch of my time. By golly, back in my day…”
Now review how this is a huge win for you: your manager has proof that you were thorough and didn’t stand down when faced with the choice to compromise quality or save time.
Most importantly, you have prevented the code base from degenerating. Bad coding is infectious: newer developers will base their code on what’s already checked in. Bad designs propagate into newer features, sloppy coding standards lead to a growing sloppy code base and quick hacks suddenly become standard practice for achieving behavior. It is ten times harder to back out a faulty coding standard that was seeded from a bad check in than it is to prevent it from being checked in in the first place.
By refusing to compromise, you will make a name for yourself as a good code reviewer. People will avoid sending you code for fear of retribution but their managers will insist that it get reviewed by you. Suddenly you’re an important person, and right out of college.
