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

I think it is faster in the long term because well tested code is less likely to contain bugs, and reviewed code more maintainable as it adheres to an agreed upon standard. So it may be longer in the short term, but faster overall as you have to revisit the code less due to these reasons.

This is how it struck me, as well. There is a big gradient, and this is the extreme opposite end.

Just be thankful the devs can “push” to production and aren’t individually rsyncing their code into the app servers. :)

I have been in both kinds of companies. 20 years ago, having none of these basics was almost the norm. It can work, and sometimes I even miss those days, because it can be fun and very fast paced. However, it also comes at a price. There's a constant, high stress level because things break all the time, even on production, and you have to be quick to fix them, often directly on production. I wouldn't want to go back, especially not with a bigger team or today's average developer and project complexity. And it sounds like you already made your decision. Unless there are compelling reasons to stay (and maybe try to introduce newer practices), you have learned a lesson which questions to ask in your next interview (also google for Joel Test) and try to find something new.

All of this sounds like something you should expect except perhaps point 4, I don't think deployments need to be automated and with infra as code although that is a nice thing to introduce. I'd push for the first three points to be mandatory though, there's no good reason (except maybe in a 1-3 dev startup) to avoid them.

However, don't see it as demoralizing, see it as a way to teach other developers good practice and have a huge impact on the businesses engineering practices!

It kind of depends on the company and the projects at hand. I've been in a similar situation and still am now to a fair degree. Back when we started the projects there were no guidelines or clear rules and definition set: "There are X developers, this is what needs to be in production in a month". Hardly any specification just a vague explanation of what was needed. Which might have been fine, but half of those developers were as bad as they could get. And even spending 7 days a week at the office was not enough. I mean no one could realistically finish what they were doing and then go back to cleaning after the others. But, 30 days later we were in production(till this day, I have no idea how).

The biggest problem was that most of the bad developers were located in a country, where once you are past your test period, and you are at work at 8, no one can touch you. Meaning that for years, they were doing every anti-pattern known in the books, and someone cleaning up after them(in most cases me). And in those conditions you are left with no choice but to... Cut corners... Eventually we managed to pressure all of them to quit. Keep in mind, there were entire releases where I've personally had to re-do everything they had done for that release because it would take less time than it would take me to tell them what they have done wrong or why. And they were perfectly happy with that. All while every deadline was approaching fast. Now with them gone, things are improving, though we still spend countless amounts of time to clear the roads from what they left behind while still having to build on top. Which, sadly, is a slow and painful process.

My advise - do the best you can do to your ability, even if it means cutting corners for the time being. Once the water has set, things will start going back to normal(but that could take a lot of time). This has to do with the lead developer(which we didn't even have at the start, and one was appointed much later). Eventually he quit so... I was next in line for better or worse...

So a 3 things you need to figure out:

1. Lead developer - are they pedantic, strict and do they go over stuff when they have free time and fix/optimize things? If they do re-factor or even rebuild entire chunks of the application with the intention to improve it, then sit back and relax. Things will eventually start falling into place(see my following points). Go through something big in the project they have developed on their own with sufficient amount of time at hand? Is it clean, well structured, documented and organized or is it just "working". Do they write documentation when they can or do they just kick the can down the road(again, stressing on "sufficient time")? If it is effectively good code, you are on the right path. Granted that the rest of the team has the will to learn and improve. Tl;dr - follow the leader, something which has been instrumental for many of the developers I've worked with. Eventually they will start mimicking the leader's behavior. Your best course of action is to give him/her enough space to be able to clear things out - you know - flatten the curve.

2. Tests, while good, are not always a clear indicator. Sometimes people take tests as ground truth and as long as a test passes, they will call it a day. In addition, some systems are way too complex for automated tests. I have such an example, I've worked out the math: you need a 124! (yes, factorial) to cover all possible scenarios. And counting... Good luck with that. So yes, no tests, just making sure that there's a way to restore things if something goes wrong.

3. Company infrastructure - some companies are incredibly strict and conservative, meaning that developers end up having to spend ridiculous amounts of time trying to get around firewalls, rules and regulations. Which, as you can imagine, takes a lot of time and a lot of effort to break out of. But with the adequate amount of will and time that's not impossible.