In my personal experience PRs are almost useless unless all your team knows how to do them well. In my opinion PRs cannot beat a well configured Sonar + CI Server.
You have an amazing Sonar + CI Server if it can give warnings for inappropriate architectural approaches, business requirement issues, or rolling your own libraries when those already exist in the codebase or in existing dependencies.
"PRs are useless".
I'm seriously more and more horrified I would accidentally one day work for that team. I'm sure I'll see a nightmare tonight. Dude you need a good mentor who can show you how it's done. No offense, try to work with people having worked abroad and have a wide experience in leading teams. You have many misconceptions and dogmas.
Then you have no idea what you're talking about. You can configure PRs such that if the code is not building, or passing tests, it will never be possible to merge that code to the main branch. With your approach, this is not possible and who knows if you even pay attention to failing tests at the moment. Because when you're not FORCED to solve these issues, sooner or later somebody will say to leave it to later, because now you're busy with other stuff.
Also, you still didn't answer how you conduct code reviews. I'm guessing you don't. But even if you do, the result is that code pushed to main development branch is messy.
In some other comment you mentioned that developers changed architecture in their feature branches. Well, with code reviews, you'd see that and comment on that and tell the developers to not change the architecture, or resolve the situation before it gets to main development branch.
I'm thinking maybe you just never worked in a technically mature team and you never conducted proper code reviews and that's why you have these opinions.
In my personal experience PRs are almost useless unless all your team knows how to do them well. In my opinion PRs cannot beat a well configured Sonar + CI Server.
You have an amazing Sonar + CI Server if it can give warnings for inappropriate architectural approaches, business requirement issues, or rolling your own libraries when those already exist in the codebase or in existing dependencies.
"PRs are useless".
I'm seriously more and more horrified I would accidentally one day work for that team. I'm sure I'll see a nightmare tonight. Dude you need a good mentor who can show you how it's done. No offense, try to work with people having worked abroad and have a wide experience in leading teams. You have many misconceptions and dogmas.
Then you have no idea what you're talking about. You can configure PRs such that if the code is not building, or passing tests, it will never be possible to merge that code to the main branch. With your approach, this is not possible and who knows if you even pay attention to failing tests at the moment. Because when you're not FORCED to solve these issues, sooner or later somebody will say to leave it to later, because now you're busy with other stuff.
Also, you still didn't answer how you conduct code reviews. I'm guessing you don't. But even if you do, the result is that code pushed to main development branch is messy.
In some other comment you mentioned that developers changed architecture in their feature branches. Well, with code reviews, you'd see that and comment on that and tell the developers to not change the architecture, or resolve the situation before it gets to main development branch.
I'm thinking maybe you just never worked in a technically mature team and you never conducted proper code reviews and that's why you have these opinions.
There is no race between those. Those are supposed to work together.