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.
"You can fly 400 hours, or you can fly the same hour 400 times."
Sounds like your coworker has had the same first year of experience 30 times...
The other 2 senior people never came up with the idea of introducing it.
One of them is still putting Tickets in Review which still lack basic quality expectations.
My biggest / most used quality right now is persistence and pointing out the same misstakes/issues over weeks and month...
And don't get me wrong, there are only two options to this: 1. Get your collegues up to speed and be persistent 2. Search for a new Team
The obvious choice of not caring doesn't work for me.
But when people around you enable and tolerate poor code instead of correcting it gently but firmly, you don't know what to correct.
Refusing to use version control is a prime example. The industry as a whole has unanimously decided that version control is necessary, but he still argues that his backup of an entire directory that he does once every 2 months is more efficient
For what's it's worth, a lot of people who use version control treat it as a backup system instead of as a record of logical changes to the code base with a detailed description of what has changed and why.
Just refuse to accept the code unless it's a PR; leave him no choice.
They're the one setting the standards for the team. Your colleague is just working to rule and the rules are lax.
The day I interviewed, he said "I know I'm not the best programmer but I believe that after enough hours on the project you will end up with something that works", and he bragged about many nights sleeping in the office on a cot he had under his desk, keeping systems running and debugging live programs.
It was some of the ugliest code I had ever seen in my life. Every couple years, they'd hire an actual programmer, but he refused to change his methods, and the programmers would eventually find another job out of frustration. It was very easy to see which code was done by the other programmers, it just made so much more sense than his code, it was documented, etc etc.
I definitely agree that his approach to code quality is bad and he should improve.
On the other hand, he still seems to be delivering value to the business by making things work, regardless of how awful the code is, and I feel like this is still an improvement over the other extreme which is chasing hype and buzzwords while delivering near-zero actual business value.
I don't think he understands the purpose of architecture is to make future development easier, and instead thinks that if you make all variables global to be changed anywhere at any time, then that makes it easier and faster
His code has absolutely no sense of quality, doesn't employ any sort of standard design patterns or style, has no semblance of architecture and is an absolute hacky rats nest of code that falls apart with any change because of how interdependent it is.
The other day I was sent some of his updated code, which had no version control and had randomly added an extra 150 files to the project. It turns out the majority of those files where duplicated from elsewhere in the project and apparently it was my job to find where the changes were among that mess.
It's like he learnt to program decades ago and then never opened a book or looked at anyone else's code since.