Monday, April 9, 2012

Tips for Working With Others

Many of us software engineers work somewhat in isolation. Yes, most of us are on teams and yes, most of us are working in the same code base as other engineers. However, code bases contain thousands of lines of code, with dozens or hundreds of modules (or classes or files or whatever). The truth is that most of us kind of work off on our own most of the time.

For example, I have one project where I spend most of my time working in the reporting module. There are about 8 other engineers on this project, but I'm almost always the only one working on reporting. In the sense of the overall code base, I work with the rest of the team - it all gets combined together and deployed together. At the module level, though, I don't work with others very often.

Contrast that with another project, where I'm writing some Selenium tests for a client. There's another engineer here writing Selenium tests as well. This is a big project, so he and I have divided it up, but we're still both working within the same modules. I'm working on test A while he's working on the Page object, and I'm working on the Page object while he's working on test B. At the module level, we're working quite closely together.

This kind of close collaboration is a lot of fun; when it goes well you get a whole lot done quickly, and you can use each others' work to accomplish a lot quickly. It's also really easy for this kind of project to go poorly, for it to end with shouting and tears and a whole lot of deleting of code. So, if you ever find yourself in a situation where you're doing something like the Selenium project I'm working on, there are some things you can do to make it go a lot better:

  • Update your code often. git fetch or svn up frequently - every time you finish a small task. This will make sure that ya'll don't get too far apart, and will help prevent merge problems.
  • TALK. Talk about what ya'll are going to do frequently. Mention what you're doing. Describe what you're going to do next. You'll spend less time duplicating each others' effort and more time using each others' helpers.
  • Keep your checkins tiny. Don't check in dozens of files and hundreds of lines of code. That's just asking for a merge problem. Check in small changes, and remember that the "wip" convention in commits is a valid choice.

It can be a great joy to work together  - even on the same code - with someone, as long as you're careful about how you do it.

No comments:

Post a Comment