Am I My Code?
I read this quote on Twitter from Avdi Grimm today and it really resonated with me
People don't tell singers "you are not your songs", or artists "you are not your paintings". #iammycode
— Avdi Grimm (@avdi) May 20, 2015
This really got me to thinking about some feedback I received during a performance review.
Martin sometimes gets a bit precious when given feedback about his code
Well I wasn't gonna shy away from it, the comment was accurate and we had a decent chat about it. Seeing the tweet from Avdi really helped crystalize my thinking on the topic of feedback.
So why do I get precious when given feedback?
Well I guess the short answer is, I am human and I have feelings.
How we feel in a given situation is the culmination of our life experiences up to that point, how we're feeling on the day, how we feel about the person giving the feedback and how we feel about the way the feedback is given.
This makes interactions when giving feedback unpredictable. What may be received well one day may not the next. They may not have slept well, the sweater you're wearing reminds them of some negative past event, they might be having a day where they just want to write code that works and not have a debate about it.
So given all that, what are some of the strategies that can be used to reduce the likelihood of feedback being received poorly?
Strategies for giving feedback
One thing that I find really motivating when receiving feedback is a genuine attempt on the part of the giver to understand why I did what I did.
If you've spent any time coding, I'm sure you've looked at someone else's work and gone "What the hell were they thinking??". I'm sure you've also had the moment where you think, "I can make that so much better", only to discover that there were a bunch of complexities you hadn't considered, before finally conceding that perhaps what was there originally wasn't quite so terrible after all.
When someone takes the time to ask probing, but open questions feedback becomes conversational and collaborative, rather than combative and oppositional.
Consider the following:
Eugh, why did you do that?
vs
So, can you tell me a bit more about about what's happening here?
Which would you prefer?
Another thing that is valuable is making the recipient feel safe. How do you do that? Well, one way to make someone feel safe is to share stories of your own experiences.
Oh, I never use {insert controversial pattern / operator}
vs
I used to think that {insert controversial pattern / operator} was a really good idea, then I {did / read / discovered / was shown} {other thing}.
Bluntly dismissing something with the unspoken insinuation that you always knew about a given topic is really unhelpful. Sharing some of the journey you went on helps the recipient feel safe because although you're sharing something they may not know, you're acknowledging that you didn't always know it!
How do you feel about the code you're looking at? How does the person who wrote it feel about it?
Asking clarifying questions can help open up a dialogue.
So, how are you feeling about this story? Are there any bits you are less proud of?
Acknowledging people have feelings is a great way of opening the door for conversation. Getting them to self identify bits they are not proud of can lead to them asking for an opinion. This can be a really natural segue into some useful feedback.
Code is for computers, but it's written for humans
Empathy is the skill above all others that will allow you to give feedback in a well received way. If you care about the recipient and allow yourself to be guided by that, you're starting from a good place.
It can be easy to dismiss someone's feelings with the "it's the code, not you" line, but that misses the humanity of the creator.
Do check out Avdi's full thought stream. http://devblog.avdi.org/2015/05/20/i-am-my-code-redux/``