7 ms·

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 po

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. The beauty of the architecture is the ability to build a spaceship compared to a train of kerosene tankers. Physically similar, but in capability radical different. 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 literally the difference between rocket-science and exploding failed projects. Everyone can pile up explosives, not everyone can go to space today. Its a great interview topic to filter this kind of candidate out of companies.

MomsAVoxell 4mo ago
“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 ..
hnlmorg 4mo ago
> 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/ 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.
- brunooliv 4mo ago
  Thanks for saying this! I completely agree with everything you said! There’s far, far too many people who confuse code quality for speed of development and start treating code quality as the product for customer base in the hundreds and active customers in the dozens and for most features to be basically unused. The reality is that tech debt as a concept these days is hardly real: to be in debt means previous decisions or a previous implementation makes current work extremely hard or impossible, but, the truth is that the human factors such as knowing what to build, team collaboration and even speaking to customers matter far more and can get you “in debt” so so much faster than code alone. At least in your typical SaaS company. If you ship code in a way that you let tech debt pile up to the point that customers notice it, you have an organisational problem, not code issues per se. The fact that a lot of people don’t get this is really baffling to me.
  - nandomrumber 4mo ago
    [dead]
  - 21asdffdsa12 4mo ago
    Im talking about the speed of mental model building, understanding concepts, relations and organizational concepts. Good codebases sort of read themselves. You can guess where things are, how they are sorted and how they work, by understanding and relying on the authors ideas.
    - hnlmorg 4mo ago
      “Good” code makes trade offs. While readability is an important constraint, it’s far from being the only constraint. And there are plenty of occasions where objectively better code is subjectively harder to read because other constraints trump human parserability, such as using CPU-friendly memory layouts, SIMD-instructions in tight mathematical loops, and so on and so forth. Not to mention that readability is entirely dependent on the readers familiarity with particular coding styles. Eg someone unfamiliar with SQL would find ORMs easier to read, whereas I find SQL easier than ORMs. Same is true for any other paradigm, eg for functional vs imperative. And this is why I hate when people generalise about human readability being the definition of “good code”. For one thing, there will never be a consensus on what is more readable. And external constraints might require subjectively less readable code.
gpderetta 4mo ago
great coders ship.
FpUser 4mo ago
>"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
pjmlp 4mo ago
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.
jongjong 4mo ago
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.
overfeed 4mo ago
> 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.

MomsAVoxell 4mo ago

“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 ..

hnlmorg 4mo ago

> 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/ 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.

brunooliv 4mo ago
Thanks for saying this! I completely agree with everything you said! There’s far, far too many people who confuse code quality for speed of development and start treating code quality as the product for customer base in the hundreds and active customers in the dozens and for most features to be basically unused. The reality is that tech debt as a concept these days is hardly real: to be in debt means previous decisions or a previous implementation makes current work extremely hard or impossible, but, the truth is that the human factors such as knowing what to build, team collaboration and even speaking to customers matter far more and can get you “in debt” so so much faster than code alone. At least in your typical SaaS company. If you ship code in a way that you let tech debt pile up to the point that customers notice it, you have an organisational problem, not code issues per se. The fact that a lot of people don’t get this is really baffling to me.
- nandomrumber 4mo ago
  [dead]
- 21asdffdsa12 4mo ago
  Im talking about the speed of mental model building, understanding concepts, relations and organizational concepts. Good codebases sort of read themselves. You can guess where things are, how they are sorted and how they work, by understanding and relying on the authors ideas.
  - hnlmorg 4mo ago
    “Good” code makes trade offs. While readability is an important constraint, it’s far from being the only constraint. And there are plenty of occasions where objectively better code is subjectively harder to read because other constraints trump human parserability, such as using CPU-friendly memory layouts, SIMD-instructions in tight mathematical loops, and so on and so forth. Not to mention that readability is entirely dependent on the readers familiarity with particular coding styles. Eg someone unfamiliar with SQL would find ORMs easier to read, whereas I find SQL easier than ORMs. Same is true for any other paradigm, eg for functional vs imperative. And this is why I hate when people generalise about human readability being the definition of “good code”. For one thing, there will never be a consensus on what is more readable. And external constraints might require subjectively less readable code.

gpderetta 4mo ago

great coders ship.

FpUser 4mo ago

>"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

pjmlp 4mo ago

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.

jongjong 4mo ago

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.

overfeed 4mo ago

> 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.