A PR should be merged if it solves a problem and does not break/prevent future changes.
Then you can always do a followup PR to fix styling, complexity etc.
Everything else can be solved outside of the PR.
Need better styling? Teach people this.
Need less complexity? Pair program and mentor people.
Need people to see future problems? Share your code visions with the team at a planning meeting or even better write a spec’.
Mind, it took me a while to get over my own ego to realize this... :)
Yup, I totally agree that if you want to raise the level of expertise on the team it has to come from mentoring. But it’s kinda important to mention that:
some people don’t want to pair program
on remote teams the code review is that primary mentoring opportunity
So while I love pair programming personally, sometimes I have to use the code review as my chance to learn and to teach.
I was speaking in broad terms, I totally agree, this is not a one shoe fits all situation. :)
Both of those examples however present a less than ideal situation, that could be resolved outside of the PR.
Such as, keep people that need to learn on site, and not remote. And to teach people the importance or pair programming, especially in a learning setting.
If these can’t be done, then the mitigating action can be to use the PR.
But it really should be considered last option, as it is super unproductive, compared to alternatives. At least in my humble experience.
I work at a 100% remote company, so there is no “onsite” location
“teach people the importance of pair programming”
Good idea! In fact I tried that today. I’m on a pair programming break right now. :) It’s tough going at first, but I’ll be sharing my learnings on it in a future article.
Thank you for the fun conversation. I hope you subscribe/ keep reading. I like having readers who challenge my assumptions! :)
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.
A PR should be merged if it solves a problem and does not break/prevent future changes.
Then you can always do a followup PR to fix styling, complexity etc.
Everything else can be solved outside of the PR.
Need better styling? Teach people this.
Need less complexity? Pair program and mentor people.
Need people to see future problems? Share your code visions with the team at a planning meeting or even better write a spec’.
Mind, it took me a while to get over my own ego to realize this... :)
Yup, I totally agree that if you want to raise the level of expertise on the team it has to come from mentoring. But it’s kinda important to mention that:
So while I love pair programming personally, sometimes I have to use the code review as my chance to learn and to teach.
I was speaking in broad terms, I totally agree, this is not a one shoe fits all situation. :)
Both of those examples however present a less than ideal situation, that could be resolved outside of the PR.
Such as, keep people that need to learn on site, and not remote. And to teach people the importance or pair programming, especially in a learning setting.
If these can’t be done, then the mitigating action can be to use the PR.
But it really should be considered last option, as it is super unproductive, compared to alternatives. At least in my humble experience.
I work at a 100% remote company, so there is no “onsite” location
Good idea! In fact I tried that today. I’m on a pair programming break right now. :) It’s tough going at first, but I’ll be sharing my learnings on it in a future article.
Thank you for the fun conversation. I hope you subscribe/ keep reading. I like having readers who challenge my assumptions! :)