I wrote a short post about feedback five years ago. I was a new developer then, coming out of architecture and design, and I was mostly on the receiving end of it. The main point still holds: no one gets it right on the first pass, and the people around you are the fastest way to find out where you’re wrong.
What I’d change is the timing.
Photo by Annie Spratt on Unsplash
Back then I thought of feedback as something that arrives after the work. You build the thing, you show the thing, someone tells you what’s off, you fix it. That framing makes feedback expensive. By the time you’ve built it, you’re attached to it, and every note feels like a rejection of the effort rather than a comment on the result.
The discomfort is real, and it isn’t a character flaw. Hearing that you were wrong is genuinely unpleasant, so the instinct is to explain the decision instead of examining it. I still catch myself doing it. The difference now is that I notice it happening and let the other person finish.
Doing both design and development changed how I use feedback. I’m asking earlier and asking smaller. A rough wireframe, a half-built component, a flow with three screens and no styling. At that stage nobody is grading me, so a note like “this step doesn’t make sense” costs an afternoon instead of a sprint. Showing unfinished work still feels uncomfortable. It’s just cheaper than being right in private.
I’ve also changed how I ask. “What do you think?” gets politeness. Specific questions get answers:
- Is this the step where you’d expect to enter your information?
- What would you click first here?
- Would this label mean anything to you if you’d never seen this tool before?
The other shift is who I ask. Feedback from someone more senior tells me whether the build is sound. Feedback from the people who will actually use it tells me whether the build is right. Those are different questions, and only one of them can be answered by an expert in my own field.
One thing I’d retract outright: five years ago I described the “sandwich” method, where criticism gets wrapped in praise on both ends. I don’t use it anymore. Most people hear the opening compliment and start waiting for the “but,” which means the praise reads as filler and the real note lands anyway. When I give feedback now, I say what the problem is, why it matters, and what I’d try instead. That’s shorter, and it treats the other person as someone who can handle it.
Five years of this has made me faster, mostly because I waste less time defending decisions I made alone. Good work rarely comes from getting it right the first time. It comes from being willing to show it before it’s finished.