In software engineering collaboration, platforms like GitHub, Azure DevOps, and GitLab have given us a formidable tool: Pull Requests. They've become the cornerstone for many engineers, a stronghold of quality control before merging code into the main or developed branches.
But let's entertain a notion that often goes unnoticed amidst the enthusiasm for Pull Requests - they can be the silent speed bumps on the road to productivity. "Hold your horses!" you might protest, "Pull Requests are indispensable. They catch errors and ensure code integrity."
That's a fair point, to some extent. But here's the thing: Have we ever stopped to think that maybe, just maybe, relying too much on Pull Requests is like putting a Band-Aid on a deeper issue? Could it be that we're using them to cover up skill gaps rather than bridging them?
Enter an age-old contender from the annals of eXtreme Programming: pair programming. Despite its proven benefits, it remains the black sheep for many engineers—the fear of distraction or the discomfort of someone peeking over their shoulder at their code. But let's be real here - pair programming is like a free course in coding, with the added bonus of having someone to bounce ideas off of. It's like having your own personal brainstorming session but with code. Sure, you have GitHub CoPilot or some AI programming tool these days, but where is the fun in that?
Pair programming and its cousin, Mob Programming, is like pair programming on steroids, but in a good way. Imagine tackling those brain-busting coding problems with a whole squad of colleagues. It's like assembling the Avengers for your codebase. They're akin to on-the-job training, a free-flowing exchange of ideas that can unravel the complexities of coding faster than solitary efforts. As my esteemed colleague Tim Ottinger puts it, they're the antidote to what he aptly dubs "multi-brain problems" - challenges best tackled with collective intellect.
Don't get me wrong—Pull Requests are handy. But sometimes, they can be like that one slowpoke in the fast lane—slowing down the whole process. You know, when you're waiting on that one senior dev to give the green light before you can move forward? Yeah, that.
The Achilles' heel of Pull Requests lies in their queuing mechanism. In the lean philosophy, we've long understood the perils of queues, often manifesting as bottlenecks. Regrettably, this bottleneck scenario isn't uncommon in engineering teams, where a select few seniors find themselves burdened with reviewing the work of their peers.
Pull Requests, in essence, breed a culture of distrust. And perhaps, in some cases, rightfully so. What if a single misstep halts the entire team's progress, all because someone slipped through the cracks? It's a chilling prospect indeed.
However, it's time to rethink our reliance on Pull Requests. After all, trust is good, but a little faith in our fellow devs can go a long way. It might just be the boost our productivity needs.