google reader refugee.
1690 stories

Ditch “Culture Fit”

1 Share

A couple different talks at OSCON got me thinking about the unhealthy results of hiring on the basis of “culture fit”.

What is company culture? Is it celebrating with co-workers around the company keg? Or would that exclude non-drinkers? Does your company value honest and direct feedback in meetings? Does that mean introverts and remote workers are talked over? Are long working hours and individual effort rewarded, to the point that people who value family are passed up for promotion?

Often times teams who don’t have a diverse network end up hiring people who have similar hobbies, backgrounds, and education. Companies need to avoid “group think” and focus on increasing diversity, because studies have shown that gender-diverse companies are 15% more likely to financially outperform other companies, and racially-diverse companies are 35% more likely to outperform. Other studies have shown that diversity can lead to more internal conflict, but the end result is a more productive team.

How do you change your company culture to value a diverse team? It’s much more than simply hiring more diverse people or making people sit through an hour of unconscious bias training. At OSCON, Casey West talked about some examples of company culture that create an inclusive environment where diverse teams can thrive:

  • Blame-free teams
  • Knowledge sharing culture
  • Continuous learning
  • No judgement on asking questions
  • Continuous feedback
  • Curiosity about different cultures
  • Individually defined work-life balance
  • Valuing empathy

For example, if you have a culture where there’s no judgement on asking questions or raising issues and people are naturally curious about different cultures, it’s easy for a team member to suggest a new feature that might make your product appeal to a broader customer base.

The other problem with “culture fit” is that it’s an unevenly applied standard. An example of this was Kevin Stewart’s OSCON talk called “Managing While Black”. When Kevin emulated the company culture of pushing back on unnecessary requirements and protecting his team, he was told to “work on his personal brand”. White coworkers were reading him as “the angry black guy.” When he dialed it back, he was told he was “so articulate”, which is a non-compliment that relies on the stereotype that all African Americans are either uneducated or recent immigrants.

In both cases, even though his project was successful, Kevin had his team (and his own responsibilities) scaled back. After years of watching less successful white coworkers get promoted, he was told by management that they simply didn’t “see him in a leadership role.” Whether or not people of color emulate the white leadership behavior and corporate culture around them, they are punished because their coworkers are biased towards white leaders.

As a woman in technical leadership positions, I’ve faced similar “culture fit” issues. I’ve been told by one manager that I needed to be the “one true technical voice” (meaning as a leader I need to shout over the mansplainy guys on my team). And yet, when I clearly articulate valid technical or resourcing concerns to management, I’m “dismissive” of their goals. When I was a maintainer in the Linux kernel and adamantly pushed back on a patch that wall-papered over technical debt, I was told by another maintainer to “calm down”. (If you don’t think that’s a gendered slur based on the stereotype that women are “too emotional”, try imagining telling Linus Torvalds to calm down when he gets passionate about technical debt.)

The point is, traditional “cultural fit” narratives and leadership behaviors only benefit the white cis males that created these cultural norms. Culture can be manipulated in the span of a couple years to enforce or change the status quo. For example, computer programming used to be dominated by women, before hiring “personality tests” biased for men who displayed “disinterest in people”.

We need to be deliberate about the company culture we cultivate. By hiring for empathy, looking for coworkers who are curious about different cultures, and rewarding leaders who don’t fit our preconceived notions, we create an inclusive work environment where people are free to be their authentic selves. Project Include has more resources and examples for people who are interested in changing their company’s culture.

Read the whole story
39 minutes ago
Melbourne, Australia
Share this story

Fizz Buzz in Tensorflow

1 Share
machine learning for dumb coding interview questions  
Read the whole story
51 minutes ago
Melbourne, Australia
Share this story

Inessential Weirdnesses in Open Source Software (OSCON 2016)

"Inessential Weirdnesses in Open Source Software": written version of a speech I delivered at the OSCON conference, Wednesday, 18 May, 2016, Austin, Texas. O'Reilly will be posting the video behind a paywall sometime in June 2016.


me smiling at cameraHi there. I'm Sumana Harihareswara and I'm going to speak with you about "inessential weirdnesses in open source software".

You can't be all things to all people. [pause]

We would be making more and better software, and empowering more people, if we got and kept more people, who have different strengths. [pause]

This is a contradiction. It is. The ways we do things right now, in open source, are really good at some things and bad at others. We are good at using some people's strengths and bad at using others. And if we want to get better at that, we need to reduce the barriers to entry, and I'm going to talk about how to do that. But we also need to watch out, so we don't accidentally get rid of the values and the habits we're really uniquely good at, the things we care about, that we should keep. There are people who really love open source culture the way it is now, who feel safe and loved and comfortable here, and that is great. We absolutely deserve to feel safe and loved. But I think there are some changes we can make so that even more people can also feel safe and loved here -- it's additive, it's not about replacement, it's saying, let's invite these people to the party too, and make sure they can have a good time once they get here. We can all work together, and complement each other's strengths.

That's the heart of what I'm going to talk about today, so you can look at your own project and think about where you want to add another interface to your community, so you can be more hospitable to new potential colleagues.


Just some housekeeping to start: I am not using any slides today; instead we have CART, Computer-Assisted Realtime Translation. A person is transcribing the words I'm saying. Stacey. Thank you, Stacey. I will be taking written questions at the end -- you can use pencil and paper, or you can tweet with the hashtag #osnewbie and I'll see it at the end of the talk. I'll be posting my notes online later today.

And there are other good talks happening right now, so to help you decide whether to stay in this room: this talk is going to be more interesting to people who already have been participants in open source software for a few years, who can use tools we commonly use in our community, like version control, IRC, mailing lists, bug trackers, and wikis, and who are already familiar with general open source software trends and arguments. And this talk is going to be most interesting to people who regularly spend time working to help reach out to new people and get them to use open source software and participate in our communities. So if that is not you then right now, check out the other talks, like "Making awesome things accessible", "I am your user. Why do you hate me?" or "Managing while Black".

"Inessential Weirdness"

OSCON 2016 So the title of this talk is "inessential weirdnesses in open source" -- and this phrase comes from the article "It's not 'them' -- it's us!" by activist Betsy Leondar-Wright. There'll be a link to this article in the notes I put online. The basic idea is, if you look at your own community with the eyes of an outsider, look at it from the perspective of a specific group of people you'd like to recruit, what do you think might discourage them or make them uncomfortable? Those are what we'll call "weirdnesses." And you get to decide, your community gets to decide, which weirdnesses are essential, and which ones, in Betsy Leondar-Wright's words, are inessential, meaning you should offer a workaround for them, or even try to change them.

Leondar-Wright suggests that there are a few classes of essential weirdnesses. There are weirdnesses that come out of our shared core values -- as she puts it, they "couldn't be eliminated without doing a deep injustice to someone". So, for us, that would include stuff like releasing our code in public. There are people who have a hard time with that. There was one coder I tried to help, because she wanted to get into open source, and she just choked, and could not start contributing to our community, because no matter how much handholding or guidance I gave, she was just too afraid to make commits in public. But that's inherent to open source. We can't make that one chunk of the codebase private so people can never see it, that would be against our values and also just logistically it wouldn't work.

Leondar-Wright also points out that some essential weirdnesses are "personal differences that may seem weird to others but are very important to the individual" (for example, choosing not to drink alcohol even though everyone around you is). I would argue that this is also a reflection of our values. We respect people's choice to abstain from alcohol because we value personal autonomy and bodily consent.

But "it's rarely essential to impose one's personal choices on others".

I've run into trouble using this term, because the word "inessential", to some people, implies that something has no value, or that it's harmful and we should get rid of it. No. It's more like a heads-up, that here's a place where you could build out some new API client libraries, in more languages, have more interfaces, so more people can interoperate with you.

I'm going to quote an anecdote from Betsy Leondar-Wright's article:

A few years ago, I listened to week-by-week reports from a radical working-class friend who tried to join a [group fighting corporate globalization]. He told me of snide comments about his fast food; elaborate group process that took hours and hours; insistence that everyone "perform" by answering a certain question at the beginning of the meeting; uniformly scruffy clothes that made his pressed shirts stand out; potlucks that were all tofu and whole grains; long ideological debates over side issues; and an impenetrable fog of acronyms and jargon. He soon quit in disgust. I wonder if the group members understood why he left.

For professional-middle-class progressive activists like myself, it's easy to understand why working-class people would be alienated by the mainstream culture of well-off people. After all, we tend to be alienated by it ourselves, because it represents values we've rejected, like greed and materialism. But the idea that working-class people would have any negative reactions to our own subculture, in particular our values-based 'alternative' norms, tends not to occur to us.

I read that and I thought about times I've seen new people in open source having a bad time, because of something that has nothing to do with our core values, nothing to do with transparency and freedom and helping your neighbor. But because someone was mean to them because they use Windows, or they feel pretty alone and isolated because of our communication norms, or they had a tough time getting started with Git, because it's really hard to get started with Git.

And am I saying "let's get rid of Git"? No! I'm saying, if someone wants to get started in open source, maybe Git isn't the very first thing I want to teach them. Maybe I accept that right now they're on Windows. You gotta meet people where they're at.

That progressive activist group that Betsy Leondar-Wright's friend tried to join -- it sounds like they were basically a working group full of experts who had process and jargon and habits that worked well for them. And we have specialized process and jargon and habits that work well for us, when it's all experts together. I think one of the hardest things to do is for experts to look at a culture that's working for us and figure out what scaffolding we can offer so new people can come in and become experts too. Researchers Stuart and Hubert Dreyfus actually talked about this problem in 1980, in their Dreyfus Model of Skill Acquisition -- when you go from novice to expert, you don't just learn a bunch of new facts. The way you look at the world changes, you're making decisions on a new analytical level, you have a whole new perspective. And it's really hard for you to empathize with people who don't have this skill, who haven't learned the judgment and the reflexes that you have. [See Mel Chua's talk slides on education psychology for more on this.] This is one reason writing documentation is so hard. [Here, despite the bright lights, I saw one audience member nod, and that made me happy.]

So today I'll be talking about some few examples, bits of our subculture, the open source software subculture, that routinely alienate new people. And I'll give my thoughts on how to discern the bits that are important, that we shouldn't ever give up because they're key to our values, from stuff where we can offer workarounds when we're doing outreach events and creating online spaces for newcomers -- those are the bits that Betsy Leondar-Wright calls "inessential weirdnesses". Then I'll explain how you can better recognize and fix these kinds of snags in your own outreach work. My hope is that after today's talk you'll be more effective and you'll help make outreach experiences more hospitable and thus more effective.

[Now: three stories.]


My first story today is Aurynn Shaw's story about realizing that hating on Windows and PHP has real costs. She writes in "Contempt Culture":

...when I started programming in 2001, it was du jour in the communities I participated in to be highly critical of other languages. Other languages sucked, the people using them were losers or stupid, if they would just use a real language, such as the one we used, everything would just be better.


This sort of culturally-encoded language was really prevalent around condemning PHP and Java. Developers in these languages were actively referred to as less competent than developers in the other, more blessed languages.

I do recommend that you read Shaw's essay. She goes into some really worthwhile insights on what this dynamic achieves for the people who participate in it, and whom it excludes.

She writes:

It's 2015, and I saw a presenter at a Python conference make fun of Java. How would that feel to people trying to move from Java into something else? I wouldn't feel welcome, and I'd have learned that the idea that the Python community is welcoming wasn't true.

I'm tired of calling people out again and again for dumping on PHP.

I'm tired of people dumping on Windows, that most popular operating system, because it's not what we choose to use, tired of the fact that we don't make it easy to use our tools and teach them how to move, when they're ready.

As I experienced in most of my community management work in open source software, over and over, I saw how few of our tools and applications make it easy for Windows users to try out open source software. On Windows, installing, for instance, an open source application that depends on Ruby is a big hassle, and might mess up other stuff you're doing that depends on Ruby.

So what is essential here and what is inessential?

Do you yourself have to go get a Windows machine and start writing PHP? No. Of course not. Remember, personal autonomy and choice is essential!

It's essential that we encourage people to move off of proprietary systems, giving them support in the short term with training and help, and in the long term with kick-ass operating systems and applications, and a culture and a political environment that encourages open source software. It's inessential to make people feel bad that they haven't done a really hard transition yet. Activists have known for a long time that if you ask a new potential ally to change their entire life and lifestyle at once, you don't get as many new followers as if you get more doable, with short-term goals that give them immediate benefits.


Here's my next example, and it's about language. Now, if you were teaching someone a skill they didn't know before, like woodworking or omelet-making or choral singing, it would make sense for you to teach it in the language they already speak. If they only speak English, teach it to them in English.

Well, every day, we do the opposite of that. We tell people that they have to learn a new language along with the new topic. The topic, the skill, is using open source software, and the language is the command line.

Gus Andrews, who's a usability expert and a Fellow at Simply Secure, has a provocatively titled blog post, "Why the command line is not usable". She discusses how the command line is an environment that requires tremendous cognitive load of new users. She reminds us that recognition is far easier than recall.

Command lines demand that users remember the correct phrase to make the system run, rather than giving them prompts which might help them guess what the system needs them to do next. The overwhelming majority of people alive today have never had the opportunity to learn those commands. Making them look them up and learn them themselves would make them very, very frustrated -- they don't have time for that. GUIs aren't just "shiny": they are tools which help us remember what is possible.

Some users absolutely find the command line a lot more usable and accessible! And I don't discount their experience! But over and over we see that a lot of new users find it really frustrating to get started on the command line.

And this is not just about uneducated users, or users who don't spend that much time with computers. As an example, computer science professor Philip Guo has an essay on his site called "Command Line Bullshittery" where he talks about all the little commands his research students, CS researchers, have to learn in order to get their research done. Stuff like

nohup tar -jxvf giant.tar.bz2 2> cmd.errs &

And he says that as an advisor, one of the things he has to do to keep his students from getting super demoralized is to teach them how to install and configure and use open source software on the command line, which is a really deeply unfriendly experience, and to reassure them that it's "just a necessary upfront tax required to enable them to do the actual interesting research".

And in that piece he distinguishes between incidental and intrinsic complexity.

The fact that it's hard to learn the command line "arises simply because modern research software development is a messy jumble of open-source tools tied together by the duct tape of command-line scripts." It's incidental complexity. It has nothing to do with the intrinsic complexity of CS research, the hard problems that these researchers are trying to investigate.

This underscores that it is just hard to install open source software, often, and get it to a state where it's properly configured and secured, and you can do work with it and import and export data. Recently Bret Davidson and Jason Casden wrote a piece in the code4lib journal, "Beyond Open Source: Evaluating the Community Availability of Software". Their suggestion was: What if you just took a stopwatch and saw how long it took a representative user to install software and do something useful with it? I think for a lot of us, we are aware that this number, for our projects, would be dismally high.

Similarly, when I was at the Wikimedia Foundation, we started the Visual Editor project, which makes it easier to edit Wikipedia articles. Before we started this, we often saw that skilled writers with useful content to contribute would get discouraged, because they knew English, they were web-savvy, they sometimes even knew HTML, but they didn't know this wacky weird markup language, wiki syntax, that no one else in the world used. In fact, sometimes this made them think that they were not allowed to edit -- people would click the Edit link, see this jumble of what looked like source code, and then Back-button right on out of there, for fear that they'd broken something, or that they were about to break something.

And what's worse, when we started introducing the what-you-see-is-what-you-get editor, the Visual Editor, some of the experienced editors pushed back with the argument that the syntax was a gatekeeping measure, that the ability to master this syntax was a really good proxy for whether someone was going to be a good writer and contributor in general. This is pretty nonsensical and has not been borne out as far as I can tell.

So, what is essential here? what is not?

With wikis, it's essential that everyone can edit an article -- that is part of the freedom of free culture. MediaWiki is meant to make it easy to edit. By default, when you set up a new MediaWiki installation, every user can edit every article. We aren't going to add a bunch of different permission and access control layers so that there are fifteen layers of privileges to determine who can edit what page. There's other wiki engines that'll do that, that have different core values, but it's inherent to MediaWiki that we default to freedom.

And that everyone can see every article's history, because that transparency makes everyone a more informed consumer. And there's more, I'm sure. But using the syntax is inessential. It's incidental complexity.

And I would argue that the most essential aspect of the command line is that people are empowered to control their machines and use them the way they want. It's a tool. And it's important that all users have the command line on GNU/Linux available, so they can chain together operations and learn to do development work, if they want, and because there are people who find it a much more accessible experience. But the command line is such a difficult, alienating experience to new users, it's like it gives them unusable freedom. (Hashtag #unusablefreedom .) So, making new users learn the command line in order to use open source software is an inessential weirdness. Having alternatives available, like the rich desktop environments that GNOME and KDE have made and Ubuntu helped make available, is great. As long as all the GUIs are also accessible to screenreaders.

REMINDER: I will be taking written questions at the end -- you can use pencil and paper, or you can tweet with the hashtag #osnewbie and I'll see it at the end of the talk.


Now another story, and it's actually about a rare failure by one of my favorite conferences. PyCon North America is a yearly community conference about Python. In scheduling PyCon 2014 and 2015, the organizers accidentally scheduled it over Passover, both times. And this means that a nontrivial number of observant Jews couldn't come.

And beyond that, consider how many of our conferences happen over Fridays, Saturdays, and Sundays. If going to a weekly Muslim, Jewish, or Christian religious service is important to somebody, then a weekend conference schedule is going to really crimp their style.

(Now, this is important to balance against the fact that some people can't miss that much work in order to attend a conference. Maybe the best approach is to be aware of who seems to be consistently catered to, what demographics aren't having any trouble showing up, and try to change it up a bit so you have some events, some communication channels, and so on that cater to the people you haven't had as much success in reaching. You can see an example of how I'm doing that in this talk -- I'm using written questions instead of oral Q&A, because it's a way to make some people comfortable who usually don't get to ask questions. And instead of using slides, I suggested we have the live captions, to help people who usually have trouble following a spoken talk.)

I'm not here to try to persuade anyone to join or leave any religion -- I'm a Hindu myself and I'm really grateful that we do not do that here, that in my nearly 20 years in the free software movement no one has tried to convert me. I'm glad our spaces are secular. That is essential to us being open for everyone. But in our aggressive ignorance of religion, and sometimes when we stand by and let anti-religion comments stand without challenging them, we sometimes cause snags for people who want to engage with us.

Sometimes this is in missing opportunities, like partnering with churches, temples, and mosques. Hey, they have communities full of people with free time who are interested in making the world a better place! A lot of them care about privacy from government surveillance, for very good reason! And they have free venues for meetings!

But, again, it's essential to respect people's personal autonomy and freedom. There are people in our communities who have been hurt by religion, been traumatized by religion, who currently face discrimination from religious communities. So of course we have to be mindful of that. So, for instance, if someone in your community isn't going to feel comfortable in a religious space then there's no reason to try to persuade them to do that bit of outreach.

In any case, I'd say that it's an inessential weirdness for us to stand by and allow anti-religious comments in our public spaces. One person who ran an online technical forum mentioned that, in its "off-topic" section, sometimes people said things that were casually sexist or Islamophobic. He said,

"I just kind of rolled my eyes and ignored them. About three years in to running the forum, I incidentally discovered that we had a few closeted women and Muslims in our membership. Suddenly those jokes that were white noise before made me acutely ashamed and I had to update the rules and enforcement to stop those posts going forward. If you had asked me the year before what I thought the community's most serious issues were in expanding and increasing engagement, a 'casual hostility to certain demographics' wasn't even on my radar." -- Matt, Crooked Timber comment thread

More things I wish I could have talked about

I wanted to go into these in depth, so there are topics I mentioned in my abstract that I do think contain inessential weirdnesses but that I don't have time to discuss in depth in this time slot, like open source communication norms, and how our community acts regarding pop music, patriotism, small talk, professional sports, and the primacy of in-person conferences, and the user interface of Git specifically, and assumptions about bandwidth & personal computer quality. I'm happy to discuss any of those during the Q&A or afterwards. This is an incomplete list of examples.

REMINDER: I will be taking written questions at the end -- you can use pencil and paper, or you can tweet with the hashtag #osnewbie and I'll see it at the end of the talk.


me in conversation in speaker's lounge - photo by O'Reilly MediaSo what does this imply for open source software advocates? Now I'm going to talk about some ways to watch out for these problems and reduce the harm they cause.

1. Look for code smells

These are some really rough heuristics to try to find snags that other people are hitting.

Take the same approach that a Software Reliability Engineer would take, and say, any time a user gets hassled or tripped up, that's a symptom of a problem that needs fixing. You treat every downtime, every pager call, as a bug report.

Look out for any advice your project is giving newcomers that has the word "just" in it. I think Greg Wilson calls this the passive-dismissive adverb.

Watch out for any place in your workflow where newcomers have to deal with simultaneous newness on multiple dimensions. Mako Hill has observed that Wikipedia was founded at the same time as a lot of other innovative free knowledge projects, but Wikipedia's the one that thrived and that's still around, because yeah, it was super weird and disorienting and innovative on the workflow level, but the thing it was aiming at, an encyclopedia, that was a vision all the participants understood. ["Almost Wikipedia: What eight early online collaborative encyclopedia projects reveal about the mechanisms of collective action."] You can only innovate on so many levels at the same time. This goes back to that woodworking example at the beginning. People will have a hard time learning a new language while they're also learning to do an entirely new kind of thing.

If you make an application you want people to use, use the Simply Secure guides on doing qualitative UX (user experience) research, such as seeing how users are using your product/application.

And another possibility -- I know this is a wacky idea -- but you can ask. You can reach out to individual people who attended one event and drifted away, and ask them what you could fix to be less unappealing. That doesn't always scale, it's artisanal data, but still, it'll give you some thoughts to work off of.

And having those thoughts, a list of some things to look at, helps with the next step.

2. Realistically assess yourself & your goals

Once you have an inventory of some things about your community that are putting off newcomers, you have some choices to make. What are you really committed to keeping in absolutely all your activities, and what do you think you could stand to tone down when you're trying to talk to newbies?

Discerning essential from inessential means being honest about what your real values are.

So, what are your goals? What are your values? You care about the Four Freedoms and about treating everyone with respect; beyond that, what are you particularly attached to? Who are you trying to reach out to, & what are the gaps between your culture & theirs? I haven't even gone into international, inter-language, and other differences you might want to traverse, but I can recommend to get some representative thoughts.

"Observe the cultural norms of people you'd like to work with, watch for signs of discomfort, and study what conveys respect and disrespect in their subculture." -- Leondar-Wright

This isn't about completely changing the entire core of your work. If you have a strong cultural practice and you're committed to it, own it but be nonjudgmental -- say "if you want [other approach] consider [other project]".

Acknowledge that different people want different things. And acknowledge that when you negotiate that with people who are different from you, that will probably require conversations, not just writing FAQs that live forever. [See this explanation of the success of the English Wikipedia's "Teahouse" for more on this.]

3. Find easy ways to build bridges

Sometimes you're going to find easy wins, which is great! There are easy add-ons you can do that overcome a barrier.

Some old-school people like Mailman mailing lists. Some new contributors really like web forums. If you upgrade to Mailman 3, you get one thing that acts like both, so everyone's happy!

If you have an IRC channel, you can do what OpenHatch did and have an automated welcome bot. It greets new people and gives them a couple tips, including the names of a few people they could reach out to for help who have been active recently. If you have a Slack, you can make a bot with the botkit framework to do something similar.

You can use pre-existing playbooks to run events like SpinachCon, so that new folks don't have to learn git or the command line to make their first contribution.

But usually those kinds of easy wins are not the whole story. If you are serious about building coalitions with people who are not like you, you will probably want to:

4. Build and maintain differentiated but connected spaces

Your project can support both experts-only spaces (where jargon and in-group practices are welcome, like really concise speech and Douglas Adams jokes) and mixed-experience spaces (where hospitality is emphasized and legitimate peripheral participation opportunities are available for learning). [Also see Mark Guzdial's and Greg Wilson's posts on this.]

These newcomer-friendly spaces are like tidepools, connected to the ocean, but calmer, where things can germinate in a gentler environment. For you, a tidepool might be a community that publicizes beginner-friendly events, where Windows users who prefer GUIs to command lines are welcome, where new people can make relationships through small talk, where there's an occasional installfest at a church.

This means that you would have to learn to be comfortable explaining, nonjudgmentally, that there are high-jargon spaces and low-jargon spaces, and helping steer conversations to where they ought to be.

These newcomer-friendly events and online spaces probably ought to have agreed-upon rules. Example: the Recurse Center rules (manual) to help everyone feel comfortable saying "I don't understand." And it's probably a good idea to regularly revisit and revise those rules to see if they've lost touch with any of the essential values and weirdnesses that the community needs to preserve.

And this isn't meant to suggest that we should condescend to newer contributors -- just listen to them, and do what it takes to support and encourage them in their open source software journey. Everybody's got something to learn from us and everybody's got something to teach us. So while teaching new learners, yeah, we should err on the side of clarity and listening, and call things by their proper names while also collaborating among people with different perspectives to build a common language -- and a common movement.

5. Acknowledge the costs

"Don't expect you can remain exactly as you are and be a bridge person" -- Leondar-Wright

Engineering is a game of tradeoffs. And yeah, there's a tradeoff here. You are going to reduce the amount of time that the outreach-centric folks spend in the pre-existing expert communities. Let's acknowledge that different spaces are genuinely, irreconcilably different.

Whenever you try out a kind of funnel or ladder that you hope will get you new users, new participants, new collaborators, not all of those people are going to work out. And every one of them who drops out is going to feel like a failure of the new plan. Like, "we spent all this time on making a GUI and negotiating with the local mosque to host a meetup and actually making smalltalk with people, and it's still a grind!" You're going to have demoralizing moments and it's going to feel even harder because you're trying something new that you're not good at yet. Which is where the learning happens.

Leondar-Wright says: "Figure out which of your weirdnesses are essential to you, and drop the inessential ones when you're doing cross-class outreach or coalition building. Be thoughtful about who your group sends to be the emissary to a culturally different group." So, that means that some of the people in your community who are not very good at adapting to other people's cultures should not be doing this work. And if they're trying to do this work and they're not good at it, they need to hear that, and that's a hard conversation to have.

Another cost is the cost of the weirdnesses you decide to keep.

If you decide to hold onto a weirdness, then acknowledge that in your outreach, you'll need to pay the cost of making new people comfortable with it. Develop good explanations and metaphors and help people understand why you've made the choices you've made.

Figure out what needs teaching in a standalone class. For instance: the nonprofit Software Carpentry teaches researchers and scientists of all kinds -- physicists, biologists, sociologists, anybody who has to manage and sort through data to do research -- they teach them basic research computing skills, like version control, the Unix command line, and better programming skills. And the Software Carpentry folks have created these workshops and boot camps, sort of as a coping mechanism for the weirdnesses of Git and the command line.

As a community, it looks like we are sort of doing this with Git by creating learning materials, and by making some workarounds. Look at the GitHub web UI as sort of a costly, unfree mitigation of the horribleness of Git's command-line UI. As with wikis: it's essential, with Git, that everyone can suggest improvements, everyone has access to the whole history, it's possible to search for specific changes or classes of changes. But learning to use the command line and the syntax is just not as essential as a first step.


So here's the tiny plug, which is that, through my firm, Changeset Consulting, I can help you with this -- with contributor outreach and with auditing and assessing and improving your current intake and onboarding process. But no matter whether you hire somebody or ask for volunteer help or do all this work yourself, this is going to be tough, but necessary work, for us to build a mass movement.

As Betsy Leondar-Wright says:

None of this is easy. It's one thing to briefly change ourselves for a job interview or for dinner with the in-laws, but it's painful to have to change ourselves in our own activist groups. But as civil rights activist and Sweet Honey in the Rock founder Bernice Johnson Reagan said about coalitions, "If you're comfortable, you ain't doing no coalescing."

I am asking you to stay safe and loved but to try installing discomfort. Everyone deserves safety. Safety is what makes it possible for us to function. But maybe we could take turns being uncomfortable, so the same people don't always have to be uncomfortable all the time. If you are recruiting for new Google Summer of Code interns, or you're on a newbies-friendly mailing list, and you see a barrier to entry, check whether you're acting like those old-school Wikipedians who thought the Visual Editor was keeping out the riffraff. Ask yourself: "Is this essential to our values, or is it more like adding another way in would make us uncomfortable?"

Just give it a spin. As the Open Source and Feelings Diversity Statement says:

"Sometimes we will need to step out of our comfort zones to make everyone feel welcome. We recognize that privilege is real and that the privileged have more bandwidth to be uncomfortable and help make our space more welcoming."

Thanks to Amy Hanlon, Anne DeCusatis, Leonard Richardson, Denver Gingerich, Betsy Leondar-Wright, Naomi Barrettara, Darius Kazemi, Brendan Adkins, Nick Murphy, Roan Kattouw, Meredith Patterson, Andromeda Yelton, and Kaitlin Thaney for their comments on drafts of this talk, and thank you to Mary Gardiner and Camille Acey for earlier comments on this topic.

Question & Answer

And I'm now ready to answer your written questions. [I received one question.]

Q: Does jargon exist for matters that cannot be understood with preexisting vocabulary?
A: I think the word there is jargon. I think that it's useful to remember that there are -- jargon isn't just about synonyms. It isn't just, you know, we say "quit" or "exit" where somebody else says "end." Jargon isn't just about different words for the same thing. Often one function of jargon is an encapsulated compressed thought that does have dependencies. You can think of trying to reach newbies as a dependency management exercise. How many new concepts and skills are you making them install in order to get to the point where they can do something useful and collaborate with you? And so, I could, you know, if you want some metaphors, I think that's a reasonable one to talk to other coders with. The chunk of thought that this questioner asks about, ideas that cannot be easily expressed or understood with the person's preexisting vocabulary until they learn new words and thoughts, I think "jargon" is a reasonable thing to start there.

Additional note: Thank you to White Coat Captioning for working with O'Reilly Media to provide CART services for this session. I've checked the transcript they provided and improved this post to reflect the question-and-answer session, as well as places where I said something better live than I had scripted for myself to say, and I've included in this post parts of the speech that I did not have time to deliver during my OSCON slot.

This talk is a revision of an earlier talk I delivered at LibrePlanet 2016; in particular, I cut the "small talk" section due to ableism concerns, and may someday expand that chunk of thought into another talk or essay.

Read the whole story
1 day ago
Melbourne, Australia
Share this story

Your project's RCS history affects ease of contribution (or: don't squash PRs)

Github recently introduced the option to squash commits on merge, and even before then several projects requested that contributors squash their commits after review but before merge. This is a terrible idea that makes it more difficult for people to contribute to projects.

I'm spending today working on reworking some code to integrate with a new feature that was just integrated into Kubernetes. The PR in question was absolutely fine, but just before it was merged the entire commit history was squashed down to a single commit at the request of the reviewer. This single commit contains type declarations, the functionality itself, the integration of that functionality into the scheduler, the client code and a large pile of autogenerated code.

I've got some familiarity with Kubernetes, but even then this commit is difficult for me to read. It doesn't tell a story. I can't see its growth. Looking at a single hunk of this diff doesn't tell me whether it's infrastructural or part of the integration. Given time I can (and have) figured it out, but it's an unnecessary waste of effort that could have gone towards something else. For someone who's less used to working on large projects, it'd be even worse. I'm paid to deal with this. For someone who isn't, the probability that they'll give up and do something else entirely is even greater.

I don't want to pick on Kubernetes here - the fact that this Github feature exists makes it clear that a lot of people feel that this kind of merge is a good idea. And there are certainly cases where squashing commits makes sense. Commits that add broken code and which are immediately followed by a series of "Make this work" commits also impair readability and distract from the narrative that your RCS history should present, and Github present this feature as a way to get rid of them. But that ends up being a false dichotomy. A history that looks like "Commit", "Revert Commit", "Revert Revert Commit", "Fix broken revert", "Revert fix broken revert" is a bad history, as is a history that looks like "Add 20,000 line feature A", "Add 20,000 line feature B".

When you're crafting commits for merge, think about your commit history as a textbook. Start with the building blocks of your feature and make them one commit. Build your functionality on top of them in another. Tie that functionality into the core project and make another commit. Add client support. Add docs. Include your tests. Allow someone to follow the growth of your feature over time, with each commit being a chapter of that story. And never, ever, put autogenerated code in the same commit as an actual functional change.

People can't contribute to your project unless they can understand your code. Writing clear, well commented code is a big part of that. But so is showing the evolution of your features in an understandable way. Make sure your RCS history shows that, otherwise people will go and find another project that doesn't make them feel frustrated.

(Edit to add: Sarah Sharp wrote on the same topic a couple of years ago)

comment count unavailable comments
Read the whole story
4 days ago
No gerrit then
Melbourne, Australia
5 days ago
I think squashing has a place but it's to clean up the parts which have no historical value. Once it's more than a discrete change, ease of comprehension should win
Washington, DC
Share this story

New York magazine on Ask a Manager

1 Comment

Y’all, New York magazine did the greatest profile of Ask a Manager yesterday. I love everything about it, except that apparently I say “I mean…” constantly. But I feel like the writer really gets the site and what’s going on here. Read it here!


New York magazine on Ask a Manager was originally published by Alison Green on Ask a Manager.

Read the whole story
5 days ago
To that end, there is one core piece of advice she says she is always returning to. “More often than not, when people write in, they’re looking for an answer that does not require them to have an awkward conversation about it,” Green said. “And, I mean — it’s not Ask a Magician. But if there is one thing I say over and over and over, it is probably this: You either have to have the awkward conversation, or live with the thing that’s annoying you.”
Melbourne, Australia
Share this story

#862: Q: “Does my boyfriend actually love me?” A: “Who knows? He treats you like crap, so time to go!”

1 Share

Spoiler note: I reject this “boyfriend,” and all his works, and all his empty promises, and all his creeping on young women destroying their self-esteem.

Dear Captain Awkward,

I’ve been seeing the same guy for almost two years now. We met when I was living in Colorado, shortly after we met I moved away, and our relationship there wasn’t ever really too serious, but I feel like both of us felt that we wanted it to grow stronger, so when I moved away we continued to see each other and have a long distance relationship, but we aren’t truly in a relationship because he says he doesn’t want to claim me as his girlfriend until I am 21. He is 29 and I am 19. I know that is quite an age difference, but I am very mature for my age, and I feel like he acts more as if he is 24/25 than a 29 year old. So after going to visit him in Colorado a few times, I actually found out that the first time I went back to see him he had a girlfriend, this really upset me because I felt lied to and betrayed, but he thought it would make me feel special to know that he cheated on his girlfriend to be with me. They ended up breaking up right after I saw him, and that was that.

Besides telling me that we can’t be together until I’m 21, he also tells me he can’t be with a girl who doesn’t have, in his words, “a perfect ass”, so he constantly is harassing me about going to the gym and working out, he will check in with me and asked if I worked out today, which is really upsetting to me because, I eat very healthy and I go to the gym daily, and it is because I like being healthy and feeling good about myself. I am not overweight or out of shape by any means, I’m [height and weight redacted by Captain A.], I wouldn’t call that out of shape, but he constantly is harassing me about the way I look. It is so bad that I don’t even want to show him my body because he always has something negative to say. The things he has said to me have really hurt my self esteem, and make me feel like I am not good enough in his eyes. He will say terrible things about my body and my looks but then the next day tell me how beautiful I am. It is hard for me to understand.

When I get upset at him for critizing my body and putting me down he will tell me I need to toughen up and that he is only trying to make me better, but it’s not because he is worried about my health, it is because he wants me to look a certain way, like some model he sees online. He has even said to me, “I see other girls and I just want to f–k them”..I just don’t know how you say that to someone you love, and he says he’s just being honest, and that he’s a guy and every guy I meet will think that about other girls. Bottom line is, he just makes me feel terrible about my looks, and I wonder will I ever find a guy who can love someone that has all of the flaws he points out in me, I know I will never be a bikini model, but I am in very good shape, and he acts like he is a bodybuilder or something, meanwhile he doesn’t even have a gym membership, eat healthy, or go to the gym on a daily basis. I have never, and would never try to change him, even though he is 29, doesn’t have a job and has no clue what he is doing with his life, I always encourage him and tell him he will figure things out. I never bring him down, or make him feel bad about himself, and he will say the only reason I don’t is because I think he is so perfect already, and it’s not that, it’s just that I love him for who he is and all of his flaws or imperfections make him who he is..I just really don’t know what to do anymore. He also, came to Florida, where I live now and went on a cruise with another girl, before I found this out he told me he was coming to Florida to visit me, but around this time he told me he met someone else and he never really loved me, that we were just friends,and that maybe one day if I was in better shape we could be together, so I was confused as to why he was coming to see someone he felt this way about, then the day before he came he told me the real reason he was coming to Florida was to go on a cruise with another girl, and he wanted to see me after..After that I blocked his number, but ended up forgiving him a week or two later. But even after all that he still disrespected me and treated me poorly when this should’ve been a time he was amazing to me.

I asked him if I could spend New Year’s and go to a concert with him and he told me I didn’t look good enough to be seen with him there..but Later on he said he needed me there and was so happy I came. I just cannot keep being put down so harshly, by the one person that is supposed to bring me up, I just don’t understand what is wrong with him, or what is wrong with me. obviously he can be good, and sweet to me and we have had some amazing times together, which is why I love him, but hearing him say such hurtful things makes me question his love for me. I just don’t know what to do.

Dear Lovely Letter Writer,

Your email subject line was “Does my boyfriend actually love me?

No. He doesn’t. He may say that he does, or have feelings inside his head that he calls “love,” but the way he treats you isn’t how love works.

Question Time:

Is this the kind of treatment you want from a boyfriend?

Are you okay with it when he criticizes your body and makes you feel ugly?

Are you okay with him constantly lying about his relationships with other girls and women?

Do you think that “girlfriend” is a role that you must constantly audition for and prove you deserve? Over the course of multiple years? At the cost of your well-being and self-esteem?

I don’t have any scripts that will make him behave better or turn into the boyfriend you need and deserve. He won’t ever change or stop these asshole behaviors. He has been grooming you since you were 17 to accept his warped version of love and what your body should look like and how people treat other people (and he likely grooms and mistreats all his other “not quite girlfriends” too). He is an emotionally abusive asshole who picks on you to make himself feel better. He behaves according to an all-too-predictable and recognizable pattern.

You end your letter with: “I just don’t know what to do.”

You DO know what to do and you already tried to do it (block him forever). You just gotta make it stick this time, and I’d love to help you do that.

Right now, you could text him and say “I am breaking up with you, goodbye.”

Then (also right now), you could block him on all possible forms of communication and delete his number from your phone. It doesn’t matter what he thinks or feels or says – once you decide to break up, it’s over.

Then, you could let yourself get really, really angry about how he’s treated you.

Next, imagine your ex-boyfriend as a flat piece of paper.

I want you to mentally crumple that piece of paper.

Make it really tiny and dense.

Did you crumple it? Can you feel it crushed very tight inside your fist?


Now I want you to mentally launch it into the center of the sun.

The Sun

Whenever you start to think about him or miss him or think you might want to talk to him, picture the piece of paper going into one of those extra bright burny bits. *Poof* Goodbye forever!

This dude has been shredding your sense of self for 2 years, so it might take more than that to get him out of your system. That’s okay! If you have access to a counselor (maybe at school?) I want you to find one and tell them everything. You could show them your letter from the blog, if you don’t know where to start talking about it. If you don’t have a counselor available, has free online resources, including an online chat staffed by trained volunteers, if you need to talk to someone in confidence right now. Also, check out The Sunflower Project if you need a reminder that people can and do move on. Leah Zeiger is a survivor of an abusive relationship that started in high school. She and her dad made an amazing film about that, together.Being in a relationship like yours can be incredibly isolating, but you are not alone, and ending things with this guy it is not the end of anything except you feeling awful all the time.

“…it’s just that I love him for who he is and all of his flaws or imperfections make him who he is…” “(But I LOVE him, Captain Awkward!)”

You do love him, and I’m not going to tell you that that’s not real, just, that love is more about you and your wonderfulness and loyalty and the spark of joy inside you than it is about him. I mean, let’s unpack that – You love this guy, “despite his imperfections,” but all he does is point out what he sees as your imperfections and tell you how it makes you not quite good enough for him (except when it’s convenient for him). He (and our shitass culture) has sold you a story where your love and the achievement of a “perfect ass” can conquer his sexism and cruelty to you if you just believe and try hard enough, but it can’t. It never will. Your body is already perfect just the way it is (and it always will be), and you You can’t love someone into being a better person or into treating you with basic kindness and respect.You gotta find a way to take all that love you feel for him right now and shine it on yourself.*

If that’s too overwhelming to imagine just yet, that’s okay. There are more kinds of love than romantic love. Look around you for the people in your life who make you feel good, throw a little love their way, and trust that it will come back to you somehow.

We are rooting for you so very hard.

Animated ghost giving a ghost hug.

*Text here.

Read the whole story
5 days ago
Melbourne, Australia
Share this story
Next Page of Stories