tags:

views:

222

answers:

6

Here's a common situation: you have an existing application with large codebase and you hire a new developer to the development team. From my experience, it can take up to 6 months before that developer becomes fully productive. In the process the developer will cost much more than its' salary by taking the time of other team members and writing buggy code.

Question: do you have any tools or techniques you use to reduce this cost and accelerate the process?

+3  A: 

Pair programming and code reviews.

cherouvim
A: 

Make sure he is either shadowing or being directly mentored by an experienced team member. There is no substitute for direct, personal interaction.

It is difficult for a new team member to feel comfortable "bothering" a more experienced team member, so dedicate that mentor to spending time with the newbie. For as many working hours as possible.

Joe Koberg
A: 

Minimize their interruptions, and focus on learning at first. I mean really studying, like they are in school, in college, in the library. Give them stuff to read and then simply test their comprehension assuming you already know the details of the documentation they are reading. They shouldn't be typing or talking at all in their first two weeks except perhaps to ask questions having to do with soliciting some clarification on anything vague in the learning materials.

If you have a larger organization, perhaps those first 2 weeks should be pure class time with mesmerizing PowerPoint slides, and the next 2 weeks should be pure reading.

The minute that you make them responsible for "getting things done", junior devs will go off and over-specialize in whatever you threw in front of them at first that was actually something that they could accomplish, and that whole task set will end up getting away from you. It is important for junior devs to be fully assimilated into your overall culture and understand the values and direction of your organization.

6 months is insane. It shouldn't be that long, but the only reason it is that long is because of the initial pressure to produce anything at all. I know that's why.

Managers whether technical or not will just keep throwing junior devs at the wall until they stick to tasks their given. Bad move. Instead, know that it is your responsibility to get them ramped up. If you don't have time to do that, or cannot assign someone to give them some individual attention as they get ramped up you might be hiring too fast.

Try just easing off on the gas at first, and keep it in low gear and go really slow at the beginning. The pistons will thank you once they all start firing.

Christopher Morley
A: 

A wiki is a great area for them to post their questions to the team with the benefit of helping subsequent new hires.

Other best tools to give them are no different than the best tools your seasoned developers have: a debug environment to fail in, a debugger, and a free source of coffee.

While not exactly a tool having the developer handle support calls and emails for the project brings a great deal of upside. They will generally feel lost but the interaction with the other team members will lead to a paired programming environment mentioned above. Also not a tool allowing the new resource to review and categorize the existing bugs or feature requests will allow them to understand the project.

ojblass
+2  A: 

Make sure they spend 1-2 hours investigating something before asking for help. Also let them know they should come ask for help after that period of time. The reason for this is to ensure they are learning the code, but not becoming permanently blocked. It also means they'll solve a lot of their own problems and reduce the burden on the team.

Code review everything they check in. Don't be afraid to push it back for major rework. This will stop bad code from creeping into your codebase.

Steve Rowe
A set time to ask questions (morning, after lunch, end of day) might help.
ojblass
A: 

Code browsing tools like doxygen can be very helpful for new programmers to get familiar with the code. Especially with the INLINE_SOURCES and REFERENCED_BY_RELATION options enabled.

For very large codebases, a file indexing search utility can also make searches trough the code many times faster than with bare file searches or grep.
On Windows I use Copernic desktop search and I can't live without it.

total