Following several days of diligent work, a duo of programmers working in tandem attained a shared breakthrough. Both individuals excelled in their designated roles, and the team’s spirit was contagious. This kind of success is the ultimate goal of any project manager.
Although this situation may seem promising, both programmers are unaware that it could lead to a stalemate. They are each engrossed in their individual tasks and are eagerly anticipating a code review, inadvertently neglecting to engage with one another. In essence, this is the challenge of the Pull Request.
Understanding a Pull Request
A new and groundbreaking initiative named “Open Source Software” has been introduced. The idea was revolutionary in its straightforwardness; making the source code of a program available to all inspired more coders and programmers to contribute to it, resulting in enhanced software quality.
We had the ability to extract sections of code and implement them into varying projects, or suggest enhancements and fixes for pre-existing software. It was a cooperative endeavor, reminiscent of professional engineering. This method was effective for a while, but had to evolve as the internet expanded and more individuals started producing software.
Consolidating feedback from numerous team members can be a formidable undertaking, particularly when dealing with significant quantities, such as hundreds or even tens of thousands. Although this may appear to be a favourable concept, it can pose challenges for those accountable for the source code. This is demonstrated by the proliferation of communities surrounding projects like PHP.
GitHub provided the solution and quickly became the universal standard for both open source and commercial enterprises. With its advanced source code management abilities, GitHub was modelled on mathematical tree structures and has transformed the way developers collaborate around the globe.
Developers on GitHub can establish their own individual versions of a project through ‘forking’ from the main branch. This provides them with the opportunity to test the code without affecting the production branch.
A developer has the freedom to submit their modifications to the master branch at their discretion, but the branch owner retains the power to scrutinise and either accept or decline the submission.
A pull request is a notification transmitted by a developer upon pushing their branch, petitioning for their adjustments to be merged into the main branch. Git is a platform that empowers software developers to collaborate and exchange information.
When Language Falls Inadequate…
After analysing more than 26,000 developers’ pull requests and 3.9 million comments, the data science team at LinearB discovered some captivating observations:
The assessment time for each Pull Request was gauged to be approximately four days and seven hours on average. If we presume that half of the Pull Requests remain neglected for half of their existence, we can conclude that the average span of inactivity for a Pull Request is roughly two days.
Although it may appear trivial for developers to divert their attention to other facets of the project, this could result in a significant delay if they require a code review. Allowing the mind to wander for 48 hours could have severe ramifications. I have experienced multiple instances in which I reviewed my code after a few days and questioned whether it had been composed by someone else.
Postponing the resolution of any code issues will make it increasingly difficult to address them in the future. As the mental effort required to revisit the code intensifies, the chances of overlooking significant details escalate, elevating the likelihood of future errors and defects.
It is apparent that numerous requests fail to produce any tangible outcomes. The complicated nature of software development necessitates the interconnectedness of all stakeholders to accomplish a successful end result.
As developing software in a timely manner can be complex, working in teams is typically advantageous; this enables the amalgamation of differing perspectives, oftentimes resulting in a more durable and sturdy product.
Conversely, some aspects of our day-to-day regime can be quite isolating. Every programmer is well-acquainted with the sensation of sitting alone in a hushed room, donning headphones, and staring at a computer monitor.
It is imperative to recall that our endeavours and proficiency are critical for the success of others. Developers frequently delay responding to requests “for just a few more minutes” or “until the completion of a task”. This is to avert any disruptions to the workflow.
Resolving the Paradox
As the prevalence of remote work rises, the need for effective solutions to the ‘Pull Request conundrum’ increases. One solution is to seek feedback or a second opinion from a colleague by visiting their workspace for their thoughts and opinions.
Messages sent via chat applications such as Teams and Slack are easier to disregard or postpone, similar to emails. To mitigate this, we are endeavouring to replicate certain aspects of “face to face” communication within our digital environment by transitioning to a phone- and voice-over-IP-centric society.
Certain advocates of a continuous delivery methodology dissuade the use of pull requests. Although this may seem appealing in theory, it can also create its own set of challenges.
As a software developer, you are likely familiar with the benefits of using pull requests to obtain feedback and advice from your colleagues. Experienced team members conducting code reviews can be especially advantageous for less seasoned engineers.
Presently, the originality of human contributions cannot be substituted by automation, and this is evident when a pull request is initiated. A second opinion assessing our code is extremely valuable. The inquiries and feedback we receive from this exchange often broaden our understanding of the issue and aid us in developing our professional skills.
Therefore, a team possessing extensive experience and proficiency may gain from a fully automated solution. Utilising pull requests is an exceptional methodology for fledgling teams or teams with less experienced members to encourage creativity and mentor junior members of the team.
Fostering a positive atmosphere in groups where Pull Requests are acknowledged, and responses are provided promptly is critical. An effective method to reaffirm the significance of prompt replies is to quantify inactivity as a key performance metric.
We may expedite the turnaround time by requesting partial shipments. If the list of modifications is lengthy, the reviewer may be less inclined to dedicate the required time to examine each one. Typically, individuals form opinions and decide on actions based on the amount of energy they anticipate needing to invest. Therefore, if the task demands less effort, they are more likely to act swiftly.
We Possess a Strong Team Bond.
The Pull Request paradox highlights the interdependence that developers have on each other. In the midst of a task, it is simple to overlook the broader outcomes of our actions, yet their consequences can be far-reaching and a team’s accomplishment is only as strong as its least capable member. Fortunately, we are not machines; instead, we possess the potential for education, evolution, and cooperation.
