Last time I said a column was coming on how to take feedback and make it useful, and then suddenly felt pressured to actually write this so-called column. It was terrible. Here I go getting all excited to write about how terrible Git is and I’m already onto other things! I promise to get back to hating on Git soon.
Not that the Git people are responding to my feedback … which is actually a pretty valid response to negative feedback coming from the internet, honestly. The source of the feedback counts for a lot. Random internet trolls rarely give useful suggestions, except of course when the random internet troll is me.
Overall I ended up with two beliefs about feedback. The funny thing is that these points have been true both for software development and for stage performances. Who would have expected overlap? But hey!
The first is obvious – listen and be open to making changes instead of being defensive. You don’t want to rewrite everything because someone made a good suggestion – but that doesn’t rule out making improvements. This is an extension of the golden rule to me – if I see something in your code that really could be improved, how do I want to be treated? It’s not like I’m going to respect a coworker more if they steamroll everyone and ignore possible improvements! Seeing them listen, absorb extra input, and make improvements is what I respect – so that guides how I behave as well.
And again that seems obvious – but a surprising amount of people pick a path and then just close off the idea of making any alterations. So if someone makes a suggestion and you don’t like it check in with yourself. Are you not liking it because it’s not your idea? Is this defensiveness? If so, then force yourself right past that and actually look at the idea.
And secondly … good lord some feedback is just terrible. Terrible like I want to just kind of get some popcorn relish how bad it is. A LOT of feedback is like that. I think of those as pointers. Maybe I won’t use the suggestion, but I do mark where it’s pointing.
If I end up with multiple pointers to something – then something is wrong there. Maybe every suggestion given was terrible, but why is everyone making suggestions about THAT bit? Usually because THAT bit has a problem.
In a show, I’ll end up with several people making suggestions about a particular place in a routine. What that tells me is that in THAT place, the show didn’t flow right. But very few people can actually tell me “that didn’t flow right” – but they felt it, and that led to suggestions. So what is most important out of that to me is WHERE the suggestions point.
Similarly in code – people are thinking when they listen to you. The stuff that makes the most sense just flows through while they listen, there isn’t anything to catch. The stuff that catches is almost always the place that needs attention – something doesn’t make sense, something didn’t feel right – and that leads to people making suggestions.
So for those – even if the suggestion is terrible, don’t ignore it. Pay very careful attention to where the feedback points. And if you get multiple pointers to the same place, then go pay attention to that place!