Avoiding headaches as a team programmer

Working as a member of a software development team (as opposed to being the only programmer on a project) can have some subtle, but very important differences. I’d like to share with you some of the tips and advice I’ve come up with over the years to reduce headaches and frustration – both for me and my fellow team members:

Communication

  • Don’t assume that your team will tell you everything you might need to know. There’s a lot to keep track of (even on small projects) and we’re all human. Sometimes we forget or don’t realize that the changes we’ve made impact somebody else’s code.
  • It can often be helpful to send out a status e-mail each night, letting the rest of your team know where you’re at – what’s done, what’s changed, etc.
  • Document any agreements/decisions made between two or more team members. This helps ensure that everyone came out of the discussion with the same understanding, and can keep new members from wasting time covering the same ground.

NOTE: “Documenting” doesn’t need to be a formal process. An e-mail, IM or shared discussion area is fine. The important thing is that the information is recorded and shared.

Source control

  • Multiple, smaller sets of changes are¬†much¬†easier to rollback, troubleshoot and/or fix than large, sweeping code changes that span several days/weeks.
    • Whenever possible, try to organize your coding tasks into chunks that can be completed and checked in within a day.
    • At the end of the day check in as much as you can – anything that doesn’t break the project for somebody else.
  • Before checking in your work; pull down and build the latest files to make sure your changes don’t conflict with any recent changes made by other developers.

NOTE: I do this even when nobody else is working on the project – because that might not be an accurate assumption. If the project is in the repository, anybody can make a change at any time.

  • Before beginning each new task/chunk of work; pull down and build the latest files from the shared repository. This will catch pre-existing issues before you start adding your changes.
  • Key project-wide files (e.g. settings, configuration, the project file) should be checked in as soon as possible. And don’t forget to also check in any new files and/or changes they may reference.

Documentation

Even if nobody else is going to be looking at your code, any experienced programmer will tell you that in a couple of months you won’t be able to recall what you were thinking either.

  • Use clear, descriptive names for your classes, methods, etc.
  • Add comments to code that varies in any way from what it appears to do, has a side effect, etc.

All this can seem like a lot to do in the moment. It can feel like you don’t have time. Establishing a routine can help. Decide on a few things you are going to do every morning, before you start coding, or first thing when you get back from lunch. This can also help you get into the right frame of mind for getting back to work.

Comments 1

  • Shawn,

    Good tips on team collaboration. I read them and will try to keep them all in mind with the Team Foundation Server/site (TFS) us WA developers are starting to utilize.

    I come from a strong individual programmer background and I am weak (to say the least) at proper etiquette with team programming and hope my learning curve is tolerable when in you come in contact with me.

    Thank you again for the tips and the TFS your team has set-up.

    8D…ave

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: