Feedback on My Software Development Makes Me Miserable. I’m Not Alone
Photo by Felicia Buitenwerf on Unsplash
The Secret Developer just came back from a few days in the sun.
“It’s true. I even left the laptop at home and took a bite out of the Elon Musk book instead. SPOILER: Elon Musk is a bad boss.
Now I’m home and am back at the keyboard I can see a problem. The first piece of (trivial) feedback I’ve gotten now I’m back is negative.
I’m already looking at job postings”
I’m The Problem It’s Me
The feedback referred to in the introduction is nothing personal or ‘against’ The Secret Developer. It’s a PR that did not conform to the (unwritten) team rules about adding the business section in the title.
This might mean that The Secret Developer is oversensitive or in a terrible mood about returning to work after a vacation.
“The point is that it’s the only piece of feedback I’ve gotten after a week on vacation, and I can already feel my shoulders tense.
When I think about it, I never receive any positive feedback in my work, and we focus on trivialities such as variable names or the order of variables in a class.
No joke. I feel underappreciated and that my efforts are going to waste“
This kind of reaction to constructive feedback is probably more common than we might think. That being true, we need to think of a better way to enhance the performance of software engineers.
The Paper
We live in a world where a great deal of fantastic papers have been written about feedback. Sach, Rien James Anthony (2013). The Impact of Feedback on the Motivation of Software Engineers covers the topic for software engineers and contains some great advice that I think we can all implement in our working lives.
Issues With Giving Feedback
Intention-impact disparity
Those giving or receiving feedback should consider that the intention and the effect of the (same) feedback may not be the same. The judgemental approach of software developers applies to how they process received feedback.
“If we were not judgemental I guess we would not be software developers”
Individual preferences
How we receive feedback can be seen as important to an individual.
Some developers might feel that feedback through email is more important than Slack whereas some felt it less important.
When giving feedback we should take into account their preference for the medium that delivers that.
“What sort of dev uses email?”
Feedback content
When providing feedback the recipient's values should be considered, and this is tied in with the medium chosen to present the feedback.
We need to understand what feedback is valued by the recipient if not we risk that feedback being ignored.
“If you think my code is rubbish I think you is rubbish. Or something.”
Perceptions of the source
Your position on the hierarchy is an important factor in giving feedback. Feedback recipients may perceive the source of feedback is unable to comment and ignore the feedback.
This effect is so profound that it can make sense to ask someone else to pass on the feedback.
“Now we get to the heart of why juniors are oftentimes scared to give code reviews.”
Source relationship
The relationship between the feedback source and recipient can cut the possibility of a negative reaction.
This includes the medium of feedback as well as the recipient's perception of the source and their values. It is true much knowing the recipient will help you do a better job in giving feedback.
“So, if I knew any of my colleagues my reaction might be better?”
The impact of received feedback
In the paper, the impact of receiving feedback is noted to be wide-ranging. The impact includes:
job satisfaction
motivation
performance
attitude
behavior
feelings
“In this case, The Secret Developer is not entirely alone in their oversensitivity.
Lots of us around THE EVIDENCE SHOWS”
When providing feedback to software engineers we should consider the impact that the feedback will have on the recipient because it affects the whole team.
How We Should Communicate Feedback
You should take into account the recipient of the feedback in order to produce the best outcome. That is:
Feedback that is well-received
Feedback that affects change
Feedback that delivers value
“I still like to give feedback served cold and revenge. In a PR comment.”
Practically that means
Get to know your colleagues
Don’t leave a ‘bad’ code review as static text. Walk over to their desk or pick up the phone
Give feedback which can be actioned
Don’t leave your emotions out of it. Consider the impact of what you do when giving feedback
Come from a good place. Give feedback only to help the recipient
“The revenge feedback is helpful, no?”
The consequence of poorly delivered feedback
Not only is some feedback not acted upon but it also damages working relationships.
“Although that sounds bad, I work alone. So what does it matter?”
Conclusion
Motivation theory is really important for the productivity of software developers and job satisfaction. We need to look at what we can do to make the lives of software developers better in so far as it will improve their work and extend their tenure in any particular job.
”Looks like a business person wrote that conclusion. We should really get devs to focus on code. End of discussion.”