Critique the Code, Forgive the Developer

When I first began my career in tech, I had the privilege of starting a lot of projects and being the sole contributor. That meant that each and every hello world started from day one with Test Driven Development baked in; every nook and cranny involved researching best practices to ensure that it was "good code". It was easy back then to look around at other projects and think of how much better they would be if the developer(s) had just adhered to good coding practices. "Don't they realize how important it is to test your code?", "Why didn't they make this more modular?" I would scoff. I'm even guilty of having had non-constructive conversations with peers about how projects we work with are built and how "they wouldn't have all these problems if the other developers would just build it the right way."

I recently had a project where the deadline was approaching, and I was falling behind. In order to get it over the finish line, all of my holier-than-thou-it-must-have-tests-for-everything-and-be-cleanly-written-code attitude had to go on the back burner. It smacked me in the face with just how fast-paced this industry can be. We build things with good intentions to fix things up later, which almost always leads to poorly implemented components. In order for a product to get to market, often times the only way to move fast enough is to shoot from the hip and break all the rules.

Don't read me wrong - I am not advocating for being OK with bad code. Rather the opposite, you should strive to write clean, well-tested code at every chance you get, primarily because you will not always get the chance to do so.

What I am advocating for is to be more forgiving of the developer who wrote bad code you see (including your former self). They may have been up against a deadline. Maybe they lacked a clear set of criteria from which to build. Maybe they were having a terrible day aside from work. They might have not intended for the project to take off and thought that writing it quickly wouldn't cause any issues. They might have just been inexperienced at the time. They might write it differently now that they have more experience. It's possible that they had to shoehorn it in to an already messy project. Etc., etc., etc.

If you see bad code during a review, take a step back and think about how you can help the developer as a person and professionally. You might see it as bad code because of experience that they don't have and you can help guide them to write it better. If you think they're experienced enough to know better, maybe take a few minutes to ask them how their day's going. Developing a rapport with your peers is crucial so that when you are critiquing their code, they know you aren't criticizing them as a person. Then you can critique the code while forgiving the developer.

In summary, a man infinitely smarter than myself once said:

"Do not judge, and you will not be judged. Do not condemn, and you will not be condemned. Forgive, and you will be forgiven...Why do you see the speck that is in your brother's eye, but do not notice the log that is in your own eye?...first take the log out of your own eye, and then you will see clearly to take out the speck that is in your brother's eye." - Luke 6:37,41-42