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

> but with the slightest bit of pressure those principles are gone

If this is pressure from above, there is little you can do. Employees have one overriding requirement and that is to keep management happy.

Management clearly didn't care about any of this before and they evidently do care about speed, so what are employees going to prioritize?

Also, testing and code review are better at producing bug free features. Most managers I know aren't counting the bugs as part of the feature but rather as an additional feature. Past bosses would be happier with me if I delivered a buggy feature in a week and spent the next week fixing it rather than delivering the feature in 10 days.

The vast majority of software development work outside of startups and the FAANGs is cleaning up someone else's garbage, usually without enough budget allocated to be really thorough about it.

It's a toss-up as to whether your management will be receptive to any plans for migrating over to industry best-practices or not.

If are an "A" employee, and you can't handle working with "C" employees, do yourself a favor, and ask to look into the code base at the interview, then decline if you notice too many bad smells. Otherwise, you will have plenty of future work teasing things out of the big ball of mud, fixing them, and then throwing them back into the blob.

Half of all code-writers are worse than the median. And the median coder will happily copy-paste the first code that works into six different places, rather than spare a thought for future maintainability. Then they move on, you get hired, and will have to discover for yourself that the same broken code is in six-different places, now with subtle differences due to lazy bug-fixes.

Most companies can't compete with FAANGs on salary and benefits, and can't compete with startups on coolness factor. There will be some cargo-culting. Your co-workers will be less skilled than you, but will also have more seniority. You may, in fact, be able to do all their jobs by yourself, in less time. Resist this temptation.

How does this sound? Do your own job the first 2 hours or less of every workday, and then slack off while looking busy for six. Repeat until retirement. Mediocre companies won't reward you for being a better developer. They just don't know how to measure it. And they don't have former developers with still-current skills in management. The way to translate your former expectations over to a different kind of company is to look for a CTO that comes from a similar background as you, and shares those expectations. Other companies don't even know what good code looks like, or how much it costs--even in 2020, after 40 years of software gradually worming its way into every other kind of business. They're probably still using the Excel spreadsheet created by the co-founder in 1992, with all the VBA macros in it, and source control faked by making copies of it with different dates in the file name. It works, so why not?

If those software best-practice process requirements are not enforced from the highest levels, all those sloppy, below-median coders that get hired will drag the company standard down to what they can handle, or, even worse, turn the practices into pointless cargo-culting. Those code reviews could be overly focused on tabs vs spaces, or ensuring that names are in camelCase rather than snake_case, and putting try-catch blocks around code that does not throw exceptions (to name some examples that may or may not be actual anecdotes from my personal experience).

This is such a good word, great find!

There are so many things in production that are prototypes (even when people/companies cannot allow themselves to recognize them as such...), having a word for this pattern is great.

I am not convinced that you have ever worked at the average startup. Your points are incredibly divorced from the reality most face.

Years worth of runway is not the norm. Having your choice of senior engineers to hire right away is not the norm. Most startups exist as sinking ships.

It sounds like you lucked in to a company that raised a shitload early on and so had the luxury to make these decisions.

This is an interesting conversation and one I think about a lot myself. I currently work for a large-ish company with "quite good" practices, and I often wonder what sorts of policies other companies implement. As you grow in your career and continue to join teams that were better than the last, it's sometimes hard to know if your standards are a product of your career trajectory, or simply a product of the times.

However, I do think there is some mid-ground between what you are used to and what the company currently does. In my opinion, these are the minimum requirements of what a mid-sized company should be doing:

- Version control. No excuses here.

- Code Review. This needs to be done.

- Test frameworks are setup and make it easy for a developer to write and run tests. I wouldn't necessarily get hung up on coverage, but large features should have tests in the PRs, and there should be a good culture of testing within the company.

- A CI pipeline that fails the build if tests or linting fails.

- I wouldn't be too concerned about automated deployment from the CI. This also depends a lot on the type of product. It's much easier to automatically deploy a b2p application than a b2b one that might require proper release correspondence with clients beforehand. I think the minimum here should be a system to handle provisioning and deploying to boxes (whether that be something like ansible or in-house scripts).

I'd be interested to know what others think the benchmark should be for mid-sized companies. One last point: You are in an excellent position to make changes within your company. If the truth of the matter is that your colleagues "just can't imagine another way", then you can work with them to try to get some of these policies implemented. If you can convince them that there are actual benefits to doing their job a different way, then I think they should be receptive. You can come out of this job knowing that you helped level-up the developers and left the company in a better place than when you started.