All too often, working on a team becomes a never ending sequence of dares. This applies to all teams, but for development teams the problem has some recognizable patterns: Changes are submitted, approved and merged with discussions that take place over the heads of most of the team members -- or without explanation at all; projects lack the supportive tooling that makes work efficient and pleasurable for all of the roles on a team; developers are told to "own" a problem and sent off alone as if on some mythical hero quest. This is a set of dares. We dare you to speak up. We dare you to ask for explanation of code you do not understand. We dare you to figure out how to create your own tools. We dare you to find an end-to-end solution in isolation that the rest of the group will deem worthy.
The dares may not be explicit, but the implied risk involved in speaking up, asking for help, or seeking collaboration is often real: Our reactions to the behaviors listed above are used as indicators of how smart and good we are. These behaviors, and many others that follow along the same lines, create significant barriers to building and operating inclusive teams that can successfully leverage members from varying backgrounds, with varying levels of training, and with varying subject matter expertise.
This presentation will offer ideas for how teams can become more inclusive in order to create a positive, productive environment that allows all members to maximize their efficiency and pleasure. There are quite a few steps an organization can take to improve team structures and processes, but to create an inclusive environment the key concept is support. Putting mutual support, whether requested or not, at the base of every decision we make is the best way to create an inclusive team that builds the commitment and investment of its members while building a product that represents them.
We all know the recommendations around collecting a user's gender or sex, especially as a single binary field: don't. There are so many brilliant flowcharts and diagrams and essays publically available that all remind us that it's none of our business.
But... what happens when knowing someone's sex IS your business? for example, for a doctor's office?
Clearly a male-female radio button isn't going to cut it. But what would? and what do doctors actually need to know about a patient's sex or gender? Spoiler: the answer is not what you might assume it would be.
Tech is notoriously bad at talking about intersections of class, disability, race, gender–health, weight, and embodiment are equally nuanced subjects all on their own. What happens when a self-consciously desk-oriented culture tries to over-correct? What happens when people tire of beer and pizza that no longer feels optional, and "clean eating" is the cleanest way out? What happens to those who are already hyper-aware that their bodies are battlegrounds? How do we find some socially-acceptable balance in these interwoven networks of expectation and self-care?
This talk will explore the complex landscape of body image negotiation in tech-specific cultural spaces, and hopefully offer a couple of tools to enable a baseline level of body-positive communication with tech co-workers.
Our culture glorifies busyness, and perhaps the worst of it can be found in the tech industry. Workers at startups brag about how much they work, and how little they sleep. Engineers forgo lunch for more hours at their desk, social media is riddled with #hustlin and #riseandgrind, and everyone is available at all times. This kind of stress is bad for employees, and bad for business. This talk will cover the importance of self-care, avoiding burnout, and ways to set boundaries to protect your health.
Turn the narrative about "crufty old legacy technology" on its head! From CGI scripts, to PHP, from TCL to MySQL, explore why these technologies were exciting and what led to their success. Programming as a profession is forward looking and this sometimes leads us to forget how much influence they've had on what we do today.
This talk will be half history lesson, half cheer leading now unpopular technologies.
As Star Wars recently reminded us, robots are very popular. What Star Wars didn't explain, along with why Death Stars are so easy to blow up, is how robots can reduce recidivism.
This talk explores the landscape and demographics of our prison system, the role that tech plays today, and how the tech community, a group that prides itself on solutions-oriented innovation, can turn our strengths toward solving problems here in our community.
From our first lines of code onward, we are bombarded with well-meaning advice on How To Tech Right. Often, this includes "owning your ignorance" and "squashing your ego" in order to embrace a learning mindset. But we also frequently tell people, particularly women and minorities in tech, to "own their expertise" and not be afraid to confidently stake their claim as a programmer. The fight between impostor & entitlement syndromes has left us with a confusing assortment of advice we dole out to beginners and vets alike: be humble but be confident, be a novice but an expert.
So what can we do with this incongruity? Is there a way to find balance? Or do we need to rethink our guidance model altogether? In this talk, I’ll examine the impact our advice has on disadvantaged groups in tech and explore ways in which we can move the onus of change from the impacted individuals onto the community at large.
I believe empathy is the core competency that is missing from much of the efforts to push the tech community in a direction towards more diversity of all kinds. Companies, communities and conferences cannot expect everything to magically change until they’re willing to go deep and examine the systemic patterns and structures that keep underrepresented communities from feeling safe and welcome in the tech space.
When confronting racism results in a critique of the manner in which the offender was confronted by the people calling themselves supporters, it makes it that much harder to address the real issues.
If a man’s first response to a woman complaining about a sexist incident or a sexual assault is to defend all the men who ’aren’t like that,’ that shows a lack of empathy. It keeps the focus on how men are being perceived, not empathizing with a woman who has been hurt.
This talk is for people in positions of all sorts of privilege who consider themselves allies to underrepresented minorities and want to learn how to be more effective allies.
We’ll talk about what it’s like to live as a minority—why someone might have what seems to you like an ‘overreaction’ to something that seems small.
How to stop, drop, and empathize before you go on the personal defensive for anger that’s directed at a group that you happen to be a part of, even if you didn’t specifically do anything wrong.
We’ll talk about tone policing, derailing, man-splaining and other hurtful behaviors that are sometimes practiced by well meaning people who consider themselves allies.
Leave your ego at the door and come with an open heart.
At last October's Open Source & Feelings, Jacob Kaplan-Moss gave an excellent talk on his experiences as a Django maintainer, and what ultimately led him to quit working on the project. Shortly after that, I gave a talk at another conference, entitled Empathy & Burnout that was, in some ways, in conversation with Jacob's talk. It discussed my own experiences as someone who hadn't yet gotten to the point of no return, and what I was doing to try to make the load of doing OSS work sustainable. Since then, I've continued to do the work described in that talk, and to struggle to balance the needs of the community for a popular open-source project with the need to take care of myself and the members of my team.
Something that was less clear to me then than now is that there is a largely invisible complement of less-visible emotional labor involved in this kind of work that can't just be waved away by being encouraged to maintain a healthy work-life balance. Even in a community, like npm's, that's blessed with a relative absence of abusive behavior and harassment, there's still a lot of mundane negativity and frustration that bleeds through from communication with the people depending on your project to do their jobs. Finding the right balance between project work and working to support a welcoming and inclusive community is tricky to manage. It takes effort and a lot of (sometimes ethically hazardous) judgment calls to determine what, exactly, "life / work balance" means when you're a small team supporting an ever-growing user community.
I don't propose to provide clear-cut answers to these problems, because I haven't figured them out. What I do have is strategies, and some thoughts about what it's going to take to make it so that those of us can do this work can imagine still doing it more than a few months down the road. I also have what I believe is some useful advice about making your peace, as an open source developer, or an open source project manager, with dropping all kinds of things on the floor, and how to do that without harming the project, or its users. So, real talk, but not without hope.
Seattle has two of the longest floating bridges in the world, and in 1990, one of them sank while it was being repurposed. To this day, the public reporting on the failure is extremely simplistic and full of fingerpointing- but the official investigation found that there were five factors involved and all of them were required for the bridge to fail. This accident was a classic complex systems failure, and there are a lot of really interesting things to learn both from the official findings and from the difference between those findings and the public coverage.
In the era of The Cloud and services like Wikipedia, more and more of us are going to be dealing with complex system failures and trying to understand what happened. When we ask "what happened?", the language most people answer with carries implied blame- we find ourselves talking about who made a mistake and what they should have done instead. But this doesn't help us understand what changes we can make to actually change the chance of experiencing that failure again and we don't learn how to make our systems more robust by suggesting that people not make mistakes. It's possible to do better and to be better to ourselves while we do it.
We look at ourselves in context of others. We have a primal nature to classify, categorize, and organize things into groups that support us and help us grow, and those that harm us and make us wither. We do this with nature, food, religion, people, and anything else you can imagine. It is the root cause of strife in the world, but it also is the bedrock on which our misaligned society is built on.
Having grown up a square peg, I often attempted to fit into the round holes. And while sometimes I could slip through the opening and mingle with all the cylinders, I never truly fit in. As much camouflage as I wore, I never had anything that ever felt like my identity, and never thought I would.
Eventually, I settled into a societally approved role in my twenties, only to have it shatter a few years later. I tried again in my thirties with the same results. Now, after an long and arduous journey, I am less sure of who I am, yet more confident that I am true to myself. I know that it is okay to have an identity that doesn't fit a happy little picture of what society says is allowed. I know how society views me, even if it is wrong. I'm ready to be myself, and I'll flip society on it's head to be recognized as square peg in a world of round holes.
Using my journey as an example, we'll walk through finding your personal venn diagram of identity and finding the empathy for others even when we have nothing in common.
In an industry best suited for white and asian men where diversity is no more than a buzzword and dataset for most companies, it's easy to get lost in the shuffle, fetishized, and pushed to the side as a black woman in tech.
In both open source communities and in the workforce, black women are often excluded, misunderstood, or subject to conscious and unconscious bias that unduly effects their work effort and performance. Our feelings are to be kept at bay, lest we'd be deemed argumentative, uncooperative, or bitchy.
Dealing with being an 'only' has social, emotional, and other implications, and my talk will seek to illuminate a few of these feelings, while giving actionable advice on how to have empathy, understanding, and social graces when encountering and being an 'only.'
The Internet of Things is upon us, whether we like it or not. From doorknobs to refrigerators to automobiles to medical devices, internet connectivity is becoming integrated not just into our consumer technology, but also our culture and everyday lives. Open source software (and hardware!) is already a part of IoT development, but to what extent do open source developers have a responsibility to the products and end users they affect? The extent of IoT adoption has the power to both empower and harm people in ways never before possible.
In this talk, we will explore the ethical landscape of IoT development. We'll talk about IoT security and robustness. We'll discuss the leftpad incident and what impact that may have on an IoT future. We'll also explore how certain industries (e.g. the medical device industry) are regulated with respect to open source and software development in general, and ultimately what responsibilities and powers developers have to forge the IoT into a force of good.
There's been a recent push for incorporating computer science into high school classrooms, while some schools struggle to find funding for their art and music programs. This talk asks "Why not both?" and explores the ways that incorporating art can benefit a computer science curriculum, using Bubblesort Zines as a case study.
We use platforms like Facebook to find, connect, and build alliances with the people who can work together to co-create self-sustaining systems that promote our individual agendas. This talk will explore spaces that eclipse both the real and digital worlds. Marin will outline how she has used performance, poetry, and visual art as strategic communication tools to establish spaces for deeper engagement on topics from birth control and gender identity, to white privilege and racism. Her work with projects like Red Lineage, Miko Kuro's Midnight Tea, SPoCS (Seattle People of Color Salon) and #WhiteOrWrong allow the idea of community and imagination to grow and thrive through different levels of engagement, modes of connection, and methods of encounter.
Getting aligned and connected to each other as well as the objective and ultimate goal of a project before the first line of code is written is critical for long-term success. Building a solid foundation based on the relationships between both the team members as well as the intended audience of the project allows much more than the code itself to manifest. The energy we put into our code is the energy our audience feels as they use it. Bringing this awareness and intention to any project is a common step missed. I will talk about ways to bring and maintain this step, this perspective, as a team member.
CW: Suicide; no specific details.
In this talk, I will share my experience of loss and how our community got through it and still managed to host a conference. I’ll explore the fragility of building personal relationships solely around open source and community work. Finally, I’ll illuminate the practical issues each of us need to address to ensure our work and our community’s work lives on in the way that we wish after we are gone.
Just days before we were scheduled to open our CFP, a dear friend and one of our key organizers committed suicide. We were already late in opening our CFP and the conference was going to happen in 10 short weeks whether we felt up to it or not. We had to move forward while we navigated our grief.
We pulled together in ways that still make my heart soar. We managed to keep our conference more or less on schedule. We helped to help settle the affairs of our friend, with many of us sharing the burden. We divided the load based on what made sense for each of us to carry.
One of my jobs was to co-lead the planning of our friend’s celebration of life. We did this collectively using the same processes as our other events. It was sometime during this planning that I realized I was functioning as a kind of secular pastor. I still don’t feel particularly skilled or equipped for this extra-dimensional community organizer role. But it did, and still does, give me a deep sense of purpose.
Another thing we did, and rather quickly, was to transfer the communal assets our friend controlled before they became inaccessible. It might seem strange to focus on pedestrian matters at such a time. But it’s actually the main thing you have to do when somebody dies. What do you do with their things? What are you legally required to do with their things? What do you do with the communal assets that they held? What if you’re not as lucky as we were and don’t access to these communal assets? How do you secure them?
After an author he liked died without leaving a proper will, Neil Gaiman worked with an attorney to create a general will for authors of creative works. He did this to help them ensure their works would live on in the way they wanted after their deaths. I believe we need a similar awareness raising and resource in tech.
Lastly, I’ll speak to how I’m thinking about all of this nearly three years later. I still miss our friend, deeply. What I regret most is not spending more "just hanging" out time with him. In fact, I’ve noticed that this is not specific to my friend who has passed. For many reasons, I’ve come to rely upon building my friendships around work, volunteer or otherwise. It’s part of why open source has been so attractive to me. But more and more I am feeling the fragility of this. Not only does it place work-related stress on those friendships, but it reinforces the message that we are only valuable inasmuch as our ability to contribute.
I want to be loved and to be welcome regardless of how much I’m able to contribute at a given time. And I think I’m not the only one.