# Pair Programming

## The What

What is pairing programming really for?

> <mark style="background-color:green;">Pair programming to exchange knowledge among people</mark>

The main goal of pair programming is knowledge sharing - an activity through which knowledge is exchanged among people.

> <mark style="background-color:green;">Pair programming to the rescue</mark>

Check out Eric Elliott's post about pair programming :point\_right: [here](https://medium.com/javascript-scene/stop-wasting-time-pair-programming-rocks-4a99604cb09d)

## The How

### For Ramping Up New Team Members (<mark style="background-color:green;">effective</mark>)

It is not uncommon to pair an existing team member with a brand new team member. Information like domain knowledge, internal tooling, and existing ways of working can be passed along to the new team member.

### For Upskilling Juniors (<mark style="background-color:green;">pretty common</mark>)

Kind of like knowledge sharing, but focusing on upskilling juniors. I'd say pairing isn't the most productive way to upskill juniors. There are other alternatives like code review, training, knowledge sharing sessions, etc.

### For Firefighting (<mark style="background-color:green;">it's a must</mark>)

The production environment is on fire and needs to be fixed as soon as possible. How you apply the hotfixes is an anti-pattern and in a rush. e.g.,

* ClickOps
* Deploy the latest working image on your dev machine
* Run SQL scripts to fix broken tables
* Run shell scripts to fix a broken node

### To unblock yourself or your colleagues (<mark style="background-color:green;">do it</mark>)

It is what pair programming is for. Do it often. Do it whenever you need help. Do it regardless.

### Troubleshoot Defects (<mark style="background-color:yellow;">can be helpfu</mark>l)

Sometimes, an extra pair of eyes help you find more clues about what you're looking for.

### Avoid Bugs (<mark style="background-color:yellow;">okay but costly</mark>)

It shouldn’t be the goal, instead, it is the happy outcome we got by accident. Bugs should be captured via code review, unit test, integration test, end-to-end test, and monitoring and alerting system.

## :red\_circle: Red Flags

* Paring can be exhausting.&#x20;
* Pairing doesn't work for everyone
* 100% pair programming can harm productivity and responsibility. Don't do that.
* <mark style="color:red;">Shared responsibility is no one’s responsibility</mark>

## :scroll: Tips

Pair programming is excellent and we should definitely use it when appropriate, but don't go too far on that track as its drawbacks are clear.

## :hole: Pitfalls


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://jamiewen00.gitbook.io/tech-lead-handbook/engineering/pair-programming.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.