– There are people who are afraid to review the code on a regular basis

In light of the previous focus on “impostor syndrome” and how stressed the developers really are, I’d just like to add a few more nuances to the whole code review discussion. From a developer who got himself very dusty after bizarre forms of code reviews, and who is now trying to balance code quality with good ergonomics himself.

Mattis, of course, is absolutely right; Yes, please code good and integrated review (CR), and yes, please program couplings and mobs. As long as the CRs are done correctly.

In fact, Kent Inge Fagerland Simonsen started his article by writing a little bit about “psychological security”, and the whole article is actually quite good:

Monday He should Able to enjoy a positive and fun work environment, with honesty in reactions to pull requests (PR).

I don’t think, as Ton Hobsdale has written, that this will happen more The distance between the person proposing the change and the reviewer.

safety first

Hobsdal writes well:

“We don’t need more distance. What we need are safe teams, where all kinds of proposals for change are allowed and where everyone dares to speak their mind.”

But it should be quite possible to come up with completely new proposals for how to solve the task in PR, even if the developer spent several days solving the task. And that He is possible, without more spacing or less critical code revisions.

But then psychological security in the team must already be there. Because we have a very large percentage of developers who suffer from “impostor syndrome” every single day, and there are people who suffer regularly horrors for code reviews.

Short, critical reactions can quickly feel like a slap in the face, and can destroy self-confidence. Then it’s not just that you keep getting tons of comments without talking to each other first.

talk to each other

It’s nothing worse than just being nice to each other. Build on each other, comment on what’s particularly good, and give your feedback in a fun way if you don’t know how the person you’re reviewing the code with will handle it.

that it no A contradiction between being nice and getting complementary feedback.

If you have a lot of annoyances and comments, it’s really possible to send a little “nudge” on Slack or Teams, or actually say, “Hey, now it might sound like I’m yelling nasty, but these are just some suggestions for improvements I’ve found 😊”.

Of course, look at the person whose code you’re going to review, but I’ve had quite a bit of experience with that myself.

And if you see a completely new way to solve a task and the suggested changes are too broad, feel free to write a short article “Should we discuss your workaround?”.

Not everything has to be tolerated

The situation that two days of development will be wasted because a workaround is found after completing the task is not necessarily good either. Two days of development lead to a solution, then a good technical discussion and then a new, better solution that will never go to waste.

Of course, you have to be practical and look at the customer, but the most important thing is that the task is solved in the best possible way based on the assumptions that you have.

One shouldn’t care how hard it is for a developer already mired in impostor syndrome to receive “eh? What is this?” Or just “cross this out” without actually having a tune where that’s fine. The worst I received was of the “?” 😛” without any further context (the goat face emoji is one of my biggest hate emojis).

These examples do not contribute to the learning, quality, or mental health of the developer. It just makes you feel dumb and stupid. Not all forms of criticism are what you just have to learn to tolerate.

So be nice and fair, but use your CRs for what they’re worth: an extra pair of eyes that can spot things others haven’t noticed and come up with new angles.