Group projects inevitably come with all kinds of feelings and questions about working with your project partner. People are messy and the efficient-minded programmers that we are don't want to deal with the hassle of splitting the workload or cleaning up our partner's messes. Some experienced programmers would rather do the entire project themselves than risk being paired with a slacker or 'rookie.' Some less experienced programmers might feel like deadweight compared to these 'experts' and while they are glad to have the help they feel guilty about their contribution. However my experience working on Iteration 1 has shown me that both of these people are valuable and neither should feel haughty or humiliated. Both 'expert' and 'novice' are better off with the other by their side.
Let me first describe myself and my project partner. I would consider my partner to be quite an accomplished programmer, at least for an undergraduate student. He has been programming for a while in his free time, for class, and for research projects at the University and has experience with C++ and several other languages. I do not have such an impressive résumé. While I am by no means a slacker or poor programmer, I simply do not have enough practice or languages under my belt to consider myself an experienced programmer. In this group I am the 'novice' and my partner is the 'expert.'
Over the course of the project I sometimes felt useful and other times inadequate. Occasionally I would stumble and need help from my coworker to get me going again. At times I wondered what I was bringing to the table and if my partner was not my friend and a nice guy I am sure he would have probably been frustrated by me at least once or twice. I am fairly confident that there were other groups who may have felt similarly one-sided. While some groups may have genuinely been unfairly weighted, in my case these feelings were not grounded and both the 'expert-novice' pairing was mutually beneficial. I suspect that others who felt unequally yoked still gained because they weren't pulling the entire load themselves.
The first step towards completing Iteration 1 was the design. This is the step where I think it is most easy to see the benefits of working in pairs. Having multiple people involved in design allows programmers to bounce ideas off of one another. More ideas are generated and these ideas are explored more fully through counter-arguments and questions than if a single person was brainstorming alone. Overall design quality is improved through considering all possible options. Furthermore the activity of generating and weighing options is not limited by the speed and scope of a single mind, creating potential for a faster design process. In code design "two minds are better than one" is almost invariably a true statement.
Without a doubt the 'novice' in group projects benefits immensely in both debugging and learning new techniques. During my coding I struggled in several areas: from returning a temporary pointer to scope to memory leaks. It was simple for my partner to fix these errors whereas I did not even know where to start, saving me hours of time when he stepped in. Furthermore, it was much easier for me to learn from him rather than the internet or a textbook. By the end of Iteration 1 I was even able to catch a memory leak on my own! I also learned through simply watching my partner. He would try techniques and commands that I had never seen and I was able to ask questions and grasp new solutions. I grew in skill because I practiced with someone of greater skill. This is the principle behind mentors and internships in industry and in my experience it extends to classroom projects.
Nevertheless this does not explain why 'expert' programmers are better off in groups than flying solo. What did I bring to the table that my partner couldn't get himself? One answer is help with debugging. Both experienced and beginner programmers have spent large amounts of time debugging only to find a simple and tiny error. My partner ran across this phenomenon during the implementation of scan. We were both working in the lab and after a while of him trying to find the error I took a quick look. It turned out that he had forgotten that we had not yet written consumeWhiteSpaceAndComments and I found the problem right away. Even experienced programmers have errors slip by them that a fresh, if less experienced, pair of eyes can immediately spot. Even if the less experienced partner cannot help with a solution they most likely can narrow down the erratic behavior to a small set of potential problems which is often half the battle. Furthermore the 'novice' programmer can still write a good amount of the code. This allows the experienced programmer to focus on a smaller section of code rather than quickly working through the entire project. I would argue that this increased concentration results in fewer errors made and thus less time debugging. By having a programmer, any fairly competent programmer, by his side the 'expert' saves time spent coding and time spent debugging.
Going into Iteration 2 I believe it would be best if groups who find themselves in 'expert-novice' pairs recognize the benefits of working together. The 'novice' should take the initiative in asking questions and learning new techniques from their more experienced half. They should not shy away from difficult tasks but tackle them to the best of their ability and learn from any failures they encounter. On the other side, the 'expert' should not discount their coworker. They should recognize what their partner brings to the table in taking code off their hands and debugging. They should also take the time to teach their partner more tricky errors and better techniques. This way the 'novice' does not make the same mistakes in subsequent iterations and can catch tricky errors that the 'expert' causes. Both sides of the 'expert-novice' relationship profit when they work together and should be consciously using this dynamic to their benefit in future iterations. I personally plan on doing my best with my current skill set, asking questions of my partner, and not devaluing my contribution to the project.
As a final caveat the 'expert-novice' relationship is only mutually beneficial if both partners put in their required effort. If one side does not carry their side to the best of their ability the reasons for a group project instead of a solo endeavor fall apart. However if both partners hold their own there is no reason for the 'expert' to feel weighed down or the 'novice' to feel useless. Both are better off because the other is there.