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? 🤷
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.
Great text! It's short yet packed with powerful information. Now, I understand better what the title "Staff" means. Thanks for taking the time to share this with us!
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!
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!
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? 🤷
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! 👏💻
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.
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!
Great text! It's short yet packed with powerful information. Now, I understand better what the title "Staff" means. Thanks for taking the time to share this with us!
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
Thank you so much for the post,Ryan, this is golden! I'll put it into action in a few months 😊
This is great, I will definitely follow it in my next job, just in 2 months. Thanks!
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 😂😂