Thanks for the great share! As a junior, I've got to say that while landing code fast is rather effective as you go to higher levels, working on small tasks first with well-defined contexts would be a better start to learn more about how the parts of the codebase interact together. I realised even after changing company after a year of graduating, while landing code is great, improving documentations and simplifying processes would be even better to onboard which is what helped me. Most important key ingredient at least to me, is to have an onboarding buddy! That simplifies a lot of things!
Excellent tips, and makes me think about my team's onboarding (or lack thereof) process. We have some docs in a Sharepoint, I prefer the idea of a single Wiki the team can use and update. I might look at how Team's channel wikis could serve this purpose 🤔
... still learning substack. What does "Also share a note" do? 🤷
"Share a note" also publishes your comment as a "Note" which is Substack's Twitter-like product. There's a feed where people can see algorithmically recommended notes
I have changed jobs and it helps to start with low risk code changes. You are spot on with that. Low risk doesn't mean low impact, we just got to pick the right one. Another I may add is that, look into the tests that peeks your interest, also a good way to familiarize and not to forget get curious and have the right questions. Always a good read, thanks !
Congratulations on hitting 47,000 readers, Ryan! 🎉 Your insights on effective onboarding for software engineers are invaluable. The "Career Cold Start Algorithm" you shared, inspired by Meta's CTO Andrew Bosworth, is a gem. The emphasis on building foundational knowledge and relationships through directed searches and targeted questions adds a practical touch. Your advice on contributing code fast, with real-life examples, underscores the importance of hands-on experience. Your newsletter consistently delivers actionable guidance for career growth in the software engineering field. Looking forward to more insightful content! 👏💻
As someone who will join a new team soon in a senior position, this is a great list to have!
Something I always did when joining new projects as a Junior was adding tests to untested parts of the codebase. By this I made sure I did some meaningful work, I have the app up & running, and I'm getting familiar with the codebase without risking a breaking change to production.
Yea having an "onboarding buddy" can save you a lot of time. Most company's codebases are so large that just reading code without direction will take too long
That quote is golden, great approach! I wonder how that algorithm works in reality in big companies, if there are engineers who will get to 1000 names and spend 2 years talking to people 😂😂
Spot on as always!
Almost verbatim the only comment I can even make on Ryan’s stuff haha. Ryan ftw 🙌
Thank you Josh, appreciate the kind words :)
is the total count of readers/subscribers a variable ? Updating with the incrmements of thousands? :P
Well it would be cool though to make the subs count in the onboarding doc a variable, wouldn't it be?
That would be nice, but I don't think Substack has that functionality. The subscriber count you see in the blog posts is static text I added manually
I appreciate how you're streamlining the onboarding process to be as efficient as possible.
In my current role, I was able to grasp team dynamics and tools within two weeks, and even contribute to code in the second week.
Onboarding isn't about mastering everything, but rather about understanding enough to start contributing to code and design promptly.
This can be achieved through code reviews and well-documented tools and processes.
Thanks for sharing your experience, Ryan!
Thanks for the great share! As a junior, I've got to say that while landing code fast is rather effective as you go to higher levels, working on small tasks first with well-defined contexts would be a better start to learn more about how the parts of the codebase interact together. I realised even after changing company after a year of graduating, while landing code is great, improving documentations and simplifying processes would be even better to onboard which is what helped me. Most important key ingredient at least to me, is to have an onboarding buddy! That simplifies a lot of things!
Glad you liked it Melody
> Most important key ingredient at least to me, is to have an onboarding buddy
Agreed, nothing beats a good onboarding buddy!
Right when I’m onboarding our newest senior onto the team! Perfect timing haha!
I like the "contribute code fast" point. Really important. Because otherwise, you're holding back your growth.
Thanks for sharing this, Ryan!
Excellent tips, and makes me think about my team's onboarding (or lack thereof) process. We have some docs in a Sharepoint, I prefer the idea of a single Wiki the team can use and update. I might look at how Team's channel wikis could serve this purpose 🤔
... still learning substack. What does "Also share a note" do? 🤷
"Share a note" also publishes your comment as a "Note" which is Substack's Twitter-like product. There's a feed where people can see algorithmically recommended notes
I have changed jobs and it helps to start with low risk code changes. You are spot on with that. Low risk doesn't mean low impact, we just got to pick the right one. Another I may add is that, look into the tests that peeks your interest, also a good way to familiarize and not to forget get curious and have the right questions. Always a good read, thanks !
Great idea Anjana, improving tests can be a good way to learn intended behavior while not risking taking down prod
Congratulations on hitting 47,000 readers, Ryan! 🎉 Your insights on effective onboarding for software engineers are invaluable. The "Career Cold Start Algorithm" you shared, inspired by Meta's CTO Andrew Bosworth, is a gem. The emphasis on building foundational knowledge and relationships through directed searches and targeted questions adds a practical touch. Your advice on contributing code fast, with real-life examples, underscores the importance of hands-on experience. Your newsletter consistently delivers actionable guidance for career growth in the software engineering field. Looking forward to more insightful content! 👏💻
Thanks, Ryan!
As someone who will join a new team soon in a senior position, this is a great list to have!
Something I always did when joining new projects as a Junior was adding tests to untested parts of the codebase. By this I made sure I did some meaningful work, I have the app up & running, and I'm getting familiar with the codebase without risking a breaking change to production.
This is a great tip. Unambiguous, low-risk code changes to get familiar with the app
Wow, the cold start tip is golden. 🏆
What a way to go deep quickly and pick up a lot of context that SMEs have that might only be in their brain.
Feels like a shortcut to overcoming the traditional 3-6 month slow onboard.
Combine that with starting coding early and you’ve got a winning strategy.
Definitely bookmarking this and applying it next time I switch positions or jobs. Thanks Ryan!
Glad you liked the cold start tip Caleb!
Very useful Ryan. I have had the pleasure of being in multiple teams/orgs/companies. Have done some version of this every time.
I had a related post. That comes at changing companies /teams from a different angle. Let me know what you think. Cheers!
https://www.softwarebytes.dev/p/tips-for-starting-a-new-job-successfully
Great stuff Peter. I always had this question. I've tried so many things and nothing worked. The worst was just reading the code base.. hah
Yea having an "onboarding buddy" can save you a lot of time. Most company's codebases are so large that just reading code without direction will take too long
Thank you so much for the post,Ryan, this is golden! I'll put it into action in a few months 😊
Happy to Milos, glad you liked it :)
This is great, I will definitely follow it in my next job, just in 2 months. Thanks!
Congrats on the upcoming job Sergio! Hope this post is helpful
That quote is golden, great approach! I wonder how that algorithm works in reality in big companies, if there are engineers who will get to 1000 names and spend 2 years talking to people 😂😂
Haha in practice you'll run out of names once you go through most of your immediate team and potentially some of your sister teams