I ONLY WANT TO WRITE MY OWN CODE

TODAY I FOUND OUT I HATE DOING PR REVIEWS AND HAVING TO GO BACK AND FORTH WITH PEOPLE ABOUT WHAT THEY DID IN THEIR CODE

I'm sure it's beneficial, but it FEELS like such a waste of time

You are probably doing it wrong.
PR are a learning experience - sometime you learn how to do things better. Sometimes - you learn how *not* to do things.

Leave the feelings at the door, and use an online review tool.

Pair review = good

Depends on behaviour of people.

PRs in a non wanker team with experienced people:

Cool, learned some new stuff today. 👍 Thanks.

PRs in a wanker team with emotional crybabies:

Gosh, just stop masturbating with sand paper you fucking cunt, then your dick doesn't hurt as much and you can stop whining for fucks sake.

I usually collect examples of good PRs in the company ... When it goes out of hand, I make the very simple "PR is closed, see these PRs for proper way: XY. Rest via separate meeting" comment and close the PR.

Took a long time... But most people now behave at least in the PRs nicely.

Someone has to do the reviews and you are likely perceived as the most qualified dev. But in the end, you don't do a full static analysis in that reviews anyways. In principle anyone who is somewhat competent at writing maintainable code and knows the style guide could potentially do them.

So maybe you could just find someone who can do them and likes to do them - and get that task delegated to them. Then you can focus on maintaining and creating while that part of the quality assurance is done by someone else.

@Oktokolo we're a small team, we do PR reviews to "share responsibility" about PRs or something

tbh it's cool to see how someone did something, but when it has problems and I have to keep messaging back and forth with them about it so I can approve it, I can't focus on my tasks

@nururururu So the problem is the guaranteed distraction due to answers to your complaints.

One solution could be to skip the message ping pong by upgrading the communication to synchronous when you found stuff to be fixed (most blunt way to do so: call em over).

Or you could just go full asynchronous and ignore answers until your current task is done.

Either way, you still need to communicate. If that is the actual problem, you could also just fix the stuff yourself and encourage them to read your changes (so there is a chance of future improvement). This doesn't work with anyone though - some might get very lazy when they realize that you do the final polishing if they don't...

I feel you - what I usually do is only do a few deep dives in the PR list, and for the others I will do just code formatting and surface level stuff. If I found out what other people wrote all day it would be insanity. Also, tell them to send their PR to someone else occasionally.

@aaronswart Perhaps indeed

@magicMirror To be fair it can be pretty time consuming with people that are a waste of space. When they churn out crap every time and are basically unable to fix it unless you hold their hand it becomes a real chore.

Fortunately I do like teaching and now I work with way better people. There is still a large gap with most (my on par coding buddy left unfortunately) but they teach me some things too and it's nice to watch them grow.

@hjk101
You are descibing the essential Bad PR experience, VS the Good PR experience.
The idea is to learn from each other and get gud as a result. If you do it for any other reason... 🤷‍♂️

@magicMirror Ow yes in case I wasn't clear I fully agree with you and I think that reviewing has a lot of benefits. Not just learning new tricks but most importantly keeping your understanding of the codebase up to date.

The problem I described is a problem with the team, not the review system itself.

There are a lot things that can make it feel tedious. For the OP what gives that feeling can be different for every person. Perhaps nothing can be done to fully mitigate it for you but perhaps you can minimise it and even make arrangements with the team so you are only assigned a certain type (e.g. high priority) of MR/PR in trade of some other chore

@hjk101
Don't get me wrong 😁. PR are a chore. Especially when you examine the codebase, and looking for potential bugs, n^2 algorithems, bugs, bad var names, more bugs, non enforced code conventions, and bugs. Thats why it is a chore - you are spending time doing something boring. And looking for bugs.

Most coders treat PR like that. The number of times I got "whats this?"/"why like this?"/"not convention! fix!" in a PR is staggering. Thats why I started opening +2k/-0.8k PR and liberally applying "the boyscout rule" 😉.

PR should teach how to better code. Telling another coder "fix this", without explaining the actual problem with the code... Makes you a "code janitor".