“OK Xer”: pair programming with Gen Z

Of all the things I miss about being together with the Nexient team, the one that I might miss the most is the simple experience of strolling through our product development center. I was always struck by the sight of our most senior developers, with decades of experience under their belts, working shoulder-to-shoulder with our youngest employees, who were just out of college.

Not that this was a surprise. At Nexient, veteran/junior pairings are common. Our clients hire us to build software with the customer in mind, which requires input from team members from all sorts of different backgrounds, including different generations.

With all the talk about generational conflict (remember “OK Boomer”?) I couldn’t help but wonder what it was like for Gen X and Gen Z coders to work together. How does the generation that cut its technological teeth on BBSs, Atari consoles and Commodore 64s with tape-drive storage relate to the generation that grew up with broadband, Chromebooks, and GitHub? 

To find out, I “pair programmed” a Q&A with Gen Z developer Anthony Reakoff and our principal technologist and Gen X vet, Keith Skronek.

Q: Are most Gen Zers familiar with pairing? If not, what are their initial reactions, and how do these compare with other generations?

Anthony (Gen Z): I know someone who quit a company because he was being forced to pair program and he hated it. That’s not to say all of Gen Z feels that way. But I do think we have a special aversion to being told what to do. If we’re being encouraged to pair-program, we want the ability to decide when to do it, and for how long.

My impression of Gen X is that they tend to be dutiful, nose-to-the-grindstone developers, while my generation tends to be more comfortable speaking up. Pair programming lets us express suggestions or pose ideas. You don’t get that kind of open dialogue when you’re heads-down coding.

Keith (Gen X): Organizations have different definitions of pair programming, so it depends. The most classic type of pairing is more commonly used in the workplace than it’s taught in school. That’s where one developer is the “driver,” solely focused on writing code and one is the “navigator,” reviewing and offering improvements. The two work at the same machine (if they’re not remote) and regularly switch roles. 

There’s also “mob programming” which involves a group of 3+ developers. This pattern is particularly useful when you’re trying to work through complex programming challenges, like architecture. I like to assign four developers to mob program a solution, and then split them into pairs or solos to execute.

Anthony is right, my generation was taught to simply do what we’re told. We learned pair programming as a tool, while Gen Z seems to think of it as an approach.

Ironically, Gen Z programmers are likely to start their careers using more old-fashioned techniques like functional vs. object-oriented programming. Maybe that’s because it's what their professors know, or maybe that’s what they’ve picked up on Stack Overflow. As they start using more modern techniques, their code gets leaner and more efficient. Pair programming is one way to improve.

Whether or not they have formal experience with pairing, I’ve seen that Gen Zers as a group tend to be highly collaborative and communicative. I think they warm to pair programming because it’s similar to the natural way they work.

Q: What are the advantages to expert-novice pairings?

Keith (Gen X): It’s typically best to pair peers, but there are times when expert-novice teams can be useful. Because they’re in constant dialogue, pairing can be a great way for junior developers to learn directly from seniors. Someone with more experience in a certain client domain or language can transfer their knowledge to a newer team member.

Anthony (Gen Z): We get a bad rep for losing focus too easily. But we’re definitely guilty of getting distracted by notifications on our phones. Pair programming forces us to be accountable and tuned in. Pairing with a senior dev also helps me realize that my way of doing something isn’t the only way. There are lots of routes you can take to solve a problem.

Q: What are the advantages to pair programming in general? When shouldn’t you use it?

Keith (Gen X): In addition to the benefits around education and perspective we mentioned earlier, everyone I’ve spoken to agrees that paired work results in cleaner, tighter code. I have decades of experience but I’m a sloppy typist. Having a detail-oriented partner is a huge benefit there. I also encourage pairing when I want to improve team collaboration. It usually helps more reserved or introverted developers open up.

Pair programming doesn’t drive a lot of value for simple coding tasks. Novice programmers would be assigned that kind of work anyway. Doubling the head count is a waste of time.

In general, you can aim for no more than two of three things: quality, speed, or optimal cost. Pair programming gives you higher quality, but the tradeoff is slower work. That makes it more expensive for the client.

Anthony (Gen Z): Most developers say they reach peak productivity by putting on headphones and smashing code. When you get in that mode, you don’t want anything to kill your flow. No messages, no distracting noises and definitely no water-cooler talk. I’m not saying it’s impossible to reach flow with a partner—for some people, pairing actually helps them feel more tuned in—but you definitely shouldn’t knock a developer out of the zone just because it’s pair programming hour.

One advantage of pairing is that you don’t waste any time waiting for feedback. Every line of code you write is reviewed in real time. If you make a mistake, someone catches it instantly. When you’re new to pairing that might make you feel a little self-conscious, like someone is breathing down your neck (and if you’re at the same keyboard, they literally might be), but you don't have to worry about throwing away development hours because you’ve chased code down a blind alley.

Because everything is happening in real-time, pair programming can be hard for large distributed teams. There might not be a convenient time to do pairing if you’re working with developers around the world. Peer code reviews would be a better alternative because they’re asynchronous. Since conversations are public, not person-to-person, code reviews can also help spread knowledge more effectively throughout remote teams.

Q: It can be difficult to integrate any new hire into the company culture, but this might be especially true for Gen Zers, as they’re new to the workforce as well. Do you think pairing influences how Gen Z connects to the rest of the team?

Anthony (Gen Z): You don’t have to be part of a pair to take in culture. I think it’s more about working in agile that helped me build accountability and adapt to a shared culture. Communicating honestly and being open to exploring new possibilities—those are Nexient values I picked up easily from being on an agile team.

Keith (Gen X): Pairing is typically driven by a need to learn. Like Anthony said, our values are all about generous collaboration and flexible thinking. The best Gen Z performers I’ve seen are the ones who aren’t afraid to say, “I don’t understand, can we pair on this?” They learn faster and outperform peers who are embarrassed to admit when they don’t know something. Speaking up when you need help, instead of furtively trying to look stuff up in the wiki, builds rapport with your teammates, and helps you feel more connected to the larger company.

Q: Do you think other Gen Zers should have pairing in their skill stack?

Anthony (Gen Z): Yes! It’s a great way to learn and improve your code.

Q: Any tips for Gen Zers asked to do pair programming during an interview?

Keith (Gen X): The most important one is practice, practice, practice. Pair programming really can’t be faked. Your interviewer can tell, without a doubt, if you’ve never done it before.

You’ll be evaluated on whether you’re a good communicator. Be prepared to talk about what works well in pair programming, and when you’d want to use it.

Lots of Gen Zers prefer learning through video. It’s no substitute for hands-on-practice, but watching pair programming how-to’s on YouTube, PluralSight, and Udemy can be a good way to get your bearings.

Conclusion

Getting a group of developers to agree on anything can be nearly impossible. Dynamic or static typing? What’s the best language for beginners? Let’s not even get into the editor war.

These opinions come from experiences in the field, so it’s only natural to think agile preferences fall upon generational lines—of course developers with different career and educational backgrounds would butt heads.

Our conversation doesn’t deny head-butting, but it does make the case for getting value out of conflict. Realizing that “my way of doing something isn’t the only way,” as Anthony articulated, will help any odd couple developers give each other more credit.