One of the things you might take for granted if you’ve mostly worked with experienced developers is how good we’ve all had to get at debugging weird laptop issues and working around out-of-date documentation. A Senior Developer will barely notice if the README says “install Ruby 2.76” but the .ruby-version file says “3.1.2”.
Junior developers haven’t had to build those skills yet. Maybe they’ll never have to!
Depending on your setup (Mac, Linux, Windows; Docker, VMs, WSL) your laptop setup might take 5 minutes or 5 days, but hopefully either way it’s well documented in a way that’s junior-friendly. If not, take the time to get it there.
At Charlie every new developer has the same first release: adding themselves to the About Us page on our marketing site.
$ git show f0f51f6
+ - name: "Alex Balhatchet"
+ avatar: "team/Alex.jpg"
+ role: "Software Engineer"
+ bio: "🧙♂️ 🍱 🎧"
+ new file app/assets/images/team/Alex.jpg mode 100644
It doesn’t touch any Ruby code, but it does get them to go through the motions of how we write, test and release code changes.
There are a hundred tiny steps to even a small release like this, and it’s good to start building up those foundations from day one. They test the change locally; they go from config/routes.rb in to understand how the About Us page is rendered and why editing the YAML file has the effect it does. They change the code, refresh the page, and see themselves appear. And finally they go through our code review and Heroku release process. A week or two later they’ll do them all without thinking, but the first time is different.
After adding themselves to the About Us page, we start our new hires out on real bug fixes.
We have a nice long backlog of known but low priority issues on our product, and we tag some of them as “good for a new dev hire”.
These are chosen for being straightforward to reproduce with a clearly defined fix, unlike most of our open bugs which are more like “this seems weird but I don’t know what it should do instead” 😅 Those ones aren’t very good onboarding bugs!
We pick 5-10 of these bugs, pick an order for them, and then specify how to approach them in decreasing specificity. My rule for the first one is:
“Spend an hour specifying a fix that you could do in 10 minutes, so that the new joiner can spend another hour on implementing the fix.”
It sounds absurd, right? Spending 2 hours over two people for something that one of them could’ve done in 10 minutes. But it’s an investment in the future. By the 10th bug fix, 3-4 weeks in, the spec looks more like “here’s a bug report we wrote a year ago, figure it out” and they’re fixing it in only 10-20% more time than the experienced dev would take.