Pull Requests have become a well-known concept in open-source projects, not in the least thanks to GitHub. But pull requests are also finding their way to the enterprise and closed-source projects. Making pull requests part of your team’s workflow might require some changes to your daily routine, but it will result in better code and better distribution of knowlegde. Let’s zoom in on that shall we?

Experienced developers sometimes have the tendency to think they write great code while the junior developer writes code that needs to be improved. Heck, I’ve encountered not-so-experienced developers that think they write great code (read about the Expert Beginner for a great characterization of these types). We might even say that a truly experienced developer knows he/she writes code that needs to be improved.

But the issue here is that developers sometimes fall into the trap of wanting to check up on the code a junior developer is writing, without feeling the need to let someone check their own code.

Pull requests are sometimes put into place on a selective basis. Bob and Lisa need to create pull requests that must be approved by either Jack or Alice. But Jack and Alice don’t need approval from anyone. This is a surefire way to crush the enthusiasm of Bob and Lisa.

Pull requests can be seen as small code reviews and in that form they do provide learning opportunity for less experienced developers. But this learning opportunity can come from both directions. Let me explain.

Bob, the junior developer, creates a pull request that Alice, the senior developer, takes a look at. She adds her remarks and Bob learns from these remarks.

But take a look at the other way: Alice creates a pull request and Bob has a look. Bob will now see how a senior developer might solve the problem at hand. Bob learns by reading the code, by seeing the design pattern used, by understanding how clean and readable code is constructed. And Bob might even add some valid remarks to this pull request, because even a senior developer can make mistakes.

In both cases, pair programming would have been an even better solution, but maybe that’s not always practical. Pull requests, however, should go both ways, because there’s always a learning opportunity for both parties.