In a team environment, finding opportunities for everyone to collaborate simultaneously can be difficult, especially for remote teams. Our weekly team coding sessions arose from a desire to get everyone in the same room and make progress on some of the interesting, challenging, and often new problems that we face in our projects. Team coding sessions provide an opportunity to accelerate learning and the overall programming skills of our entire R&D team.
With team coding, or “mob” coding, we put the collective problem-solving abilities of our group to task and encourage teammates to show off their unique development environments and skill sets. With one team member in the driver’s seat and the group acting as collective backseat navigators, we’ve expanded our tool literacy, learned new programming languages, and embarked on entirely new projects made possible only by combining our coding powers.
The primary trade-off in team coding is sacrificing speed for greater knowledge transfer. The long-term value of collectively improving the skills of everyone on the team outweighs the cost of the additional time spent working to complete a project. Team coding might not be the fastest way to build a program or make progress on a given task, but it surely is a super fast way to learn.
When reviewing code, you see the results of someone’s work and can sometimes even get a sense of their thought process. What you don’t see is how they arrived at that solution. You don’t see their questions or their search for answers, reading documentation, etc. When learning a new language, for instance, the learning process can be really helpful to observe, because you see, firsthand, the search terms used and where to find the helpful resources.
We’ve found that these 5 principles embody team coding:
1. Don’t be the only one writing the software.
Team coding is all about the “team” aspect. When TEECOMlabs does a mob coding session, the driver is on the keyboard typing out the code and the mob provides instructions, guidance, and solutions. The rule is: the driver isn’t allowed to initiate any action, only the mob. For the mob, this means that communicating ideas clearly and in a manner easily understood by the driver is critical. Having to communicate an idea verbally often illuminates challenges in a way that going directly from your brain to code does not.
2. Encourage experimentation outside your comfort zone.
There’s an old saying, “If you’re the smartest one in the room, you’re in the wrong room.” When you’re coding in a group context, there are going to be things you’ll understand, and things you’re not familiar with. You may be challenged to learn a language you’re unfamiliar with, work in an unfamiliar text editor, or write with an unfamiliar coding style. The key is to remain open to those new challenges and not shy away from them. By absorbing new skills, you’ll be able to contribute more to your team over time.
3. “Team coding” is more about “team thinking,” which is then captured in code.
A lot of the benefit of team coding comes from the discussion around programming, not the programing itself. You can distribute collective knowledge through meetings, blog posts, or presentations, but team coding forces your team to get into and out of each other’s heads in real time. “Team thinking” exposes everyone to different ways of approaching the same problem, and enables discovery of unique solutions.
4. Objective progress necessitates actual team work.
Unlike other collaborative exercises, like writing, drawing, or brainstorming, software development incorporates an objective measure of functionality. The compiler, interpreter, or runtime can be a harsh judge of the group’s work. This added dimension makes team coding more like stereotypical team building exercises where a group combines their efforts to overcome an obstacle course. That impartial arbiter serves as a focal point for the team’s energy and forces real collaboration.
5. Depend on others.
As software engineers, we’re mostly trained to work on a problem internally and to try to produce a valid suggestion before going to others for help. In the mob coding approach, this paradigm is flipped: the solution and the code itself is created by a collective, not by any one individual. Rather than having to think about how to implement a function or library by yourself, you can poll the mob. If you encounter a problem you can’t solve by yourself, raise it as a question. Chances are, others have the same question.
The CEO’s Perspective
One of the most significant challenges that organizations face is how to continually elevate the skill levels of their staff in an engaging, collaborative, and effective way. Team coding sessions allow participants/team members to discuss how to structure appropriate solutions to problems, alternative solutions, and why the team prefers one particular solution over another while producing valuable work output. Usually, the entire group finds value in the exercise, either by learning something new or strengthening the confidence in a specific approach. Team member relationships become stronger, barriers to communication break down, and the team operates more effectively as a group.
The process of team coding can be applied to other organizational groups, not only in coding. For example, TEECOM has used team engineering sessions to develop creative solutions to complex engineering challenges. New staff members and senior staff members work together on solving common problems and, more often than not, new staff members generate more creative solutions that end up as the final solution to the problem.