Taro Logo

How can I best spend my time ramping up?

Profile picture
Mid-Level Software Engineer [SW2] at Intuita year ago

I'm in the onboarding phase. I was assigned a starter task and have been working on it. I haven’t done the work of asking questions on design choices (that part is pending).

I want to be ramped up after a week and am wondering how to spend the time. Should I go in-depth on overall architecture? Or spend time working on the codebase? Or is there something else I should do?



(1 comment)
  • Profile picture
    Robinhood, Meta, Course Hero, PayPal
    a year ago
    • Focus on crushing your starter task and picking up as many small wins as you can.
    • I wouldn't view asking questions on design choices as a substantial supplemental task: I think it should be a behavior that's naturally weaved in as you're processing code. If you have questions on why things are written in a certain way, ask your team immediately!
    • Ramp-up isn't a binary process: It's a big spectrum. Of course, as a mid-level engineer, you need to get good productivity quickly and do the bulk of your ramping up within the first 1-2 months. But I think reaching true 100% productivity can take 3-6 months. Just something to keep in mind - Don't be too hard on yourself if you're still missing things 3 months in!
    • I don't expect mid-level engineers to have a huge impact on technical direction, especially newer ones on a team. I would focus on building a very strong proficiency with the codebase. Landing new high-quality code into your team's codebase quickly should feel like breathing to you within the next month or so.

    Zooming out, I recommend talking more with your manager and TL to figure out what the longer-term horizons are for you. From there, you can work backwards on what's best for you to do. For example, let's say the plan for your next 3 months is to deliver a big project in a specific part of the codebase. You can start preparing for that now by finding relevant stakeholders in that codebase, going through that code, etc.

    Lastly, I recommend going through this onboarding checklist I shared with a new engineer that started at Google. I think a lot of it can apply to your situation as well.