10 Replies - 1276 Views - Last Post: 20 August 2013 - 12:35 AM

#1 Solixious  Icon User is offline

  • New D.I.C Head

Reputation: 3
  • View blog
  • Posts: 10
  • Joined: 26-July 13

My Fear of Group Projects

Posted 10 August 2013 - 12:21 PM

I've been programming as a student for few years now. I never had a chance to work in a group project with someone. I have made few personal projects on my own, but I'm afraid that I will not be able to work in a group with anyone because I don't think I'll be able to co-ordinate well with other members. I don't even know how they work in a group. I find it weird actually. I'm feeling stupid whilst I'm posting this topic, but I don't know if this feeling in me is normal or not. What should I do?

Is This A Good Question/Topic? 0
  • +

Replies To: My Fear of Group Projects

#2 modi123_1  Icon User is online

  • Suitor #2
  • member icon



Reputation: 9366
  • View blog
  • Posts: 35,187
  • Joined: 12-June 08

Re: My Fear of Group Projects

Posted 10 August 2013 - 12:27 PM

First - you do realize that this is why they have group projects, right? To get you to solve complex tasks with other folks - much how the real world will run.

Get out the jitters now, be amicable, don't slack, and (if you feel up to it) help coordinate work.
Was This Post Helpful? 1
  • +
  • -

#3 laytonsdad  Icon User is offline

  • Cheese and Sprinkles
  • member icon

Reputation: 442
  • View blog
  • Posts: 1,884
  • Joined: 30-April 10

Re: My Fear of Group Projects

Posted 10 August 2013 - 12:34 PM

Confidence in your ability and finding out what you can add to a group is very important along with communication. Everyone does something better than another and working in a group is finding your place and producing the best you can while making sure everyone is on the same page.

Once you get in it will all become natural working with others. I also felt this way after school, it will pass.
Was This Post Helpful? 2
  • +
  • -

#4 andrewsw  Icon User is offline

  • It's just been revoked!
  • member icon

Reputation: 3602
  • View blog
  • Posts: 12,388
  • Joined: 12-December 12

Re: My Fear of Group Projects

Posted 10 August 2013 - 12:55 PM

You'll probably find the members of the group to be very supportive :bigsmile: (ahem, or a number of them).

You always have the choice to set out on your own - although some would consider this a scarier prospect.

This post has been edited by andrewsw: 10 August 2013 - 12:56 PM

Was This Post Helpful? 0
  • +
  • -

#5 Solixious  Icon User is offline

  • New D.I.C Head

Reputation: 3
  • View blog
  • Posts: 10
  • Joined: 26-July 13

Re: My Fear of Group Projects

Posted 10 August 2013 - 01:00 PM

Hopefully I'll be able to work well in groups when the time comes. But it still gives makes me feel strange, the idea of working in a group. I've been pretty shy among people my entire life.
Was This Post Helpful? 0
  • +
  • -

#6 stephen.d  Icon User is offline

  • New D.I.C Head

Reputation: 6
  • View blog
  • Posts: 15
  • Joined: 03-August 13

Re: My Fear of Group Projects

Posted 10 August 2013 - 01:33 PM

I used to be extremely anti-social, and the idea of group projects would completely freak me out.

I'm about to graduate with my CS degree, and I can say that the group projects I participated in
spawned some of the best memories I have. I absolutely loved them.

Everyone is nervous and uncomfortable their first time. Just listen to what everyone else says, pay
attention to body language, and try to plan the project out. Be open (and tactful) about your thoughts;
decisions are based on available information. Your team needs to set up meeting days and delegate
project topics. It will be bumpy at first, but you'll be fine.

At some point someone will take leadership -- it might even be you -- and things will get done.
Was This Post Helpful? 2
  • +
  • -

#7 Slice  Icon User is offline

  • sudo pacman -S moneyz


Reputation: 245
  • View blog
  • Posts: 719
  • Joined: 24-November 08

Re: My Fear of Group Projects

Posted 10 August 2013 - 10:19 PM

View PostSolixious, on 10 August 2013 - 09:00 PM, said:

Hopefully I'll be able to work well in groups when the time comes. But it still gives makes me feel strange, the idea of working in a group. I've been pretty shy among people my entire life.


I used to have issues working within a group but mainly because I didn't trust other people. Throughout highschool, our group projects always had that one guy that said he'd have his part ready for the presentation, then wait till 5 minutes before hand and not show up.

That all changed at college/university level though. Everyone has the same kind of passion and knows how important it is.

The best thing I found was to take it in baby steps. Don't expect your group to click in the first five minutes and turn into a bunch of hack-bros. Developing good communication between other people (especially communication when working on complex projects) needs to evolve naturally. You can help by being the guy who goes the extra step to get to know them. Ask them if they want to meet up in the library or cafe on a free period or something. A lot of the time everyone will be up for it, but they are all too shy to be the ones asking.

EDIT: Oh and just to add, when inviting them to meet up outside of class, don't force it. Make it casual because you don't want to be the "meet up or you're out of the project" guy. Nobody likes that guy.

This post has been edited by Slice: 10 August 2013 - 10:21 PM

Was This Post Helpful? 0
  • +
  • -

#8 aaron1178  Icon User is offline

  • Dovakiin, Dragonborn
  • member icon

Reputation: 169
  • View blog
  • Posts: 1,299
  • Joined: 22-October 08

Re: My Fear of Group Projects

Posted 11 August 2013 - 03:48 AM

View PostSlice, on 11 August 2013 - 04:19 PM, said:

The best thing I found was to take it in baby steps. Don't expect your group to click in the first five minutes and turn into a bunch of hack-bros. Developing good communication between other people (especially communication when working on complex projects) needs to evolve naturally. You can help by being the guy who goes the extra step to get to know them. Ask them if they want to meet up in the library or cafe on a free period or something. A lot of the time everyone will be up for it, but they are all too shy to be the ones asking.


Sounds like The Internship ;)
Was This Post Helpful? 0
  • +
  • -

#9 xclite  Icon User is offline

  • LIKE A BOSS
  • member icon


Reputation: 911
  • Posts: 3,178
  • Joined: 12-May 09

Re: My Fear of Group Projects

Posted 11 August 2013 - 08:32 AM

View PostSlice, on 11 August 2013 - 01:19 AM, said:

That all changed at college/university level though. Everyone has the same kind of passion and knows how important it is.

I found this to not be the case, and maybe that's because I went to state school. It's less of a gap, but you still find the occasional asshat who just screws your group. You get graded on group performance, regardless of the actual work put forth by each member.

Part of group projects is learning how to deal with those schmucks as much as how to work with the people actually willing to make an effort.
Was This Post Helpful? 0
  • +
  • -

#10 BetaWar  Icon User is offline

  • #include "soul.h"
  • member icon

Reputation: 1167
  • View blog
  • Posts: 7,207
  • Joined: 07-September 06

Re: My Fear of Group Projects

Posted 11 August 2013 - 09:05 AM

Group projects, I have found, are hit or miss. Especially in college. Basically, you need to just get a team together and start working. It is better to do as many group projects while in university as you can so that when you get to the real world you have some experience working on teams with various people. Some are going to work well together, and some aren't. That is just the name of the game.

Here are a few suggestions on making a team work out:
1. Don't be afraid of stepping up. Sometimes people will be running behind or just slacking off completely. If that becomes the case don't hound them about getting their work done, instead offer to help them out with their tasks (especially if/ after you are done with your tasks). However, do note which people are constantly needing help to reach their goals and give them less to work on in the future since they are unable to keep up with the load they already have been given. Find a workload they can handle and just give them 1 load at a time until their part is done.
2. Realize that everyone has different strengths, weaknesses, skills, and points of interest. Depending on which courses someone has taken, what they do with their free time, and how much they actually know, it can take people time to get acquainted with new a new tool-set or programming paradigm. This isn't a bad thing, but will usually means that the initial few tasks will take them longer to complete than later ones.
3. Allow team members to volunteer for the tasks they undertake. This will allow them to more closely choose what they work on and give them a sense of ownership (since they weren't just arbitrarily assigned a task which they have no interest in).
4. Test and code review. This may sound counterproductive to do, but I assure you it will lead to a higher quality piece of software at the end. Come up with a coding standard (where the brackets go, how classes, functions, variables, etc. are to be named, and so on and ensure that everyone follows the standard by doing code reviews. Additionally, in code reviews have whoever is doing the review actually read the code and make sure that they agree with the logic being used and are able to understand how someone is accomplishing a task. This will allow you to have at least 1 other person somewhat familiar with everyone else's code so that if someone drops out of the project, or is sick, or otherwise unavailable, you still have someone who knows others' code. Given the last reason, I would also suggest spreading the code reviews out over the team instead of having a single person responsible for all of the reviews. The tests should be there to test a. the main functionality which the task adds, and going further b. the corner-cases which may be encountered with the code. It may seem like an over the top practice for a group project, but when you get to industry you will likely be responsible for writing unit tests to cover any and all code you are responsible for, so getting in to the habit now will only help in the future.
5. Have scheduled sprints (agile programming methodology) at which point all currently-assigned tasks should be completed and in your main project code base (tested and reviewed). This way you have a "working" project every, say, 2-week period, and can see the progress.
6. Finally, if someone is consistently not doing their work, make sure you record it (talk to them first, say if at the end of the first sprint they don't have anything to add to the codebase) and let your professor know (after 2 or three sprints of them not pulling their weight), if nothing else they may remove the slacker from your group so you aren't getting them a good grade for all of your hard work. The best case scenario is that the professor is able to get through to them that they have to help out or they are going to fail.


And in closing, don't be afraid to take the lead. Group projects can be difficult and scary for some people, but having a leader who is willing to step up and keep everyone organized is helpful.
Was This Post Helpful? 3
  • +
  • -

#11 jon.kiparsky  Icon User is offline

  • Pancakes!
  • member icon


Reputation: 7872
  • View blog
  • Posts: 13,350
  • Joined: 19-March 11

Re: My Fear of Group Projects

Posted 20 August 2013 - 12:35 AM

I would suggest that you start out by mapping out the pieces of the problem and break it down into manageable sub-problems. You can then take those, do your best to estimate the time required for them (it's okay to be wrong, as it turns out - the important thing is to have a best guess), and arrange them in a reasonable order, ie, an order which respects and reflects dependencies.

This is a two-dimensional time-line, since tasks that can be worked in parallel should be on the same piece of the time line. It's also a relative timeline - you're not saying that this task will be completed on 17th September, you're saying that this will take a few hours and it'll have to be done after these ones, and before those ones.

This is enough to give you a thumbnail - overly optimistic, typically - of the work that you're facing. This sketch will be modified as you go along, but what you've done now is that you, as a team, have spent some time thinking about what it is that you're doing, in greater detail than you'd done before, and you've developed some intuitions about what's going to happen, and how long it's going to take. This is huge. Your intuitions are wrong, of course, but still this is a big thing.


Now, you pull work and you do it. Everyone pulls one task at a time - nobody gets to just say "I'm going to be in charge of X". That exposes you to a major risk: suppose Bob is in charge of the GUI. And suppose Bob is a flake, or he comes down with a girlfriend, or he gets caught by the mob running a card-counting scheme at a casino in Atlantic City and takes a long walk off a short pier wearing cement overshoes, or something like that. Okay, now your GUI is screwy. Better to encourage everyone to get their hands on everything. That spreads the risk around, and it also means that your team is sure to understand all the parts, which reduces risk. (no single point of failure).

The important thing about this model is that you want to work as a team - the team succeeds, or the team fails. In the real world, if the GUI isn't finished in time, it might be Bob's fault, but that doesn't matter. The team has failed to deliver. Likewise, if what you produce is good, the team made a good thing.

There are lots of other details to consider - you have to set up and use source control, and everyone has to be committing their changes constantly, you need a bug tracker, and you need to agree on and abide by some style conventions, but I think a good schedule is probably the most important step.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1