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

I have lost perspective on what is reasonable to expect, and need a reality check from HN.

Some time ago, I left a large-ish company with what I perceived as overall quite good engineering to join a smaller company. When I say "quite good", I don't mean perfect, but what I consider the basics were there

- Code review, where we would consider architectural concerns, failure cases, etc. ensuring maintainability. Shortcuts were taken intentionally with a plan to address them

- Test coverage was good enough that you could generally rely on the CI to release to production

- Normal development workflow would be to have tests running while developing, adding tests as you introduce functionality. For some projects that didn't have adequate test coverage, developing might involve running the service locally and connecting to staging instances of dependencies

- Deployments were automated and infrastructure was managed in code

Those are what I consider the basics. Other things I don't expect from every company and am fine setting up myself as needed.

In $current_company, I was surprised that none of the basics were there. All agree to do these things, but with the slightest bit of pressure those principles are gone and people go back to pushing directly to prod, connecting to prod DBs during development, breaking tests, writing spaghetti code with no review, leaving us worse off than we were before. This is frustrating since I see how slow dev is, and I know how fast it is to develop when people write good code with discipline. Most devs in the company don't have experience with other kind of environments (even "senior" ones), I think they just can't imagine another way. My disappointment isn't with the current state, but that people of all levels are making it worse instead of better.

These setbacks are demoralizing, but I'm wondering if my standards are unreasonable. That this is what mid-sized companies are and I just have to endure and keep pushing

You can try and softly push towards better practices but if it's an organisational issue you will likely fail. Your standards are not unreasonable so it might pay to find a better company

I would say your standards are very reasonable and should be implemented across the board.

In my experience it's very easy for company culture, namely in smaller businesses, to get the impression that code quality is a luxury rather than a necessity. And it's even easier to have good intentions, but due to a lack of cultural enforcement just keep them at intentions and never implement anything.

So I would say that you either try to get your standards across or learn to live with lower standards .

Eeek. Doesn't sound like you're being unreasonable in your expectations at all!

I've been a small business owner, and a software contractor, so I've seen a fair few medium/large python codebase of varying age and quality.

To address your points from the ~10 codebase I've worked on in recent memory:

- Code review: Always in place, though often the CTO has a tendency to merge without review on evenings/weekends

- Test Coverage: Often a challenge - or rather tests are there for coverage, but are of poor quality and don't really assert anything that useful

- Your suggested normal workflow _is_ the normal. Sometimes there's been a dedicated QA team that verifies the changes as seen by the end user too.

- Deployment: Yep. Heroku or k8s have been common, but at least some form of 1-click deploy/promote

Perhaps I've just been super lucky! There are often still major problems in the codebase and refactoring/rebuilding needed to address the challenges, as well as resistance of the existing team to truly change their mindsets to address the problem v.s. the band-aid (or instant gratification) of a quick fix.

Don't give up the fight!

These don't sound unreasonable. I've been in a similar situation before. In my experience, if the culture in the org is generally positive, it is worth taking the effort to champion good practices. You can become the go-to guy for setting these standards. Future developers will thank you for having done so.

However, if you think the culture is not conducive to positive, large scale change, it might end up being a waste of your time and energy. Having to constantly say no, and ask for everyone else to fix stuff in PRs can be exhausting. There is also a real risk of others perceiving you as someone who always finds faults with everyone else. That is a hard tag to shake off. Balancing that is the real challenge.