The Zen of Parallel Programming(smolnero.com) |
The Zen of Parallel Programming(smolnero.com) |
I'm genuinely considering that this is just a foreword and I missed the clickthrough link to the meat of the article.
The article makes a lot more sense if you've practiced Zen.
Think of it as someone's way of making sense of Zen teachings by related them to something they already understand.
The "about" section of the website is equally vacuous:
SmolNero is a philosophical startup rooted
in first-principles thinking.
We explore how humans relate to technology—
how we speak to it, depend on it, thank it,
and sometimes forget it’s there at all.
We don’t claim expertise. We see ourselves
as translators—working at the crossroads of
emotion and programming, curiosity and care
(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"
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
To people who say "You don't need scalability" I say "You also don't need unscalability..."
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.
One subject matter expert visionary
One technical architect visionary
One or two technical masters
One or two UI/UX masters
One or two padawans capable of becoming a master
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.
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.
"Zen Mind, Beginner's Mind" makes more sense in a group setting. I read extracts of it with a Zen priest in a meditation group.
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.
Edit: aaaand I hadn’t read the article
When you're dealing with multiple platforms, or hardware accelerators, or mostly all of economically relevant shit in the AI era you don't get a small, clean, fast build.
Fable can't print a Tauri faux-native app without dragging in half of LLVM.