How Our Engineers Solve Problems in Pairs

Here at MailChimp, there’s no limit to the number of complex puzzles the skilled developers on our Engineering team get to solve. But when you’re elbow deep in code every day, it’s sometimes easy to overlook an issue or hit a wall when brainstorming a new idea. While every department has its own method for tackling and solving problems, our Engineering team has managed to strike a balance between working individually and partnering up to find the best solutions.

Traditional paired programming is a technique for writing code where 2 developers sit at the same desk, and one writes code while the other reviews each line as it’s written. But MailChimp’s style is much more laid back and informal, says Pamela Vickers, one of our software engineering managers. Developers have complete autonomy to either work together or separately on a project, “but a lot of times when an engineer is working through something, another engineer will come pair with them for a while.”

We talked with 6 of our developers to find out what they like about solving problems in pairs.

Getting to know you

Venisa Correia started working as a backend developer 4 months ago, and she says that pairing up with Sonya Jilani—who’s been a software engineer at MailChimp for 6 years—on her first project made getting to know the team and the application less overwhelming. “We were both assigned to be backend developers on a project for the campaigns feature, and I would reach out to Sonya if I had to think something through or was stuck on something because she’s been here longer,” she says.

Their pairing is a long-distance one, as Sonya works remotely in another state and Venisa works out of our Atlanta HQ, but neither of them feels this has a negative impact on communication. “It’s not a dealbreaker,” Venisa says. Through video chats, they’re still able to share and discuss code, as well as any issues they run into.

“I feel lucky that Venisa and I have a very organic coding relationship,” Sonya says. “Since this project has become so meaty, we have to work closely to make sure our code collaborates properly.”

But beyond this current project, Sonya and Venisa feel they’ve established a working relationship where they can reach out to one another freely whenever they need to talk through ideas or problems. It sometimes takes a second set of eyes to improve a line of code, find a reasonable solution, or make an unfamiliar database seem more manageable.

“Because Sonya has helped me understand the application, I was able to do a better job,” says Venisa. “Because she helped me, I helped the project.”

Rubber ducking

Sometimes, finding a solution to a problem is as simple as talking through what you’re seeing out loud. It also helps to have someone there to listen, which is what works with Kate Harlan and Will Castillo’s pairing relationship.

Kate joined Will’s team about 2 years ago as a junior developer after completing an internship with the Engineering department. His team works on projects related to our internal tooling system and consisted of only 2 developers when Kate got started. Because the team was so small, working collaboratively on the major restructuring of our internal system happened organically, but it also solidified the work styles both Kate and Will have carried over to other projects.

Will makes himself available to anyone on his team whenever they need him. He’s big on holding “proactive” meetings, which means that he’s ready to drop everything to talk through any questions that come up. “I prefer to have several 5-10 minute meetings during the day where we stop when we run into something we need to fix and immediately start talking about how we’re going to fix it,” he says.

But what Kate likes most about working on projects with Will, and the Engineering department in general, is that he’s willing to listen as she verbally tries to make sense of all the questions buzzing around her head. She’s usually able to find a solution to a problem as soon as she starts to explain it to Will.

In the software engineering world, this method is known as “rubber ducking,” or debugging your code by explaining it to another person or an inanimate object like a rubber duck. Developers at MailChimp even have a chat room dedicated to rubber ducking. They refer to it as the place for “devs helping devs dev.”

“Everything can be a problem.”

For Takuya Yoshikane and Kevin Xu, collaborating with different teams before they start a project helps them figure out how they’re going to build, fix, or debug something. After an idea is presented to a group, a mix of people across departments add to it until Takuya and Kevin have a more concrete plan for tackling a problem. “Everything can be a problem,” he says. “I need people to help me understand the problem that needs to be solved, and that’s when collaboration is key for me.”

When they were working on restructuring the MailChimp app and API to have more e-commerce capabilities, Takuya and Kevin had to talk through a lot of thought problems. “Before we could even start coding, we had to work out all the potential problems we could run into and how to avoid them,” Kevin says.

One of their biggest undertakings on this project was rebuilding the Shopify integration to address and resolve issues users were reporting in the reviews for the app. Their team discussed a number of different approaches for updating the Shopify integration and eventually settled on starting from scratch.

And the reviews for the MailChimp for Shopify integration they built definitely made the hard work worthwhile. “It’s just a good feeling when your code is being used by thousands or millions of people,” Kevin says. “It was definitely a good example of how well our whole team comes together to solve a problem.”