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

When I first entered an environment with CI and code reviews as a junior, my thoughts were "OMG I am going to get nothing done now - it is going to take forever to do anything!".

And I was right to a degree - before I could pickup a bug, fix it, and it submit to the main repo without any fuss or review within 5 to 10 minutes and it would be in the next release. Knocking out bugs was a dream - done! fixed! resolved! done! done! done! DONE! project managers loved it as you could just machine-gun through fixes. Afterwards my personal velocity slowed right down and it felt very restraining.

This freedom and simplicity to do what is needed for developers is super seductive. If you come in as someone new to a team and want to start taking this away from people, you'll probably get some pushback with people complaining about it slowing them down/taking too long etc

So with that said, I don't think your expectations are unreasonable, but if this "wild-west" culture is ingrained it is going to be hard to introduce it.

My advice:

- get explicit "firepower" from as senior person as you can find. Make the request to do these things come from that senior person, not you. If it is you boss's boss's boss's boss is telling your team to do it, that carries greater weight than "the new guy" (no offense) and complaints about going slow or whatever are then kinda moot since your boss's boss's boss's boss knows the repercussions and wants it done like that regardless.

- couch these things as a developer aid. E.g. proper unit testing can help to prevent embarrassing mistakes or make "risky" changes less stressful, CI and repeatable builds means that the boring toil of cutting the release is removed etc. Reviews are a harder sell as most people see it as an intrusion/trust-thing/"we don't trust you not to fuck up without us checking"-thing/etc.

- try introducing things piecemeal. At one place I worked, we had CI but failing tests were not a blocker (we had a more of a jokey "hat of shame" where someone had to wear a top-hat or cowboy hat or something if they broke the tests that day) - eventually people ran the tests before submission to avoid the hat of shame and people were proud to say they never had to wear it over the past 5 sprints etc. At another we did "ad hoc" reviews where senior devs or TLs would randomly pick some changes from the other devs and review those after they had been submitted to get some level of oversight - usually hideous hacks, lip-service unit tests, or spaghetti messes were uncovered pretty quickly this way, but didn't "slow everyone down".

Slowly as people get used to unit testing and reviews or whatever you can slowly tighten the screws and introduce more rigor. Hopefully eventually people will come to appreciate the benefits these things bring.

Good luck.

Yep. Worst application I've ever had to work with was a WinForms monstrosity where ~300 form elements were used to store the application state, and none of them were named (so it was all "TextBox1", "TextBox2", etc.). Most of the application logic was in a single ~8000 line method. An absolute nightmare to debug or modify.

Me as a manager at a startup: "Look, we have 5 months of runway. Does that make sense?"

Young dev from large corp: "Yes. But if you don't use Terraform we wont be able to see our infrastructure changes over time. We don't even have a proper code review process."

Me as a manager at a startup: "We have two micro instances. Do not install Terraform. Finish the import prototype... now."

Young dev from large corp: "Sigh, ok, just saying in 2 years from now we wont be in a good spot". [Then proceeds to blow 2 hours complaining on hacker news.]

Your perspective is just right in my opinion (and apparently most of the commenters).

I have worked in several small companies with 1-20 devs and have seen this again and again. I have been thinking a lot about all this, so in case you're interested, here's my thoughts on the subject.

For context:

I use git for almost any size projects, unless it's a couple of files, for an internal non-critical project. I create tests for at least the critical paths and usually benchmarks for hot paths. I use docker to separate dev from prod, while keeping a realistic environment. I use code formatters to avoid spending brain power, thinking about details that are irrelevant to the solution. I monitor and log as much as possible from the start.

Early on I was a part of the "code, then deploy" group, thinking that it was the clearest, easiest path to get as much done as possible. Slowly I have learned to use version control as a helper while coding, rather than a chore to be done after changes. E.g. by not being afraid of large re-factoring, when I see a way to clean up code or as an easy way to just try something out as it can easily be discarded again. It has also put my brain into a "segment changes into similar things" or maybe rather "do one thing, then another", instead of changing 7 things at once. This is not always true of course, but I try as it makes it easier to keep track of changes.

The same thing with separation of dev and prod (and test, etc.) - it makes it safer, simpler and easier to try things out, when you aren't afraid of breaking things.

On top of what you have mentioned, I've also always been the ops. guy, which has taught me to monitor and log as much as possible, then remove unnecessary monitoring or logging, when it becomes obvious noise. It also helps you understand WHY it's important to have working code in production ;-)

What I have experienced:

ALL of the above have ALWAYS been seen as "extra" from the business side and usually from other devs as well. It's hard to make (some) people understand the value of checking for correctness now, is better than having to find bugs and fix them 3 months from now (after they've usually caused data loss or corruption).

It's even harder to argue for the value of changing existing code AND write tests for it. It can easily seem like so much extra time in which nothing new is being produced.

I think the issue can be summed up in just a few points:

We as developers can be very averse to changes in our daily routine and/or how we do our job. Also: to get any size team to be effective, everybody has to be on board with 1 way of doing things.

Both dev and biz needs to understand and trust, that what seems to be slow progress, compared to "code, then deploy", is actually a streamlined process that makes development safer, faster and less buggy (and more fun) in the larger perspective.

Possible solutions:

It all becomes a cost / benefit analysis for biz and/or a question of getting devs to see the benefit in their daily work. Biz can usually understands the reasoning behind spending more time now to save even more down the road and avoid bugs in productions as that equals happier customers. Even better: tell biz devs, they'll have a less buggy system to present, when they meet with potential customers! The most resilient idea I have fought against, is the the thinking that you can keep adding low quality code to low quality code at the same pace without creating more/new problems.

I think that the 1 thing that concerns most developers is what held me back from all of this to begin with: We want coding to be easy and fast. We want compile times to be as fast as possible, trying code and testing to be snappy. Everything that is not code should be the absolutely minimal amount possible. So... If you are used to "code, then deploy", then testing, version control, code review, CI, CD, etc. can seem like a lot of extra work, that will take time away from solving a problem in code.

If you can show what each step accomplishes, a lot of developers can see the reasoning and if asked if they're willing to try, will actually be willing to try. The next step is to make sure that each step is impossible to avoid. E.g. Somebody has to be responsible for code review, pushing to production, etc. It should be impossible to commit directly to master branch or whatever is used for live. Pull requests should simply not be accepted, until it meets the requirements agreed upon.

Sometimes a clear path can remove the perception of e.g. creating a pull request, being a roadblock rather than a safeguard that helps you code faster and more safely.

Always remember, you are not there to make code better or implement robust processes.

You are there to make money. Or, if you are working a lower tier job, simply reduce costs. If you are not doing one of those two things as a developer, your job is in grave danger and you will be the first one cut.

Throw your standards away, your standards are the company’s standards now. If you want to preach standards go be a consultant.