How I Give Feedback

As I become more senior, I find myself more and more reviewing “artefacts” and giving feedback, and less actually writing artefacts myself. Here is how I prefer to give feedback.

First of all, what are the artefacts that I review? It can really be anything: documentation, scientific articles, job applications, CVs, code, to name a few.

When I review I do not order changes, but rather suggest changes. It is not my code, my documentation, my CV. Rather, I let you, the author, be the ultimate authority to decide how the artefact should evolve, so that you reach your goals.

To help, I put myself in the shoes of the target audience:

• If I review code, I’m the next developer to read said code.
• If I review documentation, I’m the user.
• If I review a CV, I’m the recruiter.
• If I review a scientific article, I’m the peer reviewer or the reader.
• If I review slides, I’m the audience.

I tend to classify my suggestions according to a color system:

• Green: Super nice! I always like to also give positive feedback and encouragements.
• Yellow: I would have written it differently, but I see the value of you having written it as such. Feel free to ignore this comment.
• Orange: This feels like a smell. I suggest either changing it or explaining a bit more in details why you wrote this way.
• Red: This will make you look bad and needs to be changed.

I hope this will clarify how to interpret my feedback. Looking forward to your feedback on my feedback. 😄