1. that's a pretty horrible interpretation for an engineer to have. Though I feel "code" and "codebases" are different topics to consider. There will always be some bad code as long as multiple people work on a codebase (because you're simply not going to have a principle programmer stuck doing minor bug fixes). I argue most truly bad codebases fail early (or become bad later, when being a "good codebase" is no longer a selling point for them, and as people shuffle in and out).
2. even if it's true that most companies have tereible codebases, I argue good codebases with no traction is worse than bad codebases with traction. Ideally we have good code with traction, but this example shows that even multimillion dollar companies will be sold on promises rather than proper features.
1. that's a pretty horrible interpretation for an engineer to have. Though I feel "code" and "codebases" are different topics to consider. There will always be some bad code as long as multiple people work on a codebase (because you're simply not going to have a principle programmer stuck doing minor bug fixes). I argue most truly bad codebases fail early (or become bad later, when being a "good codebase" is no longer a selling point for them, and as people shuffle in and out).
2. even if it's true that most companies have tereible codebases, I argue good codebases with no traction is worse than bad codebases with traction. Ideally we have good code with traction, but this example shows that even multimillion dollar companies will be sold on promises rather than proper features.