October 2011 Archives


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.

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.

About this Archive

This page is an archive of entries from October 2011 listed from newest to oldest.

September 2011 is the previous archive.

November 2011 is the next archive.

Find recent content on the main index or look in the archives to find all content.