> Either you're a true 100x coder who can get a full understanding of every single project and every effect it will have through the full end to end stack.

It's hard to state how good I am without sounding like an arsehole, so here goes... I am certainly a very experienced engineer, I've coded from the age of 10 and now at 50 I'm 'retired' after selling the company that I founded. I started in the 8bit era doing low level to-the-metal coding and ended it building an internationally used healthcare SaaS app (with a smattering of games engineering in-between). I've been a technical proof-reader for two Manning books, have at least one popular open-source project, and I still write code for fun and am working on my next idea around data-sovereignty in my now infinite free time... so yeah, I'm decent, and I feel like I've gained enough experience to have an opinion on this.

But also you're not reading what I wrote. I never said "a full understanding of every single project and every effect it will have through the full end to end stack", which I explicitly dealt with in my last reply, when I said: "It’s important to understand the scope of the change. Knowing more may well improve decision making, but pragmatism is of course important."

If the scope is small, you don't need "a full understanding of every single project and every effect it will have through the full end to end stack". But in terms of what it does touch, yeah you should know it, especially if you want to become a better software engineer, and not just an engineer with the same 1 years worth of experience x 30.

It should also not take "a few days" to investigate the scope. If it's taking you that long then you're not exercising the capability that allows you to navigate around unfamiliar code and understand what it's doing. That knowledge accumulates too, so unless you're working on a completely different project every single day, you're going to get quicker and quicker.

I have seen pathological cases where a dev that worked for me went so far down the rabbit hole that he got nothing done, so it has to be a pragmatic process of discovery. It should entirely depend on the extent to which your change could leak out into other areas of the project. For example, if you had a reusable library that had some core functionality that is used throughout the project and you wanted to change some of its core behaviour, then I'd want to find all of the usages of that library to understand how that change will affect the behaviour (if at all). But equally, if I was updating a UI page or control that has limited tentacles throughout the app, then I'd be quite comfortable not doing a deep dive.

> "here's code that Bob wrote 10 years ago, it's not working. Customers are complaining and this needs to be fixed yesterday".

I've been in that exact situation. You need to make a decision about your career. Are you just going to half-arse the job, or are you going to get better? If you think continuing as you are is good for your career, because you've made your idiot boss happy for 5 minutes before they give you the next unreasonable deadline, then you're wrong.

The fact is the approach you're taking is slower. It's slower because you and the team of engineers you're in (assuming everyone takes the same approach) are accumulating bugs, technical debt, and are not building institutional knowledge. When those bugs need dealing with in the future, or that technical debt causes the application to slow to a crawl, or have some customer-affecting side-effects, then you're going to waste time solving those issues and you're sure as hell gonna want the institutional knowledge to resolve those problems. AI doesn't "understand" in the way you're implying. If it did understand then we wouldn't be needed at all.

> Most likely the fix will work and nobody has to touch that bit in a few years. Should we spend time to understand it fully and document it, add proper and comprehensive tests? Yep. But the bosses will never approve the expense.

So you work for a terrible boss. That doesn't make my argument wrong, that makes your boss wrong. You can obviously see the problem, but instead of doing something about it, you're arguing against good software development methodology. That's odd. You should take umbrage with your boss.

The best engineers I have worked with in my career were the ones that fully understood the code base they were working on.