All Case Studies Design Development Interviews Machine Learning Project Management

How I Learned to Embrace Negative Feedback

Negative feedback is something you shouldn't be afraid of - in fact, embracing it and getting the most out of it will help you evolve as a developer. I wanted to share how I learned to treat negative feedback as a push towards improvement.

Imagine you’ve just had a productive day. You worked through the changes locally and they seemed to check out perfectly. All the tests passed. After pushing a batch of commits, the staging build completed successfully. It all works! You moved on to the next task with a big grin on your face. A little later comes the time for a bit of a code review. What could possibly happen?

Turns out, one of 3 things:

  • All your commits got accepted
  • You got a comment (or a few) saying “This is wrong, fix it”
  • You got a longer remark or a question: “This could have been done better, have you tried using X instead?”, “What made you go for this method here?”, “Can you explain what you’re trying to achieve?”

What can you expect?

Which of the scenarios above feels the most likely to you? Don’t let the number of letters fool you - the last one is by far the least likely. That’s assuming you don’t commit hot garbage that leaves the reviewer baffled and asking you if you recently decided to take leave of your sanity. Here’s how to interpret these three cases:

If all your commits got accepted

Well then, your code was obviously impeccable! Everything you wrote was pure gold! Feel free to look yourself in the mirror and tell yourself straight that you’re an amazing developer. You deserve it!

Either that or the reviewer didn’t spot anything embarrassingly wrong with the code so he didn’t care to comment or reject any of your commits.

Someone said “fix it, this is wrong”

Your commit didn’t get accepted. There’s a comment on Github saying “fix it”. Some more work just got dropped on your plate and your self-esteem might have taken a little hit. But that’s not such a big deal. Mistakes happen, right? If someone reviews your code it’s very easy for them to just glance over it, point out some glaring syntax and stylistic issues and call it a day. Now imagine that the reviewer dug a little deeper and said “these couple of lines won’t do what you want” or “this is just wrong, fix it”. That’s a start!

You got a longer comment or a question.

It might have been a longer comment explaining why your solution won’t work or what corner cases you missed by implementing it the way you did. You should appreciate this even though your first instinct might be to crawl off into a corner somewhere. Cheer up! It’s just a mistake that someone pointed out, that’s all.

Giving feedback is an art

Do you realise how rare it is to get well formulated, valuable negative feedback? Giving meaningful feedback is difficult! It requires a lot of time, thought and linguistic finesse. If the reviewer had more time to spare, he or she could have even explained why your piece of code won’t fly and how to fix it. However, you shouldn’t expect people to actually go to those lengths.

We all have our own projects to take care of. We’re busy adding new features, fixing bugs, trying to stay up to date on communication with clients and attend all the calls. Code review is hardly something more experienced developers look forward to with relish. So if one of them actually devotes his/her time to giving your code a thorough reading and pointing out mistakes then that could mean that you - the junior developer - have something to be happy about.

You got feedback - what's next?

You spend a lot of time on your code and you try your best. The client is fussy - they don’t want you to dwell on trivia. “How hard can it be to just display a notification for the user?”. You feel like you are doing good work even with all the distractions around you. And then someone says “Your code sucks”. Well, maybe he/she actually said it in a “nice” way, like “please keep in mind that this method does something completely different and you’ll run into such and such problems in certain cases”. But the fact remains that a lot of your commits got reviewed, you got a lot of negative feedback and you feel like your work wasn’t appreciated. All you can read between these comments is “your code sucks”.

It’s not a great feeling, but you have to remember that nobody gives you negative feedback out of spite or some malicious intent to make you feel bad. You always have self-doubt to fall back on but that just seems like the easy way out and give this instinct a wide berth. Think of it like this - someone just spent a lot of time and effort on a thorough review of your code and handed you, on a silver platter nonetheless, a concise list of the mistakes you made. Cool! That just took away all the worry about whether or not there are potential errors in your code. There are! And a lot of them! Which means you know exactly where to focus on getting better!

Focus on improvement

Computer science is a field that’s expanding at an insane pace. There are new technologies being invented every day, new programming languages and frameworks exploding in popularity. It’s almost impossible to keep up with all that’s happening and it’s unreasonable to expect any one person to be an expert in all of these fields. At the same time, you will have to learn new things. Having someone more experienced guide you is one of the best ways. Having information on what you’re doing wrong gives you a good idea of how well or not you’re doing currently and what needs more work.

“You are not your code” is a line that gets thrown around a lot. It’s correct in terms of - you shouldn’t respond emotionally to criticism of your code. However, don’t take this as an excuse to disavow your code. Take full responsibility of it. You wrote it. You made those mistakes. You need to fix them. At the same time, you could take pleasure in learning from those mistakes. You are getting better! The quality of your code written from now on will move onwards and upwards. If someone less experienced runs into similar problems, you’ll know exactly how to help him/her. You will feel reassured that you’re on the right track, and you’ll be proud of your work. This is the road that begins with “your code sucks”.

There are no stupid questions (if you want to move on)

What if you get some brief feedback that’s negative and not very well put together? Just ask a selection of these questions: “Is that feedback correct?”, “Did I really make a mistake here?”, “How can I fix it?”. Ask questions. A lot of them, if you’re not sure. Look for sensible and concrete answers. Don’t be satisfied with “It’s a bad solution”, “Nobody does that” or “I don’t like this piece of code”. The magic word is always “why” if you’re not sure!

If you have to involve other developers, please remember to put in some minimal effort beforehand. If you don’t understand the feedback you’re given, you should definitely ask the people who gave it to you for clarification. If you simply disagree with it but don’t have strong arguments please spend time researching the issue. If they notice that you’ve investigated the feedback and possible solutions but need their input they will feel valued and will be happy to help you (unless there’s a fire in their project that requires their urgent and undivided attention). You will get vastly different results if you just shoot off a question along the lines of “I don’t know what’s wrong here, I didn’t check for possible solutions, please tell me how to fix it step by step or fix it for me”. Respect other people’s time.

So in short…

You should welcome negative feedback. I don’t mean you should merely tolerate it. I’m not saying you should accept it. I mean you should feel the urge to pop open a bottle of champagne every time you get well formulated negative feedback about your work.

I found that the tasks that I did that got rejected or passed stuck a lot longer in my mind. When I had done something right on the first try I wasn’t always sure a couple of months down the line how I did it without looking back at my old code or I didn’t necessarily have a good understanding of why the solution I implemented worked.

It was negative feedback that compelled me to reread my own code, try to dig deeper into why it was broken and look at what could be done to fix it. Often in the process, I’d read the documentation on methods I was using and good practices recommended by other developers. The upshot was that I started to write code of a higher quality and even began to look forward to negative feedback more than its positive counterpart. And I think that you might too!

How do you deal with any feedback that gets sent your way? Please share your thoughts in the comments below!

digital transformation
remote work best practices
Read also
Need a successful project?
Estimate project or contact us