41–50 of 308 posts
It's really great to see when someone who is totally honest with themselves and what sparks joy in their life/career, and is also respectful to all the people who depend on the work/artifact. So much respect.
Thanks again.
HN hugged to death. Here's the snapshot on archive: https://web.archive.org/web/20200630130517/http://antirez.co...
On one hand, it’s sad that they’re leaving, and/or that circumstances made the job less enjoyable than it would otherwise be.
But on the other hand, I cannot help but be happy for one who has thrown off the chains and is now free to pursue their dreams again.
Best of luck wherever life may take you!
I would love a story on "I don’t like much what the underground programming world became in recent years" What could he mean? What underground programming world is he talking about?
Dang. I say this frequently both online and when discussing system design with newer devs, but will repeat here: of all the production issues I've debugged, the culprit has has never been redis. In fact, redis has been a critical piece of achieving cost-effective scaling. It is one of only two pieces of software (along with postgres) that I blindly recommend without any caveats. From following along here and on your…
In any case, I've had the same experience with only two programs - CouchDB and Redis.
I’m at a similar point in my life, though of course I’m much less influential than him. I’m getting to the end of the most stressful and most important part of my career, with no desire to do something similar again, without a clear idea of what’s next.
There are plenty of problems with BDFL-style projects, but I think there are a lot of advantages too. Redis is unique in my experience in that it works the way you'd expect - it doesn't cause outages, it is fast, and it has a vanishingly small number of gotchas. The feature set is well curated and for the most part fits together cohesively.
The most important thing Antirez did, in my opinion, was to say "No" to things. No to new features that didn't make sense. No to PRs that didn't fit the vision. Saying no is one of the most important jobs of a project maintainer. It's a thankless task that upsets a lot of people. But it's critical for a project to stay successful and achieve the leader's vision.
Maybe I'm a pessimist, but I predict after a few years of this new model we'll see weird features, more stability issues, and performance regressions as more cooks enter the kitchen. Time will tell.