Take the 2-minute tour ×

I've worked in team-based environments most of my career, but not as a programmer. (I am trained as a musician/composer.) I'm becoming aware of programming specific team-based concepts, though--slowly but surely--such as Version-Control, SDLC, documentation, etc. I'm getting a certain theoretical understanding, but not really feeling confident about it. I'd like to practice anything I can to help me learn how to work more effectively in a team. ...before I actually go and bother someone with my heavy-handedness or ignorance.

I'm not sure if it's possible or even recommendable to attempt to 'practice' team-based methodologies privately. Maybe the only way to really learn how to work in a team is to just experience it. Likewise, I wouldn't know how to explain teamwork to another musician, but as musicians we don't really have codified methodologies in the same way that programmers do, and I think that could make all the difference. In music there are certain conventions and inflexibility due to the mechanical nature of the instruments/recording equipment (akin to hardware/language, I suppose), but otherwise we kind of make it up as we go along (and I assume programmers do a little bit of that, too, depending on the context--I wouldn't know. That's kind of what I'm trying to figure out).

I'm pretty sure that the inevitable answer is that I should work on something open-source; the world is flat, after all, and it's not difficult to communicate across great distances as a programmer (like it often is with musicians). But my feeling is that I'm not ready for that. I would feel safer learning how to approach teamwork with programmers before just diving in, because programmers can perhaps be a little persnickety. I'm trying to avoid a trainwreck-type of experience that might cause some irrational fear.

So is there anything I can study beforehand, and if so, is there a generally accepted way to go about it? Like mock-teamwork, team-related practices that can be practiced privately; is any of this making sense?

share|improve this question
IMHO ... Version control software is a great tool even by yourself. "Doh! I just permanently deleted that important file!" Done that before. But it does really shine when you are in a team environment. So I'd +1 for trying some team based things by yourself to begin with. –  James Khoury Oct 4 '11 at 3:10
@James +1...I forgot to mention that in my answer. I consider version control an important part of every project, regardless of whether or not I am ever planning on working on it with other programmers. –  dbyrne Oct 4 '11 at 22:39
add comment

3 Answers

up vote 1 down vote accepted

You are right that getting involved in an open source project is the best way to learn to work in a team. My advice would be to get involved in a small (but active) project that you are passionate about. Small projects are usually thrilled to help out new contributors, and are more likely to tolerate your initial growing pains.

Once you've picked a project, I would spend some time getting familiar with the technologies. If they are using git or subversion, go through a few tutorials and check the project out. Go read the wishlist or bug tracker and start coming up with ideas for bite-sized enhancements that are within the scope of your abilities. Once you've done that, get in touch with some of the contributors before you start work. They will almost certainly have some valuable feedback for you right away, and will keep you from wasting your time going in the wrong direction.

share|improve this answer
add comment

If you look closely at your background, you'd find a lot more parallels between things that you have done and these software processes than you'd think.

I have never written a piece of music, so pardon any loose analogies, but I'm certain that there is quite a bit of planning/designing before you'd start a piece of music, as you need to know what type of group (orchestra, quartet, punk band) for which you are writing it, and what their capabilities are, in the same way that you can establish the parameters of a software platform.

You broke down your music into measures, and perhaps worked on it in movements, shuffled those around as needed (refactoring!), played a few out loud in isolation (units!), and combined them together (systems integration!).

Eventually, the whole group played the music, and you decided whether or not it all worked well together, and you can refine it, test it out, bring it all together over and over.

People probably made changes on their own sheet music, and some of those were brought back to the main piece of music, incorporated, and new copies were redistributed...

I agree with the other answer, in that, an open source project would be a great opportunity to perfect your skills in these concepts within the software realm, but don't discount a lot of the experience you (probably) already have in related areas.

share|improve this answer
This is an interesting and clever simile. I agree with you that a lot of this experience will definitely come in handy, but the parallel doesn't really line up as well as I wish it did. Composers are often told to make magic happen specifically with very sketchy or non-existent 'requirements,' (because the commissioner is usually looking for some nebulous notion of personal expression and originality that doesn't actually exist) and the finished piece is often discarded instead of critiqued and allowed time for improvement. The comparison to coding in general, though, is spot on. –  user25791 Oct 4 '11 at 14:51
Actually, for playing in a punk-bank (done that too), the comparison works much better. And I wish 'classically trained' composers did more work with that kind of methodology. –  user25791 Oct 4 '11 at 14:53
add comment

I don't have a musical background so I don't fully comprehend any similarities of playing in a band and being on a product development team, so the following my be mooted.

Working in a team is more than understanding underlying tools used by the team. It is more about the interaction you have with each of the team members and also with the team at large. That's is why when the team members changes, the dynamics of the team changes as well.

If all you want is to get a quick understanding on the tools, using it by yourself is a good way.

Get involve in an opensource project is a great way to experience some of the team atmosphere.

If possible, get involve in a opensource project that have a high face-to-face communication factor. This is so much different to one that occurs mostly online.

share|improve this answer
It would be great to work face-to-face (I would absolutely prefer that). I wonder how to go about finding something like that (in North Carolina?) –  user25791 Oct 4 '11 at 15:00
add comment

Your Answer

