I came to software engineering later than most of my peers. While many of them went through schools built specifically to train future engineers, I went through a regular high school on a path toward university and research. That later start meant catching up in some ways, but it also gave me a different vantage point: I learned software engineering as an adult, without the background assumptions that come from growing up in the field. Alongside my experience as a trained scout leader, this has shaped how I think about feedback; I've had to develop my own sense of when it's genuinely useful and when it isn't. That outsider's need to understand why, not just what, is exactly what I find missing from a lot of the feedback I get on my code.
When you start your journey as a software engineer, you inevitably have to start writing code, as the job requires. Now, before you just "push to main," you should maybe let someone look over the code you wrote beforehand. So you open a PR ("pull request"). This lets your colleagues take a look at the code you wrote and either approve your new code or request some changes. Requesting changes is the norm. Your code is almost never going to be perfect on the first go. The reviewer will leave comments on what can be changed or improved upon, usually something along the lines of This doesn't seem right, maybe try this?, sending a code example along with it. This is somewhat helpful, as you can't mindread and don't know what the reviewer felt wasn't good.
But as a novice, someone who doesn't have much experience in writing code or implementing features, reasoning is everything. After receiving a review, I'm often left asking myself: Why is the solution I implemented not a good fit? Why is the change my reviewer is proposing a better solution? How did my reviewer come up with their solution?
There are some rare cases where your code is "perfect." Reviewers have a look at your code and they can't find a fault. Great! They leave a Looks good to me! comment and approve your PR. This isn't helpful. Often, when I worked hard on a new feature and it was approved instantly, I felt really good about it for a moment. But when I let some time pass, I noticed that I hadn't really learned anything from that feature. Yes, I wrote code and it was "good," but what does that even mean? Why was the PR approved? What was good about the code that I wrote? Would the reviewer have done the same had they implemented the feature?
The feedback culture in this field often seems solution-oriented, not education-oriented. That works fine between peers with roughly the same experience, who can fill in the reasoning themselves. But it breaks down when the person on the other end is a junior. So here's what I'd ask of anyone reviewing a junior's code: it is your job to reason and explain your decisions to the layman. Explain your doubts, reason your proposed solutions, point us to blog posts or tutorials that explain new concepts to us, and try to make us understand why something works or doesn't work in your mind. It may seem tedious in the moment but will save you from lots of re-proposing solutions in the future and, as an added benefit, we grow as software developers. Giving meaningful and educational feedback is the most important thing you can do for junior developers.
