I don't want to be that guy, and i don't want to work with that guy, but i have to confess to a certain jealousy that people like him have figured out how to sit back and just phone it in and collect pay cheques for thirty years.
It's hard to fire them, because to many outsiders, they're workhorses. They know just enough to scrape by on each task, but they also have institutional knowledge and social connections that make them seem invaluable. Often that institutional knowledge is that they're the only person who understands their own shitty code. Their more-capable peers usually know that they're incompetent, but management doesn't.
There are many reasons people like this can survive. Peers don't want to explicitly throw them under the bus. The best of their peers simply move on--to other projects in the same company, or more often, to greener pastures at another company. Their peers cover for them, because it's easier to work around a millstone like this than it is to get them removed. It takes months of concerted effort to get a peer fired for underperforming. If you want to try to get someone like this fired, it starts to look like you're the asshole with a personal vendetta. Especially because they've been there for a decade and you probably just arrived.
These millstones aren't outright incompetent. On paper they've got extensive experience. Socially they're well-regarded by everyone at the company except their immediate peers who know they suck. They've been faking it and faking it well since long before you arrived, and they'll be doing it long after you've departed.
Make no mistake, though. These people are rarely phoning it in. They are busting ass to tread water. Sometimes they believe their own lies, but more often they are terrified that someone will find out just how bad they are. That's why they work so hard.
Don't underestimate the value of slow and steady in the world of corporate development. Many fresh out of college might seem like super stars developers that know all the latest buzz word technologies, I know this is a massive generalisation, but they don't like to work on "boring" or "legacy" and often quick to jump ship to the next opportunity.
Also, please be aware that this feeling is a common symptom of imposter syndrome.
I've stagnated at jobs in the past. I've thought it was my problem. Then I moved on to better places, where coworkers helped each other to excel, where people placed a premium on improvement and education.
If your company shoves everyone into a cubicle and assigns them individual tasks, how are you ever going to learn? If you can get a job somewhere that embraces pair programming, you might find a whole different world. You can be mentored by your coworkers and collectively solve problems, instead of feeling like you need to put your head down and produce something on your own that may be beyond your expertise.
Fresh grads, especially grads out of code schools, often arrive with a lot of buzzwords ready to go, and a script of practices they've been told are the right way, but that's all flash and no substance. It can lead to overconfidence. There's something to be said for it, though; you can fake it until you make it. The important part is that you actually make it in the end, and to do that, you need mentoring. It sounds like you're not getting the mentoring.
I know it's hard to quit a well-paid job and take a chance, but I think that's better than going to work every day hoping you won't get fired, and not growing as an individual.
Whether such a Domain Owner is aware of his standing - that's a philosophical question. Job security on the one hand, inertia on the other, compounded with the very much environment that gives such role more support.
Just wish these guys are willing to share the crusts of the tribal knowledge with you, as this is where their true expertise may be. Side note: if there's this perceived disparity in the technical skill, the seniority in such org may trump the merit. There could be a way to get such Domain Owners on your side; pointing out their lack of skill is not the one, in fact this can backfire literally.
I could never be that person, I always strive to improve and become better.
Whereas you put focus on aspect such as maintainability, readability, adaptability, testability,... of the code he's writing, your employer might simply keep him around either because his code, well, simply "works" to a degree that is satisfactory, or because of a complex interpersonal relationships which have been established over decades turning him into much into a fixture.
Put more succinctly: No one wants to know what goes into making a sausage.
That is, there's little value in explaining or arguing the fine technical details of code optimization, architectural design, functional programming, etc. etc. etc. if you don't consider your audience.
Stakeholders who rely on your co-worker's work simply want to know what his work could mean to them, and how it helps them get the job done. Your concerns regarding code quality are totally valid, but unless you, as the maintainer, will be fully perceived by your employer as a formal stakeholder in your own right, your objections risk being thrown in the wind.
At that point, it's not just a co-worker issue, it becomes a workplace culture issue. If there's a dissonance in the manner in which he's held accountable for the quality of his work by the team on the one hand, and management on the other hand, then how does that same dissonance affect how your own work gets perceived?
If he gets to scrape through, does that then imply that you're putting the bar for yourself really high, whereas you could clearly get away with doing less? Or are you trucking on despite the fact that your work is held to a different standard because there's a different expectation towards your own performance?
I think striving to "improve" or "become better" is something that only means anything if you do it for yourself first and foremost. Because that's what you want for yourself. It's a valid pursuit to want that for yourself. Whereas you have to be mindful that few people selflessly care about that desire and go out of their way to let you self-actualize that. After all, your job is first and foremost a business deal between you and your employer, and the primary reason why you are there is because your employer feels there's value in what you bring to the table.
If you work in a group, it's equally important to understand how to compromise on where you set the bar for yourself and others. Of course, in your case, you don't want to compromise on what you want for yourself to the point where you start to cross personal boundaries, lest you want to end up resenting the entire situation.