Posted for Michael L.
A few months ago I came across an interesting article in the New York Times about a web design and software development company based in Florida named Hashrocket. The article talks about the collaborative approach programmers at Hashrocket take, using a concept called pair programming. Pair programming is when you have two programmers paired together at a computer workstation and while one programmer codes (the coder) the other programmer critiques (the critique). According to the article, pair programming has been used for years in some software design companies.
In the article you have Desi McAdam acting as the coder and Jim Remsik critiquing her code as she types. Annoying right? For some programmers maybe, but that’s what supposedly makes pair programming a collaborative effort. One of the programmers in the article admitted to how exhausting this particular style of programming can be, but he also believes that it makes him more disciplined.
I personally would like this kind of collaborative effort when it comes to programming, however personality wise I’m sure some people would prefer to program alone and then submit their code for critique. Do you think this form of collaborative programming (so to speak) is a good idea? Could it really save companies money and time (as the article alluded to) by cutting down on errors?

Tarngrud, I like the point you said about the strong programmer taking over. I completely agree. I feel like the weaker programmers would definitely sit back and not contribute the same amount.
What do you think about one programmer working on one part of the program while another does another part and then when they're both done they go through the others code?
I also feel like the company should have testers that test code to look for bugs and errors. Anyone agree?
Posted by: Joe Steinkamp | November 15, 2009 at 01:45 PM
I feel like that is not productive. I can completely understand that there would be less errors but I also feel like you're paying a programmer to just watch. Also I can't imagine anyone enjoys having someone look over their shoulder. I also don't feel like its that collaborative because the one is only an editor.
Posted by: Joe Steinkamp | November 15, 2009 at 01:40 PM
I do not think this type of technique is good. Constantly having someone look over your shoulder while you work is no way to work. If the developers and project management team go over the type of techniques and approaches in detail before they code, I think that preparation is enough.
Posted by: Matt Fields | November 15, 2009 at 01:29 PM
I am not programmer but from my perspective it thinks it is a challenging for both
You need more concentrate and effort ,,right it will save the company time and cupture the bugs fast
Do you think this kind of collaborative should be just for the professional programmers?
I am wondering if there is a time between the one who code and the other who review or it is at the same time ?
Posted by: zainab | November 15, 2009 at 01:03 AM
Personally, I love doing pair programming because I would like to learn all the tricks that other people might know. Also, having two programmers is better for the morale of the team, improves communication, provides real training and helps me do away with the paper work of a peer code review process. However, there are some disadvantages of pair programming which they are not big enough for me to be worried about but some other people might find the information useful. First, the day-to-day progress is slower than when a single programmer is working on the project. However the end result is a product of much higher quality so it’s worth it. In those organizations where each phase of the project has its own deadline, it is very difficult to introduce pair programming. Also, it requires great discipline and oversight to make sure that the pair programming routine is being followed. The strong programmers have a tendency to take over the coding process while the weaker programmer would be happy to stay in the reviewer's role without significantly contributing to the project.
Posted by: Tarngrud Tripitak | November 14, 2009 at 08:03 PM
I am a programmer and I cannot imagine somebody constantly critiquing on how I program. On the other hand I like when somebody looks over my code from time to time as that person might see errors that I missed.
I see one issue in this approach. How are people paired? On what criteria? I work with people in my company that are anti people to the highest level. Its hard to communicate with them by the coffee machine, not to say constantly talking with them about code.
Most programmers are not social people (maybe its a stereotype, but in my company its true) and I cant imagine working in pairs with anyone from my company.
Posted by: Grzegorz Walukanis | November 14, 2009 at 03:51 PM
As the article states, Pair programming is quite popular now days. As others have mentioned, I believe you have to have the right team in order for pair programming to work. Proponents of pair programming say that it does produce better code in the end and have proof to support this. Personally I do not like having someone look over my shoulder as I program, but I haven’t actually worked as a Developer in recent years. I don’t mind peer reviews of my code, but pair programming seems somewhat stifling.
The Pomodoro concept, which was brought up in the article, was interesting. I have never heard the recommendation that a programmer should take a 5 minute break after 25 minutes of coding. The usefulness of respecting the tomato is debatable.
Posted by: Janice Hill | November 14, 2009 at 09:50 AM
Programming using a buddy system can be either a positive or negative experience and to a large extent may relay on each persons personality and their willingness to be constantly critiqued.
There have been times in my coding career where having someone work side by side and being able to bounce ideas and thoughts back and forth has been very beneficial to the task at hand. Other benefits to pair programming which include knowledge and skill transfer.
On the other hand, having everything you write being critiqued at the time you are writing it may be a little too intense for some. I would think that in order for this to work over the long term that the two people that are put together as ‘programmer buddies’ would need to be very laid back individuals and are willing to be constantly watched over and to some extent be willing to be micro managed. Some may feel comfortable in this environment, but others would be more at ease with writing their own code, being able to review and correct it without someone watching over them and doing a code review after they have had time to check it out on their own.
Posted by: Sally Loies | November 13, 2009 at 08:37 PM
They always say "Two Heads better than one" and this method can yield very impressive result if proper team is formed and they work in a harmonic way. But I think it needs a lot of training and time to adopt to this style of work.
Posted by: Haidar AlMubarak | November 13, 2009 at 06:02 PM
I agree with Micheal's thinking. I also like collaborative effort when it comes to programming but we have to work with the right people whose personality are match with yours to work efficiently.
It is hard to collaborate online alone and it will be harder to get the programming going online
Posted by: Ying C. | November 13, 2009 at 03:18 PM