Chemaclass - code-review

Ship, Show, Ask

2025-04-12T00:00:00+00:00

In fast-moving teams, one of the biggest tensions we face is this: How do we keep shipping without compromising quality or collaboration?

The traditional approach to pull requests often slows things down. We wait hours, or days, for approvals, even for trivial changes. But the alternative, merging directly, can feel reckless or invisible to the rest of the team.

That’s where the Ship-Show-Ask strategy comes in. Originally described by Rouan Wilsenach, this model offers a more flexible and thoughtful way to handle code changes. It’s not just a branching strategy, it’s a shift in how teams collaborate, trust, and take ownership.

What is Ship, Show, Ask? #

It’s a model that classifies changes based on how much review they require:

Ship: Merge directly to main (without a PR)
Show: Open a pull request, but merge it immediately
Ask: Open a pull request and wait for review

The key idea is to use Ask as the default for most work, fall back to Show when the context makes it safe, and avoid Ship (or reserve it for extremely trivial cases, if used at all).

Why I prefer to Ask and Show #

Treat every change, even the small ones, as something worth sharing. I always create a branch and open a PR. It provides visibility, builds a shared history, and creates a space for optional or asynchronous feedback. It’s working with the garage door open, applied to code.

But not all PRs need to follow the same review process.

I default to Ask #

I prefer to wait for a peer review when:

The change involves risky or complex logic
It could impact other developers or teams
It introduces architectural or structural decisions that haven’t been agreed on yet
It benefits from shared input or a second pair of eyes

That said, Ask doesn’t mean over-engineering the process. Often, one thoughtful reviewer is enough, especially if they’re familiar with the domain. If the change touches a specific area, I’ll ask for feedback from the person who owns (or best understands) that part of the code. It doesn’t need to involve everyone.

In small teams, requiring two approvals on every PR can quickly become a bottleneck and slow down the delivery of value. The goal is alignment and quality, not ceremony for its own sake.

I use Show for safe, low-impact changes #

I might merge immediately when:

Practicing pair programming (the review already happened live)
Fixing typos or broken links
Updating documentation or changelogs
Refactoring within a module I own
Adding tests for existing behavior
Making non-functional tweaks (formatting, logs, comments)
Applying UI or style adjustments with no logic change

The key principle: Show is optional, never mandatory. I choose Show only if the change is low-risk and fits within team expectations. When I use Show, I own the outcome. The responsibility is mine.

Why this approach works for me #

This model helps me:

Ship faster without compromising quality
Work with greater autonomy and ownership
Avoid bottlenecks, especially in small or async teams
Foster a mindset of trust, accountability, and thoughtful decision-making

It shifts the goal from getting approval to sharing intent and owning the outcome.

What makes a good “Show”? #

A Show PR might be the right choice when:

The change is trivial and within my area of responsibility
No one is available to review, and waiting would block progress
The PR includes clear context and reasoning
I’m open to post-merge feedback
I’m ready to follow up with adjustments if needed

Tips for making it work #

Some practical advice from experience:

Clarify team expectations for when to use Show vs Ask
Always provide context in your PR, even if merging immediately
Write tests for any new logic or behavior
Welcome post-merge feedback, review doesn’t stop at merge
Reflect regularly as a team and adjust the approach as needed

Ship, Show, Ask is more than branching hygiene. It builds a culture of clarity, accountability, and trust, where developers move fast while staying thoughtful.

If you’re tired of slow PR queues and over-engineered approvals, try it on your next change. Want to dive deeper? Read Rouan Wilsenach’s original post.

Match the review to the risk. Own what you merge.

Pull Requests vs Pair Programming

2021-04-01T00:00:00+00:00

Let’s talk about the benefits of Pull Requests and Pair Programming, and my thoughts on these after some years of experience with them.

Pull Requests #

A Pull Request (PR) is basically a way of showing your suggested code changes such that they are easily comparable with the existing source code. This is part of a workflow that helps developers to share knowledge about the changes that are being done within the system.

A Pull Request is the moment where you ask your peers to review and check out your code changes.

Usually, it’s also used:

For discussions about code style.
To spot potential bugs.
For architectural or design discussions once the solution is done.

Pull Requests aren’t the best tool for everything #

The main problem with these topics above is that PR’s are usually ready when the feature/bug is already being worked on and in the last stage of its development process. It [a PR] is an “already changed proposal [I have already worked on this change, here’s the code] to be merged into the current system [someone please look it over]”.

The concept of “Draft PR” exists to make explicit that a PR is not ready to be merged, so it’s still a “work in progress thing”, but that’s another topic.

Pull Requests are, indeed, one of the best tools that we have in our industry to share knowledge about the changes that we are doing in the system, but sometimes they might be misused, as for example:

Discussions about code style. Code style shouldn’t be discussed in a PR. There should be already a CI running a code style checker, that’s all. If you want to talk about code style, request a change in your code style checker, but not in a random PR.
Spot bugs. Bugs and desired behavior should be covered by automated tests. The developer is the first responsible person for this topic.
Architectural or design discussions. Once a particular solution is developed and ready for review, it is usually really hard to “rollback” that idea and rewrite it again. Because “why would you do that? For some subjective opinion? It’s done already. And it seems to work just fine.”

Having an extra person looking at the changes that we have done for “designing decisions” might be beneficial, but we could have addressed “potential disagreements” in a sooner stage.

What should the purpose of a Pull Request be? #

Sharing knowledge about the proposed changes with the team.
Ensuring the team aligns and agrees across the multiples changes that are getting submitted every day in order to keep a healthy direction for the project. Yes, this might include double-checking the outcome design, but… What if that is now too late? How could we solve all those issues?

Pair Programming #

The concept of “Pair Programming” can be understood from different points of view. Pair thinking and pair programming, driver-navigator roles concepts, or pure live coding from one side. Actually, this is way easier than it looks like at first instance:

Either you watch and help the other person to write code,
Or you type while getting another pair of eyes watching and helping you.

Pair Programming helps the team to work together.

Pair programming is the joy of working with an extra brain and another pair of eyes, where the key is to build a context where you two share the same goal in order to find the best possible solution. All of this while learning from each other every single second. Pair Programming is not about developing the best solution at the very beginning. It’s about making it work, sharing ideas, and finding a better solution together. After that, you can refactor and clean the code.

Pair Programming is a continuous code review #

Pull Requests are an asynchronous way to share code changes, while Pair Programming is totally synchronous because it happens at the same time.

That said, Pull Requests and Pair Programming aren’t mutually exclusive, they can coexist. They are tools, and we should wisely choose them in order to achieve our objectives.

The most common fear that I saw while encouraging to do Pair Programming is that some people are shy and they don’t like to have other eyes around them while they are coding because of:

Fear that they don’t know what to code or where to start.
Fear that others will laugh at their solutions.
Fear to not succeed in public.
Fear to not be able to develop the expected solution for multiple reasons: misunderstanding the task or lack of knowledge.
Fear to change your mind in front of others.
Fear to discuss and make decisions loud.
Fear of disagreeing with others.

After several years of experience on this topic #

The pattern which rejects Pair Programing is basically “fear”, and being out of your comfort zone. And this is due to the misunderstanding of the roots of the actual Pair Programming concept.

Pair Programming is not “to show off in front of your colleagues” or “to be screwed by your peers”, but to be transparent (showing your skills as they really are) and improve as a team lifting up each other.

Programming is an iterative process that needs a continuous refactoring of our way of thinking in order to achieve better solutions, day by day. Therefore, programming with another person next to you (with a different way of thinking) will help the team to get the best from each other while discarding the waste or bad habits if necessary.

Pair Programming doesn’t need to be always set for everything. As a tool, it’s flexible, and we can choose how, when and for what reason.

A personal rule of thumb, before starting tasks that might involve touching multiple modules or complex business rules, think about a quick Pair Thinking/Programming with another more experienced colleague in that field.

Everything depends on a particular context and people: the developers, the pairs, the tasks, the mood.

Still uncomfortable with Pair Programming? #

If you still feel uncomfortable having another person next to you while you write code, it might be because you aren’t particularly happy with your own code, or the process that you follow in order to achieve some result. My favorite way to work on this is by exercising on your own and working on improving your skills as a software developer.

Create and play around with your own pet projects.
Work on code katas on your own and with others.

Practice makes the master.

Keep pull requests, add pair programming #

Don’t get me wrong, Pull Requests are great. Keep doing them.
Team collaboration is essential. Pair Programming aims for this.
Pair Programming encourages the team to proactively work together.
Don’t be afraid of coding while having eyes around you. Ask questions when something is unclear. Ask for help when you don’t know how to solve something.

It’s totally ok not knowing everything. The most important thing is to know how to work together.

Sharing Your Git Patches

2020-12-01T00:00:00+00:00

Discover another way of sharing suggestions with your development team.

Imagine this situation #

You are reviewing a Pull Request (PR), and you see some minor improvements or suggestions that you would like to share with the author. You might write some comments, and usually, that would be sufficient.

Imagine that in order to transmit your “whole idea” you would need to change some files because just communicating the full picture will end up in a huge comment which might be not as clear as it could be.

What possibilities are there apart from just comments in a PR? #

Well, there are multiple options. The key is to be aware of them and use them wisely depending on the priority of the task and the changes themselves:

As already mentioned, writing a comment as feedback is a good idea by default, but not the only one.
We can always do some pair-thinking, talk at any time. Communication is always good in order to clarify the possible uncertainty.
Sharing your git patches is another good option.

Git diff to the rescue! #

What if you (as a reviewer) could share your idea without any single commit or comment in the PR, but sharing your changes directly with the author?

Well, that’s actually possible and really easy. As you already know, the git diff command gives you the differences between any two branches.

git diff origin develop > ../my-origin-develop.patch

What we are doing here is redirecting the output of the diff command into a file (aka: patch), so we can share that output with any other peer-team.

What now? #

Well, having that patch file, it’s pretty easy to apply those changes in your local machine without doing any commit:

git apply ../my-origin-develop.patch

Applying this patch will simply change your local system in the same way the patch was created.

“How to” by steps #

Let’s divide the responsibilities into two: the creator of the patch and its user:

The patch creator: the person who will create the patch #

# Checkout that branch
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Do your suggestions and changes in the targeted branch
# Generate the patch file using the diff command
$ ~/myProject git:(the-branch) ➜ git diff > ../your-diff.patch
# Share the patch file with the author of the PR

The patch user: the person who will see the patch #

# Ensure you are in that branch
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Apply the patch file
$ ~/myProject git:(the-branch) ➜ git apply ../your-diff.patch

References #

Official documentation for “git apply”