Making code better with Pull Requests

Developing software is a team effort. Even when you’re working on a single feature, you’re never truly building alone. The code you write will be read, maintained, and extended by others. Pull Requests help make that collaboration structured and transparent.

A Pull Request is the moment when a developer proposes changes to the code to be merged into the shared codebase. Instead of merging code directly, a Pull Request invites the team to review, provide feedback, and ask questions. It is therefore not just a way to check code, but above all a powerful mechanism for sharing knowledge and safeguarding quality. It creates space for discussion, improvement, and shared responsibility.

The right mindset: shared responsibility

A good PR review starts with the right mindset. Feedback is meant to improve the code, not to evaluate someone personally. It is also a moment to ask questions and learn from what a colleague is doing, can do, or knows. By openly receiving comments, both the author and the reviewer learn from each other.

When you review a PR, you are not just looking along, you become a co-owner of the code. This means taking responsibility for what ultimately ends up in the codebase. In this way, reviewing becomes a joint process where everyone actively contributes to a better end result.

Context is everything

A clear PR starts with a good commit message and description. At Harborn, we believe it is important that it does not only describe what has changed, but especially why the change was necessary. That context helps reviewers understand intent faster and provide more focused feedback.

During reviews, we prioritize. Not every line of code carries the same weight. The focus is on aspects with the highest impact, such as:

• Stability
• Maintainability
• Readability
• Functional correctness

AI tools can help by highlighting potential issues that humans might easily overlook. This allows reviewers to focus more on assessing the PR in the context of what the client is trying to achieve.

Communication makes the difference

Communication is the connecting factor in this process. Asking questions during a review is encouraged. When something is unclear, we dig deeper into the decisions that were made. Sometimes this leads to a discussion that does not immediately result in a conclusion. In those cases, a third person can help break the tie.

And it is okay to make mistakes, the most important thing is how you deal with them. Reviewing each other is not criticism, but an opportunity to improve.

Good communication also means giving compliments. A short remark about a clean implementation or a smart solution makes the review process more constructive and motivating for everyone.

Pull Requests as a way of sharing knowledge

Although PRs happen in writing, not every discussion needs to take place in comments. Sometimes it is faster and clearer to hop on a call, walk over to a colleague, or review code together. Pair programming is a great example of this: a form of real-time reviewing where knowledge is shared instantly.

Whenever possible, verbal feedback is also documented in the PR so decisions remain traceable and everyone has access to the same information. This creates a process that not only improves code, but also strengthens the team and preserves knowledge.

We often see PRs that are too large to review comfortably. In those cases, breaking changes into smaller, more focused PRs helps keep the process manageable and prevents important details from being missed.

At Harborn, PRs are an important mechanism for spreading knowledge within the team. By explaining the “why” in comments, we make decisions transparent to others. Sometimes a review even leads to no changes being made, because the current solution is the most practical for now. That is also valuable knowledge. In this way, every PR contributes to a shared understanding of the codebase and the decisions behind it.

More than a technical process

Good Pull Requests are more than a technical process. They lead to more stable software, fewer production issues, and more predictable releases. By structurally sharing knowledge through PRs, we reduce dependence on individual developers, improve the maintainability of our codebase, and enable teams to scale more effectively.

This results in less rework, lower long-term costs, and above all: greater trust from clients that we deliver sustainable, high-quality solutions.

But perhaps even more important: PRs show how we work as a team. Not as individual developers writing code, but as a group taking shared responsibility for what goes live. That collaboration is where the real strength lies—and the reason a Pull Request is never just about code.