What is the best way to get a new developer up to speed?

Question

We are a small software company and in going through a technical evaluation recently, it was brought to our attention that we lacked an "onboarding" process for new developers. "Onboarding" is exec-speak for a process for getting new hires up to speed. We do have a process which is:

1. Get the new hire setup on their machine including access to domain, source control, issue tracking etc. While the installation of software onto their machine is done before they arrive, some time is needed to answer questions like "Where is your SCM?" and "How do I log into it?". For example, while the source client is already installed, new developers aren't going to know what program we use or perhaps even be familiar with that client. They know SCM in general or they wouldn't be there but not necessarily our client. The same is true with our issue tracker.
2. Spend an hour or so going over what the company does, how our solutions solve problems for our clients and general system architecture.
3. Introduce them to other developers.
4. Let them spend the rest of the day reviewing the architecture and source for one of our products. That means pulling down the code, compiling and running it and/or looking at database diagrams.
5. The next day, give them some specific project on which to work along with introducing them to the stakeholders and other team members on the same product.

My main questions are:

• If this process is insufficient, what is it missing?
• Is there a recommended onboarding process for developers? It would help to know how do other software companies do their onboarding (or how to go find out they do it).

Lastly, and I realize this may be considered a separate question, how should that process be documented?

Answer 1

I think you need more than the day or so you're spending on this. Telling people stuff outside of a context in which they'll use that knowledge only goes so far.

Our process (smaller enclave in a large company) goes like this:

Morning of first day: administrivia -- passwords, HR stuff, time-reporting training (needed for compliance tracking), tour of space with introductions to key people. (Not just the key technical people, but also the ones who'll help you if you lock yourself out or set off the alarm, need to submit expenses for reimbursement, IT support, etc.) We would prefer not to lead with paperwork, but it blocks other key tasks, including access to the corporate network, so we have to get it out of the way.

Rest of first day: spent with your mentor, a technical person working on the same team you'll be working on. This is a mix of tools (not just what the SCM commands are but how we use branching, for example), project architecture, and acculturation (how we do things, informal resources like the wiki, who the key gurus in various technical areas are, where to eat lunch...). This is pretty free-form, guided by the style of the mentor and the needs of the new employee.

First week: continued mentoring (mentor should be spending an hour a day on this, minimum), and the new employee is assigned several bugs to fix. The mentor helps navigate through the code (it's a large code base), coding standards, bug process, etc. All bug fixes are code-reviewed (everybody's, not just new people's); the mentor usually does informal reviews of these early bugs before they're sent for official review. Concurrently, continue to review important documentation, start using the wiki, file bugs as they're encountered, etc.

First couple weeks (variable): newcomer is assigned meatier tasks alongside bug-fixing and begins contributing more directly to development. This varies based on the experience of the newcomer and the current phase of the development cycle for that project.

First month: new employee meets with his manager to do goal-setting and discuss expectations. (Our performance-review process involves formal goals that are evaluated at set times; this will be the first set for this employee.)

Answer 2

Get the new hire setup on their machine including access to domain, source control, issue tracking etc.

Setup should be done before they arrive. Development practices should be automated as much as possible, and the manual steps should be documented. If you regularly have to execute multi-step procedures to perform routine developer actions (check out, check in, test, release, etc.) then your process is insufficiently automated and you are wasting money.

Spend an hour or so going over what the company does, how our solutions solve problems for our clients ...

Good, it's very important for people to understand how their work drives revenue for the company.

... and general system architecture.

Let them spend the rest of the day reviewing the architecture and source for one of our products.

Reading code or documents with no specific goal is a waste of time. Instead of attempting to eat the elephant, they should check out the code, build it, and run unit tests, with the help of another developer if necessary. If much help is required, you should clean up your build process.

The next day, give them some specific project on which to work along with introducing them to the stakeholders and other team members on the same product.

Good. Ideally they would be paired with another developer on that product.

Answer 3

One of the key element every new employee should have is be familiar with your product, not just the source code and architecture, but also from the user point of view.

My first day on my current job was mostly using the product I was going to work on, like any of our users. In former Jobs, I sometimes worked with developpers asking "Our product can do THAT ?!". This helps understanding the code better and provides feedback from a "newbie user", which can sometimes help find bugs that you don't see when you test while already knowing the product.

Answer 4

I don't think there is a hard rule to this. Obviously the machine should be set up for the job with all the software installed, passwords set up, and most of all. Email.

Give the guy a point of contact with all parts of the business that will concern him. HR, Lead Developer etc.

You could always add a wiki to your network. Ask the new guys to fill in the wiki with the bits that other newbies would require when starting the job. This makes the task self documenting.

You must allow for around 3-6 months for the new guy to bed in (take root) and the new guy must be fed and watered at regular intervals (never just leave him sitting in the corner, looking like a spare part).

Don't give the poor chap handbooks, they are crap and just get filled in a draw.

Allow for time, give the chap some basic self contained tasks at the start that are not required to be integrated into the main project, or can be easily attached to the main project(s) through component design.

Allow the new guy to freely look over the code base for at least 2 weeks, to get acquainted. Just make sure that he is a new guy and not a competitor. :)

Answer 5

Is this process insufficient?

Yes - Let me explain why.

Get the new hire setup on their machine...

A good first step.

Spend an hour or so going over what the company does...

Yep. Probably a good idea.

Introduce them to other developers.

Another good idea. To avoid any "first-day" awkwardness, try to do this as early as possible.

Let them spend the rest of the day reviewing the architecture and source for one of our products. That means pulling down the code, compiling and running it and/or looking at database diagrams.

Hmm... Time could be better spent elsewhere. See below.

The next day, give them some specific project on which to work along with introducing them to the stakeholders and other team members on the same product.

OK. This is the most crucial step. Here's why:

• Good programmers love to solve problems; but in order to solve a company's software problem, a programmer must understand the requirements and some back story before he/she can get started.
• Even if you're not a pair programming shop, and even if the new hire is a senior developer, I highly recommend pairing the new hire with another developer for at least half a day. Why? Because that developer will have more smallish questions than you could've possibly anticipated and imagined.
  • This new hire, if he/she is any good, should have two qualities (among many others): Self-sufficiency and curiosity.
  • There will be plenty of time for the new hire to demonstrate his/her self-sufficiency.
  • But for now, you should feed his/her curiosity about your business, your culture, and your process.
  • Many of the new hire's questions will likely be of the "low-hanging fruit" variety, and by themselves won't take very long to answer.
  • So my advice is: Don't put the new hire on an island too early, pair them with another developer at the beginning, and start them off on the right foot.

Answer 6

Sounds like you've got a good first day agenda, but you probably want to find a way to answer some longer term needs. How you answer them is heavily dependent on your company culture. But here's the points to consider.

1. Revision of the setup process - particularly the technical part - I've noticed most development shops have tools and configurations that change pretty rapidly. I have yet to find a situation where the process was so stable and automated that the guy was instantly up and running. Given that no one loves maintaining a process like this - I recommend some mechanism where the new guy updates the process (scripts, manual procedures, or both) for the next new guy.
2. Culture stuff - every group and organization has some unspoken culture stuff. This typically takes 3-12 months to fully absorb - mileage varies by both new hire and group. There's no perfect mechanism here, but having some mechanisms that are fairly mutable per person is good - like mentors, informal contact with management, and introductions to any electronic communication mechanisms and etiquette is a good plan.
3. Feedback - no ever is perfect on the first try - on the first few projects a known and understood feedback mechanism is important - pair programming, code reviews, supervisory reviews, or external testing are all great technical mechanisms. But also feedback as needed on communication and personal style. Even "you're doing a great job! keep it up!" is important to make sure that you say.
4. Problem domain ramp up - the big difference between the new guy who knows your technology and the been-here-forever guy who knows your technology is the problem domain expertise - having some plan for how people ramp up on this is critical. It may be done in terms of how you assign projects, or how long you wait before exposing the new guy to the customer - but have some background plan for how he gets smarter about your business risks before he has to take on the big risks.

Some of this may be part of your general processes - after all, a code review is good for long-time people too - it's just a good quality control mechanism. So you may or may not have more code reviews for new people - as long as it's a conscious decision, you're off to a good start.

You may also consider reviewing the onboarding process with new people after they are successfully "onboarded" - what worked, what was a waste of time?

Answer 7

Depending how complex your company setup is, it might be more beneficial to spread these activities over a number of days. Onboarding will include more than just the development environment for the software engineer. Even if your company deliver software products, there will be other items such as:

• company administrative process (eg. emergency procedures for when a fire breaks out)
• introduction to other departments in the department (eg. design, or hardware, or IT)
• the other projects being run in the company

Answer 8

Another thing that is missing (and maybe you already do this for everyone so didn't mention it) is code review. I have seen new developers get in horrible fixes because no one looks at their code for months. I have seen new developers put on projects with key deliverables who weren't checked frequently and who quit immediately before the deadline with no notice because they knew they had not produced anything (the reason why we now have code review of all code!). Even if code review is not a standard practice in your shop, you need to review it with new people. You can save them from some major mistakes just because of incomplete product knowledge. You can make sure they are actually writing code.

Of course the reviewers probably thought you had no onboarding at all because you don't document it. A simple sign-off sheet where they check what has been done and sign and date is enough.

Answer 9

If there's a existing training curriculum for the software product/system, have the new hire do that first. There usually isn't, or it's too limited.

A new software developer should then follow step-by-step a regression test plan. There should ALWAYS be a regression test plan.

After performing the regression test plan, reviewing/fixing/adding unit and/or integration test cases within source code is encouraged. This will allow the developer get to know the "API" of the legacy system. I put API in quotes, because there may not be a formal API, but every software product/system has its own set of interfaces.

Then the developer should begin fixing existing bugs.

Finally the developer can start developing new features and/or refactoring.