Infrastructure tasks vs feature tasks during onboarding?
I'm really excited about my new role as a mid-level backend engineer and have been soaking up everything on Taro about onboarding – it's been super helpful! My aim is to ramp up quickly by delivering small wins regularly and asking enough questions to move beyond the newbie phase. I've got a great onboarding buddy and plenty of support, but no one's handing out tasks. Instead, I get to pick from the todo-list. So, I'm wondering: should I focus on infrastructure tasks or feature tasks?
The infrastructure work is appealing because it's a chance to dive into microservice infrastructure, something I haven't done before (my last job was more traditional on-prem SOA). But I'm also thinking feature tasks might be better for getting a broader understanding of the system and services. I don't want to be a bottleneck for the team, and infrastructure improvements seem like they could be done in parallel without impacting critical deadlines, but it's also an easy way to get nerd-sniped I'd imagine.
Any input is appreciated!
![Senior Software Engineer [E5] at Meta company logo](/_next/image/?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ftech-career-growth.appspot.com%2Fo%2Fcompany_logos%252Fmeta.jpeg%3Falt%3Dmedia%26token%3Da7a5bcc0-e178-4b5b-b71e-09bf6c6aefae&w=48&q=75){kind=small}
![Entry-Level Software Engineer [L3] at Google company logo](/_next/image/?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ftech-career-growth.appspot.com%2Fo%2Fcompany_logos%252Fgoogle.jpeg%3Falt%3Dmedia%26token%3D780356ef-3efc-4728-9eb4-d909b75bb4a6&w=48&q=75){kind=small}
Discussion
(2 comments)- 410 months agoTech Lead @ Robinhood, Meta, Course Hero
I would work on the feature tasks. Here's why:
- The impact and testability are clearer
- Feature work is generally less complex than infrastructure work (when you're onboarding, you want to knock out easy wins consistently)
- Feature works tends to involve more parties (front-end engineers, designers, PMs), so it helps you build relationships
There are exceptions of course alongside other factors to consider like how much you enjoy infra vs. feature/product work.
1 thing I will call out though is that bugs are excellent for teaching a codebase. They push you to understand how components should (and shouldn't) fit together and will exercise your deductive reasoning and critical thinking while feature work is often times copy-pasting what another engineer did for a similar module and tweaking 10% of it.
Here's a good thread about product vs. infra if you're curious: "Is it safe to join cost centre teams like infra or platform?"
- 310 months agoEng @ Taro
Your goal should be to get something shipped as soon as possible to build momentum early on and set a first impression of getting things done.
I would pick the easiest task, regardless of whether it's on the infrastructure or feature side, to solve first. A lot of times, these tasks will introduce you to how code review is done, how to build the application locally, how the build system works, how tests are written, and how the code is deployed.
A word of caution, sometimes the easiest tasks can actually be more difficult than you think, especially if it's a task that has been in the backlog for a long time. I would come up with a list of three tasks, brainstorm how you would solve them (without coding them), and then meet up with your onboarding buddy to validate whether your solutions seem sound.
