 Hi everybody. Welcome and thanks for coming. I'm Stephanie Schirmer. I'm a software engineer at Etsy.com. Etsy is a global online marketplace where you can buy and sell handmade and vintage goods. We have 1.5 million active sellers right now and we value craftsmanship and human connection. I write software to help sellers at Etsy. Now, the title of my talk is a culture of courage. I wouldn't say that I'm an overly courageous person. In fact, I'm a bit shy. I'm giving a talk now so that requires a bit of courage. But I'm mainly here because I found myself in a community of encouraging people. These are my colleagues from the Etsy spirit squad. And I'm very grateful for these encouraging people. It hasn't always been this way, especially in internet-related cultures, among nerds and hackers of all kinds and people like me and all of us. We see a lot of the opposite behavior. One, upmanship, outsmarting each other or just plain bad communication. We've all done it. I've done it. And I think it has to do with technology shaping our brains and behaviors. Wait, what did I just say? Technology makes us evil. Now, that's a bit far-fetched. Let me explain what I meant by this. I'm speaking from the perspective of a software engineer, but I think we can deduce general patterns for communities from what I'm saying. Every day I work with a computer. I love that because the computer is a great teaching instrument. From the nature of its construction as a machine, I know that it's always right. We could say it never lies. A faulty behavior has been programmed into the computer by a human at some point. So if I'm trying something new and it doesn't work, I can be pretty sure that the mistake is on my side and I have to poke around to find out what I did wrong. So in comparison to a human, a computer is very deterministic, predictable, following the same rules. Also, that means it's kind of inflexible, right? And programming, a small mistake like a forgotten new line in the program code can make the computer unhappy. Over time my brain learned that it's very important to pay attention to teeny tiny details. Learning this can feel like banging your head against a very rigid wall at times. It's a very humbling process. It's also a very intimidating process. So I have friends who can never remember their passwords and they say it happens because they fear their computer. Because it's so complex but rigid and they fear of doing something wrong when they touch it. My job is building computer programs. That means I work on parts of the system that are under development and not quite working yet. So working with broken code is the main part of my job, right? Imagining the code was working already, then my job would be done. How boring. I'm sure this can be translated to other professions like editing or creating art and media. We are knee-deep in broken things all the time. And that's the nature of our work. And it's not our fault. The weird thing is nobody talks about this part of the process. I don't know about you, but it used to make me feel slightly grumpy and stressed me out. All these not working yet things. Before I heard this thought from my coworker Bethany and I thought about this in depth. It gets even more difficult when we add constraints of the real world, like time, for example. We want our code to be ready fast because we have lots of things to do. That means there's also the trade-off of how to approach our job. Ideally, we write some perfect code. Super clean, easy to understand for the next person. In reality, we have to make it work and then move on to another thing. If we are seasoned and smart about it, we try to strike a balance between idealistic goals and realistic outcome. If we just take shortcuts, we incur technical debt in the project, meaning our shortcuts introduce unclear parts that other people have to tidy up after us. Maybe we even landed on a project where the code is already messy and we are scared to touch certain parts of it. Another constraint is the connection of our work to the rest of the world. How does my code work together with the rest of the code base or my co-worker's code? Maybe we have different styles of writing. Sean likes spaces and I like tabs. My friend Nina said a good code base should look like a single person wrote it, no matter how many people contributed. So there's some communication and decision-making to do to accomplish this. It can be an area of frustration when people insist on having their personal styles met and are not willing to collaborate. This happens surprisingly often and I suspect it's because computers trained us over the years to follow a very rigid style because that's how they work. Also, the collaboration in terms of style should be easy to understand when a new person is joining the project and that's another reason to focus on a clear decision and communication about it. So we could say those are a bunch of different and completely non-technical pitfalls or evils when working with computers. No matter if we are coders, researchers or other digital workers. I've seen people, friends and colleagues, become desperate, cynical, sad, mean or lonely for these reasons because the computer always wins. So there seems to be some fuzzy emotional headspace element to working with computers even though or maybe because they are unemotional machines. I started realizing this when I transitioned between different communities working with computers. So let's talk about technical culture. When I grew up, my dad was a programmer and even though he sat down at some point and coded with me for a bit, he was too impatient to really explain the details and he gave me a book that he had written instead. I don't blame him. I was in primary school and this was the C programming language. I was just too young. When he installed Linux on our home computer, he went to his room alone for a day or two. It was a very mysterious but not very collaborative process. I had learned to read the manual before daring to ask, before I was even in high school. I still remember my first time installing Linux on my own computer, doing it all alone with just the help of the fine manual. And then having a friend help me set up my dial-up modem after moving to my own place, which he did by grabbing my keyboard and typing things without giving any explanation of what he did. Must be wizardry. In the university, I studied computer science and I started going to the local hacker space or airfall crisis, as we say here. They are adorned on me that doing things with the computer has a political dimension. I learned a lot of details, tuning my computer at night, patching and building the kernel of my operating system in order to learn some wizardry myself, mostly all by myself. The meetings with fellow geeks were reserved for boasting about new tricks, new versions and arguing about overheard opinions on software, not learning or sharing. Trying to fight my way into a competitive culture, which wasn't very welcoming to female folks in part because people seemed to be afraid we might find out about the poor they share. These were the awkward years of undergrad studies. Here I learned competing and outsmarting people, not asking questions in fear of looking foolish, even though everybody in the room had the same question. I learned that people seemed to like doing the coding, but not the documentation and writing it was looked down upon and other toxic tricks of engineering culture. I suppose back in the days when engineers were designing mostly trains or bridges, like here, it made sense to have people prove themselves and fight their way into the ranks of esteemed engineers in order to make sure they really do know their shit, how to build stable bridges. This one sensible idea overshot its target and it created a culture that can be an obstacle to learning and development. During my following years as a PhD and postdoc in computer science in which the university became my professional work environment, I saw more and more of these behavioural patterns from growing up in engineering culture take over the internet. So people were outsmarting each other on professional sites like hacker news and Stack Overflow, just as we had done it in our undergrad years in our geeky meetups. I saw people derailing a conversation by adding a, well, actually, just like in school. I saw the same questions being asked at professional conference talks that were in fact just thinly veiled statements of opinions or facts to put the speaker into place or directing the conversation to the person asking the questions. Instead of being a real desire to learn how to do it, I started by having a burning question answered. Also, there was this really beautiful sounding but soft and squishy concept of meritocracy. Or as the German geeks like to call it, wer macht hat recht? Whoever does it is right. Which essentially says that fame in this culture is based on what you do and nothing else. So you are what you do, what you can hack, what you coded. Sounds excellent to me, being judged by what I do means stripping away other factors such as money, class, race, age or gender that can be used to judge a person. No prejudices. Sounds great. Except for it doesn't work like that. Numeritocracy is a theory. In reality, people from different backgrounds are dealt very different hands in life and the amount of money, spare time and education influences what they can hack on or code, what they can do and will be judged for. It sounds like this romantic but unrealistic dream of capitalism where everybody can be a millionaire when they just work hard enough. What's also really dangerous about the meritocracy idea is that people in this culture will always be judged based on productivity. Even in our spare time, we're supposed to write blog posts, contribute to open source software and do cool stuff. So we are optimizing ourselves to be productive even in our spare time. Don't get me wrong. I love tinkering and technical discussions in my spare time and I don't want to say that we should never do such things in our spare time but basing our value on it is like a logical fallacy and creates a lot of pressure. And it makes it really hard to take a break from things or do useful things that don't fall into the cool tech projects pattern like spending time with my grandma. Not taking a break makes most people depressed and burned out after a while. Also, I noticed there was a packing order of geekier than though established in most work groups I was in. So people introduced themselves as old sea gurus, network technology specialists, grumpy sediments with wood privileges and keys to the data center. And many people introduced themselves with the history of how long they'd been programming to make themselves more credible in the group. While I understand that every person has a history and even though I did write my first program as a kid and I compiled my own operating system before, I'm not sure why I should tell this to the people I work with now. It's of no relevance to them except for trying to impress. It establishes a hierarchy and excludes people who are new to the craft. So I catch myself doing it all the time. Looking closer at this pattern, there seems to be a war of generations going on. I'm 33. I'm somewhere in the middle of this war. The order dinosaurs of the internet are strongly shaped by a geekier than though attitude. For them, the internet was a playground of geeks which was a safe space from the rest of the world. It's hostile in its own way because you had to fight your way into it and you prove that you know something or at least you were able to set up your dial-up connection and read a news group. But once you were in, you could be pretty sure to be safe from the jocks and mainstream people that bullied you in school if you were a geeky. Times have changed, though now everybody's on the internet and my 88-year-old grandma skips me from her iPad, which is awesome. And with different communities, there are different interaction patterns again. The internet is now part of everyday life. If I put on my dinosaur geek hat, it's about time to grow up and reflect on my behavioural patterns. The question is, does my inner-old style geek get angry about new people invading my safe space? Is it my space at all? Or do I manage to be inclusive and extend this space and make it even bigger and even nicer? How do we welcome new people? Focusing back on the professional sphere, I think we have problems with passing on knowledge about technology. Historically, people have been kind of exclusive about it. Maybe because in history, technology was an underground niche. Maybe it is because technical people are more versed to focus on technology than on teaching. Maybe it is because of outdated safety concerns. Who knows? But maybe it has to do with the fact that it's really hard to teach programming and other tech topics. You can't really learn it from the book. First of all, the book is most likely outdated. And secondly, the big leaps of learning come from doing the thing, the thing itself. So it's more like a craft. Yet there's no such thing as an apprenticeship or a master apprentice relation when learning about programming because it's still a fairly new craft and it has no links to traditional crafts. A lot of the learning for me happened in informal ways. On the Internet, after class, at night in this parallel universe. A weird cause of the problem of passing on knowledge is also that fellow engineers love to point people to the documentation instead of explaining things. Reading the fucking manual like I experienced it as a kid. Interestingly, nobody seems to want to write these manuals. My hard-boiled dinosaur geek me would pride myself on just writing code and documentation was almost as evil as bureaucracy to me. Even though we might not like these behavior patterns or we might not have fully identified all of them, they are known to the entire Internet generation of which I see myself and all of you as a part. It's the toxic undercurrents in the culture that we all love. We have friends who are as geeky and who we really like. And there are fun moments when the empowerment through technology makes up for occasional bad behavior. It can't be that bad, right? I didn't fully realize the extent to which it was dragging me down and how much of this behavior was ingrained in me myself before I moved across the ocean and back where I encountered different tech communities with a different interaction style. I now work in what I describe as the culture of courage and encouragement. Before that, I went to a free school in New York City called Hacker School, now called the Recurse Center. The school works like a writer's retreat for programmers. There are no teachers, just facilitators that help you when you get stuck. So essentially, you pick your own project and then you PR program and teach each other for three months. Hacker School was one of the first safe spaces I encountered for programmers and it was an eye-opening experience. Hacker School created the space by giving you some simple social rewards. No, well, actually. If you're trying to explain something and another person corrects you with well, actually, what they usually do is they throw in some facts nobody asked for just to sound smart and divert the conversation to themselves. No feigning surprise. So if someone asks you in fake surprise, what? You really don't know what a frame buffer is. They don't accomplish anything except for making you feel bad. No backseat driving. If you listen into a conversation where two people are trying to learn something and then you hijack that conversation with the answer, you make these two people feel really bad and make them lose their chance of learning how to figure it out. No subtleties. This makes it possible to call out behavior that makes the space uncomfortable for marginalized people and make it welcoming for everyone. This culture makes it a great learning environment. A place where people feel encouraged to try new things out and ask questions and give answers in a straight forward way without boasting or ridicule or shaming. This was one of my first encounters of a geeky culture that felt safe for asking any kind of question. When I started working at Etsy, I had to write code and bring it live to their website on my first day. It felt like a giant wave of forward trust that everybody had in me. Of course, somebody was reviewing my code and explaining me the steps to put it on the side to make sure it all works, but still it felt like an empowering accomplishment. We called this the first push project because it's the first time an engineer pushes code to the site. A few months later, my colleague Dan and I organized the first push project in the Berlin office where I work from. My colleagues from the international community, design team and office management pushed code to our website. They felt the same sense of empowerment as I did in my first push project. This was a great exercise of unity, breaking down the somewhat artificial barrier between engineers and non-engineers that I always found silly. In the end, it's not magic, even if people like to sell it that way. Also, a few months later, I pushed code which contained a bug for the first time. Uh oh. I was pushing a bit late, all alone in Berlin while my fellow engineers were in Brooklyn. The internet was flaky and I noticed I pushed the wrong thing and caused a bunch of alerts on the test server. I freaked out a little bit, but people patiently offered their help and in the end, we fixed my bug before it even made it out to the real website. Yay! I was actually surprised about how relaxed and friendly my colleagues were in this situation. Nobody was angry at me. People gave me time and trust to fix my mistake. After I fixed the mistake, I found some super nice reassuring messages from fellow engineers who said, don't worry about breaking stuff, we've all done it and they told me their faulty push stories. Even though they were all the way across the ocean, I felt a giant wave of support. So from this anecdote, we can speak a bit about the process for pushing code to the side. We always do it together. We have a queue so that people don't push changes at the same time and write all over each other's changes. We communicate a lot while being in the queue together. The push queue is opening hours to make sure that people are around watching and people don't drive by a push late at night when they are tired. During opening hours and also off hours in case of emergency, every engineer has full autonomy to push code to any part of the side. So we push continuously to the side, driving its change up to 60 times per day. When something breaks, we can push a fix in the same quick fashion, which is oftentimes faster than the speed of the engine. It keeps us rolling forward all the time. There is also a custom which was very surprising to me at first. A price for breaking the side in the most spectacular way. An Etsy seller made a three-arm sweater as a reference to our famous error page, which looks like this. And this sweater, which is a real thing, you can put it on, is awarded as a yearly price. A colleague from our team once bought a sweater because he accidentally banned all Etsy admins from the side, wearing us all from doing our work. The price is giving away a bit jokingly as a reminder that failure happens, even though people usually have good intentions. Good intentions and trust are a very important point to this philosophy. Overall, this strategy sounds counterintuitive, right? Everybody can push code to the side and there is no blame when people break something and they even get a price. Thinking a bit more about it, it makes sense if we come from a place of trust. Then we can assume that the person who introduced the mistake did it by true accident because they were changing something in their best intentions. The system is just so complex that they didn't know it's full behavior at that point in time. They didn't know that their behavior would have a different outcome from what they expected. By blaming them or even firing them, we would let this great moment of learning pass and the same mistake might happen again in the future. Of course, it's a calculated risk. We do have code reviews, tests and the collaborative deploy process and a test server which is called the princess that saved us many times. Still, the full autonomy of deploying code for everybody at all times is important because it allows us to move fast and if things eventually do break despite all our precautions, we can fix them. Another topic that's still a bit hard for me is asking questions the right way. Looking back at my time in university, I feel a bit sad about all the questions I didn't ask and the pressure I felt around asking questions. After all, this should have been the place of learning in my life. Why was I so reluctant to ask questions? Because asking a question makes you vulnerable and exposes an area of not knowing and describes a need or a dependency on another person. And there was no explicit culture around creating a space for asking in class, even though professors occasionally drop phrases like there are no dumb questions, do they really mean it? Why were they sometimes annoyed if somebody did ask a question then? So I asked other people, I asked the professors after class, or I went to the library instead. All fair. What I only realized later is that so many people had the same questions they didn't dare to ask. So I would have made it easier for everyone if I'd mustered the courage to ask more. Of course there's a trade-off and I don't want to be selfish and waste the classes or the professor's time and have them cater to all my smallest needs. I understand that. But understanding each other requires asking questions sometimes and it's surprisingly hard to do without an encouraging community, without good examples and without practice. It got a bit easier with practice and gaining more knowledge in general, but even as a graduate student, I found it hard. Geez, I still find it hard sometimes. At the same time, how can I help people to ask questions? How can I answer a question without making the person who asked it feel uncomfortable? As briefly mentioned, some questions are indeed difficult. I call them unreal questions. They are no real questions. They are demands of attention. Sometimes they are negative. This I've seen when another person gave a really good explanation or when people speak in bigger groups. Maybe they are misguided attempts of a thank you. I'm still figuring those out. But back to answering a real question, the rules of hacker school helped me a lot here because they cut out a great deal of subtle or maybe even subconscious ridicule and boasting such as faint surprise and well-actualies and they encourage people to reflect on their communication patterns. They allow us to address negative mechanisms. We have names for them. And a good first step is also welcoming the question. So I have this colleague, Lara, and every time you ask her a question she says, that's a great question with a lot of enthusiasm and she means it and then she takes the time to answer it. So it's really fun to ask her a question, actually. Another good step is to admit not knowing as a positive example and make it a normal and non-scary thing. This can be used very constructively when saying things like, I've understood the first step but then I don't know why the second step is happening instead of this other thing that I assume to have. This is an area where I try to watch myself continuously. Thinking about this change of perspective that my encouraging colleagues kicked off on me, I noticed a few takeaways. So we could call this really the courage and philosophy part. First of all, there are a bunch of myths in engineering culture that hurt us. There's the myth that there's such a thing as technical perfection and that it scales to bigger systems. We all know that in a sufficiently complex system it's impossible to oversee every detail. I can't. There will be bugs. There's the myth of the ten times engineers, some magical people who do ten times the work of others. This myth has to die because it's introducing more pressure where most people don't have a problem with not working enough. They have a problem with taking breaks. Also it doesn't move ten times as fast come at the cost of technical debt and an untidy code base for other people. That doesn't feel like it would work well with others. And then there's this artificial boundary between engineers and users. Or we could say writers and readers and artists of consumers of art. And consumers of art. So doing the first push program with non-engineers in our office was one of the most empowering moments in a long time. In the end we're all humans and we can all do awesome things. Everybody was able to do it. There's a big element of ego and pride and programming and among nerds. Perfectionism is a problem. Leading to not finishing a project or not even starting it yet. And fear of it not being perfect. And I think the narcissism of the modern internet makes this even worse because you can see all the people around you presenting their awesome projects. And there are so many over achievers and people with really great ideas among us which can be really intimidating. Everybody wants to be awesome, right? And thanks to meritocracy we also have the problem that people strongly identify with their code. So for some people it's hard to get a code review with criticism in it because they learn that they are their code. Which is obviously not true when you're breathing human being with a heart and not a machine. But it's easy to forget when people tell you this all the time. Maybe it's a thought coming with the immense power to change things that you can do in the programming realm. Some people I know practice meditation in order to improve their skills of letting go of the ego and overly controlling elements that can come with coding. And then there's a big part of society who still sees failure as a shameful process. Politicians step down instead of fixing things when they fuck up. Our parents might have been angry when you got a bad grade. Our inner voice might criticize us for every tiny mistake, wanting us to cover them up and hide them from others. Opportunities for learning are lost in this realm of mind. I think these three problems are disproportionately huge when working with our brains, ideas and computers. I saw them among scientists, writers, artists and geeks. Because oftentimes we cannot see the results of our work. They seem virtual. We cannot touch them. It feels different than building a house from real wood with our real hands. I think it's easy to get alienated from digital work for this very reason and also because a lot of the work is done alone. The work doesn't feel real in some days. Did I do any work at all today? Maybe I'm just imposter. Speak to your fellow nerds about this and find out why and when it happens to you. Another big field of action is the field of collaboration versus competition. So what's competition? Usually we compete when resources are limited or scarce. This is why countries fight over natural resources, right? In capitalism we are supposed to fight for resources that are not limited like grades in school or money to buy digital goods, to establish a healthy competition. Usually this is done to establish some artificial power dynamics. Many goods in a digital world are shareable like education and information. And even if they are limited like attention or one-on-one time of a person, collaborating and giving it freely and helping each other will empower everybody around you in a long run so that even more people can help each other and you in the future. In Montreal I was part of a group that practiced do it together where we exchange computer skills in our spare time. Julia from Montreal is giving away self-made zines about her favorite tool S-Trace. I think sharing and doing stuff together makes it less scary and it's fun. So my favorite trick that I notice in all of the above points is to go from the situation of failure to a situation of learning. As quickly as possible removing blame helps a lot. When there's no blame and shame failure becomes a learning opportunity right away. And also I want to mention that it's still a privilege to fail and learn from it. Depending on your standing and your community you might get a pet on the back or a kick in the butt. So I'm very grateful I'm in this place. I think it's important that we create an inclusive and safe space in which everybody can ask questions try wrong things and improve because that's the way we learn. Always being right means I'm doing or thinking only things that I know already boring. Being wrong and having to change my view is awesome because I just learned something and evolved an idea. And I want to close with a suggestion that you are someone's spirit squad. I had a transformation by other people. I don't have it all figured out. It's an ongoing process for me. I still encounter grumpy dinosaur geek parts in my personality every day. But I'm also starting to see more and more ways to build and expand this culture of courage. And I want to share it with you. I want to be your spirit squad and I want to encourage you to encourage others. And I want to hear the story about your community. Thank you.