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

This is not unreasonable at all.

Does a captain of a ship do exactly what his crew wants all the time? No, because they're steering a ship and sometimes they have to make moves that not everyone will agree with.

I thought the same thing, but after reading what the comment said again it wasn't a "use terraform or don't" story, it was terraform vs "import prototype".

Generally for most resources, I feel like I can write terraform just as fast as I could create the resources in the console.

Probably not a good example, but I agree with the sentiment that you have to prioritize the business.

There are definitely small and medium sized companies that follow the principles you describe. However, there are lots that do not. Trying to transition a company from "do not" to "do" is quite difficult.

Whenever I hear stories like this, I try to ask the person to imagine how the relatively good practices were born in the better company. The pressures are similar. The people are similar. There are two really big differences: the current situation of the organisation and the approach you take to move toward a better way of working.

One of the easiest ways to change culture is if everybody in the culture is unhappy. Revolution is just a suggestion away. When you look at things like the first XP project (whether you believe it was a success or not), it's well documented that they were able to use XP because they were just so sick of the thing they were doing previously.

Often this is not the case, though. Some people like what they are doing now, or doubt that another way will be substantially better. In this circumstance, I like to try to do something I call "aligning vectors" (which I'm pretty sure I stole from something that James Coplien wrote, so if so, I apologise :-) ).

Software is a team sport. When you think you have the correct way of doing something, it is tempting to go and do it. But if everybody goes off in different directions, following the ideas that they think are right, the result is that the team as a whole will certainly fail. Perhaps it won't be your fault (you walked in the right direction after all), but it hardly matters.

So what you need to do is to convince everyone to walk in the same direction. At first, it doesn't matter which direction you go. It is completely fine for everyone to walk in the wrong direction as long as you can change direction later. It is much easier to change everyone's direction after they are all going in the same direction to begin with.

This means that your first task is to align yourself with the majority - even if you disagree with it. Remember, at first you just need to get everyone walking in the same direction. That means that you need to walk in the same direction as the majority.

Next, you need to look at what other people are doing differently. If you think one person is doing something better than the others, try to align one of the others towards that person. This is where you need to be a bit clever, because not all people are equally easy to align.

In any group, there are early adopters, middle adopters and late adopters. Early adopters will try anything for giggles. Middle adopters need to have some kind of evidence that the thing is better for them to try it. Late adopters will not try it until the vast majority of people are already doing it. So your task is to find an early adopter and get them to try the better thing that someone else is doing.

Now here's the most important thing. You need to make sure that they are successful. You need to help that person and do everything in your power to see that they succeed. If they fail, it's best to say, "Oh, that was my fault (for whatever reason)", so that they feel OK about failing and will feel happy to try again with something else. If they succeed, you have to say "Oh, that's amazing! You are great!" so that they feel happy they tried something new.

Then you need to advertise the success. Once the middle adopters see the success, they will want to get a piece of the action. Encourage them gently and hopefully you will get one to bite. If you make them successful and make them look really good, then others will want to try.

Eventually you will have only the late adopters. The thing about late adopters is that they are usually very socially sensitive. They will be very uncomfortable with everyone else doing something other than what they are doing. They may complain. They may get angry (even at you). Just stay calm and suggest, "Why don't you give it a try? If it doesn't work, we'll learn something that everyone can benefit from." Usually they will, but if they don't, it is totally safe to let them do their own thing for a while.

Keep doing this (it takes a long time!) until everyone is going in the same direction (with the exception of 1 or maybe 2 late adopters). If you do a good job, everyone will trust you and will be very eager for suggestions about what to do next (because you have a history of helping them be successful). It is at this point you can introduce something new: "I don't know if this will work for this team, but in my last job we did X and it seemed to work really well".

The more success you have and the happier the early and mid adopters are, the more pressure the late adopters will put on themselves. They hate this kind of thing. They will either decide to join you, or they will quit. I've never seen another outcome (and it breaks my heart when they quit).

Anyway, I typed too much. YMMV :-)

The reality in most startups is that everyone works on whatever will increase revenue the most. There's no point in testing, code reviews, CI, etc if you are not yet sure that you'll still be selling the same product 2 months from now.

That kind of makes it a moot point if people get it or not. They just do what needs to be done to help the company survive. Once the company is secure financially and has settled on a product, then it's kind of not a startup anymore.