Eventually, the scope of the project that you will be conducting will be too great for a single individual and you will be forced to interact with others and figure out how to portion the work accordingly; we have reached this point our academic careers. Though alleviating some of the stress associated with a project, this generally tends to add a whole new depth of issues. Up until this point, I have enjoyed conducting projects on my own and I would have to say that being forced to work in a group/partner setting is something that I would prefer to avoid if possible, despite the unquestionable benefits.
There are a few reasons that I am anti-groups to a certain extent. One of these issues that arise is the suppression of innovation. If you are in a group setting, new ideas that you formulate are often questioned and sometimes completely tossed out the window. This can sometimes be frustrating when you know that the idea you had in your head was most likely going to work and you end up wasting an abundance of time on a project, rather than implementing your idea in the first place. I have personally encountered this issue a few times this semester already in this class and in CSCI4061. In this class, my partner and I debated implementing the linked list in the scanner, despite its optionality. Eventually, after a lot of persistence on implementing it in this iteration, I ended up cranking out the code for it in little to no time, since I already had it conceptualized in my head. To my partner and I's surprise, in lecture today, Oct 11th, this implementation is exactly what Professor Van Wyk was suggesting, so hopefully the past struggle will pay off in the near future. If I were working solo, I would have still implemented this without my partner questioning the benefits of implementing it in this iteration, which would have saved me a bit of time in the long run.
Asides from this conflict, there have also been conceptualization conflicts that arose in CSCI4061. The last project we had to do was to design a program that manages process execution based on their dependencies. It was a very interesting project, and my two partners and I had to implement a handful of abstract data types to manage this as efficiently as we saw fit. We spent hours debating various routes that we could take to implement the project, which could have been avoided if I had sole responsibility for this project. I had to sacrifice some of my ideas to please my group members, even though I knew they would have been equally valid solutions.
Another issue that is commonly faced in group settings is the difficulty in establishing an in-person meeting with your group members. I know that for computer science we don't necessarily have to meet in person in order to work on our projects, because we have tools such as FTP, SSH, and Subversion (version control), which are designed to give us access and synchronization to files on CS servers from our personal computers. Although, these tools prove beneficial if members are unable to meet up in person, I still advocate for in person meetings, because it's easier to talk to people in-person rather than being on a conference call of some sort. I have previously been bothered with attempting to draw diagrams with group members over an online drawing application, which proved more detrimental then anything else. Being able to openly construct new ideas with ease is something that is vitally important for me when I am working on project development.
Asides from the relevant hassles of being committed to a group, there are undeniably benefits that present themselves as well. Since we are able to choose who our group members are for this and many of our other classes that we will take in our undergraduate career, we are able to pick people that may have similar programming mentalities as we do. This is something that I have to advocate for, because I have been stuck with programmers in the past that don't share a common approach to programming. As I have discussed previously, I find it EXTREMELY useful to layout the implementation of a project in the form of diagrams before I start programming. If I were to be stuck with a partner that was against this process, it would be very difficult for me to jump straight into code. I do not appreciate rushing into code only to be faced with a plethora of errors. When I program in my own style, I am generally lucky enough to be able to put my ideas into code and cope with relatively little debugging. This process of pre-planning also encourages the discussion of ideas, which in this case we can view as beneficial, despite it being an aforementioned issue. Sometimes it is too hard to conceptualize a project on your own, and you need someone else there to talk things through with.
Overall, working in groups undeniably complicates the process, even though it adds many benefits as well. There are quite a few companies that can contribute their success to a particular individual. It would be interesting to see what the world would be like if all companies were run on an individual basis. Most likely it would not be very successful, because it would be too much work for one person to cover themselves, however that particular individual would encounter complete freedom of expression in his/her work.
Despite my insistence on superiority of individual work, I would not trade the experience of working with people that I have for anything. These experiences have taught me a lot about myself and how to work properly with various individuals. Also, some of my closest friends have been my partners for various group projects in the past and I would not trade that for anything. I look forward to meeting lots of new people as my careers progresses, since interpersonal communication is vital in the modern-day workplace.
---- Josh K. Anwar
I agree that having a partner can sometimes actually cost you more time than if you didn't have one. Disagreements over implementation can frequently delay a project that would otherwise be straightforward.
Andrew Hall
I really enjoyed reading your article. It goes beyond the typical reasons why working in groups can be good or bad. I can also sense a hint of frustration for when you have to go back and redo it your way (which is good for the reader). I've been it situations where partners/coworkers had a different implementation in mind also. It can be really frustrating when your partners stop listening to you because they have something else in mind. Luckily, I've been able to convince the people I work with to reconsider their ideas before implementation (most of the time).
Dylan Bettermann
I really enjoyed reading your article. It goes beyond the typical reasons why working in groups can be good or bad. I can also sense a hint of frustration for when you have to go back and redo it your way (which is good for the reader). I've been in situations where partners/coworkers had a different implementation in mind also. It can be really frustrating when your partners stop listening to you because they have something else in mind. Luckily, I've been able to convince the people I work with to reconsider their ideas before implementation, which has probably saved me from some headaches.
Dylan Bettermann
Sorry for the double post.. the U of M authentication for this site is kinda weird.
I understand your grief in the idea's and all but sometimes it may benefit you. I to want to implement the link list but my partner had only wanted to do the bare minimum just get the code working. i wanted to work against and just do the link list since we were gonna have to eventually anyways. But we ended up not doing it and just going with the expectations and now we end up doing link list with problems we could have solved in the earlier phases.
I agree with most of your points, they are definitely legitimate concerns with working with other people. It was nice to read your blog after writing mine, which was about the positives of working in a group. But, you contrast nicely at the end, saying that there are positives as well. I would offer this though, when working with someone that has a vastly different, but effective coding style, use it as an opportunity to add a new tool to your programming arsenal. You may still be right, but hear what they have to say, and use that to improve yourself if you can. They should do the same. That way, you two will generate a hybrid coding style that should be more conducive to working together then and in the future. Other than that, I agree, working in groups can add lots of conflict to something that you might rather do yourself.
Kevin Zdon
I definitely agree with your point that working with others does sometimes suppress creative ideas and thinking. Although this can be true sometimes, I would say it can also work the other way too. If I am working with others on a project, they might mention different ideas that I have not thought about before, opening my eyes up to different ways to program. This could then actually get me thinking about different ways and not necessarily suppressing my creative ideas all the time. What I would say would be import is to realize the ideas of everyone in the group to try to not suppress this creative thinking. Although some may seem better than others, we should take all ideas of everyone in the group into consideration when programming. I believe in this way we would be able to get a better program than working individually.
-Zachary Panzer
I admire your inclination to draw out designs before getting started on code. I find that whether or not I start out by sketching on paper, I too must do some diagramming before I can accomplish anything tricky. I wonder if a partner could be helpful in this diagramming process (maybe in catching logic errors before they are even implemented)!
On another note: I've been hearing a lot of this talk about coding disagreements. Maybe part of the tao of programming is being willing to let go of your own code.
Jonathan Bassen
I agree with your point about in-person meetings. When discussing ideas in coding and implementation over a phone, through chat or even video calls, you are more likely to misunderstand what the other side is explaining. You can relate to a person physically in front of you more than a person who is just a voice , text or video to you. Of course in the case of discussing simple ideas or inquires, setting up an in-person meeting would be useless and that is when other methods of communication are useful.
Adel Aldawood