Pull Requests are dragging you down | Things I don't like | Software Development | CI/CD

Pull requests were born out of necessity in OpenSource projects, but they are dragging us down in our agile teams and we need to address this issue.

Follow me:

[BeheadedKamikaze]

Hey Mati, you're so right! I just did a synchronous in-person code review with my consultants today (I work for the client company) and it went so much better. We were able to address all the concerns already raised by others, they were able to teach me about the context of why they were doing what they did, and I was able to teach them some best practices at the same time. We got done in a really short time and now the feature is ready for QA. 🥳

[solisarg]

Hola Mati, I see your point specially regarding the chance to face unknown code from a random client, so in a consultancy context, pair programming with client devs is a win-win. But once trust is constructed, after a few months (and your company keeps clients for more than 10 years or more) having 2 devs working on the same issue imply more resources (in time or devs) and guess what?
Pair programming is great and usually teams should enforce doing it from time to time, but face it, in usual environments (even consultancy or final) that's force 2 devs on the same feature most of the time, doubling team or time, kind of similar of what happens with PR, but PR has the advantage of asyncronous..Team leaders need to push devs to review asap any PR (and I hate reviewing, until i decide to make a routine) Despite all the studies, average standard industry is to use PR even in product companies (after years of consultancy I'm finally on product world) because in the end syncing the whole team and keeping more people on it is more in the learning side than on the productivity one.

Saludos a todos los AOLERS, dispuestos a conquistar el mundo !

[GizmoMaltese]

I remember the days before pull requests destroyed programming. The value add of PRs is not worth the loss of efficiency.