[ldjkfkdsjnv]

Managers dont have the time to figure out if someone did something well or poorly. The code works and so they move on. Certain people leave a trail of bad code with nice looking syntax. Working directly with them, it will be obvious, but otherwise forget it, you will never figure it out. All it takes is them speaking well in meetings/good at project planning/BSing some design.

The result of their bad code is future changes take 2x-3x as long. But no one can tell if those timelines are just what they are, or that there is a problem with the existing code.

[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?"