Hacker News new | past | comments | ask | show | jobs | submit login
Redis Core Team Update (redislabs.com)
102 points by itamarhaber on July 9, 2020 | hide | past | favorite | 71 comments



Both Madelyn and Zhao are terrific programmers. In case you wonder, they are not random people put there for reasons, like for example since Madelyn is a woman so there was some pressure to add she. She deserves this 100% and is one of the top Redis contributors of the last times, with deep technical knowledge in basically every aspect of Redis. The same for Zhao, he is simply impressive, can track bugs about complex conditions like almost nobody can. I'm happy to see them aboard. Btw they were both effectively part of the informal "core team" that was forming spontaneously in the recent times.


> In case you wonder, they are not random people put there for reasons, like for example since Madelyn is a woman so there was some pressure to add she

Kind of a strange thing to call out.


These are the times we live in. Thanks to widespread racist/sexist hiring practices, every time I see a woman or minority in an upper level position I can’t help but wonder if they are there because someone wanted to fill a diversity quota. The thought never even crossed my mind 10 years ago.


This is a bizarre claim. People getting labeled as "diversity hires" and being assumed to be less competent than their peers is a decades-old thing.

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. :| )


> This is a bizarre claim. People getting labeled as "diversity hires" and being assumed to be less competent than their peers is a decades-old thing.

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)


Are you claiming that you couldn’t find any woman who was qualified for your project?


More likely that they couldn't find a woman who was qualified for the project and actually wanted to join at the price the company was willing to pay.


It was true, at the time.

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.


In that case, I would say HR is at fault not for asking that affirmative action be taken, but for not backing it up by making the job attractive in the first place.

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.


> then asking that you hire at least half women shouldn't be an issue;

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".

[0]: https://www.pinkprogramming.se/en/


It's often hard to find anyone of any characteristic for many projects so it shouldn't be surprising that it's also hard to find people of a specific sub-group.


Why are you jumping to that conclusion? The parent comment probably couldn't even find a person qualified to lead and you had to make it a gender thing.


The parent comment explicitly made it about gender. They explicitly said they had a man they liked but couldn't hire him because of HR.


For whatever it's worth we didn't have a man in line, we had nobody in line. But we had pressure to hire this person because it would increase the representation and the expectation was that we'd be able to train her on the job.


> This is a bizarre claim.

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.


Yes, there's been ongoing activism, hand-wringing, counter-activism, legislation, etc, in this space for several decades.

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?


> Where have you all been?

The pressure on management to hire diverse candidates has increased 100 fold over the past decade.


25 years ago it was already old news. I remember in my childhood even further back than that, the grownups would make comments about affirmative action hires.

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.


Surely the weirder thing is to see, for example, a dozen member board for a global corporation where every single member is a middle aged white guy? Or an outfit where everybody in the C-suite went to the same school.

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.


This might be unpleasant to say, but I don't think it's _weird_ that a C-suite is all middle-aged, white men. As in, it's pretty common and unsurprising. That is very different than saying that is what is _best_, which I would disagree with. There's a lot of inertia and it would be no doubt obvious that these middle-aged, white men have had more opportunities than women and have had greater chances to progress professionally. Again, I don't mean that's better or right, it just is what is for historical reasons.

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.


To me whether something is weird is distinct from it being usual or familiar.

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.


> It stands to reason that there are going to be women (in particular) with the innate abilities you want

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.


Hiring !== Promoting


I think the widespread practices may be calling from inside the house.


Are you suggesting that tech or corporate culture now is more discriminatory in its hiring practices than it was 10 years ago?


This is very sad but I share your sentiment. Thanks for having the courage to write this comment.


Jesus this is the kind of handwringing excuse Trump could only dream of coming up with on his own. So your own sexism is the fault of women or non-white men getting promoted on merit. That is weapons grade bullshit.


You know what, when I see a woman in a male dominated field like infantile fcking tech, I have found they are literally 2x-10x better than their peers. That they can cut through bullshit, navigate metric tons of stupidity and still get their jobs done. They are in the position in spite of their sex, not because of it.

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.


> I have found they are literally 2x-10x better than their peers.

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.


Those are the only two options?


> Those are the only two options?

Do you have another reason a developer 10x better than her peers isn’t promoted to senior, to principal, etc?


That 10x developer. or ninja, or unicorn, are just bullshit titles/prepositions by itself?


I'm pretty sure Antirez doesn't mean it the way you're interpreting it. Just like me, he's not a native English speaker. I believe what he means is that she has NOT been chosen simply because she's a woman, but because of her skills.


Exactly, I wanted to make sure people realize she was picked as a human being that is suited to the role. Without consideration for any other metric.


Tech's got plenty of the pince-nez set who would Just Ask Questions about a core contributor getting their spot for those reasons.

Can't blame him for being proactive about nipping them in the bud.


Until you called out Madelyn as a she. I had no idea.

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.


> I'm glad HN doesn't have profile pictures and things.

THIS


As a non-native English speaker, I am always thrown off by the word terrific. It sounds horrible to me, and apparently it can also mean very bad.

https://www.merriam-webster.com/dictionary/terrific


I was interested enough in the etymology to do some googling; terrific has its roots in ‘terror’, much like horror/horrific. It was used as a generic intensifier, often hyperbolically, which became common enough that it lost its negative connotation.

https://www.mentalfloss.com/article/56865/why-does-terrible-...


> it can also mean very bad

this usage is definitely uncommon/archaic


Yep it's the same in italian, it means "generating strong fear" or alike. But at this point I got accustomed to the English meaning when I write English.


Awesome is a similar word. It used to mean awe-inspiring, but now can simply describe an enjoyable bowel movement. lol


The original meaning of awful used to be awe-inspiring too. Awesome came about as a replacement when awful started acquiring significant negative connotations.


I don't remember hearing it used in that way before; I think you would have to go back a couple of centuries for that usage.

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...


I always think of the famous Hindenburg crash tape. "it's a terrific crash" 1937 for those, like me, that weren't sure of the decade.

https://genius.com/Herbert-morrison-hindenburg-disaster-broa...


Sure - but that is "terrific" in the still-current sense of "massive, of great size" - not the archaic use in the parent.


The only reason I remember that use is because it sounded out of place to me.

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-...


You certainly leave some big shoes to fill, as shown in the quick stats below:

https://imgur.com/QUPER9q

https://imgur.com/RnlzECa

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.


What site are those screenshots from?


It's a product that I'm working on, which is focused on developer first metrics. I want to create software metrics, that developers can trust, which in turn can be used to properly gauge productivity and risk.

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:

https://imgur.com/OMD8rFF

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.


Looks promising. Are you active on Reddit? Because the screenshots looked familiar, and I think I've seen screenshots of your app posted there before.

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.


Thanks for the kind words. I'm on reddit but I haven't posted in a while, so I'm not sure if what you saw was mine.

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 :-)


Feel free to email me when you release! My email is in my profile.


Will do and thanks for the support!


That looks amazing! Is there a way to subscribe to updates / releases?


Hey thanks for the interest. Unfortunately I don't have an automated way to sign up (my focus really is on the technology as it's not trivial), but if you send me an email (see profile), I can add you to my list.


I know Zhao Zhao personally. He is one of the very best. Better than antirez IMHO.


Interesting move, putting “SLA-driven” infrastructure engineers (i.e. people working at public clouds to deliver Redis-as-a-Service solutions) in charge of the project. (Not just these two from AWS and Alibaba Cloud, but the rest being from Redis Labs.)

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.


> I’m sure people running Redis in production are happy about that.

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.


Zooming out, there are two kinds of production infra software:

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.


This follow up comment was insightful. Thanks.


True but I think thats the most skeptical viewpoint possible.

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


2. Developers think for themselves and aren't always "double agents".

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.


What will be interesting to see is how Redis fares without Antirez.

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.


One of my favorite bits of trivia: What would Git be like if Linus stepped away? Oh yeah, he stepped away after a few months and Junio Hamano continued running it for the next 15 years[1] (!!).

[1]: https://github.com/git/git/graphs/contributors


I'm not sure what your point is. Antirez has been contributing to redis for over 11 years and accounts for 80% of all its code churn.

https://imgur.com/RnlzECa

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.


I think they were replying to a different bit of the parent comment than you seem to think:

> ... what would Linux be when Linus decides to step away?


I think it was a fair reply. Linus's contributions to Git, while basically 100% of the project initially, were not sustained over as long as Antirez's contributions to Redis.


While this is true, I think Git is quite different. Linus has said that he's not really a "VCS guy", so apart from high level architecture and high level concepts of what Git actually is as a VCS, he hasn't really had as much impact on Git's codebase as much as Linux.

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).


As with Yossi and Oran vis-a-vis Redis labs, it is not clear whether Madelyn and Zhao are in the core team in their personal capacities or as representatives of Amazon and Alibaba respectively, we know that Redis labs reserves the right to name replacements for Yossi and Oran, is the same true for Madelyn and Zhao and their current employers ?


So that at least looks like good news. Hope they can make this transition work smoothly!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: