How do you get newcomers to get started on a existing project?

Question

When you are in a running project, how do you get newcomers to get started? What is, in your opinion, the fastest way to get them up and running? How do you get them to know the code and the project culture quickly so they can catch-up fast?

What do you do? Give them defects to solve so the have to dive into the code? Do you give them documentation to read (so they get bored)?

I recently started on a project, and I was assigned defects as a starting point. As always, I don't have access to the SCM yet (but I have the sources), I don't have a mail yet, people don't have much time to help, etc... So here is the other question:

How, as peon, do you get started on a project? What can you do to make it more effective?

Answer 1

A quick meeting with one of the existing developers, preferably one as "senior" as possible, is helpful. It's good to hear anyone actually talk about the project, since that gives you a lot of clues as to what parts are interesting, what they are doing, what interfaces to what, and so on.

Getting "the big picture" of a new system can take a very long time, and I while I don't think it's possible to cheat and just get it immediately, it's at least possible to speed up the process.

Such a meeting need not be very long (an hour, perhaps?), and I also think it can be quite fun/interesting for the existing developer(s) too, since talking about things you know well usually is.

Answer 2

I think the best thing is to assign bugs to new people, for them to fix.

As the new guy, I'll often do some things to help me understand the new code base. I'll reverse engineer the code into UML using Sparx Enterprise Architect. Same with the database. In both cases, this gives me the ability to search the reverse-engineered model to find things like types and column names. I can also create diagrams based on the reverse engineered model. The diagrams can focus on one area I'm interested in learning.

I'll also use ReSharper to do test refactorings of areas of code. These would be aggressive refactorings and reformatting to make it easy for me to read the code; I do not check these back into source control!

Answer 3

Helping them jump in as quickly as possible. You only really learn by doing something :-).

Identify small bugs / new features with limited scope, and have them go at it. Possibly assign them a mentor they can always ask questions.

Giving a formal introduction talk is also a good idea, but mostly information should be supplied "on demand" (otherwise it'll be forgotten quickly). Of course, you should answer not just the literal question, but give some context.

Answer 4

I like to get a quick look at the design docs, and skim over them. I've found the best way to get to know the code base is to tinker with it by adding new functionality or fixing bugs.

It helps if there is somone who you can ask questions of.

I have been thrown in the deep end once or twice having been told I think there is a Thread safety problem somewhere in there can you see if you can find it, without even being told what the code was meant to do. That was not so useful.

I've found, when getting other people up to speed with a project that spending an hour or two of my time showing them the ropes and telling them what the different components do and what external tool we use saves time in questions later. Thats how we dealt with doubling the number of devs on our team of 4 overnight, I think it helped an aweful lot.

Answer 5

It really depends on the experience of the newcommer in software, experience in the domain (industry)/technology the project addresses.

The first thing I do is assign a coacher to that person, to take care of onboarding:

• explain to him the project (overall things)
• set a bibliography of documentation related to project
• present architecture stuff.

Then, depending on the experience, I might put the person to solve new features, independently (not the critical ones, but some with lower importance), or put him in a pair-programming mode with his coacher in the beginning, then involve him in "productive" tasks.

I usually not use bug fixing for getting hands-on the project, because the risk of introducing side effects when fixing a bug is significantly higher than for the other people, already in project. If I have no other choice, I let him make the fixes, but have his changes reviewed first by somebody else, before committing.

Answer 6

• Start making yourself familiar with project file structure
• Read developer docs (if there are ones)
• Have some basic issue assigned to you, explore it, fix it, rinse, repeat ;)
• Find a friendly person (alas, not all of the developers are friendly) to refer to with questions
• Along the way, start inspecting database schema (if there is db backend)
• As you progress try to solve more complicated issues
• Start taking part in public discussions, express your ideas

Answer 7

The quickest way to learn how something is done is to see it happen.

I would pair the newcomer with an someone who's worked on the project for a while. Soon, our newcomer will know where to look for solutions, and thus be able to figure things out on his own.

Since you're the newcomer in this case, I think defects is a fine starting point :) . Just keep asking your experienced team mates questions.

Answer 8

In some companies (especially those that are too busy to give you the time you need) it's easier to beg for forgiveness than it is to ask for permission.

What I mean by that is the following: Don't spend too much time trying to understand a problem before attempting to fix it. It often works to try something, then have that reviewed by someone that knows what it should have done. If you got it wrong, they will tell you, if you did it right, the quick turnaround time will make you look good.

This obviously assumes that your attempts are at least intelligent. You don't want to be branded the team dunce either. But ask the dumb questions earlier on. The longer you leave them, the more unforgiving the environment will become.

This obviously wouldn't be a problem if the documentation was up to scratch. I worked for Accenture a couple of years ago, and I was actually productively creating useful code on my 3rd day (first 2 days where HR type induction). It may also only have been that one project though. But I have never before or after experienced the same thing.

Answer 9

Others have mentioned getting the new guy (or gal) to look at fixing bugs. I think this could be counter productive as it could involve some detailed product knowledge both to find and then safely fix the problem. It could also de-motivate someone.

On the coding side a small, self-contained sub-project is probably best. It will give the new starter a way into the rest of the project and produce something useful.

On the management side, make sure they are included in all relevant meetings and that they are treated as a full member of the team from day 1. Assign a mentor and also schedule some tutorials on the project and it's history. Knowing where the project's come from is important when it comes to understanding design decisions.

Answer 10

After introducing them to the architecture and the documentation, give your newcomers little projects. Choose that projects under the following topics:

• projects should be small and reasonable
• projects should contribute to the "big picture"
• projects should deal with the issues of your main project

This way, people get in touch with your main project and have to learn the foundation (e.g. working with framework XYZ). The newcomers get momentums of succees, which is very import. Due to this, they get motivated instead of bored. Motivated workers are good workers ;-)

Answer 11

I also just started a new job and jumped into a new project. What helps me the most is to be given low-hanging fruit tasks. These are the kinds of things that someone familiar with the system could do in just a few minutes. They aren't difficult to program, but they force me to become more familiar with the system. Good ideas are anything that relates to the structure of the project like automating a process or importing data.

Answer 12

get to know the environment first, your team's approach to tasks and how they solve it, that tells you a great deal on how to reverse engineer existing code to fix defects. have document as a reference only when you are stuck, or to find the piece of code you are looking for, I would definitely recommend you knowing the architecture and business rules before you get started, if you have a fair enough experience in dev, you will be able to pick up code and fix defects quicker if you know what you are doing.

hope this helps.

Regards,

Answer 13

In IT, it is always possible that new people will be added to the running projects when requried.

1. Gather as much as deatils about the project from all available sources
2. Try your best to get an existing person to explain the business requirements. And try to keep him as a mentor.
3. Since you ahve the source code you can dig into it to find what all technologies it uses.
4. Spend (extra) time to learn the necessary technologies (Eg: Ajax, jquery, etc.) you find difficult.
5. Rather than reading the whole souce code, give a quick start in the module which you are supposed to work on.
6. Learn the rest of code when ever you need them.

Initial days will be tough for sure. But things will get stable once you started.

Answer 14

You're actually asking two different questions here: "What can the team do to help the new member?" and "What can the new member do to help the team?"

In answer to the former, we do pair programming. From the beginning, the new guy is working on the same projects as everybody else (well, okay, selected projects, but still real iteration work), but working with an experienced member of the team. And not the same person all the time, either; we try to swap pairs frequently.

It slows down the experienced developer for a while (having to give background, draw diagrams, let the new guy have the keyboard and make mistakes), but there is no quicker way to get the new guy up to speed as a full-fledged member of the team, able to chip in anywhere they're needed.

Answer 15

First thing for some one to get started on a project, I would suggest, keep a well documented project. Documentation, even though boring if long, should be kept as concise and as to the point, it could be

I have a python, java, C background. And mostly I prefer python. So let me put my examples in python

My python documentation is of such a format. choose a style which is followed strictly in your project.

"""
This program does so and so, a single line explanation

arg1 does so and so. arg2 acts on so and so. It returns a list of something

Detailed explanation of exceptions, process etc.

>>> code.samples
expected result
>>> code.samples.failed
traceback
...
SomeError
"""

Anyone with interest would start reading some sample codes, so this will be a good point to start, which explains what a function, class, or method does.

Next up.

Maintain a wiki, there are n number of wiki engines out there. For python, you can use moin-moin.

Thirdly,

For a newbie, it is hard to just put him stay, he would definitely bored, instead of boring trainings and all, you can just throw him into pair programming with one of the experts. This is an well tried formula in extreme programming. see wiki http://en.wikipedia.org/wiki/Pair_programming Any newbie will learn faster, if he is explained some concepts in person, rather than him reading things from other written sources.

Lastly,

Put give a newbie some work to do, he can start on building tests for a program, he can compile the programs if you are using a compiled language(C/C++/Java). Let him, work on changing a functions while sticking to unittests.

These would be my two cents on getting a newbie started. Don't just put him into courses and trainings, let him work on the project, even if he tends to break stuff, let him work on his own copy.

Again, see that the newbie is really interested into programming, else all this will not work for him. I have seen some guys who just get onto projects, just to satisfy their personal agenda, and sometimes just jeopardize the project. Avoid such ppl.

Most of what I said, refer to an open source projects or community maintained projects, might not just be holding true for enterprise or corporate projects, which stick by their own rules. Always follow rules.

Answer 16

Q: When you are in a running project, how do you get newcomers...to know the code and the project culture quickly so they can catch-up fast?

We set two goals for new hires.

1. Build familiarity: New folks attend 2 code reviews the first day. They meet developers, see project code, and can ask questions. Continue including them in code reviews until they choose to stop.

2. Build group respect: If the new person blogs, uses StackOverflow, or contributes to a public project, link to their profile or work. If you have a project wiki, show them how to post questions and when they can expect answers.

First three days, two people (typically 1 manager and 1 developer) have lunch with them. This gives outgoing folks access to their experience and lets reserved people absorb some culture without forcing them into a 1-on-1 conversation.

Q: How, as a peon, do you get started on a project? What can you do to make it more effective?

If possible, I start work in the lunch room, a conference room, or another public area. I put something unusual on the table so people will ask about it. Conversation sparks inclusion, a tough thing to achieve early in a new job. The technical side comes easier once you know something about the people.