Since it has already been discussed in other answers why pair programming isn’t a solution for you, I will discuss what we have currently experimented with, and are satisfied with the results.

In my view what you can do to increase collaboration is to have two people together on each project. Each of them works on a different part of the project, but because these parts have to be integrated the two developers have to collaborate. This also requires that the two programmers discuss the architecture (layering and interfaces) of the project, and then decide to take on different roles.

And, if this approach, limits the number of projects your company can handle at a time, you can assign this collaborating pair two projects simultaneously.

We recently experimented with this approach, having one of them develop models + integration with apis and the other programmer handling views and controllers. We have found following advantages of this setting:

1. The code structure results out in a much better way than if only one is working on all aspects of the project.
2. We don’t have to remind them about committing code to repository etc.
3. They have to put some effort in testing each others code, instead of relying solely on our dedicated QA for it.

In my opinion, pair programming is not the solution to the issue you raise.

There are two distinct roles in a pair programming. The observer is there to review and feedback on the code written by the driver. If you are trying to convey ideas to improve the decisions your junior programmers are making, I question how effective you may find their ability to critically review the code you are writing when you are performing the role of the driver.

Without this dynamic the benefit of pair programming is lost.

As the senior programmer I would suggest you consider a stronger program of employee training and development with your boss. Your junior programmers should be given a framework to improve their skills. Typically you can use methods such as enlightenments, writing a coding standards document, splitting off self-contained tasks from your own work and ensuring proper code review processes are in place.

TL;DR: I don’t think pair programming would work for you. Instead you should try to get people concerned about the long-term quality of their code and make them want to find answers. This has to be done informally.

About culture and quality

I feel this issue is not about programming methodology but rather about culture.
In my experience, culture is possible to direct, but rarely by telling people about it. That is, trying to force a certain workflow on people that hadn’t evolved naturally or is too far removed from the existing practice is bound to have negative consequences.

In other words, you don’t want to look like the suit who comes around buzzing the latest buzzwords, even when ultimately you are. Most programmers I know would mentally tag you as background noise. Don’t be a corporate bee.

In my opinion, the primary question you should be asking yourself is “am I happy with the quality and business value of the code my organization puts out?” and if the answer to that is negative, you should ask “how do I turn this around?”.

Ultimately, quality and value are human definitions only you or someone else in your organization can (and should) think about.

Pair programming and micromanagement

So, at the risk of sounding a bit forward and harsh, it seems to me that reading about pair programming actually got you thinking about some form of micromanagement, or the other way around. MM is a sure-fire recipe for alienating most people.

In defense of pair programming: pair programming is not about some guy looking over some other guy’s shoulder. That is as micro as management gets. PP is about using two minds to think about two levels at the same time – one person deals with high-level, big picture issues while the other takes care of the nuts and bolts needed to produce working code. And in my humble opinion, it rarely works well if the two participants are not in a position to switch places. They ought to be similarly-experienced enough to have a similar professional arsenal of concepts and a shared professional vocabulary (we’re not mind-linked – yet, muhahaha).

For your situation, I’d say since you’re a small team and you’re the only one with real experience (that’s what your post sounds like to me), pair-programming or reviewing most of the code most of the time wouldn’t work. You only have 24 hours a day. Instead, some solutions you could consider:

• Encourage them to participate in SO under the appropriate language tag, or to post some code snippets for review on Code Review SE. Start a little informal contest over who can gain the most SO rep points per week.

  SO can do wonders for newbie developers since it provides constant feedback and follows the heartbeat of the community.

• Take a look at some of the code they check in and challenge them informally with some questions concerning its long-term evolution. Most beginner programmers are simply not accustomed to thinking about making their code readable and maintainable. Once you get those issues into their heads, they’ll seek more information on their own, from you or other sources.

I don’t think that pair programming is something that would help you in your environment. It’s not that it wouldn’t help bring the less experienced developers up in skill – there’s even a Programmers question about pair programming with engineers of varying skill levels. Even though there are benefits such as knowledge sharing and fewer errors, pair programming requires a greater time investment. With a team of three developers and only four people who have development backgrounds/experiences, maintaining a pair programming routine seems like it would be difficulty.

I think that a better alternative in your situation is code reviews, especially if you tailor them appropriately. A code review could consist of anything from one person looking over a small bit of code and providing feedback to multiple people (even the whole team) in a room for an hour or two to look through an entire component’s design and implementation. These can be varied as appropriate for the work being done, especially based on the knowledge, experiences, and needs of the team. You can still get the knowledge sharing aspect by having multiple people partake in the review for the purposes of finding problems, providing suggestions, and gaining knowledge by reading the outputs of the review to incorporate the comments into their own work, before they have it reviewed. This also has the advantage of letting the other developers work individually until they consider their work to be done, but still provides a venue for achieving your desired goals while utilizing the entire team’s knowledge and skills.

My question is whether anyone has ever been in a similar situation, and what worked for them.

Since you’re inviting experience here’s what I did. I chose the low risk approach and asked someone decades younger than me to spend some time working together. We did not label the activity. Nobody, except for me, knew we were trying a new technique.

I don’t know exactly what details to relate, but the process worked very well. He wanted to be mentored, which was something I had no hint of in advance. So it opened communication in both directions in a very positive way.

As a matter of fact, I (as the most advanced developer) ask for the others’ opinion/help more than they do mine, because I value the input of an outside eye.

It sounds like you could frame this as logical progression of what you’re currently doing.

Some months after raising this question, I have to say I’m happy with our results. But it is not exactly the one I accepted in the beginning. Keep in mind this is small team, so this solution will not fit everyone one.

I’ve found it’s best to let everyone do their own work. And over time we have developed a trust in one another where if we run in to a problem, we call the others to our aid. I don’t think anyone wants to work with someone watching over their shoulder. I occasionally sit behind someone and sometimes help them through a problem without being solicited. Sometimes I have nothing to add, and I maybe annoy them a bit. But they understand that I’m not there to harp on them. I’m mostly there to take a break from what I’m doing and introduce a bit of collaboration.

What I’ve found is that the RIGHT people over time (in a small team) pick up and synchronize with that others are doing. There’s no need to micro manage or tell someone what they are doing wrong all the time.

From time to time, sit down with someone and work through a problem, whither you are an expert or someone learning, or both. Explain why you would or wouldn’t do something one way as opposed to another. Good ideas catch on usually, while others get left behind. And at the end of the day you have a productive, cohesive group of people who may be working on different things but share a common purpose.