“You can dislike a tool without writing a mean blog post.”
– Kat Cosgrove, at the time a Staff Developer Advocate at Pulumi
Before I slung code for a living, I majored in drawing and painting at an arts magnet school. I wore a pair of jeans that I had offered to my classmates with a fistful of colored sharpies and no holds barred. The results were about what you’d expect1.
I burned out on drawing, painting, and dressing like that until very recently. The lessons from that period of my life that have most profoundly influenced my career came from the time we spent honing the craft of critique.
Art students explicitly learn to critique the work of others. Engineers don’t, and it shows.
I believe we would be not only better teammates, but also better programmers, if we paid more attention to our technical critique skills.
I’m about to discuss critiquing a piece (like code, a product, or a book). Two caveats come with that.
So let’s address those real quick.
Caveat #1: This isn’t about feedback on a person.
I did a six-part series about giving feedback to a person, so you can check that out if that’s what you’re looking for.
Or, if you’re light on time, check out the 20 minute talk version.
One of the most important lessons I want people to take away from that series is this: rather than guess, assume, or independently decide what should be important to a person to improve, ask them.
Ask them for their goals as a programmer, teammate, or leader. The number one reason well-intentioned feedback gets poorly received is that it’s about a thing that the recipient wasn’t prioritizing and therefore reads as an accusation of the recipient having the wrong priorities.
Caveat #2: This isn’t specific to pull request review.
Pull request review is a specific type of feedback with specific strictures, and so I wrote about that in its own post. Building your critique skills will help you with your pull request reviews, but this post is not specific to them. You can find my direct, step-by-step advice for reviewing pull requests right here.
The most important lesson from that piece is probably that the most helpful code review happens when the reviewer actively participates and considers themselves responsible for the success of both the code and its original author. Sound hard? That’s why there’s a whole piece about it. It’s that piece, not this piece.
Onward, to this piece.
So what constitutes a sophisticated, useful critique of a piece of work?
When we use an app, read a book, import a library, we tend to make a snap judgment about whether we “like” it.
That’s not necessarily bad, but it isn’t a basis for critique. Here’s why2: at that point, we have not yet established the answer to a really important question:
Question #1: Is this piece for me?
The number one feedback party foul I see from engineers is the assumption that everything that exists in the world is for them personally.
Friends, it ain’t.
This is why they get ignored or rebuffed after they provide what they think is a helpful critique.
Sometimes it’s because “the creator can’t take feedback” or whatever. More often, it’s because the “feedback” was “this should have been a different thing.”
But it’s not a different thing. It’s this thing. You’re not being helpful by telling a professional seafood chef “This dish is not good because I don’t like seafood.” Great—go eat someone else’s food. This food is not for you, and your opinion is totally orthogonal to the goals of a chef who specializes in seafood.
Similarly, you’re not being helpful by telling someone whose course is specifically aimed at intermediate or advanced programmers that their thing is inaccessible for beginners. Or by telling someone that their piece specifically aimed at beginners moves too slowly.
It can be super illuminating to put some real thought into who an app/book/etc is for.
Is it for working moms who don’t have time to use your favorite thing? Is it for engineering beginners? Experts? Who is the person who would like this thing the most?
Whether that person is you or not, thinking about who that person might be can help you make a more useful, grounded, nuanced critique.
Creators do not create for the people that their thing isn’t for. This sounds tautological, but it matters in the context of critique.
Question #2: Under what conditions did the creator decide to make this?
This can also be super illuminating. What gap were they trying to fill? What problem were they hoping to solve? What personal experience led them to make this?
That can help you understand their perspective—which you need, to make a nuanced critique.
This is why artists present their work for critique with an explanation. (Tangent: remember this next time you moan about chefs putting a story at the beginning of their online recipe).
No one has ever come at me for including a story in any of my informative blog posts. Ever. Maybe it’s because they’re afraid I’d put their name up in lights, but I’d like to believe it’s because they know that the contextual information is especially important in computer science.
Here’s why: mechanical engineers, unlike us, get to lean on the natural laws of physics. Computers are person-made, so in computer science, our “physics” are the perspectives of the creators of the things we consume. So it is with any person-made thing. With this information, you can better understand and talk about whether the creator accomplished their goals, based on their perspective, for their audience. This is much, much more useful for everyone involved than “I didn’t like it.”
So far we have covered two questions:
1. Who is the creator’s audience?
2. What are the creator’s goals?
Now let’s get personal.
Questions #3 and #4: Who is your audience, and what are your goals?
What are you trying to accomplish with this critique?
This sounds trivial, but in practice it can be a relatively advanced self-reflection exercise.
See, we tend to think that the audience for a critique is the creator, but that’s not always true. Take books, for example. The book is already published—critique won’t change that book. The author might already be rich and famous and not care what one reader thinks. Hell, the author might be dead! If the audience for critique is always the creator, then all critique should stop the moment the creator dies. This would render 90% of a traditional English literature curriculum obsolete. It would also obviate gripes about the C programming language, COBOL, and rake. Clearly, the engineering community doesn’t actually work this way.
Critiques have audiences beyond the creator. Maybe the audience is you. Maybe the goal is to articulate and understand what you like and want. Or maybe the audience is other readers or programmers. Maybe the goal is to help others decide whether, or how, to read a book or watch a video or use a library.
Maybe the audience for your critique is others who have also tried the piece you’re critiquing. Maybe you notice an important bias or omission and you want to warn others against taking the account at face value.
Now, just because the audience isn’t always the creator doesn’t mean it never is. With a product, or with code, your audience may well be the creator. Maybe you are their intended audience, and you want to express a need that you hope they’ll fill. Or maybe you’re genuinely trying to help them improve their thing and accomplish their goals.
It turns out that none of these audiences or goals is well-served by some kind of excoriating screed.
And you know what? I think engineers mostly know that. I think screeds happen for a few reasons.
REASON #1: Someone got themselves into a position where they depended on a product, service, or resource, and it didn’t deliver, and now the person is frustrated or upset, and instead of regulating their emotions, they’re yelling at someone.
REASON #2: Internet discourse values pithy zingers. Internet humor often depends on them. In a lot of the cruelest “critiques” I have seen, I recognize the intent to make a Clever Wisecrack™—maybe for clout, maybe just to feel good. It fails, but it’s there.
REASON #3: The fact that a creator did something, or the positive response to that creator’s thing, makes someone feel insecure, and they write a screed from their own insecurities to try to knock the creator down a peg.
Now here’s the catch: to offer good, useful, nuanced critiques, we need to be able to catch ourselves writing something for one of these three reasons.
And that’s what I mean when I say that critique requires relatively advanced self-reflection capacity.
As Kent Beck put it during a Clubhouse conversation on incentive design: “Who is this feedback about?”
We must be able to recognize when our critiques are no longer about the piece we are critiquing, and are instead about us.
Footnotes:
- If you decide to submit your clothes for collaborative decoration, I recommend having someone you trust annotate the naughty bits before anyone else can draw on those.
- One time Avdi Grimm told me he gets a dopamine hit every time I say “and here’s why,” and if I tried to tell you that knowing this doesn’t influence my predilection for the phrase I’d be lying.
If you liked this piece, you might also like:
This piece about the pitfalls of data-driven innovation
This post about engineering for edge cases, complete with space pr0n, which nerds love
This piece about how blithely naming a model ‘User’ in your code base is probably bad (there, I said it)