Pairing is an agile software development technique where two people share a single keyboard station, and work through the problem together.
Agile software development is an umbrella term for a number of principles and methodologies that aim to produce software in an iterative, incremental way. Very broadly, incremental/iterative means making small but working changes to software and continually releasing improvements and adaptations rather than taking 4 years to build a huge software project, releasing it, and then finding the brief has changed. Agile methodologies focus on collaboration, communication, cross-functional teams, continuous improvement, adaptivity and responsivity. Pair programming is a methodology often used in agile software teams for reasons we'll discuss.
You may have also heard of Waterfall development which is the opposite of agile.
We'll talk more about agile throughout the course.
Major companies practice pair programming. Thought Works who are regarded as the biggest and best development consultancy in the world and also have offices here in Manchester pair program 100% of the time.
A lot of companies have a mix between pair programming and non pair programming. They may or may not have rules over percentage times spent on each.
We do it here at Northcoders.
Why do companies do this? Does it not just double to cost of writing software?
The simple answer is no because less errors make it into production and errors are not only a resource cost to fix but they can also be a cost to the business in terms of its ability to make money.
It can also be used as a technique for training new staff by pairing them with more senior developers. It leads to a culture of knowledge exchange which helps staff to grow and develop, in turn leading to more value for a company.
If you have any doubt about how a second pair of eyes and a second brain tackling a problem can be valuable, there are too many high profile examples to list. For example, an $8bn rocket carrying a $500m satellite (the Ariane 5 Flight 501) famously exploded on launch due to a software error where a 64-bit number had been stored in a space only big enough for a 16-bit number. Hundreds of people also lost their lives after a similar problem with a Boeing 787 Dreamliner which has been left running for too long and encountered an integer overflow which shut down the engines mid flight. Also the hole over the ozone layer was ignored for many years because the software was designed to ignore any data it interpreted which deviated too greatly from the norm. In these situations, we have no idea whether, had more than one people been communicating about the code they were writing, these disasters could have been averted. But it's possible.
You don't just learn from us but you also learn from each other. Have a show of hands as to who has learnt something from one of their pairing partners this week.
You will graduate Northcoders as an exceptional software engineer which is great, however to have an exceptional career you also need to be a exceptional communicator. These skills are equally as important. Bear in mind that we are constantly assessing you as communicators as well as coders because we know how much companies value communication skills, and it is us who will be putting you in touch with companies and writing your references. (NB mention lightning talks and other things we do to help develop soft skills)
This will come very naturally to some people but not so naturally to other but its an equally important part of this learning process
Pairing forces you to think more clearly in your mind about the problem you are trying to solve because you also have to clearly communicate something which is very technical.
By having to express your thinking and ideas in words, you learn to communicate technical ideas and use technical vocabulary. Talking through a problem can help you spot flaws in your reasoning and develop a more logical process to approach a problem.
As I said before this will come very naturally to some people but not so naturally to other but its imperative we work hard at it.
Driving is to be actually physically typing code into the editor. The important part is that the Driver is not coming up with the ideas, of course you are thinking about them and there will be plenty of discussion but you are literally implementing what the navigator is explaining to you.
Someone of a similar ability
Junior/Senior?
Someone you work well with
Different pairs every sprint (we often randomize them)
Decide how you will have your screens, etc. Who will begin by driving? How will you decide when to switch? How long? Maybe after each successful commit, or every 30 mins? Pomodoro timer?
Most of our common practices such as the code linter are defined for you. Make sure you are constantly reminding each other about Best Practices. Again its easy to make mistakes but two heads are better than one for spotting and rectifying these.
Ideally we would pair on all sprints. However, we also recognize that people also benefit from time alone to work on problems with no distractions and get into the zone. On 1-day sprints or workshops you will work alone. On 2 days sprints you will spend both days working with your pairing partner. On some occasions we will ask you to go solo after getting to a certain point in the sprint - listen out for instructions on the day!
There a three sprints in a week so this one is easy enough! This rule includes pairing with yourself!
If we are of an odd number someone will be attacking problems on their own.
-
Sprints are short term projects that designed to achieve a specific goal as part of a larger project.
-
They operate on a much smaller time-scale, anywhere from a few hours to a couple of weeks, than a full-scale project. Hence their name.
-
Whilst you are here at Northcoders we will work on Sprints. These will range from 1 to 3 days at a time.
-
In your first sprint, you will be solving some katas to practice your TDD and pair programming skills.
-
Each solution must be fully tested and each piece of functionality tested as separately as possible.
-
You will work in pairs and switch roles after each kata, or every hour at a minimum.
-
Instructions for each sprint will be in the README.md and this first one contains a REFERENCE.md with some useful setup information.
-
Up until now you have been working solo, so when you forked your pre-course from Northcoders you have all had an individual repo. Now you will be working in pairs on the same repo.
-
For this reason, whoever is driving first will make a fork from Northcoders and that is the repo you will both work from.
-
When you have finished working together and move on to the next sprint. If you would like to continue working on it solo then you can make your own fork from your pair and carry on solo.
-
When you are working together on the sprints, you will inevitably reach the point where you become stuck. Being able to overcome these barriers is crucial to your success and you are your pair should apply your 'technical knowledge' (google) to overcome these problems.
-
If you are not making progress or are become stuck for more than 10 minutes, then use nchelp to ask a tutor. When we come to help you, we won't just tell you the answer, but help you figure out what's going wrong and where to go next.
-
We will never let you get completely lost but going through exactly what is wrong with your functions and figuring out how to fix them is the best way of learning.
-
When a tutor comes to help you, it is your job to get rid of them as quickly as possible.
-
You can nchelp when your stuck but you can also use it if your not sure about how something works, or if you just want to check what you've done. It is there as an aid but always try and solve the problem first before calling for help.
A few tips for when you're working remotely and pairing over Zoom:
-
It's always a good idea to keep your video on as much as possible - that way, it's easier to build a rapport with your pair.
-
Drivers, don't forget to share your screen with your navigator!
-
When it's time to switch roles:
- Make sure all your current tests are passing. It's good practice to only commit working code.
- The current driver commits and pushes the work you've done so far.
- The current navigator pulls down.
- Switch roles - the new driver shares their screen.