“Lessons from a Code Review: How Feedback Improved My Code and My Career”

2 minute read

dist files

Foto de Alvaro Reyes en Unsplash

I remember that afternoon at the office. It was Friday afternoon, and it was when the whole team would get together for a code review. Back then, we would go to the office, and the dynamics were different (you know what I mean).

So, the way we did the code review was as follows: someone on the team would propose one of their classes to the rest of the team with enough time in advance so that everyone could read it carefully.

What people did was print it out and note down if there was anything in the code worth highlighting, either for suggesting changes or improvements. For example, “on line 25, you’ve written a variable with a name that’s not very clear.” These kinds of comments.

When Friday arrived, we would all meet in a room with the printed-out code, ready to discuss it. There was a moderator (nowadays, we’d probably call them a facilitator to make it sound cooler) who would give people turns to speak and set time limits if discussions dragged on too long. That day, it was my turn to have my code reviewed.

At that time, I had around 3 years of experience, and the people in that room had 10 more years of experience than I did. You could say I had some experience, but compared to my colleagues, I was still quite junior. So, as soon as the session started, one of my colleagues said to me in a rather ironic and sarcastic tone, “You couldn’t have done it worse.”

At that moment, it felt like a punch in the gut because I wasn’t used to receiving criticism of my work, and I took it personally. The class had a lot of room for improvement in terms of readability, single responsibility, and a few other things.

Over time, though, I came to understand the value of that criticism in helping me improve how I develop code. Now, whenever I look at a class, I always think, how could this be improved? Could this class be made more readable somehow? Those sessions definitely helped me improve and do a better job.

So, if you have someone giving you constructive feedback about your work, accept it and figure out how you can use it to improve what you do. We’re talking about code here, but this applies to any area.

I can’t take responsibility if your code turns into spaghetti code, but I can make sure you get an email letting you know when I’ve written a new post that might help you learn something ;) I write whenever I feel like it, so don’t expect an email from me every day. Until next time.

I won't give your address to anyone else, won't send you any spam, and you can unsubscribe at any time.
Disclaimer: Opinions are my own and not the views of my employer

Updated:

Comments