At my current job, I'm a Technical Lead (TL) for a team with several other developers. As a TL, one of my tasks is that of mentoring other developers in the team, especially those with less seniority or experience.
That is not to say that I don't learn from then in turn. I believe this is always the case, but that means that I also need to spread that new knowledge around. So, I try to encourage them to mentor each other directly whenever possible.
One great tool for that is pair programming: having two developers work on the same piece of code, at the same time, using a single computer.
At first glance, this looks like a waste of resources, and there are many companies that regard it this way, although they are being proven wrong more and more these days. The rationale for this negative evaluation is that they are paying for the time of two people while the limitations of using a single computer means that only one task is being done. But there's something missing in this analysis: there are several tasks being done while pair programming, even if they are not obvious at first glance. They include:
- Code development. This is the obvious result, and the one the client is usually paying for.
- Mentoring. As one developer works on the keyboard, the other developer is looking over their shoulder, and learning about their development process, which is something they could not do by looking only at the final result. When a more experienced developer works, they usually use shortcuts or tools that are not evident to less experienced developers, who can benefit from learning about them. Conversely, when a developer with more experience looks at the development process of another developer, they are usually able to spot blind spots or misunderstandings; this gives them the opportunity to highlight those so that they can be avoided in the future. Also, no matter how experienced the developer, there's always something new to learn. They will also get exposed to new ideas and novel points of view that will be useful to explore.
- Team building. This one is also important, as when two people work together on solving a particular problem they learn to trust each other. When they need to reach out to their coworkers for help or advice in the future, they will be more willing to do so.
- Knowledge spread. When only one developer is working on a particular piece of code, their knowledge about the internals of the code is limited to that piece of code. If (when) changes to that code are needed in the future, they would be the prime choice, but if they are unavailable, whoever works on that code needs to first learn about its structure and that takes time. If they had worked together the first time, they would both be familiar enough with it to pick up the task. This gives a team more flexibility and helps increase their bus factor.
- Code Quality. While the client usually *says* that they want a high-quality product, they also want to get it as fast as possible, even when they are willing to cut down on some of the quality processes involved, like proper unit testing, or conscientious code reviews. Programming in pairs provides an extra set of eyes going over the code, which helps catch bugs early, before they get into production, and also helps speed up the follow-up code reviews, as at least one of the reviewing developers has the advantage of having watched the code grow organically.
So, while pair programming has several advantages, most of the benefits are intangible (in as much as code can be considered "tangible"). It is therefore the duty of a lead developer to ensure the team has the chance to use this tool for their advantage.