How to get new team members up to date with the project?

Question

We are about to hire 1-2 new engineers for the software team (consisting of 3 developers, 1 tester).

What are the steps to integrate them into the team?

My ideas are :

• read documentation (coding standards, documents in development methodologies we use)
• get them to read the existing code
• assign them some simple tasks
• at the end, make them responsible for the code part

What else could we do?

---

The project is in a medical sector (ultrasound system), and is already 5 years going. We have yearly releases, and we are about to finish one release, when we want to add 1-2 engineers.

The project is in the maintenance phase (refactoring legacy code, plus adding new features). Things are pretty much on schedule (more or less).

Answer 1

Coming from someone who has had to come up to speed on a lot of different codebases in my career, here's what I would suggest:

1. Spend a short amount of time (maybe a day or two) with activities related to using the product so that they can become familiar with what the product does. This could be verifying bugs or executing QA test plans or going through user training.
2. Work on small, localized bugs. This gets the engineer familiar with how to build & debug the application without having to deal with learning a lot of the architecture.
3. Ideally, write a small new feature that's localized. This lets them write a chunk of code and as they write it they will become familiar with the surrounding bits of code that their new code needs to work with.

From there, expand the scope and complexity of assignments over time depending on the engineer's experience level and aptitude. That will let the developer expand their knowledge of the codebase naturally.

I would avoid reading only tasks (documentation or code). Reading documentation gets really boring really fast and reading random code isn't helpful since they won't have any context to work with. It's hard enough to read code for code reviews when you already know the product & codebase. I can't see anything useful coming out of having a brand new engineer just reading the code.

Answer 2

My feeling is that most people's tolerance for reading documentation is fairly low (Good for a day or two, but beyond that they'll probably be itching to do something a bit more hands-on).

I don't think you can really get understanding of an application's code without a reasonable understanding of the application itself. The software presumably has plenty of functionality which they could 'toy' with as a user; they're going to need to be able to test it eventually, so I'd expect that its fairly important that they know how to install it, configure it and perform common tasks with it

I personally find that a high-level architecture overview is usually quite handy for getting a basic feeling of how things work - Maybe allocate an hour or two of a senior engineer's time (or yourself if necessary?) in their first week simply to go through the basic nuts'n'bolts of the main application. e.g. understanding all the subsystems and how things are tied together, knowing which bits are handled by 3rd-party software/libraries and which bits need to be maintained in-house. (Unless your organisation has got up-to-date documentation of truly exceptional quality, I'd guess that there's no way they're going to get a grip on that sort of stuff without someone explaining it to them directly using a whiteboard :-) )

As for giving them something "hands on", maintenance/bug chasing tasks might be a good way to get them up to speed for a while (a couple of weeks/months?) - they'll be in situations where specific areas of functionality need to be understood, tested and debugged; helping build up knowledge of the code, the requirements, the tools used by the company, the development processes and the product(s) as a whole while hopefully not needing to soak up too much time from the rest of the development team

Answer 3

As the Lead, I spend at least 2 days with new developers. I've found that developing a relationship in which it feels comfortable to ask the inevitable question "how is your progress?" is a MUST. There is fear in any new community to fit in... we hide mistakes, act perfect, make things better than they are, lessen difficulty. A manager spending 2 days with someone will let them know that's not what their culture is about, and allows them to lead by example. New coders need a history lesson about where you came from and how far you are along. Documents just don't do the task justice.

Answer 4

I've only been working in industry for 10 months (On placement) but I found the following helped me:

• Teaming up with other developers and observing how they tackle issues.
• Testing the software helped, I would need to test feature x which means I read the documentation on feature x. I did this a lot, it helped.

Both of those helped me a fair bit. Good luck.

Answer 5

I would go from high level to low.

Demo the app as soon as possible

One of the most important things is that the developer has an idea what they will work on. During the demo, point out some of the things that have been under recent development, and the direction the app is going.

Explain the high level architecture

This is also very important. Allow the new dev to listen and ask questions. Do this as a group exercise with the other devs, who will hopefully chime in and help you out. This will let the new developer know that it is OK to speak up openly and honestly.

Have a great on-boarding document ready

Having a great on-boarding document does not only help new devs, but old ones as well. It can contain expectations, useful links and environment setup information. (I cannot tell you how many times I used our on-boarding to set up my environment when I get a new computer...) This should be well structured and to the point and not linger on and not be a dumping ground for every little detail.

Encourage him/her to ask questions (and be available to answer them)

With the answers, guide them, but do not tell them what to do. Give them hints but allow them to finally figure it out themselves.

Help the other team members welcome the newcomer

There is two sides of the coin when someone joins a team. The team needs to have the tools to welcome the new developer as well.

Let them pick up a small task or two

Allow them to add something new and visible to the project that is demo-able. When it is demoed, call out who did it and what a good job they did. This can really boost self-esteem. The faster they feel like they are adding value, the faster they feel they are part of the team. The faster they will feel empowered to do the best they can.

Encourage them to getting into harder tasks once they feel more and more comfortable

Good candidates will do this naturally.

Answer 6

1) Give them an explanation of your code rules and guidelines. Also give a general explanation of how your application works and the general code structure.

2) Find some small bugs or projects that are largely independent of other code. Explain what needs to be done, where in the code and check on them regularly.

3) Slowly start giving them larger and larger projects while checking them less and less.

4) Sit next to them from time to time. You can learn a lot by just looking how someone else tackles a problem. Small things like "oh, you can look for functions in your code by presing ctrl-." are very useful.

Now, I've found that there are two extremes:

• Someone who asks a question every five minutes. "What does this Path.Join do?". They should Google first for an answer and only come to you when they can't find an answer.

• And the other extreme, someone who works for half a day without asking a single question. They should feel like it's a good thing to ask questions. I just want them to first try it out themselves.

Answer 7

One "orientation" flow that I've been through (and found useful) was something along the lines of:

1. A brief presentation giving the "Big Picture" what the components are, how the fit in and the general architecture.
2. An overview of the code, intro to the functions that handle the main logic for the component(s) assigned to me. Covered some stuff related to coding conventions and style.
3. A bunch of open issues and low-priority bugs were assigned (which were largely localized to the component assigned to me and fairly simple).
4. I was expected to debug through the application and ask for help with stuff that I couldn't decipher.
5. After the fix was made, I was walked through the the process (code-review, dev-level testing etc.) of releasing to integration.
6. Repeat for the remaining tasks/bugs allocated.

I feel this approach (and variations of it) will be useful because:

• This was a more hands-on and relatively independent (constant no hand-holding etc.). So, it provides enough room/time for the new person to get used to the code and the way things are done in the team.
• It is also beneficial to the team as a whole since a couple of low-priority tasks/bugs can be resolved. The person helping out the new people also has more time for dealing with tasks assigned to them since constant hand-holding is not required and time can be specifically scheduled to deal with problems/issue that the new person might face.

Answer 8

Initial hires need need a small, but not too small, and well-defined task to work on. This way they can start getting a feel for how the code is structured by trying to figure out how to accomplish their task. In the process questions will come up and at that point you can direct them to documentation or other resources that they can use to help them internalize the code base. It also helps if your develop, commit, deploy cycle is short and they can see the fruits of their labor in action as quickly as possible.

Answer 9

This is how I go about

1. Give them some tasks which are related to the project.(e.g.: If your project is database application ask them to just create an application to connect with the database and perform some simple operation.)
2. When you find they have understood the idea of working, give them a demo of the Project
3. Ask them to read the documentation.
4. Make them familiar with the coding styles and standards
5. Later give them some debugging exercises(to know the flow of the project).
6. Ask them to fix a point that you have already fixed (just to find out their logic with it).
7. Finally make them a part of the project.

Remember : no matter how much you try, until and unless the joinee understands the project completely you wont be able to get work done most efficiently out of him.

Answer 10

Number one - first learn how to use the software to discover what problems it solves from the user's perspective. If it doesn't have a UI (e.g. its a backend service or something), let them use whatever interface is available to consume it. Getting a fresh take on a user's view of your software is always good, and it might help the new employee to see things that you can't, due to you being embedded in the project already.

After this, a good first project might be something like an add-on or new module to add to the software, minimizing the amount of knowledge needed of the existing codebase. Writing something new is always going to be easier than performing a bug fix, which might require lots of changes across many source files. In my opinion, giving a new employee a bug fix task will probably turn them off your company.

Answer 11

Your outline to familiarize the new ones with the project seems reasonable. But keep in mind that they will have a lot to learn in the beginning. This is usually an overwhelming situation. You will have to be patient and answer the same questions repeatedly. This is normal, new developers have to learn a lot, don't underestimate this. If you get angry about these repeated questions you'll risk that they will not ask and try to find out things alone which maybe very slow at best but frequently impossible. Also they will have to learn the lingo. Most teams projects develop their own language. When explaining consciously try to avoid the lingo. Explain this stuff like you would explain it to your mom. Again, be patient.

Additionally, you could try to integrate them with the others already on the team by trying some assessment center style tasks e.g. build a bridge in 45 min from 4 sheets of paper supporting a coffee cup. We use this technique in a practical course in software engineering to get a group of 8 students to break the ice before they work on a single project for 3 weeks. It helps to speed up the team forming phases.

Answer 12

These were my formula and used with several new comers - these steps proven to be highly effective.

a) All new developers will be given some introduction about the project requirements and development processes for 2 days.

b) Assigning 3 weeks task of writing Junit tests for the code which does not have enough coverage.

c) Once 3 is done, assign small tasks

d) Assign complex tasks and done.

Answer 13

I think just assign some small tasks, ask them to write a few unit tests, make them debug some regression fails. Nothing too big or demanding, but enough to have them on their feet.

You should also assign a senior developer, preferably per new developer who could help mentor the candidate.

And yes, make them document what they are learning about the system. I am assuming here that you have some sort of internal wiki pages. If not it's definitely a must in both the long and short run - surprisingly fast way to have people ramp up. Wiki pages should not contain just the code documentation, but also stuff like known limitations (this is software :D), workarounds, time/memory performance metrics etc.

Answer 14

Don't explain only the good practices and standards of coding, but explain how the read code is structured. Explain what the software is supposed to do and how this is or will be achieved.

They will not understand until there is some job to do, so I suggest will to split into two parts, one before they start the real work, and the part two, after they started to work. They will look in some code or documentations and think "WTF!?". When this occurs, someone will be accompanying them and explaining the minor details.