How to Onboard a New Developer
On their first day, ensure that they have access to critical accounts such as github, flowdock, project management platform, etc on day one.
There should be a new team member checklist that lists all systems where the developer should have access on day one.
Assign a on-boarding buddy who provides advice and guidance on different aspects of working on the team.
The buddy should be:
- Willing to serve in this role
- Have available time
- Should not be the new developer’s manager
- Trusted by the team
Clear responsibilities of the on-boarding buddy should be defined prior to the new developer coming on board.
Provide support / resources for the new developer to learn the language, framework or use of technology that is used by the team.
The developer should be encouraged to review the technical materials while working on the first few assignments and refer back to them as needed. There should be a list of resources that a new developer should be given to help them learn and get up to speed with technologies and styles of development used by the team.
Establish a team vocabulary for workflow. Review with the new developer the definition of what constitutes ‘Done’.
As part of new developer orientation on the team, a senior developer or project manager should walk the new developer through the workflow and what their role is at each stage.
In this orientation these items should be explained: What is done with a story mean? What are code review responsibilities and how long is the turn around to conduct one? What are the documentation, code style and testing standards on the team? After you are ‘done’ with an assignment, how do you get another? When should you ask QA about acceptance criteria? When should you tackle a bug/ technical debt that is found in your assignment? Do you create a story around it? Is rogue/ clandestine (with a ticket/ story assignment) bug fixes, cleanup work acceptable?
For a new developer’s first assignments, they should be given small tickets to build knowledge of the code base and system. There should be loose time pressure with emphasis on learning the complex and undocumented parts of the system (and create documentation around it!).
The first assignments given to developer (junior and senior alike) should be small and well defined in order to build confidence and learn about the team workflow and technological stack. These small assignments should target things such as updating documentation, adding/ fixing tests or fixing small bugs. The timeline for submitting these should be relaxed and focused on ramping as a contributing member to the team. As confidence and knowledge of the technology grows so should the assignments.
Avoid assignments that have a tight deadline or are dependencies for other developers on the critical path.
On their first assignments, new developers should be paired with another seasoned developer who knows the technology system, is familiar with the codebase, and seems happy in their role.
For an assignment a new developers should be paired with the last developer to work on the component in the system (who should have the greatest knowledge of it). Preferably that experienced developer is a knowledgeable about most of the technological system.
For setting up a new computer and setting up the local development environment, the new developer should be paired with a recent hire who has fresh knowledge of how to set up the environment. A great first assignment is to update / recreate the documentation relating to setting up the local environment to be used by the next new hire.
The experienced developer should walk the new developer the practical and applied team development workflow.
Have established criteria and metrics for the quality of work that is acceptable.
New developers should be given access to quality and standards documents relating to code. These guidelines should be followed by developers when writing code and reviewing the code of others.
Automated checks of code quality and test coverage can be automated. Submissions of new code can run against these automated checks thus reducing the burden on the developer conducting the code review.
Quickly conduct code reviews on the new Developers first assignments.
Code reviews are an essential part of the software development process. A quality code review catches bugs and defects early in the development process and allows fellow developers to act as first line QA.
The first time contributors to a codebase need to receive feedback on their contributions.
For a development team, code reviews encourage common coding conventions and tends to enforce minimum code quality standards across a team and allows the reviewer to gain an understanding of another part of the code base.
Introduce new developer to the task management system for reporting bugs, defects or technical debt in software. When software bugs are reported, make the burden of proof low and make it clear that fixing bugs is a priority that will be eventually tackled.
New developers should be encouraged to take ownership of the codebase and keep it at a high quality to ensure a product success.
Whenever subpar work is accepted due to time constraints / business requirements, this should be noted and tracked as technical debt in a project management system. An further development on that code will have latent bugs, requirement rework and will slow down the development of subsequent features.