The truth is, most codebases are terrible. In any company that's been around for more than a year, you're likely to find most (or all) of the following:
* Legacy code that was written by people who left long ago and nobody wants to touch
* Code written in "uncool" languages, frameworks, and libraries that nobody wants to touch
* Code that was written by various offshore contractors
* Non-deterministic test suites that randomly fail and that engineers learn to skip/ignore rather than address
* Long build times
* Weird, bespoke code that was written for "fun" rather than using an established library or framework
* Microservice hell - impossible to tell what the codebase actually does since the true business logic is distributed
across so many different services, and only an old-timer will be able to tell you how they all connect together
* Severe lack of internal documentation
Given the above, when trying to select an employer, I think it's more important to carefully evaluate the people you'll be working with:
* Are they pragmatic or idealistic?
* Are they chasing fad technologies or are they comfortable using established frameworks that get the job done?
* What do they value more highly, delivering useful software or developing byzantine processes for everything?
* What percentage of the workforce is full-time vs contractors?
* What's the average years of experience of the engineers? Are there any adults in the room?
* Do people know the vision of the product? Do they what they're building and why they're building it?
* Legacy code that was written by people who left long ago and nobody wants to touch
* Code written in "uncool" languages, frameworks, and libraries that nobody wants to touch
* Code that was written by various offshore contractors
* Non-deterministic test suites that randomly fail and that engineers learn to skip/ignore rather than address
* Long build times
* Weird, bespoke code that was written for "fun" rather than using an established library or framework
* Microservice hell - impossible to tell what the codebase actually does since the true business logic is distributed across so many different services, and only an old-timer will be able to tell you how they all connect together * Severe lack of internal documentation
Given the above, when trying to select an employer, I think it's more important to carefully evaluate the people you'll be working with:
* Are they pragmatic or idealistic?
* Are they chasing fad technologies or are they comfortable using established frameworks that get the job done?
* What do they value more highly, delivering useful software or developing byzantine processes for everything?
* What percentage of the workforce is full-time vs contractors?
* What's the average years of experience of the engineers? Are there any adults in the room?
* Do people know the vision of the product? Do they what they're building and why they're building it?