A guide to a great developer onboarding for a faster, peaceful start – The start of a new job or project can be a source of excitent, or fear (or both, or something in-between). There’s a lot to learn, technically and business wise. You don’t want to feel like a burden to your (new) colleagues by drowning them in questions, but you also want to start fast.
The onboarding of new members on a project can be made easier. So yeah, this article is particularly meant for those who onboard new engineers (project managers, tech/dev leads, senior/medior developers…), but if you are yourself a developer struggling with starting on a new project, I encourage you to share it with your team, propose some solutions and make sure they’re implemented 🌈 and make the onboarding better for your future colleagues 🌈.
“Don’t panic” *
What should we teach the newcomers during their onboarding?
Anything that you get asked or must repeat every time there’s a new hire. Here’s a list to begin with but feel free to add your ideas in the comments below!
Workflows
- how do we organize our day,
- how do we do code reviews,
- how do we handle the follow-up of our tasks/tickets,
- how do we work with the business,
- where does our responsibility start and end,
- when and how do we release,
- what’s our CI/CD pipeline…
This seems obvious but I often had to figure out a lot by myself, and often ended up learning how to do it right when I got it wrong. This information is highly repeatable and will barely change over time, so it’s really worth maintaining it in the team documentation, and explaining it to newcomers (documentation doesn’t replace mentoring, onboarding and training).
Social contract and values
Business
- what’s our business,
- what’s the goal of the project,
- who’s our client,
- who’s our end-user,
- how do we gather the needs of the business,
- how do we communicate with the business (directly, via a Product Owner or Business Analyst…)
- explain the specifics of the business and the features.
Tech
- what’s our technical stack,
- what are the other systems that communicate with our(s),
- what are our preferred (or mandatory) tools in the team,
- why those tools/techs, links to the official documentation.
Environment setup
How to set up an environment for local development. The most painful of all topics.
Team and project management
- do we do scrum,
- what Agile tools are we using,
- do we work on several projects,
- how do we assign our resources,
- what are our regular meetings,
- who are the owners.
The “tools” to onboard new colleagues: how to make their life easier
What makes a good process? A good process is tested and documented, already available, leaves no room to assumptions, answers potential questions and gives directions in case of blocking points. It is also updated as soon as needed.
Reusable content
In a field where it’s still pretty difficult to hire and the turnover is higher than in most sectors, any training material or documentation that can be reused, should be reused. Giving a training or an explanation to a newcomer, or even to current members of the team? Record it (especially if it’s a video meeting, which makes it super easy)! You write some explanation on a topic? Save it for later reuse, or better, publish it as in the team documentation tool.
An up-to-date wiki
With great tools like Confluence or Teams wikis, it’s really easy to create a central point of documentation. It should be a must in any team. That’s honestly become one of my questions to the company when I get a job interview. If there’s no wiki or it doesn’t seem to be taken seriously, big red flag for me.
Documentation is all about empowering team members and sharing knowledge, and it should be a team effort everyone contributes to.
An easy-to-read code
KISS and YAGNI. Don’t overcomplicate your code. Write it in a way that can be read by most people, not only geeks and senior developers, choose good names, make it concrete…
As someone once said, code is like a joke, if you have to explain it, it’s not that good. Sometimes, adding one or two lines of code, a variable assignment, or using a less exotic way of writing your code can save you some time when you don’t have to explain it later.
And for obscure part of the codes, document what it does with comments.
README
Have a readme file with all projects on how to install and start them, a bit of explanation of the purpose of the project, the connections to other ones…
All this doesn’t erase the need for mentoring and follow-up!
Adopting those tools doesn’t mean they should be given to a newcomer without any other explanation or that it’s sufficient for the whole duration of the project. Receiving explanations from someone or reading documentation/watching a video is really different, and the chosen method should be decided upon several criteria, like the kind of stuff the person has to learn, their experience, their way of working…
But those tools can help lighten the workload of the engineers who usually give the explanations, and should be considered as a starting point for basic tasks or project overview, or as a memo (there’s so much to learn at a project start, that it’s difficult to remember everything the first time).
Credits: Illustration image based on a picture from Pixabay
*Quote from Douglas Adams’ “The Hitchhiker’s Guide to the Galaxy“
