> But the code quality is speed. And reach. You can not advance, unless you can read the code, you can understand the model, you can not scale beyond a certain point

Other people can do the important work of investing time to understand the model and simplify the code architecture, as proven many times over by actively maintained projects pioneered by Fabrice.

To kickstart a project, you have to show people that something they assumed impossible or hard to achieve is actually possible by dropping it in front of them.

> Its a great interview topic to filter this kind of candidate out of companies.

Fabrice Bellard ships. It makes sense to filter him out if you're a bank or an org with well-established products that prefers stability over velocity. If you're a start-up or have lots of greenfield projects requiring fast experimentation loops: you need folk who can ship quickly. Most organizations have a mix of projects and need a healthy mix of engineers, or ones who can flip modes relevant to the project.

Companies outside software as a product rarely care that much about what their physical goods are processed by IT, this is how you get outsourcing and offshoring of most of their computing needs, they won't care one second to filter such candidates.

> But the code quality is speed

No it’s not. Code quality is just code quality. It's a subjective measure. eg how do you define one thing is of greater "quality" than another? Is it CPU ops? Memory footprint? Code readability? And how do you measure readability? By who? What I find readable someone else might not, and visa versa.

If you’re making choices to improve development throughput then that’s fine. But so often I see developers architecting code for what they mistakenly think will improve their throughput but ultimately they spend longer on writing those abstractions than any time they have saved when using them.

XKCD parodies this problem with their pass the salt sketch: https://xkcd.com/974/

Sometimes this comes down to developer vanity, sometimes it comes down to poor alignment of goals and/or communication between the product teams and development teams. And sometimes it’s just because solving problems is fun so naturally we’ll look for problems to solve. But whatever the reasons, I’ve personally seen this happen (as well as being a victim of it myself) enough times to know it is an underestimated problem.

> I find this very scary. Somebody unable to perceive capabilities and tech-debt. If you can not perceive that- you should not be let near executive decisions or code-base evaluation.

This is a rather insulting assumption. I've been a tech lead for around 2 decades now and have worked on plenty of brownfield projects in that time. I know what tech debt looks like.

The problem with "tech debt" is it can mean anything from "this is ugly code that takes 5 minutes longer to read but it works well" to "this in a insecure/unstable pile of horse manure and customers will start to notice".

The latter is where time should be spent. The former is a vanity project that doesn't bring the business any value.

That's not to say that developers shouldn't ever spend time on the former examples of tech debt, just that it's of a lower priority than getting the project working.

I agree with this for complex problems which cannot be vibe coded with AI. So definitely it's an essential skill for any human engineer.

“You can read the code”

.. is very, very important in the context of milliseconds, hours, days, weeks, months and years. And decades.

Today, you might say that John/Fabrice’ code is readable/unreadable, but will that also be true in 5 years time, in a different cultural/technological era?

Obviously yes in the case of these individuals - because the ecosystem their products have created is self-sustaining at a mass (consumer/social) level.

I’ve built software which has shipped and effected the lives of millions, too. Many of us have.

But I have not built a massive ecosystem by working on the right software which was adopted by millions of developers who read my code, was inspired by it, and used it for something in their own products - thus creating sub-ecosystems upon sub-ecosystems, a big sprawling tree of economy which spreads out into the mass of humanity who use technology.

In this story we have two cases of individuals who have accomplished an extraordinary reach of software, in their own uniquely flavored ways - and this demonstrates that there are no absolute requirements to strip personality from the code - as long as its damn good code in the first place.

>filter candidates out of companies

It’s a great way to decide not to work at a company which managers do not understand the importance of architecture at various scales, milliseconds, seconds, hours, days, weeks ..

>"But the code quality is speed. And reach. You can not advance, unless you can read the code"

I am not sure about "proper" definition of spaghetti code but speaking of long functions: if it is straight code that reads like a book and has no common parts to refactor for further reuse it is actually way more understandable and debuggable then mess of 3 liners spread among 20 files and 10 microservices running under k8s.

>", you can understand the model, you can not scale beyond a certain point"

The needed scaling is being determined by business needs / projection. If you implement service for some SMB that deals with few partners and limited set of business entities in database and architecture of said service addressing Google style of scalability with corresponding overheads and costs you are definitely committing a crime in relation to your client.

>"Its a great interview topic to filter this kind of candidate out of companies." -

basically making sure that instead of pragmatic engineer who can deliver functional and serviceable product to client in reasonable time with reasonable costs you will have them pay for spaceship built by architecture astronauts

great coders ship.