> If your goal is to take over the market quick, as many here would like, maintainability is a very low priority aspect of your code base.
Is it? How long do you expect to keep your momentum after "taking over the market"?
Anecdata time. I once joined a 3 year old project that had ground itself to a near halt with this philosophy. The project's lead seemed almost allergic to the word "refactoring". It had accrued so much tech debt that I was the third "new guy" to join in less than two years, after the previous attempts to hire had successively faltered within 6 months, because my predecessors couldn't deal with the unmaintainable mess. I made it to 9 months.
Maintainability is not tied to OOP or functional, but rather to how much a team cares to manage the cognitive load that comes attached to having to deal with the code base. When that becomes a genuine priority, the code tends to be written with concern for the next human mind's ability to interact with it. And when it makes sense in that one pursuit, functional, OOP, DRY, WET all become valid -- even seductive but toxic affordances like inheritance can sometimes be useful in the right context.
So one of my thoughts is maybe AI makes this more viable. You continually refactor the code base. Often when you start something you do not know the correct abstractions anyway - so vibe-code it.
Then once you have the kinda-sorta prototype, do a full rewrite, try to do component modules with interfaces.
(maybe do multiple rewrites depending on architecture complexity)
Then incrementally improve the software quality of each of the components.
---
My thesis in this is that the cost of a refactor has dropped precipitously, LLMs are really good at doing translations, and are pretty good at finding good abstractions if you work them a bit. It is also much faster, becuase in your refactor you try and focus on the big picture and interfaces, and yolo the components... Make sure that they work, but if there is a particular edge case you can fix it later.
I don't know for sure, but I am testing this out and am halfway through a rewrite of a large project into rust from c++ (second step from above) - I am mostly vibe-ing the components, But am paying a lot of attention to the interfaces and layout.
This is what I've observed too in actual real life.
Massive refactoring operations that would've never been scheduled, because they would've needed a senior programmer allocated to it for at least a week can now be done to ~80% completion with a good prompt and an LLM in an afternoon.
then the senior dev only has to spend maybe a day or two in the final 20%, mostly confirming that nothing was missed.
>How long do you expect to keep your momentum after "taking over the market"?
A few years making millions is more than enough for leadership to be satisfied. Even if everyone underneath simply has broken dreams and an increasingly unstable work style. I guess in that lens the company "succeeded" compared to those who did things right and never took off.
It's the same thing as the "oh no, we need to figure something out for our youth on the verge of obsolescence" narrative. It's all about giving an impression of unfathomable power. They don't care that in actuality, the tech will end up as just an augment, not a replacement for said youth.
> I can’t conceive of the leadership of the Python or Rust or any other community I’ve ever worked with doing something like that.
I'd be prudent to use a clear faux-pas by a BDFL as an argument to push for an alternative, seemingly more consensual, leadership style. I'd also be careful to fall for the apparent lack of overt aggression in the latter type of structures, as a necessarily positive signal. I've seen people in various such communities (including the two cited languages) that have chosen not to interact with their steering committees, because of perceived toxicity.
This can and does happen with any kind of structure and can take many shapes, some of whom are too subtle or passive to even accurately pinpoint, in the way you would for example directly index a BDFL. In The Tyranny of Structurelessness Jo Freeman made the case that the lack of a clear structure in the make up of a movement presents with opportunities for very fuzzy power dynamics and related abuses that are also much more challenging to deal with.
Yeah, I don’t mean to detract from the serious communication issues that other ecosystems have.
(I don’t think committee/unstructured/BDFL communities do better as a rule, it’s more about the culture that’s promulgated by whoever is at the top, regardless of how many of them there are.)
As entertaining as that article was when it came out, I think its apparent wisdom should have been reevaluated for at least the past two decades. Even back when it was written, its pertinence was questionable, since it hinged on the perception that written code has particular value, to justify much of the failures at Netscape and Borland, neglecting many of the other -- probably more relevant -- business and human factors that were at play within the two organizations and their surrounding ecosystems. But lessons learned from watching startups fail in trove in the following two decades have mooted many of Joel's arguments. With the vantage of hindsight, if you read JWZ's account of what went on at Netscape, some of the dysfunctions become glaring.
Making software projects successful has always been about a lot more than just writing code. People have been "rewriting code from scratch" successfully even before LLMs. We just don't tend to call it that. We call it "cloning", "competition", "copy", "alternative-to", "reverse-engineering", "x-written-in-language-y", etc.
Short publication intervals. That's the heuristic you're going with? I have dozens of such unpublished long form articles on fundamental topics, just waiting for me to carve some time to polish. I expect that on a sabbatical I could finish and post them in quick succession. It's an unreliable indicator to determine AI-writing.
Being dismissive is one way to think yourself "better" than others. But on HN hastier reactions tend to be outright negative or out of context with long articles, as eyeballs actually evaluating the content will take some time before providing constructive criticism.
How were you able to pick this up? Not challenging your assertion. Just really curious. Can you point to some clues? I read it (with my own eyes). I can't see actual evidence the text itself is artificial or at least, that it is not human-curated.
Ignorance will always be a better starting point for discovery than wrong assumptions. If you leave comments, they must reflect what the code is actually doing. If during edit it's no longer the case, at least mark them as stale. The next best thing is indeed to remove them.
The article had great advice on this actually. When asked how to get into C, or whether it was more advisable to learn Zig instead, Mitchell suggested that
It’s more important to learn how computers work and make the language just a means to understanding how they work. [...] even in this age of higher level abstractions and web development, it’s still important to understand the basics of CPU scheduling, memory, cache hierarchies, file systems, disc and file access. When you work directly above the syscall layer, whether in C, Zig or Rust, it really helps you understand what’s happening[...]
> If this is the ideal model, why don't authors skip the middleman themselves and just put the .pdf/.epub on their website directly in exchange for donations?
> On the same note, why do game devs need to give Steam 30% of their money and not just sell to the public directly and pocket the 30%?
We're needlessly making this into a general problem. Why hastily discuss ideal models? The current model is fine and the issue isn't generalized. We're talking about having the option to skip asshole middlemen, or to be more specific, Amazon. A company so big that solving this special case on its own leaps us a huge portion of the way into solving the problem at large.
Is the general sentiment that Steam is also an asshole?
Is it? How long do you expect to keep your momentum after "taking over the market"?
Anecdata time. I once joined a 3 year old project that had ground itself to a near halt with this philosophy. The project's lead seemed almost allergic to the word "refactoring". It had accrued so much tech debt that I was the third "new guy" to join in less than two years, after the previous attempts to hire had successively faltered within 6 months, because my predecessors couldn't deal with the unmaintainable mess. I made it to 9 months.
Maintainability is not tied to OOP or functional, but rather to how much a team cares to manage the cognitive load that comes attached to having to deal with the code base. When that becomes a genuine priority, the code tends to be written with concern for the next human mind's ability to interact with it. And when it makes sense in that one pursuit, functional, OOP, DRY, WET all become valid -- even seductive but toxic affordances like inheritance can sometimes be useful in the right context.