Fuchsia and Diversity

Keywords: #programming #computer #social

Reading an article on the security in the Fuchsia kernel and noticed a classic “diversity” bug buried in the article.

Why this pops into my head

I hate conference keynotes. And especially the rando-speaker day 2 ones. But I actually went at the 2017 Cloud Foundry Summit. Side note: don’t schedule conferences in Santa Clara.

My Memory of the events

I might have this timeline mixed up, but whatever.

The first one was some weird rant about how robots were going to take our jobs that had a bunch of Global Average Temperature vs Pirates-level graphs. He was talking to the people that would likely build and profit from said robots even if he wasn’t a quack. I almost left.

After that was a talk on diversity. I think it’s important, but most talks just sound like pleading and moralization. After the prior, I was buckling in for that. But it was a lady from the University of Florida. So “Go Gators!” I’m in.

The best keynote I have ever seen

Kyla McMullen killed it. I couldn’t remember details about any of the keynotes I have seen over the years. I think about this one probably every month.

She glazed over the moralist argument and went straight for the practical jugular. She knew her audience and nailed it.

Diversity isn’t just a “nice to have” “you should do the right thing” thing. When we don’t have diversity on teams making products, we screw up.

She brought up practical examples like my favorite “racist soap dispenser”. They didn’t mean to make a soap dispenser that hated dark skinned people. Just the team that made it had no dark skinned people, and didn’t test with any. So dark skin didn’t trigger the sensor.

I’ve done one of these myself. I used classic stop light colors to indicate status in a UI. My first test-user was red-green colorblind and couldn’t see any difference between “good” and “bad”. Duh. So I made sure there was a shape change as well.

I’m so lucky I was working side-by-side with him, because he probably just would have complained about it to his team and the message would have never made it back to me. I would have less users who could get value out of what I made.

Consequence for me

It gave me a message I can (and do) use when talking to hiring managers. First, hire the best people. But when all things are even, look at how you can flesh out the backgrounds of your teams.

I don’t mean that necessarily as targeting a specific gender or ethnicity. I like getting folks with backgrounds in different industries and company sizes. Anything to get more coverage in perspectives.

Also message to folks that hire: Do not hire someone that has all the skills to do the job. They’ll just be bored or they’re not being honest. Hire someone with the potential to grow into (and past) the job.

In general, when hiring, think about building a team, not just a posting. That does not mean hiring someone “like your team.” That means fleshing out the team and filling gaps. You need experience and inexperience. You need different points of view. And you do need people open to collaboration, not “rock stars”. You want that natural turnover of people growing out of the team to also be building up folks to cover. That doesn’t need to be 1:1 Srikant is the new Ashley. But that Ashley’s skillset (including leadership) is covered by people she helped develop.

Sorry, I’m ranting.

My point

I ran into an article on security in Google’s Fuchsia OS and was nerding out.

I was interested in the syscall interface of this microkernel implementation.

But under the heading “Zircon kernel development workflow” there was an obvious diversity bug.

The author describes a patch he had to run/debug the kernel, just by removing the hardcoded LC_ALL from the command. This basic functionality to do much of anything only works for English users. And there’s a patch that’s been sitting out there for 3 years.

It’s a 9 character change. But the folks working on it only speak English and don’t care enough to get around to merging the fix.

The Danger

The argument against these kind of things is usually “Yeah, we’ll get around to it, but if you can’t figure that out, you probably shouldn’t be working on it.”

But this is particularly bad for a immature project like Fuchsia. Should you be able to figure it out and fix? Yeah. And even a Google search will likely pop up the referenced patch.

But it also signals that they have no interest in collaborating with non-English speakers. No one is contributing to that because they need something. They’d be jumping in because its new and interesting. That little bug is enough of a barrier that someone who could be a good contributor just moves on to another project to play with.

Be careful

So yeah. Be careful. Cover that diversity when you can. It’s hard in tech, so sometimes you just don’t have the opportunity to.

But when there is a bug, like my colorblind example or this language issue, treat it as a major bug.

Fix it, add the use case to your testing. Make sure it doesn’t exist elsewhere and you don’t regress on it.

See “users” as anyone interacting with your work product. That includes developers adding to, or taking over maintenance of your code.

And yeah, follow the basic moral principle of “Don’t be a dick.”