#28 How Proactive Engineers Operate in Solo, Pair, and Mob Programming

What are they, and when should you use each?

Engineering teams have their own ways of working—whether it’s implementing new features, troubleshooting problems, or brainstorming initiatives. Some tasks can be handled by a solo engineer with uninterrupted focus time (solo programming), while others require two engineers to “talk rubber duck” to each other (pair programming), and some need input from the entire team (mob programming).

Let’s unpack each one and explore how proactive engineers approach them.

---

I. Solo Programming

Engineers who can take on any task and execute it solo are often regarded as strong ICs. It’s an opportunity to demonstrate ownership and accountability when working on a specific task. Examples include:

• For junior-level, coding a well-defined task.

• For mid-level, debugging a deployment issue.

• For senior-level, designing a new service.

Solo programming is the default for engineers working on a task in deep focus.

Contractor software engineers work in solo mode 99% of the time. Some companies hire engineering teams made up mostly (if not entirely) of senior ICs. While this approach can increase the bandwidth for complex technical delivery, it reduces the opportunities to grow and mentor less-experienced engineers.

Pros of Solo:

• Learning: Encourages research and critical thinking to find the best solution.

• Ownership: Demonstrates responsibility for a task or project.

Cons of Solo:

• Limited perspective: Solutions may be influenced by personal biases.

• Skill variability: Task outcomes can vary depending on individual experience levels.

---

II. Pair Programming

Two developers working together, with one writing code (the driver) and the other reviewing (the navigator).

Coding interviews are based on pair programming. The candidate being the driver for solving the problem, and the interviewer as the navigator supporting the driver.

I once spent a full 8 months at Dell working in pair-programming mode. The first half was with a mentor, where I received live code reviews and guidance while implementing new solutions. The other half was with a colleague, whom I was onboarding to our codebase and infrastructure.

There are times when an engineer wants to think out loud about an implementation detail or explain their debugging approach to another engineer. This is similar to rubber duck debugging, with the other engineer acting as a sounding board.

Pros of Pairing:

• Second opinion: Seeking another opinion to address a specific problem.

• Knowledge sharing: Onboarding and mentoring engineers.

• Live feedback: Providing real-time suggestions or code reviews on a developed solution.

Cons of Pairing:

• Reduced Autonomy: The need for immediate feedback leaves little time for independent thinking and research (i.e., engineers tend to context switch if their attention is not required for long).

• Resource strain: Two people working on a single task can be an expensive use of engineering time for the team.

---

III. Mob Programming

Taking pair-programming to the next level.

This is a mode where the entire team works on the same problem, at the same time, and at the same computer. One writing code (the driver) and others exchanging ideas (navigators). Also known as Ensemble Programming.

Pros of Mob:

• Solution Ideation: More ideas are generated as everyone is actively involved.

• Team Engagement: All team members are equally engaged and invested in the outcome.

• Onboarding at scale: It’s an effective way to onboard multiple new team members.

Cons of Mob:

• Inefficient utilisation of time: Having multiple people working on the same task can be distracting, especially if conversations get in the way of focused work.

• Slower progress: While collaboration encourages discussion and debate, it can also slow things down since decisions need group approval. If speed is important, Mob Programming might not be the best approach.

So, how should a proactive engineer approach each mode?

Here are some use-cases to think about:

• If an engineer is stuck on an implementation detail for 1+ days, offer to pair with them.

• If there’s a pain point that significantly affects the entire team (e.g., dev tooling), consider fixing it solo to remove friction. Teams and managers will highly appreciate it.

• If there are new engineers on the team, consider mob programming to share process knowledge (e.g., deploying a feature, resolving an incident).

• If there’s a task you can handle quickly and effectively (e.g., demos), do it solo.

• If you need live input from product or design on a specific feature (e.g., UI widget), consider pairing if appropriate.

---

Wrap Up

Engineering teams know what works best for them and can mix and match different work modes based on the context. Solo programming enables high developer velocity, pair programming allows for immediate feedback and knowledge sharing, and mob programming creates space for solution ideation and debugging critical incidents.

Does your team work in all three modes? Let me know in the comments below.

P.S. If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already.