Good abstractions are important for the code to be readable. An AbstractEventHandlerManager is probably not a good abstraction.
The original commenter said that their code was "generic with lot of interfaces and polymorphism" - it sounds like they chose abstractions which hindered maintainability and readability.
I do, and whether I have a good time depends on whether they have written their code well, of which the book's suggestions are only one metric.
Just because open source AI is not feasible at the moment is no reason to change the definition of open source.
Are the petabytes of training data included in the repo? No? Then how could it ever be called open source?
At best, some of the current AI can be called freeware.
If you're just including the trained AI itself, it's more like including a binary, rather than source.
You can't really modify Llama in a significant way, can you? You can't fork it and continue improving that fork.
I'm fairly sure the crouch jump is part of the Half-Life 1 tutorial level.
I think that would depend on the skill of the developers and the resources they are given.
A lot of us are only ever taught to be code monkeys and those would probably not naturally gravitate towards true agile practices (which most, I would argue, have never actually seen in a real project).
Another problem is a lack of access to domain experts, which is also crucial.
However, my current project doesn't have any managers, or even business analysts, there's only the developers and the Product Owner. We have access to some domain experts and we work with them to build the right thing.
It's going great and the only problems we are facing are a lack of access to the right domain experts sometimes, as well as some mismanagement in the company around things we can't do ourselves (like the company Sonarqube not working and us not being allowed to host our own due to budget constraints).
In conclusion, I think part of the problem is educating software developers - what true agile is and what the industry best practices are (some mentioned in my previous comment). Then you give them full access to domain experts. Then you let them self-organize. Basically, make sure you have great devs, then follow the 12 Principles of the Agile Manifesto to the letter and you've got a recipe for success.
Otherwise, results may vary a bit, as I think many would tend to continue doing the Fake Agile they were taught and continue producing the poor quality, untested code they were taught to produce.
First part of the article sounds like what I'd expect.
The second part makes me wonder if this research was sponsored by some company which provides "Prompt Engineering" training.
I have never, in my decade as a software dev, seen a role dedicated to "making sure unit tests stay functional, meet standards and fixing them". That is the developer's job, and the job of the code review.
The tests must be up to standards and functional before the functionality they're testing gets merged into main. Otherwise, yes, you may actually need hundreds of engineers just to keep your application somewhat functional.
Finally, 30 engineers can be a vast breadth of knowledge.
Why aren't LRG releasing all these classics on GOG?
It's no less possible than for the tooth fairy, or Santa Claus to exist.
That's a straw man, as I never argued that there were no western influences.
It's at best naive to think that only western influences led to atrocities, though.
In my experience LLMs do absolutely terribly with writing unit tests.