Hacker News Reader

Comment by hehsjsbb | Hacker News Reader

I said this in another thread but I've been in the industry for 10 years. I don't expect to come in and rearchitect things on day 1, but I expect the tasks to be meaningful. The stuff I'm working on isn't an on-ramp to bigger tasks or being better integrated with the rest of the team, it's a silo that nobody wants to touch.

If your perspective is that onboarding is basically hazing people have to do to fit in at your company, I think that's pretty messed up. The best places I worked at tried to get people to ship meaningful features that would have an impact quickly.

View on HN

> it's a silo that nobody wants to touch.

There are multiple silos of this where I work, not necessarily because nobody wants to touch it, but because we just don't have enough people.

I've picked one of them up and my teammate now come to me for advice when they deal with this silo of stuff.

Don't underestimate the small things, unless they're things that does not need to be done, in which case you need to raise this at planning and explain how they are not necessary to waste effort on, and bury them forever.

I've been kind of deliberately vague, but after a couple months it isn't like I'm an expert on the area of the codebase now and other people come to me for advice. Other team members actively dodge working on this silo and everything just gets deflected to me. It doesn't feel like being a respected person who has experience with an area of the codebase, it just feels like shit rolling downhill.

Not neccessarily hazing, but it's only natural that you won't be able to, on day 1, co-design the big refactor or switching from platform A to B or a big feature which touches existing code in very many places. Instead, you'll be given smallerand well defined tasks (which often means that they're boring) that will allow you to familiarize yourself with the codebase, the process, the team members etc.

So, who in your opinion should work on the stuff "nobody wants to touch"? It's clearly a job that has to be done.

Ideally it would round-robin across the team or have a dedicated team with more than one person. Having only one person know a particular part of the codebase is bad for bus factor and reduces the ability of the team to review code.

Reply on news.ycombinator.com