Pair Programming: Teaming up to improve GC services

Have you ever faced a problem that didn’t have an obvious solution? At CDS, developers working on our platform products regularly need to work together to troubleshoot and address challenges.
We sat down with Dave Samojlenko and Pete Thiessen from CDS’s Platform team to learn more about how they’re collaborating using pair programming to improve GC Forms.

Meet Dave, Pete, and GC Forms

Dave joined CDS at the very beginning, when it was just a small team in a boardroom and he was the first developer at the organization. Since then, he has done a little bit of everything: from helping to build and launch CDS’s first product, to setting up security and infrastructure around our fleet of laptops, to procuring and configuring the WiFi network at our former office, to managing some early iterations of our cloud environments. Eventually, he came back to developing full time and is now a senior developer with the CDS GC Forms team.

Pete joined CDS pretty recently (about a year and a half ago), and before that he worked in the private sector. He is currently a senior front end developer with the CDS GC Forms team. He also spent some time working with the W3C working group (a web accessibility initiative), as an “invited expert”. When Pete eventually left this group, he took what he had learned about accessibility with him as he worked on new projects. His work on the GC Forms team focuses both on development and accessibility. 

GC Forms enables public servants to build online forms themselves with no coding required. The form-building flow and guidance is tailored to help teams meet Government of Canada (GC) requirements; including compliance with accessibility, bilingualism, and security requirements. You can get started with your GC email address, and build forms anytime for free! 

Let’s dive in to hear from Dave and Pete about how they’re working together to improve the accessibility of GC forms.   

Pair programming: What it is and how it works

Pair programming is a form of collaboration between developers where they work together on the same code. It’s similar to when one person is driving a car and the other person is sitting in the passenger seat. The “driver” focuses on the coding, while the “observer” provides real-time feedback. 

In the case of pair programming, backseat driving is a good thing! While the driver is focused on what is immediately happening, the person in the passenger seat can look at potential routes and keep an eye out for what is coming up ahead. If the driver gets stuck, the observer can think ahead and provide potential solutions. This creates an immediate feedback mechanism.

We’ve come across this form of collaboration throughout our careers. In fact, many developers do it without even thinking about it. We often gravitate towards other developers when we face a problem we can’t solve. In an office environment, it’s not uncommon to see developers bring their chairs over to their coworkers’ desks to discuss a problem and collaborate on code writing.

Pair programming for GC Forms 

Pair programming allows for different developers to use their various areas of expertise. In our case, one of us had a lot of experience in web accessibility coding and accessibility development (Pete), whereas the other had a lot of experience with configuring and running software builds and server infrastructure (Dave). Pair programming creates space for developers with complementary skill sets to work and learn together. 

Within the GC Forms context, we’ve used pair programming to solve problems, such as an underlying accessibility issue with a new design feature. We had both been working together on issues before, and at some point we decided to call what we were doing pair programming. So when one of us approached the other and asked whether we could do some pair programming, it set our expectations about what we would be doing and how. 

Altogether, we spent around 7 hours pair programming a solution for the accessibility issue. We split it up over a couple days so it wasn’t too intense (a few hours in the morning, a couple more in the afternoon, and a couple the next day). In our case, we stuck to the same roles (“driver” and “observer”) the whole time. However, you can always switch roles if you want! We also did pair programming remotely. Instead of sitting at the same desk, we used the screen sharing function on Google Meet. 

There wasn’t an obvious accessible solution to our problem, and when this happens pair programming is a great way to get a different perspective and brainstorm/test solutions. However, pair programming isn’t only a tool for solving accessibility problems. Anywhere you run into coding problems that don’t have straightforward solutions is an opportunity to use this process. 

Working remotely, developers can get siloed. We have a tendency to try and solve problems on our own, especially when it takes a little more effort to intentionally set meetings instead of just being able to pull up a chair in an office. Luckily, tech has evolved a lot over the last few years, which allows for remote pair programming to be more seamless. 

As far as tools go, we kept it very simple: 

• Google Meet (or sometimes Slack Huddles)
• Visual Studio Code (this is just a code editor, any code editor will do)

Other tools do exist! Tools like VS Code Live Share or Tuple allow for developers to work on the same code at the same time, allowing them both to modify the code in tandem.

Pair programming: Accessibility and beyond

We have found that pair programming creates a more efficient means of going back and forth with ideas and testing for a solution to a complex problem, and it’s benefited the GC Forms team in improving the accessibility of the product. It allowed us to test as we went.

In our case, we were able to recognize the problem and share our thought processes on how we could potentially fix it. This allowed our partner to think through things differently and provide their own ideas, as well as allowing people to play to their skill sets and look at problems from a different perspective. 

Pair programming makes finding solutions to problems fun! It stopped us from being siloed, and allowed us to work together and talk through solutions, while having fun doing it.

How can GC teams use pair programming?

We recommend using pair programming for any coding issue that doesn’t have a simple solution. It also doesn’t have to be used only within the accessibility context, so developers can use it throughout their coding work. This isn’t a new concept. For years, developers have recognized the importance of helping and sharing tips and ideas, but pair programming puts a name to this collaboration, and allows for developers to do it in a fun and efficient way. 

Tips:

1. Be mindful when pairing personalities. Don’t force it, otherwise it won’t work. 
2. Know it’s a social activity. Some developers aren’t comfortable with this. So be aware that pair programming is not for everyone. 
3. Stay open-minded. It can be scary having someone watch you code. You start thinking “Am I too slow?” “Am I doing it wrong?” “Should I still be self-editing?”. Pair programming forces you to be a bit vulnerable when it comes to code writing, but that is when the ideas start flowing! Take a deep breath and allow yourself to teach and be taught. 
4. Keep things organic. Aside from assigning the “driver” and “observer” roles, everything else can be pretty organic. Keep the interaction fairly conversational and switch roles whenever it feels right. If you make it too rigid, then it takes away the fun!
5. Be aware of your coworkers’ strengths and weaknesses. For example, if you are the observer, but you know that the driver can’t listen to talking and type/code at the same time, keep that in mind when giving feedback. 

Give it a try!

Are you thinking about using pair programming in your own work? Let us know!
Interested in learning more about GC Forms? Register for a demo today!