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
