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 | ||
| Number of Parts | 85 | |
| Author | ||
| License | CC Attribution 3.0 Germany: 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/38093 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
5
6
11
12
13
14
16
17
23
24
25
27
29
30
31
32
35
39
41
42
43
44
45
46
47
49
50
51
52
55
56
58
59
60
63
65
66
67
69
72
73
74
76
79
81
82
84
00:00
TelecommunicationChaos (cosmogony)BuildingSoftware engineeringComa BerenicesRight angleGoodness of fitConnected spaceSoftwareOnline helpComputer animationJSONXMLUMLLecture/Conference
00:38
RhombusBitMultiplication signLecture/ConferenceSource code
01:07
TelecommunicationHacker (term)Lecture/ConferenceJSONXML
01:35
Error messageSoftware engineeringBitSpeech synthesisPerspective (visual)GenderPattern languageSoftwareNeuroinformatikNatural numberProgram codeLine (geometry)Computer programmingMultiplication signDisk read-and-write headProcess (computing)Forcing (mathematics)Virtual machinePasswordConstructor (object-oriented programming)Point (geometry)Pairwise comparisonTouch typingRule of inferenceLecture/Conference
03:02
Computer programmingCodeMereologyPhysical systemProcess (computing)Software developerRight angleStress (mechanics)Constraint (mathematics)HypermediaMultiplication signNatural numberReal numberXMLLecture/Conference
03:53
CodeReal numberWordMultiplication signTrailProcess (computing)CodePerfect groupInheritance (object-oriented programming)Projective planeConstraint (mathematics)Chemical equationArithmetic meanKeyboard shortcutMereologyExpressionLecture/Conference
04:40
CollaborationismCodeConstraint (mathematics)Connected spaceSpacetimeGoodness of fitDifferent (Kate Ryan album)WritingKey (cryptography)TelecommunicationNeuroinformatikAreaCollaborationismFrustrationDecision theoryTerm (mathematics)Projective planeLecture/Conference
05:35
TelecommunicationChaos (cosmogony)ComputerNeuroinformatikDigitizingFuzzy logicSpacetimeElement (mathematics)Virtual machineGroup actionDifferent (Kate Ryan album)Lecture/Conference
06:19
Normed vector spaceTelecommunicationChaos (cosmogony)Programmer (hardware)Programmer (hardware)Point (geometry)Programming languageUML
06:44
Programmer (hardware)Chaos (cosmogony)Process (computing)Multiplication signNeuroinformatikModemOnline helpKeyboard shortcutDisk read-and-write headMenu (computing)Lecture/ConferenceXML
07:14
Computer scienceUniverse (mathematics)NeuroinformatikKernel (computing)Operating systemSpacetimeDimensional analysisPatch (Unix)Order (biology)Lattice (order)Lecture/Conference
07:43
Revision controlSoftwareForm (programming)MereologyObservational studyLecture/Conference
08:16
TelecommunicationChaos (cosmogony)Data miningCodeWave packetBridging (networking)
08:42
Bridging (networking)QuicksortSoftware developerRankingComputer scienceOrder (biology)Universe (mathematics)Integrated development environmentPattern languageLecture/ConferenceJSONXML
09:09
Pattern languageInternetworkingData conversionACIDStatement (computer science)WebsiteLecture/Conference
09:57
Product (business)Multiplication signControl flowProjective planeDivisorGenderTheoryOrder (biology)Different (Kate Ryan album)PressureSoftwareSocial classException handlingMetropolitan area networkBlock (periodic table)Lecture/Conference
11:52
Computer networkBranch (computer science)Group actionElectric generatorSoftwareRootKey (cryptography)Operating systemProgrammer (hardware)Computer programmingEvent horizonHierarchyMultiplication signData centerRhombusJSONXMLLecture/Conference
12:50
SpacetimeWebsiteSet (mathematics)Connected spaceGroup actionMetropolitan area networkForm (programming)Order (biology)InternetworkingEuler anglesComputer animation
13:27
Interactive televisionPattern languageInternetworkingMereologyVideo gameMultiplication signSphereElectronic program guideSource codeDifferent (Kate Ryan album)Interior (topology)Lecture/Conference
14:16
Exclusive orComputer programmingTheory of relativityLink (knot theory)Universe (mathematics)CausalityGraph (mathematics)Graph (mathematics)Social classLecture/Conference
15:17
TelecommunicationCode
15:41
Chaos (cosmogony)TelecommunicationPattern languageEntire functionInternetworkingElectric generatorRight angleExtension (kinesiology)AreaDifferent (Kate Ryan album)Interactive televisionComputer iconOrder (biology)Key (cryptography)Moment (mathematics)Lecture/Conference
16:25
TelecommunicationChaos (cosmogony)Ocean currentFreewareHacker (term)RecursionComputer programmingProgrammer (hardware)Projective planeOnline helpSpacetimeWordRule of inferenceXMLUMLLecture/Conference
17:07
TelecommunicationChaos (cosmogony)Data conversionFrame problemException handlingComputer animation
17:48
Point (geometry)AreaSpacetimeIntegrated development environmentInsertion lossMarginal distributionLecture/Conference
18:20
TelecommunicationChaos (cosmogony)WebsiteProjective planeMultiplication signCodePanel painting
18:49
Data managementWebsiteSound effectProjective plane1 (number)Artificial neural networkVapor barrierOffice suiteCodeLecture/Conference
19:21
TelecommunicationChaos (cosmogony)WebsiteMultiplication signBitSoftware testingServer (computing)Software bugCodeInternetworking
19:45
Multiplication signMessage passingInheritance (object-oriented programming)BitProcess (computing)CodeLecture/Conference
20:17
TelecommunicationChaos (cosmogony)MathematicsQueue (abstract data type)CASE <Informatik>Forcing (mathematics)Multiplication signControl flowMereologyCodeLecture/Conference
21:04
TelecommunicationChaos (cosmogony)Multiplication signError messageWeb pageWebsiteWater vaporSystem administratorBitComputer animationLecture/Conference
21:39
TelecommunicationChaos (cosmogony)Goodness of fitRight anglePoint (geometry)Strategy gameCodePhysical systemMultiplication signMoment (mathematics)CollaborationismSoftware testingServer (computing)NP-hardBitInstance (computer science)AreaTask (computing)Process (computing)Lecture/Conference
23:00
Multiplication signUniverse (mathematics)Video gamePressureAreaSpacetimeLibrary (computing)Goodness of fitBitSocial classStudent's t-testLecture/Conference
24:37
TelecommunicationChaos (cosmogony)Mechanism designMultiplication signTelecommunicationAreaGroup actionRootHacker (term)Pattern languageLinear regressionSpecial unitary groupComputer animationMeeting/InterviewLecture/Conference
26:07
Group actionTelecommunicationChaos (cosmogony)MathematicsPerspective (visual)Physical lawText editorPerfect groupCASE <Informatik>Physical systemSoftware bugEstimatorMultiplication signComplex systemScaling (geometry)Complex (psychology)XMLUML
26:39
TelecommunicationChaos (cosmogony)Multiplication signPressureMetropolitan area networkControl flowXMLLecture/Conference
27:06
TelecommunicationChaos (cosmogony)CodeOffice suiteOrder (biology)Moment (mathematics)Artificial neural networkMultiplication signElement (mathematics)Projective planeBoundary value problemInternetworkingComputer programmingProgrammer (hardware)Power (physics)Virtual machineWordPerfect groupOptical disc driveRight angleXML
28:31
Element (mathematics)MereologyCodeProcess (computing)Inheritance (object-oriented programming)GradientWordGroup actionFrame problemDifferent (Kate Ryan album)Text editorTheoryNeuroinformatikSpeech synthesisField (computer science)ResultantReal numberLecture/ConferenceXML
29:45
CollaborationismTelecommunicationChaos (cosmogony)GradientNatural numberCollaborationismProduct (business)Goodness of fitMultiplication signArtificial neural networkMereologyPower (physics)Group actionDynamical systemNeuroinformatikMedical imagingDigitizingWordInformationXMLLecture/Conference
30:40
TelecommunicationChaos (cosmogony)Point (geometry)Network topologyPhase transitionShared memoryBookmark (World Wide Web)Electronic visual displaySpacetimeArithmetic meanView (database)Right angleLecture/ConferenceComputer animation
31:43
TelecommunicationChaos (cosmogony)TwitterWordTransformation (genetics)Process (computing)MereologyComputer animation
32:16
EmailJSON
Transcript: English(auto-generated)
00:14
Hi, everybody. Welcome, and thanks for coming. I'm Stephanie Schirma. I'm a software engineer at Etsy.com. Etsy is a global online marketplace where you can buy and sell handmade and vintage
00:27
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,
00:47
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
01:04
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 behaviour. One-upmanship, outsmarting each other, or just plain bad communication.
01:22
We've all done it. I've done it. I think it has to do with technology shaping our brains and behaviours. Wait, what did I just say? Technology makes us evil? That's it. I'm speaking from the perspective of a software engineer, but I think we can deduce
01:43
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
02:02
lies. A faulty behaviour 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,
02:27
that means it's kind of inflexible, right? In 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
02:42
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
03:03
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? 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
03:25
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
03:42
and stress me out. All these not working yet things before I heard this thought from my co-worker 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
04:02
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,
04:24
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
04:41
is the connection of our work to the rest of the world. How does my code work together with the rest of the codebase 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 codebase should look like a single person wrote it, no matter how many people contributed. There's
05:02
some communication and decision-making to accomplish this, and 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.
05:22
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
05:41
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
06:01
seems to be some fuzzy emotional headspace element to working with computers, even though, maybe because they are unemotional machines. I started realising this when I transitioned between different communities working with computers. Let's talk about technical culture.
06:22
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
06:45
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
07:02
installing Linux on my own computer, doing it all alone with just the help of the fine manual. 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
07:32
it dawned on me that doing things with a computer has a political dimension. I learned a lot of details, tuning my computer at night, patching and building the kernel of my operating
07:42
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 over-heared 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
08:05
people seemed to be afraid we might find out about the porn they share. These were the awkward years of undergrad studies. Here I learned competing and outsmarting people,
08:23
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
08:42
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 created a culture that can be an obstacle to learning and development. During my following years
09:04
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
09:20
on professional sites like Hacker News and Stack Overflow just as we had done it in our undergrad years in our geeky meet-ups. 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
09:43
to put the speaker into place, or directing the conversation to the person asking the questions. Instead of being a real desire to learn by having a burning question answered. Also, there was this really beautiful sounding but soft and squishy concept of meritocracy.
10:03
Or, as the German geeks like to call it, 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
10:21
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. The meritocracy is a theory. In reality, people from different
10:40
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.
11:00
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 are supposed to write blog posts, contribute to open-source software, and do cool stuff, so we are optimising ourselves to be productive, even in our spare time. Don't get me wrong, I love tinkering and
11:22
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 I do useful things that don't fall into the cool tech projects pattern,
11:41
like spending time with my grandma. Not taking a break makes most people depress 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
12:01
as OLC gurus, network technology specialists, grumpy citizens with root privileges and keys to the data centre, 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 even though I did write my first programme as
12:22
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.
12:40
Still, 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 shaped by a geekier than though attitude.
13:05
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 news group. Once you were in, you could be sure to be safe
13:24
from the jocks and mainstream people that bullied you in school if you were a geeky. Times have changed, though. Now everybody is on the internet, and my 88-year-old grandma Skypes me from her iPad which is awesome. With different communities, there are different interaction patterns again. The internet is now part of everyday life. If I put on
13:48
my dinosaur geek hat, it's about time to grow up and reflect on my behaviour 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
14:04
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
14:23
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? 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.
14:44
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 is no such thing as an apprenticeship or a master-apprentice relation when learning
15:00
about programming, because it is 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
15:24
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 behaviour patterns, or we
15:47
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,
16:02
and there are fun moments when the empowerment through technology makes up for our occasional bad behaviour. It can't be that bad, right? I didn't fully realise the extent to which it was dragging me down, and how much of this behaviour was ingrained in me myself before I moved across the ocean and back where I encountered different tech communities
16:22
with a different interaction style. I now work in what I describe as a 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
16:41
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 programme 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
17:02
by giving us some simple social rules. No, well, actually, if you're trying to explain something and another person corrects you with, well, actually, what they usually do is throw in some facts nobody asks for just to sound smart and divert the conversation to themselves. No fainting surprise. So, if someone asks you in fake surprise, what?
17:27
You really don't know what a frame-muffer is, 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
17:42
answer, you make these two people feel really bad and make them lose their chance of learning how to figure it out. No subtle isms. This makes it possible to call out behaviour that makes the space uncomfortable for marginalised people and make it welcoming for everyone. This culture makes for a great learning environment, a place where people feel encouraged
18:04
to try new things out, and ask questions and give answers in a straightforward 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,
18:27
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,
18:40
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 side. A few months later, my colleague Dan and I organised 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
19:02
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
19:23
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
19:43
my bug before I 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
20:04
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. 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
20:24
same time, and write 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. During opening hours, and also off hours in case of emergency, every engineer has
20:45
full autonomy to push code to any part of the site. 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 reverting it and keeps us rolling forward all the time. There is also a custom which was very surprising
21:06
to me at first. A prize for breaking the site in the most spectacular way. An Etsy seller made a three-armed sweater as a reference to our famous error page which looks like this. This sweater, which is a real thing, you can put it on, is awarded
21:24
as a yearly prize. A colleague from our team once got the three-armed sweater because he accidentally banned all Etsy admin from the site, wearing us all from doing our work. The prize is giving away a bit jokingly as a reminder that failure happens, even
21:42
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,
22:00
and they even get a prize! 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 its full behaviour at that point in
22:20
time. They didn't know that their behaviour 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. And, of course, it's calculated risk. We do have code reviews, tests, and the collaborative deploy process,
22:42
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 is still a bit hard for me is asking questions
23:04
is 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
23:21
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
23:43
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, or fair. What I only realised 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 had mustered the courage to ask more. Of course, there's
24:05
a trade-off, and I don't want to be selfish and waste 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
24:25
more knowledge in general, but even as a graduate student, I found it hard. I still find it hard sometimes. At the same time, how can I help people to ask questions?
24:42
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
25:01
groups. Maybe they are misguided attempts of a thank you. I'm still figuring those out. But back to answering a real question, the roots of hacker school helped me a lot here because they cut out a great deal of subtle or maybe even subconscious ridicule in both things such as feigned surprise and well-actuallys, and they encourage people to reflect on their
25:22
communication patterns. They allow us to address negative mechanisms. We have names for them. 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
25:41
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 assumed
26:01
to happen. 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. We call this the courage and philosophy part. First of all, there are a bunch of
26:21
myths in engineering culture that hurt us. There is the myth that there is 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. There will be bugs. There is the myth of the ten times engineers, some magical people who do ten times the
26:45
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, doesn't moving ten times as fast come at the cost of technical debt and an untidy codebase for other people? That doesn't feel like it would work well with others.
27:06
And then there is 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 programme with non-engineers in our office was one of the most empowering
27:20
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 in 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
27:44
modern internet makes this even worse, because you can see all the people around you presenting their awesome projects, and there are so many overachievers 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
28:05
identify with their code. So, for some people, it's hard to get a code review with criticism in it, because they learned that they are their code. Which is obviously not true when you're a breathing human being with a heart and not a machine. It's easy to forget
28:20
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 the big part of society
28:41
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 criticise us for every tiny mistake, wanting us to cover them up and hide them from others. Opportunities for learning are lost in this frame of mind.
29:02
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.
29:20
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 on some days. Did I do any work at all today? Maybe I'm just an imposter. Speak to your fellow nerds about this and
29:40
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 the world is 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
30:03
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
30:25
will empower everybody around you in the 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 practised Do It Together where we exchanged computer skills in our spare time. Julia from Montreal
30:41
is giving away self-made zines about her favourite tool, S-Trace. I think sharing and doing stuff together makes it less scary, and it's fun. So, my favourite 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
31:04
no blame and shame, failure becomes a learning opportunity right away. 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. I think it's important that we create an inclusive and
31:25
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
31:40
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 via 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
32:02
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.