“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

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.

great coders ship.

You’re ostensibly arguing the same thing I am though. Focusing on building the thing rather than designing the code to look pretty.

I was thinking of sport players that have their stats laid out as a radar chart. One might be average on defense, but a world class striker. Is he better than a world class defender but average striker? And even that is a convenient and lossy approximation.

https://en.wikipedia.org/wiki/Radar_chart