Redis Core Team Update
redislabs.com
redislabs.com
this usage is definitely uncommon/archaic
https://www.mentalfloss.com/article/56865/why-does-terrible-...
You can be confident that you won't need that definition in your own usage unless you decide to write an 18th century character or something.
To add to the etymology links (I was also intrigued):
https://www.grammarphobia.com/blog/2013/08/terror-terrific.h...
https://genius.com/Herbert-morrison-hindenburg-disaster-broa...
This posting [1] puts the usage change from around 1880-1930. I've always taken the modern usage to mean unusually fine/magnificent.
[1] https://english.stackexchange.com/questions/38606/what-gave-...
but like you say, these aren't nobodies. However, I am curious to see how the pace will change (if at all), with you no longer doing the lion share of work.
I've studied software metrics for quite sometime and they are widely despised by developers, because they are
a) not useful for developers
b) never put effort into context that can be discussed, vetted and refined.
What I'm trying to do is fix the stigma associated with software metrics, by focusing on how they can be used by developers. For example, code churn metrics can be used in a positive way for developers as the following example shows:
Without looking a single line of code, you can estimate the impact each commit will have, which can be useful for domain experts, team leaders, etc.
I'm hoping to have a version of the product that people can install via docker or on bare metal linux by the end of this month.
Good points about software metrics. I'm not a big believer in them, either. I think the most useful metric I've ever needed or been able to use was in one case where I needed to see a developer's contribution activity. Looking at a specific developer, aggregated across a Github organization, it was clear they were just not doing much work!
Hoping you'll post a "Show HN" when you release.
Actionable software metrics is extremely hard to create, which is why we are often left with VERY LOW hanging fruit metrics or novelty metrics, as I like to call them. I honestly believe we are at a point now, where hardware is cheap and good enough, that we can generate very meaningful software metrics.
With GitPrime having sold for 180 USD in cash, and with GitHub and GitLab both investing in software development insights, there is a clear sign that managers and business leaders want to know what is going on. Unfortunately what we have now, in my opinion, borders on snake oil, which I'm hoping to use to my advantage to contrast my solution with others.
> Hoping you'll post a "Show HN" when you release.
Great, I'm looking forward to your upvote as getting traction is really hard :-)
Kind of a strange thing to call out.
Can't blame him for being proactive about nipping them in the bud.
It wasn't even a particularly new observation when South Park literally named a character after it almost 25 years ago.
(Probably many of the same people getting labeled that way for holding high-level positions today were similarly judged in their entry-level positions back then! But if people are no longer suspicious of women or minorities in "regular" roles and resume their judgement for upper-level roles, I guess that's a change in the right direction, at least. :| )
https://techcrunch.com/2020/06/05/alexis-ohanian-steps-down-...
https://www.nytimes.com/2019/12/17/us/california-boardroom-g...
This isn't new news. Diversity hiring and promotion is all over, alongside the recent BLM relevance.
So claiming that it's a phenomenon of just the last decade as a way to justify suspicion of merit is very bizarre. Where have you all been?
The pressure on management to hire diverse candidates has increased 100 fold over the past decade.
The truth is that it kind of doesn't matter if it's new or not, it's a very hot subject right now and people are touchy about it.
I understand why; Women are facing a lot of abuse on the internet and it feels like many are coming forward with icky things that people have said/done.
On the other side it feels like there's been a cataclysmic overreaction- and many people get annoyed when we're asked to "make sure the next one you hire is a $under-represented" or getting overruled by HR when hiring otherwise.
(yes, this happened, and it was frustrating because the person we hired was not able to lead the project we needed and was hired anyway- she later left, burned out, nearly wrecked her career and I feel incredibly guilty for not being more vocal about it and keeping it mostly to myself for fear of being called a bigot)
I live in a third city in Sweden, in a slice of time that the company needed to find someone and we do not pay competitive wages.
I’m sure we could find someone qualified eventually and if we paid enough, and we have had good female candidates at other times albeit for different roles than this one, however they didn’t want to relocate.
Context being what it is, it takes us roughly 2 years to hire a new person to our team because people don’t want to live where we are or accept the rates we pay.
If you can actually attract people to your company, then asking that you hire at least half women shouldn't be an issue; there are plenty of qualified women for any position. If you can't attract people to the job generally, I think any other factors would largely be noise versus the real problem.
Application rates of women for our studio borders 8%, and our previous hiring rate of women was 8%; with aggressive affirmative action policies (mostly around marketing and bringing in female code academies such as pinkprogramming[0]) we have increased this to 12%.
You don't specify /why/ the job is less attractive, I stipulated primarily two reasons:
1) Location.
2) Salary.
You might agree that moving 700+ people is a little untenable.
My argument about salary is, and very much playing devils advocate for HQ: "We don't really care who does the job as long as the job gets done, if we can pay a man less, we should hire a man".
If you think about it this is just one more layer of discrimination people face. If you are in one of those categories, no matter how smart, competent, and worthy you are, many people will assume you didn't get there on merit, and that you took the job from someone better. We ought to reject this.
Like, it's not quite as astonishing as a "government committee on women's health" in which every single member is a man, but it's getting up there.
Diversity is an attribute you want unless you've got some weird demographic quirk as focus for your organisation. Just as you shouldn't try to solve "Two is one and one is none" by just purchasing duplicate tools, but instead look to duplicate functionality, you want senior management (and hires throughout but this pattern matters most at the top) to each have a different range of skill sets and life experiences not just be carbon copies of each other. If the most notable difference between the senior management team is their golf handicaps then they are going to miss all the same opportunities so why are you duplicating their salary cost?
It stands to reason that there are going to be women (in particular) with the innate abilities you want, but with a different set of life experiences that are valuable. If your rivals won't hire them then it's even more likely you can find them available than their male counterparts.
Now, like a "Rust programmers, must have at least 20 years Rust experience" bogus requirement, if you hire based on what people already did, not what you assess they can do in the future then sure, you're going to conclude that there aren't many women, or black people, or whatever in a role that has not historically hired women or black people or whatever. But that means now you're bad at hiring people too.
The social and cultural shifts that would change this need years or even decades to play out before it stops becoming weird.
And, again, this doesn't mean middle-aged white men are just better or more suited for these kinds of positions – it's just that they've been in the best position, generally speaking, from an education, networking, and cultural position to get access to such positions in contrast to folks from a different background, race, or sex.
It's weird that Americans tend to cheerfully eat cow meat but not horse meat for example. Much of natural language grammar such as the adjective order rules in English - pretty weird ("My old blue hat" is OK but "My blue old hat" is wrong!). The fact that there are five Fermat primes but then no other Fermat numbers seem to be prime is weird.
Since when was hiring about innate abilities?
> if you hire based on what people already did, not what you assess they can do in the future
That’s literally how the majority of tech companies both hire and promote.
Good luck getting a promotion at Google (for example) based on potential.
If you can't help think it, it is probably because you believe it. If you look for excuse you will find one.
Maybe you could illuminate another forum with your wisdom.
So either your organisation is horribly sexist by not promoting these women or you are horribly sexist and think they are better because they are women.
Do you have another reason a developer 10x better than her peers isn’t promoted to senior, to principal, etc?
Fundamentally men and women have similar brain physiology, so an equal amount of compute and memory. Which would imply there are no differences when it comes to programming ability. It's just a matter of experience.
I'm glad HN doesn't have profile pictures and things.
THIS
It seems like, for one reason or another (Redis Labs because they want to sell their “core plus proprietary modules” service; the clouds because they want to push you to use their other products for use-cases that fit them better), all the new leadership has reason to want to not add any more developer-facing features to Redis Core. I expect the Redis Core you see right now, is the same Redis Core we’ll have 10 years from now, client-API wise. Redis, as a USP, is “done.”
Unless, that is, some third-party comes in with their own polished feature PR, and pushes really hard for it. In other words, Redis is kind of moving to the Linux kernel model, where “new use-case out of nowhere” features come in mostly not from internal development, but rather from external contributors petitioning the core-maintainership priesthood with reasons their patch should be upstreamed.
Either way, there’ll certainly continue to be plenty of ops-staff-facing innovations, bug-fixes and polish. That’s what gets this new core team up in the morning. I’m sure people running Redis in production are happy about that.
1. Those orgs succeed when redis succeeds. So they want to see it used more which means more features.
2. Developers think for themselves and aren't always "double agents".
3. The redis community still exists and open source communities are often very vocal about directing products
I don't think the situation is quite as binary as this suggests. Even assuming that developers are consistently doing what they believe is in the best interest of the project, their employers may benefit from being able to encourage them to consider the items which are the employer's priorities. Developers don't have unlimited time, and if they have to choose between two worthwhile projects and one of them is of interest to their employer, it's likely that's the one they'll spend time on.
I sympathize with the main points you were making, but surely ‘people running Redis in production’ are the core use case for Redis, so ultimately this move seems good for the project’s overall direction.
1. the kind that devops people directly see a need (usually a scaling need) to integrate it into a stack of existing production software; where this integration may or may not require additional development-time work (i.e. connector glue code in the business layer), but is either way an ops use-case. Examples: any caching layer, any message queue.
2. the kind that developers integrate with in order to get the semantic guarantees that particular kind of software offers; and then ops people are left "holding the bag", needing to deploy that same software (or something compatible with its wire protocol) in production because that's what the business logic was written to depend on. Examples: most databases; object storage; map-reduce workload engines.
Usually, it's pretty clear which bucket a piece of infra software falls into—either it's developers or ops people that suggest it as a solution, but rarely is a piece of software equally loved by both.
But Redis straddles the line between these usually-clear clusters of software. It can be a metrics-reactive "patch" to a running system to get it to scale better; but it can also be a development-time foundation for business logic, or a dependency of a library where it was a dev-time foundation for its business logic (e.g. any "background worker" library.)
In other words, Redis Core as a project, serves two masters: it must both be
1. a stable, scale-multiplying, worry-free daemon you can easily toss into your existing legacy infra;
2. a feature-rich "durable data-structure server", allowing developers to obviate the keeping of durable state in the app layer itself.
The new leadership certainly will care a lot about use-case 1.
I'm pretty sure, though, that the previous leadership (i.e. Antirez) cared almost exclusively about use-case 2—making developers' lives easier by taking durable-in-memory-state-management code they were writing, and replacing it with calls to Redis. That's why we didn't see TLS support and so forth for so long. Redis wasn't being built for ops people; it was being built for developers. Code that went into complex deploy-time use-cases, was only ever added by Antirez as a consequence of systems developed for Redis now depending on running it in production. (E.g. you don't scale Redis into a cluster; you develop for the sharding semantics of Redis Cluster, and so therefore you must deploy Redis Cluster. You can "upgrade to" Redis Cluster after-the-fact, but it's far harder than just writing your code to be "cluster-safe" at the start. It's idiomatically a development-time choice you're supposed to be making, knowing the eventual "scaling goal" of your system.)
Yes, the rest of the core team—mostly ops-focused engineers—gradually accrued around Antirez. That's why many of these ops-time use-cases did start getting addressed.
I'm mostly worried that now, with Antrirez out of the picture, the team is unbalanced in the other direction: there's no one on the core team pushing the "developer productivity" side of the story.
To me, that laser focus on developer productivity was what made Redis consistently the infrastructure component I would most want to integrate to solve a problem, if it offered a solution to that problem. I knew that "the Redis approach" would always involve just a library import, a connection URL instantiation, and one or two atomic Redis command calls; whereas other libraries might require me to write delegate modules, serializers, attach to special listener modes, etc. And I always knew I could just open redis-cli and prototype out those same commands against my local zero-initial-config-required Redis server; where other infra might require me to fiddle with everything from setting my own compile-time flags, to JVM memory-management, to Docker image volume mounting, etc.
I really just hope that the new leadership retains enough of the spirit Antirez has been injecting into Redis, that they'll reject PRs that solve ops use-cases but come at the expense of developer productivity (e.g. moving to entirely-async command execution, and then deprecating the text-based Redis wire protocol because it's hard to integrate its parsing into a Jepsen-correct threaded execution engine, or something like that.) Such features wouldn't hurt cloud deployments for existing Redis users at all, but they'd sure scare away new developers from finding new ways to replace business logic with Redis.
He was the heart and soul of the project.
It also makes me think, what would Linux be when Linus decides to step away? I kind of don't want to think about it.
Thank you to Antirez for all your hard work on Redis.
In just the last 90 days, he accounted for 50% of the code that is being changed in redis. I'm currently indexing the Git repository, as I'm curious to see the impact Linus had before he left, but I don't think Linus leaving, is anything like antirez leaving.
Sorry if this post comes of confrontational, as that is not its intention. I just don't understand what comparison you are trying to make.
> ... what would Linux be when Linus decides to step away?
Antirez, on the other hand, has had a large part in the continued development of Redis since it's inception, so like, 11 years or so (2009).
AFAIK, apart from UI improvements over the years, Git has _largely_ been the same since inception, in that you can watch a video as far back as e.g https://youtu.be/4XpnKHJAok8 and not much has really changed since those days (by the time Linus gave that prez, Junio already started running the project).