At least for Casey his case is less that everyone should be Carmack or Abrash but that programmers often through their poor design choices prematurely pessimise their code when they don’t need too.

The argument made there is that "software quality" in the uncle bob sense, or in your domain version, is not necessarily wrong but at the very least subjective, and should not be used to guide software development.

Instead, we can state that the software we build today does the same job it did decades ago while requiring much vaster resources, which is objectively problematic. This is a factual statement about the current state of software engineering.

The theory that follows from this is that there is a decadence in how we approach software engineering, a laziness or carelessness. This is absolutely judgemental, but its also clearly defended and not based on gut feel but rather on these observations around team sizes/hardware usage vs actual product features.

Their background in videogames makes them an obvious advocate for the opposite, as the gaming industry has always taken performance very seriously as it is core to the user experience and marketability of games.

In short, it is not about "oh it takes 2 seconds to startup word ergo most programmers suck and should pray to stand in the shadow of john carmack", it is about a perceived explosion in complexity both in terms of number of developers & in terms of allocated hardware, without an accompanying explosion in actual end user software complexity.

The more I think about this, the more I have come to agree with this sentiment. Even though the bravado around the arguments can sometimes feel judgemental, at its core we all understand that nobody needs 600mb of npm packages to build a webapp.

[0]: https://www.youtube.com/watch?v=ZSRHeXYDLko

I think that's an overall good summary of the crowd's attitude. They think that mainstream programming environments err too far in the direction of keeping your software from being buggy, charging programmers a heavy cost for it. Undoubtedly for videogames they are correct.

Jai in particular does support array bounds checking, but you can turn it on or off as a compilation option: https://jai.community/t/metaprogramming-build-options/151

Obviously, this assumes you write enterprise grade code. YMMV

(The answer btw: Because nobody would be able to explain to a jury/judge that 80% or whatever is enough)

Key word is ‘can’. And it takes far more time and money to assemble “quality” team.

The quality of your team is more-or-less a pre-existing background variable. The question is whether a team of comparable quality takes longer to produce quality software than hacked-together software, and the answer appears to be "yes". The only way out of this is if optimizing more for code quality *actually helps you recruit better engineers*.

I can put a little data to that question, at least. I run a recruiting company that does interviews, so we have data both on preferences and on apparent skill level.

I went and split our data set by whether an engineer indicated that emphasis on code quality was important to them. Our data suggests that you can probably make slightly better hires (in a raw technical-ability sense) by appealing to that candidate pool:

- Candidates who emphasized quality were slightly (non-significantly) more likely to pass our interview and,

- Candidates who emphasized quality were slightly (non-significantly) less likely to have gotten a job already

The effect is pretty small, though, and I doubt it outweighs the additional cost.

This is traditionally not only with software, but other kinds of companies too.

Some people are just not quality people.

At this conference there's a presentation encouraging "You should finish your software."

If that's all people did that would be 10x better right there.

I’ve converted people by building better systems than they’ve seen before. Some balk, but better than half end up getting it and pitching in.

It that were always the case we could bask in the joy that the problem sorted itself out, but alas, there's a lot of crap that keeps on going.

Ouch. It seems that when a manager sinks some team's velocity by adding a bad developer to it the following reaction is always to add more bad developers so the velocity recovers.

And then when they can't herd all the bad developers around, the obvious next step is to finish destroying everything again by imposing some strict process.

The argument here isn't "the goal of a software engineering job isn't economic", it's "sometimes quality is aligned with economic goals" (which is of course true).

If there's a 10-point scale from 0 = the most hacked-together nonsense and 10 = perfect formal proof of correctness, I'm arguing that a lot of engineers should come down from a 9 to a 6, not to a 0 (or at least, that they'd benefit from picking their battles about when to argue for a 9).

In business contexts, I often argue the opposite, trying to move them from a 3 to a 6, because nontechnical people often underestimate the importance of tech debt. That's not a typical problem on HN, though.

Do they? I’ve been fighting against the tide for years until I understood that all of quality this and quality that doesn’t matter. Sure, it sucks to be on the receiving end of buggy software, but this where you vote with your money. At work? Finish the task with least amount of resources and move on.

I think it’s like switching CEOs when the company goes out of startup mode into grownup company. What got you here won’t keep you here.

If you're working at a company who disregards safety and security good luck getting them to care about clean code and efficiency.

Yep, preemptively destroying the reputation of whoever opposes you is a common and ancient tactic of bullies from all levels, from school patios to fascist governments.

Look at the people who are pushing for politicizing software development, and you'll see they are always getting money out of the deal.

You can find some kind of objective metric, e.g. bug count or time spent developing new features. That alone is super hard to get right, but even if you could, it wouldn't necessarily tell you which techniques lead to a better result. People have tried studying such things (e.g. do static types help) and the studies rarely come up with any effect.

I don't think that's necessarily because these things don't have an individual effect, but because there are humans involved and so, personal ways of thinking probably play an outsized role, so technique X might be a very good fit for person A, but not for person B.

Anyway, you could analyze my comment and reply. That's what I did with yours. Perhaps you could call my apparent bluff and challenge what I claim to know about epistemology. Maybe you're having trouble doing that because analysis wasn't how you arrived at your own opinion? You were expressing an ideological position that you inherited from-- I'm just guessing-- one article about Six Sigma or TQM that was 30 years old?

I read Quality Without Tears, by Phil Crosby, in 1987, that expressed much the same attitude as you just did. I've had a lot of time, since then, to become educated and experienced in these things.

Yes and I gave you that definition in the first part of my response. That someone in the semiconductor industry made a poor and colloquial choice of words when he confused qualitative and quantitative processes, (the hardware industry deals with the latter), is not evidence to the contrary.

When people talk about software, they're using the terms appropriately. We can objectively talk about the quantities attached to a software. Number of dependencies, size, startup time, what have you, but two people will never necessarily agree on the quality of software, your high quality software might be junk to me, because that is at its root a subjective judgement. There is not a lot of qualitative or subjective judgement in the world of elementary hardware (it either works or doesn't), there is a lot of it in end user software.

It is very difficult to make a bad piece of hardware that does very well on a number of metrics, it's very easy to make a shoddy piece of software that performs well on an infinite number of metrics, because nobody has a subjective experience with a transistor but they do with a piece of software. That is why you should use the terms correctly and not apply processes from one domain to the other.

Yet people throw around the term "engineers" with reckless abandon for seemingly anyone that wrote Javascript once in their lives. It all strikes me as very silly.