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

My point is: a lot of software wasn't built using these principles. Software that's used in a lot of places and/or got very popular (also note there's no "unit tests" in those items)

So yeah, these are all good, but what I would set as priority (in my mind)

- Source control

- Quiet/comfortable working conditions (the "best tools" might be merged here - though the meaning of best tools is debatable)

- Bug database

- One step build

- Candidates writing code on interviews

Fucking that. Only skip the basics entirely if you don't plan to hire anyone in those 5 months (no or inadequate tests, no scripted way to create a dev instance? You just cut their first-two-months productivity in half.) and are 1000% sure no-one's gonna horrifically break prod, and don't mind dev velocity dropping ~10% (and/or bug rate and "of shit it's on fire" calls increasing alarmingly) every month over the next 6 months.

There's a lot of room between "we need a k8s cluster with autoscaling, three kinds of databases, lambdas, blah blah" and "LOL develop on prod YOLO!" IME this kind of thing never gets added in month 4 because there's already too much tech debt. Add it in month 1. A couple days and 10s of dollars/month setting up or buying tools & services to keep your team confidently moving fast over the next half-year is some of the most valuable work you'll do.

[EDIT] oh and in the specific case of Infra as Code or fully-scripted deployments, around month 4 when your stuff's a bit more complicated it makes your answer "yeah, give me these couple pieces of info and put me in touch with one of their tech guys and I'll have it done by lunch tomorrow" instead of "uhhhh... fuck... uh.... two weeks? Hopefully?" when your sales guy says "we've got a huge deal almost closed but they need our thing hosted on govcloud/on-prem/European servers, can we do that?"

Even small teams of 3 people can benefit from basic code reviews and CI pipeline that makes them significantly more capable of responding to new business requirements than startups bogged down in 5 months of technical debt.

The startup that I joined after that had passwords stored in plaintext via a google spreadsheet. Code was not stored in VCS and updates were done in production. I helped the organization adopt scrum and added some development processes in place and added tools to help me and the small team (me +2) of developers manage the different codebases a little better. No one wanted to do this but I forced it anyway.

The organization I'm at right now was similar but has a lot of different challenges.

Each organization you join will be different, the culture will be different. Some will be focused on quality and some will not. You need to understand a few things and be able to communicate with executives and/or managers to accomplish your goals.

Executives do NOT GIVE A SHIT about automated deployments, code coverage, code reviews, etc. They view those things as wastes of time and the "code monkeys" should just get back to work. I'm not saying this is the case 100% of the time, but you need to change how you communicate with these people. Explain what tech debt is and how small investments in time can reduce this. Yes, going from 0% code coverage to 80% is going to take time, and this is something you will need to explain to them.

Some devs are similar and I think that's mostly because no one sticks around long enough at a company to maintain their shit code.

Depending on your role you are either in a position to force these things to happen or you are in a position where you need to bring others up to your level. Both are difficult in their own ways and will require a large time investment on your part. However, BOTH will require you to help others raise their expectations.

The other thing I want to leave you with is a conversation I had with a mentor a long time. Being in a similar situation he told me to not hold others to MY expectations. Hold others to THEIR expectations. This comes back to helping others improve. Bring others UP to your level.

If none of this helps, you may want to quit and find another position elsewhere, but keep in mind, this will be something you are going to run into in many organizations and you are going to have to learn to deal with it.

> the senior engineers knew our estimates were crazy high compared to what they'd be able to do independently

Interestingly, I worked at a company where teams of engineers were given wide latitude to design, implement, and deliver their features in isolation. The theory was that engineers could be more productive if they were left alone to make the decisions.

I'd say it worked about 1 in 4 times. The other 3 out of 4 times, engineers created their own labyrinth of over-engineering, spent too much time building things as reusable frameworks instead of simply getting the job done, and over complicating the system with unnecessary "Wouldn't be cool if..." type features.