Ask HN: Are my expectations on code quality and professionalism too high?

The standards you've described are totally reasonable! This sounds like an amazing opportunity for you to have a really wide impact and a great chance for the company to level up their game using your experience. I'm sure you've thought about this already but it doesn't have to be a "fight" - in many cases what people need is some appealing reasons, e.g. describing how their world would be much more amazing if they implemented X, Y and Z. Depending on the size and stage of your company it might actually make sense to do it in a 'quick & dirty' way (e.g. dominating the market might be more important at an early stage than doing it in a sustainable way) but even then they (tech decision makers) should be aware of the tradeoffs and if they are, they should be communicating the reasons to the whole company.

Your standards are reasonable. However, what's missing in a lot of comments is a good process for assessing what the human and business factors that led to where the company is now, and how to approach changing it. This is natural as most people here are techies first, but it could lead to setting you up for a bad experience.

There are very limited conditions, under which making this a blame exercise would be the right answer.

There are also business conditions, under which this situation is the best that the business could have achieved by now. Eg, if other things needed to be higher priority for the viability of the business. Having said that, once you are in such a situation it is difficult to get out of it, and hence such situations tend to linger for much longer than any justification.

What you probably need to do now is find out how much appetite there is to change, and what the blockers are.

Consensus that these processes are really the best way to do things is relatively recent, and I wouldn’t be surprised if there are a lot of shops that haven’t yet retooled to them.

Continuous integration was only proposed as a concept 30 years ago, and was a relatively fringe theory for another decade at least. Automated deployment followed a similar path, but about a decade later. Manual acceptance tests, in particular, remained quite common a decade ago even at the big tech giants.

To counter the flood of 'you sound reasonable', I think you are probably being unreasonable.

The hint is "spaghetti code".

What might have happened is you started slagging off everyone's code as soon as you've come in and now you're plucking at straws to justify it as you're getting ostracized.

Also, objectively speaking, how can writing MORE code and spending MORE time talking to people be faster? Your argument makes no sense. Tests and reviews are a massive drag on development, also more code means more bugs. That we know.

It would take years to get full test coverage and somehow you think that makes everyone inherently faster?

Also, ask yourself this, how much money have they lost so far by doing this? Is it perchance $0? Zero downtime? As you've not listed a single actual COST of what they're doing.

While direct to prod/connect to prod db is nuts and not normal, you also haven't given the context of who did that and why they did that. Is there really no staging server? No Dev branch?

This looks like a cultural problem where the top brass either believe in strong-arming developers or aren't aware about the dreadful impact of not following processes (code review etc.)

Your expectations are perfectly reasonable. I think you should consider explaining to everyone (including non-developers) how bad things can go if these practices continue.