On Pairing
By: Michael Main
Tags: Pair Programming, Software Development, Programming

Hi. My name is Michael. I am a software developer and also a person who does not know things. Of course, I know some things, but there are a lot more things that I do not know than things that I do know.

There are also a lot of things that I do not know, and that I also do not know that I do not know them. Probably. Altogether, counting the things that I know that I do not know and the things that I do not know that I do not know, that’s, well, that’s a lot of things that I do not know.

If you are reading this, it is possible that you are like me, and that you also know some things and do not know other things. If so, pair programming is an exciting tool that you might be interested in using to build better software, learn new things, and connect with your teammates.

If you are not like me, and you know everything, please @ me in the comments. I have several specific questions about the nature of the universe that I would like to have answered (ex. how is Chipotle so good?).

Oops hold on. Recruiter email. One second:

Michael! Came across your profile, and it looks like you are a 10X DEVELOPER. Perfect for what we need here at [redacted]. Coffee sometime?? — — — — — — — — — Thanks for your interest, but I am not very good at math 😬. I don’t know how I would even begin to multiply developers. Best,

Michael

Okay. Sorry about that.

Where was I? PAIR PROGRAMMING! Right. You might have heard of it before. Pairing is great for people who only know some things because chances are any two people do not know exactly the same things. I’ll give you an example. Say you and I are pair programming on a problem.

O < — This circle represents all of the things that I know.

O < — This circle represents all of the things that you know.

Now imagine that we stacked them on top of each other where only the things that we both know are overlapping. It would be the smallest part! And, what’s more, the parts that do not overlap represent things that we could learn from each other. By teaching each other as we code, we can both sharpen our skills.

I swear there is a name for this…

Shoot. Another recruiter email, give me just one second:

Hey Michael! [redacted] is looking for ROCKSTAR DEVELOPERS to fill out our team in Chicago, and judging by your LinkedIn profile, you look like a great candidate. Let me know if you are free to chat anytime in the next week! — — — — — — — — — Yikes. Sorry to have misled you, but I can’t even read music let alone play an instrument. I could maybe sing?… but I really only have experience in the shower and on long car rides. I just don’t think I’d be a good fit. Thank you for your interest, though! Best,

Michael

Woof. Moving right along.

One other benefit of pair programming is having a second set of eyes on code before you open a pull request or merge. Here, let me give you an example. Say, for instance, that I’m writing a blog post by myself. I mghit have sevral typos that I don’t see or malformed sentences like run ons or fragments or any other number of possible mistakes that I could make on my own. But if

we were pairing on a blog post together, we would have twice the chance of catching those errors. I might make a lot of mistakes by myself, but with some help, I could avoid many of them.

ANOTHER recruiter email?? Sorry again:

Michael! Our team at [redacted] is looking for talented JAVASCRIPT NINJAS to band together in the night and silently attack our latest tech problems with ruthless efficiency. Reading through your LinkedIn profile, it seems like you might fit the bill. Please let me know if you’d like to schedule a quick phone call sometime soon. — — — — — — — — — Excuse me. I have never, to my knowledge, used JavaScript to conduct covert espionage missions or assassinations in feudal Japan, and I don’t have the faintest idea where you got that impression from my LinkedIn profile. But thank you for your interest. Best,

Michael

A​ ​Semi​ ​Serious​ ​Conclusion​ ​to​ ​a​ ​Semi Serious​ ​Blog​ ​Post

In my opinion, one wonderful thing about building software is that the languages and methodologies we use represent a limitless fount of knowledge which no single developer will ever fully master. All of us can return to that fount of knowledge as many times as we’d like to, forever, and there would still be more to learn. We all know things that others do not and we all

bring something unique to the table.

Pairing is not the only option for sharing our knowledge, but it is a great hands-on way to rapidly level up your teammates, without sacrificing your output.

The people sitting next to you have the potential to teach and challenge you more than O’Reilly, YouTube, and Medium on even their best days, as long as you are willing to ask.

By pairing at Rocket, I have of course learned a lot more about technologies previously unfamiliar to me. I have also deepened my understanding of technologies I am already familiar with as a fun added bonus of fielding my teammates’ questions. And in an even more fun, even bonus-ier added bonus, I have learned a lot about the tools that we use everyday to do our jobs; everything from some of the more nuanced features of Intellij, to how to program your Apple Magic Mouse or Logitech MX Master, to convenient terminal aliases.

Pairing also offers some unique but important challenges for developers, one of which is admitting that you don’t know things. It is scary and difficult to sit next to your peers and tell them that you don’t know how the debugger works, or what some specific syntax means, or that you made an assumption which turned out to be incorrect. Not knowing things is hard in an industry rife with imposter syndrome and real issues with diversity and inclusion. But the only way to go from not knowing to knowing is learning, and asking someone to teach you is the fastest way to learn.

I am not a 10x, a rockstar, or a ninja. I do not even have a CS degree*. As I said at the top, I am a person who does not know things. But the good news is that it’s okay to not know things, and it’s okay to think you know something and be wrong. All you have to do is take a deep breath, grab a friend or a teammate (maybe both?!) and start to figure it out.

*I would be remiss not to mention Dev Bootcamp here, the incredible organization responsible for teaching me and thousands of others how to pair, code, and be nicer, more empathetic people.