In hour fairly infrequent meetings other engineers have raised the point that we should start valuing code quality and proper testing to our codebase, only to be met with arguments such as "the customer doesn't pay for good code".
Furthermore, most likely an anecdotal bias and nothing else but I want to mention it: Online elitism revolves around shipping speed too. Comments like "I can build X in Y hours", "I can skim the docs and build what I want with Z library in less than a day", and so on.
How does everyone feel about it? Maybe it's just me but it feels weird. It's kinda like everyone I mentioned feels like there are no trade-offs to be concerned in regards to speed over quality or people decided that there's no reason to bother ourselves with contemplating what we're trading off speed with. Also, I feel that because quality is subjective and perfect is the enemy of done, people rely on objective metrics like "time taken".
Is there truth and merit to this observation?
Poor quality code is a clear indicator of short term-ism. It is senior leadership's responsibility to protect the long term health of the company, and only senior leadership can do that.
If you are a line worker and you are making long term decisions, then you are what's called a 'hero.' You are sacrificing yourself for the greater good. Being a hero is not rewarded, it is punished. Hero's end up burnt out and cynical.
You can either choose to lead upwards by trying to get your senior leadership to understand the long term cost of their short term incentives or you can do what everyone else is doing and be a mercenary. Your stock compensation is the only thing that should make you question your mercenary status. Unless you're employee 5 or working for a rocket ship, your stock is probably not functionally different than salary, that is, you probably won't double the value of your stock to make being a hero worth it.
> "the customer doesn't pay for good code".
If this is how they see it, those are the rules they set. Do it for 1-2 years and leave when the company starts collapsing under the weight of their poor quality code.
I am sure there are environments where that is the driving metric (like the environment you are in), but I've never been in such a situation in the 17 years I've been a "professional".
You always have to balance a bunch of things instead.