“Dojos refer to collaborative group coding experiences […] which is a fancy way of saying, ‘We take turns writing code together,’ in service of solving a problem,” wrote Bucky Schwarz, former software engineer at Etsy, in a blog post. “We realized that in addition to being helpful, the dojo was also really fun. So we went from there.”
[ Related: Introducing Mob programming: The best team technique you've (probably) never heard of ]
Etsy’s dojos, which are part of the collaborative programming trend, start with an achievable goal that’s usually unrelated to work, Schwarz says. A group of five or so engineers set up shop in a conference room, plug a laptop into a TV and take turns writing code for three minutes each until the goal is achieved—usually after two hours.
Collaborative programming, which includes methods tied to work productivity such as mob programming and pair programming—and dojos and hackathons, which usually encourage collaboration on projects outside of work—have grown in popularity, says Jeffrey Hammond, principle analyst at Forrester Research.
“More organizations are starting to look at writing code as more of a creative profession than an algorithmic one,” he says. “Consider music composing and screenwriting: Those are intensely creative professions, and often have multiple people involved. Many people do better in a collaborative environment where you’re working together and bouncing ideas off each other. That’s when the best stuff happens.”
IT teams adopt collaborative programming techniques for a number of reasons, from team building to knowledge sharing. Here’s a look at their benefits and drawbacks, plus how to assess whether you’re a good candidate and tips for getting started.
Mob and pair programming capitalize on groups that work on the same piece of a project at the same time in the same space. Mob programming might involve an entire team while pair programming uses just two people. Martin Puryear, lead instructor at coding bootcamp Coding Dojo, says these methods benefit both projects and teams—but come with drawbacks, too.
Some businesses are drawn to mob and pair programming because of their reputation for producing good, solid code, Puryear says. “When you have multiple people working on a piece of code, the code is more sure-footed,” he says.
But assigning more than one person to work on it might be a disadvantage, at least in the short term: “You might use more resources to produce fewer lines of code, which some companies might see as a drawback,” he says. “You’ll end up with fewer tasks done in the end, but they’ll be done and done well.”
While completed tasks and solid code tend to be the objective for adopting pair or mob programming, they have other benefits, too. One, Puryear says, is more creative code.
“If you only have one person working on a piece of code, it will only reflect a specific mindset or approach,” he says. “The more people you have engaged on something, the more creative you’re going to get with the solution.” The drawback, he says, is idea overflow. “Sometimes it might take a little time to separate the crazy from the brilliant.”
Pair and mob programming, in addition to hackathons and dojos, all help to share knowledge and expertise, and create more well-rounded teams, Puryear says.
When you pair and mob program, code becomes better understood by more people. “If someone changes teams or is overloaded with a piece of work, it’s easier for other people to step up and work on it since they’ve been in the loop,” he says. “And if you have a piece of tech inside the company that’s only understood by one or two people, there’s an opportunity to use these techniques to spread the knowledge.”
Knowledge sharing and creative code are two benefits to hackathons and dojos, which take slightly different approaches to collaborative programming. Hackathons typically involve many people from different backgrounds working on different projects outside of work, while dojos focus on a particular goal using a smaller team.
At Etsy, knowledge sharing is an invaluable component to the dojo, Schwarz says. “The most exciting part of a dojo is when someone watching the coder shouts, ‘Woah! Wait, how did you do that’” Schwarz says.
Introducing collaborative programming requires a certain mindset, leadership and corporate culture for it to succeed, Puryear and Forrester’s Hammond agree. Here’s how to determine whether it’s right for you and how to start.
1. Assess your culture. “If you have the kind of corporate culture where your developers work until they drop, it’s going to be very hard to drive this type of experience,” Hammond says. Because pair and mob programming specifically require people to work in teams on projects, scrum or agile teams with freedom to be creative tend to be most successful. “It’s more about accomplishing the goal rather than being prescriptive of how you achieve that,” Hammond says.
2. Gauge trust. Pair and mob programming demand a level of trust among team members in order to succeed, Coding Dojo’s Puryear says. “You need to have enough trust with your teammates that you’re able to collaborate with them without caring about whether someone will get credit or be blamed for work on a project,” he says. “You need to firmly believe that you’re going to either succeed together or fail together, and that everyone will look out for each other and finish each other’s work to stay productive and add value.”
3. Try a hackathon or dojo. Hackathons and dojos are good gauges for whether or not your team would work well with pair or mob programming methods, Puryear and Hammond agree, and could help to change the workplace culture to support it.
“Hackathons are focused on solving a specific problem, which can help people focus less on whether or not they’re getting their share of work done compared to someone else,” Puryear says. Hackathons and dojos might also help you identify team members who are enthusiastic about this type of work, or conversely, those who aren’t.
4. Find supporters. Enthusiasts might reveal themselves during dojos or hackathons, but finding them among your team can be as easy as just talking to them, Hammond says.
“Walk around and ask developers what types of things they’re working on in their own time. A lot of developers write code outside of work or might invest in learning a new programming language,” he says. “Those are the motivated ones, and the ones you want to target. Figure out which ones are most likely to engage and give them exciting things to work on.”
5. Start small. Finding those supporters is essential to begin, Puryear says. “Find a couple of people who are not just willing to pair program, but they’re excited about it,” he says. “They should already be believers that this is the right thing to do because they need to work through that initial phase where they get used to working as a pair and are convinced that they’ll get to the other side where they will be productive and working together.”