How to think about MR Feedback as a developer

I was having a conversation with a close friend. He’s an engineering leader and we like to talk shop although he has gone back to the IC role. In our conversation, he brought up this scenario.

He had two principal level developers, one was newer to the organization and one had been there a long time. The new guy was getting lots of feedback on his MRs from the other guy. This was causing the new guy some frustration. Its not enjoyable to have your code critiqued but we all know it is necessary. He, being the new guy, didn’t have a lot of context for the systems so there was obviously going to be some things he got wrong.

When your code is under scrutiny, your defenses can come up. It can be very unstabling and you want to know, “Is it me? Am I really this bad?” The answer might be yes, but how would you know for sure? When receiving feedback there are two questions you should be asking yourself. Is this something I didn’t know or is this something I didn’t think?

Story Time

At first glance those might seem like the same question but I can assure you that they are vastly different.

Lets contrive a scenario, the new guys submits some code. When writing the code he thought about how much load the solution would need to handle and based on the data of the last 2 weeks he considered it low. In review the more senior developer gave him feedback that his solution wouldn’t scale to what they needed because the workload would burst to double to normal load at the beginning of the month due to some financial operations.

This is an “I didn’t know” problem. He had considered scalability but he was missing some details. He should lay out to the other dev what his thinking was but accept the new information and adjust his code.

What if he submits the exact same code but didn’t consider scalability? When other dev says this code wont work due to scale, he has no recourse. He didn’t think through the code thoroughly enough so he didn’t even have an answer to why his code could only handle a certain load.

This is an “I didn’t think” problem. He hadn’t even thought about scalability and while his code would work in production most of the time, it would also fail periodically.

I Didn’t Know

Becoming a top level developer requires that you think well. You have to consider so many different things when writing your code: scalability, readability, testability, reliability, monitor-ability, debug-ability, Etc. As a top level developer you should have a reason for every single line of your code and even reasons for lines you didn’t put into your code. However, you will not always have the domain context. There may be parts of the application that you are unaware of and other developers can educate you on.

If you determine the feedback is domain specific and given the new information the code needs to change, you should not feel bad. They did the correct thing and you did the correct thing. This is the MR process working perfectly.

I Didn’t Think

If someone catches you missing something due to a coding universal, its time to take a look in the mirror. You need to ask yourself “Why didn’t I even consider that?” This means there is a problem with your thinking. Good developers have reasons for every line of code they write. Great developers also have reasons for the lines of code they didn’t write. You have to consider everything even if what you considered doesn’t turn into a line of code.

If you determine that the problem is with your thinking you have an opportunity to grow. It is going to feel like you got punched in the gut. Good. Use that feeling as a reminder not to do it again. Maybe its something you normally consider but were moving fast and got sloppy. You should feel grateful that you were caught and find a way to move quickly without sacrificing your thinking.

Think Better

Every MR comment should result in a response, “I thought about that, and chose to do it this way” Your reasoning might persuade the other person. Maybe they are not thinking about the problem correctly. As long as you are committed to thinking better you will get better. Code Review is the best place to test your thinking. If you can move away from “I didn’t think” problems to “I didn’t know” problems you will find the dialog on reviews to be enjoyable.

There may be times that two people have both thought through the issue and have come to different conclusions. That happens a lot but is a whole topic in and of itself. Maybe for another article.

Finally, don’t make the same mistake twice. If you get caught not thinking correctly, write it down, make a self review process before formal review. A bigger problem than not thinking correctly is not having a process by which you fix your thinking.

---

If you liked this, consider subscribing to my Substack. I publish an article about software engineering and software engineering management every Tuesday. If you want even more, consider joining my paid content where I am writing a course in real time about making the jump from developer to manager.