DEV Community

loading...

Don't be me. Be a better pair-programming partner.

SpencerLindemuth
Born to code, live to code better
・4 min read

Recently we were assigned our requirements for our first free-form pair programming project at school. Harkening back to elementary school, the mystery of who you'll be paired with burning inside you. Hoping... Or very much hoping not to be paired with the people around you. However unlike elementary school, you hardly know these people. You've only been here 2 weeks, and everyone is overwhelmed with the work, and it's still early and the skill level remains at a huge discrepancy. You start thinking, "I've been programming since freshman year in twenty ten, and have written more basic CLI apps than I can count, this is going to be a cake walk" but you don't know who around you has the same level of experience, and I didn't know it at the time but this way of thinking is the first step to becoming a bad pair programming partner. Tip number 1 for better pair programming is to tie up to a hitching post and take a break from the ride on your high horse.

Since this project seemed so nominal from the start, and "I'm such a good programmer", I spent a lot of time thinking about what I wanted to accomplish in this dedicated week. I found a great API for real time stock market info that lined up perfectly with an app idea that I had been tossing around building in my free time. With this new-found API and energy I present the idea to my partner and they were on board! Perfect! Now the ideas really start swirling around in my brain. "What should I start on first? What gem am I going to use to put this data in a table? What's the lifecycle of real-time stock market data in our program? What do I actually need out of this .JSON?"... and never thought for a second what kind of thoughts might be running through my partners head. "What the hell is a stock? An ETF? Why would someone want to see a companies 5 year stock history?". At this point I had already written 300 lines of imaginary code in my head without a second to think about what was happening in my partners. Tip number 2 for better pair programming is to realize that you have to share a vision to equally contribute to a project. No one is going to be enthusiastic to help with something they are constantly googling about along the way.

After two days of furious coding it's time to start hooking their UI to my back-end hooks, and (to no-one's) surprise! Their vision of what my pet project should look like is different than mine! (gasp).

"Don't worry, I can fix this! I'll stay late today and make some quote, unquote *subtle* changes." There's that pesky "bad partner" voice again. Tip number 3 to better pairing is acceptance. Riding right off the back of tip number 2, tip number 3 means you have to let it go. If you make the program look exactly how you want, do exactly what you want, and the whole concept is about exactly what you want, why do you even have a partner? Acceptance of your partners vision is only half the battle too. Everyone is different. Everyone's eyes are different, their fingerprints are different, their handwriting is different, and their coding style is different. To truly accept your pair partner (and life partner, but that's a different blog) is to appreciate the way they do things differently. Maybe they like if/else statements better than case statements, or they prefer .atom to VSCode like you, but maybe they've used a gem that makes that table you've been trying to format for 16 hours.

Pair programming is meant to create to a result that is the expression of both parties involved, which inherently make is better suited to tackle a task because it has 100% more brain power behind it. Every change to the code might bring your vision up 1% or 2% but the capability of the program drops 5% or 10%. Tip number 4 is, don't be afraid to express yourself. You are great! Give the world what you have to offer! But so is your partner! Don't block the shine of the person shining next to you, because you know it wouldn't feel great if they were the one holding the umbrella.

Let's review:

  1. Be humble - Smart today doesn't mean smart tomorrow.

  2. Share a vision - Working towards a common goal is better than building someone else's.

  3. Acceptance - You are as different to them, as they are to you.

  4. Collaborate - If you had every great idea, why are you sitting here reading my blog?

The most important tip is learn something! If you don't come out of a pair project feeling like you've learned something about coding and yourself, you are living all wrong.

  • “If you’re the smartest person in the room, you’re in the wrong room.”

Discussion (0)