This is marvelous advice. I can definitely improve the code reviews on my teams
---
RT @HeyChelseaTroy
@jezhumble OMG I wrote about this! Twice!
This first one is about the standard for effectiveness in code reviews.
Once reviewers are contributing appropriately to support submitters, pair programming starts to look a lot less like a comparative "waste of time."
https://chelseatroy.com/2019/12/18/reviewing-pull-requests/
https://twitter.com/HeyChelseaTroy/status/1456116582283890688
@worldsendless nice to learn that our team is already implementing these practices and I thought these were coming sense. Looks like it's not the case.
One thing we implemented is that each developer has their own main branch, which is then used for all their pull requests to be merged to that branch before being merged to the global main branch. That way we can have multiple pull requests open from one developer without putting too much pressure/load to get through all the pull requests.
@barefootstache Interesting! What we do is just have a branch per issue that gets PRd in, but we do sometimes run in to merge conflicts
@worldsendless that definitely is the better approach. Sadly the way our project was setup is that we have huge issues/tickets per branch that are dependent on multiple points while having way too little developers working on the project. Because for the project we get to migrate the whole app from one language to another one.