Building a culture of courage
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 61 | |
| Number of Parts | 79 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/19615 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Open setSoftwareFreewareIntegrated development environmentOcean currentConnected spaceSoftwareGoodness of fitOnline helpSoftware engineeringXMLUMLLecture/Conference
00:33
BitRight angleInheritance (object-oriented programming)TelecommunicationCausalityMotion captureHacker (term)Lecture/Conference
01:18
BitPort scannerSoftwarePattern languagePerspective (visual)Sound effectSoftware engineeringConstructor (object-oriented programming)NeuroinformatikNatural numberComputer programmingSampling (statistics)Line (geometry)Virtual machineComplex (psychology)Software testingWordOrder (biology)Multiplication signPairwise comparisonDisk read-and-write headPasswordProcess (computing)Touch typingBitPoint (geometry)Program codeRule of inferenceJSONMeeting/Interview
02:48
Group actionIRIS-TProcess (computing)MereologyCodeHypermediaComputer programmingPhysical systemMultiplication signIdentity managementStress (mechanics)Constraint (mathematics)Product (business)XMLLecture/ConferenceMeeting/Interview
03:32
CodeProcess (computing)Multiplication signConstraint (mathematics)Total S.A.Type theoryReal numberArithmetic meanChemical equationMereologyTouch typingProjective planeKeyboard shortcutOcean currentIntegrated development environmentLecture/Conference
04:15
NP-hardComputerConnected spaceConstraint (mathematics)FrustrationWritingCodeAreaTelecommunicationGoodness of fitDifferent (Kate Ryan album)Design by contractRule of inferenceSingle-precision floating-point formatSpacetime
04:52
ComputerNP-hardProjective planeTerm (mathematics)Operator (mathematics)Decision theoryNeuroinformatikTelecommunicationKey (cryptography)CollaborationismDigitizingDifferent (Kate Ryan album)Ring (mathematics)Lecture/Conference
05:44
Metropolitan area networkElement (mathematics)NeuroinformatikVirtual machineDifferent (Kate Ryan album)SpacetimeFood energyProgrammer (hardware)Connectivity (graph theory)Rule of inferenceComputer programmingProgramming languageProcess (computing)Revision controlLecture/ConferenceMeeting/InterviewJSONComputer animationXMLUML
06:36
SicWechselseitige InformationMP3Uniformer RaumMultiplication signExecution unitKeyboard shortcutModemOnline helpSet (mathematics)NeuroinformatikMereologySpacetimeOrder (biology)Dimensional analysisKernel (computing)Local ringOperating systemPatch (Unix)Hacker (term)Lattice (order)Random walkUniverse (mathematics)Electronic mailing listConnectivity (graph theory)ExplosionFamilyComputer scienceOffice suiteMatching (graph theory)Lecture/Conference
07:51
Observational studyWritingDynamical systemWave packetSoftware developerMultiplication signOrder (biology)Bridging (networking)RankingLecture/ConferenceMeeting/Interview
08:39
WebsiteInternetworkingPattern languageUniverse (mathematics)Data conversionStatement (computer science)Integrated development environmentTangentDivisorHacker (term)Data managementMultiplication signXML
09:31
Computer architectureDifferent (Kate Ryan album)PressureControl flowMultiplication signOpen sourceTheoryProduct (business)Order (biology)WebsiteGenderOcean currentException handlingSocial classWeightSoftwareDivisorMeeting/Interview
11:31
SoftwareRule of inferenceData centerMedical imagingIntegrated development environmentGroup actionKey (cryptography)RootSystem administratorComputer programmingOperating systemMultiplication signException handlingEvent horizonPhysical systemNatural languageHierarchyJSONXMLLecture/Conference
12:26
AliasingInternetworkingEuler anglesElectric generatorConnected spaceProof theorySpacetimeDialectMetropolitan area networkPlanningForm (programming)Computer animation
13:05
Different (Kate Ryan album)Video gameMereologyMultiplication signInternetworkingInterior (topology)Pattern languageInteractive televisionRight angleSpacetimeMeeting/Interview
13:45
Extreme programmingNeuroinformatikSphereNumberWater vaporComputer programmingLink (knot theory)Theory of relativityUniverse (mathematics)Social classInternetworkingGraph (mathematics)Lecture/Conference
14:44
CausalityProcedural programmingPoint (geometry)Entire functionMereologyElectric generatorInternetworkingSemiconductor memoryStudent's t-testDifferent (Kate Ryan album)Ocean currentLecture/Conference
15:26
Moment (mathematics)Key (cryptography)Extension (kinesiology)Different (Kate Ryan album)CASE <Informatik>Interactive televisionOcean currentJSONXML
16:05
Programmer (hardware)RecursionFreewareRight angleAffine spaceSpacetime1 (number)Computer programmingProjective planeCASE <Informatik>Rule of inferenceMeeting/InterviewJSONXML
16:38
WindowException handlingData conversionSoftware frameworkMarginal distributionPlastikkarteIntegrated development environmentDevice driverNegative number10 (number)XMLComputer animation
17:52
WebsiteProjective planeCodeMultiplication signSystem callArtificial neural networkData managementOffice suiteVapor barrierForm (programming)Sound effectBit rateMeeting/InterviewLecture/Conference
18:54
Curve fittingSoftware testingMessage passingBitMultiplication signCodeSoftware bugInternetworkingServer (computing)XML
19:40
Staff (military)CodeProcess (computing)WaveBitQueue (abstract data type)MereologyCASE <Informatik>Multiplication signOpen setMathematicsTime zoneWebsiteWeb 2.0Musical ensembleKeyboard shortcutLibrary catalogWordSampling (statistics)Sound effectMeeting/Interview
20:45
WebsiteMultiplication signElectronic visual displayMereologyBitSystem administratorError messageArm1 (number)Computer animationMeeting/Interview
21:37
Physical systemCodeStrategy gamePoint (geometry)Goodness of fitBitMoment (mathematics)Multiplication signRight angleWebsite
22:33
Multiplication signCodeSoftware testingCollaborationismPoint (geometry)Disk read-and-write headLimit (category theory)Process (computing)NP-hardPressureUniverse (mathematics)Meeting/Interview
23:12
Student's t-testPatch (Unix)Multiplication signSocial classPower (physics)AreaLibrary (computing)Video gameVector spaceSpacetimeForm (programming)BitGradientGoodness of fitMeeting/Interview
24:34
Group actionNegative numberMultiplication signTerm (mathematics)Goodness of fitAxiomMeeting/Interview
25:08
AreaHacker (term)Rule of inferenceNP-hardConstructor (object-oriented programming)Multiplication signMechanism designPattern languageTelecommunicationMereologyEnterprise architectureMeeting/Interview
26:19
Perspective (visual)MathematicsPhysical lawMusical ensemblePhysical systemPerfect groupEstimatorScaling (geometry)Complex (psychology)Multiplication signJSONXMLMeeting/Interview
26:56
Multiplication signControl flowPressureSoftware testingCodeAdaptive behaviorComputer programmingPattern languageBoundary value problemArtificial neural networkOffice suiteJSONXMLLecture/Conference
27:37
Office suiteElement (mathematics)Multiplication signComputer programmingMoment (mathematics)CodeProjective planeMathematical analysisSound effectInternetworkingMeeting/InterviewJSONXMLUML
28:08
Analytic setSampling (statistics)Slide ruleCodeMereologyProcess (computing)Element (mathematics)Order (biology)ArmPower (physics)ImplementationVirtual machineComputer programmingEstimatorMeeting/InterviewJSONXMLLecture/Conference
29:08
GradientInheritance (object-oriented programming)Multiplication signInfinityField (computer science)Touch typingMessage passingGroup actionNeuroinformatikSpeech synthesisReal numberResultantFrame problemJSONXMLUMLMeeting/Interview
30:12
GradientProduct (business)CollaborationismField (computer science)Medical imagingInformationGoodness of fitDynamical systemNeuroinformatikShared memoryPower (physics)Group actionBookmark (World Wide Web)MereologyArtificial neural networkMultiplication signDemosceneDivisorJSONXMLLecture/Conference
31:22
Right anglePoint (geometry)View (database)Arithmetic meanSpacetimeJSONXMLLecture/Conference
32:21
Process (computing)Transformation (genetics)MereologyPlastikkarteOcean currentLecture/ConferenceMeeting/Interview
32:57
Special unitary groupMoment (mathematics)Euler anglesNeuroinformatikSound effectFocus (optics)Negative numberExterior algebraMereologyMultiplication signProjective planeHacker (term)Point (geometry)SpacetimeSingle-precision floating-point formatRule of inferenceShared memoryBitPhysical systemMathematicsTelecommunicationMathematical optimizationNumberRecursionRootComputer scienceContingency tableHypermediaAreaRight angleStudent's t-testForm (programming)Self-organizationLecture/Conference
40:21
Open setSoftwareFreewareComputer animation
Transcript: English(auto-generated)
00:08
Hi, everybody. Welcome, and thank you for coming. I'm a software engineer at Etsy.com, and Etsy is a global online marketplace where you can buy and sell handmade and vintage goods. I think we have 1.5 million active sellers right now,
00:23
and we value craftsmanship and human connection. And I write software to help sellers at Etsy. Now, the title of my talk is A Culture of Courage. And I wouldn't say that I'm an overly courageous person. In fact, I'm a bit shy, but I'm giving a talk right now,
00:41
so that requires a bit of courage. I'm mainly here because of my community of encouraging people. So these are my colleagues from the Etsy Spirit Squad, and I am very grateful for these encouraging people. So it hasn't always been this way for me, especially in internet-related cultures, among nerds and hackers of all kind,
01:01
and people like me, and all of us here, we see a lot of the opposite behavior. One-upmanship, outsmarting each other, or just bad communication. We've all done it, I've done it for sure. And I think it has to do with technology shaping our brains and behaviors. Wait, what did I just say?
01:20
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 describing. So every day I work with a computer. I love that because the computer has a great teaching instrument.
01:40
I love computers. From the nature of the construction as a machine, I know that the computer is 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 a bit
02:01
to find out more 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. In programming, small mistakes like a forgotten new line in the program code can make the computer unhappy. You all know this.
02:21
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 is also a very intimidating process. I have friends who can never remember their passwords, and they say it happens because they fear their computer,
02:42
because it's complex but rigid at the same time, and they fear doing something wrong when they touch it. So my job is building computer programs. That means I work on part of the system that are under development, and they are not quite working yet. So working with broken code is a main part of my job.
03:00
Imagine 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 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
03:21
slightly grumpy and stress 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. We want our code to be ready fast, because we have lots of things to do.
03:40
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, right? 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 a realistic outcome.
04:00
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.
04:26
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 coworker's code? Maybe we have different styles of writing. Sean likes spaces, and I like tabs. My friend Nina said, a good code base
04:41
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, and it can be an area of frustration when people insist on having their personal styles met, and they're not willing to collaborate on that matter. This happens surprisingly often, and I suspect it's because computers trained us over the years
05:02
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. We could say those are a bunch of different
05:21
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. It's a rigged game, right?
05:41
So there seems to be some fuzzy, emotional headspace element to working with computers, even though or 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.
06:02
When I grew up, my dad was a programmer, and even though he sat down at some point, and he 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. The C programming language? I don't blame him, I was in primary school, and this was the C programming language.
06:22
I was just too young. When he installed a new Linux version 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 learned to read the manual before daring to ask, before I was even in high school.
06:41
And then 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 over, helping 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 explanations of what he did. Must be wizardry.
07:04
In the university, I studied computer science, and I started going to the local hacker space. So this was actually before hacker spaces took off. This was the local Erhfag heiß, as we say in CCC. This was many years ago. There it dawned on me that doing things with the computer has a political dimension.
07:21
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, versions, arguing about over-heared opinions on software,
07:40
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 porn they share. These were the awkward years of undergrad study. Here I learned competing and outsmarting people,
08:01
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 day, when engineers were designing mostly trains or bridges, it made sense to have people prove themselves
08:23
and fight their way into the ranks of esteemed engineers in order to make sure they really know their shit, how to build stable bridges. But this one sensible idea overshot its target and created a culture that can be an obstacle to learning and development now.
08:41
During my following years as a PhD and post-doc, in which the university became my professional work environment, I saw more and more of these behavioral 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
09:01
and our geeky meetups. I saw people derailing a conversation by adding a non-relevant tangential detail with the phrase, well, actually, just like in school. I saw the same questions being asked at professional conference talks that were in fact just thinly-weighted statements of opinions or facts to put the speaker into place,
09:22
or directing the conversation to the person asking the question, instead of having a real desire to learn via having a burning question answered. Also, there was this really beautiful sounding but soft and squishy concept of meritocracy, or as the German geeks call it,
09:41
weir macht hat recch, whoever does it is right, which essentially says that fame in our culture is based on what you do and nothing else. So you are what you do, why you can hack, and what you coded. Sounds excellent to me, not being judged by what I do. Being judged by what I do
10:00
means stripping away other factors, such as money, class, race, age, gender, or other things that can be used to judge a person. No prejudices, sounds great, except for it doesn't work like that. And the meritocracy is a theory. In reality, people from different backgrounds are dead, very different hands in life,
10:21
and the amount of money, spare time, and education influences what they can hack on our code, what they can do, and what we judge 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 the people in this culture
10:41
will always be judged based on productivity. So even in our spare time, we're supposed to write blog posts, contribute to open source software, of course we do, and do cool stuff. So we're 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,
11:01
and I don't wanna say that we should never do such things in our spare time, but basing our value on it is almost like a logical fallacy that creates a lot of pressure. And it makes it hard to really take a break from things, or do useful things that don't fall into the school category, like spending time with my grandma.
11:22
Not taking a break makes most people depressed and burn out after a while. Also I noticed there was a pecking order of geekier than though, established in most work groups I was in. So people introduced themselves as OLT gurus,
11:41
network technology specialists, grumpy system admins with root privileges and keys to the data center. And many people introduced themselves with a history of how long they had been programming to make themselves more credible in the group. While I understand that every person has a history, and some people here had a great history, I really loved the talk we saw today.
12:02
While I understand this, and even though I did write my first program as a kid, and I compiled my own operating system queries before, I'm not sure why I should tell this to the people I work with now. It's of no relevance for them, except for trying to impress. It establishes a hierarchy, and it excludes people who are new to the craft.
12:21
Still, I catch myself doing it all the time. So looking closer at this pattern, there seems to be a war of generations going on. I am 33, I am somewhere in the middle of this war. The oil art dinosaurs of the internet are somewhat shaped by this geekier-than-though attitude.
12:43
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 prove that you know something, or at least you were able to set up your dial-up connection and read a newsgroup. But once you were in, you could be pretty sure to be safe
13:00
from the jocks and mainstream people that bullied you in school if you were a geeky. And times have changed, though. Now everybody's on the internet, and my 88-year-old grandma skypes me from her iPad. That's awesome. And with different communities, there are different interaction patterns again. So the internet is a part of everyday life now.
13:20
If I put on my dinosaur geek hat, it's about time to grow up and reflect on my behavioral 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 the space and make it bigger and even nicer?
13:41
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's because technical people
14:02
are more averse to focus on technology than on teaching. Or maybe it's because of outdated safety concerns. Who knows? 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 book. First of all, the book is most likely outdated, and secondly, the big leaps of learning
14:21
come from doing 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, in this parallel universe.
14:46
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.
15:01
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, or we like in different parts of this journey, they are known to the entire internet generation
15:22
of which I see myself and all of you as a part. It's the toxic undercurrents in a culture we all love. We have friends who are as geeky and who we really like. There are fun moments where the empowerment through technology makes up for occasional bad behavior. It can't be that bad, right?
15:40
So for me, 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 work now in what I would describe
16:02
as a culture of courage and encouragement. Before that, I went to a free school in New York City. It's called Hacker School. It's now called the Recurse Center. The school was like a writer's retreat for programmers. So there are no teachers, just facilitators. They tell you when you get stuck.
16:20
Essentially, you pick your own project, and then you pay a 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 for me. Hacker School created the space by giving us some simple social rules. I hope you can read this, yeah. So first of all, know well, actually.
16:42
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 asks for, just to sound smart and divert the conversation to themselves. A second one is no feigning surprise. So if somebody asks a fake surprise, you really don't know what a frame buffer is.
17:02
They don't accomplish anything except for making you feel bad. No backseat driving. If you listen to a conversation where two people are trying to learn something, and then you hijack that conversation with the answer, you make two people feel really bad and make them lose their chance of learning how to figure things out.
17:21
And last one, no subtle isms. This makes it possible to call out behavior that makes the space uncomfortable for marginalized people and make it welcoming for everyone. And this culture makes for a great learning environment, a place where people feel encouraged to try new things out, ask questions, and give answers in a straightforward way
17:42
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, felt great. When I started working at Etsy, I had to write code and bring it live to the website on my first day.
18:01
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 site to make sure it all worked, but it still felt like an empowering accomplishment to do this on day one. We call this the first push project because it's the first time an engineer pushes code to the site.
18:22
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,
18:42
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. Everybody could do it. Also, a few months later, I pushed code which contained a bug for the first time. Uh-oh.
19:01
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 made it out to the real website.
19:20
Yay. I was actually surprised about how relaxed and friendly my colleagues were in this situation. This was great. Nobody was angry at me. People gave me time and trust to fix the mistake. After I fixed the mistake, I found some super nice reassuring messages from my fellow engineers who said,
19:41
don't worry about breaking stuff. Everybody has done it, and they told me their faulty push stories. Even though they were all the way across the ocean, it felt like a giant wave of support. So from this anecdote, we can speak a bit about the process for pushing code to the side that we have. We always do it together.
20:02
We have a queue so that people don't push changes at the same time and ride all over each other's changes. We communicate a lot while being in the queue together. The push queue has opening hours to make sure that people are around watching, and people don't drive by a push late at night when they're tired, what I did do to my time zone thing.
20:22
And during the opening hours, and also off hours in case of emergency, every engineer has the full autonomy to push code to any part of the site. So we push continuously to the site, driving its change up to 60 times per day. And when something breaks, we can push a fix in the same quick fashion, which is oftentimes faster than reverting a change,
20:42
and we keep rolling forward all the time. There's also a custom which is very surprising for me at first, a prize for breaking the site in the most spectacular way. So this is really related to what Leslie said earlier with the fail cake in the previous talk, if you've been there. So we have the three-armed sweater for this.
21:02
And Etsy seller made a three-armed sweater as a reference to our famous error page, which looks like this, can you see it? And this sweater is awarded as a yearly prize. A colleague from our team once got the three-armed sweater
21:21
because he accidentally banned all Etsy admin from the site, burying us all from doing our work. Shit happens. The prize is giving away a bit jokingly as a reminder that failure happens, even though people usually have good intentions. Good intentions.
21:40
So good intentions and trust are a very important point to this philosophy. Overall, this strategy sounds counterintuitive, right, like we discussed before. Everybody can push code to the site, and there's no blame when people break something, and they even get a prize. Thinking a bit more about it, it makes sense, right? If we come from a place of trust,
22:01
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 its full behavior at that point in time. They didn't know that their behavior would have a different outcome from what they expected.
22:20
By blaming them or even firing them, we would let this opportunity of this great moment of learning pass, and the same mistake might happen again in the future. And of course, it's a calculated risk. We do have code reviews, we have tests, we have the collaborative deploy process, and a test server, which is called the Princess,
22:40
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, asking questions the right way.
23:03
Looking back at my time in university, I feel a bit sad about all the questions I didn't ask and the pressure I found back then around asking questions. After all, this should have been the place of learning in my life, so why was I so reluctant to ask questions? Because asking a question makes you vulnerable
23:22
and exposes an area of not knowing, and it 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 said phrases like, there are no dumb questions, do they really mean it?
23:41
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 must have the courage to ask more.
24:03
And of course, there's a trade-off. I don't want to be selfish and waste the classes or the professor's time and have them cater to my smallest needs. I understand that concern, but understanding each other requires asking questions sometimes, and this is surprisingly hard to do without an encouraging community, without good examples, and without practice.
24:22
It got a bit easier with practice and gaining more knowledge in general, but even as a grad student, I found it hard. I still find it hard sometimes. What is that, answering questions? At the same time, how can I help people to ask questions?
24:41
How can I answer a question without making the person who asks feel uncomfortable? As I briefly mentioned, some questions are indeed difficult. I call them unreal questions. They are no real questions. They are more demands of attention. Sometimes they're negative. This I've seen when another person gave a really good explanation
25:01
or when people speak in bigger groups. Maybe they are misguided attempts of a thank you. I'm still figuring them 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 fame, surprise, and well, actually,
25:22
and they encourage people to reflect on their communication patterns. They allow us to address negative mechanisms. We have names for them, right? A good first step is welcoming the question. So I have this colleague, Lara, and she's really great. So if you ask her a question, she will go, that's a great question with a lot of enthusiasm.
25:40
So it's really fun to ask her a question, and then she takes the time to answer it. It never feels bad to ask her a question. It's great. Another good step is to admit not knowing something as a positive example and make it a normal and non-scary thing that you don't know stuff sometimes. This can be used super constructively.
26:02
So when you say things like I've understood the first step of the problem, but then I don't know why the second step is happening instead of this other thing that I assumed to him. So you can debug your problem in this way, right? And this is an area where I try to watch myself continuously, it's hard.
26:20
Thinking about this change of perspective that my encouraging colleagues kicked off in me, I noticed a few takeaways. So we could say this is the courage and failosophy part, maybe. 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
26:42
to bigger systems. We all know that in a sufficiently complex system, it's impossible to oversee every detail. It's not possible for one human. There will be bugs. Then there's the myth of the 10 times engineer, some magical people who do 10 times the work of others.
27:00
This myth has to die because it's introducing more pressure when most people don't have a problem with not working enough. They have a problem with taking breaks. Also, doesn't moving 10 times as fast come at the cost of technical depth and an untidy code base for other people, maybe? It doesn't feel like it would work well with others.
27:20
And then there's this artificial boundary between engineers and users, or we could say writers and readers or artists and consumers of art, whatever. You see the pattern. And doing our first push program with non-engineers, or however we want to call this, people not in engineering roles, in our office was one of the most empowering moments in a long time.
27:41
In the end, we're all humans, and we can all do awesome things, and yeah, everybody could do it. And then there's this big element of ego and pride in programming and among nerds. So this is really interesting to me. Perfectionism is a big problem. It's leading to not finishing a project or maybe not even starting it yet in fear of it not being perfect.
28:03
And I think the narcissism of the modern internet, where everybody takes pictures and posts about their stuff, this makes it even worse, because you can see all the people around you presenting their awesome projects, and there are many overachievers or people with really great ideas or people that are just really smart, which can be intimidating.
28:21
Everybody wants to be awesome, right? And thanks to meritocracy, we also have the problem of strongly identifying with our code. So for some people, it's really 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 a breathing human being with a heart and not a machine.
28:42
But it seems easy to forget when people tell you this all the time. Maybe it's a thought coming with the immense power that you can change things in the programming arm. I don't know. Some people I know practice meditation in order to improve their skills of letting go of the ego and these overly controlling elements that come with programming.
29:03
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. Why? Our parents might have been angry when we got bad grades. Our inner voice might criticize us for every tiny mistake, wanting us to cover them up and hide them from others.
29:23
Opportunities for learning are lost in this frame of mind. And I think these three problems are disproportionately huge when working with our brains, ideas, or computers. I saw them among scientists, writers, artists, and geeks. Because oftentimes we cannot see the result of our work.
29:42
They seem virtual. We cannot touch them. It feels different than building a house from real wood with our real hands, at least for me. 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 on some days.
30:01
Did I do any work at all today? Maybe I'm just an imposter. Speak to your fellow nerds about this and find out when and why this happens to you. Another big field of action is the field of collaboration versus competition. So what's competition? Usually we compete when the resource is limited, right?
30:22
That's why countries fight over natural resources. In capitalism, we're 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 the digital world are shareable,
30:42
like education and information. And even if we are limited, if they are limited, like for example attention or one-on-one time of a person, collaborating and giving it freely and helping each other will empower everybody around you in the long run so that even more people can help each other and you in the future.
31:02
In Montreal, I was part of a group that practiced do-it-together, where we exchanged computer skills in our spare time. Julia from Montreal is giving away self-made zines about her favorite tool, S-rays. I think sharing and doing stuff together makes it less scary and more fun.
31:26
My favorite trick that I noticed and all of the above points is to go from this 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.
31:43
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 pat on the back or a kick in the butt. So I'm very grateful I'm in this place and I can talk about this here. I think it's important that we create an inclusive and safe space in which everybody can ask questions,
32:02
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. Being wrong and having to change my view is actually awesome because I just learned something and I evolved an idea. And I want to close with a suggestion
32:21
that you are someone's spirit squad. I had a transformation via other people. I don't have it all figured out. I'm still learning all of this. It's an ongoing process for me. I still encounter grumpy dinosaur geek parts in my personality every day. But I'm also starting more and more ways to build and expand this culture of courage.
32:41
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.
33:02
So do you want to ask questions here or do you want to maybe discuss at the side? It might feel more comfortable. Do you have questions? Okay. About the spirit squad at Etsy, how does it work like this? Oh, so I'm supposed to explain
33:22
what the spirit squad at Etsy is. So this picture is from the Etsy talent show and there was actually a cheerleading squad which is the Etsy spirit squad. So this was from a performance, this picture. But this is like, I use this as a metaphor. I know that these colleagues have my back and if I do something wrong, they're gonna help me out.
33:42
I can trust them 100%. No, that would be awesome. Great idea.
34:06
Yeah, so that's a bit what I'm trying to, so how can you teach children nowadays programming and have a better experience was the question. So I made this talk with the focus of
34:21
what did I experience and what would I like to be different so I think these rules that I got from Hecar School are creating these spaces. This would be what I would like to encounter so that I can have just my pure curiosity flowing out and exploring the world and answering all my questions
34:43
without these steps that I have to prove myself and so on and so on.
35:27
So I think the question was when you get an objective number from your system, how can you communicate when this number is negative? How can you communicate this in a good way? So I think I'm not really touching this here
35:45
but I think maybe this topic of non-violent communication that we heard in the previous talk could be helpful here. So you have to think of this emotional side too when you're discussing pure effects because we talk about computer science,
36:01
it's never purely facts. There's humans communicating and we tend to forget this part of it and especially dealing with negative things. There are some interesting reactions in the brain so if you tell a person, for example, negative feedback, their reptile brain takes over and their reptile brain
36:21
will say no, no, this is not true and then you cannot discuss it. So I would say for these things, if it gets emotional or if it's some negative things you have to talk about, come back to the discussion later after this brain reaction has passed because you can wait it out because it's happening in everybody. It's like a proven scientific thing.
36:44
More questions? Otherwise we can just talk and have a little discussion at the side maybe.
37:31
So how can you work with a system in which people are hoarding knowledge and they don't wanna share it? What can you do about this? That was the question.
37:41
I think that's also a cultural problem. So you have to create a culture of sharing. You have to create a culture where people teach each other, where learning comes first, where curiosity comes first and it's more important than having this single point of failure person and that you bow down to them because they have the knowledge.
38:01
But that takes time. Yeah?
38:27
So this question was about hacker school and the social roots and if there's maybe an alternative to this in Germany, I would just encourage you to try hacker school because everybody can go there. I mean I came there from here.
38:40
They are international. Everybody can apply there and it takes three months knowing which you can pick your own project. So you can just go to hackerschool.com. Now it's called the Recurse Center so now you have to find the new website because in my times it was called differently so now they are Recurse Center, recurse.com I think.
39:26
Oh Edwin wants to know if flipping the glass from half empty to half full, like optimism versus pessimism, plays a big role in this change like learning from failure and seeing it positively. I think that's definitely true
39:41
and we have such an attitude towards it but I think there's even more facts that speak for it so even if you just want to optimize the learning within your organization, it's a smart path to follow because otherwise these moments where you can learn something because something was wrong,
40:01
they would just pass by. No more questions? Then yeah, feel free to continue the discussion at the coffee stand or find me later.