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

The DevDiscuss Podcast begins with an interview and ends with commentary from listeners — and we like to feature the actual voices from our community!

This week's prompt: "What are some good practices when onboarding junior devs — or devs in general? "

For your chance to appear on an upcoming episode, answer the question above by:

• Calling our Google Voice at [phone] and leave a message 📞

• Sending a voice memo to [e-mail] 🎙

• OR, leaving a comment here (we'll read your response aloud for you) 🗣

Please send in your recordings by September 2nd at 5 PM PT (8 PM ET, 12 AM UTC)

---

Don't forget to check out the latest episode, released on Wednesday!

Comments

[Nathan Kallman]

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.

[Gracie Gregory (she/her)]

Hi Nathan — this is great! Would you consider sending us a voice recording of this comment and/or other thoughts and suggestions on onboarding devs? Instructions to submit a recording are above.

We love to feature actual voices from the community on DevDiscuss 🌟

[Vitor Paladini]

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

[michelemauro]

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.

[Mike Bybee]

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).

[Helen Anderson]

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

[Gracie Gregory (she/her)]

Hi Helen! We'd love to feature your voice on this episode of DevDiscuss! Would you consider sending us a voice recording summing up your thoughts on onboarding new devs? Instructions to do that are above 🙂

[Helen Anderson]

Done! Hope it fits the brief :)

[Brett Stevenson]

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.

[Jonathan Yeong]

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.

[Frederik 👨‍💻➡️🌐 Creemers]

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.

[Gracie Gregory (she/her)]

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

[Chris Bongers]

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.