ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
55% Positive
Analyzed from 1238 words in the discussion.
Trending Topics
#more#zen#don#problem#article#technical#between#project#where#here

Discussion (26 Comments)Read Original on HackerNews
I'm genuinely considering that this is just a foreword and I missed the clickthrough link to the meat of the article.
The "about" section of the website is equally vacuous:
(The two M-dashes are also suspicious)It's not often I comment on blog posts, but this is honestly one of the most meaningless blogs I've ever read (not counting those fully AI-generated SEO ones). I don't get why it ended up so high on Hacker News; it has an interesting title I guess, but pretty much no substance.
"Everything we've looked at so far is a technical problem. Compared to organizational problems, technical problems are straightforward. Distributed systems are considered hard because real systems might drop something like 0.1% of messages, corrupt an even smaller percentage of messages, and see latencies in the microsecond to millisecond range. When I talk to higher-ups and compare what they think they're saying to what my coworkers think they're saying, I find that the rate of lost messages is well over 50%, every message gets corrupted, and latency can be months or years"
- from https://danluu.com/sounds-easy/
To people who say "You don't need scalability" I say "You also don't need unscalability..."
I’ve enjoyed reading the comments here and I think there’s truth in how the technical problem is divided and teams are arranged. The idea of frequency of features (or builds) being a reflection of our division of the problem, is interesting. It made me think about our teams trying to ship releases and the problems arising, but zen and parallelism don’t give any hints. It’s just about effort to organise better, like it always was
In my experience with more than a couple dozen software projects, the ideal team size to successfully deliver a non-trivial effort is between five to nine people.
Staffing exceeding the above for an individual team is more a managerial genitalia contest than anything focused on organizational success.I've been on projects where everybody needs to know everything, and on projects where many groups can be insulated from others.
The more your group can work without needing a meeting with other groups, the more things can progress in parallel.
Some projects won't work well with that constraint though. And some organizations won't either.
Edit: aaaand I hadn’t read the article
But it's secondary.
The wall is build. If you can AI program, your problem is the build is too slow, too unreliable, not secure enough from a supply chain standpoint.
That is where one competent senior hacker tops out today. The agents are yielding to a CI that gets 35% per-vCPU occupancy.
The wall right now is skill or build, depending on your skill.
To the people wondering the meaning of the article, it's I think this.
I like the part about synchronization and honesty. And I'm certain every time I get annoyed that someone is not as open with me as I wish they were, there is a part in there that myself contributed to that.
A good example is game theory and game semantics. The term "actor" in this context are soo abstract that we can pretty much attempt to implement them anywhere we see fit and that I think is the beauty.
She proved that he made a trip to a town where the monk lived after his return, and the library contained a copy of his reports. She could not prove more than opportunity but she strongly suspects that Hume not only read the report but may have met with the monk as well.