Pair programming is an extraordinary way to learn, work with others and contribute. From increasing code quality to building bonds there's so many benefits to it. In fact, there's so many benefits we wrote a whole separate blog about that which you can read here!

And there's definitely an art to being a great pair. And you want to be a great pair, don't you?

1. Preparing and planning the day

1. Care about your pair! Ask them how they are feeling. Are they tired, or need emotional support? You're both human - this is the best time to check. This should also set the scene for the rest of the day. You might like to say something like: 
   
   "If you start to feel a bit lost or left out, please let me know. I'd much rather you say. If you don't mind, I'll do the same."
2. Plan your work. What are you hoping to get out of the session? What's the goal? What do you want to learn? If you work for a business that implements agile, what did you commit to in the stand-up?
3. Set everything up. Make sure you can both see the screen and read the text clearly. Set the screen up at a height that encourages good posture. You don't want a bad back from all that slouching!
4. Check the code. Where are you up to? What's the starting point? Is everything working as you expect so far? Are tests passing?

2. Work Together

1. Listen! Almost all of us have a habit of focussing on our own ideas, but there will almost always be someone with a better idea - and that person might be your pair. But if you don't listen, you might never know... And don't interrupt. Interrupting means not listening!
2. Suggestions (not orders!) Say "I think a .map() might work well here, what do you reckon?" Don't say "Ok, now create a .map()".
3. Driving? If you're the driver, your primary job is to write the code. But it isn't your only job. You should keep up a continuous stream of questions about why you're doing things this way, and offer suggestions or solutions to problems. Keep the navigator engaged. Most of all, as the driver, you need to trust the navigator. Ultimately they have the final say, so it's up to you to communicate effectively to write the best code possible.
4. Navigating? If you're the navigator, then your job is to take overall control of the situation. You should discuss and ask questions, but you should have the final decision. When communicating, you'll need to put your efforts into making sure what you're saying is clear, and offering a "why" as to why you've chosen this particular solution. Make sure you wait for the driver to finish what they're doing to point out mistakes. Ensure you leave enough time for the driver to digest what you've said and make some progress. And if you've got design or refactoring issues to bring up, make sure you wait until the task is complete!
5. TDD! If you're writing code ripe for applying TDD principles, stick to them. Test first, code second!
6. Commit regularly. This gives you a "save point" in case something goes wrong, especially if you're learning! It also helps you verbalise what you've achieved so far and it's a good time to celebrate progress! It's also a good time to switch roles and helps get a rhythm going.
7. Share. If you know something your pair doesn't, then this is the perfect opportunity to help someone develop their skills. You can help them by asking questions to help them find the solution. Make them feel comfortable to ask questions. Remember, it's not about being "right", it's about writing the best code.
8. Don't speed off! It's tempting, but if you understand something and your pair doesn't, you don't want to be that person that just gets on with the job without another word. That is not the point of pairing! Plus, explaining something to someone else helps you consolidate your own knowledge.
9. Ask questions. If you don't understand something, say. You're here to develop as well as to code. Watch out for patterns or methods that your pair is using that you might not have thought of.
10. Ask for input. Ask questions like "how would you go about solving this?" or "what do you think we should do next?" or "what tools should we use here?" Two brains are better than one, and this is a great way to learn and develop!
11. Ask for feedback. Constructive feedback is a gift, even if it isn't always easy to take. Opening that conversation may make your pair feel ready or more comfortable receiving feedback, too.
12. Take breaks! Resting your eyes and having a stretch are really important. Not just is it good for your body, but it's good for your brain too. And when you get back, you'll be able to look at your project with a fresh pair of eyes!

3. Finishing up

1. Clean up. Check you haven't got any broken tests, messy code or uncommitted changes.
2. Push. Get all of the work you've done up from your local machine and onto GitHub.
3. Review the day. What've you learned? What've you achieved compared to your goal at the start of the day? What did you find hard? What will you do differently next time?
4. Contribute to the stand-up. If you're in a business which follows agile practices, you'll likely have a stand-up at the end of the day. You might find it helpful to make a few notes beforehand to remind yourself of your thoughts.
5. Prepare for the next day. There's nothing worse than coming into work in the morning and not knowing what the plan is! Make some bullet points on what you'll contribute to the stand-up, if you have one.

Northcoders lives and breathes an agile-inspired teaching environment, and is the perfect place to learn not just how to code, but how to be a software developer. 

If you're thinking about that career change, head over here to find out more!