6 Tips for Programming in a Group

Every programmer will, at least once in their lifetime, have to work in a group setting. Most software today is just too large for a single developer to work on.

Programming with a group is a much different experience than programming by yourself. You need to worry about other people’s code, getting along with other developers and making sure your own material is up to standards. It can be a stressful time if you’re not prepared.

Here are 6 tidbits of information that will hopefully help make your group experience a little bit better.


Strong communication skills is a must when it comes to developing in a group. You need to coordinate with your co-workers where you are at in your development phase and where they are at in theirs.

When you program by yourself you know exactly how the software is coming along, what parts are done and what still need to be completed. When you’re working with a group you need to communicate to get an idea of what’s going on in the larger picture.


Once you’ve written your part of the software and your group members have written theirs, you still need to integrate. Even if you’ve communicated extremely well with your co-workers there are still going to be bugs with the integration.

Integrating code is one of the main things that programmers forget to account for when they’re giving their clients a project time-line. Integrating, even when done well, can take a long time to get everything fitting properly and all of the bugs ironed out.

Be a People Person

Being a people person is crucial to having a good group experience. Development is a team sport and you need to make sure that you get along with your other “team mates”.

While being friendly and polite is a good idea all of the time, you need to make sure that any differences get settled right away and don’t affect the group. Understanding that people will have different ways of completing the same task is vital to programming in a group.

Have Clear Expectations

Ask your fellow programmers what they expect from you and each other. Tell your group what your expectations are for yourself and them. It is good to be explicit about expectations from the beginning (you can always re-negotiate later).

A good manager will sit the entire team down before the start of a project so the programmers can get to know one another. This can help with conflict down the road and any personalities that just don’t mix.

Understand Your Place

If you’re the database guy, do databases. If you’re the front-end gal, design the UI. Knowing your place is very important in a group setting. One of the things that annoy me the most when working with a group of developers is when they try to shove their “experience” into my face and tell me the “right” way to do things.

I’m not saying that you shouldn’t try to help out others by giving them advice, I’m simply stating that if you’re not the expert in a certain area, don’t try to force your ideas to the person that is.

Set Realistic Goals

This is probably the most important tip and is aimed more at the manager of a group than the developers. Setting unrealistic goals is one of the easiest ways to make sure a project fails. If you set goals that your team won’t be able to meet, it will only hurt morale and damage team spirit.

Setting proper, realistic goals is a good way to keep team spirit high and make sure that great software is made.

Your Thoughts?

Programming in a group is extremely different from programming by yourself. It can be very rewarding or it can be a pain in the butt. What are you thoughts though? Have you ever programmed in a group? What made your experience positive or negative? Feel free to drop us a line in the comment section below.

If you like this post then why not share it?
  • StumbleUpon
  • description
  • Technorati
  • Digg
  • Slashdot
  • Design Float
  • del.icio.us
  • TwitThis
  • Reddit
  • E-mail this story to a friend!
Add devjargon( ); to your RSS Updates.

Get new posts sent to you by email for free!


  1. 1 07.03.08
    7:44 pm

    Essential to a term project are proper source control and unit tests. What you really don’t want is to have someone permanently delete a part of your code, and not have anyone notice this for weeks.

  2. 2 07.06.08
    1:24 pm

    Very true, Tony. On top of that, regular backups are a great idea too, as CVS can only protect/prevent so much.

    At work we had one of our new hires completely remove a project from CVS, by “accident”. Still not sure how you do a CVS-Remove, and commit that without noticing the 3 alerts that check to make sure you’d like to do that, but hey…I guess anything is possible.

    Needless to say, that guy didn’t stay with us much longer, and we would have been really screwed if we didn’t do regular backups of our CVS server.

Leave a Comment