Feedback. On the one hand, we live by it as programmers, designers, and software engineers. How can we improve if no one tells us? On the other hand, some feedback can leave us feeling devastated, often without a definite reason why it has affected us.
Critique is an especially tricky corner of communication, and it requires special care and attention to be effective.
As an author, I've been participating in professional critique groups for over 20 years. As an internship supervisor, I spend a significant amount of time reviewing code, proposals, and other work, particularly that of junior developers. In turn, I have been on the receiving end of many critiques and code reviews throughout that time, both good and bad. These are ten principles of critique I have found effective in maximizing the benefits of constructive criticism without discouraging the person behind the work.
So why bother with all this? Can't people just learn to accept critique in any form? Not really. Even the thickest skinned person still has feelings. One may eventually build up an emotional callous — although that can lead to them being brusque and insensitive in turn — but in the meantime, time and energy is always spent processing the emotional quality of communication.
There are two benefits to the constructive criticism techniques herein:
It saves developer hours otherwise wasted on debating and reiterating already established or otherwise irrelevant points.
Because the emotional weight of the critique is decreased, the author can skip right to considering and responding to feedback, instead of trying to process and rationalize around their emotional response.
So, to that aim, here are ten principles of an effective critique.
When someone takes the time to share their work, whether it be prose, code, a proposal, an idea, or whatever it may be, they are being vulnerable. Assume their work is their best effort to identify and solve a problem. Be careful of dismissing or devaluing their work in your mind because of real or perceived lack of experience. Great code can come even from junior developers, and great prose even from novice authors.
When you're going to respond to, act on, or critique something, your first step is to read it thoroughly. It is very tempting to skim — we're all busy, after all! — but this ultimately wastes time when the author has to repeat what they already wrote. Furthermore, skimming is disrespectful to the author: they put real effort into the work, so you should expect to put in the time to read and understand. If you can’t spare the time, don’t comment.
Once you've read through the work, you'll probably have already formed an opinion. That's fine, but now you should read the work again. Check your own assumptions. See how many of your questions and concerns you can answer yourself.
Before critiquing, make an effort to see the problem and solution from the author's perspective. Ask clarifying questions. Be careful that these initial inquiries are not a form of criticism! Your first few questions should be dedicated to understanding the author's way of thinking. Bonus: these initial clarifying questions will often help the author self-identify flaws in their own work, which is always an ideal outcome.
It's easy to launch into everything you disagree with about someone else's work. Resist this urge! When you're ready to give feedback, start by identifying something positive about the work you're commenting on. This is important because, as objective as we humans like to pretend we are, we are all still emotional creatures underneath. Starting with a genuine, positive comment will frame your upcoming constructive criticism as improving work, rather than invalidating it.
Challenging assumptions and decisions is a normal part of constructive criticism, but these are often most effective in the form of questions the author can answer. For example, "Is there a reason you chose to use a singleton here instead of a class attribute?" is less threatening than "Singletons are terrible, use class attributes instead."
Clearly identify to yourself what it would take for you to change your mind about the work you're critiquing. This is especially important regarding proposals and ideas. Even if you feel certain, it's always possible for you to be wrong! When a debate becomes protracted, that's a particularly good time to enumerate to the author what it would take for you to change your position; you don't have to wait for them to ask.
This one feels obvious to everyone, but it is so easy to lose sight of during a critique. Keep a check on yourself to direct all criticism towards the work, and not towards the person. This can be more subtle than it first appears. Before you submit a critical comment, re-read it to consider how you'd feel if you received that comment, especially if you were in the author's position.
If your critique goes beyond a handful of minor "nitpicks", be sure you find something else positive about the work to end your critique with. This is known as a "feedback sandwich": when the first and last comment are both positive, it bolsters the constructive nature of your criticism, and helps prevent discouragement. (If your feedback is somewhat non-linear, e.g. a code review, you can just tuck an additional positive comment amidst the others.)
Once your comments have been addressed, and the work has earned your approval (in some measure), keep an eye on the feedback others are providing on the work. Be an advocate! Having to field criticism from multiple people alone is very discouraging. Be explicit about your approval of the work. Support the author's work publicly to the scope you've approved it as they address additional feedback. Lend your own expanding understanding to the conversation. This is both encouraging to the author, and helpful to the other reviewers as they try and understand the work.
All that may feel like a lot, but with a little practice, constructive critique can become a nearly automatic habit.
Over time, these patterns build trust between individuals. It increases psychological safety, thereby inviting more participation. Feedback takes less time to process, and improvements can be made more rapidly. That's something everyone benefits from.
After all, who doesn't want their critiques taken seriously?