After that - sounds like your (and/or his) manager are too weak/ineffective to fix the obvious problem. And more of the same, up the chain.

How long have you been there, and what might other coworkers think? I'd probably be polishing my resume - on the theory that low-functioning orgs can go away fairly quickly. And that what I didn't know about the politics behind that mess could still hurt me.

I have mixed feelings on maintaining other’s code. Changing 412 to 200 sounds trivial, but do you know where else in the code it may be looking for 200 vs 412? Others that may rely on it? These are where bugs are formed.

Someone asked me for a “trivial” change to someone else’s code a couple weeks ago. They told me it would take 15 minutes, tops. I pushed back and refused to commit to doing it on any kind of timeline. After the call I looked at the code. I had made some other minor changes in the past (things I made that needed to be integrated into a bunch of places), but looking at the bulk of it, it was 6 years old and mostly irrelevant. Doing what they asked probably would have taken a few hours, but doing what was needed to achieve the stated goal of the code in 2025, would be more like a week+… a full re-write and some meetings with engineering and operations to better understand what is needed these days. It’s rarely as trivial as people make changes out to be.

They ended up just asking for access to run the existing code, and said they’d work around me so I would have to do nothing more than add a service account for access. Fine. A week later they were asking me for code changes again, to support adding results into a ticketing system that didn’t exist when the code was written. So much for not having to do anything or 15 minutes.

It’s almost never as quick and trivial as people say. What are the competing priorities of the team and individual? Where do these tasks fall? What is the culture like, if he makes that one update is he then the owner of all that code and responsible and accountable for it all? I’ve seen that pretty often, and it makes people not want to sign on to old code from others.

Your coworker's stance is quite extreme and problematic from both technical and business perspectives. While there's a kernel of truth to concerns about code context, their absolute refusal to touch any legacy code is unrealistic and unprofessional. Here's why their position doesn't hold up: The context argument has limits. Yes, understanding original intent helps, but well-written code should be reasonably self-documenting, and professional developers are expected to work with unfamiliar codebases regularly. If code is truly incomprehensible without the original author, that's a code quality problem, not a reason to never touch it. Business impact matters. Refusing customer-requested changes - especially simple ones like status code adjustments - because of authorship is putting personal comfort over business needs. That's not sustainable in any professional environment. It's part of the job. Maintaining and modifying existing code, regardless of who wrote it, is fundamental to software development. Every developer inherits code from others constantly. The real issue might be deeper. Your coworker might be using this as an excuse because they're overwhelmed by the codebase's complexity, lack confidence in making changes safely, or are trying to avoid responsibility for a messy service they inherited. Your frustration is completely understandable. This approach creates unnecessary friction with customers and forces management intervention on routine technical decisions. It's also unfair to you and other team members who have to deal with the fallout. Have you considered whether your coworker might benefit from pair programming or code review support to build confidence with the legacy code?