21

I work at a small development company as the lead developer. We have two other developers, as well as my boss who is a developer, but doesn't really do much of the actual coding anymore.

The problem I am trying to overcome is multifaceted. We have a tendency all to work on our own projects without much collaboration between us. 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.

I want to increase our collaboration, and have expressed that to them. In large part because I'd like to show them some things about how to become better developers and follow better practices. But given our other developers' personality types, I think they are more comfortable working alone.

I've been reading about pair programming, and I have read (in some forums) that it doesn't work well when you have one developer being more advanced than the others (which I am). And yet, I feel it is imperative that we start to collaborate so that our work is not so disparate.

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

I realize this is not a one-size-fits-all situation, but I'm willing to give multiple approaches a shot.

We all work in a common area, developers don't have have individual offices / cubicles.

  • 2
    Do you and the other developers have individual offices, cubicles, or sit in a common area? – hatchet-inactive Aug 25 '13 at 13:43
  • @hatchet We all work in a common area. – Ryan Williams Aug 26 '13 at 2:14
12

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.
  • 1
    I will think over this also. I really like the separation of the development of the views and controllers from the models, because it forces the developers to come up with a good API for the models. In order to work simultaneously, it also forces the writing of relevant tests. – Ryan Williams Aug 26 '13 at 1:05
  • 1
    I have decided to accept this answer because after going over it and talking it over with a couple team members, I'm convinced the best way to induce collaboration is to divide roles on the same project. It may not work, but it seems to be the best fit I've heard. – Ryan Williams Aug 28 '13 at 1:38
7

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.

  • I will take your thoughts into consideration. It's a bit to parse and rectify mentally against what we are currently doing. An honest feeling I have is a bit of insecurity in my position as lead developer. Not because I'm not comfortable from a skill-perspective, but rather because both of our other developers are older than myself (one significantly, one not), and one even has a couple more years of experience. That being the case, traditional code reviews would seem awkward, because I don't want to seem like I'm breathing down their necks. Then again, maybe that's what I have to do. – Ryan Williams Aug 25 '13 at 1:55
  • One other thing. Do you think there is less benefit than it is worth to pair program with them, where when I am the driver? It could still be used as a way to point out best practices, and still have some input and feedback on what I am doing (even if the relationship would surely be unbalanced). – Ryan Williams Aug 25 '13 at 2:04
  • If the pair programming relationship is one way, I'd suggest it wouldn't be engaging and perhaps even slightly patronizing to your co-workers. Depending on how you model it, this could quite easily come across as, "this is how I program and it's the best approach". You wouldn't actually call this pair programming since it doesn't have both components. – user96303 Aug 25 '13 at 2:17
  • I guess that's really what I'm afraid of. Thanks for the thoughts. I'm going to accept your answer for being the first. (There were a couple other good ones, too.) – Ryan Williams Aug 26 '13 at 1:10
  • @RyanWilliams Code reviews are not about "breating down their neck". It's not about you controlling them. At our place, we use ReviewBoard as a platform and comment on each others code. There is no "hierarchy". The learning in this case is "implicit". They learn from reading your and their code, from your and the other devs questions and the answers/comments to those questions. And they get to know other parts of the code base, which is quite beneficial IMHO. – Johannes S. Sep 15 '13 at 13:00
5

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.

  • As, everyone else, I appreciate your input. The one thing that I have realized in posting this is that I have some discomfort with being the one who is looking over their shoulders. They are both actually older than me and one has significantly more experience. So I don't picture them as people who are going to go around on CE and ask for code reviews. They aren't newbies. But they come from different languages, and unorthodox practices. – Ryan Williams Aug 28 '13 at 1:36
  • I see. I think it's good you don't feel comfortable looking over their shoulders because I don't think you should. Nobody wants to have someone second guessing every keystroke they make (exaggerating). – idoby Aug 28 '13 at 8:28
4

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.

  • Seems to be a popular opinion. I like the idea of code reviews. But in my mind I would guess that with their personalities and skill levels, it's going to be me who is doing the reviewing, and them just listening (mostly uninvolved). But maybe there is a way to get them more involved. I guess I have to reflect on that. – Ryan Williams Aug 25 '13 at 2:11
  • Also, to be clear, I wasn't talking about pair programming as something we do all the time. Rather, devote some significant, but not huge portion of the work week to it for larger or more complex features. (That's partially out of practical necessity. I have my own demands that need to be met.) – Ryan Williams Aug 25 '13 at 2:13
2

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.

  • My worry is that I'm not so sure they want to be "mentored". They are both older than me and one (significantly older) actually has a few years more experience than I have. But I like the second part of your advice. – Ryan Williams Aug 26 '13 at 1:12
  • And it's natural to worry before you do something -- because you don't have information. My experience has been that if you just do it, that people will sense that you're not worried, and that you're relaxed and they'll go along. And then if it works -- continue, and if it doesn't -- try something else. – dcaswell Aug 26 '13 at 1:16
  • Maybe getting them involved in a bigger project that I would normally do myself could ease that a bit. For example, we're redoing our CMS soon. It would take a bit of me getting used to the idea, though. – Ryan Williams Aug 26 '13 at 2:02
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.