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