This talk looks at the challenges of exclusionary attitudes within the tech industry, particularly ones that might be less apparent like the varying levels of experience and knowledge among professionals. It highlights instances of ‘exclusionary nerdery,’ such as reactions to unfamiliarity with older technologies like floppy disks or newer concepts like serverless computing. It explores the industry’s struggle with effectively narrating its history and integrating diverse experience levels without creating feelings of inadequacy. It delves into various forms of exclusion that are often overlooked and discusses strategies for building more inclusive teams and communities. By embracing the full range of experiences, the goal is to improve the quality of the software by improving the harmony and happiness of the teams building it.
Transcript
OK. So the title is “You Used Floppy Disks, So What?” which might feel a little spicy. But don’t worry, I have an alternate title, so no one feels left out.
I just put some random shit down. But in this talk, it’s about stories and how we communicate. Which I honestly think is perfect for Monktoberfest. while you may not be in marketing or write regularly, but we all communicate. And stories are everywhere. Stories are the way humans convey concepts, ideas, memories, events, emotions to each other and our days are full of them. They might be little bite-sized things. Others are larger presentations or ideas. And this talk is rooted in a few different things. I don’t want to offend anyone in this room, so first of all the title is a little spicy, but first I want you to understand where it’s coming from. It’s coming from a love of our industry. It’s an attempt to include more while we’re building these really great products, tools, open source projects and infrastructure and so much more and this isn’t talk about putting down experience, because you had those experiences and no one can take that from you. It’s more about communication, storytelling and building environments where a diversity of experiences not only exists, but is embrace. I’m not really calling anyone out specifically. We’re guilty as a group, so if you feel called out, I’m sorry, you’re not alone and if there’s something you really don’t feel I handle well, come up and talk to me about it. I’d like to get that feedback.
So I want people to get excited, experience joy and have fun conversations about technology. I’m not talking about conversations with your buddies, people you know really, really well in private settings. I’m talking about conversations that happen in Slack, in our communities out in the public that others are a part of.
But before we get a little too deep. I started out in software engineering. I quickly realized that I wanted more than that. So I’ve been in Developer Relations for a little over eight years now. Typically work at startups, I’ve been working as a staff Developer Advocate for a little over two years, the mySQL database platform. I wear a lot of hats literally and figuratively. I’ve got any Developer Advocate hat, my engineering hat, my product hat, my community — I could just go on, documentation, the list is very long. But the one thing I’ve noticed that goes throughout all of these is storytelling.
It might be talking to a developer, explaining a new feature, it might be talking to engineering about a feature request for a user. They are all stories.
And so my first story was I was working with a new grad last year or the year before, and they asked me this question: What came before Vercel and Netlify. And for context, really popular places today, and they partially created this whole new era of how we deploy things on the web on top of serverless architectures and so they were basically asking, what came before our current modern web development practices and my response was, what? Do you think they maybe knew a little bit before that, but where do I even begin? Some engineers might react in a negative way, maybe even have less respect for them. Screw that. In this case, my experience was important. And I couldn’t blame them for not knowing. The systems set them up for this. They didn’t learn this in college. They came into an industry and did what everyone else was doing, go deploy to this thing, it’s really easy and so I explained it the best I could, but I realized this wasn’t going to be the last thing something like this happened. I needed to get better at it. So the term I want to focus on is exclusionary nerdery. Because we are all passionate nerds about something, and actually I agree with this term, first time here Monktoberfest last year. It was from Rachel and her talk about introspection gaps. It was just one bullet on one side but suddenly my brain clicked, that there were so many experiences that I’d seen or had and had no name for and it was exactly this, so like Rachel said, in many ways we intentionally and unintentionally create this on ourselves, we are totally allowed to be passionate and geek out about things we love, but we need to make space for others in our industry, so people can see themselves in our industry. It’s not a contest of who’s nerdier. So that we can build better products that are informed by just not one person’s ideas, but lots of people’s ideas.
And so if you break this down, solutionry, having the effect of excluding or shutting someone out, enthusiasm for a particular subject, put those together so you’re having the effect of shutting someone out by enthusiasm for a particular subject. The important words here are having the effect. I know most people generally don’t do this on purpose, but it is something to remind ourselves before we go into some of the examples, but it’s the difference between intent versus impact. It may not be your intent to shut someone out, but it could be the impact that you shut someone out.
So I want to go through just a few examples. There’s some out there. First one is manual work as a flex. There’s a whole new generation of developers out there that have totally different expectations of their tools and technology. Manual work is no longer a flex for them. They don’t want — high learning curves will always exist in certain parts of the industry, but they don’t want to do that for basic things, they just want to build and one great example that I have seen is, you bring up — you’re having a conversation about like an email API and someone brings up like maintaining their old email server and all the complexities of that, and somehow they’re using that and they’re using this for a flex that they know more about email and you’re like, cool, I just want to send this email for a job application.
Again, it’s important that you may have had that experience, but be careful how you wield it.
Examples, you know, we often have specialized knowledge based on our work. This issue comes up when we take the specialized knowledge and thenoo try to create factions amongst ourselves. Maybe it’s because of my background, but I find folks who work in the backend generally put-down frontend engineering. For various reasons. That’s a whole talk.
Which is ridiculous to me, because frontend engineering today is like, freaking hard. Why should it matter if they don’t understand some very specific backend concept. That’s not their job. Their job is to focus on the performance of the actual frontend application. I see similar things between software and hardware engineers, product and infrastructure teams and many more.
Now, this is actually an example of when Rachel gave her talk, I thought of first. Reminiscing on older technologies, AKA every Slack I’ve ever been in. Conversation is someone less than if they used a Commodore 64 instead of some machine being a random computer in the ’90s, from Sam’s Club? Which is my first machine. The other side doesn’t know how to participate. You’re younger, you have different experience, maybe they try to participate and they engage and they get shut down, because you don’t know what you’re talking about, something like that.
That’s a really popular one. There’s a little bit of story for this one. In the ’90s, LAMP stack dominated. Which means all the work was being done. In average performance, then a lot of client-side rendering started happening, became really popular, so a lot of that work was being done on the browser side and next thing you know, everything is getting slow, the browser is getting overloaded and then kind much the web developer will move to more of a hybrid model, which is more where we are today and they love to remind everyone, often a PHP developer — they love to remind everyone that this has already been done in the LAMP stack thing. This isn’t new, why are you talking about this brand new thing? Like, yeah, cool, are you adding to the conversation by saying that? The reality is, what is often old becomes new again in some form. Like, don’t be that person.
And then the last one, home labs and networking. You have to spend more time around infrastructure and network engineers to hear this one. There’s nothing wrong about being passionate about it. Sharing on social, chatting among good friends about it, but just make sure you’re not excluding other people about it. Despite the fact that I can terminate a cable, I can buy it on the shelf. Am I less of an engineer because I don’t care as much about my home network? No.
What is the impact, it makes people feel less than. It doesn’t actually help people learn. They’re not getting experience from these exclusionary tactics.
It creates ons unnecessary division between teams and people and people from different demographics and it just continues the cycle of we’re not in this together, that we have different experiences and somehow that, like, divides us.
And the impact is also intersectional. I was talking about this conversation with an older white woman in tech, and she pointed out that ageism for non-men is different. Women, for example, can’t carry that badge of experience sometimes. It’s different than for men. If they reveal that they were working on that Commodore, it could result in different responses from the conversation. All these things are intersectional. They’re interconnected between different identities, like race, gender, socioeconomic background. If you’re a care-giver or not, the list goes on.
It’s important to remember this is not black and white. There are many shades of gray here.
When I was thinking about this idea of exclusionary nerdery, how I’ve dealt with it over the years, other than those technologies that were all created before 200 0, what do they have in common? They’re my defense mechanisms. They’re things that I’ve developed to say in conversations just to fit in? Should I need these? Of course not. But being represented in tech means that we have to prove our technical credibility at every step of the way.
My first programming Lang was Pascal and it was a little outdated at the time but that is what I was introduced into. Then I got into some Delphi UI stuff which is very ugly and when people talk about old UI programming, I feel like I can bring that conversation up. When I was at IBM, I was using Lotus Notes which I think has a new name now that they’ve sold it off. But I don’t know what it is. And then my first database. I was like using Microsoft Access in ’97 whens I was pretty young, creating like fake businesses on it because the computer I had didn’t have an internet connection, and I was like, cool, what can I do with the Microsoft Office suites? But should I feel like I have to have these defense mechanisms? No. But I know other people have these, too.
So it brings us to this question: How do we learn technical history today? GitHub repos? That’s sometimes to tell a good story, although most of those developers are pretty bad at marketing so it’s a little iffy at times. You can read the commits, the issues, the pull requests, maybe some code comments.
Rarely documentation about history and why different things were actually done.
But there’s always something miss interesting.
Formal education? Iffy. Maybe if you’ve done some graduate work, you get more into things. But otherwise, it hasn’t historically been very helpful here. I don’t know about anybody else, but the only historical mention that I had was never again was that mentioned, but it was a great tragedy, go into the Wikipedia page. But this is one example in all of the computer science degree that is really silly to me.
Museums, books and blogs, who’s curating the museum? Who’s actually representing the whole industry? Who are the ones who had this power. Many voices are often missing, people are left out of history. Who are the actual people consuming it? Like, it’s not really super-accessible.
And then the most popular form: Wonder of mouth or personal curiosity. These take time, motivation, knowledge that the thing even exists, and so much more. I have my own, you know, I’ve dug down into different things. One of these is within develop wer experience, there’s the thing of Hello World, but I never knew where that came from. The first time it kind of appeared was in Brian K’s, it they needed something to make sure that all the components of a language, the compiler, development and runtime environment could all have been installed correctly and there was no standard first program at the time, and he wrote Hello World. Something some places say it was based on something about a chicken and egg that he saw that said Hello World, I don’t know, but it’s cool to me that it’s a program that transcends history. It’s been around for decades, we’re still doing today, but many people don’t even know, like, where did that actually come from.
Learning technical history is something which is not super-easy. It takes a lot of digging and I believe there is a better way to talk about it.
How can we explain technologies and experiences in a useful way? How can we learn about it without having to posture about experience? How can we have these conversations and not be exclusionary, and instead, inclusive and interesting to everyone who is a part of the conversation.
Now, I could give you the traditional marketing lessons on how to tell a story, but I don’t really think y’all need to know these things. They’re not really useful in most people’s day to day. But I want something that everyone can use and when you’re communicating.
So the first one comes from Recurse Centers social rules. resource center have social rules to put in place to help you learn. And if feigning surprise is when you act sprays surprised when someone doesn’t know something. So similar in my story at the start of the talk. Responding with surprise at the situation, makes that person bad for not knowing it. Makes them less likely to ask questions in the future, and which makes it harder for them to learn.
The next time they have that question, they’re more likely to keep their mouth shut and never ask at all. There is no social or educational benefit for acting surprised when someone asks a question.
Create an environment where people will continue to ask these questions. A tip from Julia Evans is if you are surprised, don’t act like it and if you need to turn that energy of being surprised, turn it into enthusiasm into answering their question and that they even asked it in the first place.
Know your audience. Who’s your audience? Do you understand anything about their background? You have to gear what you’re saying, to who you are talking to. I talk about this all the time in my day job. I can’t explain the backend can concept to a frontend engineer in the same way. They’re going to respond to it differently and so I constantly ask, when someone’s creating anything, talking about anything, who’s the audience in this conversation? Leave space. So Python community really started the Pacman rule. It’s when you’re standing in a group of people, you always leave room for one person to enter the conversation. It’s giving them specific permission to join the group. What about in virtual spaces? On conversations online? Are you giving someone the opportunity to join that group, to come into the conversation? And not only listen, but be a part of that conversation?
Take cues from people when they’re having a conversation. If they’re trying to respond and, like, nobody is really reacting to the response maybe respond to them directly so that they know that they’re not left out of that conversation.
And also think of the dynamics of this, power dynamics in the conversation. If the person who’s leading the conversation in a way, has more power, what is it like for someone with less power to be a part of that conversation?
Empathy. At this point, I still feel like empathy is a little bit overused but I still think it’s important. The ability to understand, share feelings of another.
I don’t think you can be a really good storyteller without empathy? Will it be a good story for some? Yes, of course, but to a broader audience, probably not.
We were all new to things once upon a time. It’s kind of hard to remember, though, time happens, you gain a little experience, so the next time, it’s a little different. It’s kind of hard to remember that. You aren’t always going to feel the feelings that the people on the other side have, but we have to find a way to share experiences that we can relate to so we can have empathy. I see two types of failure here. Problems caused by my words don’t affect me so therefore they’re not a problem, or two, which are related. Beginner’s mind failure, it’s perfectly clear to me, I do not understand why you’re not understanding this.
Side brand and related. Sarah Mei has this amazing talk, calmed the power of agile. It’s about the agile manifesto, the 17 white men that created this thing that kind of transformed how we work. Where are the people of color? There’s not even a white woman. Where are the other gender minorities? Where is literally anyone else in this photo? Doesn’t look like this room. And the real problem is they have the power and those power dynamics, and these stories of agile are coming from a very specific demographic.
It’s total empathy failure to me. They’ve created something for a whole industry, and it didn’t even reflect what that industry was. But I’ll go back to the 5th tip. But go watch Sarah’s talk. It’s amazing.
Really great about power dynamics.
When you mention a technology, explain it, especially in a broad audience. You might have NPS noticed something when I explained Vercel and Netlify. I didn’t even ask, I just explained it. Don’t assume that people know everything you know.
Who has used whatever, OK, speaker says that, 17 people in the room raise their hand and they go on with the talk without ever explaining it and 25% of the room has no idea what they’re talking about. Don’t do that. Just explain it. Don’t even ask questions sometimes. In a smaller group, maybe ask that it needs explained. Don’t assume that because somebody has less experience, they don’t know. Maybe they do and you’re just wasting their time.
And the best stories tap into emotions and pain, especially when you’ve had like previous project you might have been working on, had a lot of stories of emotion and pain, and you want to convey that to the next group working on it. Like, you know, those are grew great. Somehow we had forgotten that what developers do best is learn, it’s something that was said in a blogpost years ago, we have to give people the opportunity to learn. Younger people are building on things like serverless and they never experienced what came before that. But the thing is, future generations care what the past generations think. They actually do care. They may act like they’re too cool for it, but they’re not. They look to them to understand the intent to guide them.
So what we need to say what the intent was, not just this is how we solve this. Why? Why is it like this? And that pain and emotion is like really good to understand part of that.
So those are the 6 tips. No feigning surprise, know your audience, leave space, empathy, explain technologies, and no badges, but communicate that emotion and pain.
And I just want to touch on one last thing before the end.
The future. where — how should we think about this going forward? As more products, tools, open source projects are released, the need for storying telling and communication of ideas is only increasing.
I look at frontend engineering world, for example, which I sit very adjacently on, and I swear like every day, multiple times a day, there’s a new shiny tool launched and I have no context times for how I should think about this tool unless I really spend a lot of time looking into this. And we just need to make that easier, to better understand. More and more solutions come from understanding the past. We learn from history. Unless we know where we came from, how are we going to improve and build better projects in the future? We’re constantly tackling new challenges, but they often have subtle differences from the old challenges at times, but they’re always related in unique and interesting ways, and I think if we build one of the better projects with an understanding of the past, we need, you know, to be more well informed. And more informed solutions is I believe the future.
So I want to end with a question. Are there stories you can go tell that you might have thought of during this talk? I’d love to hear them from you later. But yeah, thank you so much.
[applause].
