When you are new to programming — whether it be self-taught, enrolled in a boot camp, or learning a new language, everything can feel daunting. I can relate to this experience as someone who is currently enrolled in a coding bootcamp.
You eventually find your rhythm as you learn to work with these tools by immersing yourself, revisiting syntax, and learning to test snippets of code. And that rhythm gives you the confidence to build on the skills and knowledge as a new developer.
Then everything you worked up to vanishes as you are put into a virtual room (I am currently learning remotely during the pandemic) with a group of your peers in what is called pair programming.
Pair programming is an Agile software development technique used to code, problem-solve, and develop in a pair. As a newcomer to this field, I have yet to develop a firm opinion on this technique, but you can find studies, or articles that examine its benefits.
If you are starting your journey as a programmer or web developer, you will more than likely encounter this practice. The basic premise is that there is a ‘driver’ who writes the code, and a ‘navigator’ who pitches ideas, confirms syntax and conducts supportive research.
I come from a theatre background. This means that saying yes, staying open to ideas, and being an effective team member was part of my craft. When my program introduced pair programming to us with phrases like: ‘eases the workload’, ‘confidence and affirmation’, ‘code quality’, and ‘waste less time’; I was ready to see what pair programming was all about. I was confident in my communication and interpersonal skills to be prepared for this method of coding.
I was completely wrong.
During my first pair-programming (we were in a group of three, which we will touch on later) on the third day of bootcamp, I wasn’t able to problem solve like I used to and wasn’t able to contribute much. I felt paralyzed, unable to think, and it was a frustrating experience overall.
But, thankfully, we were given two more chances to attempt pair programming in the following weeks. I quickly learned that it was similar to working out a muscle. At first, it can hurt (your brain) and get real messy but I came into each subsequent session better than the last.
This is why I want to share some gentle reminders and guidance as you try to navigate this new workflow. This is just a list of reminders I made for myself to be ready, available and embrace the highs and lows of growing and learning as a new developer.
Gentle reminders on pair programming:
- Remember the first time trying to understand loops, functions, and recursion? Similar to learning a new concept, if you are new to pair programming, you are training a new muscle. You will get better at it and find ways to leverage this workflow as you grow and develop new problem-solving skills.
- Approach these sessions with curiosity and openness, focus on listening, and try any uncertain ideas. Before ruling anything out, give it a go until you confirm that an idea does not work.
- If there is some expected reading before the pair programming exercise, take time to put in the prep-work. Suggest to go over some of the important points, or better yet, read out the instructions as one member breaks it down in pseudocode.
- Suggest to pseudocode the solution before writing any code. If you are new to writing in syntax, this is the fastest way to get good at coding. With pseudocode, the skeleton is laid out and the time and effort taken will help encourage clarity and for everyone to start on the same page.
- Explaining a block of code, logic, or syntax in plain speech is a crucial skill as a developer. Your future job interviews may depend on it, and pair-programming is a good chance to practice those skills.
- Strive for clarity in thought and intent. Use file names, line-numbers and communicate in blocks of code. Each member should actively try to further streamline the group communication.
- You may feel inadequate in terms of programming knowledge, but don’t let that get in the way of your session. Especially in a group of beginners, there will always be more efficient ways to refactor, problems to solve, and errors to catch. Be confident with what you know, open to learning, and contribute.
- You may feel that you are more advanced and steering the boat. Don’t let that overshadow your partner and their contribution during the session. As you write syntax, make effort to communicate what you’re doing, and why you’re doing it. To avoid confusion, check in with your partner incrementally. Doing so will ultimately save time and allow you to work more effectively.
- I found pair programming with two people to flow much smoother than with three people. When in a group of three, take the extra initial effort to clearly outline the roles and set boundaries. It will depend on each group, but try to stay as organized and streamlined as possible.
- In a group of three, it is easier for two people to outvote the third. Be mindful and focus on listening. Every member should set their ego aside and understand that all ideas are valid until proven false. In the end, the ‘best idea wins’.
- When you go down a wrong rabbit hole on your own, it’s easier to pivot to a different path compared to when in a group of two or three. Take time to step away from what you are working on, as it may be time to revisit and entertain the logic that your partner pitched twenty minutes ago.
- Getting stuck in a group of three is a real struggle. When two out of three grasps the concept, and the third doesn’t — it can be a huge time sink. Rather than just verbalizing concepts, logic, or syntax — share diagrams, write small snippets of code and run it to confirm the results on a smaller visual scale.
- If you feel that you are over-sharing, you probably are. Check for consent, and ask your group if it’s ok to continue sharing. Your peers will appreciate the check-ins.
- Be open to new concepts and get curious. This is a chance to share knowledge and passion while being introduced to workflows that may differ from your own.
I hope this list of reminders helps those who are about to start their journey in programming. As I fight against imposter syndrome, I’m actively working to remind myself that learning to code is a long-term journey, and any setback is a chance for me to learn and grow.
There are many resources out there to get you more comfortable with pair programming (listed below). I encourage you to seek resources to help build this incredibly useful muscle.