[johngalt_]

I think there is a difference between bad and good places. I have worked in bad places where things worked exactly as you described. Fortunately times have changed, and places I work now care about quality. Most of the time managers used to be engineers and they either know and care about it, or they care and rely on input from other engineers to understand what is going on under the hood.

[ldjkfkdsjnv]

Eh I've seen this even at FAANGs.

The thing is, the syntax/design patterns in the code can look clean. But that doesnt mean the abstraction/interface is the right one

[syntheweave]

Every formalization of a workflow is susceptible to this.

I recall how when Git started getting widespread adoption, a popular blogpost theme was discussion of cleaning up your commits...which is the kind of thing you can do if you're writing in small increments. But code that "moves mountains" in the architecture, as is often the case in a greenfield project where there's a lot of learning being done, tends to have dirty rip-off-the-bandage moments. If you clean up those kinds of commits, it's not really beneficial to future code archeology. But if you're clocking minimal effort and maximum CYA, it suddenly becomes hugely important to dot the i's and cross the t's, because that looks more professional than a commit log where you iterate on it a bunch and your log is like "maybe it's fixed now?"