Code Critique

Image from the ad card from my thesis show.

Body cast in resin from my thesis show.

I graduated with a major in Fine Art in Sculpture. What can I say? I’m multi-faceted. You should ask yourself what advice I could offer coming from such a fluff study. I mean, working with clay, casting models with paper and plaster, studying line and color: these things don’t have any influence on the design and administration of databases. Right?

In my final two years, I had been placed into all graduate level courses. There were no undergraduate courses left for me to pursue: I had advanced in my theory far beyond what they could have supported, if they had existed. Being placed into those graduate courses were the best experience that I could have hoped to gain. They forced me to continue to develop and grow at an accellerated pace and opened new opportunites for me that didn’t exist for any of my other undergraduate peers. In my junior year, I was included in and won an award in a senior show. In my senior year, I had been granted a thesis show, which were reserved to graduate students alone.

While the recognition was a fantastic perk, the best part of these two years came every Monday. Mondays were critique days. For four to six hours, the graduates and I would go from studio to studio, ripping each other’s work apart. We were ruthless and nothing was sacred nor spared.

But the thing about it is that we still had to go to lunch together afterwards. We still had to share the studio space and be friends. The critiques weren’t about attacking each other. They were about deconstruction the work and understanding why you made the decisions that you made. It was filling in the meaning to the action of creating art.

The same can be said about creating code. We’ve all got our little quirks and customs when it comes to writing code. It’s like our signature: it’s something unique. But apart from likes and dislikes, good and bad practices, it comes from experience. If there were one answer for every problem, we’d all code the same all the time. A lot of technical IT-types like to make the claim that they’re not very creative, and I’d like to posit that it’s just a bit of narrow-mindedness on the definition of creativity.

Getting back to the subject, you might be able to think of code reviews as though they were art critiques. It’s just tearing the code down so that everyone can understand why it was written in that specific way. It’s nothing personal, though it certainly feels quite personal during the review. I mean, how can those peons understand why you did what you did? They don’t work with those servers on a daily basis. They don’t even know most T-SQL commands by memory!

It’s easy to take a review in the wrong way. But you have to concentrate on the fact that the critique is of the code and that it isn’t a reflection of the person who wrote it. How can the code not reflect the person who wrote it? Just moments ago you said that code was personal like a signature! As I also said earlier, it’s also based on personal experience, and as many in the SQL community have said before, no one person can know everything there is about SQL-related products.

When going throgh a code review, you have to keep that in mind. Others have different experience and knowledge that you do. Any critique of the work comes from comparing the solution to what they know from experience. It’s doesn’t make the reviewer right, and it doesn’t make you wrong, but it brings addition information to the table so that a broader solution can be considered. In the end, it can make you a better programmer, if you’re willing to open up and listen.