| 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? |
While I can empathize with the desire only to work in neat and tidy situations, people who have such requirements are often insufferable, and are in my view deserving of a significantly lower salary because they can only effectively contribute in a very narrow range of situations.