How do you give a junior developer a shot on a big project with tight deadlines?

Question

I'm looking for advice on how to give a junior developer a chance to gain experience on a big project with tight deadlines without hurting the timeline. If we all know it will take a little longer with the developer because of less experience, then what is the best way to give them a portion of the project and spread the risk? Giving these developers the ability to learn on the job on real projects instead of handing down maintenance work all the time is important to me, and I want to find a way to make it work.

Answer 1

Very short, clear goals that are measured and checked on very often.

Bite size approach will help the junior realize that big things are accomplished by doing the very small things, very well, over and over and over...

Also, consider doing the conceptual design, or a feature spec, or even the tech spec to get their feet wet and let them have more and more say if they take to it like fish to water.

Answer 2

How well do you know the junior? Certainly there must be something he/she has shown an interest or special aptitude in. Try finding pieces of the project that are digestible and fit the profile.

Assigning a mentor and making sure design and code reviews are a part of the process are important, especially if the junior is not well known.

If the junior is new to the subject matter, technology, or team, it may be advantageous to also make sure the piece he/she gets to work on is one of the better documented pieces (decent requirements definition, and possibly even a tech design already prepared by a senior). I have been able to do this in the past. I had a reasonably well fleshed out technical design of a medium-sized task, parceled out parts of it to a new team member, then also did code reviews and corrected the work. Even with the time spent doing the review and correction, it was a great way to get the new dev involved and use their ability to help finish the tasks. The new dev learned a lot along the way too.

Answer 3

You need to know if they grasp the problem you are handing down. When I have to do this here is my approach:

• Give them a piece I think is a stretch for them but doable.
• Explain the importance of the piece, how it fits into the larger picture, and how they will contribute to the project success.
• Ask them to go away, take some time to think about it and then write up several possible solutions with pros and cons of each. This shows me if they have grasped the problem and if they can design a solution.
• If they come up with something that looks reasonable, then let them at it. If not, we meet and discuss the problem some more and I give them another shot.

Giving them a chance to design the solution gives them ownership and lets them prove themselves. Having them communicate the design to you first with pros and cons gives you the confidence that they can complete the solution on time.

If they can not think of any possible solutions and possible outcomes of each solution then they are not ready to step up to this problem. They will need closer mentoring and smaller problems which have been designed by another more skilled developer first.

Answer 4

Although this wont work in all shops, pair programming is a great way to get juniors on board quick. However pair them with some of your more sociable developers for best results. This way they get mentored, are doing important work, and learning important things related to your work-style, and the more sociable devs in your shop will probably enjoy mentoring juniors anyways.