Tag Archives: Tech industry

Photograph of two hands, one holding a magnifying glass, the other a soldering iron (by Paul Downey)

Hiring based on hobbies: effective or exclusive?

“When I’m interviewing a candidate, I ask them what they do in their free time.” It’s not unusual for me to hear this from people who are in a position to influence hiring for software jobs. Often, though not always, these people are male. The implication is that the interviewer prefers candidates who have sufficiently interesting hobbies (according to the interviewer’s sense of what’s interesting), and won’t give preference to (or will weight negatively) those candidates who either don’t have hobbies, or who the interviewer judges to do boring hobbies.

As far as I can tell, hiring based on hobbies has two major possible implications for software jobs. One is that it’s easier for people who hack on open-source code in their free time to get a software job. I guess the idea there is that if you want to choose a good worker, you pick someone whose hobby is doing more work. Mary Gardiner previously addressed the issue of leisure-time open-source hacking as a job qualification, in “Is requiring Open Source experience sexist?” on this very blog.

The other possible implication is that “interesting” hobbies don’t necessary have to involve programming, but you do have to have a hobby and it does have to be interesting to your interviewer, which probably means it has to be something that wouldn’t be a surprising interest for a hetero white cis male software engineer. From hanging around many such people and observing what they find “cool”, I can surmise that ideally this would involve fooling around with robots or circuits or wires. It should involve building things and tinkering for the sake of tinkering. Cooking, crafting, and other hobbies that have a practical application — that involve skill and art, but aren’t practiced just to impress other hackers — probably aren’t going to count for a whole lot of status points.

You’ll be disadvantaged on both counts, of course, if your spare time gets spent taking care of your family or doing the household work that women in relationships with men are often disproportionally saddled with (see Arlie Hochschild Russell’s book The Second Shift for more on that.) Or if you can’t afford to do hobbies that require more materials than a pencil and paper. You also may be disadvantaged if you have a disability: for example, if you don’t have the physical coordination to mess around with wires. Closer to my experience, you may be disadvantaged if you’re someone who has mental illness. As someone who’s been living with clinical depression for 20 years, a lot of the time it’s all I can do to put in my eight hours in a day and then get home, feed the cats, and throw together something to eat. Energy and motivation are not evenly distributed across the population.

Because status hierarchies in geek circles are frequently about who has the assets (in both time or money) to do the coolest projects in their spare time, I often feel excluded when other people talk about what they do in their free time, and guilty because I don’t have enough executive function to do much after work besides recharge so I can do more work the next day. I love my work, but like lots of kinds of work, it’s a source of stress for me. I imagine the same is true for most or all people who do software: I doubt there’s anyone who never experiences stress as part of their job. What’s not universal is how people deal with stress, and how much time off a person needs to recharge from it. Whether or not someone gets pleasure from hacking in their free time is affected by their social placement: the amount of time doing non-work-like activities someone needs before they can return to demanding intellectual work is affected by their physical and mental health; how many worries they have about money, relationships, and other non-work-related stressors; how many microaggressions they face as part of an average working day; whether they were brought up with self-esteem and a sense that they have the ability to recover from failure, or had to learn those things on their own as an adult; and many other factors. Few of those factors have to do with an individual’s level of dedication to their work; many are implied by where someone finds themself placed within a variety of intersecting social structures.

Recently, someone online said to me that he hires based on hobbies because he wants to hire interesting people. I’ve seen other people imply that there’s something even morally suspect about somebody working an engineering job just for the money, and that someone who doesn’t do the same stuff in their free time is obviously just in it for the money. Of course, that’s classist. It’s easier to feel like you’re motivated by the sheer love of your work if you don’t really need the money.

But besides, if you decide someone isn’t worth hiring because they don’t have “interesting” hobbies, what you’re really saying is that people who didn’t come from an affluent background aren’t interesting. That people with child care or home responsibilities aren’t interesting. That disabled people aren’t interesting. That people who have depression or anxiety aren’t interesting. That people who might spend their free time on political activism that they don’t feel comfortable mentioning to a stranger with power over them aren’t interesting. That people who, for another reason, just don’t have access to hacker spaces and don’t fit into hobbyist subcultures aren’t interesting.

You might counter that a person’s hobbies are relevant to their level of commitment to or interest in their work, and thus it’s justifiable for an employer to ask about them. However, this sounds essentially similar to the idea that women are to be looked at with extra suspicion during hiring, involving the assumption that women are cis and have relationships with cis men, and that cis women who have relationships with cis men will take time off from work to have babies. Statistically, there might be some truth to this — by the way, I’m not sure what evidence there is behind the assertion that people who do software or engineering in their spare time make better software engineers than people who play music or sail boats or bake muffins. Even so, it’s illegal (at least in the US, and possibly elsewhere) to use gender and marital status as bases for discrimination. People with some types of disabilities or chronic illnesses might sporadically be less productive at work, but it’s still illegal to ask about health conditions. Obviously, I’m not suggesting we should legislate against asking about hobbies as part of the interview process. It’s impossible to ban every type of question that might be used in a discriminatory way. It’s up to individual hiring managers to be ethical and mindful about whether they’re asking a question to evaluate a candidate’s abilities directly, or to make sure the candidate is sufficiently similar on a personal level to the manager’s mental ideal of what a programmer is supposed to be. I happen to think evaluating people on their skills rather than whether they fit the profile for a particular social clique is a better way to identify good workers.

A less cerebral “hobby” that may also be compulsory, as Ryan Funduk wrote about, is drinking. As he points out, when work-related social events revolve around alcohol, this excludes people who can’t or don’t want to drink as well as many women, who might enjoy drinking but don’t feel comfortable being in groups of drunk men (especially not when pretending that alcohol erases responsibility for sexual assault is a staple of rape culture). I haven’t personally experienced this much, since I’ve spent more time in academia than industry, but it’s something to discuss in the comments.

Have you ever found that your hobbies were an asset when getting hired? Or have you felt the need not to mention a hobby because it seemed like more of a liability? Have you felt pressure to do extra unpaid work just to be a competitive candidate for software jobs? Or to take up recreational pursuits you didn’t really like just to increase your level of cultural fit in your workplace?

Photograph looking up several floors of outdoor stairs

you keep using that word

This is a guest post by Garann Means. This post originally appeared on her blog.

I keep seeing the word “meritocracy” pop up, mostly in discussions that seem to have stemmed from Faruk Ateş’ “A primer on sexism in the tech industry”. Do yourself a favor, don’t go googling. It’s the same shit:
“Sexism isn’t real because I’m a woman and no one did the sexism to me!”
“Women resent being treated as women instead of being evaluated solely on their capabilities!”
“You’re a sexist!”
“Some people called me a sexist after my sexist blog post and it hurt my little feelings and I’m leaving the internet!”
“You GUYS, remember this is supposed to be a meritocracy.”

Except no. No it fucking isn’t. Because a meritocracy is not a real thing. It is a joke.

The word meritocracy comes from a political satire. It was never meant to be something we should aspire to. It was the opposite, actually, a warning about how we rationalize what we believe we’ve “earned”. If that sentence doesn’t seem to you applicable to the tech industry and our cyclical discussions about sexism, racism, and even occasionally classism, go get yourself another cup of coffee.

There’s some dumb bullshit in one of the current crop of reaction posts waxing poetic about “hacker culture,” and its freedom of speech and lack of PC dogma. Hacker culture was a bunch of white dudes. Hacker culture is a great example of a meritocracy. Some of the most privileged of the privileged got together and formed a community around the idea that they were smarter than everyone else. They created an arbitrary set of metrics for membership and according to their metrics, they triumphed. This was the first time in the history of the world white men had experienced the elation of peer recognition.

A meritocracy is not a system for locating and rewarding the best of the best. If it were, the “best of the best” in almost every goddamned industry or group on the planet would not be a clump of white men. I’m having trouble finding good stats on this, but white men are something like 8% of the world’s population. When you go to a fucking conference and you look around at all the white dudes, do you really honestly think, “Wow! What a bizarre fucking statistical anomaly it is that basically everyone with the special magic gift of computer programming happened to be born into a teeny tiny little demographic sliver of the population”? Of course you don’t. You don’t think about it. You focus on telling yourself that you’re supposed to be there, because you’re so fucking smart, and if other people were as smart or, if you prefer, they were “technically inclined,” they could be there just as easily.

A meritocracy is a system for centralizing authority in the hands of those who already have it, and ensuring that authority is only distributed to others like them or those who aren’t but are willing to play by their rules.

Somebody on twitter told me that when the computer industry was overwhelmingly female, it was due to merit. I think that makes a really good counterpoint to this meritocracy bullshit. Because no, it was not due to merit. Merit didn’t fucking enter into it. Most of those women had no experience in the industry and – even if we accept the lol-worthy premise that merit can be objectively measured – there was no way to evaluate their merit as computer scientists. That’s not to say we shouldn’t use that as a template. We absolutely should. Those women had jobs and were happy to have them. They worked hard. Those who stood out did so because they had demonstrated that their work was good (through their work, not through their savvy) and because standing out and advancing the field was necessary to their work. I would rather work with a roomful of those women than with the arrogant, privileged brats our industry too often recognizes “merit” in these days.

If we met the utopian ideal we toss around in blog posts, we’d still have lots of middle-aged women in this field. We’d have black people. We’d have Asian people – not a smattering, but a majority, cause the world is mostly Asian people. We’d have an even ratio of men and women. Because if there’s one thing I’ve learned after sixteen years in this career, it’s that if a middle-class white boy who literally never had a job before getting a sweet internship at some cutting edge technology company can eventually, through practice, become a passable computer programmer, anyone can do it. If there’s one thing I’ve learned after thirty-three years of being alive, it’s that if you see middle-class white boys flocking in droves to a particular career path, it’s a pretty fucking easy job and you should try and get yourself one like that.

I guess that’s a little mean. Sorry, middle-class white boys. I’m not calling you dumb. I’m calling you soft. I’m calling myself soft, also, and everyone else who works in this field. What a meritocracy really protects us from is challenge. If we don’t even allow most people through the gates, we don’t have to worry that we might pale in comparison to them (pun intended). There will always be a place for us in an industry we keep others out of. That’s why we should seek out diversity – because the lack of it makes us weak.

If you give a shit about this industry’s goals beyond making yourself look smart and cool, for fuck’s sake, stop calling it a meritocracy.

Linkspam: The Gathering (12 October, 2012)

  • Viewpoint: More women needed in technology | BBC: “Dr Gloria Moss, a gender marketing expert, confirms that when targeting women, having female input on the design team is crucial: “In design preference tests, I’ve always found extremely strong statistical evidence for ‘same-sex preference’. Men tend to prefer the designs that men produce, and women prefer the designs that women produce.””
  • E-mails Ignored, Meetings Denied: Bias at the Search Stage Limits Diversity | Knowledge @ Wharton: “Using an experiment that explored the treatment of prospective applicants to doctoral programs, they found that professors were significantly less likely to be responsive to communication from women or minority applicants — and that the level of unresponsiveness was greater within academic disciplines that tend to pay more, and at private institutions, where faculty salaries are higher on average.”
  • A primer on sexism in the tech industry | .net magazine: “Designer and developer Faruk Ateş, the man behind Modernizr, says that sexism is hurting our industry in more significant ways than most people realise. Here he explains what it’s all about and what we can do to address this issue.”
  • Busting a Cyberstalker: How Carla Franklin Fought Back | The Daily Beast: “After just a few casual dates with a guy, Carla Franklin faced six years of harassment, stalking, and cyberbullying. Now she’s suing him—in a new frontier of online crimes. Her story, as told to Abigail Pesta.”

You can suggest links for future linkspams in comments here, or by using the “geekfeminism” tag on delicious or pinboard.in or the “#geekfeminism” tag on Twitter. Please note that we tend to stick to publishing recent links (from the last month or so).

Thanks to everyone who suggested links.

Quick hit: “How Git shows the patriarchal nature of the software industry”

The most seemingly trivial design decisions in a software project can show who is not present as part of that project. And the absence of people in minority groups can result in decisions that exclude people in minorities from joining, in a feedback loop of self-reinforcing exclusion.

Git is a distributed version control system that has gained increasing popularity over the past few years, especially in free and open-source projects, despite a user interface widely regarded to be user-hostile. While most of the issues with git’s user interface are equal-opportunity annoyances, there is one that is specific to trans people who change their names, people who take or drop their spouse’s surname on marriage or divorce (who in Western culture are usually women), and the overlap between the two groups. Megan at “A Megahbite of Feminism” shows how the design choice to make the committer’s name and email address part of the data that determines the unique identity of a given commit can have a negative effect on women and trans people:

To try and put it simply, the author of a commit is tied in to the identity of the commit itself. If you change the author, it’s treated as an entirely new commit. Anyone who has grabbed a copy of your original commit and made subsequent changes on top of it finds themselves orphaned from the history of the project. To use a crude analogy, it’s like you rip the trunk of a tree out, while the branches are magically left hanging in the air, connected to nothing and isolated.

Of course, it’s not that the designers of Git tried to make it difficult for committers to change their names. It’s likely that most of them just didn’t think about what would happen if a developer needed to change their name retroactively, because most of the people who have worked on Git are cis men. They aren’t expected to change their names if and when they get married or divorced, and having cis privilege, they don’t need to change their name to something more consistent with their gender. Nevertheless, the inability to change one’s name retroactively without disrupting others’ work can mean that trans people — particularly trans women, who are likely to face harsh social stigma in any space where their trans history is known — will have to cease to contribute to their projects when they transition.

What other seemingly innocuous software design decisions contribute to exclusion?

Update: I’ve had to moderate a lot of comments for ‘splaining. When replying, avoid arguing from authority and keep in mind that other people have had experiences that are real even if you haven’t personally experienced them.

Second update: I’m continuing to moderate comments that are condescending or dismissive, because comments like that aren’t constructive and don’t create a useful discussion. Please familiarize yourself with our comment policy. Particularly, note that anonymous comments (those with an email address that can’t be tied to a consistent identity, such as anonymous mail services) are not permitted here.

Cookie of the Week*: dherman suggests playing the blog post, not the CV

Cookie of the Week* is an occasional series highlighting action in the geek community to fight sexism, in order to show that fighting sexism is possible and happening.

When a poster on Hacker News disliked a blog post of Hilary Mason’s and disparaged not only the contents of the post but also criticised her job title and her self-description, dherman replied:

[Disclaimer: I have decades of first-hand knowledge of Hilary's awesomeness, going back to when we were CS students together in college. So yeah, I'm defending my friend.]

I’d like to ask you to think twice before publicly questioning someone’s credentials like this. Whatever your intentions, picking on someone’s CV just because of a blog post you disagree with is not only rude, but it sends a message — particularly to women in tech — that if they speak publicly, if they offer up their opinion, they will be attacked not about the content of their point but about their competence to speak at all. I believe this kind of attack has real consequences on our field, and I would urge everyone to show everyone the respect they’d want for themselves.

(via Tim on Twitter)

Enjoy some Tetris cookies, dherman:

Tetris cookies
Tetris cookies by andremache

Does anyone else have any cookies to spare this week?

* Disclaimer: cookies may not be baked weekly!

A Problem With Equality

This post is cross-posted to Tim’s blog on dreamwidth.org.

“Most women fight wars on two fronts, one for whatever the putative topic is and one simply for the right to speak, to have ideas, to be acknowledged to be in possession of facts and truths, to have value, to be a human being. ” — Rebecca Solnit, “Men who explain things”

A Problem with Equality

In March 2012, Gerv Markham, who works for the Mozilla Corporation dealing with issues of community and governance, ignited a controversy about what kinds of content Mozilla tolerates on its Web properties. That debate opened the broader question of whether the Mozilla Corporation should have a code of conduct for its employees, as well as whether the Mozilla project as a whole should have a single code of conduct for its employees and volunteers. An internal — but world-readable — discussion on Mozilla’s online discussion group, mozilla.governance, ensued, examining the nature and desirability of community standards for inclusion.

That was about as neutral and objective as I’m going to be in this essay. In what follows, I analyze the controversies of March and April, while sharing a hefty quantity of my own feelings and opinions about them. These opinions are my own and solely my own. While I’m an employee of the Mozilla Corporation, in what follows, I am speaking only for myself. I’m not writing from the perspective of someone who has formal education in political and social analysis; the only authority I claim to have is on my own lived experiences. Thus, I don’t have citations at hand for every idea; moreover, much of what I am saying here has been said before, by people who make it their calling to interrogate sexism, homophobia, racism, and other social structures of domination. I’m writing for an audience of people who think critically, reflect openly, and draw their own conclusions.

Disclaimers: please read them.

What happened

In what follows and in the subsidiary links, I’ll frequently use the sociological concepts of power and privilege. If you don’t feel familiar with notions of power and privilege as they play out in everyday life and interaction between people, or if you don’t understand how the same person can have power over others in one situation and be powerless in another, I’ve written a brief primer about these concepts.

Planet Mozilla (“Planet” from here on) is a blog aggregator that aggregates the blogs of people in the Mozilla community — both paid Mozilla Corporation employees, and community volunteers — who choose to maintain blogs and include themselves in the Planet newsfeed. The sidebar states: “The content here is unfiltered and uncensored, and represents the views of individual community members.” Glancing at Planet, most content is related to Mozilla projects, but some personal posts from community members, about non-Mozilla-related topics, appear — some people syndicate their entire blogs to Planet, while others only syndicate posts that have a particular tag (or keep completely separate technical and personal blogs). For example, I syndicate my work-related posts on my Dreamwidth blog to Planet Mozilla Research (not part of the main Planet) by tagging only those posts with the tag “research”. My posts about politics or what my cats are doing don’t show up.

I look at Planet sometimes, but don’t read it every day. Some Mozilla employees, however, are required by their managers to read it regularly, in order to stay abreast of what’s going on in the community.

On March 6 while I was getting off Caltrain to go to work and reading email on my phone, I saw an email on the Homozilla (internal Mozilla LGBTQ and ally group) mailing list about the fact that a post from Gerv Markham [Content note for homophobia and advocacy of legislative violence in post and some comments], a Mozilla employee who works remotely from the UK, had written a blog post encouraging people to sign a petition distributed by the Coalition for Marriage, a homophobic hate group, that would endorse the legal codification of marriage in the UK as “the voluntary union for life of one man and one woman to the exclusion of all others”. This post appeared on Gerv’s personal blog, but as per his settings, all of his personal blog posts were at the time syndicated to Planet. Thus, without him taking explicit action, a post encouraging people to support social inequality and discrimination against a group into which many Mozilla contributors fall appeared on a Mozilla Web property.

I’ve only been at Mozilla for a year and a half, so I don’t have too much context, but people who have been at Mozilla longer have said that the discussions that resulted were the most intense of any of the debates that have occurred about what content is acceptable on Planet. A number of Mozillans, both people who are out as LGBTQ and people who are allies, wrote blog posts or tweeted saying that it was wrong for a Mozilla Web property to be used to spread hate, and that we needed to set a clearer standard for what content is acceptable either on Planet specifically, or on mozilla.com and mozilla.org domains in general. I think most or all of the people in this category would agree with what the person who posted the first Homozilla email said: “Gerv is entirely entitled to have his opinions on gay marriage, but I absolutely do not want to see them in Planet Mozilla, just as I don’t expect to see pro gay marriage posts there or posts about the upcoming US election.” Another Homozilla member wrote, “Even at work, we’re not free from being reminded that some say we’re different, not normal, and not worthy of the same rights as everyone else”, which is something that I agree with and that I’ll attempt to explain and flesh out in much of the remainder of this post.

Posts from Al Billings [Content note for homophobic derailing in some of the comments, but not in the post itself], Graydon Hoare, and Christie Koehler [Content note for derailing in some comments] soon after March 6 describe why many of us found the presence of Gerv’s post on Planet objectionable and why some of us feel that it illustrates the need for community conduct standards at Mozilla. I’ll avoid repeating what they already said very well. I wrote an initial reaction as well on the 6th.

The same day, the Planet Mozilla Module Team (made up of both Mozilla staff and volunteers) published a response [Content note for derailing in both post and comments] to the concerns raised by people like Al, Graydon, Christie, and myself, as well as to a letter from Homozilla people that was sent privately, and possibly to other private communication. The line of reasoning in this response is an old one: speech like Gerv’s must be allowed because of a social-libertarian commitment to freedom of speech, which is assumed to be part of Mozilla’s mission. Somehow, this means that Planet Mozilla must be a forum even for content not related to the project, so long as one project member wants to use the megaphone for that purpose.

Through private communication, it became clear to me that the Mozilla HR department and legal team do not see any legal liability on their part to allowing unrestricted (more later about whether it’s really unrestricted) free speech on a mozilla.org Web site. As far as I can tell, they do not believe that speech that helps construct the inferiority of a particular social group creates a hostile working environment for employees, because they believe that nobody is required to read Planet as part of their job responsibilities. However, that belief is simply incorrect: some people are required to read it. And they do not appear to believe that such speech damages Mozilla’s reputation, because they believe it is clear that Planet, as its disclaimer said, “represents the views of individual community members” and not of the Mozilla Corporation or Foundation as a whole.

User interface design principles suggest that the guiding principle for an interface should not be how its developers prescriptively think its users should understand the interface, but rather, how its users will understand the interface, even if those users’ understanding is incorrect or naïve. The idea is that if the user comes to a wrong conclusion from looking at the interface, that’s the responsibility of the interface designers — they should have made the interface less confusing — rather than the user’s fault. That’s because computers should be tools for people rather than people serving computers.

Likewise, if people outside Mozilla read Planet and assume that the opinions there are representative of or endorsed by the company or the community, the answer to that is not to say they’re wrong, but to either make the user interface of the site clearer (not everyone will read a disclaimer in small text away from the main flow of the page), or simply avoid including content that could go against the company’s values or damage its reputation. At least in this sense, the customer is always right.

Separately, I’ve written about my personal views on the issue of same-sex marriage (the term I prefer is “universal marriage”) and why I find opposition to universal marriage to be baffling and incoherent, for those who wish to appreciate what someone who is simultaneously regarded as more than one sex and gender by government agencies might think about restricting marriage by sex or gender. Otherwise, there’s so much that’s already been said about universal marriage that I don’t feel the need to say more. Anyway, this post is about general patterns that occur in discussions about many different forms of social power imbalances, and not primarily about the specifics of homophobia or heterosexism.

The conversations that happened as a result of Gerv’s post and of the response from the Planet Mozilla Module Team eventually led Mitchell Baker, the chair of Mozilla, to initiate a
[Content note for more or less every kind of psychologically/emotionally abusive comment directed at minority groups that's possible, not in the original post, but in the replies] on the open mozilla.governance mailing list/newsgroup. In the unstructured discussion that followed, I saw some comments that were far beyond the level of harmfulness and hurtfulness that I would expect from colleagues. I read a number of open Internet fora, and some of these comments were worse than I would routinely expect from those fora.

In the rest of this essay, I won’t talk much about Gerv’s original post. I don’t mean to make him into the bad guy. I am less concerned about individuals and their opinions or decisions than about systems and processes, and I’m going to talk about how underlying, external systems of oppression — systems that Mozilla did not invent, that predate its existence by centuries — were nevertheless replicated inside Mozilla during the community discussions that followed. Again, my choice of the word “oppression” is quite deliberate, to emphasize the real, damaging nature of being treated with unequal respect and dignity. Being oppressed as queer people corrodes our self-esteem and limits our life chances. It also stops us from contributing all that we can to whatever endeavors our talents and desires would normally allow for.

Why it matters

First of all, I am writing about the Mozilla community as a member of the community. I am as much a member of the community as anyone else who is involved in Mozilla’s projects, and I belong here as much as any other Mozillan does. If you want to ask me why I don’t just go somewhere else, the answer is because this is my community too, and I like it here. Out of all of the parts of the world that I could choose to focus on changing, I choose to focus on the community of people who work on software — and specifically in that part of the community that happens to employ me — because it is home to me, and I don’t have another home. If you’re still wondering why I bother or what my stake in it is, here you go.

In the discussions on mozilla.governance and on various blogs, many people claimed (implicitly or explicitly) that there was a tension between protecting free speech and protecting people in minority groups. They claimed that there was a tension between the right of people in minority groups to feel safe and comfortable in a space, and the right of people in majority groups to say what they want.

I challenge the precept that this tension is difficult to resolve. In part, I think the apparent tension arises from the logical fallacy that doing nothing is the neutral choice. Actually, adopting a laissez-faire “free speech” policy in an organization is to take a political position: it means taking the position that existing power dynamics from the larger society will and must recreate themselves in your organization. To do nothing is to let bullies be bullies, because bullies always bully when they get the chance to and when there are no checks and balances against bullying.

So in reality, the choice isn’t between taking a laissez-faire, neutral position; and adopting a code of conduct that excludes some form of speech. The central conflict is:

Shall we implicitly exclude people in socially stigmatized minority groups, or shall we explicitly exclude people who cannot or will not behave with respect?

Another way of asking this question is to ask “In a conflict between abusers and people who are being abused, should we side with the abusers or the victims?”

To some people, the language of “oppression”, “abuse”, and “victims” may seem harsh or strident. To some people, speech that proclaims the inferiority of a particular social group may seem like “only words”, words that are only as hurtful as the recipient chooses to let them be. I disagree, and have written a number of subsidiary essays to explain why. Together, they add up to a lot of words, but I hope that after reading them, most people will at least be able to understand why I see the choice between excluding minorities and excluding people who choose not to behave with respect as the central choice here, even if they disagree with my conclusions.

That one form of exclusion (tolerance of disparaging remarks about minorities) is implicit and the other form (formal codes of conduct) is explicit doesn’t make the implicit kind of exclusion any less real. You may believe that you, personally, don’t exclude anyone, and that you never do anything to exclude people who are socially stigmatized. Even if you don’t intend to exclude people, you may still be engaging in behavior that has the effect of excluding people, and you’re still responsible for the consequences of your actions even if you don’t intend those consequences.

There is no neutral choice. No matter what position the leadership takes, someone will be excluded. If this is unclear, please keep reading. If what I’m writing makes you feel guilty or defensive, please take a moment to step back and think about why.


What I’ve just written may raise a number of questions for some people. I’ve tried to anticipate, and answer, some of those those questions.

  • “Why are you talking about power so much? I don’t have power over you.” Power and privilege operate in ways that often make people who have power unaware that they have it.
  • “How can I be engaging in behavior that oppresses or excludes? I would never intend to do that, after all; have you ever seen me treating an LGBT person badly?” Understanding how systematic patterns of behavior act themselves out through individuals may help answer that.
  • “Don’t you think it’s rather harsh, describing your pain as ‘oppression’? Isn’t that a word that refers to things happening in a far-off country or in the distant past?” Here’s what “oppression” means to me, and why I don’t see any satisfactory synonyms for it.
  • “Is it really that bad, what happened? Can’t you just ignore it and not let it have power over you? After all, no one meant harm, and anyway, if you’re so angry, how do you expect anyone to listen to what you’re saying?” These questions are a form of emotional invalidation, an insidious set of learned social behaviors that have the effect of making people in oppressed groups question their own understanding of reality in order to silence discussion of abuse.
  • “No, really, is it that bad?” Well, yes, it is; for me, being told I’m inferior is painful, and I’ve tried to explain what that’s like.
  • “So what should we do about it?” I don’t have a single answer, but here are some possible solutions.
  • “What does all of this have to do with Mozilla’s mission? And why are you being so critical?” My conclusions might answer that.

Everything I’ve written in the linked-to posts is an attempt to clarify some aspect of the single question above, about explicit versus implicit exclusion.

Summing up

It may appear that we’re stuck excluding some people one way or the other, and if exclusion is always bad — if the badness of intolerance means we must also tolerate intolerance itself — isn’t there no way out?

I reject that premise. To exclude people based on who they are — based on qualities that either cannot be changed or that there is no good reason for them to change, such as gender, sexuality, race, ability, age, shape, and so on — is to exclude needlessly, to harm the community by excluding people who would otherwise contribute to it. To exclude people based on what they do — engaging in anti-social behavior — is fair. It says that anyone can be part of this community as long as they’re willing to observe community standards; to do what’s best for the community; to play fair. If my employment agreement says that I must protect confidential information and trade secrets, and that I will use company resources wisely, I don’t see that as an unfair limitation on my rights. I see it as something I’m being asked to do to maintain a healthy community. I think the same should go for a request to behave in a way that’s inclusive and welcoming. Expressing speech at work that is racist, sexist, homophobic, ableist, or that otherwise maligns an entire group of people based on identity rather than based on behavior hurts the company and project as a whole, by making it harder for some people to contribute. (If you see being queer as a matter of behavior that any individual can give up without fundamentally compromising who they are, and are not willing to trust the lived experience of many queer people when they say it’s no more possible for them to become heterosexual than to become a redwood tree, I suppose I have nothing more to say to you.)

I’m disappointed that some Mozillans objected to other people’s objections to being demeaned in the workplace. I understood their arguments as essentially saying they felt that being asked not to be an asshole was a violation of their rights. I’m disappointed that some of my colleagues would respond to a request to stop hurting people by asserting that they have the right to hurt people.

I’m also disappointed that Mozilla leaders entertained the “free speech” argument. The majority must not determine minority rights — that never ends well for minorities, and in fact, it doesn’t end well for the entire group, because the community needs minority members’ contributions. That’s why it’s so important for leaders to take a stance in favor of inclusion. I didn’t see the leaders do that — instead, I saw them fumble about whether it was more important to them to include everyone who’s capable of contributing to the project respectfully, or to protect the freedoms of the minority that claims it’s their right to abuse others. Mozilla can retain its commitment to the free exchange of ideas while also declining to be a forum for ideas that attack people in vulnerable groups. This decision would violate no one’s freedom of speech, as everyone is free to say anything that’s legal in their home country when they are not at work or using their employer’s computing and networking resources. The fundamental flaw in the “free speech” argument is the supposition that freedom of speech means freedom from having to face the consequences of one’s speech. It does not.

Leaders have to make a choice about who to exclude. Including everyone is not an option: every community excludes people who harm the community and do not respond to requests to stop doing so. The question, then, is who in the community merits protection from harm. I think the answer to that question should be “everyone”, not just the people who conform most closely to social norms about gender and sexuality.

We can exclude people based on who they are, or we can exclude people based on what they do. I prefer a community built on norms for healthy behavior, one that has a mechanism — to be used as a last resort — for excluding people who repeatedly violate those norms. I think such a community is better and safer for me to work productively in than one that is built on a hierarchy in which a smaller sub-group rules, and excludes others capriciously, for no reason other than being different. If your response is that a community like Mozilla doesn’t need the contributions of people in minority groups, I guess there’s no way I can persuade you otherwise, but I would wonder why you think we can afford to turn people away for reasons unrelated to their technical and collaborative ability. I think that protecting the open Web is a job that requires the help of everyone who’s willing to commit to it.

I think we can do better, and moving forward, I hope that we do better. I hope that the community participation guidelines serve to make Mozilla a more inclusive community and that in the future, dialogue will be less about people defending their privileges and more about people listening to the experiences of those who are unlike themselves. Ultimately, even though I know some of the intellectual reasons why, I still don’t get why we can’t build great open-source software and protect the Web while also setting standards for ourselves about how we treat each other while we’re doing it.


I thank Gwen Cadogàn, Ellie Collier, Jessamyn Fairfield, Graydon Hoare, Carolyn Hogg, Christie Koehler, Lindsey Kuper, Sheree Schrager and Alley Stoughton for reading drafts of this essay and providing useful feedback. Several other people also gave valuable feedback who did not grant permission for me to thank them by name; my gratitude to them is no less. I also thank Juli Mallett for originally drawing my attention to “Letter from a Birmingham Jail”. Inclusion on this list does not necessarily imply agreement with or endorsement of any point of view in this set of essays. All of the opinions contained in it are solely my own.

A closeup photograph of an open lipstick, with a blurry laptop in the background (by Aih)

The Ladycoders Project, Interviewing and Career Advice

This is a guest post by Addie. Addie is a software engineer specializing in web applications in the Portland, OR area. She’s actively involved in the Portland tech community, including the local women-in-tech group Code N Splode.

This post originally appeared on her blog.

Last fall, I attended the Grace Hopper Celebration of Women in Computing (GHC) and had a transformative experience. Over those two days of sessions and networking, I felt like I reconnected with every aspect of myself that has existed throughout my 12 years writing code, and this had a way of healing some old career wounds in a way nothing else really has. GHC is interesting because it brings together women from all stages of the computing pipeline – academics, industry veterans and novices alike, and students – so many students.

Many of the conference’s sessions focused on career development, and rightly so. Many of the students in attendance were on the cusp of starting their careers in industry, and the conference provided some crucial guidance. Some sessions were tuned to issues female developers tend to grapple with more than male developers – Impostor Syndrome and other crises of low confidence, for instance. In one of the most personally powerful moments of the conference, the woman who was my only female teammate on a team of 30+ men in my first job out of college sat down next to me during a “Confidence Building Tricks” session. This woman has been my role model both personally and professionally in the six years since I met her, and this was the first time I’d seen her since leaving that job. At the behest of the workshop organizers, she turned to me and bragged, “I run the Internet” (and she does!) in her best Schwarzenegger voice, and I felt elated.

The final session I attended at GHC involved an informal, rotating panel of women in industry giving career advice to women just about to launch their careers. Everybody had different stories, and the hour of discussion that followed was really eye-opening. I learned that I hadn’t been the only person who’d cried during my first job interview. I learned that I wasn’t the only person to find my college’s career center training to be mostly insufficient when it came to technical interviewing, because technical interviews often reduce a person to their skills and can feel very dehumanizing when you’ve been trained to expect something entirely different. I heard about a variety of industry experiences very different from my own, and reconnected with the nervousness that is standing on the cusp of the unknown as a college graduate-to-be.

After the session, one of the college-age women pulled me aside and said she wanted more advice about interviewing, specifically technical interviews. I reiterated that she should take traditional interview training with a grain of salt, because technical interviews rely so heavily on problem-solving and proving technical skill. I recommended that she investigate the wide array of websites that post sample technical interview questions and problems to solve, and to practice working through the solutions to those problems not only on her own but out loud and with others – to get comfortable “working on the whiteboard”. I told her that the technical content in interviews varies substantially depending on the company – and even the interviewer!, and that she should expect to occasionally deal with problems that are intentionally difficult and not easy to solve. I wrapped up by telling her that it’s easy to feel discouraged and frustrated with oneself after dealing with the rigor of some technical interviews, but that’s a normal response and to not think she wasn’t cut out for this if she has a bad interview or practice session. Once you get the hang of it, I said, technical interviews can actually be a lot of fun.

One of the most difficult aspects of the Grace Hopper conference was interacting with women who approached the “gender in tech” issue from a different angle than me. Many of the goodies in the Expo Hall celebrated being a coder in the same breath as stereotypical girliness in a way that I find quite problematic. But I also saw college women who loved the problematic swag and was reminded that, a decade ago, seizing upon my girliness as part of my identity as developer was an act of rebellion.

I squirmed when women – especially industry women, and especially those on stage, in panels – made gender essentialist claims (implying that women were superior in certain skilled areas). I wished these women wouldn’t make such claims in front of a room full of students who looked to them as authorities, but I also remembered the times in my past where cheap gender essentialism helped me feel a lot better during times of low confidence.

When I explored the discomfort that surfaced while witnessing others coping with the women-in-tech issue in ways I found problematic, I saw so much of my younger, less experienced self. I empathized strongly with the coping mechanisms we all employ to make the difficult journey as a female or other minority developer. Like all coping mechanisms, some work better than others. One of the big questions I grappled with in light of this, and still grapple with, is this: being well-versed in women-in-tech issues is something that requires education and lived experience just like any other specialty. As we’re learning, we’re going to accidentally hurt people along the way. How do we correct problematic behavior when we see it, without alienating? How do we learn, and encourage participation, along all steps of our journey, and cope with the inevitable cases where someone says something that isn’t quite clueful and steps on some toes?

I’m reminded of all of this thanks to a discussion popping up in several of my social circles lately regarding the Ladycoders Project, a (now fully-funded) Kickstarter campaign and upcoming career-development seminar for women in technical careers. After learning about this project, most of the women in tech that I know were initially jazzed: we all love the idea of empowering women to succeed in an industry that doesn’t make it easy. Every female developer has a thing or two she’s learned the hard way that she would have preferred to see in a seminar like this one. Most of the initial discussion I saw was overwhelmingly enthusiastic.

It didn’t take long, though, before some folks started investigating the Ladycoders site and found some content that disturbed them. That “good” and “bad” mock interview in the Kickstarter video didn’t sit right. The seminar opens with a session called “Skin Deep”, which focuses specifically on appearance. The outline to the “Certifications and Skills” session includes a bullet point on “why you have to be qualitatively better” (presumably, than your male peers). There’s language in the Kickstarter’s FAQ which has made LGBTQ individuals – who face many of the same issues (and more!) in industry as cisgendered women – uneasy. But the session that sticks out the most (and the worst) is “Men Aren’t the Enemy”, which posits:

Men don’t deliberately keep us out; it’s our job (for now) to be easily integrated into an all-male team, nonthreatening, and hyperskilled

This statement has (rightly) made many women in industry quite angry, myself included. Geek Feminism’s Timeline of Incidents catalogs an ever-growing list of sexist events across communities. People have (and will continue to) say that these exclusionary practices aren’t a “deliberate” attempt to keep women out, but anybody who has experienced the isolating chill of exclusionary behavior understands that it is harmful, whether or not it is deliberate, and it does keep women out. (Further reading: Intent is Not Magic.) The rest of the sentence suggests a path of least resistance that relies heavily on performing stereotypical gendered behavior; I’m not the only person who detects a strong whiff of victim blaming in all of it.

Many of us who have been discussing this project feel incredibly torn here: we have serious problems with some of the content on the Ladycoders site, but we also think the project has an excellent goal. There’s a lot of good advice in the session outlines as well – in particular, I liked seeing bits about “the myth of the one-page resume” and building up a public code repository on a site like GitHub. There’s also emphasis on practicing whiteboard exercises and mock technical interviews. Since this project is just getting off the ground – the seminar hasn’t happened yet – we don’t know how the problematic stuff in the session outlines will translate to in-person education; the only information we can go from is what’s provided by the website and the Kickstarter. The problematic content inspires far more questions than answers.

Some of us are also torn because of a discussion a few weeks ago following a post called “The Dark Side of Geek Feminism”; Skud’s post summarizes the scope of the discussion quite well. We’re still grappling with some difficult questions: if our feminism really isn’t about setting rules or hoops to jump through, how do we skillfully engage with problematic content? How do we take a stance on something when we all come from different perspectives, opinions, and backgrounds? How do we call out ignorant or hurtful statements while still showing compassion? While Ladycoders doesn’t explicitly state that it’s a feminist project, its goals (to increase the participation and representation of women in industry) match those of [geek] feminists. As individuals, we all draw our lines in different places when it comes to problematic content and behavior.

I can only speak for myself here. I think the problematic content in the Ladycoders outline has the potential to do tremendous harm, and ultimately drive women away from industry by delivering misleading information. That’s my beef with it.

Circling back to Grace Hopper here for a moment, I had the same feeling when I came out of Sheryl Sandberg’s keynote address. As I’ve said before, I really have trouble with Sandberg’s “inspiring” speeches to women because she places so much emphasis on women’s ambition and hard work, as if every obstacle constructed by institutional sexism can be overcome just by working a little harder or shedding a bit more blood. As a young person it is enormously empowering to feel like what’s possible is solely within the realm of one’s imagination and willpower. And there is some truth to that. But there are also so many systems at play, and when it comes to being a minority in any field, those systems can work very strongly against us.

The problem with not acknowledging the oppressive influence of the system in one’s approach is that it can be utterly heartbreaking once the system gets in the way. If I’ve been taught that my success in industry just comes down to my agreeability, my ambition, my skillfulness in not threatening my male peers – what happens when the problems that such behavior meant to solve arise anyhow? How do I cope in that situation – do I blame myself? Do I decide I’m just not cut out for this, and quit? What information could I have received about these inevitable obstacles that could have fostered resilience?

This is what I’m worried about when I hear Sandberg speak, or read about Ladycoders encouraging me to do all the work to integrate with my all-male team. It just doesn’t match up with the reality that I’ve lived. In fact, it would require an inhuman amount of energy and the emotional fortitude of a robot. One approach does not fit all situations.

I’d like to pivot back to the advice I gave that college student back at GHC, and some general sentiments about my own experience with interviewing and otherwise getting by in industry. There’s a lot we can do as developers to better ourselves – to make ourselves better candidates for a job, and outstanding employees once we’re on the job. But the onus shouldn’t just be on us. The tech industry is very young, and there are a lot of things it’s not doing well either. I have major criticisms about the general trend of software companies hiring for a very specific set of skills and experience rather than aptitude, and being unwilling to invest significant resources in training: I firmly believe this is damaging for all parties, and allows for the continued glorification of the stereotypical hacker type who spends all of their time on code, disadvantaging developers who prefer more balance. Peter Cappelli has been writing some great pieces about the skills gap myth that tie into his book “Why Good People Can’t Get Jobs: The Skills Gap and What Companies Can Do About It“. It encourages me to see a voice putting pressure on institutions instead of individuals for once. Needless to say, I have the same opinions about organizations with gender diversity issues: it is the organization’s job to proactively make themselves appealing to people of all identities; if the responsibility has been placed on the token person in that diverse group to point out what you’re doing wrong, you’re not doing it right. We absolutely need to work on improving ourselves as candidates and employees, but the pressure on systems and institutions to fix themselves up could be so much stronger, and that’s where my passion lies.

Personally, I love talking about interviews and general career advice. There’s a lot of things I’ve gotten right and many more I’ve gotten wrong. I’m an excellent interviewer, and getting a job has never been difficult for me. I’ve still had some interviews that I would have conducted differently if given the chance to do them again. On the job, things have been a bit more challenging for me – I’ve spent more time as a “new employee” than not, and one of the things I’ve learned is that I’m not very good at being “new”. I’m not very good at asking lots of questions in lieu of reading documentation, motivating myself to jump into a foreign code base, or warming up to a new development team. I’d like to be a more focused and organized worker, and I’d like to spend more time on skill development than I currently do. So I have plenty that I’m still working on.

I asked some other female developers about their experiences interviewing women, and learned some interesting things. I want to wrap this up by passing on some advice I think is useful and trends women-or-minority-specific, but a bit more constructive than the problematic bits in the Ladycoders outline.

  • Learn about terms like Impostor Syndrome, Stereotype Threat, and microaggressions as soon as possible. It’s normal to encounter one, if not all, of these at some point. Being able to put a name to that uncomfortable feeling will help you feel less alone in your experience, and will help you communicate your needs more precisely.
  • The most important component of a technical interview is being able to problem-solve on your feet. Try doing this with both easy and hard problems; examine the way you react when you don’t know how to solve a problem, and consider more constructive ways to engage with it. Asking for clarification or additional information is totally okay. Give as much information as possible while you’re thinking through an answer; it’s okay to say “I know this isn’t the optimal solution, but here’s the first thing that comes to mind.” Technical interviews can actually be a whole lot of fun once you get the hang of these things.
  • One of the benefits of switching jobs regularly is more frequent interview experience. If you’re looking for a new job after a few years away from interviewing, realize that you’ll probably be a bit less polished. Take some time to review potential interview questions and practice with a friend. I know some people that regularly interview between jobs even if they aren’t actually looking; this doesn’t work for everybody, but it does help the practice stay fresh.
  • Appearance and personality mean so much less during a technical interview than they do any other interview, and this can be disorienting for people who have been trained on non-technical interviews. I typically interview in jeans and a sweater (and also a nose ring and candy-colored hair – YMMV, but this hasn’t been a problem for me), and I incorporate things like my motivations and values into my narrative about my career history, technologies I’ve worked on, etc. With time, you’ll find ways to make responses to questions about past experience both informative and personally insightful.
  • Yes, women tend to express less confidence and more doubt in their abilities. I am absolutely one of those folks. At the same time, I’ve found most interviewers find it refreshing that I’m admitting what I don’t know instead of pretending that I have everything figured out, since so many other interviews can feel like trying to smoke out the candidates who are faking their expertise (an unfortunate side effect of this industry’s stereotypically hyper-masculine culture: braggadocio). I try to reframe my deficits in a positive way: “I haven’t worked with that – but I’d like to learn it,” or “That’s not in my skillset, but given my experience with x, I’m sure I’ll pick it up in no time.” There is a way to be honest about one’s limitations while avoiding self-deprecation.
  • Being personable in a technical interview is really about showing excitement and passion for a particular technical topic or field of study; figure out what you’re enthusiastic about ahead of time and feeling engaged with your interviewer will be a lot easier. When you’re researching the company you’re interviewing, what aspects of their work seem the most interesting to you?
  • Interviews are a two-way street. You are always interviewing the company, too. If they do something that doesn’t impress you, that’s important data and shouldn’t be ignored. Don’t be so fixated on your own performance that you miss warning signs. Think about what you’ve liked and didn’t like about past jobs you’ve worked, and questions you could have asked to get information about those components of the job in the interview. Sometimes your mind will go blank when an interviewer asks if you have any questions – if you know this happens to you, come with a list!
  • Curate your online presence. If you have a unique-to-the-Internet full name like me, this is a lesson you learned a long time ago – we of the unique names are really easy to find on Google (right down to the Tamagotchi haiku I wrote as a 13-year-old that wasn’t really a haiku). Make sure you have a web presence that conveys an accurate picture of who you are both as a developer and an individual. Personally, it’s important to me that my web presence is authentic and not sterile – think of how you want to present yourself to someone doing a web search on your name in a variety of career contexts (future employer, future coworker, collaborator on an open source project, peer in your local tech community, etc.), and decide what you can do to get yourself to that point. (This was a big topic at GHC and I think it’s going to become increasingly important. You can use your presence on the Internet to your advantage!)
  • Talking about past negative experiences is a tricky road, but if you avoid the issue altogether in interviews, don’t be surprised if those issues re-emerge after you get the job. This is the one I’m doing the most work with right now. I’ve been harassed and bullied on the job, so now I ask about company harassment policies in interviews; I’ve had neglectful managers and a void of performance feedback, so I ask about the frequency of performance reviews, one-on-one meetings, and the organization’s managerial philosophy. The big one that I’ve just started doing – and it scares me a lot – is being public about my priorities as a geek feminist and my interest in improving experiences for minorities in tech while I’m in an interview. I’ve realized that I’m no longer willing to work for companies that haven’t even done the most basic research on the issues facing women in tech, so if they react poorly to my disclosure, that’s important data. Yes, this has terrified me, but so far it’s led to positive results.  I’m still figuring out the right questions to ask in that department, and I’m learning as I go.

Want to read more on this topic? Here are some links that have emerged while my peers have been discussing Ladycoders and constructive career advice for tech minorities.

Screenshot of computer program code

Quick hit: BlackGirlsCODE’s 2012 Summer of Code

Signal boosting this in a separate post rather than a linkspam, since the fundraising deadline is soon:

“A child educated only at school is an uneducated child”

Today there is a huge epidemic taking place across America. In low-income neighborhoods across the country thousands of children of color are not being offered high-quality education. There is a digital divide separating our country and our children are stuck in the middle. It is said by 2015 (3 years from now) 80% of new jobs will require a technical degree:


On June 17th, 2012, BlackGirlsCODE (BGC) will launch our Summer of CODE Campaign. Our goal is to teach computer programming to more than 300 boys and girls from underrepresented communities, in 90 days, in more than 7 cities across the United States. We are launching this BGC Summer of CODE Campaign to emphasize the importance of technology education and achievement for our next generation of citizens. We are especially focused on giving girls from African American, Latino, and Native American communities the opportunity to learn valuable tech skills and to plant a seed that may “Change the Face” of the future of tech!

They are aiming to raise $18 500. As of now, with 42 hours left in the fundraising campaign, they have raised $9 915.

Donate to the Summer of CODE via Indiegogo.

Quick Hit: a GF approach to events

I help plan technical events at the Wikimedia Foundation. I think we’ve improved in making them more welcoming and inclusive over the course of my time there. We just recently filled to capacity on registration for an upcoming event, and I thought I’d share a few things we’ve done:

  • A friendly space policy
  • Event info page shows photos of people of different genders, allows people to opt in to sharing their names/attendance
  • Registration form doesn’t ask for sex or gender; instead, it asks what kind of t-shirt we should provide (including a “None, thank you” option) and “If you need accommodation: would you prefer to share a room with a woman or with a man?” (options: “women’s rooms”, “men’s rooms”, “either will be fine”)
  • We’ll aim to document as much of the event as possible in realtime text
  • We’re ensuring that at least one of the social events is not booze-oriented
  • I’m working to ensure people can put whatever names they prefer on their badges, including handles/nicks for those who don’t want to share their wallet names
  • Free to attend, and we provide travel sponsorships to encourage participants from far away
  • Hostel very near the venue

I failed at:

  • childcare – just didn’t put in the time to ensure we could provide this
  • ensuring our venue is accessible to those with disabilities (I’m not sure, and didn’t emphasize this as a key criterion when my contact in Berlin was scouting venues)
  • clarifying many of the points above to prospective attendees
  • and probably more

What have you done to make your geek events more welcoming?


Increasing your programming skill

This is an Ask a Geek Feminist question for our readers:

I’m a geek feminist trying to get into IT, specifically object-oriented programming and Flash/Actionscript. What I’m having the most problems with is practice – I’m taking some Continuing Ed courses because I have a totally different day job, but I still don’t feel like I’m gaining much skill in programming, probably also because I know exactly what I WANT to learn, but I haven’t found anything yet that covers it.

What I’m wondering is, for the typical programmer/developer job path, how do you figure out how to solve programming problems that aren’t covered in your classes? Do you just search through the language documentation (e.g. Java API) looking for relevant code?

This is in many ways closely related to an earlier AAGF question about finding newbie coding problems, but also a little broader: programmers, when you were learning, did you go to the puzzle sites, or work through language docs, or work on open source, or something else?