Any tips for onboarding developers? Let us know for the chance to be featured on a DEV podcast!

Pairing, pairing, and a little more pairing.

It naturally provides opportunities for them to learn:

1. The tools
2. The codebase
3. The domain
4. The workflow(s)
5. The etiquette
6. The people

on the team(s) that the onboardee needs to know.

I've worked in very small and very big companies with different approaches to onboarding, here's a list of what a great one should have IMO:

1. An overview of how the company works, its major areas of operation and how it makes money
2. A detailed intro of the team's mission, expectations, and related teams
3. A quick briefing on how project management works at the team
4. How to navigate the corp bureaucracy if we are talking big company (ticket filing, compliance stuff, etc)
5. Slack/email/general communication etiquette
6. How to set up your local environment and start working
7. Coding standards, test and deploy guidelines
8. Where to look for internal documentation
9. How to collaborate with other teams
10. Who to ask for help when things get funky

Onboarding starts before "getting on board": thinking about new dev onboarding (also known as "thinking about team scalability and resilience") means having:

• general/product goal/architecture documentation well laid out and kept fresh
• clear processes for HR (first), and commit/push/test/CI/collaboration/release (better if automated)
• and a practice of reaching out and speaking about how the organization works and how it pursues its goal of attracting talent and doing good business.

If you have this in place, then onboarding is really easy, and adding hands to the team is no more hassle than picking the right personality and some familiarity with the tools.

Oh, and all that will be beneficial all around, so making onboarding easier is just icing on the cake.

1. Don't be a dick. And being a "nice asshole" (backhanded, passive aggressive, etc.) doesn't count as not being a dick.
2. Don't make assumptions, about what they know or what they don't know.
3. Should be a duh, but usually isn't (relates to point 2): Good documentation AND discussion is a must. You may think your code is self-evident, but they haven't been working on this project for months or years like you have.
4. Not nearly enough people do this: Architect with the junior developer in mind. It doesn't matter what your project accomplishes or aims to accomplish. It should be simple enough for a junior dev to quickly get up to speed to add or make modifications to the project as they learn (relates to point 3, but specifically addressing the code/infra here).

I have a lot of thoughts on this :D

Onboarding: How to give new hires a soft landing

Helen Anderson ・ Feb 10 ・ 5 min read

#leadership #career #hiring #analytics

In my experience, I would argue that the most important onboarding work is done by actively maintaining your project documentation.
There have been too many cases where little inconsistencies or additional steps are added throughout the development process that quickly turn onboarding into a minefield for new hires.

I think the goal of onboarding is to provide context. Any dev coming onto a new project doesn't know the history of the project, the decisions made, or the architecture. A good onboarding will provide info on all of these.

The actual process could vary depending on the level of the developer. A senior developer may be fine with a few diagrams and documentation. But an early in career developer might need some more hands on onboarding e.g. through pairing or knowledge sharing. The onboarding process should accommodate both of these options!

Good onboarding experiences for me have been:

• Onboarding steps documented and up to date.
• Automating things like permissions to projects.
• Culture doc for things like meeting expectations, fun events, or slack channels to join.

Finally, a good onboarding process should have continual check in's. Either through an onboarding buddy or through your team. When I first started as a developer, I didn't ask questions because I was worried about disrupting others. This caused me lots of pain and slowed down my onboarding.

Making a safe space for someone onboarding to ask questions is really important. And we want to give developers the time to soak in all the new information.

I only have experience with very small, early-stage teams, and in terms of technical onboarding I really liked the process I went through.

• The README contained all the information I needed to set up my local environment
• If there was anything missing, I could ask a colleague for help, and add the missing info to the README. This was also my first commit and contribution to be merged, which gave the nice feeling of a quick first win, and improved the README for future onboarding.

Hi Greg! Thanks for these thoughts! Would you consider submitting this as a voice recording also? Instructions are above 🎧 🎧 🎧

For me mainly giving chances, I think with a good conversation instead of a "test" you can tell how someone is, if they are willing to learn.

So give them a chance to prove themselves.

Pairing with other people in the team, updating the onboarding documentation as they go over setting things up and reviewing things with the new developer.