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

You as a manager at a slightly more mature startup: "What, you want to rewrite? No, everyone knows rewrites don't work! Just hire up and keep moving fast."

Experienced eng lead after a few months of burning out on a miserable project: "I have better options for this, here is my resignation."

Board member after another few years and lots of turnover: "It seems like we're no longer able to execute because of all our technical debt. You have been a great manager for this early stage of the company, but now we need to bring in the mature company professionals. Thank you for your service."

end scene

I do not even claim that this is a bad outcome. It really is important to execute quickly early if you are going to have any chance of success. I have made the mistake of being too slow too early. But path dependency is also a big deal, and there is rarely (never?) an obvious bright line point at which it is clear that the time is right to up the professionalism game. It is not hard to get into a situation where the team is spending nearly all their time baling water out of a sinking ship that you're still trying to sail while competitors speed past you in newer sleeker dryer ships. I also think the hiring / turnover risk is a real problem. There are companies with good engineering practices, which make work much more pleasurable, and you are competing against them for talent.

But I think this is a false dichotomy. I think there are a set of practices that don't introduce so much friction that they are an existential threat early on, but that are small steps in the right direction down the path to practices that scale well.

I think it is telling that you went straight to Terraform in your example, although nothing like that was alluded to in the OP. I would agree with you that Terraform does not belong in this low-friction-step-in-the-right-direction category of practices. But I think all or most of the practices the OP actually listed do fall into that category. Code review, in conjunction with automatic style fixing (which most languages have tools for now), is low friction and has immediate value. Same thing for unit tests. I do think a whole end-to-end testing setup is beginning to be more friction than can be afforded, but unit tests are easy (especially if you choose languages with type systems that allow you to dispense with tests that verify the type contracts are being satisfied). Automated deployment is actually both a step in the right direction and something it would slow down your early execution to not have.

There is a huge gray area, and I think it is really difficult to strike the right balance (to wit: I've never seen or personally accomplished this balance satisfactorily), but I think it is the right way of framing it. I think the right mindset for you as a manager at an early startup is not "we don't have time for that!" but "will the ROI of that be worth the time?", and that you need to do the hard work to explain that that thinking to and get buy-in from your developers.

You have to sacrifice a lot of code quality and professionalism in fast paced environments, its almost always better to under-engineer than to over-engineer

Here's my opinions

- codereview - there's never any resources for QA. I just check teammates PR if it builds and passes a few manual tests, then merge. I don't spend more than 15 minutes on this. Coding standards highly depends if I've worked with teammate before. Sometimes I disagree with something but still OK it anyhow if its just me being nitpicky

- Test coverage - not in early stages. If you use typescript it eliminates a huge need for test coverage, but you'll still eventually want end-to-end testing. Just not until production is near deployment

- Normal development workflow - No tests, its a high opportunity cost, but again depends on what software your building. I'd say 90% of apps don't need testing early on

- CI/CD - yes, its good practice to still use protected branches and specify workflows for PR'ing and naming things

At the end of the day, you realize you have to cut corners and need to weigh out the value proposition each tool set offers. As well as how your team composition works.

Sometimes you have to defer tasks for later dates to revisit because its over-engineering and things aren't fleshed out enough yet

The most important thing early on is elminating tech debt too. Each decision you make is cascading. For instance code patterns you set today are going to be used several months from now, ideally you want to minimize the need for refactoring early on.

Write clean code with good variable names, and sane folder structures. Likewise with sass styling etc. KISS (keep it simple stupid), just follow those rules

I work for a company that took all sorts of shortcuts that we are digging our way out of now. But guess what? If they hadn't taken those shortcuts, they would have run out of money before they found product market fit, would not have referenceable customers (B2B), would not have been able to secure funding and the company wouldn't be around today and well enough capitalized for them to pay me to help improve processes.

Some pointed out things like retrospective on outages, but there are other things, like how testing could reduce the number of bugs, thus, reducing context switching and debugging times.

You could even tight it directly to money by measuring what a bug cost and make a experiment in a team showing testing reducing that cost over time.