Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When you add a programmer to a project with a large code base, what is the best way to get them involved right away? Do you give them formal training in the code base or let them figure it out themselves? What tasks are best to get them up to speed? What kind of tasks are "safe" until they are familiar enough with the project to contribute to it with a full understanding of what they're doing? How do you determine if they've reached a level of full understanding?


The project isn't behind a deadline. I work alone and want to add employees soon. I'd like to know how best to familiarize them with the code base.

share|improve this question

closed as too broad by MichaelT, GlenH7, Bart van Ingen Schenau, gnat, Dan Pichelman Oct 27 at 18:54

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

"Safe?" I assume you're going to review every line of code they write (at least to begin with), right? –  Mark Peters Sep 29 '10 at 18:24
Yes, the code would be reviewed. In hindsight, I guess that negates the safe part of the question. –  VirtuosiMedia Sep 29 '10 at 18:27

6 Answers 6

up vote 6 down vote accepted

We use a combination of techniques to get them up to speed.

  1. We start with training on using the product, what it is and why it exists, so that they get an understanding of our users.
  2. We then put them into the QA team for a short period, again to get familiar with the product and how it works.
  3. We then have them work on a number of applications that are not part of our core product - internal tools and the like. This allows us to introduce our development process, source control, coding style etc. It also gives us chance to code review their changes early on and get a feel for how quickly they are integrating into the team.
  4. As we gain confidence, we assign them bigger tasks to do, but still nothing on our critical path. If we have to revert all their changes and throw them away, we won't be upsetting anyone. We review 100% of all code produced by everyone on our team, but if you don't do that, I would certainly keep code reviewing the new team members code.
  5. Finally, we ask them to spend some time in product support fixing a few issues. This gets them looking at many different areas of the system.

As a few people have already pointed out, most developers learn from doing, so we try and focus on lots of doing. However, we do need to balance out the risk of just letting them rip and causing more harm than good.

share|improve this answer
I like this answer, but I say beware of the 2nd and 5th step. You do not want to risk losing a good programmer because they are working at finding bugs. Fixing bugs is great, simply finding bugs is insulting to their education. –  Stargazer712 Oct 15 '10 at 22:52
I totally agree with Stargazer. Programmers should not be placed as QA. It's definitely offend them. –  Rudy Jul 13 '11 at 2:43

Writing some unit tests can be a good way to break someone into parts of the codebase.

share|improve this answer
Will endeavour to remember this one in future, its sensible at various levels. –  Murph Sep 29 '10 at 19:18

My typical approach is to pick out a bug/feature that needs to be implemented that shouldn't require major rippling changes to the code base and let them work on it. There's really no "right" task to start them out on as it really varies from project to project (and skill level). I may walk them through the existing UI so they have an idea how to trigger the defect or where it should be most noticeable if they are not familiar with how the application works, but overall I let them dig in and make sure a senior level developer is around to answer questions as they come up.

If you're really worried about major breakage, then make sure they are working on a branch in source control rather than the master and don't have them merge until a code review has been done.

share|improve this answer

If this isn't under a deadline or something I would give them the code base and ask them to make changes. Even if the changes aren't necessary or needed, give them a separate branch and have them dick around with it.

You could also take working code and break specific things and have them work through the fix.

The fastest way I've ever learned anything is diving right in and working through it.

share|improve this answer
"We're not going to throw you in the deep end to see if you can swim. We're going to throw you off a cliff and see if you can fly" - The Big Kahuna –  JeffO Oct 1 '10 at 19:40
@Jeff: That's the mindset. :) –  Josh K Oct 1 '10 at 19:42
You have to see who is going to crack under pressure. –  JeffO Oct 3 '10 at 0:09

What if I told you that you could code review every single line the new guy wrote before he checked in, so you know he's not doing anything daft, AND you could personally show him round the codebase and tell him about all the odd quirks you know about, so he doesn't have to just figure it out himself, AND share your programming experience to help him do stuff better, AND he would be writing code from the very first minute?

Welcome to Pair Programming

share|improve this answer
Any resources on distributed pair programming? We probably won't have an office for a while, if ever. –  VirtuosiMedia Sep 29 '10 at 20:22
We've done it before just using Skype and screen sharing e.g vnc. There are things like saros-project.org for Eclipse, although I've never used it so I can't vouch for it's effectiveness. –  RevBingo Sep 29 '10 at 20:29
I should also say that, as with everything XP, the key thing is to do what works for you. If physical switching of roles is not workable (VNC is not always the smoothest of connections), there's more than enough value in at least spending an hour or two just letting your cohort watch whilst you code and commentate, let them make suggestions etc. –  RevBingo Sep 29 '10 at 20:33
Conceptually nice... How would you run this in a shop where you've only got 3 warm bodies? In this case it couldn't be full time, so how would you "schedule" the time (and how much). Don't misunderstand me, I think its an excellent idea (in this context I assume that its mostly the new person driving...) but more depth... –  Murph Sep 30 '10 at 7:28
This is how our company ramps up new devs. It's by far the most efficient way we have found. Plus, our team is 100% distributed. We use a combination of skype voice calling, join.me on each screen, and source control (checking in before switching coders). This works for 2 developers, definitely. We have also done it with 5... it felt more like a class, but it did the trick. –  Byron Sommardahl Sep 28 '12 at 13:23

Some bugs to get their feet wet, then assign some small features to them. Once they are up to speed, you can assign some more involved feature to them.

share|improve this answer
My first answer is the same, bug fixes - you need to explore the code to find the stuff you need to fix and to understand what you're doing when you fix it. A diverse selection will get you a touch on a lot of code. –  Murph Sep 29 '10 at 19:18

Not the answer you're looking for? Browse other questions tagged or ask your own question.