Your team (developer and otherwise), and the product/users is why imo. You’re unblocking your team mates, allowing the feature (assuming you have some sort of CI/CD process) to get deployed sooner.
It’s also for you too! You may interact with this code down the line, so having sight of how it works is useful. You can also pick up any algorithms you might not have seen before.
If there is a lot of back and forth, there are a few things you can try to limit this. What are the common things you tend to go back on?
Using a linter and/or a code style to automatically reformat code for you will cut down on comments like “use double quotes instead of single”.
3 amigos, which is an agile methodology. you tend to take (not limited to 3) a designer, developer(s) and a tester, spend 5-10 minutes before the ticket is started and talk about how it should be implemented
consider, would it be faster for you to pair program if the other developer is struggling
also consider, is the code bad? Or is it just different way of implementing a feature than you would? Is it worth requesting a change? Or can you just comment (not requiring a change)
do the PRs need to be smaller? That (hopefully) means less code to review and less code to change
I look at PRs when I am done with the sub task/thought I was working on, so it’s not disrupting me. We as a team try to look at them ASAP for the reasons mentioned above. I enjoy looking at them, it’s a learning experience for both parties!
Hi! I'm R Estrella, creator of Code Matter Media.
With almost 20 years of web development experience, I write about the soft-skills I wish I new about when I started.
What a great answer! I think keeping the users at the top of mind is a great suggestion. The experience engineers build ultimately is about the people using it.
You're spot on; giving reviews is a great exercise that will inevitably make you a better developer. Seeing other people's approaches could add to your repertoire.
Also, self-reviewing! Seeing your code diffs side by side can illuminate anything you didn't catch in your dev env.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Your team (developer and otherwise), and the product/users is why imo. You’re unblocking your team mates, allowing the feature (assuming you have some sort of CI/CD process) to get deployed sooner.
It’s also for you too! You may interact with this code down the line, so having sight of how it works is useful. You can also pick up any algorithms you might not have seen before.
If there is a lot of back and forth, there are a few things you can try to limit this. What are the common things you tend to go back on?
I look at PRs when I am done with the sub task/thought I was working on, so it’s not disrupting me. We as a team try to look at them ASAP for the reasons mentioned above. I enjoy looking at them, it’s a learning experience for both parties!
What a great answer! I think keeping the users at the top of mind is a great suggestion. The experience engineers build ultimately is about the people using it.
You're spot on; giving reviews is a great exercise that will inevitably make you a better developer. Seeing other people's approaches could add to your repertoire.
Also, self-reviewing! Seeing your code diffs side by side can illuminate anything you didn't catch in your dev env.