> It's called "paying your dues" and exists in all industries. You need to earn respect of your new colleagues by doing some of that shitty work and doing it well. If all goes well, in a couple of months you'll be a part of the in-group and will get the interesting tasks.

"Pay one's dues" "Earn respect" "Part of the in-group"

I am sorry but this is not my experience at all. What you've described is how gangs work, not companies.

I am hired to work on certain areas due to my skills and knowledge. Shitty tasks are everyone's (in the team) responsibility. I am not hired to "pay my dues" and "earn respect" to become "part of the in-group". I'd leave that initiation ritual to other, uh, industries.

Following on to this, earning the trust of your colleagues takes time and effort. “Paying your dues” doesn’t capture the nuance in my opinion.

Perhaps you're right, English is not my native language.

I couldn’t tell, your English is very good. I hope my comment didn’t come across in any way as a sleight, my apologies if so.

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.

> 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.