I've worked on plenty of good codebases. I think the key is continuous improvement. The code from 5 years ago is always going to be worse than today's code, but as long as you're able to improve code as you work on it it doesn't get too bad.

Once when I was interviewing for a job, I was given and offer and I accepted it conditionally. I asked to sit with a senior developer for 30 minutes and browse the code. Turns out it was in great shape and the person that gave me the walkthrough was one of the greatest programmers I've ever had the pleasure to work with.

Do you do this for every job you apply to?

No. This company's main product (the one I would be working on) had been around for a long time so I was concerned about what kind of shape the code was in.

A lot of the codebase at Google is pretty darn good. Certainly nowhere close to approaching a technical debt singularity where further progress becomes impossible.

There is a difference between bad code you write today and make better tomorrow and code so bad that it takes you days to even understand it properly that making changes become very difficult and usually always breaks existing functionality.

I work on two systems at the moment, and they are in very good condition

Yeah, I agree. It's a really common excuse and I think it somewhat diminishes the credibility of those who use it. I don't think anyone's opinion on what constitutes a "truly horrible codebase" should count until they've been a developer for at least 10 years, worked at several different employers, and contributed to several different large open-source projects (which usually have the luxury of rejecting code until they feel it's "right" despite the potential commercial consequences, not something that most other projects get to do). "This codebase is terrible" is a common whine from newer devs and/or people that are just too lazy to put in the time to learn someone else's code.

In the real world, production projects get messy because getting stuff done is more important than building a codebase that represents the paragon of academic excellence. That doesn't automatically make the project horrible.

Depending know how horrible it gets that starts to affect maintainability and development of new features.

You mean like SQL query strings sprinkled throughout and IF'd depending on the DB type? Yeah...

I think I know a better way because I run a 7 figure a year project and the codebase isn't a mess. :/

In my experience it mostly just boils down to having the right processes and being strongly motivated to do things right rather than push things out the door as quickly as possible. Assuming superiors have your back, this is doable. It's when they don't or when the developers lose or completely lack motivation that things start to fall apart.

Lack of motivation often means lack of process, lack of process often means lack of testing and maintenance, lack of testing and maintenance often means lack of quality. It's a vicious cycle too - once you start down the road it's harder and harder to get motivated about your product again.

Pretty much.

Honestly, the only reason the codebase isn't a mess is its a single project I've been able to tightly control and enforce things on [because its 100% my problem if something goes wrong].

The rest of our codebase is filled with drama. :/

As someone who has seen several LARGE commercial software projects, there is a definite gradation from "it's hard to comprehend these layers of abstraction, but after a few days I kind of understand how they interact" to

    // X - uncommented on 1.2.03 to fix bug
    // Y - commented again on 3.2.03 because it broke stuff
    // if (condition)
    {
       ... logic here, half of it commented out ...
    }

Of the same opinion, there is sort-of the architecture "mess" where it is complicated and you may just have to spend some time learning and/or see some hiccups because large projects are complicated and then there is the 15 year old code base where _everything_ feels hacked/tacked on.