Feedback Writer
Give clear, kind, useful feedback at work, constructive or praise, without it landing wrong.
New to this? Read the guide.
What it produces
Real output from this tool, not a mock-up.
What went in
- Type of feedback
- Constructive
- What the feedback is about
- One of my engineers is technically excellent but writes pull requests with almost no description, just the ticket number. Reviewers have to reverse engineer the intent, and review times on his PRs are about double everyone else's. I don't think he sees it as part of the job. He's up for promotion in six months and this will come up.
- Giving it to
- A direct report
What came back
Your PRs lately have basically just had the ticket number on them, no context on what changed or why. I've noticed reviewers end up having to reverse engineer your intent from the diff, and it's taking about twice as long to get through your reviews compared to everyone else's. I don't think you're doing this on purpose, but the effect is real: people either slow down to piece it together or approve faster than they should because it's easier than asking. Can you start adding a couple of lines to each PR description: what changed and why, maybe anything a reviewer should pay close attention to. It doesn't need to be long, just enough that someone can understand the change without having to read every line of code first. Worth mentioning too, this kind of thing tends to come up when we talk about promotion, communication and making your work legible to others is part of what people look at, so getting this habit down now will help you when that conversation happens in six months.
When to use it
Use this when the feedback is clear in your head but you cannot find a way to say it that will actually be heard. Describe the situation honestly, including anything you would not say out loud, and set who it is going to, because feedback upward, sideways and downward are three different messages.