Pairing is daring

WHY PAIR PROGRAMMING SHOULD BE IN EVERY TEAM’S TOOLBOX

Pair programming is old news for most developers. It’s quite possible that you “paired” with a colleague before and might have had some good and some bad experiences. In this blog post, you will get a quick overview of pair programming. You will learn that there are lots of benefits and potential downsides. Additionally, there are some hints on the process and pitfalls to keep in mind. Finally, you will find a quick overview of remote collaboration tools.

BENEFITS OF PAIR PROGRAMMING

According to a study conducted by a Microsoft Research team [1], participating developers reported “fewer bugs”, the “spread of code understanding”, and “higher quality of code” as the main benefits of pair programming.

Fewer Bugs

In many work areas, the four-eyes principle allows teams to spot errors early on. Developers usually conduct code reviews before code goes out to production. Think of pair programming as giving a programmer a second pair of eyes. They might spot bugs right away, leading to reduced friction down the road. The earlier you spot a bug, the easier it is to fix.

@Saad Bin Akhlaq: After a pairing session, I have more confidence in pushing the code since 2 engineers have already gone over it.

Spread of Code Understanding

According to the Agile Alliance, a team that applies pair programming will gain “better diffusion of knowledge among the team, in particular when a developer unfamiliar with a component is pairing with one who knows it much better.” You will notice a “better transfer of skills, as junior developers pick up micro-techniques or broader skills from more experienced team members.” Furthermore, the Microsoft study highlights that “there is never only one person in the team who knows all the code”.

In the paper “The Costs and Benefits of Pair Programming” [2] by Alistair Cockburn and Laurie Williams, they claim that “if [a] pair can work together, then they learn ways to communicate more easily and they communicate more often. This raises the communication bandwidth and frequency within the project, increasing overall information flow within the team.”

@Jobrann Mous: I especially enjoy a pairing session when I am exposed to different topics, codebases, and coding practices.

Higher Quality Code

The authors of the Microsoft study state that pair programming helps to improve code quality “through more extensive review and collaboration.” Also, “‘Programming out loud’ leads to a clearer articulation of the complexities and hidden details in coding tasks, reducing the risk of error or going down blind alleys”, says the Agile Alliance.

In addition to that, a quantitative study at the University of Utah [3] showed that pairs not only completed their programs with superior quality, but they consistently implemented the same functionality as the individuals in fewer lines of code.

Critique of pair programming

In the same study from Microsoft, developers listed cost efficiency, scheduling, and personality clash as their biggest problems when applying pair programming.

Cost efficiency

Management most likely is in doubt about the efficiency of pair programming. In the Microsoft study “the number one problem reported with pair programming is cost. Two people are being paid to do the work of one.” On paper, you halve the allocatable time of two developers. But there are studies suggesting that pair programming actually increases time spent by only 15% (and not 100%), while at the same time reducing the error rate by 15%. [2] Occasional pairing programming will balance out the cost with the benefits.

Scheduling

Yet another meeting? Calendars are already full and scheduling meetings is a pain? Pair programming will not improve the situation. If scheduling a spontaneous pairing session is hard, your team should review the number of meetings in general.

What worked well for the cross-functional engineering teams of Bertha and Mercedes Me Service apps, is a fixed pairing slot every two weeks. The engineers begin the 2 hours slot with a short alignment, check who is available, and what topics they can pair on. Then the pairs (or sometimes groups of more than two) start their sessions.

During sprint planning for Bertha, we schedule pairing sessions to tackle tickets with high estimations together.

The backend team of Reach Me is doing it differently. Instead of scheduling anything, they start their day with a Teams-call which they keep running in the background for most of the day. It simulates a being-together-in-the-office feeling and allows for spontaneous conversations, some of which lead to pair programming sessions.

Personality clash

Pair programming is not the best work mode for every problem. While some of us are happy to collaborate on a task and align with a colleague, others need alone time. They want to play around with different possible solutions, sketch something, etc.

Most programmers tend to shy away from collaborative tasks. They want to be on their own while coding. Practice (and constant nudging) is your only chance to convince introverted people to pick up pairing more often.

There are also big differences in the way people articulate themselves. Pairing a person who thinks longer before answering with a fast speaker might end up in a one-sided conversation. It’s important to give everyone enough space. You don’t need to rush anything.

It is an acquired taste

You sometimes hear “I need to get this done, I don’t have time for a pairing session”. Or “it will take me half the time explaining the issue to my colleague before being productive”. Please reconsider. True, pair programming comes with a cost. You have to set it up, agree on a work mode, explain the context. It adds cognitive overhead. Practice can mitigate most of that. If you are getting used to pair-programming it becomes a standard way of working within your team. Doing so will feel normal, and you will consider it for more and more assignments. Jumping on a pairing session with someone lacking the context should be the outlier.

HOW TO DO PAIR PROGRAMMING

4 simple tips for pair programming. Just give it a try.

Agree on topic and scope

There should be a common understanding of what the problem is, and a general direction of how to tackle it. Keep reminding each other when you are deviating too far from your goal. It’s easy to get lost. Now you have someone helping you to focus!

Pick your role, switch them

Usually, when sitting next to each other at one desk, there is one keyboard to share. This puts the person on the keyboard in a different position than the person next to them. The person who types – the “driver” – is more concerned about the coding details, types, syntax, formatting. The person off the keyboard – the “navigator” – can think about the bigger picture, e.g. abstraction layers, dependencies, potential refactorings, etc.

That situation changes when you are leveraging remote collaboration tools. All participants can now write to the current codebase, they can be “drivers” and “navigators” at the same time.

Regardless of the setup, you should keep all participants engaged by flipping through the two roles. This allows everyone to contribute to the lower-level and big-picture problems.

Acknowledge different pairing situations

You should always be aware of the circumstances and the setting of each session.

@Svitlana Piddubna: “Not all tasks are equally good for pairing, so I think it works best when someone sees a ticket that could be a good one for pairing and offers to work on it together”

Are you and your pairing partner on the same page about the issue? Can you both focus on the issue at hand? Does the schedule suit both of you?

Plan enough breaks beforehand. This allows accommodating for individual daily routines, habits, speed of thought, etc. Especially during a pandemic, we need to pay special attention to a flexible schedule (eg: no daycare!). Some people need their time thinking through things alone. Take a break from the session when needed. Pair programming doesn’t mean you are bound to each other for the whole session.

Consider also the implicit or explicit power dynamic within a pair. An example: You are the most experienced developer in your team. Your pairing partner is a junior member with knowledge of the context, but lacking coding experience. As a senior, you have the responsibility to motivate, acknowledge, and drive the conversation positively. Don’t be condescending, don’t turn it into a lecturing lesson. You only get the inspiration of your counterpart flowing when it is a mutual experience.

Programming out loud

Reflection is an important step in learning. You are allowing your brain to streamline your thoughts on a topic. More often than not, only when attempting to write down or articulate, do you realize that you haven’t understood a problem. Now imagine you are articulating and reflecting on your current assignment. You gain an improved understanding of the topic and your pairing partner gains insights into your thought process.

The Agile Alliance advised, that “‘Programming out loud’ leads to a clearer articulation of the complexities and hidden details in coding tasks, reducing the risk of error or going down blind alleys.”

PRO TIP: Think of TV chefs and how they orate every detail of their process.

Remote pair programming

The obvious downside of remote pair programming is the fact that you can’t grab the keyboard and switch between navigator and driver. The “navigator” is not looking at the same monitor as the person who “drives”. To overcome these barriers, a variety of tools can help.
The easiest and most intuitive solution is simple screen-sharing. If you need more elaborate features, look at tools like JetBrain’s Code With Me and Microsoft’s Live Share. They come with plenty of features to accommodate for a sophisticated pairing session.

Microsoft Teams

At Mercedes-Benz.io the main tool for remote collaboration is Microsoft Teams. Its screen sharing feature already allows for a great remote pairing environment. You set up a call, share your screen, and go. There is even a function to take over the controls of the shared screen. This can be helpful when a topic is hard to articulate or to switch roles between “driver” and “navigator”.

JetBrains Code With Me

The Code With Me service [4] allows any JetBrains IDE user to share and open up their codebase for collaboration with remote colleagues. It works across almost all their IDEs (Android Studio coming soon). You can give your colleagues instant access to your current project. Up to 10 developers can join one session, and collaborate on one codebase. Especially for a mob-programming session, this is quite a valuable solution. Each participant can choose to either sync with (or follow) the “driver” and see what they are seeing, or work on their code area, all within one session.

Visual Studio Live Share

Visual Studio and Visual Studio Code offer a similar service, Live Share [5]. You can start a collaboration session and share a link to it for others to join. You have fine-grained control over the permissions the session members get.

Conclusion

Pair programming is an important tool in the arsenal of software engineering teams. It’s a great way to share knowledge, reduce friction, and increase communication bandwidth. Most of us are currently working remotely. Introducing collaborative work methodologies like pair programming helps you to cope with that. Remote collaboration tools like screen sharing make it super easy to do. Now that you know more about pair programming, try it out more. You will be surprised about the positive outcome!

Reference

[1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/esem-begel-2008.pdf
[2] https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
[3] https://web.archive.org/web/20041129085715/http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.PDF
[4] https://www.jetbrains.com/code-with-me/
[5] https://visualstudio.microsoft.com/de/services/live-share/

Sabine Geithner: “Bertha Benz is a developer.”

Sabine Geithner works as the Lead Link Mobile Engineering at Mercedes-Benz.io. She combines 13 years of experience, working in different leadership roles from Project Management, Online Marketing to Software Development.

Until recently, she worked as an iOS developer for the Bertha app. In her current position, she is in charge of hiring the right mobile developers to drive the mobile strategy of the company, fostering a culture of knowledge-sharing and providing an environment for professional growth for mobile developers.In her second role as People Promoter she helps MB.ioneers set meaningful professional development goals and supports them to achieve these goals. 

Sabine’s career starts with her studies. She owns a university diploma in Biotechnology. The requirement for her first semester was an introduction to Java class. It may seem that Sabine has a bit of unusual career background, although it is not uncommon to find people with diverse backgrounds in software development.

In this interview, we want to find out what makes tech jobs interesting to women and how we can inspire young girls to strive towards such jobs. Hello, Sabine!

You’ve had quite the unconventional career journey—what did your start as a Developer look like?

My journey to software development kicked off when I turned 30 and looked back at my life where I was and where I wanted to be. At that time, I was working as Head of Online Marketing and Consumer Insights. My responsibilities included: writing HTML for our SEO landing pages, as well as analyzing consumer data to get valuable insights. So, I had already learned some web development and was using my rudimentary programming skills, for things like writing VBA scripts for my Excel Sheets and SQL statements for MS Access. 

I realized I actually liked programming and wanted to learn more. I started to look for classes online and in Berlin, where I live. Coincidentally, an in-person program called Rails Girls Berlin (now called Code Curious) had just started. They offered free programming workshops for women. I had missed their first workshop, but I liked their idea so much that I offered to join the organizer team and support with marketing. This was the turning point!

What made you decide to completely pursue a career in tech?

By organizing the mentioned workshops for Code Curious I was able to witness women of all backgrounds quitting their jobs and pursuing successful careers as software developers. It was so inspiring that I decided to leave my own job, spend a few months learning with online courses, find myself an internship, and become a software developer. I was 31 years old when I took that step.

What are some of the challenges you have faced in your career?

When I started seriously considering software development as a career, I received some unwelcome comments from people. They said things like “You won’t be able to learn this so fast. You are learning the wrong programming language. You should learn [insert a preferred language] instead. I would never hire someone who hasn’t been writing code since they were little.” I could have easily been discouraged by their words. Luckily, I like to prove people wrong and understood it as a challenge to show them: it can be done and I will do it.

In the early years of my career, I sometimes wasn’t taken as seriously as my male counterparts and had to have several critical conversations confronting people with their behavior. Often they were completely shocked that they behaved this way and every-time things improved significantly afterwards. I wish I didn’t have to jump into these conversations, however, I can only encourage everyone (especially younger women) to confront such behavior. It helped me, and no one should ever feel intimidated and helpless.

What are some of the positive experiences you have gained throughout your career?

There were positive ones that encouraged and supported me to pursue my dream of becoming a Developer. For example, most of the coaches for Rails Girls Berlin were men and the whole Ruby community was actively working towards increasing the number of women in their field. Also, the people who gave me my very first iOS internship were super trusting in my abilities (I had only done online courses before that) and made me feel at home and welcome in the Developer scene.

There are also many men at Mercedes-Benz.io — who understand the value a diverse workforce adds to our team culture and performance and are actively working on hiring more diverse people.

What does a day-in-the-life at Mercedes-Benz.io look like for you?

There is little to no routine in software development. A “typical day” could look like this:

The day kicks off with a meeting that we call Stand-Up, where everyone gives an update on the progress of their current tasks. We also discuss blockers or topics that need more clarification and then talk about what we plan on doing today. Afterwards, everyone starts working on current tasks. If we work on a new feature, we will meet to talk about how to approach the problem.

These conversations can stretch over several teams, including backend and design. We talk through different approaches or give feedback to someone else’s result. At the end of the day, we publish the code we wrote to the whole codebase and have a coworker give us feedback on our solution. We also create a new internal version, that the team can use to test the new features we implemented during the day.

Let’s take a look at the bigger picture. According to a 2019 study by the UK Department of Education, parents and teachers are less likely to be encourage girls to study STEM subjects. Since only 3% of females say a career in technology is their first choice, a lower female participation in STEM fields equates to fewer female role models for girls.

Why could (or should) women be interested in becoming a Developer?

Let‘s stop putting people into boxes. The job is interesting for anyone who loves logic, no matter the gender. However, I’ve also observed that children’s interests are largely formed by their environment. If you offer girls only dolls and boys only cars, it’s no surprise they end up having a preference for one. I don’t have kids of my own, but I know that my interest in science was sparked at a very young age by getting microscopes and physics toys, so I give the same toys to my nieces. 

Qualities of high-performing teams are made up of a wide breadth of holistic skills, such as empathy, sensitivity, creativity, and more! Regardless of gender, many roles benefit from having these qualities, e.g. the Plant, the Coordinator, and the Teamworker in Belbin’s model of Team Roles. Thus, I am certain that anyone can be interested in becoming a Developer but success does not depend on your gender.  

What is the benefit of working in the tech industry?

Oh, there are many! From a lifestyle perspective, I think no other job allows for more freedom. Working remotely and asynchronously at weird hours has been common for software developers for a long time. This is absolutely perfect for those who want to have lots of freedom or need to juggle jobs and family. It’s also easy to find a job because software developers are always in demand—and always will be!

For me — the biggest benefit is actually the effect it has on your brain. When I started out, it really felt like my brain was growing. I mean it! You often need to keep a lot of thoughts and ideas in your head in order to figure out how to solve an issue. On top of that, it’s a job that requires life-long learning and keeps you mentally fit in the long-term.

Let’s talk about needed skills and interests. What do you think is the most important strength for software developers to ‘develop’?

According to a study published in Nature, the most important strength for software developers is fluid reasoning and memory capacity (the ability to solve problems with logic and to keep several solutions/ideas in your head) followed by language ability. Funnily enough, numeracy (being good at Mathematics) has the lowest correlation with programming abilities.

However, being a successful software developer requires more than just being able to write good code. Developers need to be able to communicate their ideas to their client, their colleagues, and their boss. Communication skills are key. And of course, if you juggle several projects, you need to be organized, too. These skills become more and more important the more seniority you gain, the more you interact with stakeholders and the more projects you juggle at the same time.

How can I start getting into developing? 

  • To figure out if coding is their interest, I recommend codecademy. It’s a gamified way to learn basic programming principles and highly addictive to people who like logical challenges. 
  • For taking a step further, there are plenty of online platforms that offer pretty good courses, many of which are free. For example, most courses on coursera can be attended without paying. I started 7 years ago with team treehouse. I really liked their curriculum back then and it helped me stay motivated. You are learning software development by working on small projects that grow bit by bit and it is extremely rewarding to see the result so quickly.
  • To go the academic way, there is even a women-only Computer Science study course offered by the HTW in Berlin.
  • There are also meetups (e.g. code curious, women who code, women techmakers) in bigger cities where women in tech help others get into and continue learning software development.

What can I do as a parent to bring this professional field closer to my child and spark their interest?

  • For parents of young children, there are also plenty of opportunities. There is the code.org where kids can learn programming while building or playing a game.
  • Some toys help children practice logical thinking and learn the basics of computer instructions, e.g. Osmo.
  • There are hardware kits, like Kano, that allow kids to assemble their own computers and gives them an insight into how computers work.
  • And don’t forget free meetups and workshops (often called “Coder Dojo”) for kids in bigger cities where they can learn coding in a group.
  • One of the founders of Rails Girls Berlin also wrote a children’s book for girls called “Hello Ruby,” which also has a website to help parents with their kids quest to conquer the world with code.

What is your wish for the future of women in tech?

I hope that more women consider software development as a career and find more and more representation in their teams, at conferences and in technical leadership positions. My wish is that we can at one point drop the “female” in-front of the introduction and refer to people who happen to identify as female, just as “software developer” or “CTO” instead of “female software developer” or “female CTO”.

And lastly…why this headline? Why do you think Bertha Benz would be a Developer and active in mobile engineering today?

The headline is 100 percent correct. Bertha Benz would be a software engineer because she was a woman who valued freedom and independence and wasn’t afraid of entering a male-dominated area.

Want to support and inspire women for tech professions, want to change the game, and know talented women who need to become developers?

Share this article
& APPLY NOW