Onboarding complexity reality check.
So I have worked in codebases where there’s one repo per microservice or maybe at most 7-8 services in 1 repo with good CI/CD that’s isolated. Those repos we just develop independently of one another. I’ve seen this throughout my career of 4 YOE. Is it a fair statement to say that “I don’t know what real onboarding is”?
I usually have gotten away with knowing
- the structure of spring boot microservice,
- maven gradle dependency downloading,
- how kafka consumer works in spring
- how rest api typically gets exposed in spring
- high level knowledge of spring bean creation
- how db interactions have been done.
- reading the arch diagram and learning where the infra is to connect dots.
This has made me able to ramp up fast and get productive within 2 weeks and follow discussions.
I don’t know if I just have “had it easy my whole career and I need to step my game up”
Discussion
(4 comments)- 1
3 months agoTech Lead @ Robinhood, Meta, Course HeroThere's no such thing as "real" onboarding. Onboarding will vary based on the makeup of the team, the complexity of the codebase, the quality of your manager, and so much more.
In fact, "easy" onboarding is the sign of a good team: It means they engineered the status quo in a way that's simple to understand and provide newbies lots of support. My onboarding at Instagram was incredibly easy as the Instagram Android codebase is pretty vanilla and I could understand it on Day 1.
It seems like you have a solid understanding of the Java/Spring Boot back-end stack, and you should be proud of that. Keep sharpening your technical skills while also focusing more on fundamental skills. The fundamentals like relationship building and communication are far more important than the technical ramp-up during onboarding.
- 03 months agoMid-Level Software Engineer [OP]Taro Community
Αhh the question was more like “isn’t it better to work in a more interdependent codebase” so you have way more chance to learn how to be collaborative and gear you up to learn to operate in a imperfect environment and if you’re having to learn a new flavor of a same stack isn’t that inherently something you’re missing out if you work on a stack that has robust open source documentation?
- 03 months agoTech Lead @ Robinhood, Meta, Course Hero
As always, there's trade-offs. Having a codebase with more interdependencies is better for overall learning as that additional complexity forces you to do so. Senior/staff engineers are usually expected to thrive in those codebases, especially at big companies.
The thing is that with those codebases, a lot of the learning is non-technical as it's more about building relationships with stakeholders/tech leads on those other services/components.
Having a focused codebase on just 1 stack is better for depth and specialization, which is also valuable, especially for junior/mid-level engineers. If you work on just 1 stack and you hold the performance bar really high (e.g. at Instagram Android, we held a crazy high code quality bar as the most common Instagram Android user is in India using a low-RAM device), your technical skills will grow tremendously. That's another path to get to Staff (specialist).
- 13 months agoMid-Level Software Engineer [OP]Taro Community
I see. So looks like by not working on those clunky codebases in my career I didn’t develop that relationship building muscle as much but I’d imagine it can work in microservices type environments where upstream or downstream services act as your dependencies and you can still deliver business value by partnering with those teams for projects if necessary and practice those skills I guess
