Why Does Mavenlink Pair Program?
We never realized how punny our engineers were until we put them Between Two Pears
What do large plush pears have to do with software development? To find out, we asked Mavenlink engineers to interview each other, on camera, about the impact of pair programming on culture and code. Check out the highlights from those conversations below — and don’t miss our pear-flavored take on Between Two Ferns at the end of this post.
Featured “Mavens” include Amanda Hall (Software Engineer), Andy Leavitt (Director of Engineering), Jeff Moore (Lead TP Architect), Catherine Meyers (Software Engineer), Naomi Jacobs (Software Engineer), and Roger Neel (CTO and Founder). If you’re interested in joining our team, check out open roles or email JB Steadman (SVP, Engineering), jbsteadman@mavenlink.com.
What is pair programming?
Catherine: Pair programming is when two engineers write code together as a couple. That sounds weird.
Jeff: Pairing would be two people sitting at the same computer with two keyboards and two mice, typing chaotically over each other.
Roger: Every other letter.
Catherine: It always happens. It’s called cross-driving.
Why isn’t pair programming half as efficient?
Jeff: If you had two humans on two computers typing characters as quickly as they could, yes, you would get half of the output of characters typed. But if you have made software, you might have learned the lesson that number of characters typed into a keyboard doesn’t necessarily equate with better software or more functional product build.
“Everyone is able to work twice as fast because you have two usually great minds working on the same thing.” –Amanda
Amanda: I was super-skeptical when I was first interviewing and Katlyn mentioned, “Oh, we do pair programming here.” My immediate question was why? It just seemed like a waste of time. I was like, wouldn’t you get more work done if you had two people working on stuff? And then I actually came here for my on-site interview, and I’m like, oh, I see I was totally wrong.
Andy: With two people focused on the same problem, you really get a chance to zone in and roll through the multiple possibilities, multiple solutions.
Catherine: And produce better code.
Why does pairing produce better code?
Roger: I think the biggest thing is that there isn’t one knowledge silo. That’s a pretty rare trait on a team. Usually people begin specializing and they begin understanding less about the whole code base.
Jeff: When you don’t pair, you end up having these little medieval fiefdoms of which you are very protective. And you say, “This is my thing and I’m the one that knows about this, and therefore I don’t want you to know about it.” When you know for certain that somebody else is going to be working on the code that you’re writing tomorrow, then you are more likely to write that code with an eye toward readability, and that leads to maintainability.
How does pairing affect Mavenlink’s culture?
Jeff: It makes it so that collaboration is the rule rather than the exception. I think in a lot of cultures, collaborating is a sign of weakness, that “Oh, I can’t figure this out. I will admit defeat, and go ask a question of another person.” Whereas here, it’s expected and encouraged to go ask for help, to go work with another human, to have engineers actually talk to each other.
“Everyone’s talking — and not just rambling. People are having meaningful engineering discussions.” –Amanda
Amanda: There was one internship I had where I went down to the engineering floor, and I swear to God you could hear the clock ticking on the wall it was so quiet. Then I came here for my interview, and I was instantly overwhelmed. Everyone’s talking — and not just rambling. People are actually having meaningful engineering technical discussions. You just get this much more collaborative culture.
Why did you choose to work on a team that pairs?
Jeff: I was pretty sure that a programming job would be like living Office Space, and I never wanted to do it ever. I had friends that went into computer science and got programming jobs straight out of school, and by and large they hated their lives. It was by pure happenstance that I ended up visiting [Roger] at Pivotal [Labs] and saw that, hey, there is another way of doing things: people talking to each other and collaborating.
Jeff: I joined with very little experience. I had never had a software job before, and yet the culture of pairing enabled me to learn on the job. We’ve tried to maintain that and have people be able to join who are more junior or come from other walks of life.
“It’s expected and encouraged to go ask for help, to have engineers actually talk to each other.” –Jeff
Catherine: Yes, I am a former professional opera singer. I sought out pair programming because I knew I would learn a lot more. Actually the last job I had, I wasn’t pair programming. I was sitting by myself and just thrown into the deep end, and part of me loved that because it was a huge challenge to figure everything out myself. I was really afraid that I was not developing good habits. You can make it work, but is it right?
Do you always pair with the same person?
Jeff: For a day, yes. Switching off every day, it’s hard because it’s hard to gain context into another problem that you’re jumping into. But as it turns out, when you do hard things, you get good at them eventually, and it makes people better engineers.
Are there certain roles when pairing?
Andy: There are two roles when you pair. When you’re new to a project or to a team, your role is very much that of the learner. Through different stages of your career and experience on a project, you go from mentor to learner often. That constant learning is something that’s really valuable to me as an engineer. I get the opportunity not only to teach, but to learn all the time.
“To be a good pair, you have to have a lot of emotional intelligence and a lot of empathy. That leads to having a really nice working environment.” –Naomi
Is there anyone you dread pairing with?
Naomi: I don’t think that there’s anyone here who I’m like, “Ugh, I don’t want to pair with that person today.” There are definitely people where I feel like I pair better, but I actually kind of have found that the people that I didn’t have that vibe with first I learned a lot more from. Usually it was because they were prioritizing something differently and I didn’t understand why — and we had to talk about why in order to figure out how to work together well.
How did pair programming become a part of Mavenlink’s culture?
Roger: Pairing was very intentional. From the very beginning, we always paired. Many years ago I was in sales, and we were building custom demos. Oftentimes, those came at the last minute. We had business to close, and we just simply had to get the work done. Anytime that was the case, we paired on it. It was always the hard things that we would pair on. My rationale was [that] starting this company and building the software was always going to be hard, so why not always pair? Then we found Pivotal Labs, who also instilled that culture in us.
Jeff: In addition, because [Mavenlink] stayed at Pivotal for so long, we got to see the cycle of startups that would contract Pivotal Labs, give them a pile of money, and say, “Please build this product for us.” Then they would take that product, leave the nest, and promptly stop pairing. If they survived, [they would] come back in two years and say “Help. Everything’s broken!” and start pairing again.
And now, a word from our CTO…
Interested in joining the Mavenlink team?
Check out open roles in San Francisco and Salt Lake City, or email JB Steadman (SVP, Engineering), jb@mavenlink.com.
