6 months ago, I had barely written a line of Java. Now, I can feel a marked improvement, I can read code and understand what is going on. I can understand how to make simple changes to the code given a requirement, and I know where to go in our enormous code base to find the touch points of a change. I can honestly say that the biggest advancement in my learning has come from pair programming.
Pair programming is where two people work together at one workstation with one keyboard between them. One will be the driver (they will be the one typing), and one will be the navigator. The two will frequently switch roles.There are several different flavours of pair programming, of which I have come across two:
- Ping-pong programming – one member of the pair will write the failing test, for the other member to then take the keyboard and write the code to make the test pass.
- Strong-style pair programming – the driver acts as the “hands” for the navigator, and literally doesn’t type a word of code until they are told what to do.
Of these, the second is extremely effective in allowing someone like myself to learn how things work. Pair programming in itself has other benefits for code quality, test assurance, readability and collaboration, but the focus of this post is on the learning benefits it brings, particularly to those with less experience.
Imagine sitting at a workstation, in front of a code base that you’ve never seen before, with limited understanding or experience in the language it’s written in. Now imagine being given a requirement and being told to implement it! This is (to a degree) what my first few months in my previous role felt like – I had a supportive but very busy team who would help out when I asked for it, but for the most part Google was my best friend. I did learn, after about 12-14 months I felt comfortable making contributions and involving myself in the more complex tasks, but that first year was very much me picking up relatively simple tasks and taking a long time implementing them – calling a colleague over every so often to check if how I’d done something was “correct”.
Now imagine sitting at a workstation, in front of a code base that you’ve never seen before, with limited understanding or experience in the language it’s written in and being given a requirement and being told to implement it. However, this time you’ve got someone with even a little bit more experience and all that is asked of you is to type what you’re told to. You will immediately feel comfortable picking up any story on the board, because you’ve got a safety net. You also know that you’re going to be told what to do, so really the only prerequisite is that you know how to type (and if you’re in a developer role that’s kind of a given). So initially, your pair tells you to “press shift+F6” and rename a variable, or Ctrl+Alt+M to extract a method and you see all this cool stuff happening (shortcuts are IntelliJ specific! 🙂 ). After a while, s/he can simply say “extract this into its own method” and you’ll know immediately what to type. Initially, you’ll be told “type BankAccount account = new BankAccount();”, after a while, your colleague will simply say “initialise a new BankAccount object” After maybe 2 hours of this, you suddenly know some of the basics that would have taken days of “Googling” and practice for you to master on your own. Not only this, but you know that everything you’ve typed is “good code” (at least by your colleague’s standards) – which, as someone who’s learnt from zero both ways, is a huge deal when you’re starting out.
Another thing that I personally feel is a massive benefit of this collaborative way of working (and often overlooked) is that you learn how to talk about the code. This may seem trivial to a lot of people, particularly those with experience in coding, but as someone from a non-technical background, knowing words like “initialise”, “extract”, “schema”, “interface” etc is not something to be taken lightly. You feel much more confident making contributions if you feel like you know what you’re talking about. What’s more – when other people are talking, you can understand what they’re saying much more easily. If you’ve got a beginner on your team, words that have become part of your day to day language may seem completely foreign to them, and as the junior on the team, for them to constantly ask what something means is difficult as it highlights their ignorance. I remember having to look to my mate Google a few times, look up the word and try and figure out what was said based on the context, which is tough when conversations are riddled with these things.
Having a pair also means that you can bounce ideas off someone else much more easily. In a large group of new people (or even just more experienced people), it can be intimidating to make a suggestion for how you think things could be improved, for fear of the idea being shot down. Even if you do pluck up the courage to suggest something, you very rarely understand why it’s a bad idea 🙂 In a pair, with the code in front of you, you can confidently make a suggestion, because if it’s a bad idea your pair can explain why in your terms and you learn, rather than feeling like a fool in a larger crowd. It encourages further questioning and suggestions, (and when a suggestion is taken seriously it’s an amazing boost of confidence!)
Pairing is also a lot of fun! So if you’re a beginner, or have one on your team, try out Strong style pairing and see the benefits for yourself 🙂