As I mentioned in Embedded episode 290: Rule of Thumbs, I’ve been going to a writing group to learn how to give better feedback. The writing help has been great but I’m really there to watch how people put together their criticisms and how other people accept those criticisms (or not). I’ve mentioned this to my writing group, but I don’t think they got it since they are still reading my extremely silly novel.

Every month we each send out a chapter or around ten pages. We read each other’s pages, mark them up, meet, go around the table to give our feedback, then hand over our marked pages. I tried to send nontechnical blog posts or other writing but my writing group didn’t seem to enjoy the randomness that is my life. Since they were sending me memoirs and fiction, I went that direction. Having written a silly novel ten years ago means I have very little ego at stake upon receiving criticism, enabling me to really listen to how as well as what they say.

This is important to me. I tend to be quite blunt if I’m not thinking about humans and their messy emotions. Let’s just say that I don’t like it when people cry.

I mean, I’m familiar with the ham sandwich style of critique: start with a good thing (bread), add two or three improvement points, then end with a good thing (bread). This is good and you see it from the judges on contest TV shows. If I have to give feedback right away, that is my standby method.

However, there is more to giving feedback, particularly well-reasoned feedback, not initial gut-instinct feedback. And if you don’t know the difference, well, think about it next time you want to criticize something. Instead of providing feedback, wait a day and think about what really matters for improvement, not just what you wish had been done at that moment.

This all applies to code reviews as well as writing as well as performance as well as grumping at your spouse for leaving peanut buttery knives in the sink (why not wipe the extra on the bread you put it on?).

In Embedded episode 290, our guest Phillip Johnston asked me what was the most important thing I’d learned about feedback from the writing group. On the spot, I said that I’ve learned not to comment on grammar and spelling much, not even in my marked-up pages. For one thing, other people do that. For another, it doesn’t help the writer become better, it only helps them fix what they have now.

Instead I’m looking for overarching constructive criticisms. For example, if someone uses commas when they mean semicolons, I’d rather explain the difference than note every error. In a code review, this might translate into asking “how can you test this function independently?” instead of saying “don’t use a static variable in this function.” Or for someone who uses run-on sentences, “Have you tried reading this aloud? Or having the computer read it to you?” (And yes, I have mostly switched to questions instead of declaratives. I’m ambivalent as to whether that is a good thing or not.)

I’ve been thinking about this because I got some awful feedback at the last writers group. A new person joined, and he hates my writing style. He finds it boring. Happily for me, this is not an area where I’m super vulnerable. My writing sounds like me; it sounds like how I speak. You can hear the amusement and enthusiasm. You can hear the snark. There is a lot of goodness to that; many people have trouble finding their voice. I’m happy mine is clear. Even better, I have different voices: more formal ones for more formal writings and simpler delivery for places where I think the material is complicated.

Even knowing this is an area where I am better-than-average, even when the group leader held me back after and said the feedback was bad, that I should ignore it, even though the rest of the group seems to like my writing, feedback like “your writing is monotonously structured, tedious to read, and generally boring” is like acid etching away my confidence. Even though it is from one of the only unpublished writers in the group so he has no professional credibility. Even though.

I never want to give feedback like that. I fear I might have in the past but the worst part about it (other than its inherent meanness) is that there is nothing I could really do to change my writing at that level. It is unactionable criticism.

So, I was thinking about feedback when we recorded the show. Having considered it, when Phillip asked what could be applied to code reviews, I wish I’d given a different answer. There are more important lessons on criticism that I’ve learned from my writers group.

First, even though the material is not the way I would have written it, it is not wrong. For fiction, this is easy; their story is their story. I may think their main character is overpowered so that there is no challenge he cannot face with ease, but that’s ok. I can mention it as a possible issue and go on without harping upon it. For code, if theirs compiles cleanly and works, well, it is not wrong. It may not be optimal given other constraints, but it isn’t wrong.

Second, if I don’t like how it is implemented, that doesn’t mean it is bad. There is one writer in our group who often has incomplete sentences. It drives me up the wall. It feels like stream-of-consciousness but accidental. It took me a few meetings to realize that is how she usually speaks. That is her voice. I may still believe the grammar cops will someday knock on her door but people read her work and enjoy it. When I let go of my inner copyeditor, I enjoy her writing.

With code, this isn’t so much about style. I think you should have a style guide and use it. (I think my writer friend should have a copy of MLA and use it but she never signed up for that.) As a consultant, I see many different styles. I like some and some I don’t care for but that isn’t implementation.

On the other hand, I often think my way is the best because it is the most obvious (to me). When I review someone else’s code, I forget that the way it is implemented is the most obvious way to the developer. We can talk about why it is different from what is obvious to me, but I should expect to often be wrong because the developer has put more thought and effort into solving the problems. My feedback should reflect that I may be wrong because my perspective is different. Put this way, it is much easier for me to be less blunt, less definitive in my correctness.

Someday I’m going to ask my writers group for criticism on my criticisms, but not quite yet. I still have a dozen chapters of a silly novel to work on. In the meantime, well, good job finishing this post. Have you considered getting a bit more sleep? It might make having patience easier. Either way, I’m pleased that you care about how to make things better for those around you.

***

As I was writing this, I came across Captain Awkward’s presentation about giving and receiving criticism. If you are interested in learning more about providing feedback, I highly recommend it.