Pair programming is no new topic and has been widely used in the industry. At first, it might seem like itʼs a waste of time because two coders work in the same station. However, it provides values like team building and less defective code.

Although code reviews provide a degree of control in written code pieces, a second person makes sure, hopefully, nothing has gone off the road. The practice is to have a pair review the code while the coder writes it. Thus, the code doesn't need further code review. So, thatʼs what I and others have heard called “shoulder ship it.”

Shoulder ship it!

When Shoulder Ship It Makes Sense

I believe having a second eye is important in some cases. Nevertheless, I donʼt see much value in having pairs constantly, because some (at least half) parts of software are trivial. Iʼll list the cases where I think shoulder ship its can take place.

Somebody New

When somebody new joins the team, pairing helps them learn existing systems and bring a completely new perspective. It accelerates onboarding and builds shared understanding faster than documentation ever could.

Critical Production Bug

It might be necessary to do a quick fix. In this case, a second eye is very important. Although acting rapidly on these cases is crucial, you become more vulnerable because of stress. Having a pair reduces possible mistakes and keeps judgment sound.

Vital Components

Some components are more important than others. Whenever you feel like you are dealing with the heart of your application, support from your colleagues might be indispensable. By pair programming, you offload some heavy lifting to your partner so that you donʼt get drowned.

Final Thoughts

There might be other examples, but these are the most common scenarios Iʼve encountered. Shoulder ship it works best when used intentionally, not as a default.

Happy shoulder ship its!