DEV Community

Cover image for Project Collaboration And Pair Programming
Ayu Adiati
Ayu Adiati

Posted on • Originally published at adiati.com

Project Collaboration And Pair Programming

Hello Fellow Codenewbies 👋,

A bit of background, I am a self-taught front-end developer.
In this article, I want to share my experience in project collaboration and pair programming.

A while ago, I had a chance to collaborate in creating a project with vanilla Javascript.
One of the approaches that we did to collaborate was pair programming.

The first time I heard the term pair programming, I imagined two (or more) developers learning the same topics together.
But that wasn't it! 😅

Pair Programming

So, what is pair programming?

Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.
-- Wikipedia

First Experience Doing Pair Programming

As a self-taught, I spent my time learning and coding solo. I solve problems and make decisions alone.
So when I had the chance, I saw the team project as a good opportunity to learn to collaborate.

As the first step, we had a meeting to decide on a project app that we would create and how this app would work in general.

Next, we planned the features that we want for the app and started pair programming to create those features.
So the pair programming journey began.

In the first couple of sessions, I only observed how pair programming works to get a grip on it.
But then, I got confused about what's going on and freaked out!

Before the navigation, some of us were talking over the solutions. But those solutions were not what I would think of as my first approach. So I needed some time to digest them. When two or more people are having the same thoughts, the pace goes faster. That is exactly what happened. I didn't want to break the flow by asking questions or asking them to slow down. And while I was still trying to figure things out, the problems were solved.

The confusion in trying to wrap my head around what's going on while having a somewhat fast pace was the thing that freaked me out. I faced the famous imposter syndrome until I did the next session a few weeks later.

Be The Driver

Although I'm an introvert, I don't have trouble with general communication. But communicating codes and go through them with other people requires another skill. A skill that I'm sure everyone can get better at with practice.

On the next session of pair programming, I got the opportunity to be the driver, the one who writes the code.
This was when I finally learned so many things about pair programming and its benefits.

As the driver, I need to listen to the navigators' instructions and type/write the codes in a good structure.
There were times when the navigators were talking too fast. And there were also times when the given instructions were not too clear, or when I wasn't sure how to write the codes.
When it happened, I had to ask them to slow down, or repeat and give clearer instructions, or told them that I need a minute to google the syntax. These were necessary for me to write the codes.
By listening, writing the codes, and asking questions, I started to understand what's going on and was able to follow the whole process.

Final Thoughts

Pair programming gives many benefits. Some of them that I've experienced are:

  • Learn to work in a team.
  • With more heads solving the problems, the project is done faster.
  • When people talking through solutions, we could gain new knowledge.
  • Everyone learns to listen and communicate better as a team.

For self-taught developers, it would be a challenge to get this experience, but it's not impossible.
Try to find a community to open up a chance for you to collaborate on a project, and even for networking.
If you're doing an online course on Udemy or any other platforms, you can try to find a study buddy and do pair programming from there.

And if it is your first time, volunteering to be the driver could give you a better view of pair programming. Also, it's okay for you to ask questions or to ask other collaborators to slow down.

It's completely normal if you feel confused or uncomfortable in your first sessions. Like other things, pair programming takes practice.
Well, I'm still practicing myself 😊.


Thank you for reading!
Last but not least, you can find me on Twitter. Let's connect! 😊

Oldest comments (5)

Collapse
 
squidbe profile image
squidbe

Also, it's okay for you to ask questions or to ask other collaborators to slow down.

In fact, it's more than ok. If you're not asking questions and having thoughtful (sometimes slow 😊) conversations, you're not really reaping the benefits of pair programming.

Thanks for sharing your experience!

Collapse
 
adiatiayu profile image
Ayu Adiati

Yes, my mistake in the beginning was that I didn't want to break the pace by asking my team to explain what's going on 😅
But it's surely much needed 😄

Thank you for reading! 😊

Collapse
 
threeal profile image
Alfi Maulana

I'm totally agree with this pair programming concept, especially for transfer learning to junior programmers. It's better to be an observer while they are writing the code, instead of just let them done all tasks and blame them if there's something wrong with their codes.

Collapse
 
dolamu profile image
Dolamu Asipa

The first time I heard the term pair programming, I imagined two (or more) developers learning the same topics together.

This was my first thought too when I first heard about pair programming. I thought it would be awesome to have someone doing the same thing as you and going through coding lessons together. Little did I know, pair programming is much more than that!

Collapse
 
adiatiayu profile image
Ayu Adiati

I'm glad that I'm not the only one who thought that way! 😅

I was mistaken pair programming with coworking 🙈