Hacker News Reader

Your analogy is flawed. The CPU doesn't care at all about how or what code looks like, all the nice comments explaining what it does, nice naming conventions, whether its easy to understand or not. They have zero impact on the final compiled code. The executable ends up as a spaghetti of machine instructions with countless gotos in a single large file.

Using bad ingredients in food, or poor quality materials in construction has tremendous impact on the final product.

>"Better is the enemy of the worse" is no excuse to have spaghetti code, or 50,000 lines of code files. It means that good is sometimes more convenient than perfect. Spaghetti code is not good to begin with.

Just calling code good or bad doesn't mean much - ultimately, results matter - if your code doesn't have tons of bugs, if your team can add features without any problems, if you can ship reasonably on time, if your product delivers value to the end user, etc - then you have succeeded. It doesn't matter what outsiders think about the code or what labels people give. Its best to ignore them and continue doing good work.

If you're writing code that controls radiation therapy machines or trains or autoclaves or something, yah, maybe there should be some regulation and potential jail time for negligence. But 95% of all software written (especially if it's the first version of new software) isn't life or death. If the next social media startup or saas-for-painters is spaghetti code it's not going to hurt anyone.

Failure is cheap in our industry. That's largely a very good thing.

No, that is not the restaurant industry version or the construction industry version. You can't possibly compare "good practices" in software with building codes and food safety regulations. Building codes and food safety regulations are based on facts, science, and decades of experiences. Good practices are rooted in ideology, hype, and not based on facts. There are no studies showing that "having tests helps". There are no studies showing that "splitting code into multiple files means that you'll have a better end product". And experienced people (like in this thread) even say that there is often not that much correlation between how code "looks" and how well it works.

> Good practices are rooted in ideology, hype, and not based on facts.

That is a really sad statement that is predicated on the assumption that nothing can be objectively compared and therefore nothing can be ranked, which is also a way to kill arguments that lead to innovation and iterative improvement.

You can measure the complexity of an algorithm, you can measure the cyclomatic complexity of a function, you can measure code in terms of length, you can count references to external functions or modules, etc.

There are many ways in which you can compare code and make decisions about what style is more convenient for your team.

What is clearer for you to understand?

a) 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1

b) 12

If your argument was true, they would both be the same. We both know that a) is a waste of time.

Your example is oversimplifying the problem, I don't think you're proving anything here. I've used tools that calculate cyclomatic complexity, and sometimes they're a good indicator, and sometimes they aren't at all. You can measure the complexity of an algorithm, sure, but unless it comes with a real life benchmark, it's only part of the answer. Same with the length of the code, you can measure the length but it doesn't tell you much about how hard to follow is the code.

If you take any style guide, book about good practice, or stuff like that, you'll find that there are some good ideas, and there are some bad ideas. Even with something as simple as code formatting, we still don't know as an industry if it's better to format everything the same, or use formatting to convey information. The debates about OO, FP, static/dynamic typing are endless and there's no evidence about which is better. There is a rough idea that you need more organization when more people work on code (static types, microservices, more documentation, more isolated parts), but even that isn't really clear.

My assumption is not that "nothing can be objectively compared and therefore nothing can be ranked". It's not even an assumption, it's what I've seen in this industry: we lack data to give objective good practice that go beyond anything trivial ("try to make code easy to read and simple", "give meaningful names to your variables"). There is a wide gap between "common sense" and "cargo cults", which is the gap between easy and complex topics. I would really like if in the last 50 years we had learn a lot about how to build software as an industry, as people. The reality is that we haven't.

We cannot objectively determine what is a good sandwich length therefore we should eat 1000 mile sandwiches.

I think your examples are unfair. Getting stuck on needing the perfect architecture is closer to scrapping a building plan because it wouldn't hold up to a 2km asteroid strike than it is building something that will ultimately kill people.

Also all of your examples have wildly different impacts than a dev "portfolio project". They all cause physical harm to people, which a poorly coded website/cli tool/etc almost certainly won't. Unless this person's hobby is writing code for MRI machines, in which case, go ahead and make everything is perfect, but that doesn't seem to be the case here.

Basic hygiene when cooking is not perfectionism, and is not only done at elite restaurants.

Dismissing basic development good practices as "perfectionism" is just gaslighting people into believing that any form of thinking is overengineering.

> Basic hygiene when cooking is not perfectionism, and is not only done at elite restaurants.

Ok, so let's continue this analogy on the other one.

It's less like basic hygiene, and more like refusing to cook outside a clean room.

> Dismissing basic development good practices as "perfectionism" is just gaslighting people into believing that any form of thinking is overengineering.

Basic development good practices are something you develop during the "portfolio building phase", not before.

There's being uncharitable and then there's this.

Your entire point rests on a baseless assumption. There's absolutely nothing in the parent's post that indicates that the programs he would create could have the potential to harm humans.