1

Effective onboarding

Profile picture
Anonymous User at Taro Community4 months ago

I am looking forward to grow as senior engineer soon. I realised one of the improve my areas as I become senior is to be more independent and onboard to new projects effectively.

As someone who likes to understand things deeply, I am taking more time to get started and contribute to new projects when introduced to new frameworks/languages/tools. How should I become more effective?

50
2

Discussion

(2 comments)
  • 1
    Profile picture
    Tech Lead/Manager at Meta, Pinterest, Kosei
    4 months ago

    A very common failure mode among engineers is to spend too much time trying to understand a language, library, or codebase before becoming effective. A few thoughts:

    • Realize that learning something new should feel uncomfortable. Embrace the fact that you can and should be making code changes with an incomplete understanding of the code.
    • What's the easiest thing you can do to commit some code? Try to make a bunch of trivial changes that give you confidence for larger changes.
    • There's probably only a small surface area that matters (where the "real" logic lives, or whatever is being changed). Your job is to figure this out, as I talk about in the onboarding course: Figuring Out What Matters In A Codebase

    See this related discussion, How to learn a new programming language when you join a new company?

  • 0
    Profile picture
    Eng @ Taro
    4 months ago

    I agree with Rahul about making code changes as soon as possible. You'll be able to learn a lot from anyone on the team. The intern will be able to give you some pointers because they're more familiar with the code than you. Take that advice as early as possible.

    As far as other tips, I would just go crazy in your local development environment to test any assumptions you have about the codebase. When they don't align with what you had in mind, keep track of them so you can ask your teammates about them when you get into the office.

    There have been many times where I have experienced company-specific domain knowledge that I wouldn't have been able to figure out just by going through documentation. Either because internal documentation is out of date or there's one gatekeeper of the knowledge that hasn't written down the information yet.