New Developers in an Agile Team

Two new developers, Jonathan and Andy, have started at Esendex this past week, both fresh from university. I'm sure they'll start their own blogs soon enough, so watch this space.

It's got me thinking about the best way of introducing them to the work that they will be doing so that they can be productive as soon as possible.

Esendex developers are very agile for the most part--we're able to turn out new and updated tested functionality relatively quickly--but while this is great for the company and our customers I'm sure it must be overwhelming for a new starter.

Documentation helps, and we do have some which explains (in loose terms) the architecture of the internal messaging system, and how our system's tiers hang together. But for the most part knowledge is passed verbally, if only because the entire system is far too large to describe in documentation. After all, we'd do nothing but write documents if we had to document everything.

So the way we have introduced new developers before (and how I believe Andy and Jonathan will be introduced this time), is to get them exposed to the code as soon as possible, and let them ask questions so they get things straight in their own minds.

Pair programming and test driven development helps here, so they'll always have someone to direct questions at, and the tests should make it clear if something will break another part of the system.

I guess the key is to not flood them with too much information to begin with. People can only take in so much information at any one point, so introducing someone to part of the system they are not currently working on will only complicate things.

If anyone has any suggestions, or stories about what you do in this situation, then please leave a comment.