5 October 2017
Code Reviews and Art Critiques
As I’ve progressed in my software development career, I’ve come to really appreciate working with good designers. I’ve been fortunate enough to work several places where developers and designers co-exist in this wonderful utopia of productivity, creativity, and mutual respect. I love that I can code something to solve the problem at hand and that a designer will make it so much better than I could have anticipated.
The other thing that I’ve learned is that the activities of programming work and activities of design work - at least in regards to web applications - are very similar. As programmers, we are tasked with solving the problem of getting a computer to do this thing that improves a person’s life. Web designers need to solve the problem of getting the user’s experience of “that thing” to improve a person’s life.
Both programming and designing are creative activities. Read that last sentence again. Both activities are creative in nature. I think for most people, design is intuitively creative, but it usually takes some talking to convince someone that programming is also a creative process. Programming is the process of creating (software). That software can be built in many different ways (mediums). The problem being solved can be solved in many different ways and programmers at various stages of their career (time spent practicing their art) have different ways of interpreting the problem (and solution).
Given that programming and design are both creative activities, I think that as programmers, we can learn a lot from traditional art education, especially when applying the practice of art critique to code reviews. Learning effective critique, both giving and receiving, are crucial components of an art education. I would love to see the same in software development education. However, for those of us no longer in school, we can still learn and apply some of the same concepts used in art critiques to our code reviews.
Anatomy of Art Critique
While reading up on art critiques (and chatting with the Gaslight designers), I’ve learned there are several components or stages of a critique: description, analysis, interpretation, and evaluation. Without going too in-depth with each of these, I just wanted to highlight a few things that I believe are important as we apply these stages to code reviews.
The description phase is pretty self-explanatory. Describe the work, who did it, with what tools, and more importantly, describe the work with words applicable to that practice while avoiding any “value words” or judging. For a piece of art, describe the composition, the palette, and the particular use of a cross-hatching technique to provide texture. Avoid saying that it’s “wrong” or “ugly”.
During analysis, the goal is to describe how the various components of the artwork contribute to the entire composition. How does a particular brush stroke pattern or particular colors contribute to the overall piece?
With the next step of interpretation, it’s all about how the work makes you feel or if it makes you react a certain way. Does it remind you of anything? How would you describe, in words, your reaction? Does it relate to anything else you’ve seen?
Finally, during the evaluation stage, it’s your chance to express your opinion. Does the artwork express what the artist was hoping to express? Did the artist apply the tools and techniques well? Do you see any opportunities for the artist to challenge themselves and improve?
Applying Art Critique to Code
All of the above stages of critique can be applied to code reviews. And, they can be applied in a way that DOES NOT involve telling someone that their work sucks. During the process both the critiquers and the person who did the work can learn a ton, but only if everyone feels safe with the situation.
Describe the work WITHOUT USING VALUE WORDS! What is the purpose of the code? What best practices does it use? Does the formatting of the source code adhere to an agreed-upon style guide?
Analyze the code to ensure that it does what it’s supposed to do. Are all the necessary components there? Does it satisfy all those edge cases that may be out there?
While interpreting the overall code under examination, does it feel like the right solution? The term “code smell” is frequently used - do you detect any? Are there any patterns in use or that could be applied?
During evaluation, express your opinion about the code itself and not about the person who wrote it. If there is a better way, in your opinion, to have completed the work, please communicate that. Are there ways to apply additional best practices that your team uses?
Next Steps
If you’d like to improve your code reviews and you work with designers, I would highly encourage you to sit with them when (and if) they do critiques of each other’s work. I strongly believe that their critique experience can be directly applied to code reviews and it would be silly not to take advantage of this expertise.
