Around June of 2019, when I was in between jobs, I decided to kill time by offering to do some pair-programming with anyone who would want to give it a try.
Pair-programming can be a rather strange experience if you are not accustomed to talking about your code to another person. But it is a muscle that you can train and something you can adopt as part of you software development workflow.
Format
I created a Calendly schedule and let people book 2 hours slots between 2 weeks in June. The sign-up form included questions about what they would like to achieve.
In order to have a productive time pair-programming, I needed a conducive environment. One that is quiet, has WiFi and power, and I can feel free to communicate openly with my pair without being disturbed. Fortunately, my appeal for a free space scored me a 1 month free membership at WeWork.
The venue was the WeWork Labs office at WeWork 380 Jalan Besar. Many thanks for my long time friend Adrian Tan (who runs WeWork Labs) for sponsoring.
Pairing up
Most who signed up were largely of 2 categories.
CTO or newly minted head of engineering
These were tech co-founder or people newly promoted to a technical lead role in their startup.
For them, the session was more like a consulting session where I gave them tips on hiring and managing an engineering team.
Junior Developers
These folks are in their first professional job as a software engineer. They are fresh graduates, mid-career switchers and most of them has not experienced what it was like to write code with pair-programming. For these, I mostly attempted a Code Kata (a coding puzzle) with them.
Bootcamp Students
I also did a session with the students from Trent Global's Diploma in Software Development. They are mostly mid-career switchers. I gave them some advice on how to prepare for the job market ahead.
Practical Tips for Effective Pair Programming
Here are some of the tips that i shared with them.
- Be conversational. Talk through your thought process. Because people can't read minds.
- Plan. Take time to plan what you hope to achieve at the beginning of the pairing session.
- Take notes. I find that sometimes, it's faster to communicate ideas on paper/whiteboard than on the screen. I draw architectural diagrams and bullet points on paper (or on a whiteboard) to brainstorm ideas. An ex-colleague loves to fill up the monitor edges with post-it notes of the task list - and she would dutifully cross them off when its done.
- Agree on a pairing workflow. There are many pairing technique. My favourite is the Ping-Pong method - where one pair writes a test, and the other pair writes the code that passes the test, and repeat. Another technique is a Driver-Navigator method - where one takes the helm (of the keyboard & mouse) and the other guides through the things that needs to be done. This technique is suitable when one has more knowledge of the code base and can help the other ramp up. Agree on a workflow and stick to it.
- Focus on the work at hand. Don't get distracted by non-work PM, emails and social media pings. Don't waste the other pair's time.
- Share keyboard time. Don't hog the keyboard. Let the other pair speak through code as well. Be patient with them.
- Learn all the keyboard shortcuts. This is to be more efficient - reduces the time from thought to code. Also to not waste people's time. In a pairing situation, the pair usually agrees on an IDE or text editor to use. The one who is more familiar with the editor can use the opportunity to do more of the driving and show the other pair the frequently used shortcut keys. If you are afraid of constantly disrupting the "driver" to ask "what keyboard shortcut did you use?", you can try using this on-screen utility to help you display the shortcut keys used: https://github.com/keycastr/keycastr.
- Use on screen cues to help bring focus. Use line number to help zoom in on code. Learn to bring focus to things on screen with the mouse cursor instead of your finger. The other pair's focus is on the monitor, so unless you are using the same monitor, they might not notice where your focus is when you point on your own monitor.
- Take breaks. Do take breaks frequently. Once you reach a natural breakpoint, like after a Git check commit has been made, do take a short break to clear the mind. Pairing can be very intense and involves much concentration and focus - so taking frequent breaks will help rest your mind. As a guide, I take 15 minute breaks between every 1.5 to 2 hours of pairing time.
Conclusion
The session was eye-opening for the devs as it was the first time that they tried coding this way. It was interesting to see how they opened up and we had a good conversation on what the next steps were and how we should go about solving the coding puzzles.
I hope they will continue to learn and grow in their software engineering journey.
Oldest comments (2)
Hey Michael! I am just doing the same thing with my 14 years old son. Sometimes it is much more effective to write a few lines of code for him to understand, than trying to explain with words. Mainly I just write pseudo code for him. It is really fun. We created a pacman clone in three days, and he is proud of himself, and of course am I. Keep coding!
R.
Super excited to be part of this! Always wanted to try pair-programming with someone who has immense experience to see what their thought process is like. Honoured to be able to take part in this.