In 2022, the average tenure at Google was about 1.1 years. Even if you don't switch that often, you'll have to ramp up many times in your career. After helping many engineers onboard successfully there's two things I'd keep in mind: 1. "A Career Cold Start Algorithm" - Andrew Bosworth, Meta's CTO, shared a great algorithm for onboarding effectively: https://lnkd.in/ga8-FFGM 2. Land Code Fast - This will help tie your high-level understanding to the codebase. Also, it's the fastest to start having an impact If you plan to start a new role soon, I suggest some tweaks to the cold start algorithm for software engineers and share more here: https://lnkd.in/gq6mTNsT
I remember Google's average tenure was ~2 years some time ago. Now it's coming close to Amazon's 1 year. That's sad to see this. That means culture/work-life balance is bad and among the few reasons for going there is just for a nice resume.
This meme hits hard 😂
Alexey Kuznetsov
7mo
I don't believe average was/is 1.1 year neither in Google nor in Amazon. It is in fact uncommon to see people leave that early, it's basically you do your first mid-sized project and leave before you get a reward. Even if it didn't go that well, mentioned companies don't get rid of you based on one project. It would also mean that hiring process on average fails, but I know for sure, it doesn't. We had amazing teams when I worked for both companies
Infrastructure is being changed so often and by so many people that you reach the point where maintaining documentation becomes very difficult and costly job. That said it all depends on the company. I have observed in Meta we optimise for apeed and agility so in most cases/teams bdocumentation is the code itself, that's your best source of truth. Everyone can go and update other people/teams code allowing easier alignment and driving product changes. I have spoken to friends at Google and I can definitely see higher focus on stability, strict ownership of codebase, but that inevitably leads to slower pace of development and more upfront alignmenet when you need to change another team's code or interface. Documentation is great, stability one idea better and overall slower to ship and adapt code/services and aligb with teams. At tge end of the day it's about tradeoffs. One can do a hybrid approach where less critical systems can cope with less stability and critical ones require more upfront alignment for new changes and controlled intake process, respectively solid and stable documentation.
Alexander Zammit
7mo
I am sorry for the company that thinks that it's ok for the Team Lead to be the documentation. And I am saying this because this is so real and is such a red flag of badly managed projects.
I think documentation has always been seen as a heavy and tedious process. That is why we should focus on integrating it into the development and creation process, so that it is done clearly but in natural language. The pompous templates, with difficult words do not make the documentation better, although they do make it longer, tedious, therefore of greater resistance for the teams.
Kelvin Meeks
7mo
❤️ The article, "A Career Cold Start Algorithm" - is excellent advice. Succinct, simple, and clear.
Bob Ulrich
7mo
What if instead of mandating time for compliance training every quarter, it was mandated you spend at least as much time creating high quality documentation? Better yet; what if it was rewarded? 🫢
Staff Site Reliability Engineer at BECU
7moTwo favorites I've heard over the years. me: "where's the server documentation?" answer: "it's saved on the servers" me: "where's the documentation for what this does?" answer: "the documentation is in the code"