In working on group projects in other classes and on Iteration 1 for this class, I have found that partners can be both a good thing and a bad thing. Having a partner allows you to divide up and focus on certain parts of a project and can relieve stress since you know that you will not have to do all of the work. The partner may also provide insight into areas of coding that you are not as familiar with. However, there are also challenges to working in a group. Conflicting schedules and disagreements on how to tackle the project can collapse a project before it has even started.
A good example of where having a partner allows one to divide up the work into a manageable size is in this class, CSCI 3081W. In Iteration 1, my partner did a large amount of the debugging after I wrote the majority of the code and thus, we were able to divide up the work fairly evenly. This was definitely a benefit to me since I had homework and projects in other classes that I needed to work on that week and therefore I was not as overwhelmed as I would have been if I had worked alone on Iteration 1.
Perhaps the biggest advantage to having a partner is the fact that they may be able to help you understand requirements and code that you are not familiar with. In this class, my partner has experience in C (which I do not) and thus for Iteration 1, he was able to help me understand what I could and couldn't do in C and help me out with certain C related errors and issues. In Iteration 1, I did a lot of the coding to start the project out but got many errors when I attempted to compile it. When my partner looked through the code with me, he was able to eliminate the vast majority of the errors within thirty minutes. Many of those errors were easy fixes that I had overlooked. Thus, having a partner allows for a fresh set of eyes to look for things that you may have missed.
Working with a partner is not a cure for all of the problems one faces in projects and often there are problems that will result from the fact that one has a partner. In some of my other computer science classes and to an extent in this one, trouble with being able to find a time where both partners could sit down and work on the project together actually resulted in some significant coding time being lost. In Iteration 1, the fact that my partner and I were not able to meet and fully understand how to attack the project until three days before the assignment was due caused a great deal of stress for me (and undoubtedly my partner as well).
Having a partner with a completely different view of how to tackle a problem can be perhaps the biggest hurdle to overcome when trying to tackle a project. This situation occurred in CSCI 1901 last year. My lab partner was undoubtedly smart and could satisfactorily complete projects that were due, but his way of thinking was significantly different than mine. I often found myself overthinking problems because I could not understand how my partner wanted to approach the problem. In CSCI 1902, I worked alone for the majority of my projects and ended up not only understanding the materials in the projects better but also completing them in a more timely matter. Thus, sometimes not having a partner allows you to understand the material better by not allowing you a crutch to lean on (your partner) when you are doing the project.
As you can see, there are both large advantages and disadvantages to having a partner when working on a coding project. With a partner, you can very easily divide up the work into manageable sections and with two sets of eyes, if you don't exactly understand how to do something, chances are good your partner will have a better idea of how to do it. As I said, you can also run into differences when scheduling to meet with a partner and in philosophies of how to approach a problem. Thus, if given the choice of whether or not to have a partner for a coding project, you should understand the advantages and disadvantages of having one. Only work with a partner if you and that partner have similar schedules and more importantly if you both think and approach the problem in a similar manner.
While I realize the medium isn't ideal, did you two consider communicating through email? I'm imagining one partner establishing some sort of schedule/plan and the other making revisions. Even a roughed-out plan would give some kind of framework that you could work from.
It's nowhere near as good as an in-person meeting but it might be less stressful than waiting would be :)
Cameron Muehlen
I definitely understand your stance on groups being both beneficial and somewhat detrimental at the same time. In particular, your analogy to group settings granting you a sort of "crutch" to lean on is very true. I have worked in group settings where I have been the primary developer and in groups where I have been the backseat driver (I prefer the former).
This crutch is an amazing resource/necessity for our busy lives however! I fell into a similar category where I did most of the coding and then let me partner figure out any necessary optimization/bug removal. This allowed me to concentrate on other things without the feeling of doing inadequate work on our project.
Josh K. Anwar
It's true there are advantages and disadvantages when working with a partner. I think there really are more advantages though. I'm glad you and your partner were able to divide the work evenly between you two. That's always one of the problems.
I was surprised to hear that your partner did a lot of debugging of code that you had written. I would have pictured it to be more difficult to find bugs in other people's code than your own, simply because YOU wrote your code and YOU can quickly picture the different data structures and algorithmic approaches you used. Having heard your story, I guess I could rationalize that one's partner might understand a bug (such as a weird seg fault) that the coder had never encountered before. The combination of these ideas makes me wonder if optimal testing would involve both of the group members' simultaneous collaboration.
I was surprised to hear that your partner did a lot of debugging of code that you had written. I would have pictured it to be more difficult to find bugs in other people's code than your own, simply because YOU wrote your code and YOU can quickly picture the different data structures and algorithmic approaches you used. Having heard your story, I guess I could rationalize that one's partner might understand a bug (such as a weird seg fault) that the coder had never encountered before. The combination of these ideas makes me wonder if optimal testing would involve both of the group members' simultaneous collaboration.
Jonathan Bassen