The Code Sucks, Not The Author

Posted on November 24, 2007 @ 17:29 agile

One of the few things I’ve learned in the last few weeks is to not be so politically correct when it comes to sifting through code. What I mean is, if you spot a piece of code that can improved, then address it.

Don’t hold back your comments because you’re worried that the author of the code will feel attacked or hurt. There’s also constructive ways of doing this, if you’re intentions are to make someone else look bad or prove that you’re a better developer then everyone else, then you’ve got some character flaws that probably need addressing.
If you spot code that smells deal with it. Explain why it smells and construct ways to improve it. You’re not helping anyone by holding back your true thoughts. The only way you and your team is going to get better is if you constantly offer each other feedback.
With constant feedback you might start to notice more more light bulbs turning on in your teams heads. It’s no use if only you can see why a certain piece of code smells, but the rest of the team needs to see it to.
Most developers try to put out the best possible code that they can. They want to deliver value, so if you spot a better way that someone can do that, show them. It’s the code that sucks, not the author.