Giving my first conference talk recently was an absolute thrill. I was excited, not overly nervous, and deeply confident in the hard work I’d put in. My mindset was simple: I’m going to nail this.
And mostly, I did! Despite a few initial jitters and some screen-sharing shenanigans, I found my rhythm. When the screen randomly went black mid-presentation, I handled it with humor, kept my cool, and let my passion for the topic shine through. Overall? 10/10. I was proud.
The I got my feedback from the attendees. Most were positive, kind, full of support and praise. One was a 7/10 with thoughtful critiques that I found myself nodding along to as I was reading the review. and then, there was this:
My initial reaction? "What. Is. This."
I'm someone who has a tumultuous relationship with feedback. I'm certainly not arrogant enough to think I can never improve on things. With people I know and respect, I can take feedback easily, with humor and a sincere goal to get better. With people I dislike, I can simply be ambivalent, with a "you-can't-win-em-all" mindset.
With people I don't know at all, I can be stung by it, but more than anything I want a conversation. I want a back and forth. I want to make sure my position is known and understood even if its disagreed with.
Enter my bane, anonymous feedback.
I absolutely understand the value of anonymous feedback, that people usually won't be honest otherwise. But it does, unfortunately, narrow in on my weak spot: getting vague feedback from someone I don't know with absolutely no way to probe deeper on their meaning.
So, at first, I was grumpy. Got feedback from various people on that, some understanding while others counseling me that accepting feedback was optional. After sleeping on it, I realized what was annoying me most about it... that person was right. They tapped directly into an insecurity I had harbored before even stepping on stage.
My talk was on accessibility. My core strategy was to read the presentation content explicitly so hard-of-hearing attendees could read everything and visually impaired attendees could hear everything. It was a deliberate, logical choice, but deep down, I had worried: Is this too dry? Too literal? Too boring?
That uncomfortable review forced me to ask new questions: How could I deliver the same accessible information in a more dynamic way? How do I balance thorough accessibility with high engagement?
Suddenly, my frustration shifted into creative motivation. I started brainstorming new ways to evolve the talk and I feel really motivated to do so now! Excited even.
What's the moral? Even when feedback arrives in an unideal wrapper, don't throw it in the trash right away.
You don't have to process it immediately like a robot. Step away, take a walk, or sleep on it. But once the dust settles, investigate that needling feeling. See if you can ask yourself why it upsets you so much. Because that feeling is usually trying to tell you something and it can be a really good way for growth, if you're brave enough to sit with the discomfort.
Top comments (9)
A speaker after my own heart. I also got feedback that I read too much through my presentation. But I don't think I could memorize 75 minutes of content, ever. How have changed your talk if at all? 🙂
“You read everything.” might be one of the most annoyingly efficient pieces of feedback I’ve seen. 😄
Four words, almost no context, no suggestion for improvement — and somehow it still found the exact question you had already been asking yourself.
I think there’s an important distinction here between badly delivered feedback and useless feedback. They aren’t necessarily the same thing.
As engineers, we’re used to wanting reproducible bug reports:
What happened?
What did you expect?
Where did it happen?
How can I reproduce it?
Anonymous feedback often gives you none of that. It’s basically:
“Something felt wrong. Good luck.” 😂
But I really like what you did with it. You didn’t blindly accept the 4/10 as some objective measurement of your talk, and you didn’t dismiss it either. You extracted the useful signal from a very noisy report.
And accessibility makes this particularly interesting because the solution probably isn’t simply “read less.” The real design problem is exactly the one you identified: how do you preserve the information channel for people who need it while making the delivery more engaging for everyone?
That’s a much better question than “Was the reviewer right?”
If four frustrating words eventually produced that question, I’d say you got something useful out of a pretty terrible bug report. 🙂
three words. not four :-D :-D
Preface: I am in no way defending or attacking anyone here, I am going to try and describe an observation and try to add a perspective that is not emotional.
You hit an important point there and bury it right away. It's the "engineers want" point:
The feedback gave two components that an engineer should be happy with. It stated a reproducible observation: The content of the talk was being read. 100% reproducible if you allow simplification. Second, it stated how that fact landed with one member of the audience: Sub mediocre. That's another fact, not a bad critique. It simply states that the way the talk was given landed badly with this person. So why not 1/10? Obviously, there was enough "good" content so that the presentation did not fully ruin it.
The critique therefore was actually a perfect "engineer wants this" feedback. Objective and subjective without overly emotional dismissal. You can't get better than this without a detailed bug-report.
I say you "buried" this important point, because, you pick up on the author's note that the presentation was done deliberately. Which is not the point of the critique. Even if the TASK was to "read out like a robot", the critique would still have been spot-on: Read out. Didn't like it. Nothing to add.
The author is right to suggest "sleep over it". And realize, that the critique is not negative but, without context, simply objective: Observation, personal qualification, done.
Three words. Damn. 😄
I managed to introduce a bug into my own bug-report analogy. Fair catch.
And I actually like your distinction between the observation and the qualification. “You read everything” is indeed a reproducible observation, and 4/10 tells us exactly how it landed with that particular listener. I agree that neither of those facts needs defending.
Where I’d still make a small distinction is between valid feedback and actionable feedback.
If a monitoring system tells me, “CPU hit 100% and the user experience was terrible,” I absolutely want that signal. It’s real and useful. But as an engineer, I’m still going to want to know what workload triggered it, when it happened, what the user was doing, and what “terrible” looked like before deciding what to change.
That’s how I read Amanda’s situation too.
The interesting part isn’t whether the reviewer was “right” or whether reading everything was intentional. The interesting part is that one very compressed observation exposed a design tension: the accessibility strategy achieved one goal while apparently hurting engagement for at least one listener.
And that gives you something interesting to engineer around.
So I’ll happily downgrade my assessment from “pretty terrible bug report” to “minimal bug report with surprisingly good signal.” 😄
And yes, next time I’ll run the word-count test before shipping.
This really resonated with me. I’ve noticed that the feedback that bothers us the most is often the feedback that touches something we already quietly worry about.
Early in my career, I treated criticism as a judgment of my ability instead of information about my work. The shift happened when I started asking myself: “Is there something useful hidden inside this, even if the delivery wasn’t perfect?”
The interesting thing about feedback is that positive feedback confirms where we are, but negative feedback shows us where the next level is. The hard part is separating the useful signal from the emotional reaction.
I also think anonymous feedback is uniquely challenging because there is no conversation behind it. You can’t ask follow-up questions or understand the context, so your brain fills in the gaps (usually in the worst possible way).
But those uncomfortable moments often become the ones we remember most. Growth rarely comes from hearing “you’re doing great”; it usually comes from discovering the one thing we didn’t want to see.
Great reminder that feedback isn’t always comfortable, but learning how to process it is a skill worth building.
This resonates with my younger self. In the past, I hated negative feedback (especially since I put all my effort into anything I do). But now, I relate to stepping back first.
I read in an article once that our feelings are natural. We don't usually keep it inside until it bursts. We let it out (about 10 mins). Then we'll find ourselves having clearer minds about how to approach said feedback.
It works well on my end. It's not perfect since I'm still learning how to control my emotions as I grow older. But this is one of the steps I usually take whenever I get undesirable feedback from other people. And yeah, sometimes I see their point after cooling down and at the end, I just think maybe they are just having a bad day or they just phrased their feedback wrong.
Either way, it is still up to us if we are going to make a tragedy out of something that can be solved with just pausing and then going back to it when ready.
As someone that has worked on live games and games adjacent software for a few years, there is real value in truly separating feedback data from tone, verbosity, and even significant signs of ignorance. But the true skill is doing so while taking minimal, if any, mental damage.
1) "There is a quest called 'Under the Sun' in the Elysian Fields that can't be turned in if someone else has done it because the NPC gets stuck when walking back to his shop. Thanks!"
2) "God u pepul dont no how to do any thing STUPID lazy n I kileld the hippo n every thing!@ why don u fix ur CRAp dude isnt even here???"
The first is polite and easy to read and detailed and I know exactly what issue they are having and probably can go to fix it without even having to repro the issue. Perfect, because I have a hundred of these to go through today.
The second guy sucks. Rude, stupid, and even worse, I don't really know what is going on! I am going to have to figure out what quests have you kill a hippo? Maybe? And then maybe the hippo is not there, or maybe the turn in NPC? I am going to have to spend time figuring this out before I can even start to fix it. And let's not forget how much this person sucks and honestly, doesn't seem like the sort of person I want playing my game anyway!
Sadly, both of these are about the same thing. A broken piece of the game that is hopefully being experienced by thousands of players a day if I am lucky! It must be fixed and so if I don't have the first comment, I have to rely on the second. And since I have a ton of these to do today, I really can't get too upset over the failings of the second. Not because they don't suck (they truly do) but because I need to protect my peace and have a good time at work.
People often learn the skill of pulling gems from crap, but in my experience the harder skill is doing so without any of the crap getting on you and ruining the rest of your day.
That last paragraph is probably the hardest part of the whole feedback problem.
Finding the signal is an analytical skill. Not carrying the noise around for the rest of the day is an emotional one — and I suspect the second takes much longer to learn. 😄
Your two examples also expose something I hadn’t really considered when I made the bug-report analogy above: sometimes the worst-written report may still be the only telemetry you have.
You don’t get to reject production evidence because the logging format offended you. 😂
The trick, as you said, is extracting:
“NPC may be broken after another player completes the quest.”
…without also importing:
“STUPID lazy n fix ur CRAp”
into your brain for the afternoon.
Maybe that’s the mature version of handling feedback: not becoming immune to criticism, and not pretending tone doesn’t matter, but getting very good at deciding which parts deserve access to your engineering process — and which parts don’t deserve access to your head.
“Pulling gems from crap without getting any of the crap on you” is a surprisingly good specification for that skill. 😄
Some comments may only be visible to logged-in visitors. Sign in to view all comments.