Podcasts about devreps

00:44 - Pandemic Life * Politics * Healthcare * Society * Work 13:58 - Jay, Happiness, and Fulfillment * Personal Development and Self-Discovery * Brené Brown (https://brenebrown.com/) * Glennon Doyle (https://momastery.com/) * Elizabeth Gilbert (https://www.elizabethgilbert.com/) * Nihilism (https://en.wikipedia.org/wiki/Nihilism) * Manifestation * Gratitude & Daily Journaling * Morning Pages (https://juliacameronlive.com/basic-tools/morning-pages/) * EarlyWords (https://earlywords.io) 29:09 - Witchcraft & Magic * Intention and Ritual * Terry Pratchett (https://en.wikipedia.org/wiki/Terry_Pratchett) * Franz Anton Mesmer (https://www.britannica.com/biography/Franz-Anton-Mesmer) * The Placebo Effect (https://www.webmd.com/pain-management/what-is-the-placebo-effect) * Zenify Stress Relief Drink (https://zenifydrinks.com/) * Effort and Intention Reflections: Mandy: Everyone should journal. Reflect on the past and bring it to the present. Damien: Bringing magic into non-magical environments. Aaron: Ritual, intention, reflection, alignment. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: DAMIEN: Welcome to Episode 277 of Greater Than Code. I am Damien Burke and I'm joined with Aaron Aldrich. AARON: Hi, I am Aaron and I am here with Mandy. MANDY: Hello, everybody. I'm Mandy Moore and today, it's just the three of us! So if you came expecting more than that, I'm sorry. [laughter] We're what you get today, but hopefully, we can have a great conversation and we were thinking that we would talk about all the things. I'm doing big hand gestures right now because there's been so many things happening since 2020 that are still happening and how our perspectives have changed. For one, I, myself, can tell you I have grown so much as a person in 2 years. And I'm curious to hear how the two of you have been living your lives since the pandemic. DAMIEN: [chuckles] Where to begin. AARON: I know. It's such a good topic because I feel like everyone's had so much to change, but at the same time, it's like, okay, so 2 million years ago at the beginning of this pandemic. I'm now my third place, third job since the beginning of the pandemic as well and wow, I came out as non-binary in the middle of the pandemic [laughs]. So that was a whole thing, too. I think the question I asked earlier is how much have you radicalized your politics over the course of the past 2 years? [laughs] DAMIEN: Yeah, yeah. That's been bouncing around in my head since you said it off mic. Every time I hear the word pandemic now, I think about, “Oh man,” I hesitate on how far to go into this. [laughs] Because I look at the techno-anarchist crypto bros and I can I say that disparagingly and I will say that disparagingly because I was like them. [laughs] I filled out a survey today and they asked like, “How do you rate yourself as on a conservative and liberal scale?” I'm like, “Well, I think I'm super conservative.” And I still do and every time I align with any political policy, it's always an alignment with people who call themselves socialists and leftists and why is that? [laughs] Hmm. [laughter] But anyway, that was the part I was trying not to go back into. [laughs] One of the big realizations in living in a pandemic is that healthcare is not an exclusive good. MANDY: What? [laughter] DAMIEN: That is to say that I cannot, as an individual, take care of my own health outside of the health of the community and society I live in. Didn't know that. In my defense, I hadn't thought about it, [laughs] but that was an amazing realization. AARON: No, I think that was a big thing. I think so much of the pandemic exposed the way our systems are all interconnected. Exposed the societal things. Like so much we rely on is part of the society that we've built and when things don't work, it's like, well, now what? I don't have any mechanism to do anything on my own. What do we do? DAMIEN: Yeah. It's so fundamental in humanity that we are in society. We are in community. We only survive as a group. That's a fundamental aspect of the species and as much as we would like to stake our own claim and move out to a homestead and depend on no one other than ourselves, that is not a viable option for human beings. AARON: Right, yeah. Even out here in rural Vermont with animals and things, we're still pretty dependent on all of the services that are [chuckles] provided around. I'm still on municipal electric service and everything else. There's still dependence and we still rely on our neighbors and everyone else to keep us sane in other ways. DAMIEN: Yeah, and I feel like people in rural areas—and correct me if I'm wrong, I haven't lived in a rural area in maybe ever—have a better understanding of their independence. You know your neighbors because you need to depend on them. In the city—I live in Los Angeles—we depend on faceless institutions and systems. AARON: Yeah. DAMIEN: And so, we can easily be blind to them. AARON: Yeah. I think it mixes in other ways. I get to travel a bit for work and visit cities, and then I end up coming back out into the rural America to live. So I enjoy seeing both of it because in what I've seen in city spaces is so much has to be formalized because it's such a big deal. There are so many people involved in the system. We need a formal system with someone in charge to run it so that the average everyday person doesn't have to figure out how do I move trash from inside the city outside the city. [laughter] We can make that a group of people's job to deal with. Here, it's much more like, “Well, you can pay this service to do it, or that's where the dump is so can just take care of it yourself if you want.” “Well, this farm will take your food scraps for you so you can just bring this stuff over there if you want.” It's just very funny. It just pops up in these individual pockets and things that need group answers are sometimes like pushed to the town. You get small town drama because like everyone gets to know about what's happening with the road and have an opinion on the town budget as opposed to like, I don't know, isn't that why we hire a whole department to deal with this? [laughs] DAMIEN: Yeah, but small town drama is way better than big town drama. The fact that half of LA's budget goes to policing is a secret. People don't know that. AARON: Yeah. DAMIEN: Between the LA Police Department and LA Sheriff's Department, they have a larger budget than the military of Ukraine. That's the sort of thing that wouldn't happen – [overtalk] AARON: Don't look at the NYPD budget then. DAMIEN: Which is bigger still, yeah. [laughter] That's not the sort thing that would happen in a small town where everybody's involved and in that business. AARON: Yeah. It happens in other weird ways, but it's interesting. This is stuff that I don't know how has, if it's changed during pandemic times. Although, I guess I've started to pay attention more to local politics and trying to be like, “Oh, this is where real people affecting decisions get made every day are at the municipal levels, the city level.” These are things that if we pass a policy to take care of unhoused, or to change police budget, this affects people right now. It's not like, “Oh, wow, that takes time to go into effect and set up a department to eventually go do things.” It's like, “No, we're going to go change something materially.” It's hard to compare the two because the town I'm in rents a police officer part-time from the next [laughs] municipality over. So the comparison to doesn't really work. [laughter] DAMIEN: Everybody knows exactly how much that costs, too. AARON: We do. I just had to vote on it a couple Tuesdays ago. [laughter] DAMIEN: So then I think back to how that has impacted – I'm always trying to bring this podcast more into tech because I feel guilty about that. [laughs] About just wandering off into other things. But I think about how that impacts how I work in the organizations I work in. Hmm. I recognize I'm learning more about myself and how much I can love just sitting down with an editor and churn out awesome code, awesome features, and awesome products. That brings me so much joy and I don't want to do anything else. And what we do has impact and so, it's so beneficial to be aware of the organization I'm in what it's doing, what the product is doing, how that's impacting people. Sometimes, that involves a lot of management—I do a lot of product management with my main client now. But also, in other places, you would look at, “Well, okay, I don't need to manage the client's finances”. Not because that's not as important, it's because other people are doing it and I trust how they're doing it. That's something I haven't had elsewhere. The advantage of being with a very small organization is that I have these personal relationships and this personal trust that I couldn't get at one of the vampire companies. What'd they call them? FAANG? AARON: Yeah, FAANG. We've been talking about this because FAANG, but Facebook and Google changed their name. So now, is it just MAAN? DAMIEN: Yeah. AARON: I mean Meta, Alphabet, Apple, Amazon, Netflix, right? DAMIEN: I'm all for the right of individuals to choose what they're called; I don't know if I'm willing to extend that to Facebook and Google. AARON: [laughs] Yeah. DAMIEN: Remember, was it Altria? AARON: Oh, Philip Morris. DAMIEN: Philip Morris, right? AARON: Yeah. DAMIEN: They were just like, “Oh, everything we've been doing is so horrible and harming to society for the past several decades, we'll just change our names and people will forget about it.” AARON: That was Philip Morris. Altria didn't do any of that. DAMIEN: Yeah. Altria didn't do any of that. [chuckles] Yeah, I remember that. AARON: Yeah. I'm curious because I think it's changed for me a bit over this time, too. But I'm curious for folks that have had a sensitivity change to the types of company, not necessarily types of companies, but like, I'm more sensitive to who I'm working for. I think my list of no, I won't work for the X company [chuckles] has probably grown throughout the pandemic and I'm definitely much more critical. Part of it's probably because as in tech we're sort of at an advantage, it is high demand right now and we can be a bit picky about where we work, but I definitely have been [laughs] lately. Much more careful about I'm not just willing to work with anyone. I want someone that's got reasonable values. I interview other companies a lot more and I want to make sure product is not causing harm generally speaking and make sure I get a lot more value alignment out of leadership team and things like that. I don't know if other people have had a similar experience. MANDY: Unfortunately, I haven't had that experience. I'm still working for whoever will give me money. [laughter] But I wish I could do that and I'm currently looking. I mean, I've been trying to break into a full-time DevRel career for I guess, 2 years now and I guess, I'm actively looking. Oh, here we go. If you're hiring, let me know. [laughter] I guess I am. I'm looking for that job that I'm really feeling fulfilled in is right now I'm not feeling that and I think it's because of the pandemic, I've really stopped to think about what I want in my life and how I want to feel. I want to be happy, I want to be passionate about my job, and I want to wake up and not feel scared to open my computer because – [overtalk] DAMIEN: Wow. MANDY: Are they going to tell me they no longer need my service? DAMIEN: Right. MANDY: And it's been demoralizing really, for me recently, especially because I tried to join a developer relations Slack group just a few months ago and they rejected me flat out and they're like, “You do not work in dev full time. You cannot be a part of our group,” and I'm like, “Oh.” So now I'm like, “Hmm, what do I do in tech?” [laughter] I thought I'd been doing DevRel before DevRel was cool. I'm going to humble brag for a minute, but I have single-handedly put this podcast together and put you people together that you didn't even know and you love each other. You get that vibe. I can tell who's going to get – you're going to love this person and you're going to like – [overtalk] DAMIEN: Oh man, you not only put this podcast together, but you are the sustaining force. You are the heart of it. You are the thing where that all the panelists that are connected to. You are one who gets all of the mechanical, everything besides talking in mics. You do everything else and you're maintaining all these relations with these developers. [laughter] MANDY: I never even wanted to be on mic. I just started doing it because everybody was busy and I was like, “I guess I have to step up.” [laughs] DAMIEN: Whatever it takes to get it done, right? MANDY: Well, yeah. I feel like the topics on this show that we talk about are important and they're even important outside of tech that hence, the whole name: Greater Than Code. There are more things out there than our jobs and our work and I just want to be happy. I want to be fulfilled and I want to be passionate about something and so does my dog. AARON: That was a shift for me, too. That was definitely one of the roles I was in during the pandemic and realized my struggle with it so much was it was clashing with that. It wasn't fulfilling for me, it was clashing with my core values, and it was just like, “You know what, I can't do this anymore.” [chuckles] I'm no longer in a place where I have the energy to do a thing I don't like doing, or don't have some care for. There's always something you don't like doing. There's always some crap around every job that like don't like to do or you have to deal with something, but I'm no longer at a place where I can have a whole job that rubs me the wrong way. MANDY: Yeah. It's hard for me. I should feel great about this, but I'm known as the podcast girl. If you have a tech podcast, you should talk to Mandy, but I'm not just a podcast editor! I do so much more than that. I do operation, I do product management, I do writing; there's so much more that encompasses who I am in tech than the podcast girl. I feel like not a lot of people know that and maybe that's my fault because I guess, I haven't really done a good job of putting myself out there to be like, “Hey wait. But I'm –” because for me, it's still a hustle as a single mom. I have to pay the bills. So it's like, I wish I could be more discerning with the jobs that I take and who I work for, but I don't know. I'm just one of those people of the universe. What will be, will be and if it's meant to be, it'll come to me. [laughs] So I don't ever really actively seek and that's probably half of my problem. DAMIEN: Mm. That's funny because I didn't know all those things about you. I pitch you as a podcast producer and again, I live in a LA, I'm involved in the entertainment industry at a slight level, and the word producer there is very, very powerful and very important. A producer is an executive. A producer is person who gets things done, who makes it happen. I'm not entirely sure what a producer does, even though I've done it. MANDY: I'm not even sure what a – [laughs] DAMIEN: Right, because it's never the same thing. MANDY: No. DAMIEN: It's whatever it takes and that skill. AARON: Yeah. DAMIEN: That being able to be know enough about a movie, or theatrical production, or a podcast, to know what it takes, to be able to manage, and sustain and get it done. That's really what it comes down to: get it done. MANDY: That's why it's so hard for me. Everyone's like, “Do you have a resume?” And I'm like, “I don't know what to put on it!” Like, you tell me you need this done, I'll get it done. If I don't know how to do it, I'll figure it out because that's what I've done for 13 years. Like I got hired as Avdi Grimm's virtual assistant because an Indeed.com ad came out and was like, “I need somebody to answer emails for me,” and I'm like, “Don't know why you can't do that yourself, but sure.” [laughter] And then from there, he had a podcast and was like, “Can you edit my podcast?” And I was like, “Sure,” and then I'm Googling what is a podcast. [laughter] I had no clue. So I got here, I think a lot out of luck from being at the right place and talking to the right person at the right time. But I have busted my ass to just learn what people need me to learn and do what people need me to do. I guess, that's maybe what I should just put on the resume. I'll do what you need me to do. I make it happen. DAMIEN: No, no, no. You put on the resume what your next job is going to be doing. MANDY: [laughs] Yeah, so, it's hard when people ask me for my resume. I have like three resumes and I'm like, “This does not, no.” AARON: It's almost more a portfolio at this point, right. I made this thing happen. I made this thing happen. Here's this other thing that I did. Here's another thing I made happen. DAMIEN: Resumes are horrific. They're not good for anybody and the only people who use them are people who need to filter quickly out of large groups and they're not even good for that. I've long aspired to be at a place in my career where I don't need a resume and I might be there. Steve Jobs didn't have a resume. Didn't need a resume. He didn't send his resume to the board to get that job at Apple back. It's ridiculous. MANDY: Well, that's the thing for me. I get most of my work from word to mouth. DAMIEN: Right. MANDY: So until I really lost a big client and I was like, “Oh, I don't have a resume. Don't you know who I am?” [laughter] DAMIEN: But like, they should. [laughter] AARON: Just say the portfolios level. I mean, it's kind of the same thing, right? This is... MANDY: Yeah. AARON: [laughs] Kind of the same thing. It's sort of how my resume is morphed in DevRel proper. It's gone from I still kind of have the resume that's like, “Yeah, I worked into these things internally that might not surface otherwise, but also, here's my speaking portfolio and all the things that I have done over the past 3 years. [laughs] You might know me from all of this stuff instead of what's on this resume.” [laughter] MANDY: Yeah. Of course, once I was getting comfortable enough to want to speak, that's when the whole world shut down. DAMIEN: Yeah. MANDY: So I have no videos of myself speaking anywhere whatsoever. DAMIEN: Well, I think there might be a few podcasts that you appear on. MANDY: There's a few episodes as of late that I have ventured to be on out of keeping the show alive. DAMIEN: And every episode of this podcast, and I think several others, are shits near portfolio, right? [laughter] MANDY: Then I'd have a really wrong resume. [laughs] AARON: We'll figure it out. DAMIEN: Yeah. AARON: You just need the highlights. MANDY: But I don't know, a lot of other things have changed for me over the course of the past 2 years. Just in my personal life, I've gotten sober and that was a really hard thing to do during a pandemic. AARON: Yeah. MANDY: When everybody else was out hoarding toilet paper, I was like, “Oh my God, I need beer,” [laughs] and actually, I did. While everybody was stocking up on those other necessities, I was buying cases of beer and putting them in my garage because I was like, “Oh great, the world's ending and I guess, if that's going to happen, I might as well be drunk.” And then – [overtalk] AARON: I mean, it's a fair argument in your defense. MANDY: But then it became a bad problem because when you're home all day and I was home, I worked from home before this. But everything is so damn depressing and you keep the news on the television and next thing you know, it's lunch time and cracking a beer and I'm like, “Whoa, this is… [laughs] where did this come from?” So no, I got sober and I don't drink anymore and honestly, I have never felt better. I've also become a runner. I got a treadmill and I run a 4, or 5 miles a day and I've lost a good amount of weight, probably a lot from alcohol bloat. DAMIEN: [chuckles] Yeah. MANDY: But it's more for me. It's not even about losing a weight because I don't even own a scale because it's more about how I feel. DAMIEN: Yeah. MANDY: It's what is about how I feel. So when I went to the doctor's office for my yearly checkup on Monday and I got on the scale because they make you, I said, “Whoa,” [laughs] because I didn't even know. For me, it's about how I feel and I think that that's really, what's brought a lot of things into perspective for me is that at our time here on earth is fine. I want to be here for my daughter especially. She's 13 and I want to be healthy for her. I want to be here for my friends. I ask myself why I'm still in York, Pennsylvania and I haven't left because I do have people around here that I care about. DAMIEN: Yeah. MANDY: And other than that, I could take it, or leave it. But because the people who I love are here, that's why I haven't left. DAMIEN: Yeah. MANDY: So that's another thing, the things like the pandemic has just really set me into a lot of personal development work and self-discovery. I journal every day. I read self-help books, which is so weird to me because I was one of those people that were like, “Who are those people that read self-help books?” and now I'm one of them. [chuckles] I want to be Brené Brown and Glennon Doyle's best friend. [laughter] Those two women are my people. Elizabeth Gilbert. I can give you so many names of people and great authors that just inspire the hell out of me and 2 years ago, I was not that at all. AARON: Yeah, I think there's a lot to be said for getting at our time on earth is finite and so, in refocusing on what matters to us. Another way I had a friend put it to me, it's like optimistic nihilism. Look, at the end of the day, we're all going to be dead and none of this matters. So you might as well do what makes you happy, right? [laughs] You might as well do the things that are fulfilling and meaningful and try to make other people have a good time, too. You might as well. DAMIEN: I always thought it was ridiculous that nihilism had such a negative connotation. It was like, “No. Okay. I can believe that and be –” [overtalk] AARON: No pressure. At the end of the day, we're all going to die so, no pressure. Do what do what you need to do. Doesn't matter if you succeed, or fail. MANDY: That's like, I'm one of those people that would rather spend their money on experiences. AARON: Yeah. MANDY: Because I don't care how much money I die with. [laughter] I'd rather use it now and take my kid Disney world, which I did 3 years ago. DAMIEN: Nice. MANDY: And enjoy those experiences rather than have a bank account full of dollars that I can't use. DAMIEN: High score. MANDY: Yeah, high score. DAMIEN: Shout out to thriving in hand wavy. I feel embarrassed about this and I don't talk about it much because so many people are suffering. People I love are suffering. People I work with and deal with on a daily basis are suffering, and bad things are happening. This is the best year of my life. This is better than last year and last year was better than the year before. I just keep getting better and my life just keeps getting more awesome. I don't know if I was going anywhere with that, but solidarity with Mandy, I guess. You bought a treadmill. I bought a rower. MANDY: I feel like honestly, the universe gives back what you put out and I guess, I've become real – a lot of people are like, “You're like, woo-woo witchy now,” and I'm like, “Aha, yeah.” I kind of like that. So I feel like if you manifest things, you can make that happen and yes, there's things happening. Yes, yes, there are so many bad things happening, but sometimes out of self-preservation, you just have to tune all of that out and just be in your immediate dwell. For me, sometimes I'll go a week without watching news and I feel guilty about that a lot, but it's just like, you know what, if something's going to happen, it's going to happen. AARON: I think the best way someone put that to me was anxiety is not activism. MANDY: Yeah. DAMIEN: Yeah. AARON: Right, so just sitting around making yourself anxious and stressed out about everything and whatever emotion you have, making yourself feel bad doesn't improve the situation, it just also makes you feel bad. So it's okay to take a step back and do the self-care that you need to do because just feeling bad isn't fixing the problem either. So step back, find what you can do. Maybe there's stuff you can do here, in your immediate space that you can take action on. MANDY: Exactly. And also, for drinking other people's problems away, – [overtalk] [laughter] AARON: You can't drink other people's – disassociating from other people's problems isn't effective. [laughter] MANDY: No. Let me tell you, I tried. [laughter] DAMIEN: That's such a great statement. Anxiety is not activism, but also the opposite is true. Joy is activism, rest is activism, thriving in a world that doesn't want you to thrive is an act of resistance and activism. Shout out, living a good life. AARON: That's been a good conversation. I think that's easy to forget and I've seen it come up a couple times over the past couple years of what they have been of taking those moments for joy are really important. They can be radical in and of themselves. MANDY: Keep a gratitude journal. There are so many great apps that every day before I go to sleep, I just write one sentence and it gives you an option even to have a picture. So you can snap a picture. Even if it's just like this candle, this candle is burning right here and it smells so good and it's making me happy today. So I'm grateful for the candle. DAMIEN: Yeah, I'm up to approximately 2 years of daily journaling. A buddy of mine got together. We built a daily journaling app based on Morning Pages from The Artist's Way. It's called Early Words. Shout out earlywords.io if you want to join and journal with me. But every day, 750 words. I do it first thing in the morning most days. Stream of consciousness. It has absolutely changed my life. It makes me feel good. It made me a better writer. Not because the writing is good, but because it's taught me to turn off the editor. Writing does have to be good for me to write it. MANDY: Yeah. Big proponent of journaling. AARON: I believe in it. I just don't remember to do it. But that's my own problem. [laughter] DAMIEN: Can we go back? Can we talk about witchcraft? AARON: All right, I'm in. DAMIEN: A friend of mine asked me oh my God, maybe it was a year ago. Maybe it was several months ago. I have no idea. She asked me like, “Do you actually believe in witchcraft? Those magic woo-woo stuff?” It's like, “Well, let me tell you something. Every morning when I wake up in the morning, I make a potion with dried leaves that energizes me. At night, I make a different potion with dried flowers that calm me down and helps me sleep. My literal job is making sand think. Do I believe in witchcraft? I mean, yeah.” [chuckles] MANDY: I mean, it's a full moon today so I have a whole jug of water out charging. I do. I literally have a jug of water on my deck charging for full moon water energy and I use it like, I'll put a little bit in my bath water. I'll put it a little bit of it – I'll cook with it. When I boil some water, put it in there. Does it help? I don't know, but it makes me feel better! DAMIEN: Okay. Wait. It makes you feel better? AARON: Sounds like it's helping. DAMIEN: Doesn't that means it helps? MANDY: Yeah. It does. AARON: Yeah. I think that's a good point. I believe in the power of intention and ritual. There's a reason why humans developed rituals over time and sometimes, it's just for us to feel the right thing. But like, feelings are important? DAMIEN: [laughs] But like, feelings are important. AARON: I don't want to say something controversial on the Greater Than Code podcast such as feelings are important. But they are. Sometimes, while you go through a certain step and it centers you, or you go through a certain set of steps and it makes you feel better, or it helps you process the anxiety you're feeling, or it's like, nope, I need to get centered in my five senses again so I can come back into my body and be here instead of going off on an anxiety spiral. MANDY: Absolutely. AARON: What is witchcraft? I actually love this from Terry Pratchett, one of my all-time favorite authors who does the Discworld series of novels, as a very specific approach to witchcraft, which is like, yeah, yeah, yeah, magic and whatever. But their daily thing is checking on all the people of the village and doing all the work that nobody wants to do. So it's like, how are the elderly doing? Do they need help with anything? Making sure and so takes their bath, making sure this person's animals are taken care of, making sure this sort of thing. Sometimes, it's about appearances and going through the ritual to make sure the community is coming along. Sitting with the dead, all that kind of stuff. And that's witchcraft, that's the bread and butter of witchcraft is knowing the right herbs and poultices to put together, being the heart and soul of the community and being able to get people and helping each other, and move the resources around as needed and that sort of thing. So yeah, I believe in that. [laughs] DAMIEN: Yeah. There was there's a great story and about Anton Mesmer, I learned this shout out to Mary Elizabeth Raines who taught me hypnosis. I learned this when she told me this story when I was doing my hypnosis training about Anton Mesmer, who's considered the [31:10] of hypnotism. He introduced hypnotism to the to the white people. The word mesmerism and magnetic person, magnetic personality, all this comes from Mesmer. He had salons where people would hold onto metal rod that he had “magnetized” and be healed and fall out and screaming have spirit and all that. But Mesmer was very popular and very powerful and the king of France did not like this. The king of France put together a blue-ribbon commission. I don't know if he called it a blue-ribbon commission. Probably not because he spoke French, but put together a commission of scientists to discredit Mesmer. One of these scientists was Ben Franklin, by the way. So they did a double-blind study. They did a proper double-blind test. They had Mesmer come out and magnetize a tree. That was a thing he did. He would magnetize trees, people would come out and hug the trees and then they'd be healed. So they did a study. They had to magnetize the tree and they brought people out who were sick and they said, “Hug that tree. That's magnetized and you'll be healed.” Some of the trees Mesmer had magnetized, some he hadn't and it turns out it didn't matter. People were still healed and so, they all came to conclusion, “All right. See, Mesmer's not doing anything. It's all placebo effect.” Mesmer was run out of town and lived in exile for the rest of his days. Nobody bothered to ask why were the people healed? Everybody knows placebo effect is a real effect. Nobody's like, “How do we make it more effective? Why is it working this way? What do we do it? What do we do with that? How can we use that?” MANDY: Yeah. AARON: No, I think it's a super interesting thought. The placebo effect is a powerful and interesting concept overall. We did ourselves a disservice to not understand it. DAMIEN: Yeah. To dismiss it as if it doesn't exist. Not only does it exist, it's increasing. AARON: Hmm. DAMIEN: Because people are getting more powerful. MANDY: Yeah. I'm drinking this Zenify Stress Relief Drink. [chuckles] And does it work? I don't know, but it's delicious and you know what? It makes me happy. You know why? Because it's not alcohol. [laughter] So it's not having a negative effect on me. I'm not getting drunk and doing stupid things. Is it taking away? My stress? Eh. I mean, but I love it. I love it and it makes me feel good. It's a treat. It's a special drink. I have one a day and it's one of those things that instead of missing my case of White Claw Seltzer. I know, I know, I wasn't even a bougie – well, I wasn't even a good drinker. That's what made it a problem. [laughs] AARON: This is far too affordable. MANDY: I was not a discerning drinker, so. [laughs] No, I have my one bougie drink that I have and it makes me feel good. Does it relieve my stress? I don't know, but I don't care either. DAMIEN: Yeah. If it works, it works. One of the great things about placebos is they don't – well, I was going to say they don't have to be expensive, but sometimes it works better when they're expensive. [laughs] MANDY: Moon water is free. DAMIEN: Moon water is, yeah. But, well, it's not free actually. You had to put an effort and intention. MANDY: True. DAMIEN: And I think if you didn't, it wouldn't be as effective. AARON: Effort and intention go a long way. DAMIEN: [laughs] That's a root of magic, isn't it? MANDY: Why can't I just get paid for effort and intention? [laughs] AARON: I mean, if I put my effort and intention into this money tree. [laughter] I've always thought it would be nice if real world jobs worked like Animal Crossing. Like, “Oh, so I can just go pick some stuff up and then you're just going to give money and then we can just move on? Great.” “Now look, I dug up a bag of money. If I just plant this bag of money, I'll get more money. It's fine.” [laughs] DAMIEN: I'm trying to bridge that gap. That's such a great question like when effort and intention is so well, literally magical, why does it seem to not have the impact we want in nonmagical environments, I'll call them? AARON: Mm. DAMIEN: I asked that question because I want to know what to do about that. I want to bring magic to nonmagical environment, to city council, to retail stores. I almost named an online retail store; I don't want to name it. [laughs] But it's a city council to corporate interactions. And there's no reason you can't. Corporations are people. Governments are people. I think requires dealing with them in individually in ways that we're not used to. AARON: Yeah. It's a good question. You've got to be really thinking about… MANDY: My wheels are turning. AARON: Yeah. I mean, I think part of it is effort and intention are always going to make the most effect for you because most of it is about aligning your thought processes. It's about taking the, I don't know, I'm just taking this into making the best decision I can to like, okay, if I can focus on this is my goal and my aim and what I'm after, suddenly all of the patterns emerge around that. Oh, now I'm ready for that opportunity, or oh, now this thing is working out, and oh, now this is what is working out because I've focused on my intentions and where I want to put my efforts. I think there's room for these things in other groups. Gets back to what I was thinking about ritual, about how humans are tuned for ritual to tell themselves story. We're tuned for storytelling and ritual and all this sort of thing. So I think there's room from a tech perspective, I'm thinking about what comes to mind quickly is incident management stuff. Sorry, I'm coming off of SRECon this week so, everything's going to be around that. DAMIEN: Our apologies. [laughter] It's all right. AARON: It was fantastic, but it's a different podcast. [laughs] But think about that, right? When you're coming in and doing instant reports, it's so powerful is it to set the intention of the meeting, or any meeting that you have and say, “We are here for this purpose. This is what we're looking to find. We're not looking to do –” Back when Chef had lots to say about this, they'd have those things like we're not here to determine what could have, or should have happened. We're here to find out what did and move the thing. So it's all about setting the intent of that gathering and what outcomes you're after and it focuses the whole conversation can make that meeting more powerful because you've set the focus right off the bat. I think there's room for that other places, too. DAMIEN: That's such a beautiful way of saying it. You described it as setting an attention. AARON: Yeah. S: Whereas, in corporate speak, I would describe it as setting an agenda. AARON: Right, and an agenda is one thing. It's kind of like, “Hey, here's kind of the stuff we're going to do,” but to be like, “We are gathered for this purpose to [laughs] cover this thing.” DAMIEN: No, no. AARON: Right. DAMIEN: Dearly beloved, dear colleague. AARON: Right? Yeah, right. DAMIEN: We are gathered here for this purpose. AARON: Yeah. I mean, we say it this way in personal stuff, why don't we –? Like, it's useful. [laughs] MANDY: It really is. DAMIEN: Because how are you ever going to get something done if you don't know what you're there for? AARON: Right. DAMIEN: Well, you're going to get something done. If you don't have a destination, any road you take is fine. AARON: If you don't have any intention set, it's a series of meetings that could have been emails. [laughter] And then maybe that's the power of it, in a nonmagical space, is forcing yourself to go through this thought process of why am I doing this? Why are we here? What do we want to accomplish? Can probably trim so much of the cruft from all of our meetings and engagements. DAMIEN: That was my favorite sentence as a product manager: what is it you're trying to accomplish? [chuckles] AARON: I say that a lot, DAMIEN: But it is a very, very powerful question. AARON: Especially when you have children asking to use dangerous tools. [laughter] What is it you're trying to accomplish? Maybe we don't need to bust out razor blades. [laughs] DAMIEN: So from an SRE standpoint, when you get together for – what do you call that meeting? An incident review postmortem? Postmortem is a bit – [overtalk] AARON: Yeah, yeah. Post-incident report. There's a handful of names for that reason, but post-incident review. MANDY: Retrospective. DAMIEN: Retrospective, yeah. So the question is, what is it you are trying to accomplish? AARON: Right. DAMIEN: I'm trying to find somebody to blame. AARON: And not blaming. DAMIEN: I'm trying to find somebody to blame so that I look good in my next performance review. AARON: Well, that's what was so important about doing that because that's the shift we're, largely as an industry, trying to make. Finding a person to blame doesn't learn anything about what happened and will teach us nothing for next time. So if we set the intention of like, we're trying to learn from this incident and how we can improve or what we can do better, or maybe there's nothing. Maybe this was just a fluke and let's find that out. That's what we're here to learn. But we're not here to point fingers, or find a root cause because root causes are for plants. [laughter] AARON: Again, that's a whole other podcast. [laughs] MANDY: At the beginning of the pandemic, I owned zero plants. Now, I think I'm the proud plant mother of 20? [laughs] DAMIEN: Wow. AARON: That's amazing. MANDY: I know. AARON: My problem is I can't keep things alive. MANDY: Well, mostly they're all thriving because I set the intention that I was not going to mess this up. [laughter] DAMIEN: There you go. Do you give them moon water? MANDY: I do. DAMIEN: Apparently, it's working. MANDY: I do. Do we want to do some reflections? DAMIEN: Sure. Let's do it. MANDY: I'll start us off. With this conversation, we were just having about the intention and stuff. This is why I think everybody should journal, including CEOs and leaders. Get out a journal, what do you want, and then look back at some of the stuff. I don't it often, but I go back and I'm like, “Oh yeah.” Just reflecting on what you've written in the past and bringing that to the present can really help you put stock in all the things that you want and should be accomplishing. DAMIEN: Yeah. This bringing magic into nonmagical environments and journaling is part of that. A shout out to journaling. Another plug for earlywords.io that I own. Come journal with me because it is a magical thing. It is a ritual I do daily. That clears my mind. That is a practice of the listening to myself. It is a practice of letting go and not controlling what's coming out. Along with that and all the other sort of ways I know of being that I can call magic, I can call hypnotism, I can call NLP, I can call ontological coaching I've done a lot, bringing that into environments where I haven't because they're so useful there and we talked about some of the ways they are and so, we really confirmed more ways of doing that. AARON: I think the things I'm thinking about after this conversation are ritual, intention, and reflection are the big things that are standing up. I think this pandemic, for instance, and how things have changed is because I've had just so much time to have to sit alone by myself and reflect on what's going on externally and internally. But yeah. Anyway, just about setting intentions, of understanding the directions you want to go before going, making sure you're aligned with your goals, and you're not just accidentally wandering down paths that you don't want to be down and turning around and finding out your miserable 10 months later. I think I've thought a lot about the power of even small rituals just to interrupt our standard thought processes and align ourselves with those kind of things. There's been a lot from basic health stuff of here are the rituals I can go through when I'm feeling anxious and I know they'll calm me down to writing in a journal, or directing a group to [laughs] let's align our thought processes. It can be super useful. DAMIEN: Absolutely. MANDY: Awesome. Well, this has been a really fun conversation. I'm glad we just had a panel only episode and I'd love to do more of these in the future. They're really cool. We didn't come to the show with much of an agenda and hopefully, you dear listener, appreciate it. If you would like to give us some feedback, we'd appreciate it. Tweet at us. Join our Slack. AARON: Hire Mandy. DAMIEN: Tell your friends. MANDY: DM me. [chuckles] Tell your friends. DAMIEN: Tell your enemies. MANDY: Tell your enemies, too! [chuckles] We'll see you all next week.

01:09 - Jenna's Superpower: Being Super Human: Deeply rooted in what is human in tech * The User is Everything 04:30 - Keeping Focus on the User * Building For Themself * Bother(!!) Users * Walking A Mile In Your Users Shoes - Jamey Hampton (https://www.youtube.com/watch?v=w-zYKo8f7nM) 09:09 - Interviewing Users (Testing) * Preparation * Identifying Bias * Getting Things Wrong * Gamifying/Winning (Developer Dogs & Testing Cats) * Overtesting 23:15 - Working With ADHD * Alerts & Alarms * Medication * Underdiagnosis / Misdiagnosis * Presentation * Medical Misogyny and Socialization * Masking * Finding a Good Clinician Reflections: John: Being a super human. Jacob: Forgetting how to mask. Jamey: Talking about topics that are Greater Than Code. Jenna: Talking about what feels stream-of-consciousness. Having human spaces is important. Support your testers! This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: JAMEY: Hi, everyone and thanks for tuning in to Episode 276 of Greater Than Code. I'm one of your hosts, Jamey Hampton, and I'm here with my friend, Jacob Stoebel. JACOB: Hello, like to be here. I'm with my friend, John Sawers. JOHN: Thanks, Jacob. And I'm here with our guest, Jenna Charlton. Jenna is a software tester and product owner with over a decade of experience. They've spoken at a number of dev and test conferences and is passionate about risk-based testing, building community within agile teams, developing the next generation of testers, and accessibility. When not testing, Jenna loves to go to punk rock shows and live pro wrestling events with their husband Bob, traveling, and cats. Their favorite of which are the two that share their home, Maka and Excalipurr. Welcome to the show, Jenna! [chuckles] JENNA: Hi, everybody! I'm excited to be here with all the J's. [laughter] JAMEY: We're so excited to have you. JOHN: And we will start with the question we always start with, which is what is your superpower and how did you acquire it? JENNA: On a less serious note, I have a couple of superpowers. One I discovered when I was a teenager. I can find Legally Blonde on TV [laughter] any kind of day [laughs] somewhere. It's a less valuable superpower than it used to be. But boy, was it a great superpower when you would be scrolling and I'm like, “Legally Blonde, I found it!” [laughter] JAMEY: I was going to ask if one of your superpowers was cat naming, because Excalipurr is very good. It's very good. [laughs] JENNA: I wish I could take credit for that. [laughter] Bob is definitely the one responsible. JAMEY: So it's your husband superpower, cat naming and yours is Legally Blonde. Got it. JENNA: Mine is Legally Blonde. [laughter] I also can find a way to relate anything to pro wrestling. JAMEY: I've seen that one in action, actually. Yes. [laughter] JENNA: But no, my real superpower, or at least as far as tech goes is that I am super human. Not in that I am a supremely powerful human, it's that I am deeply rooted in what is human in tech and that's what matters to me and the user is my everything. I'm not one of those people who nerds out about the latest advancement. Although, I enjoy talking about it. What I care about, what gets me excited, and gets me out of bed every day in tech is thinking about how I can solve a deeply human problem in a way that is empathetic, centers the user, and what matters to them. JAMEY: Do you feel like you were always like that naturally, or do you feel like that was a skill that you fostered over your career? JENNA: I think it's who I am, but I think I had to learn how to harness it to make it useful. I am one of those people who has the negative trait of empathy and when I say negative trait, there's that tipping point on empathy where it goes from being a powerful, positive thing to being something that invades your life. So I am one of those people who sitting in a conference room, I can feel the temperature change and it makes me wiggle in my seat, feel uncomfortable, get really awkward, and then default to things like people pleasing, which is a terrible, terrible trait [laughs] that I fight every day against. It's actually why remote work has saved me. But I've had to learn how to take caring about people and turn it into something that's valuable and useful and delivers because we can talk about the user all day and take no action on it. It's one thing to care about the user and to care about people. It's another thing to understand how to translate that care into something useful. When I learned how to do that in testing, my career changed and then when I learned how to translate that to product, things really started to change. JAMEY: That's amazing. JENNA: Thank you. [laughs] JACOB: I feel like so often at work I sit down at 9:00 AM and I'm like, “Okay, what do our users need in this feature, or how could this potentially go wrong and hurt our users?” And then by 9:20, everything's off the rails. [laughter] As work happens and here's a million fires to put out and it's all about things in the weeds that if I could just get them to work, then I could go back to thinking about to use it. You know what I mean? How do you keep that focus? JENNA: So part it is, I don't want to say the luck, but is the benefit of where I landed. I work for a company that does AI/ML driven test automation. I design and build experiences for myself. I'm building for what I, as a tester, needed when I was testing and let's be honest, I still test. I just test more from a UAT perspective. I get to build for myself, which means that I understand the need of my user. If I was building something for devs, I wouldn't even know where to begin because that's not my frame of reference. I feel like we make a mistake when we are designing things that we take for granted that we know what a user's shoes look like, but I know what my user's shoes look like because I filled them. But I don't know what a dev shoes look like. I don't know what an everyday low-tech user shoes look like. I kind of do because I've worked with those users and I always use my grandmother as an example. She's my frame of reference. She's fairly highly skilled for being 91 years old, but she is 91 years old. She didn't start using computers until 20 years ago and at that point, she was in her 70s. Very, very different starting point. But I have the benefit that that's where I start so I've got to leg up. But I think when we start to think about how do I build this for someone else and that someone isn't yourself, the best place to start is by going to them and interviewing them. What do you need? Talk to me about what your barriers are right now. Talk to me about what hurts you today. Talk to me about what really works for you today. I always tell people that one of the most beneficial things I did when I worked for Progressive was that my users were agents. So I could reach out to them and say like, “Hey, I want to see your workflow.” And I could do that because I was an agent, not a customer. They can show me that and it changed the way I would test because now I could test like them. So I don't have a great answer other than go bother them. Get a user community and go bug the heck out of them all the time. [laughs] Like, what do you mean? How do you do this today? What are your stumbling blocks? How do I remove them for you? Because they've got the answer; they just don't know it. JAMEY: That was really gratifying for me to listen to actually. [laughter] It's not a show about me. It's a show about you. So I don't want to make it about me, but I have a talk called Walking a Mile In Your Users' Shoes and basically, the takeaway from it is meet them where they are. So when I heard you say that, I was like, “Yes, I totally agree!” [laughs] JENNA: But I also learned so much from you on this because I don't remember if it's that talk, or a different one, but you did the talk about a user experience mistake, or a development mistake thinking about greenhouses. JAMEY: Yes. That's the talk I'm talking about. [laughs] JENNA: Yeah. So I learned so much from you in that talk and I've actually referenced it a number times. Even things when I talk to testers and talk about misunderstandings around the size of a unit and that that may not necessarily be global information. That that was actually siloed to the users and you guys didn't have that and had to create a frame of reference because it was a mess. So I reference that talk all the time. [laughs] JAMEY: I'm going to cry. There's nothing better to hear than you helped someone learn something. [laughter] So I'm so happy. [chuckles] JENNA: You're one of my favorite speakers. I'm not going to lie. [chuckles] JOHN: Aw. JAMEY: You're one of my favorite speakers too, which is why I invited you to come on the show. [laughs] JENNA: Oh, thank you. [laughter] Big warm hugs. [laughs] JOHN: I'm actually lacking in the whole user interviewing process. I haven't really done that much because usually there's a product organization that's handling most of that. Although, I think it would be useful for me as a developer, but I can imagine there are pitfalls you can fall into when you're interviewing users that either force your frame of reference onto them and then they don't really know what you're talking about, or you don't actually get the answer from them that shows you what their pain points are. You get what maybe they think you should build, or something else. So do you have anything specifically that you do to make sure you find out what's really going on for them? JENNA: The first thing is preparation. So I have a list of questions and that time with that user isn't over until I've answered them. If it turns out that I walked into that room and those questions were wrong, then we stop and time to regenerate questions because I can bias them, they can bias me, we can wind up building something totally different than we set out to do, which is fine if that's the direction we went end up going. But I need to go into that time with them with that particular experience being the goal. So if I got it wrong, we stop and we start over. Now, not everybody has to do that. Some people can think faster on their feet. Part of being ADHD is I fall into the moment and don't remember like, “Oh, I wrote myself a note, but there's also” – I just read a Twitter thread about this today. I wrote myself a note, but also to remember to go back and read that note. So [laughs] all of those little things, which are why I really hold to, “I got it wrong. We're going to put a pin in this and come. Let's schedule for 2 days from now,” or next week, or whatever the appropriate amount of time is. There have been times – and I'm really lucky because my boss is so good at interviewing users so I've really gotten to learn from her, but there have been times when she'll interview a user and then it totally turns the other direction and she goes, “Well, yes, we're not building this thing we said we were going to build. I'm going to call you again in six months when I'm ready to build this thing we started talking about.” Because now the roadmap's changed. Now my plan has changed. We're going to put a pin in this because in six months, it may not be the same requirement, or the same need. There might be a new solution, or you may have moved past that this may be a temporary requirement. So when we're ready to do it, we'll talk again. But the biggest thing for me is preparation. JAMEY: I have a question about something specific you said during that near the beginning. You said, “They can bias me and I can bias them,” and I wonder if you have any advice on identifying when that is happening. JENNA: When it feels like one of you is being sold? JAMEY: Mm. JENNA: So early in my career, before I got into tech, I worked in sales like everybody who doesn't have a college degree and doesn't know what they want to do with their life does. Both of my grandfathers and my father were in sales. I have a long line of salespeople running through my blood. If I realize that I feel like, and I have a specific way that I feel when I'm selling somebody something because I like to win. So you get this kind of adrenal rush and everything when I realize I'm feeling that. That's when I know ooh, I'm going to bias them because I'm selling them on my idea and it's not my job today to sell them on my idea. I know they're biasing me when I realize that I'm feeling like I'm purchasing something. It's like, oh, okay. So now I'm talking to somebody who's selling me something and while I want to buy their vision, I also want to make sure that it makes sense for the company because I have to balance that. Like I'm all about the user, but there's a bottom line [laughs] and we still have to make sure that's not red. JOHN: So you're talking about a situation where they maybe have a strong idea about what they want you to build and so, their whole deal is focused on this is the thing, this is the thing, you've got to do it this way because this would make my life the most amazing, or whatever. JENNA: Yeah, exactly. Or their use case is super, super narrow and all they're focused on is making sure that fits their exact use case and they don't have to make any shifts, or changes so that it's more global. Because that's a big one that you run into, especially when you're like building tools. We have to build it for the majority, but the minority oftentimes has a really good use case, but it's really unique to them. JOHN: What's the most surprising thing you've taken away from a user interview? JENNA: I wouldn't say it's a surprise, but probably the most jarring thing was when I got it wrong the first time and when I got it wrong, I was really wrong. Like not even the wrong side of the stadium, a different city. [chuckles] Like a different stadium in a different city wrong. [laughs] It caught me off guard because I really thought that what I had read and what I understood about the company that I was working with, the customer that I was working with. I thought I understood their business better. I thought I understood what they did and what their needs would be better. I thought I understood their user better. But I missed all of it, all of it. [laughs] So I think that was the most surprising, but it was really valuable. It was the most surprising because I was so off base, but it was probably the most valuable because it showed me how much I let my bias influence before I even step into the conversation. JOHN: Is there a difference between how you think about the user when you have your product hat on versus when you have your tester hat on? JENNA: Oh, absolutely. When I have my product hat on, I have to play a balancing game because it's about everybody's needs. It's about the user's needs. It's about the business' needs. It's about the shareholders' need. Well, we don't really have shareholders, but the board's needs, the investors' needs. And when I'm testing, I get to just be a tester and think about what do I need when I'm doing this job? What solves my problem and what doesn't? What's interesting about testing and not every tester is like this, but I certainly am. I mentioned that I like to win. Testing feels like winning when you find bugs. So I get to fill that need to win a little bit because I'm like, “Oh, found one. Oh, found another one. Yes, this is awesome!” I get really excited and I don't get to be that way when I'm product person, but when I'm testing person, I get to be all about it. [laughs] JAMEY: I love that. That's so interesting because to me as a developer, I get a similar feeling when I fix bugs. I feel crappy when I find bugs, [chuckles] but I get that feeling when I fix them. So it's really interesting to hear you talk about that side in that way. I like it. JENNA: Have I ever shared with you that I think developers are like dogs and testers are like cats? JAMEY: Elaborate. JACOB: Let's hear it. [laughs] JENNA: Okay. So I like dogs and cats. That's not what this is about. JAMEY: I like dogs and cats, too. So I'm ready to hear it. [laughs] JENNA: Dogs are very linear. If you teach a dog to do a trick and you reward them in the right way, with the exception of a couple of breeds, for the most part, they'll do that for you on a regular basis. And dogs like to complete their task. If they're a job, because a lot of dogs, they need jobs. They're working animals, it's in their DNA. If their job is to go get you a beer, they're going to go get you a beer because that's their job and they want to finish their job. Cats, on the other hand, with the exception of their job of catching things that move for the most part, they are not task oriented and really, a cat will let a mouse run past it if it's just not in the mood to chase it. It's got to be in the mood and have a prey drive and they don't all. So a cat, you can teach them a trick and if you reward them the right way, sometimes they'll do it and sometimes they won't. Some breeds of cats are more open to doing this than others. But for the most part, cats are much more excited about experimentation. So what happens if I knock on that glass of wall water? What happens if I push on that? What happens if I walk up behind you and whack you in the back of the head? They're not doing it because they're mean, they're doing it because the response is exciting. The reaction to their input in some way is exciting to them as opposed to finishing tasks. Because if you've ever had a cat catch a mouse, they're actually sad after they have caught the mouse. The game is over, the chase is done. It's not fun to give me the mouse; it's fun to chase the mouse. So testers are a lot like that. The chase and the experimentation are a whole lot more fun than the completion. When I find a bug, that's the chase, that's the good part of it. That's like, “Oh yeah, I tracked it down. I figured it out. I found the recreate steps.” After I found the bug, it's not as fun anymore. [chuckles] So I've got to find the next one because now I'm back on the hunt and now that's fun again. Dogs on the other hand, it's like, “Oh, I finished the task. I'm getting my reward. I get to cross this off. My list feels really good” Very different feedback. So I think that's part of it is that devs love to finish things and testers love to experiment with things. JOHN: Yeah. JAMEY: I think that's really insightful. JOHN: Yeah. [laughter] JAMEY: I'm like a I put something that I did on my to-do list so that I could cross it off and it feels like I did something kind of person. [laughter] JACOB: I think we, at least I was, early in my career kind of trained to have that mindset and trained away from no, we're not here to like experiment with the newest and coolest thing. We're just trying to ship features. We're just trying to fix bugs. We're just trying to finish the task. Please do not be overly experimental just for fun, which is an over simplification because everyone needs to be creative at some point. But I totally agree. JENNA: Well, and testers do have to balance that, too because there is such a thing as over testing and you hit this tipping point where it becomes wasteful and you move from I've delivered valuable information to now I'm creating scenarios that will never happen. Yes, a user can do pretty incredible things when they want to, but we can only protect from themselves to a point. Eventually, it's like okay, you've reached that tipping point now it's waste. [laughter] JOHN: Yeah. I remember some research that came out recently that if you call the cat and it doesn't come, it understands what you're asking for and it's like, “Nah.” JENNA: Yeah. Maka not so much. But Excalipurr, when she's sleeping, she'll hear you. That cat is out cold. She has zero interest in what you're saying, or doing. Nothing is going to disturb her well-earned slumber. [chuckles] JACOB: I'm kind of amazed how like my cat is just easily disrupted by the smallest noise when awake and then when he's sleeping, he's dead to the world just like you said. He clearly can't hear it, or if he is, there's something switched off in his brain when he's sleeping, because he's a total spaz when he is awake. [laughter] JENNA: I don't know. I think my vet could explain it better. He actually walked me through what happens in a cat's brain when they were sleeping. I don't remember why. I think we were waiting for a test to come back, or something and he was just killing time with me. But there was this whole neurological thing in their brains that looks for certain inputs and even biochemically, they're wired to certain sounds that are things that they should get awakened by and other things, it's like yeah, that matter. For some reason, though my cats have weird things that they're really tuned into. If you knock on the door, Excalipurr—we call her Purr—will go bananas. She is furious that someone has knocked on the door. Same thing if something beeps like microwave beep, the sound of if I've got a somebody on speaker phone and their car door opens and it beeps, she is mad. She could be dead asleep and she hears that and she is furious. But otherwise, nothing bothers her. She's out cold. [laughs] JAMEY: I also hate when people knock on my door so I can relate to that. JOHN: Yeah. JENNA: Don't come to my door if I'm not expecting you. JACOB: Yeah. JENNA: Also don't call me if I'm not expecting you. [laughs] JAMEY: I have exactly one person I open the door for. His name is Joe and he's our neighborhood person who comes and collects everyone's bottles and cans. But I recognize the cadence of his knocks so that I can answer the door for him and not other people. [laughter] JOHN: So you said earlier that working with ADHD, you had to develop some sort of techniques for how to handle that well in your life. Do you want to talk more about that? JENNA: I don't know if I would say I handle it well, but I handle it. [laughter] Most of the time. Typically, I do you pretty well. So I have lots and lots of alerts for myself. Because as I mentioned, I'll write myself a note, but you still have to have the – somebody said the name of it today and I forgot what it was, but there's a type of memory that tells you to like, “Hey, go look at your notes that you created for yourself,” because you can write the notes, but forget that the notes exist and never go look for them again. So I have lots of like alerts and alarms that tell me like, “Hey, go do this thing. Take your meds. Check to make sure that you have everything you need on the grocery list.” I have a couple of times a day that I have a reminder to go check my to-do list [chuckles] because otherwise, I just won't remember. I'll put the system into place and forget that the system exists and even with those helps, sometimes it'll just slip by especially I'm busy during those alerts. But I try really hard to use those. The most effective thing for me, though is definitely my medication. I was chatting about everybody before we started and I mentioned that because of supply delays and all of the rules around how early you can refill and the rules around not being able to transfer your script from one pharmacy to another and all that kind of stuff, I was without my medication for let's see Friday, Saturday, Sunday, Monday, because I didn't get it until midday yesterday and I was sick. So [chuckles] too many factors at one time that I was just not at all functional over the weekend. I forgot steps in what I was cooking. I forgot things on the grocery list. I couldn't stay awake. That was probably more being sick but. So for me, that's probably the most effective thing. Also, just as a note for those of us assigned female at birth, I that ADHD symptoms get worse [laughs] as we hit 40 and up that all of the hormonal stuff winds up interacting with how our attention is, because I couldn't figure out why my dose had to go up. I was like, “I've been on it forever. Why do we have to raise the dose?” And she's like, “Well, there's some things going on,” and I have a feeling it's all about premenopausal stuff, because for those who don't know, I'll be 40 in June. Not a teenager anymore. [laughs] So all sorts of things that I need to keep it all in balance and things that I'm learning about being in my age group and having ADHD that nobody talks about because of the assumption that ADHD is something only children have and that ADHD is something that you grow out of. When you don't grow out of it; it just kind of changes. And that it's not just men and people who are assigned male at birth that there's a lot of us out there, varying genders. We've got to talk about it more because a lot of us feel like we're wandering the wilderness, trying to figure out what's on in our heads. [laughs] JOHN: Yeah. I remember hearing recently that ADHD and ADD present differently in AFAB people and so, it goes underdiagnosed because of that. It doesn't show up in the classical symptom lists in the same way. JENNA: Yeah. So the classic symptom list was developed around pre-pubescent and puberty age boys and in girls, it doesn't tend to present as not being able to sit still. Although, there's still definitely some of that. It presents more in being like a Chatty Cathy as they say like, “Oh, they talk all the time.” So it presents differently and as we get older and all of the other like stuff starts to factor in, AFAB tend to get identified instead as borderline personality disorder, or bipolar as opposed to ADHD, or even anxiety as opposed to ADHD. Because when you feel like your brain is going a mile a minute, it makes you anxious. So they give you an anti-anxiety medication instead of dealing with the fact that you feel like you can't keep up with your thoughts. There are so many different factors there, but we're learning a lot more about the presentation of ADHD and autism in people who are assigned females at birth. JOHN: Yeah. I don't know a ton about the history of the diagnosis and everything, but I can assume well, because it's the society we live in that there's a giant pile of sexism going on in there, both in who is studied and who they cared about succeeding in classical schooling and the work environment and all sorts of biases up and down the hierarchy. JENNA: Absolutely. There's both, the medical misogyny, but also the socialization because there's an expectation of good girl children and the behavior that girl children should display. So we are socialized to force ourselves to sit even if it means sitting on your hands. You're socialized to doodle instead of wiggling because good girls sit still. So there's all of that kind of stuff that plays into it, too. Even things like if you develop a special interest, which typically people associate with autism, but certainly has some crossover with ADHD because they're very closely related. You learn to either hide that special interest so you just don't talk about it, or you become that person that has the weird quirky thing because ADHD girls are always quirky, right? [chuckles] They're a quirky girl. There's no neurodivergence there. They're just quirky. They're just different. I guess, in many ways, I was kind of lucky because my mom taught autistic, intellectually disabled, and other disabled early childhoods. So she identified early, like kindergarten, that I was probably ADHD. I was dealing with it like really early. Also, she had this kind of belief about raising kids without gender, but also not doing it very well. So I wouldn't say it was a successful thing. [laughs] So let me tell you, we didn't have girl toys and boy toys. We had building blocks and stuff like that. We weren't allowed Barbies. We also weren't allowed Hot Wheels. Very gender in neutral things. But when, as a teenager, I dressed really androgynous, I was told to put on a dress because she is a girl. So I don't know. [laughter] It didn't really work. But I think that a lot of that played into me being identified really early. I'm probably getting off track, but the benefit of is that I learned a lot about it from an early age and I was able to develop systems that work for me from an early age. Most people who are assigned female at birth don't get the benefit of that. My hope is that our kids, I don't have any kids, but to the people my age that have kids, my hope is that their children are being identified earlier so that they are able to get those systems in place and be more successful in the long term. JACOB: I'm autistic and sometimes I think about the fact that I think that my white male privilege let me get away with some of the less great behaviors that came naturally to me and did not force me to develop masking skills until much later in my life. So when you were talking about that, I can sort of relate to that by the opposite that that's making a lot of sense to me, that I could see how all these sort of societal pressures to sit still and behave weren't put on me. I was just encouraged to just be a weird individual and be myself and how that wasn't put on me in places where maybe it probably should have been. So that makes a lot of sense. JENNA: I have to say, though, I think I've forgotten how to mask COVID has definitely killed masking for me. I have completely forgotten how to make small talk. [laughs] JACOB: Yeah, me too. JENNA: [laughs] I can't do it anymore. I've also forgotten how to fix my face. I was never great at fixing my face. Everything I'm thinking, feeling wears on my face, but I'm even worse at it than I used to be. [laughs] JAMEY: I also struggle with fixing my face, but I've actually been finding that I love wearing face masks in public because I can interact with someone without having to worry about what my face is doing and it takes a lot of the pressure off me, I feel. JENNA: I think it does. So I have resting friendly face. [laughter] For those of you who've never met me in person, I am 4' 10”. I'm really short. I'm also kind of wide. I'm fine with it. But little ladies in the grocery store will ask me to help them reach things because I look friendly and approachable. [laughter] But I can't reach them any better than they can! [laughter] Sometimes they're taller than me. So face masks have allowed me to blend in more, which is really nice because I get less of random people coming up to talk to me. People will joke that I make a friend everywhere I go because people just start talking to me and I don't really care. I'll talk to them, that's fine. What I really laugh at is since I can't fix my face, I will put on a plastered-on smile and somebody will be like, “You are really mad at me right now, aren't you?” I'm like, “No, everything's fine. I'm super okay with this,” and they're like, “Yeah, you are furious so we're going to stop.” [laughs] Like I can manage an angry smile without meaning. [laughter] JAMEY: It's interesting what you said about people talking to you randomly, because I also I tend to be that, the kind of person that people talk to randomly in general. I've been having an interesting experience recently where I've been on testosterone for about a year and a half and I'm like finally hitting the point where the way people perceive me in public is different than it used to be. That got cut down dramatically immediately and in a way where people's eyes slide off of me in public. I'm not there in a way that never used to happen to me and it was really interesting realization for me to realize how much of that was the socialization that people think they're entitled to a woman's time and attention. It's not exactly what you were talking about, but it made me think of it and I've been thinking about it a lot lately. [laughs] JENNA: But it's true. It's really true. I think everyone who's perceived as a woman gets it, but gets it in different ways. I tend to get it from people who feel like I'm a safe place to go to. So little old ladies talk to me, little kids talk to me. Now to be fair, bright pink hair, little kids think I'm great. [laughter] Especially when my tattoos are showing, too. The parents are usually like, “Okay, okay. Leave them alone.” [laughter] But I'm also—no offense to anyone who identifies as male in the room—the person that men don't typically stop and talk to, or even notice. I remember I was taking four boxes of nuts to my coworkers and I think it was Fat Tuesday, or something so I was bringing in these special donuts from my favorite donut place around the corner. I had four boxes of donuts and this guy doesn't grab the door, or anything. Just leaves me to try and push the door open with four boxes of donuts. But then granted, she was gorgeous, beautiful blonde starts walking the other direction. He notices her right away, grabs the door, and opens it for her. It's like oh, okay. I've had that happen quite a few times and not to sound dramatic here, but that's part of the reality of living in a fat body that you do get overlooked by others. So the little old ladies tend to tend to gravitate towards me and then other women, men gravitate towards them. I think no matter, what women experience this and people who are perceived as women, because I do identify as non-binary. But let's be honest, people in the broader world perceive me as a woman. We all get it. We just get it very differently and in different ways, but I can't think of a single woman who hasn't experienced it in some way. JAMEY: Definitely. JOHN: Yeah. I've read so many rants frankly from women who have absolutely loved masking well in public because they don't get told to smile and they don't present as female as normal. So they don't fit into that category as much and so, they don't get that same attention. I look very male so no one ever does that to me, but I can imagine what a relief that must be. JENNA: I definitely think it is for some women, especially in super public spaces. JAMEY: I feel like I derailed from ADHD and I want to bring it back. [laughter] I did have a question I was going to ask anyway. So I'm bringing it back to that, which is that I feel like these conversations, like the conversation we're having right now about ADHD, is something that I've been seeing happening more, especially about ADHD and adults. I think it's just something that people have been talking about more the past few years in a way that's positive. I know a lot of people who were like, “Oh, I got diagnosed recently as an adult. I started on medication and I never realized this was what was making my life so hard and my life is so much easier now.” I have several friends that are like really thriving on that currently. So I guess, my question for you is that as someone this whole story you told about being aware of this much younger and being able to make all these coping mechanisms and things like this. What would your advice be to someone who's now, as an adult, realizing this about themselves and then coming to grapple with it? JENNA: Let me preface with this. I'm not one of those people who says medication is the only way; there are lots and lots of ways to manage ADHD symptoms. But I feel like the most beneficial thing you can do for your is to find a clinician that listens to you, that believes you, that doesn't dismiss your experiences because there are as many different presentations of ADHD as there are people who are ADHD. If you've met one ADHD person, you've met one ADHD person; we all have different traits. So finding somebody who is willing to hear you, listen to you, and partner with you, as opposed to try and dictate to you how to manage, how to cope is critical. Part of that is arming yourself with all the information that you can. But the other part of it is being a really, really good self-advocate and if you aren't comfortable with that kind of self-advocacy, finding somebody that's willing to partner with you to help be your advocate. I know a lot of people in the fat community who have personal advocates for medical appointments, because they feel like they're not heard when they go to the doctor. Same thing for us as people who are neurodivergent. We don't get heard all the time and if you feel like your clinician isn't hearing you and because there is a real barrier to getting a new one many times—oftentimes we're stuck with someone. Finding that person that's willing to walk with you is huge. It is really easy to find yourself in a situation where you lose control of your decision-making to a provider who makes the decisions for you, but is clever enough to convince you you're making the decision yourself. That's my biggest advice is don't fall into that trap. If something feels wrong, it's wrong. If a medication doesn't work for you, it doesn't work for you. There are multiple different types of medications, classifications of them, and different brands for a reason is because we all need something different. Like I went through Ritalin, Adderall, finally to Vyvanse because Ritalin and Adderall weren't working for me. Adderall worked, but it raised my heart rate. Ritalin made me feel manic. My provider listened to me when I said I feel manic. I feel out of control, and she's like, “If on the lowest dose you feel out of control, this is not a way to go.” I have a friend who has been pushed off of taking stimulants because she has a history of addiction. She has a history of addiction because she's ADHD and she was self-medicating. It took four different providers to finally get to somebody who said, “Yeah, the stimulants are what worked for you.” The non-stimulant options weren't working, but she had to go and demand and demand and demand and it was the only way to get heard. So I probably got on a tangent there, but self-advocacy, finding someone who will work with you, and getting an advocate if you don't get hurt. JAMEY: I think that advice will be really helpful for people. So thanks. JOHN: Yeah. JENNA: I'm always very worried that I'm going to cross a line and upset somebody, but it just is, right? JACOB: I don't know what line that would be. I feel like everything you said was just really empowering and I wish someone said that to me 10 years ago, honestly. JENNA: I hope it's helpful, but I've had people who haven't realized that even though they're an adult, because they're neurodivergent that they are forever a child. JACOB: Yeah, I know. JENNA: So their opinion, their experience doesn't matter, it's invalid, and those are the folks that sometimes get really upset when I talk about self-advocacy. That's a big personal journey to realize that hey, you are a grown up. You make these decisions. [laughs] You are allowed to be an adult now. In fact, you need to be an adult now. JAMEY: That's also very insightful, I think. JOHN: Yeah, and interestingly, it ties in with – so my company had an event for Black History Month. We're a healthcare company, we have a lot of clinicians of color and they put together a panel discussion about Blackness in a healthcare context and literally one of the panelists was talking about how do you cope with there's still prejudice, there's still people joining medical school right now that believe that Black people don't experience pain as strongly as other people. How do you deal with that? They said almost literally the same thing. You take advocates with you to your medical appointments so that you can have more opinions. You can have someone to help fight for you, someone to help make those arguments, and point out things that you might not be noticing at the moment about how the provider is acting, or just to give you that moral support to actually voice your like, “Hey, what, wait, wait, wait, this is not right. Let's back up and talk about this again.” So I think that advice is important in so many intersections that I'm glad you laid it out like that. JENNA: It's a really interesting conversation that I wound up having. I've had sleep problems my whole life and by the way, if you're ADHD and you have sleep problems, you're not alone. It's a pretty common symptom [chuckles] to have disrupted and disordered sleep partly because our brains get bored and then we wake up. Our brains don't know how to focus on sleep. Interesting study that somebody's undertaking. But my neurologist that I see for sleep asked me to be part of a panel conversation with a team of doctors and they basically asked me questions about being ADHD and having sleep issues. And one of the things that these doctors had never really considered is that I know enough about my own body and my own sleep to know why all of the things that they've suggested haven't worked. One of them was like, “Did you try having more potassium?” I remember I just stopped myself and I said, “Listen, my parents have told me stories of how I wouldn't sleep as an infant.” We're talking about somebody who was sleeping 2, or 3 hours a night as a toddler. This is not a new thing. This is not insomnia. This is not stress related, stress induced sleep loss. This is a chronic medical condition. I said, “If you think that I haven't tried more potassium, having peanut butter at night, turning off devices an hour before bed, not watching TV before bed, not reading before bed, using the sleep training apps, going for a sleep study. If you think I haven't done this stuff, I don't know how to help you, because if you think I've made it this far in my life without trying anything, we have a whole another conversation to have.” It's the same thing. I'm going to say this and it's going to sound really hurtful to providers, but they think that we were born yesterday and until that change, we just have to keep proving them wrong. JAMEY: I think that you won't probably hopefully hurt the feelings of providers who aren't like that. Because my suspicion is that providers who aren't like that are like, “God, I know.” [laughter] JENNA: I hope so. I hope so because they're patients, too. I really wonder what it's like for them to go to a doctor. JAMEY: Yeah. I didn't want to totally derail into a different conversation again, but I just want to kind of note that this all really resonates with me also as a trans person, because I know way more about trans healthcare than doctors do. [chuckles] So I go in and I say, “This is what we're going to do because I know all about this,” and my doctor's pretty good. He listens to me and he works with me, but he says like, “Cool, I don't know anything about that so sounds good,” and it's just wild to me that I have to learn about all of my own healthcare to do healthcare. JENNA: Yeah, which that's a whole another conversation about how important it is to – like we talk about diversifying tech, which is important, but we also have to diversify the community. Until there are trans clinicians, until there are more Black clinicians, until there are more assigned female at birth clinicians, we are going to continue to find ourselves in these situations and we're going to continue to find ourselves in dangerous situations. I think about—getting off track for a second because that's what I do. I live in Cleveland. Well, I don't live in the city of Cleveland, but Cleveland is my nearest metro area. I'm 10 minutes outside of the city. Cleveland has one of the worst infant and maternal mortality rates for Black women in the country. We also have some of the lowest numbers of Black OB-GYNs in the country. There is a direct correlation there. No offense to my white men, friends, but all of these white men sitting here in their ivory tower guessing at how they're going to solve this problem while at the same time women like Serena Williams nearly die in childbirth because they don't listen to her. It's like, so you're going to come up with these solutions when you're not even listening to some of the most educated and informed patients that you have? It's why there's a whole coalition of Black women in Cleveland that have started a doula organization that they're becoming doula to support other Black women in the city because they don't feel like the medical community is here for them. It's the exact same thing. Like until we have this diversity that's so needed and required, and reflects patients, people are going to die. JAMEY: Yeah. On the flip side of that, when you do have a provider that shares your background in that way, it's so empowering. My new endocrinologist is trans and the experience is just so different that I couldn't have even fathom how it was going to be different beforehand. [chuckles] JENNA: That's amazing, though. That transforms your care, right? JAMEY: Yeah. Totally. JENNA: But it all comes back to what I said about how I care deeply about the human [chuckles] because this is all the human stuff. [chuckles] JOHN: Yeah. JAMEY: So what we like to talk about here on Greater Than Code, the human stuff. JENNA: That's why I love Greater Than Code. [laughs] I can't help myself, though. Whenever I say human stuff, or think about human stuff, I think about Human Music from Rick and Morty. [laughter] That whole thing has always stuck out in my mind. [laughs] Just look up Human Music from Rick and Morty and you'll get a giggle. [laughs] JAMEY: I think it's a great time to do reflections. What do you think? JOHN: Yeah, I can start. I think there's probably a ton I'll be taking away from this. But I think what struck me the most is right at the beginning when you were talking about your superpower, you talked about yourself as a super human, not super human, but as a just super human, just you're really human. All of us are, but we don't think of ourselves that way. I just love that framing of it as just that I'm here as a human and I'm leaning into it. I really like thinking that way and I'll probably start using that term. JACOB: I related really hard to the forgetting how to mask situation since COVID. I don't know if that's a full reflection, or not, but I relate really hard to that. JAMEY: I feel like in a way my reflection is so general, I think it's so great to talk about stuff like this. I think that it's really important. Like I was kind of saying about we have more people realizing things about theirselves because people are just more are open about talking about this kind of topics. I think that that's really amazing and I think that when people like Jenna come on shows like Greater Than Code and we can provide this space to have these kind of conversations. That, to me feels like a real a real privilege and I almost can't come up with a more specific reflection because I hope people will listen to the whole show. [chuckles] JENNA: What's been really amazing is getting to talk about whatever just feels stream of consciousness in this conversation has connected a lot of dots for me, which is really neat because outside of tech, for folks who don't know, I'm a deacon at my church, which is also a very human thing because I provide pastoral care to people who are in the hospital, or who are homebound, or who are going through crisis, or in hospice care, or families who have experienced a loss. All of these things interconnect—the way that I care for my community, the way that I care for my broader community because I have my church community, I have my tech community, I have my work community, I have my family. All of these very human spaces are the spaces that are most important to me. If you are my friend, you are my friend and I am bad about phone calls and stuff, but you are still somebody who's on my mind and if something happens, I'm your person. You just message me and I'm there. It all interconnects back to all of these like disparate ideas that have just coalesced in one conversation and I love that and that makes my heart very full. JAMEY: Thank you so much for coming on the show. Is there anything that you want to plug? JENNA: So I have a couple of talks coming up. At InflectraCon, I am doing a risk-based testing talk and Agile Testing Days, I am doing a workshop on test design techniques. If you came to CodeMash, it's that workshop, it's fun. Support your local testers! That's my big plug. Support your testers! [laughter] JAMEY: Think about them as the experimental cats. I think that will be helpful for people. [laughter] JENNA: Yes! [laughter] JAMEY: Thank you so much. This was great! JOHN: Yeah, I loved the last line of your reflection. That was beautiful. JENNA: Aw, thank you. Special Guest: Jenna Charlton.

01:47 - Nyota's Superpower: To hear and pull out people's ideas to make them more clear, actionable, and profitable! * Acknowledging The Unspoken * Getting Checked 07:15 - Boundaries and Harmony 10:35 - News & Social Media * Addiction * Filtering * Bias 18:54 - The Impact of AI 23:00 - Anyone Can Be A Freelance Journalist; How Change Happens * Chelsea Cirruzzo's Guide to Freelance Journalism (https://docs.google.com/document/d/18rwpMH_VpK8LUcO61czV2SzzXPVmcVhmUigf1_a7xbc/edit) * Casey's GGWash Article About Ranked Choice Voting (https://ggwash.org/view/79582/what-exactly-is-ranked-choice-voting-anyway) * First Follower: Leadership Lessons from Dancing Guy | Derek Sivers (https://www.youtube.com/watch?v=fW8amMCVAJQ) 40:13 - The Intersection of Cybersecurity and Employee Wellness: Resiliency * @selfcare_tech (https://twitter.com/selfcare_tech) Reflections: Casey & John: “A big part of resilience is being able to take more breaths.” – Nyota Damien: You can be the expert. You can be the journalist. You can be the first mover/leader. Applying that conscientiously. Nyota: Leaving breadcrumbs. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: PRE-ROLL: Software is broken, but it can be fixed. Test Double's superpower is improving how the world builds software by building both great software and great teams. And you can help! Test Double is hiring empathetic senior software engineers and DevOps engineers. We work in Ruby, JavaScript, Elixir and a lot more. Test Double trusts developers with autonomy and flexibility at a remote, 100% employee-owned software consulting agency. Looking for more challenges? Enjoy lots of variety while working with the best teams in tech as a developer consultant at Test Double. Find out more and check out remote openings at link.testdouble.com/greater. That's link.testdouble.com/greater. DAMIEN: Welcome to Episode 275 of Greater Than Code. I'm Damien Burke and I'm here with John Sawers. JOHN: Thanks, Damien. And I'm here with Casey Watts. CASEY: Hi, I'm Casey! And we're all here with our guest today, Nyota Gordon. Nyota is a technologist in cybersecurity and Army retiree with over 22 years of Active Federal Leadership Service. She is the founder, developer, and all-around do-gooder at Transition365 a Cyber Resiliency Training Firm that thrives at the intersection of cybersecurity and employee wellness. Welcome, Nyota! So glad to have you. NYOTA: Thank you so much for having me. I appreciate you. CASEY: Yay! All right. Our first question—we warned you about this—what is your superpower and how did you acquire it? NYOTA: My superpower is to hear, pull out people's ideas, and make them more clear, more actionable, and more profitable. DAMIEN: Ooh. NYOTA: Yeah, that's one of my friends told me that. And how did I get it? I'm a words person. So I listen to what people say, but I also listen to what they don't say. CASEY: What they don't say. NYOTA: Yeah. CASEY: Can you think of an example? NYOTA: Like that. Like when you did that quiet thing you just did, I saw that mind blown emoji because there's a lot in unspoken. There's a lot in body language. There's a lot in silence. When the silence happens, there's a lot when someone changes the topic, like that stuff is a lot. [chuckles] So I listen and I acknowledge all of that. Maybe we all hear it, or don't hear it depending on how you're processing what I'm saying, but we don't always acknowledge it and respect it in other people, DAMIEN: You have to listen to the notes he's not playing. [laughter] Do you ever have an experience where things that are not said do not want to be heard? NYOTA: Absolutely. But that's part of acknowledging and so, you can tell when people are like, “I do not want to talk about that.” So then I would do a gentle topic change and not a hard left all the time, because you don't want to make it all the way weird, but it may be like, “Oh, okay so you were talking about your hair, like you were saying something about your hair there.” I try to be very mindful because I will get in your business. Like, I will ask you a million questions. I'm very inquisitive and maybe that's one of my superpowers too, but I'm also aware and I feel like I'm respectful of people's space most times. CASEY: I really like that in people when people notice a lot about me and they can call it out. When I was a kid, my family would call me blunt, not necessarily in a bad way, but I would just say whatever I'm thinking and not everyone likes it right away. But I really appreciate that kind of transparency, honesty, especially if I trust the person. That helps a lot, too. NYOTA: I was just saying that to my mom, actually, I was like, “You know, mom, I feel like I need a different quality of friend,” and what I mean by that is my friends just let me wild out. Like I ask them anything, I say anything, but they don't kind of check me. They're like, “Well, is that right, Nyota?” Like, Tell me, why are you saying it like that?” But they just let me be like ah and I'm like, “Mom, I need to be checked.” Like I need a hard check sometimes. So now you're just letting me run wild so now I'm just seeing how wild I can get. Sometime I just want maybe like a little check, a little body check every now and then, but I try to be mindful when it comes to other people, though. It's the check I want is not always the check that other people want. CASEY: Right, right. DAMIEN: What is it like when you're being checked? What happens? NYOTA: It's hard to come by these days so I'm not really sure [chuckles] when I'm getting my own, but I'll ask a question. I'll just kind of ask a question like, “Well, is that true?” people are like, “This world is falling apart,” and you know how people are because we are in a shaky space right now and I'm like, “But is that absolutely true for your life?” How is everything really infecting, impacting what have you being exposed to in your own life? So as we have the conversation about COVID. COVID was one of my best years as far as learning about myself, connecting with people better and more intimately than I ever really have before and we're talking virtually. So things are going on in the world, but is it going on personally, or are you just watching the news and repeating what other people are saying? JOHN: That's such a fascinating thing to do to interrupt that cycle of someone who's just riding along with something they've heard, or they're just getting caught up in the of that everything's going to hell and the world is in a terrible place. Certainly, there are terrible things going on, but that's such a great question to ask because it's not saying there's nothing bad going on. You're not trying to be toxically positive, but you're saying, “Let's get a clear view of that and look at what's actually in your life right now.” NYOTA: That part, that part because people are like, nobody's looking for crazy Pollyanna, but sometimes people do need to kind of get back to are we talking about you, or are we talking about someone else? DAMIEN: That's such a great way of framing it: are we talking about you, or are we talking about someone else? NYOTA: Yeah. CASEY: It reminds me of boundaries. The boundary, literally the definition of who I am and who I care about. It might include my family, my partner, me. It's may be a gradient even. [chuckles] We can draw the boundary somewhere on that. NYOTA: Yeah, and I think we also get to speak even more than boundaries about is it in harmony? Because I feel like there are going to be some levels that are big, like my feelings are heard, or I'm feeling like I just need to be by myself. But then there are these little supporting roles of what that is. I think it's as you see, some parts are up and some parts are down because sometimes when it comes to boundaries, it's a little challenging because sometimes there has to be this give and take, and your boundaries get to be a little bit more fluid when they have to engage with other people. It's those darn other people. [chuckles] DAMIEN: But being conscientious and aware of how you do that. It's a big planet with a lot of people on it and if you go looking for tragedy, we're very well connected, we can find it all and you can internalize as much of it as you can take and that's bad. That is an unpleasant experience. NYOTA: Yeah. DAMIEN: And that's not to say that it's not happening out there and that's not to say that it's not tragic, but you get to decide if it's happening to you, or not. NYOTA: Right. DAMIEN: And that's separate from things that are directly in our physical space, our locus of control, or inside of the boundaries that we set with ourselves and loved ones, et cetera. NYOTA: Because it's so easy to – I say this sometimes, guilt is a hell of a drug because sometimes people are addicted to guilt, addicted to trauma, addicted to a good time and not even thinking of all the things that come with those different levels of addiction. So I think we get fed into this news and this narrative, like we were speaking of earlier a of everything's bad, this is a terrible place, everyone's going to hell. Whatever the narrative is the flavor of the moment and there's so many other things. It's a whole world, like you said. It's a whole world and I think the world is kind of exactly what we're looking for. When I was in the military, every town is exactly what you need it to be. [laughter] Because if you're looking for the club, you're looking for the party people in little small towns. But I could tell you where every library was. Don't call me nerdy because I am, but I don't care. All right. I could tell you where every library was. I could tell you where every place to eat. I could tell you all of those things, but then you'll ask me like, “Where's the club?” And I was like, “There's a club here?” Because that's not what I'm looking for. That's not the experience that I'm looking for. So I would dare say every place is exactly what you're looking for, what you want it, what you need it to be. CASEY: We're talking about the news a little bit here and it reminds me of social media, like the addiction to news, the addiction to social media. In a way, it is an addiction. Like you keep going to it when you're bored, you just reach for it. That's the stimulus, that's your dopamine. I think of both of those, news and social media, as a cheap form of being connected to other humans. A bad, low quality, not a deep connection kind of thing. But what we all would thrive if we had more of is more connections to others, which like community, authentic relationships with people. But that's harder. Even if you know that and you say that's your goal, it takes more work to do that than to pick up Facebook app on your phone. I deleted it from my phone six months ago and I've been happier for it. [laughter] NYOTA: Like delete, delete? Like delete? CASEY: Well, it is on my iPad in case I have to post a shirt design into a Facebook group. I'm not gone gone, but I'm basically gone and I know that I don't interact on it and it's boring. I don't post anything. I don't get any likes. I don't even want to like anyone's post and they'll say, “Oh, you're on.” I don't do anything. Like once every three months, I'll post a design. NYOTA: Is that for every social media channel? CASEY: I'm still on Twitter. NYOTA: Twitter. CASEY: I'm still on Twitter and LinkedIn kind of for business reasons. But if I could drop them, I think I would, too. NYOTA: Did you say if you could? CASEY: If I could drop them and not have business repercussions. NYOTA: Mm. DAMIEN: This sounds like a great idea to make more profitable. NYOTA: [laughs] I'm thinking does a lot of your business come from –? I feel like LinkedIn is social, but. CASEY: I wouldn't say that I get new business from these necessarily, but I do end up with clients and potential clients and people I've talked to before saying, “Ph, I saw that thing and now that I saw you wrote a blog post about doing surveys for an engineering org, now I want to talk to you.” NYOTA: Mm, okay. CASEY: Like that is pretty valuable and when I'm writing something like a blog post, I want to put that somewhere. But anyway, I am happier that I'm off of Facebook and Instagram, which I wasn't getting as much value out of. Other than connection to people, the shallow connection to people and instead I switched to messaging people. I have text message threads and group chats and those are much more intimate, much more stuff being shared, more connection to those individuals. NYOTA: I agree with that. What about you John? Like what is your relationship with social media right now? JOHN: So I've always been sort of arm's length with Facebook. So it's been just like eh, I check in every week, maybe just sort of see. I scroll until I lose interest, which is 10 minutes the most and then those are my updates. That's all I see and then occasionally, I'll post a meme, or something. I don't really do a lot there. Usually, I keep it around just for the people that I'm in touch with that are only on Facebook and I only have connection to them. But you bring up an interesting point about there's a positive and a negative to being able to filter your social media. For example, with Reddit and Twitter, you only see the stuff for people you're following and/or the subreddits that you're subscribed to. So you can very much customize that experience into something that isn't full of most of the crap people experience on Twitter, or Reddit. So there's that positive there because you can craft a world that's maybe it's all kitten pictures, maybe whatever, and post about programming, whatever it is. But you do have the problem of filter bubbles so that if you are in something that's a little bit more controversial, you do end up with that echo chamber effect and lots of people jumping in, or if you're in a sub that's interesting to you, that's also very contentious and the threads go off the rails all the time, but you can control that. You can see like, “Well, no, get it out of here. I don't need to deal with that static.” I rely on that a lot to sort of focus in on what I'm using it for, whether it's keeping up with specific friends, or specific topics and then trying to filter out as much of the things I don't want as possible. NYOTA: Is Facebook's your only social media channel? JOHN: No, I'm on Twitter. I don't usually post a lot, usually just retweet stuff and read it. NYOTA: That's kind of lame a little bit. I'm not saying, I'm just saying that your social media choices – [laughter] DAMIEN: Wow. NYOTA: But I think you're are right, though. I'm a lot better off for it because I did find myself going down a social media rabbit. It was easy for me to cut off the news. I actually stopped watching the news in 2007 when I became an officer. They were like, “As an officer, you have to watch the news. You have to be aware of what's going on in the world,” and I was like, “Oh, okay,” and then I walked away from that lady and I was like, “I'm not watching the news anymore.” DAMIEN: Hmm. NYOTA: Because I felt like she was trying to trick me in some kind of a way, but you get what you need. If it's something that I need to know, it comes to me it. It comes to me like. Believe me, it'll come to you. She was a little bit too adamant about what I needed and how the news was a part of it. It just felt a little not right and so, I actually stopped. DAMIEN: The news is a very specific thing like that word, the news [chuckles] Is anything new about it? [chuckles] The news is a group of organizations, a group of media organizations that are all very much alike. The Economist, The New York Times, The Washington Post, The L.A. Times, The Chicago Tribune, NBC, ABC, CBS, Fox News, MSNBC. These are all organizations that operate the same, they cover the same things, and they do them in largely the same way along of course, some political partisan differences. But it's not new and for most people, it does not serve them, or inform them. NYOTA: Yeah. It's very divisive. DAMIEN: I used to get my news from Jay Leno. [laughter] That was better than CNN more and funnier, too. NYOTA: That part. [laughs] I think it's just interesting how it's such a whole world with a whole bunch of people with various levels of experiencing, bumping into each other, and like you're saying, this is what everyone's reporting on. Nothing else happens? Nothing good happens anywhere else? CASEY: Yeah. NYOTA: Nothing? See, that's not true. [laughter] Like that can't be real for me and so, I'm not going to be able to include that in where I spend my time. JOHN: Yeah. I used to have NPR on in the car whenever I was in the car, I was like, “Oh, it'll keep me inform,” blah, blah, blah. But eventually, I was like, “You know what? They still talk about the same crap. They're just from a perspective I agree with slightly more.” But even when they do human interest stuff, or stuff that isn't about a war, or some sort of crisis in Washington, it's still so negatively biased. Even the stuff that's theoretically positive, it still has this weird you should be concerned about this vibe to it and eventually, I was realizing that there's no room for that in my life. DAMIEN: Yeah. We talk about how harmed full Facebook is to society and individuals. But this is not again, new. [chuckles] Facebook optimizes for engagement, which causes harm as a byproduct. It's the AI-fication of what media has been doing ever since there has been mass media. NYOTA: Yeah. It's interesting because there was a moment in there. So I even got on social media because I was always gone. I lived wherever I lived while I was in the military and so, it was a way to let my family know, “Okay, I'm here. Look, I ate this.” [chuckles] All of those things. So there was a part where Facebook made a drastic turn on my feed and I was like, “Ohm this is so bad!” And then I was like, “Okay, wait, wait. Who's bad? Who is this coming from?” So I cleaned up my whole Facebook feed and then it became a happy place again and then now where it is, it's a place where it's only seven people out of the thousand Facebook friends I have. I was like, “Okay, well that's not it either. That's not it.” So it's just interesting how AI has such a impact of what we listen to, or what we talk about. So now it's these days I'm like new shoes, new shoes, new shoes. Because I want that to come up on my – I don't even – you know what I'm saying? Because I know that you're listening, so I'll get it later. So now I almost treat it like an administrative assistant so I can look it up later. [laughter] CASEY: Hilarious. NYOTA: Yeah. JOHN: Please target some ads around shoes to me. NYOTA: I did. Yeah, because they're listening. CASEY: And it works, doesn't it? I know. NYOTA: Yes. CASEY: I know it works. NYOTA: Yes. CASEY: That still blows some people's minds. If you could say the name of a product and you'll see it the next day. If you have your ads on, it's listening and your phone is listening. Everyone's phone is listening. NYOTA: Yes, yes. Because you're looking at something like – I don't even really listen to the music. What is it? Spotify! And then it's like, you're listening to Spotify, but why is my mic on? You want to hear me sing the song? Why does my mic have to be on? I don't understand that part. Like why? They'll be like, “Oh, she has a great voice on her.” Is that why you're listening? [laughter] Why are you listening? I don't understand that part. So I don't know. DAMIEN: There's a deal coming your way. NYOTA: [laughs] Come on. Let's go. JOHN: I assume the public reason for it is so that you can do voice searches and like, “Hey, play me some more Rebecca Black,” or whatever. But who knows what else they're doing with it once you've got it turned on, right? It could be whatever. DAMIEN: Actually listening in on people is not the technically most effective way of getting those results. If you say the brand name of a shoe, it's probably because the people around you are talking about it and what do they search on Google? What ads have they seen? It's easier to say, “Oh, you're in the room with these people who are interested in these things,” or “You're in conversation with these people who are interested in these things. Let me show you these things without honing through massive amounts of audio data.” CASEY: Yeah. Both are possible and that one's easier. I'm sure they both happen and at what frequency, that's hard to study from beyond outside, but we know it's all possible and we know it's happening. If this is news to anyone listening, you can look this up. There are a million articles about it and they explain why and how, and some people did some empirical tests and I don't have any handy, but I've read it over and over and over on the internet and the internet's always right. NYOTA: That's what I heard [laughs] and not from the news. CASEY: I have these Google Home Minis in my house and all of them, the mics are off. So if ever the power cable gets jingled, it says, ‘Just so you know, the mic's off and I have to say it for a really long time. This is a very long recorded message. So that you'll want to turn your mic back on,” and it says that. Can you believe it? [laughter] DAMIEN: That's not the actual text of the message, right? I have to check. NYOTA: These little home speakers are cool in all the worst ways, but the best ways, too. So my Alexa, I'll be asking her whatever and then I'll say, “Thank you, Alexa,” and she'll say, “You're very, very, very, very welcome,” like she's singing, yes. [laughs] DAMIEN: Wow. You people have corporate spying devices in your homes. It's unbelievable. NYOTA: But you have one, too. It's just your phone. So we all have them. DAMIEN: Yeah. She promises me she doesn't listen unless I ask. NYOTA: That's what mine said! CASEY: Mine said it! [laughter] I don't trust them either. I don't even trust that the mic off necessarily works. Part of me is tempted to go in and solder the mic off. I never want the speakers to have the mic. I will not use that feature at my house. But I do want speakers in every room enough that I'm willing to take the risk of the switch not working. NYOTA: Yeah. At this point, I think I've just big brothers watching, or at least listening, [chuckles] Big brother really like, “Oh, I need to turn that off. She's talking about the big brother. We'll blush over here.” [laughs] CASEY: I want to go back to something I was thinking on the news. Sometimes I hear, or I know about things in the world because I'm someone who's in the world sometimes and the topics I want to hear in the news don't always come up. Like, DC Rank the Vote is happening and there was eventually an article about it and another article. I wrote one, eventually. Anyone can be a freelance journalist. So if the news isn't covering stuff you want it to. NYOTA: I like that. CASEY: You can literally write the news, too. NYOTA: Mm. CASEY: They might even pay you for it. DAMIEN: [chuckles] You can write the news, too. Say it again, Casey. CASEY: You can write the news, too. There's a really cool freelance journalism guide, that I'll put in the show notes, by someone in D.C. Chelsea Cirruzzo, I think. I didn't pronounce check that, but she wrote an awesome guide and it led me to getting an article published in Greater Greater Washington, a D.C. publication about ranked choice voting. I was like, “Why is no one talking about this? It's happening here. It's a big problem.” So I wrote about it. Other people write about it, too and they have since then, but you can be the change you want in the world. You can. Journalism is not as guarded and gated as it might seem. NYOTA: That's so interesting because I think what's interesting is we know that. We know that we can contribute, we know that we can write, but then you're like, “Wait, I can contribute! I can write!” CASEY: Mm. NYOTA: So I think that's, thank you for that reminder. CASEY: Yeah. But the how is hard and without a guide like Chelsea's, I'm not sure I would have broken in to do it. I needed her to go through it and tell me this is the process, here's the person in the org, what they do, what they expect and how you can make it easy for them, and you need the pitch to have this and that, has to be timely and like –. All that made sense. I'm like, “Oh sure, sure, sure.” But I couldn't have come up with that on my own, no way. NYOTA: But she bundled it together like that. CASEY: Yeah. DAMIEN: I would have never imagined that's a thing you can do because that's an entire degree program. That's a post-graduate degree program, if you'd like, and I see people who've been doing this for 20 years and do it poorly and they seem like smart people. [chuckles] So what makes me think I could do it? NYOTA: Because we can do whatever we want. CASEY: I mean, these publications do have editors and it's their job to help make the quality, at least meet the low bar at minimum that the publication expects. But if you are really nerded out on ranked choice voting, or something, you might be the local expert. If you're thinking about writing an article, you might be the best person to do it actually. NYOTA: Mm, that's good. That's the quota right there. CASEY: So what are you nerding out about lately? Anyone listening to this, think about that to yourself and is there an article about it you can just share? I like that. I don't have to write every article ever. If not, you can think about writing it. NYOTA: I like that. DAMIEN: And what strikes me is like where the bar is for local expert. Like I believe a 100% that you're the local expert on ranked choice voting because I know enough about ranked choice voting to know that people don't understand it. [chuckles] CASEY: Yeah. And after I wrote the article, I found a group of people and so, now there's like 10 of us at this level where we get it and we're advocating for it. But I'm one of the top 10 at that point still, sure. And there are details of it that I know, details other people know that I don't know, and we're all specialists in different nuanced details and together we're stronger and that's a community, too. It's been a lot of fun advocating for that in D.C. JOHN: That's awesome. NYOTA: It's interesting the visual that I'm getting in my head, like you're over here dancing by yourself and then you back up and they're like, “Oh shoot. Other people are dancing to this same song,” and then you look and you'd be like, “Look, y'all, we're all dancing,” but you're still the lead dancer and they're the backup. [laughter] I don't know why I got that visual. CASEY: I like this image. NYOTA: Yeah. CASEY: I want to give the other organizers some credit. I think they're the lead. But I found them eventually. I couldn't have found them if I didn't write the article probably. I looked it up. I Googled it once, or twice. They have a website, but I don't know, it didn't come up for me right away, or it did, but I didn't know how to contact them and getting into breaking into that community is its own barrier. NYOTA: That's unfortunate. But you're the lead to me. I mean, you're Casey. I mean [laughter] they're okay. CASEY: Thank you. NYOTA: I mean they're okay for what they're doing, but they're not you, so. No shade on what they're doing. CASEY: Sure. JOHN: I just posted a link to a talk by Derek Sivers about how the first followers are actually more important than the first leader and it's a fantastic talk. It's pretty short, but really amusing and it makes such a fantastic point. Like Casey, you were out there, you posted the article and then all these other people show up. So now I've got this like group of 10 and then those people – you and they are all doing outreach and they are expanding that group of people that are up to speed on this stuff and are advocating for it. So there's this nucleus and it's expanding and expanding. CASEY: Yeah, and each person we get, then they can bring in more people, too and it's a movement, it's growing. I think we'll have it soon. There's literally already a bill passed in D.C. It's passed a committee and now it's gone to the bigger committee, the whole process, but there's a real bill that's been passed some steps. NYOTA: You might as well do a TEDx. I mean, you might as well. JOHN: Yeah. CASEY: Good idea. Yeah, yeah. NYOTA: But they just let anybody do them. I have one. They just give them out. They're like, “Let Nyota do it.” “Okay. I'll just – let me do it.” You can do it. You have something to talk about, it's the same. It's like the news. Why not you? CASEY: Yeah. NYOTA: You're already talking about it. CASEY: True. NYOTA: I mean, you get a TEDx, you get a TEDx. [laughter] CASEY: Look at this, Nyota inspiring us. DAMIEN: I'm inspired. Why not me? NYOTA: No, really. DAMIEN: I'm serious. That is not sarcasm. I mean that very sincerely. I'm thinking about all the things I want. I'm going to call Casey later on and go, “Okay. You know how to bring ranked choice voting to a government. How are we going to bring it to another one?” And I think about all the other – CASEY: Yeah. DAMIEN: I'm actually trying to bring ranked choice voting to my neighborhood council. I pushed to an amendment to our bylaws, which has to be approved by another organization, which I can't seem to get ahold of. [laughs] But we're doing it and why shouldn't we be doing it? Why not us? NYOTA: Why not? CASEY: Yeah. Oh, I've got resources to share with you. We'll talk later, Damien. JOHN: Well, that's also great because that again, is going to spread. Once the local organization is doing it, people start getting experience with it. They're like, “Oh yeah, we did it for this thing and it worked out great. Now I sort of understand how it works in practice. Why the heck aren't we doing it for the city council and for the governor?” And like, boom, boom, boom. DAMIEN: Yeah. Ranked choice voting is interesting because as much as people don't understand it, it's really simple [chuckles] and I think overwhelmingly, people need experience with something to understand it. CASEY: Yeah. Yeah. DAMIEN: And we have a lot of experience with plurality voting in this country, in my country at least. We have almost none with ranked choice voting. NYOTA: I think it's interesting how people get so excited about presidential elections and that sort of thing, but your life really happens at your local elections. CASEY: So true. NYOTA: Your quality of life is your local elections, like you're talking about these roads being trashed. Well, that's at the local. Biden and Kamala, they have nothing to do with those potholes all along this road. I think so people miss that. You're like, “Those elections are great. Presidential election, awesome.” But your local elections? Those are what matter for where you live and I'm like, “Why are people missing that?” CASEY: Yeah. DAMIEN: I think it goes back to the news. CASEY: Sure. That's a part. NYOTA: Darn you, news. [laughs] DAMIEN: Right, because national news is leveraged. NYOTA: Mm. DAMIEN: The national broadcast is made once and broadcast to 300 million people in the country. Local news does not have that leverage. CASEY: True. NYOTA: Mm. They need to get their social media presence together then because people are listening to Instagram. CASEY: I'm thinking about everyone's mental model of how change happens, too and I don't think a lot of people have a very developed mental model of what it takes to make change happen. I do a workshop on this actually and one of the examples I use is for gay marriage in the US. You can see the graph; you can look it up. We'll include in the show notes, a picture of gay marriage over time and it's like one's place, one's at another place, like very small amount. Just maybe not even states like counties, or some lower level, a little bit of traction, a little bit of traction, a little traction. Eventually, it's so popular that it just spikes and it's a national thing. But along the way, you might look here from the news that when it became a national thing, that's the first time, that's the first thing you heard about it. But along the way, there was all these little steps. So many little steps, so many groups advocating for it, and the change happened over time. I also think about the curve of adoption. It's a bell curve. For the iPhone, for example, some people got it really early and they were really into this thing. Like PalmPilots were really the earlier edge of smart devices. Some people had that; they're really nerdy. Some people are still holding out on the other end of the bell curve. Like my mom's best friend, she still has a flip phone and she doesn't have any interest in a smartphone. I don't blame her. She doesn't need it. But she's the lagger, the very far end lagger of on this model and to get change to happen, you've got to start on whoever is going to adopt it sooner and actually like get them involved. Like the smaller states, the smaller counties that are going to support gay marriage or whatever the issue is, get them to do it and then over time you can get more of the bell curve. But a lot of people think change happens when you get the national change all of a sudden, but there's so much earlier than that. So, so, so much. Like years. 30, 40, 50, a 100 years sometimes. [chuckles] NYOTA: Yeah. This is the dance that John was talking about that he posted about this. CASEY: The first follower, yeah. NYOTA: Yeah, first followers. But you get to be the first leader if you allow it. If you really want change like you're saying. Instead of looking for someone to follow, [chuckles] we get to decide how we want to live. DAMIEN: Yeah. This seems true at work. If there's a cultural norm you don't like, you can change it by getting your allies on board and aware of it, socializing it and more and more people and gradually over time and eventually, that thing's not happening anymore. Like, I don't know. An example is eating at your desk over lunch. Not the best social norm. I don't want that at places I work. I want people to take a break, rest, and be better off afterwards. But you can get it to happen gradually by getting more people to go to lunch room, or go out of the office and you can change the culture in the office with enough dedication and time if you put your mind it. NYOTA: Yeah. But what we don't get to do is complain about it. Right? [chuckles] CASEY: Mm. Whenever I have some kind of conflict, I think about do I want to accept it and stop complaining, or do something about it? NYOTA: Mm. CASEY: Or I guess the third option is neither and then I'm just frustrated. I don't like to choose that one if I can ever avoid it. [chuckles] Do something, figure out that I can do something like work on it, or accept it, which is kind of giving up. But you can't do every change you ever think of. NYOTA: No. CASEY: It's not really giving up. Acceptance does not mean giving up, but it does mean you can put your mind down and focus on other stuff. NYOTA: Yeah. That's triage. That's what that is. [laughs] CASEY: Triage. Yeah, yeah. [laughter] DAMIEN: That third option is really important because I choose that a lot. It's important to know that and acknowledge it. [chuckles] It's like, oh no, I've chosen to be frustrated. Okay. NYOTA: Yeah. Good. CASEY: And you can, yeah. Sometimes when I choose to be frustrated, it's that I'm still working on it. I'm working on figuring out if I can do anything, or not. I don't know yet. DAMIEN: For me, it's I'm not willing to do, or figure out what it is to do, but I'm also not yet willing to accept it so I just shouldn't to be frustrated. CASEY: Sure, yeah, yeah. DAMIEN: And the frustration. If I acknowledge that and recognize that, the frustration can better lead me to go, “Okay, no.” Making the change stinks. But [chuckles] the frustration is worse and lasts longer, so. NYOTA: And then you start speaking from your frustration, which is even worse [laughs] and then it bleeds over. CASEY: Not effective. NYOTA: Yeah, it bleeds over into other things and because now you're saying stuff like, “See, this is what I'm talking about.” [laughter] No, I don't. No, I don't see what you're – no. Are we talking about the same thing? Because now you're just frustrated all over the place. CASEY: Yeah. [laughter] NYOTA: What are you talking about again? Are you talking about work? CASEY: When someone's in that situation, I have to ask them, “Would you like to be effective at this?” DAMIEN: Ooh. [laughter] NYOTA: Oh, that's a shank. [laughter] CASEY: They might not want to be. They might just want to vent. That's fine. It helps me set my standards, too. Like, do they want support, or do they want to vent? NYOTA: I'm going to write that down. CASEY: I mean, it sounds pointy. Here's my blunt side showing. I meant it. You can answer yes, or no. It's why it's a question. I'm not going to give you obvious answer question. I expect one. NYOTA: Yeah. That's good right there because I'm just getting to the part where I'm like, “Do you want me to help, or you just want me to listen?” Because I'll be like, “Oh, I know the answer to this!” And they'll be like, “Oh, I don't. You always trying to help!” First of all, stop talking to me then. [laughter] DAMIEN: Can you tell my friends that? NYOTA: Right? CASEY: Yeah. NYOTA: Like don't come to me because I just want to help. I've got a solution and if you don't want a solution, don't talk to me. CASEY: Sure, sure. That's the kind of support you're offering. NYOTA: Yeah. CASEY: You're offering that support and if they want it, great. If they don't, sounds like you're setting the boundary. Good. NYOTA: Right, right. Oh, I don't have a – no, I have no problems setting a boundary. Yeah, no problems because the thing is this is your third time. Like at some point, you need to either want to do something, or quit talking to me about this. CASEY: Yeah. NYOTA: Like that part. CASEY: I'm pretty patient supporting friends like that, but there is a limit to the patience. Yeah, three. That sounds like pretty good. I might even go to six for some people before I start telling them no. NYOTA: Mm. CASEY: [laughs] I mean, “You have to do something, or complain to someone else.” NYOTA: Yeah. Like, are you going to do something – are we still talking about this like? CASEY: Yeah. Some people need the support, but it's not necessarily me they're going to get it from because I don't have that much energy and time to put toward that. NYOTA: Yeah. I just think that's important to, but my friends know that already. Like, don't talk to me about your allergies, or don't talk to me about your fitness, or you can't fit your clothes. For me, I don't buy new clothes because I can't fit them. I won't allow myself to do that. CASEY: Some people do. NYOTA: Yeah, so – [overtalk] DAMIEN: I'm sorry. Buy clothes you can't fit? NYOTA: No, I don't buy new clothes because I can't fit my old ones. DAMIEN: Ah, okay. NYOTA: Right. DAMIEN: I know that one. NYOTA: I only buy new clothes because I want new clothes. DAMIEN: Mm. NYOTA: I put that around myself like, it's not because I don't want to go outside and walk, or you know. But then I don't allow myself to get too thin in the other direction either, because that means I'm doing something that's probably not that healthy, like not eating real food. I will just eat potato chips and that's it. [chuckles] So I have to – like, if it's too far to the left, or to the right, then I know that I'm doing something that's not healthy. I've got to reel myself in. I don't have any other checkers. I'm my own self-checker. I don't have a spouse that's going to be like, “Hmm, those jeans look a little snug.” [chuckles] I don't have it. [laughs] It's just – [overtalk] DAMIEN: Well, what I'm hearing, though is it's going to be, you set a high bar for checking people. So for somebody to check you, they're going to have to be really insightful and not candy-coated. NYOTA: I don't like candy. CASEY: Yeah. [laughter] NYOTA: Yeah. CASEY: Like direct. NYOTA: Yeah, because I don't need a bunch of like, “Oh, Nyota. How are you today?!” You don't really have to be like, “Oh, so I heard what you said about that.” I don't think that – that's not right, or however the check comes, like however it comes. CASEY: Yeah. NYOTA: But I want that because I know I'm not right about everything. I know that and I don't pretend to be all-knowing. I just want somebody to kind of reel me in sometimes like reel me in. Please reel me in. [laughter] Because I'll just keep – I'm a habitual line stepper. You know what I'm saying because now I'm just going to keep on seeing what you're going to let me slide with. Even as a kid, my mom was like, “You're always everywhere.” Like, “You're always – like, “We could never find –” I was the kid that why they came out with those harnesses for kids. [laughter] That's – CASEY: What an image. NYOTA: Yeah. I'm that kid because I just want to see, I want to go look, I want to go what's over here. Like what's around. Are you going to let me slide? Are you going to let me say that one? What else you're going to let me slide with? It's that so that's why they created those harnesses for kids like me. [chuckles] DAMIEN: Your bio says your firm thrives at the intersection of cybersecurity and employee wellness. What's the intersection of cybersecurity and employee wellness? JOHN: I was just going to ask that. I want to know! NYOTA: I think it's resiliency. DAMIEN: Mm? NYOTA: Yeah. So cybersecurity is that resiliency within organizations and then that wellness of people is that resiliency that's within humans. When those two come together, it's a healthier—I can't say fully healthy. It's a healthier work environment because when we get to show up to work healthy, resilient, drinking water, getting rest, being able to have emotional intelligence, social intelligence; all of those things are what I count as being resilient. And then when you can show up to work that way, then you're not showing up to negatively impact the network because you're not focused. You're not paying attention. You're clicking on every link because it looked like it – it seemed fine. But had you been like you had one moment of awareness to pause, you would see oh, this is not right. When I put my mouse over that, I see that the link at the bottom is not where I'm supposed to be going. So that place is resiliency at work. DAMIEN: That is an extremely advanced view of security, maybe it's from your time as an officer, but the general view of security is it's this wall you put up and you make the wall really secure, you make the wall really strong and really tall, and that way you keep everything out. It's like, well, no. Anybody who has gone to office training school knows about defense in depth. NYOTA: Right. DAMIEN: Knows you can't maintain any particular perimeter indefinitely. The French found that out to much of their chagrin. [laughs] NYOTA: Oopsie. DAMIEN: That's a Emmanuel line reference. That's not news. [laughter] To go all the way to like – and I see where you're going with this. Phishing emails don't work on people who are calm and relaxed when nothing's urgent. NYOTA: Yes. DAMIEN: Where they can go, where they can stop and think, and have that wherewithal and that energy and that reserve. NYOTA: Right, even at home. Especially how all of these scams are on the rise, Navy, federal, IRS, all kinds of people. If you're just one moment aware, you'd be like, “Wait, have I ever engaged my bank in this way?” DAMIEN: Hm mm. NYOTA: Like ever? Have they ever called me and asked me for my six digit? They called me and I didn't call them? Like, I just think if you just take a breath and then think part of being resilient is being able to take more breaths. DAMIEN: Wow. Yeah. Wow. CASEY: Ooh, I like that line. NYOTA: Yeah. We know that one of the biggest vulnerability to cybersecurity posture of anything that happens is people because we are normally that vulnerability, we're normally that weakness in the network because we are human. So anything that we get to do to reinforce ourselves, guard ourselves up, it's always going to have a positive second, third, fourth order of effects. DAMIEN: How does upper management react to that when you come in and say, “We're going to improve your cybersecurity, give your employees more days off”? NYOTA: So I'm actually new having this conversation within leadership, but they already have leadership corporations, they already have this structure in place. Just haven't heard anyone tie it together specifically to their cybersecurity posture. So there's already a lot of wellness initiatives, you can talk to counselors. I think we already have these initiatives in place, but they're just kind of ethereal, they're kind of out here, but to say, “Now tie that not just to our bottom line, because employees are less willing to have turnover, but let's tie it to the security of the network because our employees are aware and they're more vigilant.” So it's just kind of helping them to see the work that we're already doing within corporations. We get to laser focus that into a place. CASEY: Hmm. I like it that this gives way to measuring the outcome of those programs, too. You can correlate it, too. NYOTA: Yeah, instead of like, “Oh, we're happy at work. We're skipping and holding hands down the hallway.” Well, that may not necessarily be what you want, but you do want less infractions on the network. More opportunities to be successful but not having to spend so many manhours undoing cybersecurity risk. CASEY: I want to zoom out. I want to go meta with you. You're helping them become more resilient. How do you make sure your changes there are resilient? When you leave, they persist? You can Mary Poppins out and they're still the way they were before you arrive. NYOTA: Mm, that's a good question. So during the time that we work together, they also buy a bundle of coaching. They have opportunity to come back for where I can do, like, “Hey, y'all it's time for the refresh,” and not in a lame way. I'm actually creating on workshops now and it involves coloring books. Because when we were in Afghanistan, Iraq, and all the places we colored, and I just feel like coloring saves lives and when I'm saying people, I'm talking about mine, because it is very calming and not those crazy ones that are really small and you have to have a pen. So I'm talking about a 5th-grade coloring book with big pictures where it's relaxing and you're talking amongst your peers. It involves that. Setting them up with skills to be able to well, if you do nothing else, make sure you're playing the gratitude game in the mornings. What is the gratitude game? I play this game with myself. Every morning when I wake up, I say three things that I'm grateful for, but it can't be anything that I've ever said ever before. DAMIEN: Mm hm. NYOTA: I play this game. It's always making you search for the gratitude, always looking for that shiny light. There's always a better today, a better tomorrow, and so, even if there's something as that and drink water, because there's a lot of things that happens when you're dehydrated. There's a lot of clarity that doesn't happen when you're thirsty and so, even if it's just those two things and reminding people, just those two things have even had an impact on my life. Do you see my skin popping? Do you? [laughter] I'm just saying. Water is your friend. [laughs] So just those, just kind of even a pop in, a retraining. Hey, remember. Remember sleep, remember relaxing, remember get up and walk around your cube, and the filter water is so much better. It tastes so much better than bottled water. I'm just, it's better. I'm holding up my filtered water. Picture here, I keep it at my desk while I work if I'm on a lot of calls in a row. NYOTA: Yeah. CASEY: I can go through water. NYOTA: And that's why you're alert. I don't think people understand that being dehydrated really makes you lethargic and you're like, “Are they talking? I see their mouth moving. I can't pay attention. What is happening. What is that?” And being dehydrated is not good. Don't do that. Just take a little sip of water. We're talking about water, just take a little sip of your water. Go get some water. [chuckles] If you're listening, get some water. [laughs] CASEY: Reminders help. I'm going to post one of my favorite Twitter accounts, @selfcare_tech. NYOTA: Ooh. Please. CASEY: And they do a water reminder probably every day. Something like that. So I'll just be on Twitter and I'm like, “Oh yeah. Thanks.” DAMIEN: [laughs] See, we can turn social media even to our good. CASEY: Yeah. We can find some benefit. NYOTA: But we get to decide and I think that's another thing that people don't. Like, they negate the fact that you get to decide. You get to decide where your life is, or isn't. You get to decide where you're going to accept, or not accept. You're going to decide if I work at this job, it's for my greater good, or not. We get to decide that. You've already created your life up to this point. So what does it look like later? We've created this life that we have and people take responsibility for that. Who do you get to be tomorrow? Who do you get to be today? The thing is we always get what we ask for. So I've been asking for a bold community, I've been asking for a community that pushes and pulls me and here comes Casey, here comes Andrea, here comes you guys and I'm like, “I think that's so interesting.” We do get what we ask for you. CASEY: It sounds like you're manifesting the world around you. I like that word. NYOTA: Yeah. CASEY: I don't even mean it in a metaphysical spiritual sense, but even just saying. Back when I was an engineering manager and I wanted to become a PM, I told people I wanted to be a product manager and by telling a lot of people, I got a lot more opportunities than I would have. NYOTA: Yes. CASEY: Telling people was very powerful for that. NYOTA: And in my Christian Nyota way, that's what happens. Miracles come through people. So give people an opportunity to be your miracle. JOHN: So we've come to the time on our show where we do reflections, which is each of us is going to talk about the things that struck us about this conversation, maybe the things will be thinking about afterwards, or the ideas we're going to take forward. Casey, do you want to start us off? CASEY: Yeah. I wrote down a quote from Nyota. She said earlier in this episode, “A big part of resilience is being able to take more breaths,” and I just think that applies anywhere the word resilience applies and I want to meditate on that for over the week. JOHN: I'm right there with you. That is really sinking in and applicable in so many ways. I love it. DAMIEN: Yeah, and involving taking some breaths while you do that, huh? [laughter] I am really inspired by this conversation. The ideas of you can be the expert, you can be the journalist, you can be the first mover, the first leader. Realizing that in my life, I'm going to be looking for ways I want to apply that conscientiously. How to make sure not to try apply it everywhere. [laughs] But I get to decide. I get to decide who I am and who I'm going to be in this world and what this world is going to be like for me, so that's awesome. NYOTA: That is good. I like that one, too. And along those lines for me, it's like when Casey's like, “I mean, I knew this, I knew this, I knew this, I knew this, but when someone had created this bundle for you to be able to follow, I really heard when we do things, leave breadcrumbs so someone can come behind us and also be able to support. Because if you don't – leave some breadcrumbs. So I thought that was – she was like, “I knew these things but she had created this framework for you to be able to do it, too,” and I heard leave some breadcrumbs. So I really like that. DAMIEN: Yeah. John, do you have a reflection for us? JOHN: No, I mean, really, it's the same as Casey's. [laughs] Yeah, that statement is really going to sit with me for a while. I like it a lot. CASEY: I'm going to make a t-shirt of it. NYOTA: [laughs] I love a good t-shirt. DAMIEN: Well, Nyota. Thank you so much for joining us today. NYOTA: Thank you so much for having me. I'm so honored to be amongst such caring, intelligent, thoughtful people and so, I appreciate you all for having me. Special Guest: Nyota Gordon.

02:03 - Arpit's Superpower: Tenacity * Tenacious D (https://en.wikipedia.org/wiki/Tenacious_D) 05:03 - Managing People vs Servers * Establish Consistent Language and Shared Level of Understanding * Written Word * Following Up * User Manual (Persona Investigation) * Consensus Algorithms: Single Sources of Truth & Responsibility * Independent Failures: Build and Establish Trust * Conway's Law (https://en.wikipedia.org/wiki/Conway%27s_law) * Somathesis – Collective Problem Solving: Music, Science, Software - Jessica Kerr (https://www.youtube.com/watch?v=3_VHsrz0kfc) * Reliability & Uptime Reflections: John: Meeting minutes and clear communication is a form of active listening. Mae: Thinking about trust in terms of reliability and uptime. Arpit: Collective Problem Solving: Music, Science, Software - Jessica Kerr (https://www.youtube.com/watch?v=3_VHsrz0kfc) Mandy: Tenacity. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: Coming Soon! Special Guest: Arpit Mohan.

02:28 - Kerri's Superpower: Having an Iron Butt * The Iron Butt Association (https://www.ironbutt.org/) 06:39 - On The Road Entertainment * FM Radio * Country Music * Community/Local Radio * Roadside Attractions * The World Largest Ball of Twine (http://www.kansastravel.org/balloftwine.htm) * Mystery Spot (https://en.wikipedia.org/wiki/Mystery_Spot) * Mystery Spot Polka (https://www.youtube.com/watch?v=VYHiGQiAPhI) 15:11 - Souvenir Collection & Photography * Fireweed Ice Cream (https://www.wildscoops.com/post/2018/08/28/botany-of-ice-cream-fireweed-chamerion-angustifolium) * Clubvan (https://www.google.com/search?q=clubvan&tbm=isch&ved=2ahUKEwjCk7zdiJn2AhXIFFkFHfvjC-kQ2-cCegQIABAA&oq=clubvan&gs_lcp=CgNpbWcQAzIHCCMQ7wMQJzIHCCMQ7wMQJzIFCAAQgAQyBQgAEIAEMgYIABAFEB4yBggAEAoQGDIECAAQGDIGCAAQChAYMgYIABAKEBgyBggAEAoQGFCMB1iMB2CUDGgAcAB4AIABS4gBjQGSAQEymAEAoAEBqgELZ3dzLXdpei1pbWfAAQE&sclient=img&ei=rNsXYsKNB8ip5NoP-8evyA4&bih=748&biw=906) * Lighthouses * National Parks 25:42 - Working On The Road 27:37 - Rallies, Competitive Scavenger Hunts * Traveling Salesman Problem (https://en.wikipedia.org/wiki/Travelling_salesman_problem) 30:40 - Tracking, Tooling, Databases * Penny Machine Locations (http://209.221.138.252/AreaList.aspx) * Penny Costs 1.76 Cents to Make in 2020 (https://www.coinnews.net/2021/02/23/penny-costs-1-76-cents-to-make-in-2020-nickel-costs-7-42-cents-us-mint-realizes-549-9m-in-seigniorage/#:~:text=Penny%20Costs%201.76%20Cents%20to%20Make%20in%202020%2C%20Nickel%20Costs,Realizes%20%24549.9M%20in%20Seigniorage&text=The%20cost%20for%20manufacturing%20U.S.,in%20its%202020%20Annual%20Report) 35:36 - Community Interaction; Sampling Local Specialties * Cinnamon Rolls * Salem Sue, World's Largest Holstein (https://www.roadsideamerica.com/story/2716) 38:40 - Recording Adventures * Kerri's Blog: Motozor (http://motozor.com/) * Stationary & Sassy (https://anchor.fm/stationary-and-sassy) (Jamey's Podcast) 41:46 - Focus / Music * Bandcamp (https://bandcamp.com/) * Steely Dan (https://en.wikipedia.org/wiki/Steely_Dan) * Neil Peart (https://en.wikipedia.org/wiki/Neil_Peart) (Rush) 42:22 - Directed Riding vs Wandering/Drifting Reflections: Mandy: Taking time to enjoy yourself is SO important. Jamey: Get started! Create a map, now. Coraline: Permission to go down rabbit holes: wander aimlessly, and explore. Aaron: If I'm not having fun, why am I doing this? Resetting expectations to your purpose. Chelsea: Making “it didn't always look like this!” stories accessible to folks. Kerri: It's a marathon. You can't do a lot of things in a single step. We have traveled far from where we began. Greater Than Code Episode 072: Story Time with Kerri Miller (https://www.greaterthancode.com/story-time) This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: CORALINE: Hey, everybody and welcome to Episode 273 of Greater Than Code. You may remember me, my name is Coraline and I'm very, very happy to be with y'all today and to be with my friend, Jamey Hampton. JAMEY: Thanks, Coraline. I'm also excited to introduce my good friend, Aaron Aldrich, and it's our first time co-hosting together so I'm excited about that, too. AARON: Oh, Hey, it's me, Aaron Aldrich. I'm also excited. I'm so excited to host with all these people and I will introduce you to Chelsea. CHELSEA: Him folks. I'm Chelsea Troy and I am pleased to introduce Mandy Moore. MANDY: Hey, everybody. It's Mandy. And today, I am here with one of my favorite people! It's Kerri Miller, and you may know Kerri as an engineer, a glass artist, a public speaker, a motorcyclist, and a lackwit gadabout based in the Pacific Northwest. Generally, she's on an epic adventure on her motorcycle somewhere in North America. Will she meet Sasquatch? That's what I want to know and that's why she's here today because we're not going to talk about tech, or code today. We're going to catch up with Kerri. If you're not following Kerri on these epic adventures, you need to be because I live vicariously through her all the time and you need to, too. Kerri is a prime example of living your best life. So without further ado, Kerri, how are you?! KERRI: Oh my gosh. With an intro like that, how can I be anything but amazing today? Can I just hire you, Mandy just to call me every morning and tell me how exciting I am? MANDY: Absolutely. [laughter] KERRI: No. I'm doing really, really well. The sun actually came out today in the Pacific Northwest. I've been telling people lately that if you want to know what living in Seattle is like, first go stand in the shower for about 4 months [laughs] and then get back to me. So to have the sun bright and it's 53 outside, it's amazing. AARON: 53 does sound amazing. It's been like so far below freezing for so long here that I've lost track. Every once in a while, I go outside and it's like 30 and I'm like, “Oh, this is nice!” [laughter] JAMEY: Are we going to ask Kerri the superpower question? Because I feel like she's come on and answered it a bunch of times already. [laughs] We could ask her about Sasquatch instead. MANDY: I mean, I thought her superpowers were having epicly awesome adventures, but maybe she has a different answer. KERRI: Well, in the context of this conversation, I think that my superpower is being able to sit on a motorcycle for ridiculously long amounts of time. CORALINE: Kerri, would you say you have an iron butt? Is that what you call that? KERRI: Yes. I mean, of course, the joke being that I belong to a group called the Iron Butt Association, which is dedicated to promoting the safe and sane practice of long-distance endurance motorcycle riding. So the only requirement to join, besides having the defective gene that makes you want to sit on a motorcycle for hours and hours on end, is to be able to ride a 1,000 miles on a motorcycle in 24 hours, which once you do it once, you very quickly decide if you ever want to do it again and if you do decide you want to do it again, you are one of the ingroup. AARON: What's a reference point for a 1,000 miles? That's a number that I only know conceptually. KERRI: Let's see. It is a 1,000 miles almost exactly from Seattle to Anaheim to the front door of Disneyland. It's a 1,100 miles from Boston to Jacksonville, Florida. CORALINE: Oh, wow. KERRI: It's 2,000 miles from my house in Seattle to Chicago. JAMEY: What made you feel like you wanted to sit on a motorcycle for that long? KERRI: I don't really have a short answer for that, but I'll give you an honest answer. I mean the short answer is the jokey one to say, “Oh, I've got a defective gene. Ha, ha, ha.” But when I was in – I grew up in the country and had a lot of a lot of struggles as a teenager and the way that I escaped from that was to go get in my car and drive around the back roads of New England. Dirt roads, finding old farmsteads and farm fields and abandoned logging roads and that gave me this real sort of sense of freedom. When I moved out to Pacific Northwest—no real friends, no family out here—I spent a lot of time in my car exploring Pacific Northwest. I had a lot of those same vibes of being by myself and listening to my good music and just driving around late nights. When I got into to motorcycling, I rediscovered that joy of being by myself, exploring things, seeing new things, and if I wasn't seeing something new, I was seeing how had changed this week, or since last month, or since last few years since I've been through a particular region. And my motorcycling is basically an extension of that, it's this sort of urge to travel. A desire to be by myself under my own control, my own power, and to learn and discover new stories that I'm not learning just by sitting in my apartment all day. I work from home. I've worked remotely for 8, or 9 years now, so anytime I get to leave the apartment is a joy and adventure, but doing so for longest ended periods of time just lets me see more of the world, expand my own story, and learn the story of others as I travel. Being a single solo lady on a motorcycle, I'm instantly the object of interest wherever I stop and it doesn't help that I have rainbow stickers and all sorts of stuff all over my bikes. My motorcycle helmets are crazy pink, rainbow reflective, got unicorn horns, and things all over my bike, so people see me as being super approachable. Every time I stop for gas, or to get a burger, or a soda, or something, people come up to me and they want to tell me their stories. It's usually about the motorcycle, they're really interested about. It's usually middle aged and old men come up to me to say, “Oh, I had a motorcycle when I was in college and then I got married and had a kid.” You can kind of see them deflate a little bit. Or I've had lots of kids come up because it's covered with stickers and a lot of the stickers, they're all kind of at a kid eye level. They see them and they get really excited, they want to come over and talk to me. With rainbow bandanas and everything, I think I look safe as a biker. I'm not dressed in black and skulls and so, people see me as approachable and they want to come up and talk. So there's a lot of those great interactions that I get to have with people along the way. CORALINE: And you said at the beginning, when you were driving around the Pacific Northwest, you were listening to your good music. Do you also listen to music on the motorcycle and some of those have fancy speakers in the helmet and all that sort of stuff where you just go quiet and just listen to the road? KERRI: Honestly, over the course of the day, because I will ride 18, 20 hours a day if you just let me go and if I'm trying to make distance, I'll do that. It's kind of a mix, but for the most part, I actually do listen to something. The last few years, I've really embraced and tried to understand and integrate into my personal identity, having ADHD and how does that manifest for me and I found that if I'm riding my motorcycle and I'm not listening to something, my mind wanders. But weirdly, if I'm listening to something, then I'm paying attention and focused, patrolling the motorcycle and being safe and then whatnot, which seems paradoxical. But that's just how my brain works. So I pretty much always have something going. Until recently, I had a Spotify playlist with about 1,800 songs on it that was rotating through. I tried to do audiobooks and podcasts, but that's a little tricky with all the wind noise and whatnot. I'm trying to protect my hearing. Other than that, I also listen to a lot of FM radio, which is great. So I have opinions on country music now, which I never thought I was going to have opinions on that at before. Yes, country music is great. It's all over. Even in Seattle, we have country music, bars, and whatnot, but you don't just walk down the street in Seattle and hear country music. You've got to kind of seek it out and so, I haven't been exposed to it. So listen to a lot of FM country as I cross the vast planes of America and I've also used that to discover a lot of this rebirth that's happened in the last decade of community radio. A lot of small communities have their own low power, super local FM radio you can only pick up for 20 miles at a stretch. So if I'm passing through a town and I see a sign for K, B, C, or whatever it is for some small town, I immediately tune to it. it's always somebody who's just like, they're not a trained professional. They never went to broadcasting school. They don't have that trained radio voice. They're just talking about sheep that got out, or here's a problem with the town water supply, or whatever it is, what local road is closed. That's just an amazing way of even as I'm passing through a place, if I'm not stopping, I kind of get a little bit of a flavor for that. AARON: Well, just thinking that FM radios generally got to give you more of a flavor for the local area that you're at. I always thought of that as the frustration of FM radio when traveling, like, “All my radio stations keep changing. I don't know where to tune!” But at the same time, that's pretty cool. I love that as a positive of what do they listen to over here? What do they listen to over this part of the country? I would imagine even just where different musical genres are on the dial would probably shift around. Or maybe not. Maybe that's just my…coming up with things, but. KERRI: Yeah. You do learn that there are some patterns, like all of the NPR stations, they're all down in the 800s and also, a lot of the religious radio and the top end of the dial seems to be a lot of rock. The big rock stations seem like 107, whatever the end, or something. The best ones, though are the ones that have local commercials because you get a lot of the same like, law firms and drugs that I don't know if I have even the condition, but I should really talk to my doctor, see if it's right for me. But then you'll get local car places, or I got one when I was down south, somewhere in Louisiana and it was for a combination, an airboat rental and barbecue joint? It was amazing. It was absolutely amazing and the guy had this amazing regional accent, which I never hear up here in the Northwest. We have our own accent, but I got a little taste of this real Southern accent and it was the owner. It was clearly the owner just reading a little script that he wrote, “Come on down and rent a jet boat, bring your dog and your dog can go on it and then we'll have barbecue waiting for you when we get off the dock,” and I'm like, “I'm sold.” Like, “I'm going to turn around, go see this guy right now. This is amazing,” and I actually have that business. I keep a map of every interesting place I hear about as I travel and I put a pin there I'm like, “Someday, I'm going to be coming back by this place and I'm going to be hungry for lunch and I'm going to stop. I'm going to stop here.” So advertising works, I guess, is what I'm saying. JAMEY: Will you share that map with us? [laughter] KERRI: I really should. I really should. It's a lot of fun actually because you read these websites, or roadside attractions, or you hear about some abandoned theme park, or something and it's like, that's kind of a cool thing. You read the article and you move on your day, but I add it to my maps and those maps are my GPS unit. As I'm writing, I've got this old screen in front of me and if I see a little pin appearing on the map in front of me, I can say, “Oh, there's this old waterpark over here,” or “Oh, there's that resort over there that I always wanted to see,” or a particular weird statue, or the birthplace of James Kirk, or whatever it is. So I don't have to remember if the computer could do it for me. JAMEY: I was going to ask if you go to things like the world's largest ball of twine and like –? KERRI: Every time. JAMEY: Okay, cool. KERRI: Every time. JAMEY: I'm glad that I understand you enough to know that you would do that. [laughter] CORALINE: Kerri, have you been in the Mystery Spot? KERRI: I have been in Mystery Spot. MANDY: What is Mystery Spot?! CORALINE: I remember Mystery Spot is some kind of a place where they say gravity is out of whack and everything feels sideways and you're super disoriented. They have this whole mythology around it. I've never been myself, but I did pretend that I'd been there by putting a bumper sticker on my car 15 years ago. [laughter] There's this amazing song called Mystery Spot Polka. Can't remember where I read that, but I think that's how I learned about it. MANDY: I will put that in the show notes. CORALINE: I will find Mystery Spot Polka. It is incredible. MANDY: So Kerri, what are some of the coolest places you have visited? Can you give us a top three rundown? CORALINE: And I really hope that cracker barrel is in that top three, Kerri. JAMEY: But which cracker barrel? CORALINE: Oh, cracker barrels are the same everywhere you go. I really believe there's only actually one cracker barrel, the canonical cracker barrel, and it's multidimensional, so. JAMEY: Yeah. You teleport into it? CORALINE: Yeah. [laughter] KERRI: Well, interestingly enough, I won't call this a danger, but one of the side effects of traveling as much I have in the last 4, or 5 years is strange, random flashbacks to stretches of road and you can't remember where they are. So you were just asking about this and I'm thinking about, “Okay, two places I could talk about,” and then I suddenly, unbidden, had this memory of a stretch of road. I can't remember where that is. I don't even know what state that's in. It was an amazing piece of pavement that I really enjoyed riding and, in that moment, I had this amazing moment. If I skip way ahead to the end of the conversation where I sum everything up and tell you why I ride, or what I get out of doing this is that it's cemented for me, this concept of the impermanence of everything because if I'm having a great day on the bike, it's beautiful afternoon, the temperature's perfect. It's not going to last. The sun is going to go down, the pavement is going to be bad, traffic is going to pick up, it's going to start raining. So I need to enjoy this moment, this curve, this hour, this half hour, this 5 minutes, whatever it is. Something, conversely, if it's bad, if it's raining, or it's dark, or heck, if it's snowing, it's like, this is not going to last. I'll go through this and everything will be great. But once every six weeks, or so, I make a really bad decision on the motorcycle, for instance, like that rain's probably going to clear up, that's not going to be a rainstorm. Nah, this wind is going to die down, it'll be fine. I'll be riding through something and it makes me just completely miserable. 110 degrees, or sideways rain, or whatever, and I think, “Yes, this is it. This is the moment. This is the thing that I'm going to be remembered for. This is the dumb thing that I did,” but it never lasts. I always survive and I walk away with this just amazing memory and this amazing about that time I rode through a rainstorm, or illegally parked my motorcycle in front of the Alamo to just get a photo, [laughs] things like that if it happened. CHELSEA: Kerri, do you collect souvenirs of any kind from some of these travels, or is it specifically photos? Do you post about them specifically anywhere? Maybe you do a whole bunch of things. I've certainly seen a number of your posts, but I guess I'm wondering, I'm imagining myself in these situations collecting stickers, or something like that. Do you have things like that that you look for in these places? KERRI: One of the neat things that I enjoy about traveling my motorcycle is that I just simply can't, I can't buy anything. It's not any space for it. My gear is all pretty well packed tightly. Souvenirs are kind of out unless I'm willing to pay extra ship from home. So it's kind of rare. Although, I have occasionally gotten, if I know that I'm going to be visiting a friend in a day, or two, I'll stop and pick something up and usually, it's a food item that I haven't seen before. In fact, if you follow me on Twitter, you'll see I'm always posting about weird foods, or energy drinks. 90% of the time it's weird stuff I found in a weird gas station on the side of the road, especially when it comes to energy drinks. And it's much more about having that experience of a place at the end of the day. I don't take as many photos as I'd like, or I think that I should. Although, certainly, I do take more than I used to. I've been working on landscape photography with my iPhone because again, I choose not to travel with a full camera rig. Well, I've got my iPhone, how can I take photos with that? That turns out to be much more about composition and seeing a moment and grabbing it than having the right lens, or light conditions being just right, or whatever. CHELSEA: Ooh. So I'd be very interested to hear some of your tips for phone photography, because this is a thing. We all have our phones on us and I imagine if I just a little more about how to frame my photos sometimes, I could get something a lot better. KERRI: Some of the basic tips are just photography one-on-one, like how do you compose a shot in terms of the rule of three where you break it up, and you'll see in phones, a lot of times you have the option turn on a grid. So you're looking at a grid and then help you understand how much space something is going to take up in the final shot. You want to line up your horizon, for example, if I'm taking a picture of say, like a harbor. I've taken a lot of photos of lighthouses for reasons I can get into later. So I'm trying to take really nice photos of lighthouses, the sea kind of wants to be right around and take up the lower third of the shot and then two-thirds is the sky. It's about how much of the frame gets filled with different elements will psychologically suggest the viewer, what their importance is, or how they relate to the person who's taken the photograph. So just some basic rules around that. I try to do things where, especially when doing landscape photography, because the iPhone lens is just horrible for this. It's really meant to take photos of your friends at parties, or your car in the driveway. It's not meant to take landscaping vistas, but you can do some tricks. Actually, I found that zooming in a little bit, not a lot, but just a little tiny bit just brings it a little bit closer and the final result just feels a little different. And then if also, you continue to follow those rules of composition, you can get some good landscape. Putting something in the foreground is really great. So my motorcycle is in a lot of my shots because of that, because it gives some depth to the photo. It helps to not just be like, especially if you're doing a wide-open plane like you do, it's like, oh yes, here's some bars of color. It's like, oh, now here's something to give me perspective and humanize the scale of a landscape. It's just little things like that and that's all stuff that I've learn just because I'm just a naturally curious person. So I'm like, “Well, how do I take better photos of that?” So I went off and did 4 hours of research and audited a class online somewhere. CORALINE: Have all, or most of your travels been continental US, or have you ever gone on a motorcycle trip on another continent, or? KERRI: It depends. Is New Zealand a continent? JAMEY: Well, it's not in the continental US. [laughs] KERRI: Yes. Starting closer to home, though. North America, I've done. So I've done US, Mexico, and Canada. Right when COVID hit, I was actually in Baja, California down at the Southern tip at the Tropic of Cancer on my motorcycle. I rode there all the way from Long Beach, California and I've been up to Alaska through Canada twice now. JAMEY: I'm sorry. I was going to tell a Jerri Alaska story actually, because I was in Alaska – [overtalk] KERRI: Oh, please. JAMEY: Not too long ago and I posted a landscape photo from our rental car on Twitter and I did not label where I was and Kerri was like, “Where are you in Alaska?!” And then we were talking about this and she recommended that I eat fireweed ice cream, which I did and it was wonderful. KERRI: Oh, was it great? JAMEY: [laughs] It was great. So I was going to suggest that your superpower could be recommendations. KERRI: Oh, thank you. That's super flattering, actually. I sometimes think when I finally get tired of tech, I just want to be a tour guide, or something, or write a travel novel, or something. JAMEY: Oh yeah. You'd be great at that. KERRI: Yeah. I love being a hostess and I love – whenever somebody's like, “Oh, I'm traveling,” or “I'm going here,” or I see somebody post photos from someplace I've been, I'm like, “Wait, here's this restaurant, you should go here and make sure you talk to this person and do this.” A year after I got my first bike, no, not even a year. Oh my gosh, it was 5 months after I got my first motorcycle, I went to New Zealand for a conference and said, “Well, hassle in traveling to New Zealand is actually traveling to New Zealand. So I might as well take some time.” I took two weeks and rented a motorcycle and just did a couple thousand kilometers all over the South Island in New Zealand. So those are the four countries I've ridden in. I was going to rent one – I'd been to Berlin a few times and I thought, “Oh, I'll rent a BMW when I'm in Germany, that'd be cool and ride around.” But unfortunately, I got sick while I was in Germany, the one time I was going to do that. So I stayed my hotel and felt bad. JAMEY: How different is motorcycle on the other side of the road in New Zealand? [chuckles] KERRI: I only rode on the wrong side of the road twice. [laughter] Yeah, the shop I rented from actually, they rent to a lot of Americans, I guess. So they put arrows on the windscreen to say, “Drive pass” to help remind us. But it's funny because every single rental car down there, the left side of the car is the one that's completely trashed because when you're riding, we start driving on the wrong side of the road. The side you're not used to. Now, it's like your entire concept as a driver of the opposite side of the car is now completely inverted and so, it's like trying to do something with your left hand when you're right-handed. It's just like, how do left-handed people survive?! Like, what are you doing? [laughs] CORALINE: I was in South Africa a number of years ago and we drove out to this wildlife preserve and the only car I was able a rental, that was not a stick shift because I don't know how to drive stick shift, [chuckles] was this giant club van. So not only I had driven the wrong side of the road, but I was in the largest vehicle I had ever driven. [laughs] Had no idea where the other side of the car might be was, just terrified of exactly that the whole time. KERRI: See, you called it a Clubvan, but all I can imagine, the image that popped in my brain was a party bus. [laughter] So imagine you driving around South Africa in a party bus. [laughter] CORALINE: That would have been amazing. Yeah. KERRI: Very different trip. AARON: I just want to bring it back to lighthouse pictures because as a native New Englander, I need to know why you're taking pictures of all these lighthouses. KERRI: Well, as another native New Englander, hi. AARON: Hi. KERRI: How are you? [laughter] No. So why am I taking photos of lighthouses? One of the things about the Iron Butt Association, which again, is this group dedicated to promoting this, is not just the pure endurance of can you ride a 1,000 miles in 24 hours? Can you ride 1,500 miles in 24 hours? What are the limits of safe endurance events? We also do a number of collection style things. We call them tours. I'm doing a lighthouse tour. So you go to lighthouses and I've got this little passport, my lighthouse passport I got from the United States Lighthouse Society. When they're open, you can get a little rubberstamp in your book to prove that you were there. When they're not open, I take a photo of my motorcycle next to the lighthouse and that's the proof that I've been there. The challenge is I have to visit 60 in 12 months. AARON: Okay. KERRI: And that's the bare minimum. So there's advancing levels of difficulty and they're merit badges for adults, really. [laughter] 60 in 12 months I'm at 25, or 30 now and I scoured the West Coast. I'm going to also hit the Gulf Coast and the Atlantic next month when I'm down there in Florida. There are other challenges like go to 120, or 180 again, over the course of different time periods. You have different difficulty levels. I've also done one which is visiting national parks because national parks have a similar passports stamp program where you can go get these timestamped little cancellations to say I was in the Redwood National Forest, or I was at Wounded Knee, or not Wounded Knee, Little Bighorn, or Devils Tower, or whatever. The challenge there is to visit say, 50 of them, but now you have to do 25 different states. Of course, I've upped the ante and we have the silver level, which is you also have to combine that visiting one park in Washington, California, Florida, and Maine, in addition to those 50 and 25 states. So I did two of those last year and then year before that, I added Alaska just for fun, which is the gold, or insanity level. So it's just these little different ways of encouraging people to go out and travel and see more in the country on their motorcycle. CORALINE: You work from the road, right? KERRI: Yeah, I do actually. CORALINE: I would love hear about how that works with such an aggressive travel schedule. KERRI: That takes a lot of discipline and balance, which I am surprised I managed to pull off [chuckles] given how much I can normally do it without adding to traveling. Usually, what I do is I have days where I am in one place and days when I'm traveling. So for example, on February 28th, I'm going to be heading out for 2 months on the road and my first stops going to be San Diego. I will take that weekend and ride down to San Diego, which again, only 1,300 miles so that's a day and I've rented a little place down in Ocean Beach, a block from the shore and they have Wi-Fi in this little tiny one-bedroom studio. I'll work there and I'll kind of explore San Diego. I'll work all day and, in the evenings, I'll go over ride on the hills, or go up to Legoland, or whatever I want to do in that part of the world. And then Friday night, Saturday, I'll hit the road again for a couple days. This is actually how I initially started traveling these long, long distances was trying to say like, “Okay, I really want to go to Austin, Texas, but it's going to take me four riding days, or whatever to get to Austin, Texas. How do I manage do that and still work from the road?” So well, 2 days away is Denver, Colorado. So why don't I go to Denver? I'll work there for a few days and then next weekend, then I'll skip on. So it's like setting up a series of base camps as if I was attacking Everest so I can break up these big trips. But as I wanted to travel further and further distances overall, I had to actually physically travel, or do longer distances in the same amount of time. Speeding isn't going to do that safely and it actually really doesn't get you there that much faster in the end. So the only way to do that was to figure out how to ride longer more hours in the day, figure that out. JAMEY: Can you talk about these motorcycle scavenger hunt things that you do? KERRI: Yeah. Thanks for asking. I assume you noticed the trophies on the wall behind me. So these are competitive scavenger hunt style rallies. We call them rallies. A lot of people, when you say motorcycle rally, they think about Bike Week in Daytona, or Sturgis out in South Dakota. That's none of this. It is a scavenger hunt and there's a timer on it say, 36, or 60 hours where the night before you get a list of here's all the different places that you could possibly go, you call them bonus locations and at 4:00 in the morning, everyone's released and you're like, “Okay, go, be back in a day and a half.” You go and you take photos of these different places to prove that you went there and every place gets you a certain number of points. The harder it is to get there, or the further away it is, the more points that you would get for going there. You can do combinations for visiting certain places, visit three clown theme places and get the clown bonus, or whatnot. Like a pinball machine, if you will, where you score the right combination, you get more points. So it's a timed competitive thing to who can the most amount of points because you can't visit all of the – they'll give you 80, or a 100 places you could possibly go. You can't go to all of them in the time allotted. So can you construct an efficient route that is also one that you have that you the physical capability to travel in the allotted time and earn enough points to place well? They typically last, 36 hours is one level. We have a few that do 60. I'm doing one this summer that is 9 days long. So we'll be leaving Cheyenne, Wyoming and four days later, we have to be in State College, Pennsylvania where we'll all stop for 10 hours and then we'll turn around and head back to Cheyenne. I actually just put in my application for the Olympics of the Iron Butt Association is called the Iron Butt Rally, which is an 11-day version of the countrywide scavenger hunt – [overtalk] CORALINE: Oh, wow. KERRI: With locations all over North America and Canada. We call it, it's sort of the Olympics. It happens every 2 years. You actually have to apply to be accepted to enter because otherwise, you'd have a lot of folks that say, “Oh, I could do that,” and they don't really know what they're getting into and it's a little bit unsafe if you haven't done it before and you don't really understand what it takes to do. That's what's coming up my horizon for those and they're very competitive events, although at the end of the day, it's made-up internet points. There are no sponsorships, there's no recognition besides outside of this group of 300, or 400 similarly weirdo people who like riding their motorcycles longways. But no, I've had quite a bit of success competitively in that and that just scratch all the right itches because it's riding a motorcycle. Plus, it's basically a traveling salesman problem. It's a directed graph problem and you work with GitHub all day long and like, “Oh, I understand how to traverse a graph, this is easy.” CORALINE: Speaking of that, Kerri as a long-time software engineer, do you do anything, do you have any software, any kind of tools that you develop for keeping track of all this? KERRI: Yeah, I do a lot with spreadsheets, believe it, or not. The tooling, it's tricky because at the end of the day, you still have to ride the motorcycle and you can't really automate that. So a lot of the stuff I'm able to do with software is really around using software for planning and analysis. For example, there's a number of different databases around you asked about the collection of the lighthouses and one of the things that I'm around the country collecting this year is pressed pennies. Now a pressed penny machine, actually I think they're fascinating because a pressed penny machine is the only machine still in active production that interacts with the penny in any way, shape, or form. There's no vending machines. There's nothing who deals with the penny besides coin counting machine. Besides the penny smasher, you put a penny, 2 quarters and it smashes a little design in. Again, I've got to go collect a 100 of these from 20 states and 5 of them have to be on the other side of the Mississippi, all these weird rules, but how do you find them? There's one at every cracker barrel. There's eight at Disney, one at SeaWorld. There's some obvious things like that, but it turns out, there's almost 4,000 of these machines in the United States and there's a database for these on this weird creaky, old website written in ASP. It's actually an IP address. It doesn't have a domain name. JAMEY: That's legit. CORALINE: Dark web got pennies. That's amazing. [laughter] KERRI: If only there was crypto involved here, it'd be perfect. So I got to break out some scripting the other day and actually write a little script that went into kind of scrape these old web pages and then parse CHTML and kind of strip out, look, here's the address for the place and store them because you want the name of the place and the address so you can find it. You've got to take that and ship it over to Google API, actually get an actual latitude, longitude, and then reform it into the XML format that my GPS device – it's this whole chain of Rube Goldberg machine of how to get this data into a place that I can actually use it. CORALINE: I think the story of the entire internet is made. [laughs] KERRI: Right. CORALINE: Yeah. KERRI: So fast forward to the end of that and now I happen to be the maintainer for a website that maps pressed penny machines across the United States, based on this data that I'm scraping from somebody else's website. AARON: All because you have a DNS name. KERRI: Exactly, exactly. But this actually turned to be really, really crucial because a whole bunch of people in my riding community said, “I really wanted to do that penny collecting hunt and you have 12 months to do it and I'm going to go out to the West Coast.” So I was like, I thought, “I have plenty of places to stop, but I could never find the machines.” It's just like, “Oh, okay. So my putting this information into a format that other people could actually easily digest, that's the value that I'm adding here.” It's inspired at least a dozen people to go out and start collecting smashed pennies. So I've got to be responsible for some uptick in sales on these vending machines. JAMEY: They should sponsor you. AARON: I love the weirdness of these machines that interact with a coin that's so bad at being currency, we just sort of toss them out to the extent that I was at Disney World not too long ago and the machines have their own supply of pennies because people just don't have pennies. So [chuckles] this machine just has a stock of pennies and you can swipe a credit card and be like, “Give me the smashed pennies,” and it charges you a dollar in 1 cent and then goes through and does it. KERRI: God, it's fabulous. A lot of people have heard the story that pennies are actually – it costs more to make a penny than a penny is actually worth in terms of currency. It's wild. But every time I start thinking, “We should get rid of the penny,” I'm like, “That sounds like the craziest, insane conspiracy theory position to ever take.” AARON: But also, the penny is real bad at being currency. [laughs] KERRI: Yeah. Yeah. MID-ROLL: And now a quick word from our sponsor. I hear people say the VPNs have a reputation for slowing down your internet speed, but not with NordVPN, because it's the fastest VPN in the world. I don't have to sacrifice internet speed for better security. With NordVPN, my internet traffic is routed through a secure encrypted tunnel, which protects my data and privacy. I can also have it on up to six devices like my laptop, phone, TV, iPad—all my devices are protected. Grab your exclusive NordVPN deal by going to nordvpn.com/gtc, or use the code GTC to get a huge discount on your NordVPN plan plus one additional month for free. Plus, a bonus gift! It's completely risk-free with Nord's 30-day money back guarantee. KERRI: Way back at the beginning of this conversation, somebody asked me and sorry, I forgot who asked me about some of the best places I've been and the strangest things I've seen. I kind of got derailed on some poet nonsense, but I realize that I really am a sucker for world's largest ball twine kinds of things. I had this great opportunity. So collecting pennies, lighthouses, and national parks, I'm always just getting off the main roads and things. I see a lot of stuff. I found out that I'm a sucker basically for weird local foods like the fireweed ice cream. Anytime I see something advertised on a menu that I've never heard of before, that's the thing I'm going to order. Cinnamon rolls because when you travel up the Alaskan highway from Dawson Creek, BC up to Alaska, every 60 miles, or so, there's a gas station and a little bakery. So you can get your gas, you can get coffee, and you can get a cinnamon roll and they all claim to have the best cinnamon roll on the Alaskan highway. I stop every 60 miles and get a cinnamon rolls. After about 5 hours, I really just want to fall over and vomit because I'm sick of cinnamon rolls. But now when I travel, if I see some place advertising cinnamon rolls, I'm like, “Well, I've got to stop because that's my thing because I like cinnamon rolls because that's reminds me of Alaska.” So I get to go to a lot of these really great small towns and just seeing a lot of how, especially in the central part of the country, so many towns are struggling with just having jobs for people and keeping local economies going that a lot of them will do these sorts of things. They'll have interesting, strange festivals, or hold the film festival about corn, or soy, or they'll paint their water tower, or something. Last year, as I was traveling across North Dakota one time, I saw off on the horizon on a hill—first of all, yes, a hill in North Dakota so that was notable—a giant cow. A giant Holstein cow. This a 100-foot-tall fiberglass cow and so, I said to my riding partner, I'm like, “We're going the cow, right?” And she's like, “Yeah, we're going the cow.” So get off the highway and we rode this little windy dirt road at the top of this hill. It was just this huge giant fiberglass cow that they put on top of the hill 20, 30 years ago and now it's like the 4-H Club with the FFA kids take care of it and repaint it every few years. They collect like, they ask for donations. $5 each and the little two because we're passing through and that's part of our job. That's how I'm interacting with the community and plus man, I got a ton of pictures of this giant cow. It was right at sunset, we were on this hill, and it was actually really beautiful, the prairie, it was spread out for us and it was about an hour east of Theodore Roosevelt National Park. So it's right where the planes start to break up into the what's called Missouri Breaks where the rivers have really broken up the land quite a bit. So it was just gorgeous. It was just absolutely beautiful and I never would've seen that if I didn't stop because there was a giant cow. That's my giant cow story. CORALINE: Kerri, have you ever considered writing down your stories and the stories of the people that you meet along the way and the amazing places you've been? I hate to say the B word, but it would make a pretty interesting book. KERRI: Well, I'll throw back another B word at you, which is blog. I keep a travel blog at motozor.com. Lately, I've been writing more about, because I haven't been doing as much non-directed travel, so a lot of my travel lately has been around these sort of competitive rallies that I've been riding in, which are interesting in themselves because they're like, “Go take your photo with the giant cow,” or “Go to the Clown Motel in Tonopah, Nevada, or whatnot, take a photo there.” I've been writing quite a bit about those sorts of travels, but I also have a huge backlog of articles that I've written for that over the years of all the different trips I've taken to New Zealand, Alaska down into Baja, and the multiple times I've been across the country. The one that I'm working on, that I haven't finished yet because I'm trying a new thing, which is incorporating a series of interview video interviews with my riding partner, is trying to tell the story in written form of the trip that she and I did last summer, where we rode to all 48 states in 10 days starting in New England ending in Washington. JAMEY: Kerri, I have an important question to ask you, but I'm contractually obligated to ask you. How many miles at a time would you say that you live your life? [laughs] KERRI: Well, I guess, I supposed to say one quarter of a mile at a time. [chuckles] JAMEY: Well, Kerri was also a guest on my Greater Than Code spinoff, fast and furious show, Stationary & Sassy, so. KERRI: Which I love. JAMEY: I had to pull it back. [laughs] KERRI: I'll answer that in an obliviously serious way. [laughter] I can go an entire take of gas without putting my foot down. That's kind of fun. One of my current challenges right now is can I ride through the entire state of Oregon, north to south, without getting gas? Because it's 304 miles from the Washington-Oregon border to the California-Oregon border and Oregon doesn't let you pump your own gas and it irritates me. They usually, if they see you're on a motorcycle, they're like, “You got it?” I'm like, “Yeah, I got it. I'm not from here. I pump gas.” So the challenge right now is can I cross Oregon without having to stop for gas and then actually weirdly, mentally breaks up my day. It's kind of weird motorcycle Pomodoro of like, “Okay, I can go 3 hours before I need to stop.” So my day gets broken up into these chunks of where are the stops that I have to make versus the ones I want to make, or excuse me, the ones I want to make versus the ones I have to make. JAMEY: You heard it here, folks. Kerri lives her life 304 miles at a time. [laughter] KERRI: I live my life a quarter tank at a time. [laughter] CHELSEA: Kerri, you mentioned earlier that you listen to music while you're riding because you find that it helps you focus on riding. I find a similar thing with work, whether it's fulltime job work, or side work, I have a much easier time focusing—for the audience, I'm a programmer as well—if I've got something on. I like to listen to Boston Nova, or I also go on turntable.fm, I'm in a heavy metal room there that's kind of fun. I'm curious as to whether you find that music helps you focus anywhere off the motorcycle as well. KERRI: Yes. I am very susceptible to the emotional resonance of music, if that makes any sense whatsoever. There are kinds of music that I just can't listen to before I go to bed, like heavy metal gets me going, jam music. I'm a really huge Phish fan, which surprise, from Vermont, and I wear a lot of tie dye. Of course, I'm in the Phish. But that's the music I like to listen to when I'm riding and when I'm working. But I do a lot of chill hop stuff now. I've gotten into that and I'm finding my way back to a lot of again, country music. But there's this entire alt Nashville scene that's happened in the last 10 years. I completely missed that. I'm kind of getting caught up on these days. My Bandcamp catalog, I think I'm keeping at least three of their engineers paid for; I buy so much stuff on Bandcamp these days. CORALINE: I definitely get what you said about sensitivity to the emotional music definitely resonates with me as a musician. It's kind of weird to admit, but when I'm doing writing, I listen to Steely Dan [laughs] and I actually learned from a friend of mine that William Gibson listened to Steely Dan while he was writing all the seminal cyberpunk novels and thought that's kind of interesting, maybe good company, right? KERRI: Hey, Fagen and Becker, great albums. It's the stereotypical thing that Rush is this big band in programming circles and fun fact, the drummer for Rush was a huge motorcycle guy to the point that they actually had a trailer on their tour bus that he would carry two bikes on the trailer. So he would ride between concert stops. The band do their show and they'd leave on the bus and he got on his motorcycle and like, “See you in Chicago, guys,” “See you in Milwaukee,” “See you in Madison.” The band went along. He had some personal and his wife passed away and his daughter fairly tragically and he wrote an entire book about it, where he didn't really quit the band. Although, they basically shut Rush down for a period of time so the band could work through that. But he took that time and went on the road just writing his motorcycle around. He wrote several books about dealing with grief through riding his motorcycle. I found that to be a really fascinating book and it's one of those touchstones, the Canada motorcycle riders. What little we read, that's definitely a book that everyone recommends to me at some point like, “Oh, have you read this book?” I'm like, “Yes, I've read that book.” AARON: It's Neil Peart for anyone who needs to look that up. I relate to the music as a distraction preventative [laughs] as someone who also deals with ADHD. It just makes sense to me. It's like, “Oh yeah, without it, there's so many places for my brain to go,” but if you have music on the back and it's like, “Oh, great. All right. That's where my brain is going to go when it gets distracted, it's just going to listen to this, then I'll go back to riding the bike.” [chuckles] KERRI: Exactly. Exactly. CORALINE: Kerri, you said a word earlier when you were contrasting the way you were riding when you started out and being kind of exploratory versus, I think the word you used is directive there, or a sweet spot for you between directed activity, directed riding versus wandering, maybe even drifting—not a car movie reference. But is there a balance that rejuvenates you, or that energizes you? KERRI: Yes. I've talked to other motorcycle riders about this, where you say, “My gosh, there's so many great things that we see along the way,” and we say, “I would love to stop here.” So for example, when we're doing these rallies where we're collecting things, for example, you stop to take a picture, or something, and then you've got to go. You only really stop for 5 minutes because you have this timetable and a schedule that you're trying to execute, or if you're trying to ride 1,500 miles in 24 hours, you can't stop. Your gas stops, you're timed down to like oh, 5 minutes. So you'll see things. You're like, “Man, I wish I could stop,” or “I wish I had come back here and take this in and give something,” the respect that you want to give it, or really, really dive deep and taste a place, if you will. It's a really common thing in the long-distance thing. Other motorcycles will sometimes say like, “Well, you don't see anything that way.” It's like, “Well, actually, I see a lot. I see way lot more in my days than you see,” but you don't get to stop so you have to kind of try and balance that. That's one thing that I really like about these collection things that I do is, collection challenges, I carry satellite tracker, of course so I can plot out everywhere that I've been. I've been looking at the one for my lighthouse trip so far up and down the West Coast. It's just amazing, I'm going out to every little inlet, point, and little peninsula sticks out into the ocean because that's where the lighthouses are and the things that I've gotten to see through doing that. So one of the reasons that I've gotten into those sort of challenges rather than the pure and endurance is just because it does reward that exploration. While, at the same time, being fairly directed because the directed part of it is researching and planning at home, like finding where are the lighthouses, where are the national parks I need to go visit? What are the hours are things open? Making that plan versus executing on the plan and the execution plan, getting to explore things, I think it's really a lot about the framing of the trip for me. In February, I'm going down to San Diego and then I'm going to, what's called a 50cc, which is coast to coast in 50 hours. So I'll be leading San Diego and within 50 hours, I'm going to be in Jacksonville Beach, Florida. Aha. Somehow, I'll do that. I'm not going to be able to stop and see anything along the way, but because I know that's the kind ride I'm embarking on, it becomes okay. It's this weird personal permission structure to give a pass to things that I would really like to see along the way versus say, if I'm doing a lighthouse trip – I did one several months ago down to Disneyland, but I went down the California coast and I found myself like, “Oh, I'm not making any miles. This is so slow. Why is this taking me 3 days to get down to Los Angeles when it normally takes me 1 and a half at most?” So I had to stop and I ended up stopping in this little tiny town. I can't even remember the name of the place, but it's somewhere in Northern coast, California, and there's a little tiny coffee shop there. It's like Two Girls Coffee, or something like that. I just stopped, I got a coffee, and I sat outside. They had a table, it was a nice day, and I was just like, “I'm just going to sit here for 30 minutes and I'm just going to recenter myself and really think about what am I doing here? What do I want to be accomplishing and what set of skills do I need to bring to this moment to maximize how much fun I'm going to have? If I'm not having fun, then why am I doing it?” So just being able to sit there in sunshine for a little bit and just say, “The point of what I'm doing here is to explore and it's to have this experience. It's not get someplace fast. It's not to get someplace far away. It's to explore and see things.” I was so much happier after that and I had a great conversation with a hippie in the parking lot so that was pretty great. MANDY: Bonus. [laughs] Well, we usually end this conversation with reflections. I know, for me, I just want to say that everything you described just makes me feel so happy. I've been on a really big journey to improve my life and just what you said in the last few minutes about just taking time to enjoy, not being in a hurry, slowing down, and recentering yourself. That is all just so important to remember the whole cliché of stopping and smelling the roses. Like just enjoying your life even if it's a quarter tank at a time. JAMEY: I keep thinking about this map that Kerri says that she has, which I actually legitimately would really like to see. But a lot of what Kerri was talking about was resonating with me. I also like to explore and I think about keeping track of places, but I don't have a map and I've been thinking about it for a while. I think it's one of these sunk cost things where I'm like, “Well, if I wanted to do a map, I should have been like doing it already,” but that's not how that works in real life. So if I want to have a map, I should start it now and I think that's my call-to-action. [chuckles] KERRI: When people ask my advice like, “Oh, what motorcycle should I get,” or “What's the best motorcycle to do this, or that?” I always say like, “Oh, well the best motorcycle to do the ride you want to do is the one you have.” I think that's really true of so many things in life is that the trick is just to get started and it's not about the fancy equipment. It's not about the gear. You could just do it. If you just give yourself permission to go do a thing, you can just go do it. CORALINE: I was thinking about how that kind of philosophy relates to how my life circumstances, job situation has changed so much for the past year since I retired from software engineering and the relief of not having to be productive, not having to hit goal, not having to have constraints that I'm not in control of, governing things, and permission to go down rabbit holes. So when you were talking about the giant cow, I was liking that to well, if you were in a hurry to get somewhere, you wouldn't have stopped there. But because you weren't, you had a richer experience. You saw something you hadn't seen before. You hadn't experienced before. I really think that's a lesson we can take all over the place and give ourselves permission, like you said, to wander aimlessly and to explore. That's something that I definitely intend to do in my life and your story of doing that is very inspirational so thank you, Kerri. AARON: I was just latching onto two bits that I really liked. First off, if I'm not having fun, then why am I doing this is probably life lessons to live by. [chuckles] But I also appreciated the moment of resetting your expectations to your purpose. Like, why am I doing this thing? Let me remember, because I had a reason I'm doing it and if I'm not enjoying it right now, where's the mismatch? I like that. Because so often, it's easy, for me anyway, to stumble into doing something and finding yourself like, “Why am I doing this?” and then stepping back and be like, “Okay. All right. I chose to do this because of this and if this is my purpose, then I can let go of this other pressure that I'm putting on myself to go further every day when that's not the reason I'm here.” It doesn't make sense to put that pressure on myself then. KERRI: I feel like that chain, that returning to the beginning point is also a good career skill. You have to get serious about it, or bring this into work realm. But as a senior engineer, staff engineer, and principal, blah, blah, blah, so often, it's not how efficient can I make this loop. It's also going back, is this doing the right thing to do? Like, “Why are we doing this? Is there a better way to solve this sort of problem?” So it's that lesson of what I learned on the road coming back into work, but it's also because work is life as well and if work isn't fun and whatever, then why am I doing it? But that skill comes back into my personal life so there's this free flow of influence going back and forth. AARON: Yeah. That purpose revisit thing is something that I've just been thinking about from events standpoint from doing conferences over the past couple years, like so much had to go back to first principles because it was like, okay, well what was the reason for us doing this? Just recreating the same motion in a different environment isn't necessarily going to get us the same results. What is the reason we're doing this? Let's revisit that and make sure we're still in alignment with it all. I think we can do that more often in our lives, too. Like, “What is the reason I'm doing this thing?” [chuckles] “Okay, it's not accomplishing that anymore. Let's get rid of this practice and try something else,” or not. Maybe the answer is to keep it. CHELSEA: Yeah. One of the things that I think about apropos of what a couple of other folks were mentioning about how easy it is to get caught up in the details when trying to start something as opposed to just picking early anything and getting started. Occasionally, folks will ask me questions like that about blogging and one of the things that I like to do is keep some URLs on hand of some of my earlier pieces, just because it makes it really clear that it didn't always look like this. I just started and it wasn't what people see. I think folks sometimes see someone who's several years down the road of having started something and feeling like they can't start because it won't look like that immediately and it won't. [laughs] But I imagine that having those kinds of stories on hand, what I'm thinking about is how to make those sorts of stories more accessible to folks. Because a lot of what we see understandably about how to do something is from the folks who have mastered it to some degree and it's not as clear where to look to find folks who also are just starting and what to expect your journey to look like right at the beginning. MANDY: Kerri, do you want to leave a us with any parting thoughts? KERRI: A lot of people, when I tell them I rode a 1,000 miles in a day, they're like, “You can't do that.” It's like, “I've done it 12 times.” It's like, “What are you talking about?” But to kind of carry on to Aaron and to what Chelsea just said, it's a marathon. You can't do a lot of big things in a single step. You have to make that first step and then the second step and then the third step and then you're walking and you're doing the thing. I don't really talk about motorcycling with people who don't motorcycle and everybody who I motorcycle would talk about this. We all do it and so, it's not remarkable. Sometimes I think it's important to realize that what we do accomplish in our lives is fairly remarkable and magic to a lot of people. As software engineers, what we do is frankly, astounding some days and it's important to remember that we have traveled far from where we began when we first started doing this sort of stuff and we may return to that when we change careers, or jobs, or languages, or technologies. Return to that place of not knowing and that can be uncomfortable, but there is so much joy and discovery you can have if you just take that time, and stop and understand and pay attention to your story of where you started, where you're going, and how far along you've actually come. You can't look up the mountain and be intimidated by that. You should turn around and look back down the mountain to see how far you've come. MANDY: That was lovely. Thank you so much and thank you so much for coming back on the show and telling us yet another few stories. The first time you were on the show, I distinctly remember the title being Story Time with Kerri Miller and you never disappoint. I'm so glad that you took time to join us and talk about your motorcycling adventures with us [chuckles] non-motorcycling people. It is super fascinating and it's definitely an awesome topic outside of – that we can relate a lot of the concepts to the tech field, software engineering, development, and all that. So dear listener, if you have a cool hobby like Kerri that you want to come on the show and talk about, we'd love to talk to you because this has frankly been amazing and I really enjoyed this episode. So thank you again and we'll see you all next week. Special Guest: Kerri Miller.

02:14 - Ashleigh's Superpower: Ability To See “The Vision” * The Queen's Gambit (https://en.wikipedia.org/wiki/The_Queen%27s_Gambit_(miniseries)) 03:35 - Intentionality: “People First” * Call Me Out: Intention vs Impact * “This Doesn't Make Sense” Log * Emotional Fitness Surveys * “Dare To Lead” Book Club 10:55 - Listen * Digging in to Defensiveness / Uncomfortableness * Little Things Add Up * Building Connections and Relationships 15:10 - Building Trust – Why is vulnerability not professional? * Alleviating Fear * North Star: Being Excellent To Each Other * Self Awareness & Emotional Intelligence * Discernment * Maslow's Hierarchy of Needs (https://en.wikipedia.org/wiki/Maslow%27s_hierarchy_of_needs) 21:02 - Personal Growth and Development * Brené Brown (https://brenebrown.com/) * Glennon Doyle (https://momastery.com/) * Morning Pages (https://juliacameronlive.com/basic-tools/morning-pages/) * The Holistic Psychologist: Future Self Journaling (https://theholisticpsychologist.com/future-self-journaling/) 27:24 - Intersexuality and Identity: How do you show up? * Privilege * Gender * Somatics * Safety * Solidarity 36:37 - Making and Dealing With Mistakes * Taking Feedback * Lead With Gratitude * Ego Checks 40:05 - Employee Resource Groups (ERGs) * Visibility and Understanding * Health and Wellness Benefits * Sacred vs Safe Spaces / Safe vs Brave Spaces * Dan Price 45:52 - Fundraising & Venture Capital (VC) * The House of Who (https://www.houseofwho.com/) Reflections: Mandy: Eating a shame sandwich in order to learn and grow. Chanté: North Star = Being excellent to each other. Ashleigh: Celebrating intersections of identity. Aaron: The “This Doesn't Make Sense” log. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: PRE-ROLL: Software is broken, but it can be fixed. Test Double's superpower is improving how the world builds software by building both great software and great teams. And you can help! Test Double is hiring empathetic senior software engineers and DevOps engineers. We work in Ruby, JavaScript, Elixir and a lot more. Test Double trusts developers with autonomy and flexibility at a remote, 100% employee-owned software consulting agency. Looking for more challenges? Enjoy lots of variety while working with the best teams in tech as a developer consultant at Test Double. Find out more and check out remote openings at link.testdouble.com/greater. That's link.testdouble.com/greater. MANDY: Hello, everybody and welcome to Episode 272 of Greater Than Code. My name is Mandy Moore, I use she/her pronouns, and I'm here with our new panelist, Aaron Aldrich. Welcome, Aaron! AARON: Thanks! And hey, I'm Aaron. I use they/them pronouns and I am also here with Chanté Martínez Thurmond. CHANTÉ: Hey, everyone, Chanté here. I use she/her/ella pronouns and I am so glad to introduce our guest today, Ashleigh Wilson. Welcome, Ashleigh. AARON: Thank you for having me! Hello, Ashleigh here and I use she/her pronouns. CHANTÉ: Ashleigh is the Founder and CEO of Auditmate, the world's first elevator and escalator auditing system. After discovering that customers were an afterthought to most companies, Ashleigh left the corporate world and founded Auditmate under a "people first" mentality. Ashleigh knows discrimination first-hand as a queer woman working in the tech industry and she aims to create a space where everyone has permission to be human. What a great bio. ASHLEIGH: Thank you. Thanks for having me. CHANTÉ: It's a pleasure. Ashleigh, the first question we ask our is what is your superpower and how did you acquire it? ASHLEIGH: My superpower is my ability to see the vision and it's a bit of a witchy. I don't know where it comes from, but the best visual representation I've ever seen of it as if anyone has seen The Queen's Gambit and when she can move the chess pieces on the ceiling? When I'm in the zone, and it's often when I'm half sleep, it just connects and I'm like, “Oh, this is how it works,” and I can just see the path forward. I can't force it. [chuckles] I don't get to choose when it happens. It just happens, or it doesn't. But when I get those deep downloads on the vision and the path forward, and then I think the skill that's been learned to couple with that is then how to make a plan to execute it because the vision can be one, but that execution does not work alone. [chuckles] AARON: That's awesome. I like that and I like that you mentioned the skill that gets paired with that. I can relate to a superpower can't exist in a vacuum; it needs some way to be harness and used. [chuckles] ASHLEIGH: Absolutely. CHANTÉ: I love that, too. Aaron, where you're going with that, because what it makes me think about Ashleigh, just reading your bio and kind of getting a preview of some of the things you care about, how have you been intentional about building a people first organization, or a startup in this space and using that superpower and maybe either finding people who compliment you there, or who are distinctly different? But I'd love to hear how you've been intentional about that. ASHLEIGH: Yeah. I think it starts with first of all, when you feel othered in any organization, like coming in and being able to set the culture is like, “Oh, I'm going to do all of these things.” But as Aaron mentioned earlier, it's not in a vacuum and so, I think the intentionality has been, what is the mission? What is the north star? How do we treat each other? And then at every new hire at every new customer acquisition, it then iterates, iterates, iterates, and iterates. You have to be willing to learn, to take feedback, and to eat a shame sandwich every once in a while, when you screw it all up and you have to admit it [chuckles] because it happens every single time. I've been called to the carpet. I think one of the biggest ways that I've been intentional is being communicative about call me out, call me out. I'm never going to know all of the things all the time and I think that my team knows me well enough to know my intentions, but it comes in intentions versus impact conversation. I can only know my intentions unless you tell me how this impacts you. I can't know and so, creating a culture of my team being able to call me out and be like, “Hey, your intention was good. The impact sucked. Let's talk about it.” [chuckles] AARON: What's that like practically to get folks like on that side and able to call you out because I know for – I'm thinking about it and I know I can to jump into any corporate culture, even startup and be like, “Yeah, I feel comfortable calling out my boss on this.” [chuckles] ASHLEIGH: Yeah. I don't think we feel like we have a corporate culture at least yet. AARON: Yeah. ASHLEIGH: But that also took time in creating. So one way that we did it was we have something called that this doesn't make sense log so that people can just document either things in the system, or things in the culture, or things in policies that just are kind of dumb. Like why do we do this this way? This doesn't make sense. This makes my job harder than it should be. The we need to get X done, but you're making us do Y and Z that don't go toward the greater mission. And then also we created an emotional fitness survey for every employee so that each person – and it's left in one place so each person says, “I want to receive praise publicly, or privately,” or “If I need to get feedback, I want to receive it like this,” or these just different questions on how people to be communicated to. I think setting up those conversations as people log in and it's okay to speak up, it's okay to push back, I expect you to push back on me makes people feel more comfortable, but it takes a while. It does. CHANTÉ: I love that. I use something very similar to that for my own consulting business in my firm and it's been something that we really lean into helpful to just make sure that it's transparent and it's a nice reminder as a leader that your answers to questions can change. Giving people permission to say, “You know what, how I'm showing up today is different than how I showed up yesterday, because life.” [chuckles] ASHLEIGH: Totally. CHANTÉ: So I really love that. The other sort of burning thing that I have for you is, because I read that you had been in this business so I'm guessing that you had learned from people and maybe it was a family business. I might have missed that part. I'm curious how doing it your way this time with these sort of principles is different than the way maybe you were mentored to do it, or what you've seen in the past and why that's important. ASHLEIGH: Yeah. I don't know that I had ever seen it modeled before. I was raised in the elevator industry and before that, my stepdad was in the elevator industry and my dad was salesman of any type, door-to-door salesman selling vacuums to cleaners, to cars, to whatever the case may be and I've never fallen in line. I was always the kid in school that was like, “Why do you do it that way? When you can do it this way? Why are we doing this? That doesn't make sense and that doesn't feel good?” And people are like, “Well, we don't really care how you feel,” and I'm like, “But why it doesn't feel good?” Like why do people want to work where it doesn't feel good? This doesn't make sense to me.” That feeling in my tummy has always been so wrong that it's either a hard yes, or a hard no and I'm like, “How do you operate in a hard no all the time?” Why do we expect people to operate in these visceral responses to this? Just watching how teams have responded and how you almost want to beat the individuality out of people to get performance to a certain standard, or something, like that somehow makes it better for everybody to be like that whole homogeny equals happiness saying? It was never true to me and so, I think I always had this if I feel like this, there has to be someone else that feels like this. I cannot be the only one that wants to show up as my true self and talk about feelings in business meetings! I cannot be the only one. This has to exist. I started a Dare to Lead book club at the Elevator office, which [chuckles] I'm sure you can imagine how that went over. Everybody showed up and I was like, “Oh, so y'all want to act like this is okay and that everyone seems okay. But then look at all of these white cis men in my Dare to Lead book club. Huh.” So it just kind of gave me the affirmation that I needed to say, “People do want to feel good. People do want to talk about and this does actually help the bottom line.” CHANTÉ: I personally love it. What I do for my day-to-day is focus on culture and focus on diversity, equity, inclusion accessibility, and organizations, whether it's on teams, products, services, and offerings. I think that people underestimate what it takes to build something that's special, especially there's not a culture budget. There's a budget for recruiting. There's a budget for performance stuff and for growth. But I'm like, “But what is the fascia? What is the stuff that keeps it together?” And it is the culture. I often like to say, as we're thinking about the future of work and building the next iteration of what work should be in decentralized teams working from home, we do need to lean into the sort of the soft skills that are actually aren't that soft, but they're those emotional intelligence stuff. That makes a huge difference. So is there any advice you might have to leaders like you who are like, “Okay, I guess I might read a Dare to Lead book,” or “I might start to prioritize this”? Where can they start, or what are practical things that you've learned along the way in leading your company in this fashion? ASHLEIGH: Listen. Listen is the first one. Listen when you get defensive, because those moments when your team says something to you that seems so small, insignificant, and annoying because you have all of these big things to do and all of the – you're pushing the company forward and there's this little voice that someone was brave enough to say this little thing that you're like, “Ugh.” That defensiveness, that feeling, whatever that small thing is, is probably a big thing, or will become a big thing and being able to own up to whatever it is that's making you defensive, or uncomfortable and truly listening in and digging into what is the root cause of that? Because it's generally, I don't know if you know the saying like something about the wrapper, it's never the wrapper. You get into a fight about the wrapper on the counter, that's never the wrapper. It's not throwing away the wrapper. It's the underlining way of how we are making people feel and for me, it's been about being able to truly dig into those things. The doesn't make sense log came from one of those experiences. My team, we were in these meetings and they would bring up these little things and be like, “Hey Ashleigh, well, what about this?” And I'm like, “It's not the time for that. We're talking about Z. Why are you bringing up A? We're in this super deep meeting about Z and you're talking about A,” and then they were like, “You're not listening to us. You say that you are people first, but you're not hearing us,” which is like a dagger to the heart. It's gutting and I had to sit with it for days because I was like, “I know I'm people first. I know my intention is right. How am I not translating it? How are my actions not matching my intentions?” When I boiled down to it, it was people didn't have an easy way to bring up little things to me and so, those little things would start to get bigger and then they would bring them up in big meetings because my schedule is booked. We don't have water cooler talk. We don't have walking by someone's desk and being like, “Hey, what's happening with blah, blah, blah?” That stuff doesn't exist and so, these little things were starting to get bigger and bigger and bigger and bigger because there wasn't an easy place to just discuss them. So creating one log alleviated so much pain and made people feel heard about, “Hey, this one email has a misspelling and no one's paid attention to it.” Just little stuff. And then the second thing is that we've been starting is more personal time. We started what I call an AuditMate lounge, which is on Fridays and it's just meant to be logging on and just hanging out with each other. It's water cooler time. You can be working, you can be doing other things, but this is not a business meeting. This is not meant to get things done. It's meant to just hang out. AARON: I like that. I just started working at a new company this month and similar to the team I'm on at least, the DevRel has similar like, “Oh, we're just going to hang out for a bit because I'm around,” [chuckles] and whatever. I've really appreciated it because it's something that I feel like when you're in an office, it's easy to lose track of all the time that you spend just being around those people and building those relationships because it's just rolled into, “Oh, I was getting a coffee,” or “Oh, we went to get lunch,” or “Oh, we went to do this,” and “Oh, I walked by a desk and said ‘Hey' for a few minutes.” But especially with COVID with everyone remote and at home, or remote companies, it's so easy to forget about that stuff and forget about building those connections that are more than just, “Hey, we work on this thing together.” It's like, “Oh yeah, also, we're people. We should hang out and talk about what people do,” [chuckles] which is sometimes just nothing. ASHLEIGH: Absolutely and it's how we build trust! AARON: Hmm. Yeah. I think that's a big thing, too. MANDY: What are your favorite ways to build trust? ASHLEIGH: Oh, well, I never really thought about it like that. I'm a Scorpio moon and rising so I like all of the deep things like, “Hi, I'm Ashleigh. Tell me about your trauma.” So I think the biggest way [chuckles] that I like to build trust is just in deep conversation, really getting to know each other, being vulnerable, and being able to just take the mask off. MANDY: Do you think you can do that too much, though with coworkers? Where do you find that balance? Because I struggle with that myself. Like how do you be open and completely vulnerable, but professional at the same time? ASHLEIGH: Why is vulnerability not professional? MANDY: That's a great question. ASHLEIGH: I think that's where – and I don't have an answer to it. It's kind of what I'm rambling. But why is vulnerability pegged with femininity and why is vulnerability loaded into being unprofessional, or too much, or too whatever? I think that the vulnerability that I don't want to expose too much is if it's loaded with fear because feelings aren't facts and I don't want to unload fear onto my team if there's something that I'm nervous about. I feel like it's my responsibility to hold those things and to alleviate some fear. But I think unpacking with my team that we can be vulnerable and that is actually more professional because it does make us more efficient. It does make us more trusting, I guess, would be the proper word there. The personal things that I don't share as far as vulnerability is there's some personal life stuff that I don't share, but not because it's not professional, but because it's sacred more. AARON: I think you mentioned something interesting about fear that gets at an interesting balance. From a leadership perspective, you have some responsibility about the vulnerability that you share and what you're able to be vulnerable with your team that maybe different than you want from an individual contributor on that team. You probably want to hear the fears of your team like, “Tell me what you're worried about so I can either alleviate those, or we can work to be in a good place.” But at the same time, sounds like you have some responsibility that I can't unload that on you because I'm the one who's supposed to be [laughs] taking care of that. How does that play out me besides just that one generic scenario? Are there ways you find that balance difficult to walk, or? ASHLEIGH: Yeah, like fundraising. My team needs to trust that I'm going to pay the bills. I don't want them to be worried about having money for payroll, or that we're going to be set up for our next raise, or that, right? There's some basic survival stuff that can be so linked to trauma of if we don't feel like we're going to have food on our tables for our family, if we don't feel like we're going to have continual pay, if we don't – those sort of things that are just human nature. We can't think and we can't perform because it is my duty to take care of my family and if I can't take care of my family with this company, I need to go do what I need to go do. So that's where it's my responsibility to those fears – especially when you are rational, if I'm having imposter syndrome about raising money as a queer woman and it's irrational because, maybe not irrational but loaded because of statistics, I shouldn't unload that on them, or I need to have someone, a mentor, someone that I can go to because they need to be expressed, but that could get bigger and bigger and bigger when shared with my team. So I really think about our north star is being excellent to each other. When my vulnerability is serving to them is when I share and not just when it's serving to me, because it'll make me feel better to express that I'm scared about funding, but it will not make my team feel better. It will, in fact, make them feel worse. CHANTÉ: What I hear is this dance we have to do as folks who have founded companies, or leaders of those companies to have what I consider again, that emotional intelligence. It's like – [overtalk] ASHLEIGH: Totally. CHANTÉ: Because self-awareness is huge and when you get a chance to – when you know your traps, or the traumas and the triggers that keep you stuck, or actually help to get you to another place, you can notice them in others and then the regulation is really important as well to really build relationships that are trusting and then discern it. It's like timing is everything to be like, you have to be able to read the room. You have to be able to be perceptive, read people's faces, and understand that they may have disassociation. They might be smiling, but they actually might be scared shitless [laughs] as you're like, “Oh, we're raising around.” I love how you how you kind of introduce this thought around Maslow's hierarchies of needs. People want to be able to put food on the table and be able to take care of their responsibilities whether that's a family, or a spouse, significant other, friend, or community and that is why we work. [chuckles] We need the money because we're in this capitalistic system. So I just love how you're doing that and where my mind takes me is how did you have the wisdom to do that? Who has been either an example that you admire, do you have a coach, do you have a community? Where are you learning these awesome things? Because I feel like you're so in touch with this emotional intelligence piece that so many people are missing. ASHLEIGH: Thank you. I appreciate that. I did not used to be, [chuckles] to be quite honest and I learned about emotions getting freshly sober at like 24 from Brené Brown. I had no idea. I had no idea. I quit drinking and remember starting to read one of her books and saying that an emotionally intelligent person knew 30 emotions and I was like, “Wait, there's more than happy and sad? You're telling me there's 30? That I should be able to name 30 and know what they feel like in my body?” CHANTÉ: Right, and according to her new book, she has even more stuff. ASHLEIGH: [laughs] Yeah. CHANTÉ: I think there's like 80 plus. ASHLEIGH: I'm like, “Wait, what?” [laughter] “This is a thing?” And that's when it kind of dawned on me, when people would say to me, “You don't get it. You don't get it,” and I'm like, “I don't get what?” And then I was like, “Oh, I'm not going to be able to know what you're feeling until I know what I'm feeling. Cool, great. I have a lot of work to do.” [chuckles] So that's when I think I started unpacking and learning. I was raised by an alcoholic and then became one and then getting sober at a young age was like, “Oh, this is mine and that's yours and I didn't know that I ended and you started.” So really learning and starting to place those things for me and then just reading a lot, a lot of Eastern spirituality, I read a lot of Buddhism books, a lot of yoga books, a lot of Brené Brown vulnerability, shame, rumbling type books. And then I think it's just kind of been like I'll take this from that and really, it just leads from what feels good and what doesn't. MANDY: Personal growth is essential. I'm in the same boat almost. I, too, am sober and it has changed my life. Over the past 2 years, I have done so much work on myself that sometimes I'm doing too much, but I learned – [overtalk] ASHLEIGH: Totally. That's a thing. [overtalk] MANDY: Brené Brown is one of my heroes, Glennon Doyle, too. ASHLEIGH: I was just going to mention her. Yes, oh my God! MANDY: I love Glennon. Yeah. So personal growth is, I mean, journaling. Every day, I make it a habit and a practice to sit down and just write out my thoughts and my feelings. I highly, highly suggest to anybody who will listen to me to do the same thing. ASHLEIGH: Same. [chuckles] MANDY: Morning Pages are a wonderful thing. If you can do it in the morning, just get everything out of your head. Even the dumbest little thoughts, “dumbest little thoughts.” I mean, there are no dumb thoughts, but just getting all the, I call it taking the trash out. ASHLEIGH: Oh, I like that. MANDY: And just even snippets of any weird dreams, or just little nagging thoughts that are in the back of my head. Getting all those things out is just so essential. ASHLEIGH: Yeah, absolutely. And do you know The Holistic Psychologist? MANDY: I do. ASHLEIGH: Yeah, and her future self-journaling has also been really helpful at times, like sitting down in the morning and saying, “My future self will feel like this and this is how my future self will take care of me today” has also been really powerful along those same lines. CHANTÉ: Mandy, I loved your question earlier when you were like, “How do you know? Some people are not comfortable in doing that.” So I feel like what's also really true about organizations and teams is just you can have somebody who's kind of the sage, or most wise elder on the team who's like, “I've been through this, I've walked this path,” and then there's people who are like, “Huh, vulnerability.” And then the magic of that leader in the room is finding, or recognizing the spectrum of that and being all these things are actually welcomed and everybody's experience matters. So how do you do that for your team? I'm imagining you have people who are newbies on this journey with you, or people who are like, “This is the best.” Maybe they gravitated and wanted to join you because they recognize parts of themselves in you, but how do you manage that part for your team and kind of carry and make room for the full spectrum of folk? ASHLEIGH: Yeah. I think I'm still learning that one. I think we're always learning that one as our teams constantly change and evolve. The emotional fitness survey helps. I definitely call people out and I'm like, “Okay, how does this feel to everyone? Everyone has to talk, I'm waiting and I will for you to talk,” which I know can be jarring for folks that don't want to share in a group. So really making sure to get everyone's input, that everyone gets used to speaking up in front of the group, and that it is just around Robin mentality, but then also developing those one-on-one relationships so people feel kind being like, “Hey, I'd rather share with you my idea after the call,” or whatever the case may be. But I think it's my job to hold space, it's my job to shut up sometimes and pass the mic, and it's my job to push and to pull. So to really, really look at those levers of who's ready for more and who has the potential to and wants to develop that potential. Maybe it's fear, or maybe it's something that's blocking them that I can help them see. And then for other folks they're like, “Hey, I'm good. I'm chilling. I want to be right here. I don't want to be the big boss. I want to be your right-hand human and let me stay where I'm at.” I'm in my lane. Go away.” So I think it's just really listening to folks and then also help to see what may blocking our views. CHANTÉ: I think I shared that the work I do is diversity, equity, and inclusion accessibility stuff and I often lead a lot and facilitate a lot of conversation around helping leaders and their teams recognize their identities, or intersectionality and recognizing social location and how that plays out with power privilege. One of the things we read about you is that you are a member of the LGBTQ+ community, and I'm guessing that that's a very prominent identity for you because you shared it online openly. Thank you. But I know there's other parts to you. So what are the identities that you lead with? We could start with the most obvious and kind of learn more about you from there. ASHLEIGH: Yeah. So I lead with queer always. Queer is through and through who I am. I realize the privilege I have with the way that I present to the world. In most instances, I will always be safe and I think that it's my responsibility as a VC-backed founder to take that space and I don't really own that for me. I have the privilege of being safe and so, let's make this known and let's make room for more folks while I'm here. I can elbow folks out of the way so that we can keep some more space. But the other parts of me. Gender, I don't really know right now, I'm kind of at the point that I think it's really garbage shit right now. So I don't really know. [laughs] I struggle. I've been in the dance with gender for a while and it's like, I feel like I would be taking up too much space to come out as non-binary and I know that non-binary, you don't have to look a certain way. I realize I have a lot of cis presenting privilege and it's not about that for me. I finally have landed on the conclusion that I don't give a crap about gender at all. It's more genderless and even non-binary feels too boxy for me. I don't know, I'm kind of ambiguous on that right now. [chuckles] AARON: Actually, I'm just generally agnostic you. ASHLEIGH: Yeah. I feel that. [laughter] CHANTÉ: Yeah. And I loved your response. I'm really into somatics and noticing bodies because bodies show up in space. [chuckles] ASHLEIGH: Yeah. CHANTÉ: People are triggered by bodies sometimes and recognizing it could be that your race, your ethnicity, it could be your age, or your ability, or where you grew up and accent. Are there any other parts of you that you feel like are prominent, or that you lead with, or maybe don't lead with? I'm curious just to hear more about it. ASHLEIGH: I'm pretty heavily tattooed and I also dress kind of funky in most instances. You can't tell right now, but half my hair is orange and half my hair is red. I'm loud, I'm vocal, and I'm very little, but I'm big in spaces. [laughs] I think that makes me different because most of the spaces that I operate in, I've been in this. Oh, the elevator world, it is 98% white men and I'm joking kind of about the industry, but I'm not going to shrink myself anymore. You will be uncomfortable by me. Don't let the crop top fool you. I am a CEO [chuckles] and I'm not going to change my crop top. Like, sorry. CHANTÉ: Yes. See, this is why I'm asking. I mean, I love it. You just naturally went to like, “Okay.” So those are the things that that's how you're showing up. ASHLEIGH: Mm hm. CHANTÉ: Right, and what's true for the industry and what you're in and you kind of already went there, I think it's dope and I think the context matters because you're like, “Yeah. Am I in a room with other queer people who are leading tech companies, or am I in a predominantly male, cis, able-bodied, privileged, born and educated in United States industry where I'm blending elevator technology,” whatever? So thank you for that. ASHLEIGH: Yeah, absolutely. [chuckles] A lot of times I walk into the room and it's like, either I'm uncomfortable, or they're uncomfortable. So I'm like, “You're going to be uncomfortable today. I'm sorry. I'm going to make you feel things and I'm going to make you recognize your privilege because guess what, we all must be painfully aware of our privilege and if I am in a room all full of white people, all of able-bodied people, all of privileged people in some sense, let's talk about this. Why are we not? Why are we not talking about the humans that are impacted by the work that we're doing? Hello.” AARON: It sounds like that was a big influence for your people-centric company, too. ASHLEIGH: Mm hm. AARON: I don't want to put that experience on you, [chuckles] but – [overtalk] ASHLEIGH: Totally. AARON: I don't want to ask it from a place of naivety and say like, “Oh, did this affect it?” It sounds very obviously your identity and being counterculture to the elevator and escalator world has influenced your company and where you want to go with that and how you want to show up. ASHLEIGH: Absolutely, a 100% being in that space and being different and just being like, “You know what, if I don't own this, I'm going to feel terrible forever and I don't want to because that's great.” It's great and I can walk into the sun in San Francisco and feel fantastic and so, why do I not feel that same confidence level in this boardroom? AARON: Right. ASHLEIGH: You're not going to make me feel small. I'm sorry, you're not. AARON: I think that's a big – I don't know if I'm seeing so much of a shift. It's a big portion of… I don't know I want to go with that, but I really like that. You're not going to make me feel small. I like the idea of showing up and you know what, this is me and just because you are uncomfortable, I'm not going to diminish myself. ASHLEIGH: Absolutely and the reason that I do that is me doing that shows other people that it's safe. At least if I'm in the room, you're safe to be who you are if I'm here. AARON: Mm. ASHLEIGH: And so that's why I put queer on my LinkedIn, that's why I lead with that because I know I'm safe and so, if I have – I feel responsible to it. AARON: I know you mentioned you can show up and be safe and create that safety in that environment. Has that been something you had, or had modeled for you, or is that something you had to go out and create this space where you could be that beacon of safety? ASHLEIGH: I think it's been modeled in my queer community. I don't think it had been modeled in corporate culture. I'm also not lost on how privileged I am to be safe and I'm not the bearer of safety and realize that there's many more intersections that go into that and that I'm here to listen and to learn and I don't know everything. [chuckles] Absolutely not. So it's important to just be really vulnerable about what we don't know and to say, “Hey, I'm going to fuck it up and there's going to be ways that I am not aware of my unconscious bias yet. So please teach me and if you don't have emotional capacity to teach me, I'm not saying that it's your responsibility, but if you can call me out, please do.” CHANTÉ: Yeah. That's a really important thing. I feel like being in solidarity with others who are othered. For me, it's like oh shit, we have Black history month coming up around the corner and I have some friends who are Black and queer, or Black, queer, and disabled and they're just like, “Oh, which one should I lead with first?” And I'm like, “All of them.” You shouldn't have to choose any of them over the other parts of yourself, because they're all valid and they all inform your lived experience in this particular body that you're in. I want people to see the complexity and the wholeness of others and just be like, “That is dope.” I love how you said when people have the capacity to teach you, you invite it, but you're not demanding it because so many times we've – I think we all can speak to this on this call. We're all in community. But it is, some of us have more resource and more ability to show up for each other at other points in time because we're going through something [chuckles] that the whole world doesn't know. It is likely because of our identity, our social location, our privilege, and the unique things we're kind of going through as we navigate life. It's really important to just constantly communicate that as well, that you're inviting this kind of calling out, or calling in and that people don't have to educate you. But I hear the willingness to want to show up and learn, which I think is literally a key. [laughs] The willingness. Yeah, awesome. AARON: It's at least half of the battle, right? CHANTÉ: Yes. ASHLEIGH: Totally. My friends and I were having a discussion about community here and it was like, you cannot have a community space that never once is going to screw up, or have an issue, or be called out, or called in. How you move through that, or what, I don't know. If you continue to be a safe space, it's not in not getting called out. It's how you deal with it. It's how you take that feedback from someone, or the community group and say, “One, thank you for telling me, let's be grateful that someone had the bravery to even speak up and two, then you get to say, is this mine, or not?” Don't lead with the buts, or the whys I did it, or the here's my intent. Don't lead with that. Lead with gratitude that someone felt safe enough to come forward. Someone felt that you were worth getting their feedback, because guess what, if they didn't believe that you would change, they probably wouldn't even tell you. They would just leave. They would just deem the space as unsafe and go. So that in itself, how you take feedback will determine how your community and your company thrives, both. MANDY: And then apologize and move on. ASHLEIGH: Bingo. Yes. AARON: And make material changes to show that you've learned. [laughter] ASHLEIGH: Oh, yeah. [laughter] ASHLEIGH: Good pointer. And then act also important. But [laughs] yes. AARON: That lesson of taking feedback, I think and understanding the value of that is so huge and it's a hard lesson. This is probably the hardest lesson I'm dealing with my kids for instance, is like, “Hey, that first call out, I wasn't really upset with you, but then when you acted super defensive and flipped out, that's the problem that I have. That's not okay.” ASHLEIGH: Totally. AARON: The initial action was just like, “Hey, we need to change this. Let's alter our behavior. Move on. But all the other stuff, that was not good that. That, we need to work on.” ASHLEIGH: Absolutely. AARON: Yeah. It's a tough lesson. I think it requires an ego check. Like decentering and recognizing oh, this call, it's not about me. [laughs] ASHLEIGH: Absolutely. Yes, and it's not easy work. You've got to eat it. It's not fun. AARON: Right. MANDY: Yeah. I've had to learn not everything's about me. [laughter] MID-ROLL: And now a quick word from our sponsor. I hear people say the VPNs have a reputation for slowing down your internet speed, but not with NordVPN, because it's the fastest VPN in the world. I don't have to sacrifice internet speed for better security. With NordVPN, my internet traffic is routed through a secure encrypted tunnel, which protects my data and privacy. I can also have it on up to six devices like my laptop, phone, TV, iPad—all my devices are protected. Grab your exclusive NordVPN deal by going to nordvpn.com/gtc, or use the code GTC to get a huge discount on your NordVPN plan plus one additional month for free. Plus, a bonus gift! It's completely risk-free with Nord's 30-day money back guarantee. AARON: A thing I wanted to get back to a little bit. I loved when Chanté was talking about folks who said that were Black, queer, and disabled and this multiple identities and leading with all of them. I think especially industry wise, or big corp wise anyway, we create these interest groups of this is the Black community interest group. This is the pride interest group. This is the disabled workers' interest group. I feel like it misses so much of the you of intersectionality. I'm wondering if you've seen that both, in your space and your identity and being able to create that space of vulnerability yourself, if you've noticed a benefit of that. ASHLEIGH: No, I think that's interesting and I like the note here that employee resources groups can be really great and really crappy. I totally agree. AARON: Yeah. ASHLEIGH: Often, it feels to me that the goal is visibility and understanding at the end of the day. We get great visibility in employee resource groups. We feel seen with people that are like us in some way, or another. But really, we want to have this intersectionality so how do we get both? My gosh. How do we have the representation, which is so important? How do we have the understanding, which is so important? And then how do we move past the feelings of not feeling seen so that we can see others? Because if we don't think it's possible to be seen, we're probably not able to see others and we need an on-staff therapist, really. Let's just be honest. [laughter] CHANTÉ: Yes. ASHLEIGH: Put them on payroll. [laughter] CHANTÉ: I've got to get that idea. Now you're talking my language. I'm telling you, I'm telling you if I had it my way, all organizations would offer that as their employee health and wellness benefit is to have somebody who's like on-site and depending on the ratio of people, if you have too many, you got to get several organizational psychologists and folks who are well-versed in trauma. ASHLEIGH: Totally. Yeah. CHANTÉ: But it makes me think of the conversation I often talk about, which is the difference between sacred space and safe space. AARON: Ooh. CHANTÉ: The sacred space is like those ERGs. It's like, yeah, we're going to have our unique identities where we can show up, talk to each other, see each other, and be like, “Oh my God, that really sucked,” or “That was really good. Good job in there.” The places where we're like – the safe spaces are harder because we have to make sure that everyone, when we say psychological safety, they're like, “Yes, I know what that means,” and that people are committed to doing some kind of work, which is why I'm like, “Organizations need to focus more on culture.” ASHLEIGH: Yeah. CHANTÉ: And this is where the like magic can happen, or where it can all fall apart. The sacred versus space is so huge. So, so huge because we can't have enough of people like you, Ashleigh. The world needs so many CEOs like you, then the world would be better and different and I wouldn't mind going to corporate work. [chuckles] But the reality is that you are few and far between. It's based on your identities, based on your lived experience, which is why it is so important to talk about it and to spend time with this episode getting into it. ASHLEIGH: Yeah. No, I completely agree. I also really like the idea of what's the difference between a safe space and a brave space, which plays into that a bit, too. I think in order to be safe, we have to be brave and it's kind of like what comes first vulnerability, or the courage? All the nuance in that, that ends up being this mushy gushy and I completely agree, we need it all and it's possible and I'm a firm believer in it's possible. The people that keep telling me that people first companies can't be profitable. I think it's bullshit. I think it's absolute bullshit. When we focus on people, the profits will come. If we're all safe, if we all believe in the mission, if we're all there because we want to be there, guess what? It will happen in and it will continue to happen and the foundation will be more sturdy and we'll be able to pivot easier because guess what? We move as a pack and I don't know, I guess, I'm just here to prove them all wrong. CHANTÉ: I feel like I love that and I'm also really sad that we have to work really hard to prove that people matter over productivity, [chuckles] that people matter over profits. ASHLEIGH: Yeah. CHANTÉ: My favorite, well, one of my favorite people to follow is Dan Price. He's the CEO of Gravity Payments and he's the guy who went viral when he basically gave up parts of his salary and paid everyone a livable wage. He tweets every day and of brings attention to this. It's just like you're right, Ashleigh that people first companies are rare and I can't believe that that's still happening in 2022, but the ones who are, stick out. There are definitely folks who people fall in line to submit their resume and want to work for you and you have no issue with hiring great talent and probably keeping it. It's the organizations and corporations that are literally extracting people's best parts of themselves in hope of getting a profit for their shareholders. ASHLEIGH: That just sounds so icky, doesn't it? [chuckles] CHANTÉ: Yeah. Yeah. It does. I haven't looked to see who your community is in terms of being venture backed, but when you went out, fundraised, started your company, and you said you were going to be people first, what were the reactions? Did it take you many tries to find folks to fill your cap table who believed in that, too? ASHLEIGH: So our first funding round, it was mostly retired elevator people that want to see the industry turn around, that believe in the industry and feel really crummy about where it's at now and how lost it is. Our entire first round was completely private and then after that, the next round was mostly those people coming in again. I wanted to go non-VC for as long as possible because I know I'm niche, I know I'm different, and if you don't get the vision, I don't want to waste my time trying to explain to you what we're doing, because we're too different. So if you're not with me, I don't have the time to sit here and convince you. The industry is a $100 plus billion a year industry and if you don't see that and don't get it, then bye. But then we ended up taking on some VC funding this round because I got tagged in a LinkedIn post that someone was like, “Where are all the PropTech women?” 98% of the people pitching this VC were all men. We ended up getting a meeting because I've always turned down any VC meeting. We just hit it off and then we went out to lunch and we were very similar. He was a founder himself and so, he understood what I was doing. I was like, “Hey, I'm not building this company to report to venture capitalists and so, if you're someone that expects me to work for you and not to work for my employees, we're not the right fit.” He was like, “No, that's what I expect you to do. Call me if you need me. Otherwise, I'm out of your hair.” I was like, “Great, okay! We can do this.” And then we ended up getting a couple more folks. I think it was really because I got on the phone with them and I was like, “I'm not taking your money,” and they were like, “Excuse me?” I was like, “I'm not taking your money. My round is full. I'll talk to you only because Zane wants me to talk to you. Otherwise, I don't have a conversation with you,” and they were like, “Please extend your round,” and I was like, “Okay, I guess.” So how could this happen? CHANTÉ: Wow, that's – [overtalk] ASHLEIGH: Is it because I'm being a jerk? [laughs] CHANTÉ: No, it sounds like it happened because you were more aware of who you were and you were sticking to your values and principles, actually. That's what it sounds like from my seat. So speaking of that, are your values of the company reflections of your personal values, or are they collective –? [overtalk] ASHLEIGH: Oh, a 100%. CHANTÉ: To the folks who work with you? ASHLEIGH: Yeah, I think both and we found each other. But building out the values and the mission and the vision was something that I spent a lot of money doing with The House of Who, who is a great organization and the East Bay. They're a branding company and they really helped me articulate the vision, the values, and the mission in a really eloquent way right in the beginning. I think everyone probably looked at me like I was bonkers for spending money on branding before I had any sort of software, or [chuckles] any sort of anything. But for me, it was so important that we had a way to articulate this to the team in an eloquent way that got people on board and really said, “This is who we are and this is who we're going to be.” How do we know what we do before we know who we are? It's not possible. So at that point, the people that align and that gravitate to what our values and vision are, I think we just kind of find each other. MANDY: That's awesome. I loved hearing a little bit about your journey, especially when it comes to venture capital, because I think lot of us just get a weird icky feeling from even hearing about venture capital. So it's always good to hear the good stories. ASHLEIGH: Yeah. MANDY: But since we are coming up on the hour, I was hoping that we could go into reflections and this is where we talk about something that stood out to us, maybe a call-to-action for ourselves, or the listeners. I can start. There was something at the beginning of the show that you said, that I had to write down, was just eating a shame sandwich once in a while. I'm not going to try to say that ten times fast. [laughter] You invited people to call you out and I love that. That's something I always try to do and model. It's the best way to learn, when invited, saying, “If we're talking, I'm going to ask you this. If I'm wrong, can you please let me know? Because I want to learn. I want to grow.” I think that's something that's super important and something that I try to do, especially with children that I'm around. My child, other children that are friends with her, just be like, “I was wrong. I was wrong. I'm sorry and it's just such a good thing to do, just to be humble in that ability to say I was wrong and I learned.” Thank you for that. CHANTÉ: The thing I really love that you said, and I haven't really heard this often, is you said your north star is being excellent to each other and I feel like most people have a north star of growing, or making an X number of profit, or whatever. I just love that. It is because it really does, I think eliminate your value of being people first and demonstrates that that's where you're going to put your time and money. Not only if I had the money, I'd be like, “Okay, Ashleigh, when you're having your next route, I want to invest in you.” But I feel like leading with that and saying that often tells people who might be interested in a job what you're about, tells your clients what you're about, and obviously, the communities in what you're serving. I just love that. So thank you for sharing it. ASHLEIGH: Yeah, absolutely. Chanté, my favorite part of today was you talking about the intersections and celebrating the intersections of identity and I've had so many conversations with friends about the different lanes into the intersection, but I really like that you focused on the intersection. So that intersection as a whole was very cool to me. AARON: I think one of the things I'm going to take with me was your this doesn't make sense log. I love this concept. This speaks to me on so many different levels. One is the way to raise all these little things that get missed without having to work up all of the energy to try and give someone feedback in a one-on-one meeting, or whatever else. But also, as someone who deals with ADHD and from an engineering mindset, just this place to be like, “Hey, I ran across this and it makes no sense. Can we revisit this?” Because the answer might be, “Oh, here's this explanation for why we do it that way,” and you're like, “Oh, now it makes sense to me,” or it might be like, “You're right. Let's figure out a different way to do that.” I just love that there's just this running place that anyone can just dump these thoughts as they run across them is really cool. MANDY: Awesome. Well, Chanté, Aaron, Ashleigh, it's been such a great conversation and thank you all so much for showing up and being vulnerable and having this discussion. It's been great. So with that, I just want to thank you again, thank the audience, and we'll see next week. Special Guest: Ashleigh Wilson.

00:58 - Paul's Superpower: Participating in Scary Things 02:19 - EventStorming (https://www.eventstorming.com/) * Optimized For Collaboration * Visualizing Processes * Working Together * Sticky (Post-it) Notes (https://www.post-it.com/3M/en_US/post-it/products/~/Post-it-Products/Notes/?N=4327+5927575+3294529207+3294857497&rt=r3) 08:35 - Regulation: Avoiding Overspecifics * “The Happy Path” * Timeboxing * Parking Lot (https://project-management.fandom.com/wiki/Parking_lot) * Inside Pixar (https://www.imdb.com/title/tt13302848/#:~:text=This%20documentary%20series%20of%20personal,culture%20of%20Pixar%20Animation%20Studios.) * Democratization * Known Unknowns 15:32 - Facilitation and Knowledge Sharing * Iteration and Refinement * Knowledge Distillation / Knowledge Crunching * Clarifying Terminology: Semantics is Meaning * Embracing & Exposing Fuzziness (Complexities) 24:20 - Key Events * Narrative Shift * Domain-Driven Design (https://en.wikipedia.org/wiki/Domain-driven_design) * Shift in Metaphor 34:22 - Collaboration & Teamwork * Perspective * Mitigating Ambiguity 39:29 - Remote EventStorming and Facilitation * Miro (https://miro.com/) * MURAL (https://www.mural.co/) 47:38 - EventStorming vs Event Sourcing (https://martinfowler.com/eaaDev/EventSourcing.html) * Sacrificing Rigor For Collaboration 51:14 - Resources * The EventStorming Handbook (https://leanpub.com/eventstorming_handbook) * Paul's Upcoming Workshops (https://www.virtualgenius.com/events) * @thepaulrayner (https://twitter.com/thepaulrayner) Reflections: Mandy: Eventstorming and its adjacence to Technical Writing. Damien: You can do this on a small and iterative scale. Jess: Shared understanding. Paul: Being aware of the limitations of ideas you can hold in your head. With visualization, you can hold it in more easily and meaningfully. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: MANDY: Welcome to Episode 271 of Greater Than Code. My name is Mandy Moore and I'm here today with a guest, but returning panelist. I'm happy to see Jessica Kerr. JESSICA: Thanks, Mandy. It's great to see you. I'm also excited to be here today with Damien Burke! DAMIEN: And I am excited to be here with both of you and our guest today, Paul Rayner. Paul Rayner is one of the leading practitioners of EventStorming and domain-driven design. He's the author of The EventStorming Handbook, co-author of Behavior-Driven Development with Cucumber, and the founder and chair of the Explore DDD conference. Welcome to the show, Paul. PAUL: Thanks, Damien. Great to be here. DAMIEN: Great to have you. And so you know, you are prepared, you are ready for our first and most famous question here on Greater Than Code? PAUL: I don't know if I'm ready, or prepared, but I can answer it, I think. [laughter] DAMIEN: I know you have prepared, so I don't know if you are prepared. PAUL: Right. DAMIEN: Either way, here it comes. [chuckles] What is your superpower and how did you acquire it? PAUL: Okay. So a couple of weeks ago, there's a lake near my house, and the neighbors organized a polar plunge. They cut a big hole in the ice and everyone lines up and you basically take turns jumping into the water and then swimming to the other side and climbing out the ladder. So my superpower is participating in a polar plunge and I acquired that by participating with my neighbors. There was barbecue, there was a hot tub, and stuff like that there, too. So it was very, very cool. It's maybe not a superpower, though because there were little kids doing this also. So it's not like it was only me doing it. JESSICA: I'll argue that your superpower is participating in scary things because you're also on this podcast today! PAUL: [chuckles] Yeah, there we go. DAMIEN: Yeah, that is very scary. Nobody had to be fished out of the water? No hospital, hypothermia, any of that? PAUL: No, there was none of that. It was actually a really good time. I mean, being in Denver, blue skies, it was actually quite a nice day to jump into frozen. MANDY: So Paul, you're here today to talk about EventStorming. I want to know what your definition of that is, what it is, and why it's a cool topic to be talking about on Greater Than Code. PAUL: Okay. Well, there's a few things there. So firstly, what is EventStorming? I've been consulting, working with teams for a long time, coaching them and a big part of what I try and do is to try and bridge the gap between what the engineers, the developers, the technical people are trying to build in terms of the software, and what the actual problem is they're trying to solve. EventStorming is a technique for just mapping out a process using sticky notes where you're trying to describe the story of what it is that you're building, how that fits into the business process, and use the sticky notes to layer in variety of information and do it in a collaborative kind of way. So it's really about trying to bridge that communication gap and uncover assumptions that people might have, expose complexity and risk through the process, and with the goal of the software that you write actually being something that solves the real problem that you're trying to solve. I think it's a good topic for Greater Than Code based on what I understand about the podcast, because it certainly impacts the code that you write, touches on that, and connects with the design. But it's really optimized for collaboration, it's optimized for people with different perspectives being able to work together and approach it as visualizing processes that people create, and then working together to be able to do that. So there's a lot of techniques out there that are very much optimized from a developer perspective—UML diagrams, flow charts, and things like that. But EventStorming really, it sacrifices some of that rigor to try and draw people in and provide a structured conversation. I think with the podcast where you're trying to move beyond just the code and dig into the people aspects of this a lot more, I think it really touches on that in a meaningful way. JESSICA: You mentioned that with a bunch of stickies, a bunch of different people, and their perspectives, EventStorming layers in different kinds of information. PAUL: Mm hm. JESSICA: Like what? PAUL: Yeah. So the way that usually approach it is, let's say, we're modeling, visualizing some kind of process like somebody registering for a certain thing, or even somebody, maybe a more common example, purchasing something online and let's say, that we have the development team that's responsible for implementing how somebody might return a product to a merchant, something like that. The way it would work is you describe that process as events where each sticky note represents something that happened in the story of returning a product and then you can layer on questions. So if people have questions, use a different colored sticky note for highlighting things that people might be unsure of, what assumptions they might be making, differences in terminology, exposing those types of unknowns and then once you've sort of laid out that timeline, you can then layer in things like key events, what you might call emergent structures. So as you look at that timeline, what might be some events that are more important than others? JESSICA: Can you make that concrete for me? Give me an example of some events in the return process and then…? PAUL: Yeah. So let's say, the customer receives a product that they want to return. You could have an event like customer receive product and then an event that is customer reported need for return. And then you would have a shift in actor, like a shift in the person doing the work where maybe the merchant has to then merchant sent return package to customer. So we're mapping out each one of these as an event in the process and then the customer receives, or maybe it's a shipping label. The customer receives the shipping label and then they put the items in the package with the shipping label and they return it. And then there would be a bunch of events that the merchant would have to take care of. So the merchant would have to receive that package and then probably have to update the system to record that it's been returned. And then, I imagine there would be processing another order, or something like that. A key event in there might be something like sending out the shipping label and the customer receiving the shipping label because that's a point where the responsibility transfers from the merchant, who is preparing the shipping label and dispatching that, to the customer that's actually receiving it and then having to do something. That's just one, I guess, small example of you can use that to divide that story up into what you might think of as chapters where there's different responsibilities and changes in the narrative. Part of that maybe layering in sticky notes that represent who's doing the work. Like who's the actor, whether it's the merchant, or the customer, and then layering in other information, like the systems that are involved in that such as maybe there's email as a system, maybe there's the actual e-commerce platform, a payment gateway, these kinds of things could be reflected and so on, like there's – [overtalk] JESSICA: Probably integration with the shipper. PAUL: Integration with the shipper, right. So potentially, if you're designing this, you would have some kind of event to go out to the shipper to then know to actually pick up the package and that type of thing. And then once the package is actually delivered back to the merchant, then there would be some kind of event letting the merchant know. It's very hard to describe because I'm trying to picture this in my mind, which is an inherently visual thing. It's probably not that interesting to hear me describing something that's usually done on some kind of either mirror board, like some kind of electronic space, or on a piece of butcher's paper, or – [overtalk] DAMIEN: Something with a lot of sticky notes. PAUL: Something with a lot of sticky notes, right. DAMIEN: Which, I believe for our American listeners, sticky notes are the little square pieces of brightly colored paper with self-adhesive strip on the back. PAUL: Yeah. The stickies. DAMIEN: Stickies. [chuckles] I have a question about this process. I've been involved in very similar processes and it sounds incredibly useful. But as you describe it, one of the concerns I have is how do you avoid getting over specific, or over described? Like you can describe systems until you're talking about the particles in the sun, how do you know when to stop? PAUL: So I think there's a couple of things. Number one is at the start of whatever kind of this activity, this EventStorming is laying out what's the goal? What are we trying to accomplish in terms of the process? With returns, for example, it would be maybe from this event to this event, we're trying to map out what that process looks like and you start with what you might call the happy path. What does it look like when everything goes well? And then you can use pink stickies to represent alternate paths, or things going wrong and capture those. If they're not tied back to this goal, then you can say, “Okay, I think we've got enough level of detail here.” The other thing is time boxing is saying, “Okay, well, we've only got half an hour, or we've only got an hour so let's see how much we can do in that time period,” and then at the end of that, if you still have a lot of questions, then you can – or you feel like, “Oh, we need to dig into some of these areas more.” Then you could schedule a follow up session to dig into that a little bit more. So it's a combination of the people that are participating in this deciding how much level of detail they want to go down to. What I find is it typically is something that as you're going through the activity, you start to see. “Oh, maybe this is too far down in the weeds versus this is the right level.” As a facilitator, I don't typically prescribe that ahead of time, because it's much easier to add sticky notes and then talk about them than it is to have a conversation when there's nothing visualized. I like to visualize it first and lay it out and then it's very easy to say, “Oh, well, this looks like too much detail. So we'll just put a placeholder for that and not worry about out it right now.” It's a little bit of the facilitation technique of having a parking lot where you can say, “Okay, this is a good topic, but maybe we don't need to get down in that right now. Maybe let's refocus back on what it is that we're trying to accomplish.” JESSICA: So there's some regulation that happens naturally during the meeting, during interactions and you can have that regulation in the context of the visual representation, which is the EventStorming, the long row of stickies from one event to the other. PAUL: Right, the timeline that you're building up. So it's a little bit in my mind, I watched last year, I think it was on Netflix. There was a documentary about Pixar and how they do their storyboarding process for their movies and it is exactly that. They storyboard out the movie and iterate over that again and again and again telling that story. What's powerful about that is it's a visual medium so you have someone that is sketching out the main beats of the story and then they're talking it through. Not to say that EventStorming is at that level of rigor, but it has that kind of feel to it of we're laying out these events to tell the story and then we're talking through the story and seeing what we've missed and where we need to add more detail, maybe where we've added too much detail. And then like you said, Jess, there's a certain amount of self-regulation in there in terms of, do we have enough time to go down into this? Is this important right now? JESSICA: And I imagine that when I have questions that go further into detail than we were able to go in the meeting, if I've been in that EventStorming session, I know who to ask. PAUL: That's the idea, yeah. So the pink stickies that we said represent questions, what I like about those is, well, several things. Number one, it democratizes the idea that it's okay to ask questions, which I think is a really powerful technique. I think there's a tendency in meetings for some people to hold back and other people to do all the talking. We've all experienced that. What this tries to do is to democratize that and actually make it not only okay and not only accepted, but encourage that you're expected to ask questions and you're expected to put these sticky notes on here when there's things that you don't understand. JESSICA: Putting the questions on a sticky note, along with the events, the actors, and the things that we do know go on sticky notes, the questions also go on sticky notes. All of these are contributions. PAUL: Exactly. They value contributions and what I love about that is that even people that are new to this process, it's a way for them to ask questions in a way that is kind of friendly to them. I've seen this work really well, for example, with onboarding new team members and also, it encourages the idea that we have different areas of expertise. So in any given process, or any business story, whatever you want to characterize it as, some people are going to know more about some parts of it than others. What typically happens is nobody knows the whole story, but when we work together, we can actually build up an approximation of that whole story and help each other fill in the gaps. So you may have the person that's more on the business, or the product side explaining some terminology. You can capture those explanations on sticky notes as a glossary that you're building up as you go. You can have engineers asking questions about the sequence of events in terms of well, does this one come before that one? And then the other thing that's nice about the questions is it actually as you're going, it's mapping out your ignorance and I see that as a positive thing. JESSICA: The known unknowns. PAUL: Known unknowns. It takes unknown unknowns, which the kind of elephant in the room, and at least gets them up as known unknowns that you can then have a conversation around. Because there's often this situation of a question that somebody's afraid to ask and maybe they're new to the team, or maybe they're just not comfortable asking that type of question. But it gives you actually a map of that ignorance so you can kind of see oh, there's this whole area here that just has a bunch of pink stickies. So that's probably not an area we're ready to work on and we should prioritize. Actually, if this is an area that we need to be working on soon, we should prioritize getting answers to these questions by maybe we need to do a proof of concept, or some UX work, or maybe some kind of prototyping around this area, or like you said, Jess, maybe the person that knows the answers to these questions is just not in this session right now and so, we need to follow up with them, get whatever answers we need, and then come back and revisit things. JESSICA: So you identify areas of risk. PAUL: Yes. Areas of risk, both from a product perspective and also from a technical perspective as well. DAMIEN: So what does it take to have one of these events, or to facilitate one of these events? How do you know when you're ready and you can do it? PAUL: So I've done EventStorming [chuckles] as a conference activity in a hallway with sticky notes and we say, “Okay, let's as a little bit of an icebreaker here –” I usually you do the story of Cinderella. “Let's pick the Disney story of Cinderella and we'll just EventStorm this out. Just everyone, here are some orange sticky notes and a Sharpie, just write down some things that you remember happening in that story,” and then everyone writes a few. We post it up on the hallway wall and then we sequence them as a timeline and then we can basically build up that story in about 5, or 10 minutes from scratch. With a business process, it's not that different. It's like, okay, we're going to do returns, or something like that and if people are already familiar with the technique, then just give them a minute, or so to think of some things that they know that would happen in that process. And then they do that individually and then we just post them up on the timeline and then sequence them as a group and it can happen really quickly. And then everything from there is refinement. Iteration and refinement over what you've put up as that initial skeleton. DAMIEN: Do you ever find that a team comes back a week, or a day, or a month later and goes, “Oh, there is this big gap in our narrative because nobody in this room understood the warehouse needed to be reordered in order to send this thing down”? PAUL: Oh, for sure. Sometimes it's big gaps. Sometimes it's a huge cluster of pink sticky notes that represents an area where there's just a lot of risk and unknowns that the team maybe hasn't thought about all that much. Like you said, it could be there's this third-party thing that it wasn't until everyone got in a room and kind of started to map it out, that they realized that there was this gap in their knowledge. JESSICA: Yeah. Although, you could completely miss it if there's nobody from the warehouse in the room and nobody has any idea that you need to tell the warehouse to expect this return. PAUL: Right and so, part of that is putting a little bit of thought into who would need to be part of this and in a certain way, playing devil's advocate in terms of what don't we know, what haven't we thought of. So it encourages that sense of curiosity with this and it's a little bit different from – Some of the listeners maybe have experienced user story mapping and other techniques like that. Those tend to be focused on understanding a process, but they're very much geared towards okay, how do we then figure out how we're going to code up this feature and how do we slice it up into stories and prioritize that. So it's similar in terms of sticky notes, but the emphasis in EventStorming is more on understanding together, the problem that we're trying to address from a business perspective. JESSICA: Knowledge pulling. PAUL: Yeah. Knowledge pulling, knowledge distillation, those types of idea years, and that kind of mindset. So not just jumping straight to code, but trying to get a little bit of a shared understanding of what all is the thing that we're trying to actually work on here. JESSICA: Eric Evans calls it knowledge crunching. PAUL: Yes, Eric called it knowledge crunching. DAMIEN: I love that phrase, that shared understanding. That's what we, as product teams, are generating is a shared understanding both, captured in our documentation, in our code, and before that, I guess on large sheets of butcher paper. [laughs] PAUL: Well, and it could be a quick exercise of okay, we're going to be working on some new feature and let's just spend 15 minutes just mapping it out to get a sense of, are we on the same page with this? JESSICA: Right, because sometimes it's not even about we think we need to know something, it's do we know enough? Let's find out. PAUL: Right. JESSICA: And is that knowledge shared among us? PAUL: Right, and maybe exposing, like it could be as simple as slightly different terminology, or slightly different understanding of terminology between people that can have a big impact in terms of that. I was teaching a workshop last night where we were talking about this, where somebody had written the event. So there was a repair process that a third-party repair company would handle and then the event that closed that process off, they called case closed. So then the question becomes well, what does case closed mean? Because the word case – [overtalk] JESSICA: [laughs] It's like what's the definition of done? PAUL: Right, exactly. [laughter] Because that word case didn't show up anywhere earlier in the process. So is this like a new concept? Because the thing that kicks off the process is repair purchase order created and at the end of the process, it's said case closed. So then the question becomes well, is case closed really, is that a new concept that we actually need to implement here? Or is this another way of saying that we are getting a copy of that repair purchase order back that and it's been updated with details about what the repair involved? Or maybe it's something like repair purchase order closed. So it's kind of forcing us to clarify terminology, which may seem a little bit pedantic, but that's what's going to end up in the code. If you can get some of those things exposed a little earlier before you actually jump to code and get people on the same page and surface any sort of differences in terminology and misunderstandings, I think that can be super helpful for everyone. JESSICA: Yeah. Some people say it's just semantics. Semantics' meaning, its only meaning, this is only about out what this step actually means because when you put it in the code, the code is crystal clear. It is going to do exactly what it does and whether that clarity matches the shared understanding that we think we have oh, that's the difference between a bug and a working system. DAMIEN: [laughs] That's beautiful. It's only meaning. [laughs] JESSICA: Right? Yeah. But this is what makes programming hard is that pedanticness. The computer is the ultimate pedant. DAMIEN: Pedant. You're going to be pedantic about it. [laughter] PAUL: I see what you did there. [laughter] DAMIEN: And that is the occupation, right? That is what we do is look at and create systems and then make them precise. JESSICA: Yeah. DAMIEN: In a way that actually well, is precise. [laughs] JESSICA: Right, and the power of our human language is that it's not precise, that it allows for ambiguity, and therefore, a much broader range of meaning. But as developers, it's our job to be precise. We have to be precise to the computers. It helps tremendously to be precise with each other. DAMIEN: Yeah, and I think that's actually the power of human cognition is that it's not precise. We are very, very fuzzy machines and anyone who tries to pretend otherwise will be greatly disappointed. Ask me how I know. [laughter] PAUL: Well, and I think what I'm trying to do with something like EventStorming is to embrace the fuzziness, is to say that that's actually an asset and we want to embrace that and expose that fuzziness, that messiness. Because the processes we have and work with are often inherently complex. We are trying to provide some visual representation of that so we can actually get our head around, or our minds around the language complexities, the meanings, and drive in a little bit to that meaning. JESSICA: So when the sticky notes pile on top of each other, that's a feature. PAUL: It is. Going back to that example I was just talking about, let's say, there's a bunch of, like we do the initial part of this for a minute, or so where people are creating sticky notes and let's say, we end up with four, or five sticky notes written by different people on top of each other that end up on the timeline that all say pretty much the same thing with slight variations. JESSICA: Let's say, case closed, request closed. PAUL: Case closed, repair purchase order closed, repair purchase order updated, repair purchase order sent. So from a meaning perspective, I look at that and I say, “That's gold in terms of information,” because that's showing us that there's a richness here. Firstly, that's a very memorable thing that's happening in the timeline – [overtalk] JESSICA: Oh and it has multiple things. PAUL: That maybe means it's a key event. Right, and then what is the meaning? Are these the same things? Are they different things? Maybe we don't have enough time in that session to dig into that, but if we're going to implement something around that, or work with something around that, then we're going to at some point need some clarity around the language, the terminology, and what these concepts mean. Also, the sequence as well, because it might be that there's actually multiple events being expressed there that need to be teased apart. DAMIEN: You used this phrase a couple times, “key event,” and since you've used it a couple times, I think it might be key. [laughter] Can you tell us a little bit about what a key event is? What makes something a key event? PAUL: Yeah, the example I like to use is from the Cinderella story. So if you think about the story of Cinderella, one of the things, when people are doing that as an icebreaker, they always end up being multiple copies of the event that usually is something like shoe lost, or slipper lost, or glass slipper lost. There's something about that event that makes it memorable, firstly and then there's something about that event that makes it pivotal in the story. For those that are not familiar with the story [chuckles]—I am because I've EventStormed this thing maybe a hundred times—but there's this part. Another key event is the fairy godmother showing up and doing the magic at the start and she actually describes a business policy. She says, “The magic is going to run out at midnight,” and like all business policies, it's vague [laughter] and it's unclear as to what it means because – [overtalk] JESSICA: The carriage disappears, the dress disappears, but not the slipper that fell off. PAUL: Exactly. There's this exception that for some bizarre reason, to move the plot forward, the slipper stays. But then the definition of midnight is very hazy because what she's actually describing, in software terms, is a long running process of the clock banging 12 times, which is what midnight means is the time between the first and the twelfth and during that time, the magic is slowly unraveling. JESSICA: So midnight is a duration, not an instant. PAUL: Exactly. Yes, it's a process, not an event. So coming back to the question that Damien asked about key events. That slipper being lost is a key event in that story, I think because it actually is a shift in narrative. Up until that point in the story, it's the story of Cinderella and then after that, once the slipper is lost, it becomes the story of the prince looking for Cinderella. And then at the end, you get the day tomorrow, the stuff that happens with that slipper at the end of the story. Another key event would be like the fairy godmother showing up and doing the magic. DAMIEN: [chuckles] It seems like these are necessary events, right? If the slipper is not lost, if the fairy godmother doesn't do magic, you don't have the story of Cinderella. PAUL: Right. These are narrative turns, right? DAMIEN: Yeah. PAUL: These are points of the story shifts and so, key events can sometimes be a narrative shift where it's driving the story forward in a business process. Something like, let's say, you're working on an e-commerce system, like order submitted is a key event because you are adding items to a shopping cart and then at some point, you make a decision to submit the order and then at that point, it transitions from order being a draft thing that is in a state of flux to it actually becomes essentially immutable and gets passed over to fulfilment. So there's a shift in responsibility and actor between these two as well just like between Cinderella and the prince. JESSICA: A shift in who is driving the story forward. PAUL: Right. Yeah. So it's who is driving the story forward. So these key events often function as a shift in actor, a shift in who's driving the story forward, or who has responsibility. They also often indicate a handoff because of that from one group to another in an organization. Something like a sales process that terminates in contract signed. That key event is also the goal of the sales process. The goal is to get to contract signed and then once that happens, there's usually a transition to say, an onboarding group that actually onboards the new customer in the case of a sales process for a new customer, or in e-commerce, it would be the fulfillment part, the warehousing part that Jess was talking about earlier. That's actually responsible for the fulfillment piece, which is they take that order, they create a package, they put all the items in the package, create the shipping label, and ship it out to the customer. JESSICA: And in domain-driven design, you talked about the shift from order being a fluid thing that's changing as people add stuff to their cart to order being immutable. The word order has different meanings for the web site where you're buying stuff and the fulfillment system, there's a shift in that term. PAUL: Right, and that often happens around a key event, or a pivotal event is that there's a shift from one, you might think of it as context, or language over to another. So preorder submission, it's functioning as a draft order, but what it's actually typically called is a shopping cart and a shopping cart is not the same as an order. It's a great metaphor because there is no physical cart, but we all know what that means as a metaphor. A shopping cart is a completely different metaphor from an order, but we're able to understand that thread of continuity between I have this interactive process of taking items, or products, putting them in the shopping cart, or out again. And then at some point that shopping cart, which is functioning as a draft order, actually it becomes an order that has been submitted and then it gets – [overtalk] DAMIEN: Yeah, the metaphor doesn't really work until that transition. You have a shopping cart and then you click purchase and now what? [laughs] You're not going to the register and ringing it up, that doesn't make any sense. [chuckles] The metaphor kind of has to end there. JESSICA: You're not leaving the cart in the corral in the parking lot. [laughter] PAUL: Well, I think what they're trying to do is when you think about going through the purchase process at a store, you take your items up in the shopping cart and then at that point, you transition into a financial transaction that has to occur that then if you were at a big box electronic store, or something, eventually, you would make the payment. You would submit payment. That would be the key events and that payment is accepted and then you receive a receipt, which is kind of the in-person version of a record of your order that you've made because you have to bring the receipt back. DAMIEN: It sort of works if the thing you're putting in the shopping cart are those little cards. When they don't want to put things on the shelf, they have a card, you pick it up, and you take it to register. They ring it up, they give you a receipt, and hopefully, the thing shows up in the mail someday, or someone goes to the warehouse and goes gets it. PAUL: We've all done that. [chuckles] Sometimes it shows up. Sometimes it doesn't. JESSICA: That's an interesting point that at key events, there can be a shift in metaphor. PAUL: Yes. Often, there is. So for example, I mentioned earlier, a sales process ending in a contract and then once the contract is signed, the team – let's say, you're signing on a new customer, for a SaaS service, or something like that. Once they've signed the contract, the conversation isn't really about the contract anymore. It's about what do we need to do to onboard this customer. Up until that point, the emphasis is maybe on payment, legal disclosures, and things like that. But then the focus shifts after the contract is signed to more of an operational focus of how do we get the data in, how do we set up their accounts correctly, that type of thing. JESSICA: The contract is an input to that process. PAUL: Yes. JESSICA: Whereas, it was the output, the big goal of the sales process. PAUL: Yes, exactly. So these key events also function from a systems perspective, when you think about moving this to code that event then becomes almost like a message potentially. Could be implemented as say, a message that's being passed from the sales system through to the onboarding system, or something like that. So it functions as the integration point between those two, where the language has to be translated from one context to another. JESSICA: And it's an integration point we can define carefully so that makes it a strong boundary and a good place to divide the system. DAMIEN: Nice. PAUL: Right. So that's where it starts to connect to some of the things that people really care about these days in terms of system decomposition and things like that. Because you can start thinking about based on a process view of this, based on a behavior view of this, if we treat these key events as potential emergent boundaries in a process, like we've been describing, that we discover through mapping out the process, then that can give us some clues as to hmm maybe these boundaries don't exist in the system right now, but they could. These could be places where we start to tease things apart. JESSICA: Right. Where you start breaking out separate services and then when you get down to the user story level, the user stories expect a consistent language within themselves. You're not going to go from cart to return purchase in a case. PAUL: [laughs] Right. JESSICA: In a single user story. User stories are smaller scope and work within a single language. PAUL: Right and so, I think the connection there in my mind is user stories have to be written in some kind of language, within some language context and mapping out the process can help you understand where you are in that context and then also understand, like if you think about a process that maybe has a sales part of the process and then an onboarding part, it'll often be the case that there's different development teams that are focusing on different parts of that process. So it provides a way of them seeing what their integration point is and what might need to happen across that integration point. If they were to either integrate to different systems, or if they're trying to tease apart an existing system. To use Michael Feathers' term, what might be a “scene” that we could put in here that would allow us to start teasing these things apart. And doing it with the knowledge of the product people that are part of the visualization, too is that this isn't something typically that engineers do exclusively from a technical perspective. The idea with EventStorming is you are also bringing in other perspectives like product, business, stakeholders, and anyone that might have more of that business perspective in terms of what the goals of the process are and what the steps are in the process. MID-ROLL: And now a quick word from our sponsor. I hear people say the VPNs have a reputation for slowing down your internet speed, but not with NordVPN, because it's the fastest VPN in the world. I don't have to sacrifice internet speed for better security. With NordVPN, my internet traffic is routed through a secure encrypted tunnel, which protects my data and privacy. I can also have it on up to six devices like my laptop, phone, TV, iPad—all my devices are protected. Grab your exclusive NordVPN deal by going to nordvpn.com/gtc, or use the code GTC to get a huge discount on your NordVPN plan plus one additional month for free. Plus, a bonus gift! It's completely risk-free with Nord's 30-day money back guarantee. JESSICA: As a developer, it's so important to understand what those goals are, because that lets us make good decisions when we're down in the weeds and getting super precise. PAUL: Right, I think so. I think often, I see teams that are implementing stories, but not really understanding the why behind that in terms of maybe they get here's the functionality on delivering and how that fits into the system. But like I talked about before, when you're driving a process towards a key event, that becomes the goal of that subprocess. So the question then becomes how does the functionality that I'm going to implement that's described in this user story actually move people towards that goal and maybe there's a better way of implementing it to actually get them there. DAMIEN: Yeah, it's always important to keep that in mind, because there's always going to be ambiguity until you have a running system, or ran system, honestly. JESSICA: Yeah! DAMIEN: There's always going to be ambiguity, which it is our job as people writing code to manage and we need to know. Nobody's going to tell us exactly what's going to happen because that's our job. PAUL: Right. JESSICA: It's like if the developer had a user story that Cinderella's slipper fell off, but they do didn't realize that the goal of that was that the prince picked it up, then they might be like, “Oh, slipper broke. That's fine.” PAUL: Yeah. JESSICA: It's off the foot. Check the box. PAUL: Let's create a glass slipper factory implementer object [laughter] so that we can just create more of those. JESSICA: Oh, yeah. What, you wanted a method slip off in one piece? You didn't say that. I've created crush! PAUL: Right. [laughter] Yeah. So I think sometimes there's this potential to get lost in the weeds of the everyday development work that is happening and I like to tie it back to what is the actual story that we're supporting. And then sometimes what people think of as exception cases, like an example might be going back to that merchant return example is what if they issue the shipper label, but the buyer never receives it. We may say, “Well, that's never going to happen,” or “That's unlikely.” But visualizing that case, you may say, “That's actually a strong possibility. How do we handle that case and bake that into the design so that it actually reflects what we're trying to do?” JESSICA: And then you make an event that just triggers two weeks later that says, “Check whether customer received label.” PAUL: Yes, exactly. One thing you can do as well is like – so that's one possibility of solving it. The idea what EventStorming can let you do is say, “Well, that's one way of doing it. Are there any other options in terms of how we could handle this, let's visualize.” With any exception case, or something, you could say, “Well, let's try solving this a few different ways. Just quickly come up with some different ideas and then we can pull the best of those ideas into that.” So the idea when you're modeling is to say, “Okay, well, there's probably more than one way to address this. So maybe let's get a few ideas on the table and then pick the best out of these.” JESSICA: Or address it at multiple levels. PAUL: Yes. JESSICA: A fallback for the entire process is customer contact support again. PAUL: Right, and that may be the simple answer in that kind of case. What we're trying to do, though is to visualize that case as an option and then talk about it, have a structured conversation around it, say, “Well, how would we handle that?” Which I think from a product management perspective is a key thing to do is to engage the engineers in saying, “Well, what are some different ways that we could handle this and solve this?” If you have people that are doing responsibility primarily for testing in that, then having them weigh in on, well, how would we test this? What kind of test cases might we need to handle for this? So it's getting – [overtalk] JESSICA: How will we know it worked? PAUL: Different perspectives and opinions on the table earlier rather than later. JESSICA: And it's cheap. It's cheap, people. It's a couple hours and a lot of post-its. You can even buy the generic post-its. We went to Office Depot yesterday, it's $10 for 5 little Post-it pads, [laughter] or 25 Office Depot brand post-it pads. They don't have to stay on the wall very long; the cheap ones will work. PAUL: [laughs] So those all work and then it depends if you have shares in 3M, I guess, with you. [laughter] Or Office Depot, depending which road you want to go down. [laughter] JESSICA: Or if you really care about that shade of pale purple, which I do. PAUL: Right. I mean, what's been fascinating to me is in the last 2 years with switching to remote work and that is so much of, 95% of the EventStorming I do these days is on a collaborative whiteboard tool like Miro, or MURAL, which I don't know why those two product names are almost exactly the same. But then it's even cheaper because you can sign up for a free account, invite a few people, and then just start adding sticky notes to some virtual whiteboard and do it from home. There's a bunch of things that you can do on tool like that with copy pasting, moving groups of sticky notes around, rearranging things, and ordering things much – [overtalk] JESSICA: And you never run out of wall. PAUL: Yeah. The idea with the butcher's paper in a physical workshop, in-person workshop is you're trying to create a sense of unending modeling space that you can use. That you get for free when you use online collaborative whiteboarding tool. It's just there out of – [overtalk] JESSICA: And you can zoom in. PAUL: And you zoom in and out. Yeah. There's a – [overtalk] JESSICA: Stickies on your stickies on your stickies. [laughter] I'm not necessarily recommending that, but you can do it. PAUL: Right. The group I was working with last night, they'd actually gone to town using Miro emojis. They had something bad happen in the project and they've got the horror emoji [laughter] and then they've got all kinds of and then copy pasting images off the internet for things. JESSICA: Nice. PAUL: So yeah, can make it even more fun. JESSICA: Okay. So it's less physical, but in a lot of ways it can be more expressive, PAUL: I think so. More expressive and just as engaging and it can break down the geographical barriers. I've done sessions where we've had people simultaneously spread in multiple occasions across the US and Europe in the same session, all participating in real-time. If you're doing it remote, I like to keep it short. So maybe we do like a 2-hour session with a 10- or 15-minute break in the middle, because you're trying to manage people's energy and keep them focused and it's hard to do that when you just keep going. MANDY: I kind of want to talk a little bit about facilitation and how you facilitate these kind of workshops and what you do, engage people and keep them interested. PAUL: Yeah. So I think that it depends a little bit on the level of detail we're working at. If it's at the level of a few team members trying to figure out a feature, then it can be very informal. Not a lot of facilitation required. Let's just write down what the goal is and then go through the process of brainstorming a few stickies, laying it out, and then sequencing it as a timeline, adding questions. It doesn't require a lot of facilitation hand. I think the key thing is just making sure that people are writing down their questions and that it's time boxed. So quitting while people are still interested and then [laughter] at the end, before you finish, having a little bit of a conversation around what might the next steps be. Like what did we learn? You could do a couple of minutes retrospective, add a sticky note for something you learned in this session, and then what do you see as our next steps and then move on from there with whatever action items come out of that. So that one doesn't require, I think a lot of facilitation and people can get up and running with that pretty quickly. I also facilitate workshops that are a lot more involved where it's at the other end of the spectrum, where it's a big picture workshop where we're mapping out maybe an entire value stream for an organization. We may have a dozen, 20 people involved in a session like that representing different departments, different organizational silos and in that case, it requires a lot more planning, a lot more thinking through what the goal of the workshop is, who would you need to invite? Because there's a lot more detail involved and a lot more people involved, that could be four, or five multi-hour sessions spread over multiple days to be able to map out an entire value stream from soup to nuts. And then usually the goal of something like that is some kind of system modernization effort, or maybe spinning up a new project, or decomposing a legacy system, or even understanding what a legacy system does, or process improvement that will result inevitably in some software development in certain places. I did a workshop like that, I think last August and out of that, we identified a major bottleneck in the process that everyone in the workshop, I think it was just a bunch of pink stickies in one area that it got called the hot mess. [laughter] It was one area and what was happening was there were several major business concerns that were all coupled together in this system. They actually ended up spinning up a development team to focus on teasing apart the hot mess to figure out how do we decompose that down? JESSICA: Yes. PAUL: As far as I know, that effort was still ongoing as of December. I'm assuming that's still running because it was prioritized as we need to be able to decompose this part of this system to be able to grow and scale to where we want to get to. JESSICA: Yeah. That's a major business risk that they've got. They at least got clarity about where it is. PAUL: Right. Yeah, and what we did from there is I coached the developers through that process over several months. So we actually EventStormed it out at a much lower level. Once we figured out what the hot mess was, let's map it out and then they combined that with some flow charting and a bunch of other more engineering, kind of oriented visualization techniques, state machines, things like that to try and get a handle on what was going on. DAMIEN: We'll get UML in there eventually, right? PAUL: Eventually. [laughter] You can't do software development without some kind of state machine, sequence diagram. JESSICA: And it's approximating UML. You can't do it. You can't do it. [laughter] You will either use it, or you will derive a pigeon form of it. PAUL: Right. Well, I still use it for state diagrams and sequence diagrams when I'm down at that technical level. What I find is that there's a certain level of rigor that UML requires for a sequence diagram, or something like that that seems to get in the way of collaboration. So EventStorming sacrifices some of that rigor to be able to draw in everyone and have a low bar of entry to having people participate. DAMIEN: That's a huge insight. Why do you think that is? Is it the inability to hold that much information at a high level of rigor, or just people not used to working at that sort of precision and rigor? PAUL: I think that when I'm working with people that are not hands-on coders, they are in the everyday, like say, product managers, or stakeholders, to use those terms. They're in the everyday details of how the business process works and they tend to think of that process more as a series of steps that they're going through in a very specific kind of way. Like, I'm shipping a certain product, or supporting the shipping. or returning of certain types of products, those kinds of things. Whereas, as developers, we tend to think of it more in terms of the abstractions of the system and what we're trying to implement in the code. So the idea of being able to tell the story of a process in terms of the events that happen is a very natural thing, I find for people from a business perspective to do because that's how they tend to think about it. Whereas, I think as programmers, we're often taught not so much to think about behavior as a sequence of things happening, but more as the structure we've been taught to design in terms of structures and relationships rather than flow. JESSICA: Yet that's changing with event sourcing. PAUL: I think so. EventStorming and event sourcing become a very natural complement for each other and even event-driven architecture, or any event-driven messaging, whatever it happens to be. The gap between modeling using EventStorming and then designing some kind of event-driven distributed system, or even not distributed, but still event-driven is much more natural than trying to do something like an entity relationship diagram and they'd get from that to some kind of meaningful understanding of what's the story of how these functions and features are going to work. JESSICA: On the topic of sacrificing rigor for collaboration, I think you have to sacrifice rigor to work across content texts because you will find contradictions between them. The language does have different meaning before and after the order is submitted and you have to allow for that in the collaboration. It's not that you're not going to have the rigor. It's more that you're postponing it, you're scoping it as separately. This meeting is about the higher level and you need completeness over consistency. DAMIEN: Yeah. I feel like almost you have to sacrifice rigor to be effective in most roles and in that way, sacrifice is even the wrong word. Most of the things that we do as human beings do not allow for the sort of rigor of the things that we do as software engineers and things that computers do. JESSICA: Yeah. DAMIEN: And it's just, the world doesn't work that way. PAUL: Right. Well, and it's the focus in EventStorming on exploration, discovery, and urgent ideas versus rigor is more about not so much exploring and discovery, but about converging on certain things. So when someone says pedant and the other person says pedant, or vice versa, that tends to shut down the conversation because now you are trying to converge on some agreed upon term versus saying, “Well, let's explore a bunch of different ways this could be expressed and temporarily defer trying converge on.” JESSICA: Later in Slack, we'll vote. PAUL: Yes. JESSICA: Okay. So standardize later. PAUL: Yes. Standardize, converge later, and for now, let's kind of hold that at arm's length so that we can uncover and discover different perspectives on this in terms of how the story works and then add regulator when we go to code and then you may discover things in code where there are implicit concepts that you then need to take back to the modeling to try and figure out well, how do we express this? Coming up with some kind of term in the code and being able to go from there. JESSICA: Right. Some sort of potential return because it hasn't happened yet. PAUL: Exactly. So maybe it's a potential, maybe it's some other kind of potential return, like pending return, maybe we don't call it a return at all. JESSICA: Or disliked item because we could – or unsatisfactory item because we could intercept that and try to like, “Hey, how about we send you the screws that we're missing?” PAUL: Right. Yeah, maybe the answer is not a return at all. JESSICA: Yeah. PAUL: But maybe the case is that the customer says they want to return it, but you actually find a way to get them to buy more stuff by sending them something else that they would be happy with. So the idea is we're trying to promote discovery thinking when we are talking about how to understand certain problems and how to solve them rather than closing off options too soon. MANDY: So, Paul, I know you do give these workshops. Is there anything? Where can people find you? How can people learn more? How can people hire you to facilitate a workshop and get in touch with you? PAUL: Okay. Well, in terms of resources, Damien had mentioned at the beginning, I have an eBook up on Leanpub, The EventStorming Handbook, so if people are interested in learning more, they can get that. And then I do workshop facilitation and training through my company, Virtual Genius. They can go to virtualgenius.com and look at what training is available. It's all online these days, so they can participate from anywhere. We have some public workshops coming up in the coming months. And then they can find me, I'm @ThePaulRayner on Twitter, just to differentiate me from all the indefinite articles that are out there. [laughter] MANDY: Sounds good. Well, let's head into reflections. I can start. I just was thinking while we were talking about this episode, about how closely this ties into my background in professional writing, technical writing to be exact, and just how you have this process to lay out exactly what steps need to be taken and to differentiate when people say the same things and thinking about, “Well, they're saying the same things, but the words matter,” and to get pedantic, that can be a good thing, especially when you are writing technical documents and how-tos. I remember still, my first job being a technical writer and looking at people in a machine shop who it was like, first, you do this, then you do this, then you do this and to me, I was like, “This is so boring.” But it makes sense and it matters. So this has been a really good way for me to think about it as a newbie just likening it to technical writing. JESSICA: Yeah. Technical writing has to tell that story. DAMIEN: I'm going to be reflecting on this has been such a great conversation and I feel like I have a lot of familiarity with at least a very similar process. I brought up all my fears that come from them, which is like, what if we don't have the right person in the room? What if there's something we didn't discover? And you said something about how you can do this in 5 minutes and how you can do this in 15 minutes and I realized, “Oh, this process doesn't have to be the 6-hour things that I've participated in and facilitated in. It can also be done more smaller and more iteratively and I can bring this sort of same process and thought process into more of the daily work.” So that's super helpful for me. JESSICA: I want to reflect on a phrase that Paul said and then Damien emphasized, which is shared understanding. It's what we're trying to get to in EventStorming across teams and across functions. I think it's also like what we're constantly trying to get to as humans. We value shared understanding so much because we're trapped in our heads and my experience in my head is never going to be the same as your experience in your head. But at some point, we share the same physical world. So if we can get that visual representation, if we can be talking together about something in that visual world, we can pass ideas back and forth more meaningfully. We can achieve this shared understanding. We can build something together. And that feels so good. I think that that constant building of shared understanding is a lot of what it means to be human and I get really excited when I get to do that at work. PAUL: I think I would just add to that as well is being human, I'm very much aware of limitations in terms of how many ideas I can hold in my head at any one time. I know the times where I've been in the experience that many describe where someone's giving me a list of steps to follow and things like that, inevitably I'm like, “Well, I remember like the first two, maybe three,” and then everything after that is kind of Charlie Brown. What, what, why? [laughter] I don't remember anything they said from that point on. But when I can visualize something, then I can take it in one go. I can see it and we're building it together. So for me, it's a little bit of a mind hack in terms of getting over the limitations of how many things I can keep in my mind at one time. Also, like you said, Jess, getting those things out of my mind and out of other people's minds into a shared space where we can actually collaborate on them together, I think that's really important to be able to do that in a meaningful way. MANDY: Well, thank you so much for coming on the show today, Paul. We really enjoyed this discussion. And if you, as listeners, would like to continue this conversation, please head over to Patreon.com/greaterthancode. We have a Slack channel. You can pledge and donate to sponsor us as little as a dollar and you can come in, hang out, talk with us about these episodes. If not, give me a DM on Twitter and let me know, and I'll let you in anyway because [laughter] that's what we do here at Greater Than Code. PAUL: Because Mandy's awesome. MANDY: [laughs] Thank you, Paul. With that, thank you everyone for listening and we'll see you again next week. Special Guest: Paul Rayner.

How to Trust Again – Justin Searls (https://www.youtube.com/watch?v=mu8KmhPa5Oc) Why has trust become so rare in the software industry? Developers don't trust their own ability to program, teammates don't trust each other to write quality code, and organizations don't trust that people are working hard enough to deliver on time. This talk by Justin Searls is a reflection on the far-reaching consequences distrust can have for individuals, teams, and organizations and an exploration of what we stand to gain by adopting a more trustful orientation towards ourselves and each other. 01:57 - Justin's Superpower: Having Bad Luck and Exposing Software Problems 04:05 - Breaking Down Software & Teams * Shared Values * Picking Up on Smells to Ask Pointed Questions * Beginner's Mindset * RailsBridge (https://www.bridgetroll.org/) 12:49 - Trust Building * Incremental Improvement * What Got You Here Won't Get You There: How successful people become even more successful by Marshall Goldsmith (https://www.amazon.com/What-Got-Here-Wont-There/dp/1846681375/ref=asc_df_1846681375/?tag=hyprod-20&linkCode=df0&hvadid=312118059795&hvpos=&hvnetw=g&hvrand=6049806314701265278&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9006718&hvtargid=pla-525029467829&psc=1) * Credibility * Reliability * Intimacy * Selfless Motivation * Authenticity * Detecting Authenticity * Laziness Does Not Exist (https://humanparts.medium.com/laziness-does-not-exist-3af27e312d01) 29:14 - Power Politics & Privilege * Leadership Empathy * Safety * Exposure; “Don't Cross The Net” * Masking (https://en.wikipedia.org/wiki/Masking_(personality)) 42:06 - Personal Growth & “Bring Your Whole/True Self” * RubyConf 2019 - Keynote: Lucky You by Sandi Metz (https://www.youtube.com/watch?v=c5WWTvHB_sA) How to Trust Again – Justin Searls (https://www.youtube.com/watch?v=mu8KmhPa5Oc) This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: PRE-ROLL: Software is broken, but it can be fixed. Test Double's superpower is improving how the world builds software by building both great software and great teams. And you can help! Test Double is hiring empathetic senior software engineers and DevOps engineers based in the United States and Canada. We work in Ruby, JavaScript, Elixir and a lot more. Test Double trusts developers with autonomy and flexibility at a remote, 100% employee-owned software consulting agency. Looking for more challenges? Enjoy lots of variety while working with the best teams in tech as a developer consultant at Test Double. Find out more and check out remote openings at link.testdouble.com/greater. That's link.testdouble.com/greater. JACOB: Hello and welcome to Episode 270 of the Greater Than Code podcast. My name is Jacob Stoebel and I'm joined with my co-panelist, Mae Beale. MAE: And I'm joined with another panelist, Chelsea Troy. CHELSEA: Hi, I'm Chelsea and I'm here with our guest, Justin Searls. He's a co-founder and CTO at Test Double, a consulting agency on a mission to improve how the work writes software. His life's work is figuring out why so many apps are buggy and hard to use, why teams struggle to foster collaboration and trust, and why it's so hard for organizations to get traction building great software. The Test Double Agents work with clients to improve in all of these ways and more. Hi, Justin! How are you today? JUSTIN: Hello. I'm great. Thank you so much for having me. CHELSEA: Of course. So we like to kick off our sessions by asking you, what is your superpower and how did you acquire it? JUSTIN: Well, one superpower might be that I like to give counterintuitive answers to questions and [laughs] my answer to this would be that I have really, really bad luck software and hardware. My entire life has just fallen over for me left and right. Bugs come and seek me out. In college, I was in the computer science program and so, I was around a lot of computers, like Linux data centers and stuff, and I think I went through either personally, or in the labs that I used 20 hard drive failure years in 4 years. People started joking that I had an EMP around me. So I started to just decide to lean into that not so much as an identity necessarily, but as a specialty of root cause analysis of like, why do things fail? When I see a bug, what does that mean? And to dig in to how to improve quality in software and that then extended to later in my career, when I was working on delivery teams, like building software for companies and institutions. That meant identifying more root causes about what's leading to project failure, or for teams to break down. Now I'm kind of moving, I guess, popping the stack another layer further. I'm starting to ask what are the second and third order consequences of software failing for people having for others? I see this in my family who are non-software industry family members, when they encounter a bug and I'm watching them encounter a bug, their reaction is usually to think that they're the ones who screwed up, that they're stupid, that they just can't figure it out. I'm literally watching software that somebody else wrote far away just fail and that's just no good, right? So I think that the fact that I just so easily expose problems with software and sometimes the teams that make it almost effortlessly, it's really given me a passion and a purpose to improve and find opportunities to just make it a little bit better. MAE: When you talk about software and/or teams breaking down and you're mentioning bugs. So I'm assuming that that's mostly what you mean by breaking down? I'm curious if you have kind of a mental model of software always breaks down these four ways. Teams always break down these three ways. I don't know if you have any reference texts, or things that you've come across as far as like a mental model for what is the world of breaking down? How do we characterize it? JUSTIN: That's a great question and I feel like having been basically doing this for 15 years now, I should be prepared with a better answer. I've always resisted building I guess, the communicative version of an abstraction, or a framework for categorizing, simplifying, and compartmentalizing the sort of stuff that I experience. In some ways, my approach [laughs] is the human version of machine learning where I have been so fortunate, because I've been a consultant my entire career, to be exposed to so many companies and so many teams that that has developed in me a pattern recognition system that even I don't necessarily understand—it's kind of a black box to me—where I will pick up on little smells and seemingly incidental cues and it'll prompt me to develop a concern, or ask a pointed question about something seemingly unrelated, but that I've come to see as being associated with that kind of failure. I think your question's great. I should probably spend some time coming up with quadrants, or a system that distills down some of this. But really, when I talk about bugs, that is a lagging indicator of so many things upstream that are not necessarily code related. One of the reasons I want to be on the show here and talk to you all the day is because I've been thinking a lot about trust and interpersonal relationships starting with us as individuals and whether we trust the work that we're doing ourselves, or trust ourselves to really dive in and truly understand the stuff that we're building versus feel like we need to go and follow some other pattern, or instructions that are handed to us. To kind of try to answer your question more directly, when I see teams fail, it usually comes down to a lack of authentic, empathetic, and logical targeted relationships where you have strong alignment about like, why are we in this room? Why are we working together? How do we best normalize on an approach so that when any person in any role is operating that is consistent with if somebody else on the team had been taking the same action that they would operate in the same way so that we're all marching in the same direction? That requires shared values and that requires so many foundational things that are so often lacking in teams as software is developed today, where companies grow really fast. The pay right now is really, really high, which is great, but it results in, I think a little bit of a gold rush mentality to just always be shipping, always be hustling, always be pushing. As there's less time for the kind of slack that we need to think about—baking in quality, or coming back to something that we built a couple weeks ago and that maybe we've got second considerations about. Because there's that kind of time, there's even less time sometimes for the care and feeding that goes into just healthy relationships that build trust between people who are going to be spending a third of their life working together. CHELSEA: You mentioned picking up on little smells that then lead you to ask pointed questions. I think that's really interesting because that kind of intuition, I've found is really essential to being a consultant and figuring out how to ask those questions as well. Can you provide some examples of situations like that? JUSTIN: Yeah. I'll try to think of a few. I had a client once that was undergoing—this is 10 years ago now—what we called at the time, an agile transformation. They were going from a Waterfall process of procuring 2 year, $2 million contracts and teams to build big design upfront systems that are just thrown over a fence, then a team would go and work on it, and then it would go through a proper user acceptance testing onto something more agile, I guess. Adopting Scrum and extreme programming, interpersonal process, and engineering practices. That was just meant to be more, I guess, iterative of course, innovative, collaborative, more dynamic, and able to let the team drive its own destiny. All that sounds great and you walk into the team room and they just invested millions of dollars into this beautiful newly restored historic building. I sit down with everyone and I look at them and they've got the cool desks at the time and cool open office because those were still considered cool. I sat down and I couldn't help, but—[chuckles] this is real silly. I couldn't help but notice that there was a pretty strong smell, [laughs] body odor throughout the whole room and it wasn't one person. I'm not picking on somebody here. It was that the interpersonal relationships were so afraid, the fear of failure was so strong, and the deadline pressure that had been exerted from on high was so overwhelming that there was no safety in the room. People were just scared at their job all day long and it was having a material impact that only an outsider who's walking in at 2:00 PM on a Friday detect because everyone else had acclimated. So I walked in and I was like, “Well, what do I –?” [laughs] Obviously, I'm not going to be like, “Hey, it stinks in here.” I've got to figure out a way to understand why do people feel unsafe and maybe I didn't have that sentence go through the voice in my head, but it definitely put me on a path towards to maybe the less privileged people in the room, the people who are not the managers to understand what's really going on, what pressures are they under? MAE: I love that the example includes legit real smell. So many times, especially in our industry and part of what this podcast is counteracting, is getting in touch with the fact that we are people and humans. Anyway, I love that you brought [chuckles] that home that way. Also, I wanted to say from earlier, I wasn't trying to corner you into expecting to have a philosophy. I thought you might and it was worth asking. But I recently got asked a similar question about my management philosophy and which authors do I appreciate most, or something. I've been a manager for 25 years and I'm like, “Uh. I don't know. I figure out what is needed and then I deal with that.” I don't understand how to answer. So I just want to give some – pay you back and apologize. I didn't mean to get you – [overtalk] JUSTIN: Not at all and it becomes one of those you know it when you see it. I struggle with this a lot because somebody introduced the concept years ago of beginner's mindset to me where sometimes if I'm a beginner at something, the best person to help me is not the expert—the person who's been doing it for 20 years. It's somebody who's just a few hours, or a few days, or a year, or two ahead of me because they can still remember what it felt like to be where I am right now. Because I talk a lot, because I tweet a lot, because I show up in a lot of places, and I have an outward facing sales role to potential clients and candidates, I meet a lot of people who come to me and they're like, “How do I learn how to code?” And I'm like, “I can tell you the 15-year version of this story, but it's probably going to be really depressing.” I've taken as a responsibility to like try to—and I need to do a much better job of this—be armed with either resources, or people that I trust, that I can refer folks to so that I'm not totally leaving them hanging. MAE: I love that and yes. Speaking of teaching people how to code and what you said, there's a name for it that I'm forgetting about being a teacher. If you are closer to the student, you actually are a more effective teacher. So there's just two comments. The first one is I'm a part of RailsBridge I helped found the Southeast regional chapter. So if anybody, any listeners out there still want to learn how to code, or are having that same, I don't know how to tell you about my [chuckles] zigzag story and ideally, they wouldn't all be depressing, [laughs] but I'm sure they all include some real low moments. But RailsBridge, which is bridgetroll.org, has recurring events where people can go all over the country and obviously, in pandemic times it's not as much in person, but yeah. And on the comment about teaching and when you mention talking to the people with the least privilege in the room, I'm just really sensitive and appreciative of your sensitivity to power politics and how much they impact so much of what is happening and trust. So for anybody out there who's being asked to help new people and you feel like you're still the new person, you're probably in a better position to help. So just want to offer some encouragement there. I have personally found a lot more confidence in helping people who are just behind me and that anytime you're teaching, you're learning. So just want to put those in. I love that actually your answer, instead of a quadrant, is really just the one word of trust and I appreciated the ways in which you were mentioning trust can be different things. Trust in what you're building. Trust in who's asking you to do it. Chelsea asked for a couple examples and I interrupted. So I apologize, but what are some trust building exercises that you have encouraged, or examples? Maybe even continuing that same story. Six months later, was it a fresher air in there and what are some things they did to make that happen? JUSTIN: Yeah, that story, like so many teams and companies in our industry, didn't undertake the redemption arc that I wish I could convey. I think in fact, to see a big picture problem and the desire to connect that with a big picture tidy solution, a future state where it's all rainbows and unicorns and everyone really getting along well. Sometimes that sets, for me personally and when I see consultants who are less experienced, who can see that end state in mind and they know maybe the top three hit list of stuff that needs to happen to help that organization get to where they need to be. We can sometimes set the bar so high for ourselves in terms of expectations of like, what does it mean to help them become better, that we can't help, but lose sight of the value of just incremental improvement. If I can just help restore relationship between two people on a team. I had one client years and years ago, [laughs] they were also undergoing a pretty big transition and they brought me in a – I think that what they thought they were hiring me for was to be a test-driven development coach to teach them that particular practice of TDD. They got, instead on day one, there was a room of 30 interdisciplinary cross-functional teams—some developers, some non-developers, and stuff—and I could just tell that they were like, it was a big epic rewrite from a Perl codebase that, I think they were moving to no JS and Angular as well as a chewing of cloud infrastructure at the same time, as well as Agile software practices at the same time. They were overwhelmed, they've seen this fail before, they felt a ton of pressure from the business, and they didn't even really understand, I don't think, the future business model. Even if they were successful, it wasn't clear this was going to solve systemic problems for the company. And I'm like, “Well, I can teach you all TDD. [laughs] But instead what my commitment to you all will be is that six months from now, you'll either have been successful and learned all of these things and built the thing as the business has asked you to do and then the business takes off, or I will have helped equip you with skills and ways of thinking about this industry and our work that will set you up to get much better jobs next time.” Again, the company didn't totally come together. It didn't take off like a rocket ship. The team was successful in the rewrite, which doesn't happen very often. But then you saw almost a diaspora of dozens of highly skilled people—and this was in Central Ohio—who then went to venture backed startups, some went to big, established enterprise-y kind of companies, some left the region and went elsewhere. That turned into, if I had to count, probably eight, nine additional Test Double clients [laughs] down the road where they came in and they could spot in a minute, this is a way that an outside perspective, who is here to help us at a moment of tremendous need, can move the needle just a little bit. By setting expectations realistically, being humane about it, and focused on what's best for the people involved because at the end of the day, all companies are is collections of humans. That was, I guess, more my orientation. CHELSEA: So Justin, I'm interested in your thoughts on this. I appreciate what you just shared. I worked at Pivotal Labs for a while—original labs when it was sort of a generalist's enablement. JUSTIN: Sure. CHELSEA: Very heavy on that kind of thing. One of the things that we ran into relatively frequently was similar to what you've just described wherein one of two things would happen. Either the clients were successful and there was a vastly improved, I guess, software delivery culture among the people that we were working with, or if that didn't work out, then there were individuals who took to it very well and had gained variety of skills that allowed them to go elsewhere. It happened enough times that then we would have to establish trust with potential new clients around this whole additional access, which was effectively, is this going to cause a diaspora of all of these engineers, designers, and PMs that I've managed to scrape together for this project? Do you find Test Double ever facing that, or how do you address either beforehand if product owners are aware of it, or after it happens, how do you address that with clients? JUSTIN: That's a fantastic question. Pivotal Labs was one of the companies that we looked at. We started Test Double 10 years ago. I was at the time, just starting to speak at user groups and conferences and I spent a lot of time with the people at the Boulder office at Pivotal Labs. Great people. I really appreciated the focus and the rigor and in fact, made to answer a question earlier about process, or abstraction about like, “Hey, boil it down for me.” Pivotal Labs sold a very branded, very discreet process for like, this is the way to build software and, in a sense, some of the decisions that we made when we started Test Double were a response against that. Just to say we trust the people closest to the work to make the right decisions based on tremendous experience and skills. Frankly, as we get bigger and more successful, having some somebody like me at the top of an organization who only talks at the beginning of a client relationship, which is the moment that we know the least and I've got the least amount of context, for me to go and say, “Well, this is the way that we got a test,” or whatever it is would just be ineffective and inappropriate. So to answer your question, Chelsea. Fortunately, our brand power, isn't nearly as strong as Pivotal Labs so no client has ever come to us in advance with that as a question to say, “Hey, I'm worried that you're going to train our people in this particular methodology and then they're going to leave for higher paying jobs,” or something. That's never come up in advance. In fact, one of the things that we talk a lot about is that because our consultants join client engineering teams to work with them inside of their own process, using their own tools, and their own system is we just try to be model citizens of somebody on that team. We trust our clients like, “Whatever your process is, it's apparently working for you. So let's just try it and if we have ideas for how to make that better, we will listen, we'll write them down.” But then only once we've built trust and rapport with the people on that team, will we start to share, “Hey, I've got a rainy-day list of a few things that you might want to try.” What that's actually done is has a detoxifying effect where from a context of high trust, the incongruity, the distrust, the kind of backchannel frustrations that our people pick up on because we're kind of “in the trenches” with our client folks, we're able to have multiple pathways into that client organization to help make it a better place to work. We got one of the best poll quotes that I've ever seen on our website recently. One of our clients is Betterment. They're a great financial management firm in New York where it's kind of an autopilot savings vehicle. The director of engineering, Katelyn, there said that she saw on the teams where testable people were deployed, attrition actually went down and I think it's because we help those teams to perform better. An old friend of mine named Leon Gersing, he used to have a thing he'd say. He'd said, “You can either change where you work, or you can change where you work.” Meaning you can either make the place that you're at better, or you can go find gainful employment elsewhere and we're in the make the place where people work better business, wherever possible as a first avenue. MAE: You're reminding me of a book that I'm reading right now called What Got You Here Isn't Going to Get You There. Are you all familiar with it? JUSTIN: I was so proud of my wife, because she asked for that on Audible earlier this week because I'm the person with the Audible credit and I'm like, “Oh, this is quoted in business leadership contexts left and right and all over the place. So it'll give us a touchstone to talk about.” MAE: Yeah. Well, the TLDR is so much of especially management focused and leadership focused thought is about things that you should do and this book is probably along your lines, Justin of giving the counterintuitive answer. This is here's 20 things that you might want to consider not doing and then replace it with the good behavior because that is such a stretch in real life to actually do that. It's how about you just pick a couple of these that you're a repeat offender and just stop. Just try to not do it. That's the main first thing and I've found that, a refreshing take on how to think about how to guide in ways that are building more trust and offering more safety. So definitely recommend that book. I don't know that it came out of this book, but the person who recommended it to me, my VP Scott Turnquist, who is amazing, shared that there are really four categories of things that can help build trust and it's definitely all done incrementally. So picking up on that word you said earlier, Justin, too. But the four kind of axes are credibility, reliability, intimacy, and selfless motivation. If you can demonstrate those recurringly, that is how to establish and/or course correct into a state of increased trust. So anyway, that was partly why my original statement was like, do you have this down? Because I've heard some things lately that I've been thinking about. JUSTIN: I really appreciate your perspective there and it makes me feel better because one of my commitments in life is to never write a book. But if I were to write a book, I'd probably have to come up with a tidy quadrant, a Harvard Business Review two by two, or something like that to I guess, support the good work at the people at CliffsNotes and Blinkist to boil down years' worth of work into a 13-minute podcast. I think that the advice as you expressed, it is completely valid and there's one thing that I think is a core ingredient to trust. Trust of ourselves, trust of people that we work with directly, and then trust of leadership and the people who run the organizations that we're a part of. The hardest, in my opinion, is authenticity. If you're not, I think you said credible. If you combine credible, intimacy, vulnerability, those are really useful words to prompt what I mean when I say authenticity. If I'm talking to somebody and I can lock eyes with them and I believe that what they're saying is what they actually feel and it's their true self and they believe it, then all sorts of other background processes in my head of trying to read the tea leaves of what's going on here, all the passive analysis I might do to try to understand what's the subtext that this person's operating from. That's just the form of kind of armor, or a guard that it depletes my cognitive ability to talk to the person. Authenticity is a signal that we pick up on as humans and this is why it's a miracle that we have video chat in this era and it's why I really relish one-on-one in-person interactions when I can have them. Authenticity is a signal that I can drop that guard a little bit. It's that I can really look and really listen to what the person's saying and take it at face value. The problem with just saying, “Oh, okay, well just be authentic. Just be your true self,” is that that is useless advice and way more likely to trigger somebody's defenses, or their self-doubt. When I think about authenticity in the context of a team, or an organization is that the people who are maybe not in a position of power, people who report up the chain, if they don't come across as authentic to their leaders, the leaders should not look at that as a failing of the person, but as a failure of their ability to figure out how to promote and draw out authenticity from the people who report to them. Maybe they don't have safety in the room to speak their true mind. Maybe they feel like the things that make them different from the other people that they work with are a liability, or a risk and so, they can't really bring their true self to work. It's the leader's job, when they spot inauthenticity, rather than go on a hunt like a political backchannels to try to figure out why is this person lying. What's under here? Figuring out what is it about the person's context, the environment, kind of the system that they are operating in. What could possibly be an explanation for why I can't develop an authentic connection with this person? And until you run out of every single possible explanation in that investigation, including self-reflection of what is it that I'm individually doing and how I communicate to this person that's getting in the way. Only then is it really useful to start thinking about maybe this person's not a good actor, maybe they're being duplicitous, or something. Because once you've hit that button, it is really hard to go back. So when we talk about authenticity, we often talk about the individual's responsibility to present it, to be it. If you can fake authenticity, then you can do anything, right? That is advice. It's fine. I hope that everyone feels the safety. Like I'm a cishet white dude who's pretty powerful in my little corner of the small pond. I have no problem just spouting off and being my true self and so, I should just tell other people to do that too. That's not fair. I think that what is better advice for people who are maybe not in positions of power is to be really good at detecting authenticity. When you detect authenticity and people are making their true selves known to you and you're feeling a connection with them, whether they're peers, or managers, spend more time with them, invest into those relationships, and use those people as anchors of trust. So that when you're failing to make that connection elsewhere, when you have doubts about others in the organization, you can have more points of perspective on how to best address it. MAE: I read an article yesterday that says, “Laziness Doesn't Exist.” That's the title of it and it essentially says that that same thing of what's the context in which this is happening. People don't procrastinate for fun. In fact, it usually takes more work and starting from a place of what shoes are you in, but I especially love the in what way am I impacting that person's ability to be themselves? Also, I must have said the word authenticity, because this list is credibility, reliability, intimacy, selfless motivation, but authenticity and credibility in all of these things do also have to do with the thing that I loved you bringing up about identity, power politics, and what happens and your environment is not allowing you to be credible. So another way in which people can as good peers, mentors, managers, and above can do is in what way am I bolstering these people's credibility? So always flipping it back to how are we the perp [laughs] and that's very similar to social justice, racial justice. The more we see how we are perpetuating and disenfranchising, regardless of our identity, that's where there's some hope for the humans in my mind. CHELSEA: Yeah. One of the things that I appreciate that you've both brought up, Justin and Mae, is the degree to which power gradients play a role in the way that we deal with these things. There are demographic power gradients with regard to race, with regard to gender. There are also power gradients with regards to our position in the company, with regard to technical privilege, with regard to our level of skill, with regard to the size of our network. We also, I think live in this individualist culture that has a tendency to place the responsibility on individuals to do what they can to resolve. For example, what you were saying, Justin, about how we effectively coach people to just be authentic. Maybe that coaching works fine in some context, but that's a subset of the context in which we're asking people to apply it and asking individuals to resolve this from the bottom up sometimes as opposed to looking for the systemic reasons why this is a thing that has to be solved in the first place. I'm curious as to whether you have thoughts on what a person can do, who finds themselves in a position of power, in a position of leadership in a company, for example, to address those sorts of questions with other folks who are working there. JUSTIN: I think one thing that can be helpful – and I realize your question is about what can a leader do. One thing that can be helpful is for those leaders to empathize and put themselves in the shoes of people who might not have the same privileges as you described and what would it take to—I'm waiting outside my area of expertise here—would be to think about what are the things that are in a given person's sphere of direct control, what isn't, what am I setting up, and what am I communicating in terms of expectations that I have of them? An example that came up a lot in our industry was the number of drink up events in tech in the early 2010s where there was sort of an assumption that everyone likes alcohol and when people in public drink alcohol, good things happen, which turns out isn't true, but it can also be the case. There are invisible expectations that we communicate because I'm a big fan of granting people autonomy to solve problems in their own way, to approach work the way that they feel is best. Our company has been remote from day one and a big part of that was we want people in control of everything from where they work to their home network, to the computers that they use. Because when I had that control pulled away from me in the role as developer, it just sapped my motivation, my drive, my engagement, my sense of control over the stuff that's right in front of me. When I now in a role of influence over other people, whenever I speak, I have to think about the negative space of what are the expectations that I might be conveying that are not explicit. I need to be careful of even expressing something like hobbies, or shows that I like, or stuff – especially in this remote world, we want to develop connectedness. But a challenge that I keep running into is that our ability to find mutual connection with people about stuff other than work, it rides the line really closely of communicating some other allegiance, or affiliation whether that's we talk about sports a lot because that's an obvious one, but even just interest in hobbies. So I find myself – and I realize Chelsea, I'm doing a really poor job, I think of answering the question as you asked it. I find myself only really able to even grapple with like what can leaders do to set the tone for the kind of environment that's going to be inclusive and safe for other people by really digging in, empathizing with, calling up, and dredging up what their own experience was when they were not in a position of power. If I have a secondary superpower, is I had a real rough start to my career. I was in really, really, really rough client environments that were super hostile. I had a C-level executive at a Fortune 500 company scream at me until his face was red in a room one-on-one with a closed door on a regular basis. The sorts of stuff that developed callus on me, that I look back at a lot of those experiences and I'm like, “I learned a bunch.” It's supercharged my career as an individual because it strengthened me. So the challenge that I have is what can I take from those really, really harsh experiences and translate them for people who are coming up in a way that they don't have to go through the same trials and tribulations, but that they can take away from it the lessons that I learned. And for me, it's all about not just safety for the sake of safety, but safety by which myself and others can convey the useful growth that people want to see in themselves, their skills, and their abilities that isn't diluted. That can convey the truth, the difficulty, and the challenge and how hard – Programming is really, really hard for me and I've been doing it for a long time. A lot of stuff about this is just not easy. The relationships are not easy. Like you're going to run into situations where there's massive differences between where people stand on stuff and what those perspectives look like. Navigating that is hard enough without adding a whole layer of toxicity and hostile work environment. So what's a way to promote that learning environment without just totally insulating somebody from reality. That's been, I think a challenge and attention that I see a lot of other like-minded leaders in tech trying to figure out how to create. MAE: You reminded me of a meme that someone shared with me that says, “What doesn't kill you can just regulate your nervous system, trap itself in your body, steal your sense of self, make you wish it did.” I don't know what makes you stronger means, but let's stop glorifying trauma as a life lesson we've been blessed with. [chuckles] Definitely along the same lines. JUSTIN: Yeah. Relatable. MAE: There's a thing, too about putting oneself in another's shoes and this is a place where I'm someone that can read people really well, but that makes that tricky. Because I start to trust my sense of it and I have a similar architecture going if I don't feel like I'm getting the whole story. So what's the read between the lines thing. But without a lot of exposure to a lot of very different people, and most people have not had a lot of exposure to a lot of different people, when they put themselves in the other person's shoes, they come up with a different conclusion. So I will feel hurt by people who do things that were I to put myself in their shoes would not have done that to me, or if they did, it's because of X, Y, Z about who they are, or what they think, or what is their whole context and environment. All of that is there's a tactic that we use at True Link Financial called “don't cross the net.” So you say and claim the story I tell myself about that is dot, dot. When leaders, who haven't had a lot of exposure to a lot of different people and a lot of different ideas, try to empathize and find themselves limited in that, there are other options which include one of the things you said earlier. Making it so that people can say the things on their mind so whether, or not that's persons being their authentic self this is a whole another level, but creating a place where we expect that we're all messing up and that it's okay to talk about uncomfortable things is one of my real soapboxes. It's totally okay. Yes, we are all racist. We are all sexist. We are all homophobic. There is no way to not be as a result of being in the culture we're in. We could do things to mitigate it. We can do things to name it. But if we just start from yes, we're all failing. This for me, it lowers the stakes because so many people feel that if someone brings up, “Hey, that's kind of sexist,” or “This is not supporting me in this way,” or “My credibility is not being seen because of this.” In the absence of already, yo, we're going to talk about some negative stuff sometimes, that's an introduction of negativity to the “positive, happy rainbow unicorn workplace” that you were talking about before. So one of my hopes and dreams is that we get some clouds to rain on the land to allow things to actually grow [chuckles] and this includes, yo, we are not perfect. And we are definitely doing things we don't intend all the time. JACOB: That made me think about authenticity again, because sopen about imperfection. I'm a neurodiverse person so I probably am autistic. If someone were to say to me at work, “We really want you to bring your authentic self,” probably the thing I would think is you don't want that person, [laughs] or at least without getting to know me a lot better. There's a concept called masking where it's basically, there are behaviors and traits that are exhibited by neurotypical people that just come naturally to them. By learning the hard way, I've sort of learned to do them, even if they don't feel natural at all like making eye contact, smiling at people when talking, things like that. So I think that complicates authenticity for me, which is that I'm intentionally not hiding, but choosing what parts of myself to show and what parts I just don't want to bring to work. [laughs] I don't have a clean answer for that, or a solution to that, but I think that just complicates things for me. JUSTIN: I thank you so much for sharing that and I think it's a really important perspective to bring, which is I talked earlier about sure, plenty of people's true, authentic selves, even if they were to bring them, they might be in a job, or in a space, or in a team where that wouldn't be understood as such, or appreciated, or literally safe. It's hard to tell people, “Hey, you should feel safe” when the truth when spoken would be an unsafe thing. That would be setting people up for risk, for danger, and it would be a seed of distrust, which is what we're all here to talk about avoiding. So I really appreciate you sharing that. When I talked about empathy earlier, Mae, in my brain, all that really comes through it is the E-M part of that word, like the root for emotion. I never really have been able to assume that I can get somebody's context, their perspective, and the moment that they're in into my brain well enough to role play and do a re-dramatization in black and white, sepia tones and slow motion, like this is what Justin would do if he was here. That's one reason why we trust people at our company to just do the work, because we know that they're going to have such a richer amount of data and context than we'll ever have. But one thing that I'm grateful for is that I've been able to experience what I feel like is a pretty broad range of emotion. [laughs] I'm a real emotionally volatile person. I go super high highs, super low lows and I'm just like, it's how I've been. I can't help it. So when I'm empathizing with people, I'm just trying to get in the mindset of how do they likely feel right now so that I can understand and try to do a better job, meeting them where they are. A big part of that is learning there are differences and so Jacob, of course, it's like if I worked with you, I understand that it might not be productive to bring all of yourself to work all the time. But I would hope to develop a trusting relationship with you where you can share enough so that I can know what are the boundaries that are going to be productive for you, productive for me so that we can make a connection and it's something – To make this a little bit more personal. I don't know where my career is going to go next. I founded Test Double with my partner, Todd. I was only 26 years old and we've been doing this for 10 years now. 2 years ago, we embarked on a journey of transferring a 100% of the equity of the company to our employees. So we're on an employee stock ownership plan now, it's ESOP, or any of the stuff, it is complicated because it's well regulated. We have to have outside auditors, a valuation firm, we have a third-party trustee to make sure that our people and the value of the company is transferred appropriately, treated right, and managed well. So it's naturally raised, especially in my circle of friends and family who realize that, this means that there's not an end date, but there's a moment at which I can start thinking about what my life is going to be next. The people who knew me when I was 25, 26, who look at me now, it's not that I've changed radically, or my identities are radically different, or anything. It's like, I am a very different kind of person than I was at 26, than I was at 20 before I got into this industry. I have changed in healthy ways and in maladaptive ones and in response to maybe drama and stress such that the ideal retirement that I would've imagined earlier in my life looks a lot different now where I've just kind of become habituated. I'm a really, really different person than I used to be and I'm grateful for that in almost every way. I feel like I've grown a lot as a person, but the thing about me that I really look at as an area of change is that I just work too much. [chuckles] I'm online all the time. I'm very focused on – I've optimized productivity so much that it's become ingrained in me. I understand that whatever I do next, or even if it's just changing my role inside my company, I need to find a way to create more space for slower paced asynchronous thought and learning how to, in the context of a career, not just bring your true self – I'm kind of curious Chelsea, Mae, and Jacob's perspectives. That true self might be changing [laughs] intentionally. There's a directionality and the growth isn't just learning new skills necessarily, but it might be changing core things about ourselves that will alter the dynamic of the relationships that we bring to work. CHELSEA: Yeah. I have two thoughts on that, that I can share. The first is the extent to which bringing my true self is a productive thing to do at work. So for example, my career prior to tech, I did a variety of different things to make ends meet, really a wide variety of things. I graduated directly into one of the bigger recessions. I won't tell you the exact one, because I don't feel like being aged right now, but [chuckles] it wouldn't take too much research to figure it out. I was trained to do a government job that was not hiring for the next 18 months at a minimum. I needed to figure out what to do and was trying to make ends meet. In my first year of employment, I got laid off/my job ended/something like that on four separate occasions in my first year of work and that resulted in, I do not trust when managers tell me that everything is fine. I have not ever effectively and that is something that I don't foreground that in work discussions for a variety of reasons. I don't want to scare other people. I don't want them to think I know something that they don't know about what's going to happen because I don't usually. When managers tell me, “Oh, everything's great, we're doing great,” all that kind of stuff, I just don't listen. I don't. My decisions do not take that's statement into account and I find that that's the kind of thing that I think about when I'm asked to bring my whole self, my authentic self to a place is that there are things that just sort of similar to what Jacob is saying. I'm like, “Trust me, trust me on this you don't want that.” So that's kind of the first thought in that realm. The second thought that I have around this is the degree to which work should really encompass enough of our lives to require, or demand our authenticity. So I had a variety of full-time jobs in tech and then I quit one of those full-time jobs and I was an independent consultant for a while bolstered chiefly, and I was lucky for this, by folks who had read my blog and then folks who had worked with me when I was at Pivotal. So the consulting effect of people knowing what it's like to work with you is real. That experience felt very different from a full-time position insofar as at the external validation of my work was naturally distributed in a way that it's not in a full-time position and I found that distribution is extremely comforting. Such that even though I now have a full-time job, I also continue client work, I continue teaching, and I continue writing and doing workshops and those kinds of things. This is not the chief reason that I do that, but one of the nice things about it is the diversification of investment in the feedback that I'm receiving and validation that I'm receiving. In order to do that, I have an amount of energy that I put to each of the things in my life and part of it is work, of course. But another reason that I think it works for me is that I no longer have to expect all of my career fulfillment from any one position, from any one employer, from any one place, which has worked out very well because I think that we pedal this notion implicitly that you bring your whole self to work and in return, work provides for your whole career fulfillment. But most places really kind of can't and it's not because they're terrible places to work. It's just because the goals of a company are not actually to fulfill the employees, they're just not. That's not the way that that works. So it has allowed me and I think would allow others to approach the role that a given employment situation plays in their life, from what I think is a more realistic perspective that ends up helping keep me more satisfied in any given work relationship. But it doesn't necessitate that I – I guess, for lack of a better term, it limits the degree of emotional investment that I have in any one thing, because I'm not expecting all of my fulfillment out of any one thing. But I think that to say that explicitly sometimes runs at best, orthogonal and at worst, maybe contraindicates a lot of what we talk about when we talk about bringing our whole selves to work and looking for those personal connections at work. I think there is pragmatic limit past which we maybe impose more guilt than we need to on ourselves for not doing that. JUSTIN: Yeah. Thank you so much for sharing that. I think Mae used the phrase “lower the stakes” earlier and I think that one of the problems with authenticity, the phrase “bring your whole self-trust” is that the stakes are super high because it seems like these are bullion contracts between parties. For example, you said that you don't trust managers. If I was filling out a form, like a personality inventory, or something, it's like, “Do you trust managers?” I'd say no and I think 90% of people would say no. It's sort of the economy right now. I think the economy approval rating of is the economy good, or bad is at 23%. But individuals are saying at roughly 60% levels, that they are individually doing okay in this economy. I would say the same. Like, do I trust my manager? Oh, hell yeah. I completely trust my manager right now. And to lower the stakes even further, when I've been talking about trust, it's not so much about where do I find fulfillment, or who what's my identity, or who am I being, it's about a snap orientation. It's the most immediate sphere. “Oh man, this PostgreSQL query is really slow and I can't figure it out.” Is my snap reaction, or my orientation to think, “I believe in myself enough to dig into this to figure it out”, or is it doubt myself and just kind of get lost in a sea of a thousand Stack Overflow tabs and just slowly lose my whole evening? When in a team, maybe working with them and we were in planning, or something, or maybe we're in a higher stake, let's say, a code review session and somebody makes a comment about something that I did. Is my snap reaction to doubt their motivations and think “Ah, they're just trying to passive aggressively shoehorn in their favorite architecture here,” or this is politics and gamesmanship, or is my snap reaction is to be like, “Nope, let's try to interpret the words that they're saying as literal words and take it on its face”? Like I said, I'm a highly emotionally volatile person, the weather vane shifts with me all the time and sometimes I can control it and sometimes I can just merely observe it. But the awareness of the out has been really helpful to understand [chuckles] when I hear a leader say something about the company, my reaction is I think that they've got ulterior motives and that they are probably not speaking in literal truth. If that's my snap reaction, I'm just trying to communicate that as that's a potential blind spot. Because I have a long rut of past companies that I worked for that had mission statements and vision statements that were kind of bullshit and that no one really believed in, that were just in a bronze plaque on a wall, or whatever. That's baggage that I carry. I just have to acknowledge that baggage and try to move forward. The best I can do is just be present in every moment that I'm in and to understand when I have a snap reaction, am I oriented towards what might lead me to a good outcome, or a bad one? MAE: Holy moly, so many amazing things have been shared today and Jacob, especially kudos to you for walking us into a deeper level of authenticity. Love it. Thank you. I'm, to answer some of your questions, Justin very similar to Chelsea in that tech was not my first rodeo. I didn't become a programmer until I was 37 years old and I am now 45. I'm totally fine with aging myself. Prior to tech, I did put a lot more of my identity in my job and I would usually do that job pretty much all of the hours possible and I've always worked for mission driven organizations. A lot of the things that we're talking about as far as job fulfillment and whether, or not it's a good environment, or if it's a toxic environment, there's a lot of privilege in what we're talking. My parents were paper mill workers and it was not pretty. They had me when they were 19, so they didn't have another option. That was the highest paying gig in our region and they had no education. So it was never an option to even change that. So I am someone who wants to put my whole self into what I do. It's a very working-class mode and gaining identity through what it is I'm able to do. It's also a pretty capitalist [laughs] mentality that I work to move around. But as a manager, when I am a manager, or in management, or managing managers, I'm never encouraging this everybody needs to bring their whole self to work. Although, I had this really instructive experience where one person truly did not want to have any of their self at work, that they truly only wanted to talk about work at work. We're not a family, nicely nice. I don't want to crochet together, or whatever. That is the most challenged I've ever been as a manager because my natural things are always to figure out what people need and want, and then amalgamate that across the group and see how we can do some utilitarian math and get it so that people are being encouraged in ways they would like, they are not being disadvantaged, and they have space to say when that's happening. But even still, I'm always going with the let's be buddies plan and it's not for everyone. So figuring out how to not have all of your eggs in any basket, no matter how many hours the job is, is definitely a tactic that has been successful for me. But what happens is I then am involved in so many things [chuckles] in all of the moments of life. So I still do that, but I do it by working more, which isn't necessarily the best option. The thing about the mission that I just wanted to pivot for a second and say is, we are no longer in a world where we allow failure. This is a little bit back to my earlier soapbox. The energetic reality is whatever anybody's mission statement is, that is the thing they are going to fail at, like the seamstress never has the best hemmed clothes. So when we write off anyone, or any company based their flawed attempt at the mission, we're discounting that flaws exist, [chuckles] contradictions exist. It's about where are we orienting and are we incrementally moving toward that, or away from it and not in this moment, are we this thing that we have declared because it's more of a path is how I see it than the declaration of success. JUSTIN: Yeah. Thank you so much for that, too. Because I think that one thing we didn't touch on is the universe – and we're talking a Greater Than Code podcast so it's software industry adjacent at least. The universe of people who got to stay home during this whole pandemic. The universe of people who are “knowledge workers”, or “white collar”, especially if you look at the population of the world, is vanishingly small. There was a season in my life where I was the person that you just described managing, where I just viewed myself as I was burnt out. I always wanted to be a mercenary. I had this mindset of I show up at work. “You want some great code? I'll sling you some great code.” Like I was a short-order cook for story points and feature development and that was the terms, right? I didn't want to bring my feelings to work. I didn't want to make friends with people because then God forbid, it would be harder to leave. I didn't have that available to me as a capacity at that time, but I went long enough and I realized it's not that I was missing something, or not being fed in some way by not having this emotional need filled at work. It was that I was failing to acknowledge when you say privilege, the literal privilege, that I get to wake up in the morning and think for a job [laughs] and the impact that I can have when I apply all of the skills, capabilities, and background asynchronous thoughts that are not literally in my job description. When I can bring those things to bear, I'm going to have a much, much bigger impact because what am I except for one person thinking and staring at a matted piece of glass all day, but somebody who is in a small community, or a group of a bunch of people who are in the same mode. So when I'm in a meeting, I can just be the mercenary jerk who's just like, “Hey, I'm just doing this,” and feeling like that's an emotionally neutral thing. When in fact, that negativity can be in an emotional contagion that could affect other work negatively, or and I'm not exactly – My friends who know me, I'm a stick in a mud, I'm a curmudgeon, I'm super negative. I complain constantly and I have taken it upon myself to strive to be a net increase in joy in the people that I talk to and that I interact with at work. Because it is a resource that is draining all of us all day long on its own and it needs to be filled up somehow. I have the capacity right now to take it upon myself to try to fill that tank up for the people that I interact with. So I want to touch on that because I just think it's super lucky that I get to work on a computer and talk out of a screen all day long. If I didn't have that, we wouldn't be having this conversation, I suppose, but I'm just here to make the most of it, I guess. MAE: I love that. And you reminded me of Sandi Metz's closer, Lucky You. JACOB: Tell us about it. MAE: She gave the closing talk a couple years ago and it's called Lucky You and it goes through how did we all come to be sitting in this room right now and what about redlining? What about the districting? What about all of these things that led to us to experience being here as lucky? I know you weren't saying it in that way, Justin, but it reminded me of that piece, too, which is relevant, but the talk is completely amazing and I definitely recommend it. JUSTIN: I think I mentioned it once before. The thing that brought me and our marketing director, Cathy, to think that this would be a great forum to talk a little bit about trust at work is that we're about out to – and I think that actually the day that this podcast publishes is the day that we're going to publish a new conference talk that I've prepared called How to Trust Again and we're going to post it to Test Double's YouTube channel. So we might not have a direct link for the show notes necessarily, but it'll probably be at the top of that as well as the top of our blog when the show goes live. I hope that anyone [laughs] who enjoyed this conversation will also enjoy the kind of high paced, frenetic, lots of keynote slide style that I bring to communicating about a lot of these topics while still understanding that it's just like n equals one. I'm sharing my experience and hopefully, as food for thought to maybe help you look back at your own experience and understand what connects from my experiences, my perspectives, and my context that might be useful and I hope that you'll find something. Special Guest: Justin Searls.

00:51 - Nikema's Superpower: Connecting To People Through Authenticity & Vulnerability * Background in Dancing * The Ailey School (https://www.alvinailey.org/school) * Shift to Tech * Having Babies * ADHD Diagnosis (Neurodivergence) * Masking (https://en.wikipedia.org/wiki/Masking_(personality)) 28:02 - Seeing People For Their Whole Selves; Facilitating Safe Spaces * Nikema's Founder Journey * Remote Work & Homeschooling * Pop Schools (https://popschools.com/) * School Can Be Damaging to Children * The Purpose of School * Self-Directive Education (http://self-directed.education/) 51:38 - Impostor Syndrome (https://en.wikipedia.org/wiki/Impostor_syndrome) Isn't Natural; The Tech Underclass * Bias & Discrimination * Equity & Accessibility Reflections: Damien: Connecting through authenticity. Arty: Even when you're scared, stand up and speak. Chanté: Our youth is our future. Nikema: Making real connections with other people. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: ARTY: Hi, everyone. Welcome to Episode 269 of Greater Than Code. I am Arty Starr and I'm here with my fabulous co-host, Chanté Martínez Thurmond. CHANTÉ: Hello, everyone, and I'm here with our fabulous friend and co-host, Damien Burke. DAMIEN: Hi, and we are here with our guest, today, Nikema Prophet. Nikema Prophet is a software developer and a community builder based in California. Her current projects are a book to be released in 2022 and hosting conversations on Twitter that highlight Black and neural diversion perspectives in the tech industry. Welcome to the show, Nikema. NIKEMA: Thank you for having me. DAMIEN: What is your superpower and how does you acquire it? NIKEMA: My superpower is connecting to people through authenticity. I acquired it by practicing standing up and speaking—speaking from my heart in front of others—and I had to overcome very painful, debilitating shyness to do that. CHANTÉ: I love that you started with that because Nikema, it doesn't seem like you're shy and I think even on your Twitter account, you're louder on Twitter than you are in person. I find your presence to be really lovely and a voice that our community so very much needs. When I found out you were going to be on the show, I got excited and did my research and did all the things we normally do and found a whole bunch of stuff about you. But before we get into those exciting parts, I am a person who loves to orient people to who you actually are to bring you into the room and just tell us a little bit more like, who are you besides the titles? Where are you living? Where are you from? The things that you do for joy, and if your job is one of those things, tell us about those. So just curious, who you are and then we can get into the things that you're doing now. NIKEMA: I really do need to sit down at some point and write down the story that I want to tell about myself because I tend to make it very long. So I'm going to try to keep it brief. [chuckles] But I am Nikema Prophet. I was born and raised in Sacramento, California. So I'm definitely a California girl. Sacramento is the capital city, but it's not super exciting [chuckles] as a place to grow up. There's a lot of government jobs. People say, “Get that state job, get those benefits, you're good.” Government jobs, healthcare, a lot of that. But I grew up and probably starting when I was a preteen, like 12, 13, I decided that I wanted to be a professional dancer. So that was my life goal. No plan B. I'm going to be a dancer. I'm going to get out of this small town and I'm going to go dance, which is funny because I did say that I am very shy [laughs] so I always struggled with being self-conscious and I never felt like I was really dancing full out, as we say. I always felt like I was holding back, but I think looking back it was the dance that saved me in a way. It gave me something to look forward to. It got me moving. Also, my parents were really cool about this, looking back on it, because we didn't have money for daily dance classes, or anything like that. They allowed me to go to schools that had arts program. So there were some magnet schools, or something like that that had these art programs. So actually, through elementary school, I was in the so-called gifted and talented program, which is a term that I really dislike [chuckles] because even at the time, it felt like it was segregation. [chuckles] It felt like it was money kind of rerouted to mostly white kids. The way that my program worked, it was we were our own class in a school that had gifted classes and regular classes. So it was very segregated, like we were in our own class, we would go from grade to grade with mostly the same kid, and my class was mostly white kids. I was always one of less than a handful of Black children in the classroom and the surrounding school, the so-called regular kids, were not that demographic. They were busing in the GATE kids to go to this school. So I left the GATE program in middle school to go to a school that had an arts program. I'm a December baby so I was kind of always older than most of the kids, because my birthday was, I don't know where the cutoff was, but if you weren't 5 by a certain day, then you would go the next year to kindergarten, or something like that. So I was always kind of older. I went to this school, left the gate program because I wanted to dance and ended up having just 1 year of middle school because I had one semester of 7th grade, then one semester of 8th grade because I had already had like those gifted classes. The classes were too easy once I got to the regular program. So I decided back then and my parents supported me in going to these schools where I could dance and I could take daily classes for free. I said that I think it saved me because it was regular physical activity. I always struggled with depression and I was even starting to be medicated for it in high school and thinking back, if I didn't have that dance practice, I think I'd probably be in much worse shape than I was and it wasn't good. [laughs] So I think now as an adult, I'm grateful that I did have that one thing that I was holding onto, which was like, I'm going to go dance. Also, it was that one thing where I kind of had to force myself to, even if it wasn't full out, even if it wasn't what I felt was my best effort, it was still performance. It was still putting yourself out there and I still deep down inside knew that I wanted the attention of other people. I didn't want to be hidden and yeah, I didn't want to be hidden away. I wanted to be noticed. I do look back at that as dance is what saved me in my adolescence [chuckles] because I was a bit troubled. So I did have a major accomplishment when after high school, I was accepted to two dance programs. One was Cal Arts in California, California Institute of the Arts, and the other was The Ailey School in New York. Of course, I took The Ailey School because it's Ailey. I don't know if there are dance people who are listening to this, but Alvin Ailey was a very influential Black choreographer and the company, the Alvin Ailey dance company is amazing. So I was super excited to number one, get out of Sacramento and go to where the real dancers are like New York and Ailey School. I actually graduated high school early, too. I graduated in January of that year. I didn't even attend my graduation because I hated school so much. Took the rest of that year off and I went to that summer program at The Ailey School, the Summer Dance Intensive. That was cool. I'd never been around so many Black dancers in my life. So many people of color. It was so amazing to me to be in a ballet class and almost everyone was Black. That was not my experience in Sacramento. And then I was going to start the regular semester in school in that fall and that was fall of 2001 and in fall of 2001, 9/11 happened in New York. So that rocked my world. I was living in New Jersey at the time and getting to school became very difficult and I eventually dropped out. I didn't even finish that first semester of dance school and at the time, I kind of thought, “I'm not giving up on my dream. This is just too hard, but I'm going to go back to dancing. I'll keep it up. I'll dance outside of school.” And I tried that for a while, but it's really hard to do that just on your own without the support, the structure, and the financial aid because it was a post-secondary program. I took out loans and things like that to attend. So doing that all on your own is pretty hard and that was pretty much the beginning of the end as far as dance was concerned. After leaving The Ailey School, I never danced full-time again. I came back to it like taking classes here, or there, but I never went back to full-time professional dance career aspirations. So that was a turning point in my life. I didn't want to leave New York. So I tried to struggle through it, tried to make it there. [laughs] Didn't actually work. I haven't talked to anything about my tech background, but that was always in the background. Like my no plan, B plan was to be a professional dancer, but I also always really loved computers. We had a computer in the house when I was in elementary school, which looking back that was a privilege. Most people didn't. I think we had internet, AOL. [chuckles] I remember those discs they would send in the mail, we had that. CHANTÉ: [chuckles] I remember those, too. Those were fun. [laughs] NIKEMA: Yeah. I was in a Twitter Space yesterday and Gen Z folks were in there and they were like, “Yo, you used to dial to the internet?” Like, “You actually made a phone call to connect to the internet?” And then – [overtalk] DAMIEN: I still remember the sound. NIKEMA: Yeah, and then they were like – two of them were talking and they were like, “Girl, Google it, it's crazy.” [laughs] So it's wild to think we used to measure internet in hours and if you had 10 hours and that was up, then you were off the internet. So I thought that was – [overtalk] CHANTÉ: I remember before somebody would, at your house, they would pick up the phone and then disrupt the connection. NIKEMA: Oh, oh, right, right, right. Or you have the one phone line for calls and internet so you can't. Yeah. So it was just funny, the generational difference of always knowing high speed broadband and all that. It's like, we measured this in hours [laughs] and we had to dial a number to get on. So we had a computer and internet access when I was pretty young and I would make webpages and stuff back then. Even through middle school and high school, I would take computer classes, but that was not the thing I wanted to do as a career and I was also looking at it more from a visual arts perspective, because I'm also a visual artist. Back when I was making webpages, I think the class I was in was web design and I think back then, my web design class in high school was on the colorful IMAX. I think it was the first version of IMAX. So it was web design and back then when I was looking at careers where I could use those skills, I thought it was graphic designer. I didn't know anything about a web developer. I don't even know if they were calling it that back then, but I thought graphic designers were the people who made websites. But I also took a programming class in high school, which was in the math department. So I always had an interest and even in New York, when I left dance school, I wanted to major in computer science, which I turns out, I didn't have the math prerequisites to even get into that major. I ended at pre-calculus. That's all to say that while I wanted to be a dancer and that was my only goal, I always had an interest in tech and I always had an interest in programming. I used to make my own websites back when we did have that home computer and the dial-up internet. So it was always something that in the background I enjoyed doing. It wasn't I want to do this as a career because I was going to be a dancer. So 9/11 was one of those life changing moments and then the next one came. While living in New York, I got pregnant. I was actually in school when I got pregnant and life in New York was kind of almost stabilizing because I had a job as a pharmacy tech. I was in school. My parents—here's another privilege alert. My parents had bought me a co-op, something like a condo. I don't think they call it that out here; I never heard the term until I got to New York. I had a co-op studio apartment where I could walk to my classes at Brooklyn College. Things were starting to stabilize and then I got pregnant and I decided okay, I'm pregnant and I'm going to have this baby. So that was another life-changing moment and I was pregnant for a while [laughs] and I decided that I needed to go home. I needed to go be where my loved ones were and I needed that support from my family. So left the apartment vacant [laughs] and went home and while I was pregnant, I started my web developer certificate at the junior college because I was like, “Okay, the dance thing is probably not going to happen and I'm going to have to support a baby now. This is a career that I could do and I could be a mother and I can work from home.” My child was born in 2007 so I was thinking about remote work in 2007 and almost banking on it, like this is what I'm going to do. I was enrolled in that web developer program, which was something like a 1-year certificate. You could do the associate's degree, if you wanted to. But I didn't, I did the certificate and it took me 4, or 5 years to complete that certificate, that 1 year certificate because I was primarily a mom. I had a baby in 2007 and then I had a baby in 2008. So for several years, it was chaos and two babies and I don't know. I almost want to say it was almost – I don't know what it's like to have twins, but I felt like it was probably worse to have one a year apart because it's like they're both babies, but they're at slightly different developmental levels and you just have just all babies. [laughs] CHANTÉ: I can relate, Nikema because I do have twin boys and it is really hard. Like you're describing here, I had to be with my family and I needed to take time off to be a mom first and it was really humbling. I have a sibling who I'm really close with in age and my mom always says, “I don't know what was worse: having the two of you so close in age, or you having twins.” [laughs] So it's debatable. I don't know. But either way, it is very tough. NIKEMA: Yeah. So I was depending on – and that's part of why it took so long because I was a mom and online classes were not as widely available as they are in 2022 back in 2007. I just took all the online classes I could and the ones that weren't online were hybrids so it was a few hours. My mom would watch the kids, or something while I go to school for a couple hours a week. There was a lot of privilege in my story, but there's also a lot of struggle [chuckles] because I was not diagnosed with ADHD until last year [chuckles] and that's not something that you just catch. It's been with me my whole life. Having to go through school, go through jobs, and all these things with undiagnosed and untreated ADHD, it makes the late diagnosis bittersweet. Because you've built up this idea of yourself and oh gosh, I'm going to start crying. But you built up this idea of yourself and it's always been hard, but you didn't know that it wasn't supposed to be that hard, you know? CHANTÉ: Right. NIKEMA: So I'm going to – [overtalk] CHANTÉ: I can relate, too. I'm another late ADHD diagnosed person. I was in my early 20s, but it was like, are you kidding me that I have been unnoticed by all these adults? That no wonder I was struggling to do my homework and get it turned in, literally doing 50 versions of the homework. [chuckles] Staying up until 2 o'clock in the morning as a kid to do you my homework and always struggling with feeling like I wasn't perfect. Just, I can really relate and understand, too and I think the tears are welcomed because I know it to be true about our listeners, that folks in our community identify with neurodivergence and where you feel society tells you, it's like this bad thing, it's a label, and it's shaming, but I also feel it could be very liberating. And once you know what is going on in the background of your [laughs] of your life, you can make connections and start to really get into your brilliance. So just want to say thank you for being so honest. NIKEMA: That's my superpower, right? It's a double-edged sword because I can't turn it off. Actually, okay, so superpower. Another jump. [laughs] I was in some program and they asked what's your mutant superpower, which is that superpower that you can't turn off, I guess. That's probably not the best way to it, but it's a double-edged sword because it's like, I am vulnerable and I am authentic and I can't turn it off. [laughs] So it's pretty much what you see is what you get. Fake until you make it never was good advice for me, because I can't like, if I'm trying to present myself in a way that doesn't align with what I think is true, it just doesn't work. It's going to come off really strange, but I've learned to embrace the tears because I used to fight it so hard. [chuckles] That was also recently that I learned that tears have a function, like you're releasing some endorphins and [laughs] there's an actual physiological reason why it's okay to cry and it's actually helpful. But I used to fight it so hard and I would be so because I couldn't control it and I would just cry in front of everybody and that's why it's a mutant superpower. So it's like, it's not all good. [laughs] There's some downsides to it. DAMIEN: So I can speak from the other side of that. As a person who, for decades, successfully repressed my emotions and feelings, it's not better on that side. [laughter] And so, the mutant superpower that you can't turn off is a thing that I am actively learning currently and [laughs] it's not easy and it is very, very useful. NIKEMA: Yeah. Thank you for sharing that, though. I did also learn that this is how I connect with people, which is weird. I learned that people appreciate it when you're authentic and raw. I always thought that was so weird. I'm like, “I am such a mess and you're thanking me [laughs] for this.” Like, “Why?” So the ADHD being late diagnosed, I relate to everything that Chanté said. I was always a perfectionist, I was always a procrastinator, and it's like, I would do excellent work, but it would all be done the day before it was due and it would kill me to get it done. Now as an adult and knowing what executive dysfunction is, I'm like, “Oh, okay. I didn't start because I couldn't start [chuckles] and it wasn't my fault.” There's so much kind of shame that you can build up when you're thinking that I should be able to do these things that I can't do. Why can't I do these things and I don't like the high functioning label, but I know it's one that people know. But people who are masking their symptoms in a way, which I think gets girls turn out to end up masking because they're not identified. They weren't looking for that. I've said to people before, there was no way in the 80s and 90s, they were going to look at this quiet Black girl and say, “She has ADHD.” No way. No way anybody would've identified that. Girls tend to end up masking. So people are looking at you from the outside and thinking, “This is a so-called normal child.” [laughs] CHANTÉ: [inaudible]. NIKEMA: Oh, yeah. That's another thing, other people's expectations of you. If you're capable of doing harder schoolwork and all of these things, why aren't you capable of just getting started on this assignment? Like you can do it, are you just not trying hard enough? So you start to kind of internalize that judgment of I should be able to do this and that's why an adult, it's so painful to look back at all of those years where it's like I really wasn't getting what I needed. I wasn't getting the support I needed. I wasn't getting the recognition of what's going on that I needed and you think it didn't have to be this hard and it's not supposed to be this hard right now. I think I'm also a bit teary because I'm currently undermedicated [laughs] and I'm dealing with that. Even if I can tell myself it's not supposed to be this hard, it's hard to believe that I do deserve that grace, I do deserve to have the support that I need, and that it's okay when you come up against things that you're physically unable to do, because I don't think we think enough of mental struggles as physical struggles, too. But the brain is part of the body, right? We could go on about – see, my brain goes all over the place. Now I'm thinking about, [chuckles] how our health insurance works and how I'm paying hundreds of outside of my health coverage to get therapy and how I'm paying thousands of dollars outside of my health coverage to get my teeth taken care of. Teeth are part of the body, right? Isn't your brain part of your body? [laughter] Why is that not covered? Modern dentistry again, it's a gift, but it's out of pocket for [chuckles] most of us, if we want to say things like, “The treatments that could save your teeth are cosmetic and not covered for the poorest of people.” That makes me so angry. [laughs] I'm liking that this is a demonstration of an ADHD mind at work because I'm all over the place. CHANTÉ: I like it. I welcome it. [laughs] It's completely fine. ARTY: One thing I'm thinking just listening to this and you talking about authenticity, masking, this pressure in society to wear a mask. In a world that becomes increasingly more fake, propagandized, and all of these things where people become almost not real to us, that seeing you being yourself, being in tune with what's going on with you, with your struggles, being will to cry, being willing to stand up and say what you really feel, and stand up for what you believe in. It's refreshing in a way that you look around where everything kind of becomes not real and you stand out as a beacon of light just by being in alignment with yourself and other people connecting with you. You give them permission to take their own masks off. You give them permission to admit their own struggles. Because we all have struggles, right? We all have these things that are hard for us, but it's easy to fall under that same pressure of having to wear a mask all the time. You being in tune with your authenticity is so powerful in terms of the weight that you influence the world and there's no reason you need to change. You just keep on being your beautiful self. 
CHANTÉ: Yes! [laughs] DAMIEN: Yes. NIKEMA: Man. Now I'm crying again, but thank you so much for that. It took so much to step out into the world and say, “Here I am, this is me,” because like I said, I was so shy. I would get butterflies every time I had to raise my hand in class and I would cry. [chuckles] Like I said, when I would do any kind of public speaking, I would be sweating, shaking, crying. It has been a hard road DAMIEN: And in a world are emotions are forgotten, making them visible and feeling them and allowing people to see them is a revolutionary act like when you do that, you are setting a path. You're blazing a path for people to follow, to get us to a place where there isn't so. It's not because it's not like people don't have emotions. It's not like you're the only one feeling things. It's just that other people don't have the courage to be seen, to not hide it. NIKEMA: I want to thank you for bringing that up because it reminded me of something that I used to say, which is for Black women, we're not seen as soft. [chuckles]] We're not seen as being in need of comforting and protecting. So I used to say that I'm radically soft [chuckles] and again, it's the mutant superpower. Sometimes I wish I could turn it off and just not let it all out. [chuckles] But I do appreciate what Arty said about giving other people permission to be themselves because I've been running a lot of Twitter Spaces lately and I always feel so honored with people say, “Yeah, this is my first time speaking in a space.” Because to me, that means that I have facilitated a safe space for people and I always celebrate them and I always just feel so honored when people are willing to step up and be seen that way because I know how hard it is. But being radically soft, maybe I should put that back in my bio [chuckles] because – [overtalk] CHANTÉ: I love that. Yes. NIKEMA: Yeah. CHANTÉ: I love that and I can relate, too. I like where you were going with the whole conversation, which I think is worth noting and talking about a minute because I grew up – Nikema, I'm half Black, I'm half Mexican. My mom's an immigrant. So on both sides of my family, I always felt like there was no time to be sensitive, soft, and to be in my feelings. I actually got called out a lot as a kid because I was very emotional and I was like, “I just thought I was highly empathetic and intuitive and what the hell's wrong with y'all?” [laughs] But it was something that I got made fun of and ridiculed for and eventually, tried to suppress, which I felt really impacted my image of myself and what I felt like I should be projecting into the world. And ultimately, my self-confidence to the point where, like you said, you hit a breaking point because I was masking all the time and trying to basically posture myself to be something. I was highly gifted and talented and was in these advanced classes, just like you, and it's interesting. I never thought anything about technology. I loved it just like you're describing it and I find myself interwoven into the community, not a technologist, but somebody who's recruiting and focusing on the culture and the talent of those organizations. So one of the things that as I was reading about you and just hoping that we can weave into the conversation is your approach to seeing people for their whole selves. I really appreciated when I read that about you and saw that you had been taking effort, once you got into technology, to build it seemed like a community, or spaces where you were going to allow people to show up and be their full selves, which in my mind and from my point of view, I'm assuming that's like okay, then if we're going to do that, we need to know who you are, the unique identities and intersectionalities that you bring to the conversation, or to the space. I'm just curious if we could go down that path a little bit, because I want to know how you've turned these, I put in air quotes, “adversities” into a power, into something that's really great. So tell us about that. How you've used all this stuff about yourself and your experiences thus far to do what you're doing right now, which is you've built a few different products and I'll let you talk about that in technology. NIKEMA: I will talk a little bit about my founder journey, I guess, because I did start a company. This was also a part of my coming out because even through college I was always overlooked and pushed aside by stronger personalities. Whenever I had a group project, it was just always a bad time [chuckles] because I never felt insecure about my skills, or my ability to contribute. But I did have a problem with like standing up and like making sure that my contribution was included. So I finished my web developer certificate and I was like, “I'm going to go get a job now,” and I was again, thinking I can get a job as a developer and I can work from home. I could still take care of my babies; still take care of my kids and I could do this job from home. Back then, remote work was not widely available like that. It was almost more of a perk [chuckles] and reserved for more senior people, people who had more career experience than someone who had just be coming in from junior college. But still, that's what I thought I was going to do. I'm going to work from home. I was having a hard time finding that kind of job [chuckles] and I was also feeling like I didn't get enough practical hands-on experience in my program. So I started going into the community. I started going to meetups. I volunteered for some nonprofits helping kids, teaching kids tech classes. I joined a startup weekend and I joined this startup weekend as a developer because I'm like, “I'm going to practice these skills. I need to get hands-on skills to get a job.” Didn't actually get to do any development work. But this was important because I'd never taken that much time away from my kids before and I took a whole weekend to build a startup. That's what the point of startup weekend was to start with an idea and build a product and pitch it. My team won, which was like, wow. The entrepreneur switch turned on in my brain, it was like, “Oh, my contributions matter, my work matters, and I can start solving these problems that I care about because no one else seems to be working on them.” And when that happened okay yeah, we won. Very quickly after we won, the person who came up with the idea for our startup decided that she was CEO. She also decided that she was going to fire the rest of the team, take our prizes, and go off and build a startup for real with a friend of hers and I was like, “That's not going to happen.” [chuckles] I was so angry. I was like, “This is the first weekend I took away from my kids. This was the first time I felt like my work was being recognized and that my work mattered and you're going to try to take that from me? Hell no.” Like, “No, that's not going to happen.” I could go on about that story. I don't really want to, but I will say that I alerted the organizers of the startup weekend. We ended up being disqualified, but that was also my origin story as a founder. So I decided to go and try to build something to solve my problems and my company that I ended up forming is called PopSchools. It's still a company. I'm still paying taxes on it. That started my founder journey. My company was eventually called PopSchools and in the first iterations, it was like a school alternative, an alternative school. I was homeschooling my kids at the time. Didn't really feel like they were getting the best experience out of that and I didn't want to put them back in school because I didn't feel like they were getting a good experience in regular school either. At first, it was a school alternative program. Then the later iterations, were a co-working space that is family friendly and age inclusive. So students would be first class citizen in this co-working space. They would have a homeschooling program and an afterschool program for kids who weren't homeschooling and also, a workspace for parents. So kids are taken care of, kids are doing their thing in a rich environment that is accommodating to them, and parents also have a place to do their remote work because I'm still on this remote work thing. I don't want to go sit in an office. That was a later iteration. Then I kind of played with, well, I had ideas about education, school choice, and all of those things. But also, I learned over time that if you are not financially stable, or somewhat financially well off, you don't really have school choice. You could have the best programs in the world, but not everybody is able to homeschool and not everybody was able to give up the services that they're going to get by having their kids in public school. It's really interesting that I felt very vindicated when this pandemic hit, because I'm like, “All of you people who did not understand what I was doing [chuckles] a couple years ago, were just kind of like, ‘Oh yeah, sucks to be you' when it came to the options for school and homeschooling,” and how homeschooling was not the experience that I thought it should be. All those people who didn't understand got firsthand experience and what it's like to have to homeschool [laughs] and what it's like to not have that support in place for a family that's not in a public school. So I felt vindicated because I'm like, “Now you all understand, you understand what I've been going through,” and I kind of feel like it's a good time to pick up [laughs] that project. Because like I said, a lot of people understand why there's a need for it now and a lot of people also found that school can be damaging this to some kids. Some people found that their kids were better when they didn't have to go to school. They were better mentally. They felt safer. I've heard things about the racial trauma. A lot of schools that are – the school to prison pipeline is a thing I don't want to get into that, but some schools are great and a lot of schools look just like prisons. So being home was a relief for some of these kids. DAMIEN: I want to repeat something you said: school can be damaging for children and that there's a trope in this country of children hate going to school, right? Like, “Oh, they're pretending to be sick to not go to school. They're ditching school. They don't want to be at school.” So the question is why. Nobody stops to ask why are we doing this to our children, putting them environments that they don't want to be in? What harm is that causing? Why don't they want to be in these environments and why are we not asking those questions? CHANTÉ: Yes. The question I've been grappling with, and I feel like this is appropriate group of folks to talk to and pose the questions, what is the purpose of school? Is the purpose of school to be childcare because we live in an industrialized society that demands adults to be awake [chuckles] and at work, at their attention at desk at dawn and then to dusk? Is that the purpose of school to be a holding place for those children and/or is it to allow for children to have a social and emotional experience with one another, to learn how to be friends, to learn about people who are their neighbors, and then to build a community? Is it to prepare children for a job that they're going to take in this industrialized world? And if our industrialized world is changing because of the applications of technology and where we're going with the future of work, do they need to be at school all those hours, or is there a new version of what education should look like? I think I'm just really frustrated, Nikema because I could really appreciate you saying now people understand. I felt the same way because I was a person who had to stay home with my kids for a while and not have an income. I so much dreamed and longed of a place where I could take my children that was healthy, welcoming, supportive communal while I was working for a few hours to hustle, or do whatever and it could possibly be a stimulating, positive, welcoming, loving experience for my children. But there wasn't one that existed. So I do think timing is everything. Maybe this is the right time to resurrect those efforts. But I love the question of what is the purpose of school and maybe we don't get to answer that question today, but I think it's worth just pinning and asking to you and to the listeners today. NIKEMA: I love that because that was exactly what I was pitching [chuckles] back when I was trying to be the WeWork of homeschooling [chuckles] and I could also get into VC, tech startups, and my beats with that because I was watching, I was like, “These white men have very ordinary ideas. They're not really reimagining anything, but they are being funded in the millions.” And I could see – I like to call out that tech claims to be tech leaders and VCs claim to be data-driven. But if we're all data driven, I can look and see that as a Black woman, my chances of being venture funded at the level that I would need to be are slim to none. My chances are slim to none. Black people as a whole get a fraction of a percent of all venture capital. So why should I put out this energy to pitch my ideas and ask for funding when chances are, I won't get the funding that I need going down that road? But that was exactly what I was pitching and back then, I would try to get people to imagine if your kids weren't in school, where would they be? Okay, home [chuckles] is an option, but you quickly find out if you start homeschooling after being in school, the world is not set up for children. Children are not welcome everywhere and you might think, “Okay, well, what about the library?” The library is the library. It's not a place for children to be children so much, like you're supposed to be quiet. [laughs] They have children areas. It's not a place where you could be instead of being at school. You could go to a park. You could do that, but it's a park. So if you think about it, if school didn't exist, where in the world, where in your world are kids going to be accommodated? There aren't really places to go and so, that's why I was like, “Homeschooling is very exclusive.” It's not something everybody can do and there are a lot of subgroups and not even subgroups, but maybe the dominating narrative of what a homeschooler is that I did not align with. I don't want to be aligned with religious fundamentalists. I don't want to be aligned with child abusers and people who want to keep their kids home because they want to shelter them from the world and they want to teach them their own worldview. I don't want to be aligned with that. It probably is a good time to look at this again and it's sad in a way because when I needed it the most is when I was really trying to go hard [chuckles] to start this and get backing for it. But my kids are old now. They're teens now and it was really that age group when they were 7, 8, 9, pre-teen where it's like, where do these kids go if they're not in school? What can they do? Because I don't necessarily want to put them in just classes. I want them to have a rich experience and back then, I was really into self-directed education. So I was like, “If it's not a class, if it's not school, there's literally nothing.” [laughs] There's nothing they could do, but go play at the park, or hang out in the library for a few hours, or stay home. So PopSchools was very homeschool, alternative school and it always had that aspect of like, “I need a place where I can go with my kids [chuckles] and I could do my work.” We had some things happen where even outside of being in school, my kids still weren't safe. [chuckles] So I was like, “I need to be somewhere where I know my kids are safe,” but I didn't have any money. I had less than $0 all the time [chuckles] and it's not really a position to start a business from. I did have a network and I did meet some great people in tech, VC, and all that and they were like, “Nikema, go get a job.” [chuckles] Like, “You need to get yourself stable, take care of your needs, and then once you're okay, then you can start working on that business. You can start putting your energy, time, and money into building the business that you want to build.” So I did that. I went out and got a job. There's a lot of extra to story, too that I don't want to get into. But I think it was 2019 when I started this public Twitter job campaign where I was like, “Watch me get this job.” I think I was documenting my job search, documenting my interviews, and counting my rejections and I did finally get a group of offers in, I think it was 2019. Two were for solve engineering. One was for a community manager role. I took the community manager role because I was very much wanting to be in tech and in community. I don't want to be heads down in code because like I said, my superpower is connecting to people. So it's probably not the best use of if we're talking about, like Chanté said, the whole person [laughs] to sit me in front of a computer to code. I want to be in the community with people. So I took that community manager role—it was also the highest base pay out of all my offers—and I connected with the hiring manager. So that was my choice and that was the last offer to come through. I took that and I worked there for a year. I just left in October of 2021. I was there for a year and a couple months and oh, I skipped over a lot. But talking about the whole person and I feel very strongly about equity and inclusion, I will say in tech, but specifically for people who are career switchers and so-called non-traditional technologists. I care a lot about that because I see things from this unique perspective, because I have experience as a student, I have experience as a founder, I have experience as just a parent, a single parent, someone coming from not a lot of money. I have this unique way of seeing things and I can see very clearly when things are set up to exploit people and it pisses me off. It makes me angry and I had to learn how to that energy towards something productive. Because just throwing it out there and trying to scream into the void, it seems like no one's hearing you and it seems like the things that you're calling out are just being ignored. That's a waste of energy. So I had to learn how to direct it and I started directing it by helping individuals and again, by showing up. Showing up and speaking, even if nobody's listening. I told myself, “When you're in these rooms with people that you admire and people who are influential, stand up and say something because nobody else has that perspective. Nobody else is going to say what you're going to say.” And it's not even possible. It's not possible for someone to speak your perspective and I had to learn that you need perspective is valuable. There's a quote, and I really need to find out who said it first, [chuckles] but it's, “You're an expert in your own experience,” and I latched onto that because there's a lot of – it's another one of my pet peeves is this imposter syndrome thing. But there's a lot of people who are being made to feel like they're always going to be – I call it the tech underclass. You're always going to be lesser [chuckles] than the people who have degrees, or the people who've been in this for years, and the people who are already in the industry. Here you are coming from your non-traditional background and you're always going to be lesser than those folks, and you are going to have imposter syndrome, get used to it. So I latched onto that idea of I'm an expert in my own experience and my experience is value. Bringing that up and speaking it out is adding value. It is doing a service and it's a service that nobody else can do. That's when I started kind of committing to myself that even if I'm scared, I'm going to stand up and speak. I'm going to let people know that I was in the room. But I do want to talk about imposter syndrome. So my beef with imposter syndrome is not that it's not a thing. I'm sure it is, [chuckles] but I feel like it's being thrust upon us. I feel like people are saying, “You're a woman in tech. You're a person of color in tech. You have no degree and you're trying to get into tech and you're going to feel like a fraud,” and I don't feel like a fraud. Why are you introducing that to me? I feel like another part that bugs me about it is that it's shifting the blame onto the individual for some actual, rational reactions to a hostile environment. If you're telling me, “Hey, it's natural, it's normal, it's okay to feel like you don't belong here,” you're kind of saying it's a me thing, but it shouldn't be natural and okay for me to feel like I don't belong here. Like, why is this environment not including me? I'm actually reacting to people pushing me out of this space, discriminating against me, and showing their bias against me. So what's wrong with me for noticing that? What's wrong with me for feeling that? Why aren't we talking about the folks that are making this an unwelcome place? That are making people feel bad? Who are saying out loud, “We don't want you here”? It's putting the attention in the wrong place. Instead of saying, “It should not be okay, that should not be a normal thing to feel like you're not good enough and you don't belong.” I'm not saying that it doesn't exist. This is how I think of it. The actual definition is you are capable and skilled, but you feel like you're a fraud and someone's going to find you out. I don't think that should be normalized and encouraged, and I feel like it is being normalized and encouraged that it's normal to feel like you don't belong here. DAMIEN: Yeah, it's rampant and it's something that a lot of people go through. The question is why? What is it about those environments that's causing that and why is it some people experience it and some people don't? I've seen the opposite of imposter syndrome. It is mindboggling. ARTY: Well, there's this general first principle of whatever we focus on and grows and when we have these concepts, like imposter syndrome, that we learn about as these psychological concepts that then we internalize into ourself. Does that end up amplifying the experience of like if now I'm thinking about, “Oh, I have imposter syndrome and now I'm having all these feelings where I feel this certain way, too.” Do we end up amplifying those things even more by creating that frame and then as you said, normalizing it? It's like, “Oh, it's totally okay that you feel that way. You're supposed to feel that way. That's a normal thing.” Then we end up not dealing with the fundamental problems that we're actually creating these sort of tech, underclass, second class boundaries with the way we sort of create our group collective and we are pushing people out and then normalizing the fact that they feel unincluded. I totally agree. It's putting attention on the wrong aspect of things such that as opposed to focusing on the things that are potentially corrective, that might improve the inclusivity of the culture and us thinking about how we're creating mental groups and how we can create more inclusive mental groups, instead we're normalizing the exclusion. NIKEMA: Yeah. I almost titled my book, The Underclass, [chuckles] and I decided against that because again, I want to be positive [chuckles] and I'm probably still going to say some of the same things that I plan to say in that book. But this whole thing about – and this is part of the rage [laughs] that I have to redirect is because I went through a coding bootcamp that cost $30,000, up to $30,000 of potential future income for a lot of the students that attended that school and I saw the messages coming from the leadership and the people who were really gathering these people up and funneling them into bootcamps. First off, I saw a lot of just wrong, [ chuckles] like wrong advice being given out and I saw a lot of cultural incompetency because a lot of these bootcamps are run by white men and a lot of the students are not that. So I'm like, “Here I am with this perspective, I'm a founder, I've talked to investors, I've been a student. I know how to code.” [chuckles] From that perspective of, I have a viewpoint that most students don't. So I'm seeing absolute wrong advice being given out. Like when we're talking about looking for that first job, your first job at tech, you're so-called breaking into tech, which I hate that term. We're not breaking in, let us in. [chuckles] Why should we have to break in? DAMIEN: Open the door. NIKEMA: Yeah. There are so many jobs that are not being filled. Why? Why are we gatekeeping? But wrong advice, like, “It's a numbers game. You might have to do hundreds of applications.” That's giving people wrong advice [chuckles] and it's giving people advice that you yourself never did. I know for a fact. These are people who have strong networks – Oh, most egregious wrong advice. Part of the problem is these people were better marketers than people who could run a school. But there was a thread on Twitter. I remember seeing it. It was a young Black woman. She was graduating high school, she was going to college, and I think trying to decide about what college to go to and someone comes into this thread and recommends Lambda School to her and I'm like, “Absolutely fucking not. How could you?” Like, “How could you?” [chuckles] Like, “How could you tell a Black woman with all of this going for herself, who's going to be on a path to like –” I don't know. I'm just saying you're suggesting something very low value and especially low value to a Black woman because the people who ran that school did not have the cultural competency to give advice to anyone other than white men, I'd say. Maybe abled white men. [laughs] I don't know, but just wrong advice. A lot of anti-intellectualism anti-degrees like, “Oh, this is better than a degree education.” Absolutely not. Credentials matter more for people of color, for people who are minoritized in tech. Your certificate from an unaccredited school means absolutely nothing compared to a degree in computer science. So it's rage-inducing for me to see that people are being exploited and pointed towards these programs that are not going to do what they're advertised to do for them and they're not even capable of knowing that they're giving the wrong advice. I opted out of career services when I was in a bootcamp because I saw the kind of advice they were giving and that's part of my, I guess, I'm going to call it activism today is I really want people to know what's really up. I want them to not devalue themselves and not allow others to devalue them. Because these people who know good and well what's up, they know good and well how things work, are leading them astray and they're leading them into jobs that are going to underpay them and they're not going to be satisfying and they are misleading. Misleading in what it takes to get to where we're all trying to go. I would just like to say to whoever's listening to this and you're maybe getting into tech, don't be discouraged, but also, do your due diligence. Before you start agreeing to pay anything that's tens of thousands of dollars, even thousands of dollars, see who these people are, see what the outcomes are, and talk to the students who have gone through that program. Talk to the students who weren't successful. Talk to the ones who were successful because a lot of these success stories are skewed. When I went to bootcamp, it was better than free for me. I never had an income share agreement. I had a scholarship. I had a stipend. So I was actually getting paid to attend. I always like to say that you could take my story and make it look like a bootcamp success story, but you would not be seeing the 20 years before that when I started to learn how to code. You could tell that story in a way that doesn't show that part. You could say, “Nikema was this single mom with no job who joined Lambda school did 15 weeks, then got a six-figure job the next year.” That would be true, [chuckles] but that would not be a Lambda success story. That is, Nikema worked her ass off [chuckles] for decades before Lambda was even thought of to get to where she is today and I feel like that story is left out. CHANTÉ: Nikema, that is such an amazing point to make and I want to run the balance of the time we have left, but I just want to say – I think we have a few minutes to get into reflections, but I just want to say before we do that, that having conversations about diversity and inclusion in tech doesn't means really nothing to me. We need to have conversations about equity and accessibility because equity is actually what you're kind of describing here. We have to be able to see the whole person and this is why sometimes it's important to call out the institutional and systemic racism that's widely pervasive in the industry and beyond that is happening all over our country, all over our world. and it is such, I hope a deeper conversation that needs to be had. I'm here for it if you want to come back, or we can continue the conversation on Twitter Spaces, or something. I'm there for that, invite me. But there's a lot here and I really appreciate you giving that advice because we do need to have open, honest, authentic conversations show who you really are. I'm looking forward to getting folks' reaction, but I really want to move us into reflection, if that's okay, just to respect everyone's time. NIKEMA: That's okay with me. CHANTÉ: Anybody want to go first? Anybody, Arty, Damien, you have a reflection? DAMIEN: I can go first. Really, the thing I'm going to be taking away from this—and Nikema, thank you so much for joining us here—is that connecting through authenticity and the power of that. It's not the first time I've heard words of that nature, or that idea, but getting to witness it in-person has been a really powerful experience and that's going to be something that sticks with me for a while. So thank you. ARTY: Yeah, I think you gave a very good demonstration of your superpower here, though of just being yourself, standing up, and saying what you believe and what you think and stuff. I can even see how those things just affected me and affected people in this room and being able to connect with you so that we could have a very real conversation. I think the thing that I'm going to be taking away from this conversation is you talked about even when you're scared, you stand up and speak and you're going to let people know that you're in the room and that you are an expert in your own experience and nobody else has your unique perspective. I feel like that's something that all of us have so much power in ourselves to stand up and speak in our own authenticity for our own experiences and be in the room. Even when we're scared, to go after and do it anyway because by doing so, too it gives other people permission to do the same. It creates opportunity for other people to take their mask off and create space for them to be themselves and for them to stand up. It's kind of like a chain reaction that happens. So if we can all start to do that and all start to create space for people to do that, that's the kind of stuff that one person at a time changes the world. CHANTÉ: Thank you for those. I'm really appreciating, Nikema your authenticity and your rawness. I think it's beautiful. It just really resonated with me. So I felt like I was listening to a version of myself, just listening to your story. What I think I wrote down, the aspiration that you had about children and making sure that they feel like where in our world are they first class citizens. That really stuck out to me because I think that our youth is our future and I'm really committed in this portion of my life to building and doing whatever I can to make sure we build a future that is inclusive, equitable, and accessible to everyone. I think we've got to lean in and look at our youth and I hope that they're learning from some of our – not necessarily failures, but some of our places in our lives as adults where we fall short of kind of build world that's fair and awesome. So I really want to take that and do something with it and I'm really inspired. Thank you. NIKEMA: Thank you for letting me speak like, I can go on and on, so. [chuckles] I appreciate it. CHANTÉ: Thank you. Do you have any reflections before we close off the conversation? NIKEMA: Yeah, just last thing. I just wanted to say thank you again and I really appreciate and I have come to enjoy my story. It's because of the things you told and it's because I recognize that it is how I connect with others and that is the good side of the mutant superpower is that I do get to make real connections with other people. DAMIEN: Thank you. Thank you so much for being here.

01:56 - Episode Intro: Who is Casey Watts (https://twitter.com/heycaseywattsup)? * Happy and Effective (https://www.happyandeffective.com/) 02:25 - “Gay” vs “Queer” * Cultural vs Sexual * Black vs black * Deaf vs deaf 06:11 - Pronoun Usage & Normalization * Greater Than Code Episode 266: Words Carry Power – Approaching Inclusive Language with Kate Marshall (https://www.greaterthancode.com/words-carry-power-approaching-inclusive-language) * Spectrum of Allyship (https://aninjusticemag.com/the-differences-between-allies-accomplices-co-conspirators-may-surprise-you-d3fc7fe29c?gi=decb57b48447) * Ambiguous “They/Them” 16:36 - Asking Questions & Sharing * Ring Theory (https://www.everhomehealthcare.com/post/ring-theory-and-saying-the-right-thing-in-2020) * Don't Assume * Take Workshops * Find Support * Set Boundaries * Overgeneralization * Do Your Own Research – Google Incognito (https://support.google.com/chrome/answer/95464?hl=en&co=GENIE.Platform%3DDesktop) 28:16 - Effective Allyship * Reactive vs Proactive * Parenting * Calling Out Rude Behavior – “Rude!” * Overcoming Discomfort; Getting Comfortable with Being Uncomfortable * Recognizing Past Mistakes: Being Reflective * Stratejoy (https://stratejoy.com/) * Celebrate Progress * Apologize and Move On * Microaggressions: Prevention & Recovery (https://www.happyandeffective.com/workshops/list/avoiding-microaggressions) * happyandeffective.com/updates (https://www.happyandeffective.com/updates) Reflections: Mannah: The people on this show are all willing to start and have conversations. Casey: I will make mistakes. I will find more support. Mandy: Reflection is always a work in progress. It's never done. Keep doing the work. People are always evolving and changing. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: PRE-ROLL: Software is broken, but it can be fixed. Test Double's superpower is improving how the world builds software by building both great software and great teams. And you can help! Test Double is hiring empathetic senior software engineers and DevOps engineers. We work in Ruby, JavaScript, Elixir and a lot more. Test Double trusts developers with autonomy and flexibility at a remote, 100% employee-owned software consulting agency. Looking for more challenges? Enjoy lots of variety while working with the best teams in tech as a developer consultant at Test Double. Find out more and check out remote openings at link.testdouble.com/greater. That's link.testdouble.com/greater. CASEY: Hello, and welcome to Greater Than Code, Episode 268. I'm Casey, and I'm here with co-host, Mannah. MANNAH: How's it going? I'm Mannah and I'm here with Mandy Moore. MANDY: Hey, everybody. It's Mandy and today, I'm excited because we are doing a panelist only episode. So our host and panelist, beloved Casey Watts, is going to take us through Casey did a LGBTQ panel for Women Who Code Philly a couple weeks ago and it went really great. He offered to do a show to talk about the subject in more depth on the show. So we're here to do that today. So without further ado, why don't you give us a little intro, Casey? CASEY: Sure. I'm going to start by talking about who I am a little bit and why I'm comfortable talking about this kind of stuff. My name's Casey, I'm a gay man, or a queer man. We can get into the difference between gay and queer [chuckles] in the episode. I live in D.C. and I really like my community groups that I'm in to be super inclusive, inclusive of people of all kinds of backgrounds and all the letters in LGBTQIA especially. MANDY: That's awesome. So right there, you just gave us an in. Can we get into the difference between gay and queer? CASEY: Yeah. I love it. People lately use the term “queer” as an umbrella term that represents all the letters in LGBTQIA especially younger people are comfortable with that term, but it is reclaimed. Older people, it used to be a slur and so, like my cousin, for example, who's older than me hesitates to use the word queer on me because she knows that it used to be used to hurt people. But queer people like this as an umbrella term now because it is just saying we're not the norm in gender identity, or sexual, romantic orientation, that kind of stuff. We're not the norm. We're something else. Don't assume that we're the norm and then it's not describing all the little nuances of it. It's just like the umbrella term. So I'm definitely queer and I'm gay. Another distinction that I really like to make and that's cultural versus specifically what the term means. So I'm gay and that I'm attracted to other men, but I don't hang out at gay bars and watch RuPaul's Drag Race like the mainstream gay man does in media and in life. I know a lot of people who love that I'm not comfortable there. I don't like it. I think drag queens are fun I guess, but they're also really catty and mean and I don't like that, and I don't want that to rub off on me personally. Instead, I hang out in groups like the queer marching band which has a ton of lesbian women, bisexual, biromantic people, asexual people, intersex people, and trans people and has all the letters in LGBTQIA and I love that inclusive community. That's the kind of group I like to be in. Some of the gay men there talk about RuPaul's Drag Race, but it's like a minority of that large group. I love being in the super inclusive cultures. So I'm culturally queer, but I'm sexually romantically gay. So depending on what we're talking about, the one is more important than the other. I have a story for this. Before the pandemic, I got a haircut at a gay barber shop. It's gay because D.C. has a lot of gay people and there's a gym above the barber shop that's pretty explicitly gay. They cater to gay people. They have rainbows everywhere. I got my hair cut and this woman just kept making RuPaul's Drag Race references to me that I didn't get, I don't get it. I don't know what she's saying, but I know the shape of it and I told her I don't like that and I'm not interested in it. Please stop. She didn't because she was assuming I'm culturally gay, like most of her clientele and it was really annoying and she wasn't seeing me, or listening to what I was saying and I was not seen. But she's right I was gay, but I'm not gay culturally in that way. Does that make sense? That's kind of a complex idea to throw out at the beginning of the episode here. A lot of people take some time to get your head around the cultural versus sexual terms. MANNAH: Yeah. That is interesting especially because with so many identities, I guess that's true for every identity where there's a cultural element and then there's some other thing. For instance, I'm a Black man and no matter where I hang out, or what I'm interested in, I'll always be a Black man, but there is associated with both masculinity and specifically, Black masculinity. CASEY: Yeah, and I like the – lately, I've been seeing lowercase B black to mean a description of your skin color and uppercase B Black to mean a description of the culture and I like that distinction a lot. It's visual. Deaf people have been using that for years. My aunt's deaf so my family has a deaf culture. I'm a little bit deaf culture myself just by proxy, but I'm not deaf. I'm capital D Deaf culturally in amount. Her daughter, who she raised, my deaf aunt, is culturally Deaf way, way more than the average person, but not fully because she's not deaf herself. So there's all spectrum here of cultural to experiencing the phenomenon and I was happy to see, on Twitter at least, a lot of people are reclaiming capital B black. And for me, it's capital Q Queer and lowercase G gay. That's how I distinguish into my head—culturally queer and I'm sexually gay. MANNAH: So one of the things, I've been thinking about this since our intro and for those of you listening, our intro is scripted and as simple as it was like, “Hey, my name is Mannah,” and passing it off to Mandy. Generally, when I introduce myself – I just started a new job. I introduced myself with my pronouns, he/him, because I think it's more inclusive and I want to model that behavior and make sure that people around me are comfortable if they want to share their pronouns. I do think that this is championed by the queer community and as a member of that community, I'd just love to hear your take on people being more explicit with that aspect of their identity. CASEY: I love the segment. Pronouns is a huge, huge topic in this space lately especially. I like to start from here, especially with older audiences that we used to have mister and miss in our signatures and in the way we address letters and emails, and that's gone away. So including pronouns is a lot like just saying mister, or miss, but we've dropped the formality. I'm glad to be gone with the formality, but we still need to know which pronouns to use and it's nice to have that upfront. I like and appreciate it. I try to include pronouns when I remember it and when I'm in spaces where that's a norm. I like to follow that for sure every time there. But I'm not always the first person to introduce it. Like if I was giving a talk and there were 30 older white men in the audience who've never heard of this idea, I might not start with he/him because I want to meet them where they're at and bring them to the point where they get it. So I'm not always a frontrunner of this idea, but I love to support it, I love to push it forward, and help people understand it and get on board. It's like there's different stages of allyship, I guess you could say and I really like helping people get from a further backstage to a middle stage because I don't think enough people are in that space and there are plenty of people getting people who are in the middle stage to the more proactive stage. Like, “We should use pronouns!” You hear that all the time in spaces I'm in. It's possible I can get pushback for that kind of thing, like even meeting people where they're at, and that frustrates because I want to be effective. I don't want to just signal that I'm very progressive and doing the right things. I want to actually be effective. I give workshops on this kind of thing, too. That's where we're coming from for the today's talk. MANDY: I think on the last show, it might have been Kate Marshall who said that normalizing pronouns is really important to do, but not just when there's an obvious person in the room who you're not sure. Maybe we even started off on the wrong foot on the show by not saying, “Hi, I'm Mandy, my pronouns are she and her.” Just adding that in to normalize it would be a really good step, I think. CASEY: Yeah, love it. Here's where I like to come with my role. Say, “Plus one, I love that idea. Let's do it now.” I like to activate the idea once it's in the room, but it takes someone brave to bring it up in the first place and it's a different amount of social energy, maybe in a different head space you have to be in to be that first person. But being the second is also very important and I like to help people understand that, too. If you're the second person, that's still being helpful. Maybe you can become the first person in some groups, but I want to celebrate that you're the second person even. That's great. Yeah, I think that's a good change we could do. MANNAH: You mentioned allyship and I think that that is why am so proactive in introducing myself with pronouns because I do present as a traditional man. Well, maybe not traditional, but I present as a man and I have the ability to deal with some of that pushback. We talk about superpowers on the show. I feel like one of my superpowers is I am willing to engage in those conversations, even if they are difficult. CASEY: Mm hm. MANNAH: So I can use my powers for good by starting that conversation perhaps, or starting to build that norm. Whether, or not I am doing it for anyone in particular, it is important for me to do it wherever we are. So I think that just wherever we can make spaces more inclusive with the way we can conduct ourselves and our language, it's important. CASEY: I have a framework to share that's kind of related to that. So there's a spectrum of allyship—that's my title for it anyway—that goes from an active detractor all the way over to an active supporter of an idea. In this case, the active supporter would be getting pronouns to happen in a space where they're not happening. And then in the middle, maybe you're neutral, not doing anything. In the middle on either side, there's a passive – like you're not doing anything, but you kind of support the idea. You're kind of against the idea, but you're not taking any action. And then on the active part, there's even a split between and being proactive and reactive. So for pronouns, I guess the way I'm self-describing here is I'm a reactive pronoun person. For better, or worse, that's where I'm at on that spectrum and that's where I like to help move things along. So I can talk to people who are more maybe passively against the idea because I'm not so far on the right. I like to use the spectrum for another purpose, which is moving people from one space to the next is valuable and often invisible. If you can get someone to be loudly against pronouns to just be quiet, that's a step forward. You've persuaded them a little bit to go in that direction, or if they're there to neutral, or neutral to passively supportive, but quiet about it. A lot of this kind of progress with people who aren't active supporters is invisible and that can be really frustrating for people; it feels like you're not making any progress. So for people who are allies and want to be allies, there's a step forward you can do for yourself, which is getting yourself from being reactive to being proactive. But you're not just helping the people in the room, but helping people who could be in the room, or might be in the future. Reactive to proactive. MANDY: I've been doing that a lot with just actually referring to everybody as they/them no matter if I already know how they present, or not. That, to me, is just the most inclusive way to refer to people in general. CASEY: Yeah, that's generally a safe practice, but there are people who don't want to be called they/them. MANDY: Hmm. CASEY: For example, I have some friends who… Let's imagine a trans man who wants to be considered he/him, they are very invested in this and they want the – If you keep calling them, they/them, even if they correct you, “He/him is my pronouns,” then they're going to be upset about that, pf course. But it is a safe, starting point because the ambiguous they is just generally, it's good grammar, the APA endorses it even. You're allowed to use they when it's ambiguous by grammar rules. But if you know someone's pronouns and it isn't they/them, it's generally better to use those because they prefer it. MANDY: Yeah. That's what I meant. If somebody says to me, “I would prefer you call me she/her, he/him.: But when I'm first, like if I'm even talking to say my dad and I'm talking about work, I would be like, “I have a friend, they did this.” CASEY: Yeah. That's ambiguous day and that's perfectly appropriate there. MANDY: Yeah. But as far as like addressing somebody on a regular basis who wants to be referred to as one, or the other, I have no problem doing that. I've just been training myself to use ambiguous terms because I see and I think it's wonderful. My daughter's 12 and almost all of her friends are non-binary. So when I meet them, or I'm talking about her friends for me, it's just more, I don't want to say easy. I don't want to make it sound like I'm doing it, like taking the easy way out, but I'll just be like, do the they/them stuff to have the conversation and then once I find out more, we can transfer over to the he/him, she/her as I'm corrected, or being asked to do one, or the other. CASEY: Right, right. It's definitely safer to assume you don't know than to assume someone's gender based on how they looked, for sure and the ambiguous they is perfect for that. Even for people who use they/them as pronouns, there's a switch in my head at least—you probably feel it, too—from ambiguous to specific. Like now I know they/them is their pronouns. MANDY: Yeah. I've had no problem. When my daughter has brought new people over, who I know are non-binary, I will say to them even if I already know, because she's told me, I'll be like, “What pronouns do you prefer?” And every single time these are 12-year-olds, 13-year-olds, they're like, “Thank you for asking.” CASEY: Yeah. MANDY: Because a lot of times, I feel it's not very accepted yet. So when I hear, or when they hear me say, “How would you like me to refer to you?” They smile so big. CASEY: Yeah, you're treating them like the individual person they are. MANDY: Exactly, and they're like, “Thank you,” and now I'm known as the cool mom. [laughs] CASEY: Ah. Great. [laughs] Yeah. If I could snap my fingers and change a behavior of mine, that would be one. I would consider everyone's pronouns unknown until they tell me and it also varies by context. I don't even want to trust secondhand. Like if Mandy, you said he for Mannah before I met him, I wouldn't assume that's his pronouns. If maybe you are assuming, or maybe you heard it from someone and they were assuming, or maybe based on context, it's different. I want to hear it from the person, ideally. MANDY: Yes. CASEY: I also don't necessarily want to go around asking for pronouns actively all the time. I'd rather us offer them upfront, or have them in our usernames, or something so it's less verbiage in the air about it. I like it to be normalized. We don't have to think about it. That's a dream state. But for now, I'd rather ask people directly than assume anything. But it's a hard habit because I've been trained from school and everything, since a young age, to assume someone's gender and not to use they at first. That's what we've been trained and I love this trend of untraining that. Ambiguous they is accepted and we should start with that. MANDY: I love seeing people proactively put pronouns in their Zoom profiles, or their Zoom names and at conferences, I love the conferences having badges, or stickers. CASEY: Yeah. MANDY: I love that. CASEY: It's helpful. MANNAH: I want to change directions slightly and go back to something you said about the spectrum and how we move people – I don't remember the exact words you used, the two polar opposites. CASEY: Yeah. MANNAH: But how to move people towards a more inclusive mindset, let's say and wherever you are on that spectrum, you might not know how to move forward and the way to kind of deal with that, you might have questions. I just want to hear from you how you would like to be approached with questions around how do you feel about pronouns, or whatever it might be relating to your culture, or your, I guess, I'm going to say sexual identity. CASEY: Yeah. MANNAH: People are unsure how can they approach you with questions in a way that's respectful and a way that will allow them to learn more about you? CASEY: Good question. I feel like you're reading my mind a bit here. I want to start with another framework that you might have heard of. It's the circles of grief Ring Theory. Like if someone just lost their parent, then you need to pour support into that person who's closest to them and if you're outside like a more distant family member, or a friend, pour support in and then the grief gets stumped out. That's the framework, generally. So there's a lot of rings. People who are closer to it are affected more directly and people who are outside are affected more indirectly. That applies to asking people personal things, too. So I'm directly affected by being queer and I've been discriminated against and people have said bad things to me before. To ask me about it and to bring up those feelings could harm me in some way so you can't just assume everybody's comfortable talking about their experience. Like, “Tell me about how you feel about your dead mother.” It wouldn't be sensitive either because they're experiencing the pain directly, but sometimes people do want to talk about that and they're comfortable, they processed it, and they want to help spread the word. So I'm one of those people; you can ask me anything. Even if you don't know me, you can DM me on Twitter. Anyone listening, ask me a question about queer things. I'll point you to a resource, or answer it myself. I'm offering because I'm comfortable at this point. But a lot of people aren't and, in that case, you could ask if someone's comfortable, that's not a bad idea, or you could ask people who are in further circles out. Like you don't need to ask a queer person about queer experiences if you can read about it in an article online, or watch a documentary, or talk to friends who have other queer friends and they know some things about it. It's not as good as secondhand experience hearing from someone with firsthand experience, but you're causing less harm by making the ideas come up again. So you have a range of ways you can find out more about what it's like to be queer and I encourage you to think about all the different ways you can learn about a thing. You don't have to depend on the person who has [chuckles] this negative experience to do it. Another way you can learn more is by doing workshops, like the ones that I facilitate. So I was thrilled to have a good audience at Women Who Code Philly, actively asking question and learning things, and that's a space where you're supposed to ask questions and learn. I've heard of some people have peers they can talk to like peer support; people you can go to, to ask questions like that. Like my cousin asks me questions sometimes about her kids and that's like peers. Some companies actually have support groups like a weekly, or monthly meeting for people in the company to ask these questions that they have [laughs] and they don't know where to ask them and they can all learn from it. I've seen in some Slacks, there's a Diversity 101 channel in one of the Slacks I'm in people can ask questions like when would you, or would you not use this word? That's a space dedicated to asking questions like that and if someone like me wants to go in and contribute, I can answer questions there, but I don't have to. I know I'm welcome to, and I know I'm not pressured to, and that's a great middle ground and that's a lot of options. You've got to figure out what works for you, who you have around, who you can offer the support to, and who you can ask for the support from. Both directions. MANDY: It's great to have someone like you offering to do that and take on because it is of emotional labor and sometimes when people are curious, I know for me as being bisexual, some people are just like trying to – they're asking out of curiosity, but it's more like, “Give me the dirty details,” or something like that. CASEY: Yeah. MANDY: Sometimes it's like, “We just want to know because I don't – so I want to know what it's like for you,” and I'm like, “I'm not going to share just because –” right now, I am in a monogamous heterosexual relationship. Normally, if I was in a single state, a lot of people just try to ask questions that sometimes can be, I find it more inappropriate and they want to know because they're interested in the salacious details, or something like that. CASEY: Right. MANDY: That rubs me the wrong way and I can usually tell when somebody is asking, because they're genuine, or not. CASEY: There's a big difference between asking to get to know you as a person in the context you're in with the background you have versus asking for salacious gossip. [laughs] MANDY: Yeah. CASEY: And the one is much more kind than the other. It sounds like you've done a good job setting boundaries in these situations saying, “That's not appropriate. I'm not answering that. Sorry about it,” or something like that. MANNAH: Not sorry. CASEY: Not sorry. MANDY: Well, in the same token, it's something that bothers me, too because I feel like a lot of times, I just don't even tell people that I'm bisexual. CASEY: Yeah. MANDY: Because it's easier to not answer the questions because once you open that can of worms, then everybody comes at you and wants to know this and wants to know details. “Have you ever done this?” Or, “Have you ever done that?” It rubs me the wrong way again. CASEY: Right. MANDY: So sometimes I feel almost resentful. I feel resentful that I can't be my full self because it causes people to just ask and the whole conversation, or the whole time I spend with them is focused on this one thing and it's like for me, it's just not a big deal. CASEY: Right, right, right. Like on my Twitter profile—I like to use this as an example—I list out like 10, 15 things about myself on my Twitter profile and there is one little rainbow flag emoji in there at the end and I'd rather you talk about any of the other things probably. I'm willing to share that I'm queer and rainbow I affiliate with, but so much more to me, [chuckles] I'd rather you learn about me before that. MANDY: Yeah. CASEY: But it's the newest, novelist thing to those people who don't otherwise get exposed to it. They fixate on it sometimes and that, they might not realize, can be harmful. It can hurt people like you. It does hurt people. [chuckles] MANDY: It absolutely does. It makes me uncomfortable. So it's not an aspect that I talk about much, especially living in rural/suburban Pennsylvania. It's something that I just kind of, aside from my internet friends and tech community, that a lot of people still don't know about me. CASEY: Right. I can imagine not wanting to share. I used to not share my sexuality either in a lot of contexts and still when I go somewhere like the south, if I go to a place that has more bigotry around, I'm not holding my partner's hand there. I might get attacked even, that happens still in certain environments, they don't get it. Okay, I want to acknowledge that people asking these questions might have good intentions and they're making a mistake and I want to explain what I think the mistake is. MANDY: Yes. CASEY: People want to be treated as individuals, but you can go too far in that extreme and treat someone like an individual and ignore their background. Like it doesn't matter that you've been queer. It doesn't matter that you're Black. It doesn't matter, I'm just going to treat you like an individual. Ignoring all this background is its own kind of overgeneralization in a way is ignoring that background and context. And then there's another way you can do an exaggeration, which is only focusing on that background in context and ignoring the person's individual traits and their individual experiences. The best thing to do is to treat them like an individual who has this context and background putting them both together. So maybe these people are trying to understand you better by understanding this context. Maybe—I'm being very generous— [chuckles] some of these people are probably not this, but some people honestly want to know more about your context to understand you and that's thoughtful. They're just going about it in a way that's not the most helpful, or kind to you and I appreciate those people. But then there are other people who want to use the background and context to overgeneralize and just treat you as a member of this group, a token member, and that is a problem, too. So it's like two ingredients and if you put them together, that's the best and a lot of people focus on one, or the other too much. The individual experience versus the group background context experience. MANNAH: Yeah. That was really well put. I do think that as I said earlier, I'm someone who is very willing to have these. However, the downside of that is that becomes who you're and instead of the entire human being and the other – to take it a step further, some people are uncomfortable with that identity, or uncomfortable thinking about those things. Think about the discrimination that you might face and rather than confront it, or address it, they would rather just not deal with you, or limit their interact. CASEY: Right, yeah. MANNAH: So this is not a question for Casey, this is just something to the group. How can we navigate that and wanting to being willing to share of ourselves, but recognizing that there is some social backlash that can come from that? CASEY: I think my number one thing I want allies to understand is they can support each other in being allies and it can take work to be comfortable talking to each other, to support each other. You don't have to just depend on the queer people to learn queer about things. If one of you learns and one ally learns, they can teach another ally the concept, or the idea, or share how to navigate it. I did a Twitter poll for this, actually. Not a huge sample size, but still. A lot of people only have 1 to 3 people they can talk to about things like this. That's very few and they might not cover all the different situations. So that's my number one thing to help people navigate it is get so support, find support, be support for other people and you'll get support in return for that, too. That's your homework. Everyone, write this down. Find 10 people you can talk to about inclusivity related topics, 10 people. MANDY: And Google exists for a reason. So always, when things come up, I like to Google and I've gotten push back about that several times. “Well, I don't want to put that stuff into my search engine because then all of a sudden, I start getting gay targeted ads,” or something. CASEY: That's true. That's a real concern. [overtalk] MANDY: And I'm, “It's not –” Well, hello, incognito mode. CASEY: Right. MANDY: Thank you, everyone. That's a thing. Use it. [laughs] CASEY: Yeah, and you don't have to feel icky using incognito mode. You can use it because you don't want to ads tracking you. MANDY: Exactly. CASEY: Some people use it for everything. They never use the regular browser mode because they don't want the tracking. It's work to learn things about other people and so, that's why I like to focus on the support part. If you get support from people, maybe you can both be looking up stuff and sharing articles with each other, and that's really multiplying the effects here. MANDY: Absolutely. MANNAH: So we started homework for allies. I think now it might be a good time to talk about what makes good ally. We talked a little bit about how it can feel voyeuristic. Mandy, you talked about how people asking questions can sometimes feel a little picky and we talked about some better ways to asking questions. But are there any other ways that either both, all of us would like to see people be more effective ally? CASEY: Yeah. I want to call back to an earlier point. I want to see more people switch from being reactive to being proactive. To being the first voice. Me included, honestly. Whenever you can get away with it and whatever helps you be proactive, do those things, which might be the support thing I keep talking about. Getting support to be more proactive, becoming accountable to people. If you're already an ally, I'm assuming you're being reactively supportive some of the times. A lot of the people I talk to, who consider themselves allies, would agree, but taking that next step. And there's a different spectrum for each issue, like pronouns is one. Pronouns being shared in meetings. How proactive, or reactive are you for that? I don't even know. There are thousands of things [chuckles] that you can do to become more proactive. MANDY: I would like to say for allies, teaching our children love and not hate. I see a lot of nastiness coming from children and that comes from parents. It's really sad to see sometimes the amount of people who don't – they just spew hate and they're like, “I'm not referring to this person as a pronoun.” Like, “They/them, no. They're a this, or they're –” It saddens me to no end when you are around children to model nasty behavior and I think if you are not the person doing that yourself and you're around it, and you see somebody say something and say, “That's not okay, don't. Do you understand how you sound? Do you understand what you're saying? Do you understand that you're having an effect on everyone around you by giving your nasty opinions and that kind of thing?” CASEY: Yeah. I've got a one word, one liner thing that I like to pull out and I'm proud every time I say it. “Rude,” and I can walk away. It can happen in the grocery store. Someone can say something. It doesn't matter the nuance, what's going on and how I might explain it to them in fuller language. I can at least pull that one word out, rude, and walk away and they are called out for it. I'm proud whenever I can call someone out. MANDY: Yeah. CASEY: I don't always do it, though. The stakes can seem high and it takes practice. So this is homework, too. If you see someone and saying something hurtful to another person, it's your responsibility if you dare claim this to defend the other person and call the person rude, or however you would say the same thing. Say something. MANDY: Yeah, say something. MANNAH: I think that that can be really hard for allies. CASEY: Yeah. MANNAH: And if I had one piece of advice for allies, it would be that sometimes allyship is uncomfortable and that is something that you have to navigate. You can't pick and choose when you're going to… Well, that's not true. There's some discretion, but recognize that being a part-time ally, or a tourist in that space has an effect on people and not confronting your own insecurities, or your own feelings limits your effectiveness in allyship. CASEY: Yeah. It can be a deep question to ask yourself what made me hesitate that one time and what can I do to not hesitate helping next time? You can journal about it. You can talk to friends about it. You can think about it. Doing something more than thinking is definitely more helpful, though. Thinking alone is not the most powerful tool you have to change your own behavior. Yeah, it is uncomfortable. One thing that helps me speak up is instead of focusing on my discomfort, which is natural and I do it, for sure, I try to focus on the discomfort of the other person, or the person directly affected by this and I really want to help that person feel seen, protected, heard, defended. If you think about how they're feeling even more, that's very motivating for me and honestly, it helps in some ways that I am a queer man, that I have been discriminated against and people have been hateful toward me that I can relate when other people get similar experiences. If you haven't had experiences like that, it might be hard to rally up the empathy for it. But I'm sure you have something like that in your background, or if not, you know people who've been affected and that can be fuel for you, too. People you care about telling you stories like this and it is uncomfortable. [chuckles] Getting comfortable with that discomfort is critical here. MANNAH: One of the things that is very uncomfortable is, I think that as we go through life, we all grow is being reflective on the times when maybe we're not inclusive, or maybe were insensitive. At least being able to those situations, I feel like is a great first step. CASEY: Mm hm. MANNAH: Saying, “Hey, I said this about this group of people,” or “I use this word.” Maybe you didn't fully know what it meant and recognized the impact at the time, but being able to go back and be reflective about your behavior, I feel like is a very important skill to help become a more well-rounded individual. CASEY: Yeah. Agreed. And it's a practice. You have to do it. The more you do it, the easier it gets to process these and learn from them. It's a habit also, so any of the books that talk about learning habits, you can apply to this kind of problem, too. Like a weekly calendar event, or talking to a friend once a month and this is a topic that comes up. I don't know, there are a ton of ways you can try to make this habit, grow and stick for yourself, and it varies by person what's effective. But if you don't put it into your schedule, if you don't make room and space for it, it's really easy to skip doing it, too. MANDY: Yeah. It's amazing to look back. Even myself, I'm not the same person. I was 10, 15 years ago. I'm sure. Even as being a bisexual person that back in high school, I called something gay at one point just referring to, “Oh, that's gay.” CASEY: Yeah. MANDY: I'm sure I – [overtalk] CASEY: I'm sure I did it, too. MANDY: I'm sure I've said that. Knowing that I'm not that person anymore, recognizing that, and looking back at how much I've grown really helps me to come to terms with the fact that I wasn't always woke on this subject. We do a lot of growing over our lives. I'm in my 30s now and I've done so much growing and to look back on the person who I used to be versus the person I am now, I get very proud of how far I've come. Even though it can suck to look back at maybe a specific instance that you always remember and you're like, “Oh my God, that's so cringy. I can't believe I did that.” Having those moments to be like, “Well, you know what, that might have happened in 2003, but this is 2022 and look how far you've come.” CASEY: Love it! Yeah, growth. MANDY: Like that just makes me feel so good. CASEY: Yeah. We need the growth mindset. MANDY: And having discussions like this is what has gotten me to this place. Entering tech. I entered tech 12 years ago. I know this because my daughter's 12 and I always like, I'm like, “Okay so when my daughter was born, I got into tech. That's when I started actually becoming a decent person.” [laughs] So I measure a lot of my timeline by my daughter's age and it's just amazing to go back and see how much you've grown. Honestly, you should – another piece of homework, if you can just sit back and think about who you were before and who you are now and reflect on that a bit. MANNAH: We talked about normalizing pronouns, but I think it's also important to normalize sharing that story that you just told. I know I had a similar story where wherever I am on the wokeness scale, I was definitely much less so a couple years ago. I just did not have the same – I did not have enough experiences. I did not think about things in the same way. I did not challenge myself to be empathetic as much as I do now. It is a process and we're all somewhere on that journey. Who you are, like you said, 10 years ago is not necessarily who you are now. If it is, I don't know. I hope I'm not the same person in 10 years. I hope I'm always growing. So to make sure to share with others that it is a process and you don't wake up one day being woke. It is something that takes work and a skill that is developed. MANDY: Oh, you definitely have to do the work. Every year, I do a program. It's an actually a wonderful program. It's called Stratejoy. I can put the link in the show notes. But every year there's this woman who you sit down, you take stock of the last year and she asks a lot of deep questions. You journal them, you write them down, and then you think about what do I want to see? What can I improve? What do I want to do? How can I do so? And then we have quarterly calls throughout the year and really sit down, write it down, talk about it, and reflect on it because it is work. A lot of people make fun of people who read self-help books and I love fiction books just as much as the next person, I want to get away and read before bed at the end of the night, too. But it's really important for me to read books that make me feel uncomfortable, or make me learn, or make me think. I read a lot of books on race. So You Want to Talk About Race was one I read and it had a profound effect on me to read that book and take stock of myself and my own actions. It can be hard sometimes and it can cause anxiety. But I think in order to grow as a person, that's where you need to be vulnerable and you need to say, “No, I'm not perfect. I've done this thing wrong in the past and I don't know this, so I'm going to do what I can to educate myself.” CASEY: Another thing I hear a lot is some people say, “You should not celebrate any progress you make. You should always just feel bad and work harder forever.” Do you ever hear that kind of sentiment? Not in those words. MANDY: Yeah. CASEY: But if you ever say, “I learned a thing and I'm proud of it, here's what I learned,” there's someone on the internet who's going to tell you, “You are terrible and wrong and should do even better. Forget any progress you've made. You're not perfect yet,” and that is so frustrating to me. So here's something I'd like to see from more woke allies is less language policing, more celebrating of people who make progress. A lot of it's invisible, like we talked about on the spectrum. I do like when people get called out for making mistakes, like there's an opportunity for learning and growth, but you don't have to shame people in public, make them feel really bad about it, and embarrassed in front of the whole company. You could maybe do it privately and send a message to the companies talking about the policy in general like, “Don't use this word, don't do this thing.” You can do it very tactfully and you can be very effective. You don't have to just be PC police to the extreme. But if you are PC police to the extreme, I'm glad you're doing something. That's good. But you can be more effective. Please think about how you can be really effective, that's my request for all my woke friends. It can go overboard. It can definitely go overboard, being a language police. MANDY: Yeah, and it can make people who are trying to quit. CASEY: Right. That's a huge risk. I want to give all this a caveat, though, because if – here's an example from a friend's company. There was a presentation and there ended up being a slide with Blackface on it, which if you don't know is a terrible, awful thing that makes Black people feel really bad and it makes the person showing it seem like they are malicious, or oblivious and it shouldn't happen. And then we were wondering like, “What should someone have done in that situation?” Call it out, for sure and move on publicly is a good call there to protect any Black people in the room feel like they're being protected and heard, but not necessarily shaming the person and giving them a 5-minute lecture during that. You can be effective at getting the person not to do it again in private later calling it out to defend the people in the room. Protecting is goal number one for me, but what can you do to change the company culture effectively is a piece that I see a lot of people skipping. If you are just 5 minutes yelling at a person that might make them shut down, you're not being your most effective. So it's a hard walk to balance protecting people, calling people out, and changing the culture. But it's possible and it's work. I guess, it's really two things you're balancing, protecting the person, making them feel part of the group included and cared for versus changing the culture of the group and of the individual. We want both outcomes, ideally. But if I had to pick one, I'm going to pick protecting the person first and then the larger change can happen afterwards. MANDY: Yeah. And if you do mess up, which I've done. I've accidentally misgendered somebody and I felt terrible. All night, I kept apologizing to this person and finally, this person took me aside and said, “You're making it worse by keeping apologizing. Let it go.” CASEY: Yeah. MANDY: So also, not rehashing and banging your head against the wall multiple, multiple times. Apologize and move on. MANNAH: Yeah. If your apology is sincere, then you shouldn't need to repeat it multiple times. Make sure that the person you're apologizing to hears it and make whatever amend need be made. But I do think if you over apologizing, it's more for you so you feel better than it is more for the person that you potentially offended. CASEY: Right and I don't expect you to know that without having thought about it like you are right now. Take this moment and think about it deeper. This is intriguing to you. It is natural to want to apologize forever, but it is also harmful and you can do better than that. I offer a lot of workshops in this vein. Like there's one called Bystander to Upstander. There's another LGBTQIA inclusion where I go through a whole bunch of charts and graphs. There's one called preventing and recovering from microaggressions where you can practice making a mistake and recovering from it in a group. The practice is the key here, like really making a mistake and recovering from it, getting that the muscles, the reactions, the things you say to people, it does take work to get that to be a practice. Even if you already agree you want to, it's hard to put it into practice a lot of the time. I give workshops, including these, for community groups a couple times a month and if you want to get updates on that, that's at happyandeffective.com/updates. Also, I do these for companies so if you think your company would benefit from having these kinds of discussions, feel free to reach out to Happy and Effective, too. That's my company. MANNAH: Well, with that, I think it'd be a great time to move to reflections. What do y'all think? I think this whole episode has been one big reflection to be quite honest, but does anybody want to share anything in particular that has stood out to them throughout the hour we've just spent together? MANNAH: I'm happy to kick it off. I think that we've made some really good suggestions around how people can create more through their own actions. Create more inclusive environments. I do want to say that these are not things that are kind of stone. There are a lot of ways. Everybody's an individual, every situation is different, and I don't want to be prescriptive in saying you have to do certain things. I do want to say that when I'm speaking, this is my experience and these are things that I think can help. So please don't take what I say to be gospel. They are suggestions and if you disagree with them, then I'm happy to have that conversation. But recognize that the people speaking on this panel don't necessarily have the answers, but they are people who are willing to start this conversation. CASEY: The thing I want people to take away is—and you can repeat after me, everyone—I will make mistakes. Good, good. I heard it. I will find more support. Awesome. You're great. Okay. You're on the right path for this now. Mandy, over to you. MANDY: This is not something that you do once and you're done. This kind of reflection and this kind of work is always going to be a work in progress until the day you're no longer here. It's not something you can read a book and be like, “Okay, I did that. I'm good now. I know things.” It's constantly changing and evolving and you need to do the work. You need to have empathy for others and realize that everybody is constantly changing and just because somebody isn't one ting one day, they might be something the other day. I tell my daughter all the time because she's very unsure about who is she and I'm like, “You don't have to know right now. Just because you think you're this, or you're this right now, in 2 years, you might feel differently and you might be this.” So people are always evolving, always changing, and that doesn't just go for how you present either your gender identity, or sexual identity but it also just goes for who you are. I always try to grow as a person and the work is never done. CASEY: No one has all the answers, no one knows everything, and anyone who says they do is lying because it's going to change. It will change. MANDY: Awesome. Well, thank you so much, Mannah and Casey for having this conversation today. I know it's uncomfortable, I know it's a hard thing to talk about, and I'm so grateful that you both showed up to have it. If we want to continue these conversations, I invite anybody who's listening to reach out to us. If you'd like to come on the show to talk about it, reach out to us. We have a Slack channel that we can have private conversations in. You can find that at Patreon.com/greaterthancode and donate as little as a dollar to get in. We do that so we keep the trolls out and if you cannot afford a dollar, please DM any one of us and we will get you in there for free. So with that, thank you again for listening and we will see you all next week.

00:36 - Panelist Consulting Experience and Backgrounds * Debugging Your Brain by Casey Watts (https://www.debuggingyourbrain.com/) * Happy and Effective (https://www.happyandeffective.com/) 10:00 - Marketing, Charging, and Setting Prices * Patreon (https://www.patreon.com/) * Chelsea's Blog (https://chelseatroy.com/) * Self-Worth by Salary 28:34 - GeePawHill Twitter Thread (https://twitter.com/GeePawHill/status/1478950180904972293) - Impact Consulting * Casey's Spreadsheet - “Matrix-Based Prioritization For Choosing a Job” (https://docs.google.com/spreadsheets/d/1qVrWOKPe3ElXJhOBS8egGIyGqpm6Fk9kjrFWvB92Fpk/edit#gid=1724142346) * Interdependence (https://www.merriam-webster.com/dictionary/interdependence) 38:43 - Management & Mentorship * Detangling the Manager: Supervisor, Team Lead, Mentor (https://dev.to/endangeredmassa/detangling-the-manager-supervisor-team-lead-mentor-gha) * Adrienne Maree Brown (https://adriennemareebrown.net/) 52:15 - Explaining Value and Offerings * The Pumpkin Plan: A Simple Strategy to Grow a Remarkable Business in Any Field by Mike Michalowicz (https://www.amazon.com/Pumpkin-Plan-Strategy-Remarkable-Business/dp/1591844886) * User Research * SPIN Selling: Situation Problem Implication Need-payoff by Neil Rackham (https://www.goodreads.com/book/show/833015.SPIN_Selling) 55:08 - Ideal Clients Reflections: Mae: The phrase “indie”. Casey: Having a Patreon to help inspire yourself. Chelsea: Tallying up all of the different things that a given position contributes to in terms of a person's needs. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: CHELSEA: Welcome to Greater Than Code, Episode 267. I'm Chelsea Troy, and I'm here with my co-host, Mae. MAE: And also with us is Casey. CASEY: Hi, I'm Casey. And today's episode, we are our own guests. We're going to be talking to you about our experiences in consulting. To get this one started, how about we share what got us into consulting and what we like, don't like about it, just high-level? Chelsea, would you mind going first? CHELSEA: Sure. So I started in consulting, really in a full-time job. So for early in my programming career, I worked for several years for a company called Pivotal Labs and Pivotal Labs is chiefly, or was chiefly at the time, a software engineering consulting organization. My job was to pair program with folks from client teams, various types of clients, a lot of health insurance companies. At the time, there was a restaurant loyalty app that we did some work for. We did some work for General Motors, various clients, a major airline was also a client, and I would switch projects every three to six months. During that time employed by Labs, I would work for this client, pair programming with other pivots, and also with client developers. So that was my introduction to consulting and I think that it made the transition to consulting later, a little bit easier because I already had some consulting experience from under the Labs' umbrella. After I worked for Labs, I moved on to working at a product company for about 2 years and my experience at that product company burned me out on full-time programming for a little while. So in my last couple of months at that job, I realized that I was either going to have to take some time off, or I was going to have to find an arrangement that worked better for me for work, at least for the next little while. And for that next little while, what I decided I wanted to try to do was work part-time because I was uncomfortable with the idea of taking time off from programming completely. I felt that I was too early in my career and the skill loss would be too great if I took time off completely, but I knew I needed some space and so, I quit my full-time job. After I quit the full time—I probably should have done this before I quit the job, but I didn't—I called an organization that I had previously done some volunteer work with, with whom I discussed a job a couple of years prior, but for a couple of different reasons, it didn't work out. I said to them, “I know that you're a grant-funded organization and you rarely have the funding and capacity to bring somebody on, but just so you're aware, I like working with you. I love your product. I love the stuff that you work on. All our time working together, I've really enjoyed. So if you have an opening, I'm going to have some time available.” The director there emailed me that same day and said, “Our mobile developer put in his two weeks' notice this morning. So if you have time this afternoon, I'd really like to talk to you,” [chuckles] and that was my first client and they were a part-time client. I still work with them. I love working with them. I would consider them kind of my flagship client. But then from there, I started to kind of pick up more clients and it took off from there after that summer. I spent that summer generally working 3 days a week for that client and then spending 4 days a week lying face down in a park in the sun. That helped me recover a little bit from burnout. And then after that, I consulted full-time for about 2 years and I still consult on the side of a full-time job. So that's my story. Is anyone feeling a penchant for going next? MAE: I can go. I've been trying to think how am I going to say this succinctly. I've had at least two jobs and several club, or organization memberships, or founding, or positions since I was 16. So wherever I go, I've always been saying, “Well, I've done it these 47 ways already [laughs] even since I was a teenager.” So I've sort of always had a consulting orientation to take a broader view and figure out ways in which we can systematize whatever it is that's happening around me. Specifically for programming, I had been an administrator, like an executive leader, for many years. I just got tired of trying to explain what we as administrators needed and I just wanted to be able to build the things. I was already a really big Microsoft access person and anybody who just got a little [laughs] snarky in there knows I love Microsoft Access. It really allowed me to be able to offer all kinds of things to, for example, I was on the board of directors of my Kiwanis Club and I made a member directory and attendance tracker and all these things. Anyway, when I quit my executive job and went to code school in 2014, I did it because I knew that I could build something a lot better than this crazy Access database [laughs] that I had, this very involved ETL things going on in. I had a nonprofit that I had been involved with for 15 years at that point and I had also taken a database class where I modeled this large database that I was envisioning. So I had a bunch of things in order. I quit my full-time job and went to an income of $6,500 my first year and I hung with that flagship customer for a while and tailored my software. So I sort of have this straddling of a SaaS situation and a consulting situation. I embed into whoever I'm working with and help them in many ways. Often, people need lots of different levels of coaching, training, and skills development mixed with just a place to put things that makes sense to them. I think that's the brief version [laughs] that I can come up with and that is how I got where I am and I've gone in and out of also having a full-time job. Before I quit that I referenced the first year I worked a full-time job plus at least 40 to a 100 hours on my software to get it ready for prime time. So a lot of, a lot of work. CASEY: Good story. I don't think I ever heard these fuller stories from either of you, even though I know roughly the shape of your past. It's so cool to hear it. Thanks for sharing them. All right, I'll share about me now. So I've been a developer, a PM, and I've done a lot of design work. I've done all the roles over my time in tech. I started doing programming 10, 15 years ago, and I'm always getting burnt out everywhere I go because I care so much and we get asked to do things that seem dumb. I'm sure anyone listening can relate to this in some organization and when I say dumb, I don't use that word myself directly. I'm quoting a lot of people who would use that word, but I say either we're being asked to do things that don't make sense, aren't good ideas, or there are things that are we're being asked to do that would make sense if we knew why and it's not being communicated really well. It's poor communication. Either one, the other, or both. So after a lot of jobs, I end up taking a 3-month sabbatical and I'm like, “Whatever, I got to go. I can't deal with caring so much anymore, and I'm not willing to care less either.” So most recently, I took a sabbatical and I finished my book, Debugging Your Brain, which takes together psychology ideas, like cognitive behavioral therapy and programming ideas and that, I'm so proud of. If you haven't read it yet, please check it out. Then I went back to my job and I gave them another month where I was like, “All right, look, these are things need to change for me to be happy to work here.” Nothing changed, then I left. Maybe it's changing very slowly, but too slowly for me to be happy there, or most of these past companies. [laughs] After I left, this last sabbatical, I spent three to six months working on a board game version of my book. That's a lot of fun. And then I decided I needed more income, I needed to pay the bills, and I can totally be a tech consultant if I just deal with learning marketing and sales. That's been my… probably six months now, I've been working on the marketing in sales part, thinking a lot about it. I have a lot of support from a lot of friends. Now I consult on ways to make teams happier and more effective and that's my company name, Happy and Effective. I found it really easy to sell workshops, like diversity, equity, and inclusion workshops to HR departments. They're pretty hungry for those kinds of workshops and it's hard to find good, effective facilitators. It's a little bit harder to get companies to pay for coaching for their employees, even though a new EM would love coaching and how to be a good leader. Companies don't always have the budget for that set aside and I wish they would. I'm working with a lot of companies. I have a couple, but not as many as I'd like. And then the hardest, my favorite kind of client is when I get to embed with the team and really work on seeing what's going on me on the ground with them, and help understand what's going on to tell the executives what's happening and what needs to change and really make a big change. I've done that once, or twice and I'd love to do that more, but it's the hardest. So I'm thinking about easy, medium, hard difficulty of selling things to clients. I would actually make plenty of money is doing workshops, honestly, but I want the impact of embedding. That's my bigger goal is the impact. MAE: Yeah. I basically have used my software as a Trojan horse for [laughs] offering the consulting and change management services to help them get there because that is something that people already expect to spend some money on. That, though has been a little problematic because a few years in, they start to think that the line item in the budget is only for software and then it looks very expensive to them. Whereas, if they were looking at it as a consultant gig, it's incredibly inexpensive to them. CASEY: Yeah. It's maybe so inexpensive that it must not be a quality product that they're buying. MAE: Yes. CASEY: Put it that way implicitly. MAE: Definitely, there's also that. CASEY: When setting prices, this is a good general rule of thumb. It could be too low it looks like it'll be junk, like a dollar store purchase, or it can be too high and they just can't afford it, and then there's the middle sweet spot where it seems very valuable. They barely can afford it, but they know it'll be worth it, and that's a really good range to be in. MAE: Yeah. Honestly, for the work that I do, it's more of a passion project. I would do it totally for free, but that doesn't work for this reason you're talking about. CASEY: Yeah. MAE: Like, it needs to hurt a little bit because it's definitely going to be lots and lots of my time and it's going to be some of their time and it needs to be an investment that not hurt bad [laughs] but just be noticeable as opposed to here's a Kenny's Candy, or something. CASEY: I found that works on another scale, on another level. I do career coaching for friends, and friends of friends, and I'm willing to career coach my friends anyway. I've always been. For 10 years, I've reviewed hundreds, thousands of resumes. I've done so many interviews. I'm down to be a career coach, but no one was taking me up on it until I started charging and now friends are coming to me to pay me money to coach them. I think on their side, it feels more equitable. They're more willing to do it now that I'm willing to take money in exchange for it. I felt really bad charging friends until I had the sliding skill. So people who make less, I charge less for, for this personal service. It's kind of weird having a personal service like that, but it works out really well. I'm so happy for so many friends that have gotten jobs they're happy with now from the support. So even charging friends, like charging them nothing means they're not going to sign up for it. MAE: Yes, and often, there is a bias of like, “Oh, well, that's my friend.” [laughs] so they must not be a BFD.” CASEY: Yeah. But we are all BFDs. MAE: Exactly! How about you Chelsea? How did you start to get to the do the pricing thing? CHELSEA: Yeah, I think it's interesting to hear y'all's approaches to the marketing and the pricing because mine has been pretty different from that. But before I get off on that, one thing I do want to mention around getting started with offering personal services at price is that if it seems too large a step to offer a personal service to one person for an amount of money, one thing that I have witnessed folks have success with in starting out in this vein is to set up a Patreon and then have office hours for patrons wherein they spend 2 hours on a Sunday afternoon, or something like that and anyone who is a patron is welcome to join. What often ends up happening for folks in that situation is that people who are friends of theirs support their Patreon and then the friends can show up. So effectively, folks are paying a monthly fee for access to this office hours, which they might attend, or they might not attend. But there are two nice things about it. The first thing about it is that you're not – from a psychological perspective, it doesn't feel like charging your friends for your time with them. It feels more indirect than that in a way that can be helpful for folks who are very new to charging for things and uncomfortable with the idea. The second thing is that the friends are often much more willing to pay than somebody who's new to charging is willing to charge. So the friends are putting this money into this Patreon, usually not because they're trying to get access to your office hours, but because they want to support you and one of the nice things about Patreon is that it is a monthly amount. So having a monthly email from Patreon that's like, “Hey, you we're sending you—” it doesn't even have to be a lot. “We're sending you 40 bucks this month.” It is a helpful conditioning exercise for folks who are not used to charging because they are getting this regular monthly income and the amount is not as important as receiving the regular income, which is helpful psychological preparation for charging for things on your own, I think. That's not the way that I did it, but I have seen people be effective that way. So there's that. For me, marketing was something that I was very worried about having to do when I started my business. In fact, it was one of those things where my conviction, when I started my consulting business, was I do not want to have to sell my services. I will coast on what clients I can find and when it is no longer easy, I will just get a full-time job because selling traditionally conceptualized is not something that I enjoyed. I had a head start on the marketing element of things, that is sort of the brand awareness element of things, my reputation and the reason for that is that first of all, I had consulted at Labs for several years, which meant that every client team that I had ever worked with there, the director remembered me, the product owner remember me. So a lot of people who had been clients of Labs – I didn't actually get anybody to be a client of mine who was a client of Labs, but the individuals I had worked with on those projects who had then changed jobs to go to different companies, reached out to me on some occasions. So that was one place that I got clients from. The other place that I gotten clients from has been my blog. Before I started my business, I had already been writing a tech blog for like 4, or 5 years and my goal with the tech blog has never actually been to get clientele, or make money. My goals for the blog when I started it were to write down what I was learning so that I would remember it and then after that, it was to figure out how to communicate my ideas so that I would have an easier time communicating them in the workplace. After that, it became an external validation source so that I would no longer depend on my individual manager's opinion of me to decide how good I was at programming. Only very recently has it changed to something like, okay, now I'm good enough at communicating and good enough at tech that I actually have something to teach anybody else. So honestly, for many years, I would see the viewership on my blog and I would be like, “Who are all these people? Why are they in my house?” Like, this is weird, but I would get some credibility from that. CASEY: They don't expect any tea from me. CHELSEA: Yeah. I really hope. I don't have enough to go around, [laughs] but it did help and that's where a lot of folks have kind of come from. Such that when I posted on my blog a post about how I'm going to be going indie. I've quit my job. I didn't really expect that to go anywhere, but a few people did reach out from that and I've been lucky insofar is that that has helped me sustain a client load in a way that I didn't really expect to. There's also, I would be remiss not to mention that what I do is I sling code for money for the majority of my consulting business, at least historically and especially in the beginning was exclusively that, and there's enough of a demand to have somebody come in and write code that that helped. It also helped that as I was taking on clients, I started to niche down specifically what I wanted to work on to a specific type of client and to a specific type problem. So I quickly got to the point where I had enough of a client load that I was going to have to make a choice about which clients to accept, or I was going to have to work over time. Now, the conventional wisdom in this circumstance is to raise your rates. Vast majority of business development resources will tell you that that's what you're supposed to do in this situation. But part of my goal in creating my consulting business had been to get out of burnout and part of the reason for the burnout was that I did not feel that the work that I was doing was contributing to a cause that made me feel good about what I was doing. It wasn't morally reprehensible, but I just didn't feel like I was contributing to a better future in the way that my self-identity sort of mandated that I did. It was making me irritable and all these kinds of things. MAE: I had the same thing, yeah. CHELSEA: Yeah. So it's interesting to hear that that's a common experience, but if I were to raise my rates, the companies that were still going to be able to afford me were going to be companies whose products were not morally reprehensible, but not things that coincided with what I was trying to get out of my consulting business. So what I did instead was I said, “I'm specifically looking to work with organizations that are contributing to basic scientific research, improving access for underserved communities, and combating the effects of climate change,” and kept my rates effectively the same, but niche down the clientele to that. That ended up being kind of how I did it. I find that rates vary from client to client in part, because of what you were talking about, Casey, wherein you have to hit the right price in order to even get clients board in certain circumstances. CASEY: Right. CHELSEA: I don't know a good way to guess it. My technique for this, which I don't know if this is kosher to say, but my technique for this has been whoever reached out to me, interested in bringing me on as a consultant for that organization, I ask that person to do some research and figure out what rate I'm supposed to pitch. That has helped a lot because a lot of times my expectations have been wildly off in those circumstances. One time I had somebody say to me, this was for a custom workshop they wanted. I was like, “What should I charge?” And they were like, “I don't know, a few thousand.” I was like, “Is that $1,200? Is that $9,000? I don't know how much money that is,” and so they went back and then they came back and they were able to tell me more specifically a band. There was absolutely no way I would've hit that number accurately without that information. CASEY: Yeah, and different clients have different numbers. You setting your price standard flat across all customers is not a good strategy either. That's why prices aren't on websites so often. CHELSEA: Yeah. I find that it does depend a lot. There's similarly, like I said, a lot of my clients are clients who are contributing to basic scientific research are very often grant funded and grants funding is a very particular kind of funding. It can be intermittent. There has to be a skillset on the team for getting the grant funding. A lot of times, to be frank, it doesn't support the kinds of rates that somebody could charge hourly in a for-profit institution. So for me, it was worth it to make the choice that this is who I want to work with. I know that my rate is effectively capped at this, if I'm going to do that and that was fine by me. Although, I'm lying to say it was completely fine by me. I had to take a long, hard look in the mirror, while I was still in that last full-time job, and realize that I had become a person who gauged her self-worth by the salary that she commanded more than I was comfortable with. More than I wanted to. I had to figure out how to weaken that dependency before I was really able to go off and do my own thing. That was my experience with it. I'm curious whether y'all, well, in particular, Casey, did you find the same thing? CASEY: The self-worth by salary? CHELSEA: Yeah. CASEY: I felt that over time, yeah. Like I went from private sector big tech to government and I got a pay cut and I was like, “Ugh.” It kind of hurt a little and it wasn't even as much as I was promised. Once I got through the hiring process, it was lower than that and now I'm making way less. When I do my favorite impact thing, the board game, like if I made a board game about mental health for middle schoolers, which is something I really want to do, that makes less than anything else I could with my time. I'll be lucky to make money on that at all. So it's actually inverse. My salary is inversely proportional to how much impact I can have if I'm working anyway. So my dream is to have enough corporate clients that I can do half-time, or game impact, whatever other impact things I'm thinking about doing. I think of my impact a lot. Impact is my biggest goal, but the thing is salary hurts. If I don't have the salary and I want to live where I'm living and the lifestyle I have, I don't want to cut back on that and I don't need to, hopefully. CHELSEA: Right. CASEY: I'm hoping eventually, I'll have a steady stream of clients, I don't need to do the marketing and sales outreach as much and all those hours I kind of recoup. I can invest those in the impact things. I've heard people can do that. I think I'll get there. CHELSEA: No, I think you absolutely will. Mae, I'm curious as to your experience, because I know that you have a lot of experience with a similar calculation of determining which things are going to provide more income, which things are probably going to provide less income, and then balancing across a bunch of factors like money, but also impact, time spent, emotional drain, and all that stuff. MAE: Well, Chelsea. [laughter] I am a real merry go round in this arena. So before I became a programmer, I had a state job, I was well paid, and I was pretty set. Then I was a programmer and I took huge pay cut because I quit. I became a programmer when I was 37 years old. So I already had a whole career and to start at the beginning and be parallel with 20-year-old so it's not just like my salary, but also my level and my level of impact on my – and level of the amount of people who wanted to ask me for my advice [laughs] was significantly different. So like the ego's joking stopped and so when you mentioned the thing about identity. Doing any kind of consulting in your own deal is a major identity reorganization and having the money, the title, the clout, and the engagement. Like a couple years, I have spent largely alone and that is very different than working at a place where I have colleagues, or when I live somewhere and have roommates. But I have found signing up for lots and lots of different social justice and passion project things, and supporting nonprofits that I believe in. So from my perspective, I'm really offering a capacity building grant out of my own pocket, my own time, and my own heart and that has been deeply rewarding and maybe not feel much about my identity around salary. Except it does make me question myself as an adult. Like these aren't the best financial decisions to be making, [chuckles] but I get enough out of having made them that it's worth it to me. One of the things probably you were thinking of, Chelsea, we worked together a little bit on this mutual aid project that I took on when the pandemic started and I didn't get paid any dollars for that and I was working 18 hours a day on it, [chuckles] or something. So I like to really jump in a wholeheartedly and then once I really, really do need some dollars, then I figure something else out. That is kind of how I've ebbed and flowed with it. But mostly, I've done it by reducing my personal overhead so that I'm not wigged about the money and lowering whatever my quality-of-life spending goals [chuckles] are. But that also has had to happen because I have not wanted to and I couldn't get myself to get excited about marketing of myself and my whole deal. Like I legit still don't have a website and I've been in operation now since 2014 so that's a while. I meet people and I can demonstrate what it is and I get clients and for me, having only a few clients, there's dozens of people that work for each one. So it's more of an organization client than a bunch of individuals and I can't actually handle a ton. I was in a YCombinator thing that wanted me to really be reporting on income, growth rates, and all of these number of new acquisition things, and it just wasn't for me. Those are not my goals. I want to make sure that this nonprofit can help more people this year and that they can get more grant money because they know how many people they helped and that those people are more efficient at their job every day. So those are harder to measure. It's not quite an answer to your question, [laughs] but I took it and ran a little. CHELSEA: No, I appreciate that. There is a software engineer and a teacher that I follow on Twitter. His name is GeePawHill. Are y'all familiar with GeePawHill? MAE: No. CHELSEA: And he did a thread a couple of days ago that this conversation reminds me of and I found it. Is that all right if I read like a piece of it and paraphrase part of it? MAE: Yes, please. CHELSEA: Okay. So this is what he says. He says, “The weirdest thing about being a teacher for young geek minds: I am teaching them things…that their actual first jobs will most likely forbid them to do. The young'uns I work with are actually nearly all hire-able as is, after 18 months of instruction, without any intervention from me. The problem they're going to face when they get to The Show isn't technical, or intellectual at all. No language, or framework, or OS, or library, or algorithm is going to daunt them, not for long. No, the problem they're going to face is how to sustain their connection to the well of geek joy, in a trade that is systematically bent on simultaneously exploiting that connection while denying it exists and refusing any and all access to it. It is possible, to stick it out, to acquire enough space and power, to re-assert one's path to the well. Many have done it; many are doing it today. But it is very hard. Very hard. Far harder than learning the Visitor pattern, or docker, or, dart, or SQL, or even Haskell. How do you tell people you've watched “become” as they bathed in the cool clear water that, for some long time, 5 years or more, they must…navigate the horrors of extractive capitalist software development? The best answer I have, so far, is to try and teach them how and where to find water outside of work. It is a lousy answer. I feel horrible giving it. But I'd feel even more horrible if I didn't tell them the truth.” CASEY: I just saw this thread and I really liked it, too. I'm glad you found it. MAE: Oh, yeah. I find it honestly pretty inspiring, like people generally who get involved in the kinds of consulting gigs that we three are talking about, which is a little different than just any random consulting, or any random freelancing. CASEY: Like impact consulting, I might call that. MAE: Yeah. It's awesome if the money comes, but it's almost irrelevant [chuckles] provided that basic needs are meant. So that's kind of been my angle. We'll see how – talk to me in 20 more years when I'm [chuckles] trying to retire and made a lot of choices that I was happy with at the time. CASEY: This reminds me of a conversation I had with a friend who's an executive director of an orchestra in the nonprofit space and he was telling me that so many nonprofits shoot themselves in the foot by not doing enough fundraising, by not raising money, and that comes from not wanting to make money in a way because they're a nonprofit, money is not a motive, and everybody's very clear about that. That's noble and all, but it ends up hurting them because they don't have the money to do the impactful things they would as a nonprofit. Money is a necessary evil here and a lot of people are uncomfortable with it. Including me a lot of the time. Honestly, I have to tell myself not to. What would I tell a friend? “No, charge more money.” Okay, I guess I'll tell myself to do that now. I have this conversation with myself a lot. MAE: Yeah. I've been very aware that when I become anti-money, the well dries up. The money well. [laughs] CASEY: Yeah. MAE: And when I am respectful of and appreciative of money in the world, more comes my way. There is an internal dousing, I think that happens that one needs to be very careful about for sure. CASEY: One of the techniques I use with myself and with clients is a matrix where I write out for this approach, this thing that I'm thinking about how much money will it make, how much impact will it have on this goal, and all the different heuristics I would use to make the decision, or columns and all the options arose. I put numbers in it and I might weight my columns because money is less important than impact, but it's still important. It's there. I do all this math. In the end, the summary column with the averages roughly matches what's in my head, which is the things that are similar in my head are similar on paper, but I can see why and that's very clarifying for me. I really like being able to see it in this matrix form and being able to see that you have to focus on the money some amount. If you just did the high impact one, it wouldn't be on the top of the list. It's like, it's hard to think about so many variables at once, but seeing it helps me. CHELSEA: It is. GeePaw speaks to that some later in the thread. He says, “You've got to feed your family. You've got to. That's not negotiable. But you don't got to forget the well. To be any good at all, you have to keep finding the well, keep reaching it, keep noticing it. Doesn't matter whether it's office hours, or after hours. Matters whether you get to it. The thing you've got to watch, when you become a professional geek, isn't the newest tech, and it sure as hell isn't the org's process. You've got to watch whether, or how you're getting to the well. If you're getting to the well, in whatever way, you'll stay alive and change the world.” I think I'm curious as to y'all's thoughts on this, but like I mentioned earlier, I have a full-time job and I also do this consulting on the side. I also teach. I teach at the Master's program in computer science at University of Chicago. I do some mentoring with an organization called Emergent Works, which trains formerly incarcerated technologists. The work situation that I have pieced together for myself, I think manages to get me the income I need and also, the impact that I'm looking for and the ability to work with people and those kinds of things. I think my perspective at this point is that it's probably difficult, if it's realistic at all, to expect any one position to be able to meet all of those needs simultaneously. Maybe they exist, but I suspect that they're relatively few and far between and I think that we probably do ourselves a disservice by propagating this idea that what you need to do is just make yourself so supremely interview-able that everybody wants to hire you and then you get to pick the one position where you get to do that because there's only one in the entirety of tech, it's that rare. Sure, maybe that's an individualist way to look at it. But when we step back and look more closely, or when we step back and look more broadly at that, it's like, all right, so we have to become hypercompetitive in order to be able to get the position where we can make enough while helping people. Like, the means there seem kind of cutthroat for the ends, right? [laughs] CASEY: This reminds me of relationships, too and I think there's a lot of great parallels here. Like you shouldn't expect your partner to meet all of your needs, all of them. MAE: I was thinking the same thing! CASEY: Uh huh. Social, emotional, spiritual, physical, all your needs cannot possibly by one person and that is so much pressure to put on that person, CHELSEA: Right. CASEY: It's like not healthy. CHELSEA: Right. CASEY: You can choose some to prioritize over others for your partner, but you're not going to get a 100% of it and you shouldn't. CHELSEA: Well, and I find that being a conversation fairly regularly in monogamous versus polyamorous circles as well. Like, how much is it appropriate to expect of a partner? But I think it is a valid conversation to have in those circles. But I think that even in the context of a monogamous relationship, a person has other relationships—familial relationships, friend relationships—outside of that single romantic relationship. CASEY: Co-workers, community people, yeah. CHELSEA: Right. But even within that monogamous context, it's most realistic and I would argue, the most healthy to not expect any one person to provide for all of your needs and rather to rely on a community. That's what we're supposed to be able to do. CASEY: Yeah. MAE: Interdependence, not independence. CHELSEA: Right. CASEY: It's more resilient in the face of catastrophe, or change in general, mild, more mild change and you want to be that kind of resilient person for yourself, too. Just like you would do a computer system, or an organization. They should be resilient, too. MAE: Yes. CASEY: Your relationship with your job is another one. MAE: Totally. CHELSEA: Right. And I think that part of the reason the burnout is so quick – like the amount of time, the median amount of time that somebody spends at a company in tech is 2.2 years. MAE: I know, it's so weird. CHELSEA: Very few companies in tech have a large number of lifers, for example, or something like that. There are a number of reasons for that. We don't necessarily have to get into all of them, although, we can if you want. But I think one of them is definitely that we expect to get so much out of a full-time position. Tech is prone. due to circumstances of its origin, to an amount of idealism. We are saving the world. We, as technologists, are saving the world and also, we, as technologists, can expect this salary and we, as technologists, are a family and we play ping pong, and all of these things – [laughter] That contribute to an unrealistic expectation of a work environment, which if that is the only place that we are getting fulfillment as programmers, then people become unsatisfied very quickly because how could an organization that's simultaneously trying to accomplish a goal, meet all of these expect for everybody? I think it's rare at best. CASEY: I want to bring up another example of this kind of thing. Imagine you're an engineer and you have an engineering manager. What's their main job? Is it to get the organization's priorities to be done by the team, like top-down kind of thing? We do need that to happen. Or is it to mentor each individual and coach them and help them grow as an engineer? We need that somewhere, too, yeah. Or is it to make the team – like the team to come together as a team and be very effective together and to represent their needs to the org? That, too, but we don't need one person to do all three of those necessarily. If the person's not technical, you can get someone else in the company to do technical mentorship, like an architect, or just a more senior person on, or off the team somewhere else. But we put a lot of pressure on the engineering managers to do that and this applies to so many roles. That's just one I know that I can define pretty well. There's an article that explains that pretty well. We'll put in the show notes. MAE: Yes! So what I am currently doing is I have a not 40 hours a week job as an engineering manager and especially when I took the gig, I was still doing all of these pandemic charity things and I'm like, “These are more important to me right now and I only have so many hours in the day. So do you need me to code at this place? I can, but do you need me to because all those hours are hours I can go code for all these other things that I'm doing,” and [laughs] it worked. I have been able to do all three of the things that you're talking about, Casey, but certainly able to defer in different places and it's made me – this whole thing of not working full-time makes you optimize in very different ways. So I sprinkle my Slack check-ins all day, but I didn't have to work all day to be present all day. There's a lot that has been awesome. It's not for everyone, but I also have leaned heavily on technical mentorship happening from tech leads as well. CASEY: Sounds good. MAE: But I'm still involved. But this thing about management, especially in tech being whichever programmer seems like the most dominant programmer is probably going to be a good needs to be promoted into management. Just P.S. management is its own discipline, has its own trajectory and when I talk to hiring managers and they only care about my management experience in tech, which is 6 years, right? 8, but I have 25 years of experience in managing. So there's a preciousness of what it is that we are asking for the employees and what the employees are asking of the employer, like you were talking about Chelsea, that is very interesting. It's very privileged, and does lead a lot of people to burnout and disappointment because their ideas got so lofty. I just want to tie this back a little bit too, something you read in that quote about – I forget the last quote, but it was something about having enough to be able to change the world and it reminded me of Adrienne Maree Brown, pleasure activism, emergent strategy, and all of her work, and largely, generations of Black women have been saying, “Yo, you've got to take care [chuckles] of yourself to be able to affect change.” Those people have been the most effective and powerful change makers. So definitely, if you're curious about this topic, I urge you to go listen to some brilliant Black women about it. CASEY: We'll link that in the show notes, too. I think a lot about engineering managers and one way that doesn't come up a lot is you can get training for engineering managers to be stronger managers and for some reason, that is not usually an option people reach for. It could happen through HR, or it could happen if you have a training budget and you're a new EM, you could use your training budget to hire coaching from someone. I'm an example. But there's a ton of people out there that offer this kind of thing. If you don't learn the leadership skills when you switch roles, if you don't take time to learn those skills that are totally learnable, you're not going to have them and it's hard to apply them. There's a lot of pressure to magically know them now that you've switched hats. MAE: And how I don't understand why everyone in life doesn't have a therapist, [laughs] I don't understand why everyone in life doesn't have multiple job coaches at any time. Like why are we not sourcing more ideas and problem-solving strategies, and thinking we need to be the repository of how to handle X, Y, Z situation? CASEY: For some reason, a lot of people I've talked to think their manager is supposed to do that for them. Their manager is supposed to be their everything; their boss. They think the boss that if they're bad, you quit your job. If they're good, you'll stay. That boss ends up being their career coach for people, unless they're a bad career coach and then you're just stuck. Because we expect it so strongly and that is an assumption I want everyone listening to question. Do you need your manager at work to be that person for you? If they are, that's great. You're very fortunate. If not, how can you find someone? Someone in the community, a friend, family member, a professional coach, there's other options, other mentors in the company. You don't have to depend on that manager who doesn't have time for you to give you that kind of support. CHELSEA: So to that end, my thinking around management and mentorship changed about the time I hit – hmm. It was a while ago now, I don't know, maybe 6 years as a programmer, or something like that. Because before that, I was very bought into this idea that your manager is your mentor and all these types of things. There was something that I realized. There were two things that I realized. The first one was that, for me, most of my managers were not well set up to be mentors to me and this is why. Well, the truth is I level up quickly and for many people who are managers in a tech organization, they were technologists for 3 to 5 years before they became managers. They were often early enough in their career that they didn't necessarily know what management entailed, or whether they should say no based on what they were interested in. Many managers in tech figure out what the job is and then try to find as many surreptitious ways as possible to get back into the code. MAE: Yeah. CHELSEA: Additionally, many of those managers feel somewhat insecure about their weakening connection to the code base of the company that they manage. MAE: Yeah. CHELSEA: And so it can be an emotionally fraught experience for them to be mentor to someone whose knowledge of the code base that they are no longer in makes them feel insecure. So I learned that the most effective mentors for me – well, I learned something about the most effective mentors for me and I learned something of the most effective managers for me. I learned that the most effective managers for me either got way out ahead of me experience wise before they became managers, I mean 10 years, 15 years, 20 years, because those are not people who got promoted to management because they didn't know to say no. Those are people who got promoted to management after they got tired of writing code and they no longer staked their self-image on whether they're better coders than the people that they manage. That's very, very important. The other type of person who was a good manager for me was somebody who had never been a software engineer and there are two reasons for that. First of all, they trended higher on raw management experience. Second of all, they were not comparing their technical skillset to my technical skillset in a competitive capacity and that made them better managers for me, honestly. It made things much, much easier. And then in terms of mentors, I found that I had a lot more luck going outside of the organization I was working for mentors and that's again, for two reasons. The first one is that a lot of people, as they gain experience, go indie. Just a lot of people, like all kinds. Some of my sort of most trusted mentors. Avdi Grimm is somebody I've learned a lot from, indie effectively at this point. GeePawHill, like I mentioned, indie effectively at this point. Kenneth Mayer, indie effectively at this point. And these are all people who had decades of experience and the particular style of programming that I was doing very early in my career for many years. So that's the first reason. And then the second reason is that at your job, it is in your interest to succeed at everything you try—at most jobs. And jobs will tell you it's okay to fail. Jobs will tell you it's okay to like whatever, not be good at things and to be learning. But because if I'm drawing a paycheck from an organization, I do not feel comfortable not being good at the thing that I am drawing the paycheck for. MAE: Same. CHELSEA: And honestly, even if they say that that's the case, when the push comes to shove and there's a deadline, they don't actually want you to be bad at things. Come on! That doesn't make any sense. But I've been able to find ambitious projects that I can contribute to not for pay and in those situations, I'm much more comfortable failing because I can be like, “You know what, if they don't like my work, they can have all their money back.” And I work on a couple projects like that right now where I get to work with very experienced programmers on projects that are interesting and challenging, and a lot of times, I just absolutely eat dirt. My first PR doesn't work and I don't know what's wrong and the whole description is like somebody please help and I don't feel comfortable doing that on – if I had to do it at work, I would do it, but I'm not comfortable doing it. I firmly believe that for people to accelerate their learning to their full capacity for accelerating their learning, they must place themselves in situations where they not only might fail, but it's pretty likely. Because that's what's stretching your capacity to the degree that you need to get better and that's just not a comfortable situation for somewhere that you depend on to make a living. And that ended up being, I ended up approaching my management and my mentorship as effectively mutually exclusive things and it ended up working out really well for me. At this particular point in time, I happened to have a manager who happened to get way out ahead of me technically, and is willing to review PRs and so, that's very nice. But it's a nice-to-have. It's not something that I expect of a manager and it's ended up making me much more happy and manage relationships. MAE: I agree with all of that. So well said, Chelsea. CHELSEA: I try, I try. [laughs] Casey, are there things that you look for specifically in a manager? CASEY: Hmm. I guess for that question, I want to take the perspective inward, into myself. What do I need support on and who can I get that from? And this is true as also an independent worker as a consultant freelancer, too. I need support for when things are hard and I can be validated from people who have similar experiences, that kind of like emotional support. I need technical support and skills, like the sales I don't have yet and I have support for that, thank goodness. Individuals, I need ideally communities and individuals, both. They're both really important to me and some of these could be in a manager, but lately, I'm my own manager and I can be none of those things, really. I'm myself. I can't do this external support for myself. Even when I'm typing into a spreadsheet and the computer's trying to be a mirror, it's not as good as talking to another person. Another perspective that I need support on is how do I know what I'm doing is important and so, I do use spreadsheets as a mirror for that a lot of the time for myself. Like this impact is having this kind of magnitude of impact on this many people and then that calculates to this thing, maybe. Does that match my gut? That's literally what I want to know, too. The numbers aren't telling me, but talking to other people about impact on their projects really kind of solidifies that for me. And it's not always the client directly. It could be someone else who sees the impact I'm having on a client. Kind of like the manager, I don't want to expect clients to tell me the impact I'm having. In fact, for business reasons, I should know what the impact is myself, to tell them, to upsell them and continue it going anyway. So it really helps me to have peers to talk through about impact. Like that, too types of support. What other kinds of support do you need as consultants that I didn't just cover? MAE: I still need – and I have [laughs] hired Casey to help me. I still need a way to explain what it is that I am offering and what the value of that really is in a way that is clear and succinct. Every time I've gone to make a website, or a list of what it is that I offer, I end up in the hundreds of bullet points [laughs] and I just don't – [overtalk] CASEY: Yeah, yeah. MAE: Have a way to capture it yet. So often when people go indie, they do have a unique idea, a unique offering so finding a way to summarize what that is can be really challenging. I loved hearing you two when you were talking about knowing what kinds of work you want to do and who your ideal customer is. Those are things I have a clearer sense of, but how to make that connection is still a little bit of a gap for me. But you reminded me in that and I just want to mention here this book, The Pumpkin Plan, like a very bro business book situation, [chuckles] but what is in there is so good. I don't want to give it away and also, open up another topic [laughs] that I'll talk too long about. So I won't go into it right now, but definitely recommend it. One of the things is how to call your client list and figure out what is the most optimal situation that's going to lead toward the most impact for everybody. CASEY: One of the things I think back to a lot is user research and how can we apply that this business discovery process. I basically used the same techniques that were in my human computer interaction class I took 10, or 15 years ago. Like asking open ended questions, trying to get them to say what their problems are, remembering how they said it in their own words and saying it back to them—that's a big, big step. But then there's a whole lot of techniques I didn't learn from human computer interaction, that are sales techniques, and my favorite resource for that so far is called SPIN selling where SPIN is an acronym and it sounds like a wonky technique that wouldn't work because it's just like a random technique to pull out. I don't know, but it's not. This book is based on studies and it shows what you need to do to make big ticket sales go through, which is very different than selling those plastic things with the poppy bubbles in the mall stand in the middle of the hallway. Those low-key things they can manipulate people into buying and people aren't going to return it probably. But big-ticket things need a different approach than traditional sales and marketing knowledge and I really like the ideas in SPIN selling. I don't want to go into them today. We'll talk about it later. But those are two of the perspectives I bring to this kind of problem, user research and the SPIN selling techniques. I want to share what my ideal client would be. I think that's interesting, too. So I really want to help companies be happier and more effective. I want to help the employees be happier and more effective, and that has the impact on the users of the company, or whoever their clients are. It definitely impacts that, which makes it a thing I can sell, thankfully. So an organization usually knows when they're not the most happy, or the most effective. They know it, but my ideal client isn't just one that knows that, but they also have leadership buy-in; they have some leader who really cares and can advocate for making it better and they just don't know how. They don't have enough resources to make it happen in their org. Maybe they have, or don't have experience with it, but they need support. That's where I come in and then my impact really is on the employees. I want to help the employees be happier and more effective. That's the direct impact I want, and then it has the really strong, indirect impact on the business outcomes. So in that vein, I'm willing to help even large tech companies because if I can help their employees be happier, that is a positive impact. Even if I don't care about large tech companies' [chuckles] business outcomes, I'm okay with that because my focus is specifically on the employees. That's different than a lot of people I talk to; they really just want to support like nonprofit type, stronger impact of the mission and that totally makes sense to me, too. MAE: Also, it is possible to have a large and ever growing equitably run company. It is possible. I do want to contribute toward that existing in the world and as much as there's focus on what the ultimate looking out impact is, I care about the experience of employees and individuals on the way to get there. I'm not a utilitarian thinker. CASEY: Yeah, but we can even frame it in a utilitarian way if we need to. If we're like a stakeholder presentation, if someone leaves the company and it takes six months to replace them and their work is in the meantime off board to other people, what's the financial impact of all that. I saw a paper about it. Maybe I can dig it up and I'll link to it. It's like to replace a person in tech it costs a $100K. So if they can hire a consultant for less than a $100K to save one person from leaving, it pays for itself. If that number is right, or whatever. Maybe it was ten employees for that number. The paper will say much better than I will. CHELSEA: I think that in mentioning that Casey, you bring up something that businesses I think sometimes don't think about, which is some of the hidden costs that can easily be difficult to predict, or difficult to measure those kinds of things. One of the hidden costs is the turnover costs is the churn cost because there's how much it takes to hire another person and then there's the amount of ramp time before that person gets to where the person who left was. CASEY: Right, right, right. CHELSEA: And that's also a thing. There's all the time that developers are spending on forensic software analysis in order to find out all of the context that got dropped when a person left. CASEY: Yeah. The one person who knew that part of the code base, the last one is gone, uh oh. CHELSEA: Right. CASEY: It's a huge trust. And then engineering team is often really interested in conveying that risk. But if they're not empowered enough and don't have enough bandwidth time and energy to make the case, the executive team, or whoever will never hear it and they won't be able to safeguard against it. MAE: Or using the right language to communicate it. CASEY: Right, right. And that's its own skill. That's trainable, too thankfully. But we don't usually train engineers in that, traditionally. Engineers don't receive that training unless they go out of their way for it. PMs and designers, too, honestly. Like the stakeholder communication, everybody can work on. MAE: Yeah. CASEY: That's true. MAE: Communication. Everyone can, or not. Yes. [laughs] I learned the phrase indie today. I have never heard it and I really like it! It makes me feel cool inside and so love and – [overtalk] CASEY: Yeah, I have no record label, or I am my own record label, perhaps. MAE: Yo! CASEY: I've got one. I like the idea of having a Patreon, not to make money, but to have to help inspire yourself and I know a lot of friends have had Patreons with low income from it and they were actually upset about it. So I want to go back to those friends and say, “Look, this prove some people find value in what you're doing.” Like the social impact. I might make my own even. Thank you. MAE: I know I might do it too. It's good. That's good. CHELSEA: Absolutely. Highly recommended. One thing that I want to take away is the exercise, Casey, that you were talking about of tallying up all of the different things that a given position contributes in terms of a person's needs. Because I think that an exercise like that would be extremely helpful for, for example, some of my students who are getting their very first tech jobs. Students receive a very one-dimensional message about the way that tech employment goes. It tends to put set of five companies that show remain unnamed front and center, which whatever, but I would like them to be aware of the other options. And there is a very particular way of gauging the value of a tech position that I believe includes fewer dimensions than people should probably consider for the health of their career long-term and not only the health of their career, but also their health in their career. CASEY: One more parting thought I want to share for anyone is you need support for your career growth, for your happiness. If you're going to be a consultant, you need support for that. Find support in individuals and communities, you deserve that support and you can be that support for the people who are supporting you! It can be mutual. They need that, too.

01:48 - Kate's Superpower: Empathy * Absorbing Energy * Setting Healthy Energetic Boundaries * Authenticity * Intent vs Impact 10:46 - Words and Narratives Carry Power; Approaching Inclusive Language * Taking Action After Causing Harm * Get Specific, But Don't Overthink * Practice Makes Progress * Normalize Sharing Pronouns * No-CodeConf (https://webflow.com/nocodeconf) * No-CodeSchool (https://nocodeschool.co/) * Gender Expresion Does Not Always Equal Gender Identity 21:27 - Approaching Inclusive Language in the Written Word * Webflow Accessibility Checklist (https://webflow.com/accessibility/checklist) * Asking For Advice * Do Your Own Research/Work 29:18 - Creating Safe Places, Communities, and Environments * Absorbing and Asking * Authenticity (Cont'd) * Adaptation to Spaces * Shifting Energy 42:34 - Building Kula (https://kulayogadenver.com/) While Working in Tech * Community Care, Mutual Aid-Centered Model * Using Privilege to Pave the Way For More People * Alignment Reflections: John: The dichotomy between perfectionism and authenticity. Arty: Words carry power. Kate: Having an open heart is how you can put any of this into action. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: PRE-ROLL: Software is broken, but it can be fixed. Test Double's superpower is improving how the world builds software by building both great software and great teams. And you can help! Test Double is hiring empathetic senior software engineers and DevOps engineers. We work in Ruby, JavaScript, Elixir and a lot more. Test Double trusts developers with autonomy and flexibility at a remote, 100% employee-owned software consulting agency. Looking for more challenges? Enjoy lots of variety while working with the best teams in tech as a developer consultant at Test Double. Find out more and check out remote openings at link.testdouble.com/greater. That's link.testdouble.com/greater. JOHN: Welcome to Greater Than Code. I'm John Sawers and I'm here with Arty Starr. ARTY: Thanks, John. And I'm here with our guest today, Kate Marshall. Kate is a copywriter and inclusivity activist living in Denver. Since entering tech 4 years ago, she's toured the marketing org from paid efforts to podcast host, eventually falling in love with the world of copy. With this work, she hopes to make the web a more welcoming place using the power of words. Outside of Webflow, you'll find Kate opening Kula, a donation-based yoga studio, and bopping around the Mile High City with her partner, Leah. Welcome to the show, Kate. KATE: Hi, thank you so much! ARTY: So we always start our shows with our famous first question. What is your superpower and how did you acquire it? KATE: My superpower, I've been thinking about this. My superpower is empathy. It can also be one of my biggest downfalls [laughs], which I actually think happens more often than not with any superpower. I once heard from a child, actually, they always seem to know best that too much of the good, good is bad, bad. [laughter] So it turns out sometimes too much empathy can be too overwhelming for my system, but it has really driven everything that I've done in my career and my personal life. As for how I acquired it, I don't know that you can really acquire empathy. I think it's just something you have, or you don't. I've always been extremely intuitive and if you're going through something, it's likely that I can feel it. So I think I'm just [laughs] I hate to steal Maybelline's line, but I think I was born with it. JOHN: You talked about having a downside there and I've heard – and I'm curious, because most people talk about empathy as a positive thing and wanting more people to develop more empathy, but I'd to love hear you talk a little bit more about what you see the downsides are. KATE: Yeah. As someone who struggles with her own mental health issues, it can be really overwhelming for me to really take on whatever it is you're going through. Especially if it's a loved one, you tend to care more about what they're feeling, or what they're going through and an empath truly does absorb the energy of what's happening around them. So although, it does influence a lot of the work that I do, both in my full-time career and opening my yoga studio and everything in between, it's also hard sometimes to set those boundaries, to set healthy, really energetic boundaries. It's hard enough to voice your boundaries to people, but setting energetic boundaries is a whole other ballgame. So it can tend to feel overwhelming at times and bring you down if the energy around you is lower than what you want it to be. ARTY: So what kind of things do you do to try and set healthy, energetic boundaries? KATE: Ah. I do a lot of what some people would call, including myself, woo-woo practices. [chuckles] Obviously, I practice yoga. I teach yoga. I'm super passionate about holistic, or energetic healing so I go to Reiki regularly. I'm in therapy, talk therapy. All of those things combined help me build this essentially an energetic shield that I can psych myself up to use any time I'm leaving the apartment. If it feels a high energy day, or if I'm meeting up with a friend who I know is going through something, I really have to set those boundaries is. Same thing kind of at work, too. So much of the time that we spend in our lives is spent at work, or interacting with coworkers or colleagues and same thing. Everyone's going through their own journey and battles, and you have to carry that energetic shield around you wherever you go. JOHN: One way I've often thought about having those sort of boundaries is the more I know who I am, the more what the limits of me are and the barrier between me and the universe is. So the work that I do, which includes therapy and other things, to understand myself better and to feel like I know what's me and what's not me, helps me have those boundaries. Because then I know if there's something going on with someone else and I can relate to it, but not get swept up by it. KATE: Yeah. It's so funny you say that because I was actually just having a conversation with a friend a couple weeks ago that has really stuck with me. I was kind of feeling like I was messing up, essentially. Like I was not fully able to honor, or notice all of the triggers of the people around me. I think especially at the end of the year and as a queer person who is surrounded by queer community, it can be really tough around the holidays. So that energy can just be generally more charged and I was finding it difficult to reconcile with my idea of perfection in that I really want to honor every person around me who has triggers, who has boundaries that maybe haven't been communicated, and it almost feels like you're almost always crossing some sort of line, especially when you're putting those perfectionism expectations on yourself. My friend was like, “I don't think it's as much about being perfect at it as much as it is feeling like you're being authentically yourself and really authentically interacting with those people.” I don't know if I can really voice what the connection is between being able to honor triggers and boundaries of the people around you and feeling like your authentic self, but there's something about it that feels really connected to me. As long as you're trying your best and feeling like you're coming from a place of love, or connection, or compassion, or empathy whatever feels most to you, that's really all we can do, right? JOHN: Yeah. I feel like that authenticity is such a tricky concept because the thoughts that you're having about wanting to be perfect and take care of everyone and make sure you're not triggering anybody and not stepping on any of your own things, that's also part of you that is authentically you. You may not want it to be that way, but it still is. [laughs]. ARTY: Yeah. JOHN: So I still don't have a really clear sense in my mind what authenticity really is. I think probably it settles down to being a little bit more in the moment, rather than up in the thinking, the judging, the worrying, and being able to be present rather than – [overtalk] ARTY: Totally. JOHN: Those other things, but it is tricky. KATE: Yeah. It can be tricky. Humans, man. [laughter] It really is like being a human and part of the human experience is going to be triggering other people. It's going to be causing harm. It's going to be causing trauma to other humans. That's just part of it. I think the more you can get comfy with that idea and then also just really feeling like you're doing everything you can to stay connected to your core, which usually is in humans is a place of love. You're rooted in love for the people around you. How could you criticize yourself too much when you know that you're coming from that place? ARTY: I feel like things change, too as you get feedback. In the context of any intimate relationship where you've got emotionally connected relationship with another person where you are more unguarded and you're having conversations about things that are more personal, that have at least the potential to hurt and cause harm. Like sometimes we do things not meaning to and we end up hurting someone else accidentally, but once that happens—and hopefully, you have an open dialogue where you have a conversation about these things and learn about these things and adapt—then I think the thing to do is honor each person as an individual of we're all peoples and then figure out well, what can we do to adapt how we operate in this relationship and look out for both people's best interests and strive for a win-win. If we don't try and do that, like if we do things that we know we're harming someone else and we're just like, “Well, you should just put up with that,” [laughs], or whatever. I think that's where it becomes problematic is at the same time, we all have our own limitations and sometimes, the best thing to do is this relationship doesn't work. The way that we interact causes mutual harm and we can't this a win-win relationship and the best thing to do sometimes is to separate, even though it hurts because it's not working. KATE: Yeah. I feel like sometimes it's a classic case of intent versus impact, too. Like what's your intention going into a conversation and then how does that end up actually impacting that person and how can you honor that and learn from that? That's actually one thing that I love so much about being a writer is that words do carry so much power—written word, spoken word, whatever it is. They hold so much power and they can cause harm whether we want them to, or not. Part of being an empath is caring a lot about people's lived experiences and I really see it as more than putting – being a writer and doing this every day, I see it so much more than just putting words on a page and hoping signs up for the beta, or watches the thing registers, or the conference. It's words can foster connection, words can build worlds for people; they can make people feel like they belong and I believe that I'm on this planet to foster that connection with each other and with ourselves. So it all connects for me. It all comes back around whether we're talking about being in a romantic relationship, or our relationship with our parents, or our caregivers, or the work that I do every day it all comes back to that connection and really wanting to make people feel more connected to themselves, to each other, and like they have a place with words. ARTY: Yeah. It's very powerful. Words and narratives, I would say too, just thinking about the stories that we tell ourselves, the stories that we tell one another that become foundational in our culture. It's all built upon were words. Words shape the ideas in our head. They shape our thoughts. They shape how we reflect on things, how we feel about things, and then when people give us their words, we absorb those and then those become part of our own reflections. KATE: Yeah. ARTY: We affect one another a lot. I think that's one of the things I'm just seeing and talking to you is just thinking about how much we affect one another through our everyday interactions. KATE: Yeah, and I think a lot of this comes down to – there's something you said earlier that resonated in that it's really about the action you take after you cause the harm, or after you say the thing that hurts the other person and it's less about – and that's what made me say intent versus impact because you see the impact, you acknowledge it, and you make a decision to lessen that next time, or to be aware, more aware next time. This is really at the core of all the work I do for inclusive language as well. It's just the core principle of the words we use carry a lot of power. And I was actually just chatting with someone in the No-Code space. We connected through Webflow a couple weeks ago and he said, “I think people are so scared to get it wrong when it comes to inclusive language,” and I experience this all the time. People freeze in their tracks because they don't know how address someone and then they're so scared to get it wrong and they're like, “Oh, so sorry, sorry, sorry, sorry,” and they're so apologetic. And then that makes it worse and it's just a whole thing. In this conversation, we were talking specifically about misgendering people. My partner is non-binary. They're misgendered every single day when we go to restaurants, when we are just out and about. So this is something that is a part of my life every day. I told him that fear is so real and I carry that fear, too because I don't want to hurt people because I want to like get it right. It comes back to that perfectionism, that expectation that I put on myself, especially as a queer person to get it right all the time. But so much of the good stuff lies in how you approach it and then how you fix it when you mess it up. Like, it's not so much about the thing, it's about the way that you approach it. If you approach inclusive language with an open mind, an open heart, and a real willingness, like true willingness to learn, that's what's important going into it and then you're already doing the work. You're already an ally. You're already however you want to put it. And then when you use an ableist word, or you use a racist word, or you misgender someone, your actions for following that speak volumes. I think we can really get caught up in the action itself and it's more about how you go into it and then how you try to fix it. ARTY: So I'm thinking for listeners that might identify with being in a situation of being in the headlights and not knowing how to respond, or what to do. Other than what you were just talking about with coming at it with an open heart, are there any specific recommendations you might have for how to approach inclusive language? KATE: Yeah. Yeah, I have a couple really, really good ones. So often, the way to speak more inclusively, or to write more inclusively is just to get more specific about what you're trying to say. So instead of saying, “Oh, that's so crazy,” which is ableist, you can say, “Oh, that's so unheard of.” That's a good example. Or instead of unnecessarily gendering something you're saying like, “Oh, I'm out of wine, call the waitress over.” It's server instead of waiter, or waitress. You kind of start to essentially practice replacing these words and these concepts that are so ingrained into who we are, into society at large, and really starting to disrupt those systems within us with challenging the way that we've described things in the past. So just essentially getting more specific when we're speaking. When it comes to misgendering people specifically, it's really important to not be overly apologetic when you misgender someone. I can give an example. If a server, for example, comes up to me and my partner and says, “Can I get you ladies anything else?” And I say, “Oh, actually my partner uses they/them pronouns. They are not a lady,” and they say, “Oh my God, I'm so sorry. Oh shit!” And then that makes my partner feel bad [chuckles] for putting them in that position and then it's kind of this like ping pong back and forth of just bad feelings. The ideal scenario, the server would say, “Oh, excuse me, can I get you all anything else?” Or, “Can I get you folks anything else?” Or just, if you're speaking about someone who uses they/them pronouns and you say, “Yeah, and I heard she, I mean, they did this thing.” You just quickly correct it and move on. Don't make it into a production. It's okay. We get it. Moving on. Just try not to overthink it, basically. [laughs] Get more specific, but don't overthink it. Isn't that like, what a dichotomy. [laughter] JOHN: That ties back to what you were saying about perfectionism also, right? Like you said, you freeze up if you try and be perfect about it all the time, because you can't always know what someone's pronouns are and so, you have to make a guess at some point and maybe you're going to guess wrong. But it's how you deal with it by not making everybody uncomfortable with the situation. [laughs] KATE: Yeah. JOHN: And like you said, ping pong of bad feelings just amplifies, the whole thing blows out of proportion. You can just be like, “Oh, my apologies.” Her, they, whatever it is and then very quickly move on and then it's forgotten the next minute. Everything moves on from that, but you're not weeping and gnashing and – [laughter] KATE: Yeah. JOHN: Well, it means you don't have to keep feeling bad about it for the next 3 days either, like everyone can move on from that point. KATE: Right. Yeah, and just doing your best to not do it again. JOHN: Yeah. KATE: Once you learn, it's important to really let that try to stick. If you're having trouble, I have a friend who really has trouble with they/them pronouns and they practice with their dog. They talk to their dog about this person and they use they/them pronouns in that. Practice really does make perfect in this – not perfect, okay. Practice really does make progress in this kind of scenario and also, normalize sharing pronouns. JOHN: Yeah. KATE: It's more than just putting it in your Zoom name. It's more than just putting it in your Instagram bio. A good example of really starting this conversation was during Webflow's No-Code Conf, our yearly conference. It was mostly online and we had a live portion of it and every single time we introduced someone new, or introduced ourselves, we said, “My name is Kate Marshall, my pronouns are she/her, and I'm so happy to be here with you today.” Or just asking if you don't know, or if you're in a space with someone new, you say, “What are your pronouns?” It's really is that easy. Webflow made some year-round pride mech that we launched over the summer and we have a cute beanie that says “Ask me my pronouns.” It's like, it's cool to ask. It's fine to ask and that's so much better than unintentionally misgendering someone. It's going to take some time to get there, but normalize it. JOHN: Yeah, and I think there's one key to that that has always stuck out of my mind, which is don't ask pronouns just for the people you think might have different pronouns than you would expect. KATE: Yes. JOHN: Make it part of all the conversations so it's not just singling somebody out of a group and saying, “I want to know your pronouns because they're probably different.” That's not good. KATE: Right, because gender expression does not always equal gender identity. JOHN: Yeah. KATE: You can't know someone's gender identity from the way that they express their gender and that's also another huge misconception that I think it's time we talk more about. JOHN: So we've been talking a lot about conversations and person-to-person interactions and inclusive language there. But a lot of what you do is it on the writing level and I imagine there's some differences there. So I'm curious as to what you see as far as the things that you do to work on that in the written form. KATE: Yeah. So this is actually a really great resource that I was planning on sharing with whoever's listening, or whoever's following along this podcast. There is a really wonderful inclusive language guidelines that we have published externally at Webflow and I own it, I update it regularly as different things come in and inclusive language is constantly evolving. It will never be at a final resting point and that's also part of why I love it so much because you truly are always growing. I'm always learning something new about inclusive language, or to make someone feel more included with the words that I'm writing. This table has, or this resource has ableist language, racist language, and sexist language tables with words to avoid, why to avoid them, and some alternatives and just some general principles. I reference it constantly. Like I said, it's always evolving. I actually don't know how many words are on there, but it's a good amount and it's a lot of things have been surfaced to me that I had no idea were racist. For instance, the word gypped. Like if you say, “Oh, they gypped me” is actually racist. It's rooted in the belief that gypsy people are thieves. [chuckles] So it's things like that we really kind of go deep in there and I reference this constantly. Also, ALS language is a really big consideration, especially in the tech space. So instead of – and this can be avoided most of the time, not all of the time. We do work with a really wonderful accessibility consultant who I run things by constantly. Shout out to Michele. Oh, she was actually on the podcast at one point. Michele Williams, shout out. Lovely human. So a good example is instead of “watch now,” or “listen now,” it's “explore this thing,” “browse this thing,” “learn more”. Just try not to get so specific about the way that someone might be consuming the information that I'm putting down on the page. Stuff like that. It truly does come down to just getting more specific as just a general principle. JOHN: So it sounds to me some of the first steps you take are obviously being aware that you have to mold your language to be more accessible and inclusive, then it's informing yourself of what the common pitfalls are. As you said, you have consultants, you've got guides, you've got places where you can gather this information and then once you have that, then you build that into your mental process for writing what you're writing. KATE: Yeah, and truly just asking questions and this goes for everyone. No one would ever – if I reached out to our head of DEI, Mariah, and said, “Mariah, is this thing offensive?” Or, “How should I phrase this thing to feel more inclusive to more people?” She would never come back at me and say, “Why are you asking me this? You should already know this,” and that is the attitude across the board. I would never fault someone for coming to me and asking me how to phrase something, or how to write something to make it feel better for more people. So it's really a humbling experience [laughs] to be in this position. Again, words carry so much power and I just never take for granted, the power essentially that I have, even if it is just for a tech company. A lot of people are consuming that and I want to make them feel included. JOHN: Yeah. The written face of a company is going to tell readers a lot about the culture of the company, the culture of the community around the product. KATE: Yeah. JOHN: Whether they're going to be welcome there, like what their experience is going to be like if they invest their time to learn about it. So it's really important to have that language there and woven into everything that's written, not just off the corner on the DEI page. KATE: Yeah. That's what I was just about to say is especially if you're a company that claims to prioritize DEI, you better be paying close attention to the words that you're using in your product, on your homepage, whatever it is, your customer support. I've worked with the customer support team at Webflow to make sure that the phrasing feels good for people. It truly does trickle into every single asset of a business and it's ongoing work that does not just end at, like you said, putting it on a DEI page. Like, “We care about this,” and then not actually caring about it. That sucks. [laughs] JOHN: Oh, the other thing before we move too far on from last topic, you're talking about asking for advice. I think one of the keys there, a, being humble and just saying, “I would like to know,” and you're very unlikely to get criticized for simply asking how something can be better. But I feel like one of the keys to doing that well is also not arguing with the person you've asked after they give you an answer. KATE: Right. Yes. Especially if that person is a part of the community that your words are affecting, or that your question is affecting. It's such a tricky balance because it's really not the queer community's job to educate people who are not queer about inclusive language. But when that person is willing to share their knowledge with the you, or willing to share their experience with you, you've got to listen. Your opinions about their lived experience don't come into that conversation, or shouldn't come into that conversation. It's not questioning the information that you're given, but then it's also taking that and doing your own research and asking more people and having conversations with your friends and family trying to widen this breadth of information and knowledge as a community. Like I said, kind of dismantling the things that we're taught growing up by capitalism, by society, everything that kind of unnecessarily separates and then doing better next time. I've actually had conversations with people who are very curious, who come to me with questions and then the next time I interact with them, they're just back to factory settings. That's so disappointing and just makes me feel like my energy could have been better spent having that conversation with someone who is more receptive. So I think it really is just about being open to hearing someone's experience, not questioning it, and then really taking that in and doing the work on your own. JOHN: Yeah, and part of that doing the work is also for the things that you can Google for the things where you can look at it from the guide, do that first before asking for someone's time. KATE: Yeah. JOHN: So that they're not answering the same 101 questions every time that are just written in 15 different blog posts. KATE: Yes. Especially if you're asking a marginalized person to do the work for you. JOHN: Yeah. KATE: Intersectionality matters and putting more work on the shoulders of people who are already weighed down by so much ain't it. [laughs] ARTY: Well, I was wanting to go back to your original superpower that you talked about with empathy. We talked a lot about some of these factors that make empathy of a difficult thing of over empathizing and what kind of factors make that hard. But as a superpower, what kind of superpowers does that give you? KATE: Ah, just being able to really connect to a lot of different people. I mentioned earlier that I believe it's my purpose, it's my life's work on this planet at this time to connect people to themselves and to each other. The more asking I can do and the more absorbing I can do of other people's experiences, the better I am at being able to connect with them and being able to make them feel like they belong in whatever space I'm in. I can't connect with someone if I don't try and get it. Try and get what they're going through, or what their experiences are. That's why I do so much time just talking to people, and that's why I love yoga and why I want to start this studio and open this space. Because we live in a world where we don't have a lot of spaces, especially marginalized communities don't have a lot of spaces that feel like they're being understood, or they're truly being heard, or seen. Me being an empath, I'm able to access that in people more and therefore, bringing them closer to safer spaces, or safer people, safer communities where they really feel like they can exist and be their full, whole, and complete selves. It's really special. ARTY: We also touched this concept of authenticity and it seems like that also comes up in this context of creating these safe spaces and safe communities where people can be their whole selves. So when you think about authenticity, we talked about this being a difficult and fuzzy word, but at the same time, it does have some meaning as to what that means, and these challenges with regards to boundaries and things. But I'm curious, what does authenticity mean to you? How does that come into play with this idea of safety and creating these safe spaces for others as well? KATE: Yeah. I feel like there's so much in there. I think one of the biggest things to accept about the word authenticity, or the concept of authenticity is that it's always changing and it means something different to everyone. We are all authentic to ourselves in different ways and at different times in our lives and I think it's so important to honor the real evolution of feeling authentic. There are times and days where I'm like who even am. It's like what even, but there's always this sort of core, root part of me that I don't lose, which is what we've been talking about. This ability to connect, this feeling of empathy, of compassion, of wanting to really be a part of the human experience. That, to me, kind of always stays and I feel like that's the authentic, like the real, real, authentic parts of me. There are layers to it that are always changing and as people, we are also always evolving and always changing. So those different parts of authenticity could be what you wear that make you feel like your most authentic self. It can be how you interact with your friends, or how you interact with the person, getting your popcorn at the movies, or whatever it is. Those can all feel like parts of your authentic self. That means something different to everyone. But I think that's such a beautiful part about it and about just being human is just how often these things are changing for us and how important it is to honor someone's authenticity, whatever that means for them at that time. Even if it's completely different from what you knew about them, or how you knew them before. It's this constant curiosity of yourself and of others, really getting deeply curious about what feels like you. ARTY: I was wondering about safety because you were talking about the importance of creating these safe communities and safe environments where people could be their whole, complete selves, which sounds a lot like the authenticity thing, but you trying to create space for that for others. KATE: Yeah. Well, the reality of safety is that there's no one space that will ever be a “safe space for everyone,” and that's why I like to say safer spaces, or a safer space for people because you can never – I feel like it's all coming full circle where you can never meet every single person exactly where they need to be met in any given moment. You can just do your best to create spaces that feel safer to them and you do that with authentic connection, with getting curious about who they are and what they love, and just making sure that your heart's really in it. [chuckles] Same with inclusive language. It's all about the way you approach it to make someone feel safer. But I do think it's an I distinction to remember. You're never going to be safe for everyone. A space you create is never going to be safe for everyone. The best you can do is just make it safer for more people. ARTY: When I think about just the opposite of that, of times that I've gone into a group where I haven't felt safe being myself and then when you talk of about being your complete whole self, it's like bringing a whole another level of yourself to a space that may not really fit that space and that seems like it's okay, too. Like we don't necessarily have to bring our full self to all these different spaces, but whatever space we're a part of, we kind of sync up and adapt to it. So if I'm in one space and I feel the kind of vibe, energy, context of what's going on, how people are interacting, the energy they put forth when they speak with whatever sorts of words that they use. I'm going to feel that and adapt to that context of what feels safe and then as more people start adapting to that, it creates a norm that other people that then come and see what's going on in this group come to an understanding about what the energy in the room is like. KATE: Yeah. ARTY: And all it takes is one person to bring a different energy into that to shift the whole dynamic of things. KATE: Yeah. The reality is you'll never be able to change every space and I think that's such a good point. It makes me feel like saying you have to be protective of your energy. If you go into a space and it just doesn't feel right, or there's someone who is in the room that doesn't feel safe to you, or that doesn't feel like they're on the same page as you, it's okay to not feel like you need to change the world in that space. Like you don't always have to go into a space and say, “I'm going to change it.” That is how change is made when you feel safe enough. That's why it's so important to foster that energy from the jump. That's just a foundational thing at a company in a yoga studio, in a home, at a restaurant. It can be changed, but it really should be part of the foundation of making a safer space, or a more inclusive space. Because otherwise, you're asking the people who don't feel safe, who are usually marginalized people, or intersectionally marginalized in some way. You're asking them essentially to put in the work to change what you should have done as the foundation of your space. So it's a such a delicate balance of being protective of your energy and really being able to feel out the places where you feel okay saying something, or making a change, or just saying, “No, this isn't worth it for me. I'm going to go find a space that actually feels a little bit better, or that I feel more community in.” ARTY: And it seems like the other people that are in the group, how those people respond to you. If you shift your energy, a lot of times the people that are in the group will shift their energy in kind. Other times, in a different space, you might try to shift energy and then there's a lot of resistance to that where people are going a different way and so, you get pushed out of the group energy wise. These sorts of dynamics, you can feel this stuff going on of just, I just got outcast out of this group. Those are the kinds of things, though that you need to protect your own energy of even if I'm not included in this group, I can still have a good relationship with me and I can still like me and I can think I'm still pretty awesome and I can find other groups of folks that like me. It definitely, at least for me, I tend to be someone who's like, I don't know, I get out grouped a lot. [laughs] But at the same time, I've gotten used to that and then I find other places where I've got friends that love me and care about me and stuff. So those are recharge places where I can go and get back to a place where I feel solid and okay with myself, and then I'm much more resilient then going into these other spaces and stuff where I might not be accepted, where I might have to be kind of shielded and guarded and just put up a front, and operate in a way that makes everyone else feel more comfortable. KATE: Yeah, and isn't it so powerful to feel cared for? ARTY: I love that. KATE: Like just to feel cared for by the people around you is everything. It's everything. That's it. Just to feel like you are wanted, or you belong. To feel cared for. It can exist everywhere is the thing. In your Slack group, or whatever, you can make people feel cared for. I have never regretted reaching out to a coworker, or a friend, or whoever an acquaintance and saying, “Hey, I love this thing about you,” or “Congratulations on this rad thing you just launched,” or whatever. It's the care that's so powerful. ARTY: I feel like this is one of those things where we can learn things from our own pain and these social interactions and stuff. One of the things that I've experienced is you're in a group and you say something and nobody responds. [laughs] KATE: Yeah. ARTY: And after doing that for a while, you feel like you're just shouting into the void and nobody hears you and it's just this feeling of like invisibility. In feeling that way myself, one of the things I go out of my way to do is if somebody says something, I at least try and respond, acknowledge them, let them know that they're heard, they're cared about, and that there's somebody there on the other side [chuckles] and they're not shouting into the wind because I hate that feeling. It's an awful feeling to feel invisible like that. KATE: Awful, yeah. ARTY: But we can learn from those experiences and then we can use those as opportunities to understand how we can give in ways that are subtle, that are often little things that are kind of ignored, but they're little things that actually make a really big difference. KATE: Yeah, the little things. It really is the little things, isn't it? [laughs] Like and it's just, you can learn from your experiences, but you can also say, “I'm not doing this right now.” You can also check out. If you are giving and giving. and find that you're in the void essentially, more often than not, you can decide that that's no longer are worth your time, your energy, your care, and you can redirect that care to somewhere else that's going to reciprocate, or that's going to give you back that same care and that's so important, too. JOHN: Yeah, and it sounds like starting a yoga studio is not a trivial undertaking and obviously, you're highly motivated to create this kind of an environment in the world. So is there anything more you'd like to say about that because that ties in very closely with what we're talking about? KATE: Yeah. It's so weird to work full-time and be so passionate about my tech job and then turn around and be like, “I'm opening a yoga studio.” It's such a weird, but again, it's all connected at the root, at the core of what I'm trying to do in this world. The thing about Kula is that it's really built on this foundational mutual aid model. So being donation-based, it's really pay what you can, if you can. And what you pay, if you're able to give an extra $10 for the class that you take, that's going to pay for someone else's experience, who is unable to financially contribute to take that class. That's the basis of community care, of mutual aid and it's really this heart-based business model that is really tricky. I'm trying to get a loan right now and [chuckles] it's really hard to prove business financials when you have a donation-based model and you say, “Well, I'm going to guess what people might donate per class on average.” So it's been a real journey, [laughs] especially with today's famous supply chain issues that you hear about constantly in every single industry. I have an empty space right now. It needs to be completely built out. Construction costs are about triple what they should be. Again, coming from this real mutual aid community care centered model, it's really hard, but I have to keep coming back. I was just telling my partner about this the other day, I have to keep coming back to this core idea, or this real feeling that I don't need to have a beautifully designed space to create what I'm trying to create. When I started this, I envisioned just a literal empty room [chuckles] with some people in it and a bathroom and that's it. So of course, once I saw the designs, I was like, “Oh, I love this can lighting that's shining down in front of the bathroom door.” It's like so whatever, stereotypical. Not stereotypical, but surface level stuff. I really have had to time and time again, return to this longing almost for a space that feels safer for me, for my community, for Black people, for disabled people, for trans people, for Asian people; we don't have a lot of spaces that feel that way and that's just the reality. So it's a real delicate balance of how do I like – this is a business and I need money, [laughs] but then I really want this to be rooted in mutual aid and community care. It comes back to that car and that inclusivity, creating authentic connections. It's tricky out there for a queer woman entrepreneur with no collateral. [laughs] It's a tricky world out there, but I think we'll flip it someday. I really think pioneering this idea, or this business model at least where I'm at in Denver, I think it's going to start the conversation in more communities and with more people who want to do similar things and my hope is that that will foster those conversations and make it more accessible to more people. JOHN: Yeah, and I think every time someone manages to muster up the energy, the capital, and the community effort to put something like this together, it makes it just slightly easier for someone else a, they can learn the lessons and b, they're more examples of this thing operating in the world. So it becomes more possible in people's minds and you can build some of that momentum there. KATE: Yeah. And of course, it's really important to note and to remember that I come from a place of immense privilege. I have a great job in tech. I'm white. I am upper middle class. Technically, I'm “straight passing,” which is a whole other concept, but it is a thing and this is the way that I'm choosing to use my privilege to hopefully pave the way for more people. I do not take for granted the opportunity that I'm given and like I said, intersectionality matters and all of that, but I still have a lot of privilege going into this that I hope turns into something good for more people. ARTY: It also takes a special kind of person to be an entrepreneur because you really have to just keep on going. No matter any obstacle that's in your way, you've just got to keep on going and have that drive, desire, and dream to go and build something and make it happen and your superpowers probably going to help you out with that, too. It sounds like we've got multiple superpowers because I think you got to have superpowers to be an entrepreneur in itself. KATE: Yeah. I don't know, man. It's such a weird feeling to have because it just feels like it's what I'm supposed to be doing. That's it. It doesn't feel like I'm like – yes, it's a calling and all of that, but it just feels like the path and that, it feels more, more natural than anything I guess, is what I'm trying to say. The more people follow that feeling, the more authentic of a world, the more connected of a world we're going to have. I see a lot of people doing this work, similar things, and it makes me so happy to see. The words of one of my therapists, one of my past therapists told me, “Always stick with me,” and it was right around the time I was kind of – so I'd started planning before COVID hit and then COVID hit and I had to pause for about a year, a little bit less than a year. It was right around the time I was filing my LLC and really starting to move forward. It was actually December 17th of last year that I filed my LLC paperwork. So it's been a little over a year now. He told me, “How much longer are you willing to wait to give the community this thing that you want to give them? How much are you willing to make them wait for this space?” And I was like, “Yesterday. Yesterday.” Like, “I want to give people this space immediately,” and that has truly carried me through. This supply chain stuff is no joke. [laughs] and it has really carried me through some of the more doubtful moments in this journey. Yeah, and I feel like, man, what powerful words. Like, I just want to keep saying them because they are such powerful words to me. How much longer are you willing to make them wait? And it's like, I don't want to. [chuckles] So I guess I'm going to go do it. [laughter] Throw caution to the wind. [laughs] JOHN: Well, I think that ties back into what you were talking about is as you were thinking about designing the space and what kind of buildout you're going to need, and that can be a guide star for what actually needs to be there. What's the actual MVP for this space? Does it need a perfect coat of paint, or is what's there good enough? Does it need all the things arranged just so in the perfect lighting, or does it just need to exist and have people in the room and you can really focus in on what's going to get you there? And then of course, you iterate like everything else, you improve over time, but. KATE: Right. JOHN: I love that concept of just cut out everything that's in the way of this happening right now as much as possible. KATE: Yeah, and what a concept, I think that can be applied to so many things. Who am I trying to serve with this thing and what do I need to do to get there? It doesn't have to be this shiny, beautiful well-designed creation. It just needs to serve people. The people that you want to serve in the best way possible, and for me, that's getting this space open and actually having it in action. ARTY: I think once you find something that feels in alignment with you, you seem to have lots of clarity around just your sense of purpose, of what you want to move toward of a deep connection with yourself. One thing I found with that is no matter how much you get rejected by various groups in the world, if you can be congruent and authentic with yourself and follow that arrow, that once you start doing that, you find other people that are in resonance with you. They're out there, but you don't find them until you align with yourself. KATE: Yeah. Community. Community is so powerful and I love that you just said alignment because that really is truly what it is. It's finding the thing that makes you feel like you're doing something good and that feels authentic to your core, to those core principles of you that never really change. The things that are rooted in love, the things that are rooted in compassion, or whatever it is you care about. Community, that alignment is absolutely key. It's also, when I say I was born with my superpower of being an empath, this desire to create this space feels, it feels like I was also born with this desire, or born with this alignment. So I feel like so many times it's just going back to the basics of who you are. ARTY: Like you're actualizing who you are. KATE: Yeah. Like full alignment, enlightenment, that all kind of falls into place when you're really making the effort to be connected to your core. ARTY: It seems like a good place to do reflections. So at the end of the show, we usually go around and do final reflections and takeaways, final thoughts that you have and you get to go last, Kate. JOHN: There are a whole lot of different things that I've been thinking about here, but I think one of the ones that's sticking with me is the dichotomy between perfectionism and authenticity, and how I feel like they really are pulling against one another and that, which isn't to say things can't be perfect and authentic at the same time. But I think perfectionism is usually a negative feeling. Like you should do something, you're putting a lot of pressure, there's a lot of anxiety around perfectionism and that is pretty much an opposition to being authentically yourself. It's hard to be in touch with yourself when you're wrapped up in all those anxieties and so, thinking about the two of them together, I hadn't made that connection before, but I think that's something that's interesting that I'll be thinking about for a while. ARTY: I think the thing that's going to stick with me, Kate is you said, “Our words carry so much power,” and I think about our conversation today out just vibes in the room and how that shifts with the energy that we bring to the room, all of these subtle undercurrent conversations that we're having, and then how a sort of energy vibe becomes established. And how powerful even these really little tiny things we do are. We had this conversation around inclusive language and you gave so many great details and specifics around what that means and how we can make little, small alterations to some of these things that are just baked into us because of our culture and the words that we hear, phrasing and things that we hear, that we're just unaware of the impact of things. Just by paying attention and those little subtle details of things and coming at things with an open heart, regardless of how we might stumble, or mess things up, how much of a difference that can make because our words, though carry so much power. KATE: Yeah. And the thing you just said about having an open heart is truly how you can put any of this into action, how you can remain open to learning about authenticity, or what it feels like to not fall into a trap of perfectionism, or how to speak, or write, or interact more inclusively with other human beings. I feel like being open, being openminded, being open-hearted, whatever it is, is just really a superpower on its own. Remaining open and vulnerable in today's world is hard work. It does not come naturally to so many people, especially when you're dealing with your own traumas and your own individual interactions and maybe being forced into spaces where you don't feel safe. To remain open is such a tool for making other people feel cared for. So if that's the goal, I would say just being open is truly your superpower. JOHN: I think that's the quote I'm going to take with me: being open is the key to making people feel cared for. KATE: Yes. I love that. ARTY: Well, thank you for joining us on the show, Kate. It's been a pleasure to have you here. KATE: Thank you so much. This has been just the energy boost I needed. Special Guest: Kate Marshall.

00:54 - Emily's Superpower: Being a Good Teacher * Greater Than Code Episode 261: Celebrating Computer Science Education with Dave Bock (https://www.greaterthancode.com/celebrating-computer-science-education) * CyberPatriot (https://www.uscyberpatriot.org/) 06:24 - Online College Courses vs In-Person Learning / Emily's Community College Path * Network Engineering (https://www.fieldengineer.com/blogs/what-is-network-engineer-definition) * Virginia Tech (https://vt.edu/) * Guaranteed Transfer Programs (https://blog.collegevine.com/an-introduction-to-guaranteed-transfer-programs/) * Loudoun Codes (http://loudouncodes.org/) * Emily Haggard: My Path to Virginia Tech (http://loudouncodes.org/2020/09/23/path_to_va_tech.html) 11:58 - Computer Science Curriculums * Technical Depth * The Missing Semester of Your CS Education (https://missing.csail.mit.edu/) 19:28 - Being A Good Mentor / Mentor, Student Relationships * Using Intuition * Putting Yourself in Others' Mindsets * Diversity and Focusing On Commonalities * Addressing Gatekeeping in Tech * Celebrating Accomplishments * Bragging Loudly * Grace Hopper Conference (https://ghc.anitab.org/) * Cultural Dynamics Spread 38:24 - Dungeons & Dragons (https://dnd.wizards.com/) * Characters as an Extensions of Players Reflections: Dave: College is what you make of it, not where you went. Arty: Teaching people better who don't have a lot of experience yet. Mandy: “Empowered women, empower women.” Empowered men also empower women. Emily: Your mentor should have different skills from you and you should seek them out for that reason. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: MANDY: Hey, everybody! Welcome to Episode 265 of Greater Than Code. My name is Mandy Moore and I'm here with our guest panelist, Dave Bock. DAVE: Hi, I'm David Bock and I am here with our usual co-host, Arty Starr. ARTY: Thank you, Dave. And I'm here today with our guest, Emily Haggard. Emily is graduating from Virginia Tech with a Bachelor's in Computer Science this past December so, congratulations. She has a wide variety of experience in technology from web development to kernel programming, and even network engineering and cybersecurity. She is an active member of her community, having founded a cybersecurity club for middle schoolers. In her free time, she enjoys playing Dungeons and Dragons and writing novels. Welcome to the show, Emily. EMILY: Thank you. ARTY: So our first question we always ask is what is your superpower and how did you acquire it? EMILY: So I spent some time thinking about this and I would say that my superpower is that I'm a good teacher and what that means is that the people who come to me with questions wanting to learn something number one, my goal is to help them understand and number two, I think it's very important to make sure that whatever gap we have in our experience doesn't matter and that they don't feel that. So that they could be my 6-year-old brother and I'm trying to teach him algebra, or something and he doesn't feel like he is the 6-year-old trying to learn algebra. DAVE: I'll echo that sentiment about being a good teacher actually on two fronts, Emily. First of all, I am teaching your brother now in high school and just the other day, he credited you towards giving him a lot of background knowledge about the course and the curriculum before we ever started the class. So he seconds that you're a good teacher. And then listeners might remember, I was on a few weeks ago talking about my nonprofit and Emily was there at the beginning of me starting to volunteer in high schools. In fact, the way I met Emily, it was the fall of 2014. The first time I was volunteering at Loudoun Valley High School and one morning prior to class, there was going to be a meeting of a cybersecurity club. There were a bunch to the students milling about and there was this sophomore girl sitting in front of a computer, looking at a PowerPoint presentation of networking IP addresses, how the /24 of an IP address resolves and just all that kind of detail. Like very low-level detail about networking stuff and I was like, “Oh, that's interesting.” I wouldn't have expected a sophomore girl to be so interested in the low-level type of details of IP. And then the club started and she got up and started giving that presentation. That was not a slide deck she was reading; it was a slide deck she was creating. EMILY: Thank you. I actually remember that. [laughs] ARTY: So how did you acquire that superpower? EMILY: I think it was out of necessity. So going back to the story that David mentioned in high school, there was a cybersecurity competition called CyberPatriot that I competed in with friends and one year, all of a sudden, they just introduced network engineering to the competition. We had to configure and troubleshoot a simulated network and no one knew how to do that. So I took it upon myself to just figure it out so that my team could be competitive and win, but then part of the way that I learn actually is being able to teach something like that's how I grasp. I know that I've understood something and I'm ready to move on to the next topic is like, if I could teach this thing. So actually, I started out building all of that as a way to kind of condense my notes and condense my knowledge so that it'd stick in my head for the competition and I just realized it's already here, I should share this. So that's how I started there. Teaching network engineering to high schoolers that don't have any background knowledge is really hard. It forced me to put it in terms that would make sense and take away the really technical aspects of it and I think that built the teaching skill. DAVE: That relates to the club you started at the middle school for a CyberPatriot. How did that start? EMILY: That was initially a desire to have a capstone project and get out of high school a few weeks early. But I was sitting there with my friend and thinking about, “Okay, well, we need to do something that actually helps people. What should we do?” Like some people are going out and they're painting murals in schools, or gardening. It was like, well, we don't really like being outside and we're not really artistic. [chuckles] But what we do have is a lot of technical knowledge from all this work with CyberPatriot and we know that CyberPatriot has a middle school competition. So we actually approached the middle school. We had a sit down with, I think the dean at our local middle school. We talked about what CyberPatriot was and what we wanted to do with the students, which was have them bust over to the high school so we could teach them as an afterschool program. I guess we convinced him and so, a couple months later they're busing students over for us to teach. DAVE: Wow. And did they ever participate in competitions as middle schoolers? EMILY: Yes, they did. DAVE: Very cool. EMILY: Yeah. DAVE: Can you go into what those competitions are like? I don't think most of the audience even knows that exists. EMILY: Yeah, sure. So CyberPatriot, it's a cybersecurity competition for predominantly high schoolers that's run by the Air Force and you have a couple rounds throughout the year, I think it's like five, or so, and at each round you have 6 hours and you're given some virtual machines, which you have to secure and remove viruses from and things, and you get points for doing all of that. They added on network simulation, which was with some Cisco proprietary software, which would simulate your routers, your firewalls, and everything. So you'd have to configure and troubleshoot that as well and you would get points for the same thing. It builds a lot of comradery with all of us having to sit there for 6 hours after school and like, we're getting tired. It's a Friday night, everyone's a little bit loopy and all we've eaten is pizza for 6 hours. [laughs] DAVE: Well, that's a good jumpstart to your career, I think. [laughs] EMILY: Yes, for sure. MANDY: So while in college, I'm guessing that – well, I'm assuming that you've been pretty impacted by COVID and doing in-person learning versus online learning. How's that been for you? EMILY: I've actually found it pushes me to challenge the status quo. Online college classes, for the most part, the lectures aren't that helpful. They're not that great. So I had to pick up a lot of skills, like learning to teach myself, reading books, and figuring out ways to discern if I needed to research something further, if I really understood it yet, or not. That's a really hard question to ask actually is if you don't have the knowledge, how do you know that you don't have that knowledge? That's something I kind of had – it's a skill that you have to work on. So that is something I developed over the time when we were online and I've actually also done – I worked time for a year after high school and I took mostly online classes at the community college. Those skills started there, too and then I just built on them when I came to Virginia Tech and we had COVID happen. DAVE: Actually, I'd like to ask about that community college time. I know you had an interesting path into Virginia Tech, one that I'm really interested in for my own kids as well. Can you talk about that? EMILY: Yeah. So I, out of high school, always thought I'm going to – I'm a first-generation student. My parents did not go to college. They went to the military and grandparents before them. So I had always had it in my head that I am going to go and get that 4-year degree. That's what I want for myself. At the end of high school, I applied to Virginia Tech. I had a dream school. I wanted to go to Georgia Tech. They rejected me. Oh, well, that dream shot. I need to find something new. So I applied to Virginia Tech thinking it was going to be a safe bet. It's an in-state school, I was a very good student; they would never reject me and so, I applied for the engineering program and I was rejected. They did admit me for the neuroscience program, but it wasn't going to be what I wanted and I was realizing that I did not like either chemistry, or biology, so that would never work. And then at the same time, because of my work with CyberPatriot, I was able to get an internship in network engineering at a college not too far from where I lived. After I graduated high school, they offered me a job as a network engineer, which I took because my team was fantastic, I really liked my manager, and I was comfortable there. I took this job and I said, “Okay, I'm going to keep working on the college thing because it's what I always wanted for myself.” So I just signed up for community college and that was pretty tough working a full-time and doing community college until 11 o'clock at night and getting up the next day and doing it all over again. And from there, I decided that Virginia Tech was going to be the best option for me, just from a very logical perspective. I kind of thought Virginia Tech was a bit cult-y. I was never really gung-ho about going, but it made the most sense being an in-state school that's very well-known. I worked through community college and I applied to Virginia Tech again after 1 year at community college and they rejected me again. so I was like, “Oh no, now what do I do I?” And I realized I needed to make use of the guaranteed transfer program. One of the really cool things in Virginia at least is that a lot of the state schools have agreements with the community college, where if you get an associates with a specific GPA, you can transfer into that program and the university and your transfer's guaranteed, they can't reject you. So I was like, “Aha, they can't get rid of me this time.” Yeah, I did it and it's kind of a messy process. I actually went into that in a blog post on David has a nonprofit called Loudoun Codes. I wrote a blog post for his website and detailed that entire – being a transfer student is hard because there's a lot of credits that may not get transferred over because Virginia Tech is a little bit – all 4-year colleges are a little bit elitist in their attitude towards community college and they didn't take some of the credits that I had, which put me behind quite far, even though I had that knowledge, they said I didn't. So that added on some extra time and some extra summer semesters while I was at Tech. ARTY: Yeah. I did something similar with doing community college and then what you're talking about with the whole elitist attitude with the transfer and having a whole bunch of your credits not transferring and I'm definitely familiar with that whole experience. DAVE: Yeah. EMILY: And even now that I think about it, I remember community college, too. It's built for one specific type of student, which is great. I think they're really good at helping people who just weren't present, or weren't able to do the work and make the progress in high school. They're really good at helping those types of students. But as someone who did a whole bunch of AP classes, had a crazy GPA, they just didn't really know how to handle me. They said, “Okay, you've tested out of pretty much all of our math classes, but you are still lacking some credits.” So I had to take multi-variable calculus in community college in order to get credit to replace the fact that I tested out of pre-cal and which was kind of silly, but in the long run, it was great because I hear multi-variable calculus at Tech is pretty hard. But definitely, there's a lot of bureaucratic nonsense about college. Education is important. It's great. I've learned a lot of things, but there's still all these old ways of thinking and people are just not ready for change in college a lot of the time. The people who make decisions that is. DAVE: Well, I'd like to ask a little bit about the computer science curriculum that you've had and the angle I'm asking from when I worked at LivingSocial, I worked with one of the first group of people that had graduated from our bootcamp program and had transferred from other careers, spent 12 weeks learning software engineering skills, and then were integrated with a group of software engineers at LivingSocial. We would occasionally get into conversations about, well, if I learned to be a software engineer in 12 weeks, what do you learn in 4 years of college? So we started to do these internal brown bags that were kind of the Discovery Channel version of computer science. A lot of that material I've since recycled into the presentations I do at high school. But for your typical person who might have sidelined into this career from a different perspective, what's been your curriculum like? EMILY: I really like the parts of the curriculum that had technical depth because coming into it at my level, that's what I was lacking in certain areas. I had built the foundation really strong, but the details of it, I didn't have. The classes that Virginia Tech, like the notorious systems class and a cybersecurity class I have taken this semester, that have gone in detail with technology and pushed what I understood, those were my most valuable classes. There was a lot of it that I would've been happy without [laughs] because I'm not sure it will apply so much to my life going forward. I'm a very practical person. Engineer mindset; I don't want to worry about things that can actually be applied to the real world so much. So for me this semester, actually, it's been really challenging because I've taken a data structures and algorithms class where we're talking about NP complete versus NP hard, and what it would mean if we could solve an NP complete problem in polynomial time. It's really hard to care. It's really hard to see how that [laughs] helps. It's interesting from a pure math perspective, but coming into it as someone who was already in the adult world and very grounded, it feels like bloat. DAVE: Yeah. That stuff is interesting if you're are designing databases, but most of us are just using databases and that – [overtalk] EMILY: Right. DAVE: Stuff is all kind of baked in. EMILY: Yeah. DAVE: For the average person on a technical career path, we're far more interested in the business problems than the math problems. ARTY: I'm curious, too. There's also lots of stuff that seems like it's missing in college curriculum from just really fundamental things that you need to know as a software engineer. So did you have things like source control and continuous integration? I think back to my own college experience and I didn't learn about source control until I got out of college. [laughs] And why is that? Why is that? It seems so backwards because there's these fundamental things that we need to learn and within 4 years, can we not somehow get that in the curriculum? I'm wondering what your experience has been like. EMILY: So Virginia Tech, I think the CS department head is actually really good at being reflective because he requires every senior to take a seminar class as they exit. It's a one credit class; it's mostly just feedback for the school and I think it's really cool because he asks all of us to make a presentation, just record ourselves talking over some slides about our experience and the things we would change. That really impressed me that this guy who gets to make so many decisions is listening to the people who are just kind of peons of the system and what I said was that there are certain classes that they give background knowledge. Like there's one in particular where it's essentially the closest crossover we have with the electrical engineering department and it's really painful, as someone who works with software, to try and put myself in a hardware mindset working with AND gates, OR gates, and all that, and trying to deal with these simulated chips. It's awful and then it never comes back. We never talk about again in the curriculum and it's a prerequisite for the systems class, which has nothing at all to do with that, really. This segues into another thing. I've had an internship while I've been at Virginia Tech that's a web consultant role, or a development consultant role with a company called Acceleration. They run just a small office in Blacksburg and they have a really cool business model. They take students at Virginia Tech and at Radford, a neighboring school, and they have us work with clients on real software development projects. They pair us with mentors who have 5, 10 years of experiences, software consultants, and we get to learn all those things that school doesn't teach us. So that's actually how I learned Git, Scrum, and all that stuff that isn't taught in college even now and I went back to the CS department head and I said, “Replace that class with the class that teaches us Git, Scrum, Kanban, and even just a brief overview of Docker, AWS, and the concepts so that people have a foundation when they try to go to work and they're trying to read all this documentation, or they're asked to build a container image and they have no idea what it's talking about, or what it's for.” Yeah, going back to the original question, no, I didn't learn version control in college, but the weird thing is that I was expected to know it in my classes without ever being taught it because, especially in the upper level like 3,004 level, or 1,000 level classes, they have you work on group projects where Git is essential and some of them, especially the capstone project, are long-term projects and you really need to use Scrum, or use some sort of methodology rather than just the how you would treat a two-week project. Actually, it's interesting because David was my sponsor on my capstone project in college and he really helped my team with the whole project planning, sprint planning, and just understanding how Scrum and all that works and what it's for. DAVE: Yeah. I just shared a link that is a series of videos from MIT called The Missing Semester of Your Computer Science Education that talks about Git, version control and command line, using the back shell, stuff about using a database, how to use a debugger; just all that kind of stuff is stuff that you're expected to know, but never formally taught. ARTY: What about unit testing? EMILY: Okay. So that's an interesting exception to the rule, but I don't think they really carried it through, through my entire experience at Tech. So in the earlier classes, we were actually forced to write unit tests that was part of our assignments and they would look to see that we had – I think we had to have a 100% testing coverage, or very close to it. So that was good, but then it kind of dropped away as we went to the upper-level classes and you just had to be a good programmer and you had to know to test small chunks of your code because we'd have these massive projects and there would be a testing framework to see if the entire thing worked, but there was no unit testing, really. Whereas, at work in my internship, unit tests are paramount, like [laughs], we put a huge emphasis on that. ARTY: So earlier Emily, you had had mentioned teaching people that had no experience at all and the challenge of trying to be able to help and support people and learning to understand regardless of what their gap was in existing experience. So what are some of the ideas, principles, things that you've learned on how to do that effectively? EMILY: That's a really tough question because I've worked on building intuition rather than a set of rules. But I think a few of the major things probably are thinking about it long enough beforehand, because there's always a lot of background context that they need. Usually, you don't present a solution before you've presented the problem and so, it's important to spend time thinking about that and especially how you're going to order concepts. I've noticed, too with some of the best teachers I've had in college is they were very careful with the order in which they introduced topics to build the necessary context and that's something that's really important with complete beginners. The thing is sometimes you have to build that context very quickly, which the best trick I have for that is just to create an analogy that has nothing to do with technology at all, create it out of a shared experience that you have, or something that they've probably experienced. Like a lot of times analogies for IP addressing use the mailing service, houses on a street and things like that, things that are common to our experience. I guess, maybe that's the foundation of it is you're trying to figure out what you have in common with this person that can take them from where they are to where you are currently and that requires a lot of social skills, intuition, and practice, so. DAVE: That's a really good observation because one of the things I find teaching high school, and this has been a skill I've had to learn, is being able to put my mindset in the point of view of the student that I need to go to where they are and use a good metaphor analogy to bring them up a step. That's a real challenge to be able to strip away all the knowledge I have and be like, “Oh, this must be the understanding of the problem they have” and try to figure out how to walk them forward. EMILY: Yeah. DAVE: That's a valuable skill. EMILY: I think that's really rewarding, though because when I see in their eyes that they've understood it, or I watch them solve the problem, then I know that I did it well and that's really rewarding. It's like, okay, cool. I got them to where I wanted them to be. ARTY: Reminds me. I was helping out mentoring college students for a while and I hadn't really been involved with college for a really long time. I was working with folks that knew very, very little and it was just astounding to me one, just realizing how much I actually knew. That's easy to take for granted. But also, just that if you can dial back and be patient, it's really rewarding I found to just be able to help people, to see that little light go on where they start connecting the dots and they're able to make something appear on the screen for the first time. That experience of “I made that! I made that happen.” I feel like that's one of the most exciting things about software and in programming is that experience of being able to create and make something come to life in that way. Just mentoring as an experience is something, I think is valuable in a lot of ways beyond just the immediate being able to help someone things, like it's a cool experience being a mentor as well. EMILY: And I think it's really important, too as a mentor to have good mentors yourself. I was really lucky to have David just show up in my high school one day [laughs] and I've been really lucky consistently with the mentors in my life. In my internship that I mentioned, I worked with fantastic engineers who are really good teachers. It's difficult to figure out how to good teacher without having first had good teachers yourself and regardless of the level of experience I have, I think I will always want to have that mentor relationship so that I can keep learning. One of the things, too is a lot of my mentors are quite different from mine. Like I am a very quiet introvert person. I would not say I'm very charismatic. I would say David is the opposite of all those things. So wanting to build those skills myself, it's good to have a role model who has them. DAVE: Well, thank you for that compliment. EMILY: Yeah. MANDY: That's really interesting that you said to find mentor that's the opposite of yourself. I literally just heard the same thing said by a different person last week that was like, “Yeah, you should totally find someone who you want to be, or emulate,” and I thought that was really good advice. EMILY: I agree with that completely. There's a lot of conversation around diversity in computer science and that's definitely a problem. Women do not have the representation they should, like I've always gone through classes and been 1 of 3 women in the class. [chuckles] But I think one of the ways in which we can approach this, besides just increasing the enrollment number, is focusing on commonalities—kind of what I mentioned before— from the perspective of mentors who are different than their students. Maybe a male mentor trying to mentor a female student. Focusing on your commonalities rather than naturally gravitating towards people who are like you; trying to find commonalities with people who are different from you. I think that's important. From the student perspective, it's less about finding commonalities more about, like you said, finding the things you want to emulate. Looking at other groups of people and figuring out what they're good at and what things you would like to take from them. [laughs] So. DAVE: Yeah, that's been an interesting challenge I've noticed in the school system is that in the elementary school years, boys and girls are equally competent and interested in this material. By the time they get to high school, we have that 70/30 split of males versus females. In the middle school, the numbers are all over place, but in the formal classes, it seems to be at 70/30 split by 7th grade and I can't really find any single root cause that causes that. Unfortunately, I think I saw some stuff this week with Computer Science Education Week where students as young as first grade are working with small robots in small groups and there always seems to be the extrovert boy that is like, “It's a robot. I'm going to be the one that plays with it,” and he gatekeeps access to girls who are like, “It's my turn.” It's really discouraging to see that behavior ingrained at such a young age. Any attempt I try to address it at the high school level – well, not any attempt, but I feel like a lot of times I can come off as the creepy old guy trying to encourage high school age girls to be more interested in computer science. It's a hard place for me to be. EMILY: Yeah. I don't think you're the creepy old guy. [laughter] I think this is a larger topic in society right now is it's ingrained in women to be meek and to not be as confident, and that's really hard to overcome. That sounds terrible. I don't think people consciously do that all the time. I don't think men are consciously trying to speak over women all the time, but it it's definitely happened to me all over the place—it's happened at work, it's happened in interviews. I think getting over that is definitely really tough, but some of the things that have helped me are to see and celebrate women's accomplishments. Like every time I hear about Grace Hopper, it makes me so happy. I know one time in high school, David took a few other female students and I to a celebration of women's accomplishments and the whole thing, there were male allies there, but the topic of the night was women bragging loudly about the things that they've accomplished. Because that's not something that's encouraged for us to do, but it's something that it builds our confidence and also changes how other people see us. Because the thing is, it's easy to brag and it's saddening that people will just implicitly believe that the more you say you did. So the more frequently you brag about how smart you are, the more inclined people are to believe it because we're pretty suggestible as humans. When women don't do that, that subtly over time changes the perspective of us. We have to, very intently – I can't think of a word I'm trying to say, but be very intentional about bragging about ourselves regardless of how uncomfortable it is, regardless of whether we think we deserve it, or not. MANDY: I also think it's really important for women to also amplify other women, like empowered women empower women. So when we step up and say, “Look at this thing Emily did, isn't that cool?” EMILY: Yeah. MANDY: That's something that we should be doing to highlight and amplify others' accomplishments. EMILY: For sure. I've been to the Grace Hopper conference virtually because it was during COVID times, but that was a huge component of it was there would be these networking circles where women just talk about the amazing things that they've done and you just meet all these strangers who have done really cool things. It goes in both directions, like you said, you get to raise them up and also be encouraged yourself and have something to look forward to. ARTY: It sounds like just being exposed to that culture was a powerful experience for you. EMILY: For sure. ARTY: I was thinking about our conversation earlier about role models and finding someone to look up to that you're like, “You're a really cool person. I admire you.” Having strong women as role models makes it much easier for us to operate a certain way when we interact with other people, and stay solid within ourself and confident within ourself and not cave in. When all the examples around us of women are backing off, caving in, and just being submissive in the way that they interact with the world, those are the sort of patterns we pick up and learn. Likewise, the mixed gender conversations and things that happen. We pick up on those play of dynamics, the things that we see, and if we have strong role models, then it helps us shift those other conversations. So if we have exp more experience with these things, like the Grace Hopper conference and being able to go into these other that have a culture built around strong women and supporting being a strong woman, then you can take some of those things back with you in these other environments and then also be a role model for others. Because people see you being strong and standing up for yourself, being confident and they might have the same reaction to you of like, “Wow, I really admire her. She's really cool.” And then they start to emulate those things too. So these cultural dynamics, they spread and it's this subconscious spreading thing that happens. But maybe if we can get more experiences in these positive environments, we can iteratively take some of those things back with us and influence our other environments that, that maybe aren't so healthy. EMILY: Yeah. I agree. And I think also, it's important to be honest and open about where you started because it's easy, if you're a really confident woman walking into the room, for people to think you've always been that way. I think it's important to tell the stories about when you weren't, because that's how other people are going to connect with you and see a path forward for themselves. Definitely. I'll start by telling a story. I think it's just a million small experiences. I was a strong student in high school. I was very good at math. We had study halls where we'd sit in the auditorium and we'd all be doing homework, and students would often go to the guy in my math class who knew less than I did and ask for help. I would just sit there and listen to him poorly help the other students and mostly just brag about himself, and just be quiet and think about how angry it made me, but not really be able to speak up, or say anything. I'm very different now. Because of the exposure that I've had, I am much more quick to shut that down and to give a different perspective when someone's acting that way. MANDY: But how cool would it have been if that guy would've been like, “Don't ask me, ask Emily”? DAVE: That's a really important point because I hear women talk about this problem all the time and I don't think the solution is a 100% in the women's hands. I think that it's men in the room. My own personal experience, most of my career has been spent in government contracting space and, in that space, the percentage of women to men is much higher. It's still not great, but I think there's a better attempt at inclusion during recruiting. I think that there's a lot of just forces in that environment that are more amenable to that as a career path for women. And then when I started consultancy with my two business partners, Kim and Karen, that was an unheard-of thing that I had two women business partners and at the time we started it, I didn't think it was that big of a deal at all. But then we were suddenly in the commercial space and people thought it was some scam I was running to be a minority owned company and my partner was my wife, or I'd go into a meeting and somebody thought I brought a secretary and I was like, “No, she's an engineer and she's good, if not better than me.” It opened my eyes to the assumptions that people make about what the consulting rates even should be for men versus women and it's in that environment I learned that I had to speak up. I had to represent to be a solution to that problem. I think you can get in an argument with other guys where they aren't even convinced there's a problem to solve. They'll start talking about, “Oh, well, women just aren't as interested in this career path.” It's like, I've known plenty that are and end up leaving. EMILY: I think definitely having support from both sides has been really important because it is typically men in places of authority and to have them be encouraging and not necessarily forcing you into the spotlight, but definitely trying to raise you up and encourage you to speak out means a lot. ARTY: Yeah. I found most of the teams I've been on, I was the only woman on the team, or one of two maybe and early on, when nobody knows you, people make a lot of assumptions about things. The typical thing I've seen happen is when you've got a woman programmer is often, the bit is flipped pretty early on of that oh, she doesn't know what she's doing and stuff, we don't need to listen to what she says kind of thing and then it becomes those initial conversations and how things are framed, tend to affect a lot of how the relationships on the team are moving forward. One of the things that I learn as just an adaptive thing is I was really smart. So what I do, the first thing on the team I'd find out what the hardest problem was, that none of the guys could solve and figure it out, and then I would go after that one. My first thing on the team, I would go and tackle the hardest thing. I found that once you kick the ass of the biggest baddy on the yard, respect. [laughter] So I ended up not having problems moving forward and that the guys would be more submissive toward me, even as opposed to the other way around. But it's like you come into a culture that is dominated by certain ways of thinking in this masculine hierarchy, alpha male thing going on and if that's the dominant culture, you have to learn to play that game and stake yourself in that game. Generally speaking, in this engineering world, intelligence is fairly respected. So I've at least found that that's been a way for me to operate and be able to reset that playing field anyway. MID-ROLL: This episode is supported by Compiler, an original podcast from Red Hat discussing tech topics big, small, and strange. Compiler unravels industry topics, trends, and the things you've always wanted to know about tech, through interviews with the people who know it best. On their show, you will hear a chorus of perspectives from the diverse communities behind the code. Compiler brings together a curious team of Red Hatters to tackle big questions in tech like, what is technical debt? What are tech hiring managers actually looking for? And do you have to know how to code to get started in open source? I checked out the “Should Managers Code?” episode of Compiler, and I thought it was interesting how the hosts spoke with Red Hatters who are vocal about what role, if any, that managers should have in code bases—and why they often fight to keep their hands on keys for as long as they can. Listen to Compiler on Apple Podcasts, or anywhere you listen to podcasts. We'll also include a link in the show notes. Our thanks to Compiler for their support. ARTY: Well, speaking of games, Arty, one of the things that Emily mentions in her bio is playing Dungeons and Dragons and this is an area where as well as I know Emily from her high school years, this is not something I know much about Emily at all. So I'd like to talk about that. Play, or DM, Emily? EMILY: Both. But I really enjoy DMing because it's all about creating problems to solve, in my opinion, like you throw out a bunch of story threads. The way I approach things is I try actually, unlike a lot of DMs, I do not do a lot of world building for places my players haven't been. I pretty much, there are bright light at the center of the world and anything the light doesn't touch doesn't exist. I haven't written it and I don't really look at it that often. So I'm constantly throwing out story threads to try and see what they latch onto and I'll dive into their character backstory to see what they are more predisposed to be interested in. It's like writing a weekly web comic. You don't have necessarily a set beginning and end and you don't really know where you're going to end up in between, but you end up with all these cool threads and you can tie them together in new and interesting ways. Just seeing the connections between those and being able to change what you want something to be on the fly is really cool and just very stimulating mentally for me. So it's like a puzzle exercise the whole time and it is also an interesting social exercise because you're trying to balance the needs of each person. I feel like D&D allows you to know people on a really deep level, because a lot of times, our characters are just – that we're playing. I guess, I didn't really explain what D&D is; I just made an assumption that people would know. It's a tabletop role playing game where you make a character. You're usually heroic and you're going about on this adventure trying to help people solve problems and these characters tend to be just naturally an extension of ourselves. So you get to see all the things that subconsciously the person doesn't real about themselves, but that show up in their character. I think that's really cool. DAVE: So do you have a weekly game, or how often do you play? EMILY: I try to run a weekly game. College often gets in the way. [laughs] DAVE: How many players? EMILY: It ranges from 3 to 4, sometimes 5. It's really cool because it's also, most of them are people that I met during the pandemic. So we've played predominantly online and this is the way we've gotten to know each other. We've become really close in the year, or so since we started playing together through the game that I DM and through the game that one other person in the group DMs and it's cool. It's definitely a way to kind of transcend the boundaries of Zoom and of video calls in general. DAVE: Hmm. ARTY: How did you end up getting into that? EMILY: It was just a friend group in high school. Someone said, “Hey, I would like to run a Dungeon and Dragons game. Do you want to play?” And I said, “Oh, what's that?” I've always loved books and reading so it was kind of a natural progression to go from reading a story to making a story collaboratively with other people. So that just immediately, I had a connection with it and I loved the game and that's been a huge part of my hobbies and my outside of tech life ever since. DAVE: Yeah. I played D&D as a kid in the late 70s, early 80s, but my mom took all my stuff away from me when that Tom Hanks movie came out that started the whole Satan panic thing. So I didn't play for a long time until my own kids were interested after getting hooked on Magic. Seeing my own kids interested in D&D, the story building, the writing, the math that they had to do, like I don't know why any parent wouldn't encourage their kids to play this game. It's just phenomenal. The collaborative, creative, sharing, math; it's got everything. EMILY: Yeah. I'm an introverted person so it takes a lot to make me feel motivated to be in a group with other people consistently, but D&D does that and it does it in a way that's not, I guess, prohibitive to people who are naturally shy. Because you're pretending to be someone else and you're not necessarily having to totally be yourself and you're able to explore the world through a lens that you find comfortable. DAVE: That's really cool. EMILY: I guess, also, it kind of goes back to our conversation about teaching. Being a DM, a lot of my players are people who have not played before, or very, very new. Like, maybe they've read a lot about it, maybe they've watched them [43:18] shows, but they maybe haven't necessarily played. D&D does require a lot of math and there's a lot of optimization, like you can get very into the weeds with your character sheet trying to make the most efficient battle machine, whatever and that's not really always approachable. Especially when I started introducing my younger siblings to D&D, I used versions, D&D like games that were similar, but not quite D&D. Like less math, a very similar amplified character sheets so you're looking at fewer numbers, or fewer calculations involved just to kind of get the essence, because there's a few core concepts in D&D. You have six statistics about your character that they change a little bit between different types of role-playing games, but they're pretty universal, I think for the most part. It's constitution, strength, dexterity, wisdom, intelligence, and charisma. Once you kind of nail those concepts down and once a person understands what those skills are supposed to mean, that really opens the gates to understanding a lot more about the core mechanics of D&D outside of the spell casting stuff and all the other math that's involved. I think just simplifying the game down to that makes them fall in love with the narrative and collaborative aspect of the game, and then be more motivated to figure out the math, if they weren't already predisposed to that. DAVE: So if somebody were interested in picking up a game trying to figure it out, where would they start? EMILY: It really to depends on the age group. If you're going to play with high school students, I would definitely say if none of you have played before, then pick up a player's handbook, maybe a dungeon master's guide if you're going to DM, you've never DM before because it gives a lot of tips for just dealing with the problems that arise in a collaborative storytelling game. And then probably just a prewritten module so you don't have to worry about building your own story, because these modules are stories that are written by professional game developers and you can take pieces of them and iterate it on yourself so you don't have to start with nothing. But if you are going for a much younger audience, I can't remember off the top of my head what it was, but it's essentially an animal adventure game. It's very much D&D without using the word D&D because I think it's a different company, it's copyrighted, and whatnot. But you have these little cute dog characters and they're trying to defeat an evil animal overlord who wants to ruin the town festival. It's very family friendly, like there's no death like there is in regular D&D and it's just a chance to engage with the character creation aspect of it. MANDY: That's really cool. So we're about heading towards our time, but I really appreciate you coming on the show, Emily and I wanted to just ask you, if you could give any advice to young girls looking to get into tech, or software engineering, what advice would you give them? EMILY: I think don't be afraid to walk off the path. A lot of my life has been kind of bucking the prewritten path that a lot of people are told is the best one because it didn't work for me, or whatever reason, and I think it's important just to not be afraid of that and to be courageous in making your own path. MANDY: That's great advice. So should we head into reflections, everyone? Who wants to start us off? DAVE: I'll start with one. I mentioned that when asked Emily about her path into college, that I was interested in a similar path for my own kids. I had a really strange college path that I started out a music major, ended up a computer science major, and had a non-traditional path. I've always believed that college is what you make of it, not where you went. Where you went might help you get your first job, but from then on, it's networking, it's personality, it's how well you did the job. Talking to Emily about her path, just reinforces that to me and helps me plot a path for what I might have my own children do. I have triplet boys that are in 9th grade. So we're starting to think about that path and not only would a path through Virginia Community College save us a fortune, [laughs] it would also be a guaranteed admission into Virginia Tech, or one of the Virginia schools so it's definitely something worth to consider. So I appreciate that knowledge, Emily. ARTY: I've been thinking a lot about how we can better teach people that don't have a lot of experience yet. We've got so much stuff going on in this field of software engineering and it's really easy to not realize how far that this plateau of knowledge that we live in and work with every day to do our jobs, and how important it is to bring up new folks that are trying to learn. One of the things you said, Emily was about teaching is being able to find those shared things where we've got a common understanding about something—you used metaphor of male delivery to talk about IP addresses, for example. But to be thinking in those ways of how do we find something shared and be able to get more involved with mentoring, reaching back, and helping support people to learn because software is super cool. It really is! We can build amazing, amazing things. It'd be awesome if more of us were able to get involved and have that experience and having good mentors, having good role models, all of those things make a big difference. MANDY: I just love the conversation that we had about men and women in technology and for me, I love to reiterate the fact that empowered women empower women and I even want to take that a step further by saying especially right now in our field, empowered men also empower women. So I think that that's something that really needs to be said and heard and not perceived as like Dave said oh, he felt like the creepy guy encouraging girls, or women to get involved in tech. I think it's cool. Dave has personally, he's mentored me. He's gotten me more interested. I used to do assistant work and now I'm learning programming and it's because I've been encouraged to do so by a lot of different men in the industry that I've been lucky to know. DAVE: Well, thank you, Mandy. You certainly have a who's who of mentors. MANDY: I am very, very lucky to know the people I know. DAVE: I'm quite honored to even be named on that list of people you know. [laughter] EMILY: I think the thought I keep coming back to is one that I've mentioned, but didn't really crystallize in my head until this morning when I was preparing for this recording is, I listened to David's interview and I thought about like, “Oh wow, he did really well on the podcast, all these things that I wish I did.” It really crystallized the idea that your mentor should be different from you and should have skills you don't, and you should seek them out for that reason. Mentors tend to be the people that I run into and I haven't really thought about it that way before, but that gives me a different perspective to go out and intentionally seek out those people. That definitely gives some food for thought for me. [laughs] MANDY: I love intentionally seeking out people who are different from myself in general, just to learn and get perspectives that I might have never even thought of before. But with that, I guess we will wrap up. Emily, it's been so nice having you on the show. Congratulations and best of luck on your exams. I know being – [overtalk] DAVE: I can't believe you took the time to do this with your exams coming up. MANDY: I know! EMILY: I'm procrastinating as hard as I can. [laughter] MANDY: But it's been so nice to have you on the show. Dave, thank you for coming and being a guest panelist and Arty, it's always wonderful to host with you. So I just wish everybody a happy new year and we'll see you next week! Special Guests: Dave Bock and Emily Haggard.

00:54 - Pariss' Superpower: Being Vocal and Transparent * #BlackTechTwitter (https://twitter.com/ParissAthena/status/1068873547005812737?s=20) * The Villian Origin Story * Deadpool (https://en.wikipedia.org/wiki/Deadpool_(film)) 08:01 - #BlackTechTwitter (https://twitter.com/ParissAthena/status/1068873547005812737?s=20) & Black Tech Pipeline (https://blacktechpipeline.com/) * Job Board (https://blacktechpipeline.com/jobs) * Labor Compensation 15:56 - Being Okay with Losing Opportunities * Announcing Success * Criticism & Privilege * The Great Resignation (https://en.wikipedia.org/wiki/Great_Resignation) * Generational Wealth (https://www.investopedia.com/generational-wealth-definition-5189580#:~:text=The%20term%20%E2%80%9Cgenerational%20wealth%E2%80%9D%20refers,real%20estate%20and%20family%20businesses.) * Hustle Culture * Hustle Culture: Why Is Everyone Working Too Hard? (https://medium.com/the-post-grad-survival-guide/hustle-culture-why-is-everyone-working-too-hard-69f9f5331ab5) 28:57 - UX Design vs Software Engineering (What would you do if you weren't in tech?) * Thinking About Vulnerable Communities * Coding For Work * Foley Artist (https://en.wikipedia.org/wiki/Foley_(filmmaking)); Working Behind the Scenes * Tech Supporting People's Real Passions 35:11 - Pariss' Passion for Acting & Being On Set * Behind-the-Scenes * Watching Marginalized People Succeed: “BE BOTHERED!” 43:38 - Growing & Evolving Community * @BotBlackTech (https://twitter.com/botblacktech?lang=en) * A Note to #BlackTechTwitter (https://twitter.com/ParissAthena/status/1068873547005812737?s=20)/Black Tech Pipeline (https://blacktechpipeline.com/) Potential Successors Reflections: Chanté: Being intentional about community. John: The impact an individual person can have on culture. Jamey: Be bothered. Ways that marginalized communities share some things and not other things. Tim: Having these discussions because people who are not Black do not understand the Black experience; Making sure the Black experience is changed for the better moving forward. Pariss: Being an ally vs being a coconspirator. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: Coming Soon! Special Guest: Pariss Athena.

02:01 - Kat's Superpower: Terrible Puns! * Puns & ADHD; Divergent Thinking (https://en.wikipedia.org/wiki/Divergent_thinking) * Punching Down (https://www.urbandictionary.com/define.php?term=punching%20down) * Idioms (https://www.ef.edu/english-resources/english-idioms/) 08:07 - Security Awareness Education & Accessibility * Phishing * Unconscious Bias Training That Works (https://hbr.org/2021/09/unconscious-bias-training-that-works) * Psychological Safety * 239: Accessibility and Sexuality with Eli Holderness (https://www.greaterthancode.com/accessibility-and-sexuality) * Management Theory of Frederick Taylor (https://www.business.com/articles/management-theory-of-frederick-taylor/) * Building a Security Culture For Oh Sh*t Moments | Human Layer Security Summit (https://www.youtube.com/watch?time_continue=21&v=d2girBtrbCQ&feature=emb_logo) * Decision Fatigue 20:58 - Making the Safe Thing Easy * (in)Secure Development - Why some product teams are great and others aren't… (https://tldrsec.com/blog/insecure-development-why-some-product-teams-are-great-and-others-arent/) * The Swiss Cheese Model of Error Prevention (https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1298298/) 22:43 - Awareness; Security Motivation; Behavior and Culture (ABC) * AIDA: Awareness, Interest, Desire, Action (https://en.wikipedia.org/wiki/AIDA_(marketing)) * Inbound Marketing (https://www.hubspot.com/inbound-marketing) 33:34 - Dietary Accessibility; Harm Reduction and Threat Monitoring * Celiac Disease (https://celiac.org/about-celiac-disease/what-is-celiac-disease/) * A Beginner's Guide to a Low FODMAP Diet (https://www.benefiber.com/fiber-in-your-life/fiber-and-wellness/beginners-guide-to-low-fodmap-diet/?gclsrc=aw.ds&gclid=Cj0KCQiAnuGNBhCPARIsACbnLzqJkfl2XxxUQVSAGU96cmdVl5S7gn6GXnOQAHf-Sn0zEHvBBKINObUaAlOvEALw_wcB) * Casin (https://en.wikipedia.org/wiki/Casein) * DisInfoSec 2021: Kat Sweet - Dietary Accessibility in Tech Workplaces (https://www.youtube.com/watch?v=rG1DApAlcK4&feature=youtu.be) Reflections: John: Internal teams relating to other internal teams as a marketing issue. Casey: Phishing emails cause harm. Kat: AIDA: Awareness, Interest, Desire, Action (https://en.wikipedia.org/wiki/AIDA_(marketing)) Unconscious Bias Training That Works (https://hbr.org/2021/09/unconscious-bias-training-that-works) The Responsible Communication Style Guide (https://rcstyleguide.com/) This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: PRE-ROLL: Software is broken, but it can be fixed. Test Double's superpower is improving how the world builds software by building both great software and great teams. And you can help! Test Double is hiring empathetic senior software engineers and DevOps engineers. We work in Ruby, JavaScript, Elixir and a lot more. Test Double trusts developers with autonomy and flexibility at a remote, 100% employee-owned software consulting agency. Looking for more challenges? Enjoy lots of variety while working with the best teams in tech as a developer consultant at Test Double. Find out more and check out remote openings at link.testdouble.com/greater. That's link.testdouble.com/greater. JOHN: Welcome to Episode 263 of Greater Than Code. I'm John Sawers and I'm here with Casey Watts. CASEY: Hi, I'm Casey! And we're both here with our guest today, Kat Sweet. Hi, Kat. KAT: Hi, John! Hi, Casey! CASEY: Well, Kat Sweet is a security professional who specializes in security education and engagement. She currently works at HubSpot building out their employee security awareness program, and is also active in their disability ERG, Employee Resource Group. Since 2017, she has served on the staff of the security conference BSides Las Vegas, co-leading their lockpick village. Her other superpower is terrible puns, or, if they're printed on paper—she gave me this one—tearable puns. [laughter] KAT: Like written paper. CASEY: Anyway. Welcome, Kat. So glad to have you. KAT: Thanks! I'm happy to be here. CASEY: Let's kick it off with our question. What is your superpower and how did you acquire it? KAT: [chuckles] Well, as I was saying to both of y'all before this show started, I was thinking I'm going to do a really serious skillful superpower that makes me sound smart because that's what a lot of other people did in theirs. I don't know, something like I'm a connector, or I am good at crosspollination. Then I realized no, [chuckles] like it, or not, terrible puns are my actual superpower. [laughter] Might as well just embrace it. I think as far as where I acquired it, probably a mix of forces. Having a dad who was the king of dad puns certainly helped and actually, my dad's whole extended family is really into terrible puns as well. We have biweekly Zoom calls and they just turn into everyone telling bad jokes sometimes. [laughter] But I think it also probably helps that, I don't know, having ADHD, my brain hops around a lot and so, sometimes makes connections in weird places. Sometimes that happens with language and there were probably also some amount of influences just growing up, I don't know, listening to Weird Al, gets puns in his parodies. Oh, and Carlos from The Magic School Bus. CASEY: Mm hmm. Role models. I agree. Me too. [laughter] KAT: Indeed. So now I'm a pundit. CASEY: I got a pun counter going in my head. It just went ding! KAT: Ding! [laughter] CASEY: I never got – [overtalk] KAT: They've only gotten worse during the pandemic. CASEY: Oh! Ding! [laughter] Maybe we'll keep it up. We'll see. I never thought of the overlap of puns and ADHD. I wonder if there's any study showing if it does correlate. It sounds right. It sounds right to me. KAT: Yeah, that sounds like a thing. I have absolutely no idea, but I don't know, something to do with divergent thinking. CASEY: Yeah. JOHN: Yeah. I'm on board with that. CASEY: Sometimes I hang out in the channels on Slack that are like #puns, or #dadjokes. Are you in any of those? What's the first one that comes to mind for you, your pun community online? KAT: Oh yeah. So actually at work, I joined my current role in August and during the first week, aside from my regular team channels, I had three orders of business. I found the queer ERG Slack channel, I found the disability ERG Slack channel, and I found the dad jokes channel. [laughter] That was a couple of jobs ago when I worked at Duo Security. I've been told that some of them who are still there are still talking about my puns because we would get [laughs] pretty bad pun threads going in the Slack channels there. CASEY: What a good reputation. KAT: Good, bad, whatever. [laughs] CASEY: Yeah. KAT: I don't know. Decent as a form of humor that's safe for work goes, too because it's generally hard to, I guess, punch down with them other than the fact that everyone's getting punched with a really bad pun, but they're generally an equalizing force. [chuckles] CASEY: Yeah. I love that concept. Can you explain to our listeners, punching down? KAT: So this is now the Great British Bake Off and we're talking about bread. No, just kidding. [laughter] No, I think in humor a lot of times, sometimes people talk about punching up versus punching down in terms of who is actually in on the joke. When you're trying to be funny, are you poking fun at people who are more marginalized than you, or are you poking at the people with a ton of privilege? And I know it's not always an even concept because obviously, intersectionality is a thing and it's not just a – privilege isn't a linear thing. But generally, what comes to mind a lot is, I don't know, white comedians making fun of how Black people talk, or men comedians making rape jokes at women's expense, or something like that. Like who's actually being punched? [chuckles] CASEY: Yeah. KAT: Obviously, ideally, you don't want to punch anyone, but that whole concept of where's the humor directed and is it contributing to marginalization? CASEY: Right, right. And I guess puns aren't really punching at all. KAT: Yeah. CASEY: Ding! KAT: Ding! There goes the pun counter. Yeah, the only thing I have to mindful of, too is not over relying on them in my – my current role is in a very global company so even though all employees speak English to some extent, English isn't everyone's first language and there are going to be some things that fly over people's heads. So I don't want to use that exclusively as a way to connect with people. CASEY: Right, right. JOHN: Yeah. It is so specific to culture even, right. Because I would imagine even UK English would have a whole gray area where the puns may not land and vice versa. KAT: Oh, totally. Just humor in general is so different in every single culture. Yeah, it's really interesting. JOHN: Yeah, that reminds me. Actually, just today, I started becoming weirdly aware as I was typing something to one of my Indian colleagues and I'm not sure what triggered it, but I started being aware of all the idioms that I was using and what I was typing. I was like, “Well, this is what I would normally say to an American,” and I'm just like, “Wait, is this all going to come through?” I think that way might lead to madness, though if you start trying to analyze every idiom you use as you're speaking. But it was something that just suddenly popped into my mind that I'm going to try and keep being a little bit more aware of because there's so many ways to miss with communication when you rely on obscure idioms, or certain ways of saying things that aren't nearly as clear as they could be. [chuckles] KAT: Yeah, absolutely. I'm sure that's definitely a thing in all the corporate speak about doubling down, circling back, parking lots, and just all the clicking, all of those things. [laughter] But yeah, that's actually something that was on my run recently, too with revamping one of the general security awareness courses that everyone gets is that in the way we talk about how to look for a phishing – spot a phishing email. First of all, one of the things that at least they didn't do was say, “Oh, look for poor grammar, or misspelled words,” because that's automatically really exclusive to people whose first language isn't English, or people who have dyslexia. But I was also thinking we talk about things like subtle language cues in suspicious emails around a sense of urgency, like a request being made trying to prey on your emotion and I'm like, “How accessible is that, I guess, for people whose first language is English to try and spot a phishing email based on those kind of things?” Like how much – [chuckles] how much is too much to ask of…? Like opinions about phishing emails, or the phishing training anyway being too much to ask of people to some degree, but I don't know. There's so much subtlety in it that just is really easy for people to lose. JOHN: Yeah. I mean, I would imagine that even American English speakers – [overtalk] KAT: Yeah. JOHN: With a lot of experience still have trouble. Like actually, [chuckles] I just got apparently caught by one of them, the test phishing emails, but they notified me by sending me an email and saying, “You were phished, click here to go to the training.” And I'm like, “I'm not going to click on that!” [laughter] I just got phished! KAT: Yeah. JOHN: But I think my larger point is again, you're talking about so many subtleties of language and interpretations to try and tease these things out. I'm sure there are a lot of people with a range of non-typical neurologies where that sort of thing isn't going to be obvious, even if they are native English speakers. KAT: Exactly. Myself included having ADHD. [laughs] JOHN: Yeah. KAT: Yeah. It's been interesting trying to think through building out security awareness stuff in my current role and in past roles, and having ADHD and just thinking about how ADHD unfriendly a lot of the [laughs] traditional approaches are to all this. Even like you were just saying, “You got phished, take this training.” It seems like the wrong sequence of events because if you're trying to teach someone a concept, you need to not really delay the amount of time in between presenting somebody with a piece of information and giving them a chance to commit it to memory. ADHD-ers have less working memory than neurotypical people to begin with, but that concept goes for everyone. So when you're giving someone training that they might not actually use in practice for several more months until they potentially get phished again, then it becomes just information overload. So that's something that I think about. Another way that I see this playing out in phishing training in particular, but other security awareness stuff is motivation and reward because we have a less amount of intrinsic motivation. Something like, I don't know, motivation and reward system just works differently with people who have trouble hanging onto dopamine. ADHD-ers and other people's various executive dysfunction stuff. So when you're sitting through security training that's not engaging, that's not particular lead novel, or challenging, or of personal interest, or is going to have a very delayed sense of reward rather than something that immediately gratifying, there's going to be a limitation to how much people will actually learn, be engaged, and can actually be detrimental. So I definitely think about stuff like that. CASEY: That reminds me of a paper I read recently about—I said this on a previous episode, too. I guess, maybe I should find the paper, dig it up, and share. KAT: Cool. [laughter] CASEY: Oh, but it said, “Implicit bias awareness training doesn't work at all ever” was an original paper. No, that's not what it said of course, but that's how people read it and then a follow-up said, “No, boring! PowerPoint slide presentations that aren't interactive aren't interactive.” [laughter] “But the interactive ones are.” Surprise! KAT: Right. That's the thing. That's the thing. Yeah, and I think there's also just, I don't know. I remember when I was first getting into security, people were in offices more and security awareness posters were a big thing. Who is going to remember that? Who's going to need to know that they need to email security at when they're in the bathroom? [laughs] Stuff like that that's not particularly engaging nor particularly useful in the moment. But that DEI paper is an interesting one, too. I'll have to read that. CASEY: Do you have experience making some of these trainings more interactive and getting the quicker reward that's not delayed and what does that look like for something like phishing, or another example? KAT: It's a mixed bag and it's something that I'm still kind of – there's something that I'm figuring out just as we're scaling up because in past roles, mostly been in smaller companies. But one thing that I think people, who are building security awareness and security education content for employees, miss is the fact that there's a certain amount of baseline level of interaction and context that you can't really automate a way, especially for new hires. I know having just gone through process that onboarding weeks are always kind of information overload. But people are going to at least remember more, or be more engaged if they're getting some kind of actual human contact with somebody who they're going to be working with; they've got the face, they've got some context for who their security team is, what they do, and they won't just be clicking through a training that's got canned information that is no context to where they're working and really no narrative and nowhere for them to ask questions. Because I always get really interesting questions every time I give some kind of live security education stuff; people are curious. I think it's important that security education and engagement is really an enhancer to a security program. It can't be carrying all the weight of relationships between the security team and the rest of the company. You're going to get dividends by having ongoing positive relationships with your colleagues that aren't just contact the security team once a year during training. CASEY: And even John's email, like the sample test email, which I think is better than not doing it for sure. But that's like a ha ha got you. That's not really [chuckles] relationship building. Barely. You've got to already have the relationship for it to – [overtalk] KAT: No, it's not and that's – yeah. And that's why I think phishing campaigns are so tricky. I think they're required by some compliance frameworks and by cyber insurance frameworks. So some places just have to have them. You can't just say we're not going to run internal phishing campaigns, unfortunately, regardless of whether that's actually the right thing for businesses. But I think the angle should always be familiarizing people with how to report email like that to the security team and reinforcing psychological safety. Not making people feel judged, not making people feel bad, and also not making them sit through training if they get caught because that's not psychological safety either and it really doesn't pay attention to results. It's very interesting, I remember I listened to your episode with Eli Holderness and at some point, one of the hosts mentioned something about human factors and safety science on the evolving nature of how people management happens in the workplace. How there was this old model of humans being a problem to be managed, supervised, and well, just controlled and how the new view of organizational psychology and people management is more humans are your source of success so you need to enable their growth and build them up. I think a lot of security education approaches are kind of still stuck in that old model, almost. I've seen progress, but I think a lot of them have a lot of work to do in still being, even if they're not necessarily as antagonistic, or punitive, they still feel sometimes paternalistic. Humans are like, “If I hear the phrase, ‘Humans are the weakest link one more time,' I'm going to table flip.” First of all, humans are all the links, but also – [overtalk] JOHN: Yeah. KAT: It's saying like, we need to save humans, which are somehow the security team is not humans. We need to save humans from themselves because they're too incompetent to know what to do. So we need, yeah – which is a terrible attitude. CASEY: Yeah. KAT: And I think it misses the point that first of all, not everyone is going to become a security expert, or hypervigilant all the time and that's okay. But what we can do is focus on the good relationships, focus on making the training we have and need to do somewhat interactive and personal and contextual, and let go of the things you can't control. [chuckles] JOHN: Yeah, I think Taylorism is the name for that management style. I think it came around in the 40s and – [overtalk] KAT: Really? JOHN: Yeah, ruined a lot of lives. [laughs] Yeah, and I think your point about actually accepting the individual humanity of the people you're trying to influence and work with rather than as some sort of big amorphous group of fuckups, [laughs] for lack of a better word. Giving them some credit, giving them, like you said, something that's not punitive, somewhere where they don't get punished for their security lapses, or forgetting a thing, or clicking the link is going to be a lot more rewarding than, like you said, just making someone sit through training. Like for me, the training I want from whatever it was I clicked on is show me the email I clicked on, I will figure out how it tricked me and then I will learn. I don't need a whole – [overtalk] KAT: Yes. JOHN: 3 hours of video courses, or whatever. I will see the video, [chuckles] I will see the email, and that is a much more organic thing than here's the training for you. KAT: Exactly. Yeah, you have to again, give some people a way to actually commit it to memory. Get it out of RAM and into SSD. JOHN: Yeah. [laughter] KAT: But yeah, I love that and fortunately, I think some other places are starting to do interesting, innovative approaches. My former colleague, Kim Burton, who was the Security Education Lead at Duo when I was there and just moved to Texas, gave a webinar recently on doing the annuals security training as a choose your own adventure so that it could be replicated among a wide group of people, but that people could take various security education stuff that was specific to their own role and to their own threat model. I really liked that. I like being able to give people some amount of personalization and get them actually thinking about what they're specifically interacting with. JOHN: Yeah, yeah. That's great and it also makes me think about there are undoubtedly things I'm pretty well informed in security and other things that I'm completely ignorant about. I'd rather not sit through a training that covers both of those things. Like if there's a way for me to choose my own adventure through it so that I go to the parts where I'm actually learning useful things. Again, a, it saves everybody time and b, it means I'm not fast forwarding through the video, hoping it'll just end, and then possibly missing things that are actually useful to me. CASEY: I'm thinking of a concrete example, I always remember and think of and that's links and emails. I always hover and look at the URL except when I'm on my phone and you can't do that. Oh, I don't know. It has never come up in a training I've seen. KAT: Yeah, you can click and hold, but it's harder and I think that speaks to the fact that security teams should lead into putting protections around email security more so than relying entirely on their user base to hover every single link, or click and hold on their phone, or just do nothing when it comes to reporting suspicious emails. There's a lot of decision fatigue that, I think security teams still put on people whose job is not security and I hope that that continues to shift over time. JOHN: Yeah. I mean, you're bringing up the talking about management and safety theory that probably came from Rein Henrichs, who is one of our other hosts. But one of the things he also has talked about on, I think probably multiple shows is about setting the environment for the people that makes the safe thing easy. KAT: Right. JOHN: So that all the defaults roll downhill into safety and security rather than well, here's a level playing field you have to navigate yourself through and there's some potholes and da, da, da, and you have to be aware of them and constantly on alert and all those things. Whereas, if you tilt the field a little bit, you make sure everything runs in the right direction, then the right thing becomes the easy thing and then you win. KAT: Exactly, exactly. I think it's important to put that not only in the technical defaults – [overtalk] JOHN: Yeah, yeah. KAT: But also process defaults to some degree. One of my colleagues just showed me a talk that was, I think from perhaps at AppSec Cali. I'll have to dig it up. But there was somebody talking about making I guess, threat modeling and anti-abuse mindsets more of a default in product development teams and how they added one single line to their sprint planning—how could this feature potentially be misused by a user—and that alone just got people thinking just that little process change. JOHN: Yeah. That's beautiful. But such a small thing, but constantly repeated at a low level. It's not yelling at anyone to… KAT: Yeah. JOHN: Yeah. KAT: Yeah. And even if the developers and product designers themselves weren't security experts, or anti-abuse experts, it would just get them thinking, “Oh hey, we should reach out to the trust and safety team.” CASEY: Yeah. I'm thinking about so many steps and so many of these steps could be hard. The next one here is the security team responsive and that has a lot to do with are they well-staffed and is this a priority for them? Oh my goodness. KAT: Yeah. [laughs] So many things. CASEY: It's layers. But I'm sure you've heard of this, Kat. The Swiss cheese model of error prevention? KAT: Yeah. Defense in depth. CASEY: Yeah. [chuckles] I like to bring it up on the podcast, too because a lot of engineers and a lot of non-security people don't know about it. KAT: Hmm. CASEY: Do you want to explain it? I don't mind. I can. KAT: Oh, yeah. Basically that there are going to be holes in every step of the process, or the tech and so, that's why it's important to have this layered approach. Because over time, even if something gets through the first set of holes, it may not get through a second set where the holes are in different spots. So you end up with a giant stack of Swiss cheese, which is delicious, and you come out with something that's hopefully pretty same. [laughter] CASEY: Yeah, and it's the layers that are – the mind-blowing thing here is that there can be more than one layer. We don't just need one layer of Swiss cheese on this sandwich, which is everybody pay attention and don't ever get phished, or it's your fault. You can have so many layers than that. It can be like a grilled cheese, really, really thick, grilled cheese. [laughter] KAT: Yes. A grilled cheese where the bread is also cheese. CASEY: Yes! [laughs] MID-ROLL: This episode is supported by Compiler, an original podcast from Red Hat discussing tech topics big, small, and strange. Compiler unravels industry topics, trends, and the things you've always wanted to know about tech, through interviews with the people who know it best. On their show, you will hear a chorus of perspectives from the diverse communities behind the code. Compiler brings together a curious team of Red Hatters to tackle big questions in tech like, what is technical debt? What are tech hiring managers actually looking for? And do you have to know how to code to get started in open source? I checked out the “Should Managers Code?” episode of Compiler, and I thought it was interesting how the hosts spoke with Red Hatters who are vocal about what role, if any, that managers should have in code bases—and why they often fight to keep their hands on keys for as long as they can. Listen to Compiler on Apple Podcasts, or anywhere you listen to podcasts. We'll also include a link in the show notes. Our thanks to Compiler for their support. CASEY: Earlier, you mentioned awareness, Kat as something interesting. You want to talk about awareness more as a term and how it relates to this? KAT: Oh, yeah. So I – and technically, my job title has security awareness in it, but the more I've worked in the security space doing employee security education stuff as part of all my job. I know language isn't perfect, but I'm kind of the mindset that awareness isn't a good capture of what a role like mine actually should be doing because awareness without behavior change, or action is just noise. It's just we're all very aware of things, but if we don't have an environment that's friendly to us putting that awareness into some kind of action, or engagement, or response, we are just aware and scared. [laughs] CASEY: Yeah, awareness alone just makes us feel bad. We need more than that. KAT: Yeah. So I think security awareness is sometimes just a product of a term that got standardized over several years as it's in all of the compliance control frameworks, security awareness is a part of it. I don't know it's the best practice thing. I hope over time it will continue to evolve. CASEY: Yeah. KAT: As with any other kind of domains. JOHN: Yeah. I think that maybe security motivation might be a better term for it. KAT: I've seen a bunch of different ones used. So I end up speaking in terms of, I don't know, security education and engagement is what I'm working on. Security culture is my vision. I've seen things like security awareness, behavior, and culture, ABC, things like that. But all this to say security awareness not being in a vacuum. CASEY: I like those. This reminds me of a framework I've been thinking about a lot and I use in some of my DEI workshops. AIDA is an acronym. A-I-D-A. The first one's Awareness, the last one is Action, and in the middle is Interest and Desire. KAT: Nice. CASEY: So the questions I use to frame is like, are they aware of, for example, if they're misgendering someone? That's the context I'm using this in a lot. Are they aware of this person's pronouns in the first place? Are they interested in caring about this person and do they want to do anything about it and did they do it? Did they use their proper pronouns? Did they correct their actions? It's like 4 stages – [overtalk] KAT: I like that. CASEY: AIDA. It's used in marketing a lot for like a sales funnel, but I apply it to all sorts of how do you get someone from aware to action? KAT: I like that a lot. It's been interesting working at a place that makes a product that's more in the sales and marketing space. Definitely learned a lot because a couple of previous roles I've had been with security vendors. I think one of the interesting ideas that was a new concept to me when I started was this idea of inbound marketing, where instead of just cold contacting people and telling them, “Be interested in us, be interested in us, buy our stuff,” you generate this reputation as being of good service by putting out useful free nuggets of content, like blog posts, webinars, and things. Then you get people who are interested based on them knowing that you've got this, that you offer a good perspective, and then they all their friend. They are satisfied customers, and they go promote it to people. I think about this as it applies to security teams and the services they provide, because even though corporate security teams are internal, they've still got internal customers. They've still got services that they provide for people. So by making sure that the security team is visible, accessible, and that the good services that they provide are known and you've got satisfied customers, they become promoters to the rest of their teams. Think about like security can definitely learn a lot from [chuckles] these sales and marketing models. CASEY: I can totally imagine the security team being the fun team, the one you want to go work with and do workshops with because they make it so engaging and you want to. You can afford to spend your time on this thing. [laughter] KAT: Oh yes. CASEY: You might do it. [laughter] JOHN: Yeah, and I think marketing's a great model for that. Marketing sort of has a bad reputation, I think amongst a lot of people because it's done badly and evilly by a lot of people. But it's certainly possible and I think inbound market is one of those ways that you're engaging, you're spreading awareness, you're letting people select themselves into your service, and bring their interest to you. If you can develop that kind of rapport with the employees at your company as a security team, everybody wins. KAT: Yeah, absolutely, and it can absolutely be done. When I was working at Duo a couple jobs ago, I was on their security operations team and we were responsible, among other things, for both, the employee security education and being the point of intake; being the people that our colleagues would reach out to with security concerns to security and it definitely could see those relationships pay off by being visible and being of good service. CASEY: So now I'm getting my product manager hat on, like team management. KAT: Yeah. CASEY: I will want to choose the right metrics for a security team that incentivizes letting this marketing kind of approach happen and being the fun team people want to reach out to have the bigger impact and probably the highest metric is like nobody gets a security breach. But that can't be the only one because maybe you'll have a lucky year and maybe you'll have an unlucky that's not the best one. What other metrics are you thinking of? KAT: That's the thing, there's a lot more that goes into not getting pwned than how aware of security people are. There's just way too many factors to that. But – [overtalk] CASEY: Yeah. I guess, I'm especially interested in the human ones, like how come – [overtalk] KAT: Oh, yeah. And I mean like – [overtalk] CASEY: The department allowed to do the things that would be effective, like incentivized and measured in a sense. KAT: Yeah, and I think a lot of security education metrics often have a bit of a longer tail, but I think about not – I don't really care so much about the click rates for internal phishing campaigns, because again, anyone can fall for a phish if it's crafted correctly enough. If it's subtle enough, or if just somebody's distracted, or having a bad day, which we never have. It's not like there's a pandemic, or anything. But for things that are sort of numbers wise, I think about how much are people engaging with security teams not just in terms of reporting suspicious emails, but how often are they reporting ones that aren't a phishing simulation? How much are they working with security teams when they're building new features and what's the impact of that baseline level before there's, I don't know, formal process for security reviews, code reviews, threat modeling stuff in place? What does that story look like over time for the product and for product security? So I think there's quite a bit of narrative data involved in security education metrics. JOHN: Yeah. I mean you could look at inbound interests, like how often are you consulted out of the blue by another team, or even of the materials you've produced, what's the engagement rates on that? I think that's a lower quality one, but I think inbound interest would be fantastic. CASEY: Yeah. KAT: Yeah, exactly. I was thinking to some degree about well, what kinds of vulnerabilities are you shipping in your code? Because I think there's never 100% secure code. But I think if you catch some of the low-hanging fruits earlier on, then sometimes you get an interesting picture of like, okay, security is being infused into the SDLC at all of these various Swiss cheese checkpoints. So think about that to some degree and that's often more of a process thing than a purely an education thing, but getting an education is an enhancer to all of these other parts of the security programs. JOHN: So in the topics for the show that you had suggested to us, one of the things that stood out to me was something you called dietary accessibility. So can you tell me a little bit more about what that means? KAT: So earlier in this year, in the middle of all of this pandemic ridiculousness, I got diagnosed with celiac disease. Fortunately, I guess, if there was a time to be diagnosed with that, it's I'm working remotely and nobody's going out to eat really. Oh, I should back up. I think a lot of people know what it is, but just in case, it's an autoimmune disorder where my body attacks itself when I eat gluten. I've described it in the past as my body thinks that gluten is a nation state adversary named fancy beer. [laughter] Ding, one more for the pun counter. I don't know how many we're up to now. [laughs] CASEY: I have a random story about a diet I had to do for a while for my health. I have irritable bowel syndrome in my family and that means we have to follow over really strict diet called the low FODMAP diet. If your tummy hurts a lot, it's something you might look into because it's underdiagnosed. That meant I couldn't have wheat, but not because I had celiac disease; I was not allergic to the protein in wheat flour. I was intolerant to the starch and wheat flour. So it would bother me a lot. People said, “Do you have celiac, or?” And I was like, “No, but I cannot have wheat because the doctor told me so, but no, it's not an allergy.” I don't know, my logical brain did not like that question. [laughter] That was an invalid question. No, it's not a preference. I prefer to eat bread, but I cannot, or it hurts my body according to my doctor. KAT: [chuckles] So you can't have the starch and I can't have the protein. So together, we can just – [overtalk] CASEY: Separate it! KAT: Split all of the wheat molecules in the world and eat that. [laughs] CASEY: That's fair. I literally made gluten-free bread with gluten. [laughs] I got all the gluten-free starches and then the gluten from the wheat and I didn't have the starch in the wheat and it did not upset my stomach. KAT: Oh man. JOHN: Yeah. I've got a dairy sensitivity, but it's not lactose. It's casein so it's the protein in the dairy. CASEY: Protein, uh huh. KAT: Oh, interesting. CASEY: I apologize on behalf of all the Casey. [laughter] Casey in. KAT: Who let Casey in? CASEY: Ding! KAT: Ding! No, but it's made me think a lot about as I was – first of all, it's just I didn't fully appreciate until I was going through it firsthand, the amount of cognitive overload that just goes into living with it every day. [laughs] Speaking of constant state of hypervigilance, it took a while for that to make it through – I don't know, me to operationalize to my new life that's going to be my reality for the [laughs] rest of my life now because it was just like, “Oh, can I eat this? Can I eat that?” All of that. Something that at least helped ease me out of this initial overwhelm and grieving period was tying some of the stuff that I was dealing with back to how would I do this in my – how would I approach this if this were a security education and security awareness kind of thing? CASEY: Oh, yeah. KAT: Because it's a new concept and it's a thing that is unfamiliar and not everyone is an expert in it. so I'm like, “How would I treat myself as the person who's not an expert in it yet?” I, again, tried to get myself back to some of those same concepts of okay, let's not get stuck in thud mode, let's think about what are some of the actual facts versus what's scaremongering. I don't need to know how much my risk of colon cancer is increased, because that's not how helpful for me to actually be able to go about my day. I need to know what are the gluten-free brands of chips? That's critical infrastructure. CASEY: I love this parallel. This is so cool. KAT: And so I thought about to – I've mentioned earlier, decision fatigue as a security issue. I thought about how can I reduce the decision fatigue and not get stuck just reading all the labels on foods and stuff? What are the shortcuts I can take? Some of those were like okay, let me learn to recognize the labels of what the labels mean of a certified gluten-free logo and also just eat a lot of things that would never have touch gluten to begin with, like plain and raw meat, plain potatoes, plain vegetables, things like that. So just anything to take the cognitive load down a little bit, because it was never going to be zero. It's interesting. Sometimes, I don't know, I have tons of different interests and I've always interested in people's perspective outside of security. A lot of that stuff influences the way I think about security, but sometimes the way I think about security also ends up influencing other stuff in my life, so. CASEY: Yeah. I think that's brilliant. Use – [overtalk] KAT: And interesting to connect with those. CASEY: The patterns and you're comfortable with, and apply them. KAT: Exactly. CASEY: A lot of really cool ideas come from technology. KAT: Yeah, and go for harm reduction, not nothing because we don't live in a gluten-free world. It's like I can try to make myself as safe as possible, but at some point, my gut may suffer a data breach and [laughs] when I do, should be blameless and just work on getting myself recovered and trying – [overtalk] JOHN: Yeah. I mean, thinking about it as a threat model. There's this gluten out there and some of it's obvious, some of it's not obvious. What am I putting in place so that I get that 95th percentile, or whatever it is that you can think of it that way? I like that. KAT: Exactly. It's an interesting tie to threat modeling how the same people – even if people have the same thing that they can't eat, they may still have a different threat model. They may, like how we both had to avoid wheat, but for different reasons and with different side effects, if we eat it and things like that. CASEY: I love these parallels. I imagine you went into some of these in that talk at DisInfoSec. Is that right? KAT: Yeah. A little bit. So DisInfoSec, it's a virtual conference in its second year of existence, specifically highlighting disabled speakers in the InfoSec community run by Kim Crawley, who's a blogger for Hack the Box. There was a really interesting lineup of talks this year. Some people, I think about half of them touched on neurodiversity and various aspects of security through lenses of being autistic and ADHD, which is really cool. For mine, I focused on those of us who have disability-related dietary restrictions and how that affects our life in the tech workplace, where compared to a lot of other places I've worked, there's a lot of free food on the company dime hanging around and there's a lot of use of food as a way to build connection and build community. CASEY: Yeah, and a lot of stuff, a lot of people can't eat. I'm with you, uh huh. KAT: Yeah. I just took stock of all of the times that I would take people up for lunch interviews, go out to dinner with colleagues when they're in town, all of these things. Like snacks in the office. Just there not being a bathroom on the same floor as me for multiple jobs where I worked. [laughs] Things like that. So I really wanted to – the thing that I wanted to highlight in that talk in general was systemic level accommodations to be made for people with be they celiac IBS, food allergies, diabetes rather than relying on people individually requesting accommodations. This universal design model where you've got to make sure that your workplace is by default set up to accommodate people with a wide range of disabilities including dietary needs and a lot of times it doesn't come down to even feeding them. It comes down to making sure their health insurance is good, making sure people can work remotely, making sure that – [overtalk] CASEY: Higher levels of Swiss cheese on that. They are various levels. KAT: Yeah, the levels of Swiss cheese. A lot of stuff cascades from lunch interviews, making sure that if you do them at all, that you're really flexible about them. JOHN: Yeah. I can definitely relate to the being able to work from home, which I've done for the last decade, or more, has been huge for being able to have a solid control of my diet. Because it's really easy to have all the right things around for lunch rather than oh, I've only got half an hour, I can run out to the sub shop and I'll just deal with the consequences. Because that's what's nearby versus, or trying to bring food into the office and keep it in the fridge, or the free – that's a whole mess. So just like you said, good health insurance, working from home, these are things that allow for all sorts of different disabilities to be taken care of so well that you don't – that's the base, that's table stakes to formatting kind of inclusion. KAT: Exactly, exactly. CASEY: Yeah. KAT: Exactly. Yeah, and I think what sometimes gets missed is that even there are other things that I need to – the ability to just sometimes lay down, the ability to be close to a bathroom, and things that are not food related, but definitely are my reality. [laughs] CASEY: And companies went out, too. By accommodating you, they get all of your expertise and skills and puns. In exchange for flexibility, they get puns. KAT: [laughs] And I still make puns about gluten, wheat, rye, and barley even though I can I eat them anymore. That will never go away. CASEY: They just keep rising. KAT: Wheat for it. Wait for it. [laughter] CASEY: Ding! KAT: That's just my wry sense of humor. CASEY: All right. We're getting near end of time for today. This point, let's talk about reflections and plugs. JOHN: I can go first. I think the thing that's definitely sticking with me is thinking about the internal teams relating to other internal teams at a company as a marketing issue. Security is obviously one where you need to have that relationship with pretty much every team. But I'm thinking all sorts of all the way around development, DevOps, tech QA. Everyone can think this way and probably gain something from it as a what are we presenting to the rest of the company, what is our interface, and how do we bring more things to it such that people like working with our interface a lot so that we have great relationships with the rest of the team? I think I'm going to keep thinking about that for a while. CASEY: I'll share a reflection. I liked noticing that those phish emails can cause harm to people—they can feel bad and then make them less receptive. I've always been a fan of them overall. But thinking about that impact, I might have even been the one to say that, but it was still surprising to me when that came out of my mouth. Say, oh yeah, it hurts people in a way, too. We don't have to have that painful experience to teach people. It can be done in a safer environment. I wonder what else we can do for training of things like that to make it more positive and less negative. I'm going to be thinking on that. KAT: Yeah. And I wrote down AIDA. Awareness, Interest, Desire, and Action. Did I get that right? CASEY: Yeah. KAT: I'm definitely going to look into that. I think that's a great model for education of all kinds. CASEY: Yeah. If you want to go even deeper, there's like 6 and 7 tier models on the Wikipedia page links to a bunch of them. That's just the most common. KAT: Awesome. CASEY: For plugs, I just want to plug some homework for you all. Everyone listening, there's this Unconscious Bias Training That Works article that I've mentioned twice now. I hope you get to read that. And I guess, the AIDA – It'll be in the show notes for sure. And then the Wikipedia page for AIDA marketing just so you have a spot to look it up, if you forget about it. Try to apply that to situations, that's your homework. KAT: I think something I plugged on Twitter quite a bit over the years and a lot when we were talking about the language that we use earlier, I'm a huge fan of the Responsible Communication Style Guide, which was put out by the Recompiler, which is a feminist activist hacker publication. So they've got guides on words to avoid, words to use instead for when talking about race, gender, class, health, disability status. It's written for a tech audience and I really like that as a resource for using inclusive language. JOHN: Yeah. It's great stuff. CASEY: I love it. All right, thanks so much for are coming on our show today, Kat. Special Guest: Kat Sweet.

00:59 - Evans's Superpower: Talking about topics that aren't interesting to whomever he's talking to at the time * ADHD (https://www.cdc.gov/ncbddd/adhd/facts.html) * Diagnosing as an Adult * Adult ADHD Self-Report Scale (https://addadult.com/wp-content/uploads/2014/02/ASRS-v1.1_Form.jpg) * QbCheck: ADHD Self-Check Test (https://www.qbcheck.com/) * Why seek a medical diagnosis? * Almost everything that you know about “Attention Deficit Hyperactivity Disorder” is probably wrong (https://elight.medium.com/almost-everything-that-you-know-about-attention-deficit-hyperactivity-disorder-is-probably-wrong-b2127d9fc28a?source=linkShare-a8240757c989-1638906006&_branch_match_id=801116751921979067&_branch_referrer=H4sIAAAAAAAAA8soKSkottLXz8nMy9bLTU3JLM3VS87P1U%2FJsUxxd3by9stJAgBTm%2FDPIwAAAA%3D%3D) * Vulnerability 12:45 - Debugging Oneself, Neuroscience, Meditation * Debugging Your Brain by Casey Watts (https://www.debuggingyourbrain.com/) * CBT - Cognitive Behavioral Therapy (https://www.apa.org/ptsd-guideline/patients-and-families/cognitive-behavioral) * MBCBT - Mindfulness-Based Cognitive Behavioral Therapy (https://en.wikipedia.org/wiki/Mindfulness-based_cognitive_therapy) * Search Inside Yourself Program (https://siyli.org/search-inside-yourself/?gclid=Cj0KCQiAqbyNBhC2ARIsALDwAsCp4R7sA2xVnxOknPLb8QIPyEshgY1P_frUWrqLIyWREgJz-a3Quu4aAgt3EALw_wcB) * Neuroplasticity (https://en.wikipedia.org/wiki/Neuroplasticity) 21:57 - The Limitations of Science 24:54 - The Spiritual Side, Mindfulness, and Meditation * Buddhism (https://en.wikipedia.org/wiki/Buddhism) * Aikido (https://en.wikipedia.org/wiki/Aikido) * Ki Society (https://ki-society.com/) * Siddhartha by Hermann Hesse (https://www.gutenberg.org/ebooks/2500) * Zencasts (http://www.zencast.org/) * AudioDharma (https://www.audiodharma.org/) * Secular Buddhism (https://en.wikipedia.org/wiki/Secular_Buddhism) 32:03 - Psychological Safety * Groupthink (https://en.wikipedia.org/wiki/Groupthink) & Human Dynamics and Teams * Welcomed Disagreement * Vulnerability & Accountability * Unconscious Bias * Resmaa Menakem: My Grandmother's Hands: Racialized Trauma and the Pathway to Mending Our Hearts and Bodies (https://www.amazon.com/My-Grandmothers-Hands-Racialized-Pathway/dp/1942094477) 49:28 - Faith and Science * Exploring Areas of Disagreement * Truth * Disagreement and Conflict * Radical Candor (https://www.radicalcandor.com/) * Nonviolent Communication (https://www.amazon.com/Nonviolent-Communication-Language-Life-Changing-Relationships/dp/189200528X) * Acetaminophen Reduces Social Pain: Behavioral and Neural Evidence (https://journals.sagepub.com/doi/abs/10.1177/0956797610374741) 01:04:08 - Words! * Think, Know, and Believe; Hope, Want, and Intend: Are these words unique? * Greater Than Code Twitter Poll Results! (https://twitter.com/heycaseywattsup/status/1467242254783942659) * Replacement Words For “Normal”, “Guys” Reflections: Damien: The value of being vulnerable. Evan: Disagreement leading to deeper discussion. Cultivating more empathy. Casey: We can't usually know what is true, but we can know when something's false. Mae: Think about the ways you are biased and have healing to do. Talking about ways we are not awesome to each other will help us actually be awesome to each other. Search Inside Yourself Leadership Institute (https://siyli.org/) Greater Than Code Episode 248: Developing Team Culture with Andrew Dunkman (https://www.greaterthancode.com/devloping-team-culture) Happy and Effective (https://www.happyandeffective.com/) Siddhartha by Hermann Hesse (https://www.gutenberg.org/ebooks/2500) Nonviolent Communication (https://www.amazon.com/Nonviolent-Communication-Language-Life-Changing-Relationships/dp/189200528X) Conversations For Action (https://conversationsforaction.com/) This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: Coming Soon! Special Guest: Evan Light.

Catch Dave on Episode 006 of Greater Than Code! Getting Technology Into the Hands of Children with David Bock (https://www.greaterthancode.com/getting-technology-into-the-hands-of-children) 02:10 - Dave's Superpower: Ability to Reevaluate and Drop Ideas – Onto The Next! * Star Trek: The Next Generation (https://en.wikipedia.org/wiki/Star_Trek:_The_Next_Generation) * Impostor Syndrome (https://en.wikipedia.org/wiki/Impostor_syndrome) 07:10 - The Acceptance of Ruby; Using Ruby as a Teaching Language * Teaching Ruby Makes Approaching Computer Science Approachable * Intro To Programming Skill Tree.md (https://gist.github.com/caseywatts/93cba34cd882a05b3107) * Computational Thinking (https://en.wikipedia.org/wiki/Computational_thinking) * Object-Oriented Programming (https://en.wikipedia.org/wiki/Object-oriented_programming) * Functional Programming (https://en.wikipedia.org/wiki/Functional_programming#:~:text=In%20computer%20science%2C%20functional%20programming,by%20applying%20and%20composing%20functions.&text=When%20a%20pure%20function%20is,state%20or%20other%20side%20effects.) * Primer on Python Decorators (https://realpython.com/primer-on-python-decorators/) 18:01 - Mobile Development * Accessibility * FingerWorks (https://en.wikipedia.org/wiki/FingerWorks) * Teaching Performance; Linear Algebra (https://en.wikipedia.org/wiki/Linear_algebra) * Star 26 Math Puzzle (https://www.puzzlemaster.ca/browse/wood/otherwood/12292-star-26-math-puzzle) * Aristotle Number Puzzle (https://www.amazon.com/s?k=aristottles+number+puzzle&ref=nb_sb_noss_2) 24:10 - Teaching Remotely * WatchDOG Dads (https://www.pickerington.k12.oh.us/violet-elementary/watch-dog-dads/) * Cameras On/Off * % of Women Went Up / Gatekeeping and Gender Bias * Grace Hopper (https://en.wikipedia.org/wiki/Grace_Hopper) 34:25 - Computer Science Education Week (https://www.csedweek.org/) + Teaching/Volunteering * Hour of Code (https://hourofcode.com/) * Code.org (https://code.org/) * Scratch (https://scratch.mit.edu/) “Computers aren't smart. They're just dumb really, really fast.” Understanding the Pareto Principle (The 80/20 Rule) (https://betterexplained.com/articles/understanding-the-pareto-principle-the-8020-rule/) Zero: The Biography of a Dangerous Idea (https://www.amazon.com/Zero-Biography-Dangerous-Charles-Seife/dp/0140296476) Plimpton 322 (https://en.wikipedia.org/wiki/Plimpton_322) 56:39 - Handling Time Management and Energy * Ted Lasso (https://en.wikipedia.org/wiki/Ted_Lasso) * Getting Positive by Looking at the Negative Reflections: Casey: Motivating students to learn algorithmic efficiency. Feeling the problem. Mae: Becoming more involved in the community. Chelsea: What are people in the tech world ready for? Dave: How much talking about computer science education is invigorating and revitalizing. Seeing problems through beginners' eyes. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Special Guest: Dave Bock.

01:01 - Ian's Superpower: Curiosity & Life-Long Learning * Discovering Computers * Sharing Knowledge 06:27 - Streaming and Mentorship: Becoming “The Career Development Guy” * The Turing School of Software and Design (https://turing.edu/) * techinterview.guide (https://techinterview.guide/) * twitch.tv/iandouglas736 (https://www.twitch.tv/iandouglas736) 12:01 - Tech Interviews (Are Broken) * techinterview.guide (https://techinterview.guide/) * Daily Email Series (https://techinterview.guide/daily-email-series/) * Tech vs Behavior Questions 16:43 - How do I even get a first job in the tech industry? * Tech Careers = Like Choose Your Own Adventure Book * Highlight What You Have: YOU ARE * Apply Anyway 24:25 - Interview Processes Don't Align with Skills Needed * FAANG Company (https://en.wikipedia.org/wiki/Big_Tech) Influence * LeetCode-Style Interviews (https://leetcode.com/explore/interview/card/top-interview-questions-medium/) * Dynamic Programing Problems (https://medium.com/techie-delight/top-10-dynamic-programming-problems-5da486eeb360) * People Can Learn 35:06 - Fixing Tech Interviews: Overhauling the Process * Idea: “Open Source Hiring Manifesto” Initiative * Analyzing Interviewing Experiences; Collect Antipatterns * Community/Candidate Input * Company Feedback (Stop Ghosting! Build Trust!) * Language Mapping Reflections: Mandy: Peoples' tech journeys are like a Choose Your Own Adventure book. Keep acquiring skills over life-long learning. Arty: The importance of 1-on-1 genuine connections. Real change happens in the context of a relationship. Ian: Having these discussions, collaborating, and saying, “what if?” This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: ARTY: Hi, everyone. Welcome to Episode 260 of Greater Than Code. I am Arty Starr and I'm here with my fabulous co-host, Mandy Moore. MANDY: Thank you, Arty. And I'm here with our guest today, Ian Douglas. Ian has been in the tech industry for over 25 years and suggested we cue the Jurassic Park theme song for his introduction. Much of his career has been spent in early startups planning out architecture and helping everywhere and anywhere like a “Swiss army knife” engineer. He's currently livestreaming twice a week around the topic of tech industry interview preparation, and loves being involved in developer education. Welcome to the show, Ian. IAN: Thanks for having me. It's great to be here. MANDY: Awesome. So we like to start the show with our famous question: what is your superpower and how did you acquire it? IAN: Probably curiosity. I've always been kind of a very curious mindset of wanting to know how things work. Even as a little kid, I would tear things apart just to see how something worked. My parents would be like, “Okay, great. Put it back together.” I'm like, “I don't know how to put it back together.” So [chuckles] they would come home and I would just have stuff disassembled all over the house and yeah, we threw a lot of stuff out that way. But it was just a curiosity of how things work around me and that led into computer programming, learning how computers worked and that just made the light bulb go off in my mind as a little kid of, I get to tell this computer how to do something, it's always going to do it. And that just led of course, into the tech industry where you sign up for a career in the tech industry, you're signing up for lifelong learning and there's no shortage of trying to satiate that curiosity. I think it's just a never-ending journey, which is fantastic. ARTY: When did you first discover computers? What was that experience like for you? IAN: I was 8 years old. I think it was summer, or fall of 1982. I believe my dad came home with a Commodore 64. My dad was always kind of a gadget nut. Anything new and interesting on the market, he would find an excuse to buy and so he, brought home this Commodore 64 thinking family computer, but once he plunked it down in front of me, it sort of became mine. I didn't want to share. I grew up in Northern Canada way, way up in the Northwest territories and in the wintertime, we had two things to do. We could go play hockey, or we'd stay indoors and not freeze. So I spent a lot of time indoors when I wasn't playing hockey—played a lot of hockey as a kid. But when I was home, I was basically on this Commodore 64 all the time, playing games and learning how the computer itself worked and learning how the programming language of it worked. Thankfully, the computer was something I had never took apart. Otherwise, it would have been a pile of junk, but just spending a lot of time just learning all the ins and outs. Back then, the idea was you could load the software and then you type a run command and it would actually execute the program. But if you type a list, it would actually show you all the source code of the program as well and that raised my curiosity, like what is all this symbols and what all these words mean? In the back of the Commodore 64 book, it had several chapters about the basic programming language. So I started picking apart all these games and trying to learn how they worked and then well, what would happen if I change this instruction to that and started learning how to sort of hack my games, usually break the game completely. But trying to hack it a little bit; what if I got like an extra ship, an extra level, or what if I change the health of my character, or something along those lines? And it kind of snowballed from there, honestly. It was just this fascination of, oh, cool, I get to look at this thing. I get to change it. I get to apply it. And then of course, back in the day, you would go to a bookstore and you'd have these magazines with just pages and pages and pages of source code and you'd go home and you type it all in expecting something really cool. At the end of it, you run it and it's something bland like, oh, you just made a spreadsheet application. It's like, “Oh, I wanted a game.” Like, “Shucks.” [laughter] But as a little kid, that kind of thing wasn't very enticing, but I'm sure as an adult, it's like, oh cool, now I have a spreadsheet to track budgeting, or whatever at home. It was this whole notion of open source and just sharing knowledge and that really stuck with me, too and so, as I would try to satiate this innate curiosity in myself and learn something, I would go teach it to a friend and it's like, “Hey, hey, let me show you what I just did. I learned how to play this thing on the piano,” or “I learned how to sing this song,” or “I learned how to use a magnifying glass to cook an ant on the sidewalk.” [chuckles] Whatever I learned, I always wanted to turn around and teach it to somebody else. I would get sometimes more excitement and joy out of watching somebody else do it because I taught them than the fact that I was able to learn that and do it myself. And so, after a while it was working on the computer became kind of a, oh yeah, okay, I can work on the computer, I can do the thing. But if I could turn around and show somebody else how to do that and then watch them explore and you watch that light bulb go off over their head, then it's like, oh, they're going to go do something cool with that. Just the anticipation of how are they going to go use that knowledge, that really stuck with me my whole life. In high school doing little bits of tutoring here and there. I was a paid tutor in college. Once I got out of college and got into the workplace, again, just learning on my own and then turning around and teaching others led into running my own web development business where I was teaching some friends how to do web development because I was taking on so much work that I had to subcontract it the somebody where I wasn't going to meet deadlines and so, I subcontracted them. That meant that I got to pay my friends to help me work this business. And so, that kind of kicked off and then I started learning well, how to servers work and how does the internet work and how do I run an email server on all this stuff? So just never-ending stream of knowledge going on in the internet and then just turning around and sharing that knowledge and keeping that community side of things building up over time. MANDY: Very cool. So in your bio, it said you're streaming now so I'm guessing that's a big part of what you do today with the streaming. So what are you streaming? IAN: So let's see, back in 2014, I started getting involved in mentorship with a local code school here in Denver called The Turing School of Software and Design. It's the 7-month code program and they were looking for someone that could help just mentor students. They were teaching Ruby on Rails at the time. So I got involved with them. I was working in Ruby at SendGrid at the time where I was working, who was later acquired by Twilio. And I'm like, “Yeah, I got some extra time. I can help some people out.” I like giving back and I like the idea of tutoring and teaching. I started that mentorship and it quickly turned into hey, do any of our mentors know anything about resumes and the hiring and interviewing and things like that. And by that point, I had been the lead engineer. I had done hiring. I hired several dozen engineers at SendGrid, or helped hire several dozen people at SendGrid. And I'm like, “Yeah, I've looked at hundreds and thousands of resumes.” Like, “What can I help with?” So I quickly became the career development guy to help them out and over time, the school started developing their career development curriculum and I like to think I had a hand in developing some of that. 3 years later, they're like, “You just want a job here? Like you're helping so many students, you just want to come on staff?” And so, I joined them as an instructor, taught the backend program, had a blast, did that for almost 4 full years. And then when I left Turing in June of 2021, I thought, “Well, I still want to be able to share this knowledge,” and so, I took all these notes that I had been writing and I basically put it all onto a website called techinterview.guide. When I finished teaching, I'm like, “Well, I still miss sharing that knowledge with people,” and I thought, “How else can I get that knowledge out there in a way that is scalable and manageable by one human being?” And I thought, “Well, I'll just kind of see what other people are doing.” Fumbled around on YouTube, watched some YouTube videos, watched people doing livestreaming on LinkedIn, livestreaming on Facebook, livestreaming on YouTube and trying to think could I do that? Nah, I don't know if I could do that. A friend of mine named Jonan Scheffler, he currently works at New Relic, he does a live stream. So I was hanging out on his stream one night and it was just so much fun seeing people interact and chat and how they engage the people in the chat and answering questions for them. I'm like, “I wonder if I could do that.” The curiosity took over from there and you can imagine where that went; went way down some rabbit holes on how to set up a streaming computer. Started streaming and found out that I wasn't very good at audio routing, [chuckles] recording things, and marketing, all that kind of stuff. But I kind of fumbled my way through it and Jonan was very generous with his time to help me straighten some things out and it kind of took off from there. So I thought, “Well, now I've got a platform where I can share this career development advice having been in the industry now for 25 years. Now, I've been director of engineering. I'm currently the director of engineering learning at a company. I've got an education background now as an instructor for several years. I've been doing tons of mentoring.” I love to give back and I love to help other people learn a thing that's going to help improve their life. I think of it like a ripple effect, like I'm not going to go out and change the world, but I can change your world and that ripple effect is going to change somebody else's world and that's going to change somebody else's world. So that's how I see my part in all of this play out. I'm not looking to be the biggest name in anything. I'm just one person with a voice and I'm happy to share my ideas and my perspectives, but I'm also happy to have people on my stream that can share their ideas and perspectives as well. I think it's important to hear a lot of perspectives, especially when it comes to things like job hunt, interview prep, and how to build a resume. You're going to see so much conflicting advice out there like, “This is the way you should do it,” and someone else will be like, “No, this is the way you should do it.” Meanwhile, I'm on the sidelines going, “You can do it all of that way.” Just listen to everybody's advice and figure out how you want to build your resume and then that's your resume. It doesn't have to look like the way I want it, or the way that someone else wants it; it can look how you want it to look. This is just our advice kind of collectively. So the livestream took off from there and I've got only a couple of hundred followers, or so on Twitch, but it's been a lot of fun just engaging with chat and people are submitting questions to me all the time. So I do a lot of Q&A sessions, like ask me anything sessions and it's just been a ton of fun. ARTY: That's awesome. I love the idea of focusing on one person and how you can make a difference in that one person's life and how those differences can ripple outward. That one-on-one connection, I feel like if we try and just broadcast and forget about the individuals, it's easy for the message and stuff to just get lost in ether waves and not actually make that connection with one person. Ultimately, it's all those ones that add up to the many. IAN: Definitely. Yeah. ARTY: So can you tell us a little bit more about the Tech Interview Guide and what your philosophy is regarding tech interviews? IAN: The tech interview process in – well, I mean, just the interview process in general in the tech industry is pretty broken. It lends itself very well to people who come from position and privilege that they can afford expensive universities and have oodles and oodles of free time to go study algorithms for months and months and months to go jump through a whole bunch of hoops for companies that want four, or five, six rounds of interviews to try to determine whether you're the right fit for the company and it's super broken. There are a lot of companies out there that are trying to change things a little bit and I applaud them. It's going to be a tough journey, for sure. Trying to convince companies like hey, this is not working out well for us as candidates trying to apply for jobs. As a company, though I understand because I've been a hiring manager that you need to be able to trust the people that you're hiring. You need to trust that they can actually do the job. Unfortunately, a lot of the tech interview process does not adequately mimic what the day-to-day responsibility of that job is going to be. So the whole philosophy of me doing the Tech Interview Guide is just an education of, “Hey, here's my perspective on what you're likely to face as a technical interview. These are the different stages that you'll typically see.” I have a lot of notes on there about how to build a resume, how to build a cover letter, thoughts on building a really big resume and then how to trim it down to one page to go apply for a particular job. How to write a cover letter that's customized to the business to really position yourself as the best candidate for that role. And then some chapters that I have yet to write are going to be things like how do you negotiate once you get an offer, like what are some negotiation tips. I've shared some of them live on the stream and I've shared a growing amount of information as I learn from other people as well, then I'll turn around and I'll share that on the stream. The content that's actually on the website right now is probably 3, 4 years old, some of it at least and so, I'm constantly going back in and I'm trying to revamp that material a little bit to kind of be as modern as possible. I used to want to go a self-publish route where I actually made a book. Several of my friends have actually gone through the process of actually making a book and getting it published. I'm like, “Oh, I want to do that, too. My friends are doing that. I could do that, too,” and I got looking into it. It's like, okay, it's an expensive, really time-consuming process and by the time I get that book on a shelf somewhere, a lot of the information is going to be out of date because a lot of things in the tech industry change all the time. So I decided I would just self-publish an online book where I can just go in and I can just constantly refresh the information and people can go find whatever my current perspective is by going to the website. And then as part of the website, I also have a daily email series that people can sign up for. I'm about to split it into four mailing lists. But right now, it's a single mailing list where I'm presenting technical questions and behavioral questions that you're likely to get asked as a web developer getting into the business. But I don't spend time in the email telling you how to answer the question; what I do instead is I share from the interviewer's perspective. This is why I'm asking you this question. This is what I hope to hear. This is what's important for me to hear in your answer. Because there's so many resources out there already that are trying to tell you how to craft the perfect answer, where I'm trying to explain this is why this question is important to us in the first place. So I'm taking a little bit different perspective on how I present that information and to date I've sent out, I don't know, something like 80,000 emails over a couple of years to folks that have signed up for that, which has been really tremendous to see. I get a lot of good feedback from that. But again, that information it doesn't always age well and interview processes change. I'm actually going through the process right now in the month of November to rewrite a lot of that information, but then also break out into multiple lists and so, where right now it's kind of a combination of a little bit of technical questions, a little bit of behavioral questions, a little bit of procedural, like what is an interview and so on. Now I'm actually going to break them out into separate lists of this list is all just technical questions and this list is all just behavioral questions and this list is going to be general process and then the process of going through the interview and how to do research and so on. And then the last one is just general questions and answers and a lot of that is stemmed from the questions that people have submitted to me that I answered on the live stream. So it all kind of packages up together. MANDY: That's really cool. I'd like to get into some of the meat of the material that you're putting out here. IAN: Yeah. MANDY: So as far as what are some of the biggest questions that you get on your street? IAN: Probably the most popular question I get—because a lot of the people that come by the stream and find the daily email list are new in the industry and they're trying to find that first job. And so by far, the number one question is, how do I even get a job in the industry right now? I have no experience. I've got some amount of education, whether it's an actual CS degree, or something similar to a CS degree, or they've gone through a bootcamp of some kind. How do I even get that first job? How do I position myself? How do I differentiate myself? How do I even get a phone call from a company? That's a lot of what's broken in the industry. Everybody in the industry right now wants people with experience, or they're saying like, “Oh, this is a “entry-level role,” but you must have 3 to 4 years' experience.” It's like, well, it's not entry level if you're asking for experience; it can't be both. All they're really doing is they're calling it an entry-level role so they don't have to pay you as much. But if they want 3-, or 4-years' experience, then you should be paying somebody who has 3-, or 4-years' experience. So the people writing these job posts are off their rocker a little bit, but that's by far, the number one question I get is how do I even get that first job. Once you get that first job and you get a year, year and a half, 2 years' experience, it's much easier to get that second job, or third job. It's not like oh, I'm going to quit my job today and have a new job tomorrow. But the time to get that next job is usually much, much shorter than getting this first job. I know people that have gone months and months, or nearly a year just constantly trying to apply, getting ghosted, like not getting any contact whatsoever from companies where they're sending in resumes and trying to apply for these jobs. Again, it's just a big indication of what's really broken in our industry that I think could be improved. I think that there's a lot of room for improvement there. MANDY: So what do you tell them? What's your answer for that? How do they get their first job? How do you get your first job? IAN: That's a [chuckles] good question. And I hate to fall back on the it depends answer. It really does depend on the kind of career that you want to have. I tell people often in my coaching that the tech industry is really a choose your own adventure kind of book. Like, once you get that job a little bit better, what you want your next job to be and so, you get to choose. If you get your first job as a QA developer, or you get that first job as a technical writer, or you get that first job doing software development, or you get that first job in dev ops and then decide, you don't want to do that anymore, that's fine. You can position yourself to go get a job doing some other kind of technical job that doesn't have to be what your previous job was. Now, once you have that experience, though recruiters are going to be calling you and saying, “Hey, you had a QA role. I've also got a QA role,” and you just have to stand firm and say, “No, that's not the direction I'm taking my career anymore. I want to head in this direction. So I'm going to apply for a company where they're looking for people with that kind of direction.” It really comes down to how do you show the company what you bring to the company and how you're going to make the company better, how are you going to make the team better, what skill, experience, and background are you bringing to that job. A lot of people, when they apply for the job, they talk about what they don't have. Like, “Oh, I'm an entry level developer,” or “I only went to a bootcamp,” or “I don't know very much about some aspect of development like I don't know, test driven development,” or “I don't really understand object-oriented programming,” or “I don't know anything about Docker, but I want to apply for this job.” Well, now you're highlighting what you don't have and to get that first job, you have to highlight what you do have. So I often tell people on your resume, on your LinkedIn, don't call yourself a junior developer. Don't call yourself an entry level. Don't say you're aspiring to be. You are. You are a developer. If you have studied software development, you can write software, you're a software developer. Make that your own title and let the company figure out what level you are. So just call yourself a developer and start applying for those jobs. The other advice that I tend to give people is you don't have to feel like you meet a 100% of the requirements in any job posts. As a hiring manager, when I read those job posts often, it's like, this is my birthday wish list. I hope I can find this mythical unicorn that has all of these traits [laughter] and skills and characteristics and that person doesn't exist. In fact, if I ever got a resume where they claim to have all that stuff, I would immediately probably throw the resume in the bin because they're probably lying, because either they have all those skills and they're about to hit me up for double the salary, or they're just straight up lying that they really don't have all those skills. As a hiring manager, those are things that we have to discern over time as we're evaluating people and talking with them and so on. But I would say if you meet like 30 to 40% of those skills, you could probably still apply. The challenge then is when you get that phone call, how do you convince them that you're worth taking a shot, that you're worth them taking the risk of hiring you, helping train you up in the skills that you don't have. But on those calls, you still need to present this is what I do bring to the company. I'm bringing energy, I'm bringing passion, and I'm bringing other experience and background and perspectives on things, hopefully from – just increasing the diversity in tech, just as an example. You're coming from a background, or a walk of life that maybe we don't currently have on the team and that's great for us and great for our team because you're going to open our eyes to things that we might not have thought of. So I think apply anyway. If they're asking for a couple of years' experience and you don't have it, apply anyway. If they're asking for programming languages you don't know, apply anyway. The languages you do know, a lot of that skill is going to transfer into a new language anyway. And I think a lot of companies are really missing out on the malleability and how they can shape an entry-level developer into the kind of developer and kind of engineer that they want to have on the team. Now you use that person as an example and say, “Now we've trained them with the process that we want, with the language and the tools that we want. They know the company goals.” We've trained them. We've built them up. We've invested in them and now everybody else we hire, we're going to hold to that standard and say, “If we're going to hire from outside, this is what we want,” and if we hire someone who doesn't have that level of skill, we're going to bring them up to that skill. I think a lot of companies are missing out on that whole aspect of hiring, that is they can take a chance on somebody who's got the people skills and the collaboration skills and that background and the experiences of life and not necessarily the technical skills and just train them on the technical skills. I went on a rant on this on LinkedIn the other day, where I was saying the return on investment. If a company is spending months and months and months trying to hire somebody, that's expensive. You're paying a recruiter, you're paying engineers, you're paying managers to screen all these people, interview all these people, and you're not quite finding that 100% skill match. Well, what if you just hired somebody months ago, spend $5,000 training them on the skills they didn't have, and now you're months ahead of the game. You could have saved yourself so much money so much time. You would have had an engineer on the team now. And I think a lot of companies are kind of missing that point. Sorry, I know I get very soapbox-y on some of the stuff. ARTY: I think it's important just highlighting these dynamics and stuff that are broken in our industry and all of the hoops and challenges that come with trying to get a job. You mentioned a couple of things on the other side of one, is that the interview processes themselves don't align to what it is we actually need skill-wise day-to-day. What are the things that you think are driving the creation of interviews that don't align with the day-to-day stuff? Like what factors are bringing those things so far out of alignment? IAN: That's a great question. I would say I have my suspicions. So don't take this as gospel truth, but from my own perspective, this is what I think. The big, big tech companies out there, like the big FAANG companies, they have a very specific target in mind of the kind of engineers that they want on their team. They have studied very deep data structures and algorithms, the systems thinking and the system design, and all this stuff. Like, they've got that knowledge, they've got that background because those big companies need that level of knowledge for things like scaling to billions of users, highly performant, and resilient systems. Where the typical startup and typical small and mid-sized company, they don't typically need that. But those kinds of companies look at FAANG companies and go, “We want to be like them. Therefore, we must interview like them and we must ask the same questions that they ask.” I think this has this cascading effect where when FAANG companies do interviews in a particular way, we see that again, with this ripple effect idea and we see that ripple down in the industry. Back in the early 2000s, mid 2000s—well, I guess right around the time when Google was getting started—they were asking a lot of really oddball kinds of questions. Like how many golf balls fit in a school bus and those were their interview challenges. It's like, how do you actually go through the calculation of how many golf balls would fit in a school bus and after a while, I think by 2009, they published an article saying, “Yeah, we're going to stop asking those questions. We weren't getting good signals. Everybody's breaking down those problems the same way and it wasn't really helpful.” Well, leading up to that point, everyone else was like, “Oh, those are cool questions. We're going to ask those questions, too,” and then when Google published that paper, everyone else was like, “Yeah, those questions are dumb. We're not going to ask those questions either.” And then they started getting into what we now see as like the LeetCode, HackerRank type of technical challenges being asked within interviews. I think that there's a time and place for some of that, but I think that the types of challenges that they're asking candidates to do should still be aligned with what the company does. One criticism that I've got. For example, I was looking at a technical challenge from one particular company that they asked this one particular problem and it was using a data structure called Heap. It was, find a quantity of location points closest to a target. So you're given a list of latitude, longitude values, and you have to find the five latitude and longitude points that are closest to a target. It's like, okay and so, I'm thinking through the challenge, how would I solve that if I had to solve it? But then I got thinking that company has nothing to do with latitude and longitude. That company has nothing to do with geospatial work of any kind. Why are they even asking that problem? Like, it's so completely misaligned that anybody they interview, that's the first thing that's going to go through their mind as a candidate is like, “Why are they asking me this kind of question?” Like, “This has nothing to do with the job. It had nothing to do with the role. I don't study global positioning and things like that. I know what latitude and longitude are, but I've never done any kind of math to try to figure out what those things would be and how you would detect differences between them.” Like, I could kind of guess with simple math, but unless you've studied that stuff, it's not going to be this, “Oh yeah, sure, no problem. It's this formula, whatever.” We shouldn't have to expect that candidates coming to a business are going to have that a, formula memorized, especially when that's not what your company does. And a lot of companies are like, “Oh, we're got to interview somebody. Quick, go to LeetCode and find a problem to ask them.” All you're going to do is you're going to bias your interview process towards people that have studied those problems on LeetCode and you're not actually going to find people that can actually solve your day-to-day challenges that your company is actually facing. ARTY: And instead, you're selecting for people that are really good at things that you don't even need. [chuckles] It's like, all right! It totally skews who you end up hiring toward people that aren't even necessarily competent in the skills that they actually need day-to-day. Like you mentioned FAANG companies need these particular skills. I don't even think that for resilience, to be able to build these sort of systems, and even on super hardcore systems, it's very seldom that you end up writing algorithmic type code. Usually, most of the things that you deal with in scaling and working with other humans and stuff, it's a function of design and being able to organize things in conceptual ways that make sense so that you can deconstruct a complex, fuzzy problem into little pieces that make sense and can fit together like a jigsaw puzzle. I have a very visual geometric way of thinking, which I find actually is a core ability that makes me good at code because I can imagine it visually laid out and think about the dependencies between things as like tensors between geographically located little code bubbles, if you will. IAN: Sure. ARTY: Being able to think that way, it's fundamentally different than solving algorithm stuff. But that deconstruction capability of just problem breakdown, being able to break down problems, being able to organize things in ways that make sense, being able to communicate those concepts and come up with abstractions that are easy enough for other people on your team to understand, ideally, those are the kinds of engineers we want on the teams. Our interview processes ought to select for those day-to-day skills of things that are the common bread and butter. [chuckles] IAN: I agree. ARTY: What we need to succeed on a day-to-day basis. IAN: Yeah. We need the people skills more than we need the hard technical skills sometimes. I think if our interview process could somehow tap into that and focus more on how do you collaborate, how do you do code reviews, how do you evaluate someone else's code for quality, how do you make the tradeoff between readability and optimization—because those are typically very polarized, opposite ends of the scale—how do you function on a team, or do you prefer to go heads down and just kind of be by yourself and just tackle tasks on your own? I believe that there's a time and place for that, too and there are personality types where you prefer to go heads down and just have peace and quiet and just get your work done and there's nothing wrong with that. But I think if we can somehow tap into the collaborative process as part of the interview, I think it's going to open a lot of companies up to like, “Oh, this person's actually going to be a really great team member. They don't quite have this level of knowledge in database systems that we hope they'd have, but that's fine. We'll just send them on this one-week database training class that happens in a week, or two and now they'll be trained.” [overtalk] MANDY: Do they want to learn? IAN: Right. Do they want to learn? Are they eager to learn? Because if they don't want to learn, then that's a whole other thing, too. But again, that's something that you can screen for. Like, “Tell me what you're learning on the side, or “What kinds of concepts do you want to learn?” Or “In this role, we need you to learn this thing. Is that even of interest to you?” Of course, everyone's going to lie and say, “Yeah,” because they want the paycheck. But I think you can still narrow it down a little bit more what area of training does this person need. So we can just hire good people on the team and now our team is full of good people and collaborative, team-based folks that are willing to work together to solve problems together and then worry about the technical skills as a secondary thing. MANDY: Yeah. I firmly believe anybody can learn anything, if they want to. I mean, that's how I've gotten here. IAN: Yeah, for sure. Same with me. I'm mostly self-taught. I studied computer engineering in college, so I can tell you how all the little microchips in your computer work. I did that for the first 4 years of my career and then I threw all that out the window and I taught myself web development and taught myself how the internet works. And then every job I had, that innate curiosity in me is like, “Oh, I wonder how e-commerce works.” Well, I went and got an e-commerce job, it's like, okay, well now I wonder how education works and I got into the education sector. Now, I wonder how you know this, or that works and so, I got into financial systems and I got into whatever and it just kind of blew my mind. I was like, “Wow, this is how all these things kind of talk to each other,” and that for me was just fascinating, and then turning around and sharing that knowledge with other people. But some people are just very fixed mindset and they want to learn one thing, they want to do that thing, and that's all they know. But I think, like we kind of talked about early in the podcast, you sign up for a career in this industry and you're signing up for lifelong learning. There's no shortage to things that you can go learn, but you have to be willing to do it. MID-ROLL: Rarely does a day pass where a ransomware attack, data breach, or state sponsored espionage hits the news. It's hard to keep up with all this and also to know if you're protected. Don't worry, Kaspersky's got you covered. Each week their team looks at the latest news, stories, and topics you might have missed during the week on the Transatlantic Cable Podcast. Mixing in-depth discussion, expert guests from around the world, a pinch of humor, and all with an easy to consume style - be sure you check them out today. ARTY: What kind of things could we do to potentially influence the way hiring is done and these practices with unicorn skilled searches and just the dysfunctional aspects on the hiring side? Because you're teaching all these tech interview skills for what to expect in the system and how to navigate that and succeed, even though it's broken. But what can we do to influence the broken itself and help improve these things? IAN: That's a great question. Breaking it from the inside out is a good start. I think if we can collectively get enough people together within these, especially the bigger companies and say like, “Hey, collectively, as an industry, we need to do interviewing differently.” And then again, see that ripple effect of oh, well, the FAANG companies are doing it that way so we're going to do it that way, too. But I don't think that's going to be a fast change by any stretch. I think there are always going to be some types of roles where you do have to have a very dedicated, very deep knowledge of system internals and how to optimize things, and pure algorithmic types of thinking. I think those kinds of jobs are always going to be out there and so, there's no fully getting away from something like a LeetCode challenge style interview. But I think that for a lot of small, mid-sized, even some large-sized companies, they don't have to do interviewing that way. But I think we can all stand on our soapbox and yell and scream, “Do it differently, do it differently,” and it's not going to make any impact at all because those companies are watching other companies for how they're doing it. So I think gradually, over time, we can just start to do things differently within our own company. And I think for example, if the company that I was working at, if we completely overhauled our interview process that even if we don't hire somebody, if someone can walk away from that going, “Wow, that was a cool interview experience. I've got to tell my friends about this.” That's the experience that we want when you walk away from the company if we don't end up hiring. If we hire you, it's great. But even if we don't hire you, I want to make sure that you've still got a really cool interview experience that you enjoyed the process, that it didn't just feel like another, “Okay, well, I could have just grind on LeetCode for three months to get through that interview.” I don't ever want my interviews to feel like that. So I think as more of us come to this understanding of it's okay to do it differently and then collectively start talking about how could we do it differently—and there are companies out there that are doing it differently, by the way. I'm not saying everyone in the industry is doing all these LeetCode style interviews. There are definitely companies out there that are doing things differently and I applaud them for doing that. And I think as awful as it was to have the pandemic shut everything down to early 2020, where no hiring happened, or not a lot of hiring happened over the summer, it did give a lot of companies pause and go, “Well, hey, since we're not hiring, since we got nobody in the backlog, let's examine this whole interview process and let's see if this is really what we want as a company.” And some companies did. They took the time, they took several months and they were like, “You know what, let's burn this whole thing down and start over” as far as their interview process goes. Some of them completely reinvented what their interview process was and turned it into a really great process for candidates to go through. So even if they don't get the job, they still walk away going, “Wow, that was neat.” I think if enough of us start doing that to where candidates then can say, “You know what, I would really prefer not to go through five, or six rounds of interviews” because that's tiring and knowing that what you're kind of what you're in for, with all the LeetCode problems and panel after panel after panel. Like, nobody wants to sit through that. I think if enough candidates stand up for themselves and say, “You know what, I'm looking for a company that has an easier process. So I'm not even going to bother applying.” I think there are enough companies out there that are desperately trying to hire that if they start getting the feedback of like you know what, people don't want to interview with us because our process is lousy. They're going to change the process, but it's going to take time. Unfortunately, it's going to drag out because companies can be stubborn and candidates are also going to be stubborn and it's not going to change quickly. But I think as companies take the step to change their process and enough candidates also step up to say, “Nah, you know what, I was going to apply there,” or “Maybe I got through the first couple of rounds, but you're telling me there's like three more rounds to go through? Nah, I'm not going to bother.” Companies are now starting to see candidates ghost them and walk away from the interview process because they just don't want to be bothered. I think that's a good signal for a company to take a step back and go, “Okay, we need to change our process to make it better so the people do want to apply and enjoy that interview process as they come through.” But it's going to take a while to get there. ARTY: Makes me think about we were talking early on about open source and the power of open source. I wonder with this particular challenge, if you set up a open source hiring manifesto, perhaps of we're going to collaborate on figuring out how to make hiring better. Well, what does that mean? What is it we're aiming for? We took some time to actually clarify these are the things we ought to be aiming for with our hiring process and those are hard problems to figure out. How do we create this alignment between what it is we need to be able to do to be successful day-to-day versus what it is we're selecting for with our interview process? Those things are totally out of whack. I think we're at a point, at least in our industry, where it's generally accepted that how we do interviewing and hiring in these broken things—I think it's generally accepted that it's broken—so that perhaps it's actually a good opportunity right now to start an initiative like that, where we can start collaborating and putting our knowledge together on how we ought to go about doing things better. Even just by starting something, building a community around it, getting some companies together that are working on trying to improve their own hiring processes and learning together and willing to share their knowledge about things that are working better, such that everybody in the industry ultimately benefits from us getting better at these kinds of things. As you said, being able to have an interview process that even if you don't get the job, it's not a miserable experience for everyone involved. [chuckles] Like there's no reason for that. IAN: Yeah. MANDY: That's how we – I mean, what you just explained, Arty isn't that how we got code of conducts? Everybody's sitting down and being like, “Okay, this is broken. Conferences are broken. What are we going to all do together?” So now why don't we just do the same thing? I really like that idea of starting an open source initiative on interviewing. Like have these big FAANG companies be like, “I had a really great interview with such and such company.” Well, then it all spirals from there. I think that's super, super exciting. ARTY: Yeah. And what is it that made this experience great? You could just have people analyze their interview experiences that they did have, describe well, what are the things that made this great, that made this work and likewise, you could collect anti-patterns. Some of the things that you talked about of like, are we interviewing for geolocation skills when that actually has absolutely nothing to do with our business? We could collect these things as these funky anti-patterns of things so that people could recognize those things easier in there because it's always hard to see yourself. It's hard to see yourself swinging. IAN: An interesting idea along those lines is what if companies said like, “Hey, we want the community to help us fix our interview process. This is who we are, this is what our business does. What kinds of questions do you think we should be asking?” And I think that the community would definitely rally behind that and go, “Oh, well, you're an e-commerce platform so you should be asking people about shopping cart implementations and data security around credit cards and have the interview process be about what the company actually does.” I think that that would be an interesting thing to ask the community like, “What do you think we should be asking in these interviews?” Not that you're going to turn around and go, “Okay, that's exactly what we're going to do,” but I think it'll give a lot of companies ideas on yeah, okay, maybe we could do a take-home assignment where you build a little shopping cart and you submit that to us. We'll evaluate how you did, or what you changed, or we're going to give you some code to start with and we're going to ask you to fix a bug in it, or something like, I think that there's a bigger movement now, especially here in Canada, in the US of doing take-home assignments. But I think at the same time, there are pros and cons of doing take-home assignments versus the on-site technical challenges. But what if we gave the candidate a choice as part of that interview process, too and say, “Hey, cool. We want to interview you. Let's get through the phone screen and now that you've done the phone screen, we want to give you the option of, do you want to do a small take-home assignment and then do a couple of on-site technical challenges? Do you want to do a larger take-home and maybe fewer on-site technical challenges?” I think there's always going to be some level of “Okay, we need to see you code in front of us to really make sure that you're the one that wrote that code.” I got burned on that back in 2012 where I thought somebody wrote some code and they didn't. They had a friend write it as their take-home assignment and so, I brought them in for the interview and I'm like, “Cool, I want you to fix this bug,” and they had no idea what to do. They hadn't even looked at the code that their friend wrote for them it's like, why would you do that? So I think that there's always going to be some amount of risk and trust that needs to take place between the candidates and the companies. But then on the flip side of that, if it doesn't work out, I really wish companies would be better about giving feedback to people instead of just ghosting them, or like, “Oh, you didn't and pass that round. So we're just not even going to call you back and tell you no. We're just not ever just going to call.” The whole ghosting thing is, by far, the number one complaint in the tech industry right now is like, “I applied and I didn't even get a thanks for your resume. I got nothing,” or maybe you get some automated reply going, “We'll keep you in mind if you're a match for something.” But again, those apple looking at tracking systems are biased because the developers building them and the people reading the resumes are going to have their own inherent bias in the search terms and the things that they're looking for and so on. So there's bias all over the place that's going to be really hard to get rid of. But I think if companies were to take a first step and say like, “Okay, we're going to talk to the community about what they would like to see the interview process be,” and start having more of those conversations. And then I think as we see companies step up and make those changes, those are going to be the kinds of companies where people are going to rally behind them and go, “I really want to work there because that interview process is pretty cool.” And that means the company is – well, it doesn't guarantee the company's going to be cool, but it shows that they care about the people that are going to work there. If people know that the company is going to care about you as an employee, you're far more likely to want to work there. You're far more likely to be loyal and stay there for a long term as opposed to like oh, I just need to collect a paycheck for a year to get a little bit of experience and then job hop and go get a better title, better pay. So I think it can come down to company loyalty and stuff, too. MANDY: Yeah. Word of mouth travels fast in this industry. IAN: Absolutely. MANDY: And to bring up the code of conduct thing and now people are saying, “If straight up this conference doesn't have a code of conduct, I'm not going.” IAN: Yeah. I agree. It'll be interesting to see how something like this tech interview overhaul open source idea could pick up momentum and what kinds of companies would get behind it and go, “Hey, we think our interview process is pretty good already, but we're still going to be a part of this and watch other companies step up to.” When I talked earlier about that ripple effect where Google, for example, stopped asking how many golf balls fit in a school bus kind of thing and everyone else is like, “Yeah, those questions are dumb.” We actually saw this summer, Facebook and Amazon publicly say, “We're no longer going to ask dynamic programming problems in our interviews.” It's going to be interesting to see how long that takes to ripple out into the industry and go, “Yeah, we're not going to ask DP problems either,” because again, people want to be those big companies. They want to be billion- and trillion-dollar companies, too and so, they think they have to do everything the same way and that's not always the case. But there's also something broken in the system, too with hiring. It's not just the interview process itself, but it's also just the lack of training. I've been guilty of this myself, where I've got an interview with somebody and I've got back-to-back meetings. So I just pull someone on my team and be like, “Hey, Arty, can you come interview this person?” And you're like, “I've never interviewed before. I guess, I'll go to LeetCode and find a problem to give them.” You're walking in there just as nervous as the candidate is and you're just throwing some technical challenge at them, or you're giving them the technical challenge that you've done most recently, because you know the answer to it and you're like, “Okay, well, I guess they did all right on it. They passed,” or “I think they didn't do well.” But then companies aren't giving that feedback to people either. There's this thinking in the industry of oh, if we give them feedback, they're going to sue us and they're going to say it's discriminatory and they're going to sue us. Aline Lerner from interviewing.io did some research with her team and literally nobody in recent memory has been sued for giving feedback to candidates. If anything, I think that it would build trust between companies and the candidates to say, “Hey, this is what you did. Well, this is what we thought you did okay on. We weren't happy with the performance of the code that you wrote so we're not moving forward,” and now you know exactly what to go improve. I was talking to somebody who was interviewing at Amazon lately and they said, “Yeah, the recruiter at Amazon said that I would go through all these steps,” and they had like five, or six interviews, or something to go through. And they're like, “Yeah, and they told me at the end of it, we're not going to give you any feedback, but we will give you a yes, or no.” It's like so if I get a no, I don't even find out what I didn't do well. I don't know anything about how to improve to want to go apply there in the future. You're just going to tell me no and not tell me why? Why would I want to reapply there in the future if you're not going to tell me how I'm going to get better? I'm just going to do the same thing again and again. I'm going to be that little toy that just bangs into the wall and doesn't learn to steer away from the wall and go in a different direction. If you're not going to give me any feedback, I'm just going to keep banging my head against this wall of trying to apply for a job and you're not telling me why I'm not getting it. It's not helpful to the candidate and that's not helpful to the industry either. It starts affecting mental health and it starts affecting other things and I think it erodes a lot of trust between companies and candidates as well. ARTY: Yeah. The experience of just going through trying to get a job and going through the rejection, it's an emotional experience, an emotionally challenging experience. Of all things that affect our feels a lot, it's like that feeling of social rejection. So being able to have just healthier relationships and figuring out how to see another person as a human, help figure out how you can help guide and support them continuing on their journey so that the experience of the interview doesn't hurt so much even when the relationship doesn't work out, if we could get better at those kinds of things. There's all these things that if we got better at, it would help everybody. IAN: I agree. ARTY: And I think that's why a open source initiative kind of thing maybe make sense because this is one of those areas that if we got better at this as an industry, it would help everybody. It's worth putting time in to learn and figure out how we can do better and if we all get better at it and stuff, there's just so many benefits and stuff from getting better at doing this. Another thing I was thinking about. You were mentioning the language thing of how easy it is to map skills that we learned from one language over to another language, such that even if you don't know the language that they're coding in at a particular job, you should apply anyway. [chuckles] I wonder if we had some data around how long it takes somebody to ramp up on a new language when they already know similar-ish languages. If we had data points on those sort of things that we're like, “Okay, well, how long did it actually take you?” Because of the absence of that information, people just assume well, the only way we can move forward is if we have the unicorn skills. Maybe if it became common knowledge, that it really only takes say, a couple months to become relatively proficient so that you can be productive on the team in another language that you've never worked in before. Maybe if that was a common knowledge thing, that people wouldn't worry about it so much, that you wouldn't see these unicorn recruiting efforts and stuff. People would be more inclined to look for more multipurpose general software engineering kinds of skills that map to whatever language that you're are doing. That people will feel more comfortable applying to jobs and going, “Oh, cool. I get the opportunity to learn a new language! So I know that I may be struggling a bit for a couple months with this, but I know I'll get it and then I can feel confident knowing that it's okay to learn my way through those things.” I feel if maybe we just started collecting some data points around ramp up time on those kind of things, put a database together to collect people's experiences around certain kind of things, that maybe those kinds of things would help everyone to just make better decisions that weren't so goofy and out of alignment with reality. IAN: Yeah, and there are lots of cheat sheets out there like, I'm trying to remember the name of it. I used to have it bookmarked. But you could literally pull up two programming languages side by side in the same browser window and see oh, if this is how you do it in JavaScript, this is how you do it on Python, or if this is how you write this code in C++, here's how you do it in Java. It gives you a one-to-one correlation for dozens, or hundreds of different kinds of blocks of code. That's really all you need to get started and like you said, it will take time to come proficient to where you don't have to have that thing up on your screen all the time. But at the same time, I think the company could invest and say, “You know what, take a week and just pour everything you've got into learning C Sharp because that's the skill we want you to have for this job.” It's like, okay, if you are telling me you trust me and you're making me the job offer and you're going to pay me this salary and I get to work in tech, but I don't happen to have that skill, but you're willing to me in that skill, why would I not take that job? You're going to help me learn and grow. You're offering me that job with a salary. Those are all great signals to send. Again, I think that a lot of companies are missing out and they're like, “No, we're not going to hire that person. We're just going to hold out until we find the next person that's a little bit better.” I think that that's where some things really drop off in the process, for sure is companies hold out too long and next thing they know, months have gone by and they've wasted tons of money when they could have just hired somebody a long time ago and just trained them. I think the idea of an open source collective on something like this is pretty interesting. At the same time, it would be a little subjective on “how quickly could someone ramp up on a, or onboard on a particular technology.” Because everybody has different learning styles and unless you're finding somebody to curate – like if you're a Ruby programmer and you're trying to learn Python, this is the de facto resource that you need to look at. I think it could be a little bit subjective, but I think that there's still some opportunity there to get community input on what should the interview process be? How long should it really be? How many rounds of interviews should there be from, both the candidates experience as well as the company experience and say, as a business, this is why we have you doing these kinds of things. That's really what I've been to teach as part of the Tech Interview Guide and the daily email series is from my perspective in the business, this is why. This is why I have you do a certain number of rounds, or this is why I give you this kind of technical challenge, or this is why I'm asking you this kind of question. Because I'm trying to find these signals about you that tell me that you're someone that I can trust to bring on my team. It's a tough system when not many people are willing to talk about it because I think a lot of people are worried that others are going to try to game the system and go, “Oh, well, now that I know everything about your interview process, I know how to cheat my way through it and now you're going to give me that job and I really don't know what I'm doing.” But I think that at the same time, companies can also have the higher, slow fire, fast mentality of like, “All right, you're not cutting it.” Like you're out right away and just rehire for that position. Again, if you're willing to trust and willing to extend that offer to begin with. If it doesn't work out, it doesn't work out. It's a business decision; it's not a personal thing. But it's still devastating to the person when they don't get the job, or if they get fired right away because they're not pulling their weight, but if they're cheating their way through it, then they get what they deserve to. MANDY: Awesome. Well, I think that's a great place to put a pin in this discussion. It is definitely not a great place to end it. I think we should head over to our reflection segment. For me, there were so many things I wrote down. I loved that you said that people's tech journey is like a choose your own adventure. You can learn one thing and then find yourself over here and then the next thing you know, you find yourself over here. But you've picked up all these skills along the way and that's the most important thing is that as you go along this journey, you keep acquiring these skills that ultimately will make you the best programmer that you can be. Also, I really like that you also said something about it being a lifelong learning. Tech is lifelong learning and not just the technical skills. It's the people skills. It's the behavioral skills. Those are the important skills. Those skills are what ultimately it comes down to being in this industry is, do you have the desire to learn? Do you have the desire to grow? I think that should be one of the most important things that companies are aware of when they are talking to candidates that it's not about can this person do a Fibonacci sequence. It's can they learn, are they a capable person? Are they going to show up? Are they going to be a good person to have in the office? Are they going to be a light? Are they going to be supportive? Are they going to be caring? That's the ultimate. That right there for me is the ultimate and thank you for all that insight. ARTY: Well, I really, really loved your story, Ian at the very beginning of just curiosity and how you started your journey, getting into programming and then ended up finding ways to give back and getting really excited about seeing people's light bulbs go off and how much joy you got from those experiences, connecting with another individual and making that happen. I know we've gotten on this long tangent of pretty abstract, big topics of just like, here's the brokenness in the industry and what are some strategies that we can solve these large-scale problems. But I think you said some really important things back of just the importance of these one-on-one connections and the real change happens in the context of a relationship. Although, we're thinking about these big things. To actually make those changes, to actually make that difference, it happens in our local context. It happens in our companies. It happens with the people that we interact with on a one-on-one basis and have a genuine relationship with. If we want to create change, it happens with those little ripples. It happens with affecting that one relationship and that person going and having their own ripple effects. We all have the power to influence these things through the relationships with the individuals around us. IAN: I think my big takeaway here is we have been chatting for an hour and just how easy it is to have conversation about hey, what if we did this? How quickly it can just turn into hey, as a community, what if? And just the willingness of people being in the community, wanting to make the community better,

01:42 - Rin's Superpower: Writing, Public Speaking, and Being Neurodivergent + Awesome! 02:18 - GitHub Actions (https://github.com/features/actions) * Concurrent Actions * CICD (Continuous Improvement, Continuous Deployment) * Security * Trivy (https://aquasecurity.github.io/trivy/v0.17.0/) * Building Secure Open Source Communities From the Ground Up (https://www.youtube.com/watch?v=DtDitJyd-3s) * Camunda Community Hub (https://github.com/camunda-community-hub) * community-action-maven-release (https://github.com/camunda-community-hub/community-action-maven-release) 07:47 - Improving Developer Experience * Kubernetes Community Contributor Experience Special Interest Group (https://github.com/kubernetes/community/blob/master/sig-contributor-experience/README.md) * Contributing Code * Kubernetes.dev (https://www.kubernetes.dev/) 11:33 - Neurodivergence + Autistic Burnout * A Vulnerable Tale About Burnout - Julia Simon (https://www.youtube.com/watch?v=lpiXbfOTNYw) * CNCF Slack (https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/attend/slack-guidelines/) * Articles From Rin (https://muckrack.com/kiran-oliver/articles) * John K. Sawers: Hacking Your Emotional API (https://www.youtube.com/watch?v=OGDRUI8biTc) * CPTSD (https://www.healthline.com/health/cptsd) * EMDR (https://www.emdr.com/) 17:04 - Mentoring and Reviewing for Kubernetes (https://kubernetes.io/) * KubeCon + CloudNativeCon (https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/) 20:49 - Open Source Contribution * Paying Maintainers * Getting Hired Based on Contributions * Getting Started with DevOps/DevSecOps Contributing * MiniKube (https://minikube.sigs.k8s.io/docs/start/) * The Diana Initiative (https://www.dianainitiative.org/) * Trivy (https://aquasecurity.github.io/trivy/v0.17.0/) * Auditing 29:04 - Mentoring (Cont'd) * Pod Mentoring (https://github.com/kubernetes/community/blob/master/mentoring/programs/mentoring-events.md) * Ruby Central Scholarship Program (http://rubycentral.org/scholarships) 32:46 - Evaluating Open Source Projects: Tips For Newbies * Contributor Licence Agreements (CLAs) * Codes of Conduct (CoCs) * Evaluate the Community Reflections: John: Technical Mentorship vs Social Mentorship. Mando: Providing a welcoming sense of community for people with non-traditional backgrounds. Rin: Being intentional about helping others, but also helping others means helping yourself. John 2: The distinction between technical and autistic burnout. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: Coming Soon! Special Guest: Rin Oliver.

01:53 - Michael's Superpower: Networking and Community Building * Being Driven to Fulfill Needs * Mental Health First Aid (https://www.mentalhealthfirstaid.org/) * Working in Proximity / Keeping In Touch * MAPS at Burning Man (https://maps.org/news-letters/v15n3/burningman.pdf) 10:36 - Defining Mental Health * Self-Invalidation & Dialectics (https://plato.stanford.edu/entries/hegel-dialectics/) * Money buys happiness, but euphoria comes dear (https://www.economist.com/graphic-detail/2021/02/05/money-buys-happiness-but-euphoria-comes-dear) * Boots Theory of Socioeconomic Unfairness (https://moneywise.com/managing-money/budgeting/boots-theory-of-socioeconomic-unfairness) * Decolonizing Wealth (https://decolonizingwealth.com/) * Mental Health First Aid (https://www.mentalhealthfirstaid.org/) * Youth (https://www.mentalhealthfirstaid.org/population-focused-modules/youth/) * Teen (https://www.mentalhealthfirstaid.org/population-focused-modules/teens/) * Older Adults (https://www.mentalhealthfirstaid.org/population-focused-modules/older-adults/) * Aboriginal & Torres Strait Islander (https://mhfa.com.au/courses/public/types/aboriginal) 20:09 - Involving Gaming in Engaging in Talk Therapy * Jane McGonigal How GAMING Can Make A Better World TED Talk (https://www.youtube.com/watch?v=irsTFdCtcuQ) * Counselling with Mike: The Nerd Therapist (https://counsellingwithmike.com.au/) * The Nerd Therapist (https://www.facebook.com/NerdPsychology/) (Facebook) * Pop Culture Competence by The Nerd Therapist (https://popculturecompetence.wordpress.com/) * Grand Theft Auto 101 (https://popculturecompetence.wordpress.com/category/video-games/) * Five Nights at Freddy's 101 (https://popculturecompetence.wordpress.com/2020/09/05/five-nights-at-freddys-101/) * Call of Duty 101 (https://popculturecompetence.wordpress.com/2020/09/09/call-of-duty-101/) * Among Us 101 (https://popculturecompetence.wordpress.com/2021/03/02/among-us-101/) 31:13 - “Age-Appropriate Horror” * Critters (https://en.wikipedia.org/wiki/Critters_(film)) * Starship Troopers (https://en.wikipedia.org/wiki/Starship_Troopers_(film)) * Civilization VI (https://civilization.com/) 38:45 - Social Media, Media, and Mental Health: Curate & Engage Responsibly * Rick and Morty (https://www.imdb.com/title/tt2861424/) * BoJack Horseman (https://en.wikipedia.org/wiki/BoJack_Horseman) * Zootopia (https://www.imdb.com/title/tt2948356/) * Inside Out (https://www.imdb.com/title/tt2096673/) * Onward (https://en.wikipedia.org/wiki/Onward_(film)) * Avengers: Endgame (https://en.wikipedia.org/wiki/Avengers:_Endgame) * Worthiness: Character Spotlight: Thor (https://popculturecompetence.wordpress.com/2020/10/02/character-spotlight-thor/) 50:41 - The Geek Therapy Community (https://geektherapy.org/?gclid=Cj0KCQjww4OMBhCUARIsAILndv5g7398NpUpX_cnN_t9zVT_uJqW8erTdfLGKfx_95ZxWwKSs1eP1WgaAuxzEALw_wcB) * Mike's Facebook Page (https://www.facebook.com/CounsellingWithMike/) * The Spoon Theory (https://butyoudontlooksick.com/articles/written-by-christine/the-spoon-theory/) * Spell Slots and Spoon Theory (https://medium.com/collected-blog-posts-of-a-bipolar-author/spell-slots-and-spoon-theory-f9481abaacd6) 55:16 - Connect with Mike! * linktr.ee/thenerdtherapist (https://linktr.ee/thenerdtherapist) * D&D Therapy (https://counsellingwithmike.com.au/roll-for-growth/) * Warhammer 40,000 (https://warhammer40000.com/) * Minecraft (https://www.minecraft.net/) 59:14 - Intergenerational & Epigenetic Trauma * My Grandmother's Hands: Racialized Trauma and the Pathway to Mending Our Hearts and Bodies by Resmaa Menakem (https://www.amazon.com/My-Grandmothers-Hands-Racialized-Pathway/dp/1942094477) * Epigenetics (https://en.wikipedia.org/wiki/Epigenetics) Reflections: John: Coyote & Crow Role Playing Game (https://www.kickstarter.com/projects/connoralexander/coyote-and-crow) + Using Role Playing and Game Playing to treat mental health. I'm Begging You To Play Another RPG (https://www.facebook.com/groups/313523509340906/)(Facebook Group) Mae: The pragmatic approach to seeing where people are and meeting them there. Casey: Helping middle schoolers talk to friends in a structured way. Mike: The hardest part about doing something is helping people know you're doing it. Tall Poppy Syndrome (https://en.wikipedia.org/wiki/Tall_poppy_syndrome) Bristol Children's Hospital: Oath of Accessibility: (https://www.dicebreaker.com/games/dungeons-and-dragons-5e/news/dungeons-and-dragons-oath-of-accessibility) “Anyone can be a hero. Everyone deserves to go on an adventure.” This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) _To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at Special Guest: Michael Keady.

01:03 - Not Giving Into Peer Pressure 02:31 - Reaching Outside of the Accessibility World (Demystifying Accessibility) * Everyday Accessibility by Dr. Michele A. Williams (https://www.a11yproject.com/posts/2021-06-14-everyday_accessibility/) * Thinking About Disability Until It's Everyone's Normal Way of Thinking * Power Structures and Erasing Innovation * Recognizing Specialty * Cormac Russell: Four Modes of Change: To, For, With, By (https://www.skybrary.aero/bookshelf/books/4510.pdf) 12:37 - The Real Work of Accessibility: Organizational Change * Taking a Stance and Celebrating Innovation * Inclusion 17:52 - Avoiding Dysfunctional Ways of Working * The 5 Principles of Human Performance: A contemporary update of the building blocks of Human Performance for the new view of safety by Todd E. Conklin PhD (https://www.amazon.com/Principles-Human-Performance-contemporary-updateof/dp/1794639144) * Context Drives Behavior * How Leaders Respond Matters * Set Up The System So The Right Thing Is Easy 26:46 - Moral Obligations and Social Norms: Top Down * PAPod 36 - Martha Acosta Returns - The 4 Things Leaders Control (https://preaccidentpodcast.podbean.com/e/papod-36-martha-acosta-returns-the-4-things-leaders-control/) * Roles * Processes and Practices * Values/Norms * Incentives 31:20 - Personas: Translating Ideas and Principles Into Action * Software Security: Building Security In by Gary McGraw (https://www.amazon.com/Software-Security-Building-Gary-McGraw/dp/0321356705) 37:04 - Putting Accessibility Into Action * Knowledge Building: Iterate * Giving Access * “Appreciate the bunt.” * Clearer Consequences * Greater Than Code Episode 162: Glue Work with Denise Yu (https://www.greaterthancode.com/glue-work) 51:06 - “Disability Dongles” – Liz Jackson (https://www.cbc.ca/radio/spark/disabled-people-want-disability-design-not-disability-dongles-1.5353131) * The Lows of High Tech – 99% Invisible (https://99percentinvisible.org/episode/the-lows-of-high-tech/) * Infrastructure Disables Blind Navigation * The Models of Disability (https://www.disabled-world.com/definitions/disability-models.php) * The Pretty One: On Life, Pop Culture, Disability, and Other Reasons to Fall in Love with Me by Keah Brown (https://www.amazon.com/Pretty-One-Culture-Disability-Reasons/dp/1982100540) Reflections: Michele: Finding room for everyone to provide their perspective. John: The real solutions are infrastructural. Rein: Accessibility has to be built-in throughout the process of building and designing software. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: REIN: Hello and welcome to Episode 257 of Greater Than Code. I'm your co-host, Rein Henrichs, and I'm here with my friend, John Sawers. JOHN: Thank you, Rein, and I'm here with our guest, Michele A. Williams. She's the owner of M.A.W. Consulting (Making Accessibility Work). Her 16 years of experience include influencing top tech companies as a Senior User Experience Researcher and Accessibility Consultant, and obtaining a PhD in Human-Centered Computing focused on accessibility. A W3C-WAI Invited Expert, international speaker, published academic author, and patented inventor, she is passionate about educating and advising on technology that does not exclude disabled users. Welcome to the show, Michele. MICHELE: Thank you so much, John and Rein. Thanks for having me. JOHN: You are very welcome and we'll start the show as we always do by asking our standard question, which is what is your superpower and how did you acquire it? MICHELE: I don't think I have the most creative answer to this. [laughs] I kind of hate those, “Oh, tell us something fun about yourself.” But the thing I thought about that came to mind was my ability to not give into peer pressure. [chuckles] And some ways that manifests for instance, I have a technology background and yet I'm almost the least technical person like I was probably one of the last people to get a smartphone. I love my flip phone and you couldn't take it from me. So this idea that everyone's doing this social media, all of that, I just joined Twitter last year. So I do things dagnabbit; when I need it, not necessarily just because there's groundswell. So I would say that's pretty good superpower. JOHN: All right. So you gave some examples there in your personal life with technology and social media. I assume that that's also a fairly powerful capability in a business context as well. MICHELE: I think so. Particularly when you're advocating for say, disabled people who aren't necessarily always advocated for, it definitely helps to have a more strong will and the ability to take a stance that turns others rather than consistently feeling like you're being turned around about what others want you to do. So I agree with that, thanks. JOHN: [chuckles] Excellent. And so it looks like you've been involved in the accessibility world on a number of different angles and capabilities and so, what have you found to be the most impactful of those? MICHELE: I tend to want to reach people who are outside of the accessibility world. Unfortunately, I think sometimes accessibility people can tend to talk to other accessibility people a little bit too much. I tend to like to recognize that it is something that everyone in the world should know a little something about. It is an expertise, but there are some ways that everyone can do it. I just recently wrote an article for A11Y Project called Everyday Accessibility. That's when you're making a Word document, for instance, using the Ribbon, using headings, and buttons, or bulleted lists. So I tend to want to bring everyone on board, and demystify accessibility and make it more attainable and easier to grasp and that feels so much like this expert field that takes years to break it down to those tangible pieces that still make a big difference. REIN: One of the things that I hear a lot when abled people are advocating for accessibility is, “Sure, this helps disabled people, but you should care about it because it helps abled people, too.” How do you feel about that? MICHELE: So that's a conversation that's been coming up a lot, too and I have a particular colleague that sent me their response, for instance and it's a stance that I don't particularly align with because the problem with that stance is you end up keeping the status quo. So there are real consequences to being in a society that does not value disability and you, as someone who doesn't have a disability, do not feel those effects. So until we are a more equitable society, we do have to call out the characteristics that make someone have negative effects. So the reality is yes, there are things like situational impairments, which is when the situation you're in mirrors the impact of a disability such as walking and texting—you're not seeing out of your periphery—or there's temporary disabilities, like you've broken your arm, and then there's just the natural process of aging. All of that is true and you can also figure designing for your future self for that last part. But again, I think that we have to be very mindful that right now we need to overemphasize and think about disability until it is our normal way of thinking. REIN: It also seems like it's conceding the ground that doing what's right for disabled people is enough of a justification. MICHELE: Explain that a little bit more, what you mean by that. REIN: So when you say it helps disabled people, but it also helps abled people, it seems to me like you're saying it's not enough for me to just say that this helps disabled people. I have to give you another reason. MICHELE: Absolutely, absolutely, and that ties back into ableism and the invisibility of disability and the devaluing of disability. Like you said, it's like a disabled person is not enough. It has to also include absolutely right with that way of thinking and that's another reason not to go that route of segmenting it in that way. JOHN: I think this ties into something that you had mentioned earlier that I find really interesting, this idea that able people are doing something for disabled people. MICHELE: Yes, and that's the big thing. When you say like, “What's been on your mind lately?” That's the one that comes to mind and it comes to mind for a couple of different reasons. None of them new, none of them – I did not discover any of this; people have been saying this for decades upon decades. But for me, my personal experience, I will give a talk, an accessibility talk, I might explain something about say, screen readers, or some other technology, or a particular disability and then the response is, “Well, it should work this way,” or “We should do this.” There's a lot of solutioning around what I've just presented without any context of ever having met say, a disabled person, or particularly a person in the disability community that has been talked about and that comes, I think from this idea, a couple of things. One, again, this idea of a power structure where, “Well, I'm doing this for you, disabled person.” Not understanding the empowerment that the disabled person has, or this misunderstanding and again, invisibility of disability in spaces like tech innovation and not understanding, okay, that touch screen you're using, that text-to-speech you love, those captions that you use at the bar; all of these things [chuckles] came from disability. We erased the innovation that came from someone designing for themselves and designing for their ability and it's assisted technology and therefore, it's an add-on when it's for disabled folks, but it's innovation when it's for people who don't have disabilities. I think we need to have a lot more discussion about this, particularly in spaces like user experience, where we're supposed to be all inclusive and all about the user. There's some ways that we really are reinforcing this mindset and this power structure, for sure. JOHN: So I want to check my understanding of what you're saying, just to make sure. Are you saying that when you present a problem, accessibility problem, the abled people, the other UX designers, the other people who want to be helpful jump in with, “Oh, we can do this, we can do that, or that” rather than saying, “Well, let's go talk to some disabled people and find out what they need and let that guide how we solve this problem rather than us just being like, ‘Oh, it would be great if dah, dah, dah, dah, dah.'” MICHELE: So to two stages to that. For the first one yes, that's the first thing that happens. In the assistive technology, broad accessibility world, this manifests in some very familiar ways. The first is the blind navigation. Every year, some engineer thinks they've solved blind navigation, pedestrian navigation. Meaning they've created a belt with vibrations on the left and right with an Arduino, or something and they go, “You don't need a cane anymore because it's going to vibrate left when you need to turn left and right when you need to turn right, and you can walk like a sighted person,” or some variation of that—robot guide dogs, smart cane, something like that, or the sign language gloves, or the stair climbing wheelchair. There's these sort of assistive technologies that always come out with very little context around whether it's actually happening, whether it's actually needed. But then there's something John, about what you said, too about let's see what people need and we'll build it. We have to be careful even with that, too because that assumes that I can't build for myself and that's not true either. [chuckles] Disabled folks are the most innovative people because the world is not accessible. There is a such thing as a specialty. Like I have an accessibility specialty, I have a design specialty, but I think we often think that's someone without a disability. No, a disabled person can also have these specialties, or they can be someone who has the idea of what they need and you're partnering with them with your specialty in say, design to create those solutions. So again, I think we have to be very careful about our wording and our viewpoints of what's actually happening. REIN: There's a framework that I've been using for this that actually comes from aviation safety and there's a European aviation safety magazine where Cormac Russell published an op-ed called Four Modes of Change: To, For, With, By. The idea is that change to is the mode where change has done to us without us. So this is a sort of authoritarian top-down thing. We've got no say in the matter. It's not even necessarily for our benefit. Then change for is a benevolent top-down approach. “I'm trying to help you, but I'm the one who decides what to change.” Change with is a participatory co-creating the change. And then change by is change done by us for us where if I'm, for example, a manager, my role would be find out what support you need so you can make the changes you want to make. MICHELE: Absolutely. Perfect. Thank you. I knew there was some reference. This appears in disability justice spaces, in any kind of space where you're talking about inclusion, we know that sometimes inclusion can be code for do things the way that the current power structure does it. Do things the way that the current people in charge of comfortable and assimilate rather than no, we're actually going to allow you to be your authentic self and come into these spaces. Part of the reason this has also been on my mind is because I fit into some of these other spaces as a woman and as a Black person. I think that sometimes my cohorts think well, because we have experienced some of that in our lives, we are immune to them giving that out to others. So as a Black person, a woman, even someone with intersectionality, I can't possibly do that to do was done to me to someone else. But we don't realize how much ableism is steeped into our society, such that it is very easy to do that with disability and not even realize it and not even realize you have the mentality that someone is inferior to you, incapable, and particularly when the disability has to do with neurological, or anything that we really don't understand. But even still, even that kind of categorization can go away because the idea is that any sort of disability triggers usually some sort of ableist response and these things can happen even if you've experienced it yourself. JOHN: So like so many of the other things we discussed on this podcast, it sounds like the real work of accessibility is organizational change. It's getting the power structures to change to allow these things to come into being rather than forcing them in there, or trying to – like you were saying, not forcing the change on the disabled people to fit in. MICHELE: I've been thinking about the roots of this, for sure. And thank you for that. Unfortunately, capitalism drives a lot of this and again, if we're talking specifically more to tech worlds and say, including accessibility into your tech, part of that is just because the buy-in sometimes comes from the internal stakeholders, not the end customer. Again, if you're not mindful, not careful, and don't have leadership that are careful. So the dirty little secret is for instance internally yes, you may be making education software for students, but you're really marketing to the teachers who are going to buy it, and you're then even more so really marketing to whoever the management structure is internally who's going to approve it to even be on the market. So you get further and further away from actually helping a student because you have all these other checks that it needs to impress, or you need to make the case for similar to what we were saying earlier, you have to make the case for disability. For instance, you have to say, “Well, blind people to do this.” You get this pushback of, “Well, blind people don't do that so we don't have to worry about it and you keep moving on.” So there is a shift that is hard, but I do think it goes back to what I was saying earlier about taking a stance. I think that people do need to individually start to take the stance that that may be how we do things now, or how it may even need to be done. But we do want to be careful buying into that completely because it's going to perpetuate the same. We know that that power dynamic internally of who the stakeholders are, again, also sometimes doesn't reflect the diversity of who we are designing for. We're going to keep getting the same result if we're not super mindful and super careful to take the stance that we are going to care about the diversity of the end users, the people that ultimately will have their hands on what we're making and celebrate that oftentimes those best solutions, again, come from the community who are doing the work. So celebrating the innovation that comes from being tied back to those end users rather than thinking the solution has to come from within. So changing that mindset around this difficult, but it takes taking a stand and recognizing it, too. JOHN: So it's trying to change my thinking around to the by style change around accessibility and my context is on the team of web developers who develop apps that are eventually used by some disabled people. So I'm trying to think about obviously, we need buy-in from the power structures as a company and to spend time on the work, but deciding what work gets done needs to be – that's where the inclusion comes in and I'm curious about what the steps are there that helped me get to that point where those people are included MICHELE: So here's a few ways that that comes about. One of it could just be, okay, this is the feature we're doing and we're going to make sure that this feature that we're doing—however that came about—is assessable. That can come from anything from how you're going to code, like making the decision to use standardized elements that come with accessibility built-in, or whatever knowledge building you can do internally to just bake it into how you are creating that feature. Then there is what is the feature and making sure that that, if nothing else, is as inclusive as possible, or at least not exclusionary. You're not making a feature that will exclude people. Again, that comes from an understanding of who is the audience and making sure everyone understands that. No one, I don't think has fully solved for how to make accessibility the thing that everyone knows does – it's difficult. It takes time. It takes training. It takes science from top down as well as then knowledge from the bottom up. It's a journey. But I think that there are places where decisions are made, that you know you're going one way, or the other, whether it's, I'm using a div, or a button, [chuckles] whether it's we're going to wait to put captions, or we're going to go ahead and build in time to do that, whether it's, again, we're going to put in this very visual feature, or we're going to take a little bit more time to understand how to have an alternative to that feature. So there's lots of places where you can be very intentional, that you are going to take the steps to learn about accessibility from your point of view and then incorporate it. REIN: So let's say that your VP of engineering mandates that every project has to meet a certain accessibility score, or something like that, but you don't train the developers. So you were saying top down and bottom up have to come together. I have seen things like that lead to some pretty dysfunctional ways of working. MICHELE: I can see that [laughs] and I think part of that comes from a misunderstanding that accessibility is not just something you say we're going to do. Like, it's not like we didn't do it because we just simply forgot, or we didn't do it just for reasons that can then you can flip a switch and turn it on. People aren't doing it because they weren't taught it, they aren't fully aware of the diversity of it, they aren't aware of what's required, and then leadership isn't aware. Therefore, that steps have to be taken. So there's a lot of rally around let's be inclusive, let's be assessable, but then there's less so when you learn oh, that means we have to maybe take half of the time to train and disrupt our workflow, or we have to do our workflow differently, or we have to go back to the code we've already written and been using for years and fix it. Those are some real decisions and those are some real consequences sometimes to that, too when you're a business that is expected to constantly move forward, but they are decisions that have to be made in order to actually put it in place, not just say you are for it. REIN: Todd Conklin has a book, The 5 Principles of Human Performance, and there are two that I think are especially relevant here. One is that context drives behavior. So if you want to know why someone is behaving the way they do, the thing to look at is the context that they're operating in, and the other is that how leaders respond to matters. When I think about this, I think if you have a design systems team, is that design system built to be accessible from first principles? Is the easy thing to do grab a component that's already designed to be accessible, or is the easy thing to do is throw a div on the page? MICHELE: Yeah, and there are, I think that the number one takeaway is none of it is easy because all of it is late. So there are initiatives like teachaccess.org; we really need to be embedding it in how we even learn the things that we learned, because then it does feel like we're almost disrupting industry to do this. When in reality, we just learned it wrong. [chuckles] We learn to cheat and to make it look and feel the way I want it to look rather than learning that there was a reason there's this thing called a button versus this thing called a div. Now, recognizing, too, though that standards come after innovation. So you can't standardize something that hasn't really even been explored, or even invented yet. So we understand that as you want technology to advance, it's more difficult to then say, “Okay, there's a standard for this and that will guarantee us accessibility.” So for instance, using native HTML elements isn't all, or when we look at mobile, native mobile elements is more difficult to do. This is still a new space, a growing space and so, sometimes we don't often know what that looks like. But that then requires again, that awareness piece of what disability looks like and this is where they're trying to catch augmented reality and virtual reality with XR Access and accessibility initiatives. Because if you're at least aware of the diversity of disability, you can catch it early enough so that when the standards come out again, we're making it less hard. Someone on a panel I was on last week, talked about like tech debt and this idea of well, it can be overwhelming. Well, if you have less things you need to maintain, it's less overwhelming and that comes from using standards and being aware of standards. You lessen your tech debt; that becomes part of the overall responsibility of standards bodies, for instance. So there are some again, tangible steps that I think just need more awareness and talking about over and over again until we get it right, that can be put in place, should be put in place. Hopefully, it will be put in place to make this less daunting over time. REIN: Yeah, and then on the how leaders respond thing. If someone builds something that's not accessible to you, do you punish them to just drive that behavior underground, or do you say, “Why weren't they able to do it? Do they not have the right expertise? Were they under too much time pressure?” How can I make the context better so that people are more likely to do the behaviors that we're trying to lead them towards? MICHELE: Yeah. Thinking a lot about that, too. So I tend to have two ways. I guess, it's sort of the carrot stick kind of thing, or maybe some other dynamic like that, but we know some people are going to get the altruistic side. Again, awareness. They just weren't thinking about disability. It's not something that's in their life. It's not something that was exposed to them. Once someone is exposed and understands a little bit of the work that needs to be done, they're bought in and they go for it. There are other folks that just are ablest. They just will not care. If it has not affected them personally in their lives, they are going to look – maybe like you said, maybe their motivations are something like money, even though they don't realize they're excluding more consumers. Whatever those things are, they're just not going to buy in. That's when unfortunately things like the threat of lawsuits, or bad publicity has to be the way that you get those folks to turn around, or again, you just do it. [chuckles] So that's when maybe the folks on the ground can just do it regardless and the one thing, I think about is this video that went around with this little baby and there was a parent and a teacher aide. I presume the baby was supposed to be doing their sound it out cards, flashcards, but didn't feel like doing it. The little baby sitting on the floor back turned, the mom and the teachers, they did it. They did the sound out cards. The baby's looking back still playing, but keeps looking back and eventually, the baby goes, “Wait a minute, that's my game,” and next thing you know, they're playing the game. So there is something also, too to like you said, maybe it's just a peer pressure thing. No one else seems to be doing accessibility so why do we have to be the ones to do it? But if the cool kids start doing it, if the company start exposing that they are doing it, if there's enough groundswell, people will just get on board with the thing that everyone is doing, too. So I think maybe there are three ways now—maybe I've added a third in my mind. There are ways – as a user experience person, I say user experience the person that you're dealing with. Like you said, get in their head, what are they thinking? What do you think they would want? But ultimately, understand that it isn't always going to be because it's the right thing and the faster you learn that, the more you might be able to actually get some results, too. JOHN: Yeah. I like what you said there, Rein about set up the system so that the right thing is easy and I think obviously, there's a lot of work to get to that point where you have the whole system built around that. But once you can get there, that's great because then, like you were saying, Michele, there's so much less effort involved in getting the thing to happen because that's just how everyone does it and you're just pulling the components are, or copy pasting from the other parts of the code that are already accessible so that it that stuff is already built into the process. And then it doesn't have to be quite so much of an uphill. Like even just uphill thinking process where you have to think differently than you used to in order to get the thing done in an accessible manner. MICHELE: Yeah. Again, unfortunately it's not embedded within us to do this, but maybe the next generation will, maybe the next couple of generations If we keep talking about it and we take the effort to start to shift ourselves, maybe it will be the thing that people can't even remember when they didn't do it. I do feel like we're in a cool moment right now where that might be possible. I'm hearing it more and more. I didn't learn it in school when I was doing computer science and software engineering, but I know some students now that are coming out that are. So I'm kind of hopeful, but the conversations really need to be said aloud and often in order for it to happen, for sure. REIN: You mentioned the larger structural problem here, which is that designing accessible software is a moral obligation and we work in an economic system that's not optimized around moral obligations. Let's put it that way. MICHELE: Yeah. [laughs] That will dollar. [laughs] I think again, there's that school, are we changing that, or we're going to work within it. I think you can do both. Some people should – we should really be tackling both, any kind of inclusion efforts, same thing. Do you do it from within, or outside? Do you work within the structure, or do you dismantle it? I think there's benefits to both. I think there's benefit to basically editing what isn't working about what we're currently doing. There's always an improvement and I tend to look at it that way. It's not so much as it's down with this and up with that. I think we just need to recognize, as human beings who can evolve and do things different, learn, grow, and get wiser, let's just do that. Let's do what we're doing better and when we recognize that we have a negative effect, let's solution something that is going to work better and just recognize that and do better. It's okay to edit. So I don't think we have to toss our hands up and say, “Oh, we'll never get there because of how this is.” That was invented, too. All of these things are constructs. At some point, the way we do things wasn't the way we did things; we did things completely differently. Empires can fall and rise and be redone. So we don't have to stay stagnant, but we can, again, start to make these changes. REIN: I think that even within a capitalist system, there's still a place for social norms. There's still a place for deciding which behaviors we're going to accept and which behaviors we're not going to accept and what we're going to do about those. I just wouldn't expect that to be the CEO's job. I would expect that to be the entire community of the company. MICHELE: The entire community with the CEOs. So the two companies that are the pillars, for instance, of accessibility, Microsoft and Apple, you hear their CEOs say, “We do things accessibly.” So it's not necessarily on them to forego stakeholders and stock prices and all of that. Certainly, you can't do too much if you don't have a company, so they have to do what they have to do, but there is still an okay from that and that's part of that top-down. Again, we need training. Is there money in the budget for training? That has to come from management. So there is still a recognition and it's just always beneficial when everyone is on the same page that this is how we operate; the message then doesn't ever get disconnected. It just shifts to the role of a person and they put it into practice in their own particular way. REIN: Martha Acosta, who is one of the few original women in safety science, she says that there are four things that leaders can control, or have leverage over—there's roles, there's processes and practices, there's values, or norms, and there's incentives. So I think this ties in with what you're saying about what the CEO's job could be. MICHELE: Versus stock prices? Yeah. [laughs] Versus yeah. Which unfortunately is, again, I think it's even upon the CEO to take a stance on what they are going to do with their company and their time. Because certainly, the pressures are coming to them sometimes not necessarily emanating from them. So I think there is opportunity, this is why there's opportunity for everyone to evaluate what are we doing. Like you said, we can decide what is important, how are we going to go about this? And if enough people start to be even more mindful than they were yesterday, shifts are going to inevitably happen. And people who disregard others, discriminate all of these other negative effects that we've seen will inevitably have less effects because the norm will be these other ways that we're trying to include and get better as a society. REIN: So one of the things I like to think about when we have guests, or ask guests to think about, is to think about this challenge from the perspective of a few different people. A few different personas. So I'm a manager, I'm a line level manager and the people that report to me are engineers. What can I do? Or I am a mid-level engineer, what can I do? How do we translate these ideas and principles into action? MICHELE: So what is to understand that there are, for instance, guidelines like there are web accessibility, web content, accessibility guidelines, or author and tool guidelines, because we do need to define what it means. At some point, there needs to be metrics and there needs to be measures that need to be placed to understand, did we do this? One way to do that is to translate those into those various roles. Some of that work has happened and some of it needs to happen. So there's understanding the tangible actions that can and should happen. But I think also, it's simply a matter of deciding that accessibility and inclusion and particularly in my world, disability is just going to be a part of everything. Every check that you make for whatever your role is. You were talking about different frameworks for different levels. Certainly, that's true. I think that we tend to separate out disability from those kinds of conversations as if it's different. It's not different. Making decisions for how you're going to manage your employees should be inclusive of disabled employees. The tools that you want them to use, the ways you want them to work, how “productive” you want them to be, how you're going to measure that. All of that should be mindful of the variety of people that you are supporting. Same with I am a developer so that means that I am writing code on behalf of a group of other people and that means I need to know who these people are. It's funny you say personas because—I know that's not probably what you meant, but in my role, obviously that triggers the user experience personas, which I'm not a fan of. That's all another podcast. [chuckles] But when we're talking about that so in user experience we're saying, “Oh, we're designing for these people, these target audience per se.” It'll be John who's the manager and he does this on his way to work and then there's Mary. Maybe she's a stay-at-home mom, but uses it this way. Dah, dah, dah, all these other characteristics. And then we'll go so now we need disability personas. No. [chuckles] John can also be quadriplegic. Mary can also have multiple sclerosis. So again, it goes back to the idea that we have separated out and made invisible disability. Oh, taboo. Even the word oh, it's taboo. Can't talk about disability. REIN: Yeah. Like imagine having a separate persona for a woman, or a Black person. MICHELE: Thank you. We don't do it. We don't do the whites only school and we'll get to the Black people later. We know that intrinsically, but we do it in everything. So same thing particularly when we're talking about inclusion of disability in all of these phases of say, an organization, we go, “And disability.” No, no, no. If we really want to think about it, disability is the equalizer. Anyone can become disabled at any moment at any time, it does not discriminate. It is the one thing that any human being can become at any time and yet we still separate it out as if it's this taboo, or a terrible thing. Now, again, there are negative outcomes of disability. Not saying that, but we have this tendency to segment it in ways that just absolutely don't make sense and aren't necessary and are detrimental and make it more work, so. REIN: There's a book called Software Security by McGraw. It's kind of old now, but the premise is still very relevant, which is that to make software secure, you have to build security in at the beginning, and you have to keep constructing and repairing it throughout the software development life cycle. So it starts with design, but it includes, you talked about different touchpoints in the life cycle, where you want to sort of check in on whether you still are as secure as you think you are. So that includes design. It includes code review. It includes testing. I wonder if this sort of an approach works for accessibility, too; we just sort of bake it into the fabric of how you design soft. MICHELE: It should be how it works. The moniker is shift left. That's absolutely what has to happen to do it well. You have to be thinking about it all the time. Everything that you do. So that's how my mind works now. It took a long time to do that. But now when I'm sending an email and I put a picture in, “Okay, let me put the alternative text.” I'm making a spreadsheet, “Okay, let me do the heading.” Like, I'm always constantly checking myself as I'm doing anything. “Okay, if I'm doing a podcast like this, is there a transcript, or are there captions?” I'm just constantly doing these checks. That takes time to build up, but it is the way you have to do it to make sure nothing slips through the cracks so that all the hard work that say, the design team, or the dev team did, and then QA comes in and doesn't know how to test it. We're all interdependent so it has to be everyone all the time, all throughout the process in order to get it from end to end to work; the weak link in the chain will break that. So very much how it has to go. REIN: It also seems like this there are small, actionable things that you could do to move in this direction. So for example, when you do code review, ask some accessibility questions. Maybe build yourself an accessibility checklist. Now I don't like checklists, but that's a whole other podcast, but it's better than not thinking about it. MICHELE: Yeah. As you're learning something, sometimes the checklist is helpful because you don't yet have it in your own mind and you don't want to forget. Now you don't want to – I'm sure what you're saying is you don't want to tie yourself to the checklist, too. REIN: Yeah. MICHELE: But as you're building up knowledge, yes, there are so many just tangible did I do this things that you might as well just keep a sticky at your desk, or however you want to do it and just start doing those things. Again, we don't have to keep talking about it. It doesn't have to be this revelation of inclusive buy-in in order to put captions on your videos. [chuckles] These things, you know. REIN: Yeah. This also seems like an opportunity for tech leads to do leadership to say, “Hey, so I looked at this and the contrast ratio is a little bit low. Do you think we could punch this up in a code review?” MICHELE: Yeah. The only thing, though is back to the beginning—being careful about these directives, making sure you understand the directives that you're doing because again, a lot of times, particularly when people are new to accessibility, they overdo it. So they hear a screen reader and they think it needs to read like a novel so they want to add in a summary of the page in the beginning, a summary of this section, and they want to overly describe the alternative text, the image down to the pixels. There's some give and take there, too. There's some learning you want to do, but you can iterate. You can learn one piece, get comfortable with it. Okay, now that this next piece. Knowledge building it's just what it is, is what it is. So there's absolutely knowledge building that you can do to get more comfortable and we need everyone to do this. There's certain parts that should be specialty, but unfortunately, the specialists are doing what everyone else should be doing the basics and so, we've got to shift that so that the specialists can do the specialty stuff, the harder stuff that may not quite get – [overtalk] REIN: That's exactly the same problem is having a security person on your team. MICHELE: Absolutely. So it sounds like you all have a focus on implementation. Like you're implementing and you want to know how best to make – I'm turning it on [inaudible]. [laughs] So you want to know how best to make it work for you, or is that what I'm hearing? REIN: I guess, I lean towards practice. I want to understand the theory, but then if I can't put that theory into practice, the theory is not very useful to me. If that makes sense. MICHELE: Absolutely makes sense. My company name is Making Accessibility Work and a lot of what I say is put accessibility into action, because I am very much tied to this idea that you can be absolutely on board with accessibility and not have any clue how to do it. [chuckles] And then the inverse can be true, too. You can absolutely do not care, but because you care about semantic HTML, you're doing more accessibility than the person who cares. There are these places that people can be in their understanding that neither one is actually, or you think one is helping, but the other actually is. I think people think you have to care. You have to want to Sometimes, you know what, you don't. Sometimes I just need you to fix the color contrast, [laughs] or yes, it's great that you care, but in doing so, you're actually, co-opting a message. You care a little too much and you are actually not letting disabled people speak for themselves because you've now discovered accessibility and now, you're all about it. So I think we've got to meet in the middle, folks. Let's care, let's do, let's demystify, but also understand there are some harder problems to solve, but understand where those are. Putting headings on the page is not the hard problem we need to solve. Just put the headings, making math and science more accessible, particularly when we've made it so visualization heavy. Yeah, let's go over there. Let's tinker with that, folks and that's where we need to be putting all this massive brain power. We've had Web Content Accessibility Guidelines for 20 years. HTML5, which addressed a lot of semantics for accessibility, has been out a decade. Y'all, hurry up and learn that and let's get that going so we can get over to this harder stuff. Get this brain power over to these more complex issues and newer innovations. JOHN: Yeah. I think if you're one of those people that cares, like you were saying, a little too much, or perhaps just a lot, you can end up with option lock because you want to solve all the problems and then you're just like, “But what do we do? What are we doing here?” Like, I'll just put the headings in, put the alt texts in, we'll start there. You've got to get moving. And that's partly where I'm coming from with some of the questions I'm asking is that process of just getting that boulder rolling a little bit so that it takes a little bit less effort to keep going in the future. MICHELE: Yeah, and there's no perfect way to do it. I think everyone's looking for okay, well, how do we do it? You're going to spend a year on how and again, miss the year of what and doing it. It is messy because you're hiring people, you've got people working who don't know how to do it; it's going to be disruptive. We didn't come in with this knowledge. I know you didn't hire people to then train them up and send them to school but unfortunately, you've got to do that. People need to know what to do differently, what they're doing wrong. So some of it is going to be experimental, iterative, and messy, but in the end, start giving access. We talk about language even. Do we say disability? Do we say people with? Or do we say disabled people? And do we say differently abled? Even these – okay you know what, the reality is you do all of that and still don't get access. What would be better is if you have a person with a disability at the table to tell you themselves, but you're worried about language and yet can't even hire someone with a disability. So again, it's getting out of these little zones that we sometimes get in and recognizing the real work that needs to be done and can get done today. REIN: I think there's a real temptation to fixate on the hard, or interesting problems in the tech world that might be wanting to build this distributed database with five nines of durability. But your API server has a bug where 1% of the requests are an error. So if you don't fix that, your five nines over here are useless. MICHELE: The flashy thing, yes. [laughs] The shiny thing, we want to gravitate. Oftentimes, there's no glory in what was considered the grunt work, the foundational work. But I think that's where leadership could come in. I heard someone say years ago, “Appreciate the bunts” in baseball that oh, chicks dig the home run. We love the home run, but sometimes, that bunt wins the game. But that's where a leadership can come in and appreciate laying found a scalable foundation of code that does not add to tech debt, or the diminishing of the bugs that you've kept rolling year after year after year, you close 50 of them. That's where, again, a change in mentality of what we value. Sometimes again, accessibility is not put at the front because sometimes it's just code changes that aren't visible to users. So users are going to think you spent a year and didn't do anything to your code, or some of them will. But again, I think that's a messaging and that's an appreciation of really trying to do, and that's even appreciating software engineering versus just COVID. I have a software engineering degree and that's when I realized, “Oh, we're not just supposed to sit down and start hacking away and make sure it runs for the teacher to check it and we're done.” There's an engineering to this, but you have to value that. But also, I think there needs to be clearer consequences like speaking of engineering. If it's a building, we know the building can collapse. I don't think sometimes we appreciate what can happen if we don't do that foundational work and I think that's a shift overall and then technology and appreciation of that work. REIN: And I appreciate what you did there, which was to subtly redirect me back to the context and to how leaders respond. Because if building that five nines database gets you promoted and fixing that bug doesn't, what are people going to do? MICHELE: Yeah. So what's valued and that's set. Someone sets that. That's made up. You can value whatever you want to value. You can praise whatever you want to praise. Complete tangent, but that takes me to my high school where they were intentional that the students who performed well were going to be recognized by the principal because oftentimes, it was the misbehaving students that went to the principal's office. So the principal knows all the misbehaving students, but doesn't know any of the students that are doing the actual work that the school is asking of them to do. Not trying to get too much into school systems but again, it's an intention that you will honor the work, the unseen work. We do these in other spaces; the behind-the-scenes work, the unsung heroes. That's an intentional step that you can take as well to celebrate that, too. REIN: We have an older episode on glue work and how valuable glue work is, but how rarely it's acknowledged, or appreciated, especially by leadership and also, how it has a gender characteristic, for example. It seems to me like it might be easy to put accessibility in the category of glue work rather than in the category of like you were saying, foundational things that make us have a reliable product and a product that works for everyone. MICHELE: And I don't know if how we've presented technology to consumers plays into that as well. Again, the new flashy wow. The other day, I just looked down at my keyboard on my computer and I just thought about we just take such advantage of the fact that I'm just sitting here typing on the keyboard. Someone had to decide what the material would be that doesn't scratch my fingertips. Someone had to decide how to make the letters so that they don't rub off, or how they light up in the back. There's so much detail that goes into almost everything that we use and we just get so dismissive of some of it. “What's next? Eh, that's okay.” So I think, again, it's a human condition. It's the human condition to appreciate what people are doing for one another in front and behind the scenes and absolutely. But I think that also ties into, again, ableism, too. We see in assistive technology, or an adjustment because of disability as okay, that thing we can do later. But then when it becomes Alexa, when it becomes the vacuuming robot, when it becomes the new latest and greatest thing, then it's front and center and everyone wants to work on it. But it's the same technology. [chuckles] It's the same reasons that you should do it. It just happens to benefit everyone. It came out of disability, but you didn't want to think about it until you've found a benefit for all the “others.” Again, I think that's a human condition we have to correct. REIN: There's a thing that happens once a month on Twitter, which is someone will post an image of pre-sliced vegetables and they'll say, “What kind of a lazy loser needs pre-sliced vegetables?” And then someone will respond, “Disabled people need pre-sliced vegetables.” And then the response to that will either be blocking them, or saying, “Oh my God, I'm so sorry. I had no idea.” I think that there's maybe that dynamic going on here as well. MICHELE: Absolutely what I was thinking about, too, like Nike's shoes recently that you don't have to tie. Well, who doesn't want to sit down and tie their shoes? People who can't sit down and tie their shoes, but that was also a marketing issue. They refused to market it for disability. Like where were the disabled people? Where were the people with chronic illness, or chronic pain, or body size that just does not lend itself to bending over and tying your shoes? Why did it have to be marketed in that other way that then took away the messaging that this is a useful piece of equipment? REIN: Yeah. Like why is this fit model not able to tie their shoes? MICHELE: Exactly. Rather than take the angle that – again, they're all made up. Someone just happened to decide laces. We could have very easily decided this other way at the beginning. We could have very easily decided Velcro was the way. We just, I don't know, somewhere along the way, came up with laces. I think people in general have to go through their own journey of recognizing that what they were told was fact, truth, and stance just with someone's made up thing. Even these companies that we've just hold as pillars started in garages. They may have started in garages a 100 years ago, rather than just 50, or 20 years ago. But these things are just built. So we can build them differently. We can say them differently. It's okay. So taking away that stigma that things have to go a certain way and the way that they've been going, or at least perceived to have been going. We have got to start dismantling that. JOHN: Harking back here, a point earlier about the new shiny is always held up as always better. I read an article recently about prosthetic arms and how everyone's always really interested in building new robotic prosthetic arms. They're the new shiny, they're the cool thing to work on, and people feel good about working on them because they feel like they're helping people who need them. But that in a lot of cases, they're not better than the one that was designed 30 years ago that doesn't do a lot, but has at least a functional hook. They were following one woman through the article who had gotten one of these new ones, but it actually wasn't any better and she ended up switching back to the old one because she could get it to do the things that got her through the day and – [overtalk] REIN: Made with titanium. [laughter] JOHN: And you can clearly see that probably the people that are designing these probably weren't working with people bringing that feedback into the process enough and it was designed for rather than designed by. MICHELE: Absolutely. So Liz Jackson coined the phrase “Disability Dongle.” That's another one that comes up. The prosthetic, the exoskeleton, absolutely. The thing that non-disabled people look at and awe and look at what technology is doing, disabled people are over in the corner going, “That ain't going to help us.” [laughs] If you had asked, we would have told you we don't need that. I think we've also reached a point where we're at the harder stuff and no one's willing to tackle, I don't think always the harder stuff. So for instance, going back to blind navigation, one of the things that makes navigating difficult as a blind person—and I learned this because I talked and worked with like 80 blind people. [laughs] So one of the conclusions that came to with that infrastructure disables blind navigation, you don't need a smart – a lot of people espouse a smart cane. Well, they had this white cane, but it needs an infrared and it needs buzzers and it needs – okay, you're going to give people carpal tunnel. The battery on that is going to die. It's not going to be reliable. And in the meantime, the thing you could have done is educate people on putting stuff at head level. So the way that we design our street signs, for instance, we do everything very car minded. We do a lot of things for cars and we forget people also have to walk and so you put obstacles, or you can educate people about trimming your trees, for instance so people aren't running into them, or how they park their cars so that they're not in the way. Some of it is also just not a technology solution. It may be more an environmental and human education solution, but you can't tell people, who have signed up to work in technology, that they must find a technology solution. So they end up solutioning amongst themselves in ways that actually aren't helpful, but they make themselves, like you said, feel better and they promote within themselves. It's difficult to get people to undo that. JOHN: Yeah, it strikes me like you were talking about the wheelchairs that can go ramps, the exoskeletons, and there are certainly use cases for those sorts of things. But I think the distinction there is those are a solution to make the disabled people more abled rather than making the world more accessible. Like what they need is lower countertop so that in the wheelchair, they can still cook. That's what they need. Not the ability to walk upstairs, or have like you said, this awe-inspiring exoskeleton that just draws more attention to them and probably doesn't even solve most of the problems. MICHELE: I'm just going to say amen. [laughs] That is it. That is the thing we need people to get. So you'll hear about the models of disability, too. Sometimes you'll hear about – you should hear about the models of disability and when people extract that and summarize that, they usually pull out two, which is the medical model, which is generally what we've been under, which is the effects of disability and how that affects the person. Therefore, these things need to happen to overcome and this sort of again, hospital, kind of what the body's doing, or what the mind is doing mindset, which is opposite of one that people often quote, which is the social model. The social model says, “No, no society, the world, my environment is disabling me. If you would just give me something more adaptive, more inclusive, I'd be good.” So a lot of examples of that, I recently read a Kia Brown's book with a book club and you'll have to insert [chuckles] the link. The Pretty One is what it's called. Kia has cerebral palsy and one of the things that was a feat for her was putting her hair in a ponytail and it made you think about scrunchies and the makeup of that. What if we just made the mechanism to have maybe a little bit more to it to grab your hair and put it in the ponytail rather than relying on the fact that you have two hands that you can do that with? So those are the differences in the mindsets of our views of disability that we need people to shift and even go sometimes again, deeper into what it is you're really doing when it comes to inclusion. Are you really being inclusive, or are you saying, “Hey person, come on to what I believe is the way of life”? JOHN: So reflections, then. MICHELE: My reflection, or takeaway would be that my hope is that we can find room for everyone. Everyone who wants to create great tech, everyone who has an idea, everyone who has a contribution. I hope that that doesn't continue to need to filter through say, a non-disabled person, or a certain status of job title. My hope is that we're starting to recognize that there's room for everyone to provide their perspective and it can be valued and it can be included in the ways that we operate at equal opportunity. So that's hopefully, my reflection and my takeaway. JOHN: All right, I can go next. I think really actually the point that that's really sitting with me is what I had just said, which dawned on me as I was saying it, as we were talking in the last minute there about how the real solutions are, like you said, infrastructural. They're changing the form of society to make the disabled person able to do what they need to do rather than bringing them up to the level of whatever was currently built, or whatever that – and even there's a weird value judgment in saying, bringing them up to the level. I'm uncomfortable saying it that way. So just changing the thinking, like you said, the social model is, I think a powerful change and thought process around this, and I'm going to keep turning that one around in my head. REIN: I think for me, I'm coming back to the idea that just like security, accessibility has to be built in throughout the process of designing and building software. You can't have a part of your software delivery life cycle where that's the only place where you think about accessibility. You can't just think about it during design, for example, and you can't just have a team of accessibility experts that you go to sometimes when you need help with accessibility. It's really everyone's job and it's everyone's job all the time. MICHELE: I love it. I'm going to change the world. [laughs] Special Guest: Dr. Michele A. Williams.

Greater Than Code Episode #170: The Case for Vanilla JavaScript with Chris Ferdinandi (https://www.greaterthancode.com/the-case-for-vanilla-javascript) 02:50 - Project Gemini (https://gemini.circumlunar.space/) and Text Protocols * Always Bet on JavaScript 07:05 - Overusing Analytics & Tracking Scripts * Be An Advocate For Your Users / Ethical Obligations 12:18 - Innovations: Making Accessibility The Default 14:48 - Ad-Tech and Tooling * Partytown (https://partytown.builder.io/) * Fathom (https://usefathom.com/pjrvs) * Preact (https://preactjs.com/) * Alpine.js (https://github.com/alpinejs/alpine) * petite-vue (https://github.com/vuejs/petite-vue) * Svelte (https://svelte.dev/) * SvelteKit (https://kit.svelte.dev/) * Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes (https://www.youtube.com/watch?v=860d8usGC0o) * Astro (https://astro.build/) 32:08 - HTMX (https://htmx.org/) 46:30 - Frontend Development is Hard * SPA's and Transitional Apps * Federated Multipage Apps * Micro Frontends * Phoenix LiveView (https://github.com/phoenixframework/phoenix_live_view) * Joint Activity * Joint Cognitive Systems: Foundations of Cognitive Systems Engineering (https://www.amazon.com/Joint-Cognitive-Systems-Foundations-Engineering/dp/0849328217) Reflections: Rein: Vanilla JavaScript + Privacy. Jacob: The web piqued at LiveJournal. Also, encouraging devs to think about what tool would be best for different jobs. Chris: Maintaining privacy on the web. Sign up for Chris's newsletter at gomakethings.com (https://gomakethings.com/)! This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: Coming ASAP! Special Guest: Chris Ferdinandi.

02:47 - Anne's Superpower: Empathy & Collaboration * Feeling Accepted & Creating a Sense of Safety * Creating Happy Bubbles * Making People Feel They Matter on Teams * No Matter Status (i.e. Employees vs Contractors) * No Matter Geographical Location/Timezone * Equivalence in Remote Work 17:45 - Framing and Shaping Relationships + Communication * Changing Company Culture * Sharing Concerns with Upper Management * “We are all on the same team.” * Silence IS a Response * Working Through Challenging Conversations 29:47 - Helping People Learn – Work Therapists: Should/Could They Exist? 38:18 - Having Support Outside of Work: Networking * Find Communities First; Individuals Second * Attract Your Dream Job (https://pivotgrowhustle.com/dreamjob) * @pivotgrowhustle (https://twitter.com/pivotgrowhustle) * #BlackTechTwitter (https://twitter.com/search?q=%23blacktechtwitter&src=hashtag_click&f=live) * Making Sure People Know What You Do! 48:20 - Overcoming Job Responsibility Misperceptions * Managing Project Ownership and Roles * “Secret Agile” Reflections: Arty: Being able to find strength and solidity within yourself so you can be someone that helps to contribute to moving things in a positive direction. Casey: Coaching men on DEI. How could it be successful? Anne: The future of where we need to go as a society, especially a tech-driven society, is to ask yourself how do you bring what you love to the table and to do it with love. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Special Guest: Anne Griffin.

In this episode, Charles and Taras discuss "big ideas" and all the things they hope to accomplish at The Frontside over the next decade. Please join us in these conversations! If you or someone you know would be a perfect guest, please get in touch with us at contact@frontside.io. Our goal is to get people thinking on the platform level which includes tooling, internalization, state management, routing, upgrade, and the data layer. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES: Hello and welcome to The Frontside Podcast, a place where we talk about user interfaces and everything that you need to know to build them right. Today, we're going to talk about big ideas and the future of Frontside. TARAS: Yeah, starting with is Frontside is good idea? CHARLES: No, we're going to just talk about how do you know that an idea is good? We've touched on it a couple of times before. Like how do you, how do you go about validating a big idea, how do you discover a big idea? What do you do? TARAS: And then, even when you have big ideas like big tests, what does that mean for the world? How do you make a big idea an idea that a lot of people like and agree with and actually use on day to day. CHARLES: Yeah. It turns out that it's not easy. There's a lot of work involved with that. A lot of it crystallized around the conversations we're having about what exactly is big test and recognizing that big test isn't really a code base. It's not a toolkit. Even though it does has aspects of those things, it really is an idea. It's an approach. It's a way of going about your business, right? TARAS: Yeah. Especially when you put big test functionality in place, when you start doing big testing and then you put together things like using Mocha and Karma, big tests in that kind of test suite is really just like interactors and the idea of big testing. There's nothing else. All the interactors do is just give you an easy way to create composable like [inaudible] objects, so you don't have to write -- you have the components but you don't have to write selectors for each element in the component, especially if gets composed. But that's like a very small functionality that does a very specific thing. But big test itself, it takes a lot of work to actually -- we had this firsthand experience on the project we're working on right now. We are essentially introducing like Ember's acceptance testing but for React in a react project and having to explain to people what is it about this that actually makes it a really good idea and having people in the React world see that this is actually a really good idea. It's kind of incredible. When you actually try to sell something to somebody and convince somebody that this is a good idea is when you realize like how inadequate your understanding of the idea really is. You really have to start to break it down and understand what is it about this that is a really big idea. CHARLES: Yeah, I completely agree 100% because to be clear, we've actually been doing this now for two years almost. So, this is not the first React project where we've put these ideas in place. But I think in prior examples, we just kind of moved in and it's like we're going to do this because this is what we do. And we have firsthand knowledge of this working because we've operated in this community where this is just taken on faith that this is the way you go about your business. You have a very robust acceptance test suite. And because of that, you can experience incredible things. When you and I were talking before the show, we were kind of commenting on inside the Ember community, you can do impossible things because of the testing framework. You can upgrade from Ember 1 to Ember 3 which is a completely and totally separate framework, basically. You're completely and totally changing the underlying architecture of your application. You can do it in a deterministic way and that's actually incredible. TARAS: And what's interesting too is that the React core team kind of hinted a book at this also in their blog post about fiber or moving to fiber because one of the things that they talked about there is that knowing how the system is supposed to behave on the outside allowed them to change the internals of the free app framework, specifically about test suite for the React framework, but it allowed them to change the internals of the framework because they were testing kind of on the outside. The system kind of is a black box and that allowed them to change the internals and the test suite essentially stayed the same. So this idea of acceptance testing your thing is really fundamental to how Ember community operates. But other communities have this as a big idea as well. It's just applied in different areas. CHARLES: Right. And so applied to your actual application, this is something that's accepted in one place, but it's not an accepted practice in other places. But you can make your argument one of two ways and say, "I have experienced this and it's awesome. And you can do architectural upgrades if you follow the patterns laid out by this idea." And that works if you have a very, very high, high trust relationship, but you don't always have that, nor should you. Not everybody is going to be trusting you out of the box. So, you're going to have to lay out the arguments and really be able to illustrate conceptually practically how this is a good idea just so that people will actually give it a try. TARAS: And it takes a lot. One of the reasons why it was easier for us to introduce big testing to the current project we're working on is because we were able to write, like we've done the implementation for this in a previous project. So when we were convincing people this is a good idea, we're like, "Look, your test suite can be really good. It's going to be really fast. And look, we've done it before." So the actual process of convincing people that a big idea is a really good idea is actually kind of a complicated process that requires a lot of work and partially requires experimentation. You have to actually put an implementation in place and show that you're going to have to build up on your successes to be able to get to a point where you can convince people that this is actually a really good idea. People who have not heard about this idea, and especially people who might have counter, like they have people of authority in their community that have counter views. For example, quite often when it comes to big tests, when you bring up big tests, people will reference a blog post by a Google engineer that talks about how functional testing or acceptance testing is terrible. And for a lot of people, a Google engineer means a lot and the person makes really good points. But that's not the complete idea. The complete idea is not just about having an acceptance test suite. It's a certain kind of acceptance test suite. It's an acceptance test suite that mocks out at boundaries so you don't make API requests to the server, you make an API request to a [inaudible] server using something like Mirage or whatever that might be. So, the big idea, it has like new ones that makes it functional, but getting people who are completely unaware, who don't necessarily look up to you as an authority to believe you like, "Yes, that actually sounds like a really good idea." It is not a trivial task. CHARLES: No, it's not. Because the first time you try and explain it, you're arguing based on your own assumptions. So, you're coming to it safe in the knowledge that this is a really, really good idea based on your firsthand knowledge. But that means you're assuming a lot of things. You're assuming a lot of context that you have that someone else doesn't and they're going to be asking questions. Why this way, why this way, why this way? And so, you have to generate a framework for thinking about the entire problem in order to explain the value of the idea. And that's something that you don't get when it's just something that's accepted as a practice. TARAS: I think simulation is actually a really good example of that. If you haven't had experience with Mirage, if you don't know what having a configurable server in your tests does for you, you will probably not realize that similar ideas apply to, for example, Bluetooth that when you're writing tests for your Bluetooth devices, or you're writing tests for an application that interacts with Bluetooth devices, you actually want to have a simulation there for Bluetooth so that you can configure it in a kind of similar way to the way you would configure a Mirage for a specific test. You want to be able to say, "This Bluetooth device is going to exist," or, "I have these kinds of Bluetooth devices around me, they have the following attributes. They might disconnect after a little while." There's all kinds of scenarios that you want to be able to set up so that you can see how your application is going to respond. But if you haven't seen a simulation with something like Mirage, you're going to be going like, "I don't know what the hell why would this be helpful." CHARLES: It seems like lot of work. One of the things that we've been working on, as I said, is trying to come up with a framework for thinking about why this is a good idea because we can't just assume it. It's not common knowledge. For example, one of the things that we've been developing over the last year and more recently in the last few months is trying to understand what makes a test valuable. At its essence, what are the measures that you can hold up to a test and say this test has X value. Obviously, something like that is very, very difficult to quantify. But if you can show that and you say, "This test has these quantities and this test has these quantities," then we can actually measure them. Then it's going to allow people to accept it a lot more readily and try it a lot more readily. So, the ideas that we're playing with right now is that you kind of have to evaluate a test on one on speed, tests that are fast, have an intrinsic value, or rather test that are slow. The upside that you gained from the test is very quickly bled away or offset if the test is slow. So, I can have a very comprehensive test that tests a lot of high value stuff. But if it takes three days to run, it's going to be basically worthless. Another axis on what you can evaluate is in terms of coverage. I'm not talking about coverage of lines of code. I'm talking about use cases and units of assemblage. So, there's the module. Those modules are then stitched together into components. Those components are stitched together into applications. Those applications are downloaded onto browsers. And I would consider it a different unit of assemblage. Your application running on Firefox is a different assemblage than your application running on Chrome, is a different assemblage than your application running. You have this access, which is the coverage of your unit of assemblage. That's another way that you can evaluate your tests. So if I have a test that runs only on Node in a simulated dom, there's a cap, there's an absolute cap on the value of that test and it cannot rise above a certain point. And the other thing, another access that we've identified is isolate ability, an ability to run a test. So if I have a test suite comprised of 1500 tests, but if one fails in the middle, I have to restart the test from the beginning. That's going to decrease the value. Maybe it's related to speed, being able to run the tests without having to install a bunch of different dependencies. So that's another access. And so trying to really understand the variables there, that's something you have to be very systematic about thinking about the tests so that you can actually take your idea and explain it to someone who's not coming at it from first principles. Imagine you have to explain an if statement to somebody who's never programmed with an if statement before. TARAS: That is going to be very difficult. CHARLES: It's going to be difficult, right? TARAS: Yeah. In general, it's very challenging to go from an experience that somebody had, like overriding somebody's experience conveying your own personal experience is very difficult. And getting someone to experience something is very difficult. And so that's what I think a lot of the work that we've been doing over the last little while has been breaking down these problems into a way of understanding them so that we can actually explain why these things are important. Like what we've had to do this recently with a Bluetooth work that we've been doing. We have a partner that's implementing a Bluetooth abstraction for mobile devices and trying to convey to them the value of being able to simulate devices. That's something that we saw with Mirage. We knew that being able to simulate devices in tests in different environments is extremely valuable. We know this firsthand from our experience. But trying to justify to them why we think this is important and why they should rejig all of their thinking about how they're going to architect this middle layer between the native APIs and the application APIs, why they should rejig this layer to make it so that it will allow for simulation, like convincing very technical, very knowledgeable and experienced people that these ideas are important, it requires kind of fundamental understanding of the value that they provide. And I think this touches on what really I think Frontside is going to be doing going forward is creating conditions for this kind of thought to be cultivated, to be able to create business environment where our clients gain benefit from this kind of very deep insight, insight that transcends the source of those ideas. Because there are certain ideas that are really fundamental and they're beautiful ideas. For example, in React world, a functional component is a really beautiful idea. It's a really simple concept. And kind of going along along with what you're saying about this kind of fundamental ideas, they will drive you to the next point you couldn't even imagine. I think the work that the React core team has done -- they've set out this functional component as a primitive, but it wasn't possible for a long time to really make the functional component a reality until they've gone through the process of actually understanding what connects all the dots so that you could eventually get to a point where like, "Oh, actually this [inaudible] API is a way for us to enable the fundamental concept of having a component." Not only is it simple, but it actually works. You can write a performance application using this fundamental concept. So, the work that we're going to be doing is first of all, making it possible to have conversations at this level. So, people that we're going to be working with Frontside, clients who we work with, companies that work with us, who partner with us, it's going to be all to support creating this environment where we can have this kind of ideas. Then being able to extract these great ideas from the frameworks and actually making them available across frameworks. You don't have to be locked into a specific community to be able to benefit from that. One of the first steps we're working on now is now that we have an understanding about big tests, we believe this is a good idea, we have ways to justify why it's a good idea. We have clients who have benefited from this good idea. Now we're in position to fill in the gaps that are missing from big tests, from being something that could be used in any framework. We want it to be really easy for people to be able to say, "I really love acceptance testing, but I have to work in a React project or I have to work in a Vue project, I have to work in an Angular projects." It's like, "It's no problem. I have big tests. Big tests is going to give me what I want." The big tests, the idea, but it's going to come with all the little pieces that you need to be able to assemble the functional test suite that is going to give you the benefits that Ember's acceptance test suite provides for Ember projects. CHARLES: I mean, why should you have to compromise on these things. If it is a good idea and it is a fundamental idea, whether it's how you manage concurrent processes, whether it's how you manage testing, whether it's how you manage routing, why should you have to compromise? Why should you have to say, "You know what? I love..." I don't know, what's a comparable system? "I love air conditioning." Why should I have to go into a car that doesn't have air conditioning? Because every single car has a different air conditioning system, or every single house has a different air conditioning system. I'm showing the fact that I live in Texas here by using this example. But we've developed air conditioning systems that are modular so that they can be snapped on to pretty much any house and you don't have to build a custom thing for the circulation and refrigeration of air every single time or have it just be like it's part of the house. Or we have this wood that ships with ducks. It's like, no, we want to separate out that system. TARAS: You don't have to commit to living in a specific area to get the benefit of being comfortable. You don't have to give up the comfort for specific areas. The good idea of air conditioning is not restricted to just one area. You can actually experience it wherever you go and have it be available wherever you would go. You have to be able to, like if you're moving to a new house, you can install air conditioner and now you're going to have like cool air. That's the kind of the theme I think of what we're going to be doing. But there's so much work to do because we're kind of, I would say, probably 30 or 40% into having -- if we were to look at like big tests as a big idea is used and is well known in our industry, we're probably maybe 5% on that. If we take into consideration what it takes for us to be able to convey what it takes to convince people is a good idea. I think we're, if you add to it, we'll probably add another 15%. So the next step is actually creating some tooling around it that would make it really easy for people to consume. Because right now, what's really unfortunate is that you have big tests that is available. If we set it up in the React project, doing it with create-react-app right now is kind of difficult. So we're going to make that easier. But then companies still need to make a choice between the ergonomics [inaudible] Cypress or the speed and the comfort and the control that you have with big tests. We have to basically eliminate the need to make that choice by making the tooling that you get in Cypress and making that tooling available for big test projects. So that is going to kind of bring us up to maybe 60%. And then the remaining part is taking the software that enables the big idea and then making the software work across all different frameworks so that it's really easy to install. On Angular, it's just going to be add a plugin and it gives you big testing. You don't have to rely on their unit testing or you don't have to rely on the end to end testing as using Selenium. You just have big tests and it works just as well as it works and React and just as well as it works in Ember. So you can get the benefits of that. Going through the whole process and then bringing into the world this way, we have a lot of work to do because every part of the architecture of building modern frontend applications requires this level of effort. If you look at routing, routing is extremely inconsistent across frameworks. There are different opinions for every framework. There are different opinions of how to implement it. And that's problematic both on an individual level and a specific project level because it's so hard to know what you should use. And in many cases, it's not complete. What constitutes a routing system on React looks different than what would be in Ember, and it looks different than what it is in Angular. And each one of them has their own trade-offs. So if you find yourself in a situation where you've been using React and now you have to use Angular, you have a steep learning curve. But this also has an interesting effect of like, "Well, we have a world now where micro frontends are a thing." There are really good reasons why companies might want to use multiple frameworks for single platform because different frameworks have different benefits and different teams based on their location might prefer a different framework. There's lots of different reasons why companies choose and we want developers to be able to choose specific framework. But how do you do that when you need to have basically micro frontend architecture, you need to provide an SDK that provides a consistent user experience like -- you need to provide an SDK that provides a consistent developer experience, but then that developer experience because it's developer experience, needs to enable consistent user experience regardless of what framework the team decides to use. So now, routing needs to be more robust. Routing without having a strong concurrency primitives is going to be very limited and it's not going to be as portable across frameworks as one that actually has very robust concurrency primitives. So now we'll start looking at concurrency. We've got concurrency primitives that are different for each framework. We've got Ember concurrency, we have a Redux-sagas. We have observables. React is introducing suspense and their hooks. And now each one of those things is different. So now, we need a concurrency primitive that is framework agnostic that is externalized, that we can consume to build stuff. Now that's a piece of the routing system. There's other things like state machines. State machines are an important part. If you look at the authentication system, the core of an authentication system is a state machine. How do you express a state machine in a way that is framework agnostic, in a way that works in every framework. That's an area that we need to explore. So, there's a lot of work for us to do to take these big ideas and externalize them from the framework so that they can be consumed by frameworks. And the applications that use this frameworks, that is a lot of work. And that's essentially what Frontside is setting out to do is hold these good ideas and extract the pieces that are actually core to these ideas. And then make them available independently and then see what that will provide. In a world where we have all of these pieces in place and we have kind of the granular little pieces that we need to be able to have a really strong concurrency primitive, we have a great routing system that's using this concurrency primitives. We have a state machine mechanism that can work with any framework, has very comfortable APIs. We have all these pieces. What kind of collaboration will that allow? What is the world that that will create? I think for people who are in the Ember community, we saw firsthand what it means for us to stand the shoulders of giants. We have wonderful, brilliant people creating really awesome tools. Now, if that same level of collaboration was happening in a way that was framework agnostic, but we were all standing on shoulders of giants and we were helping each other create something like this, what kind of world would that create? That's what Frontside is setting out to find out. CHARLES: Yeah, and it's going to be fantastic. I should say it's going to be really, really fun. It's going to be challenging. Like you said, there is a lot of work to do. TARAS: A lot of conversations to have. I mean, I think it's difficult to have these conversations because we all have good reasons for thinking certain things and a lot of times it requires understanding each other to find the place. Core teams do this. It's getting everybody to align on where we want to go, provide leadership like doing all of that work and doing it in a way that is actually possible. Because to create an environment with this kind of research that is happening, it requires a lot of money. Charles and I cannot do this. A small group of people probably cannot do this either because we need real use cases. We need real projects to make sure that these ideas are not dream implementations or just like vaporware. We need the pressure of real projects, real clients' relationships to create software that is going to make a huge difference for their developers. So we need those relationships with clients so that we can actually create the conditions for this kind of thing to emerge. That needs to also happen for us to make this kind of a situation possible. So, there is a lot of work to do but it's a really worthwhile cause. CHARLES: And I think that it's one of the reasons that we start with testing as the most important use case because it's something that you don't want to be just saying, "Hey, you want to come help us fund research to make everything better?" There is real pressure, there's financial pressure and there's a duty to make sure that if a project has a deadline, that deadline is met. You want to come in at cost and on time. That's the goal of every project. And you want to try and strive to do your best to achieve that. And testing is an area where the research almost always pays off. I mean, where it has clearly. You can invest a lot of money and get a lot of reward in return because you're losing so much money by not testing or by focusing your investment in testing on lower value targets. TARAS: For people that are familiar with acceptance testing, I think that just goes like a no brainer. Acceptance testing just enables you that. So by putting big test as a first kind of objective, but putting acceptance testing as a first kind of milestone, it sets us up to benefit in the way that Ember community has benefited where the acceptance test now became a mechanism that made it possible for the framework to change. And so, we're kind of setting up the same conditions here. When you start working with us or with any of the companies that work with us, the first benefit you get is you get the acceptance testing. Now, developers are more productive because they know that they have a certainty that if something broke, they will know. If they broke something, they will know. But what that also gives us is a way of introducing change in a systematic way. So, if we find that we have a new routing mechanism, we can start to refactor our React router setup to use this new routing mechanism and we can do it safely because we have our acceptance testing in place. So in many ways, it's kind of like the first step. And it's actually a great first step for business and is a great first step for tech technology. That's kind of a really awesome overlap. CHARLES: In the podcast with Dylan Collins, we talked about this is like step one is make experimentation cheap because experimentation can be wildly expensive and you can throw away a lot of money if you're just experimenting without constraints. And there is nothing like a great application/acceptance test suite that puts those constraints in a completely and totally unambiguous way. So I think that's actually a great summary of our next decade. TARAS: Yeah, I think so too. I think it's a good to show you the perfect next step. And I think this is going to show us the perfect next future though we can't really imagine it right now. But I do know one thing, this future is going to include a lot of people. Fundamentally, what we're setting out to do is a big idea. And so, big ideas are brought to the world by a lot of people. And I think one of the things that's important is that from day one, we include everyone in the process. For anyone who's interested in these big ideas, we want to make it possible for you to participate in. So that's the reason why Frontside is going to have an RFC. Like on our Frontside website, we're actually going to start writing and publishing RFCs. The first RFC that we're going to have is going to be for big tests, which is to lay out why big test is a big good idea for frontend for our industry. And as we start talking to people, there's actually lots of applications beyond frontend. So, we're going to focus on writing these RFCs and sharing them with the world so that we can include as many people in it as possible so everyone can participate. And ultimately, hopefully, that will have an influence on our industry and actually allow us to leverage these big ideas in a way that is not tied to any particular source of these brilliant ideas. CHARLES: Yeah, hat tip to the Ember community for the whole RFC thing, which I guess they didn't invent either. TARAS: Yeah, they borrowed it also, sorry. But I mean, it's been adopted everywhere. And I think it is a really interesting way of making people part of your process and making it our process as our meaning, like everyone who works with us. Whether you work for Frontside, that there's a client of Frontside or you work with the company that is partner with Frontside, whatever that might look like, we want to start to create places where we can be having these conversations and together surfacing these great ideas and making them part of a tool sets. CHARLES: I think that's a perfect way to wrap up. Like I said, you pretty much described our next decade. Maybe if we get more people, it's going to be significantly less and we'll move onto the next thing even more rapidly. I am fully pumped. I'm ready to see this. There's a lot of work to do and I feel great about getting to it. TARAS: I'm very excited about all the work that we're going to be doing, so let's get to it. CHARLES: Yup. All right. We'll see everybody next time. Thank you for listening. If you or someone you know has something to say about building user interfaces that simply must be heard, please get in touch with us. We can be found on Twitter at @TheFrontside or over just plain old email at contact@frontside.io. Thanks. See you next time.

In this episode, Charles and Taras discuss "transparent development" and why it's not only beneficial to development teams, but to their clients as well. Please join us in these conversations! If you or someone you know would be a perfect guest, please get in touch with us at contact@frontside.io. Our goal is to get people thinking on the platform level which includes tooling, internalization, state management, routing, upgrade, and the data layer. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES: Hello and welcome to The Frontside Podcast, the place where we talk about user interfaces and everything that you need to know to build them right. It's been a long summer and we're back. I'm actually back living in Austin, Texas again. I think there wasn't too much margin in terms of time to record anything or do much else besides kind of hang on for survival. We've been really, really busy over the last couple of months, especially on the professional side. Frontside has been doing some pretty extraordinary things, some pretty interesting things. So, we've got a lot to chew on, a lot to talk about. TARAS: There's so much stuff to talk about and it's hard to know where to start. CHARLES: So, we'll be a little bit rambly, a little bit focused. We'll call it fambly. But I think one of the key points that is crystallized in our minds, I would say over this summer, is something that binds the way that we work together. Every once in a while, you do some work, you do some work, you do some work, and then all of a sudden you realize that a theme, there's something thematic to that work and it bubbles up to the surface and you kind of organically perceive an abstraction over the way that you work. I think we've hit that. I hit one of those points at least because one of the things that's very important for us is -- and if you know us, this is things that we talk about, things that we work on -- we will go into a project and set up the deployment on the very first day. Make sure that there is an entire pipeline, making sure that there is a test suite, making sure that there are preview applications. And this is kind of the mode that we've been working in, I mean, for years and years and years. And where you say like if what it takes is spending the first month of a project setting up your entire delivery and showcasing pipeline then that's the most important work, inverting the order and saying that has to really come before any code can come before it. And I don't know that we've ever had like a kind of unifying theme for all of those practices. I mean, we've talked about it in terms of saving money, in terms of ensuring quality, in terms of making sure that something is good for five or 10 years, like this is the way to do it. And I think those are definitely the outcomes that we're looking for. But I think we've kind of identified what the actual mode is for all of that. Is that fair to say? TARAS: Yeah, I think one of the things I've always thought about for a long time is the context within which decisions are made because it's not always easy. And it's sometimes really difficult to really give it a name, like getting to a point where you have really clear understanding of what is it that is guiding all of your actions. What is it that's making you do things? Like why do we put a month of work before we even start doing any work? Why do we put this in our contract? Why do we have a conversation with every client and say, "Look, before we start doing anything, we're going to put CI in place." Why are we blocking our business on doing this piece? It's actually kind of crazy that from a business perspective, it's a little bit crazy that you be like, "Oh, so you're willing to lose a client because the client doesn't want you to set up a CI process?" Or in a case of many clients, it's like you're not willing to accept -- the client is going to say, "We want to use Jenkins." And what we've done in the past, in almost every engagement, we're like, "Actually, no. We're not going to use Jenkins because we know that it's going to take so long for you to put Jenkins in place. By the time that we finish the project, you're probably still not going to have it in place. That means that we're not going to be able to rely on our CI process and we're not going to be able to rely on testing until you're finished." We're not going to have any of those things while we're doing development. But why are we doing all this stuff? It was actually not really apparent until very recently because they didn't really had a name to describe what is it about this tooling and all of these things that makes why is it so important to us. I think that's what kind of crystallized. And the way that I know that it's crystallized because now that we're talking to our clients about it, our clients are taking on to picking up the language. We don't have to convince people that this is a value. It just comes out of their mouth. Like it actually comes out of their mouth as a solution to completely unrelated problems, but they recognize how this particular thing is actually a solution in that particular circumstance as well even though it's not something Frontside sold in that particular situation. Do you want to announce what it actually is? CHARLES: Sure. Drum roll please [makes drum roll sound]. Not to get too hokey, but it's something that we're calling Transparent Development. What it means is having radical transparency throughout the entire development process, from the planning to the design, to the actual coding and to the releases. Everything about your process. The measure by which you can evaluate it is how transparent is this process to not just developers but other stakeholders, designers or people who are very developer adjacent, engineering managers all the way up to C level executives. How transparent is your development? And one of the ways that we sell this, because I think as we talk about how we arrived at this concept, we can see how this practice actually is a mode of thinking that guides you towards each one of these individual practice. It guides you towards continuous integration. It guides you towards testing. It guides you towards the continuous deployment. It guides you towards the continuous release in preview. I think the most important thing is that it's guided us, by capturing this concept, it's guided us to adopt new practices, which we did not have before. That's where the proof is in the pudding is if you can take an idea and it shows you things that you hadn't previously thought before. I think there's a fantastic example. I actually saw it at Clojure/conj in 2016, there was a talk on juggling. And one of the things that they talked about was up until I think it was the early 80's or maybe it was the early 60's, the state of juggling was you knew a bunch of tricks and you practice the tricks and you get these hard tricks. And that was what juggling was, is you practice these things. It was very satisfying and it had been like that for several millennia. But these guys in the Physics department were juggling enthusiasts and I don't know how the conversation came about, you'd have to watch the talk. It's really a great talk. But what they do is they make a writing system, a nomenclature system for systematizing juggling tricks, so they can describe any juggling trick with this abstract notation. And the surprising outcome, or not so surprising outcome, is that by then, once you have it in the notation, you can manipulate the notation to reveal new tricks that nobody had thought of before. But you're like, "Ah, by capturing the timing and the height and the hand and we can actually understand the fundamental concept, and so now we can recombine it in ways that weren't seen before." That actually opened up, I think an order of magnitude of new tricks that people just had not conceived of before because they did not know that they existed. And so, I think that's really, as an abstract concept, is a great yardstick by which to measure any idea. Yes, this idea very neatly explains the phenomenon with which I'm already familiar, but does the idea guide me towards things with which I have no concept of their existence? But because the idea predicts their existence, I know it must be there and I know where to look for it. And aha, there it is. It's like shining a light. And so I think that that's kind of the proof in the pudding. So that's a little bit of a tangent, but I think that's why we're so excited about this. And I think it's why we think it's a good idea. TARAS: Yes. So what's also been interesting for me is how universal it is. Because the question of is this transparent enough? That question could be actually asked in many cases. What's been interesting for me is that asking that question in different contexts that I didn't expect actually yielded better outcome. At the end of the day, I think that a test for any idea is like, is it something that can help you more frequently than not? Like is it actually leading you? Does applying this pattern, does it increase the chances of success? And that's one of the things that we've seen, thinking about just practices that we're putting into place and quite asking are they transparent enough? Is this transparent enough? It's actually been really effective. Do you want to talk about some of the things that we've put in place in regards to transparency? Like what it actually looks like? CHARLES: Yeah. I think this originally started when we were setting up a CI pipeline for a native application which is not something that we've typically done in the past. Over the last, I would say, 10 years, most of our work has been on the web. And so, when we're asked to essentially take responsibility for how a native application is going to be delivered, one of the first things that we asked kind of out of habit and out of just the way that we operate is how are we going to deliver this? How are we going to test it? How are we going to integrate it? All the things that we've just talked about is something that we have to do naturally. But because this is not very -- like continuous integration and build is very prevalent on the web. I think that testing still has a lot of progress on the web, but it's far more prevalent than it is in other communities, certainly the native community. So when we started spending a month setting up continuous integration an integration test suite, spending time working on simulators so that we could simulate Bluetooth, having an automated process with which we could ship to the App Store, all of these things kind of existed as one-offs in the native development community. There are a lot of native developers who do these things. But because it's not as prevalent and because it was new to us, it caused a lot of self reflection both on why is it that we feel compelled to do this. And also we had to express this, we had to really justify this work to existing native development teams and existing stakeholders who were responsible for the outcomes of these native development teams. So, there was this period of self reflection, like we had to write down and be transparent about why we were doing this. TARAS: Yeah. We had to describe that in SoWs. We actually had really long write ups about like what it is that we're setting up. And for a while, it was, people I think would read these SoWs and I think they would get the what's of what we're actually going to be putting into place. But it wasn't until we actually put it into place and we've seen a few like really big wins with the setup -- one of the first ones was the setting up preview apps where preview apps in -- the web are pretty straightforward because we've got Netlify that just kind of gives it to you easily. CHARLES: Netlify and Heroku. It's very common. TARAS: Yeah, you activate it, it's there. But on the mobile side, it's quite a different story because you can't just spin up a mobile device that is available through the web. It's something kind of very special. And so we did find a service called Appetize that does this. And so we hooked up the CI pipeline to show preview apps in pull requests. So for every pull request, you could see specifically what was introduced in our pull request without having to pull down source code, like compile it. You could just click a link and you see a MVC stream of a mobile device and that application running on a mobile device. So the setup took a little bit of time. But once we actually put it in place and we showed it to our clients, one of the things that we noticed is that it became a topic of conversation. Like, "Oh, preview apps are amazing." "This is so cool." "Preview apps are really great." And I think in some ways, it actually surprised us because we knew that they were great, but I think it was one of the first times that we encountered a situation where we would show something to a client and they just loved it. And it wasn't an app feature. It was a CI feature. It was part of a development process. CHARLES: Right. So, the question is then why was this so revelatory? Why was it so inspiring to them? And I think that the reason is that even if we have an agile process and we're on two week iterations, one week iterations, whatever, there's still a macroscopic waterfall process going on because essentially, your business people, your design people, maybe some of your engineering people are involved at the very front of the conversation. And there's a lot of talking and everybody's on the same page. And then we start introducing coding cycles. And like I said, even if we're working on two week iterations and we're "agile", the only feedback that you actually have, whether something is working, is if the coder says it's done. "I'm Done with this feature. I'm on to the next feature for the next two weeks." And after that two weeks, it's like, "I'm done with this feature. I'm on to the next feature." From the initial design, you have the expectation about what's going on in the non-technical stakeholders minds. They have this expectation. And then they hope that through the process of this agile iterative development cycles, they will get the outcome that satisfies that hope. But they're not able to actually perceive and put their hands on it. It's only the engineers and maybe some really tech savvy engineering managers who can actually perceive it. And so they're getting information secondhand. "Hey, We've got authentication working and we can see this screen and that screen." And, "Hey, it works on iOS now." "I have some fix ups that I need to do on Android." So, maybe they're consuming all of their information through standups or something like that, which is better than nothing. That is a level of transparency. But the problem is then you get to actually releasing the app or whether it's on the web, whether it's on native, but this is really a problem on native. You get to where you actually release the app and then everybody gets to perceive the way the app as it actually is. So you have this expectation and this hope that was set maybe months prior and it just comes absolutely careening into reality in an instant, the very first moment that you open the app when it's been released. And if it doesn't meet that expectation, that's when you get disappointment. When expectations are out of sync and grossly out of sync with reality, even a little bit out of sync with reality, you get disappointment. As fundamental and explanation of just the phenomenon of disappointment, but it's an explanation of why disappointment happens so often on development projects. Is this kind of the expectations and hopes of what a system can be in the minds of the stakeholders? It's kind of this probability cloud that collapses to a single point in an instant. TARAS: And that's when things really hit the proverbial fan. Now, you have the opposite. So everything that was not transparent about your development process. So everything that was hidden in the opaqueness of your development process, all of those problems, either on a product side, maybe something didn't quite get implemented the way it's supposed to. Like you actually found out two weeks or three weeks before you're supposed to release that that feature wasn't actually quite implemented right. It went through testing, but it was tested against the Jira stories that were maybe not quite written correctly. So the product people are going like, "What the hell is this? It's actually not what I signed up for. This is not what I was asking for." So, there's that part. And then on the development side, you've got all of the little problems that you didn't really account for because you haven't been shipping to production from day one. You actually have like application not really quite working right. You didn't account as supposed to integrate with some system that is using Chorus or something you didn't account for. Like you have a third party dependency you didn't really fully understand. But because it wasn't until you actually turned it on that you actually started to talk to the thing properly, and you realize there's some mismatch that is not quite working. But now you've got everything that was not transparent about the development process, everything that was hiding in the opaque corners of your development process is now your problem for the next three weeks because you've got to fix all of these problems before you release. And that's what I think where a lot of organizations kind of find themselves in is this position where they've been operating for six months and like, "Everything is going great!" And then three months or three weeks before, you're like, "Actually, this is not really what we were supposed to do. Why did this happen?" That time is really tough. CHARLES: Yeah. That's what we call crunch time. And it's actually something that is lot of times we think of it as inevitable, but in fact it is actually an artifact of an opaque process. TARAS: Yeah. CHARLES: That's the time when we have to go, everybody's like, "We're ordering pizza and Dr. Pepper and nobody's leaving for a month." TARAS: Yeah. I think there are people that do that practice like functional testing as part of development process or acceptance testing, I think they could relate to this in some cases where if you had to set up a test suite on an application that was written without a test suite, first thing you deal with are all the problems that you didn't even know were there. And it's not until you actually start testing, like doing functional testing, not integration or unit testing where you're testing everything in isolation, but when you're perceiving the entire system as one big system and you're testing each one of those things as the user would, it's not until that point you start to notice all the weird problems that you have. Like your views are re-rendering more than you expected. You have things that are being rendered you didn't even notice because it's hard to see, because it happens so quickly. But in test, it happens at a different pace. And so, there's all these problems that you start to observe the moment that you start doing acceptance testing, but you don't see them otherwise. And so, it's the process of making something transparent that actually highlights all these problems. But for the most part, if you don't know that there are transparent options available, you actually never realize that you are having these problems until you are in crunch time. CHARLES: Right. And what's interesting is viewed through that lens, your test suite is a tool for perception. And to provide that transparency, not necessarily something that ensures quality, but ensuring the quality is a side effect of being able to perceive bugs as they happen or perceive integration issues at the soonest possible juncture. To shine the light, so to speak, rather than to act as a filter. It's a subtle distinction, but I think it's an important one. TARAS: About functional testing and acceptance testing. I think one of the things that I know personally from experience working with comprehensive acceptance test suites is that there is certainty that you get by expressing the behavior of the application in your tests. And I think what that certainty does is it replaces hope as opposed to having hope baked into your system where you think like you're hoping. I think for many people, they don't even perceive it as hope. They perceive it as reality. They see it as, "My application works this way." But really what's happening is there's a lot of trust that's built into that where you have to say like, "Yeah, I believe the system should work because I wrote it and I'm good. And it should not be broken." But unless you have a mechanism that actually verifies this and actually insures this is the case, you are operating in the area of dreams and hopes and wishes, and not necessarily reality. And I think that's one of the things that's different. A lot of the processes around highlighting or shining light on the opaque areas of the development process. And it's actually not even just development process. It's actually the business process of running a development organization. Shining light in those areas is then what gives you the opportunity to replace hope with real validatable truth about your circumstances. CHARLES: And making it so that anyone can answer that question and discover that truth and discover that reality for themselves. So, generating the artifacts, putting them out there, and then letting anybody be the primary perceiver of what that artifact means in the context of the business, not just developers. And so, that kind of really explains preview apps quite neatly, doesn't it? Here we've done some work. We are proposing a change. What are the artifacts that explain the ramifications of this change? So we run the test suite. That's one of the artifacts that explains and radiates the information so that people can be their own primary source. And look at it in a developer centric, although you can tell, any old person can tell if the test suite's failing, it's not a change that we should go with. But the preview app is something we take this hypothetical change, we build it, we put it out there and now, everyone can perceive it. And so, it calibrates the perception of reality and it eliminates hope. Which is like if your development process is based on hope, you are signing yourself up for disaster. I like what you said that it implies a huge amount of trust in the development team. And you know what? If you have a cracked development team, that trust is earned and people will continually invest based on that trust. But the fundamentals are still fragile because they still can open up a crack between the expectation and the reality. And the problem is when that happens, the trust is destroyed. And it's during that crunch time, if it does happen that you lose credibility and it's not because you became a worse developer. It's not because your team is like lower performing, it's just that there was this divergence allowed to open. But then the problem is that really lowers the trust and that means that unfortunately that's going to have a negative knock on effect. And reasonably so. Because if you're an engineering manager or a product manager, you're something like this and you're losing trust in your development team and their ability to deliver what you talked about, then you're going to want to micromanage them more. The natural inclination is to try and be very defensive and interventionist and you might actually introduce a set of practices that inhibit the development cycle even further and lower the team's abilities to perform right when they need to do it the most, then you end up destroying more trust. TARAS: Yeah, it's a spiraling effect I think because it's in the process of trying to make things better. And then you start to introduce practices. Like maybe you're going to have meetings every day reviewing outstanding stories to try to get everybody on the same page, but now you're micromanaging development team. The development team starts to resent that and now you've got this like people hating their job. It starts to get messier and dirtier and more complicated. And the root cause of that is that from day one, there was a lot of just [inaudible] about getting into it and just starting to write some code but what you didn't actually do is you didn't put in place the fundamentals of making sure that you can all observe a reality that is honest. And I think that kind of fundamental principle, it's interesting how when you actually start to kind of take this idea and when you start to think about it in different use cases, it actually tells you a lot about what's going on and you can actually use it to design new solutions. One of the things that Frontside does, I don't know if those who've kind of worked with us before might know this or might not, but we don't do blended rates anymore. Because we don't actually, one of the challenges with blended rates is that they hide the new ones that gives you the power to choose how to solve a problem. CHARLES: Yeah. There's a whole blog post that needs to be written on why blended rates are absolute poison for a consultancy. But this is the principle of why. TARAS: Yeah. I think it's poison for transparent consultancy because if you want to get the benefits of transparency, you have to be transparent about your people. Because alternatively what happens is that you start off relying on your company's reputation and then there is a kind of inherent lie in the way that the price points are set up because everybody knows that there is going to be a few senior people, there's going to be a few intermediate people, a few junior people. But these exact ratios of those or who is doing what, how much people are available, all of those things are kind of hidden inside of the consulting company so that they can manage their resources internally. And so what that does is it simplifies your communication with the client. But actually what it also does is it disempowers you to have certain difficult conversations when you need the most. And you could say, "Look, for this kind of work, we don't need to have more senior people working on this." We can have someone who is junior who is at like $100 an hour, $75 an hour as opposed to being $200 or $250 an hour. We can have that person working on this and we can actually very clearly define how certain work gets solved. It requires more work. But then what it does is it creates a really strong bond of honesty and transparency between you and your clients. And it gives you a way, like now the client starts to think about you as a resource that allows them to fulfill on their obligations in a very actionable way. They can now think about how they can use you as a resource to solve their problems. They don't need a filter that will process that and try to make it work within the organization. You essentially kind of become one unit. And I think that sense of unity is the fundamental piece that keeps consulting companies and clients glued together. It's the sense of like, "We can rely on this team to give us exactly what we want when we need it, and sometimes give us what we need that we don't know we need." But that bond is there. And that bond is strong because there is no lie in that relationship. You're very transparent about who are the people that's working on it. What are they actually going to be doing? How much is this costing us? CHARLES: It's worth calling out explicitly whether on the flip side of it is, is if you have a blended rate, which is the way that Frontside operated for, gosh, pretty much forever, is that people will naturally calibrate towards your most senior people. If I'm going to be paying $200 an hour across the board, or $150 an hour across the board, or $300 across the board, whatever the price point is, they're going to want to extract the most value for that one price point. And so, it means that they're going to expect the most senior people and become resentful if what I'm paying is $300 for a task. If I've got five senior people, it's a better deal for me. For the same price to get five senior people than two senior people to a medium level people and one junior person. And so, it has two terrible effects. One is that they don't appreciate the senior people to be like, "Hey actually, these are people with extraordinary experience, extraordinary knowledge, extraordinary capability that will kick start your part." So they are under appreciated and then they're extremely resentful of the junior people. It's like, "I'm paying the same rate for this very senior person as I am for this junior person? Get this person off my project." But if you say, "You know what, we're going to charge a fifth of the cost for this junior person and we're going to utilize them," then you're providing real value and they're appreciating it. They're like, "Oh, thank you for saving me so much money. We've got this task that does not require your most senior person. That would be a misallocation of funds. I'd be wasting money on them. But if you can charge me less and give me this junior person and they're going to do just as competent a job, but it's going to cost me a fifth of the money, then that's great. Thank you." So, it flips the conversation from 'get this god-damn junior person off my project' to 'thank you so much for bringing this person on'. It's so critical. But that's what that transparency can provide. It can totally turn a feeling of resentment into gratitude. TARAS: What's interesting is from business perspective, you make the same amount of money. In some cases, you actually make more money. I think in that way, it's a consulting company. But that's not the important part because the amount of value that's generated from having more granular visibility into what's happening is so much greater. It's kind of like with testing where any of those things where when you start to put, when you start to shine light on these kind of opaque areas and then you start to kind of flush out the gremlins that are hiding there, what you then start to do, what you kind of discover is this opportunity to have relationships with clients that are honest. So you could say, for example, like one of the things that we've done recently is we actually have like 10-tier price point model, which allows us to to be really flexible about the kind of people that we introduce. So, there's a lot of details that go into the actual contracting negotiation. But what it does is it allows us to be very honest about the costs and work together with our clients, like actually really find a solution that's going to work really well for them. And then this is kind of a starting point when we start thinking about transparency in this kind of diverse way, you actually start to realize that there are additional benefits that you might have never been experienced before. One of the things that we found recently is that one of the initiatives that we kind of launched with one of our clients is we wanted to bring together, there's a general problem that exists in large projects, which is that if you have a really big company and you have like, let's say 20 or 30 interconnected services, your data domain, like the older data, kinds of data you work with is spread over a whole bunch of microservices spread over potentially a bunch of different development teams spread over a bunch of different locations. What usually has happened in the past is each one of those problems or the domain, the data domain has been kind of siloed into a specific application. We worked with a bank in the past and that being had for every, they had 80 countries. In each country they had 12 different industries, like insurance and mortgage and different kinds of areas of services they offered. And then for each of the country, for each of the service, they had a different application that provided that functionality. Then the next step is, let's not do that anymore because we now have something like 100, 150 apps, let's bring it all together under a single umbrella and let's create a single shared domain that we can then use. And so, a GraphQL becomes a great solution for that. But the problem is that making that change is crazy complicated because the people on the business side who understand how all the pieces fit together. On the other side, you have the developers who know where the data can come from and how to make all that real. And on the other side is there's like frontend implementers who actually build in the UIs that are consuming all these services. On a project that we're working on right now is we're building a federated GraphQL gateway layer that is kind of connecting all these things, bringing all these things together. But the problem is that without very specific tooling to enable that kind of coming together of the frontend, the backend, the business people having coming together, creating a single point of conversation and having a single point of reference for all the different data that we have to work with and different data that is available to the gateway, without having something like that, without having that transparency in the actual data model, it is really difficult to make progress because you don't have shared terminology, you don't have shared understanding of the scope of the problem. There's a lot of dots in context that needs to be connected. And for anyone who has worked with enterprise, you know how big these problems get. And so what we've done on a project that we're working on now is we actually aimed to bring transparency to this process. What we actually did is put in place, start to build an application that brings together all of the federated services into a visualization that different parties can be involved in. And so I think one of the kind of common patterns that we see with transparency in general is that we are including people in the process, in the development process that were previously not included. So in the past, they would be involved in the process either very early on or very late in the process, but they wouldn't be involved along the way. And so what this kind of transparency practice actually does is it allows us to kind of democratize and flatten the process of creating foundations for pieces that touch many different parts of the organization. And so this tool that we created allows everyone to be involved in the process of creating the data model that spans the entire organization and then have a single point of reference that everybody can go to and have a process for contributing to it. They don't have to be a developer. There's developers who consume it. There are business people that consume it. There are data modeling people that consume it. Like there's different people parties involved. But the end result is that everyone is on the same page about what it is that they're creating. And we're seeing the same kind of response as we saw with preview apps where people who previously didn't really have an opinion on development practices or how something gets built, all of a sudden they're participating in the conversation and actually making really valuable suggestions that developers couldn't really have exposure to previously because developers often don't have the context necessary to understand why something gets implemented in a particular way. CHARLES: Something beautiful to behold, really. And like I said, it's wonderful when a simple concept reveals things that had lay hidden before. TARAS: Yeah. It's a very interesting lens to look at things through. How transparent is this and how can we make it more transparent? I think asking that question and answering that question is what has been kind of giving us a lot of -- it had been very helpful in understanding our challenges in the work that we do on a daily basis and also in understanding how we could actually make it better. CHARLES: I apply this concept in action on my pull requests. I've really been focusing on trying to make sure that if you look at my pull request, before you actually look at the code, you can pretty much understand what I've done before you even look at the diff. The hallmark of a good pull request is basically if by reading the conversation, you understand what the implementation is going to be. There's not really any surprises there. It's actually hard to achieve that. Same thing with git history. Spending a lot of time trying to think like how can I provide the most transparent git history? That doesn't necessarily mean exactly the log of what happened moment to moment, day to day, but making sure that your history presents a clear story of how the application has evolved. And sometimes that involves a lot of rebasing and merging and branch management. I think another area that has been new for us, which this has revealed those things that I just described are areas where we're kind of re-evaluating already accepted principles against a new measure, but introducing an RFC process to actually a client project where we're making architectural decisions with our developers, the client's developers, external consultants. You've got a lot of different parties, all of whom need to be on the same page about the architectural decisions that you've made. Why are we doing this this way? Why are we doing modals this way? Why are we using this style system? Why are we using routing in this way? Why are we doing testing like this? These are decisions that are usually made in an ad hoc basis to satisfy an immediate need. It's like, "Hey, we need to do state management. Let's bring in Redux or let's bring in MobX or let's bring in whatever." And you want to hire experts to help you make that best ad hoc decision? Well, not really. I mean, you want to lean on their experience to make the best decision. But having a way of recording and saying this is the rationale for a decision that we are about to make to fulfill a need. And then having a record of that and putting it down in the book so that anybody who can come later. First of all, when the discussion is happening, everybody can understand the process that's going on in the development team's head. And then afterwards and it's particularly important is someone asks a question, "Why is this thing this way?" You can point directly to an RFC. And this is something that we picked up from the Ember community, but this is something that open source projects really by their very nature have to operate in a very highly transparent manner. And so, it's no surprise that that process came from the internet and an open source project. But it's been remarkably effective, I would say, in achieving consensus and making sure that people are satisfied with decisions, especially if they come on afterwards, after they've been made. TARAS: We actually have this particular benefit that could experience that particular benefit today where one of the other things that this RFC process and transparency with the architecture, how that kind of benefits the development organization is that a lot of times when you are knee deep in doing some implementation, that is not a time you want to be having architectural conversations. In the same way like in a big football team, they huddle up before they go on a field. You can't be talking strategy and architecture and plans while you're on the football field. You have to be ready to play. And this is one of the things that the RFC process does is it allows us to say, "Look, right now we have a process for managing architecture so that with the RFC process you can go review our accepted RFCs. You can make proposals there." And that is a different process than the process that we're involved in on a daily basis, which is writing application, using architecture where we have in place. And so that in itself can be really helpful because well intentioned people can bring up these conversations because they really are trying to solve a problem, but that might not be the best time. And so having that kind of process in place and being transparent about how architecture decisions are made allows everyone to participate and it also allows you to prioritize conversations. CHARLES: Yeah. And that wasn't a practice that we had adopted previous to this, but it's something that seemed obvious that we should be doing. It's like, how can we make our architecture more transparent? Well, let's do this practice. So, I keep harping on this. But I think it's the hallmark of a good idea if it leads you to new practices and new tools. And we're actually thinking about adopting the RFC process for all of our internal developments, for maintaining our open source libraries. TARAS: There is something that we've been working on that we're really excited about. So, there's a lot of stuff happening at Frontside. But one of the things that we've been doing is working on something we call the transparent node publishing process, which is something that I think we originally drew inspiration from the way NativeScript has their repo set up. But one thing that's really cool about how they have things set up is that every pull request automatically is available, like everything is available. Very quickly, a pull request is available for you to play with and you can actually put it into your application as a published version in npm and actually see exactly if that pull request is going to work for you. You don't have to jump through hoops. You don't have to clone the repo, build it locally, link it. You don't have to do any of that stuff because if you see a pull request that has something that you want but then is not available in master, there's an instruction on the pull request that tells you, "Here's how you can install this particular version from npm." And so you essentially you're publishing. Every pull request automatically gets published to npm and you can just download and install that specific version for that particular pull request in your project. That in itself I think is one of those things I suspect that is going to be talked about. It actually can alleviate a lot of problems that we have on a development processes because like the availability of the work of people who are participating in the project, there is kind of a built in barrier that we are essentially breaking down with this transparent node publishing process. And so, that's something that we're very close to to having it all on our repos and we're going to try it out and then hopefully share it with everyone on the internet. CHARLES: I didn't know that the NativeScript did this. I thought that the idea that came from it is like how can we apply these transparency principles to the way we maintain npm packages. The entire release process should be completely transparent, so that when I make a pull request, it's available immediately in a comment. And then furthermore, even when a pull request is merged, there's no separate step of let's get someone to publish it. It's just now it's on master. Now it is available as a production release. You close the latency and you close the gap and people perceive things as they are. There is nothing like, "Oh that emerged. When do I get this?" This is something that I can't stand about using public packages is you have some issue, you find out that someone also has had this issue, they've submitted a pull request for it and then it's impossible to find if there's a version and what version actually supports this? And it's even more complex between projects that actually do backporting of fixes to other versions. So I might be on version two of a project. Version three is the most recent one, but I can't upgrade to version three because I might be dependent on some version two APIs. But I really need this fix. Well, has it been backported? I don't know. Maybe upgrading is what I have to do, but maybe downgrading. Or if I'm on the same major release version, maybe there's been 10 pull requests, but there's been no release to npm. And it can be shockingly difficult to find out if something is even publicly available. And the transparency principle comes in to, "Hey, if I see it on GitHub, if I see it there, then there's something there that I can touch and I can perceive for myself to see if my issue has been resolved or if the things work as I expect." TARAS: I'm really excited about this. I'm really excited about this kind of clarification, this crystallization of transparency. And I'm also seeing our clients starting to apply it to solving problems within their organization as well is very inspiring. CHARLES: Yeah, it is. It is really exciting. And honestly, I feel like we've got one of those little triangular sticks that people use to find water. I feel like we have a divination stick. And I'm really excited to see what new tools and practices it actually predicts and leads us to. TARAS: Me too. I'm really excited to hear if anyone likes this idea. Send us a tweet and let us know what you're seeing for yourself about this because I think it's a really interesting topic and I'm sure there's going to be a lot that people can do with this idea in general. CHARLES: Thank you for listening. If you or someone you know has something to say about building user interfaces that simply must be heard, please get in touch with us. We can be found on Twitter at @TheFrontside, or over just plain old email at contact@frontside.io. Thanks and see you next time.

Rich Harris talks about Svelte and Reactivity. Rich Harris: Graphics Editor on The New York Times investigations team. Resources: Svelte Please join us in these conversations! If you or someone you know would be a perfect guest, please get in touch with us at contact@frontside.io. Our goal is to get people thinking on the platform level which includes tooling, internalization, state management, routing, upgrade, and the data layer. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES: Hello and welcome to The Frontside Podcast, a place where we talk about user interfaces and everything that you need to know to build them right. TARAS: It's actually a really nice, Rich and I'm really, really happy to have a chance to actually chat with you about this because Svelte is a really fun piece technology. In many ways, it's interesting to see our technology evolve and our industry evolve through innovation, real innovation. I think Svelte 3 has really been kind of that next thought provoking technology that kind of makes you think about different ways that we can approach problems in our space. So, really excited to chat with you about this stuff. RICH: Well, thank you. Excited to be here. TARAS: I think quite a lot of people know, Rich, about your history, like how you got into what you're doing now. But I'm not sure if Charles is aware, so if you could kind of give us a little bit of a lowdown on where you kind of come from in terms of your technical background and such. RICH: Sure. I'll give you the 30-second life history. I started out as a reporter at a financial news organization. I had a Philosophy Degree and didn't know what else to do with it. So, I went into journalism. This was around the time of the great recession. And within a few weeks of me joining this company, I watched half of my colleagues get laid off and it's like, "Shit, I need to make myself more employable." And so gradually, sort of took on more and more technical responsibilities until I was writing JavaScript as part of my day job. Then from there, all these opportunities kind of opened up. And the big thing that I had in mind was building interactive pieces of journalism, data-driven, personalized, all of that sort of thing, which were being built at places like the New York Times, and The Guardian, and the BBC. That was the reason that I really wanted to get into JavaScript. And that's guided my career path ever since. CHARLES: It's interesting that this D3 and all that did come out of journalism. RICH: It's not a coincidence because when you're working under extreme time pressure and you're not building things with a view to maintain them over a long period of time, you just need to build something and get it shipped immediately. But it needs to be built in a way that is going to work across a whole range of devices. We've got native apps, we've got [inaudible], we've got our own website. And in order to do all that, you need to have tools that really guide you into the pit of success. And D3 is a perfect example of that. And a lot of people have come into JavaScript through D3. CHARLES: And so, are you still working for the same company? RICH: No. That's ancient history at this point. CHARLES: Because I'm wondering, are you actually getting to use these tools that you've been building to actually do the types of visualizations and stuff that we've been talking about? RICH: Very much so. I moved to The Guardian some years ago. And then from there, moved to Guardian US, which has an office in New York. And it was there that I started working on Svelte. I then moved to the New York Times and I'm still working on Svelte. I've used it a number of times to build things at the New York Times and the people have built things with it too. And so, yeah, it's very much informed by the demands of building high performance interactive applications on a very tight deadline. CHARLES: Okay, cool. So I've probably used, I mean, I'm an avid reader of both Guardian and the New York Times, so I've probably used a bunch of these visualizations. I had no idea what was driving them. I just assumed it was all D3. RICH: There is a lot of D3. Mike Bostock, the creator of D3, he was a linchpin at the graphics department for many years. Unfortunately we didn't overlap. He left the Times before I joined the Times, but his presence is still very much felt in the department. And a lot of people who are entering the industry, they're still becoming database practitioners by learning from D3 examples. It's been a hugely influential thing in our industry. TARAS: How long is a typical project? How long would it take to put together a visualization for an article that we typically see? RICH: It varies wildly. The graphics desk is about 50 strong and they will turn around things within a day. Like when the Notre Dame burnt down a couple of months ago, my colleagues turned around this interactive scroll driven webGL 3D reconstruction of how the fire spreads through the cathedral in less than 24 hours, which was absolutely mind blowing. But at the same time, there are projects that will take months. I work on the investigations team at the Times. And so, I'm working with people who are investigating stories for the best part of the year or sometimes more. And I'm building graphics for those. And so that, it's two very different timescales, but you need to be able to accommodate all of those different possibilities. CHARLES: So, what does the software development practice look like? I mean, because it sounds like some of this stuff, are you just throwing it together? I guess what I mean by that is, I guess the projects that we typically work on, three months is kind of a minimum that you would expect. So, you go into it, we need to make sure we've got good collaboration practices around source control and continuous integration and testing and all this stuff. But I mean, you're talking about compressing that entire process into a matter of hours. So what, do you just throw right out the window? What do you say? "We're just doing a live version of this." RICH: Our collaboration processes consist of sitting near each other. And when the time calls for it, getting in the same room as each other and just hammering stuff out on the laptop together. There's no time for messing around with continuous integration and writing tests. No one writes tests in the news graphics, it's just not a thing. CHARLES: Right. But then for those projects that stretch into like three months, I imagine there are some. Do you run into like quality concerns or things like that where you do have to take into account some of those practices? I'm just so curious because it sounds like there's actually, the difference between two hours and two months is, that's several orders of magnitude and complexity of what you're developing. RICH: It is. Although I haven't worked on a news project yet that has involved tests. And I know that's a shocking admission to a lot of people who have a development background, but it's just not part of the culture. And I guess the main difference between the codebase for a two-hour project and a two-month project is that the two-month project will strive to have some reasonable components. And that's, I think, the main thing that I've been able to get out of working on the kinds of projects that I do is instead of just throwing code at the page until it works, we actually have a bit of time to extract out common functionality and make components that can be used in subsequent interactives. So, things like scroll driven storytelling, that's much easier for me now than it was when I first built a scroll driven storytelling component like a couple of years ago. CHARLES: Yeah. That was actually literally my next question is how do you bridge that, given that you've got kind of this frothy experimentation, but you are being, sounds like, very deliberate about extracting those tools and extracting those common components? And how do you find the time to even do that? RICH: Well, this is where the component driven mindset comes in really handy, I think. I think that five or 10 years ago when people thought in terms of libraries and scripts, there wasn't like that good unit of reusability that wasn't the sort of all encompassing, like a component is just the right level of atomicity or whatever the word is. It makes sense to have things that are reusable but also very easy to tweak and manipulate and adapt to your current situation. And so, I think that the advent of component oriented development is actually quite big for those of us working in this space. And it hasn't really caught on yet to a huge degree because like I say, a lot of people are still coming with this kind of D3 script based mindset because the news industry, for some interesting and historical reasons, is slightly out of step with mainstream mode development in some ways. We don't use things like Babel a lot, for example. CHARLES: That makes sense, right? I mean, the online print is not like it's a React application or it's not like the application is all encompassing, so you really need to have a light footprint, I would imagine, because it really is a script. What you're doing is scripting in the truest sense of the word where you essentially have a whole bunch of content and then you just need to kind of -- RICH: Yeah. And the light footprint that you mentioned is key because like most new sites, we have analytics on the page and we have ads and we have comments and all of these things that involve JavaScript. And by the time our code loads, all of this other stuff is already fighting for the main thread. And so, we need to get in there as fast as we can and do our work with a minimum fuss. We don't have the capacity to be loading big frameworks and messing about on the page. So that again is one of these sort of downward pressures that kind of enforces a certain type of tool to come out of the news business. TARAS: A lot of the tooling that's available, especially on like the really fatter, bigger frameworks, the tools that you get with those frameworks, they benefit over long term. So if you have like a long running project, the weight of the abstractions, you've experienced that benefit over time and it adds up significantly. But if you're working to ship something in a day, you want something that is just like a chisel. It does exactly what you want it to do. You want to apply it in exactly the right place and you want to get it done exactly, like you want the outcome to be precise. RICH: That's true. And I think a lot of people who have built large React apps, for example, or large Ember apps, they sort of look at Svelte and think, "Well, maybe this isn't going to be applicable to my situation," because it has this bias towards being able to very quickly produce something. And I'm not convinced that that's true. I think that if you make something easier to get started with, then you're just making it easier. If you build something that is simple for beginners to use, then you're also building something simple for experts to use. And so, I don't necessarily see it as a tradeoff, I don't think we're trading long-term maintainability for short term production. But it is certainly a suspicion that I've encountered from people. TARAS: This is something that we've also encountered recently. It's been kind of a brewing discussion inside a front side about the fact that it seems to be that certain problems are actually better to rewrite than they are to maintain or refactor towards an end goal. And we found this, especially as the tools that we create have gotten more precise and more refined and simplified and lighter, it is actually easier to rewrite those things five times than it is to refactor it one time to a particular place that we want it to be. And it's interesting, like I find this to be very recent, this idea is blossoming in my mind very recently. I didn't observe this in the past. CHARLES: Do you mean in the sense that like if a tool is focused enough and a tool is simple enough, then refactoring is tantamount to a rewrite if you're talking about 200 or 300 lines of code? Is that what you mean? TARAS: Yeah. If you're sitting down to make a change or you have something in mind, it is actually easy to say, "Let's just start from scratch and then we're going to get exactly the same place in the same amount of time." But this kind of mantra of not rewriting makes me think about that, makes me question whether that's actually something that is always the right answer. RICH: I definitely question that conventional wisdom at all levels, as well. I started a bundler called Rollup as well as Svelte more recently. And Rollup was the second JavaScript bundler that I wrote, because the first one that I wrote wasn't quite capable of doing the things that I wanted. And it was easier to just start from scratch than to try and shift the existing user base of its predecessor over to this new way of doing things. Svelte 3 is a more or less complete rewrite. Svelte has had multiple, more or less, complete rewrite. Some of them weren't breaking changes. But Svelte itself was a rewrite of an earlier project that I'd started in 2013. And so in my career, I've benefited massively from learning from having built something. But then when the time comes and you realize that you can't change it in the ways that you need to change it, just rewrite it. And I think that at the other end of the spectrum, the recent debate about micro frontend has largely missed this point. People think that the benefit of the micro frontend is that people don't need to talk to each other, which is absolute nonsense. I think the benefit of this way of thinking about building applications is that it optimizes for this fact of life that we all agree is inevitable, which is that at some point, you're going to have to rewrite your code. And we spend so much energy trying to optimize for the stability of a code base over the long term. And in the process, lock ourselves into architectural and technical decisions that don't necessarily make sense three or four years down the line. And I think as an industry, would be a lot better placed if we all started thinking about how to optimize for rewrites. CHARLES: So for those of us who aren't familiar, what is the debate surrounding micro frontends? This is actually something I've heard a lot about, but I've actually never heard what micro frontends actually are. RICH: Yeah. I mean, to be clear, I don't really have a dog in this fight because I'm not building products, but the nub of it is that typically if you're building a website that maybe has like an admin page, maybe it has a a settings page, maybe it has product pages, whatever. Traditionally, these would all be parts of a single monolithic application. The micro frontend approach is to say, "Well, this team is going to own the settings page. This team is going to own the product page." And they can use whatever technologies they want to bring that about. And the detractors sort of attack a straw man version of this, "You're going to have different styles in every page. You're going to have to load Vue on one page. You're going to have to load React on the other page. It's going to be a terrible user experience," when actually its proponents aren't suggesting that at all. They're suggesting that people from these different teams coordinate a lot more that are free to deviate from some kind of grand master architectural plan when it's not suitable for a given task. And darn right. I think it means that you have a lot more agility as an engineering organization than you would if you're building this monolithic app where someone can't say, "Oh, we should use this new tool for this thing. We should use microstates when the rest of the organization is using Google docs." It's not possible. And so, you get locked into the decisions of a previous generation. CHARLES: Right. No, it makes sense. It's funny because my first reaction is like, "Oh my goodness, that's a potential for disaster." The klaxon's going to go off in your head, but then you think, really then the work is how do you actually manage it so it doesn't become a disaster. And if you can figure that out, then yeah, there is a lot of potential. RICH: Yeah. People always try and solve social problems with technology. You solve social problems with social solutions. CHARLES: Right. And you have to imagine it too, it depends on the application, right? I think Amazon, the Amazon website is developed that way where they have different teams that are responsible even down to little content boxes that are up on the toolbar. And the site doesn't really, it shows, right? Like it shows like this is kind of like slapped together, but that's not what they need. They don't need it to not look like there's slight variation with the different ways that things behave. They need to be showing for their business to work. They need to be showing the right thing at the right time. And that's the overriding concern. So having it look very beautiful and very coherent isn't necessarily a thing. Same thing in Spotify, used as another example of this. I didn't know if it was called micro frontends, but I know that they've got a similar type thing, but they are clearly the experience and having it look coherent is more important. And so, they make it work somehow. And then like you're saying, it probably involves groups of people talking to other groups of people about the priorities. So yeah, it doesn't sound to me like just like you're going to adopt micro frontends guarantees one particular set of outcomes. It really is context dependent on what you make of it. RICH: Totally. TARAS: I'm curious though, so with Svelte, essentially for your reactivity engine, you have to compile to get that reactive behavior. RICH: Yeah. TARAS: How does that play with other tools like when you actually integrate it together? I've never worked with Svelte on a large project, so I can't imagine what it looks like at scale. I was wondering if you've seen those kind of use cases and what that ends up, if there's any kind of side effects from that. RICH: As you say, the reactivity within a component is only in the local state within that component or to state that is patched in as a prop from a parent component. But we also have this concept called a store. And a store is just a project that represents a specific value and you import it from svelte/store. And there are three types of store that you get out of the box. A writable, a readable and a derived. And a writeable is just, var count = writable (0) and then you can update that and you can set it using methods on that store. Inside your marker, you can reference or in fact inside the script block in the component, you can reference the value of that store just by prefacing it with a dollar sign. And the compiler sees that and says, "Okay, we need to subscribe to this store as value and then assign it and apply the reactivity." And that is the primary way of having state that exists outside the component hierarchy. Now, I mentioned the writable, readable, and derived are the built in stores that you get, but you can actually implement your own stores. You just need to implement this very simple contract. And so,, it's entirely possible to use that API to wrap any state management solution you have. So you can wrap redux, you can wrap microstates, you can wrap state, you can wrap whatever it is, whatever your preferred state management solution is, you can adapt it to use with Svelte. And it's very sort of idiomatic and streamlined. Like it takes care of unsubscriptions when the component is unmounted. All of that stuff is just done for you. CHARLES: Digging a little bit deeper into the question of integration, how difficult would it be to take wholesale components that were implemented in Svelte and kind of integrate them with some other component framework like React? RICH: If the component is a leaf node, then it's fairly straightforward. There is a project called react-svelte which is, I say project, it's like 20 lines of code and I don't think it's [inaudible] they did for Svelte 3, which I should probably do. But that allows you to use a Svelte component in the context of React application, just using the component API the same way that you would [inaudible] or whatever. You can do that inside a React component. Or you could compile the Svelte component to a web component. And this is one of the great benefits of being a compiler is that you can target different things. You can generate a regular JavaScript class and you've got an interactive application. Or you can target a server side rendering component which will just generate some html for some given state which can then later be hydrated on the client. Or you can target a web component which you can use like any other element in the context of any framework at all. And because it's a compiler, because it's discarding all of the bits of the framework that you're not using, it's not like you're bundling an entire framework to go along with your component. And I should mention while I'm talking about being able to target different outputs, we can also, as a NativeScript project, you can target iOS and Android that same way. Where it gets a little bit more complicated is if it's not a leaf node. If you want to have a React app that contains a Svelte component that has React [inaudible], then things start to get a little bit more unwieldy, I think. It's probably technically possible, but I don't know that I would recommend it. But the point is that it is definitely possible to incrementally adopt Svelte inside an existing application, should that be what you need to do. CHARLES: You said there's a NativeScript project, but it sounds to me like you shouldn't necessarily need NativeScript, right? If you're a compiler, you can actually target Android and you could target iOS directly instead of having NativeScript as an intermediary, right? RICH: Yes. If, if we had the time to do the work, then yes. I think the big thing there would be getting styles to work because Svelte components have styles. And a regular style tag just to CSS and you can't just throw CSS in a native app. CHARLES: Right. Sometimes, I feel like it'd be a lot cooler if you could. [Laughter] RICH: NativeScript really is doing a lot of heavy lifting. Basically what it's doing is it's providing a fake dom. And so, what the NativeScript does is it targets that dom instead of the real dom and then NativeScript turns that into the native instructions. CHARLES: Okay. And you can do that because you're a compiler. TARAS: Compilers has been on our radar for some time, but I'm curious like what is your process for figuring out what it should compile to? Like how do you arrive at the final compile output? Manually, have you written that code and then, "I'm going to now change this to be dynamically generated." Or like how do you figure out what the output should be? RICH: That's pretty much it. Certainly, when the project started, it was a case of, I'm going to think like a compiler, I'm going to hand convert this declarative component code into some framework plus JavaScript. And then once that's done, sort of work backwards and figure out how a compiler would generate that code. And then the process, you do learn certain things about what the points of reusability are, which things should be abstracted out into a shared internal helper library and what things should be generated in line. The whole process is designed to produce output that is easy for a human to understand and reason about. It's not like what you would imagine compile [inaudible] to be like, it's not completely inscrutable. It's designed to be, even to that level of being well formatted, it's designed to be something that someone can look at and understand what the compiler was thinking at that moment. And there's definitely ways that we could change and improve it. There are some places where there's more duplication than we need to have. There are some places where we should be using classes instead of closures for performance and memory benefits. But these are all things that once you've got that base, having gone through that process, that you can begin to iterate on. CHARLES: It's always curious to me about when is the proper time to move to a compiler, because when you're doing everything at runtime, there's more flexibility there. But at what point do you decide, "You know what? I know that these pathways are so well worn that I'm going to lay down pavement. And I'm going to write a compiler." What was the decision process in your mind about, "Okay, now it's time." Because I think that that's maybe not a thought that occurs to most of us. It's like, "I had to write a compiler for this." Is this something that people should do more often? RICH: The [inaudible] of 'this should be a compiler' is one that is worth sort of having at the back of your head. I think there are a lot of opportunities not just in DUI framework space but in general, like is there some way that we can take this work that is currently happening at runtime and shift it into a step that only happens once. That obviously benefits users. And very often we find that benefits developers as well. I don't think there was a point at which I said, "Oh, this stuff that's happening at runtime should be happening at compile time." It was more, I mean, the actual origin has felt that it was a brain worm that someone else infected me with. Judgment is a very well known figure in the JavaScript world. He had been working on this exact idea but hadn't taken it to the point where he was ready to open source it. But he had shared like his findings and the general idea and I was just immediately smitten with this concept of getting rid of the framework runtime. At the time, the big conversation happening in the JavaScript community was about the fact that we're shipping too much JavaScript and it's affecting startup performance time. And so the initial thought was, "Well, maybe we can solve that problem by just not having the runtime." And so, that was the starting point with Svelte. Over time, I've come to realize that that is maybe not the main benefit. That is just one of the benefits that you get from this approach. You also get much faster update performance because you don't have to do this fairly expensive virtual dom different process. Lately, I've come to think that the biggest win from it is that you can write a lot less code. If you're a compiler, then you're not kind of hemmed in by the constraints of the language, so you can almost invent your own language. And if you can do that, then you can do the same things that you have been doing with an API in the language itself. And that's the basis of our system of reactivity, for example. We can build these apps that are smaller and by extension, less bug prone and more maintainable. I just wanted to quickly address the point you made about flexibility. This is a theoretical downside of being a compiler. We're throwing away the constraints about the code needing to be something that runs in the browser, but we're adding a constraint, which is that the code needs to be statically analyzable. And in theory, that results in a loss of flexibility. In practice, we haven't found that to affect the things that we can build. And I think that a lot of times when people have this conversation, they're focusing on the sort of academic concepts of flexibility. But what matters is what can you build? How easy is it to build a certain thing? And so if empirically you find that you're not restricted in the things that you can build and you can build the same things much faster, then that academic notion of flexibility doesn't, to my mind, have any real value. CHARLES: Hearing you talk reminded me of kind of a quote that I heard that always stuck with me back from early in my career. I came into programming through Perl. Perl was my first language and Perl is a very weird language. But among other things, you can actually just change the way that Perl parses code. You can write Perl that makes Perl not throw, if that makes any sense. And when asked about this feature, the guy, Larry Wall, who came up with Perl, he's like, "You program Perl, but really what you're doing is you're programming Perl with a set of semantics that you've negotiated with the compiler." And that was kind of a funny way of saying like, "You get to extend the compiler yourself." Here's like the default set of things that you can do with our compiler, but if you want to tweak it or add or modify, you can do that. And so, you can utilize the same functionality that makes it powerful in the first place. You can kind of inject that whole mode of operation into the entire workflow. Does that make sense? That's like a long way of saying, have you thought about, and is it possible to kind of extend the Svelte compiler as part of a customization or as part of the Svelte programming experience? RICH: We have a very rudimentary version of that, which is pre-processing. There's an API that comes with Svelte called preprocess. And the idea there is that you can pass in some code and it will do some very basic, like it will extract your styles, it will extract your script and it will extract your markup. And then it will give you the opportunity to replace those things with something else. So for example, you could write some futuristic JavaScript and then compile it with Babel before it gets passed to the Svelte compiler, which uses acorn and therefore needs to be able to have managed other scripts so that it can construct an abstract syntax tree. A more extreme version of that, people can use [inaudible] to write their markup instead of html. You can use Sass and Less and things like that. Generally, I don't recommend that people do because it adds these moving parts and it makes like a lot of bug reports of people just trying to figure out how to get these different moving parts to operate together. I don't know, it means that your editor plugins can't understand what's inside your style tag all of a sudden and stuff like that. So, it definitely adds some complexity, but it is possible. At the other end, at a slightly more extreme level, we have talked about making the cogeneration part plugable so that for example, the default renderer and the SSR renderer are just two examples of something that plugs into the compiler that says, "Here is the component, here's the abstract syntax tree, here's some metadata about which values are in scope," all of this stuff and then go away and generate some code from this. We haven't done that so far, partly because there hasn't been a great demand for it, but also because it's really complicated. As soon as you turn something into a plugin platform, you just magnify the number of connection points and the number of ways that things could go wrong by an order of magnitude. And so, we've been a little bit wary of doing that, but it is something that we've talked about primarily in the context of being able to do new and interesting things like target webGL directly or target the command line. There are renders for React that let you build command line apps using React components. And like we've talked about, maybe we should be able to do that. Native is another example. The NativeScript integration as you say, it could be replaced with the compiler doing that work directly, but for that to work presently, that would mean that all of that logic would need to sit in core. And it would be nice if that could be just another extension to the compiler. We're talking about a lot of engineering effort and there's higher priority items on our to do list at the moment. So, it's filed under one day. CHARLES: Right. What are those high priority items? RICH: The biggest thing I think at the moment is TypeScript integration. Surprisingly, this is probably like the number one feature request I think is that people want to be able to write Typescript inside the Svelte components and they want to be able to get TypeScript when they import the Svelte component into something else. They want to be able to get completion [inaudible] and type checking and all the rest of it. A couple of years ago, that would've been more or less than thinkable but now it's like table stakes is that you have to have first-class TypeScript support. CHARLES: Yeah, TypeScript is as popular as Babel these days, right? RICH: Yeah, I think so. I don't need to be sold on the benefits. I've been using TypeScript a lot myself. Svelte is written in TypeScript, but actually being able to write it inside your components is something that would involve as hacking around in the TypeScript compiler API in a way that, I don't know if anyone actually or any of us on the team actually knows how to do. So, we just need to spend some time and do that. But obviously when you've got an open source project, you need to deal with the bugs that arise and stuff first. So, it's difficult to find time to do a big project like that. CHARLES: So, devil's advocate here is if the compiler was open for extension, couldn't a TypeScript support be just another plugin? RICH: It could, but then you could end up with a situation where there's multiple competing TypeScript plugins and no one's sure which ones are used and they all have slightly different characteristics. I always think it's better if these things that are common feature requests that a lot of people would benefit from, if they're built into the project themselves. I go really light in the batteries included way of developing and I think this is something that we've sort of drifted away from in the frontend world over the last few years, we've drifted away from batteries included towards do it yourself. CHARLES: Assemble the entire thing. Step one, open the box and pour the thousand Lego pieces onto the floor. RICH: Yeah, but it's worse than that because at least, with a Lego set, you get the Lego pieces. It's like if you had the Lego manual showing you how to build something, but you were then responsible for going out and getting the Lego pieces, that's frontend development and I don't like it. CHARLES: Right. Yeah. I don't like that either. But still, there's a lot of people advocating directly. You really ought to be doing everything completely and totally yourself. RICH: Yes. CHARLES: And a lot of software development shops still operate that way. RICH: Yeah. I find that the people advocating for that position the most loudly, they tend to be the maintainers of the projects in question. The whole small modules philosophy, they exist for the benefit primarily of library authors and framework authors, not for the benefit of developers, much less users. And the fact that the people who are building libraries and frameworks tend to have the loudest megaphones means that that mindset, that philosophy is taken as a best practice for the industry as a whole. And I think it's a mistake to think that way. TARAS: There is also, I think, a degree of a sliding scale where you start off with like as the more experience you get, because there is more experience you get closer, you get to that kind of wanting granular control and then they kind of slides down towards granular control and then slice back up to, once you've got a lot of experience, you're like, "Okay, I don't want this control anymore." And then you kind of cast that and you get into like, "I'm now responsible for tools that my team uses," and now you're back to wanting that control because you want things to be able to click together. It's kind of like a way that your interest in that might change over time depending on your experience level and your position in the organization. So yeah, there's definitely different motivating factors. Like one of the things that we've been thinking a lot about is designing tools that are composable and granular at individual module level, but combined together into a system for consumption by regular people. So like finding those primitives that will just click together when you know how to click them together. But when you're consuming them, just feel like a holistic whole, but at the same time not being monolithic. That's a lot of things to figure out and it's a lot of things to manage over time, but that's solely the kind of things we've been thinking about a lot. RICH: I think that's what distinguishes the good projects that are going to have a long lifespan from the projects that are maybe interesting but don't have a long shelf life is whether they're designed in such a way that permits that kind of cohesion and innovation tradeoff, if you think of it as a trade off. Anyone can build the fastest thing or the smallest thing or the whatever it is thing. But building these things in a way that feels like it was designed holistically but is also flexible enough to be used with everything else that you use, that's the real design challenge. CHARLES: It's hard to know where to draw that line. Maybe one good example of this and, these are actually two projects that I'm not particularly a fan of, but I think they do a good job of operating this way. So, I guess in that sense, it means I can even be more honest about it. I don't particularly care for Redux or like observables, but we ended up using, in one of our last React projects, we had to choose between using Redux-Saga and Redux-Observable. The Redux-Observable worked very well for us. And I think one of the reasons is because they both had to kind of exist. They had to kind of co-exist is their own projects. Like Redux exists as its own entity and Observables exist as their own kind of whole ecosystem. And so, they put a lot of thought in like what is the natural way in which these two primitives compose together? As opposed to the Saga, which I don't want to disparage the project because I think it actually is a really good project. There's a lot of really good ideas there but because it's more like just bolted on to Redux and it doesn't exist outside of the ecosystem of Redux and the ideas can't flourish outside and figure out how it interfaces with other things. Like the true primitive is still unrevealed there. And so, whereas I feel like with Redux you actually have to really, really true primitives. Now, they're not necessarily my favorite primitives, but they are very refined and very like these do exactly what they are meant to do. And so when you find how they connect together, that experience is also really good. And the primitive that arises there I think ends up being better. Is that an example of what you guys are talking about? RICH: Maybe. [Laughs] TARAS: No, I think so. I mean, it's distilling to the essence, the core of what you're trying to do and then be able to combine it together. I mean, that's been kind of the thing that we've been working on at the Frontside. But also within this context, it makes me think of how does a compiler fit into that? How does that work with the compiler? It's just like when you add the compiler element, it just makes it like my mind just goes poof! [Laughter] CHARLES: Yeah, exactly. That's why I keep coming back to like, how do you, and maybe I haven't, you just have to kind of go through the experience, but it feels like maybe there's this cycle of like you build up the framework and then once it's well understood, you throw the framework away in favor of like just wiring it straight in there with the compiler and then you iterate on that process. Is that fair to say? RICH: Kind of, yeah. At the moment, I'm working on this project, so I referred a moment ago to being able to target webGL directly. At the moment, the approach that I'm taking to building webGL apps is to have webGL components inside Svelte in this project called SvelteGL. And we've used it a couple of times at the Times. It's not really production ready yet, but I think it has some promise. But it's also slightly inefficient, like it needs to have all of the shade of code available for whichever path you're going to take, whatever characteristics your materials have, you need to have all of the shade of code. And if we're smart about it, then the compiler could know ahead of time which bits of shade of code it needed to include. At the moment, it just doesn't have a way of figuring that out. And so that would be an example of paving those cow paths. Like if you do try and do everything within the compiler universe, it does restrict your freedom of movement. It's true. And to qualify my earlier statements about how the small modules philosophy is to the benefit of authors over developers, it has actually enabled this huge flourishing of innovation, particularly in the React world. We've got this plethora of different state management solutions and CSS and JS solutions. And while I, as a developer, probably don't want to deal with that, I just want there to be a single correct answer. It's definitely been to the advantage of the ecosystem as a whole to have all of this experimentation. Then in the wild, there are projects like Svelte they can then take advantage of. We can say, "Oh well, having observed all of this, this is the right way to solve this problem." And so, we can kind of bake in that and take advantage of the research that other people have done. And I think we have made contributions of our own but there is a lot of stuff in Svelte like the fact that data generally flows one way instead of having [inaudible] everywhere. Things like that are the results of having seen everyone make mistakes in the past and learning from them. So, there are tradeoffs all around. TARAS: One thing on topic of data flow here and there, one thing that I've been kind of struggling to compute is the impact of that as opposed to something where you have like one directional data flow because it seems like conceptually it's really simple. You set a property like in two way balance system, like you just propagate through stuff but we don't really have a way, you don't have any way of assessing what is the true impact of that computation. Like what is the cost of that propagation where I think it's almost easier to see the cost of that computation if you have like one directional data flow because you know that essentially everything between the moment that you invoke transition to computing the next state, that is the cost of your computation where you don't have that way of computing the result in a two way balance system. Something like Ember Run Loop or mobx or zones, Vues, reactive system. All these systems make it really difficult to understand what is the real cost of setting state. And that's something that I personally find difficult because this clarity that you have about the one directional data flow and what it takes to compute the next state, it's almost like because that cost is tangible where you're thinking about like mutation of objects and tracking their change like that cost is almost immeasurable. It just seems like a blob of changes that they have to propagate. I don't know. That's just something that I've been thinking a lot because especially with the work that we'll be doing with microstates because as you're figuring out what the next state is, you know exactly what operations are performed in a process where that might not be the case with the system that tracks changes like where you'd have with zones or with Ember Run Loop, or Vue. RICH: I would agree with that. The times that I found it to be beneficial to deviate from the top-down ideology is when you have things like form elements and you want to bind to the values of those form elements. You want to use them in some other computation. And when you do all that by having props going in and then events going out and then you intercept the event and then you set the prop, you're basically articulating what the compiler can articulate for you more effectively anyway. And so conceptually, we have two way bindings within Svelte, but mechanically everything is top down, if that makes sense. CHARLES: Is it because you can analyze the tree of top down and basically understanding when you can cheat. This might be really over-simplistic, but if you're kind of with the event, you're collecting the water and then you have to put it way up on top of the thing and it flows down. But if you can see the entire apparatus, you can say, "Actually, I've got this water and it's going to end up here, so I'm just going to cheat and put it over right there." Is that the type of thing that you're talking about where you're effectively getting a two way binding, but you're skipping the ceremony. RICH: It's kind of writing the exact same code that you would write if you were doing it using events. But if you're writing it yourself, then maybe you would do something in a slightly inefficient way perhaps. For example, with some kinds of bindings, you have to be careful to avoid an infinite loop. If you have an event that triggers a state change, the state change could trigger the event again and you get this infinite loop. A compiler can guard against that. It can say this is a binding that could have that problem, so we're going to just keep track of whether the state changes as a result of the binding. And so, the compiler can sort of solve all of these really hairy problems that you had faced as a developer while also giving you the benefit in terms of being able to write much less code and write code that expresses the relationship between these two things in a more semantic and declarative way without the danger. TARAS: This is one of the reasons why I was so excited to talk to you about this stuff, Rich, because this stuff is really interesting. I mentioned that we might, so we have a little bit more time. So I just want to mention, because I think that you might find this interesting, the [inaudible], the stuff that we were talking about that I mentioned to you before. So, I want to let Charles talk about it briefly because it's interesting, because it essentially comes down to managing asynchrony as it ties to life cycle of objects. Life cycle of objects and components are something we deal with on a regular basis. So, it's been an interesting exercise and experimenting with that. Charles, do you want to give kind of a low down? CHARLES: Sure. It's definitely something that I'm very excited about. So, Taras gets to hear like an earful pretty much every day. But the idea behind structure concurrency, I don't know if you're familiar with it. It's something that I read a fantastic -- so people have been using this for a while in the Ember community. So Alex Matchneer, who's a friend and often time guest on the podcast created a library called ember-concurrency where he brought these ideas of structure concurrency to the ember world. But it's actually very prevalent. There's C libraries and Python libraries. There's not a generic one for JavaScript yet, but the idea is just really taking the same concepts of scope that you have with variables and with components, whether they be ember components, Svelte components, React components or whatever there is, you have a tree of components or you have a of parents and children and modeling every single asynchronous process as a tree rather than what we have now, which is kind of parallel linear stacks. You call some tick happens in the event loop and you drill down and you either edit an exception or you go straight back up. The next tick of the event loop comes, you drill down to some stack and then you go back up. A promise resolves, you do that stack. And so with structure concurrency, essentially every stack can have multiple children. And so, you can fork off multiple children. But if you have an error in any of these children, it's going to propagate up the entire tree. And so, it's essentially the same idea as components except to apply to concurrent processes. And you can do some just really, really amazing things because you don't ever have to worry about some process going rogue and you don't have to worry about coordinating all these different event loops. And one of the things that I'm discovering is that I don't need like event loops. I don't really use promises anymore. Like actually, I was watching, I think it was why I was watching your talk when you're talking about Svelte 3, when you're like -- or maybe did you write a blog post about we've got to stop saying that virtual doms are fast? RICH: Yes, I did. CHARLES: So I think it was that one. I was reading that one and it jived with me because it's just like, why can't we just go and do the work? We've got the event, we can just do the work. And one of the things that I'm discovering is with using the construction concurrency with generators, I'm experiencing a very similar phenomenon where these stack traces, like if there's an error, the stack traces like three lines long because you're basically doing the work and you're executing all these stacks and you're pausing them with a generator. And then when an event happens, you just resume right where you left off. There's no like, we've got this event, let's push it into this event queue that's waiting behind these three event loops. And then we're draining these queues one at a time. It's like, nope, the event happens. You can just resume right where you were. You're in the middle of a function call, in the middle of like [inaudible] block. You just go without any ceremony, without any fuss. You just go straight to where you were, and the stack and the context and all the variables and everything is there preserved exactly where you left it. So, it's really like you're just taking the book right off the shelf and going right to your bookmark and continuing along. Rather than when you've got things like the run loop in ember or the zones in angular where you have all these mechanics to reconstruct the context of where you were to make sure that you don't have some event listener. An event listeners created inside of a context and making sure that that context is either reconstructed or the event listener doesn't fire. All these problems just cease to exist when you take this approach. And so, if it's pertinent to this conversation, that was a surprising result for me was that if you're using essentially code routines to manage your concurrency, you don't need event loops, you don't need buffers, you don't need any of this other stuff. You just use the JavaScript call stack. And that's enough. RICH: I'm not going to pretend to have fully understood everything you just said but it does sound interesting. It does have something not that dissimilar to ember's run loop because if you have two state changes right next to each other, X+=1, Y+=1, you want to have a single update resulting from those. So instead of instruments in the code such that your components are updated immediately after X+=1, it waits until the end of the event loop and then it will flush all of the pending changes simultaneously. So, what you're describing sounds quite wonderful and I hope to understand that better. You have also reminded me that Alex Matchneer implemented this idea in Svelte, it's called svelte-concurrency. And when he sent it to me, I was out in the woods somewhere and I couldn't take a look at it and it went on my mental to do list and you just brought it to the top of that to do list. So yeah, we have some common ground here, I think. CHARLES: All right. TARAS: This is a really, really fascinating conversation. Thank you, Rich, so much for joining us. CHARLES: Thank you for listening. If you or someone you know has something to say about building user interfaces that simply must be heard, please get in touch with us. We can be found on Twitter at @thefrontside or over just plain old email at contact@frontside.io. Thanks and see you next time.

Philippe De Ryck joins the show to talk all things security: the importance and why you should be taking active steps, how to do it in your codebase effectively, and what can happen during a breach. Philippe De Ryck: Pragmatic Web Security Resources: OWASP Top 10 OWASP Top 10 Proactive Controls Please join us in these conversations! If you or someone you know would be a perfect guest, please get in touch with us at contact@frontside.io. Our goal is to get people thinking on the platform level which includes tooling, internalization, state management, routing, upgrade, and the data layer. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES: Hello and welcome to The Frontside Podcast, a place where we talk about user interfaces and everything that you need to know to build them right. My name is Charles Lowell, a developer here at The Frontside. Joining me, also hosting today is Taras Mankovsky. Hello, Taras. TARAS: Hello, hello. CHARLES: And as always, we're going to be talking about web platforms, UI platforms, and the practices that go into them. And here to talk with us today about a pillar of the platform that I certainly don't know that much about, and so, I'm actually really happy to have this guest on to talk about it is Philippe De Ryck who owns his own company called Pragmatic Web Security. I understand you do trainings and are just generally involved in the small space. So, welcome, Philippe. PHILIPPE: Hi. Nice to meet you. CHARLES: Wow! I almost even don't even know where to start with this subject because I'm kind of like the hippie developer mindset where it's like, "LaÖlaÖlaÖlaÖlaÖ we're in this open land and nothing's ever bad going to happen and we're just going to put code out there," and nobody would ever take advantage of any holes or anything like that. And I think that a lot of developers share that mentality and that's how we end up with major, major security breaches. And so, like I said, this is something that I'm actually very eager to learn but I almost even don't know where to start. I need training, man. [Laughter] PHILIPPE: Well, that's good to hear. No, you're totally right about that. If you're not into security, it seems like this fast space for a lot is happening and you don't really know how or why and what really matters to you and should I even be worried about this. And let me start by addressing the very first thing. Yes, you should be worried because maybe you're not building something that somebody cares about but you always have something that somebody wants, even the simplest of attacks always targets a valuable resource. Just to give you a very simple idea today, cryptocurrency is all the hype and you have a taker that's just aiming to misuse your users' computers to mine crypto coins because it essentially saves them a bunch on electricity cost. So, there's always something to grab. Usually, it's data or services or worse. But even in the most minimal cases, you have hardware, you have devices, you have network capacity that somebody might want to abuse. So yes, security, I would say, always matters. CHARLES: What's the best way to get started? You said understanding that everything we do, we're holding onto resources that might be valuable, that someone might want to seize but I'm just getting started with my application. I don't know anything about security. Where do I get started on just understanding the space? And then before I even look at tools that I wantÖ PHILIPPE: You want the honest answer for that? [Laughter] PHILIPPE: The honest answer is probably hire someone who has security knowledge. I don't mean this in a bad way. I've come a very long way in my career doing what I do now. And if I look at that, if you are aiming as a developer with no knowledge about security to build a secure application, it's going to be very hard. There's a lot of things you need to know, intrinsic knowledge. These are not things you can simply read a small book in a week, you know all of these security things that you'll know what to do. So, if you have no previous experience at all, I suggest to find some help. CHARLES: Right. It's like saying, "Hey, you've never written a data layer before but you want to go out and you want to write a massively distributed system where you have all these notes talking to each other. You're not going to read the O'Reilly book 'How to Build Distributed Systems' in a week and go out and do the same thing." It's the same thing with security. You need to understand the entire context. And there's no substitute for experience. PHILIPPE: Sorry, I actually like that comparison because in a sense, you're right, it's like these other very complex topics you don't expect to learn that in a week or a month and right a functioning data layer. But the difference is if you fail at writing that data layer, your application is probably not going to work. While if you fail at securing the application or seeing potential vulnerabilities, it's still going to work just a bit more than you anticipated. It's going to result leaking all your data to an attacker or opening all doors so that they can gain access to your server, stuff like that. So, I would say that the consequences of not getting it right are, at least in the beginning, very invisible. It's only after things happened that it's like, "Oh, crap!" And you should pay attention to that. CHARLES: Yeah. And then you have these back doors and these leaks that are set in stone and may be very hard to change. PHILIPPE: Yeah, absolutely. And honestly, the worst part of the breach is for a company, it might be reputation damage. But what you really should be worried about is all that personal information that's being leaked to, most cases, publicly leaked to anyone but in other cases, it's sold on [inaudible] markets and actually abused by people looking for someone else's identity or credit card information or stuff like that. And the companies usually get away with some bad press, maybe a small dip in their stock price but eventually, they'll bounce back. But it's the users that suffer from these breaches for a very, very long time. TARAS: What do you see the kind of hot zones around concerns that companies have around security? Because I imagine it's hard to be concerned about everything, so they're probably thinking about specific things like this thing worries us. Like what kind of things do you see companies and teams need to worry about? PHILIPPE: That's an interesting question. You have all different kinds of companies and all different levels of security awareness and what they're worrying about. I would say if you have the companies that are not very good at or don't have very much security knowledge, they're probably not to worry about things because otherwise, they would have started investing in improving their practices. If you look at the companies that are at least very aware of the landscape, I'm not saying that anybody here is perfect, but some of the companies are actually doing quite a good job. One of the most interesting challenges today is dealing with dependencies. So, all of your packages, you depend on npm, Maven, Python packages, Ruby gems, and so on. All of them form a huge attack factor in most applications today. That's definitely a problem that a lot of companies struggle with and it's very hard to find good solutions. TARAS: GitHub recently, I saw their vulnerability alert service that I've been getting a lot of notifications from on some of the open source libraries that we use. They have a lot of dependencies. And a lot of projects have the same dependencies. So, the moment that one notification goes on, it like lights up on all of the GitHub repos that I have. So, I have been going through and like updating dependencies and all those libraries. PHILIPPE: Yeah, that's a very good example. Absolutely. A lot of the projects we build today usually start out by installing a bunch of dependencies. Even before you've written the first line of code, you already have a massive code base that you are relying upon. And a single vulnerability in a code base might be enough, it's not always the case, but it might be enough to compromise your application. And that leaves you, as a developer, in a very hard place because you haven't written any lines of code yet. You have built a vulnerable application and that starting point can be very terrifying. So, there's a lot of reports on this. And actually, if you want some numbers, 78% of the vulnerabilities discovered in existing applications like the ones you mentioned. If GitHub alerts you like, "Hey, there's a problem in one of your dependencies," it's often even an indirect dependency, meaning that you include a framework, if you include React or Express or whatever you're building, that one of your dependencies of one of those projects actually has a vulnerability. If you look at the trees of these packages, they get quite big that it's not dozens but it's thousands of packages that we're talking about. CHARLES: Yeah that's the other thing is how do you know how to interpret these security vulnerabilities because some of them, we get a lot of security vulnerabilities for node packages but we only use them for our development tools to build frontend. So, if we're building a React application and there's some security vulnerability in some node packages that we're using in our build tool, then that doesn't actually get deployed to the frontend. So, maybe it's not a concern but if we were actually using it to build a server, then it would be absolutely critical. And so, how do you evaluate because the same security vulnerability is not a vulnerability in one context, but might be in another or maybe I'm thinking about it wrong. You see what I mean? PHILIPPE: Yeah, sure. I totally get what you mean. Actually, I have observed the same things. I also get these security alerts on my projects, and sometimes it's devDependency, so it seems like we don't need to care about that. You're right in the sense that you have to assess the criticality of such a report. So, they will have a rating, a severity rating saying like, "This is a minor issue," or, "This is a major issue," that should be a first indication. And then a second thing to look at is, of course, how are these things used in practice. It's not because it's a devDependency that it's not exploitable because it all depends on what is the vulnerability. If there's an intentional malicious backdoor in the library and you're building that on your build server, it might give an attacker access to your build server. So, that might not be something you actually want to do. So in that case, it does matter. Of course, if it's only stuff you run locally, you can say like, "OK, this is less important." But usually, updating or fixing these vulnerabilities also requires less effort because there's no building and deploying to production servers either. So, it's a matter of staying up-to-date with these. And one of the things that people struggle with is handling this in a lot of different applications. You mentioned you had a lot of GitHub repos and the vulnerability starts popping up in all of them and you have to fix and update all of them. You can imagine that major companies struggle with that, as well, especially if you have quite a few different technologies. Managing all of that is insanely hard. CHARLES: Right, because you just usually look at it and you're like, "Oh, I've got to download this." And maybe, "I haven't used it this repo for a while. I've got to clone it up, I've got to update the dependency. I've got to make sure I run all my tests locally, then run all the tests in CI and make sure I didn't break anything by upgrading. I might have fixed closed security hole but broken my functionality." And so, make sure that that is all intact and then push it out to production. Even on the small, it's like I'm looking, "OK, maybe this is going to take me 30 to 45 minutes." But if you have four or five of those things, you're looking at half your day or maybe even the whole day being gone and that's if you have the processes in place to do those automated verification. If you have a very high confidence in your deployment pipeline which I don't think a lot of places have. So, it sounds like these are complementary, like you really need in order to keep a secure application, you have to keep it up-to-date because I think what I'm hearing is you should just evaluate all the threats. You should fix it if you can. The first part of my question is, am I kidding myself when I say, "Oh, I can ignore this one because it's just local or it's just a devDependency." PHILIPPE: The answer to that question is briefly, I would say they are less critical. CHARLES: That's cool. PHILIPPE: In general, the rule is update if you can. And actually some of the tools out there that monitor vulnerabilities, they will automatically create a pull request in your repo saying to upgrade to this version and then you can automatically run your tests if you have them, and you can very quickly see whether some conflicts are generated by updating that dependency - yes or no. And in most cases, if it's a minor version bump, it's going to work as expected and you can easily push out the new version without that vulnerability. So, I would say fix if you can. If it goes quickly, then definitely fix them. But I would focus on non-devDependencies first instead of devDependencies. CHARLES: Yeah. PHILIPPE: Second thing I wanted to add is you paint a very grim picture saying you have to spend a lot of time updating these issues and I can totally understand that happening the very first time you look into this. There's going to be some stuff in there, I can guarantee that. But if you do this regularly, the effort becomes less and less because once you have up-to-date libraries, the problem is bad but it's not like we have 50 new vulnerabilities every day, fortunately. CHARLES: Right. PHILIPPE: So, once you have done that, it's going to be a bit less intensive than you might anticipate at first glance. Of course, if you're using these projects, if you're reusing the same library, then you'll have to update them everywhere. That's the downside, of course. CHARLES: It's probably a little bit dangerous to be assessing the criticality of the security threats yourself if you're not an expert, and kind of in the same way, it's dangerous to be assessing an architecture if you don't have an expertise in our architecture, I guess is the thing, because you might not understand the threat. PHILIPPE: Yeah, that's, again, absolutely true. It again depends very much on how it's deployed and what it's used for. That's going to be one important aspect. Another thing that might be very useful is, how deep is the dependency that creates the vulnerability or has the vulnerability? Because for example, if you have your tree of dependencies, if you dependency is like five or six levels deep, the chances of malicious data are reaching that specific vulnerability, and that specific library is going to be fairly small. Because usually, libraries have a lot of features and you only use part of them in your application. So, the other one is address of the features is just sitting there and if it's never used and it's also not exploitable. So, that might play a role as well. I saw a presentation about a month or two months ago from how Uber manages these things and they struggled with a lot of those things as well. And they eventually decided that they really care about vulnerabilities going three levels deep. And something that goes deeper is considered to be less relevant or less urgent to update because chances of exploitability are going to be very small. CHARLES: That's actually really interesting. TARAS: One thing that got me thinking about something that is actually happening right now. A friend of mine has a WordPress site that was hacked. But what's interesting about WordPress, I think the fact that WordPress site was hacked is not really a surprise but I think what's interesting about that is that the frequency and the sophistication of these attacks has increased. The tooling has improved also in the WordPress ecosystem. But at the same time, I think there is actually more people that are aware of the kind of exploits that could be done. There are a lot of people going after WordPress sites, but it kind of makes me think that there's probably going to be a time when the vectors of attack for web applications are going to become pretty well known as well. Because of the architecture, there are a fewer of them. But as the awareness of the actual architecture becomes more common, I think the angles of attack are going to become more interesting. Like one of the things that I was reading about a couple days ago is that there are some researchers that found a way to attract users based on a combination of JavaScript APIs that are available in the browser. So, they are actually able to fingerprint users based on the kind of things that they're using, the application for [inaudible] extensions they have installed. I think people are going to get more creative. And that's kind of scary because we've seen this happen already in WordPress and people are greedy. So, there are going to be ways. I think there's going to be more people looking at how to get into and how to exploit these vulnerabilities. PHILIPPE: Yeah. That's actually a couple of very good examples that illustrate the underlying issue. So, this browser-based tracking of users, it's called browser fingerprinting and it's been going on for a while. Back when I did my PhD, I had colleagues working on those things and you have other people at universities doing research on this. And yes, you can use things like JavaScript APIs in the browser to identify a particular user with a very high probability. It's not perfect but it's usually enough to identify a user for ad tracking or those purposes. By the way, these things also have a legitimate purpose. So, they are also used to keep track of a particular user to prevent things like session hijacking or detect problem logins or stuff like that, so they can also have a legitimate use case next to tracking. But they very clearly show how security will always be a cat and mouse game. Tracking used to be easy. You just set a cookie in a browser and the cookie was there next time and you knew who the user was. And then, users became a bit more savvy. You had browser extensions trying to block listings because let's be honest, they're kind of shady. So, users probably don't want that. And then the attacker started moving towards other things and getting more advanced. And you see that in other areas of security, as well. So, I consider that a good thing because as we make things harder for attackers, they will have to get more creative and it will become more difficult to exploit or to take advantage of applications. That's the good side. The bad side or the dark side of that equation is that unfortunately, the vulnerabilities are not going away. It's not because we now have these somewhat more advanced attacks using advanced features or even CView-based vulnerabilities that the old things like SQL injection and [inaudible] have disappeared in applications. That's also not true and that means that it makes it just a bit more harder for everyone on the defensive side to build more secure applications. You're going to have to know about the old stuff and you have to learn about the new stuff. CHARLES: Again, we come back to that idea. It's all a bit overwhelming. Aside from the solution of like, "Hey, let's hire Phillippe. Let's hire some other security expert." We were actually in your training, and obviously, I don't want to divulge all the secrets or whatever. If we were to attend your training, what do you see is the most important thing for people to know? PHILIPPE: There's no secrets there. [Chuckles] What I teach is web security. I kind of like to think I teach that in a very structured and methodical way. But in the end, there's no secrets and I don't mind talking about this here on the podcast because I honestly believe that everyone should know as much as they can about security. What do I teach? I can talk about specifics but I can also talk about generic things. One of the general takeaways is that one of the best things in my opinion that a developer can do is realize when they don't know something and actually admit that they don't know something, instead of just doing something. Maybe having like a brief thought like, "Hmm, is this secure? Well, it's probably good. I'm going to deploy it anyway. We'll see what happens." That is not the right way of doing things. If you do something and you recognize like, "Hey, this might be security sensitive. We're dealing with customer information here. We're dealing with healthcare information. We might want to look at what plays a role here," and then you can go ask someone who does. You probably have a colleague with a bit more security knowledge, so you can ask him like, "Hey Jim, or whatever your name is, do you think that this is OK or should we do something special here?" Very much like you are doing, asking me questions right here. That's one important takeaway that I hope everyone leaves with after a training class because not knowing something and realizing that you don't know it allows you to find someone who actually does. That still leaves us with that point which you wanted to sidestep. CHARLES: [Chuckles] PHILIPPE: A second thing is to realize that security is not a target. It's not something you're going to hit. It's not a holy goal that after working really hard for two years, you're going to hit this security milestone and you're done. It's always going to be a cat and mouse game. It's always going to be a moving target but that's OK. That's how things are. And that's the same with all other things in the world essentially. It's an evolving topic and you'll need to be ready to evolve with that as well. TARAS: One of the challenges that I see into quite often in teams is that at the individual level, people really try to do their best, maybe the best of their abilities. But it's often, when it comes to being part of a group, it's often like they do best within the kind of cultural environment that exists. I'm curious if you've seen good or kind of environments or cultures for engineering teams that are conducive to good security. Are there kind of systems or processes the companies put in place that you've seen to be very effective in preventing problems? Have you encountered anything like this? PHILIPPE: Ideally, you have developers that are very well educated about security but honestly, it's going to be insanely hard to find these people because a developer not only has to be educated about security, they also need to know about UI design and JavaScript frameworks and other frameworks and all of these things. And it's virtually impossible to find someone up-to-date on all of these things. So, what most companies do today that seems to work quite well, even though it's very hard to judge whether it's working or not, is they work with security champions. So, you typically have a dev team and within a dev team, you would have a security champion, one or two or five, depends on how large your teams are, of course, that is knowledgeable about security. So, that developer has some knowledge. He's not an expert but he knows about common attacks and common dangers and how to potentially address them in the application. So, having that person embedded in the team allows the team to be security aware because when you have a team meeting like, "Hey, how are we going to solve this particular problem?" That person will be able to inject security knowledge like, "Hey, that seems like a good idea but if we're using SQL in the backend, we need to ensure that we don't suffer from SQL injection." Or if you're using a NoSQL database, it's going to be NoSQL injection and so on. And that already elevates the level of security in the team. And then, of course, security champions themselves are not going to be security experts. They're mainly developers just with a security focus. So, they should be able to escalate problems up to people with more knowledge, like a security team which can be a small security team within their organization that people can easily reach out to, to ask like, "Hey, we're doing something here and I know that this is security relevant and I'm not entirely sure what's happening here. So, can we get a review of this part of your application?" Or, "Can you guys sit on the meeting to see what's going on and what's happening there?" And I think that structure also makes sense. It's still going to be hard to build secure applications because there's still a lot of things to address, but at least, your teams get some awareness. And then of course, you can help your security champions to become better and they will get better over time. You can augment them with the security architects. You can train your security champions separately with more in-depth knowledge and so on. And that veteran or that setup seems to work quite well in many large organizations today. CHARLES: Yeah. I like that. It gets me to thinking, so having the having the security champions, having people who have this as part of, not their specialization, but at least part of their focus, being in the room, being part of the conversation because we try and do that and provide that service when it comes to UI but we also have a bunch of processes that kind of automate the awareness of quality. So, the classic one is your CI pipeline, your deployment pipeline. So, you're automating your advancement to production. You're automating your QA. It's still no substitute for having someone who's thinking about how to have that quality outcome but you still have some way of verifying that the outcome is quality. Are there tools out there that you can do to kind of keep your project on the security Rails. I'm thinking something that we we've done recently is having preview apps, so that we get a tight feedback loop of being able to deploy a preview version of your application that's on a branch but it's talking to a real backend. There's a lot of more software and services that are supporting this and it's kind of become an integral part of our workflow. So, testing automated deployment preview apps, there's this kind of suite of tools to make sure that the feedback loops are tight and that the quality is verified even though you have people, you also have people guiding that quality. It's just making sure that the standards are met. Is there a similar set of tools and processes in the security space so that we've got these champions out there, they're being part of the conversations. They're making suggestions but they can't be everywhere at once. And is there a way to make sure that the kind of the ways that they're guiding the application, just verifying that the application is going in that direction? Or an alarm bell has sounded. We mentioned one which is the automated pull request with the, "Hey, you got this dependency and there was a pull request." Are there more things like that, I guess, is what I'm saying. PHILIPPE: Yes, there are. But I would dare to say not enough. So yes, you have some security tools you can integrate in your pipeline that do some automated scanning and they tried to find certain issues and alert you of those issues. So, these things do exist but they have their limitations. A tool can scan an application. Some of the findings are going to be easy and fairly trivial, but it's good to have the check in place nonetheless. But some of the more advanced issues are very likely to be undetectable by those automated tools because they require a large amount of skill and expertise to actually craft and exploit to abuse that particular feature in an application. So, we do have some limitations but I like discretion because I do believe that we need to leverage these mechanisms to ensure that we can improve the security quality of our applications. A very simple thing you can do is you can run an automated dependency check when you build the application and you can use that to decide to halt deployment when it's a severe vulnerability or go ahead anyway when you consider this to be acceptable because if you automate all of those things, things can go wrong as well. We can talk about that in a second. So yeah, these things can be done. But what I strongly encourage people to do to ensure that they can kind of improve the code quality is to flag certain known bad code patterns. So if you're building an Angular or a React application, if you're using functions that output go directly into the template, that's going to be very dangerous. So, we know these functions in Angular, they're called bypassSecurityTrustHtml, bypass security should be kind of a trigger and this kind of security irrelevant. And in React, that property is called Dangerously Set innerHTML, also indicating like a 'developer watch out what you're doing'. So, what you could do is you could set up code scanning tools that actually flag these things whenever they appear in application because sometimes people make mistakes. You hire an intern and they don't really know the impact of using that property and they use it anyway which would cause cross-site scripting vulnerability. If you're code scanning to flag these things ensures that it doesn't get pushed to production unless it's a benign case which is actually approved to be in there, then you can definitely stop some of these attacks coming on for sure or some of these vulnerabilities happening. TARAS: I think the hardest thing to understand is when someone doesn't understand what they're doing that what they will create is so cryptic that I think any tool that tries to figure out what it is that person is doing I think will have a really hard time. The person making the thing doesn't understand what they're doing, then the system is not going to understand what they're doing which makes me think that one of the things that we think about a lot at Frontside is this idea of trying to understand the system from the outside as kind of looking at a system as a black box and wonder what kind of tools are available specifically for inspecting the application from the outside, like as if somehow understanding what the application is doing based on what's actually going on inside of the runtime and then notifying someone that there could be something off in the application, but through exercising the [inaudible] things like, for example, memory leaks is not something you can catch unless you have a test suite that has like a thousand tests and then you will see over time that your application is actually leaking memory. But if you run individual tests, you'll never see that. I wonder if there's anything like that for security where at runtime, there's actually a way to understand that there might be some kind of a pattern that's incorrect in the application. PHILIPPE: If only, if only. It depends on who you ask. There is such a concept that's called Dynamic Application Security Testing. Essentially, what you do there is you run the application, you feed it all kinds of inputs, and you monitor when something bad happens. And that means that you have detected vulnerability. So, these things do exist. But unfortunately, their efficiency is not always that good. It very much depends on what kind of security problems you're trying to detect. And they can, for example, detect some instances of things like cross-site scripting or SQL injection or things like that. But there will always be limitations. I've seen tools like that being run as an application where you actually know there's a vulnerability because it has been exploited. There is a manual written exploits and the tool still doesn't find any vulnerabilities which is not surprising, because these things are really hard to make an abstraction of to be able to find that in an automated way with a tool. If you would have such a tool that would be, I think, that [inaudible] would be a lot better. I think there's a lot of funders working on that. But at the moment, those tools are not going to be our savior to build more secure applications. CHARLES: Yes. I mean, it's kind of like linting, right? Or you can make tests. We've been through this kind of all the features or the aspects that we want our application to have, whether it be accessibility. There's certainly a very comprehensive suite of lint level checks that you can run to make sure that your application is accessible. You can run a suite of three thousand things and if it triggers any of these things, then yes, your application won't be accessible but it's not a substitute for thinking through the accessibility architecture. The same thing goes with code linting. You're not going to solve bugs with a linter that makes sure that it's formatted and that you're declaring your variables right and that you're not shadowing things. But you can definitely eliminate a whole classes of things that might be put in there just for maybe even you know what you're doing and you're just forgetful. PHILIPPE: Yes, these rules exist, as well. They're not extensive but there are linting rules for Angular used for security, for example. But the problem in linting is that they are very useful to find potential instances of security relevant features or security relevant functionality. But the linting rule alone cannot decide whether something is OK or not. Just to give you a very simple example, if you use the bypassSecurityTrustHtml function, if you give that function a static snippet of HTML, that's going to be fine unless you write your own attack essentially. But if you feed that function user inputs, you're going to be in a lot of trouble. And making that distinction with a linter is going to be difficult unless you have a static string in the arguments. But if once you start having that from variables to dynamically decide to have a different code path, then that's going to be very, very difficult to decide automatically. So, yes, you can use that to find the places in the application where you should be looking for, in this example, a cross-site scripting in Angular but the linting alone is not going to give you an answer whether this is OK or not. That still requires knowledge of how Angular handles this things, what happens, and how you can do things safely. TARAS: Sounds like we keep going back to nothing beats having knowledgeable developers. PHILIPPE: Yes. Unfortunately, that is true. However, with that said, I want to highlight that frameworks like Angular, well mainly Angular, make things a lot better for developers because yes, you still need knowledgeable developers but the ways to introduce a cross-site scripting vulnerability in an Angular application are actually very, very limited. It's not going to be one, but there's going to be maybe three or four things you need to be aware of, and then you should be set. While if you would have done the same for PHP, it's going to be 50,000 things you need to be aware of that are potentially dangerous. So, yes, frameworks and libraries and all of these abstractions make it a lot better and I really like that. That's why I always refer to abstract things away in a library so that you actually have the ability to look for this dangerous code patterns using linting rules in your code base and that you can, at least, inspect the go to see whether it's OK or not, even though you might not be able to make an automatic decision. You, at least, know where to look and what to approve or how to change in the code base. TARAS: I think that's one of the things that oftentimes is not taken into account that the frameworks are different. And I think of big differences in how much -- like right now, the most popular framework, I think, React. But it's such a thin layer, it's such a small part of the framework that you can hardly call it a framework. But it is something that companies rely on. But then when you consider how much of that code that you need to write, to make React into a complete framework for your company, the amount of code that your team has to write versus the amount of code that your team has to write when you use something like Angular or Ember, there's definitely a lot less parts of the framework that you need to write or a lot less parts of the framework you need to choose from what's available in the ecosystem. Like in Angler and Ember, and I'm not sure what the story is with the view, but the pieces, they come from kind of a trusted source and they've been kind of battle tested against a lot of applications. But I don't think that enters into consideration when companies are choosing between Angular or whatever that might be because they're thinking like what is going to be easiest for us. What is going be [inaudible] for developers? They're not thinking about how much of the framework are we going to need to put together to make this work. CHARLES: I can say it sounds, Taras, like almost what you're saying is by using the frameworks that have been battle tested, you actually get to avail yourself of code that actually has security champions kind of baked into it, right? Is that what you were saying? You keep coming back to 'you need developers who are knowledgeable about security', and if you're using kind of a larger framework that covers more use cases, you're going to get that. Do you think that that is generally true, Philippe? PHILIPPE: Yeah. I think it is and that's why I mentioned that I liked Angular before because Angular actually does offer a full framework. And because they do that, they made a lot of choices for developers and some of these choices have a very, very big and positive impact on security. On the other hand, if you make those decisions, you become an opinionated framework and some people don't like that. They actually want the freedom to follow their own paths and then a less full featured framework like React might be an easier way to go. CHARLES: But I think what happens is folks don't enter into that decision with their eyes open to the fact that they then now need to be their own security champion because they just don't even see it. We said the most dangerous thing is the things that you don't know. PHILIPPE: Yeah, absolutely. And I totally agree. That's something that's at least a couple of years and probably still today, many companies moving into this space struggle like, "Which framework do we choose and why do we choose one or the other and which one will still be there in three years because we don't want to switch to another thing in three years," which is risky to our developers. I like that you said that Angular has this security champion knowledge built in because in Angular 2 and every version behind it, but the new version of Angular essentially, they spent a lot of time on security and they learned from their mistakes in the first version because there were some and they took that and they built a more robust framework with security built in by design or by out-of-the-box. Angular offers, for example, very strong protection against cross-site scripting. It's just there, it's always on and unless you actively sidestep it, it's going to protect you. And that's one of the things I really like about Angular and how they did that. CHARLES: Yeah, that's one of the things that I really like too because I remember there was a blog post back, this is probably, I don't know, almost 10 years ago now, maybe seven or eight years, where someone was comparing why they were more interested in using, their servers were implemented in Ruby and why it was better to use Rails than just Sinatra which is just a very, very, very lightweight HTTP framework. And one of the things that he was pointing to was this new vulnerability was discovered and if you were using Rails, the middle way where the middle square stack is managed by the framework, you just upgrade a minor version of Rails. And now, by default, there's this middleware that prevents this entire class of attack. PHILIPPE: Was that a cross-site request forgery? CHARLES: I think it might have been. PHILIPPE: I think Rails was one of the first to offer built in automatically on support for that. So yeah, that was a very good early example of how that can work really well. CHARLES: And the advantage from the developers' standpoint, because the contrast that, if you'd been writing your application in Sinatra which is this is very, very low level based right on top of rack and you're managing the middleware stack yourself and there are no opinions, then not only do you have to like fix this security vulnerability, you have to understand it. You have to get to do a lot of research to really come up with what's going on, how is this going to affect my application and then I can deploy a fix. And that's like a huge amount of time, whereas you have the freedom to not even understand the attack. I mean, it's always better to understand but you can defer that understanding invariably knowing that you're kind of invulnerable to it. And I think for people who enjoy kind of pretending, not pretending, but that the security world doesn't exist and say, "Hey, I want to focus and specialize on these other areas and attain deep knowledge there." It's very reassuring to know that if a defense for a novel attack comes out, I can avail myself of it just by bumping a version number. PHILIPPE: Yeah, absolutely. If you have everything in place to actually upgrade to that version that fixes those, that's a preferable solution. Towards the future, I believe it's going to be crucial to ensure that we can actually keep things up-to-date because everything that's being built today is going to require continuous updates for the lifetime of the application. I definitely hope that the frameworks get better and more secure and start following these patterns of naming the potentially insecure functions with something that indicates that they are insecure. I think that's definitely a good way forward. CHARLES: Yeah. Can I ask one more question? Because this is something that is always something that I wonder about whenever you talk about any aspect of a system. And part of it is folks will not appreciate good architecture until they've experienced some sort of pain associated with not having that architecture in place. Their project fails because they couldn't implement a set of features without it taking months and years and they just ran out of runway, ran out of deadline. Those types of people who've been on those projects appreciate having a nimble system internally, good tooling. Folks who have experienced good tooling understand how much time they could save, and so, have a very low tolerance for bad tooling. A tool takes too long or is misbehaved or is not well put together, they just can't stand because they know how much time they're losing with security. Is there a way to get people to care about it without having some sort of breach, without having gotten smacked in the face? When you do your trainings, is it generally, "Hey, someone has experienced a breach here, and so they want to bring you in." Or is there some way to get people raise awareness of the problems they don't have to experience that pain but can just experience only the benefit? PHILIPPE: That's, again, a very good question and that's also a very good illustration of why security is so hard. Because if you get everything right, nothing happens. [Laughter] PHILIPPE: Or it might be if nothing happens, that nobody cares enough to actually try something against your application. So, there's no positive confirmation if you've done a good job. You can keep putting things off but eventually, there's going to be vulnerability and it's a matter of how you respond to it. We recently had a cross-site scripting in Google's homepage, one of the most visited pages on the web. And somebody figured out that there were some weird browser thing that could be abused and that resulted in a vulnerability on, let's say, such a simple page. So, even there, things can go wrong. So, what would be a good way to draw with some awareness about this is I would recommend following some simple new resources or some Twitter feeds. I have some security relevant articles there but plenty of other people in the industry have as well. And when you read such an article about security incidents, just think about whether this could happen to you or not. And that should probably scare the shit out of you. Simple examples like the Equifax breach, one of the biggest, most impactful breaches of the past few years happened because of an Apache library that was not updated. I think the Apache library, they had a known vulnerability in there. We knew about it. We had a patch, yet it took too long to install that patch and the attackers abused that vulnerability. This is something that probably can happen to each and every one of us because the attacks started, I think, 72 hours after the vulnerability and the patch had been published. So, ask yourself, "Would I have updated my servers in three days after I got that vulnerability report on GitHub?" Yes or no. And if the answer is no, then the same thing can happen to you. Other cases: Magecart is a very big problem, people injecting credit card skimming malware in the JavaScript library. Are you including third party JavaScript libraries? If yes, then chances are that this can happen to you. And there's nothing preventing someone from exploiting that. It's probably just because you got lucky that nobody tried to do that. And the same thing you see now with all these attacks npm packages where people actively try to get you to install a malicious package as one of your dependencies. And again, everybody can fall victim to these things. So, if you read the articles with that mindset, I probably guess that your security awareness will grow rapidly and you will start caring about that very fast. CHARLES: Yeah. TARAS: Lots to think about. CHARLES: Yeah, there's lots to think about because the next thing that occurs to me is how do you even know if you've been targeted. Because a good attacker is not even going to let you know. PHILIPPE: Yeah. CHARLES: It's just better to siphon off your blood, like you said, than to kill the -- you want to be a vampire bat and come to the same cow every night and just take a little bit of blood rather than the lion that kills the cow and then the cow's gone. PHILIPPE: I would say constant monitoring is going to be crucial and you need that data for all kinds of different purposes. You need to monitor everything that happens, first of all, for a post-mortem analysis. If something happens, you want to be able to see how bad it was. This user apparently got a full admin access and if you have decent monitoring, you will be able to retrace his steps to see what they did or did not get. So, that is one very good use case. A second use case is you can use that data to detect attacks. Usually when the attacks are noisy, it's an automated scanning tool but it might be an attacker trying to do things. Again, that may be something very useful for you to act on to see if there is a problem to prevent that user from connecting, or so on. And then, another very good use case of these things is actually inspecting the logs manually as an ops engineer or whatever, who is responsible for doing that, because that might again yield new insights. I've been talking to someone who said that they discovered an abuse of one of their APIs just by looking at the logs manually and detecting a strange pattern and looking and digging deeper into it. And the automated monitoring tools that they had installed that trigger on certain events like a mass amount of requests to the authentication and stuff like that, they did not catch this particular abuse. So, I would say monitoring there is absolutely crucial, for sure. TARAS: So, the takeaway is higher attentive knowledgeable developers who will learn about security. PHILIPPE: I would say the takeaway is security knowledge is essential for every developer. So, I encourage every developer to at least have a little bit of interest in security. I'm not saying that everyone should be a security expert. We should at least know about that the most common vulnerabilities in web applications, what they mean, what they might result in, and what to be on the lookout for. So yes, I think that's one of the crucial things to start with. And then within an organization, you should have someone to fall back on in case that there are security relevant things that you actually can talk to someone who does see a bigger picture or maybe the full security picture to decide whether these things are a problem or not. I think we're closing or nearing the end here, but one of the things we haven't talked about is how to actually get started in security. What if you are interested in security after hearing this podcast and you want to get started? I want to give you just a few pointers so that you actually know where to look. One of the first things to look at is OWASP. And OWASP is the Open Web Application Security Project. It's essentially a nonprofit that has the mission to improve the security posture or knowledge of developers, and they have a lot of resources on various different topics. They have a lot of tools available and things like that. What you want to start with as a developer is the OWASP Top 10, which is a list of the 10 most common vulnerabilities that exist in applications, just to open your eyes like these things exist in applications today and are definitely a problem. And then, there's a complementary Top 10 called the Proactive Controls and that's about how you, as a developer, can actually prevent these things. So, what should we know about implementing security, which guidelines should we follow. And these two documents are a very good place to start. And then there is a huge community that's actually mostly very eager to help people figure out the right way of doing things and solving these problems we have in our ecosystems. TARAS: Awesome. That's great. Thank you very much. CHARLES: Yeah. I'll take that in. That is really, really helpful. Well, thank you very much, Philippe, for coming on and talking about security. I actually feel a lot better rather than usually I'm thinking about securities kind of stresses me out. [Laughs] PHILIPPE: You can bury the problem but it's going to return in the future anyway, so you might as well get onboard and start learning. It's not that scary if you actually -- it's a lot of fun. So, you should learn about security. CHARLES: Well, I am looking forward to diving in. If anyone wants to get in touch with you, how would they do that on Twitter or Email? PHILIPPE: Yeah, sure. I'm on Twitter. I'm always happy to chat about security. You can reach me by Email as well. I'm very easy to reach. And I'll be happy to help out people with questions. Sure. CHARLES: All right. Thank you so much, Philippe. Thank you for listening. If you or someone you know has something to say about building user interfaces that simply must be heard, please get in touch with us. We can be found on Twitter at @TheFrontside or over just plain old Email at contact@frontside.io. Thanks and see you next time.

In this internal Frontside Podcast episode, Charles, Taras, and Jeffrey analyze the NativeScript Mobile Platform. Please join us in these conversations! If you or someone you know would be a perfect guest, please get in touch with us at contact@frontside.io. Our goal is to get people thinking on the platform level which includes tooling, internalization, state management, routing, upgrade, and the data layer. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES: Hello and welcome to The Frontside Podcast, a place where we talk about user interfaces and everything that you need to know to build them right. My name is Charles, a developer here at Frontside. With me today are Taras and Jeffrey. TARAS: Hello everyone. CHARLES: Today, we're going to be talking about NativeScript, in particular, and evaluating technologies and frameworks, kind of at the meta level. So, I'm kind of excited about it because we've been pretty heavily involved with NativeScript for the past three months or so. And so, we've gotten to look at it both from beginners' eyes being kind of totally fresh to the platform, but then actually having to start to pump up against some of the edge cases which is what always ends up happening when you actually use a framework for real. Let's get started. TARAS: All right. I think there's a lot of things that we could talk about because when we would start looking at NativeScript, the length that we were looking at NativeScript through this is that this platform that our client is going to be using for doing development of large applications. So, what does NativeScript need to have to be able to support potentially hundreds of developers building apps? We started looking at it and one things that made us consider NativeScript early on was it kind of provides a platform that allows you to encode in JavaScript and run it on mobile. And we saw this kind of emergence of Angular and Vue.js running on top of NativeScript. So, those things together is kind of exciting. CHARLES: There was also an implementation in progress of React and there were a couple of spikes of Ember also running on top of NativeScript. So, my first impression was initially very favorable. The onboarding experience is actually pretty nice because it was JavaScript and the application was interpreted, there's the ability to completely and totally dynamically change the application at runtime. So, they have essentially an application called the NativeScript Playground which lets you flash a QR code at it and then it will go in to the URL associated with that QR code and it will download all of the assets for a NativeScript application running at that URL. So, all the JavaScript, all the templates, all the whatever, it'll pull it down, it will actually start running like within that app. So, the Playground app then becomes your actual app that you want to use. There's no App Store, no TestFlight, no Google Play. There's no gatekeeping to delivering your application into a running app. And I thought that was really, really cool and really, really compelling. TARAS: We should clarify that this is specifically for preview purposes because if you're going to be shipping the application to production, you still need to go through all those things before... CHARLES: Yes. TARAS: But the onboarding process, you could just install the preview app and then you can point a QR code and it will open that app, whether it's in Angular or in Vue, that app will open up in the preview app and you have a native app that you could play around with. CHARLES: Right. JEFFREY: And that's key both for the engineers who are playing around with this and building this and also really key for the non-engineers who are part of the team to be able to really easily spin up and see what the engineers on the team are working on. CHARLES: That's exactly why we thought, "Hey, we want to be able to use this mechanism for preview apps." In the same way on the server side, you have preview apps associated with a pull request. When we saw this, what we immediately wanted to do was have a bot post a comment onto a pull request with a QR code, so that anybody could just, boom, test out this app on their phone. TARAS: We ultimately ended up setting that up but not quite that way because the original idea of being able to have something like danger bot post the QR code to the comments, you can kind of point out with your phone and open the preview app, that didn't actually pan out. Charles tried to implement that. What happened there? CHARLES: What it actually turned out was that the preview functionality was dependent on a central server, a central NativeScript server. So rather than kind of statically bundling the assets and just saying 'these assets are this URL and just pull them in and bootstrap your NativeScript application that way', it required a lot of extra stuff. So, it required you to be running a Webpack Dev Server that was building your assets and then basically registering and doing some port forwarding with that dev server to a central NativeScript service that was provided by the company that underpins NativeScript. And that connection needed to be hot and live the whole time for that to work. So, while it was really cool that you could get the QR codes up and running, unfortunately that functionality could not be decoupled from the hot update and the central service. Those central services were kind of hard coded into the tools. TARAS: Yeah. So we eventually ended up implementing the preview apps that we wanted but we ended up using Appetize.io to essentially -- the process there is you build the app, you upload the app to Appetize and then danger bot embeds a link to a URL where you can open that app and it will essentially stream like it's running somewhere in a simulator for iOS, an emulator for Android and it will stream a video of that and you can interact with it, kind of like a VNC setup. CHARLES: Yeah. TARAS: And that actually accomplished the goal. It's just we weren't able to do the way that we thought we were hoping to do it straight off with the preview app mechanism. CHARLES: It accomplished the goal. And Appetize is an incredible service that lets you preview the apps on pretty much any type of Android device, any type of iOS device, right there inside of a pull request. But what it didn't allow us to do was pop up your actual device, your actual phone and scan a QR code off of the pull request and pull down the assets. That would have been amazing. But it doesn't always work out that way. And I don't know if that would work long term anyhow because you can't pull down native libraries over the wire and funk them in. That's a big, big no-no. So, the process does have limitations. But nevertheless, that part was really cool. TARAS: Yeah. That was kind of the entry point, the onboarding. And then I think one of the things that was kind of, I remember at the time when we were talking about the NativeScript architecture because we were starting to understand more about how it works. The idea itself is really kind of amazing actually because you have this V8 where you can run your JavaScript code and then they're kind of wired together on iOS and Android. They're wired to the native implementation. So when you're interacting with it, I think the thing that's really great about NativeScript is that the runtime environment for JavaScript essentially gives you API access. In JavaScript, you could say, "I want to create a Java view," and there will be a Java view that's rendered in the actual native device. You're using the same -- the APIs that you find on the Android docs or iOS docs, all of those APIs are available to you as JavaScript. So, you [crosstalk] as JavaScript. And it's seamless, right? CHARLES: Yeah, and it makes it very, very handy. The language is different but the APIs are exactly the same. There is an attempt to make cross-platform components and cross-platform classes that serve the needs on both platforms and then delegate to the platform on which you happen to be running. But those are not mandatory, and the low level APIs are always available to you. An example of this is in iOS, kind of the core foundational object is NSObject. All the controllers, the views, the things, all of them are descended from this object. I can go from object and I can go in from JavaScript and I can just say {let object = new NSObject} and boom! I've got a reference to the actual object and I can pass it around to any other iOS API. That is really, really powerful that there's nothing off limits. There's nothing at an arm's distance. There's really not much you can't do because all of those things are available to you. There's nothing that's off limits. That means that they can build cross-platform components on top of those APIs. Whereas a sort of system like React Native which does have cross-platform components, that's kind of where the base layer is but you can't crack open the hatch and go down the next level and start mucking around, unless you want to actually start meddling with the React Native source code or recompiling Swift in Java code. TARAS: For me, I think this architecture is probably my favorite part of NativeScript. JEFFREY: Mine too. CHARLES: Yeah, me too. TARAS: I really like this part. I kind of hope that everything else is as clever as that was. CHARLES: Because among other things, it allowed us to write a Bluetooth. We were able to implement Bluetooth using nothing but JavaScript. We didn't actually have to go down and do any Swift and do any asynchronous message passing between the iOS libraries and the JavaScript libraries. It's like, "No." We've just got a very simple cross-platform interface that instantiates an implementation for Android and an implementation for iOS, but both of them are like JavaScript. And so, it really is you're doing native development but it's JavaScript all the way down. TARAS: Yeah. And when you're writing plugins, your plugin is actually JavaScript plugin that is assuming iOS APIs and Android APIs. CHARLES: Yeah. And if you have to have a native plugin like a CocoaPod or an Android Package, you just install it and you can instantiate it from JavaScript. There's no fuss, no muss, no ceremony. It's just like, "Hey, I want to use the..." what was the one we like to use? The Material-UI floating button which is a CocoaPod. You download it, you link it into your application, and then you just instantiate it from JavaScript. TARAS: That was really cool. The challenging part was that a lot of that kind of awesomeness, like everything around it wasn't quite as polished. And so, one of the big things is that like around tooling, because one of the things about having grown up in a way like in the Ember community, in a sense, we have a certain expectation of what the level of polish from tooling that we would expect. And it's kind of supported in the way like when you look at how React or React Native tooling is, even Angular tooling, it's very polished. You kind of expect to see what you need to see when you're looking at a CLI input and you don't see anything else. That level of polish. I think part of the changes that they're going through, maybe that's part of the reason but that same level of polish isn't available around the tooling. CHARLES: There are these fantastic qualities about the platform and it is amazing. We were using Angular and a lot of people are using Vue and things like that and that actually is pretty incredible. And there is nice tooling, there is command line stuff, but we started to run into issues where, for example, it was very clear that we were pretty much, as far as I could tell, one of the very, very few people running a NativeScript project on CircleCI or in a CI environment at all. It had capability for testing, both for acceptance testing and for unit testing, but it required changes to the core framework and the core tools in order to get those tests to work in a CI environment. JEFFREY: Before we kind of get into the testing story there, some of the issues were around determinism of reliably reproducing your whole NativeScript environment and stack every time because that's such a key feature of doing it. And on a CI server, it's like, "Hey, we need this to load in the same exact packages every time." And so, we ran into challenges there. TARAS: I think we spent almost two days. There's example projects in different combinations. One thing that was off was that there's a pattern that is applied in a lot of the plugins in NativeScript ecosystem is installing things. So, you run npm install and npm install will generate some files. And so, when we're trying to move it over to a CI, there were files, like there's hooks, like TypeScript hooks that were excluded that you can ignore, but they were necessary to compile the TypeScript. And so, what was happening is when we're running these at CI, the application, we would build the app but the app would crash the moment that you start it. And the reason for that was that the JavaScript files that were transpiled from TypeScript to JavaScript, those JavaScript files were actually never included because they were never transpiled in CI because the hooks directory, like we weren't preserving it between our tasks and so... CHARLES: Right. We weren't caching. This was an artifact of the install. And so, we were caching the install, so essentially the yarn.lock was not changing. But the directory was not getting generated unless the cache key changed. TARAS: And we spent spent quite a lot of time... CHARLES: Two or three days out. TARAS: Yeah. CHARLES: What that said is, "Oh, nobody's really running this in CI." Nobody's actually building an app from scratch every time. TARAS: There are people in NativeScript team that actually does a great job of documenting. They did have example projects that exist but sometimes that example project doesn't fit like a perfect combination of what you're looking for. There was an example project that was showing how to run on CI but it didn't use TypeScript. And so, that's where we lost a lot of time. CHARLES: Right. JEFFREY: So, let's talk about testing since that's kind of the core, the most important part of why you even want continuous integration capabilities to begin with. What did we run into there? What did it look like? TARAS: Well, I think it's safe to say that we were really on a bleeding edge of testing capabilities in NativeScript ecosystem with Angular, at least. But I think it was still an interesting project. We were using the latest builds. And I have to say I think this is one of those things that's going to be kind of consistent through this, is like the people in NativeScript team are amazing. They're so easy to work with. They're so accommodating. When we ask for stuff, they're on it. But it was a lot of things we're trying to figure out like how do we run unit tests, what can we do. Ideally, we wanted to run, first and foremost, we started with how do we run functional testing. So we spent quite a lot of time trying to get Appium set up. I spent a good two to three weeks on that and it was not productively spent time. CHARLES: I think ultimately, we had to pull back from it. And there were a number of reasons. Part of that is there are multiple paradigms for how you can build your NativeScript application. So as we speak, there's a move towards using Webpack to build all of your JavaScript in your style sheet assets because it's very much like a React Native application. You've got style sheets, you've got JavaScript assets, that some of them might be in TypeScript, some of them you might be using Babel, and you need to actually transpile them down to include them in a way that your underlying JavaScript runtime is going to be able to understand. But that wasn't always so. They have their own build system and packaging system, they kind of used the TypeScript compiler ad-hoc, if you were using TypeScript, which we were. And so, this was kind of this orthogonal complexity, I guess, where you have your unit testing and it has to play nice with this one package or Webpack. There were multiple ways to package your app. And so, we ran into problems where, like TypeScript kept coming up as a problem and the way in which we were bundling our assets. So, in order to get TypeScript to work, we kind of had to get Webpack running. But the problem is it felt like three quarters of the tooling wasn't Webpack compatible yet. And so, it meant that other pieces of the build were breaking because of this. And so, we had to be on the bleeding edge of several different aspects of the runtime. And the problem is when you're on the bleeding edge, that can break other stuff. TARAS: But there's complexity in running on native platforms that I think a lot of this complexity is kind of leaking to development experience because one of the challenges is your tests need to run on the native device in the application. So, you have to build the app. You have to push the app into the actual device. So, there's like all the setup of installing the at the app on the device. CHARLES: You have to launch the simulator. TARAS: Yeah, right. CHARLES: To make sure the device is connected. TARAS: And you run your tests in there. So, that created kind of this situation where we say let's just kind of set Appium aside and just use unit testing which is a very small fraction of the kind of testing that we actually want to do. It will test very little. But let's just do that because getting functional testing to work was really kind of not going anywhere. So once we start doing unit testing, one of the challenges is that it takes like 30 seconds to start your tests. And then, if you for whatever reason, made a mistake, the moment you cancel the build, it leaves, like it doesn't clean up of itself well. So, it leaves processes running in the background. And so now, you spend another like 10 to 15 minutes Googling around for a cookie, "How do you find these processes and stop them?" So, we eventually settled on having a script that does that, but this is the kind of things you have to end up doing because there's a bunch of things that are wired together, but they're not wired together in a way that is seamless. And so, you end up kind of just debugging a lot of stuff where you just want to run some tests but you end up doing all these other stuff. CHARLES: Right. TARAS: And you spend a couple of minutes just doing something that you'd expect to happen in like 20 seconds. CHARLES: Right. There is a feeling that every aspect of the system is coupled to every other aspect of the system in kind of varying ways of interconnectedness. And that's not what you want for a very, very complex system. You want it to be extremely modular. So, I think we should keep the command line tool. There's probably a separate discussion, I think, about that. But you have to close the book on the Appium and the unit testing. I think the other problem was that you have to run these things on simulators. On macOS, that's not a problem because the simulators ship with X code. And so, you don't actually require an external service. Whereas in CI on Android, it's very unlikely that you're going to have Android emulators on hand because they require a separate virtual machine. Android emulation is actually quite heavy. If you're running through Android Studio or something locally, you essentially need VirtualBox or some equivalent to run your Android simulator because you actually need that simulated hardware. If I understand correctly, that was actually not something that had been really accounted for. It was that you might want to be running simulators not on the same machine as what you were developing on or what the actual that you were building on. TARAS: Yeah, a lot of the tooling seems to be designed around this idea that you're going to be building and running everything on your machine. And so, you can spin up a virtual machine easily. But in CircleCI, for example, they don't support running a virtual machine inside of a Docker container because for that, you need a feature of a virtualization that is not supported in many CI platforms. You have to run a parallel server if you want to have like Appium running, for example. You need to have a separate server running like an Azure or a Google Cloud somewhere that is able to run virtualized servers that have a host machine that's being guest systems that are running the actual Android emulators of different versions. And so, when I started doing research in this, there are companies that are doing this really well but it's not unusual to be using hardware from Amazon that costs thousands and thousands of dollars per month. I think for anyone who's getting into mobile development, I would say the hidden gem of Android world is Genymotion. Those that do a lot of Android development, they know about it. But Genymotion has both like a desktop environment and it has SaaS offering that they're in the process of releasing. And so, what it allows you to do is when you run it locally or on your local machine, it allows you to create a virtual machine that is running in VirtualBox and then it allows you to run kind of optimized environment for running Android. And when you do that, it's really fast. It's very smooth. It makes running Android devices locally as easy as it is to run iOS devices on macOS. CHARLES: I remember starting out and trying to actually just get any Android emulator running on my Mac and I couldn't even do it. JEFFREY: It was such a huge time saver. CHARLES: Yeah. TARAS: And to have this Saas offering is really great because you could basically create your virtual machines on demand and then you install into a virtual machine from your CI server and then you run your tests there. That's kind of the key that I found to be able to run tests and automate it against emulated devices for Android. Genymotion is really great. CHARLES: Yeah. Again that's the kind of thing that you need when you're in CI. And so, one of the things, I think, one of our discoveries is that there just isn't -- when we started working on this and we haven't seen a culture of running these tools in the cloud and accounting for the fact that you might have not all of the tools running on the same machine. From, I would say, the beginning, I remember the kind of the diagnostics command didn't work but we were running it on a CI server. So, there's a diagnostics command that you run to see do you have this, do you have that, do you have that. It would work and give meaningful results when I wanted to debug my CI server because when we were initially getting set up, something wasn't building right, there was some dependency missing. And I just wanted a diagnosis but it was trying to install all those tools for me. And I was like, "No, no, no. I don't want you to do anything. I don't want to install them. I'm going to be doing all of that as part of the setup of the CI environment. It's going to be installed, it's going to be cached. I don't want you to just try and like massage my system into a suitable state for NativeScript development. I just want you to diagnose what is wrong. Tell me, am I missing this compiler? Maybe I've got the wrong version of Android SDK. Tell me what's going on." And I couldn't get that to work. That was very frustrating. I think it was because the kind of bulk of the assumptions was that it was going to be individual developers working on their own laptops or their own desktop computers to build, to test, to distribute these applications. I think that's becoming less and less the case. I mean, at this point, that's not a way that we're willing to operate. TARAS: And we eventually figured out how to do all this stuff, right? CHARLES: Yeah, we have. JEFFREY: We have. TARAS: We have the entire process working but it took a lot longer than one would imagine. It took all the time that we had allocated to it which we thought was very generous amount of time but it took like almost a month to get everything set up. The great part of this is that we do have now everything working. And so, there's a repo where people could take a look if they want to get all stuff working on CI, but it took quite a bit of work in figuring out. CHARLES: Yeah. Actually, I think worth probably a Screencast to show some of those capabilities because it is really exciting. I mean, when you actually think about the pipeline in its entirety. But we never were able to get functional testing working. TARAS: And then the challenge here is that because we were essentially looking at NativeScript, going back to this question like, "What do we need to be able to have like hundreds of developers potentially running on this platform?" And so there's a lot of considerations and this tool is just one of them. I think the other one that is a big one is like what are the capabilities of the view layer because that's where most of developers were spending most of their time. We got stuck a little bit about that because I spent a lot of time working in the view layer. The thing that was really great and the thing that I really liked about it is the fact that you have a collection of components that you can use in Angular. You render it as component and then that component is going to look correctly on iOS and is going to look correctly on Android. From a single code base, it's building appropriate components for iOS and Android. What I think is really confusing in that case, though, is because the Android and iOS components don't have parity in a sense. They don't behave exactly the same. And there is also a kind of a reputation in the NativeScript documentation that Android tends to be slower, much slower than iOS. And so, when you start to run into performance problems and you start to run into those pretty fast because it is not really clear what is necessary to not optimize NativeScript, when you start to run into performance problems, it's not really clear like where is it coming from. Right now, the profiling that they have for the UI is very limited. They're kind of in the process of migrating over to chrome.debugger, but profiling in chrome.debugger is not implemented. You can do performance optimization using Android tooling but that's only going to tell you performance of the Java side, or the iOS side is not going to tell you the performance of the code that's running inside of JavaScript. It's not really clear what is causing the problem. If you don't know what's happening, you kind of write it off as like, "I think it's just Android being slow." In reality, when you actually start to dig deeper, you realize there's things about the Android implementation of the components that are different or the views that are different than iOS. And it's the differences that add up to weird performance problems. That's probably the thing that gave me the most hesitation because one of the things that made me think like if we want to be able to give this to a team of like 50 people, we need to have our own view layer because we cannot rely on components. An example of this would be, they have a list ticker on iOS, it doesn't omit change events when you scroll. If the list is moving, it change events and not omit it. But on Android, every time that a different item shows up on a screen, it changes the selection. And so now, you've got this view that's a meeting on Android as a meeting change events. I made an issue around this and the response was that while there's a workaround that you can have for this, but that's hard. Work around is not a solution. CHARLES: Right. When you have a leaky abstraction like that. TARAS: Part of the problem is because people use leak abstraction. And so, what's happened in Native -- we actually got on the call with NativeScript core team and they're excellent in really being very helpful, understanding what the problems are, and providing pass on making things better. But what's happened as a result of having this leaky abstraction is that people are relying on the leak. And so now, the leak is the API. And so, we can't change that. JEFFREY: Right. CHARLES: And the answer that you really need there is, "We can't change that without breaking stuff. Here's our migration path for deprecating this and introducing a new API." And that gets more into the process stuff and it seems like the process for making changes to the underlying API, I think, could use a little love in the sense that it's kind of opaque as to where the platform is going. There's not a concept of like an [RSC], there's no roadmap about what to expect. What is this API going to look like in the future? Is this stable? If I were writing a software and someone said, "Hey, there's this leaky abstraction," I think my reaction would be, "We've got to fix this." And we also have to acknowledge that there are users who may depend on this. And so, we have to be very deliberate about it. TARAS: The challenge with this too is that NativeScript kind of outgrew its hands because I think originally, it wasn't meant to be hosting Angular and hosting Vue. Vue didn't exist. Angular didn't exist when NativeScript started. So I think what's happened is that these views that were available, I wouldn't call them components because they don't act like components, but they're exposed in Angular like components but the API feel like Vue objects. So these Vue objects that you consume, that you render in Angular, for example, or in Vue.js, they are the same APIs that NativeScript had before Angular and Vue.js. CHARLES: Right. You know what? It feels like there's a MVC framework, like a Circa 2010, 2012 MVC framework that has now become the foundational layer for Vue frameworks that have had significant advances in the way we conceive of model in Vue and how data is generated and passed around and how views are rendered off of the data and how reactivity is changed. But there's still, the underlying platform has not evolved. And in fact, this was originally user-facing APIs and now these APIs have become foundational for other user-facing APIs but haven't had the iteration and evolution to make them robust. TARAS: And flexible enough. As a result, you have the situation where not only is it really super easy to deoptimize the views simply because the requirements of keeping performance expectations are not obvious. One of the things that I found is that the list which is, lists are like 50% of most applications. Before I go into the problem with list, the nice thing about lists in NativeScript is that because they're interacting directly with native APIs, you have really fast list when they're optimized. They're really easy to work with. But they easily get deoptimized by the fact that the expectation to keep the list fast, you have to use this API in NativeScript called array observable and observable. And this is not to be confused with like... CHARLES: [Inaudible] observables? TARAS: Yeah. CHARLES: It's not to be confused, but in fact, every conversation involves a lot of confusion. Because we were using observables, right? TARAS: And we were actually using observables. So, we're using observable [inaudible] and we're using this array observables and object observables. And so, it's necessary for NativeScript to, essentially what it expects for list to be fast, is it expects that it's going to receive an array observable which is an object that wraps an array because it needs to know when an order or length of data rate changes. So what happens when you pass an array observable, a NativeScript array observable into a list? It will listen for change events on that object. But if you want to change the value of each of the items, like if you want to change a property on the object and have your view remain optimized, the array observable has to have an observable object which allows NativeScript ListView to listen for changes, property changes on the object. You pass this array observable which contains observables that ListView listens for changes on to make sure that it knows how to correctly apply this change to the list. If you don't have this magic, like if you haven't figured out this recipe for ListView performance success, you're going to have a really hard time because it's really not clear at what point and how this thing got deoptimized, why has it just gotten slower. CHARLES: There's a lot of iteration that needs to happen there and it's not clear what the plan, what the priority, or even how you will even begin to go about this. Because I think that the internal working is that it seems basically to be controlled by one company. I don't recall seeing any contribution from anybody except for Progress which is Progress Incorporated is the company that's kind of the controlling interest, the original company that developed it. TARAS: The way this showed itself very practically is that to make changes too -- so they have a ListView which comes with NativeScript public and there's RadListView which is the component that has a lot of stuff on it. Like if you want to pull to refresh or if you want to do like laser loading a data or if you want to do a filtering, you want to do -- so most people use RadListView. But RadListView, you can install, so there's no limitation when you build to install it, and your node modules has the source code for that. But the source code, the original TypeScript code, untranspiled code is not publicly available. They have a process for doing this and it's very nice that everybody's very kind and very accommodating. You send an email, they'll give you access to this repo and then you'll have the ability to contribute. NativeScript core team is very helpful and they're open to contributions. There are changes that need to be done to the Angular implementation to make it faster without having to put the requirements of the observable thing, and so they can give you a path to make that stuff happen but it's not open source in the sense that it's not a traditional open source that we would kind of expect. So, there's all kinds of hoops that you need to jump through and the source code is very difficult to read because it's transpiled from TypeScript to JavaScript. CHARLES: And there was a certain level of opacity in terms of process. For example, I filed an issue which was actually a blocker. For us, it was actually causing our Android build not to work. I didn't hear anything about it. And then, all of a sudden like four days later, a fix came through referencing another repository on which this thing depended with. There was not a lot of context service. So it was obviously referencing a bunch of context that probably happened between two people in a face-to-face conversation. But I couldn't really tell what was going on, why it was an issue, because there was no comment. It was just a pull request that was referencing this issue. I never got a notification. I actually had to go and be like, "Hey, I really would like for this issue to be solved. I wonder if I..." I was actually going to post a, "Hey, is there any progress on this?" Or, "Is there any way that I can help? What can I do to get this looked at?" And I saw that there was another pull request that had referenced my issue. And it was merged and I looked down, but then there was no indication of when this would be available for public release, how I might be able to work around it. And so, the strange loop that didn't get connected was, "Hey, you've got a user who files an issue. You actually use this as the impetus to fix the issue and make a release." But then that whole process was completely invisible to me. TARAS: You know what? It sounds like you wanted for it to work [inaudible] but you got a pulling mechanism. CHARLES: Yeah, exactly. Well, I wanted someone to say like, "Hey, here's what's going on, and we're looking right into it." Or, "We're going to look into it in like two months," or, "We can't address this now. But here's a workaround for it." Or, "I don't have a workaround." That's just kind of the expectation that you have when you're playing with open source. In many ways, it does not feel like an open source project. TARAS: Let's just do a quick note about Saas. Jeffrey, what did you find about the styling of NativeScript views? JEFFREY: All the components that come kind of shipped as part of the NativeScript core set of components all have styles attached to them. They have CSS attached to them. And as part of the standard data script workflow, with your build toy, you have SaaS available which is very nice. But actually on a recent project, we're not using Saas at all. We're simply using post-CSS and we were able to kick out some CSS variables that turned out to be really nice for theming. So as kind of a future friendly experiment, we were trying to have a light theme and a dark theme since that is very recently now a core part of Android and very likely will be part of iOS this year, where there's kind of a light theme and a dark theme for everything. We were trying to do that. The simplest way to do that with standard web tools is with CSS variables. You can have the flexibility, you have the theming with those. It's so nice. You just, "Hey, my primary color is this color in one scenario and it's this color in another." And we just didn't really have the flexibility to do that with SaaS by itself. And so, that's kind of a limitation of the tooling right now that I hope in the future, we'll have some more sophisticated CSS tools. And really, NativeScript's move toward Webpack and having that as a primary part of the workflow really opens up that possibility that I hope somebody runs with in the near future. TARAS: Yes, let's bring it all back together. CHARLES: Can we pause for a moment? Because I actually do think it's important that we at least touch on the command line. I can give a little bit of a kind rant in here but I think that's actually something really important that we have to talk specifically about that. The other thing that I wanted to touch on very briefly as we kind of draw to the close is the command line tooling, in particular in NativeScript. I think that this is probably one of the weakest points of the platform. And again, I don't want to disparage anybody working on NativeScript. It's an extraordinarily complex problem. This is a command line tool that needs to manage launching simulators, installing things into simulators, pushing code to those simulators. It needs to handle hot updates to things that it's running on, devices and simulators. So, it needs to be building JavaScript assets either with Babel or with TypeScript. It needs to be building those SaaS assets that you were just talking about, image assets. But it needs to be doing all of this for two platforms, so it needs to be managing everything that I just described. It needs to be managing on iOS. Everything that I've just described needs to be managed on Android, as well. It needs to work for a single developer's desktop. It also needs to work with all of those components that I just described distributed out in the Cloud. So, we're talking about an extraordinarily complex piece of software. And I think that unfortunately, the NativeScript CLI does not inspire confidence because it can do all of those tasks. But Taras, you also mentioned often if you stop the process midway, it will leave a thousand things open and they're just spewing output to your console. The console output, unfortunately, means there's a big noise to signal ratio because it puts out all of the content for Webpack. Every little thing that it's doing with any of the devices, it's logging to the console. So, it doesn't give you a sense of control. So, what you really are looking for in terms of a command line is, "Hey, I've got this incredible sprawl of complexity and I want to feel like I'm on top of it." And unfortunately, by leaving these things open and having so much console output and having the console output not be formatted well, there's all kinds of colors. Every single tool that you're using whether it's Webpack or whether it's Karma or whether it's just console outputs that you are happing inside of your NativeScript application, the brand of those tools comes through. Webpack is a great example. Its console output feels very Webpack. So when you've got Webpack content randomly interleaved with your console content from your Mocha content, from Karma, all of these competing brands, it doesn't feel like a cohesive developer experience. And so, I really, really hope that -- so, to the point being where I felt like I could not live with that command line tool without rewriting it myself. If we want to use this platform long term, we'd have to either have an alternative command line tool or really, really, really help the NativeScript team completely and totally rewrite the command line experience. TARAS: I would love to work on fixing a lot of these parts about NativeScript if there was a way to actually do it in terms of like, if they wanted to pay us to help them kind of bring some of these things to a state that would match. For example, what's available in Ember or available in React CLI, I would love to do that. CHARLES: React Native, yeah. TARAS: Yeah, let's do that work. But who knows what's in store? A lot of awesome platform like the idea around NativeScript architecture is fascinating and it's really, really powerful and really wonderful people doing some, trying to tackle really challenging problems, but it's all glued together in a way that doesn't instill confidence. And it just makes everything feel wobbly, just makes it feel like you never know, is it a problem? Where's the problem from? What is causing this? CHARLES: Yeah. And if I fix this thing, is it going to break something else? TARAS: Yeah, we've seen it happen actually with one of the solutions that was introduced to a bug that you were referring to earlier. CHARLES: Yeah. So that was our three months experience working with NativeScript. TARAS: We are considering other things now, very seriously looking at Flutter as an alternative for the same client, same scenario. Flutter is looking pretty exciting. There's a lot of things that are really good there. So in three months, we'll do another report and talk about Flutter and what we found. So, that's it. CHARLES: And I will say I'm actually not like super excited about dart but I'm in dart spot. JEFFREY: That's a whole other conversation for yet another episode. CHARLES: I think that, to continue the conversation maybe next week, next time we have kind of an internal podcast, is I would like to really talk about platform evaluation because really you need three months, at least, to get a good idea of this. Is this going to work for the next five years? And most of the time, we give it a week or give it a two week. Or someone comes on who's really excited about this one particular technology and you go off on that tangent. I think there's an interesting meta discussion about how do you select technologies. And we don't have time for that now, obviously. But it's definitely something that I want to have in the future. TARAS: Sounds good. I think that will be a good conversation for sure. CHARLES: I guess that is kind of the executive summary on NativeScript from our perspective. With us being three months in, I think, like you said, there's a lot there. Thank you for listening. If you or someone you know has something to say about building user interfaces that simply must be heard, please get in touch with us. We can be found on Twitter at @TheFrontside or over just plain old email at contact@frontside.io. Thanks and see you next time.

Luke Melia, Aaron Chambers, and Mattia Gheda john Taras and Charles to discuss all things deployment! Luke Melia: Luke has been working with Ember since it was under early development as Sproutcore 2.0. Ember.js powers a SaaS company he co-founded, Yapp, and they funded their business for a couple of years doing Ember consulting under the Yapp Labs moniker. They're full-time on product now, and his engineering team at Yapp (currently 3 people) maintains around 6 Ember apps. Luke helps to maintain a bunch of popular addons, including ember-cli-deploy, ember-modal-dialog, ember-wormhole, ember-tether, and more. He started the Ember NYC meetup in 2012 and continues to co-organize it today. Aaron Chambers: Aaron Chambers: Aaron is the co-author of EmberCLI Deploy and is currently an Engineer at Phorest Salon Software, helping them move their desktop product to the web platform. He's been using Ember for 5 years and maintains a number of plugins in the EmberCLI Deploy ecosystem. Aaron loves trying to work out how we can ship JS apps faster, more reliably and with more confidence. Mattia Gheda: Mattia is a Software Engineer, Ember hacker, Ruby lover and Elixir aficionado. Currently he works as Director of Development for Precision Nutrition where Ember, Ruby and Elixir power several applications. He loves meetups, organizes Ember.js Toronto and co-organizes Elixir Toronto. Resource: Immutable Web Apps Please join us in these conversations! If you or someone you know would be a perfect guest, please get in touch with us at contact@frontside.io. Our goal is to get people thinking on the platform level which includes tooling, internalization, state management, routing, upgrade, and the data layer. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES: Hello and welcome to The Frontside Podcast, a place where we talk about user interfaces and everything that you need to know to build them right. My name is Charles Lowell, a developer here at the Frontside. With me also co-hosting today is Taras Mankovsky. Hey, Taras. TARAS: Hello, everyone. CHARLES: Today, we have three special guests that we're going to be talking to. We have Aaron Chambers, Luke Melia, and Mattia Gheda who originally met collaborating on fantastic open source library that we, at the Frontside, have used many, many times that saved us countless hours, saved our clients hundreds of thousands of dollars, if not more. ember-cli-deploy. We're gonna be talking not about that library in particular but around the operations that happen around UI. So, welcome you all. LUKE: Thanks, it's great to be here. CHARLES: Like I said, I actually am really excited to have you all on because when we talk about the platform that you develop your UI on, something that often gets short shrift in communities outside of the Ember community is how do I actually deliver that application into users' hands. Because obviously, we don't want it to be working just on our laptop. We want it to be delivered to our users and there are myriad ways that that can happen and it's only gotten more complex since the last time we talked which must have been like three or four years ago. I kind of just have to ask, I think that what you all were talking about then was cutting edge is still cutting edge now but there must have been some pretty incredible developments like in the last three or four years. What have been kind of the new insights that you all have? LUKE: I think that what we realized as we got started with ember-cli-deploy and a project kind of came together as a combination of a few different open source efforts, something that Aaron was working on, something that our collaborator Mike was working on. We decided to come together under one umbrella, joined forces. And what we realized pretty soon is that deployment needs vary a ton between companies. And so, we are coming from this background in Ember community where we had this attitude where nobody is a special snowflake. We all kind of have the same needs for 90% of what we do. And that's true. I really believe in a lot of that Ember [ethos]. But when it comes to deployment, you know what? A lot of companies are special snowflakes or it's at least is much more fragmented than kind of our needs around on the JavaScript side. And so, what we decided to do was to try to evolve ember-cli-deploy into a platform essentially, an ecosystem that could let people mix and match plug-ins to do in their organization without locking them into an opinion that might simply be a non-starter in their org. CHARLES: It's hard enough to have opinions just around the way that your JavaScript code is structured but when it comes to rolling out your app, it really does encompass the entire scope of your application. So, it has to take account of your server. It has to take account of your user base. It has to take account of all the different processes that might be running all over, distributed around the Internet. Maybe somewhere on AWS, maybe somewhere on Legacy servers but it has to consider that in its entirety. So, it's having opinions that span that scope is particularly difficult. LUKE: Yes. And so, you mentioned a bunch of technical details which are absolutely forcing factors for a lot of words in how they do their deployments but what we found in talking to people that there are also people in political aspects to deployment in many cases. Engineers kind of own the JavaScript code that's running within their app, more or less. But when it comes to pushing the app into the world and a lot of companies, that means they're interacting with sysadmins, ops folks, people who have very strong opinions about what is an allowable and supportable way to get those deployments done and to have that stuff exist in production. And so, we needed to come up with an architecture that was going to support all these kind of varied use cases. And so, we came up with this system of essentially a deployment pipeline and plugins that can work at various stages of that pipeline. And that ecosystem has now grown quite a bit. It's actually, I don't know Aaron if you and Mattia would agree but I think it's probably the best decision that we made in this project because that ecosystem has grown and evolved without us needing to do a ton of work in maintenance. And it's been really great. I think Mattia, you pulled some of the current numbers there. MATTIA: Yeah. I pulled some numbers just yesterday and we have currently 150 different plugins attached to themselves, to different parts of the pipeline. So some of them are about how to build the assets, some of them are about how to compress them, some of them are about shipping. And they allow people to ship it with different ways like we are seeing [inaudible] with just simply Amazon APIs or Azure APIs and some of them even are about just how to visualize data about your deployments or how to give feedback to the user about what was deployed and represent the information. And then this is kind of a bit more detail, probably specific to us but we also added this idea of plugin packs. So, in order to help people define their deployment story, we created this ideal of plugin packs. Plugin packs are simply group of plugins. So, plugins grouped together. As a user, if you want to implement what we call a deploy strategy, you can simply install a plugin pack and that will give you all the plugins that allow you to deploy in a specific way. And that's kind of like an optimization that we added just to make it easier for people to share deployment strategies, share ways of deploying applications. CHARLES: Right. It's almost like an application within the framework. MATTIA: Yeah, exactly. But to stay on the community side, I think that the interesting part about what Luke was saying which was a great success for us is that all we maintain as the core team for this project is the core infrastructure, so the pipeline and a thousand of plugins. Everything else is community-based. And often, even in my day-to-day work, I end up using plugins that I didn't write and that I don't even maintain. But because the underpinning of it were designed especially by Luke and I are flexible enough. It just like has been very, very stable and very, very reliable for many years. So, I will say definitely the idea of like in the spirit of what Ember is, I guess, creating a shared ecosystem where people can add what they want and extend what was provided has been the one single biggest win of this project. CHARLES: One of the things that I'm curious about is we've talked about how you're allowing for and kind of embracing the fragmentation that happens in people's kind of the topology of their infrastructure. What do you see is the common threads that really bind every single good deployment strategy together? MATTIA: My biggest thing here, and we actually have some shared notes about this, but my biggest thing about this is the idea that building and deploying an application for me is divided into three parts. There's building part where you have to decide how to compile your JavaScript application and how to produce some sort of artifact. There is the shipping part where it's about deciding where you're going to put the artifact. And then there is the serving part which is how you show it and deliver it to your users. I think that these three are the underpinnings of any deploy strategy. What we did with this project is just acknowledging that and give each one of these a place. And so, the entirety of what we do in what Luke defined as a pipeline is simply give you a way to customize how you build, customize how you ship, and then customize how you serve. So yeah, I think that that's kind of the root. And the question that everybody that wants to deploy a modern JavaScript application have to ask themselves is how do I want to build it, how do I want to ship it, and how will I serve it to my users. And these things are completely independent one from the order in the sense that you can have something build it, something ship it and something serve it, and that's what we end up doing in most of our deployments, I find. CHARLES: It's good to think about those things as soon as you possibly can and make sure that you have all three of those bases covered really before you start adding a whole ton of features. TARAS: Sprint 0, right? LUKE: In Agile, we call Sprint 0 the phase the thing you do right in the beginning. You've got a skeleton of an app and then you get the deployment infrastructure going, you have the test infrastructure going, so that there is no task within your actual feature development where you have to do those things. And I think that can be a valuable concept to embrace. I would just add to Mattia's three points that for deployments, to me, some very simple qualities of a good deployments are repeatability. You need to be able to reliably and consistently run your deployment process. Sounds simple but there's plenty of operations that have run up way too long on manual deployments. So, we don't want to see those rollback capabilities if you have a deployment that you realize was a mistake right after it gets into production. I'm sure none of us have ever experienced that. CHARLES: That never happens to me. LUKE: You want to have a method to roll that code back. That's something that can be remarkably complex to do. And so, having some guardrails and some support mechanisms to do that like ember-cli-deploy provides can be really useful. But whatever your approach is, I think that's a necessary quality. And then I think we start to step into kind of more advanced capabilities that a good deployment architecture can provide when we start to think about things like personalization, A/B testing, feature flags, these kinds of things. And that requires more sophistication, but you cannot build that on a deployment foundation that's not solid. AARON: I think for me, one of the things I've been really thinking about a lot lately, it's a bit of a mindset shift, I think, to get to where the things Mattia was talking about separating those different parts of deployment. And so, I really start to realize the traditional mindset around deployments like I build some stuff and I ship it to the server and then the users get it. But if we can actually stop and actually split our understanding of deployment into two separate phases. One is the building and the physical shipping of the files; and the other one's actually making them available to people. You open up this whole world of our features that you wouldn't normally have. So to be able to actually physically put stuff in production but not yet have it active, as in users don't see it yet but you can preview those versions in production against production databases. And then at some point after the fact, decide, "Okay, I'm now going to route all my users to this new thing," And to be able to do that really easily is massively, massively powerful. And so, to me, the thing I've been thinking about lately is it is a small mindset shift away from packaging everything up and pushing and overwriting what's currently there to being something, again like Luke said, immutable deployments where everything we build and ship sits next to all the other versions and we just decide which one we want to use to look at it any time which leads into then, I guess, A/B testing, feature flags and things. So I guess deployment really is not so much about the physical shipping, that's one part of it. To me, deployment now is shipping of stuff, as in physical deployment and then the releasing it or enabling it or activating it to users. CHARLES: Or routing it. Sounds like what you're describing is an extraordinarily lightweight process. AARON: It is, yeah. CHARLES: To actually route traffic to those files. AARON: It is. It's incredibly lightweight. That's the amazing thing about it. When you think about it, you're building a few JavaScript files and CSS files and images and putting them on a CDN, and then you just need a tiny web server that basically decides which version of the app you want to serve to people. There's not much to it at all, really. CHARLES: I mean that's absolutely fascinating, though the capability that you have when you have the ability to have these versions, the same versions or different versions of your application sitting along next to each other and being able to route traffic. But it also seems to me like it introduces a little bit of complexity around version matching because only certain versions are going to be compatible with certain versions of your API. You have different versions of your API talking to the -- so the simplicity of having kind of mutable deployments, so to speak, is that everything is in sync and you don't have to worry about those version mismatches. Is that a problem or this could just be me worrying about nothing? But that's kind of the thing that just immediately jumps out to me is like are there any strategies to manage that complexity? LUKE: To me, what you're describing, I kind of think of as a feature not a bug. And what I mean by that is that it is very simple to have a mental model of, "Oh, I have a version of my JavaScript code that works with this version of my API." And as long as I kind of deploy those changes together, I'm good to go. The reality is that that's impossible. The JavaScript apps that we write today, people are using anywhere from two seconds at a time to two days at a time. It's not uncommon these days to have some of these dashboard apps. People literally live-in for their job eight hours a day, nine hours a day, keep the browser tab open and come in the next morning and continue. And so, obviously there are some mechanisms we could use to force them to reload that kind of thing. But at some point in most apps, you're going to have a slightly older version of your JavaScript app talking to a slightly newer version of your API for either the span of a minute or perhaps longer depending on their strategies. So to me, the process of thinking about that and at least being aware of that as an engineer thinking about how your code is going to get from your laptop into the world, I think it's an important step that we not paper over that complexity and that we kind of embrace it and say, "Hey, this is part of life." And so, we need to think about just like we need to think about how your database migrations get into production. That's not something that you can paper over and just have a process that it's going to take care of for you. It requires thought. And I think that this, in the same token, how different versions of your JavaScript app are going to interact with your API requires thought. An exact parallel also had different versions of a native mobile app that go into the app store. How did those interact with different versions of your API? So, I think you're right. There's complexity there. There's ways that we can try to mitigate... CHARLES: Keep repeating ourselves if we think that that [inaudible] actually doesn't exist even in the simple case? MATTIA: Yeah. I think that that's to reiterate what Luke is saying. That's exactly the point. You can pretend it's not there but it is and you have no way to avoid it. Once you ship something to a browser, you have no control over it anymore. And so, you have to assume that somebody is going to be using it. LUKE: Aaron, I think you too, I don't know if you can share it. But you recently told us some stories about kind of what you encountered in your work about this and of how long people were using versions and stuff. AARON: Yeah. Something that we hadn't sort of put a lot of thought into. But the last place I worked at, we had quite a long lived app and we're using feature flags and we're using launch [inaudible] something and it gives you a list of flags and when they were last requested. And there were also flags that we removed from the code and it was just a matter of waiting until all the users had the most current version of the app and weren't requesting the flag anymore. But this one flag just kept getting requested for months and we just could not work out why. It really sort of opened my eyes up to this exact problem that these long lived apps set in the browser and if you have someone that just doesn't reload the browser or restart the machine or anything, your app can live a lot longer than maybe you actually realize it is. So we're shipping bug fixes, we're shipping new features, and we're all patting ourselves in the back. We fixed this bug but have we really? If your users haven't reloaded the app and gotten the latest version, then you haven't actually fixed the bug for some number of people. And it's really hard to tell them as you think about this and put things in place, really hard to tell what versions are out in the world, how many people are using this buggy version still. CHARLES: Yeah, that's an excellent point. I haven't even thought about that. I mean, what is the countermeasure? AARON: We hadn't made it until we came across [crosstalk]. CHARLES: It's nothing quite like getting smacked in the face of the problem to make you aware of it. AARON: That's right. CHARLES: So, what's the strategy to deal with that? AARON: I guess for me, my learnings from that would be from very early on thinking about how we're going to encourage people to reload, to start with, and maybe even have the ability to force a reload and what that means but then that has gotchas as well. You don't want to just reload something when a user is in the middle of writing a big essay or something like that. But definitely thinking about it from the start is one of the things you've got to think about from the start. But I guess something that I'd like to implement and I've kind of thought through but not really explored yet, but the ability to see what versions are out there in the world and there are things I've been thinking about in terms of this little server that serves different versions. Maybe we can start having that kind of tracking what versions are out there and who's using what and being able to see because it would be great to be out to see a live chart or a dashboard or something that sort of shows what versions are out there, which ones we need to be aware of that are still there and even what users are using and what versions they can maybe even move them on, if we need to. But there's definitely a bunch of things that aren't immediately obvious. And I don't know how many people actually think about this early on, but it's critical to actually think about it early on. MATTIA: Yeah. I was going to share what we do which is very similar to what Aaron said just maybe for the listeners to have some context. The first thing you can do is basically what Gmail does, which is every time a web app sends a request, an [inaudible], it will send the version of the app with the request and the backend can check. And the backend can check if you are sending a request from the same version that is the most recent deployed version. And if it's not, this sends back a header and the same way that Gmail does, it will display a pop up that is like, "Hey, we have a new version if you want reload." And on top of that [inaudible] is that we have a dead man's switch. So if we accidentally deploy a broken version, a part of this process, the frontend application tracks in the headers. And if a special header is sent, it force reloads, which is not nice for the user but it's better and sometimes is critical to do so. CHARLES: Right. I remember that was that case where Gmail released something. They were doing something with broken service workers and the app got completely and totally borked. I remember that my Twitter blew up, I don't know, about a year ago I think, and one of the problems I don't think they had was they did not have that capability. MATTIA: I mean, you learned this the hard way sadly. But I think these two things are definitely crucial. And the third one, [inaudible]. I thought, Luke, you had the ability that Aaron was talking about like tracking versions in the world. And I think that's more useful for stats so that you know how often your users update. And then you can make the design decisions based on that and based on how much you want to support in the past. LUKE: Yeah. We haven't implemented that but it reminds me whenever there's a new iOS version, we do a bunch of mobile work in the app and we're always looking at that adoption curve that's published. A few different analytic services publish it and say, "OK. How fast is iOS 12 adoption? How fast are people leaving behind the old versions?" And that helps to inform how much time you're spending doing bug fixes on old version versus just telling people, "Hey, this is fixed in the new OS. Go get it." But if you are able to see that for your own JavaScript apps, I think that would be pretty hot. CHARLES: Yeah. Crazy thought here but it almost makes me wonder if there's something to learn from the Erlang community because this is kind of a similar problem. They solved 20 years ago where you have these very, very long running processes. Some of them there's some telephone servers in Sweden. They've been running for over a decade without the process ever coming down. And yet they're even upgrading the version of Erlang that the VM is running. And they have the capability to even upgrade a function like a recursive function as it's running. And there's just a lot of -- I don't know what the specific lessons are but I wonder if that's an area for study because if there's any community that has locked in on hot upgrade, I feel like it's that one. LUKE: That's a terrific analogy. I bet we could learn a ton. Just hearing that kind of makes me think about how kind of coursed our mental model is about updates to our JavaScript apps. We talked to Aaron, we're talking about kind of this idea of a mutable apps and you have different versions side by side. But the idea of being able to kind of hot upgrade a version with running code in a browser, now that's an ambitious idea. That's something I'd say, "Wow! That kind of thing would be a game changer." CHARLES: Yeah. AARON: Makes me feel like we got a whole bunch of work to do. CHARLES: We welcome them. I'm always happy to give people plenty more work to do. No, but how they manage even being able to do migrations on the memory that's running. I don't know if it's something that's going to be achievable but it sounds kind of like that's the direction that we're heading. LUKE: It does, as these apps get more complex and they continue to live longer. The idea, the work arounds that Mattia mentioned about kind of showing a message and having a dead man's switch, these are all certainly useful. And today, I would say even like the best practice but they were not what you would want to do if you could magically design any system. If you're taking a magical approach, the app will just be upgraded seamlessly as a user was using it. And they would be none the wiser, the bugs would be fixed. End of story. There's no interruption to their workflow. At least for me personally, I don't really think about that as a possibility but I love the Erlang story and analogy and to say maybe that is a possibility, what would it take? I would obviously take a collaboration across your JavaScript framework, perhaps even JavaScript language features and browser runtime features as well as your backend and deployment mechanism. But I think it's a great avenue for some creative thinking. CHARLES: I'm curious because when we're talking about this, I'm imagining the perfect evergreen app but there's also feels like there's maybe even a tension that arises because one of the core principles of good UI is you don't yank the rug out from underneath the user. They need to, at some point and we've all been there when the application does something of its own agency, that feels bad. It feels like, "Nope, this is my workspace. I need to be in control of it." The only way that something should move from one place to the other without me being involved is if it's part of some repeatable process that I kicked off. But obviously, things like upgrading the color of a button or fixing a layout bug, those are things that I'm just going to want to have happen automatically. I'm not going to worry about it. But there is this kind of a gradation of features and at what point do you say, "You know what? Upgrading needs to be something that the user explicitly requires," versus, "This is something that we're just going to push. We're going to make that decision for them." LUKE: Yeah, it's a great question. One of the things that I'm curious what you all think is when you think about the mental model that our users have of working in a browser app, do you think that there is a mental model of, "Oh, when I refresh, I might get a new version." Do people even think about that? Or are they just like your example about a button color changing as kind of a minor thing. I don't even know if I could endure stack. We've all been I think in situations where you do a minor redesign and all of a sudden, all hell breaks loose and users are in revolt. Take the slack icon. So, I think it's a fascinating question. CHARLES: I don't know. What's the answer? Do you always ask for an upgrade just observing? I don't have any data other than observing people around me who use web applications who don't understand how they actually work under the covers. I don't think it's the expectation that this code, this application is living and changing underneath their feet. I think the general perception is that the analogy to the desktop application where you've got the bundled binary and that's the one you're running is that's the perception. AARON: I'd say the difference there is that, and with all these new ways of deploying, we're shipping small things faster in multiple, multiple times a day or even an hour. So it's not the sort of thing you really want time to use. There has been an update, need to upgrade as well. And that's the difference between the desktop mentality. And if that's the mentality they have, it sits quite a bit of a shift, I guess. MATTIA: It makes me think that one of the tools that the users -- if you take a look at the general public, there's probably one tool that everybody can relate to which is Facebook. So, I think if there is a way to say what do people generally expect. There is a business user which I think we are often most familiar with but the general public, probably what they're most familiar with is what happens in Facebook. And I don't use Facebook almost. I haven't used it for a couple of years but I wonder how much of what people experience in Facebook actually impacts the expectations around how applications should behave. LUKE: I think that's a really good question. I do think your underlying point of you have to know your own users I think is an important one also. Obviously, some folks are going to be more technical than others or some audiences will be more technical than others. But I would even question, Charles, your suggestion that people think of it kind of as like a binary that it stays the same until you refresh. I think people have an idea that web apps improve over time or sometimes they get bugs but hopefully that they improve and change over time, and that there is a tradeoff there that means sometimes there's something new to learn but at the same time, you get new features. But I don't know that people necessarily associate that with and it happens when I hit reload or it only happens when I open a new browser, like I don't know that it's that clear for people in their head. CHARLES: Right. I can see that. But the question is if the evolution is too stark, I think people tend to get annoyed. If they're in the middle of a workflow or in the middle of a use case and something changes, then it gives it a feeling of instability and non-determinism which I think can be unsettling. LUKE: Definitely. We all value, as engineers, we value getting into that flow state so much of like, "Oh man, I'm being productive. I don't have any distractions." And you kind of owe that to your users also to be able to let them get into that state with your app and not be throwing up, "Hey, there's new stuff. Reload." "I'm in the middle of something. Sorry." CHARLES: Yeah. I definitely do the same thing. Sometimes, I let iOS be bugging me to upgrade for a month until I finally start to feel guilty about security and actually do the upgrade. LUKE: Right. CHARLES: Although once they started doing it at night, it actually made it a lot better. LUKE: That's an interesting idea, too. I think there's a natural tension between the lower integration risk that we have as the engineering teams of shipping very frequently. Aaron mentioned shipping a dozen times a day. We certainly have been there and done that as well. I would say on average, we ship a few times a day. But the reason that we do that is because we know the faster we get code into production, the faster we can trust it. So it passes all your tests, it passes your [inaudible], but you don't really know if you're being honest. You don't really know until there's thousands of people using it in production. And yet, this conversation makes me think about there is a tension between how frequently you do that versus your users' kind of comfort level and expectations. CHARLES: And maybe there is a thing where you can kind of analyze on a per user basis how often they're active in the application and try to push updates on times that are customized to them. LUKE: Like when a user has been idle for 30 minutes or something like that. CHARLES: Yep. Or even like track trends over months and see when they're most likely to be idle and schedule it for them. LUKE: Good point. CHARLES: Something like that. TARAS: I have an idea. We should introduce screen savers into web apps. And so when the user stops using the app, just turn on screen saver and do the upgrade. LUKE: I can see the VC patch. It's after dark but for the web. CHARLES: Enter install flying toaster. AARON: It does that to open up the idea as well of that automated checking that things are okay well after the fact because it's all right to sit there maybe activate something and sit there even for an hour and make sure there's no bug request coming in. But if no one's actually received your app, then of course it's not going to come in. And it's very easy to kind of move onto the next thing and forget about that. I guess it's not something that I've ever put a lot of time in and I haven't worked anywhere that's had really great automated checking to see is everything still okay. And I guess it's an interesting thing to start thinking about as well an important thing. CHARLES: Like actually bundling in diagnostics in with your application to get really fine grained information about kind of status and availability inside the actual app. AARON: I'm not exactly sure, really. I guess I maybe wasn't thinking about inside the app but I don't know what it looks like exactly. But there is that element of shipping fast and getting stuff out there. But are we really making sure it all works later on when everyone's actually using it. LUKE: Yeah. This by the way, I just wanted to say when we were talking earlier what are the essential qualities around deploying an app. And this reminds me that one thing that we didn't mention but is very simple is your app should have a version. And it should be unique and traceable back to what was the GitHub, git commit that was the origin of that code. It's just a very simple idea but if you're going to be analyzing errors in production when you have multiple different versions of your JavaScript app running, you're going to need to know what version caused this error and then how do I trace it back and make sure that the code that I'm trying to debug is actually the code that was running when this error happened. CHARLES: Do you only use just [inaudible] or do you assign like a build number or using SemVer? What's a good strategy? LUKE: In our case, we use git tags. And so, our CI deployment process for our Ember apps basically looks like this is we work on a PR, we'll merge it to master. If it builds, the master gets deployed into our QA environment automatically using ember-cli-deploy from our CI server. And then once we're happy with how things are on QA, we do git tag or actually I use an ember addon called ember release that does that tagging for me and I'll tag it either in patch minor or major, roughly [inaudible] although it doesn't matter that much in the case of apps. When there is a new tag that builds green on CI, that gets deployed automatically into production by ember-cli-deploy. And so, that's kind of a basic flow. That tagging, just to be clear, the SemVer tag is just going to be number.number.number. You can get more sophisticated than that and I think both Aaron and Mattia have a system where even in the PR stage, there's automatic deployments happening. So maybe one of you want to mention that. AARON: We're slightly different. Every time we push the pull request, that gets deployed to production. We're able to preview up pull requests in production before we even merge into master which we find super useful to send out links to stakeholders and maybe people that have raised bugs just to get them to verify things are fixed. And then at the point that it's all Google merged, the pull request to master which will automatically do another deploy which is the thing we'll ultimately activate, we activate it manually after the fact. We just do a little bit of sanity checking but we could automatically activate that on merge to master as well. But yeah, the being able to preview a pull request in production is super powerful for us. CHARLES: That is definitely a nice capability. It's hard. It's one of those certain workflows or patterns or tools that you remember life before them and then after them and it's very hard to go back to life before. I would definitely say kind of the whole concept of preview applications is one of those. AARON: Absolutely. It's a daunting concept if you're not there, previewing something that's essentially a work in progress and production. And there are some things you want to be careful with, obviously. But for the most part, it's a super valuable thing. As you say, it's a world where once you're there, it's very hard to step back and not be there again. CHARLES: So I had a question about, we talked about I think it was 162 plugins around the ember-cli-deploy community. What for you all has been the most surprising and delightful plugin to arrive that you never imagined? MATTIA: That is a good one. I'm pulling up the list. What I can tell you, for me, it's not about a specific plugin. The surprising part was the sheer amount of different strategies that people use for the shipping part. At least, I found that the build part is similar for most people, like most people want to do the things that you're supposed to do. So, you want to build your application and then you want a minify it in some way. And there's a bunch of options there from gzip to more recent technologies. But the way people deliver it to servers and the difference in the solutions, that I think for me has been the biggest thing, where people that ship [inaudible] are people that ship directly to Fastly, people that use FTP files, people that use old FTP, people that use our sync, people that do it over SSH. We have people that ship stuff directly to a database because some databases actually have great support for large files. So we even use it as a storage. We have people that do it in MySequel, people that do it in [inaudible]. CHARLES: It's actually storing the build artifacts inside of a database? MATTIA: Yes, I've seen them in that. It's kind of interesting like the solutions that people ended up using. And so for me, I think that that's been the most fascinating part. Because as we were saying at the beginning, I'm just seeing now, we even have one for ZooKeeper. I don't have an idea what this does but it's probably related to some sort of registration around the seven-day index. That, to me, I think has been the biggest surprise. Everybody ends up working in a different environment. And so, that flexibility that users need has been by far the most surprising one. AARON: I think that's also been one of the challenging things, one of the enlightening things for me. I think in the Ember ecosystem, addons and even just Ember itself, it's all about convention of configuration and doing a lot of the stuff that you do for you. I think people expect them to see a lot of point to do the same thing. But the key thing here is it just really automates all the things you would do manually and you need to understand exactly what you want your deployment strategy to be before use them to see a lot of [inaudible] could do for you. You need to decide do I want to install my assets on a CDN and do I want to install my index in Redis or in console or in S3 bucket. You need to know all these things and have decided on all these things and then ember-cli-deploy will make that really easy for you. And this is one of the educational things, I think we still haven't even nailed because there are always people that want to know why this doesn't work. But deployments are complex thing and as what you were saying Mattia, there are so many different variables and variations on doing this that there's no sensible configuration ember-cli-deploy could really provide out of the box, I guess. And so, that's why we ended up with a pipeline that gives you the tools to be flexible enough to support your strategy. LUKE: I think the closest that we come to the convention is that if any app is using ember-cli-deploy, you can run ember deployment targets or ember deploy prod and ember deploy QA and you can expect that that's going to work. What you don't know is how has it happened to be configured in this project. Charles, your question about kind of the most surprising thing that's come out of the ecosystem. For me, I would say -- Mattia mentioned plugin packs earlier which are groups of plugins that kind work together well. And so, we've seen some plugin packs like you might expect, like an AWS pack for deploying to AWS. But the more interesting ones to me that we've seen a lot of, companies open source their plugin packs. So what you naturally fall into as a company that's adopting ember-cli-deploy that has multiple ember apps is that you are going to develop your own plugin pack for internal use because generally speaking, companies follow the same deployment pattern for each of their apps. There's usually not any reason to vary that. So then the new thing that happen on top of that is people said, "Why don't I make this open source so other people can kind of see how we do it?" And that's been a really delightful part of the process to kind of get a peek into how other organizations are orchestrating their deployments. And if people are curious about kind of looking at that themselves, you can go on NPM and look for keyword ember-cli-deploy-plugin-pack and pull up all of those. And you can kind of poke around and see what different companies have open source there. CHARLES: I actually love all three of those answers because it really is for me when you have a constellation of people around a particular problem, it's the surprising solutions that emerge that are some of the most exciting that would have lain hidden otherwise. It would have been kind of buried beneath the source of company A or company B or company C but actually having it all out in the open so that you can inspect it and say, "Wow, where has this solution been all my life?" Something that you have never imagined yourself. LUKE: It's so funny that you mentioned that because that actually is the origin story way back, I'm talking like 2013 probably when we were very early Ember adopters and we were trying to figure out how do we deploy this thing. We're deploying it with our Rails app, like literally deploying the Ruby code and the JavaScript code together which took forever which is a disaster. And I heard through the grapevine, just exactly what you're saying Charles, where the good ideas are kind of hidden inside of a company. I heard through the grapevine that Square had this approach that they were using where they would deploy their JavaScript assets and then deploy their index HTML file, the contents of that file, into a database, it's Redis in their case, and serve then it out of there. And it empowered all of these interesting situations of like having multiple versions, being able to preview the release, et cetera. And so we then set out to copy that idea because there was nothing open source. So we had to create it ourselves which we did in Ruby which we made it inaccessible to many JavaScript shops in the first place. Then the evolution of that kind of over time and of Mattia and Aaron and Mike and the rest of the community kind of talking together has now moved this into the open source sphere where these ideas are more accessible and we've created an ecosystem encouraging these ideas to stay out in the open. It's so true that there's just gems of ideas that have been created by really brilliant engineers inside of companies that could be benefiting so many people, they just haven't seen the light of day yet. CHARLES: Yeah, that leads me to my next question. I would say most of the ideas that we've been talking about today really, except for the build part, how Ember specific are they? Obviously, the ember-cli is a great resource and has a lot of great opinions for actually building the JavaScript assets themselves. But the second two phases of the pipeline really can vary freely, if I understand correctly. And so, have you all ever thought about trying to maybe kind of abstract these processes and these plugins so that these same ideas don't remain not just inside of a company but inside a community that spans a set of companies so that it's available for a wider audience? How integrated is it with Ember and what kind of effort would that be? LUKE: That's a great question. Aaron or Mattia, one of you guys wanna talk a little bit about the history here? MATTIA: Yeah, sure. We've been thinking about this as well. In the past, a guy on the ember-cli-deploy team, Pepin, has actually started this effort and it kind of prototyped this very idea of separating the ember-cli-deploy part from Ember CLI itself and make it a bit more generic. And he started a project called Deploy JS which I can give you a link for the show notes later. I don't think that the project is currently maintained but definitely the start of the effort is there. And the funny thing is that it was surprisingly easy. I think that we didn't get there mostly because we just all use Ember at work. As you know, open source is mostly motivated by the needs that an individual or a group of people have. But if any of the listeners were very interested in this, I think they should definitely get in touch and we will be happy to talk to them and see what can be done here. AARON: And also if you look, there's actually a plugin called ember-cli-deploy-create-react-app and there's also ember-cli-build-view. So it can and is being used to deploy non-Ember apps which I think is super interesting because the only real Ember part of it is just using the CLI to discover the addons and plugins. And from then on, it's really out of the hands of Ember. But it sort of leads into a little bit, Luke mentioned this concept of immutable web apps. And I've been thinking a lot about this lately because a deployment strategy that ember-cli-deploy use as an example a lot and it's kind of become [inaudible] ember-cli-deploy in ways, the lightning approach which is this whole idea of splitting or putting your assets in CDN and your index HTML separately maybe in Redis and serving that. I've been trying to work out how I can talk about this to the wider JavaScript community in a non-Ember way and knowing full well that the concept of lightning deployment means nothing to anyone outside of Ember. Just by chance, I was just talking to some people and this terminology of immutable deployments kind of rose. I started searching around and I come across a website called ImmutableWebApps.org which was just scarily the same as what we've been talking about for the last three or four years with ember-cli-deploy. And a way to boil down at a framework-agnostic level, what are the key points that you need to consider when building a JavaScript web app to make it immutable. And it was just really amazing seeing it. This website was put up 3 weeks before I did my Google search coincidentally. And it's basically word for word what we have been talking about the last three or four years, So, someone else in the other side of the world's been coming up with the same ideas in their company like you were talking about earlier and we've reached out to him. I guess that, to me, is sort of the way forward that I want to sort of pursue to try and get these ideas out in a framework-agnostic way to the rest of community and say, "Hey, we thought about deployment in this way. Have you thought about building your app in this way to give you these sorts of capabilities?" CHARLES: I think the wider community could definitely benefit from that because most of the blog posts and talks I've seen that concern themselves with deployment of single page applications, it's still much more of the tutorial phase. Like, "This is how I achieve getting this deployment strategy." Not, "This is how I repeatedly encode it as a program," and leverage it that way. And so, definitely getting that message out to a wider audience, I think it's a -- what's the word? It's an underserved market. LUKE: Yeah. I really like this idea also. I think about this ImmutableWebApps.org, if you look at it. It's sort of a manifesto with conceptual description of what are the qualities that your app has to have to qualify as an immutable web app which I think is kind of a funny idea but one that people can start to get their heads around and compare that description to their own apps and say how do I hit this or fall short. And it reminds me a lot of kind of the idea of Twelve-Factor App which is an idea that I think came out of Heroku originally. And it's an idea of a backend app that is portable to be able to easily move across different hosts and easily be scalable to different instances of [inaudible] if your app obeys all of these things then it's going to do well under those circumstances, that will satisfy those needs. So, I think it's a great way of thinking and probably maybe even a better entree into the conversation with the wider community than a library, this is certainly a library called ember-cli-deploy. CHARLES: This is a fantastic discussion. It's definitely reminded me of some of the best practices that I haven't thought about in a long time and definitely opened my eyes to some new ones and some new developments. So often, we can be focused on how our apps work internally, like how the JavaScript code works that we can just kind of -- what's the saying -- lose sight of the forest through the trees or I can't remember. It's like too busy looking down the end of your nose to see past your face. I've probably mangled both of those adages, but maybe 60% of two mangled adages is at least equal to one. This is something that we need to be thinking about more, that everybody needs to be thinking about more. This is actually a very exciting, very useful problem space and I'm just really grateful that you guys came on to talk to us about it. So, thank you, Mattia. Thank you, Luke. Thank you, Aaron. MATTIA: Thank you so much. It was a great time. AARON: It was a pleasure. Thanks for having us. LUKE: Thanks so much. CHARLES: Thank you for listening. If you or someone you know has something to say about building user interfaces that simply must be heard, please get in touch with us. We can be found on Twitter at @TheFrontside or over just plain old email at contact@frontside.io. Thanks and see you next time.

Joe joins the panelists to talk about pull request etiquette. Joe Leblanc: Joe first learned to code on a Zenith computer his dad brought home from work. It had this built in blue LCD monitor and ran on 5 1/4" floppy disks. He used spreadsheets for work and Joe was interested. They spent about an hour going over macros together and he took off from there. Long after the Zenith died, the open-source content management system Joomla! landed in the center of his attention. Joe found himself writing a book about Joomla programming, authoring video tutorials about Joomla for lynda.com, giving Joomla talks, and helping organize Joomla conferences. Since his time in the Joomla community, he's picked up Node, Rails, React, and other frameworks. He's currently coding at True Link Financial and working on a few hobby-projects as well. Please join us in these conversations! If you or someone you know would be a perfect guest, please get in touch with us at contact@frontside.io. Our goal is to get people thinking on the platform level which includes tooling, internalization, state management, routing, upgrade, and the data layer. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES: Hello and welcome to The Frontside Podcast, the place where we talk about user interfaces and everything that you need to know to build them right. My name is Charles Lowell, a developer here at The Frontside. And with me also is Taras. Hello, Taras. TARAS: Hello, hello. CHARLES: Today, we're going to be continuing our conversation about platforms, as always, but in particular the pillar of your platform that has to do with how you collaborate on code. It's an important one. And so, we're spending some time on it. And with us to talk about this today is Joe LeBlanc who is a senior software engineer at True Link Financial in our very own beloved Austin, Texas. Hey, Joe. JOE: Hi. CHARLES: Thanks for coming on the show. We're going to be talking about collaboration and I was thinking we could kick off the discussion talking about pull requests because that's typically one of the ways that we collaborate on code. That's really where the rubber tends to hit the road. You have particular interest in the dynamics of a pull request. What experience kind of led you to that interest? JOE: My background has been doing a lot of work as a freelancer. And when you work as a freelancer or do agency work, a lot of times you are really the only software developer that is around or you're working with maybe one or two other people. And I didn't get a lot of opportunity for pull request reviews. Mine was in that space. And then when I moved to a full time job at a place where I was one among maybe half a dozen or a dozen engineers, that's when I really began to get interested in how I could be better at giving pull request reviews and also submitting pull requests that people want to review. CHARLES: What made you notice the need for this? JOE: What would happen is someone would submit a pull request and there would suddenly be just dozens and dozens of comments coming in that were just kind of difficult to keep track of and often were maybe talking about things that didn't necessarily need to be reviewed as a part of that pull request or addressed, maybe things that could be caught by a linter. CHARLES: Right. JOE: And other tools that are a little bit easier to receive feedback from. Like it's easier to have a tool tell you your spacing is off than have me tell that to you. CHARLES: Right. And really that seems like the spacing is off, that's kind of like if you need to deliver that feedback, that's kind of like not what you want to lead with. If you don't have linting in place like after all other issues are sorted out. JOE: Yeah. CHARLES: But it sounds like what you're describing is people who have kind of swarmed over a pull request each with their own kind of pet peeve issue. JOE: Yeah. And then you're just left with this long list of comments to go back and address and you're pushing up more and more commits. And by the end of it, you could have more than 100 comments on this PR. And you thought that you were going to get this done in a day or two, and then suddenly it's the end of the sprint and it's like, "Oh fine, then I get to merge this." CHARLES: And typically, it's actually, in my opinion, an anti-pattern when you have like 10 mergers that happen on the second last day of the sprint or the last day of the sprint. There's always issues with that, right? Ideally, you are merging code throughout the course of the sprint. It kind of like defeats the purpose almost. I guess you're doing your integration in shorter periods but even so, tons of stuff is bound to break when everybody's pushing and everyone's rushing. JOE: Yup. TARAS: So, what would happen in that situation, in your experience, when you have this pull request that a lot of people are commenting on and some of the comments could be addressed by linters. Would you guys go back and actually implement linting? Did that happen? Would you put linting in place so that you'd have consistent formatting on the projects to reduce that kind of feedback? What would be the resolution or a way to improve on a process so you could actually get better feedback? JOE: Yes, we did install a linter and that's something that you can either run locally or you can also run in your continuous integration environment. And it's really good to run it locally first because then you can just catch it before you even submit the PR. And that was something that definitely helped cut down on these sorts of comments and even debates over style. You just have this one thing that is maintaining that style or rather telling you when you're wrong for you, and then you don't have to have all these comments coming in as you submit your PR. And another thing that we would do is we would use, even beyond just things like whitespace and trailing newlines and those sorts of issues, sometimes you would have some of these issues that would come in that wouldn't necessarily be a trailing newline or whitespace issue or something like that but it would be purely someone's sense of style. And in those situations, we came up with a bit of a standard where if you wanted to make a comment that was strictly style that wasn't something that you necessarily wanted to block the pull request over, we would use emojis that had specific [inaudible] thing. So in our case, we would use either a beer emoji or the cocktail emoji to kind of say, "Here, take this with a drink." CHARLES: [Laughs] JOE: This is not something that's super serious. It's a suggestion, "Here, let's discuss this over beers." [Laughter] TARAS: It's a really nice approach to friendlify the actual pull request because people can get really -- I think another way people would say this is like when you say that it's not 'I believe it whole strongly'. How does that go, Charles? CHARLES: It's strong opinions, weakly held. JOE: Yes. CHARLES: Right. You're kind of making an assertion about the way things ought to be or often missing from that is how important it is to you. You've made this thing like it should be like this. That's a very black and white statement, very firmly cut between right and wrong. But how important it is to you if it goes the other way is often missing from the conversation. TARAS: So Joe, what would happen once you made this change? Did you see a shift in the kind of feedback you were getting? What did it look like after this? JOE: After we started implementing the ideas of putting on emojis to signify things that were not super serious, it became a lot easier to just picture all those comments and define the things that really needed to address. And it was a lot faster. I was just able to address these very specific problems and do that first. And then if I had time later, come back and address those style issues. CHARLES: Right. Was the kind of the good feedback there the whole time but it was just obscured by the noise of these kind of exterior issues or side issues? Or did you find that because people's thoughts were more given over to the heart of the matter, that you actually got more comments directly relating to kind of the meat of the implementation? JOE: I think it was really more that the good comments really were buried in there. A lot of times when you see critical comments that seem to be petty, that can really trigger your emotions. And so, I feel like a lot of the times the emotional state that we would get into would prevent us from seeing the good comments that people were leaving, and we would get a little too angry about things that really weren't that big of a deal. CHARLES: Would the tension kind of noticeably rise? JOE: Yeah. I actually remember several instances at my job where -- this is when I was working in office and in the same room as all my co-workers. And one of my co-workers would know that I was reading his review by the number of sighs that were coming out of me. [Laughter] JOE: Yes, I definitely had this reaction that people could tell. Implementing things like these emojis definitely helped. They didn't always fix everything, though. One thing that would happen too is even after filtering out kind of the noise comments and getting into the meat of the matter, we would still wind up in situations where I would want to use one design pattern and another engineer would come along and say, "No, you should do something different," and we would have these arguments. CHARLES: Right. And those are harder to resolve too because those are strong opinions strongly held. JOE: Yes. CHARLES: But it's still a step forward, right? You've eliminated the passionate arguments about the strong opinions weakly held. And so you're able to now grapple with 'how do you resolve these arguments' of these stronger opinions that are more strongly held. JOE: Yeah. Part of the way that we handled this was we came up with a way of being able to have a debate about something on a pull request, yet also keep in mind that we're working under deadlines and that ultimately, it might not be that big of a deal. TARAS: I don't know if you experienced this but there's this kind of a feeling where you know you have a deadline that you want to reach and this feedback is kind of not really helpful to that end goal. But at the same time, there feels like a trade off for you, like trading off quality by accepting something that people don't agree being fully ready. JOE: Yeah. TARAS: But then there is, I guess the tests seem to be like you have some tests and the tests are passing. So, thumbs up. [Laughs] CHARLES: Yeah. Well, here's the thing. This thought just occurred to me when I heard that is when we are reviewing code, probably the most important code to review is actually not the implementation but it's the tests. Because why do people get so care mad about the code being right? It's because they know how expensive it is to get it wrong. And we all have our different opinions of what's right and wrong and what's going to cost us more. But at the end of the day, we're all trying to save us, save ourselves and our team, pain in the future. The tool that we have to do that is the code review. We're trying to make sure the code is "good". But usually what ends up happening, and I know I'm certainly guilty of this, is I'm focusing on the implementation and I look in and say, "Oh yes, there are tests." I don't really look at the test and say, "Is this a good test?" Because a good test is going to lower that cost that we're so afraid of in the future, and that drives us to want to make sure the code is as close to what we conceive of as perfect as it's likely to get and still hit our deadline. It sounds to me like maybe what we really ought to be doing is reviewing the quality of the test because if you have an excellent test, then the shape of the code almost is unimportant or changing the shape of the code, more importantly, is very cheap. So if you do find that the implementation is suboptimal, the cost of rejiggering it into a better configuration is going to be very low. JOE: I've discovered so many times where you are running a test that was written previously either by somebody else or by yourself, and you realize that the test is testing the wrong thing entirely. CHARLES: Yeah, coverage is spotty. It covers 10% of your cases. JOE: It can also might have a stub or a mock in there somewhere that is hiding something that you weren't counting on. Or it could just be you pull up this screen and test then it saves but you're not really testing what it's saving. CHARLES: Right. Can I actually proffer a suggestion? At least I'm going to try and hold myself to going forward, is that when I review a pull request or some proposed change to a code base, I'm going to review the test first. JOE: Ooh, that's a great idea. CHARLES: I'm going to try and start with the test and avert my eyes from the implementation, no matter how curious I am how this person accomplished the solution. I'm going to hide from the solution and focus on the verification. And if I have faith, first and foremost, in the verification, then my faith in the implementation is secondary. TARAS: You know, Charles, I really like this. I think it'd be really interesting to try this out and see what kind of impact it creates. It makes me think that there is actually something really useful in here in terms of providing feedback because the challenge is that when you're giving feedback to someone on a pull request, ideally that feedback is going to be useful and it's going to give the person something to think about in regards to the work that they did. And I think a good way of pushing to work back onto the person in a way that allows them space to internalize what they need to do is identifying cases that might be missing because a lot of times, we test happy paths. We don't test the things that we didn't think about. And that's where the devil is in details. It's in the things that we don't test. Those are the kind of problems that we're trying to prevent with having good code. But really the best way to kind of flush those things out is to make sure we have the right test coverage for it. So yeah, I think if you add to that just when you're looking at a pull request is to go, is a test coverage missing the following cases and actually surfacing not. I'm actually thinking like a danger task. A danger is a tool for adding information to pull requests so that it's kind of like an automated mechanism to comment on pull requests. And so I'm thinking like having something that does what [JAS] does. [JAS] has this thing where they will check based on the last git commit. It will figure out what are the tests that have been added since the last commit and then it will actually show you. So when you run tests, it only runs the tests that you kind of impacted which is something that could be used to surface tests that were written in this commit. I mean, we also have that information in the actual commit itself but being able to see 'these are the tests that were written or added' and then you could use that and figure out what else is missing from this. This could be like a way to kind of add onto this process, something a little bit more automated so you could actually highlight this information very easily in the commit itself. CHARLES: It's funny, my mind was wandering off towards GitHub. When do you use danger and when do you use GitHub actions? GitHub actions have been kind of like brewing and fermenting in my mind. TARAS: One nice thing is that I mean, danger is a little awkward in that it creates one single commit at a topic. It creates a comment first time you commit and then it keeps pushing information into a comment which shows up at the top of your comment thread. CHARLES: Right. TARAS: But that's not how you read comments. You read like top to bottom. You don't read top to bottom to top. And so, I think the nice thing about the actions is that because it's using checks like GitHub checks that actually is part of a different area, it's part of the validation area as opposed to part of the actual comment conversation. This seems like a more appropriate place to put their information rather than the first comment. CHARLES: Yeah. So, do we decide on kind of what the ultimate resolution is for when you have these high order conflicts? JOE: Yeah. So that's one thing that we came up with that I'm really proud of. And so what we do and at least at that job that I was at, what we did in those situations was we said, "OK, if you've gone back and forth on this two or three times and there's still not an agreement as to what should be done or there is no compromise, what you should do is let the author of the pull request go ahead and merge that code," because you want to merge that code, get it out to production, make sure it's serving our users and our clients. And then what you want to do is take that conflict and record it somewhere to specify this interpersonal conflict not a code conflict or a merge conflict or anything like that. So you take this interpersonal conflict, the topic that was being discussed and you put that -- we were just putting it in a Google doc and leaving it there. And then every couple of weeks or maybe every couple of sprints, we would go through that Google doc and just talk about topics that had come up. And then really more often than not, what we would find is that we didn't care about the topic anymore. CHARLES: [Laughs] It's amazing how time has a way of cooling passion over things that really don't matter. JOE: Yeah. And for the things that did matter, we usually have like a really good discussion. Sometimes, we even came up with something different entirely based on just having more people in the conversation and thinking about this problem. TARAS: I like this because there's a bit of process around it. It's kind of like a retrospective on pull request passions. JOE: Yes. TARAS: It sounds like a healthy thing to do for a team, especially. And I think just allocating some breathing room to go through these kind of things could be really important cumulatively over time, especially. CHARLES: Yeah, definitely. It sounds almost like the pull request is then ongoing. You have this collaboration that happens kind of at the front of the change but then is rippling outwards and onwards and hopefully then has an impact on future changes, like if you're disagreeing. So, would you qualify that the types of issues that end up living in this Google document as architectural issues or just, 'hey this is the way we need to talk to each other and this was off and we need to fix this' or is it both? JOE: It was mainly more architectural decisions that was coming up in this, sometimes like code style issues as well. Not so much the interpersonal issues, like the interpersonal issues would come during retros. CHARLES: OK, because it sounds to me like it's not. Then you have the added benefit that your architecture does get to improve because clearly if there's some disagreement about this, then there's some sort of tension there. There's someone perceiving that some problem is not being resolved by a particular implementation. And so it's good to just at least surface this issue again and again. What was your experience with kind of revisiting the architectural issues? Was it mostly 'well, this wasn't really an issue' or is it 'wow, I'm really glad we took note of this because now we have these three ways of thinking about things' and it turns out that given three or four months more experience, this is something that we should be doing. JOE: Yeah, it is definitely a mix of both but I'm kind of leaning more towards the latter. Like we're just glad that we bring things up. Occasionally, there will be one or two topics that will come up that we still would resolve and we would have to agree to disagree on something. Or in some cases, I think we would allow one of the lead engineers to just make the final decision on something. But that was pretty rare. CHARLES: So, apart from appealing to either time, the passage of time or just kind of taking a brain dump of all the different architectural options or deferring to a more senior engineer and just kind of asking them to step in and make the call, are there any processes that you can put in place say to kind of mechanically come up with a decision? Like any set of values that you can use as a ruler to kind of line up a set of things to kind of attach weight to one particular solution? For example, one of the things that I always think of is when I have internal conflict about a decision, there's kind of a part of me that feels like this might be the right way and maybe another way is the right way. And so, a tool that I will use is what's internally consistent with the rest of the system. So, even if I've had an insight that something really ought to be framed,one solution should be framed in a certain way. If there's another solution that's more internally consistent with the way things are existing, then I'll use that as a discriminator to say, "OK, that's one thing that I can use to measure a solution against, that I'm not emotionally tied to." It feels more objective. And if you have those tools, you can kind of pile them up and see which pile ends up being higher for each solution. Do you see what I mean? JOE: I definitely lean more towards keeping things consistent with what's already there. Personally, I probably do that to a fault. Sometimes I need to branch out a little more and get comfortable with possibly breaking something. But you always need to weigh whether it's something that is acceptable to break. Like a lot of the systems I've worked with involve money and it's really important that people either have money when they need it or are charged the correct amount when you charge them with things. CHARLES: They get really mad when you charge them too much. [Laughs] JOE: Isn't it amazing? [Laughs] CHARLES: Yeah. JOE: It could be that you are OK with breaking this other end of it where you might charge them the correct amount but the fulfillment of that product or the service or whatever you're selling, you might have a little more wiggle room in that part of the code base. Where if you break something, somebody calls in and says it's broken, and then you're just able to fix it. CHARLES: Is there anything else? If folks are struggling with the way their pull requests work or their code reviews work and they're experiencing friction and tension with their teammates, is there anything else they can do? JOE: What I would suggest is definitely look at the pull request template feature that is in GitHub and make use of that. Because what you can do with that is come up with several sections of the pull request template and say, "These are the questions that we want to ask before we submit a PR." And if you have those questions and those sections right when you go on that template and people read through that as they're making their pull request, they can often catch problems before they get to another reviewer. I can't tell you how many times I have submitted a pull request, started to write the description and [inaudible] these questions and realized, "Oh, this is wrong," or it's broken or it's totally the wrong thing. CHARLES: Right. It's funny and I feel like you want to be asking those questions not when you're submitting the pull request but before you're even writing the code. JOE: Yes. CHARLES: But a lot of times, we don't do that until afterwards and you're like, "Oh man!" Just this process of forcing myself to think about the problem in this way or think about it holistically totally recasts my implementation. JOE: Yeah, things like, "How can this break after we merge it?" [Laughter] CHARLES: Yeah, that's actually a great question, that of one you're talking on pull request. JOE: Oh yes, definitely. CHARLES: Like imagining the [inaudible] scenarios. JOE: Yep. CHARLES: Man, it's almost like you want to read the -- what are the other questions that you have? JOE: So the ones that we have are, first of all, what is this pull request? How does it fulfill the requirements for the ticket? And then how can this break after we merge it? Are there any post-merge tasks that need to be run? If you need to get on a server and run a task or do something after it has gone to production, that's a place to document that there. And then the final question is, how is this tested? CHARLES: Right. That's a good one. And like I said, I think that's the one where I'm going to be starting when I'm both thinking about how my changes will be reviewed and how I review changes. JOE: Maybe I should consider moving that to the top position. CHARLES: [Laughs] I mean, it is like. I'm just thinking about it and it does seem like we go straight to the implementation because that's what's fascinating to us. And so we might have way too much bias for the importance of the implementation over the importance of the test because I have to say I am so guilty of when I'm reviewing. Just looking for the fact that it has a test and not looking for what the test does. JOE: Yeah. CHARLES: And only referring back to the test and trying to understand how the test accomplishes its task. If I don't understand the implementation, I'm like, "Oh, let me look at the test and see how this code is used to the test." That might be problematic but I know that's definitely a little personal goal that's coming out of this podcast for me. TARAS: Excellent. CHARLES: All right. Joe, do you have anything else that's coming up? Any talks? Any meet-ups that you're going to? Any announcements? Anything that you want to plug? JOE: I have a website at JLLeBlanc.com and that's where I am. CHARLES: All right. Well, fantastic. Thank you so much for coming on. JOE: All right. Thank you. CHARLES: Thank you for listening. If you or someone you know has something to say about building user interfaces that simply must be heard, please get in touch with us. We can be found on Twitter at @TheFrontside or over just plain old email at Contact@Frontside.io. Thanks and see you next time.

Sam joins the panelists to talk about frontend and backend team collaboration. Resources: Worse is better The Tao of Microservices by Richard Rodger Sam Joseph is a CoFounder of AgileVentures, a charity that helps groups of volunteers gather online to develop open source solutions for other charities all around the world. Sam's been mucking about with computers since the early 80s and followed the traditional education system through to a PhD in Neural Nets. Next he went all industry, researching mobile agents at Toshiba in Japan, going freelance and then swung back to academia to research peer to peer system and collaborative systems. He now spends the majority of his time trying to make AgileVentures a sustainable charity enterprise, with occasional moonlighting as a contract programmer. Check out his blog at nonprofits.agileventures.org. Please join us in these conversations! If you or someone you know would be a perfect guest, please get in touch with us at contact@frontside.io. Our goal is to get people thinking on the platform level which includes tooling, internalization, state management, routing, upgrade, and the data layer. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. TRANSCRIPT: CHARLES: Welcome to The Frontside Podcast, the place where we talk about user interfaces and everything that you need to know to build it right. My name is Charles Lowell, a developer here at the Frontside. With today also is TARAS: Mankovski. TARAS:: Hello, hello. CHARLES: Hey, TARAS:. Today we're going to be continuing our theme when we think about UI platforms and web platforms, continuing the theme of collaboration and with us to talk about this is Sam Joseph. Welcome, Sam. SAM: Hi, thanks for having me. CHARLES: We've already talked a great deal about how the way in which your team collaborates and the communication that happens between your team and between the different pieces of software, your system, form one of the pillars of the platform that you can't just take lightly. You need to actually be intentful about that. I was thinking we could kind of start today's discussion, kind of talking about some of those collaborations. One that we've probably all encountered, which is usually teams will be split into people who are focused on frontend, people who are focused on backend systems, kind of the services that make sure that all of the nodes that are running on our laptops and our desktops and stuff are running smoothly and error-free and obviously, those two groups of people can sometimes arrive with different sets of priorities and how do we resolve those priorities to make sure that that communication flows freely. TARAS:: What's interesting about these frontend and the backend teams is that our users are not seeing that separation. They only see one thing. They only touch one thing. They actually see as one group but there's tends of be this kind of split between the frontend and the backend. It's kind of interesting that how the user get into this. SAM: Yeah. Obviously in some teams, there's a very clear cut distinction between people at the backend and working with the components that are serving JSON over the API and there are some people who are very, very focused on the frontend and drilling CSS and a number of bits and pieces or even just staying explicitly on the design or UX design and there's a mythical full stack developer who is up and down the platform. It doesn't run exactly in parallel but there is this key thing which is almost how much sympathy or empathy can you have for another person who is not you, trying to use something that you set up. If there was a direct parallel, you'd say, "Obviously, all people who will be working on the frontend are more of that sort of person and perhaps, the people on the backend are not so much that sort of person," but actually, I think you can have people who are doing backend stuff and they're designing API is very, very thoughtfully or the kind of people that consumes those APIs and sometimes, you can have people who are very, very focused on the design and the aesthetics when not necessarily so plugged into how will someone else use this, how will it fits into their lifestyle, which might be very different from my own, so that's maybe another axis, if you know what I mean apart from this sort of pure technical [inaudible]. Does that makes any sense? TARAS:: Yeah. What's interesting is that everyone is trying to do a great job. Everyone is setting out to do something really good. What people's way of expressing good might be different, so if someone could be really focused on the quality of their code like they want to do their version of doing a really, really good job is doing the best code they could write. Sometimes that doesn't necessarily equate to the best user experience. I think everyone that I've met -- engineers who are writing code, almost everyone that I know is trying to do a really good job. If everyone is doing a good job, it doesn't necessarily always equate to the best user experience. CHARLES: I think we had a reference that everyone wants to make sure that their system is of the highest quality possible but quality in of itself is not an absolute value. It's relative. In other words, a good definition of quality is how well a system is fit to a purpose. If it fits very well to that purpose, then we say it's of high quality but if it fits very poorly to a particular purpose, then we say, "This is a system of low quality," but what constitutes something of high quality is relative to the purpose. The question is, what is the purpose of writing the frontend system? What is the purpose of writing the backend system? So it seems to me you're going to have a lot of dissonance if the purpose is divergent but if they both share the same purpose, then that is kind of standard quality on both sides. Does that make sense? SAM: That makes sense and what even more makes it tricky is that actually, purposes can evolve over time and so the thing with the frontend that needed to do with the business today is different tomorrow and the day after. The trick then is sort of the frontend and the backend, as people try to do a great their job, there's this question of how far ahead are we looking so you can talk about important things like sort of asking close modification about [inaudible] extension and there's a [inaudible] of different coding heuristics as best practice that say, you should kind of go in this direction. Sometimes, that will be the hill they want to die on. It's like, "This code needs to be this way because of this thing," and the idea is that it's sort of future-proofing them but I think the messy reality is that sometimes, the thing that you put in place to future-proof, the whole system gets canned. In two weeks, the business changes and what have you, so the extra effort that you are pushing in on one day to protect yourself against changes in the future actually gets lost and perhaps, if only you'd be able to deliver a shortcut pack, this one feature that that will got the next line of funding in, either one advocates cutting corners but... you know what I mean? Like --? CHARLES: Yeah, absolutely. I just wanted to chime in and vehemently agree with you that the purpose can change radically, especially if you're in an evolved environment. What constitutes the good code or the good quality solution can vary just as radically because it needs to fit that purpose. TARAS:: When we talk about frontend and the backend, it seems there's this relationship, which is kind of positional like there's the frontend and then there's the backend. One is in sequence from front to back. It's the direction with the frontend. It's closer maybe to the user where the backend is not. But I think in practice, it's probably more like the left and the right hand where when you have to do two things together, you actually need to do two things to coordinate together. What you describe about and this is I think where taking shortcuts sometimes can actually be a good thing is that if you say, "I'm going to spend the next few weeks on a backend and doing this specific thing," and then you find out that 10 days into the iteration that it doesn't fit, the better approach to synchronize would be to stop the action and realign. But if you persevere, then you might overstep and you actually be out of sync. It makes me think that the art of creating cohesive organizations from development perspective is to create context where the two kind of work in synergy together. I think that's where a good tooling that allows its synergy to exist. I think that's a lot of the work of actually creating systems where the user experience is kind of cohesive and integrated. CHARLES: Actually, there was something that you just mentioned in there but it's actually a little nugget that I'm curious to explore and that is if you're 10 days in to like a 14-day piece of work and you realize that it isn't right and it doesn't fit with the whole, right action is to throw it away. I feel like software organizations and this might be a little bit off topic but it's something that really is interesting to me, so please indulge me. I feel like we see the product being the kind of the code output, even in Agile environments and there is an aversion to throwing away code that has been written. There's the, I would say, incentive is to go ahead and persevere because developer time is so expensive. These are days out of people lives, so they've already invested 10 days. Why not just have four more days just so you have it. When in fact, you actually have more if you just throw that work in the trash because it's an obstruction that's not needed. It's a piece of weight. It's actually something that you now are going to own and it's actually going to be cheaper in the long run and it can be more beneficial to your organization to not own it. Do you all see that happen kind of play out where people become attached to software that they've invested and will make the decision to hold on to it? Say, we'll spend two more days to complete it, even though it's the wrong thing, like identifying which things need to be thrown away? I feel like we don't actually do that very aggressively -- to say, "You know what? We need to not complete this work." SAM: I think that is a really tricky one because I think whatever people might say, when you spend time working on something, you become emotionally attached to it. I would say strongly that how logical or rational or whatever sort of a person you are, my experience is being that people working on things want to see them used. I think in a situation with version control where you can keep things on a branch, they can be useful explorations, things don't have to be thrown away in their entirety. Our charity is doing work for the National Health Service in the UK where there's a lot of employees in Europe and I've noticed the user interface that we're supplying them and I was suggesting some sort of minor tweaks and one of the developers has sort of run with the entire, big, advanced search feature that partially solves the problem but brings in a lot of other bits and pieces. He does some good work there. It's a great work but I think he kind of ran further than I was expecting down that line and I think we have now found a much simpler solution that rather than bringing an entire cabinet, it's a little shading off the side of the existing one. But I think that doesn't have to be a loss and I was reassuring him that the work was valuable and that there is interesting learnings there and potentially, we might use it in the future version of the project and now of course, the way that stuff is moving on, just how it's going to branch, it doesn't mean you can then sort of magically lose some of the work. In that case of doing this 10 days out of 14 and so on, the real question is can you get any value from switching somebody that fast? If they spent 10 days in and they realized they don't need that thing, it's like can you switch them quickly onto something else where they'll do four days or might they as well, just finish up there and leave that on a branch. That's a pull request that gets closed and it's there to go back to. That's kind of depends team by team about how quickly you can repurpose people missed rigs, if you know what I mean. CHARLES: I absolutely agree but the key thing is leaving it on a branch and not integrating it into production, like not actually deploying it because I feel like when we see a feature, it's like we've got to get this thing done and it's done and we're just going to get it in versus now that we've learned how to do this, let's put that on a branch and let's rewrite it and let's take a different approach, rather than just being married to the idea that we're going to get it right the first time or that now is the time for this feature because we understand the complexity of what it actually takes. It is a tricky question. I'm wondering if our processes don't include enough implicit experimentation. We talked a little bit about this on a prior podcast that if they don't include some incentive to not deploy features just because you have them. TARAS:: I think from a business perspective, there's not a lot of model to evaluate a certain thing. We don't have really any effective way of evaluating learning. You can measure code by the numbers of lines of code that somebody wrote and how much of code was shipped but you can't really evaluate how much was learned and how much was persisted. I think a lot of this work around supporting effective collaboration is in building a cumulative systems of knowledge like why is a good Git history useful is because it has a built in mechanism for understanding history. It gives you a way to return back to time in your project and understand the context of that specific change and I think this is something that really good teams do this really well. They will respect this because when it's necessary, it is valuable to have this. When you don't have it and you are a year into the project and something happened and then, you are using the only thing you have, which is your troubleshooting skills or you are trying to figure something, as supposed to going back and relying on that history, on that knowledge that's built into the system, what I'm trying to get to is there is an element that is inherent to our development process, which is we don't have a way to quantify it. We have no way to really evaluate it. I think this is the problem that makes it difficult to throw away work because you can measure the amount of time they'll spend but you can't measure the amount of learning that was acquired. CHARLES: Right. Thatís true. SAM: I think if you have a positive team environment, if you have your team that is stable in there -- your contacts are coming in, the money is there, everybody is there and you've got the team, you don't necessarily be able to measure the learning because the output of the team will be good. They're kind of doing that in the background but I think individual comments are not going to want to pay for learning experience. It's certainly not at the rate of software developer's cost. Although, the throwing-aways, if you're familiar with the [inaudible] book, which I think is a [inaudible] is the author, you know, build one, to throw away, you will anyway. We have a frontend mob that we run weekly doing frontend stuff and CSS and so on and we've done like it's a mockup for the client and there's this question about in my [inaudible] and so Iím saying to other developers there, "Let's not get too attached to this. We may need to throw it away and it will be a great learning to sort of restart on that." The [inaudible] to look quite nicely and the client might get attached to it. They want to ship it and I'm like, "Well, actually there's a lot of other stuff that needs to happen," and so, it's a minefield. It really, really is. TARAS:: I think some of the business relationships that we have to this kind of client consulting company relationship, that relationship might not always create the fit to purpose team for specific challenge. You can have a company that has a lot of employees but their team and their team dynamics might not be fit to purpose to the problem they're trying to solve. If you're building a platform over a long time, you want to be creating that space where that learning gets accumulated over time. It doesn't matter what necessarily the relationship is between the companies that are participating in this process. I think what matter is what are you producing as a result. If you're working together with people from different companies and they're working together and they're building this kind of an environment where you can collaboratively build things together and then people learning from the output and that knowledge is being carried over and people are being able to stack their knowledge continuously over time, if you're creating that environment and you're building a large platform for example, then you are creating a build to purpose kind of technology team to fit what you're looking to accomplish and that'll include consulting companies. I think those team, they're kind of secondary but I think it's just [inaudible] to that. It's like building a quality development organization to fit the purpose of building whatever it is that you're trying to build. If you're building something small, you might have a small team that'll able to build that effectively. If you have something big, you could have a big team that is building that effectively but building that team in a way that is appropriate to what you're trying to accomplish, I think that's the real challenge that company struggles to do. CHARLES: Yeah. In the context of these real teams, I guess what can you put in place given that you have backend teams, frontend teams and each one of these needs to be specialized. This is kind of the power of the way that people work is that we're allowed to specialize and there's power in specialization. You can have someone who can be super focused on making sure that you have these high throughput backend systems that are resilient and fault tolerant and all these wonderful things, so that they don't necessarily have to have the entire context of the system that they're working on inside their head at a given time and the same thing someone working on CSS or working on a frontend system architecture, which has grown to be a very complex problem domain in its own right. But these teams can be working in a context with a purpose is whip-lashing around and changing quite drastically and so, how do you then keep that in sync? Because we've identified purpose as being actually something that's quite a dynamic value. How do you keep these teams keyed in and focused and so, that they're kind of locked in on that similar purpose of they're going to be adapting the systems for work that they're responsible for and specialties that they're responsible for to match that? SAM: It's a good question and I have my own bias view there -- CHARLES: I would love to hear it. SAM: I can't bear working on things where I don't understand in great detail how that end user has experienced or what is the effect overall that it's trying to be achieved. You know, I've been working in boards between the industry and the charity for like 30 years and I know people are commenting like, "You were the person who wants to understand everything." I think there were some people who are maybe quite satisfied who get ticket off the general board or what have you and work on that thing and if the API specs have filled in, so that's it. Go home and they weren't losing a sleep over it. But I think if youíre going to be dealing with these changes and sympathetic that the changes is coming down the path, I think you need to have some degree of empathy with the people who are driving the changes. Do you know what I mean? CHARLES: Oh, absolutely yeah. SAM: You know, as we've mentioned already, I think people get attached to what they build and I don't think you can do anything about that. They will get attached to what they build. CHARLES: Yeah, we've all experienced it. It's so true. It's impossible to [inaudible]. SAM: Yeah. We can try and target it but it's sort of part of our nature. I think there are sort of the tools of the design sprint, of the design jam, of these sorts of things where if you can build to some level is obviously that it can't be shipped but can actually tease out the needs of the user, the designs sprint, the Google team, they have an example with kind of like this robot for hotels where it's like the whole thing is they can have robots that can deliver toothpaste to your door if you run out of toothpaste. In this design, obviously, that would be a huge undertaking to make that as a sort of our production system but they used like a remote control of a robot to simulate all of the key touch points when the client of that hotel, will actually interacts with that robot. I think the same is true when you're building these systems if you can, again going to touch back on we don't fit a code in that way that I think an ever better thing is not be building the code in the first place and to build an almost a non-code system and then, maybe some of the backend are not going to be interested in the results of what people have learned through this kind of user experience trial before they [inaudible] forever but I think it's seeing other people try to use the end system that puts you in place where you can be empathetic. I argue for the bias point of view that I think people on the backend of Netflix, trying to optimizing the streams in that or the other, they need to spend some time watching Netflix or at least watching the comedy of Netflix in order to empathize of how their work relates to the end experience and then, when those end experience needs changed, it's important for them to make change on the backend. Do you know what I mean? CHARLES: Right, exactly. They have to watch through that kind of glass window where they can actually help the person. They can't give them any information. The only levers of control they have is through their own work, making the thing changes that they need to make on the backend, so that one of those users is going to have a good user experience. This idea reminds me of something which I believe is the case at Heroku where they rotate everybody in the company through pager duty, which I think is kind of a brilliant idea where the entire team is responsible for providing technical support to the end users. When a problem arises, you get to understand what it's like to be someone who's trying to use the system. You get to exposed to the satisfaction, whether an issue was resolved or when it's working correctly or your pager is quiet for your entire shift but you can also get exposed to the frustration that you're engendering in the users if something doesn't go quite according to plan. SAM: Yeah. I'm not [inaudible]. TARAS:: There is movement in this direction because there is actually a term that has been floating around. It's like a product engineer. It's someone who thinks about the product. These kind of people tend to have the highest value in Silicon Valley as someone who thinks about the product as the outcomes supposed to their code as the outcome. Even in the Agile space, there seems to be movement in that direction because I think one of the challenges, like to do that, you have to understand how you fit into the bigger picture. I could see it being really difficult. Imagine if you're working at a bank or something and being pager duty at a bank would be impossible, simply because their organization is either too big or too sensitive. The way that their company is dealing with that is they have these group of people where you have a product manager working closely with the frontend engineer and the backend engineer so there's this exchange that is happening where people get to understand the consequences of their actions a little bit more. They understand how things fit together. There is definitely a movement happening in that direction that I think just the more, the better because one of the big differences now is the things that we make are very palatable to the users and the quality of the user experience that users are now expecting is much higher than they were in the past. I think the world is changing. CHARLES: Yeah. We mentioned this when we were talking before the show but going to the University of Michigan as I did, I was in school with a bunch of mechanical engineers. Their goal was to go work for auto companies: Chevrolet and Ford and everything like that but their mindset was very much, I think the product engineering mindset. All of them loved cars and wanted to be part of building the coolest, most comfortable, most responsive cars. For whatever definition of a good car -- there are a lot of them -- they wanted to design good cars but they were into cars and they were into the experience of driving a car, so what's the equivalent then of that product engineer in software? I think that every conversation that I had with any of the mechanical engineers who were going into the auto industry, I'm sure there are some of them that were out there but it wasn't about carburetors or whatever. They really wanted to just get into the building of cars. In some aspects, I'm sure they all integrated in some way or another but it was a group that was very focused on that outcome. SAM: In the UK, I'm hearing this term, 'service designer' a lot that's coming up. Are saying that, Charles, you get the feeling that even getting into software, I'm not so excited about using their own? Like the car, I want this amazing car and then I can drive the car and I'll experience the car --? CHARLES: Right and other people will experience the car that I've helped design. SAM: Right and in some way, in software, it's almost like the software itself there's this kind of mathematical beauty of its own and it's like always been more important than the other software heads around me like the software that I wrote. I mean, the user? At the conference and all the software guys love it, that's the key objective, isn't it? Yeah. I work with a lot of learning developers who are rightly focused on wanting to improve their skills and wanting to level up in particular tech stacks that are the ones that will lead to jobs and the future and financial stability and so on but I kind of wish I could inculcate in them this desire that the user experience was the higher goal than which bit of code does this or the other. Maybe, I'm being unfair to them when I say that. Coding is hard. There's a lot strange concepts to grasp than sort of grappling with those concepts -- how does this work or why does this work or should I use this function or should I use this method or what have you. I don't know. I think [inaudible] bit a wall when I'm sort of saying like, "Let's think about it through the user perspective, what does the user needs here." It feels like they want the safer answer of what's the correct solution here, how should this be refactored because you need a skinny controller or a fat model or whatever happens to be. I don't know if that's -- CHARLES: Right, like what's going to make my life easier, in a sense of if I'm going to be maintaining this code and it's important. It's very important. You want to be happy in your job, you want to be happy in your work and so, you want to have the skinny control or the fat model because it's going to lower the risk of pain in your future, supposedly. I definitely understand but that can't be the only incentive. I think it's what I'm hearing. The thought just occurred to me, I actually don't know that much about game development. I know the game industry is certainly has got its problems and I don't know much about the development culture inside the game industry. I do wonder what it's like because it does seem to be somewhat analogous to something like the car industry, where if you're a developer in the game industry, you're probably extremely focused on the user experience. You just have to be. It's so incredibly saturated and competitive for just eyeballs and thumb on controllers. Like I said, I don't really know anything about the game industry when it comes to development but I'm wondering if there's an analogy there. SAM: Yeah. It sounds strong to me and as much of my cousin who works in the game industry and I sort of taught game programming and work through a lot of it. The game industry has got these sort of user testing experience baked in and it kind of like repeat, repeat, repeat, repeat. There's this sort of constant cycle of doing that and in the somewhat wider software industry, in a certain extent, pay lip service to that. CHARLES: The game industry, they live and die by that. The code lives and dies by how it actually plays with real users. SAM: Yes and it feels like in the general world, there's a lot more user interfaces that they just sort of struggle on whatever market dynamics people need to use, these existing vested interest, these banks, these supermarkets and what have you. I guess the market is too big, almost. It's not covered enough but do we really want our industry to be so cutthroat? I don't know. CHARLES: Yeah. We've kind of seen an example of a couple of industries: the car industry, the game industry which is kind of adjacent to where most software development happens but they have this concept of exhaustive user testing, kind of the pager duty if you will, where you get to experience that. So how do we, on our team and when I say our team, I mean anyone who happens to be listening, what's the equivalent of pager duty for the applications that we write? How can we plug ourselves into that cycle of user-ship so we can actually experience it in a real and repeatable way. SAM: In the work that we're doing with the NHS, they have a similar program. There's a lot of people who are working purely death by desk jobs but they do have a framework for us to go and observe in the hospitals and emergency rooms and so on. I guess the 'how can we achieve that outside of those clients who have those framework in place,' it seems like maybe we need a version of the cycle where a different person gets to be the product owner and tries to represent what the users are experience each week. I think almost though, it seems like we need more of that thing you mentioned, Charles which is like kind of being behind the one-way silvered mirror as some sort of framework that connects the loop between some of the individual developers are doing and their experience of how the users are seeing things. I think that's going to be difficult to introduce. Just to sort of back up a little bit with them, I see this kind of idea of Agile, which says, "Let's be using the software which is the thing that's kind of changing and evolving unless you already deployed and you are in the maintenance mode from the beginning and you're getting that thing out there so you have your one-week or two-week or three-week cycles where you keep on having touch points," and I think that's better than touching once every two years. As malleable as modern software potentially is, it's too sticky. It's like you were saying Charles before with that deploying or whatever, these are all gyros and so, you kind of need a really good mechanism for mocking out interfaces and having users experience and there's a couple of [inaudible], vision and there's something else that's sophisticated systems on the UX space where you can put together sort of a simulation of your interface relatively cheaply and you can run these things and then have sort of video capture of the users interacting with the system. I think the difficult part that we have in the software industry is we are in this thing, where there's not enough people wanting to be software developers, partly with I guess the cars and the games, is there's so many people want to be game designers that the industry can kind of set the terms but we're in this inverse situation here with software developers where software developers are so much in demand, they can kind of say, "Don't put too much pressure on me. I'll kind of like, I'll go off to different company." You know, we kind of have to like herd the cats, as they say into allowing these high powered software developers to go in the direction as they want to go in and so, it may be difficult to impose something like that, where you're getting software developers to really experience the end user's pain. I guess what one has to do is somehow, create a narrative to sell the excitement of the end user experience and the beautiful end user experience to software developers such that they're fully out of themselves and say, "Yes, I want to see how the users are using my software." Do you know what I mean? CHARLES: Yeah. TARAS:: Yeah. Because a lot of company had this process where there'll be a product manager, there'll be a designer, they'll design through mock ups and they'll just hand it over to developers to build. There could be some backend, some frontend. I think if you're doing that, there is no emotional engagement between the creators of the actual implementation and the people who are going to be using that. One way to do that is to try to add more of this actual 'however you do it.' You know, introduce more of the personal experience of the users to go along with the actual mock ups so that people understand like, there's actually be a person on the other end that are going to experience this and create some kind of emotional engagement between these two end. How you do that, I think that's a big question but I think if the organization is simply just throwing designs over to development, that's where the part of the problem is and trying to -- CHARLES: Well, actually, that's a fantastic point because ultimately, we've talked about emotional engagement and attachment to the software being a liability but the reason it exists and the reason it's intrinsic to the way we do things is that's how things get built. We get emotional attachment to it. It's the impetus. It's the driving force. It's literally the emotive force causes us to go forth and do a thing. It's why we're going to do it as a good job. Like you said TARAS:, if you just kind of throwing your tickets over the wall, there is no emotional engagement and so people will look for it wherever they can find it. In the absence of an emotional engagement, they will create their own which is good quality software that's 'clean' code because people need to find that meaning and purpose in their work. Maybe the answer is trying to really help them connect that emotional experience back to that purpose of the user experience, so that there is no vacuum to fill with kind of synthetic purpose, if you will. SAM: That's a great point. The charity in AgileVentures that I run, when we get things right, that's the thing that happens in that. We go for transparency at open source. We have these regular cycles where the charity client is using the software in a Hangout with us, with the developers who work on these things and the developers whether they're in a Hangout Live, whether they're watching the video a week later, they see the charity end user struggle with the feature that volunteer developers have been working on and they make that attachments. It's more than just 'I want to learn and level up in this thing.' It's like 'I want to make this feature work for this end user' and we're very lucky to have these charities who allow us to do that level of transparency. The difficulty often comes that I would see in our paid projects where I would love to be recording the key stakeholders using the system but for whatever political reason, you can't always get that. I think that process of actually connecting the developer with the person who using it and doing that reliably, so that they can have that empathy and then get that emotional connection. It's just tricky in the real world. CHARLES: It's very hard. One thing that we've deployed on past projects, which I think has worked fairly well is kind of putting a moratorium on product owners writing stories or writing tickets and actually having the developers collaborate with the product owners to write the tickets. In other words, instead of kind of catching a ticket that's thrown over the wall, really making sure that they understand what is the context under which this thing is being developed and then almost as in a code review sense, having the product owner saying, "Actually, the reason we're doing it is this," and having a review process where the developer is actually creating the story in support from the product owner. Because ultimately if they have that context, then coming up with the implementation is going to be much easier. It's really is about facilitating that upfront learning than being able to do the actual work. That's something but a lot of organizations are resistant to that because the product owners really want to say like, "No, I want it to go this way and I want to just hand this to a developer and I want them to do it." It's kind of wrestling in control and saying, "You've got veto power over this. You're the editor but we really want to make sure that you're on same page with the developer." In cases where we have been able to kind of have product owners make that shift where the developers are owning the story, oh sorry, or the primary authors of the story and more of the code reviewers of the story, if you will, implementation just seems to go so much more smoothly. The questions, the key points kind of come out of the front of the process and by the time you start actually working on the thing, the manager or the product owners has the confidence that the developer understands what is involved in making it work. SAM: Getting that done, what one will say something as tricky to do, I think in the ideal world, you have more of the developers involved in the design sprints or the design jams. The logistics of it are you can't really afford to have all those developers in all of those soft meetings where they are coding away. That sounds a great medium there. I think there's various organizations that do sort of their kick offs where their stories are kind of if not code designed, then there's cooperative voting on the complexities of the stories and making sure that they have folks understand the stories that they're working on and there might have some very different organization that are going to have different constraints on how much time that the organization feels, the different people can be allowed to spent on different sorts of activities. It's sort of tricky, isn't it? CHARLES: It is definitely tricky because any time that you allocate for people, that's the most expensive resource that you have, so you want to be smart about it. SAM: Which comes back to that issue then again of repurposing people. If you've got that feature that you go over 10 days, can you say to that person, "Can I switch you over onto this other thing for four days?" Maybe logically, that would be a better outcome for the sprint but maybe emotionally, that person is so attached to that. They are not fighting that front. The biggest trouble for me, I think over the last 30 years is I assumed that the logical stuff was tantamount. These things like the skinny controller and the fat model, we'd agreed on that that was correct and so, that's why I should pushed for, that's why I should fight for because it's the truth or whatever and actually, maybe I'll sling back around in another 30 years, you can choose your battles because the level of emotional pressure on people, then the whole thing just explodes and nothing gets done. You know what I mean? TARAS:: Sam, I have experienced something very similar and I think about this all the time. It's just how many perfect things are perfectly acceptable to people in using a different lens when I think about technology because the more skilled you are, I think quite often, people become more pedantic about how they approach things but in practice, the more things that you see that are not written but you realize how really imperfect they are and how in many ways, they fit the world very well, people use it. It's being used by many people in its imperfect state, so there is something like this hole between perfect implementation and the role of this perfect implementation in the world that I think that duality is really interesting. CHARLES: Yeah. There's a fantastic paper written by, I think it was Richard Garfield back in the late-90s or early 2000s called 'Less is More,' where he kind of talks about this exact tension and he calls it the MIT school of software and the Berkeley school of software and I think Garfield came from the MIT school but basically, the whole thing was saying the Berkeley School is actually right and the name of the paper is 'Worst is Better.' It's a really interesting essay but just talking about working things that are in people's hands will beat the best design every single time because those are the systems that get used and improved. There's a lot more to it than that. He talks about this exact fundamental tension and obviously, no system exists on either one of those perfect poles -- the MIT school or the Berkeley school. I think what he was trying to point out is that exact fundamental tension that we're talking about, the quest for the 'correct solution' and the quest for a solution. I'm actually have to go and re-read it. I remember it being an intriguing paper. SAM: I guess the thing that makes me think of is sort of related to philosophy value. I read recently about this, attachment to outcomes. I'm going to segue back but we've got this discussion in one of our teams about, this is sort of microservices versus monoliths and in reading this, I doubt microservices, which is actually pretty radical in some of its suggestions that they're talking about it in Greater Than Code Slack where it's sort of saying that actually, if you keep your microservices small enough, then a lot of the things like code quality become actually kind of irrelevant it sort of almost argues that a lot of the things that we like about the Agile and these things are our ceremonies that are only necessary because we trying to feed these monoliths. I'm not saying it is true. Iím just saying it's a pretty radical position that itís taking and it certainly, captures the minds of some people in our organization. Some things that I've been trying to make some simple changes just to smooth off some of the edges of the platform that we're working with and I had this respect of like, "No, we can't just make those simultaneous. We need to move to microservices." They're great and it will be perfect and they will allow expansion and so on and my immediate reaction is sort of, "I'm glad we don't have to build microservices because [inaudible]. It's all about attachment to outcomes, so am I attached trying to automate part of my week that I think will have some positive goals in the future? No one's got a crystal ball. That's only a guess on my part. If I've got some folks who are excited about doing this thing with microservices, maybe I should empower them in that and I should started a mobile microservices and we kind of playing with these set of framework and so on. It's interesting stuff as I'm working my way through the book. At the same time, while we've been doing that, I've actually delegated it to someone else to sort out this sort of thing and I've actually kind of addressed the problem what we would need the microservices for through a different mechanism but still, the microservices thing rolls on and I kind of think, "Well, is that all a complete waste?" But then actually maybe, in two years down the line, it will turn out and that will be a beautiful thing that will enable things. The further that I go on, the more I say, "I just don't know," and actually, if I can detach myself from caring too much about the outcomes one way or the other, I think it's both long and enjoy myself but it's a tricky thing when you got to pay the rent and pay the bills and so on. I don't see any resolutions to that. I love people being able to use things and get stuff done. I'm so excited about that and I guess, I will keep pushing all of the developers that I'm with towards trying to have a better empathy or understanding of their end users because I think software is more fun when you're connected to the end people who are using that. CHARLES: Absolutely. Microservices reminds me kind of the experience that we've had with the microstates library. Because we've kind of identified this one very small slice of a problem, a 'refactor,' it's basically a ground up rewrite. If you've got a library that is a couple of hundred lines of code but it presents a uniform API, then you can rewrite it internally. You can refactor it by doing a ground up rewrite and the cardinal rule or the cardinal sin is you're never supposed to do a rewrite. SAM: Yes and that's the microservices that they're saying. It's like you should rewrite everything all the time, basically. CHARLES: Exactly. You should always be rewriting it. SAM: Yeah. Should be able to throw it away because it's a microservice and it can be rewritten in a week and if you're throwing one away, it's only a week worth of work and you can keep on moving away. It is an amazing idea. CHARLES: I have to read that book. Anyhow, we're going to have you on again to explore -- SAM: Well, let's do another one on microservices. It was a great fun. Definitely, it's time to wrap up but I really appreciate you having me on the show and being able to discuss all these topics. CHARLES: Fantastic and I can't wait to talk about microservices. This might be the impetus that I need to finally actually go learn about microservices in depth. SAM: I'll recommend Richard Rodger's book, 'The Tao of Microservices.' CHARLES: All right. Fantastic. Anything we should mention, any upcoming engagements or podcast that you're going to be on? SAM: Iím always on the lookout for charities, developers, people who want to help, you can find us at AgileVentures.org. We're busy trying to help great causes. We're trying to help people learn about software development and getting involved in Agile and kind of like experience the real software in action, software development where you ideally interact with the end charity users and see how they're benefitting from the product. We love any support and help. You can get involved in that, if you want to give a little bit to open source and open development. We go for transparency. We have more mob programming sessions and scrum and meetings online/in-house every day, so just come and check out AgileVentures.org and maybe, see you [inaudible]. CHARLES: Yeah and if they wanted to say, reach out to you over email or Twitter, how would they get in touch? SAM: It's Sam@AgileVentures.org and I am at @tansakuu on Twitter. Hit me on Twitter or just at Sam@AgileVentures.org. CHARLES: All right. Well, fantastic. Thank you, Sam. Also, if you need any help with your frontend platform, you know where to get in touch with us. We're at @TheFrontside on Twitter or Info@Frontside.io. Thank you, TARAS:. Thank you, Sam and we will see everybody next time. Thank you for listening. If you or someone you know has something to say about building user interfaces that simply must be heard, please get in touch with us. We can be found on Twitter at @TheFrontside or over just plain old email at Contact@Frontside.io. Thanks and see you next time.

Jacob joins the panelists to talk about team collaboration based on his RubyConf 2017 talk, Code Reviews: Honesty, Kindness, Inspiration: Pick Three. Jacob Stoebel is a software developer living in Berea, KY. He spends his days writing web applications in Ruby, JavaScript, and Python, working with data, and leveling up as a software engineer. He works and studies at Berea College. You can find out more about Jacob at jstoebel.com. Please join us in these conversations! If you or someone you know would be a perfect guest, please get in touch with us at contact@frontside.io. Our goal is to get people thinking on the platform level which includes tooling, internalization, state management, routing, upgrade, and the data layer. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. TRANSCRIPT: CHARLES: Hello and welcome to The Frontside Podcast, the place where we talk about user interfaces and everything that you need to know to build it right. My name is Charles Lowell, a developer at the Frontside. With me today from Frontside also, is Taras Mankovski. TARAS: Hello, hello. CHARLES: Hello, Taras and today, we're going to be talking like we do every time about a piece of the platform that you used to develop user interfaces frontside at your company or organization or wherever it is that you build software. Today we're going to be talking about a piece of the platform that's very, very critical that often gets short shrift or is excluded entirely from what people think of when they think about their tech stack and that's how we as teams collaborate to build and maintain and produce the quality software that we can. With us today is Jacob Stoebel. Welcome, Jacob. JACOB: Hello. CHARLES: Now, what is it that you do, in your day-to-day? JACOB: I'm a full-stack developer for a little company called ePublishing and I mostly work in Rails and React. CHARLES: Rails and React and so, when we were searching for people to talk about how we collaborate these teams, Mandy suggested you because of a talk that you've given at a RubyConf, specifically about code reviews, which I think are actually a huge piece of the collaboration process because it's a major forum where team members get to interact with each other and it's the gateway for making sure code quality is maintained but more than that, I think it's a learning -- a place where we learn. I learned so much both as a reviewer and as someone who is submitting my work and so, it's actually a very important part of the software development process. You have a lot of great examples of how to not do code reviews. JACOB: Yeah, I think I may have been a little bit too indulgent in that talk. I had a lot of fun. I did some research from other people, mainly from anecdotes. I had research from talking to people about really, all the anti-patterns that come out of code reviews. It seems like every few weeks, I'll see a tweet that says something along the lines about how code reviews are broken. I don't really know about that and I have to say, I think I'm kind of lucky at my job that I think they're done in a way that really leaves me feeling pretty positive and that's certainly a good thing but I think what it comes down to -- I'm going to sort of talk about where these ideas come from in a minute -- is that we often have code reviews that for one -- and you can tell me how this is for you too -- often the code review is happening at a point so late in the process, where the feedback that you get may not be actionable. Have you experienced that? JACOB: Before I answer that question, just to kind of echo the sentiment and maybe I'm being presumptuous, I feel like the code reviews that we do are actually very positive, so I haven't got to experience firsthand. Although I have seen conversations on GitHub where it looks kind of like a Celebrity Chef, where you have someone doing the code reviews like Gordon Ramsay up there just screaming and someone has put this plate of food in front of them and kind of picking it apart. That one is extreme but this is actually something that I struggle with, what you were talking about, what is the appropriate point at which to get feedback. I agree that you want to get feedback as soon as possible and sometimes, when you've invested weeks and weeks into something or you're like at Mile 100 and they're like, "You know, at Mile 2, you were supposed to turn right," and now, you're off in the forest and you've been tracking 98 miles in the wrong direction. JACOB: Yeah and the work is due, right? This needs to get ships tomorrow. CHARLES: Right, so you've got massive pressure. This is something that I struggle with myself is when is an appropriate time to really try and be public about what it is that you're doing. JACOB: Yeah. I think that is a really good question and I think what you're getting at and I would agree is that, the sooner, the better and when you can tighten the intervals between feedback is probably better. I'll just take a step back and I'm going to take a longer route to go and get to my point. I am a career changer and before I was in this career, I was a high school theater teacher, so it was really different and I won't give answer why I changed other than this is the greatest [inaudible]. But one thing that I really struggled with is I was working with teenagers and I really wanted to see them grow and improve but at the same time, these were kids and they have fragile egos and I don't want to tear them down, so I came across this really interesting framework for feedback. It is called the Liz Lerman's Critical Response Process and I give credit to her in the talk. This comes out of the dance world. Liz Lerman is a pretty accomplished dancer and choreographer and what she found is that in the dance world and I think it's not too dissimilar from our industry is that the feedback received was often given in a way that was leaving people feel really torn down and mostly, not feeling inspired to go back to their work and make it better. It really felt like feedback is about giving you a grade. It's like, "I'm going to tell you how good of a job you do," and there's certainly a time and place for that but the inspiring question -- I guess the rhetorical question -- that she made is, "Shouldn't the big point about feedback be that it makes you so excited about the work you're doing that you just can't wait to go back to your keyboard and keep working on it," and she found or in the case, back to the dance studio, it really sort of structures this framework for how people can give feedback to a creator and that could be a creator of anything. You mentioned cooking. This could be about food as well that sort of set some guardrails for how we can give feedback that is useful, it's inspiring and it's kind. I'm going to really distinguish between kind and nice. Nice would be, here I'm going to say things that are only pleasant about your work but what I mean by kind is feedback that is really taking care of your team and making them feel like they are respected and cared for as human beings so they don't go home every Friday afternoon and cry on their couch and just drag and coming back on a Monday. That's kind of the basic idea of why we need, maybe a kind of a framework for getting feedback. CHARLES: I agree totally. It's almost like you need to conceive of your feedback is not a gate to quality but a gift to embolden somebody. It's like they've just been doing battle with this code, with this problem, they've been grappling with it and it needs someone to wipe their brow and maybe give them a stiff drink, so that they can get back into the ring and be invigorated. JACOB: Yeah. TARAS: What I'm hearing in this conversation so far is it's kind of like a tone or way of communicating to the person receiving the feedback but sometimes, no matter what your tone is, depending on how your team is set up, depending on the context of your actual code review, it can still kind of land in the wrong place? Have you experienced that where the team conditions impact your ability to actually provide feedback? JACOB: I think I know what you mean. I think what you're talking about is this sort of the organizational structures that are set up are sort of lend themselves to certain modes of feedback and discourage others. I will give this example that I've heard from numerous people and I think this is what you're getting at is feedback that's given at the end. Just like I said, feedback that is given the day before, it has to be shared. Or feedback that it's almost like if we work in an environment where sort of like the hair on fire environment where it's like everything was due yesterday, that's not an environment that's going to be conducive to slowing down, taking a step back and saying like, "Let's point out what we think this work is doing? What questions we have about it? Who has opinions about the direction that's being taken on it?" And really zoom out a little bit more. CHARLES: Do you have any concrete examples of how that early stage feedback has taken place at your work? Is it just over Slack? Maybe, the whole people need to step back from the idea that working on one-week iterations or two-week iterations and at the end of the iteration, everything is due and everything will get merged at that point. How do you kind of break up that structure to say, "No, we're going to try and have checkpoints and milestones?" What are deliverables that you can decompose the work into that fit inside the framework, that are inside the big deliverables, which is sensibly, the feature that you're working on? JACOB: I think first of all, it's the way this thing goes about. I don't think this framework works over Slack. I think it has to be immediate, I think it has to be either in personal or on Skype or Hangouts or something. One of the points of this type of feedback is really about checking in with each other as a team and I think what's great about Slack is that it lets you leave a message and walk away and the unfortunate thing about Slack is it's not meant for sort of attaching how people feel about things or what people's reactions were to them. I think you all have to be in the same space, hopefully with your camera on, if possible and really, just sort of checking in with each other as a team. I can point to times with my team that I think that's really worked out. I think you made a good point when it comes to really getting started with a project because there are times where I made the mistake of not trying to get feedback from my team early on when I was going to start a project and as you can imagine, did that really cost me? It's really getting feedback from my team and my supervisor about the direction this is going to want to go and I'll say from experience, I work on legacy codebases and as you can probably imagine, it's easy to paint yourself into a corner and what the thing about legacy code is that you don't know what pitfalls you're working into. You can get started and you can sort of find into the process, there is some reality about this code that you didn't know and it is really getting in the way of your work that had you known about it, it would have saved you a lot of trouble because you could have planned your way around it. Then the fortunate thing is drawing on the wisdom from people who they know about it because they struggled with it already if they've been around longer than I have. I think that's a really good point. This is a good thing to do. As you're getting started and you can be sharing this is my just initial idea of how I'm going to go about this. What my tech stack is or my understanding of the problem space, all of the above and to really sort of check your assumptions and see if they really check out. CHARLES: I want to circle back a little bit to something you'd mentioned before and that is you want to be kind in a code review and I would say, you probably want to be kind anytime you're giving feedback or interacting with your teammates but what's the process that you can go through if you find yourself struggling? How can I deliver this message that I want to deliver and have it come across this kind? What's a process or checklist that I can go so that I don't open my mouth up and say something that I can't take back or that is going to land wrong? JACOB: I'm glad you asked that and I think that this is a great way to introduce the guidelines for the critical response process. There's basically four steps to it and the way it's structured is you have the person who has created the thing. It could be the person or the team that has created the feature. You have other people who are responders to it. They could be people within your team or they could be others in the organization who are invested in your success. They're not here to tear you down or give you a grade. They're here because they want to see the project do well and then, there's going to be someone who is a facilitator. The way it works and I think this is directly addressing your question is there are guardrails that are going to help you not steer into territory that is going to leave someone feeling torn down. The first step to this process is all the responders are going to say statements of meaning about the work and what I mean by that is you're going to make things that stand out to you that are not attached with an opinion. You could say, for example, "This project is using React hooks. That's something I noticed." You're not going to say, "I think that's a good idea or a bad idea," but you're going to say, "This is what I'm noticing," and that is something that can get jotted down because that's going to be fodder for discussion later on like, "Let's talk about this new feature in React," and let's talk about it later. We can talk about if we think that's a good thing or not or what the implications are for that. The next step after that is that the person who has made the work of the team, they get a chance to ask questions of everybody else about what they thought. You've probably noticed that in a lot of pull requests, someone puts their work out there and then, the next thing that happens is everybody starts commenting on the work and saying what they think about it. This flips it. At first, you as the creator, start asking questions or you can say, "This thing over here, I think it's maybe a little wonky or it's a little hacky but I couldn't think of a better way to do it. What do you think? Do you think it's right? Do you think it's a bad idea?" Or this bit over here, "I'm pulling in the third party library. I think maybe, it's worth it but what do you think? Is it not worth it?" CHARLES: I like that because ultimately, the people who have created the thing are the most familiar with the problem space. They've spent a lot of time thinking about it and so, they can actually direct the conversation to the parts of the implementation that really are the most iffy and the most unknown because everybody is going to feel this need to comment but it's the classic case of bikeshedding really, the true experts or the people who've just been spent all this time implementing and so, people will comment up to their greatest point of familiarity with the problem, which could actually be not that great. Can you say like, "Can you really focus your mental energy on this?" I like that a lot. JACOB: Yeah and really, it sets a good tone. The assumption behind all of this is that the creator, like you said knows the work best and really ought to be in the driver seat when it comes to feedback, so it really sets the tone there and say like, "The creator knows what's most important. Let's give them the first opportunity to frame that," and I know plenty of times like if I'm asked to review a PR and I'm not given any kind of prompt or direction, I will probably scroll to the file. Maybe I'll find the file in that PR that I'm actually familiar with or I'll look for some pattern that's something that's like, "I understand what's going on here. I can give feedback," and if it's all that other thing over there, I'm completely confused, I'm going to ignore it. But the creator could illuminate me a little bit, then I would understand a little bit more and then, I'm in a position to comment on that thing that I otherwise wouldn't have understood. That's the second step. The third step is now the responders get a chance to ask their questions but the important thing about that is that there are neutral questions. The assumption here is that the responders need to better understand the context from which this code was written in order to be able to give their opinion. Here's an example coming from the Rails world. I could say, "Tell me your thought process for using Factory Bot," in this example. If anyone doesn't know that is somewhat of a contentious issue in the Rails community, rather than just coming out guns blazing and say like, "I think this was a bad idea." It's like, "Tell me your process because I want to understand the context you came from and then we can together evaluate if coming from that context makes sense or if it doesn't," so neutral question. They have to be neutral questions. By the way and we've probably all heard this before, this is not a neutral question, "What were you thinking when you decided to do blah-blah-blah-blah-blah." Everyone knows what that means. CHARLES: Right. I was going to say, you can be very, very passive-aggressive with questions. JACOB: Yeah, exactly and this is a place where having a facilitator can really help -- facilitator who is not one of the creators. Someone can just say, "Let's back up. Can you rephrase that without the opinion embedded? Can you just say that again?" and with that again, those are some of the guardrails that keep us on track. After the responders have been able to ask their questions how hopefully everyone has a better understanding of the context from which the code was written, then it's time for opinions with consent of the creators. The way it works is the responders can say, "I have an opinion about using React hooks in this codebase. Would you like to hear it?" The responders can say, "Yes, please. Let me know," or they can say, "No, thank you," because the responders, having the best knowledge of the context, might know that that feedback is not useful. Maybe, they have a really good reason for using React hooks or maybe, they know what's coming in the future or maybe, they know if there's no time to fix it now or it's not worth fixing now. They know the tradeoffs best and so again, those are guardrails and it puts the creator in the place of saying, "That's actually not useful feedback right now. Let's just not use it." They can say, "Yes, please tell me," or they can say, "No, thank you. Let's not talk about that." CHARLES: In the context of a pull request, the process you're describing could be played out in any number of media but in the context of a pull request, the creator is the person actually submitting the code, how do you handle the issue of who pushes the merge button if there's still some opinions that haven't been voiced? For example, a creator says, "No, I don't think that's helpful feedback," is the assumption of then the creator can go ahead and just push the merge button? Or is it basically saying, "I don't want to hear your opinion," relatively rare? JACOB: That is a great question. I think I tried to get at this in the talk. Before one thing, I am probably, like most people don't have the option to just say to my manager, "No, I don't want to hear your opinion." I get that. There is a contrast between the pure version of the feedback process and then reality. They have to balance. But teams can sort of work out the way they give feedback. I have example of an anecdote that someone shared with me once, when I was doing research for this talk. There was this sort of agreement with the manager that their manager wouldn't give feedback on Friday afternoon. They just wouldn't. Everyone preferred that. Everyone sort of wanted, say on Friday afternoons, I'm really going to be just focusing on winding down for the week and I don't want to get dumped on a bunch of feedback. The point being, even though you can't just blanket-ignore feedback, you can work out circumstances with your team for the best way that feedback can be given and circumstances under which, it can be politely declined. CHARLES: I see. TARAS: I'm curious about a different part of this because a lot of this is how to give feedback but I'm really curious about the why part. I think many of us take it for granted that good code reviews are very valuable because a lot of teams that I've encountered that are taking on really big challenges but didn't have a code review process and so, one of things I'm kind of curious is for people or for teams that don't have it in place, what kind of symptoms can they observe in their daily operations that would suggest that maybe code review is something that they need to put in place. CHARLES: Taras, you're talking about kind of the places where we've seen where the culture is just push everything to a branch, there's a 1000 commits there, open up a pull request and no description, no name. It's like, "Here's this thing. I'm taking comments for the next three hours and if everything goes well, let just merge." Are you talking about those kind of situations where really a big culture of pull request or just feedback around change is very, very nascent.? TARAS: Yeah, a lot of times, it's the 'ship it' culture, like this is getting in the way of shipping it. CHARLES: So you're saying like how you sell the entire idea? TARAS: Yeah and if someone is listening who is noticing that, a lot of people would know that we're not really doing code reviews but what are the symptoms that they could be observing that could say like really, this is we need to change, like this can't continue. JACOB: Yeah. One thing that occurs to me as if there's all high level of surprise when you read it, when pull requests are read, it's like, "Oh, you went in that direction." I think that could be an indication that maybe, we could have checked in at the halfway point or even sooner because there seems to be differences of perspective on where this is going or where it should end up that's why [inaudible]. TARAS: At what point do you think people would see this? Is this something that would happen kind of way down the road? Like actually, "How did this end up in the codebase?" CHARLES: That's surprising except deferred even further, right? JACOB: Yeah, who wrote this last few. In having that kind of feedback process, let's sort of take a look at where this project has come in the last few months and see if we can sort of learn from what went well and what didn't. CHARLES: This is related to the concept of surprise, if you see a proliferation of many different patterns to accomplish the same thing, that means the communication is not there. People are not learning from each other and not kind of creating their own code culture together. If that's missing and that manifests itself in all kinds of ways, in bugs, in weird development set up that takes me two hours to get this local environment set up and things like that, if you're seeing those things, chances are you need some way to come together in a code review culture is really, really good for that. JACOB: Yeah and I think in the ideal code review culture, everyone that's sort of brought on board is saying, "I am going to share responsibility in this patch, doing what it's supposed to do and not breaking anything or not burning down the world." You mentioned the 'ship it' culture, I could imagine toxic cultures where the person who shipped it, if it broke everything, it's on them to fix it and they have to get woken up or whatever and the idea about feedback is now we're sort of forming a community around what was done, so it's like the person that push the merge button isn't the only person involved. It's like if we have a culture where we say everyone that participated in the PR is collectively sharing the consequences and that will happen eventually and say like, everyone who's on this thread, it's on all of us if something goes wrong to fix it. I think that is certainly something that one would hope you'd see. TARAS: I'm curious, where do you see this kind of observations usually come from because sometimes, I can imagine there, being a developer, coming on the team and they're like, "Why wouldn't I do code reviews?" and they're like, "Well, we have always not done code reviews," but then there could be someone like a product manager or somebody who's like, "Why wouldn't I do code reviews? We should start code reviews." Have you seen ways of introducing these ideas to teams that have worked out well? JACOB: Yeah and I should probably say that, I'm not a manager, I'm certainly not an expert in how this works so I actually don't have a really great example, personally. I can churn example from working in a previous team, where everyone secretly wanted to be more collaborative but didn't know how to do it because if I'm the first person that puts myself out there and no one knows else knows how to collaborate with me, how to reciprocate, then what was the point? For the top 5% of teams that are just really have great energy together, they don't need a framework to do this sort of thing. They're just doing it naturally. I think for everybody else, we need some kind of guidelines to do this because for better or worse, this is the industry that we're in right now. It isn't built around us. We don't know how to function this way and it's no one's fault. It's just sort of that's the way we've all sort of learn to work in this industry and I suspect we're not the only industry like this but we need some kind of guidelines to do it. TARAS: Maybe it's a difficult question to answer. It varies probably from team-to-team. JACOB: Yeah. CHARLES: Yeah and maybe, we can kind of shift the question just a little bit because I have one that sits alongside not quite the same question but I think related and can bridge it and maybe we can find the answer there. We've talked about a little bit and there's definitely more to unpack there, how to give feedback that's kind and honest and I think to... What was the third? JACOB: Inspiring. CHARLES: Inspiring, that's right. What about from the flip side? This is something that actually comes up with us as consultants but I think it's something that other people will encounter in their jobs too, is what do you do when you are the creator and you're trying to present or share and ultimately solicit feedback from a stakeholder, the CEO of your company, one of your clients, one of your customers and you see them engaging in kind of a mode of feedback that's less than constructive. They're nitpicking on things that aren't really important and maybe, this could be completely and totally inadvertent. Their intention could be that they're trying to help you out but it's really not being helping at all and it's kind of like either tearing you down or just not being productive and it makes you feel... What's the word I'm looking for? Just brings an air of contention to the conversation that's not really helpful to producing the best result for everybody involved. How do you, as the creator actually engage with those people in a positive way and kind of help establish the guardrails and be that agent of change when those guardrails don't exist in their minds yet? JACOB: Yeah, how do you do it, right? It's probably rare that there's going to be an environment where someone's going to say, "We're going to do this framework for feedback," and everyone are onboard from Day 1. I think one of the things that you're probably getting at is the frustration that happens when people start giving feedback. You have this perception that they're giving you feedback that's unuseful and they're only giving it because that's the only thing they can think of or -- CHARLES: Exactly. They got to say something, they need to contribute their two cents to the conversation and some people are trying to be helpful and just aren't. Some people are just trying to appear smart. JACOB: Yeah and it's like, "Oh, boy. They're just really off." CHARLES: But you can derail the main narrative that you're trying to establish and get off in the weeds, kind of skirmishing with these people and after that happens, you're like, "Wait, no. I don't want to end up over there. I was trying to tell a story." JACOB: When I gave this talk once, one idea that someone threw out was when you make a PR, mark up your own code first with everything that you want to draw people's attention to. I think you were getting at this as like, "One frustrating thing is when people getting feedback seem to have less invested than you do." They sort of just flying by and dumping on you and they probably, actually couldn't care less and that can be frustrating. When you're engaging with people that maybe don't know how to get deeply involved in it yet or maybe don't have the time to, you can sort of gently nudge them to sort of like, "I want to talk about this part of it." It's almost like you're giving the answers to the test, which was like, "If you want to be part of the smart conversation, comment over here," and I think from the responders perspective, just speaking personally, I would appreciate that. It gives me an opportunity to feel like I'm actually being useful. We can all probably point to times where all the code review we have to do feels like homework that isn't the best use for our time. It's like, maybe the responder can make us feel like our opinions matter and they will be put to good use when you tell them, "If you comment here, it will probably be put to good use." I think the sort of the way to get started is the responder can just say, "I would really like feedback over here," and I can't speak for everybody but I would suspect that more people than you think would be more than happy to be gently guided in what feedback they should get. CHARLES: Right. I'm thinking how you would do this, for example in the context of a demo that you're giving to stakeholders because there's maybe the inkling of the idea to do that but it's often presented as an apology like, "This screen doesn't work," or, "Your handling isn't quite right. Sorry we're going to fix that." Look at the stuff that's over here and maybe, the way to frame that is a really hard problem based on the legacy architecture that we have for displaying errors and I'm not quite sure how to do it in a robust way and I could really use some feedback there. It's an area of exploration or something that we really need to focus on. You put that out there as I'm demoing this main functionality right now. JACOB: Yes. You sort of say like, "Here's something to watch out for and please, let us know what you think," and then after you could say like, "As a team, we thought up these three possible solutions but we didn't want to move on them because we wanted to get your feedback first, so please impart on us what is the right way to do it." You know, flattery goes a long way. TARAS: I have this imagery coming up in my mind as I'm hearing you guys talk about this that I keep seeing this kind of difference between a line and a triangle, where a line is kind of a tug and pull between, "Did I do this right? No, I didn't do this right." I think those are kind of a bad code review because it's very personal. It's not really where you kind of want to go and then the other way is like a triangle where the end goal that you're trying to get to is somewhere that is beyond both places where you let two people: the recipient of the code review and the giver of the feedback, the end goal that you want to get to is actually someplace else. When we deliver the code and we say, "My code is done," then it invites this kind of linear feedback where it's like, "No, you didn't do it right," but in the other way, "This is where I got to so far. Tell me where you think we could take it next. If you don't think we need to change anything, then we're done. We can merge this." JACOB: Yes. The very intelligent Jessica Kerr said recently on another podcast, there's no such thing as done but you can always make it better. I think you're getting at that point. That's a great question, by the way to ask of your responders -- where should we go next? Where do you see this going next? What will make it better? What would make it more robust? What would make us happier six months down the line when we're looking back on this? But I think of it as the firing range. That's the analogy I gave where it was like, "You put a pull request out and you assert that it is done and if no one can find fault with it, then it's done," and I just don't think that that makes sense. I don't think, really most people actually want to work that way. It's maybe not necessarily even healthy but I think everyone can find, at least I hope, a process that invites them to come into the process and share the way they see things. It can hopefully be enriching and just make everyone feel better along the way. TARAS: This sounds to me like the inspiration part of this conversation because one thing I really like about working at Frontside, I'm an to experienced developer but I know that Frontside is dedicated to doing something much greater than I can do as an individual. When I ask, "What do you think about this?" then I know the feedback is going to be because there something always that is just beyond the reach that could be a little bit better than what we have right now and it's not until I can actually get the feedback from Charles, from Jeffrey and hear, "What do you guys think? Is this it?" and they're like, "What about this?" and I know that the next step is going to be a little bit or maybe even a lot better than what I have right now. I think that's the part that inspires me. I know I have actually gone a little bit further beyond my personal ability to get us to that vision of like this being much better than we could do as individuals. JACOB: Yes and as opposed, "Oh, I screw it up and now, I have to fix it." The framework of find all the errors that I made, even though there may be errors. Let's be honest, there could be things that would be really bad, that would be a security problem but for a growth mindset, to think about it, it's like, "This is a way to make it better." CHARLES: One of the things that you can do to help that is try and find inside every change, try and see the potential that hasn't yet been realized but is enabled by this change, like what exciting paths does this change unlock in your mind, right? And then you can share that. That's a great way to 'inspiration is infectious,' so if you can find inspiration to change, then you might be able to share that with the creators. If something is very personally exciting to you when you see something, maybe spend a little time searching for what you find to be exciting about it. JACOB: Yeah, nice. That's great. CHARLES: Yeah, we might have touched on that. I just bring that up because so often, I'll see the changes that people on my team are submitting and sometimes, it can feel like a cloud burst of like, "We could do this or we could do this or we could do this," and it's great to get excited. JACOB: Yeah. I can share -- recently, there was an example. My coworker opened a pull request and it unlocked something for me where I said like, "You know what? This is making me think about this other thing that I've always hated doing with our legacy codebase. We should do that thing you're doing more because boy, would it make life easier?" and I wonder if it would be worth the time in refactoring X, Y, Z because then I would never ask you A, B, C again and I would be so much happier. TARAS: It makes me think that we need to revisit our pull request template like what would that like? What would be the sections on a pull request template that would facilitate this kind of way? CHARLES: I don't know. I know we're almost a time but before we even get into that, this is a question I have because we talk about pull requests templates, how do you match the amount of process with the scope of the change? Because it's probably a little bit heavy weight if I want to fix a typo and say, "Now we're going to have the creators lay out their case that they're going to ask questions of the reviewers and then the reviewers are going to ask questions and once everybody's been able to write down things that they observe the questions that they have, completely and totally divorced from opinion, now we can talk about opinion that is welcomed." If you're capitalizing one letter, that's probably a little bit heavy weight but on the flip side, it's probably absolutely warranted if it's a major feature that's going to be affecting a huge portions of your revenue stream and so, this is one of the problems I have with pull requests templates is they are one-size, fits-all. Sometimes, a pull request template feels like it's supporting you and sometimes, it feels like the epitome of busy work and I have to spend all this time deleting the sections for the pull requests template. I wish there were ways you could choose different pull requests templates. Maybe, there are. JACOB: So do I. CHARLES: That's a little bit of a quibble that I have is the amount of ritual and ceremony that you have to go through is fixed with a pull request template but it seems like you want to match the amount of process to the scope of the change. JACOB: Yeah, you do and the flipside is also joy. You don't want to give someone too little homework when you really needed the same work. Maybe there's a way to say, when a pull request is opened, the person who opened it or the manager or maybe someone else, has the option to sort of tag the pull request as saying, "This is going to be a bigger conversation. We cannot merge it until we have a face-to-face conversation first with these various stakeholders." Maybe, one of the questions, the first form that everyone gets for every PR gets is what level of PR is this? Is this a quick change? And what people that you just need some quick feedback on? Or is this the long form that you need where there needs to be a sit down with these people? TARAS: Actually, I was thinking what's the adjustment that could be made for pull request is to say, "Here's what a complete pull request looks like. You can opt into whatever section you want," so you decide based on your pull request, what the actual sections of this template are appropriate but then someone can, on the flip side say, "Look, I would really like to learn about the motivations of this pull request. Can you add motivation section?" and understand that from your pull requests. JACOB: Absolutely. You filled out Section A, please answer Section B and C. Yeah, cool. TARAS: Yeah. Because I think what part of the challenge is that we have people look to us, especially people who have a lot of experience, or developers look to us to know what is the right thing to do sometimes or often and I think it's helpful to be a little bit more gentle and saying, "You can decide what is the right amount of detail to set the right conditions for this code review but I will give you some directions for what are things you can consider in including. JACOB: Absolutely. CHARLES: All right. We're a little bit over time, so we should probably go ahead and wrap it up. You are absolutely right, Jacob. This is a topic that keeps on giving. We didn't really move much beyond the pull request and feedback and stuff but we moved a lot around within that topic because it's a big one. Jacob, is there anything that we should mention? Any upcoming talks, meetups? JACOB: No, I have a one-year old and it's all about work and family in this part of the life, so I have nothing to speak of at this point. You can come find me on Twitter as JStoebel. CHARLES: Okay, awesome. Well, thank you so much, Jacob for coming and talking to us. This is a very rich topic. We only really scratched the surface. That's it for our episode today and we'll see you next time. Thank you for listening. If you or someone you know has something to say about building user interfaces that simply must be heard, please get in touch with us. We can be found on Twitter at @TheFrontside or over just plain old email at Contact@Frontside.io Thanks and see you next time.

Here it is, folks! The first episode of our newly rebranded "Frontside Platform Podcast". In this episode, we talk about why platform? What is going to come out of these conversations over time? Our goal is to get people thinking on the platform level which includes tooling, internalization, state management, routing, upgrade, and the data layer. We also want to get people thinking categorically, rather than in the moment: Planning strategically Recognizing and knowing obstacles - matching Don't want the framework, but still have the problems Virtue is a weakness in different contexts Laziness is a virtue but also a weakness Not a question of can Shared problem Please join us in these conversations! If you or someone you know would be a perfect guest, please get in touch with us at contact@frontside.io. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.

Special Guest: Kris Van Houten: @krivaten | krivaten.com In this episode, we are joined by Kris Van Houten to chat about Functional CSS and Styled Components: pros and cons, the problems that they are trying to solve, and how to choose between one or the other. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: DAVID: Hello, everyone. Welcome to Episode 116 of The Frontside Podcast. I'm David Keathley, a software developer here at Frontside and I'll be your host for today's episode. Joining me as a co-host is Jeffrey Cherewaty. JEFFREY:: Hey, there. DAVID: And we've got an amazing guest with us today, Kris Van Houten. Kris is the author of a very interesting functional CSS library called Elassus, a good friend of mine and today, we're going to be talking about how that compares with another new pattern I've been seeing everywhere recently: styled-components. Hi Kris. KRIS: Hey, how's it going? DAVID: Doing great. Let's just go ahead and jump into things. Kris, you want to give us a little introduction to your functional CSS library? KRIS: Yeah, for sure. I guess, first of all about me. I've been primarily a frontend developer for about seven or eight years now. I don't know, at some point you start losing count but over the years, I worked largely within the Ember framework but I've also worked within React and Vue. Like most of developers over the years, you tend to require an affinity towards certain areas of software development and for me, those areas tend to lean towards accessibility but also, learning how to write CSS with what I call like the future in mind. To try to keep the story as short as possible but a couple of years ago, I was working on a project and started to realize that our CSS is one of those things that just continues to grow over time along with the rest of our application but I also noticed that we tend to have a lot of areas of repetition within our CSS, like how many times are we setting text align to center, how many times are we setting the text color to the primary color or to gray or something of that nature and maybe we could create a utility library that just does all the stuff for us, similar to if you've ever worked with Bootstrap that they had utility classes that allow you to do some things like set the text alignment or the text color or font size and things of that nature. I started thinking around it but eventually, I changed jobs and that idea kind of just went to the side but then, I'd say about a year and a half or two years ago, I came across a blog post called '15kb of CSS is all you'll ever need' and so, immediately I was intrigued. It was actually a blog post on Medium that was talking about the benefits of using something like Tachyons or base CSS, which are two different functional CSS libraries. To explain what I mean by functional CSS, it's just a whole library, a whole arsenal of these utility classes that just do one or two things that allow you to basically take any design and implement it by composing all these classes together throughout your HTML. I was looking at Tachyons, looking at base CSS and thinking, there's a couple of things I like to customize about this but at the time, when I was looking at it, I couldn't really figure out how to customize those values very easily and so, I did every developer does and just decided to make my own and that's where Elassus came into play, where it's a CSS library that is entirely made up of functions that generate your CSS based off of the value of variables in Sass. Everything is customizable, all the way down to how the class names look and the syntax that you use. If you hate what I'm doing, you can customize it very easily. A lot of people might wonder why would you want to use functional CSS, what are the benefits that you get out of it and really, one of the first two things that comes to mind for me that really attracted me to it was that your CSS files start small and they stay small. For the most part, depending on the configuration and the particular library that you're using, your entire CSS payload can be anywhere from 10 to 20 kilobytes, minified and gzipped, which is in stark contrast to some other projects I've worked on, where just one of the many CSS files you're downloading are 745 kilobytes. Dramatic improvements there, so that's why it was instantly appealing to me. But one of the other nice things you kind of get for free by default is a consistent design pattern, right out of the box. Because if you're working on a large team that has maybe multiple designers and many developers, one designer might implement something with the spacing system that's maybe based on five pixels: your padding, your margins, your widths, might be five, 10, 15, 30 pixels, 45 pixels but then maybe, another designer is implementing something based off of more material design, which is base-4 pixels, so it's like four pixels, eight pixels, 16 and so on. Over time, little differences like this can really show up as you navigate between pages of your application and with functional CSS, you're given a limited number of options to choose from. As a result, it actually makes your application feel like it's one cohesive consistent piece of software between pages and between the features that you're navigating through. Those are really two areas that have really attracted me to functional CSS and I guess, is a tl;dr -- if that was a tl;dr in fact -- of what functional CSS is and why I like it. DAVID: One of the things we've got here was the problem that functional CSS and styled-components are both trying to solve. KRIS: Like I said earlier, a lot of the applications that many of us might be working on, they tend to grow at time by either adding features or rewriting and improving existing feature. In JavaScript, over the years, we have made tremendous improvements in our tooling with things like code splitting and tree shaking to really limit and minimize the amount of payload that we're sending to our users at the end of the day. But really, it's only up until recently we hadn't really been talking about how we do that for CSS and typically, as developers, we had deadlines, we're working with them in sprints, we had a real strict time constraints on what we can work on and for how long and so, we tend to focus on making sure the features look right, they work right, and that our test passed. In CSS cleanup is just one of those things that often doesn't get cleaned up as often as you would like. Sometimes, that's also because we assume that a particular set of styles is probably getting used by another team, working on a completely different part of the application. As a result of just not being able to work on this problem or this issue, we likely have many, many kilobytes of orphan styles being shipped to our users at the end of day and our style sheets tend to grow over time. If there's one thing that's kind of become a mantra within software development over the last few years, it's that every kilobyte matters. One of the main reasons I wanted to come and talk to guys today was about some things that I've been tinkering with on the side, just to figure out how we solve this problem and so, their approach of using functional CSS is one of those things but using something like styled-components, which is mostly used in React library of the solution of writing your CSS in your JavaScript and that's another approach to how to tackle this problem. DAVID: That's an interesting thing you said there. I remember, whenever I started off in software development, one of the big no-nos for styling is don't put your styles in your JavaScript. It's interesting to see that that has kind of changed. KRIS: Yeah, indeed. I remember listening to a podcast about two, maybe three years ago and they had a panel on and they were talking about there's a new thing called CSS and JS and I was like screaming in my car like, "This is the most horrible thing in the world you could possibly do. Why would someone want to do this?" and obviously over the last couple few years, the technology has definitely matured and they definitely hardened it, to where when I was working on updating my personal blog, working on moving over to Gatsby, I didn't want to have to pull an entire functional CSS library because I kind of thought that would be overkill for just a couple small pages and so I was like, "Let me try this whole styled-component thing. That way if I'm going to hate it, I can hate it from the experience point of view." I actually found that the developer experience of working with styled-components was really nice and so, I kind of became converted over to that way of thinking about, "I'm not a hater. It's actually a really nice way to write your CSS for your blog or your applications." JEFFREY:: I count myself still as a skeptic about this whole idea, so I'm excited that we're going to talk about it now and then, you have the opportunity to sell me on it, which should be fun. Some of the work I've been doing on lately, we've been doubling down on the idea of CSS modules, that at least fix some of the encapsulation and problems around CSS where everything is sending up in a global scope. How do these ideas of functional CSS kind of take that even farther? What advantages are there over using, just simply using say, CSS modules where we're fixing the global namespace. KRIS: I'd say with functional CSS, again the things that kind of mine for me are you keep the file size small, you have your design patterns that you can get for free right out of the box. Your styles are pretty low specificity, meaning that if you ever have a need to where you get a really customized something because you just can't do a functional CSS, which I found to be very, very few and far between as far as the number and instances I've come across, it's very easy to overwrite if you need to go back into, I guess old fashioned way of actually writing some CSS yourself. But then you also have the benefit of not having to come up with clever class names to describe the different states or different use cases of your component that you're working on or the future that you're trying to implement and so, I'd say those are definitely some of the pros of why I like using functional CSS at the end of the day. I will say that there are some cons -- I'll be completely honest -- and say that one of the areas where functional CSS tends to have a weak spot is in the area of browser specific issues. In my experience, I tend to have a lot of issues with iOS Safari and it's like the bane in my system sometimes. Sometimes, worse than i11 but if you have to really target something that's exclusively for a specific browser, that's really not doable from what I've seen in functional CSS. That's where we should have to go back in and handwrite some CSS for that kind of situation. But also, one of the cons is that sometimes, depending on the element or the component you're trying to style, I think the example is if you have a nav bar that can toggle between being a sidebar but also a top nav bar, that's a completely different set of styles and to achieve those few layouts at the end the day, you have to have a completely different collection of class names that you have to toggle between based off of the state of that component or that feature that you're working on. While that's doable, especially with something like a frontend framework like Vue, React or Ember, it's just a little pain point that sometimes you have to work around but I say, those are the pros and admittedly some of the cons of using something like functional CSS to tackle your styling needs. JEFFREY:: My favorite thing that you mentioned there was how hard naming is. I think everyone can agree, very strong of it, just naming things is the hardest thing. What has been your experience in learning these? They're almost new domain languages for like we want to padding of this amount. Have you found that pretty easy to get up to speed and get fluent in or have you run into some blocks in kind of learning these new languages that some of these CSS tools have presented. KRIS: That's a really good question. When I first started digging into Tachyons -- that was the first functional CSS library I started working with -- there is definitely, I'd say a small learning curve of maybe, I was trying to implement it just to see how it worked and it took me, maybe a couple of hours, if that, to kind of get a feel for how they write their classes and how the classes are put together to do certain things. But once you kind of get through that little initial pain point, it's pretty easy. In one of the things that when I was working on my own implementation of it, I wanted to make sure that no matter what you're doing, all the class names are consistent, that the patterns that you use to your class naming is consistent and I guess, because I wrote it, then it wasn't so hard for me but I also understand that that's not the case for everybody. When I wrote Elassus, one of the things I did is I actually was able to create a compiled JSON version of all the CSS and actually, use that to create like a little React search tool. If you're looking for padding or margin, you can just enter that in a search bar and it'll tell you all the options in the classes that are associated with that and that's one thing I did to kind of help with that barrier but it definitely can be a bit of a learning curve but like I said, it's maybe an hour or two of your time to really get familiar with it. JEFFREY:: That is not bad. KRIS: No, not at all. I was actually really surprised at how fast I got up and running with it. DAVID: That actually ties into something that I was kind of curious about myself. Whenever I went through the coding bootcamp that I did a couple years ago, after we finished going over raw CSS and how that works and the basics of that, they introduced us to Bootstrap as our first real CSS library to play with. That was fairly achievable for someone brand new to frontend work in general. What I was curious about is would you see these functional CSS libraries as equally accessible or maybe, more advanced than something like Bootstrap or Foundation. KRIS: I never thought about that before. I think I kind of see it like as the next step. I've worked on several products over the years where Bootstrap was what they started with. As we went on to build out the feature set of the product, we started to find ourselves battling with the various styles that we get at from Bootstrap for free. I think one of the things about working on a website, where actually using Bootstrap is that sometimes you can just kind of tell that it's a Bootstrap based website. I don't know if I'm making any sense to you guys -- DAVID: Oh, yeah. Definitely. KRIS: That was another reason why I wanted to have something... That had basically forced me to decide how my navigation bar looked. It forced me to think more about how my sidebar is looked or what my spacing scale -- it's the term I like to use -- based on what you're using for your pure margins, your paddings or what's your heights, things like that. It make me think about what those values should be and that's how you kind of break out of the box of having everything look like it was built in the same framework. I would say it's more of a next step if you're talking about your experience as a developer. Yeah, learn CSS. I think it's still incredibly valuable to know CSS and for me, like you David, I kind of got started and learned about this thing called Bootstrap and you can quote me. Back in the day, I said, "This is like the jQuery for CSS. It's amazing," but quickly, I kind of ran into some of those issues that I mentioned earlier and kind of force me think about, "Maybe, I don't want to use Bootstrap. Maybe, I want to handle my own thing," and so, I say functional CSS, as far as like again your education level, it's more or less that step of if you think about how do you want to solve certain problems in our design. DAVID: Okay. We've gone over functional CSS with some and styled-components, how would you choose between the two? KRIS: This is actually really hard because I actually like both approaches. I'm not one of those guys that's like, "That one sucks. I don't want to use it." I actually think both have their place and so, I know I kind of sound like the typical 'this versus that' blog post in technology right now but I will say that there's a few questions you should ask yourself and ask your team if you're considering changing up your approach to CSS. One of those is what is the preferred developer experience of your team. That's something we've been talking about a lot at the company. What we mean by that is how enjoyable is it to work in a particular codebase? Do your developers mind writing their CSS, instead of a JavaScript file? Or would they prefer to have something where they can actually read the HTML and build a C, just by looking at the elements in the classes that are being applied there? What this layout looks like or what's being applied to this layout? You know, questions like that can definitely help determine what direction you should go. Again like I said, one thing I love is that both approaches remove the developer's burden from having to come up with clever class names for all the different use cases or states of your components. I think you're going to get a win-win either way there. However, if you're using React, we already have a ton going on in our JSX and so, if adding a series of class names to determine your design tips is overwhelming for you, then maybe give styled-component a try because it can definitely simplify your JSX output a little bit. If the idea of having JS to handle your CSS seems a little fishy, I think one of the cons of using styled-components is that we're asking JavaScript to do yet another thing for us. If you're one of those people who has a problem with that, then give functional CSS a try. There's definitely more than one flavor out there and I've tried out almost all of them and like them. They all have their nice tidbits inside of them. I'll say, if you prefer to have easy theming, if you're working on a project that has to have a lot of theming involved, then I might be more toward styled-components. If design consistency and design patterns is a priority, then maybe functional CSS is an option for you. With both of those scenarios, easy theming in patterns is possible in both. It's just one is harder in one than the other. With styled-components, there are implementations of it in Vue and Ember but they don't seem to be very widely used yet, so I'd say use at your own risk or contribute to open source to make them better. I'd say for right now, if you don't mind being locked into using React, then styled-components is pretty cool. It also allows you to transfer your styled-components from one project to another without having to worry about. [inaudible] all the CSS because that's a big deal but I would ask myself those kind of questions to determine what solution I would choose. JEFFREY:: I am interested in the performance implications of these tools. You touch earlier on by using tools like this, you can definitely shrink your CSS payload by a lot, so what is the actual output of using these tools? What will it look like? Do you end up with still an external CSS file or is it a scenario where you're kind of getting some CSS injected into your markup? KRIS: Yes with one and no on the other. With functional CSS, you typically have a CSS file that is compiled and maybe, you're using Sass to do the operation for you or post-CSS, so you get an output CSS file that you help you fetch on the frontend of your application. Like I said, [inaudible] if these files are between 10 to 20 kilobytes, which is remarkably small. With styled-components, it's a totally different approach. It's a totally different implementation as well, unless you have a normalize or perhaps a reset CSS that you're fetching on the frontend, all the styles are actually -- I guess, I should start with earlier. What happens is you define your styles in your JavaScripts and at runtime, the component will read the styles that you set and then create a unique class for that instance into the head of your document. It's basically a single class use for that component and so, all in all, it gets compiled at runtime. There's no additional CSS files being injected. It's actually being created dynamically in your actual HTML document. One of the things I was first concerned about was what are the performance implications of having JavaScript do this for us and over the last couple of years, as the technology has been maturing, performance has been an issue but I think it was with V4 -- version 4 styled-components that just released, I want to say, in September or October, they have tremendous performance improvements. It's rapidly fast now, so it's not really something you need to be concerned about. I'd say again, it's one of those things: Can you get over the mental hurdle of having JavaScript do one more thing for you? And can you get used to the developer's ergonomic practice of writing CSS inside a JavaScript file? I know it kind of takes a little bit of getting over that because it just seems so strange but you also get a lot of perks by doing that with having easy access to theming, you get to use some of the power of JavaScript to help build out your CSS, which can be nice as well even if it kind of feels weird. JEFFREY:: Yeah, I agree with the ergonomics do feel weird but you'll get some benefits out of doing that. In the styled-components where it'd bring on the fly, I'm happy to kind of figured out the performance like runtime implications with that but it seems to me that now you no longer have a cache CSS and that you're having to get that all the time on the fly. Maybe for some systems, that is okay but that's definitely something that I would miss having -- the idea that CSS actually can be a little heavier because it will always be cached. KRIS: That is totally a valid point. I think one thing I do kind of like about the styled-component approach is that when you delete a component, all the styles go with it, so you no longer have orphaned styles just hanging out there that are getting shipped down to your user. I agree that the caching is definitely a concern but I just kind of start to weigh the pros and cons and again, you have to decide for your product, for your team what works best for you. Also, one of the pros that I would bring up is that you don't have any orphan CSS hanging out in your application anymore, which is definitely one of the key contributors to growing bloat in your files over time. JEFFREY:: That is very nice. KRIS: Yeah. DAVID: That ties into a question that I was kind of wondering. As your projects get larger and larger and more complex, your style sheets tend to grow along with that and one of the issues that you might have as time goes along is visual regressions like styling bugs. How does using functional CSS or styled-components sort of deal with that or prevent that? KRIS: With functional CSS, like I said, you have those patterns kind of built in out of the box. As long as you don't change the value of what a particular class renders out of, maybe someone goes in and without thinking of it, they change the second value of your spacing scale to a lot of pixels just because they felt they needed to. You're not going to have visual regression that happen over time because the whole premise of functional CSS, those values don't change. Those are basically meant to be seen as immutable values, immutable classes. You shouldn't have style regressions that pop up over time as people continue to work on your application. With styled-components you still have that risk unless you are setting all those same values and your theme properties that you can use within styled-components. Unless you're setting all your different spacing values, you have a tendency to potentially run the same issue. But actually, now that I think about it, maybe not because with styled-components, every component is unique. Every components styles are completely unique, so again, unless you're changing those core values of your themes, you should not have visual regression that happen in a totally separate part of your application when you're working on say, the home page. I would say both handle that pretty well, now that I'm thinking of it. DAVID: That's cool. KRIS: This reminds me, I'm working on a particular piece of software at a particular feature of my work and we don't use functional CSS or styled-components yet. I'm trying to get them to move over so again, this is all stuff I do on my free time but I'm working on editing a component and I had to make some pretty drastic changes to it and I was like, "How is this going to break on some other page that I'm not aware of yet," and so, this requires a lot more going back and checking all the various uses of this particular component. We used it in 10 or 11 different places on different pages and so, we have to go back to each and every single one of those use cases to make sure I didn't break something. Whereas if I was using one of these two approaches, it wouldn't be something that I would have to be concerned about. This is what I'm trying to push through on my own job as well. DAVID: Yeah, it really eat up your time. KRIS: Yeah. JEFFREY:: I want to talk for a few minutes about media queries because, I think that the situation is kind of handled. It's definitely something I've run into: CSS variables and with post-CSS tooling. I'm interested in kind of how does the media query story is handled with the setup. KRIS: With functional CSS, you tend to have, basically say, I have a class that sets a margin on the top of 16 pixels, for example. Let's say that that class name is MT-3... I don't know, meaning for like the third position in your spacing scale, 'MT' stands for margin top. If you wanted to only use that style for perhaps, like your medium break point, then different libraries have a different way to approach this, basically, you're 'MT-3--medium' or '--desktop.' It's the additional characters that you append to the class name to target that specific media query. Also, depending on the framework that you're using, you can also target pseudo states, whether or not this element is focused or on hover, maybe you want the background code to change. There's variations of those classes that allow you to target those specific states, which is really nice in functional CSS. Again, just by looking at the classes that you're adding to your DOM, you don't have to scroll through your style sidebar to figure out like what styles are associated with this class name and why it's being overwritten by these 10 other things that we have going on. Again, you can just look at the HTML and see what's happening and what should happen if you hover over an element. With styled-components, you can still use media queries and all that stuff right out of the box. In order to keep your media queries consistent, that way not everybody is having a handroll, at least by every single time that you need to use them. You can actually store your media queries in a separate JS files and it's kind of import them as you need them, which again, kind of feels like a weird developer ergonomic for your CSS but definitely, it comes in handy and definitely keeps your styling consistent the more you break out the various pieces into small pieces or small components like that. That's how to handle things like media queries and things like that. JEFFREY:: It's interesting how these approaches are kind of pushing the web towards, I'm feeling a lot more like native development, where you build your style and your visual look in conjunction with your component code and those things are not really ever separate. I think, there's some interesting influences coming in there from some made up things. KRIS: One thing I think about a lot, especially when I'm thinking about functional CSS is I'm reminded of this image I saw kind of posted on Twitter somewhere in the interwebs. It was a picture of the Super Mario Brothers start screen and the entire Super Mario Brothers video game was something like 23 kilobytes. This screen that you're looking at, which was like the start screen was like 345 kilobytes or something. My numbers are probably off but it was something drastic like that and this makes me think about, if you were to go back through, there's a couple of documentaries about how the loops that developers had to jump through in order to make old video games for Nintendo Entertainment System back in the late-80s -- I'm probably dating myself right now -- but the things they had to go through and to think about in order to make those games work the way they did is insane and I kind of feel like over the last... I don't know, maybe 10 or 15 years, because we've gotten such fast computers and such fast mobile devices and so on and so forth, we've kind of gotten crazy. I look at video games now and they're 100 gigabytes sometimes and I kind of feel like they didn't need to be 100 gigabyte video game and I think -- DAVID: But it's so much cooler because it is. KRIS: I'm not saying it's not cool but I'm think like if they really took the time to pay attention to some of these details, we probably could automate this a little better. Maybe, I'm just being biased but I think about we're kind of starting to do the same thing and talk about the same kind of problems in web development. Again, just because we can have a 745 kilobytes of CSS file and thought the world falling over, it doesn't mean we should, so maybe, let's take into consideration that not everybody is using a cinema display on a super-fast MacBook to view your application, what about the person who's using an outdated Android device that hasn't been updated in three or four years? How's your product going to work on their device? I'm really glad that people actually started to take that kind of thing into consideration and it even reminds me a little bit of another area that I think a lot about is the area of accessibility: how do people with various impairments or disabilities use your software and how can they use your software but also, outside of that, how do people, who maybe don't have the money to have a fancy mobile device like you have, use your product along those same veins. It kind of dips into the same vein of accessibility when we're talking about how do we optimize our products to make them usable by everyone despite their income level or their ability to have a fancy, nice desktop or a latest iPhone. JEFFREY:: Awesome. DAVID: Yeah. Definitely, you think about who are the majority of users on the internet these days and really, it's an emerging market with underpowered devices and the internet is becoming much more and more accessible for people to get on and browse, so you really got to keep those people in mind. KRIS: Definitely, especially if you're creating software that you want people across around the world to be using, a lot of people don't have access to crazy high speed internet like we do here in the States, so we should probably be taking more time to consider what it looks like for those people to use our product. At my company, what we've been talking about is like we should be testing and basically, starting mobile first with all of our development to see how does this work on our mobile device. I'm a remote developer so we're trying to figure out how to get me mobile devices that I can actually test on our VPN but it's something that we're trying to move towards at my company as well. DAVID: Okay, that about wraps up Episode 116, our final episode of 2018. Man, the year has gone by fast. We are the Frontside. We're the frontend specialists who make your largescale application projects run smoothly by helping your team assemble the right tools and implement the right automated processes. We can ensure your projects can move forward on time and without regressions while preserving quality and long term maintainability. If that's something you're interested in, please get in touch with us at @TheFrontside on Twitter or Contact@Frontside.io via email. Do send us any questions you might have, any topics you'd like to hear about in the future. We look forward to hearing from you. Thanks again to the wonderful Mandy Moore for producing today's podcast. You can find her on Twitter at @RubyRep and that's it.

In this internal episode, Charles and Wil talk about testing issues and BigTest solutions. Pieces of the testing story are discussed, such as the start and launch application, component setup and teardown, interacting with the application and component, convergent assertions, and network. Then they talk about testing issues: the fact that cross browser and device-simulated browsers are not good enough, maintainability and when and when not to DRY (RYE), slowness and why (acceptance) testing is slow, portability and why tests are coupled to the framework, and reliability. Finally, they talk about BigTest solutions: @bigtest/cli to start / launch (Karma recommended for now) @bigtest/react, @bigtest/vue, etc for setup & teardown @bigtest/interactor for interactions @bigtest/convergence for assertions @bigtest/network in the future (Mirage recommended for now) Resources: Justin Searls – Please don't mock me This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 115. My name is Charles Lowell, this episode's host and a developer here at the Frontside. With me today to talk some shop is Mr Wil Wilsman. WIL: Hello. CHARLES: Hello, Wil. WIL: How's it going? CHARLES: It's going good. I'm actually pretty excited to get to jump into this topic because we're going to be talking about some of the big things that are happening at Frontside and some of the things that we've been developing in almost for the last year. WIL: Yeah. It's been about a year now. CHARLES: It's been about a year and we've talked about it in various podcast but we're going to be talking about it again because there's just been so much progress that we've made, I think in a lot of clarity in kind of what we're going for here when we talk about BigTest and testing big and how we want to roll out the BigTest framework. We just have a lot more experience using it on a number of different projects, so we get to talk about that today. Before we get started, I just wanted to talk a little bit about what BigTest is, both in terms of the framework and also the philosophy. Wil, you're the one who works the most on BigTest. When you think about philosophically, what does BigTest mean to you? WIL: It's the size of your test, not a physical size like size and storage but how much your task actually does. The test itself can be very small as our test are but it tests the whole application from the user interacting with it down to the network requests. That's the definition of the philosophy of a BigTest to me. It's to tests your application from the biggest point of view. CHARLES: Actually, achieving that can be surprisingly difficult, especially in a frontend JavaScript application and there are a lot of solutions out there for testing and we've talked about them. One of the questions that arises is when we talk about BigTest, what exactly are we talking about? Are we talking about a product that you can download and install? Are we talking about the philosophy that you just outlined? Or are we talking about the individual pieces of software that make that philosophy real? I think the answer is we're kind of talking about all three but we want to take this episode to talk about where we're going with the product. What we've identified is the subcomponent pieces of that product. In other words, in order to get started testing big, what are the things that you need to think about? What are the things that you need to do? And then what are the component pieces? Because one of the things that I think is very important to us is that you be able to arrive at wherever you are in your project, whatever framework you are using, whatever current testing solution and be able to begin using BigTest. That means, you might be using some of it or you might be using a lot of it but we want to meet you exactly where you are, so that you can then, get onboarded and start testing big. WIL: Yeah. Definitely an important distinction that we get confusion about is what is BigTests and people just assume like this whole test suite is BigTest but we used the parts of it ourselves like we use Mocha, which is not part of BigTest. We use Chai, which is not part of BigTest. We use Mirage which is kind of part of BigTest but definitely it originate in BigTest and Karma and things like that. BigTest isn't your testing suite. It's not one thing to go-to to grab, to start writing tests. It is a small pieces that you can use in conjunction with other small pieces, just to make it really easy and flexible to test your application. CHARLES: Exactly. Because it turns out that there's a lot going on in the application. Maybe we should talk about what some of those pieces are that you might want to start using BigTest with or that you might need to test big, I guess I should say. What's a good place to start? Let's start with talking about some of the issues that you want to do when your testing big. Then we can talk about what pieces of the testing story that fit in to solve those issues. One of them is you need to test that your application works, like actually works. That means you need to be able to test on a multiplicity of browsers, for example. We're limiting to the domain of web applications. There are actually a shockingly large number of browsers. It's not just Chrome. It's not just Safari. There's Mobile Chrome, Mobile Safari, which are subtly different. There's Edge and I'm sure the Mobile Edge is slightly different too, so you want to be able to test cross browser, right? WIL: Yeah, absolutely and things like Nightmare and JS DOM and things that simulated browsers, we don't necessarily think those are the best tools for writing BigTest because we want to ensure that those browser quirks are caught and tested as well. CHARLES: This is not theoretical like sometimes you'll have a syntax, like the parser is slightly different and you have something that throws a syntax error in Safari or in the Internet Explorer and your whole app is completely busted. If you just take in the time, just even trying to load the app in that browser, you would have caught that. That's what I've been on many times. WIL: Yeah and what I just saw came up yesterday, which comes up frequently is not closing your CSS Selector and Chrome doesn't really care like web to browsers don't care too much but that will fail in Edge and depending on what you're missing, the failing is part of that too but mostly, Firefox and Chrome don't care about that kind of thing. CHARLES: Right. It seems like the majority of testing solutions are kind of focused around Headless Chrome or some variation of Electron. That entire class of really dumb errors has already been caught. Like I said, to actually catch it, it takes less than a millisecond of CPU time just to load it onto the browser and see that thing doesn't work. Unfortunately, they can be catastrophic errors but the problem is how do you actually do. We want to test like cross browser. This is something that we want to do. For me, I just can't imagine shipping an application without having some form of cross browser testing, some capability of being able to say, "I want to test it," like, "We want to work on these eight browsers and so we're going to test it on these eight browsers," but how do you actually go about doing that? WIL: Right now, we are working on the BigTest CLI which will help us launch browsers but that's not complete yet. It has some bugs on. For the meantime we've been using Karma, which is great. Basically, you just have this service that's able to find the browser binary on the system and just launch them pointing to local hosts with your app loaded up and your normal development server take care of loading the test up and running the test. Karma and the BigTest CLI is just there to capture output and launch those separate browsers. CHARLES: Yeah. I remember when I was first using working with Karma and I think Testim is another tool that's in this space. There's Testim, Karma and BigTest actually is we're developing a launcher because launching is something that you're going to need but it's such a weird problem. I feel like with the browser launchers, there's three levels of inversion of control because you're starting a server that then starts another process, which then calls back to your server, which then loads the app resources, which then loads the tests and then runs the test. There's a lot of sleight of hand that has to happen and – WIL: Including injecting the adapter that you use, like the Mocha adapter, the Jasmine adapter that ends up reporting back to the CLI. That's something that Karma and Testim and BigTest will handle for you. CHARLES: Right, so you're fanning out the test suite to a suite of browsers then collecting the results but basically, you need some sort of agent living inside the browser that's going to act on behalf of the test suite, to collect the results. I remember when I first came into contact with Karma and Testim, I was like, "This is so unnecessarily complex," but then, having used it for a while and I think there are some complexity that can be removed but if you want to do cross browser testing, that kind of level of ping-ponging is there's a certain amount of it that just necessary. It's something that's actually quite complex that you need to have in your stack, in your toolbox, if you want to truly test big. WIL: Yeah and all the solutions is mechanisms for detecting when the browser has launched and restarting the browser based on its health check, etcetera and things like that that you wouldn't think of actually loading up a browser but you need to think of when you're doing automated testing. CHARLES: What is it that sets apart, for example the launcher solution? We kind of call this class of solutions launchers, so Testim, Karma, the BigTest CLI. What is it that sets BigTest CLI apart from say, Karma and Testim? WIL: We're trying to be as minimal config as possible and just really easy to get started and going. Karma has a lot of plugins that you need to make sure you have installed and loaded in the options set for those plugins. Testim has some stuff bundled but it still requires this big config bulk at the beginning that you need to passing or that's all what you were doing. We're trying to avoid that with BigTest CLI and one of the ways that we're able to avoid that is by just letting your Bundler handle bunding the test. In Karma, you need Karma webpack or something. Testim has some stuff that it needs and really, we just want like in-testing mode. When you're in the testing environment, just change your index to point your tests, instead of your application and your Bundler will do all the work and we just serve that file and collect the results. CHARLES: Right, so it doesn't matter if you're using Parcel or you're using webpack or you're using Ember CI. WIL: Yeah, Rollup even. CHARLES: Or even just like low level Broccoli or Gulp or whatever. There's a preponderance of bundling solutions and that was always something that was just a huge pain in the butt with Karma. I know it's like just getting to the point where my tests are loaded and you look with Testim, most of my experience come with Testim comes through how it's used in Ember CLI like the histrionics that undertaken just to bundle all your tests assets and your application assets and your vendor assets and just kind of bootstrap that thing. It's a lot of work. WIL: Another thing with BigTest CLI that doesn't include in Karma and Testim does is a concept of a watcher because all these Bundlers, you have HMR -- hot module reloading, Rollup and things like that. It come with plenty of plugins. Parcel is always set out of the box, so if you're using your Bundler, your existing Bundler to bundle your test, you get that watch feature for free, so it's another complexity that the BigTest CLI kind of eliminates. CHARLES: What it means is we've hidden most of that complexity. Just let the Bundler handle it, right? The Bundler is the part of your project that bundles. WIL: Yeah. CHARLES: You should have your launcher actually doing that for you but we still do need to have some way to do that set up and tear down. When we have that testing endpoint, we have some way to say, "We're starting a test, not the application. We're ending the test, tear it down," so how do you abstract that away? WIL: That's kind of something that we can't really avoid. It is just like some sort of dependency on the framework itself, your application framework. It's like you need to mount a React app. You need to mount an Ember app, etcetera and there's different ways to mount those things. This is one of the things that can't really be decoupled as much as everything else can but BigTest has BigTest React and BigTest Vue and we want to eventually gets like BigTest Ember but really, the main export of all these packages is just a simple mount helper that will mount and clean up your application for you and your testing hooks, whether you're using before each from Mocha or before from something else like Jasmine. You know, no matter what you're doing, you just have a hook that mounts your application and then, cleans it up on the next mount. CHARLES: It's worth pointing out here that this is kind of a core concern of testing and testing big is being able to mount your application and tear it down with regularity and having hooks into that process. Whether you're using BigTest or whether you're not, can you still use BigTest React and BigTest Vue, even if you weren't using anything else? WIL: Yeah, absolutely. Like I said, they just export simple mount helpers. I don't even think they have any other inner BigTest dependencies. They just have pure dependencies on their frameworks. CHARLES: Right and so, you could use it, even if you wanted to roll everything else by hand or you wanted to get started somehow and you needed to do set up and tear down, again this is something that's key to being able to test big, so you should be able to use it independently, whether you use the CLI or not, whether you're using any of the other tools or not. All of the tools can be used independently. WIL: Then another feature of the BigTest React and BigTest Vue is the tear down that happens before set up, rather than happening after your test runs, having a separate tear down. This allows it. Whether your test passes or fails, you can look at it and play with it and inspect it and debug it much easier than if you had tear down. You have to disable at tear down or throw a pause in there to keep other or something. CHARLES: Yeah, I love that. When something goes wrong, you can just let the test case run and the last test that it runs, it just leaves at set up. It does the tear down right before the set up. WIL: Exactly, yeah. At the very end of the whole test run, there's an app there waiting for you to play with. CHARLES: If you focus in on a single test, we most commonly use Mocha, so you say a '.only' to run that single focus test, then you have the state of the application at that test case set up and ready to go. You can just play with it, you can inspect it, you can actually just use it as a starting off point and interact with the app normally as you would. WIL: I want to say, Cypress does this too. They do their tear down before they're set up as well. That's how you're able to play with Cypress test. CHARLES: Yeah, I like that trick. Now, we talked about launching, setup and tear down but we haven't actually talked about much of what actually happens in the test cases themselves. We talked about how to start and launch your test suite, how to do that across a bunch of different browsers, how inside of that, you have a separate concern as applications set up and tear down and how you want to lean on how you're actual app is actually bundled because that fits in with the philosophy of testing big. You don't want to use an external Bundler for your test suite. You want to use your real Bundler, how the asset is actually going to look. But when it comes down to actually writing the tests, you need to be able to interact with at the highest level as you possibly can. When I say highest level, we want to verify that the users, when they take certain actions, we'll see certain outcomes and so, we want those outcomes and we already talked about this to be reflected in a real DOM, in a real browser. But at the same time, the real interactions, we want those to be as high fidelity as possible, so you want to be sending events to the browser. You want real mount events, real key events, real interactions. WIL: Yeah, interacting with application. That's another core philosophy that we kind of talked about earlier that defines a BigTest. It's the user interacting with your application. We're not calling methods and expecting other callbacks or arguments to be passed or clicking on a button and expecting a message to pop up that says, "Form submitted successfully." These are user-facing things were starting on and acting on. CHARLES: Yeah and then, it can be really tricky because these things don't happen synchronously. They're happening inside of your browser's event loop. I click that button and then it goes off and there's some loading state and then, I might get an error message that pops up this thing that animates out and then, goes away. The state of the browser is in constant flux. It's constantly changing and so, it can be very difficult to put your finger and say, I want to be in this state if you are limiting yourself to only reading from the DOM. Some frameworks, Ember for example, you have kind of a white box where you can actually inspect the state of the Ember run loop and use that to do some synchronization but it can be very, very hard to coordinate these interactions. WIL: Yeah. You know, to talk about getting to the solution as a BigTest interactor, which is basically modern page components or page objects. If you ever heard of page objects, it's just a way to encapsulate interacting with big pieces of your pages. It's not a new concept. It's been around for a while but BigTest interactor has kind of a new twist on it where they're immutable, composable interactions that are also convergent, which we'll get into later, which basically means if your buttons not there, it won't click the button until it is there. They're really powerful and they're making really easy and fun to write these tests. CHARLES: Yeah, they're super powerful. I remember we talked about convergences last time when we talked about BigTest but interactors, I think are definitely a new development. I think we should spend a little bit of time there talking about, not just the power but also the ergonomics of interactors because they are like page components or page objects, except they're scope to the component. Not only do they have all this wonderful stuff where it'll make sure that the component exists before it starts to interact with it and things like that but their composable. If I have a button, then there are certain operations that are valid for that button. I can click it. I can hover over it. I can do all these things. They're the operations that make it unique to the button. Now, those might actually map to real events. WIL: Similarly, their assertions about that button as well, like as primary is secondary. If this button is repeated throughout your application, you might want to make sure that your form has a primary and secondary button. CHARLES: Exactly. It really encapsulates all the knowledge of how you can interact with both in terms of taking action and reading state from that button. It almost feels like an accessibility API. It would be easy to write a screen reader if you had these interactors for every single component on the page. WIL: That's kind of what it is. It's just like you're defining an API around how your user would interact with your application and what your user would expect in the application. That's the point of page objects and interactors as you're defining this user API, essentially. CHARLES: Yeah and so, really the step that interactor take is that they take the classic page object and it make them composable, so I can have, you kind of touched on this before, a modal dialogue interactor, which is composed out of two button interactors. One for the primary action, one for the secondary action and maybe, it's aware of its own title text, so you can assert on the title text but I didn't actually have to write the individual button interactors for that modal dialog interactor. Then I might have a second modal dialog interactor or a form that's on a modal dialog just composed of the modal dialog interactors and the individual form components, which appear on that particular modal dialog. WIL: It's essentially how we've been building applications lately with components but this is for page objects in your test if you want to mirror that. You don't have to have one-to-one mappings of an interactor to a component but if you do, it's really powerful. CHARLES: Yeah. I found that when we have one-to-one interactors, that's when it just feels the best. WIL: Yeah and on top of this, if you have a component library and your component library exports the interactor that it uses for the component test, like we said, this BigTest technology, they're sprinkled also. We don't have to use interactors in big acceptance tests. We can use them for smaller component tests too, so if we ship these component interactors with the component library, your application that's consuming this component library now can test those components for free, without having to write their own interactors. It can just compose the interactors exported by the library. CHARLES: Man, I almost want you to repeat that word for word again, just so it can sink in. It's so awesome. Because when you actually go to write your tests, you're not starting from ground zero like, "How do I do this?" They're like, "I'm writing some tests for this thing and I'm using these components and so, I've already got the prepackaged interactions for those components." It's like you start writing your tests. If your tests are a 10-story building, it's like you're starting on Floor 7 and you only have to walk up to Floor 10, instead of slogging up all 10 stories. WIL: One really helpful interactor that we work within the open source stuff we've been working on is a date-picker interactor because date-pickers can be really complex. Just having that common interactor and have a date-picker on multiple forms where we can just use that one interactor, we don't have to tell every single test how to interact with that date-picker. We just say pick date and pass the date. CHARLES: Yeah, it's so awesome. That is actually a great example. It doesn't feel scary to write a test for a page that has a date-picker on it or two. If you're doing like a date range or something like that, you're like, "Oh, my God. I don't write the selectors to test this." You just import your date-picker interactor, you set the date, it actually worries about all the low level events and there you go. It feels like you're operating at a much higher level. WIL: Yeah. The interactor API essentially, you're telling me the test what the user would be doing and what the user would be seeing. CHARLES: Yeah. It's worth pointing out again. We've identified starting and launching. We've identified set up and tear down but interaction is a core concern of BigTesting, no matter what tool you're using. One of the things that we found as interactors are something that you can sprinkle on literally any test suite if you're testing an interface and it makes it better. We've used it inside big acceptance tests. We use it inside Jest, doing just little component tests. There are people in the BigTest community who have used it to basically, write component tests against a JS DOM and while theoretically, philosophically, you want to make those tests as big as you possibly can, you can use that piece in your test suite. If you are using a simulated DOM and if you're running a node in a browser, these interactors will still work and you're going to get high fidelity test cases that are resilient to this asynchrony and are composable and if they do have a full-fledged test suite, you can reuse these interactors. They are a really awesome power up that you can bring into your test suite. WIL: And they are not tied to the framework at all. We use them in React for our stuff but we've also written some in Ember. Robert's written some in the Vue and ported some test and one of the beautiful things we've seen from this is that one interactor goes everywhere. You just write the interactor once and you can use it in Ember, in React, in Vue, in those test suites. If the rest of your test suite is framework agnostic, you have this test suite that you can jump frameworks in your test suites until it works and can test your application with high fidelity. CHARLES: Yeah, it's fantastic. I remember when we first tried using interactors inside an Ember test suite because Ember comes with like a big kitchen sink in testing set up but interactors just slotted right in and there's absolutely no issue. WIL: Yeah and there is actually a speed boost even because in most of the Ember test offers a hook into the Ember run loop and interactors are not. There is actually a good speed boos just using interactors. CHARLES: Yeah. This is a good point. It's a good segue because typically, we think of acceptance tests as being really slow and one of the reasons, even the people [inaudible] acceptance tests or testing big as they think like it's going to take a long time. We found that actually we've been able to maintain a happy medium of testing big but also, having those test be really, really fast. When you say you said a speed boost from using interactors with Ember, where is that speed boost actually come from? WIL: I mentioned the Ember test offers a hook into the Ember run loop and interactors aren't and the reason of this is because interactors are converging and they wait for things in the DOM to exist before interacting with them. Instead of waiting for the framework to settle, it just waits for the thing to appear and then interacts with it immediately. If you're starting something about a button toward the top of the page, you don't really care that another button at the bottom of the page has rendered yet, unless of course you have assertion about that but if they're converging, you don't need to hook into the wrong loop to wait for the entire page to load, to interact with just one piece of it. CHARLES: Right. You're just waiting and you say, "I'm expecting something to happen and the moment I detect it, no matter what else is going on, the page could be taking 30 seconds to load but if that button appears and I can interact with it, I can take my action then or I can make my assertion then." It's about kind of removing gates -- artificial gates. WIL: Yeah. Another common thing that's helped with is animations as most test that are hooked into the run loop, you kind of have to wait for some of these animations to finish before you can even interact with the element and that means if a model has a half second animation where it flies in and you have 30 tests around this modal, those tests are extremely slow now because you have to wait for that modal to come in, whereas -- CHARLES: -- Straight up flaky. WIL: Yeah, straight up flaky. Whereas in the actual DOM, that modal is inserted pretty immediately and can be interacted with pretty immediately. With interactors, they don't need to wait for the animation to finish. They can just immediately interact with that modal but of course, if you need to wait for the animation to finish, there are options for that as well. CHARLES: Yeah. If there's some fade in that needs to happen, you can kind of assert on any state and as long as it's achieved at some point, the interactor will recognize it and recognize it at the soonest possible time that it possibly could. I remember getting bitten on one project where the modal animations in particular were so brutal. Not only were they flaky, they just were slow because there was all these manual time outs. It wasn't even a paper cut. It was kind of like a knife cut, like there's someone sitting there and kind of slashing you with a pocket knife. It just was a constant source of pain in your side. WIL: Yeah and that's how you end up with things like waits and sleeps in your test suite. When you need to wait for the animation to happen or something, you just see a sleep for four seconds with a comment because we have to wait for the components to load in. That's kind of a code now. CHARLES: Yeah, that's just asking for trouble both in terms of slowness and in terms of it's going to get flaky again. That has been kind of one the most freeing things about working with interactors and working with convergent assertions on which they're based is you just don't ever have to worry about asynchrony. Really, really truly, most of the time, you're writing your tests, like it's all synchronous and that kind of makes sense because from the user's perspective, their consciousness is synchronous and they don't care about the internal run loop. It's just they were making observations in serial and at some point, they're going to observe something, so the interactor sits at that point and really observes the application the way that your user would. WIL: Yeah. We've mentioned a few times now the convergent assertions, which interactors are based on. A little caveat there if you're using interactors and you're making non-convergent assertions, they might fail or be flaky. That's because interactors wait for the thing to be there to interact with, so as soon as the buttons there, it clicks it but it doesn't wait for after that event has fired and your application has reacted to that event, that's your application is concerned. We need something there like our convergent assertions that can converge on that state and wait for that state to be true before it considers itself passing or in times out. CHARLES: Maybe we should dig a little bit into convergent assertions. I think the last time we had a public conversation on the podcast about this, this is kind of where we were, like we hadn't built the interactors, we hadn't built these other component pieces of the testing story. We were really focused on the convergent assertion. We've talked a little bit about this but I think it's worth rehashing a little bit because it's a unique way of approaching the system but it's also kind of horrifying when you see how it works under the covers. I think when we tell people about the fact that it's basically polling underneath the covers. The timeout is configurable but it's basically polling every 10 milliseconds to observe a state. I remember the first time being confronted with this idea and I was horrified and like my programmer hackles on the back of my neck, like raised up and I was like, "Wait a minute. This is going to be slow. It's going to be computationally intensive." WIL: Yeah. That was my exact thought too because this is going to be slow. If acceptance tests are slow and we're doing an acceptance test every 10 milliseconds, it's going to be really slow and that's actually not the case completely. It's actually the opposite. They're extremely fast. CHARLES: It is shockingly fast. You've got to try it to believe how fast it is, how fast you can run acceptance tests. WIL: Yeah, talking like 100 tests in just tens of seconds. CHARLES: Right. You basically gated by how fast your framework can render. Your tests are not part of the slowness. Your test -- WIL: And also, memory leaks can be costly too. We experience that recently where we had memory leaks that were slowing down our test but we fixed those up in test and put our backup. CHARLES: Yeah, because basically, running the assertion or running the convergence is very fast. It's just a very light ping. I kind of think of it is as it is light as the brush of a photon or something that was bouncing off of a surface, so that you can observe it. It's extremely light and most of the time, it's just waiting so the test and the convergence really just gets out of the way. Just because they can run a thousand times or a hundred times in a second, it's doesn't gun it up. But the thing is it means that your tests run as fast as your application will run. You get back to the point... Was it in React where the kind of the key insight is that JavaScript is not the bottleneck? Well, your tests are not the bottleneck. WIL: Yeah. CHARLES: I guess this is what it is. I don't know if there's anything else that you want to say about convergences. WIL: No. We pretty much summed it up there and that's what interactors are based on. That's how they're able to wait for things in a DOM. It basically polls the DOM until it exists and then it moves on and actually does the interaction. CHARLES: Once again, this is actually a very low level thing on which BigTest is based but this is once again, something that you can use independently. You can write your own convergent assertions. You can write your own convergences that honestly have nothing to do with testing your assertions. It's a free standing library that you can use in your test suite or elsewhere should you choose. WIL: That doesn't need to be a DOM for BigTest convergence there. I use BigTest convergence in BigTest CLI to converge on the browser being launched. Instead of waiting for the browser to report that, I can just kind of poll and see how that process is doing and the convergence waits for that process to start before moving on. CHARLES: Right. I guess the best way I've thought about it it's a way to synchronize on observations and not on callbacks. It's a synchronization mechanism and 99% of the synchronization mechanisms that we're used to, they've involved some sort of callback, a promise, an event-listener, things like that or even a generator where control is handed back explicitly to a piece of code when something happens. Whereas, this is a fundamentally different synchronization primitive, where you are writing synchronous code that's based on observations, so what I observe this, do this. When I observe this, do this. It's extremely robust. WIL: Yeah, very. CHARLES: It is a core piece. A fundamental thing that on which interactors are based on, which the CLI is based, I don't know if it's core to writing tests but -- WIL: It definitely helps. CHARLES: It doesn't helps. We couldn't have BigTest interactor without that. WIL: No, definitely not. CHARLES: Because that's what makes it fast, that's what makes it not flaky at all and having those things, I think it makes it easy to maintain because you can work at the interactor level or the level of user interaction and you don't have to worry about synchronization, so the flow of your tests are very natural. WIL: Yeah. We don't have to explicitly wait for request to be done for making an assertion about your app. That'll just come with convergences, just waiting for test date in application to true. CHARLES: Let's talk about one more piece of the testing issue because when you're testing big, when you're testing in the browser, there's always the issue of what are you going to do about your API. You got to have your API running. It's just always an issue and this is kind of interesting because this sits at the crossroads of testing big and also, getting the most utility out of your test because in an ideal world, if you're testing really big, you're going to be using a real API. You're not going to poke holes in reality. WIL: Yeah. One of the things that we avoid in BigTest is poking holes. We're not shallow mounting the components and testing the methods and the results. We're fully mounting these things and fully interacting with them through the full DOM API. CHARLES: Yeah, exactly, using real browsers. It just occurred to me the irony of us talking about reality being things that are still running inside of a computer processor. I think we've inherited this term from that talk that Justin Searls at AssertJS in 2017. It's a really, really excellent talk. I think he gave it at RubyConf. It's the 'Don't mock me.' WIL: Yeah, it's one of my favorite talks. CHARLES: Yeah, it's a great talk. In it, he talks about the value of a test is a balance of how many holes you poke in reality and sometimes, you encounter a test where all it is like holes in reality. Whether you're mocking this, you're mocking that, you're mocking the DOM, you're mocking the browser, you're mocking your network layer, you're mocking this external API and the more holes you poke, the less useful it's going to be. Network is one of those where it can be very difficult to not poke holes in that reality because it's a huge part of your application. Your frontend application is how it's going to interact with the server but at the same time, servers are gigantic pieces of software themselves, each with their own dependencies, each with their own set up and tear down -- WIL: Have their own concerns. CHARLES: Yeah, exactly. They might be in a different language. They've got runtime, things like they might need external C libraries and crazy stuff like that. They're their own beast. To get a true big end-to-end test, you going to have to stand up your server but the problem that presents is you want your tests to be also isolatable. If you're a developer, I can go to a repo, I can do an install of my dependencies and I can run the tests without having to do any external dependencies other than the repository and the language in which I'm working. This is one where we kind of have tried to walk the line of not wanting to poke holes in reality but also, have the test be containable to the actual application. In order to do that, you need something that presents a high fidelity version of the network. You can kind of try and have your cake and eat it too. You want to have something that acts like a server and really acts like a server but it's actually not a server. WIL: And still poke as few holes as possible and the application and how that's all set up, we don't want to be intercepting methods and responding with fake data. That's not a good way to mock that network. CHARLES: Right. We want to be calling actual fetches, calling actual XMLHttpRequest. Ideally, if you've got service workers, making actual service worker requests. WIL: Basically, as far as the application is concerned, it's talking to a real server on us. CHARLES: Yeah and that's kind of the litmus test for is it a hole in reality or is it just a really great illusion? WIL: Yeah and that's a good name for Mirage, right? It's a really great illusion. CHARLES: Yeah. It is a simulation of reality, so we use Mirage, which is something from the Ember testing world but something that we have extracted and made available as BigTest Mirage. WIL: Yeah. The main difference just being is that we've taken away the Ember dependencies and the run loop stuff. It's just plain JavaScript Mirage. It works exactly the same as you use it in Ember minus the auto imports and the file... Oh, man. I can't think of that word. Aside from automatically importing your files for your server config, you have to do that manually because Ember is what provides that but other than that, it's a form of Mirage. You define models and serializers and factories and all the good stuff. CHARLES: Right and then you can use those factories and you can use those models to really give a high fidelity server. If you are building something in whatever framework, you can use BigTest Mirage to simulate that network layer. Again, we've used it in a number of different scenarios but having that in place means that you're going to be able to have those high fidelity tests where your application is actually making XMLHttpRequest but it's all isolatable, so that it can be run in repo. This isn't really related to testing but it has a fantastic capability where you can prepopulate, you can use the factories to prepopulate your server with data, so that you can use the application without the actual server being implemented. WIL: Yeah. That's extremely powerful. That's we were talking about earlier and getting at is the scenarios which are setting up specific, essentially fixtures but you're generating these fixtures. Factories are essentially high level fixtures, network of fixtures. CHARLES: Yeah, higher order of fixtures. WIL: Yeah, so the scenarios are just setting up these fixtures for a scenario of your applications, like the backend is down or the list only responds with two items as opposed to 5000 items, something like that. You want to be able to, not only test these things but be able to develop against it and Mirage makes that really easy because you can just start your app with Mirage-enabled point to that scenario and you're there. You have that exhausted scenario to develop in. CHARLES: If you've never used Mirage, it is really hard to understand just how incredibly powerful it can be. We've used it now on at least four projects, where we did develop the entire first version of the product without any backend whatsoever. It's an incredible product development tool, even apart from testing, that then informs the shape of what the API was going to be. I know we've talked about this on the podcast before but it's really an incredible technology and it is available to you no matter what framework you're using. I think it's one of the best kept secrets in JavaScript development. WIL: Yeah. That's definitely great. That said, though it does have some fallacies. It's great but it can be a little slow sometimes, so we are eventually working on a BigTest network like another piece of the BigTest pie that you'll be able to sprinkle into your application but in the meantime, praise Mirage. CHARLES: Yeah. We are going to be offering an alternative or maybe collaborating for another version of Mirage but hopefully, we can make Mirage faster, we will be able to make this thing faster, so that it can use service workers and be used in a bunch of different scenarios. Just to recap, we've talked about a lot of different components but over the past year, a couple of years, these are the things that we've identified as being really key components as big part of your acceptance testing and really your testing stack. How you're going to start and launch these things? How are you going to set them up and tear them down? How are you going to interact with the application from a user, both in terms of making assertions and how are you going to take action on behalf of the user and still have it be maintainable, have it be resistant to flakiness, have it be performant? BigTest is the answer to that for those particular areas of the testing story and so, some were using we're using existing components like we use Karma, we use Mirage to date. Those, we did not develop but where we see kind of key pieces of that puzzle missing is where we started writing the BigTest solutions so things like the interactor. Eventually, we are going to make BigTest into a product that's you're going to be able to use kind of out of the box, just like you might install Cypress, where it's a very quick set up and we make all of the decisions about the components for you. But in the meantime, we're really trying to take our time, identify those pieces of the puzzle and build the software component that fits that piece of the puzzle at the absolute best so when they're polished, use them in a more comprehensive product. Things like convergence, things like interactor, things like BigTest React, BigTest Vue and very soon, BigTest Ember. These are things that you can use today, to make your tests just that much bigger and that much better, especially interactor. It's been an incredible journey this past year as we kind of develop these individual pieces and there's just going to be more goodness to come. WIL: Absolutely. Right now, I'm working on some validation type API for interactor that I'm hoping to land soon. That'll open up the possibilities of maybe hiding away those convergent assertions a bit more in your tests and just handling this automatically. It'll be pretty good. CHARLES: It's really exciting. Writing test has got more and more easy and more and more fun over the last year for us. I think we're already starting in a pretty good place. If you have any questions about BigTest, how would folks get in touch with us? WIL: We have a BigTest Gitter channel. You can find a link to that on the BigTest website: BigTestJS.io. Just ask us questions on Gitter and we'll try to answer them. CHARLES: And as always, you can ask us directly. You can send email to Contact@Frontside.io or reach out to us on Twitter at @TheFrontside or you can actually reach out to the BigTestJS Twitter account directly and just call us on Twitter at @BigTestJS. Thank you very much, Wil. WIL: Thank you, Charles.

Guest: Dillon Kearns: @dillontkearns | GitHub | Incremental Elm In this episode, Dillon Kearns joins the show to talk about techniques for experimentation with Elm, making those experiments safe, the concept of mob programming, why you would want to experiment with Elm in the first place, and how you too can begin to experiment with Elm. Resources: Grant Maki's talk on experimenting in your team "Types Without Borders" by Dillon Kearns @ Elm Conf 2018 Dillon's Elm GraphQL library How Elm Code Tends Towards Simplicity by Dillon Kearns The CSS as ByteCode Talk by Richard Feldman This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 114. My name is Charles Lowell. I'm a developer here at the Frontside. With me today as co-host on the show is David. Hello, David. DAVID: Hey, guys. CHARLES: David is also a developer here at Frontside and we are going to be talking about something that we've been talking, I guess a lot about recently and we're talking about Elm. I think we first started talking about this several years ago and then it kind of simmer down a little bit but recently, it's been top of tongue. With us to talk about Elm today is Dillon Kearns. Welcome Dillon. DILLON: Thank you so much for having me. CHARLES: I understand that you are a full time Elm consultant. You have a background as a Lean and Agile coach but have recently transitioned to doing Elm consulting full time. Now, what exactly does that mean in 2018 to be an Elm consultant. DILLON: Actually a lot of my motivation for getting into Elm consulting in the first place is I kind of realize that Elm to me is just an extension of the things that I was passionate about with Agile and software craftsmanship. I'm trying to help teams have a better experience with their code, make it more maintainable, make it easier to change, make it easier to drive things based on customer feedback and I really believe that Elm helps people do that. I used a lot of the background and experiences that I've had with Agile and Lean coaching and a lot of those same skills, in order to help organizations adopt Elm. One thing I've seen a lot of teams struggling with is trying out a lot of different frameworks. I've encountered teams that have spent months, very painfully trying out different frontend frameworks and having trouble coming to consensus about that. One of the things that I think really helps address that is having an experimental and iterative approach, that you can really use the scientific method to focus on learning, rather than getting it right the first time. I think that there's really a need to help teams through that process of introducing a new frontend framework like Elm, so that that's why I've gone into full time Elm consulting. CHARLES: That's an interesting process. It sounds like you really need to be constantly sending out spikes, doing research on whether it's Elm or some other technology to help you kind of bridge the chasm to the next generation. How do you actually do that as an organization? My guess, this kind of a question independent of Elm but maybe we can talk about how you see that play out in the context of Elm. DILLON: Right and actually, for any listeners interested in that question, I would really highly recommend Grant Maki's ElmConf talk from this year. He spoke about exactly that topic and it was at ElmConf that it's relevant whether your team is considering Elm or looking at other frameworks. I think that the key is you need to get good at experimenting in a way that's low risk and in a way that you can be constantly learning and seeing how these different technologies fit in your codebase and fit for your team. There's a quote that I really like from Woody Zuill. Have you guys heard of mob programming before? CHARLES: I heard of mob programming from a paper by Richard Garfield a long, long time ago, almost 20... I don't know if it's the same concept. DILLON: Yes. It gained a lot of momentum these days. Mob programming is essentially pair programming but with more people involved. I've really enjoyed that process actually. I think it's actually a great way to experiment with different technologies because you get all of the minds together and it's a very good way to kind of transfer knowledge and explore things together but Woody Zuill talks about mob programming and he likes to ask the question, "Why did we begin doing mob programming for the team at Hunter Industries that originally started mob programming?" People would give answers like, "Because it cuts out code review from the process because you have lots of eyeballs on it in real time," or, "Because it reduces bugs," or, "Because it gives you better quality code. It gives all the best ideas into the product in real time," and all those things are valid points that are really good benefits of mob programming. But he says those things may be true but actually, they're not why we tried mob programming. The reason we tried mob programming was because the team wanted to try it. That's a really important point. The team needs to be experimenting with things that they're passionate about and they need to be exploring things on their own terms. But with that said, another lesson from that story of kind of his team at Hunter Industries discovering mob programming is that the team didn't discover mob programming in a vacuum. Really, the team discovered mob programming because the team became really excellent at experimenting and evaluating those experiments and then, they like to talk about this phrase that Kent Beck coined, 'turn up the good.' When something is working well, we often focus on the negative things and trying to eliminate those things but what happens if we take the things that are working well and 'turn that dial up to 11.' CHARLES: Yeah, I love that. I remember in the kind of the original layout of extreme programming, talking about how I really just wanted to turn up all the things that were working for 11 or to 11, so testing, refactoring, incremental releases and things like that. DILLON: Exactly. CHARLES: I actually had one question that's maybe a little bit of a diversion. This is actually the first time I've heard of mob programming. It's definitely not the same sort of mob programming I learned about in Richard Garfield's paper. I think it was more referring to massively distributed open source in the form which is really kind of commonplace now that happens on GitHub. I think it's maybe, an obsolete definition of mob programming but how many people would be in a mob like two, three, four, five, six, seven, 10? DILLON: That's a great question. Really, the answer is of course, it depends. That's a consultant's favorite answer but it really does. My rule of thumb is I find it usually three people is a very nice size for a mob. I find that mobs tend towards around three or four people but that being said, it's important to note that mob programming is all about this idea that what is the true cost of programming. I think that often we look at programming as the act of writing code, initially and that's a very limited way of looking at coding. Because of course, 90% of our effort is spent maintaining code, making decisions around code, reproducing bugs, fixing bugs, communicating with customers about bugs -- bugs are extremely expensive -- the farther out they get, until eventually they get to the point of a customer discovering them, bugs are in extremely expensive part of software. If we can minimize bugs, that's very valuable. When you look at programming on this bigger scale and look at the bigger picture of programming, then you realize that you may be able to get one person to write the code faster but then, that person needs to code review it. That person needs to go and ask somebody question down the line when they don't have context because they weren't involved in the decision making. For example, maybe there's a UX person who doesn't have context on certain choices that were made, so there's a lot of churn, so you can kind of eliminate that churn by getting all the relevant people involved right away and that's the idea. In my experience with mob programming, it works really well to keep kind of a core of around three people. Sometimes, somebody goes up to have a conversation with somebody, take a break or answer somebody's question, maybe somebody from another team has a question that type of thing and so, the team can keep coding as a pair or whatever. But ultimately, the idea is that you get faster because you're building up this shared context and you're not spending as much time down the line answering questions, doing code reviews and things like that. CHARLES: Right. I see. DAVID: That kind of matches with my experience. Mob programming on previous teams, the way we had it set up is there was a regular mob programming chat session that the whole team was invited to but it was optional. You can just show up if you wanted to and really, that sort of made it so that there was a set of people who regularly attend -- three to five people in a session -- and they were the core group, essentially. DILLON: Right. That's another great point. Invitation is a powerful technique. If you're kind of mandating the people try an experiment or work in a certain way, ultimately it's much more powerful to let the team experiment on their own and follow their passion and they'll discover great things. It's about experimenting, rather than choosing specific experiments. While we're on this topic of kind of the real cost of coding, I think this is a good point to talk about this quality in Elm because, I think that this is one of the things that really motivates me to use Elm myself and introduce it to others is that, I think that Elm really get something about programming where there's a sort of superficial ease of certain techniques that Elm kind of goes beyond and says, "Actually, let's optimize for a different set of things that we think make code more maintainable and more delightful to work with in the long run." CHARLES: I wanted to also transition between, we were on a little diversions on mob programming but do you use mob programming as explicit technique for introducing Elm when a team is considering adopting it? DILLON: That's a fantastic question. I absolutely do. Of course, I honor the ways of working in a particular organization or team. I think that's important to do but I do strongly encourage using mobbing as a technique for knowledge sharing and when I'm on-site with a client, I find it extremely powerful as a technique for knowledge sharing and also, let's say you do an experiment, somebody is off in a corner and they're trying out Vue.js or they're trying out Elm or they're trying a particular coding technique. Then they come back to their team and they say, "Hey everybody, I tried this great thing," and now they have to spend this time convincing everybody and saying like, "Wait a minute. You didn't try this, you didn't try it that way. It wouldn't actually work in our context because of this." I think that it's very powerful to have everybody kind of involved in that process so that you can evaluate it together as a team. CHARLES: Because the thing is like, when you experience win or you experience fail, it's a very visceral feeling and that's the thing that sells you or turns you away. You can argue until you're blue in the face but words have a very limited capacity to convince, especially when compared with like physical and emotional feeling. It sounds like you can get everybody to have that shared experience, whether for the good or for the bad, you're going to arrive at a decision, orders of magnitude more quickly. They have to rely in conviction of that decision spread around the team. DILLON: Exactly. I think that hits the nail on the head and you say that we have this sort of skepticism of arguments from theoretical conversations, rather than 'show me the money,' but it's actually, try solving a real problem in this and that's exactly as it should be. I think that's one of the big antidote from this problem that I've seen in a lot of environments, where there's this analysis paralysis, especially with the state of the JavaScript ecosystem these days. I think that one of the keys to improving that situation is to get good at trying things, rather than theorizing about things. We have a tendency to want to theorize and when we do that, then we say, "Can it solve this problem? Can it solve this problem? Can it solve that problem?" You can talk about that until the cows come home but it doesn't get you anywhere and it doesn't really convince anybody of anything. The key is to find very small experiments and what I really recommend and what I'm dead focused on when I'm initially working with a client is getting something into production. Now, that doesn't mean that you need to have a road map for turning your entire application into Elm. In fact that's the whole point, is that you're not trying to do that. The point is you're trying to get as realistic of an experience as possible for what problems might occur if we do this? Will the team enjoy working with this language? Will it work well with our built pipeline? Will there be any unforeseen issues? You don't know until you actually try it, so you've got to try it and you've got to try it in tiny, tiny steps and low risk experiments. CHARLES: Right but you've got to try it for real. You don't want to try it with a TodoMVC. DILLON: Exactly. It needs to be meaningful, to really have a good understanding of what it's going to be like. CHARLES: I would say that I tend to agree but I've definitely encountered the counterargument and I also think this counterargument makes sense or perhaps where the pushback lies is if I'm constantly experimenting, then what I'm doing is I'm internally fragmenting my ecosystem and there is power in similarity. Any time you introduce something different, any time you introduce one fragment, you're introducing complexity -- a mental complexity -- like maybe I have to maintain my Elm app and I also have to have my Legacy... Or not Legacy, I've got my other JavaScript tool kit that does it in one way. Maybe I've got a couple of more because I've run these other experiments. I'm not saying that there is one way but there is power in uniformity. There is power in diversity. Where do you find the balance? DILLON: Those are all excellent points. To me, I think really the key is it's about the scientific method, you could say. The thing with the scientific method is that we often forget the last part. We get really good at hypothesizing about things. Sometimes people leave it at that, which we kind of just discussed. Sometimes, people go past the hypothesizing stage and they actually run the experiment and that's great. But then, the majority of people, if they get to that point, will forget to do the last step which is to evaluate the results. I think the key here is you need to be experimenting and this is what it means for it to be a low risk experiment. It means that you're not setting yourself off in a direction where you can't turn back. You want to set it up in such a way that you can turn away from it with minimal cost. One of the things that is really helpful for that is if you build a tiny, independent, little widget in your application, try building that in Elm. Some people will do that with a little sort of login badge in the corner of their application. One of the teams where I've introduced Elm at a Fortune 10 company, actually where we introduced Elm, we started out with just a tiny little table in one page and if we wanted to back that out, it would have been trivially easy but we decided that we wanted to go in further and invest more. CHARLES: That makes a lot of sense. Effectively, you need to have a Plan B. Don't sync all of the available time that you have to invest in an experiment. Make sure that you have a Plan B and if you need to do this widget or this table in Angular or React or Ember or whatever, you are thinking about that -- how would that work. DILLON: Exactly and the thing with experiments is the purpose of an experiment is not to build something. It's to learn. I really like this kind of ethos of lean startup, which I think is really getting much more into the mainstream in the software industry, which is a wonderful thing. The idea of lean startup, the kind of core concept is this idea of validated learning. Basically, in an environment where there's uncertainty, which is pretty much most of the things you're doing in software, the main goal is you're not shipping a product like you would be if you're trying to manufacture cars as quickly as possible. The main thing that you're producing is what they call 'validated learning' and so, you want to minimize the amount of time it takes to validate or invalidate your assumptions about something and then, you want to make it as cheap as possible to move on from that. CHARLES: I like that. So if you're going to organize your development process around this principle or maybe not organize it but integrate it into development process, how do you know that you're conducting a healthy number of experiments, versus I may be conducting too many experiments? Is there a metric that you can look at? We need to have this many experiments running at all times or this is just too many or something else. DILLON: That's a really interesting question. I think I would tend to think about that more again, as looking at the way the experiments are run, rather than 'are there too many experiments?' That's just not a problem that I've seen there being too many experiments. The pain that we tend to really see in environments where experiments are hurting teams is the way the experiments are being done. It's hard to backtrack from those experiments and as you were saying before, you kind of put yourself down this path where you can't walk it back and you create this sort of rift in the way the code is being written, which makes it more difficult to work in that codebase. The thing with experiments is they can have really big payoff. Now, you want to make sure that you're not just going in and picking up every shiny object that you see. One thing that can keep you honest with that is if you're kind of coming up with a hypothesis before you start. If you're saying, "This is the value to our business and to our team if we attempt this thing and this is what will prove that it seems to have that value and this is what will tell us, 'Actually, it doesn't have that value and we should drop it and cut our losses.'" CHARLES: That's a great heuristic. As you're saying and imagining how that might have saved my bacon in the past because I've definitely made the mistake of playing with too many shiny objects and picking things because I didn't fully evaluate what I thought the value. I was explicit with myself about what is the value that is going to bring to this project or this business. I have a theory about it but I am not thinking what is my hypothesis and how am I going to validate or invalidate? I'm thinking, I've got a short term pain that I'm experiencing and I'm grasping for this thing, which I think will solve it and I'm not properly evaluating how it's going to affect me long term. DILLON: Right and that could be a great team practice to play around with is often, teams will kind of come up with action items out of retrospectives. One thing that I think can be really beneficial for teams is to kind of flip that notion of doing action items which again, it's really just doing the middle part of the experiment where you're conducting the test but you cut out the hypothesis part and the evaluation part. Try to bring that into your team's retrospective and try to have explicit hypotheses in the retrospectives and then, in the next retrospective, evaluate the results. CHARLES: All right. I will definitely keep that in mind but this feels like a fresh take on kind of how you manage software development that I haven't encountered too much, being more scientific about it. It sounds like science-oriented development. DILLON: Right. DAVID: I like that. DILLON: There are a lot of buzzwords these days in software development, in general and it's really becoming a problem, I think in the Agile community but really, what it boils down to is these basic elements and basing decisions on feedback is one of those fundamental unit. You can call the scientific method, you can call it lean startup and validated learning, you can call it agile, you can call it whatever you want but ultimately, you need to be basing things on feedback. I think of it almost like our nerves. There's actually a disorder that some people have, which can be fatal, which is that their nerves don't tell them when they're feeling pain. I think this is a great analogy for software because that can happen to companies too. They don't feel the pain of certain decisions not landing well. Because they're not getting feedback from users, they're not getting feedback from metrics and recording, they're not getting feedback from doing that final evaluation step of their experiments, so when you fall on the ground, a small cut could be extremely harmful because you don't know the damage it's doing to you. CHARLES: I think that is a good analogy. One of the things that I'm curious about is we've been discussing a lot of techniques for experimentation and how you can integrate that into your process and how you can make your experiments safe, so let's talk a little bit about -- first of all, two things -- why would I want to experiment with Elm in the first place? Because ultimately, that's why we're here and why we're having this conversation. What's compelling about it that would make me want to experiment? And then how can I begin to experiment with Elm? DILLON: I actually just published a blog post yesterday. It's called 'How Elm Code Tends Towards Simplicity.' To your question of why would a team consider Elm, I kind of talk a little bit in this blog post about a case study at a Fortune 10 company where I introduced Elm to a few of the teams there. One of the teams there, we had actually seen an Angular project that they had worked on and often, in an enterprise environment, you have projects moving from one team to another. I actually had my hands on this Angular project. It kind of moved over to another team and we were experiencing some major pain trying to make changes in this codebase. Even making the simplest change, we were finding that there were a lot of bugs that would be introduced because there's some global variable. There's some implicit state. Sometimes, it was even reaching in and tweaking the DOM and really, the topic of conversation at our team lunches was how afraid we were to touch this codebase. Fast forward a few months and this team was asking my advice on picking a new frontend framework and I introduced them to Elm. They took a run with it and it was pretty remarkable to see this same team that had really struggled with AngularJS and they didn't really have a strong sense of what were the best practices. They weren't getting any guidance from the framework itself and the tooling around it and they actually loved the experience of working with Elm because they were saying, "This is amazing. Maybe it takes a little time to figure out how to solve a particular problem on Elm but once we do, we know that we've done it in a solid way." One of the things that I think is most powerful about Elm is that it keeps you from shooting yourself in the foot. I think that's a really good headline kind of summary of what I love about Elm. For example, tweaking the DOM. Now, it might seem like a pretty obvious thing that we just won't tweak the DOM and that's fair enough. That might not be a problem for a lot of teams. People wouldn't even reach for that technique because they're disciplined about it. But at a certain point, you start taking on enough things and then go from kind of those basic things that are going to make your code more unreliable and unsafe like tweaking the DOM and you start getting into the realm of best practices. There's so much discussion these days in the JavaScript community about best practices, which is great. It's great to discuss that but my concern is that there's a new best practice each week and the team has to agree on it, you have to find techniques for enforcing it, people have to make sure that these best practices are being followed in code reviews. Then when you look at a given piece of code, you have to trust that those best practices are being followed, so it requires a lot of work to make sure, in your reducers, in redux that you are not mutating anything. With Elm, data is just immutable. That's just how it is. There are a lot of these kind of things that are baked into the language and the expressivity of the type system allows you to bake in your own constraints. One of the things that I find really compelling about Elm is its design really prevents you from shooting yourself in the foot and it gives you tools for making sure that you take it even a step further and it helps you enforce these best practices at a compiler level. CHARLES: Now what's interesting here is it's almost like the opposite tension of experimentation is a work, right? like here, we have an example of uniformity being the more powerful track but then inside the actual macroscopic process, you want a lot of experimentation and diversity. But at the microscopic level, inside your application, it sounds like you want less experimentation and you derive a lot of strength from that but -- DILLON: That's a great point. CHARLES: -- Experiments that are possible, yeah. DILLON: I think that there is a lot of pain these days in the JavaScript community. We hear people talking often about JavaScript fatigue and it's a real thing. It takes a lot of work to stay on top of the latest best practices and frameworks and that can be a lot of fun. I love learning about the latest new frameworks and tooling but ultimately as you're saying, we don't want that experimentation so much about the fundamentals. We want some dependable, solid fundamentals and then we want the experimentation to happen within there. I think that's exactly what we see in the Elm ecosystem. We have a single kind of data store or way of managing state in Elm. It's called the Elm Architecture. In fact, it's what Redux is based on and it worked extremely well and you don't have to experiment with different data stores in Elm because that's just what Elm code looks like. Now, if you want to experiment in Elm, then there is a lot of innovation happening. One of my favorite things about Elm is that the compiler and its expressiveness has sparked a lot of creativity. One of my favorite things about Elm is the library called Elm UI. Actually, a client that I'm working with right now, it's a really interesting case study. They are kind of a very small startup. They just kind of branched off of a larger startup. They're building some tooling for this ecosystem. They were engineers at a company called Procore that does cloud document management for construction companies. They wanted to get a product-ready for a big conference for their potential clients. The reason they brought me in to help them was because they wanted to reach this ambitious target of being able to do a demo of this brand new product at this conference and they wanted to iterate very quickly. One of the things that really drew them into Elm in the first place is this library Elm UI. Elm UI essentially, Richard Feldman gives a talk on it, where he uses the analogy of it being treating CSS and HTML as bytecode for your views. I think that's a really apt way to put it. If you break down this idea of CSS -- Cascading Style Sheets, it removes the cascading part of CSS and it removes the sheets part of CSS. What you're left with is a way of expressing style and it's a way of expressing style that is able to part ways with all of the baggage of the entire history of backwards compatible decisions that CSS has ever made. If you want to vertically aligned something, then you just say, "Align vertically," you know, center vertically. If you want to center something horizontally, you say center X. It creates a high level language for expressing views. My experience with Elm UI, this may not be the right choice for every team but I love it. I use it on all of the projects that I maintain personally. I love using it because it gives you that same sense of invincibility refactoring that you get with Elm, which is remarkable that you could have that feeling with managing views. CHARLES: It's definitely something that feels like a dark art and it can't be called science. It's an art. It's a science for some people but it's historically been a dark art and something fiddly to work with. In terms of being able to make the experiment with Elm, when we talked a little bit about why you might want to experiment with it in the first place, what the business case is, I guess my next question is or a question that immediately comes to mind is supposing that we have decided to experiment with this, how do you mitigate that experiment? We talked about lowering the cost, having a way to turn away from it, having a way to make it inexpensive. For example, one of the things that I think of when evaluating a new technology is how well can I use it with old technologies. I have a lot about best practices in my tool bag. We all do. We got our all favorite libraries and pathways that are just familiar to us. One of the things that I've noticed is when adopting a new technology, one of the things that makes it easy to experiment with is how well it works with the existing technologies. I know that, we talked about Elm UI, kind of rethinking style in CSS and your views and Elm itself as a completely different language within JavaScript, that can be both liberating but it can also be limiting in the sense that I can't reach back for my existing tool if no tool exists in this new space. The kind of experience that I've had where this is really worked is systems like JRuby or Clojure, where there's a very clear pathway to be able to use Java libraries from those environments, so you always have kind of an escape hatch. What's that like in Elm? DILLON: This is a really interesting conversation because it highlights, in some ways some of the most defining features of Elm. In terms of how do you kind of pull Elm into an existing application, there are a lot of different techniques for that. It's pretty straightforward to create a little Elm app. We usually don't call them components for reasons that we can get into if we want to but that's a whole can of worms. But if you've got a little Elm application that you want to use to render a widget on your page, then it's as simple as just calling Elm.yourmodule.init and rendering it onto the page there. That's quite straightforward and if you want to interface with your existing code there are several ways to do that. There's something called port in Elm, which is how you kind of communicate by sending these messages and data back and forth between your Elm app and JavaScript. Now, this is one of the decisions, I think that defines Elm as the language and the reason this is important is because Elm decided not to make the choice that a lot of other compile to JS languages do. For example, if you look at ReasonML or PureScript or a more extreme example, TypeScript. TypeScript is a superset of JavaScript, so it's trying to allow you to gradually introduce this to get some incremental improvements for your JavaScript code, so it's extremely easy to experiment with it, which we've talked about the importance of experimentation. Now, the challenge with this technique, the tradeoff here is it's great, that it then becomes very easy to transition into it and that's an excellent strategy for the goals of TypeScript. Elm has a different set of goals, so the things that elm is focused on giving you is a truly type-safe experience. When you're working with Elm, if your Elm code says that this data is a float, then it is a float. Either, it is a float or that code is not being run and so, that's very different than the experience in TypeScript where you have these escape hatches. This is an inevitable choice for any compiled to JS language. Are you going to have escape hatches or not? Elm is really the only language out there, I think that chooses not to have escape hatches and that is actually the thing that that I love about the language because that's the only way you can truly have guarantees, rather than, "Yeah, I'm pretty sure that these type guarantees hold." DAVID: Yeah, wishes and dreams. DILLON: Yeah. CHARLES: What does it mean to have no escape hatches? because you talked about ports. Does it mean like it's impossible to use an external JavaScript library? DILLON: That's an excellent question. You absolutely can use JavaScript libraries. It means that it's being explicit and upfront about the fact that there's uncertainty in these areas. That's what it comes down to. Take for example dealing with JSON. In a JavaScript application, what we get when we're dealing with JSON is you make a request up to the server, you have some callback that passes in the data you get back and then you start pulling bits and pieces off of it and you say 'response.users subzero.firstname' and you hope that none of those things are null, none of those types are different than what you expected. In a way, it's kind of letting you pretend that you have certainty there when in fact, you don't and with Elm, the approach is quite different. You have to explicitly say, "I expect my response to have this shape. I expect it to be a list of things, which have a first name and last name which are strings," and then Elm says, "Okay, great. I'm going to check your assumptions," and if you're right, then here you go and you're in a well typed-space where you know exactly what the types are and if you're wrong, then that's just another type of data, so it's just a case statement where you say, "If my assumptions were correct, then do something and if my assumptions were incorrect, then you decide what to do from there." CHARLES: Right. For me, it sounds like there is some way because ultimately, I'm going to be getting unstructured but I'm going to be getting JSON back from the server and maybe, I have some library that's going to be doing that for me and enhancing it and adding value to that JSON in some way. But then at some point, I can present it to Elm but what you just saying is I need to be complete in making sure that I handle each case. I need to do or handle the case. Explicit about saying if the assumptions that Elm wants to make, turn out to not be true, Elm is going to make me handle the case where those assumptions were not true. DILLON: Exactly. I think that TypeScript of any type is the perfect illustration of the difference. TypeScript of any type is sort of allowing you to say, "Don't type check this. Trust me here," and Elm's approach is more kind of just be explicit about what you want me to do if your assumptions are incorrect. It doesn't let you kind of come in and say, "No, I know I'm going to be right here." CHARLES: Right but there is a way to pass data structures back and forth. DILLON: There absolutely is and actually, there's a technique that's starting to gain some traction now, which I'm really excited about, which is rather than using this sort of JavaScript interrupt technique we talked about, which is again, it's very much like communicating with a server where you're kind of sending messages and getting data back -- getting these messages with data back. But there's an alternative to that which is using web components. Actually, there's quite good support for assuming that you don't need to be compatible with Internet Explorer. Basically in a nutshell, if you can wrap a sort of declarative web component around anything, it could be a Google Maps API, it could be a syntax highlighting JavaScript library, something that you don't have an Elm library for but you want to use this JavaScript library, it's actually quite a nice experience. You just render that custom element using your Elm code just as you would any other HTML in Elm. CHARLES: Yeah I like that, so the HTML becomes the canvas or composition with other JavaScript and the semantics are very well-defined and that interface is actually pretty thin. DILLON: Exactly and the key again is that you wanted to find a declarative interface, rather than an imperative one where you're kind of just doing a series of statements where you say, "Do this and then set this value and then call this and then set this call back." Instead, you're saying, "Render this Google Maps custom element," which is centered around these coordinates and has this zoom level on. You declaratively give it the bit of information that it needs to render a particular view. CHARLES: Okay. Then I guess the final question that I have around this area is about being able to integrate existing tools and functions inside of an Elm application. Because it sounds like you could theoretically develop large parts of your application, is there a way that you can actually have other areas of your application that are not currently invested in Elm still benefit from it, in the sense for kind of need of JavaScript APIs that Elm can make available. DILLON: Right, so you're kind of talking about the reverse of that Elm reaching out to JavaScript. You're asking about, can JavaScript reach out to Elm and benefit from some of its ecosystem? CHARLES: Exactly. I say that is that another potential vector for experimentation. DILLON: It's a really interesting thought. I haven't given it too much thought, to be honest but I actually have heard it come up before and my gut feeling is that it's probably more fruitful to explore the inverse, reaching out to JavaScript from Elm and the reason is kind of the main appeal of Elm is that when you're operating within Elm, you have this sense that if it compiles, it works. Because again, this central decision to not allow escape hatches is what allows you to have that sort of robustness, so you have this feeling of bullet proof refactorings and adding new features seamlessly where you change your data modeling to say, "Here's this other case that can be represented," and then suddenly, the Elm compiler says, "Tell me what to do here, tell me what to do here and tell me what to do there," and you do it and your app is working. That's the real appeal of Elm, I think and you don't really get much of that by just calling out to an Elm library from within JavaScript. That's my gut feeling on it. CHARLES: Okay, that's fair enough. On the subject of interrupt and using tools like JSON, you actually maintain a GraphQL library for Elm. You probably have a lot of experience on this. Maybe we can talk about that as a concrete case that highlights the examples. DILLON: Yeah. I think to me this is one of the things that really highlights the power of Elm, to give you a really amazing refactoring and kind of feature creating experience. A lot of Elm libraries are prefaced by the author name, so it's still DillonKearns/ElmGraphQL. I spoke about it this year at ElmConf. In a nutshell, what it does is it actually generates code based on your GraphQL schema. For anyone who doesn't know, GraphQL is just kind of a language for expressing the shape of your API and what types of data can return. What DillonKearns on GraphQL does is it looks at your GraphQL schema and it generates an API that allows you to query that API. using this library, you can actually guarantee that you're making a valid query to your server. Again, you get this bulletproof experience of refactoring in Elm where you can do something like make a change in your API and recompile your Elm code and see whether you've made a backwards incompatible change. All of this effort of doing sort of this JSON decoding I was talking about earlier where you kind of have to explicitly say, "These are my assumptions about the shape of the JSON that I'm getting back." When you're using this library, you no longer need to make any assumptions because you're able to rely on this sort of schema of your API and so you know when you're requesting this data, you don't have to run it, see if it works and then tweak it and run it again -- this sort of cycle of checking your assumptions at runtime. It moves those assumptions that you're making from runtime to compile time and it can tell you when you compile your application, it can say, "Actually, this data you're requesting, it doesn't exist," or, "It's actually called this," or, "This is actually the type of the data." CHARLES: Right. I love that. How do you do that? Because it seems like you've got a little bit of a chicken and the egg problem because the schema is defined outside of Elm, so you have to be able to parse and understand the schema in order to generate the Elm types to be able to compile Elm code against them. Maybe I'm not -- DILLON: That's exactly right. That's exactly what it does. Now, the nice thing is that GraphQL is really designed for these types of use cases. It supports them in a first class way. If you have a GraphQL API, that means you have built into it whether you know about it or not, a way to introspect the schema. All of the queries for kind of interrogating that GraphQL server and asking what types of data does this return, what are all your queries that I can run, it's built into it by the framework, so that comes for free. Getting up and running with this package I built is as simple as running a little npm CLI, pointing it to either your URL for your server or the JSON form of your schema, if you prefer and then, it generates the code for you. CHARLES: Wow, that sounds fantastic. This is the exact kind of thing that feels like it would be cool if I could just start using this library to manage the GraphQL of my application but I'm consuming that GraphQL from other JavaScript but it's the Elm code that's managing it. Do you see what I mean? DILLON: I hadn't considered that. I guess you could. You're right. Maybe I'm so smitten with Elm that it's hard to see an in-between but I guess, you could get some benefits from that approach. CHARLES: Right and as an experiment of course. DILLON: There you go. There you go. CHARLES: All right. With that, I think we'll wrap it up. Thank you so much, Dillon for coming on and talking with us on the podcast. DILLON: My pleasure. I really enjoyed the conversation. CHARLES: I actually got so many great tidbits from so many different areas of software development in Elm but also, just in kind of other things that I'm interested in trying. It was a really great conversation. DILLON: I had a lot of fun and I love discussing these things. For any listeners who are interested in this stuff, feel free to reach out to me on the Elm Slack or on Twitter. I'm at @DillonTKearns. I'm also offering a free intro Elm talk for any companies that are kind of entertaining the idea of doing an experiment with Elm. If you go to IncrementalElm.com/Intro, you can find out about some of the talks that I'm offering. CHARLES: All right. Well, thank you very much and we, as always are the Frontside. We build software that you can stake your future on and you can get in touch with us at @TheFrontside on Twitter or Contact@Frontside.io on email. Please send us any questions you might have, any topics that you'd like to hear about and we look forward to hearing from you and we will see you next week.

Guest: Philip Poots: GitHub | ClubCollect Previous Episode: 056: Ember vs. Elm: The Showdown with Philip Poots In this episode, Philip Poots joins the show again to talk about the beauty of simplicity, the simplicity and similarities between Elm and Ruby programming languages, whether Elixir is a distant cousin of the two, the complexity of Ember and JavaScript ecosystems (Ember helps, but is fighting a losing battle), static vs. dynamic, the ease of Rails (productivity), and the promise of Ember (productivity, convention). The panel also talks about the definition of "quality", making code long-term maintainable, and determining what is good vs. what is bad for your codebase. Resources: Michel Martens mote Learn the Elm Programming Language and Build Error-Free Apps with Richard Feldman Worse is Better: Richard P. Gabriel Gary Bernhardt's Destroy All Software Screencasts Zen and the Art of Motorcycle Maintenance: An Inquiry into Values The Calm Company It Doesn't Have to Be Crazy at Work This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES:: Hello, everybody and welcome to The Frontside Podcast, Episode 113. My name is Charles Lowell. I'm a developer here at the Frontside and with me today are Taras Mankovski and David Keathley. Hello? DAVID:: Hey, guys. TARAS: Hello, hello. CHARLES:: And we're going to be talking with a serial guest on our serial podcast, Mr Philip Poots, who is the VP of engineering at ClubCollect. Welcome, Philip. PHILIP: Hey, guys. Thanks for having me on. CHARLES:: Yeah. I'm actually excited to have you on. We've had you on a couple of times before. We've been trying to get you on the podcast, I think for about a year, to talk about I think what has kind of a unique story in programming these days. The prevailing narrative is that folks start off with some language that's dynamically typed and object oriented and then at some point, they discover functional programming and then at some point, they discover static programming and they march off into a promised land of Nirvana and no bugs ever, ever happening again. It seems like it's pretty much a straight line from that point to the next point and passing through those way stations. When I talk to you, I guess... Gosh, I think you were the first person that really introduced me to Elm back at Wicked Good Ember in 2016 and it seemed like you were kind of following that arc but actually, that was a bit deceptive because then the next time I talked to you, you were saying, "No, man. I'm really into Ruby and kind of diving in and trying to get into Ruby again," and I was kind of like, "Record scratch." You're kind of jumping around the points. You're not following the preordained story arc. What is going on here? I just kind of wanted to have a conversation about that and find out what the deal was and then, what's kind have guided your journey. PHILIP: There was one event and that was ElmConf Europe, which was a fantastic conference. Really, one of the best conferences I've been to, just because I guess with the nature of early language, small conference environment. There's just a lot of things happening. There's a lot of people. Evan was there, Richard Feldman was there, the leading lights of the Elm community were there and it was fantastic. But I guess, one thing that people have always said to me is the whole way track is the best track of the conference and it's not something I really appreciated before and during the breaks, I ended up talking to a guy called Michel Martens. He is the finder of a Redis sourcing company and I guess, this was just a revelation to me. He was interested in Elm. He was friends with the guys that organized the conference and we got talking and he was like, "I do this in Ruby. I do this in Ruby. I did this in Ruby," and I was like, "What?" and he was like, "Yeah, yeah, yeah." He's a really, really humble guy but as soon as I got home, I checked him out. His GitHub is 'soveran' and it turns out he's written... I don't know, how many gems in Ruby, all with really well-chosen names, very short, very clear, very detailed. The best thing about his libraries is you can print them out on paper. What I mean by that is they were tiny. They were so small and I guess, I just never seen that before. I go into Ruby on Rails -- that was my first exposure to programming, that was my first exposure to everything -- unlike with Rails, often when you hit problems, you'd start to dive a bit deeper and ultimately, you dive so deep that you sunk essentially and you just accepted, "Okay, I'm not going to bend the framework that way this time. Let's figure out how everyone else goes with the framework and do that." Then with Ember when I moved into frontend, that was a similar thing. There were so many layers of complexity that I never felt like had a real handle on it. I kind of just thought this was the way things were. I thought it's always going to be complex. That's just the nature of the problem. That's just the problem they're trying to solve. It's a complex problem and therefore, that complexity is necessary. But it was Elm that taught me, I think that choosing the right primitives and thinking very carefully about the problem can actually give you something that's quite simple but incredibly powerful. Not only something quite simple but something so simple that it can fit inside your head, like this concept of a program fitting inside your head and Rails, I don't know how many heads I need to fit Rails in or Ember for that matter and believe me, I tried it but with Elm, there was that simplicity. When I came across this Ruby, a language I was very familiar with but this Ruby that I had never seen before, a clear example was a templating library and he calls it 'mote' and it's including comments. It's under a hundred lines of code and it does everything you would need to. Sure, there were one or two edge cases that it doesn't cover but it's like, "Let's use the trade off." It almost feels like [inaudible] because he was always a big believer in "You ain't going to need it. Let's go for that 80% win with 20% effort," and this was like that taken to the extreme. CHARLES:: I'm just curious, just to kind of put a fine point on it, it sounds like there might be more in common, like a deeper camaraderie between this style of Ruby and the style encouraged by Elm, even though that on the surface, one is a dynamically typed object oriented language and the other is a statically typed functional language and yet, there's a deeper philosophical alignment that seems like it's invisible to 99% of the discussion that happens around these languages. PHILIP: Yeah, I think so. I think the categories we and this is something Richard Feldman talks. He's a member of the Elm community. He does a lot of talks and has a course also in Frontend Masters, which I highly recommend. But he often talks about the frame of the conversation is wrong because you have good statically typed languages and you have bad statically typed languages. You have good dynamic languages and you have bad dynamic languages. For all interpretations of good and bad, right? I don't want to start any wars here. I think one of the things that Elm and Ruby have in common is the creator. Matz designed Ruby because he wanted programming to be a joy, you know? And Evan created Elm because he wanted programming to be a delight. I think if you experience both of those, like developing in both of those languages, you gain a certain appreciation for what that means. It is almost undefinable, indistinguishable, although you can see the effects of it everywhere. In Ruby, everything is an object, including nil. In Elm, it's almost he's taken everything away. Evan's taken everything away that could potentially cause you to stumble. There's a lot to learn with Elm in terms of getting your head around functional mindset and also, working with types but as far as that goes, people often call it like the Haskell Light, which I think those are a disservice to Elm because it's got different goals. CHARLES:: Yeah, you can tell that. You know, my explorations with Elm, the personality of Elm is 100% different than the personality of Haskell, if that is even a programming term that you can apply. For example, the compiler has an identity. It always talks to you in the first person, "I saw that you did this, perhaps you meant this. You should look here or I couldn't understand what you were trying to tell me." Literally that's how the Elm compiler talks to you. It actually talks to you like a person and so, it's very... Sorry, go ahead. PHILIP: No, no, I think the corollary to that is the principle of the surprise in Ruby. You know, is there going to be a method that does this? You type it out and you're like, "Oh, yes it is," which is why things like inject and reduce are both methods in enumerable. You didn't choose one over the other. It was just like, "Let's make it easy for the person who's programming to use what they know best." I think as well, maybe people don't think about this as deeply but the level of thought that Evan has put into designing Elm is crazy, like he's thought this through. I'm not sure if I said this the last time but I went to a workshop in the early days in London, which is my kind of first real exposure to Elm and Evan was giving the workshop. Someone asked him, "Why didn't you do this?" and he was like, "Well, that might be okay for now but I'm not sure that would make so much sense in 10 years," and I was kind of like, "What?" Because JavaScript and that ecosystem is something which is changing like practically hourly and this is a guy that's thinking 10 years into the future. TARAS: You might have answered it already but I'm curious of what you think is the difference, maybe it just comes down to that long term thinking but we see this in JavaScript world a lot, which is this kind of almost indifference to APIs. It almost doesn't really matter what the API is for whatever reason, there seems to be a big correlation between the API that's exposed with the popularity of the tool. I think there are some patterns, like something that's really simple, like jQuery and React have become popular because of the simplicity of their APIs. What the flip side to that? What other ways can APIs be created that we see in JavaScript world. Because we're talking about this beautiful APIs and I can relate to some of the work that Charles has been doing and I've been doing microstates but I wonder like what would be just a brief alternative to that API, so it's kind of a beautiful API. PHILIP: I don't know if anyone is familiar with the series of essays 'Worse is Better' like East Coast versus West Coast, from Richard Gabriel. The problem is, I guess and maybe this is just my understanding over my paraphrase of it, I'm not too familiar with it but I think that good APIs take time and people don't have time. If someone launches a V1 at first and it kind of does the job, people will use that over nothing and then whenever they're happy with that, they'll continue to use it and develop it and ultimately, if she's market share and then that's just the thing everyone uses and the other guy's kind of left behind like, "This is so much better." I guess this is a question, I think it was after Wicked Good Ember, I happened to be on the same trend as Tom Dale on the way back to New York and we started talking about this. I think that's his big question. I think it's also a question that still has to be answered, which is, "Will Elm ever be mainstream? Will it be the most popular thing?" aside from the question of whether it has to be or not. For me, a good APIs good design comes from understanding the problem fully -- CHARLES:: And you can understand the problem fully without time. PHILIP: Exactly and often, what happens -- at least this is what happens in my experience with the production software that I've written -- is that you don't actually understand the problem until you've developed a solution for it. Then when you've developed a solution for it, often the pressures or the commercial pressures or an open source is [inaudible] the pressures of backwards compatibility, mean that you can never refactor your way to what you think the best solution is and often, you start from scratch and the reality is people are too far away with the stuff you wrote in the past about the thing you're writing now. Those are always kind of at odds. I think there are a lot of people that are annoyed with Elm because the updates are too slow, it relies on Evan and we want to have a pool request accepted. All of the things that they don't necessarily recognize like the absence of which make Elm an Elm, if you know what I mean. The very fact that Evan does set such a high standard and does want everything to go through his personal filters because otherwise, you wouldn't gain the benefits that Elm gives you. The attention is very real in terms of I want to shift my software now and it becomes easier then. I think to go to a language like JavaScript, which has all of the escape hatches that you need, to be able to chop and change, to edit, to do what you need to do to get the job done and let's be quite honest, I think, also with Elm, that's the challenge for someone who's not an expert level like me. Once you hit a roadblock, you'll say, "Where do I go from here?" I know if I was using JavaScript, I could just like hack it and then clients are happy and everything's fine and you know there's a bit of stuff in your code that you would rather wasn't but at the end of the day, you go home and the job's done. DAVID:: Have you had to teach Elm to other people? You and I did some work like I've seen you pair with someone and guide them through the work that they needs to get done. If you had a chance to do something like that with Elm and see how that actually happens, like how do developer's mind develops as they're working through in using the tool? PHILIP: Unfortunately not. I would actually love to go through that experience. I hope none of my developers are listening to this podcast but secretly, I want to push them in the direction of Elm on the frontend. But no, but I can at least make from my own perspective. I find it very challenging at first because for me, being a Ruby developer and also, I would never say that I understood JavaScript as much as I would have liked. Coming from dynamic language, no functional experience to functional language with types, it's almost like learning a couple of different things at the same time and that was challenging. I think if I were to take someone through it, I would maybe start with a functional aspects and then move on to the type aspects or vice versa, like try and clearly breakdown and it's difficult because those two are so intertwined at some level. Gary Bernhardt of Destroy All Software Screencast, I watch quite a bit of his stuff and I had sent him an email to ask him some questions about one of the episodes that he did and he told me that he done the programming languages course, I think it's on Coursera from Daniel Grossman, so [inaudible] ML which is kind of the father of all MLs like Haskell and also Elm. I find that really helpful because he broke it down on a very basic level and his goal wasn't to teach you ML. It was to teach you functional programming. It would be a very interesting exercise, I think. I think the benefit that Elm gave you is you get to experience that delight very quickly with, "Oh, it's broken. Here's a nice message. I fix the message. It compiles. Wow, it works," and then there's a very big jump whenever you start talking about the effects. Whenever you want to actually do something like HTTP calls or dealing with the time or I guess, the impure stuff you would call in the Haskell-land and that was also kind of a bit weird. CHARLES:: Also, there's been some churn around that, right? PHILIP: That's right. When I started learning, they had signals, then they kind of pushed that all behind the scenes and made it a lot more straightforward. Then I just mastered it and I was like, "Yes, I know it," and then I was like, "All right. I don't need to know it anymore." This is the interesting thing for me because at work, most of our work now is in Elixir and Phoenix. I'm kind of picking a little bit up as I work with them. I think Elm's architecture behind the scenes is kind of based, I believe on Erlang's process model, so the idea of a mailbox and sending messages and dealing with immutable state. CHARLES:: Which is kind of ironically is very object oriented in a way, right? It's functional but also the concept of mailboxes and sending messages and essentially, if you substitute object for process, you have these thousands and thousands of processes that are sending messages back and forth to each other. PHILIP: Yeah, that's right. It's like on a grand scale, on a distributed scale. Although I wouldn't say that I'm that far with Erlang, Elixir to appreciate the reality of that yet but that's what they say absolutely. CHARLES:: Now, Phoenix and Elixir is a dynamically typed functional language. does it share the simplicity? One of the criticisms you had of Rails was that you couldn't fit it in your head. It was very difficult. Is there anything different about Elixir that kind of makes it a spirit cousin of Elm and the simple Ruby? PHILIP: I think so, yes. Absolutely. I don't think it gets to the same level but I think it's in the right direction and specifically on the framework front, it was designed specifically... I mean, in a sense it's like the anti-type to Rails because it was born out of people's frustrations with Rails. José Valim was pretty much one of Rails top core committers. Basically, every Rails application I wrote at one period, at 80% of the code written by José Valim, if you included all the gems, the device and the resourceful and all the rest of it. Elixir in many ways was born out of the kind of limitations of Ruby with Rails and Phoenix was also born out of frustrations with the complexity of Rails. While it's not as simple as say, Michel Martens' Syro which is like his web framework, which is a successor to Cuba if people have heard of that, it is a step in the right direction. I don't understand it but I certainly feel like I could. They have plug which is kind of analogous but not identical to Rack but then the whole thing is built out of plugs. I remember Yehuda Katz give a presentation like 'The Next Five Years' and essentially about Rails 3.0. This is going way back and Phoenix is in some ways the manifestation of his desire to have like the Russian doll pattern, where you could nest applications inside applications and you could have them side by side and put them inside each other and things like that. Phoenix has this concept called umbrella applications which tells that, like Ecto is a really, really nice obstruction for working with the database. CHARLES:: I see. It feels like, as opposed to being functional or static versus dynamic, the question is how do you generate your complexity? How do you cope with complexity? Because I think you touched on it at the beginning of the conversation where you thought that my problems are complex so the systems that I work with to solve those problems must necessarily also be complex. I think one of the things that I've certainly realized, kind of in the later stages of my career is that first part is true. The problems that we encounter are extremely complex but you're much better served if you actually achieve that complexity by composing radically simple systems and recombining them. To the commonality of your system is going to determine how easy it's going to work with and how well it can cope with complexity. What really drives a good system is the quality of its primitives. PHILIP: Absolutely. After ElmConf, I actually invited Michel to come to my place in the Netherlands. He live in Paris but I think he grew up Buenos Aires in Argentina. To my amazement, he said, "Yes, okay," and we spent a couple of days together and there he talked to me about Christopher Alexander and the patterns book, where patterns and design patterns actually grew out of. One of his biggest things was the code is the easiest part, like you've got to spend 80% of your time thinking deeply about the problem, like literally go outside, take long looks. I'm not sure if this is what Rich Hickey means with Hammock Driven Development. I've never actually got around to watching the talk. CHARLES:: I think it's exactly what he means. PHILIP: And he said like once you get at, the code just comes. I think Michel's work, you should really check it out. I'll send you a link to put in the show notes but everything is built out of really small libraries that do one thing and do it really well. For example, he has a library like a Redis client but the Redis client also has something called Nest, which is a way to generate the keys for nested hashes. Because that's a well-designed, the Redis client is literally just a layer on top. If you understand the primitive then, you can use the library on top really well. You can embed Syro applications within Syro applications. I guess, there you also need the luxury of time and I think this is where maybe my role as VP of engineering, which is kind of my first role of that kind, comes in here which is when you're working on the commercial pressure, try to turn around to a business guy and say, "Yes, we'll solve this problem but can we take three weeks to think about it?" It's never going to happen -- CHARLES:: No. PHILIP: Absolutely, it will never going to happen. Although the small things that I tried to do day to day now is get away from the computer, write on paper, write out the problem as you understand it, attack it from different angles, think about different viewpoints, etcetera. CHARLES:: I think if you are able to quantify the cost of not thinking about it for three weeks, then the business person that you're going to talk to is their ears are going to perk up, right? But that's so hard to do. You know, I try and make like when we're saying like, "What technologies are you going to choose? What are the long term ramifications in terms of dollars or euros or whatever currency you happen to be in for making this decision?" I wish we had more support in thinking about that but it is kind of like a one-off every time. Anyway, I'm getting a little bit off track. PHILIP: No, not at all. This is a subject I love to talk about because we kind of had a few a bit of turbulence because we thought, maybe we should get product people in, maybe we should get them a product team going and what I find was -- and this is maybe unique to the size of the company -- that actually made things a lot more difficult because you got too many heads in many ways. Sometimes, it's better to give the developer all of the context so that he can think about it and come up with the best solution because ultimately, he's the only one who can understand. I wouldn't say understands the dollars and cents but he understands the cost implications of doing it in efficient ways, which often happens when you're working in larger teams. TARAS: One thing I find really interesting about this conversation is the definition of good is really complicated here. I've observed Charles work on microstates and I work with him, like I wrote a lot of the code and we got through like five or six iterations and at every point, he got better but it is so difficult to define that. Then when you start to that conversations outside of that code context and you start to introduce business into the mix, the definition of good becomes extremely complicated. What do you think about that? How do we define it in a way? Are there cultures or engineering cultures or societal cultures that have a better definition for good that is relevant to doing quality work of this? CHARLES:: That's a deep question. PHILIP: Wow. Yeah, a really, really deep question. I think often for business, like purely commercially-driven, money-oriented good is the cheapest thing that gets the job done and often that's very short term, I think. As you alluded to Charles, that people don't think about the cost of not doing the right things, so to speak in our eyes and also, there's a huge philosophical discussion whether our definition of good as programmers and people who care about our craft is even analogous to or equal to a good in a commercial context. CHARLES:: Yes, because ultimately and this is if you have read Zen in the Art of Motorcycle Maintenance, one of the things that Pirsig talks about is what is the definition of quality. How do we define something that's good or something that's bad? One of the definitions that gets put forward is how well something is fit to purpose. Unless you understand the purpose, then you can't determine quality because the purpose defines a very rich texture, a very rich surface and so, quality is going to be the object that maps very evenly and cleanly over that surface. When it comes to what people want in a program, they're going to want very different thing. A developer might need stimulation for this is something that's very new, this is something that's going to keep my interest or it's going to be keeping my CPU max and I'm going to be learning a whole lot. A solution that actually solves for that purpose is going to be a high quality solution. Also, this is going to be fast. We're going to be able to get to market very quickly. It might be one of the purposes and so, a solution that is fast and the purpose fits so it's going to be good. Also, I think developers are just self-indulgent and looking for the next best thing in something that's going to keep their interest, although we're all guilty of that. But at the same time, we're going to be the ones maintaining software, both in our current projects and collectively when we move to a new job and we're going to be responsible for someone else's code, then we're going to be paying the cost of those decisions. We both want to minimize the pain for ourselves and minimize the pain for others who are going to be coming and working in our code to make things long term maintainable. That's one axis of purpose and therefore, an axis of quality. I think in order to measure good and bad, you really have to have a good definition of what is the purpose of that surface is so rich but the more you can map it and find out where the contours lie, the more you're going to be able to determine what's good and what's bad. TARAS: It makes me think of like what is a good hammer. A sledgehammer is a really good hammer but it's not the right hammer for every job. CHARLES:: Right. TARAS: I think what you're saying is understanding what is it that you're actually doing and then matching your solution to what you're actually trying to accomplish. PHILIP: Yeah, absolutely and in my experience, we have a Ruby team building a Rails application. That's our monolith and then, we have a couple of Elixir teams with services that have been spun out of that. This isn't proven. This is just kind of gut feel right now and it is that Elixir is sometimes slower to develop the same feature or ship it but in the long term it's more maintainable. I haven't actually gotten dived into to React and all of the amazing frameworks that it has in terms of getting things up and running quickly but in terms of the full scale application, I still think 10, 11 years on, Rails has no equal in terms of proving a business case in the shortest time possible. CHARLES:: Yeah. I feel very similarly too but the question is does your development team approach the problem as proving a business case or do they approach the problem as I want to solve the set of features? PHILIP: Yes. Where I'm working at the moment, I started out just as a software developer. I guess, we would qualify for 37 signals or sorry... base camps definition of a calm company -- CHARLES:: Of a what company? PHILIP: A calm company. Sorry. They just released a new book and called 'The Calm Company' and 'It Doesn't Have to Be Crazy at Work.' I was given in my first couple of months, a problem. It was business oriented, it had to be solved but it had to be solved well from a technical perspective because we didn't want to have to return to it every time. It was standardizing the way that we exported data from the database to Excel. You know, I was amazed because it was literally, the first time that I'd been given the space to actually dive in on a technical level to do that kind of stuff. But I think even per feature, that varies and that sometimes challenging when handing the work on because you've got to say, "This fit. Literally, we're just trying to prove, whether if we have this feature, the people will use it?" versus, "This is a feature that's going to be used every day and therefore, needs to be at good, technical quality." Those are the tradeoffs that I guess, keep you in a job. Because if it was easy, then you would need anyone to figure it out but it's always a challenge. What I like is that our tools are actually getting better and I think, with Elm for example, it's kind of major selling point is maintainability and yet, with Elm, there haven't been that many companies with Elm over a period of years that exists, that can live to tell the tale. Whereas, we certainly know with Rails applications have done well like Basecamp and GitHub. For sure, they can be super maintainable but the fact that it took GitHub to just moved Elm to Rails 5.0, I belief, the fact that it took them years and years and they were running off at fork of Rails 2.3, I think it shows the scale of the problem in that way. You know, Phoenix also went through a few issues, kind of moving architectures from the classic Rails to a more demand driven design model. I think we're getting there slowly, zig-zagging towards a place where we better understand how to write software to solve business problems. I guess, I was really interested in microstates when you shared it at Wicked Good Ember because that to me was attacking the problem from the right perspective. It's like given the fact that the ecosystem is always changing. How can we extract the business logic such that these changes don't affect the logic of our application? CHARLES:: Man, we got a lot to show you. It has changed quite a bit in the last two years. Hopefully, for the better. TARAS: It's been reduced and it's almost a quarter of its size while maintaining the same feature set and it's faster, it's lazier, it's better in every respect. It's just the ideas have actually been fairly consistent. It's just the implementation that's evolved. CHARLES:: Yeah, it's been quite a journey. It parallels kind of the story that we're talking about here in the sense that it really has been a search for primitives and a search for simplification. One of the things that we've been talking about, having these Ruby gems that do one thing and do it very, very, very well or the way that Elixir being architected has some very, very good primitives or Elm, the same kind of thing being spiritually aligned, even though on the surface, it might share more in common with Haskell. There's actually a deep alignment with a thing like Ruby and that's a very surprising result. I think one of the things that appeals to me about the type of functional programming that is ironically, I guess not present in Elm, where you have the concept of these type classes but I actually think, I love them for their simplicity. I've kind of become disenchanted with things like Lodash, even though they're nominally functional. The fact that you don't have things like monoid and functors and stuff is kind of first class participants in the ecosystems, means you have to have a bunch of throwaway functions. Those API surface area is very large, whereas if you do account for those things, these kind of ways of combining data and that's how you achieve your complexity, is not by a bunch of one-off methods that are like in Lodash, they're all provided for you so you don't have or have to write them yourself. That is one level of convenience but having access to five primitives, I think that's the power of the kind of the deeper functional programming types. PHILIP: And Charles, do you think that that gives you the ability to think at a higher level, about the problems that you're solving? Would you make that link? CHARLES:: Absolutely. PHILIP: So, if we're not doing that, then we're actually doing ourselves a disservice? CHARLES:: I would say so. PHILIP: Because we're actually creating complexity, where it shouldn't exist? CHARLES:: Yeah, I think if you have a more powerful primitive, you can think of things like async functions and generator functions, there's a common thread between async functions, generator functions, promises arrays and they're all functors. For me, that's a very profound realization and there might be a deeper spiritual link between say, an async function and an array in the same way that there's a deep spiritual link between Ruby and Elm, that if you don't see that, then you're doing yourself a disservice and you're able to think at a higher level. Also, you have a smaller tool set where each tool is more powerful. PHILIP: You did a grit, I think it was a repository with a ReadMe, where you boiled down what people would term what I would term, the scary functional language down to a very simple JavaScript. Did you ever finish that? Did you get to the monads? CHARLES:: I did get to the monads, yeah. PHILIP: Okay. I need to check that out again. I find that really, really helpful because I think one of Evan's big things with Elm is he doesn't use those terms ever and he avoids them like the plague because I think he believes they come tinged with the negative experiences of people trying Haskell and essentially getting laughed at, right? CHARLES:: Yes. I think there's something to that. TARAS: But we're doing that in microstates as well, right? In microstates documentation, even though microstates are written completely with these functional primitives, on the outside, there's almost no mention of it. It's just that when you actually go to use it, if you have an idea, one of the thing that's really powerful with microstates is that this idea that you can return another microstate from a transition and what that will do is what you kind of like what a flat map would do, which is replace that particular node with the thing that you returned it with. For a lot of people, they might not know that that's like a flat map would do but a microstate will do exactly what they wanted to do when it didn't realize that's actually should just work like that. I think, a lot of the work that we've done recently is to package all things and it make it powerful and to access the concepts that it is very familiar, something you don't need to learn. You just use it and it just works for you. CHARLES:: Right but it is something that I feel like there's unharvested value for every programmer out there in these type classes: monads and monoids and functors and co-functors or covariant functors, contravariant functors, blah-blah-blah, that entire canon. I wish there was some way to reconcile the negative connotations and baggage that that has because we feel kind of the same way and I think that Evan's absolutely right. You do want to hide that or make it so that the technology is accessible without having to know those things. But in the same way, these concepts are so powerful, both in terms of just having to think less and having to write less code but also, as a tool to say, "I've got this process. Is there any way that could it be a functor? If I can find a way that this thing is a functor, I can just save myself so much time and take so many shortcuts with it." PHILIP: And in order to be able to communicate that, or at least communicate about that, you need to have terms to call these things, right? Because you can't always just refer to the code or the pattern. It's always good to have a name. I'm with you. I see value in both, like making it approachable, so the people who don't know the terms are not frightened away. But I also see value in using the terms that have always existed to refer to those things, so that things are clear and we can communicate about them. CHARLES:: Right. definitely, there's a tradeoff there. I don't know where exactly the line is but it would be nice to be able to have our cake and eat that one too. We didn't get really to talk about the type versus dynamic in the greater context of this whole conversation. We can explore that topic a little bit. PHILIP: Well, I can finish with, I think the future is typed Erlang. Maybe, that's Elm running on BEAM. CHARLES:: Whoa. What a take? Right there, folks. I love it. I love it but what makes you say that? Typed Erlang doesn't exist right now, right? PHILIP: Exactly. CHARLES:: And Elm definitely doesn't run on BEAM. PHILIP: I don't know if I'm allowed to say this. When I was at this workshop with Evan, he mentioned that and I'm not sure whether he mentioned it just as a throwaway comment or whether this is part of his 20-year plan but I think the very fact that Elm is designed around like Erlang, the signal stuff was designed around the way Erlang does communication and processes, it means I know at least he appreciates that model. From my point of view, with my experience with Elixir and Erlang in production usage, it's not huge scale but it's scale enough to need to start doing performance work on Rails and just to see how effortless things are with Elixir and with Erlang. I think Elm in the backend would be amazing but it would have to be a slightly different language, I think because the problems are different. We began this by saying that my story was a little different to the norm because I went back to the dynamic, at the dark side but for example in Elixir, I do miss types hugely. They kind of have a little bit of a hack with Erlang because they return a lot of tuples with OK and then the object. You know, it's almost like wrapping it up in a [inaudible]. There are little things and there's Dialyzer to kind of type check and I think there are a few projects which do add types to Erlang, etcetera. But I think something that works would need to be designed from the ground up to be typed and also run in the BEAM, rather than be like a squashed version of something else to fit somewhere else, if that makes sense. CHARLES:: It makes total sense. PHILIP: I think so. I recently read a book, just to finish which was 'FSharpForFunAndProfit' is his website, Scott Wlaschin, I think. It's written up with F# but it's about designing your program in a type functional language. Using the book, you could probably then just design your programs on paper and only commit to code at the end because you're thinking right down to the level of the types and the process and the pipelines, which to me sounds amazing because I could work outside. CHARLES:: Right. All right-y. I will go ahead and wrap it up. I would just like to say thank you so much, Philip for coming on and talking about your story, as unorthodox as it might be. PHILIP: Thank you. CHARLES:: Thank you, Taras. Thank you, David. TARAS: Thank you for having us. CHARLES:: That's it for Episode 113. We are the Frontside. This is The Frontside Podcast. We build applications that you can stake your future on. If that's something that you're interested in, please get in touch with us. If you have any ideas for a future podcast, things that you'd like to hear us discuss or any feedback on the things that you did here, please just let us know. Once again, thank you Mandy for putting together this wonderful podcast and now we will see you all next time.

Guests: Amanda Hickman: @amandabee | GitHub Amberley Romo: @amberleyjohanna | GitHub | Blog In this episode, Amanda Hickman and Amberley Romo talk about how they paired up to get the safety pin, spool of thread, and the knitting yarn and needles emojis approved by the Unicode Committee so that now they are available for use worldwide. They also talk about how their two path crossed, how you can pitch and get involved in making your own emojis, and detail their quest to get a regular sewing needle approved as well. Resources: Unicode Technical Committee Draft Emoji Candidates The Unicode Consortium Members Sewing-Emoji Repo Proposal for Sewing NEEDLE AND THREAD Emoji This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: ROBERT: Hello, everyone. Welcome to Episode 112 of The Frontside Podcast. I'm Robert DeLuca, a software developer here at the Frontside and I'll be your episode host. With me as co-host is Charles Lowell. Hey, Charles. CHARLES: Hello, Robert. Good morning. ROBERT: Good morning. This is an exciting podcast. Today, we're going to be discussing writing a proposal to the Unicode Committee, getting it accepted and rejected. This is basically making emojis which I think is really awesome. We have two guests today who have an amazing story, Amanda Hickman and Amberley Romo. Thank you both for joining us. You two have an amazing story that I would really love to dive into and we're going to do that today. It's about basically creating your own emoji and getting that accepted so everybody can use that and I think that's super, super cool, something that I've always kind of wanted to do as a joke and it seems like that's kind of where your stories began, so you two want to jump in and start telling? I think Amanda has a great beginning to this. AMANDA: Sure. I mean, hi and thanks for having me. I don't know where to begin and really for me, this starts with learning to sew my own clothes which is an incredibly exasperating and frustrating process that involves a lot of ripping stitches back out and starting over and Instagram was a really big part of me finding patterns and finding other people who are sewing their own clothes and learning from the process. I wanted to be able to post stuff on Instagram and it started to drive me absolutely crazy, that there's emojis for wrenches and nuts and hammers and there are no textile emoji. The best I could find was scissors which is great because cutting patterns is a place where I spend a lot of time procrastinating but that was it. I knew a woman, Jennifer 8 Lee or Jenny who had led a campaign to get the dumpling emoji into the Unicode character set. I knew she'd succeeded in that but I didn't really know much more about how that had worked. I started thinking I'm going write a sewing emoji. I can do this. I can lead this campaign. I started researching it and actually reached out to Jenny and I discovered that she has created an entire organization called... What was that called? She's created an entire organization called Emojination, where she supports people who want to develop emoji proposals. CHARLES: Before you actually found the support system, you actually made the decision that you were going to do this and you found it. You know, from my perspective, I kind of see emoji is this thing that is static, it's there, it's something that we use but the idea that I, as an individual, could actually contribute to that. I probably, having come to that fork in the road would have said, "Nah, it's just it is what it is and I can't change it." What was the process in your mind to actually say, "You know what? I'm actually going to see if I can have some effect over this process?" AMANDA: It definitely started with a lot of anger and being just consistently frustrated but I knew that someone else had already done this. It was sort of on my radar that it was actually possible to change the emoji character set. I think that if I didn't know Jenny's story and it turned out I didn't know Jenny story at all but I thought I knew Jenny story but if I didn't know that basic thing that that somebody I knew who was a mere mortal like me had gone to the Emoji Subcommittee of the Unicode Consortium and petition them to add a dumpling emoji, I am sure that I wouldn't bother. But I knew from talking to her that there was basically a process and that there were a format that they want proposal in and it's possible to write them a proposal. I knew that much just because I knew Jenny. I think at that point, when I started thinking about this, the Emoji 9 -- I should be more of an expert on that actually, on emoji releases but a new release of emoji had come out. There were a bunch of things in that release and it got a little bit of traction on Twitter. I knew that the Unicode Consortium had just announced a whole new slate of emoji, so I also was generally aware that there was some kind of process by which emoji were getting released and expanded and updated. ROBERT: That's interesting. Do you know when that started? Because it seems like Apple started to add more emojis around like iOS 7 or something but it was pretty static for a while right? Or am I wrong? AMANDA: I actually am tempted to look this up but the other piece that is not irrelevant here is that at the time, I was working at a news organization called BuzzFeed that you may have heard of -- ROBERT: Maybe, I don't know. It sounds kind of familiar. AMANDA: I do feel like people kind of know who they are. I was surrounded by emoji all the time: in BuzzFeed, in internet native of the highest order and we had to use emoji all the time and I had to figure out how to get emoji into blog post which I didn't really know how to do before that. I can put them on my phone but that was it. I was immersed in emoji already. I knew that there was a project called Emojipedia, that was a whole kind of encyclopedia of emoji. One of my colleagues at BuzzFeed, a woman named Nicole Nguyen had written a really great article about the variation in the dance emoji. If you look at the dance emoji, one of the icons that some devices use is this kind of woman with her skirt flipping out behind her that looks like she's probably dancing a tango and then one of the icons that other character sets use and other devices use is a sort of round, yellow lumping figure with a rose in its mouth that you sort of want to hug but it's definitely not to impress you with its tango skill. She had written this whole article about how funny it was that you might send someone this very cute dumpling man with [inaudible] and what they would see was sexy tango woman. I think there was some discussion, it was around that time also that Apple replaced the gun emoji with a water gun. There was some discussion of the direction that the various emoji's face. One of the things that I learned around that time was that every device manufacturer produces their own character set that's native to their devices and they look very different. That means that there's a really big difference between putting a kind of like frustrated face with a gun pointing at it, which I don't really think of it as very funny but that sort of like, "I'm going to shoot myself" is very different from pointing the gun the other way which is very much like, "I'm shooting someone else," so these distinctions, what it means that the gun emoji can point two different ways when it gets used was also a conversation that was happening. None of that answers your question, though which is when did the kind of rapid expanse of emoji start to happen. ROBERT: I feel like the story is setting in the place there, though because it seems like there's a little bit of tension there that we're all kind of diverging here a little bit and it's sort of driving back towards maybe standardization. AMANDA: There's actually, as far as I know, no real move toward standardization but the Unicode Consortium has this committee that actually has representatives from definitely Apple and Microsoft and Google and I forget who else on the consortium. Jenny 8 Lee is now on the consortium and she's on the Emoji Subcommittee but they actually do get together and debate the merits of adding additional emoji, whether they're going to be representative. One of the criteria is longevity and I tend to think of this as the pager problem. There is indeed a pager emoji and I think that the Unicode Consortium wants to avoid approving a pager emoji because that was definitely a short-lived device. CHARLES: Right. I'm surprised that it actually made it. Emoji must be older than most people realize. AMANDA: My understanding is that very early Japanese computers had lots emoji. There's a lot of different Japanese holidays that are represented in emoji, a lot of Japanese food as well are represented in emoji, so if you look through the foods, there's a handful of things that haven't added recently but a lot of the original emoji definitely covered Japanese cuisine very well. ROBERT: I definitely remember when I got my first iPhone that could install iPhone OS 2, you would install an app from the App Store that then would allow you to go toggle on the emoji keyboard but you had to install an app to do it and that's kind of where the revolution started, for me at least. I remember everybody starting to sending these things around. AMANDA: But if you look at Emojipedia, which has a nice kind of rundown of historical versions of the Unicodes, back in 1999, they added what I think of as the interrobang, which is the exclamation/question mark together and a couple of different Syriac crosses. Over the years, the committee has added a whole series of wording icons and flags that all make sense but then, it is around, I would say 2014, 2015 that you start to get the zipper mouth and rolling your eyes and nerd face and all of the things that are used in conversation now -- the unicorn face. ROBERT: My regular emojis. AMANDA: Exactly. CHARLES: It certainly seems like the push to put more textile emoji ought to clear the hurdle for longevity, seeing there's kind of like, what? Several millennia of history there? And just kind of how tightly woven -- pun intended -- those things are into the human experience, right? AMANDA: Definitely. Although technically, there's still no weaving emojis. CHARLES: There's no loom? AMANDA: There's no loom and I think that a loom would be pretty hard to represent in a little 8-bit graphic but -- CHARLES: What are the constraints around? Because ultimately, we've already kind of touched on that the emoji themselves, their abstract representations and there are a couple of examples like the dancing one where the representation can vary quite widely. How do they put constraints around the representation versus the abstract concept? AMANDA: You don't have to provide a graphic but it definitely kind of smooths the path if you do and it has to be something that's representable in that little bitty square that you get. It has to be something representable in a letter-size square. If it's not something that you can clearly see at that size, it's not going to be approved. If it's not something you can clearly illustrate at that size in a way that's clearly distinct from any other emoji and also that's clearly distinct from anything else of that image could be, it's not going to be approved. Being able to actually represented in that little bitty size and I don't know... One of sort of sad fact of having ultimately worked with Emojination on the approval process is that we were assigned an illustrator and she did some illustrations for us and I never had to look at what the constraints were for the illustration because it wasn't my problem. ROBERT: Sometimes, that's really nice. AMANDA: Yes, it's very nice. I ended up doing a lot of research. What made me really sad and I don't want to jump too far ahead but one of things that made me really sad is we proposed the slate and the one thing that didn't get approved was the sewing needle and it also didn't get rejected, so it's in the sort of strange nether space. That's kind of stuck in purgatory right now. I did all this research and learned that the oldest known sewing needle is a Neanderthal needle so it predates Homo sapiens and it's 50,000 years old. CHARLES: Yeah. Not having a sewing needle just seem absurd. AMANDA: Yeah. We have been sewing with needles since before we were actually human being. ROBERT: That's a strong case. AMANDA: Yes, that's what I thought. If I sort go back to my narrative arc, I wanted to do a sewing needle and started researching it a little bit -- CHARLES: Sorry to keep you interrupting but that's literally the one that started this whole journey. AMANDA: Yes, I wanted a sewing needle and I really wanted a sewing needle. I did a little research and then I reach out to Jenny and to ask her if she had any advice. She said, "You should join my Slack," and I was like, "Oh, okay. That's the kind of advice." She and I talked about it and she said that she thought that it made more sense to propose a kind of bundle of textile emoji and I decided to do that. She and I talked it through and I think the original was probably something closer to knitting than yarn but we said knitting, a safety pin, thread and needle were the ones that kind of made the most sense. I set about writing these four proposals and one of the things that they asked for was frequently requested. One other thing that I will say about the proposal format is that they have this outline structure that is grammatically very wonky. They ask you to assert the images distinctiveness and they also ask you to demonstrate that it is frequently requested. I found a couple of really interesting resources. One, Emojipedia which is this sort of encyclopedia of emoji images and history maintains a list of the top emoji requests. I actually don't know how they generate that list or who's requesting that and where but I think it's things that they get emailed about and things people request in other contexts and sewing and knitting, I've done on that list and I started compiling it in 2016. ROBERT: To be a part of the proposal process, to show that it is requested, without that resource, you just start scouring Facebook and Twitter and history and shouting to people like, "I really want this emoji. Why it didn't exist?" That seems pretty hard. AMANDA: Actually our proposals all have Twitter screen shots of people grousing about the absence of knitting emoji and yarn emoji and sewing emoji. I know that Emojipedia, they do a bunch of research so they go out and look at based what people are grousing about on Twitter. They look at places where people are publicly saying like, "It's crazy that there's no X emoji," and that's part of their process for deciding what kinds of emojis people are asking for. Their research was one resource but we took screenshots of people saying that they needed a safety pin emoji and that was part of making the case. One of the things that I found as I was doing that research was that, I guess at this point it was almost two years ago, when the character set that included the dumpling emoji came out, there was a bunch of grousing from people saying, "Why is there not a yarn emoji?" There was a writing campaign that I think Lion Brand had adopted. Lion Brand yarn had put in this tweet saying like, "Everyone should complain. We needed a yarn emoji," but it doesn't matter how much you yell on Twitter. If you don't actually write a proposal, you're not going to get anywhere. I had been told that the Emoji Subcommittee, they're really disinclined to accept proposals that had a corporate sponsor, so they weren't going to create a yarn emoji because Lion Brand yarns wanted them to create a yarn emoji. ROBERT: Right, so it was like counter-peer proposal. AMANDA: Right. But as I was digging around the other thing I found was this woman in... I actually don't know if you're in Dallas or Austin but I found Amberley, who also put a post on Twitter and had started a petition, asking people to sign her petition for a yarn emoji proposal or a knitting emoji. I don't remember if it was a yarn emoji or a knitting emoji but I found her petition and reached out to her to ask if she was interested in co-authoring the proposal with me because she had clearly done the work. She actually had figured out how the system worked at that point. I think she knew who she was petitioning, at least. I reached out to Amberley and we worked together to refine our proposal and figure out what exactly we wanted to request. I think there were a bunch of things that were on the original list like knitting needles, yarn and needles. I think crocheting would have been on the original list. We were sort of trying to figure out what was the right set of requests that actually made sense. ROBERT: So then, this is where Amberley stories comes in and it is interesting too because she has entirely different angle for this. Maybe not entirely different but different than outright. This kind of ties back to the word software podcast mostly. It kind of ties back to the software aspect, right? AMBERLEY: Yeah. I think, really they're kind of separate stories on parallel tracks. My motivation was also two-fold like Amanda's was, where I started knitting in 2013 and I had a really good group of nerd friends with a little yarn shop up in DC, like a stitch and ditch group -- ROBERT: I love it. AMBERLEY: It was a constant sort of like, where's the insert emoji here, like where's the yarn emoji? Where's the knitting emoji? And we would sort of sarcastically use the spaghetti emoji because it was the most visually similar but that was something that was in the back of my mind but it teaches you a lot about yourself too because I was like, "Oh, this is like fiber art, not really an emoji. It's kind of technical, like on a tech space," and I didn't really connect that it was relevant or that I might have any power to change it. It just didn't occur to me at the time. ROBERT: Interesting. I feel like a lot of people are in that similar situation or maybe not situation, even though you can make change on this. AMBERLEY: Right, so my brain didn't even make it like, "Why isn't this a thing? let me look at how to make the thing." When that happened for me, Amanda mentioned using emoji and everything in the BuzzFeed space. I love how you explained BuzzFeed a while ago, it's my favorite description of BuzzFeed I ever heard. Something similar that happened for me was I was a software developer and in 2016, the Yarn package manager was released and that kind of turned something on in my head. That was like I'm seeing all these software engineers now be like, "Where's the yarn emoji?" and I'm like, "Welcome to the club." ROBERT: "Do you want to join our Slack? We can complain together." AMBERLEY: Right. It has been like a pretty decent amount of time, I'm semi-seriously ranting and complaining to my coworkers who were primarily male software engineers. I remember I went to [inaudible] in the Frost Bank Tower after work and was just like, "I'm going to figure out how this happens," and I spent a couple hours at the coffee shop. I found the Unicode site and I found their proposal process and their structure for the proposal and everything and I just started doing the research and drafting up a proposal specifically for yarn. Maybe it was a bit naive of me but to me it was like, "Okay, here's the process. I follow the process. Cool." I mean, you have to make a case and it has to be compelling and has to be well-written and it has to be supported and all that and that to me it was like, "Okay, there's a process. At the same time, I did read about the dumpling emoji but I didn't connect it to Emojination and they had started the Kickstarter. We should talk about this later but I think the sort of idea the issue of representation on the committee and who gets to define language is really interesting but I saw that they had done the Kickstarter and there was a campaign aspect to it, so I ended up just building up this simple site so that if anyone Google, they would find yarn emoji. It's still up at YarnEmoji.com and that was how Amanda found me. I got this random email, I sort of like had this burst of energy and I did all the research and I wrote the draft, sort of piecemeal, filling out the different sections of the way they have it outlined on the Unicode site and then I feel like a month or two went by and I had kind of not looked at it for a bit and then, I get this random email from this website that I almost forgot about. It was like, "Hey, I'm working on this series of proposals. If you're working on knitting or yarn or whatever, maybe we could work together," and I was like, "Well, that's sweet." Then she opened up this whole world to me. There's this whole Emojination organization, sort of 100% devoted to democratizing the process of language formation through creating emojis and so then, I got really into that. My primary motivator was yarn. CHARLES: So what's the status of the yarn spool, those emoji right now? AMBERLEY: The yarn, the spool of thread and the safety pin, they're all approved emoji for the 2018 released. Amanda and I are actually at the end. Amanda, a couple of months ago when I saw someone used the spool thread emoji for a Twitter thread -- you know how people will be like all caps thread and have a thread of tweets -- I saw someone do that just out of the blue. I was like, "Oh, my God. Is it out?" and the thing about these individual vendors, it sort of gets released piecemeal, so at the time Twitter have I think released their versions of this series of new emoji but others hadn't. CHARLES: How does that work? Because you think the Twitter would be kind of device depending on what browser you're using, like if you're on a Windows or a Mac or a Linux Box, right? ROBERT: -- Emoji set, right? I know Facebook does this too. AMBERLEY: I'm painfully aware that Facebook does it because I can't use the crossed finger emoji on Facebook because it actually gives me nightmares. ROBERT: I have to go look at this now. AMBERLEY: Because it's so creepy-looking. CHARLES: Okay. Also like Slack, for example is another. It's like a software-provided emoji set. AMANDA: Right. AMBERLEY: I'm not totally sure that Slack actually adheres to the standard Unicode set. I think it's kind of its own thing but I might be wrong about that. AMANDA: Sorry, Slack definitely supports the full Unicode set. They also have a bunch of emoji that they've added that aren't part of the set. AMBERLEY: Slack emojis? AMANDA: Yes. CHARLES: Yeah and then every Slack also has its kind of local Slack emoji. AMBERLEY: Right. CHARLES: But how does that work with --? ROBERT: Okay, this crossed-finger Facebook emoji is... yes, I agree with you, Amberley. AMBERLEY: Thank you. I had yet to find someone who disagrees with me about that. AMANDA: I have never seen it before and I'm now like, "What is going on?" CHARLES: Yeah, so how does it work if a vendor like Twitter is using a different emoji set? How does that work with cut and paste, like if I want to copy the content of one tweet into something else? Are they using an image there? AMANDA: They're using an image. I think it's doesn't happen as much anymore but for a long time, I would often get texts from people and the text message would have that little box with a little code point in it and you were like -- AMBERLEY: More like an alien thing? AMANDA: Yeah. Definitely, if you don't have the emoji character set that includes the glyph that you're looking at, you're going to get that little box that has a description of the code point and I think what's happening is that Twitter is using JavaScript or generally programming. There were air quotes but you can't see. Twitter is using their software to sub in their emoji glyph whenever someone enters that code point. Even if you don't have the most up to date Unicode on your computer, you can still see those in Twitter. If I copy and paste it into a text editor on my computer, what I'm going to see is my little box that says '01F9F5' in it but if I get it into Twitter, it shows up. I can see them on Twitter but I can't see them anywhere else. AMBERLEY: Damn, you really have the code point memorized? AMANDA: No, I -- CHARLES: Oh, man. I was really hoping -- AMBERLEY: Oh, man. ROBERT: You live and breathe it. AMANDA: No, I'm not that compulsive. AMBERLEY: We definitely have our emojis on our Twitter bios, though. AMANDA: Absolutely. ROBERT: If you see Amanda's bio, it's pretty great. AMANDA: They started showing up on Twitter and I think that somebody in Emojination probably told me they were out and that was when I first started using them. Amberley might have actually seen it. It sounds like you just saw it in the wild, which is kind of amazing. AMBERLEY: I saw it in the wild with this tweet thread and yeah, it's just [inaudible]. I was like, "Amanda, is it out?" CHARLES: Yeah, I feel like I saw that same usage too, although I obviously did not connect any dots. AMANDA: This last week, October 2nd -- I'm also looking things up. I'm just going to come to the fact that I am on a computer looking things up so I can fact check myself -- after they actually released their emoji glyph set, so by now any updated iOS device should have the full 2018 emoji, which in addition to a kind of amazing chunky yarn and safety pin, there's also a bunch of stuff. There's a broom and a laundry basket. There's a bunch of really basic, kind of household stuff that certainly belongs in the character set alongside wrenches and hammers. AMBERLEY: I think one of the big ones too for this year was the hijab? AMANDA: No, the hijab actually came out with a dumpling. Hijab has been available -- AMBERLEY: It's been up, okay. ROBERT: So did it come with iOS 12 or 12.1? I don't know for sure. I just know -- AMANDA: I'm looking at it and it's 12.1. I really feel that I should be ashamed that I have used the internet and search for this. AMBERLEY: I would say, I have no idea what their release numbers are. AMANDA: [inaudible] as it appeared for the first time in iOS for 2018 with today's release of the iOS 12.1, Beta 2 for developers. ROBERT: That is amazing. Do you get some kind of satisfaction -- like you have to, right? -- from people using the emoji and it's starting to make its way out there? AMANDA: So much. Oh, my God, yeah. AMBERLEY: I didn't really expect it, like saying that random tweet using this spool of thread for a tweet thread. I just thought and I just got so psyched. For me, I'm a knitter. I have knitter friends and it started with yarn and then really, Amanda and through Amanda, Jenny really sort of broadened my idea of what it all really meant. To think someone using it in the wild for a totally different application than I had ever thought of was like, "That's legit." AMANDA: I definitely have a sewing emoji search in my tweet deck and sometimes, when I'm feeling I need a little self-validation, I'll go look over there and find people who are saying things like, "Why is there no sewing emoji?" and I'll just reply with all the sewing emoji, like it is part of my work in this life to make sure that not only do they exist but people know about them. ROBERT: That is awesome. I would do the same thing, though to be honest. You'll be proud of that. AMANDA: Totally. ROBERT: Were there any hitches in the proposal process? I know we're kind of alluded to it but the thing that you started off one thing, Amanda didn't make it. Right? AMANDA: I know. ROBERT: So how did that process happen from you two meet each other and then going through the actual committee and the review process and then being accepted. What would that mean? AMANDA: The process is actually incredibly opaque. We wrote this whole proposal, a bunch of people edited it, which is one of the other nice things about collaborating with Emojination. There was a bunch of people who are just really excited about emoji and the kind of language making that Amberley was talking about. There's a whole bunch of people who just jumped in and gave us copy edits and feedback, which was super helpful and then, there was a deadline and we submitted it to the committee and it actually shows up in the Unicode register which is also a very official kind of document register. I was a little excited about that too but then they have their meeting. They first have a meeting and there's like a rough pass and the Emoji Subcommittee makes formal recommendations to the Unicode Consortium and then the consortium votes to accept or reject the Emoji Subcommittee's recommendations. It's a very long process but unless you're going and checking the document file and meeting minutes from the Unicode Consortium meetings, you'll never going to know that it happen. AMBERLEY: -- You know someone connected through there because one of the things in our first pass, it wasn't that it was rejected. It was that we needed to modify something. We do have art for knitting needles with yarn because at one point, I think we weren't totally sure that a ball of yarn would be visually distinct enough in this emoji size to look like yarn and so, we had put it with sort of knit piece on knitting needles. AMANDA: Oh, that's right. There was a tease of a little bit of knitted fabric. AMBERLEY: Right and I think that, probably through Jenny or the people actually in the room, the feedback I remember is that there is a crocheter in the room who was like, "Yeah, why isn't there a yarn emoji but knitting needle?" so there was a little bit of like that was how I think we ended up from knitting needles with a fiber piece to ball of yarn, maybe. AMANDA: I think that sounds right. I'm actually sure of that. It's just all coincide with my recollection. There were some things that they had questions about and that happened really fast because I feel like we had a couple of days and they have stuck to our guns and said, "No, we're only interested in knitted bit of fabric." Also, we worked with an illustrator and went back and forth with her because the initial piece that she had illustrated, I feel like the knitting needles were crossing in a way. That was not how knitting works and so, there was a little bit of back and forth around that as well. But then once they decided that the they like the thread, yarn and safety pin, we're going to move to the next stage. I actually had to go back and look at the minutes to find out that the two reasons that they didn't move the sewing needle on to the next stage is when they thought it was adequately represented by the thread, which I wholeheartedly disagree with and they thought it wasn't visually distinctive. That's so much harder because a sewing needle, which is really just a very fine piece of metal with an eye at the end, you get down to a really small size and it is maybe a little hard to know what you're looking at. But I think there's such a big difference between the static object which is the spool or the thread which represents a lot of things and is important and the needle, which is the active tool that you use to do the making, to do the mending, to do the cobbling. CHARLES: Yeah. I'm surprised that it almost isn't reversed when certainly in my mind, which I think is more culturally important in terms of the number of places which it appears, it's definitely the needle as being kind of... Yeah. AMANDA: Yeah and I think that the thread and yarn, they're important and I think that the decision to have a ball of yarn rather than a bit of knitting makes sense because there's a lot of things that you can use a ball of yarn that aren't just knitting and they think that -- AMBERLEY: And it's the first step too that doesn't exclude anyone in the fiber art community. AMANDA: But there's so many things like in sutures and closing wounds, you're not using a little spool of cotton thread for that or polyester thread and stuff like embroidery and beadwork, you might be using thread or fiber of some sort that started on a spool but you might not. Embroidery floss was not sold in a spool and there's all these places where we use needles and all kinds of different size and you don't always use thread. Sometimes, you're using yarn. Sometimes, you're using leather cord. Sometimes, you're using new bits of, I would say Yucca. You're using plant fibers to do baskets and in all of these different practices, that process of hooking it through the eye and sewing it is how it's actually made. It still sort of mystifies me why they haven't accepted it but they also didn't reject it, which is really interesting. I don't know how many other emoji are sort of sitting in this weird nether space because sometimes they just reject them outright. I think there was a proposal for a coin that they just said no. ROBERT: They were a like, "A coin?" That would be [inaudible]. AMANDA: Oh, God. ROBERT: They have to add one for every -- AMANDA: [inaudible]. CHARLES: Literally, the pager of 2017. AMANDA: Exactly. CHARLES: So what recourse is now available to you all and to us, by extension, to get the sewing needle? AMANDA: I'm actually working on a revised proposal and I've been trying to figure out what are all the arguments that I'm missing for why sewing and the needle are not adequately represented by the thread and yarn. A bunch of things that a friend of my named, Mari who's half-Japanese, half-American but lives in Guatemala and does all this kind of arts in textile work, pointed out that there's a whole holiday in Japan devoted to bringing your broken needles and thanking them for their service. I thought that was really cool. I've been trying to formulate what are all of the arguments for the necessity of both a needle and a spool. If anybody has interesting ways to phrase that, I would love for arguments. CHARLES: Yeah but it's hard to imagine the arguments is just anything being more compelling than the arguments the you just laid out that you named about seven context: shoemaking, medicine, different fibers where the needle operates completely and totally independent of the thread. It's looming so large in kind of our collective conscious like holidays, being dedicated to them, except I think the Cro-Magnon pager, which is made out of stone, I believe, the being the artifact that pre-dates... AMANDA: There's the idiom landscape as well. Things like finding a needle in a haystack, that has a very specific meaning -- ROBERT: And for puns. I've been resisting saying a pun this whole time. AMANDA: Oh, share your pun with us. AMBERLEY: Yeah, you have to say it. ROBERT: Well, you could say that trying to get this through the committee is like threading a needle. Butchered but -- AMANDA: There's a biblical quote about getting into heaven -- a camel through the eye of a needle. I forget actually how it... CHARLES: To thread a camel through the eye of a needle than for a rich man to get into heaven. AMANDA: Exactly and there's this sort of do-re-mi, saw, a needle pulling thread. There are all these places where it's about the needle and somebody had -- CHARLES: It's primarily ancient. AMANDA: I know. CHARLES: It is the prime actor. Maybe, this is a good segue into kind of talking about the makeup of the committee and the decision making process and these kind of what seem like very clear arguments might not be received as such. AMANDA: I certainly don't want to say anything bad about anybody on the committee. CHARLES: No, no, I don't think that there's anything bad. I think that being receptive to things which are familiar to us versus with things that aren't is a very natural human thing and it can be interesting to see that at work and at play. AMANDA: The Unicode Consortium is also evaluating all of these requests for whole language glyphs sets. Lots of languages and lots of character sets that are kind of obvious, like there has to be a sort of like character set like there has to be an Arabic character set but there are a lot of languages that have been left out of that because they're very small minority languages or they are historical languages, where the actual writing is no longer written the same way but there's historical reasons to be able to represent those characters. One of the reasons why the Emoji Subcommittee cares about what gets into the formal character set is that everybody has to accommodate it and there's already been, I think some grousing. People start to moan and groan about how there's too many emoji, then it's too hard to find things. CHARLES: And there's no take backs. AMANDA: There's no take backs. You can't undo it. The committee is made up of representatives from a lot of tech companies primarily, although there's a couple of other kind of odd additional folks on there. I do try to find the committee list and I can find it right now. AMBERLEY: I have it from Emojination. I don't know if it's up to date but Oracle, IBM, Microsoft, Adobe, Apple, Google, Facebook, Shopify and Netflix. The other voting members -- ROBERT: Shopify? AMBERLEY: Yeah, right? The others being the German software company, SAP and the Chinese telecom company, Huawei and the Government of Oman. AMANDA: Yeah, the Government of Oman is a fascinating one. I don't think they're the ones that are biting us on this. Especially for those tech companies, every time the emoji character set adds 10 or 12 emoji, they don't have to accommodate it on their devices. They have to put illustrators on it, they have to deal with everyone saying that the crossed fingers emoji in Facebook looks like I-don't-even-know-what. AMBERLEY: Hey, Amanda. AMANDA: It's all your fault. There's a whole process and there's non-trivial work associated with every single new emoji, so wanting to put the brakes on a little bit and be intentional about where and when they apply that work, it doesn't seem crazy to me. I just want them to approve the thing that I want. AMBERLEY: I like the way that Emojination captures it. I looked at their website earlier and actually, they take it down but their goal quote "Emojination wants to make emoji approval an inclusive representative process." There has to be a process. There's overhead involved but looking at the makeup of the decision makers are not a trivial question. CHARLES: Right. This is a great example like [inaudible] metaphor but these little artifacts, these emojis are literally being woven to the fabric of a global culture and certainly, everybody uses them and they become part of the collective subconscious. It does seem like very important to be democratic in some way. It sounds like there is a process but making sure that everyone has a stake. AMBERLEY: Yeah. ROBERT: What was the reason that they gave for not accepting the needle and thread? Was it like a soft no? You said it's like just hanging out, not really rejected but not accepted. We're going to drop a link in the show notes for the proposal and your GitHub and everything. I'm looking at the PDF that was put together and it seems like it was all a package deal like we talked about. How do they just draw or they just take like a lawyer would, just like draw or cross it out like, "Well, no but we'll take the other ones." AMANDA: Yes, basically. What they did is they need to discuss and I don't know how long they've been meeting but they need to discuss all of the proposals that have been supplied by a particular deadline and -- ROBERT: That sounds painful. AMANDA: Yeah, I mean, it's -- ROBERT: Just imagine the power of thinking about emojis. AMANDA: One of the things that they rejected, I think because there's the smiling poo face. Somebody wanted a frowning poo face and they rejected that. There's a bunch of things that actually do get rejected. I don't know if they've been really care about a smiling poo face versus a frowning poo face. ROBERT: What about an angry one? AMANDA: We got all the feelings of poo. ROBERT: We got important work to do here. AMANDA: But they go through when they're trying to figure out. I think to some degree, you want to get them when they're not tired but I think the status that it's listed right now is committee pushback, so they've set it aside until we have some concerns. We're not going to reject it outright but we're not really sure why this isn't adequately represented. Then their most recent meeting, they just kind of passed on reconsidering it, which is fine because I think I was traveling and my proposal is not done. I really want to make sure that I have consolidated every imaginable argument in one place so -- ROBERT: And make it strong as possible. AMANDA: Yeah. If people want to help the other thing that would be amazing is any and all idioms that you can think of, especially ones that are not in English or European languages, idioms in Central European languages, idioms in Asian languages that refer to needles, either translations of the kind of classic, 'finding a needle in a haystack,' but also any idioms that are kind of unusual and specific to a culture outside of what I have experience with would be amazing for making the case, so this is an international need. ROBERT: Do they need any specific or actionable feedback or do they just say, "We're going to push back on this. We're just not quite sure?" AMANDA: The two things that we're in the minutes -- there are minutes and they publish the minutes to Unicode.org -- were it was not visually distinct, which is not totally crazy. We actually worked with an illustrator to get a different image. The first image was almost at 90 degrees. It was kind of straight up and down and it is a little hard to see and the second is -- ROBERT: Especially, because it's thin. AMANDA: The second image is actually a kind of stylized needle because it's fairly a little fatter and the eye is bigger but it's much more distinctively a needle. I'm hoping that that will also convince them but you have to be able to tell at a very small size that it's a needle. The other thing that they said was that sewing was already represented by the thread, that we didn't need thread and needle but it was literally one line in the minutes that referenced that and then it sort of like, "Did you have somebody in the room or not?" and so, if there is somebody on the committee who is willing to tell you really what their concerns were, then you have some sense of what they're looking for and why they're pushing back. When you can very much see in the earliest emoji character sets that I have a hammer and I have a wrench and I use them but there's these very conventionally male tools. We have all of the kind of office supplies but all of homemaking and housekeeping and textile production, none of them were there until very, very recently. I think it does reflect the gender of the people who've been making these tools, that sewing and knitting weren't important enough as human practices to be included in this glyph set. AMBERLEY: I guess, that's non-trivial to mention because that wasn't an argument that I made in my original yarn draft and Amanda and Jenny sort of pushing to open it up to this whole slate of craft emoji. I didn't realize until they brought that up. I took a stroll through pretty much the whole slate of emoji and you can count on almost one hand the number that represented the creative endeavors or sort of more traditionally known as creative things like camera or painting palette and stuff like that. It was extremely limited. AMANDA: I think they have stuff like that. I think there's a few different variations on the camera and then there's painting palette and that's it. AMBERLEY: Oh, there's the theater mask. AMANDA: Oh, that's right. There is the theater, the happy and sad -- AMBERLEY: And I don't know it exactly and I haven't read the minutes like Amanda has but I think and I hope that that was a particularly compelling piece of that argument. AMANDA: I think they definitely heard it. AMBERLEY: Yeah. CHARLES: Opening it up then, what else is coming in the way of craft? It sounds like this is historical but these pieces are being filled in not only with the work that you all are doing but by other emoji which you're appearing. AMANDA: Yes. CHARLES: And are you in contact with other people who are kind of associated with maybe craft and textiles and other kind of what you're labeling historically creative spaces? AMANDA: I don't think there are anymore with a possible exception. Someone's working on a vinyl record proposal which I think is great. CHARLES: Yeah, that's awesome. ROBERT: Antiquated, though. AMANDA: Maybe not, I don't know. AMBERLEY: Take a stroll through the Emojination Slack and people discussed that. AMANDA: Yeah. If you click at Emojination.org, the whole Airtable database is on there. There's not a lot of other creative ones. A friend of mine got really bent out of shape about the lack of alliums and wrote a whole slate proposal for leeks and scallions and garlic and onions. ROBERT: Oh, there is a garlic one, right? AMANDA: No. I mean, there is -- AMBERLEY: Actually, I'm looking at the Unicode page for current emoji candidates. They first get listed as... I forget the exact order. They become draft candidates and then provisional candidates or vice versa but I don't see any pending further creative ones but garlic and onion are on there. AMANDA: Yes. ROBERT: That makes my Italian a little happy. AMANDA: I think there's some prosthesis, the mechanical leg and the mechanical arm, a guide dog -- AMBERLEY: Ear with hearing aid, service dog. AMANDA: Yeah, there's a good chunk of interesting things that have been left out. I guess they've been approved by the subcommittee but are still waiting on final approval by the Unicode Consortium. ROBERT: Okay. What are the next steps that we can do to help push the thread and needle proposal through it. You mentioned a couple things like coming up with idioms that are in different languages and whatnot but how can we contact you and push this effort and help? AMANDA: That's such a good question. I don't even know. I mean, I am Amanda@velociraptor.info and you're totally welcome to email me if you want to help with this and I will -- ROBERT: That's a great domain, by the way. AMANDA: Unfortunately, there's no information about velociraptors anywhere on that site. ROBERT: That's the way it should be. AMANDA: But also, if you're excited about working on emoji proposals, Emojination is an incredibly great resource and folks there, including me actually will help you identify things that are on other people's wish lists that you could work on if you just want to work on something and we'll help you refine your proposal if you know what you want and we'll help you figure out whether it's worth putting the time in or not and how to make it compelling. You can definitely check out Emojination.org. I think there's a path to get on to the Slack from there. AMBERLEY: Oh, yeah. The Slack and the Airtable. AMANDA: Yeah. ROBERT: It sounds like there's a whole community that was born out of this, where everybody is trying to help each other and collaborate and get their shared ideas across. AMANDA: Definitely and there's a woman, Melissa Thermidor who is fantastic, who actually is a social media coordinator. It's her actual title but she works for the National Health Service in the UK and was tasked with getting a whole series of health-related emoji passed. There's a bunch of things that she's -- AMBERLEY: Is she's the one doing blood. AMANDA: She's doing blood. AMBERLEY: That's a good one. AMANDA: Because there's a lot of really important health reasons why you need to be able to talk about blood and getting blood and blood borne illnesses and -- AMBERLEY: That one was listed on the emoji candidate page or blood donation medicine administration. AMANDA: Yeah. ROBERT: That's really interesting, so she works for the government, right? and that was part of her job to do that? AMANDA: Yes. ROBERT: That's awesome, actually. I love that. AMANDA: Yeah, I think the drop of blood, the bandage and the stethoscope are the three that are in the current iteration, which is interesting because the existing medical emoji were the pill and that gruesome syringe with a little drops of fluid flying off of it, which do not do a lot to encourage people to go to the doctor. ROBERT: No, not at all. AMANDA: So a few more, we're welcoming medical emoji. ROBERT: You have a GitHub. Is that where you're still doing for the follow up and the prep work for the sewing emoji? AMANDA: Yeah, that's probably the best place. I do have a Google Docs somewhere but that's probably a better place to connect even than my ridiculous Velociraptor email. The GitHub -- ROBERT: But it's still awesome. AMANDA: It is awesome. I won't lie. I'm very proud of it. I am AmandaBee -- like the Bumble Bee -- on GitHub and the sewing emoji, the original proposals are there and I will make sure that there is information about how to plug into the revised needle proposal there as well. You guys are a tech podcast, so if people want to just submit suggestions as issues on that repository, that's awesome. We'll totally take suggestions that way. ROBERT: That would be pretty rad. Well, I appreciate you two being on the podcast. I love hearing your stories and how it ended up converging in parallel tracks but it end up achieving the same goal. Still unfinished, right? Let's see if we can help push this over the finish line and get it done because I would really like to see a needle. I could definitely use that in many of my conversations already now, making all kinds of puns. Thank you, Amanda for coming on and sharing your story. AMANDA: Thanks for having me. ROBERT: And thank you, Amberley for also coming on and sharing your story. This was super awesome. AMBERLEY: Yeah and thank you for connecting us to finally have a voice conversation. AMANDA: I know. It's great to actually talk to you, Amberley. CHARLES: Oh, wow, this is the first time that you actually talked in audio? AMANDA & AMBERLEY: Yeah. ROBERT: We're making things happen here. The next thing we have to do is get this proposal through and accepted. AMANDA: Yes. CHARLES: You've converted two new faithful sewing and needle partisans here and I'm in. AMANDA: Awesome. ROBERT: I know you've already gotten, what? Three through accepted? AMANDA: Yeah. ROBERT: We talked about that, it's got to be really awesome. I think I want to try and jump in and get that same satisfaction because a lot of people use emojis. AMANDA: Exactly. CHARLES: It definitely makes me think like you look at every single emoji and there's definitely a story. Especially for the ones that have been added more recently, there's a lot of work that goes into every single pixel. That represents a lot of human time, which I'm sure you all know, so thank you. AMANDA: Thanks for having us on. AMBERLEY: Yeah, thank you guys. ROBERT: Cool. That is the podcast. We are Frontside. We build UI that you can stick your future on. I really love this podcast because it wasn't necessarily technical but had a lot of interesting conversation about how to work with a proposal and probably make a bigger impact than any of us with software, just because the sheer reach that emojis have are insane and the fact that you can influence this process is new to me and really cool, so I hope a lot of other people learn from that too. If you have any feedback that you would like to give us on the podcast, we're always open to receive feedback. We have our doors and ears open, so if you like to send an email at Contact@Frontside.io or shoot us a tweet or DM us at @TheFrontside on Twitter. We'd love to hear it. Thank you, Mandy for producing the podcast. She always does an amazing job with it. You can follow her on Twitter at @TheRubyRep. Thanks and have a good one.

In this episode, Robert, Charles, and Wil talk about the whys and hows of accessibility, as well as what makes single page applications special, why they are they harder for accessibility, and frameworks that can do this for you. Resources: #SkyQ app on #iOS from a #VoiceOver user's Perspective Rob's Routing Doc Wil's PR Single Page Apps routers are broken Greater Than Code Episode #92: A11y Ally with Rob DeLuca This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: ROBERT: Hello everyone. Welcome to The Frontside Podcast. This is Episode 111. I'm Robert DeLuca, a software developer here at the Frontside and I'll be your episode host. Today, we're going to be discussing accessibility in single page apps. With me as co-hosts are Charles Lowell. Hey, Charles. CHARLES: What is up Robert? ROBERT: And Wil Wilsman. Hey, Wil. WIL: Yo, yo, yo, yo. ROBERT: Sounds like we're ready to drop a disc track. We're not going to be dissing anybody here. We're going to be talking about helpful things with accessibility in single page apps. Before we get into the nitty-gritty of accessibility in single page apps because we're getting into some deep stuff, I think I want to cover a lot of 'how' because I know accessibility things are usually about why you should be doing it and then they touch on things like, "You should be using alt attributes for your images," but for single page apps, I think we need to go further. CHARLES: It always ends up like, "Then draw the rest of the accessibility owl." ROBERT: Yeah, here's your two circles and the alt-tags are your circles and then the rest of the freaking owl is focus management and everything else that comes with it. Before we get there, what is accessibility? I guess, if we trim the giant umbrella down a little bit from everything that is accessibility that can be physical space things, like wheelchair accessible ramps or things like that, what about just technology? WIL: People need assistive tech to interact with technology such as switches or keyboards and obviously screen reader is a big one but when it comes to the software itself, you could even talk about colors and people who are color blind, so red might not be red to everybody. ROBERT: Speaking from experience there? WIL: Yeah. I'm colorblind. Red is brown to me. CHARLES: Things like hearing and all of it, right? It really is like just designing it in such a way that it can be used by as many people as possible. ROBERT: Right. WIL: And that includes your mom who may not be the best with technology but she still needs to pay your bills online or something. ROBERT: Exactly, yeah and in for context to listeners that might not know, my mom is 100% blind, so it's kind of where it comes from. CHARLES: But my mom is not but she has all kinds of problems. WIL: Yeah, same with my mom. CHARLES: That also falls under the category of accessibility, right? ROBERT: Absolutely. CHARLES: Right, accounting for age and culture. ROBERT: We're blending into the why of accessibility, which is perfect. One of the things that it's such a good segue because what people are starting to realize and I think why accessibility is really starting to catch wind and get some traction is because a lot of people that grew up in the technology age were open in using technology a lot. Our parents probably did not use technology heavily. That's definitely the case for my dad. He still has a flip phone and he says, he's a low tech man living in a high tech world and just refuses to pick up technology but those are the people that just didn't use technology. But now we have a lot of people that grew up with technology and use a lot and they're aging into more disabilities and they're going to need that accessibility, which I think is really interesting to think about because that's a lot of buying power if you're just going to start moving in that needs in accessibility, right? CHARLES: That's true. I know I may need glasses pretty soon, so colors and fonts were going to be heck a lot more to me in the next five years than they have over the last 20. ROBERT: Yup, exactly and that's going to be huge for that and that's one piece of the why, so what are the other reasons that you'd pick up accessibility other than people saying that it's morally correct. I don't like starting off conversations for accessibility because it's the thing that you should be doing. WIL: I think it goes even to my user experience like power users that don't like using the mice or mouse. That's me. I really prefer to just use my keyboard for everything. When the new Firefox browser came out and I couldn't navigate through the menus the way I was used to, I went back to Chrome. ROBERT: That's interesting. CHARLES: I still have not found a good workflow for navigating tabs with the keyboard without just kind of twisting my wrist all out of shape. You have to share that with me but again, that's another thing. That's an impediment that sits between me and the application, that actually -- ROBERT: Which is really interesting, you're getting into a keyboard navigation and focus management, which is really the crux of accessibility for screen reader users and switch users. CHARLES: What I'm hearing is that in this case, including good keyboard and focus management in your application, e.g. making it accessible to screen readers, you at the same time, enabling your power users. I think a great point is that by introducing these very low friction workflows, you're actually going to be enabling other parts of your customer base and not just catering to one, that there are ripple effects throughout your system. ROBERT: It may set it for everyone. WIL: Yeah, not only people who need it but people who don't know they need it. ROBERT: Yes, exactly. Think about the WCAG spec as user experience guidelines. They're not telling you how to implement a thing specifically for a screen reader. They're telling you how to implement it in a way that works for everyone, regardless of what ailment they have. It could be a temporary ailment. It could be a permanent ailment, where they have to use a screen reader or any kind of ailment that you can think of. They're not considering just one use case. It's a broad thing that shows how you can make your application better for everyone. I think that's a better way to look at the WCAG spec than I need to read through this and make sure that this auto complete works for a screen reader. If you look at the guidelines, they're not telling you just first screen reader. They're telling you how to make it work for a switch, someone who is colorblind or who is using a dictation software. I kind of tend to look at that as UX guideline, which really helps me build a better app overall because when you nail down that user flow, everyone benefits from it because it's pretty well thought out at that point. CHARLES: I like that too and I think that thinking of it as user experience and making sure that you have a complete user experience is a good way to think about it because it kind of separates the concerns of, "I've got HTML but is my application really HTML or is it a set of workflows and the data over which those workflows operate?" It really forces you to think my application is not a set of React opponents or web components or Ember components or what have you but really, there's a deep structure to it and it makes you kind of shine a light on that deep structure and try to map its surface. Then, if you really, really know it and you capture it, then you can represent it in any medium. I think it's just a win not just for one niche group of users but also for all of our users and then also for your future users that you don't have because your application is designed better and is going to work. Who knows? Maybe there's some new interface or some new medium, some new device that comes out that hasn't even been invented yet. But if you really have a strong internal representation of what your application is, you're going to be able to be the first to move to that market. ROBERT: Right and like I said earlier, people are starting to aid in the needing accessibility thing. If you need a dollar to justify it, that's going to be a big reason coming up. As a part of the new WCAG 2.1 spec, there is a zoom. I forget what this access criteria number is but the new criteria says your app basically needs to be responsive. That kind of maps directly to what you said earlier, Charles which is like you're going to need glasses soon and fonts and being able to zoom. It's going to be really important. We see that just pop up everywhere. To give a counter example of not just for accessibility like you need it for glasses but the other side of that could be like when we give demos on low resolution projectors or screencast or anything, when we zoom the screen, the apps just still be usable and you should still be able to demo it and that's just something that you have both sides to that, where accessibility kind of works out for everybody. People on the call probably don't need glasses but to see that tiny screen that's being shared, you should be able to assume that. CHARLES: Right. I'm just kind of restating what you said but I want to make sure to call it out explicitly because it was a definitely an aha moment for me, that you basically if you build yourself an accessible website, you build it so that it works on projectors and mobile devices too, so you kind of killed two birds with one stone and you don't have to make a special effort because zooming in the screen is tantamount to viewing it on a phone or viewing it on a tablet. WIL: Yeah, we mentioned it earlier about accessibility and physical space and one of those things is being able to access something from anywhere no matter the device that person is using. ROBERT: Yes. That's a lot of the 'why' of accessibility and I think we did a pretty good job of staying away from the more argument because morally we don't know if it's the right thing to do but a lot of the times it's not in front of you, it's hard to do and I want to make sure that you don't feel bad if you're not building accessibility in your apps. It's not easy. I don't sort of like people get up and say that, "Accessibility is easy. Just do this," because it's not -- WIL: If it was easy, everybody would do it. ROBERT: Exactly. I always come back to accessibility being just like UX -- user experience -- because if it were easy, everybody would have a really great user experience too. It's a hard thing to boil down and to simplify it, right? CHARLES: Right and like every other aspect, the kind of nonfunctional requirement, I say nonfunctional requirement that's a little bit of a contradiction terms but it becomes very hard if you haven't done it from the beginning. But if you didn't start with an accessible app, you weren't thinking about that or you inherited the app or it just wasn't on your radar for whatever reason. If you got a codebase that's two years old, going back and trying to make it accessible, it was extremely hard. It's expensive, expensive, expense. WIL: Yeah, it's going to cost more in terms of money and time to added it after the fact. ROBERT: Exactly. I spent a year on helping on Visa Checkout and there were some accessibility considered in the designs but a lot of the time my feedback wasn't just like, "Yeah, sprinkle some ARIA attributes on there and you're good." It was like, "Do we really need a carousel here to represent your list of carts because it's really hard to navigate around that?" A lot of the times, it ends up boiling up to is this the best way we can represent this data? Is this the best way we can navigate and build this user flow? A lot of times -- CHARLES: And if the answer is no, it's so painful, right? ROBERT: Yeah, exactly, so all that work that was put into building that carousel and all the components that built that carousel together is thrown out because it's just not a pattern that should be used there. Doing after the fact is really hard and really expensive and usually ends up in refactoring anyways. CHARLES: I just want to point that out because a lot of people find themselves in that situation, where they're staring down at a pretty big cost. Now, the reasons why your app may not be accessible or many and good and you shouldn't feel bad, if you're finally in that situation. ROBERT: I gave a talk at Nodevember a couple of years ago called Accessibility Debt and it's just like any technical debt. Your apps going to have it. It's okay. Don't get beat up about it, especially if anybody is trying to beat you up over it, don't listen to them. It really is just like any other kind of technical form of technical debt. It's something that you'll have to deal with and it is just something you have to work through. It's not world ending. It's just another problem to work through. What are some things like everybody usually talks about like the things you can do, the basics for making your app more accessible like using all its attributes and instead of doing a div with an on-click handler, just use a button or don't overuse ARIA attributes. Are there any other things that I missed there like the basics of accessibility? WIL: The biggest is the HTML structure. Screen readers and other assistive tech were built with the standards in mind, so if you're doing nonstandard things like putting divs in H1 and adding ARIA attributes within there, you're not going to have a great time. ROBERT: Right or splattering ARIA roles all over the place, probably not a good idea. That will be harder to debug. Also fun fact, ARIA roles, while you can implement directly to the spec, you may still have bugs across the different screen reader combinations or assistive tech combinations, so that's fine. CHARLES: Keep it super simple is what I'm hearing, like use semantic markup. If you're going to introduce a custom button, still make sure that it's a button. ROBERT: Use the platform. CHARLES: Yeah, use the platform. Don't fight the platform. Probably the best example of that is people implementing their own select boxes. That's the classic example. ROBERT: Wil and I, our lives has centered around that for a little while. It's so true. Usually, it's the first thing people go to grab to reimplement because selects are just ugly. I think Firefox has the ability for you to style select options now like you can change the color and the font but you can't style that. The pop up that comes, usually that's the system dialogue, which a lot of designers don't really like. That's usually the first thing that people go to implement and that's usually actually the first thing that stop somebody from signing up. A lot of sign up forms that I see, if your date of birth is in a select format, that probably will hinder somebody that uses assistive tech from signing up. CHARLES: Yeah. You just basically bounced that entire person. The thing is people don't appreciate the cost. This gets into the whole concept of accessibility that is how much money would that person or those group of people have actually brought into your site versus the cost that you spent redoing that select box. You might be thinking, "It only took this developer actually two weeks," but when you actually look at the actual cost over the course of your application, you're not factoring that into the decision to go with custom select box. Just in our experience, it's just the truly low cost option per quality of experience, that tradeoff there is almost invariably going with platforms select, right? ROBERT: Yeah. Your secret sauce and the best UX that you're going to provide is not going to be nicely styled select box and seriously, a battle that I had to fight a lot was if you really want to implement a custom widget, decide if this is what you want to spend your time on because custom widgets aren't just quick and easy things you implement. You're not going to implement the select that's fully accessible across all the AT combos in a couple of days. CHARLES: It's a lot of work. ROBERT: Yeah. You're going to fall down on a huge rabbit hole. CHARLES: Yeah. It is just you're committing to that work over the lifetime of your application. ROBERT: Exactly, if you can maintain that now. If you implement custom check boxes and custom radios and custom input that of content edible for some reason, I think -- WIL: I think what I see is like custom date pickers -- ROBERT: Oh, I just had a rant about that. CHARLES: Date pickers are hard and there's not really a good option. You just have to open your eyes to the true cost. ROBERT: Right, exactly. That's what I always try to explain, just like you have ownership over this now and you now have to maintain this and you can't regress. CHARLES: Right and if you do regress, it's your neck that gets choked. ROBERT: Yes. A good way to put it. We've talked a lot about things that are just general accessibility but nothing specific to single page apps. I do want to say like a lot of other things that people recommend is like if you're using React, use like the JSX ES1 plugin to help you analyze if you're writing any JSX that might not be accessible or use like HTML_CodeSniffer or aXe to statically analyze the DOM that you have. Those tools are great. I'd see a lot of people [inaudible] those things as like, "Look, this automated checkers says I'm inaccessible so I'm inaccessible," and that's not the case, especially in a single page apps. You can have 100% passing automated checkers but your app also could be 100% broken and why is that? WIL: I don't know. ROBERT: I'm wobbling the router question here. WIL: Yes. I guess that would just be due to routing. In single page applications, they handle their own routing, whereas static web sites and whatnot, the routing is handled despite URLs and the browser and reloading pages. ROBERT: Right. There are probably other major differences between single page apps but the biggest thing is the routing is managed by the client, the JavaScript and on a server-rendered page, you click a link, it's going to rerender the entire page for that next page and the screen reader and the browser know exactly what to do with that, to put the focus back to the top of the page and start working through the page for you. But with single page apps, you're just replacing a piece of the DOM and the screen reader has no idea of what's going on. An automated checker cannot check for this. They cannot tell you if your routes are accessible. The reason I'm bringing this up is because this has never talked about. I don't see in accessibility talks and this is the thing that actually is most broken and makes your app pretty much unusable to anybody that's using assistive tech. There's ways that people if they're savvy can navigate around it but if they don't know what's going on, they're going to think, "All right, I pressed this button and nothing happened, so I'm just going to leave now because it's not working." CHARLES: There's a great video that you point to me, I believe a guy from the UK who has recorded a bunch of his experiences using websites and apps -- ROBERT: Yes, I want to dig it up and put it in the show notes. CHARLES: Yeah. Those are great to watch because you'll really get it. ROBERT: Yeah and that's a really unique case because he's really savvy. I believe, I could be wrong but I think he might have said that he definitely work in tech somehow -- CHARLES: Right. He knows the workarounds and he knows these things but in some of the cases it's like, "If I didn't work in tech, there's no way that I would be able to use this website." ROBERT: Yeah. This is kind of the crux of like if you ever listen to anybody that is an accessibility consultant, they'll say, "You will never ever be able to automate accessibility," and this why I tie accessibility so much to user experience, would you ever have a user experience test that can tell you in a binary fashion? Yes or no, that your app has a great user experience? No, because it's pretty subjective. CHARLES: Of how does your users feel? right? ROBERT: Yeah. CHARLES: You can rate, "My users feel great." ROBERT: Accessibility is like that because there's a lot of context that you have to carry around. It's all about context. When I transition from this page, the next thing does the user have enough context of where they're coming from to where they're going to be able to operate on that page. Is there enough information to achieve the task they want? That is pretty much the crux of why there is no binary yes or no for that because it's contextual. It varies from person to person but you do your best to make sure that that works and that you provide enough information to do something. That's kind of a single page app as a crux. This is why we have a philosophy of testing as a whole. We don't test components individually because again, you can make all of your components individually accessible there but as a whole, they might not work together because you're not providing enough context on an entire page. We did this in one of the apps that we work on, which is open source, so we can link to the PR that Wil wrote for this and I wrote an entire routing documentation around our philosophy and the different things that we tried. How did we manage the focus in that application? I'm kind of just going to lob it over to you Wil since you did the work. Do you want to give context of the holdings and how that all kind of came together? WIL: Yes. One of the features of the app is these panels. It's like this three panel system. When you click an item in a list, a third panel pops up and this goes back to the context thing where if you're using a keyboard, you can't see the screen. You click an item in a list, how do you know that third panel popped up? The solution isn't for a component. The component can't be responsible for this. The list can't focus the item. It opens or vice versa, so this is definitely an application concern, where we needed to check against the route and see whether or not, the pane is opening or was already open or wasn't open before and when this pane opens for the first time, it will just focus it and that gives a lot of the context that the user needs when they click it, like they click an item in the list, it focuses this third pane and they're on a third pane. ROBERT: Right. We didn't even just focus on the entire div. We focused on the heading of the thing that you selected. WIL: Yeah because focusing the div, it might read something off but not all the time. The main thing we're focusing on that third pane opens is the heading to let them know that the item you click, you are now on that page and reading that heading. This is the same thing that would happen if you loaded up that page statically and the screen readers would usually just focus on that first heading. ROBERT: Right. That helped a lot. For a little bit more context, the middle pane is like kind of a master detail thing going on here and in the middle pane there that we have, it's an infinite scrolling list. You have different things there and one of them is like a package. If you select the package and without the focus management and focusing on that heading, you would have to go through every single package that's in that list which could be a thousand of them before you actually get over to the pane that you just opened because source order. You have to go through each one of those. WIL: And it's the same thing is true for power users, not just screen readers. It's like if they want to use tab once that pane open, they have to tab through the entire list. ROBERT: Exactly. It wasn't keyboard accessible and it made it really hard to navigate around with a keyboard because the focus just wasn't being managed. There was a lot of work that we did there. I want to focus on the routing situation there because if you can't navigate around with a keyboard in your single page app, like you click a link and it's not selecting the next thing that should be focused and you provide the right amount of context, your app probably won't be usable without a lot of trial and error to a user, which depending on what your product is, they may not have a lot of patience for trial and error, right? WIL: Yeah. ROBERT: It's really important to try and nail down the routing situation and there are some frameworks and things out there that can do it. In the app that we're talking about, it's React app and we use React router but we don't actually really hook into the router to handle that and that's because React router doesn't provide very much information. WIL: Yeah. You can think of React router as more of an outlet system, where your routes can render anything, anywhere on the page. That's kind of dangers of accessibility and that's kind of the reason that React router can't handle accessible things very well because at any point, the route can just change the button on the page to look like something else. CHARLES: Yeah. It just pop in and pop out. There's no deeper model, right? There's not -- WIL: Yeah, there's no tree. CHARLES: Right, there's the internal state -- WIL: Like a component tree, yeah. CHARLES: The internal state of what is happening is completely opaque. You can only analyze the second and third order effects of the React tree. ROBERT: Right and especially if you have nested route components, it's really hard to determine. One of the things that I've seen people do is focus on mount, which is a very naive approach because what if you have three nested routes, they're all going to focus on mount and the last one that mounts wins and that's a focus for which nobody wins. CHARLES: You all tried that, right? ROBERT: Yes. That's part of the document that I wrote up. We tried three different approaches and we ended up landing on something because we were using React router that was more of like an application state thing, so we were checking props because we knew what the user flow was. We knew what the user, when they come to this page is trying to accomplish, so we're able to kind of figure out from where they came from or where they're going through props and focus the right things for them. WIL: One of the examples, like we talked about the third pane opening and focusing the heading inside but what you know what happens when you close that third pane, you kind of lose contexts again, so we have to focus the previous list item that was active because if you focus back at the top of the list, they've essentially lost their place and the list of results. In that case, we couldn't use on mount. That list item is already mounted. We have to listen to props and we have to look at the route through these props to determine if that third pane was open. If it just closed and if an item in the list is active, it should have focus. It's a lot of logic going on. You have to really understand your app in order to make it a very good accessible app. You can't just sprinkle in ARIA attributes and focus on mount everywhere and think it'll work fine because you're accessible. You have to really know the flow. CHARLES: Right. All those signposts point towards having a deeper application state, a deeper understanding of your application than just the render tree. At that point, it's too late and so by that, I'm definitely lobbying a Reach/Ember router. WIL: Yes. We talked a lot about the React router and we can't really be too accessible with it but to create a React router to go out and there is now Reach router. Robert, have you heard any good things about that? You're the accessibility expert here. ROBERT: I haven't played with it myself, so [audio glitch] things that were lost from the React router three to four transition, I think and also, it's actually accessible routing which is nice because it comes out of the box and you know how to implement it. I haven't played with it. I know Gatsby has implemented that for their V2, that's their default router now, which makes me really happy because a lot of static sites that were being built with Gatsby were very inaccessible and broken which made me sad but now, they're not with V2. I haven't played with Reach router but one of the things that I think it provides which was missing from React router was transition hooks. It has a concept of like where you're going from and to for your routes, which really helps figure out what you need to focus. The one thing I will say about Reach router and I'm sure it's got to be configurable somewhere but I haven't really looked and the demos that I saw, they were just focusing the div of the content that's being rendered, like it kind of just wraps with a generic div or the tabindex="-1" and then focuses it. If you have a lot of content that's inside of that div, it probably will be confusing but at least, it manages the focus somewhere. If you're now off in a no man's land, you have no idea what's going on, at least it focuses that. But if you want to really nail the experience to be better, I would recommend trying to figure out what you should focus inside of that route that you just transition to, what is the best thing. That's for React. There are other things out there for other frameworks, like I am on Ember accessibility team that's out there and we have Ember A11y, which just provide you a focusing outlet for you to be able to just drop in your app and then when the route changes, it does the same thing. It focuses the wrapping div of that outlet that was just rendered. I want to emphasize more in talking about e-holdings work that we did that we were focusing the heading because that told you exactly where you're at and what package you're on or what thing you're on. You know the name of it and now you know how you can go and navigate through that. CHARLES: But it's conceivable, so how would you do that with the Ember router? Would you just introduce some way to delegate down to a particular component? Like when I'm rendered into an outlet, it focus on this component? ROBERT: That would be interesting. I actually don't know. It's been a long time since I've messed around with the Ember router and Ember accessibility. It's definitely a great first step and that's where it kind of came from. I think there needs probably some work done to help implement on what you want to focus. That's kind of where I was going with when we were first exploring the React router stuff and e-holdings was I wanted to have this like high order component that knew of your routing tree and it knew where you're coming from or where you're going. Then from there, it would just tell you, this is the route that we're going to and there's need to be focus management done, like if this prop exists, then you can pick inside of that component that what you want to focus. It leaves it up to the implementor of what they need to focus but it could be probably just like a fallback to the general div because that's not bad. It's a good first step. There needs to be a little bit of work there to get that done probably. CHARLES: Yeah. But it is worth pointing out that by starting from a position of having an externalized application state via the route structure, in an Ember application, you're starting 95% of the way there. An Ember application, at any point, you know where you are and during your transition, you know where you're starting and where you're going to end up and you know when you leave and you know when you got there. ROBERT: Yeah. Having an Ember route pivot handler there, like where you're pivoting from and to is just so nice and it kind of made it click together a lot easier. CHARLES: Right. Reach router looks interesting but as I understand, it's still couched in React components and it feels to me like this is a problem that ought to be solved, that ought to be framework agnostic. Because if I use something like Reach or I use some other routing library for another framework, some other tool might come out that I want to use and I shouldn't be locked in -- ROBERT: Right like what if I really like Redux little router, then I have to make a choice between Redux state that I like or accessibility. CHARLES: Exactly and that feels like a false dichotomy to me. What I would want to be looking for is a platform independent or a framework independent routing library that really just helps you represent your application state and the concrete state in which your application is in at any moment and then, also be able to represent the transitions between those states fully and completely. Then if you have that, you could embed that into any framework. ROBERT: Right. That would be really nice to have. Just like pull it off the shelf and help you out there. CHARLES: If anybody is listening who wants something to do for the next 18 months, no one will thank you for 18 months but you had to get on that. We'll give you lots of thanks then. ROBERT: [inaudible] compare with you. That would be awesome. CHARLES: I would love to be part of that. ROBERT: Yeah, that would be awesome. To kind of tie back to other things, I don't know too much about Angular but I'm sure there are solutions out there to help with Angular. I know Marcy Sutton used to do a lot of work in the Angular world, so I'm sure there's something out there that helps with that. I just don't know off the top of my head right now. I wrote a Medium 'think piece'... No, I wrote a little medium blog post about how all of single page out for routers are broken. I was pleasantly surprised by Vue. Vue brings its own router and their router has a concept of before each, so before each route transition you can run some code and that really helped with implementing the live, the announcer pattern where you use ARIA live to announce something but even beyond there, if you wanted to dig in there, you could probably figure out where you're transitioning from and to and give that next route some kind of attribute that says, "This needs to be focused. Figure out what you need to focus there and inside that route, you can focus wherever you want." I thought that was a really awesome. That's kind of the crux of what I was missing from React router. I wanted the concept of knowing where I'm coming from or where I'm going and I would help with everything but unfortunately, that kind of doesn't exists because they're just components. For better or for worse, they're just components. CHARLES: The world is so much more than just components. ROBERT: Yeah, a little bit off topic, I think it's kind of funny how React kind of just shoved everything into the Vue layer, just to make it all a component. CHARLES: Yeah, it's very easy. ROBERT: Yeah, until it's not. CHARLES: Yeah, exactly. It's easy but it's not simple. ROBERT: That's a lot of talking about how routes need to be done and what you can kind of do to manage focus. It's really about managing the context and how you can provide the most contexts. For somebody to operate on that information, can they complete this thing? What can you do to make sure that you've done this properly? What steps can you take to make sure that you actually are accessible and that your routes work? WIL: Manually testing those screen reader is probably the biggest thing, you know? CHARLES: Yeah. I think the biggest thing is really watching someone who uses assistive tech on a regular basis use your application and then trying to use it yourself. WIL: Yeah. ROBERT: Right. Yeah, I'll definitely -- CHARLES: If you can get a little bit of this yourself but then it's kind of like someone who is never used a mouse before and trying to learn something new. What really helps is seeing someone who's good at it and see how their expectations are either being met or not being met. ROBERT: Yeah, it's definitely the best way. If you can find somebody that actually relies on assistive tech, there's nothing that beats that kind of feedback. If they get to your app and they're really confused, I see some people that just dismiss it because they just don't understand. That is the best feedback you can actually get. If they don't understand what's going on, you have -- CHARLES: That's on you. ROBERT: Yeah, that is going to be what happens for everybody that uses that. Well, maybe not everybody because everybody has different experiences but it's probably going to be a thing that pops up everywhere. But if you don't have access to people that are actually using assistive tech regularly and are pros at it, WebAIM provides really great tutorials for how to use a screen reader. If you're using a Mac, you have a screen reader built in and you can use that called VoiceOver. If you ever want to turn it on or turn it off, its command F5. WIL: You might have to have that shortcut enabled, though. ROBERT: Really? I'm pretty sure it's quite default. WIL: I thought I had to enable mine but I could be wrong. ROBERT: It's interesting. CHARLES: Yeah. They got great tutorial too. It's like it notices the first time you turn it on, so it tries to help you navigate bullet lists and select boxes and input fields and check boxes and all kinds of good stuff. ROBERT: Yeah. It gives you a little bit of a boot camp but WebAIM also helps with specific to website and stuff because one of the things that we ran into while working on the e-holdings project is they're transitioning from a native app to a web app and there were just things that you can do on a native app that you cannot do on a web app. Just keep that in mind also when you're testing, there's just things that will behave differently. Like you're not going to have a lot of crazy key shortcut commands like you're not going to press command F to get to the search box if your app has a prominent search box because that is going to clobber a bunch of other assistive tech key commands. WebAIM is really a good help with giving you the tutorial of how to test a web app and many different screen readers, so they have it for JAWS, they have it for NVDA, they have it for VoiceOver iOS, they have it for TalkBack, which is the Android screen reader. There's a lot of really good resources there for you to start using as screen reader and test with your app. I highly recommend using it with a screen off. You gain a lot of context by looking ahead of your cursor and -- CHARLES: Yeah. It's true. ROBERT: -- The example that I usually give to people is like, "I worked on Visa Checkout. I went through that checkout flow pretty much every day for a year and eight months in, even then turning off the screen, I was still lost." Even though I knew what each screen was and what each component was there, I would find myself confused of like, what just happened and it's because sometimes, you'll get into something like you have a dropdown that sets the focus inside the dropdown and then the dropdown disappears from the DOM and your focuses in nowhere. You're like, "What is going? what am I doing. I don't even know where I'm at," and I turn the screen back on and I'm like, "Oh, now, I know what's going on." CHARLES: Right. It really is a lot like interacting with your application as though you were interacting with Siri or Alexa but with a keyboard instead, instead of voice commands. That's an excellent point. We would understand if where would Amazon be if Alexa couldn't successfully navigate those situations. The counterpoint or even the flip side of that is if you model your web application in such a way that it can handle that type of serial interaction, instead of the highly parallel environment to being able to perceive huge amounts of information concurrently, like you can on a screen, if that were effectively serialized, that means you could represent your application through nothing but voice commands. ROBERT: Yeah. Did you provide enough context for me to build this mental map is really what I'm going on to? CHARLES: Yup. ROBERT: Which I always thought was really interesting because I always wanted to know how my mom visualizes what a website looks like because it's wildly different than any of us. She's never been able to see what a website looks like. Does it look like a bunch of nodes and graphs and webs connecting to each other and how things pieced together? It's just a different way. But it's not only about screen readers, right? You can use a keyboard to navigate and that's definitely what we did with e-holdings is like can we tab through this [audio glitch] list, hit enter and go into the detail record, edit it, close it and go back and edit another one. Is that something that we can do with just a keyboard, not even a screen reader? WIL: And with the keyboard, we're not talking about shortcuts to hit edit. We're talking about like tabbing over and hitting enter like people with accessibility issues would have to do. ROBERT: Right and that's kind of a good segue into creating use cases. If you want to know if your app actually works, if your screen reader users or if your keyword users or if your dictation users are going to be able to navigate this app, create use cases. Things like actual user flows like how would somebody actually going to use this app? What task are they going want to complete? In that case, e-holding was like an electronic holdings management system for libraries. They probably want to get in there, add a couple of books or whatever you might have to their library and get out. A use case could be like, "Can I search for this thing? I'm going to search for something specific. I'm going to go through the list, find the thing that I want. I'm going to add it, close the pane, go back and then remove one thing and can they complete that flow successfully without running into any issues or any blockers or any showstoppers." I can tell you before we did the routing management stuff, you would hit search and that was it. There was nothing else that you could do. CHARLES: Yeah. They wouldn't even announce that anything can happen. ROBERT: Exactly. WIL: Yeah, and with these librarians, it's not necessarily a matter of they can't see the screen. It's just that they don't use the mouse because they're power users. ROBERT: Right. They don't have any disabilities but that was essential to the workflow. CHARLES: Yeah, exactly. Do that change. You just lowered the activation energy of that workflow by... What? three orders of magnitude? WIL: Yeah, at least. ROBERT: Let me click here right now. I can tab, now I can tab. Right now, let me click here and now I can tab, I can tab, I can tab. It's not as nice as just being able to completely do it through a keyboard. Through us making it super keyboard accessible, that also became super screen reader accessible and the people who use dictation were able to work through and get through the app and use it now, which was really cool. It really helps when you go for those things and create use cases to really figure out how a user is actually going to work through this app. That's the best way. Just get right through it. With Visa Checkout, we're like, "Can somebody buy something?" or if they don't have an account, can they sign up and buy? those were some of the use cases that we had because it turns out, those are actually pretty important to the business. That all have been said, you also can test your components for accessibility individually because even at a smaller level, some of your components might have to manage focus. The best one I can think of is models. When you open a model, you should trap the focus inside of that model and you should be able to hit escape to close the model and when you close the model, it should go back to what triggered the model to be opened. These are all things that are individual that can be tested also. But just because your components are individually accessible, it does not mean your application as a whole was accessible either. I don't want to paint the picture like, you don't have to care about your components accessibility individually because you do. It really does help but I think a lot of people miss the whole of the application, rather than individual with components. CHARLES: Right. The components are the individual stitches but you have to follow the thread throughout the entire garment. ROBERT: Right, exactly. CHARLES: Man, what I really want to do is I want to find out how your mom visualizes website navigation and use that as a visualization technique. ROBERT: That might be a fun webcast or something. CHARLES: Yeah and then see like could we actually use it as a tool because I have to imagine, it's probably pretty simple. It's much simpler than what we think of when we think of a website because it has to be really condensed down to its essence. ROBERT: Right. Yeah and [inaudible] users, they're not dumb. They have different ways. They know the gotchas. They know things that happen. They know there are different ways of getting trolled like my mom knows about focus jumping and she gets irritated what happens but she knows generally of what to do and it depends on her patience level. Like if it's focused jumping, she's like, "I don't need to use this thing. See you," and it's just not worth the frustration but there's different ways to navigate around like if you're a real power user, you might be able to recognize like the routing is inaccessible and you can navigate by headings or by regions or different landmarks. There's many different ways for users to navigate but to use those different navigation methods, you need to have a real strong coherent document structure. Your H1s have to actually be H1s and you have to have some things that they can navigate around to kind of work around those things. It's interesting and basically, do everything you can to help those situations. If you can provide semantic markup and give it a proper structure. If you can do the focus management, it's going to help everybody. It really will. I did see when we went through the use cases and defining those things, we actually learned a little bit more about our product because we had to put ourselves in a different seat and think about it because you get real close to it. You go through that same flow nine million times and you pick up real power user things that you can do like, "I'll work on that. I got this. I'll click this button. All right, we're good." Somebody that's going through it for the first time and you put yourself in that seat, it kind of opens your eyes a little bit and makes the experience better for everyone. I think that's kind of the underlying tone there. That's the message. WIL: Yeah, accessibility makes things better for everybody. ROBERT: That was a lot of content thrown at you there. We covered what is accessibility and why you'd want to do that and then kind of like more the basics things and how automated tools are really helpful and they can help you pick out things like using improper roles and nested things but they're not going to be able to tell you if your application is truly accessible or not and never will, unless we get something like a headless screen reader, where you can write automated tests for in that fashion but you're not to get something that will just run over you app and go, "Yup, you're good." CHARLES: Even so, it's a matter of user experience and that's not something you can get a thumbs up or a thumbs down to. When you as a user, it comes with application, you know when you see it but I would say until we have androids that accurately simulate human beings, I don't think we're going to actually have automated testing. ROBERT: Yeah. There's a joke for accessibility consultants. It's like if you put four accessibility consultants in a room and tell them to give you an alt attribute for an image, you'll get four different alts. We talked about the automated checkers, right? They'll not going to get everything for you and we talked about single page apps specifically in the routing and how we handled the routing in a React app and then how you can probably do it in an Angular app and how you can do it in an Ember app and Vue and different methods of how you can kind of attack that. We're definitely giving the link to the document that I wrote and the PR so you kind of see the real 'how' of how we did it because that would probably be helpful. I think there was a lot of good information there, so I would like to thank both Charles and Wil for being awesome co-host on this and -- WIL: Thanks for being an awesome host. CHARLES: Yeah, thanks for being an awesome host. I should say, you're welcome. ROBERT: I tried, I tried. We are The Frontside. We do accessibility consulting and training. If that's anything that your team needs help with, we're more than happy to jump on a call with you to kind of figure out what your needs are and what you need to do. If you need a WCAG support statement, if you need to audit, if you just need to figure out what's the next steps for you to even do, we're more than happy to help you sort through that. To reach out for that, you can contact us at Contact@Frontside.io or Sales@Frontside.io or Info@Frontside.io. You can contact us at any different ways and we'll be more than happy to help you. As always, thank you Mandy for producing the podcast. You're awesome and the next episode, what we're going to have is also still accessibility related and I'm really excited about this. It's about writing a proposal to the Unicode Committee and getting it accepted so basically, writing a proposal to get an emoji added and that's with Amberley and Amanda. They wrote three or four Unicode specs and actually got them accepted for, I believe it was sign language and deafness. That's really cool and I'm super excited for that because they'd be the first people that I've ever talked to that have actually created an emoji and gotten it accepted. WIL: Yeah, it's pretty cool. CHARLES: Yeah, that must feel great. ROBERT: Yeah, it's going to be awesome. That's our next episode. If you have any ideas or comments or anything, you can tweet us at @TheFrontside on Twitter or you can contact us through any of the emails that I talked about earlier. We're always open to hearing feedback. Thanks for listening. Take it easy, everyone.

Guest: Saron Yitbarek: @saronyitbarek | bloggytoons | CodeNewbie | @CodeNewbies In this episode, Charles and Sam talk to Saron Yitbarek about her idea of mentorship, ideas for distributed learning for businesses to promote individual and company growth, and why it's important to take "digital sabbaths" on the regular. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: SAM: Hey, everyone. Welcome to Episode 110 of The Frontside Podcast. My name is Sam Keathley. I'm a developer here at the Frontside and I will be your episode host. Today, we're here with Saron Yitbarek, discussing mentoring. She is the founder of CodeNewbie and the host of the CodeNewbie Podcast. Also with me as a co-host is Charles Lowell, who is also a developer at Frontside. Welcome Saron and welcome Charles. How are you guys doing? SARON: Thanks for having me. I'm doing pretty well. CHARLES: Hello. SAM: Today is going to be an interesting take on the mentoring talk. I mostly want to know first off, Saron, how do you feel about mentoring? What are your opinions on the mentor-mentee relationship or the value there? SARON: Yeah. I have lots of opinions on this topic. I think that the traditional structure of mentorship was usually looks like someone with less experience going to someone who has a lot more experience and say, "Will you be my mentor?" kind of like the children's book, 'Are You My Mother?' like 'Are you my mentor?' and then that person, that mother figure, that mentor looks after them and checks in on them and they have regular coffees and lunches and kind of steers them in the right, usually career-related direction. I don't think that's very realistic, to be honest. I think about why that might be. There's many different reasons. I think the fact that we're so, so, so networked and there's just so many different ways to get in contact with people and build relationships is a big reason but I think that that traditional mentorship model, that kind of one directional way of doing things is just not really needed and kind of overrated. I think that mentorship nowadays looks more like a mutually beneficial relationship, where I might reach out to someone who has more experience than me, for example in drawing, in art, not something I want to get to do but I know a crap-ton about podcasting, so I help you, you're my mentor in this specific area, in this specific topic but then, I get to be a mentor in this other thing that I'm really good at. I think it's those types of very focused topic-oriented, ideally two-way relationships that are more accurate and frankly, a more effective way of doing mentorship. SAM: Yeah, I actually agree with that. I am pretty new myself to development, only really been in this career for about a year now and I always kind of consider that mentoring relationship as a regression back to school days, where you have these -- SARON: Yeah, yeah. SAM: -- considered superior over you in some way, well, that's really not true in this community of developers and no matter where you are in development, it's all about working together and pairing. Working here has really showed me that value in paring, rather than like I have to look up to someone and regress back to feeling like a teenager in high school, like this person so good at this thing and they're the only one who can teach me. I definitely share that view of mentoring. I went to a boot camp one day when they were telling you like, "Oh, you got to find a mentor. You got to find a mentor," and I was like, "Well, but why? Why do [inaudible] together?" SARON: It's also a huge responsibility, a huge burden on the mentor too. Having to be, in a lot of ways, responsible for someone's career and trajectory and direction, that's a big responsibility. We don't have time for that, you know? On both ends, whether it's feeling like you're back in school or feeling like you have this huge responsibility, I think the traditional model isn't really the best model for either party. I think this idea of let's all learn together, let's be really focused on topics and problems that are very particular to what I'm doing, what I'm learning, what I'm trying to do. I think that works out. It feels healthier for both people. SAM: Absolutely. CHARLES: I wonder also too, it seems like it might be a little bit of a throwback to the days when people would spend 30 years in a single company or 30, 35 years in a single career where you have these people who are really these reservoirs of this intense tribal knowledge. It seems like people move around a lot more in their careers, not only in the company that they work for but also in the things that they're literally doing. I might be podcasting one day and producing a bunch of content and then, I might move into music or writing or other things like that. The careers seem to be broken apart a little bit more is one of the reasons why older models of advancement in those careers might not be as good a fit as they once were. SARON: Yes, absolutely. I'm obviously very biased because I'm in tech but when you think about the different roles that people have in tech, I feel like we're always wearing so many different hats. We have to, obviously code and be technical in that sense but we have to be really good communicators, a lot of us are speakers, we host podcasts, we organize conferences, we go to meetups, we're bloggers, we do so many other things, that this idea of, "I'm going to have a mentor who can help me in my role of being a developer," is just too big. You kind of meet people who are good at those individual pieces and those individual skills to get me to where I want to go. SAM: The whole idea of mentoring to me always reminded me of that whole Mr Miyagi relationship where you have this master of something and you're trying to learn from them. But in software development, I've learned that really no one is a master of anything because it's just changing so much and everything is so different. SARON: Yup, absolutely. CHARLES: The question is obviously, it seems like the idea that you're going to find one person who's going to represent the ideal confluence of every single skill set that you could hope to want, to be at some point in your career. That's looking more and more ludicrous. Is there a model where you can try and distribute those things, where you single out a large range of individuals? I guess the kind of what you were hinting at the beginning is that it is a lot more broken up, a lot more distributed but how do you pursue that, even if it is in a distributed manner? SARON: Yeah, that's a great question. One of the moments where I realize that the distributed model is really the only way that makes sense is, I think it was three years ago maybe. We thought about doing some kind of mentorship program in CodeNewbies, some type of way for people to link up and find people who can be there and guide in a way and we had people fill out this survey that basically said what do you want out of a mentor, what do you look for, what do you hope for to achieve but also asked how do you see yourself. Do you see yourself as a mentor, a mentee or both? It was really surprising that most people checked off both, which I thought was so interesting. It was so interesting to me that the same people who said, "I need help," with the same people who also said, "I also have help to give," and to me, that was such an amazing moment because I said, "Wow, it really isn't about this idea of I am the guide and I'm going to guide you." It's really about, "I have information expertise in one area and not in others." What I realize is there really isn't a mentor model. I think it's more of a culture of being helpful, which probably sounds really cheesy but it's true. I really think it's about saying, "I know how to do a thing. I'm going to go on Stack Overflow and answer questions. I'm going to go on Twitter and answer questions. I'm going to write blog post and share with the world." I think the real model, the real distributed mentoring model is us as individuals saying, "I just learned how to do a thing," or, "I just figured out how to do a thing well. Let me capture that. Let me capture it in a response, in an answer, in a forum, in a post and let me share that," and the more we do that as individuals, the more we have this huge amazing aggregate of knowledge that can serve as mentorship for all of us. SAM: I like the touch on that. That's kind of the idea behind Codeland Conference, where everybody thought they might be new to development and everyone is just sharing their knowledge. You might feel you really knew about it but you know a lot more than you think you do and you could still help. SARON: Yup, exactly and that's the whole idea, even the Twitter chats. When we first started, I don't have all the answers, I don't claim to, I don't really want that responsibility but I know there are a lot of people who do and I know a lot of people who have resources and opinions and who can help out. One thing that people do is they'll DM us and say, "I'm having a hard time with this." Sometimes, it's a very technical problems. Sometimes, it's a general 'I'm having a hard time getting a job,' which I do like high level question and I never answer them. I always say, "Tweet us and we'll retweet it and we'll get the whole community involved and we can have a rich conversation around it," and that's really been our motto, our philosophy. I see what they do with mentorship. If you have a mentor, you're not obligated, I guess to listen to them but the idea is kind of that you should. There is one person and you should listen to them because they know more than you. I think that's just not really fair and instead, I like to think that there are lots of different ways to do things and it's up to you to decide what's best for you and in order for you to decide, you have to have a lot of options. With Codeland, with the Twitter chats, no matter what skill level you're at, no matter how confident you feel in your coding abilities, you do have something to offer. Let's pull that out. Let's put it on the table and let's see who you can help today. SAM: That's a perfect way of introducing someone to the idea of helping or getting help from a community, rather than an individual because you never want to take one person's word as gospel on something you just know nothing about. SARON: Yeah, exactly. SAM: You can sound confident talking about something and it can be the total wrong answer but if you're seen as someone superior or someone who knows what they're doing -- SARON: And you can sell it. SAM: Yeah. You can be the best snake oil salesman in the world. SARON: Absolutely. For the CodeNewbie podcast, we do short questions at the end of each episode and one of the questions -- my favorite question -- is what's the worst advice you've ever received. I love that question because I started by saying, I think that people love giving advice. I think people love asking for advice and the assumption again is if I give you advice, then I probably know more and you should probably listen to me but that's not always true. I want people to be comfortable making their own decisions and deciding for themselves. "This may sound like it could work and this may sound like a good idea, generally speaking, but for me, it's probably not a good fit. It's probably not what's best for me," and to be comfortable rejecting advice and that was kind of the reason why I started that question, it's my favorite question and it's so interesting how much advice is good. It's kind of generic but it's a good advice. It's an advice like, "Don't quit. Keep going," which maybe a good idea and maybe you do need to quit, so being open to rejecting advice, I think is really important and that one of my favorite questions. SAM: In your experience, what is the best way to reject advice? Because when you're a new developer, when you're new at anything and you're seeking advice from a community or from a person, you don't want to come off as rude or maybe you're feeling... I don't know, not very confident but you think the advice that you were given is just bad advice. What would your advice be? I guess, what would your advice be on this advice? For your perspective, what would be a good advice to reject advice that you think is just wrong? SARON: Number one is when I ask people for advice, I try to think about and try to know upfront, do they have the same values that I do? Do they have the same worldview? Do they have the same goals? Because that's the thing too. Oh, my God, I got so much unsolicited advice. It's amazing. I've actually stopped just saying to people my ideas or what's on my mind because I know as soon as I say, "I'm thinking about this," I'll get a whole slew of unsolicited advice and I'm like, "I didn't ask for that." What I've learned is first to kind of figure out are we even on the same page because if my goal is to be a developer, if your goal is to be -- the only thing I could think of is a juggler, I don't know why -- a juggler and I ask you for a career advice, I'm going to go ahead and safely assume that what you have to say is probably not as applicable to me and so, number one is kind of identifying that. But number two is if they say something that just I know is not going to work or I've already tried, I'll just nod and say, "Thank you very much," and kind of go about my day. I don't think you have to declare whether or not you going to take it. I think just acknowledging and I think the people that give advice, I think they're trying to be helpful, they have good intentions, usually. Usually it's, "I'm trying to save you from making mistakes that I made and I'm trying to help you get to learn a little faster." I always appreciate it but knowing that I can say, "Thank you. Thank you for your time. Thank you for your perspective," but know that I don't have to go off [inaudible]. SAM: That's actually very similar to my tactic. Just not like, "Thank you. Thank you so much. Don't talk to me ever again." No. SARON: And disappear, yeah. SAM: I'm like the wind. With this pressure that either new developers or seasoned veterans are feeling about the mentor relationship, because I feel like a lot of senior developers that I've spoken with or people who've been in the business for a long time, feel like they should be mentoring or they need to take on that responsibility but there's always that hint of dread in their voice when they say about like, "Oh, I should be doing this." I always feel like it's okay to not do that. I never really understood why it was so high value to have this one-on-one relationship with an individual when you're not in school because it just feels so like... Not childish but childish. SARON: Yeah, that's one of things, frankly that I love about the tech community and also do not understand about the tech community. It's such a giving knowledge sharing community, whether you do it in a tactful way or not in a tactful way but the idea of giving back and paying it forward is just so deep. It's so, so deep that even when I've been coding for only a couple of months, I still felt this, I don't want to call pressure because pressure kind of sounds a little negative but I definitely felt this expectation that I was supposed to be blogging, supposed to be sharing and shouting and helping and doing these pay it forward type things. I don't really know where that comes from. Maybe that comes from the culture of open source, maybe that's where it kind of penetrate. I'm not sure but there's this huge need, desire, idea that we're supposed to be giving back and for that, I am very, very, very grateful. But I think that acknowledging that if you're someone who wants to be a mentor that you can do it simply by being available, literally being available, the going to be hashtag is super, super active even when we're not doing our Twitter chats and people use it to ask for help, they used it to ask questions. If you're feeling particularly giving or extra helpful that day, go on Twitter and check the hashtag and see what questions people are asking. Things like that or just super helpful and don't require a huge amount of time and effort. There's a lot of small ways to help out. That may not seem like a big deal to you but for the person who's asking for help, who has been banging their head against the wall, it's hugely valuable. SAM: Yeah, absolutely. Up until I went to my first conference this year, I didn't realize how supportive and important Twitter is. You know I always kind of considered it to be like another social media platform that I don't understand because I'm 84 years old and I just don't get it. It's been so uniquely helpful and in ways like Stack Overflow or even issues in GitHub, it just aren't. You can get so many more perspectives, so many different perspectives from people. SARON: Yeah, absolutely. Twitter has been amazing exactly for that. It's just an efficient way to crowdsource opinions and crowdsource perspectives and when you get your question answered and someone else answers it, it doesn't only benefit you the way it would if you email someone but it benefits anyone else who comes across that page, so yeah, it's hugely valuable. CHARLES: I remember the first moment I had kind of like that, a light bulb went off in my head where I was working on some really weird project that was using some strange wiki for its content storage and I was getting frustrated and I just tweeted about it and then the CTO of that company just immediately answered my question and I was like, "What?" You know, it was years ago and definitely, I was like, sound of explosion, that is where my mind exploded. I was not seeking help. I was just literally being kind of a jerk and venting frustration and lo and behold, the answer for my problem descended from the Twitter clouds. It was incredible. SARON: The Twitter clouds are the best clouds, usually CHARLES: Twitter is very... What's the word? It's very split down in the middle. SARON: Noodie? Yeah, there you go. SAM: There's this live feedback, so there's no buffer of emotion there, you know? SARON: Yeah. SAM: It's like, "Oh, this thing that you said, it made me mad. I'm going to tell you about it right now." Charles, I know that you had mentioned before that you think mentoring would be a good idea for Frontside and then, after all this discussion, have your views stayed the same? What are you feeling about that? CHARLES: As kind of the person who's like the grizzled veteran in the software world, it's definitely something that I've kind of whipped myself over the back. It's like feeling like it's something that we should do but I think it comes from the idea that people come here and we want to make sure that they're getting access to the learning that they need and the ways, in which they can level themselves up that they need, that's the kind of the prime motivator there. I always perceived mentorship as some vehicle through which to achieve that. It's something that I've heard. Obviously, we don't have a mentorship program at our company. It's something I felt that we should always be investigating. I've always felt maybe a little bit bad that we didn't have it but it's also something that I really struggled with in my career because I can't really say that I've ever had a mentor, so I don't really know what that relationship would look like but I do have a lot of people that I learned a lot of critical things from. I can look at it as kind of these seminal moments in my career, where like light bulbs went off and a lot of the time, they're associated with an individual and that individual and the thing that they taught me or multiple things that they taught me, are still with me. I have those experiences, which have been phenomenal and critical to my development as a software developer, so I guess it's just part and parcel of that impulse that you're describing to pay it forward, to realize that when you walked into the building, the lights were on and the walls were standing and the air was at a comfortable climate temperature. As you live there, you realize that there are people involved in actually, doing that maintenance and providing the building for you and the space for you to become aware of your world and then, when new people walk into the building, you want to provide them the same experience that you had. I guess that's my take on. That's the kind of thing that I would want to provide, so the question is like what does mentoring or mentoring 3.0, as we're maybe talking about in this conversation, how does that fit into that? How would you implement something like this, some sort of distributed learning in a company? I don't know. Maybe, it's not worthwhile. Maybe it is. SAM: I think it focuses more on that pair programming because when you're thinking back and you have all these people, like you have names of people that taught you something, it's multiple names. It's not just this one guy taught me all of these things. Actually, within a company, that mentoring just comes from pairing with your coworkers, seeing what different hats everybody wears and then, trying them on every now and again but not necessarily taking that individual's word as gospel, you know? CHARLES: Right and hopefully, that's not something that we've advocated for. Maybe, it's how do you introduce structure around that, to make sure that the proper ferment is happening, so that you have novel pairings and make sure the ideas that are flowing are flowing around the entire company and not just through certain set channels. SARON: Yeah. The other part of that is if you create structure around what it looks like to share outside. You know, pair programming is interesting because it's kind of one-on-one and it's hopefully, I have something important or bright to say in our pairing session. Maybe, I don't. Maybe I'm having a dull day. Maybe, I'm having a bad day but this really give you the same opportunity to take a moment and say, "What do I know? What do I want to share? What do I want to put together?" It does really give you a chance to prepare and gather yourself. It's kind of in the moment. I think having another opportunity where you can gather yourself is important and so, that might look like brown bag lunches, where everyone takes a turn and has to do a little lightning talk. That's usually the opportunity to say, "I have five minutes. I'm going to share something." Everyone has a turn, which means that the company's literally saying everyone has something to say. It's only five minutes, only a few minutes, so hopefully it won't be too terrifying if you're not big on public speaking and it's your co-worker so hopefully, it won't be terrifying because it's people you know and not total strangers. You know, a format like that, where there's structure but the company is saying, "We're going to give you time to think about what you're good at and what you know and to share that is good." I think another way to do that is by setting time aside for blogging. If your company can say, "Thirty minutes out of the week, we're going to take some time to write down five things I learned, to write down one cool thing I learned, post it publicly, post it internally about this expectation that everyone should be writing, everyone should be sharing, which also says everyone has something to share." I think those are two ideas and two ways that we can create a culture of sharing and a culture of distributed mentorship, where everyone has an opportunity to find the thing that they're excited about and specific ways to share it. SAM: Yeah, that's excellent. CHARLES: I hope you're grinning as much as I am, Sam because at least in the first half, you basically described our Lunch and Learn process. It's a little bit more than five minutes but I think another thing that clicked for me there is making sure that having a variation of expectations of quality or something like that because I feel like where we do really well is in the Lunch and Learn thing. We have a process very similar to what you describe but where we're not so good is maybe with blogging. I wonder if part of that is we just hold ourselves to such a high standard of what it is. The idea that we could throw together a blog post in 30 minutes, I love that idea but it means you really have to be willing to just say, "You know what? We're going to get it out there and we're going to make it bite-sized and the expectation is that we're not going to be writing some gigantic essay that's going to shake the industry to its core every Friday at three o'clock." There are things and if we can, I shouldn't say a reduction in quality but maybe a reduction in scope so that you can say like, "We're going to carve out 30 minutes or an hour and we're going to pick a topic that scope-appropriately for that." SARON: Absolutely and I think that knowing that you only have 30 minutes or maybe it's an hour -- an hour is probably a little bit more realistic -- but knowing that you only have an hour also forces scope. You can't write a book about JavaScript in an hour. You just can't, so the fact that by the end of that hour, you have to have something to turn in is a great way to force people to focus and do something really small and really bite-sized. The other thing is I don't think that after the hour, you need to publish it publicly. It could be, you need to turn it into someone else, to edit and look over for you and give you feedback. It's not quite ready yet but it's a solid first draft and the ideas that after that first person edits it, then it's on its way to being published. I think there's different ways to manage a scope without also making this scary thing where I have to say something for the Earth to shake. There's different things that we can do around that. CHARLES: I'm wondering what other forms of sharing that we can fit into our workday. I guess, the other baseline is just making sure that you're always... What is it? ABT -- always be tweeting. It's so easy to be write-only, not even engaging conversations but just throwing ideas out into the void. SAM: I think holding a discussion with your coworkers like if you're in an environment where you can work face to face or are constantly online, if you're more of a remote worker, I think just having a conversation with anybody, rather than just putting your idea out there, putting it out there with someone who can actually provide real time feedback in a more friendly way, then I think some people on Twitter could be. Because they're your coworkers and they're not going to call you rude names, you know? CHARLES: Right and you're also going to know, hopefully the whole trust and intent and 'are we on the same page?' that question is answered even before the text is written. SAM: Right. SARON: Yeah, absolutely and with those conversations, this actually mean [inaudible] that we do. We do like a show and tell every week and the idea is that we're both always learning random things, usually related things but sometimes, totally random but still very interesting and it will take 30 minutes to just share what we've learned. Sometimes, they'll also turn it into a blog post. Sometimes, it's just a knowledge sharing opportunity. I'm not really sure but it's a good window of opportunity to say, "We are learning and we're sharing and we have something of value to bring." The great thing about something like a show and tell is that it doesn't necessarily have to come from my brain. It doesn't have to be like, "I have a great idea that I'm going to share." It could be, "I read about this cool idea." It can be, "I heard about this cool thing that we can try and we can apply," but I still kind of credit, you know? Like I get credit for being the value bringer but the burden isn't on me every week to come up with the idea. That's a nice balance, to kind of create space to share and to promote this knowledge share and if it comes from you, it's great but if not, you're still helping other people. CHARLES: I have a question that may or may not be related in here. This has just kind of occurred to me because this is definitely something that I experienced, where I get into a mode where I become overwhelmed by the ideas that people are sharing and so, what's the balance? Because usually, we're out there searching for ideas and we're searching for novel things so that we can include them in our work, in the things that we want to do and accomplish, whether be that in tech or elsewhere. What's the balance of being heads down and being like, "You know what? I'm going to be closed to new ideas right now." Because they can be distracting, right? The [inaudible], that's actually a phenomenon and so, how do you protect yourself from sharing? What's the balance? SARON: My solution was to move to San Diego. That was my solution to that. I actually moved from New Jersey and I worked in New York City... How long has it been? Was it only been a year? Oh, my goodness, and now, I'm in San Diego and it was so interesting because that ended up being a really nice side effect. I didn't move specifically for that reason but when you are commuting in New York City every single day, there's so much going on all the time. There's just so many ideas and events and meet ups and companies and people. It's just so much. I think that it was a great place to be in my early 20s when I really just wanted to soak up everyone else's ideas and I didn't really have opinions of my own at that point and it's a great way to just kind of absorb and be this awesome sponge in the big city but after a while, I kind of realized, maybe I have my own ideas and my own thoughts, so moving to San Diego, which is a much, much, much quieter place, has been a really great way to reflect and sit with my own thoughts and feelings and opinions and just kind of focus on that. I understand that everyone can move to San Diego, although I highly recommend it but I think in that way of carving out like... What do they call it? Do they call it a tech sabbath? A digital sabbath? Am I saying that right? CHARLES: Yeah. Maybe. It sounds about right. SARON: Yeah. I came across that term recently but this idea of one day out of the week, I'm not going to be on the interweb. I'll just not going to do it. Maybe, even the whole weekend, oh, my goodness and saying, "I'm just going to stay away from things. I'm just going to create a little space for me to think and reflect." I think when I don't have the whole day and what I need is just like a moment, I find that writing things down is a great way -- a really, really good way of doing it -- even if I'm taking notes or from doing a strategy session or if I'm trying to make a decision. Usually, I'll start typing and what I've started to do recently is to say, "I'm not going to type. I'm going to plot in a notebook and I'm just going to write things down," and because writing is slower than typing, it forces you to just think. It forces you to be alone with your thoughts, for better or worse and it forces you to really just to think about what you're doing or what you're saying and reflect. It's a really, really great meditative exercise that I found. You know, finding little ways to build in an escape from the noise, ideally on a regular basis, I think is a really healthy thing to do. SAM: Yeah, I definitely agree with that. My normal method of sort of closing everybody off is I just sketch out ideas because I'm an artist. I come from that sort of perspective as I can make a drawing out of feelings more so than I can write them out. If I'm feeling really overwhelmed or if I'm trying to make sense of some information that people have given me, I just sketch it out and I think that's something that doesn't really get talked about a lot in the whole community because sometimes it's always about eat, breathe, live, code, you know? We have different skills. You have other things that you're good at that's not just code. When I was at React Rally, a lot of people were in the music and then finding a way to separate yourself from the entirety of it is definitely one of the better ways to make sense of your situation. SARON: Yup, absolutely. CHARLES: Yeah. Sleep? It's a great way to take a break. SARON: Sleep is so good. SAM: On my top three things: sleep. CHARLES: Yeah. SARON: Yeah. As a kid, I never ever thought I would look forward to my bedtime ever. You know, it's my favorite part of the day. CHARLES: Yeah but like sleep, writing, drawing, I always forget. Like when I'm caught up in a problem, I always forget that engaging in some other activity -- I like to walk in the place next to my house. I like to play my ukulele. Engaging in those activities is almost on the critical path to solving the problem and I always forget it. I think we always forget it but sometimes, you can be so frustrated and you can just shut it off, be completely alone and there is some magical process that's probably going on in your brain. I don't know exactly what it is but you come back and the answer is just sitting there, waiting practically on your desk. SARON: Absolutely. One thing, we recently moved a couple of weeks ago to a new place and it's a little bit bigger and so, I had the opportunity to unpack boxes and buy furniture that we didn't really need before or just trying to make it more of a home. I've been using it as a really great opportunity to be productive and to feel productive but not be in front of a screen. Sometimes, I even like save tasks for myself like, "I'm going to wait till the evening to put together this shelf because I'm going to need a moment to just be away from my computer." I have a plan around it so it ended up being such that, I think about every day, there's one little home activity thing that I can do, whether it's cleaning or cooking or assembly or movie or something with the home, that allows me to, because I'm not really a hobby person. I don't really do hobbies because it just feels, like no judgment on people who do. I know people get really into their hobbies but it just feels like, "Why?" You know, like, "Why?" like, "For what?" But when I put a shelf together, it's like, "I'm going to use this for books." You know what I mean? Like you're very purposeful, so home activities has been my way of carving out that space away from the screen but also feeling like I'm doing something productive, I'm getting things done. SAM: Something that I would recommend to anybody who doesn't really have that, I'm going to step away from the computer and do this thing. Something that's kind of helping me was the Pomodoro Technique, which if you're not familiar with that, it's basically a time management thing where you set your timer for work like for 25 minutes, 30 minutes or whatever and then, when the timer goes off, you take an allotted break for five minutes, 10 minutes, just so you're not doing the thing that you've been doing for the last 30 minutes. SARON: Yes, absolutely. That's a great one. SAM: My advice is to implement that if you don't have a thing, that you use for your cleaner, I guess. SARON: Oh, you want to hear some really terrible but effective advice? SAM: Yes. SARON: And this is what I found out very accidentally is if you have a really, really crappy office chair that hurts -- CHARLES: Oh, man. I'm sitting in one right now. It's literally a rocking chair from the 1800s. SARON: That sounds awesome. CHARLES: Yeah, it does sounds awesome. SARON: But if you have a crappy office chair, that can be a really great way to get away from your screen because after about an hour, your thighs will hurt and your back will hurt and you will be forced to get up and walk around. It's so funny because I have a pretty crappy office chair and my back has been hurting for so long and I just thought, "That's life." That's like my [inaudible] for myself. I'm like, "That's just how life is, my backs hurt," and then it got to a point where I was like, "I need to go and talk to someone," and as soon after that, I spoke to a conference and I was basically up and down away from any type of chair for like four or five days straight and magically, my back pain went away and I was, "Oh, my God. It's that freaking chair," and ever since I realized it, I started noticing it. I would sit down and I would go, "I'm nearing the one- Oh, there are my thighs. There they go. They're in pain." There's another great cheap life hack: get a crappy chair, after about an hour, everything will hurt. You will be forced to go do some jumping jacks for about five, 10 minutes and there's your additional sabbath. There you go. SAM: In Charles' case, probably a haunted office chair. Yeah, that's an excellent advice. I never really noticed that. Now, I'm going to. CHARLES: You know what funny is, I actually didn't even notice it but I do. I never used to get up and go on walks before or spend as much of the day standing as I do and I'm actually completely and totally oblivious to it but I think, I realize like I can attribute a lot of that to the terribly, uncomfortable chair, in which I sit on every day. SARON: I have this awesome habit of sitting cross-legged, which apparently is a very, very bad idea, my physical therapist told me, so I make it worse for myself. If you don't feel like you have enough screen time, just sit cross-legged and that will accelerate the pain process. SAM: As you said that, I am currently sitting cross-legged in my desk chair. SARON: Yeah! SAM: That's just how I sit in chairs. My legs are too short to reach the floor. SARON: Me too. I just find it so comfortable. I don't know and I'm so happy to hear that you also do this because I'm like, "Am I just weird?" because I love sitting cross-legged. It's so comfortable. It makes me really happy. SAM: No, I verified 100%, that's how I sit in all chairs. SARON: Yeah, the same. CHARLES: I can do one leg. SARON: Only one? Man, you need to work on that. SAM: -- [inaudible]. That's going to be the end of our podcast. Again, thank you Saron for coming on and having this awesome conversation about mentoring. Definitely check out the website CodeNewbie.org. We are the Frontside. We build software that you can stick a future on. Hit us up if you're looking for help building your next big thing and also, hit us up on Twitter. Hit Charles, myself, Frontside and Saron on Twitter. SARON: Thank you so much for having me. This is awesome. This is fun. SAM: Also, I want to give another thanks to Mandy, our producer for producing this lovely episode and all of our episodes. If you have any questions for us, hit us up on Twitter. Any ideas for future topics, any thoughts you have on this great conversation, let us know and we'll talk to you all later.

Guests: Brandon Hays: @tehviking | Blog Chris Freeman: @15lettermax In this episode, former Fronsiders, Brandon Hays and Chris Freeman join Charles and Taras to talk about the difference between a framework and a library, whether or not React + Redux a framework in itself, red flags to signal that you're actually building a framework, attributes of a good framework, how can you tell if you created a bad framework, and how you can make a bad framework better. Resources: Test Sizes by Simon Stewart This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. ** Transcript:** CHARLES: Hello everybody and welcome to The Frontside Podcast. My name is Charles. I'm a developer here at Frontside and today, we're going to be talking about the things that go into making a JavaScript framework. Because, hey, there's not enough of those in the world today, so we're going to talk about that and with me is Taras. TARAS: Hello, hello. CHARLES: And we've got two very special guests, who have a lot of experience with this topic. Mr Chris Freeman and Brandon Hays. Hey, guys. CHRIS: Hi, there. BRANDON: Hi, there. We're talking about the poofberry framework, right? CHARLES: What's a poofberry? BRANDON: There's a tweet that's going around right now that one of them says, "I don't know what I should be doing," and the next person says, "Oh, just use poofberry." What is that? It's like fluffnuts but the [inaudible]. Hey, dot, dot, dot. Then, it integrates with log bungler. CHARLES: There's a reason that I'm dying laughing. BRANDON: It's so true. CHARLES: It's so true, laugh, cry, laugh, cry. Let's start with kind of a very basic assessment here. Because there's a lot of different things that you can use to compose the applications that you build but for some reason, some of these things are grouped and considered as libraries and some of them are considered frameworks. I don't know that the boundary is very clear like I'll know it when I see it type thing. Maybe, we can start with what is the difference between a framework and a library? CHRIS: I have some thoughts of these. I feel like this is one of those questions that could easily just turn into an infinite bike-shed but I remember reading something a while ago that stuck with me for a long time. I'm pretty sure it's related to Java but that makes sense because if anyone is going to talking about frameworks, it's Java developers. But it was saying that the difference between a library and a framework is inversion of control and the idea is a thing that's a library is a thing where you are in control. You bring the library code into your code and it's up to you what you do with it. In a framework, the framework code calls you as I think what it said. It's like, you call the library code, the framework code calls you and -- CHARLES: In Soviet framework. CHRIS: Yeah, exactly. A framework says, "Here are a bunch of open spaces for you to put your code in and I will take care of the rest," versus a library is just like... I don't know, "Here's some things that you can use. It's up to you. What do you want to do with them?" CHARLES: Right, so in kind of like [inaudible], that would be basically, a framework would be the thing that's got the main method. I think the same thing in JavaScript and when you call it, does it actually implement the main method. In JavaScript, it'll probably like in node. Under that definition, it would be like, "Are you the main scripts when you invoke node? Do you control the main script?" If you were doing your own command line parsing, for example, you're looking at the process.rb and pulling off the command lines and doing all the things but even if you're using something like Yargs or option parser in Ruby, that's more of like a framework. I guess Yargs is a library because you're still implementing the script. You're instantiating the Yargs thing. TARAS: React calls render to figure out what to convert to DOM. Does that make React the framework? CHARLES: I think React as a library. That's a good question. What's the equivalent of the main method on the web? CHRIS: I think there's a very clear distinction, especially if you look at React versus something like Ember and I'm sure Angular does this as well. In React, by default, to build a React thing, you're going to pull in React, you may write some components, you may import them elsewhere but the main method is that you have an index.html with some div in it and you are the one that has to call ReactDOM.render and you pass it like document.query selector or whatever and then, your top level component and that can be as simple as complicated as you like or you can have a webpack plugin do it or whatever else. But the onus is on you to actually take that React app and get it starting up on the page versus Ember, it's like, "There's an index.html. It's fully wired up." There is one point where you sit down and say, "Start my program here," like Ember abstracted all that away. To me, that's the main method for a frontend application. CHARLES: Right and if you actually look at something that Ember generates, then look at index.html, they generate a script tag for you that instantiate your application and mounts it on an element. If you want to change that element, that's actually a configuration option that you can change but it still a configuration option that's consumed by the framework. In that sense, there is that inversion of control. I see what you mean like in React, you're the one who flicks off the first domino, like who's the prime mover. Is it you or is it the framework that knocks over the first domino? BRANDON: I like Chris's explanation and I think it's elegant to say because I was thinking in terms of structure. If it imposes a structure on you but really, the structure is there, it's like one of those Ikea shelf systems for you to put stuff into. If you're trying to solve a problem, here's a shelving system for you to put stuff into, whereas a library is just the tool that you might get out to put something together. Something that's multi-purpose but doesn't impose any structure on you or a ton of structure on you. My question is what's the usefulness of distinguishing between the two? TARAS: I think what's interesting and I had experienced this in a last couple of projects is that people, especially React when they kind of assume, because a lot of people entering to React not understanding the context within which React emerged and so, they're getting into React assuming that it has everything you need to build application that you need to build. A lot of them haven't necessarily built a single page application from scratch before and so, the jump into building something with React and then, it takes about a year for them to realize the full scope of all of the features that their application actually has and then, they kind of take a retroactive look and look like, "Okay, what do I have now?" and what emerges is that they've actually over the last year, they may be creating a framework without realizing that this is actually happening. CHARLES: They've imposed the structure of saying, "Here's the shelving system. Books about geography go here. Books on English literature go there and so on and so forth." BRANDON: But when you rolled your own framework, that's not how it goes. It's like, "You have to launch this balloon into the stratosphere to put a book on the shelf from geology." Taras, to your point, it sounds like the importance is setting expectations properly for people, so that they know what they're in for because kind of calling back to Ryan Florence's post a few years ago, you can't not have a framework. At some point, you will have a framework in order to ship something. I would actually take it one step further. My friend, Kyle talks about this that library is the smallest unit that you're working within a framework but that still doesn't take your code to production and put it in a debugable state. You need a platform. It's arguable, if you're handling deployment tasks and debugging tasks and operating software in production, you now have a platform and it's fair to say that Rails crossed that threshold at one point. It's fair to say that Ember has probably crossed that threshold, if you combine Ember with CLI deploy and the CLI tooling and all of that stuff. This almost like acts as a platform if you're owning and maintaining the software in production. CHARLES: Now, can I play devil's advocate here and say, the platform, is that necessarily predicated on a framework? Is there a pyramid where it goes library, framework, platform and one is built on top of the other? Why couldn't I have a library? Because what I'm hearing is the scope of concerns is just rendering HTML based on a state is a very small chunk. The actual scope of things that you need to do to get that code in production and have it be reliable and do all of the features that you want to do is just massive but why is that predicated on a framework? For example, one thing you have is a bunch of libraries out there, like routing for managing the title tag, managing all these things that you have to do for managing deployment, for building your application, for compressing it. There's all these different libraries out there. What if there was one massive library that just picked a bunch of other libraries but I was still in control? TARAS: I've actually seen this happen in the last of the projects. When people jump into building, they will eventually realize that they're building a platform but what happens before that is that they take user's requirements and they break those up by sections and then they assign them to a bunch of development teams who go and actually start to build. On one platform, they end up building five or six or 10 of siloed, packaged applications that have, in some cases, have their own dependencies, they have similar architecture, might not have similar architecture. Each team kind of implements thing differently and there's an expectation that once you package these things as npm and then you install them into one package, to one application when you run build, it's just going to work together. That's where I think, with the framework, it does create a foundation for these verticals to be implemented using kind of common foundation. This is what a lot of times that as if you don't realize that what you're trying to set out to build, the way that the projects get managed quite often, especially for big applications, for big platforms is that, it creates this period of about two years, where there's a lot of confusion and there's a lot of duplication and then, you end up seeing code that it's hard to put in production. CHARLES: Yeah, I agree. I'm curious then, because we'd started out talking about library and framework and talked about it takes two years to recognize that you're building a framework or you're building not a framework but a platform. Brandon, you said something very interesting. Rails for example, crossed the threshold of being more than a framework and actually, being a platform. What are the concerns of a platform that are beyond a framework? We talked about and using the kind of loose definition of a framework as being something where the framework create spaces for your code, to run your code so you can just take little dollops of code and they have one concern but the framework manages the coordination of the concerns but what's the next level? BRANDON: For the purposes of this conversation, I may have muddied the waters a little bit because I think it's more interesting to talk about the transition and the level of which you've crossed the threshold from being a library or using libraries or collecting libraries, into maintaining a framework because it's where you're going to experience more pain more than likely, than to me, the idea from works on my machine, to deployed and supported across a lot of users, it sounds like it's more interesting but it's not where we experience most of our pain actually. From my experience, maintaining frontend single page applications most of the pain is actually getting the damn thing to work on your machine and getting the libraries to collectively work together and then, getting that to production, it kind of enters back into an area of more known unknowns. I think that's a surprisingly a more mature ecosystem, still getting from this thing works on my machine to getting it out the door. That wasn't true when Rails was invented and so, Rails had to invent a lot of its own ecosystem around this stuff. Like I said, I don't want to muddy the waters too much. I think to me, the interesting question is how do you know you've crossed this threshold? What pain points are exposed when you start crossing that threshold or when you're pushing the boundaries of that threshold? Because you should not be using a framework if you're using React to do a select dropdown. I think of it as, if you're using it the way to replace something you might do with a jQuery plugin five or 10 years ago, you're using React like it's a library. One of the questions that you brought up was is the combination of React and Redux is a framework and I would argue that it is but I kind of want to throw that out -- CHRIS: Oh, interesting. CHARLES: I would say, it's two libraries stuck together to make a bigger library. It's like a monolithic library. BRANDON: But by the time you're actually using that to do anything, maybe the third thing in there is like transitioning states when you transition routes. At what point is that threshold crossed? I didn't build most of the software that led me to some of the opinions that I have about this. This was actually Chris Freeman's, though. I may defer to you on this. CHRIS: I think React + Redux constitutes if you look at what it does. You have like this view layer and this state layer. There's a set of opinions on there that is useful and there is the foundation for doing quite a bit but in my experience, you've already kind of alluded to this a little bit. I don't think it's a framework because as soon as you start using those two things, suddenly the next thing you hit is, "Wait. How do I handle asynchronous things?" There's a lot of different options for that. "Oh, now, I need to do routing. How do I incorporate routing into my React app but also in a way, that is amenable to state transitions in Redux but also, that is aware of the async stuff that I'm doing, that is going to possibly be triggered by my routes and by my Redux actions or by some other side of things?" Suddenly, you are very quickly pulling out a bunch of other libraries but also, probably starting to build abstractions on top of them because you're already finding a lot of common patterns that you're repeating over and over as you incorporate more and more pieces of the stack and then, you're writing a lot of glue code. I think that's the point where suddenly, you look back and behind you is the footsteps of this framework that's been walking alongside you the whole time. BRANDON: That is where I carried you, then dropped you, then sort of drowned you. CHRIS: Yeah. CHARLES: And then, kicked your core. TARAS: I'd like to suggest a way to think about this. As you guys are talking about, it kind of occurred to me is that it seems to me that libraries concentrate on how and frameworks focus on the 'what.' CHRIS: Oh, I love that. TARAS: Because if you think about for example, React is how geostack efficiently update DOM, then Redux is how do you wire together state across multiple components that might be in different parts of state tree and if you look at, for example, a React router or a kind of a routing component is how do you choose which components you want to render when you navigates specific URL. Because those things by themselves are not a complete solution but when you combine them together, what you get is you have a way of saying, "When I navigate to specific URL, I'm going to load specific data, provide that data to components and then, I would have a way to navigate through a different URL when you click on a link." From that, I think what happens when you get to the framework level is you actually have a kind of a bigger umbrella and under that umbrella, you have ways to address problems that you did not have previously. I think that's what framework does it is over time, it's a way of addressing concerns that cannot be addressed with a solution. They have to address with a collection of solutions and then, they provide a specific solution. I don't know if that's -- CHARLES: That actually sparked off a train of thought in my mind that perhaps what you really want to do is say, "I'm going to go a little bit like Lisp on you all," in the sense of every code at some point is data, that maybe every library, at some point is a framework. It's just that you can look and say, "What is the scope of the 'what' that I'm tackling." For some point, you can say like React is a framework. It creates this space where I can put my JSx, AKA the render function and I'm basically inverting control and so, what it is, it is a framework for efficiently rendering HTML or efficiently mapping an object to a fragment of DOM and then the DOM that gets generated from your render function, patching that into the HTML. You don't have to worry about that. There's that inversion of control. It creates that space but that's the only space that it creates. From that perspective, React is a framework for generating HTML but that's all it is but it is a library for constructing applications. Does that make any sense? I think as you layer on concerns, your framework create spaces for you. You use your library code to put stuff in and so, in the same way, I think one of the key realizations, I'm going to call up like BigTest and I'm not going to take credit for this, which is actually a blog post that I read at Google. I can't remember what it is but we'll link to it in the show notes where he said, "There are no such thing as unit tests. There are no such thing as acceptance tests. There are just tests of varying scope." They're all acceptance tests. To use that one thing, they're all experiments. It's just what is the scope of the test that you're trying to accomplish and his argument was we want to make that scope as big as possible by default and then, where appropriate, you narrow down. Maybe, the framework library distinction is a little bit constructed, kind of a construction of our own minds and what really is there, there's just frameworks of varying scope. BRANDON: Agreeing on a shared scope is actually probably the most important part of this conversation. We're referring to building end-to-end an application from data access to rendering to testing -- CHARLES: To deployment to routing. BRANDON: Yeah. CHARLES: To one day accessibility. BRANDON: Yeah. Adding that into the discussion is like a baseline of what constitutes an application. It's the percentage of people that are able to actually use it, the people that are locked out from using it by ability. That's a very useful frame for the discussion. Let's agree on the scope of what an application is and then, coming back to what Taras was saying is basically, when you're talking about the 'how,' that's a decision point. You hear a lot of people talk about decision fatigue in JavaScript and it's almost a played out trope at this point but it hasn't gone away as a problem, so what frameworks are doing is they're making a series of decisions for you that allow you to basically connect the pieces from end to end. Basically, somebody threw a rope bridge across the canyon and it doesn't have to be the best solution to get end to end but we have to solve the problem end to end. If we agree on the places end to end and the problem is when you're building your own series of libraries, you're like, "I'm going to choose best in class of A, best in class of B, best in class of C," and that sounds really good but if you're trying to build a bridge across a canyon and you're building in 10 best of class sections, for the type of connection we're trying to make here in the middle, we're going to use the best in class here. The weak point is in the connections, so you had better be the world's foremost engineer if you're going to be the person connecting all these disparate pieces that are each best in class, in order to bridge this canyon. That's the thing that's interesting to me and it's not even agreed in our industry that JavaScript-based web applications are a good thing or that the browser is web application runtime, those are things that are up for debate. But I think if we make that assumption, this is sort of the founding principle of where Ember came from and it executed to the best of its ability at the time and that philosophy is, I think you can prove it out in terms of results based on if you have two different applications, one of them is built by somebody trying to jam together best in class components and the other person is starting with an end to end solution with a community of people rallied around that solution. It's been interesting to watch those approaches play out over time. I know Chris has a very specific hands-on experience of having done both of these. I'm curious to get your hot take. CHRIS: There's actually a concept that I think about a lot in relation to this question. It's something that I actually heard come up again recently so the timing was great but it's called hypocognition. The idea is hypocognition is when you either just like can't see or can't understand some kind of cognitive representation of something because you don't have the words for it. An example is in Western cultures, especially like in English speaking cultures, there are not that many words for the color blue but in a lot of other cultures, they have many, many words for the color blue. After doing a big study they found that these English speakers actually have a harder time recognizing different shades of blue, like more of them just look the same versus other cultures where their brains are actually wired to see all this variety because they actually have the linguistic representations for these ideas already. When you were talking about maybe a library is a framework at some point, I think that's right on. I think one of the things that I think about a lot when talking about frameworks and seeing these debates happen on the internet about, "What is a framework?" but also like, "Do you even need a framework?" is obviously, there's a lot of people who absolutely... Like Ryan Florence. Ryan Florence clearly knows what a framework is. He knows what it takes to build a web application and he does not lack the words to define a framework versus a library. He's just made that choice and it's a very informed choice but I wonder if there's also a lot of people who are getting into web development for the first time and they look at something like a framework and it seems just absurd to anyone would want all of the things that like in Ember or in Angular is talking about, when they can make a basic UI with React and it's easy and fun and really cool. But then this two-year path happens and they look back and they've learned a whole bunch and now it's like, "Ooh, you couldn't even have explained this to me before," because all of the words would have fallen on deaf ears but now suddenly, it makes a staggering amount of sense. CHARLES: Right. I love that. BRANDON: You have to make a bad one. CHARLES: Just so that you can inherit the vocabulary to understand why you made a bad one. Now, you guys actually have some experience with this. Brandon, you gave a talk about it, which I think you should give more widely because it's fantastic but for those folks who may or may not be aware that they are walking this to your path, I want to talk first about what are the signs that you're walking along this path and then two, what are the consequences in terms of the cost you're paying for walking this path. Let's start with that first thing. What are the signs? How can you tell that I am building a framework? CHRIS: I think one of the telltale signs and one of the biggest red flags that caused me and Brandon to have a very serious heart to heart about our own personal framework was when we hit the point where you could look at a set of tickets for features and all you saw was 'framework features' that you needed to write before you could build the feature itself. You know like, "Oh, we have basic routing setting and we have it set up so that if you have a route transition and you would like a data request to happen when a certain route transition happens, that will happen," but then someone would like infinite scroll and we want to use a query param. When a query param changes, I want to update the query and fetch more records, except that the glue code that we wrote to tie our router to our redux async stuff is not aware of query params. It has no concept of what a query param is or what to do when it changes. Also, it has no concept of refetching the data without a full route transition, so what do we do, this person wants infinite scroll but I first have to implement several layers of framework code before I build the UI feature that you want? CHARLES: The basic heuristic there is ratio of direct feature code to code that supports the direct feature code and code that supports the code that supports direct feature code. It's anytime you're anywhere above that first layer on the stack. CHRIS: Yeah, I think Taras nailed it like what's the 'what' versus the 'how.' If you're asked a question that is concerned with the 'what' and you spend more time focused on the 'how,' then you might have a framework. BRANDON: I think people will think of building an application like a recipe. If you think of it in those terms, people think of frameworks as very restrictive but I'm a big fan of Blue Apron, a sponsor of this podcast. Thank you. They pre-select the ingredients and they give you the instructions and you know what to do, you still have to do the effort but you know if you connect these pieces together properly that you're going to wind up having a good experience and then, it gives you a lot of freedom to experiment and be creative beyond that, should you choose to. I think one of the signs that you've done a crummy job is that you're staring down, like Chris Freeman said, you actually starting to restrict your choices like, "I can't actually build you that feature because we don't have time to take on the amount of work necessary to build the support structure, to build you that feature," or if you find yourself writing a test framework. CHRIS: Oh, yeah we did that too. BRANDON: You know, we were real deep in this. There are developers that are like, "I really want to feel like I'm walking into a grocery store and selecting all the things necessary for my recipe," and so it really depends on what the problem actually is. If you're working at a giant megacorp and you have a two-year timeline to deliver something and their goals are not about delivering stuff on a tight turnaround, that's usually a recipe for a software failure anyway but let's say, that you're in the 5% of those types of projects that's going to succeed, that might be a good place where you can say, "What we're trying to do here is so custom and we have such a long lead time and a long leash and such a high level of internal expertise here that we should be shopping in the grocery store and we should be selecting all these things and we should be solving these problems." Basically, when is it time to use a framework? Well, when you don't have 10 times the time you think you do, when you don't have the ability to spend 80% to 90% of your time in the first three to four months of your project, maybe six months, debugging you're glue code in between the different libraries that you're gluing together and then coming back and realizing that you've painted yourself into a corner and you have to re-architect your whole framework, then you could be so proud of this baby, 18 months to two years from now, when you actually have delivered both a framework that took about 70% of your time and an application that took 25% or 30% of your time. CHARLES: Yeah. I think it's important to realize that people think we'll do it and we'll build it as we go but I want to call out right there, you will be spending 80% of your time and you have to be upfront about it. Of this two years, 18 months of it is going to be spent building this framework and six months of it is going to be spent actually writing the feature code and you have to be 75% of your tickets or your issues, whoever track the work, 75% of that has to be dedicated to the framework. BRANDON: If you're going to bake in that kind of overhead purely for the satisfaction of a single or one or two developers that like inventing things, that is literally the worst possible reason you could do that. That is almost like a guaranteed recipe for failure. It has to be for some other business reason like, "We want to be the company that owns this." There has to be business value attached in making that kind of investment. If you can't justify that at the outset, then you should probably just go ahead and lean on an existing framework and join a community of people. CHARLES: Yeah and I think one good litmus test for that is, "Is this a 'what' for which there is currently no 'how?' One of the reasons we're writing BigTest is because for the general JavaScript community, there are a number of acceptance test frameworks out there but the market is very, very limited. When we look to actually acceptance tests, our React application, this thing does not exist. Now, we had experience with something that was very like Ember specific and so, we kind of knew what the 'what' was, we experienced the 'what' but there was no 'how' for our current situation. That's like a place where you might be called upon where makes business sense to actually invest in a framework. I'll tell you another thing too is if you have made the decision to kind of follow the beaten path on the other areas, then when a framework is called for, you have the bandwidth. You've allowed for the buffer, for the margin, for you to write in with that framework, whereas if you're already just by default, maintaining all the glue code in every single thing, then if some unique 'what' comes along, for which there is no 'how,' you're not going to have a bandwidth to tackle it. BRANDON: Yeah. That's a real bad situation to be in. TARAS: There's something else that I find interesting is because there's a certain point, like this two-year mark where everyone's like, "We want to fix this now." I think what is interesting what comes next which is the three years of undoing all the stuff that you made because the biggest challenge, especially in really big projects. When your projects has to borderline into platforms and a platform threshold is when you have a multiple teams working separately to write separate modules that run, maybe in a separate Git repo and maybe, packaged in separate npm package and assembled together. Then what happens at that point, the question arises like how do you actually make this changes in this environment. Answering that question is actually really difficult. I think if you look at frameworks like Ember, Ember has made it their business to figure out exactly how to make this happen and I think they've done it really well but it's a really challenging endeavor, especially in incorporate environments where they don't have an update. You have like upgrades are like a curse. It's like a thing that you don't really want to ever do and because most quite often, they don't have the right testing habits in place to be able to support the change if necessary. I think what a lot of times happens is that the team that made the framework in the first place, they end up trying to maintain a fort but you won't have like 10 people and they only have machetes, you know? All you can do is run around and try to chop down little twigs but at the end of day, the trees is still going to keep growing. I think that's the really challenging part of being two years into a project, where you realize that you actually need something much more comprehensive than initially thought you needed. CHARLES: On that, assuming that you have decided that you are going to make a framework, it's a good business decision for you. Based on the criteria of this discussion, how can you assess whether it's good? Chris, you talked about needing to integrate query params with routing and asynchronous data loading and making sure all of that coordination happened and worked together easily. What's the difference between your framework just missing features kind of having holes in it that can be filled in, versus something that's not good and it's going to cost you lots of money down the road. CHRIS: Yeah. TARAS: One thing, if you look at what makes a good library of any kind, it tends to be like how effectively and how much words to take the address the use cases that you need. The problem is that to build a good framework, you need to understand the use cases. This is what usually happens over time. Two years in, you've actually understood the use cases and now, it's time to change and so, I think if you want to build a good framework, you actually need to understand those use cases quite early on or account for understanding use cases over time and that's a big question -- how do you figure out how to know what you don't know. CHRIS: Yeah, I think that's exactly right. I think about what you were just saying Charles and Taras like one of the things that I think has a big impact on and what this process looks like is the completeness of vision for what's your project actually is. If you have a very, very clear idea of what the entire product you're building is going to be or, at least what the key money-making feature is going to be and you can understand the ins and outs of that, then I think that's the point where you can look at what you have and say, "Have I created a good or bad framework? Does this framework have the ability to solve this one very important thing that I have to be able to do? If the framework doesn't do it, then I need to build my own but I now know what very important features I need to front load my framework with." I kind of think of it as imagine that you're like Jeremiah Johnson, the Reverend Jeremiah Johnson and you're going to go trekking through the woods for some unknown amount of time and you have no idea yet. You don't actually know where you're going. You don't know what you're going to see. You don't even know what's out there because you haven't done the research or whatever and you need to be prepared for anything, so you bring just a hodgepodge of stuff. If that's you at the beginning of your company or the beginning of your product and yours is kind of like... I don't know, we got to get product market fit and that means that we may have to kind of pivot once or twice or we need to be very flexible, then I would think long and hard before you commit to writing your own framework because you don't even know what framework to build and you might as well take a broad array of tools and use what you need. There will be times where that's frustrating and there won't be exactly the right tool for the job but 80% of the time, it's going to do just fine but if you know you have to do this one very special thing and you know that a framework is going to give you a lot of stuff that you won't need and it doesn't really excel at the one thing you do need, then don't force the framework. There may be time to build your own but just know that you need to go in with a very clear idea of what you're doing before you start building the abstractions that constitute a framework, rather than just like a constellation of libraries. CHARLES: I have a question on that then. Going back to one of the things we were talking about like React plus Redux. Your opinion, Chris that it is not a framework, so the question is does a framework actually exist for React? CHRIS: My guess is that many frameworks exist for React. CHARLES: Is there a public framework? TARAS: There is one called Fusion but it's [inaudible] what you would have imagine. It is essentially Redux and React together conventionalized. They addressed a bunch of concerns around service rendering and such but it does exist. CHRIS: How about Next? Next.js? TARAS: I'm not familiar with its features from a single page application perspective. CHARLES: I think it does have a router. It does bundle with Redux and this is one of the things that when you first started using Redux, it's like, "How do I even get my store to my components?" Yes, I can connect them but there's actually a lot of stuff that you have to do. First, you have to say, "I'm going to put my reducers here and then when I create my store, I'm going to fold all my reducers. If I've got a whole bunch of reducers in my application, I've got to fold them all together. I've got to pass them off to the store. When I create the store, I have to inject the middleware and then, everybody else just imports my store and then, I have to put in a provider and then, I can connect my components." That's actually a lot of stuff that you have to do and I think that, for example, Fusion just says, "Put your reducers here and we'll take care of all that process," and so it makes that decision for you, right? It says, "For state management, you're going to use Redux. For your reducers, they're going to go here. For your actions, they're going to go here." I don't know exactly how it's laid out but I remember reading the ReadMe, it was basically layering conventions over that. That's definitely going into framework territory but that's the only one that I know of, which is really, really odd. TARAS: There's something interesting that's happening also and this goes to what Brandon was saying earlier is that choosing the best in class, there's this 10 things but then, what if one of the best in class stops being the best in class. The fact that the creators of Redux was essentially saying that we needed to basically provide a way to do Flux that was better than 10 different options that were available, so here's Redux. We've created Redux but we don't really think it's ultimately the solution. We need to have something else in React that provides a foundation for us to be able to deliver a better state management than what Redux is, so what happens when one of the best in class is no longer the best in class? The bridge is already standing. There's people walking across the bridge already. How do you replace one of the chains in it? CHRIS: Over the course of six months while you figure out the differences in API between Flux and Redux and all the custom route transition data loading stuff you did with your Ajax library in your state management software that you put in a case statement inside there that you now have to change over. It's easy. It's no big deal. Don't worry about it. BRANDON: Just a simple matter of programming. TARAS: At least 25 years of collective frontend development experience is laughing like hyenas about the simplicity of building a -- BRANDON: Yeah, I'm actually looking at some of the old code that Chris wrote for trying to glue together, Redux Saga. I've been out of the game long enough to not know whether that's been superseded by some new or best in class piece of technology and even then, it was really challenging. This is true for frameworks too, is they don't really optimize for best in class. They optimize, hopefully for best fit for purpose but the world has moved on since Ember launched obviously. A lot of things have changed and it's, at least as difficult to try to keep that up to date with evolving trends and technologies and updates for a core team at a framework level as it is for you, as an engineer on the team. The difference is you get to outsource that work to a core team for a framework. Ember has not done a fantastic job in keeping up with. They've done a good job and they've tried their best but if there were more people working on it or if there was more effort applied to it or if it was a higher priority, you would see Ember being a more up-to-date framework using more modern tools. As a framework author, if you stay too close to the bleeding edge, all you're going to do is change out your build system. You're going to replace a Broccoli with webpack, with Rollup, whatever's after that. What's new in Packer? CHRIS: Parcel? CHARLES: Parcel. BRANDON: Parcel. You should immediately go build your framework with that and have fun. I am excited by the new and interesting stuff that's happening in these ecosystems and I think it's important not to get lulled into the siren song if your goal is to actually ship a piece of software on a timetable or a budget. TARAS: One thing, if it's a red flag, if you think this is easy, if you think your decisions can be made in this isolation without talking to somebody else and actually kind of flashing it out, then you're probably doing something wrong because a lot of these things are not trivial. There's a lot of thought, there's a lot of considerations used to go into decisions that you make, especially when you're creating something that is going to be used by more than a few people. I think that's really one of those things where it's hard to know what you don't know but if you think you know and you haven't done this before, you haven't done this a few times before, you're probably missing some pieces. BRANDON: Yeah, I agree with that. CHRIS: I think one of the things that's really enticing about React and Taras, you just hit on it but I've never felt as clever as when I was writing a React app. If I'm clever, I mean, clever in the same way that I felt really clever when I wrote some unbelievably convoluted Scala one-liner that six months later, neither me nor anyone else could decipher what it meant but at that time, I felt like a god of programming. That's how it felt like, "Well, a lot of the React stuff is addicting." It felt so much fun. It was so much fun until I really had to do something and it mattered for my job and there was a deadline and people were depending on me and I've realized that the clever thing I had done a month later was not the right clever thing but I can see how, if you're like what Taras was saying, where you are at the point where these decisions are easy. These decisions make sense. We're going to be fine and you haven't done it enough to kind of like know where all of the pitfalls are. That cleverness that you feel is fantastic and I can see why it takes two years before you look back and if the cleverness was finally worn off and then, you're just mortified at what you've done. CHARLES: Pride cometh before the fall. CHRIS: Yeah. BRANDON: It's like being a dungeon master in Dungeons and Dragons, where you're like, "Oh, look at this fiendish world." All right, cool. Now, you actually live there though. I have to move into an apartment on Mordor. TARAS: You know what's the funny flipside to that is that coming from Ember world where it's so normal to leverage the work of other clever people, like really smart people who've invested a lot of time to solve a particular problem, is that there's no stronger sense of being dumb than having to write it from scratch in React. That first feeling of like, "I've actually never had to implement this from scratch," and I feel like a bunch of applications before but because I've leaned on for accessibility, I've leaned on something that someone else has done and it worked really well for me and it was perfect. But now, I need to implement autocomplete from scratch in React and I have no support. I'm basically learning as I'm going on this and it's that sense of discomfort that you get from having to do it from scratch and then, comes the euphoria of having to figure it out. But if you figured it out, you figured it out in the last month. You've written it for the first time in the last month and you now understand what all the things that the Ember implementation does for you. It's an interesting psychology of doing this -- CHARLES: Yeah, it gives you a lot of perspective but you have to ask as a business owner, who may or may not be technical and this is the hardest thing for technical people who are business owners is to be able to not see things through a tactical lens. Is what you really want to pay for is to basically give your programmers this kind of a-ha moment of their own shortcomings because that what you want to be buying. BRANDON: Yeah, you want to maximize leverage. Your goal with technology is to maximize leverage. It's like being hired as a chef and you walk in and then you're like, "I'm a terrific chef. I worked in these fancy kitchens in New York and I'm known as a great chef," and they're like, "Okay, cool. Here's some flint and steel and a spear." CHARLES: Go hunt. BRANDON: You're like, "Wait, what?" Yeah, yeah, yeah. Show me what you can do. TARAS: We had a conversation in one of the previous podcast with Michael Jackson and we asked him, "What is the one thing you wish like React community would do more of?" and he's like, "I really wish React community have more conventions." All of this is to kind of say as like, there is a place for frameworks in React world. There's a very strong place for it. The question is how and what it said and how do you actually build it and when do you --? BRANDON: So we need a framework for making framework. TARAS: Getting really meta here. BRANDON: I totally agree with that and that's a great observation and that was actually the point of my talk as well, which is if I could convince people just to use Ember and improve Ember, that would be great because I think it's a really great starting point. But the React community is much larger because it had such a great adoption story. The adoption of Ember was very difficult and the adoption of React was very easy and it expanded to include the scope of full end to end applications in terms of what people thought the problem spaces they were thinking of with React. Ember was built to solve that but it was hard to get into. React was really easy to get into but it's actually hard to build applications with. I would love to see a dedicated subset of the React community, except the idea of shared solutions and the philosophies that made Ember into sort of a powerhouse of value delivery but built out of tools that satisfy the React community and a little more modular and a little more available for people to customize and built in that ecosystem. I'd really love to see that that included all of the main components of what we accept as, "This is an application framework. It handles testing. It handles accessibility. It handles data loading," and it doesn't have to be best in class in every scenario but it does have to be a reasonable bridge across that chasm and have a group of people look at this the same way. I would love to see a collective subset of the React community dedicate themselves to this idea. I don't know if that's too culturally opposed or even orthogonal to what the value system inside the React community. I haven't been able to fish that out but I would really love to see that emerge. this is something I would love to push for and I'd love to see other people jump in and push for as like, "What if 20 of us got together and decided we're all building our applications in similar ways, instead of one person saying, 'I'm going to use --'" Even create React app is kind of a Band-Aid on that, it isn't useful past a certain stage of life. I would love to see a group of people, though, get together that are sort of like-minded like that, the Michael Jacksons and maybe even Dan Abramov or a group of people that shared that set of values or came into React from the Ember community. That's actually one piece of advice I would give to people. You said, "How do you convince this engineer that they've built a bad framework?" Use a decent one. That's the biggest guide. Use a decent one. Build something in Ember and ship it to production and go, "Oh, I get it." If you've used a good framework, you can't go back to rolling a crappy one. Your standards have been ratcheted up. CHRIS: I wholeheartedly agree that you should try something else and Ember is a great option but I don't want to dismiss just like, "React is cool as hell," and there's a lot of stuff in React that's really, really awesome and things that I wish that will show up in Ember and they are starting to show up in Ember but they're taking a while and it'll be nice in there but who knows when that will be but I would encourage even more so is both sides, like Ember folks who are listening to this podcast, if you have never messed around with React because you feel some kind of tribal affiliation that you can't betray, please set that aside and go do something in React because you will learn a lot about why Ember does what it does and you will see a lot of really interesting things that will probably jostle some ideas loose in your brain. The same thing goes for React developers. You, 100% should spend a weekend building something in Ember and nothing about that means that you have to switch or it's going to change the path that you're going on at work but I guarantee you, you will go back to your React application with some new and fair useful perspective that you didn't have before and that's okay. That's great. There's no identity crisis that will come about as a result of that. CHARLES: That is a fantastic advice, Chris. It will only stretch you. CHRIS: Yeah. BRANDON: I think developers have been sold this idea of a competitive landscape by authors of these frameworks because it helps sell the framework. You can build and strengthen a community by leaning into the tribalism that can surround the usage of a tool. The older I've gotten as a person who was deeply tribalistic about Ruby on Rails when I got into it and Ember when I got into it, because I love tribes, I think tribes are awesome and it's a way to make friends but when you really lean into that, the costs are too high and experimenting with other technologies and noticing flaws in your own technology is not only not a betrayal, it's actually critical to your growth as a developer. The more people that do that, like Chris was saying, the better both of those ecosystems will get. CHARLES: Absolutely because having spent as much time in React as I have, I really appreciate the precious things about Ember. It will make you appreciate the things that you hold dear. It will make you appreciate the really, really, really special things about the tool that you're using and at the same time, it will highlight the weaknesses which you can immediately use to feedback and make your tool better. It really is a win-win situation. TARAS: I just want to do a little plug before we close up. I think the feels of working with Ember is actually gone into microstates and we're still getting our things together to make microstates look accessible and usable by everyone but that feeling of pleasure that you get from working with Ember and just things just being there for you, like we really want to reproduce that and make that available in React community and the stuff that we do in microstates is actually really designed for that. CHRIS: Yeah, I see that in BigTest too as well. That's definitely another place where it's like, "These people definitely used to spend time in Ember and they're now in React-land." It's cool to see that stuff getting ported over. CHARLES: Absolutely because it fundamentally changes your taste. Working with an application that doesn't have like a bolted on testing framework is like eating water soup. You just can't enjoy your life. It really is flavored everything that we do. On that note, we can go ahead and wrap up. There actually is some pretty exciting news. We're actually going to be launching a BigTest launcher. Up until this point, you kind of had to roll your own using BigTest for your assertions but using something like Karma to actually launch the browsers and we're actually launching our own launcher. I guess we've written our own launcher and we're going to be pushing it to NDM, not to overload the word launch. You can look for that in the next couple of weeks. There's going to be a CLI that ships with BigTest to help you do even more set up, to make it so that you can just drop BigTest right into your application, whether it's jQuery, React, Ember, you name it. That should be really, really fun. Be looking for that and with that, if anybody has any other remarks... BRANDON: If people are coming through RubyConf this year, I'll be there talking about management stuff. That's my only near-future conference stuff coming up. Hope to see some of the more Ruby-flavored folks out there. CHARLES: All right-y. Definitely, go to every single talk that Brandon ever gives. You won't regret it. I can base that on very dear personal experience. You won't be disappointed. You know, not to put the pressure on or anything like that but you could never put any more pressure on Brandon than he puts on himself. With that, we will say good bye. Bye Chris, bye Brandon. Thank you so much. This is a great conversation. It certainly clarified a lot in my mind -- TARAS: Yes, same here. CHARLES: -- About these problems. With that, we will say goodbye. Thank you for listening The Frontside Podcast. Please get in touch with us at @TheFrontside on Twitter or contact at Frontside.io on email. We do a range of custom services from full stack project development to JavaScript mentoring, to as you go JavaScript help desks kind of stuff. If you need to reach out to an expert, please get in touch. Our podcast as always is produced by the inimitable, Mandy Moore. Thank you very much and we'll see you all next time.

In this episode, Kristian Freeman tells us about ByteConf React: why he decided to start the conference, unique challenges of putting an online conference together, what he expects in terms of viewership and his hope for sponsors, and supporting speakers who haven't recorded videos or maybe haven't ever even given a talk before. ByteConf will take place on Friday, August 31, 2018! Grab your ticket! References: Twitter Facebook Twitch This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. TRANSCRIPT: ROBERT: Hello, everyone. Welcome to Episode #108 of The Frontside Podcast. I'm Robert De Luca, the president here at Frontside and I'll be your episode host. Today, we're going to be discussing ByteConf, which is an online stream conference with Kristian Freeman. Kristian is a developer at Product Hunt. With me today as co-host is Wil Wilsman who is a software developer here at The Frontside. Before we jump into the discussion, I would like to make a little announcement. I'm going to be speaking at ByteConf and JSConf for BigTest. If you're interested in hearing about the next generation of UI testing for single page apps, you don't want to check that one out, I think. Without further ado, let's just jump into it. Hey Kristian, how are you doing? KRISTIAN: Hey. Thank you for having me. It's a pleasure to be here. ROBERT: You recently just moved to Austin and you moved from LA. How's that thing going? KRISTIAN: It's actually going really good. We packed all our stuff up and drove all the way across the US. I guess that's not really across the whole US but it was a good move. I've been here for about two weeks or so and I'm really happy with it so far. I have a full office and recording space now, so it's glorious. I can actually sprawl out and have mikes and all kinds of other gear out. I'm very excited. WIL: Nice. Now, what is it you do at Product Hunt? KRISTIAN: I'm a software developer there, kind of full stack engineer. Product Hunt is architected basically as a Rails app in the backend and then, a React app in the frontend, so I'm doing React obviously and GraphQL stuff and then Rails on the backend. It's been really cool. It's a really neat product and there's a really cool community there as well, so I'm been very happy with the transition. I've been there since the beginning of the year, so February or so. ROBERT: That's awesome. Are those projects split so it's like the React app separate from the Rails apps or is it like a monolith? KRISTIAN: It's a good question. I am not sure if it's planned to be split up eventually but as it stands right now, it's actually all one big application. We just have kind of that classic frontend folder where everything is dropped in and that's React related. We have some interesting stuff around server side rendering and things like that. All of that stuff was kind of there before I started working at Product Hunt but it's been really interesting coming from my previous gig where it was just very straightforward Ruby on Rails and then React like it's a totally separate thing, like they weren't really related at all as working on a couple of different projects. Coming to this, it has been really interesting. It kind of gives me a better sense of what Rails projects might look like in 2018, if that makes sense. ROBERT: Right, yeah. Are you using like the webpacker gem? KRISTIAN: I don't. I mean, it's not old really, in terms of web projects overall than in terms of like a Rails app. It's still running on an older version. I think we're pretty homegrown set up. We're not using webpacker. We kind of set things up and run them as like two different processes and stuff like that. It's been really interesting. There is a bit of onboarding stuff that it took me a while because I came from doing, like I said, kind of standard Rail stuff and I would say that they are really kind of pushing what you can do with half Rails, half React set up. There's a bit of time of me kind of flailing around and figuring out what was going on but it's been really cool. I definitely feel like I leveled up in my understanding of how all that stuff can fit together over the last couple of months or so. ROBERT: That's awesome. You're running a conference, right? You're running an online-only conference for free and streamed on Twitch. That's pretty bold thing, right? That's a new concept. How do that come together? I guess before we even discuss that, what is ByteConf? KRISTIAN: I'll start with the synopsis of what it is and I can talk a little bit about history. It's actually a conference series. I have other events planned and the first of those is ByteConf React, which Robert is speaking at. It's a React in JavaScript conference that is streamed on twitch. If listeners aren't familiar with Twitch, it's a live streaming platform. Kind of the primary use for it is for gaming. There's a lot of people who will stream themselves playing like Fortnight or whatever other things. I usually just watch Fortnight. It is primarily for gaming and in the last couple of years, they've started doing this separate section called the creative section, where there is non-gaming stuff. I've watched people paint. I've watched people play guitar or take song requests on the stream and all kinds of interesting stuff. What I can say is the idea for the conference wasn't a thing that I just came up with on the spot. I actually attended a really small conference that was streamed on Twitch. It was a game development conference. I wish I could remember what it was called but it was really interesting. There wasn't too many people in the stream but I was impressed with the way that it was put together, especially for a topic like game development, which is I would say, I kind of took a stab at it last year and I found it to be pretty difficult to get into and fairly opaque in terms of understanding how to get started and then make that progression into a career. I watched it and I enjoyed the format of the conference but I didn't really get learned too much from it because it was just too kind of complicated, I think unless you already were in the field. I started thinking about that and I thought it was a really interesting model and I felt like web development in particular, would be a really neat way to approach that format because web development has, I think a reputation if you want to get into programming. I don't know if I would say, entirely approachable. There's still a learning curve and there is a lot of work that you have to put into it too to get like junior dev role somewhere but I thought it was really interesting. I thought it would be interesting to take that format and apply it. My background, besides doing straightforward full stack engineering, I've done some courses for Pluralsight. I've done some in-person technical training, so I had a background in teaching and I felt like it would be an interesting just to try it and see what would happen. So far, we're a couple of weeks out from the conference and honestly it's been pretty wild how many people are excited about the conference. I don't think I've ever done a project on my own, like a side project that has had people that just tweeting about it without me prompting it or anything like that. I saw something on YouTube today like a Spanish YouTuber who does tech news and he was talking about the conference. I don't know Spanish. I was curious and wanted to see what he's talking about but I couldn't really understand what he's saying but I saw the logo and I was like, "What? This is crazy." I'm really excited about it and I'm sure we'll kind of get into this but there's some really interesting implications and ways that this format, I think it will be a different approach to the usual tech conference format. I'm really excited about it and I think it's going to be really neat. ROBERT: It's awesome that it's free and available for anybody at any time. KRISTIAN: Right and a part of that, I think when I started thinking about it like, "Can I make it free? What are the implications of that?" I think that the main thing is that when it comes to running a conference, getting the location or whatever, I would say is probably by far, the most expensive component of that. For me, I'm a remote developer and there's a lot of people that I talk to day-to-day. I think a lot of kind of my audience and people that I know online are also working remotely, so for the conference to just be online, it wasn't too crazy of an idea for me because most of the interactions I've done in development stuff like that have been through the context of remote work. But also, for people who aren't remote workers, who are getting into the field or even just have a small interest in web development, I think it removes some barriers of being able to access this kind of stuff. You know, if we can look back at the future and say, "This sounds very ambitious," but kind of a democratizing force of anyone can view this content and get access to it regardless of their skill level or economic level or things like that. WIL: I frequent trips sometimes and I know this is obviously, a free conference but are you expecting any donations? KRISTIAN: That's a good question. That's kind of one of those things I haven't really figured out the best way to do yet. In Twitch, I think there's the concept like 'Bits.' Is that what they're called? They're like microdonations. I genuinely don't know how that's going to work out. I know the plan is to take the talks after the fact and get any kind of additional slides and stuff like that. We're doing a couple of pre-conference events that I can talk about. I guess I should plug those as well before we wrap up but the way that that's going to work, I am not quite sure because I would like to sell the packages after the fact and actually, being able to pay the speakers. But in terms of little of bits and stuff like that, I'm not actually sure. I'm genuinely curious how that's going to work out. I don't know if people will do that. I guess it just kind of depends on the audience. ROBERT: -- In my talk now. KRISTIAN: Yeah, give me Bits please. ROBERT: "I intended to write, don't move to the next slide." KRISTIAN: Yeah. I use Twitch every once in a while. I said, I generally just watch like one game on Twitch but I don't watch Twitch all day, every day. I think it'll be interesting to see because this is probably a different audience than, say the average Twitch user. It'll be really interesting to see how that shakes out. I don't really have a great answer for you there. WIL: Do you have any guests like a number of people that are going to be attending? I see on the ByteConf site, there are 1500 subscribers. KRISTIAN: That's a good question. I guess I can talk about this stuff that we have planned before the conference. We've been building an audience for really, it hasn't been that long. It's been like four or five months since I announced it. We're using kind of dogfooding a thing that I've worked on a Project Hunt, which is this Ship product, which is for collecting emails and sending out newsletters and stuff like that. ROBERT: I saw that get announced not too long ago. KRISTIAN: Yeah, it's really cool. I'm really happy with the product and they have some built-in promotional tools on the site, which is pretty neat. But we have, I think like 1500 people on the mailing list. I think, we have, the last I checked, about like 4200 followers on Twitter. It's hard to convert that like how many people are actually going to attend. What we are doing and this is like A, because I think it be interesting and B, to kind of gauge this, hopefully as best we can. We're going to be doing some preconference like 'Ask me anything' interviews with some of the speakers and I'm hoping I can get a better sense of how many people will actually start attending any of the events that happen. The way the Twitch works is you can follow and subscribe. You'll get a notification when a channel goes live. The first time that we go live will be tomorrow, actually and so, we'll see how many people will turn out and it should be interesting. But in terms of actual numbers, I genuinely am not sure. I would hope that a lot of people who are on the mailing list will be there but it's been pretty neat. I've already been hearing of people who are trying to setup like in-person events, viewing parties and stuff like that. I've tried to help coordinate that as best I can without taking over the limited amount of time I have before the conference actually happens. Also, people in Europe and vastly in different time zones are actually kind of grilling me about, "When can I watch this? Will you do every broadcast so I can actually attend this because I don't want to see the conference at two in the morning," and I'm like, "Yeah, I know. I understand that." We're kind of figuring out those details as well. Like I said, I very much consider this like the MVP of a longer term event series so I'm excited. I think it will end up building something that a lot of people will attend multiple times and hopefully, we can expose people to new stuff as that happens. ROBERT: You mentioned that somebody in Europe like wanting to know like, "When I can watch this?" which actually makes me wonder like that's one of the unique challenges that you have for an online-only conference because no one's going to be asking that question if the conference is in... I don't know, LA, right? Everybody knows where it's going to be because it's all co-located, so what are some other unique challenges that come with running an online conference? KRISTIAN: That's a great question. We don't have the explicit location and time that it starts to kind of point people to. In some ways, it's a positive thing. We have a lot of people who can attend that normally wouldn't be able to. They're excluded by price, location and stuff like that but there are some things that you, I think kind of give up when you do the online format instead. One of those is just being there at the conference and running into people that may be you know or having sponsors with booths set up, where you can make a connection in that way. Some of that, we're trying to solve by building an active community. We have a Discord server that we started a couple of weeks ago, where people are chatting about this kind of stuff. I really think of it as like there's probably many ways to solve this problem and I'm trying a couple of different ways to see what sticks. Building a community where people can continue to talk before the conference, obviously they already are doing that and then continue after the fact and build the kind of connections and relationships and community that would maybe happen organically or at least, have a chance to happen organically in an actual physical conference. Some of the stuff, I genuinely still trying to figure it out like how best to give people the sense that they are welcomed and I guess, kind of feel like they're part of a community of developers. I remember when I started the conference, one of the first things I thought about was when I first went to a conference in San Francisco that Heroku put on and I remember being there, I was very, very junior as a developer and I remember sitting there being like, "Whoa. This is probably the first time I've ever been in a room with a bunch of other hundreds and hundreds of developers," and it was real interesting. It's one of the first times that I was like, "I actually am for real, doing this. This is pretty cool." I'm trying to figure and imagine and we'll iterate on this in the future like how best to give people that experience. Maybe that means doing a couple of physical ByteConf events. I'm thinking about that definitely but also, how do we keep the original idea of the format but also, how people feel like they're part of a community. It's very much a work in progress. WIL: I could see a future where you have a physical, smaller conference but you still stream it on Twitch and everybody could still attend. KRISTIAN: Exactly, yeah. I think that's probably the format. ROBERT: That'd be rad. KRISTIAN: One of the things that I thought would be interesting would be to do some kind of and actually, I think about this before when I moved out to Austin, like doing some kind of West Coast tour where we go up the West Coast and do events, maybe every a couple of nights in a really small format. The same kind of conferencing they have people from that area, come and give a talk but still stream that on Twitch. It's kind of a hybrid approach that the people who are already part of the community can still attend but for people who want that physical experience, they can do that as well. ROBERT: That's awesome and if you did that, then you wouldn't necessarily lose the whole way track. One of the things that I really love about attending conference is like the talks are great but I usually always find those online afterwards. But what I can't find online afterwards is the communication and the talk that I have with people that are there. That's an interesting challenge to have, maybe you could have... I don't know, like not to tell you how or what to do, maybe like a channel in the Discord for a Hallway Track channel or something that encourages conversation, maybe outside of but in connection with the talk. But I would just say, maybe that's just one of the tradeoffs that you're willing to have for an online-only conference. There are a plethora of things that you just shed by not having it out at a physical location, like a bunch of cost for one and AV setup and worrying about people connecting and getting and presenting properly -- KRISTIAN: Via conference Wi-Fi. If they have problems, that will be their house Wi-Fi. ROBERT: Yeah, exactly. KRISTIAN: I totally agree. I think it's not the worst problem to have because we're in a lot of ways kind of simplifying and really, it's the kind of thing that we can iterate on over time. When I was talking about the European time zone thing, I may be sounded like I was bothered by people reaching out or whatever. It's actually quite the opposite. It's really exciting and I have actively kind of sought feedback out and been like, "How can I do this better? How can I communicate this decision or that decision?" or even help me make this decision so that it's best that I do whatever works best for the community and I expect that will, as the community grows, just be more and more a factor. I think that's the kind of thing that tying up like the Hallway Track or something like that. I'm confident that people will have opinions on that and they'll say like, "This is what would work for me best to feel like I'm part of this community," and we're going to definitely try those things and iterate on them. It's not the worst problem to have because there is really nowhere to go but up, in terms of how we do it well and stuff like that. ROBERT: Good problems to have. KRISTIAN: Yeah, exactly. ROBERT: All the talks are prerecorded, right? What have you done or have you done anything to help support people who haven't recorded a video for speakers? What are you doing to kind of ease speakers into this new style? KRISTIAN: Yeah, it's interesting because in terms of a speaking lineup, there is clearly, some people who have experience both as conference speakers, also in particular in this format. It's basically recording like a Screencast. It's more or less the same thing. It's slightly a different format, maybe condensed to a shorter, like an hour talk. There are some people: Kentcdodds, Tracy Lee, they're two of our keynote speakers, I guess you could say. They have a ton of experience. They're pretty much giving talks regularly all the time, so for them, this is this is no biggie. But there are a couple of people I've tried to, like in terms of once we got our CFP, our call-for-paper, we were accepting talks submissions and also getting information about the speakers themselves like, "What is your experience of speaking at conferences? Do you have any experience speaking at conferences?" What I thought would be in the spirit of the conference itself and kind of our ideals and even, I would say like the ethics of how we think about this kind of stuff, I do actually think about it in that term. We want to have speakers that represent that. You know, bringing anyone from any experience level, in any location and stuff like that and having them be able to attend the conference and also speak at the conference. There's a couple people that just don't have a ton of experience speaking at conferences or even keep doing this kind of Screencast format and so, for those people like kind of the silly one, I've just been reaching out to them like, "If you need any help on the stuff, let me know. I've done this a couple of times, at least the Screencast part of it, I have a ton of experience with them, so if you need help, let me know of that." Also, if someone needed it, we bought them a mike and a webcam and we sent it to them and be like, "Don't need to worry about that because that's potentially --" ROBERT: Woah, that's awesome. KRISTIAN: Yeah. That can be like an economic kind of thing to make people feel uncomfortable, like maybe, you can't afford a mike or something like that but we will cover you and no strings attached. That kind of stuff, I think is really important. I think, the kind of the main thing is we just want people to feel comfortable. There is no reason that because someone hasn't given a talk at a conference before, there's no reason they can't start. Everyone has something interesting to say, I think and everyone's experiences is really interesting and brings a perspective. Especially in the conference format, I think it will bring a perspective that you're not used to seeing at a conference. Not to say that the kind of perspective of people who are super experienced and things like that. As a developer, as a conference speaker, that's obviously really useful but it's also useful to see things from the perspective of someone who is just getting into the industry. I think that being able to amplify those voices is really interesting and exciting to me. I'm sure there's probably ways that we could do this better in the future but for now, it's been just kind of like supporting them whenever they need it and trying to be encouraging and then any kind of small things like buying a make or something, we can provide that. ROBERT: That's awesome. There are some tradeoffs you could make always with anything but it's almost, I want to say better, to give your first conference talk or one of your first conference talk in this way. I know I was really excited about it when I first heard about it because I get pretty nervous getting up in front of people. At JSConf, I don't know how many people. It kind of gives me anxiety but with ByteConf, it's pre-recorded so I have the ability to go back and polish everything that I want and I can remove those odds and things like, "Oh, wait. That didn't quite slow right. Let me fix that real quick," or, "I didn't really like what I said there. I can go back and fix it." It does come with the added complexity of like, "Now, I have to go and cut it together and make sure that there's this whole post-production aspect of it," but it makes me feel a lot better because I feel that I can deliver something that I feel really good about and I know because I've watched it six times and gone over it with a fine-tooth comb, you know? KRISTIAN: Right. One of the things that I am hoping that we can do in the future is in terms of the editing and stuff like that. If someone feels comfortable like really fine-tuning their talk and stuff like that and giving almost a finished product to us, we're happy to obviously accept that but for people who just don't have that ability or needs some help in refining, I don't want to say the quality of their talk but just kind of the delivery of it, we can definitely help with that. In terms of refining, say you're going to give the talk again in your case, I think it's really interesting also. We're trying to coordinate as with as many of the speakers as we can, kind of like time zone permitting and things like that, having them in the 'attending the conference,' or 'viewing the conference,' and also being available in the Twitch chat and not necessarily having an interview there but maybe, if something comes up or someone is like, "I don't get what this slide means," or something like that and that's both an opportunity for, we're not going to like pause the talk or anything but the speaker can be there to clarify and add that additional, I guess dimension of understanding of what's going on in the talk. I think it's actually really interesting. I'm really curious to see how it turned out. WIL: Yeah, I'm curious too because I [inaudible] with Twitch sometimes and most videos, like you mentioned before, you want like some small conference and it was a very small chat and a lot of Twitch, for me is interacting with the person that I'm watching, through the chat. It's interesting to me that it'll be pre-recorded but the speakers are still going to be interacting through the chat, so it's going to be real cool to see. KRISTIAN: Yeah, I'm trying to -- ROBERT: I'm pretty excited about that. KRISTIAN: Yeah and I hope that you would be interested in being mixed. I'm sure people will have questions about that kind of stuff. I've already talked to a couple of speakers and I'm trying to reach out individually and see how many people can be there for that because it's really interesting. In your case, if there's enough people to say like, "This part kind of confused me," or, "You lost me here," that's an opportunity for you to refine the talk and get really explicit timed feedback. I think if someone came to you after, say your JSConf talk and was like, "You know, there's this part that I don't really understand," like you don't have the immediate understanding of literally, at what point in the talk are they exactly talking about. I think that will be really interesting. That's -- ROBERT: That's absolutely could be bigger. KRISTIAN: Yeah and I'm trying to figure out the best way to do this. If you've ever been in Twitch chat before, it can get a little rowdy and I'm trying to figure out the best way to manage that because I have literally zero tolerance for whatever kind of the most toxic of Twitch chat as I have zero tolerance for that in the conference. I'm trying to figure out the best way to make that happen. But if you're a speaker and especially, it's your first time ever giving a talk or something, if you get that kind of feedback, hopefully it's delivered in a way that doesn't suck and we're going to try and mediate that as best as we can. That's a great opportunity for really effective improvement on your presentation style and stuff like that, so I'm really excited about that. ROBERT: It's actually interesting to think about is what kind of trolls you might run into and -- KRISTIAN: And you have people who are like, "Vue is better..." ROBERT: Yeah or any kind of cross-trolling that might happen. That'd be interesting to see how that plays out and how you might enforce that code of conduct. KRISTIAN: We definitely do have a code of conduct in Discord and so far, I'm happy that we haven't had to enforce that in any way or there hasn't been anyone that has brought the quality of the chat down. I've seen people answering questions about different open source projects and stuff like that. I think, Robert you wrote up a solution to someone's problem in the TypeScript channel or something. Did I see that? ROBERT: Yeah. KRISTIAN: Yeah, stuff like that is really cool. ROBERT: Someone who was asking how to do radio buttons in React and I was like, "I'll just write a quick code chain box example that kind of showing this." KRISTIAN: Yeah and if I could pick one long term goal of where I want to see the conference in the community in a year or two, I want to be able to scale that up to, say like 10x or 100x the amount of people but still keep that quality of conversation. I think that is really looking at producing a conference. That part, honestly isn't the most complicated part. It's if you can use Adobe Premiere, you can pretty much make a pre-recorded conference work. It's keeping that quality and making people feel like they are a community, especially for people who know that they want to be a web developer, maybe they have no idea where to go or how to start. If people can join the ByteConf community and feel like this is a good place, that you can call this place home, I guess online and learn in that way. That's kind of the larger goal. The conference is just one aspect of getting there. WIL: This is all very exciting. I'm looking forward to attending. KRISTIAN: Yeah. I am really looking forward to it as well. It's pretty wild that it's August, that it's actually happening soon. I'm really excited. It's going to be sweet. ROBERT: Yeah and I'm seriously working on my talk right now, to try and get it together. The cool thing that I found about that, I'm talking about BigTest and Wil is a person that's writing BigTest and he's the mastermind behind it. It'd be great to have him in there and answering any questions alongside with me as the talk goes on. I didn't even consider it before you said it. It is really powerful because I'm going to be introducing something that might be foreign to a lot of people, this testing style and how you do it in single page apps. There will be a question and I know I won't be able to cover everything and hit all the bases and make sure that's not confusing because it is a complicated topic. I'm going to do my best but the added benefit of me being able to clarify things on the spot is kind of mind blowing there. KRISTIAN: It's huge and I'm trying to figure out the best way to archive that kind of dimension of the conference. I'm really interested to see it tomorrow. We're doing an 'Ask me anything,' but I'll plug that at the end. It's going to be an interesting to see what the kind of ratio, like signal-to-noise is in the chat and if it's good, especially at the conference itself, if people are asking really good questions and that kind of stuff and the speakers are responding, that is a really valuable thing to try and save. I'm trying to figure out how to do that as well, even save the most requested questions or maybe the most detailed answers that the speakers have and making that available in some way, I think it would be really valuable to people. WIL: Yeah, for sure. ROBERT: The other thing I just have some of thought of too, with all this being pre-recorded, you are able to schedule this out pretty well. At a normal conference, if somebody had a 45-minute slide and they finished in, say 30, the conference organizers will then have to go and figure out what they're going to do with that spare time but with all pre-recorded, you can just kind of spot it together and have a plan going forward. KRISTIAN: I think most of the talks, I've kind of ask people to keep them around 45, 50 minutes and we'll have some space between the talks for people to continue to ask questions in the chat or I can plug things like the Discord server in those spaces and sponsorship infos and stuff like that. But I'm also constantly thinking of these little formatic conference allows so many different little things to be tested. One thing we're thinking about doing is like at noon, there's going to be a break, kind of a lunch break, but ideally and I need to start thinking this out, getting some lightning talk style things from people who submitted a talk and didn't get accepted or something that and those are -- ROBERT: Would those be live? KRISTIAN: That's a good question. ROBERT: Or pre-recorded? KRISTIAN: That's a great question. I think the thing with live is that I would have to figure out how to get people to hop onto the stream. That might be possible but I'm not quite sure. I think we'll probably do pre-recorded, kind of across the board for this one but there's all of these little opportunities to do interesting things with the format. One thing that, I will take you on kind of a journey here like where my mind goes and I think about stuff like this over the last year or two. This is going to seem like such a tangent but I'll tie it up, I promise. Over the last year or two, actually longer, it's probably the last couple of years, I was really into Anthony Bourdain and all of his shows and I was really interested in, again this is going to sound really bizarre but I was interested in taking that idea and applying it to conferences. For say, the keynote speakers, I was thinking like it would be cool actually to go and meet them wherever they're working and stuff like that and introduce them in that format and maybe even sit down with them and do an interview or do some kind of live coding with them and have that available as a bonus material to the conference itself. Maybe air some of it in-between talks as part of the preface for their talk. There's all these kind of interesting things. I think that one thing that always kind of bothered me about the developer world is, I guess I always feel like it's really hard to visualize how to get started as a developer and then what is the day in the life of a developer and what do you actually do. I think I've been really interested in this idea of giving people a holistic view of how to get into this industry and to show people. At least in my opinion, there is a lot of hype and maybe, not intentional but it makes a scene a lot more difficult than it really is. That takes a lot of time but there are a lot of people who probably have been, whether that's kind of the Steve Job's worship of tech people or this other thing that no one can be like them unless you're whatever, if that makes sense. Basically, everyone in this industry is just a normal person. Maybe, there are some crazy personalities out there who are really dominating or stuff like that but for the most part, I think especially in the web developer world, everyone is, at least in my perspective, very welcoming and just like normal people and I want the aspect of the community to be letting people into that world and say like, "This is not as impenetrable as you may think," and there's a lot of different ways to -- ROBERT: Amplify the kindness and amplify the welcoming. KRISTIAN: Exactly, yeah. ROBERT: I like it. You did mention like around lunch time, there would be a break. At other conference, they usually cater lunch. Is there anything offered for that or is it like go on and find your own lunch? KRISTIAN: That's actually a really interesting question. No, there isn't anything planned but now, I wonder if I should find a company that's like... Is that DoorDash? Is that grocery delivery, is that restaurant delivery? You know what I'm talking about like -- ROBERT: Restaurant delivery. KRISTIAN: -- Or something like that. It'd be cool to have a coupon like if they're React, they might want to sponsor the conference. That would be interesting. That's a super -- WIL: -- Delivery fee. KRISTIAN: Yeah, that would be super cool. ROBERT: It might be too late for that now since we're a couple of weeks out but some of those companies do used React or in the future, for the future of ByteConf series, like if it's a SwiftConf and I know you've mentioned that before, you might be able to be like, "We're doing a Swift online conference. You guys use Swift. Do you want to sponsor?" KRISTIAN: Yeah. I think there are so many opportunities to do really cool things. That's a really cool idea. I haven't thought about that before. I'm going to write that down. That's a very cool idea. ROBERT: Could you tell I've been thinking about like a ByteConf accessibility conference? Because I have. KRISTIAN: Yeah. Let's do it. For real, that would be sweet. The format, we can tweak it in so many ways. It's like a full-day conference plan but there's definitely the opportunity to do really small form, like just an evening or something like that, where you get a couple of people together. The way that I visualize it in the future is there are these longer conferences but also, it just be really neat to do kind of continuous -- WIL: Online meetup essentially. KRISTIAN: Yeah, like broadcasting. I don't want to say like a TV channel but like this place that we're going to be airing new stuff to the people who are working on and we're going to be airing old talks from conference and stuff like that and giving people a space to constantly be learning. ROBERT: You can do like a nightly techcast. "Tonight, in JavaScript news, there are 15 new frameworks." KRISTIAN: Yeah. The thing is like with Twitch, they've done a lot of tools recently that I've become kind of aware of as I'm trying to figure out the best way to broadcast the conference. They have a lot of stuff around scheduling and stuff now that actually gives us the opportunity to basically run, maybe not nightly but weekly or monthly thing without having to explicitly setup... I don't know if either of you've ever done Twitch streaming but you have this broadcast software that you have to run on your computer and stuff like that. They're working on tools to remove that aspect of it and really just make it almost like a YouTube competitor in some ways and maybe like a more live aspect. That's stuff is really interesting to me because that totally fits in with the kind of aspect of what we want to do but there's all kinds of other opportunities too. I know there are a growing number of people who are doing live programming streams and it would be really cool to be able to share our audience -- ROBERT: Coordinate that? KRISTIAN: -- And stuff like that, so I'm trying to figure that out as well. ROBERT: Are you familiar with the Ember community at all? KRISTIAN: I was familiar with the Ember community a couple years ago. It's actually is what I learned before I learned React but I think I'm pretty out of date now. ROBERT: One of the team members here at Frontside, Taras, he started something similar like that two years ago called Global Ember Meetup and it was just an online meetup that would happen at night and people would come on and give their talks. It was actually really cool because there's a lot of engagement from all across the world, which was super neat. I would love to see that idea to continue live on. KRISTIAN: I know for our mailing list, we have a sense of where people are located and this is the nature to advertise and stuff because I think our most of our audience is still in the US, Canada, UK and stuff like that but there is growing numbers of places like Africa and South America and stuff like that, where I'm not as exposed to that community but I would to make it available to all of those people. I genuinely just haven't been exposed to those communities as much and I would both like to understand the unique problems of being a web developer in those areas and also, do my best to adapt the format of the conference and stuff to those groups. I imagine that people are really excited about it but I think after the conferences, really one of a lot of the interesting stuff happens because we can take a look back and say, what could we have done better to include all kinds of groups that are historically disenfranchised from attending this kind of stuff, if that makes sense. ROBERT: Even for me, I really want to go to conferences that are in Europe but that's a big investment. It's like breaking down those barriers. I'm pretty privileged in that regard but for somebody that isn't, even just attending a conference inside the States or somewhere that even kind of close for them, just the price of the conference ticket puts them out, so I'm really excited about this idea. Why not leverage the web and make everybody available to learn in conferences and have access to that community. KRISTIAN: Yeah. I think I actually saw that Facebook just announced. They're doing another React Conference and it was interesting speaking of ticket prices, I think a lot of you were saying it was super expensive. I don't know what the exact number was, maybe you know but I actually had some people tweet like, "This is why I'm excited for my ByteConf," and I was like, "What?" WIL: That's awesome. ROBERT: I don't know what their prices but when Facebook throws ReactConf, you have to enter into a lottery. You wouldn't even actually get a chance to buy a ticket. You have to enter a chance into winning a ticket for you to buy. KRISTIAN: Yeah and that kind of stuff, I mean that won't get too deep into my politics in general but generally, that's the kind of thing that I am extremely allergic to. Even the idea of having a lottery and stuff like that, there's a lot of people who, to make the decision and say they have the opportunity to attend the conference, like if they say they get a lottery email like you have a ticket, there are some people who will be able to swing that on the spot and say, "I want to buy a ticket and start to book my flights and stuff or whatever," but there's a lot of people who that's going to be a thing they need to plan for a really long time. They don't have the opportunity to wait on the email and say, "Yes, I can go to this to what I'm being paid." That's just a different dimension of financial and I think the ticket was like $600 or something, maybe $700. It was expensive but there are much more expensive conferences. Especially, if you don't work at a company that covers your conference costs, like I am fortunate to the both places I've been at for a longer period of time like say, two plus years, have both sponsored conferences, they allowed any of their employees to go to conferences with some budget in the thousands of dollars every year and for someone to pay that, say they want to get into web development, that's a huge financial burden if you're working minimum wage or something like that. I feel like I sounds I just came down very hard on the React Conference but it's fine. It's cool that they're going to get really cool speakers and stuff like that but I think it's something. ROBERT: It's the job position of online-only versus co-located, right? There's talk there. KRISTIAN: Yeah and we talked earlier, maybe there's a hybrid approach of doing ByteConf physically, I think the one thing I will never compromise on in terms of how we put on the conference is like if we're going to do a physical thing, it needs to still be available for people who can't attend it. I think even at this point, the first conference hasn't quite happened yet but I do strongly believe that's already in the DNA of the idea and kind of ideals of the conferences I want to allow people to always attend, whatever we're doing, regardless of their situation. WIL: That's huge. I never attended a conference until last year when the company I'm currently working for, Frontside, paid for it. Before this, I had never been to a conference. It's awesome to see, they're like free [inaudible] by now. KRISTIAN: The conference I talked about earlier, the San Francisco one, I just straight up put that on a credit card, like I could not afford it. I did it because I guess I felt like -- ROBERT: That thing -- KRISTIAN: Yeah, exactly but there are people who just straight up can't do that. By that point, I was interning at a web development place but I still was basically getting paid like minimum wage. It was like under paid but I did it because I felt like it would be an investment. I didn't actually get a job from any one of that conference or anything like that, so who can say what the actual value of that was but it was important kind of in a motivational way but I don't ever want people to go into debt to go to ByteConf. That sucks. There's no way I'll allows them to do that. ROBERT: Yeah, because it's not only the conference ticket. Depending on what conference you're going to, I've seen as low as $150 and as high as $2000, just for the conference tickets and then you have to get your hotel for a week and fly out there and food. It quickly turns into a really expensive endeavor. KRISTIAN: It is in a lot of ways. I think for people who are fortunate in tech, it's somewhat of a vacation because you get to go somewhere. Usually, the tech conferences, I think are held in pretty cool locations, unless it's some kind of indie conf that doesn't have a lot of sponsorships or something like that. I went to a conference a couple of years ago that was at Disney World and it was very much a vacation. I went to the conference and I had a lot of fun. It was an Elixir Conference. I learned a lot of stuff there but after the conference was done, I went to like... I'm trying to think what it is called. It's like Downtown Disney, basically or whatever, so I went like -- ROBERT: Oh, they renamed it to Disney Springs. KRISTIAN: Oh, really? Disney Springs, wow. That sounds very -- ROBERT: Yeah, I [inaudible] for two years. KRISTIAN: Actually that does sound right. Coming from LA, I used to go Disneyland all the time. Even if the conference is just on a hotel or whatever, usually the area around it is pretty nice but that definitely limits a lot of people, unless you're fortunate enough to be making a tech salary or have a company that will cover that conference budget for you. ROBERT: We're sending two people to JSConf Hawaii. We were able to snag the early bird tickets which are so much cheaper. Then I was shocked that the hotel cost on Waikiki Beach was cheaper than my Portland hotel, so I'm actually super jealous and it was a super awesome vacation on the beach in Hawaii for less than what probably took for me to get to Portland. KRISTIAN: Is that where JSConf is? It's just in Portland? ROBERT: That's JSConf Hawaii. Portland was Chain React, so shout out to React Native Conference. The JSConf US one is in San Diego which is coming up in two weeks. Oh, my God. KRISTIAN: Nice. If you are a conference speaker and stuff, I think you get some stuff cover. I don't know. Every conference is different or whatever, so if you go in that format, if you go to conferences as a speaker, I think it's a little bit different situation but I can think of a lot of times that I looked at a conference and there's been a couple of talks that I found interesting but just the amount of money that I would spend to see one or two talks that really interested me, it wasn't worth it. ROBERT: At least ByteConf kind of shed that and absolutely drops the barrier of entry of to nothing. I mean, nothing mean you have to have an internet connection. KRISTIAN: Yeah but there's still a couple of things. This is why I'm trying to deal the rebroadcasting and making it available after the fact is there are some people who still can't take a day off and watch a full seven or eight-hour conference, so it's important to make it available after the fact too. I think I mentioned, I want to sell the conference talks with the slides and with the bonus materials and stuff after the fact. There's people that are actual, like practicing React developers who would feel fine paying like $30 for those or something and that way, we can hopefully, ideally, I hope I'm not totally speaking out of this to make totally go wrong but ideally, pay the speakers to some degree. That's another kind of aspect of it that I eventually would to do well in the future. But like you said, lowering the barrier to entry to literally as close to zero as we can get is what's really important to me. Then they feel everything else, we can work back up to something, putting on the really big conference events that a lot of other people are doing but still keep those ideals that we had from the first place. ROBERT: I love it. ByteConf sounds super awesome. I'm very excited to be selected to be a part of it. I really appreciate that. Is there anything else that you want to plug about ByteConf? KRISTIAN: Yeah. A couple of things, tomorrow depending on when this comes out, August 10th at 5 PM PST, we have our first 'Ask me anything' with Kyle Shevlin, who is a speaker at ByteConf React this year. It's just going to be Twitch.tv/ByteConf. If you're on the mailing list or you're in the Discord server or stuff like that, you probably already know about this but I will obviously tweet about it as well. A couple of other things. The 24th of August, we're actually doing and this hasn't been announced yet. This is the first time I'm talking about it. ROBERT: You heard it here first. KRISTIAN: Yay! We got an 'Ask me anything' with Kentcdodds, one of our keynote speakers. I'm very excited about that. That hasn't been announced yet but I imagine that's going to be really cool. I think people are going to be very into that. Finally of course, the conference itself. ByteConf React is August 31st. It's one day, starts at 9 AM PST. You should join the mailing list and follow us on Twitter. It's just at @ByteConf. You'll see a link to the mailing list there as well and you'll get some more information there but it starts at 9 AM. On Twitch, it's Twitch.tv/ByteConf. That's all you need to do to attend. I would love for people to follow us on Twitter and join the mailing list but if you are allergic to following the people on Twitter or getting emails, you don't have to do any of that. You can just find us that day on Twitch. We have some more things that we're probably going to announce as kind of preconference events in between now and then but those are kind of the two or I guess three, main things. Thank you for having me on. It's been really awesome. I think it's maybe the first time I've talked about the bigger picture stuff with the conference so it's been really cool to get to talk about that. I'm excited for your talk as well. I think it's going to be really neat. ROBERT: Awesome. Thank you for coming on. Like I said, I'm really excited for ByteConf. When I saw this pop up as an idea, I was all over it. I think I actually submitted the CFP before you officially announced that there was CFP. I'm like, "I'm in it. I'm going for it." KRISTIAN: One more thing, I think I didn't mention just kind of organically is that all of the CFP submissions are actually reviewed by people in the community. I'm really proud to say that the talks they have selected, including Robert's were generally, because people were just super interested in them. I think that's going to really show when we air the conference. People are going to be really excited about this stuff. It's going to be super cool. I'm beyond hyped. I'm extremely nervous, extremely hyped and it's going to be great. WIL: I'll also going to say that if you have an Amazon Prime account, you get a free Twitch subscription, so you can go ahead and subscribe to ByteConf on Twitch. KRISTIAN: Yes. That is very true. I should do a better job of plugging that. Oh, one more thing. I guess I should be a good podcast guest and also say like, if you want to follow me on Twitter, my name is Kristian Freeman, it's at @imkmf on Twitter. For the most part, I just tweet about ByteConf stuff and Product Hunt stuff and then get mad about politics sometimes but I should do a better job of plugging my stuff. Again, thank you for having me on this. This has been really, really great and I'm looking forward to seeing you both at the conference. ROBERT: Cool. Thank you Kristian. This is a great conversation. I'm really excited about it. We are the Frontside. We build software that you can stake your future on. If your team needs any help with single page app testing, accessibility especially in single page apps, I'm really, really open to helping anybody. If you or your team need help in that or leveling up, be sure to reach out. We're open to pair. We're open to start a new engagement, anything that kind of helps you and your team to move forward, we're super interested in. As always, you can reach out to us Info@Frontside.io for any feedback on the podcast and thank you Mandy for producing our podcast. Thanks everyone. Have a good day. WIL: Yup. Thanks guys. See you at ByteConf.

In the last episode, we spoke a lot about the "why?" behind microstates. This time we wanted to cover how ideas in Microstates map to different patterns used to build JavaScript applications using frameworks like React, Ember, Vue and Angular. We discussed what you need to know about Microstates if you prefer component state architecture or global store architecture like Redux, as well as how setState in React can be refactored to use Microstates. We closed off with the comments about the trade offs that component heavy frameworks make by overemphasizing the view layer at expense of other aspects of the MVC pattern. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Upcoming Conference Talks: Manhattan.js - August 8th (Taras) ReactJS Austin August 6th (Charles) Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode #107. My name is Charles Lowell and we are going to be following up with our Episode 106 with the exciting conclusion of 'Microstates, the Podcast.' With me today to wrap this subject up, at least for the near term, obviously we're going to be talking about it a lot in the days and months to come, are David and Taras, also co-developers here at Frontside. Hello guys. TARAS: Hello, hello. DAVID: Hi everyone. CHARLES: Before we get into that, we'll just make a few quick announcements. First off is here at Frontside, we are going to be having some availability at the end of August. If you or anyone on your team is looking to level up in the area of testing, especially testing single page applications, acceptance testing single page applications or if you need React or general JavaScript consulting, please get in touch. We would love to work with you and love to do some of the great things together. Second, we finally released this and this is germane to the topic at hand. We released a major version of microstates this week that's based on a new and simpler architecture. That's really exciting. It doesn't really change the content of the conversation because the API hasn't changed that much. It just means that the library, which was already very small is even smaller. I think we shaved almost 40% of the size off and it's just much simpler and it's much more harmonious with the underlying JavaScript runtime. It's even more just simple JavaScript objects. Unless there's any other news that you want to cover, we'll jump right into it. TARAS: All right. Let's do it then. Let's do microstates. CHARLES: I Love to talk about microstates. This is obviously the second podcast that we're doing on microstates, just because we ended up, I think it was two weeks ago and we'd been speaking for almost an hour and really, we're just laying out the problems that microstates solve -- the problems of state management and why you often run up against complexity when you have a single state management tool that doesn't account for a bunch of different use cases. We got into microstates a little bit but we left it as kind of a cliffhanger. We talked about transactionality and laziness and immutability, ease of composition, simplicity of API, performance, memory footprint, things like this. Those were all the problems and then we're like, "Yeah, microstates. It's awesome." We're going to talk a little bit more about actual microstates proper and what is involved like the adjustments in mindset that you need to make or don't need to make when adopting a tool like microstates. TARAS: Actually, it's been really interesting for me because I just gave a talk at Toronto JS on microstates and it was pretty cool to see. There was a panel at the end. I think the people that are representing just using component state as a way of architect implication. It was managing state and application and it's representing redux. It's really interesting to see, first of all, like how curious people were. Most of questions were directed to the discussion around microstate, simply because it is a new tool but it was also just interesting to see how curious people who really loves redux, he was like, "I really love redux but I really like that fact that you guys have types," so I was like, "Oh, that's cool." Even though you really liked your solution, you actually found something in microstates interesting but at the same time, I think he was kind of missing that what aspects of Microstates overlap with redux. I think one of the things that we can do today is talk about what microstates has and what API does microstates provides and how similar they are to what people already know. I think that's one of the things that I was thinking about this conversation is that there are some things around microstates API like how to use microstates but the architectural concepts that power a microstates, they are already part of the development process and development architectures for most people that building single page applications. I think we can do is try to map these ideas not what people really know and patterns that they use to ideas in microstates, just to show how close we actually are. I think that's a good way for us to go. CHARLES: I guess we can start with, maybe one particular mode of managing state and then, how that maps to uses with microstates. TARAS: Let's start with components state because that was kind of our starting point. One of the original starting points for microstates because so much of our work was in Ember and component state is where most of Ember development happens. I think that's a good place to start. If you're someone who uses components state, if you're using Ember or Vue without something that is redux-ish which is pretty common these days, if you use components state, then one of the features of -- CHARLES: And also, if you're using React, right? Ember, Vue and React pretty much are all the same in this regard. TARAS: Yeah. Well, Ember and Vue are a little bit different in that behalf. Their particular pattern is you have data coming into the component, then you're doing some work with the data so that in Ember and Vue, you might use computed properties to derive state on that and then you might pass that state further down into other components. In React, you would do something a little bit different because there is no memorized computed properties by default, so you, a lot of times, write your computations that you pass into other computers that are written as expressions in JSX. If you're using this pattern, then one of the challenges around using this pattern is the process of lifting state becomes quite complicated. Because if you have like a bunch of state that lives in the component, it's attached to your derivation of state and the properties that you can invoke are attached to a component object. In React world, it's called lifting state. In Ember world, it'd be essential refactoring it into the parent component and passing that state in. in microstates, you're essentially moving this state into the microstate and now, what you have is this object that instead of having the state live on the component, the state now lives on the microstate object and in all frameworks, when you do that in microstates, you can use the getters to get the memorized computed properties behavior on the microstate. If you use your computed properties, computed properties are available for you on the microstate. You can do it the same way. CHARLES: It's kind of like a wrap up of that idea, not a wrap up but a summary of that idea is that the microstate essentially is a substitute for your component properties. If you're working with a component, a component has state associated with it, so you're setting properties on a component and then using the computed properties of that component. Microstates is you have all those benefits where you can set properties directly. You can define methods that like set properties as part of a transaction and you can then have simple JavaScript getters, which are just like computed properties except there's no enumeration of dependent keys. It's just, that's all they do for you. TARAS: Then the next question that arises is like, "Do I make like one huge microstate or a bunch of smaller microstates?" I think the question is really depends on the role of your component and what's nice thing about microstate is in microstates, there's two things that are kind of cool. One is when you represent your status in microstate, it makes it very easy. If you need to lift that state from the component up into the parent, you can lift that type. You can take that type and you can compose that type into the parent's microstate, if you have to and in that case, you would pass this new object that's created from that type. You'd pass the state for that component to the component that would otherwise have its own state. Essentially now, the parent has the state that would otherwise be in a child component and now, the parent is passing a state from the parent to the child. There's two kind of benefits to that. One is it gives a parent a way to control the state of the child and it also gives you a really easy way to serialize and deserialize state. You start off with having ability to serialize state for a particular component and all of his children, now you can represent that serialized state as part of the components state, so you have an easy way to restore the state of the component tree at the parent component. CHARLES: Right and that's possible because a microstate is really just encapsulating a value within a type but the value is just a simple serializable plain old JavaScript object, right? TARAS: Yeah. CHARLES: I'm just not trying to say like this is the feature that microstate provide, so when you're creating a microstate, you just pass it a POJO and it off to the races with that POJO and you can access that POJO at any single point. TARAS: Yeah. This is part of the architecture that I think are helpful for people that are using components. Is there anything else for people who are using components state that we think would be helpful? CHARLES: I think we're just realizing that you get the benefit of the laziness and immutability and the transactionality and all kind of things that we talked about last time but actually, the mental model is very similar. I think the thing to realize is that if that's the way that you used to working with state, the bridge is not too far. It's actually quite a short one. TARAS: Yeah, that's good. CHARLES: It feels very natural. It's not a huge mental shift. It's just more about a very small mental shift, a very small shift in mechanics for a very large payoff. DAVID: For instance, say you're in an Ember application using component state, what I'm used to is you're going to be passing actions around between components. Whenever you're trading that out for microstates, is it more that these actions are just bundle in with the microstate as the transition? TARAS: Yeah. One nice thing with the microstate, because the transitions that you can perform on any data type are intrinsic to the actual data type, the part of the data type, when you instantiate a microstate, you get these transitions for free. When you pass the object into a component, you can now invoke transitions on that object, that are part of that object's type. It's hard to imagine how awesome that really is because the closest pattern that you would see for that would be like, for example, if you're using Ember, you have Ember object or Ember model that you pass into a component and then, you can work a transition and because it goes through the Ember data store, your component is going to update. With microstates, there's no observation of any kind but what you're doing is when you are invoking the transition, transitions going up to the top of the root and gives you the next microstate, which updates your component tree. You get that functionality of 'data-down, actions-up'' built into the entire system of the microstates and all of that is hooked into these transitions that you can invoke on the objects that you pass into your components. CHARLES: Right, maybe David and Taras, you all could provide a concrete example of what that looks like. Because I think it is something that when I was giving talks on microstates at Ember meetups, one of the first things I like to show is you've got all these actions that you're writing either on your router or your controller but they're really actions manipulating the same type of data. It really comes down to like you're pushing and popping things off of arrays, you're toggling Booleans, you're incrementing counters, you're setting this property on this object. These are actions that we're writing and in the kind of microstates world, that's boilerplate. Because the transitions are intrinsic to the data type of the microstate that you're working with, maybe we could provide an example, like what's an action that you describe that you would pass around. TARAS: I think an easier one would be like if you have a model for example, you're composing a model into your application state or you're compose a model into your components state, so you have this model type that gets instantiated and you pass it into component that represents a model. Off that model, you might have open status like is it open or not that gets consumed by the model component, to know whether the model should be visible. Then along with that is model is open state, there is a toggle transition that you can find inside your component that is going to automatically flip the visibility of open. What will happen when you bind that transition to some kind of action handler that you invoke inside your component, when you invoke that action, it will then trigger transition at the top of that microstates and then, it will create the next state, push it through which will cause your model to change the visibility. David, that does answer the question? DAVID: Yeah, it does and that's actually the example that I have come up with whenever asked. A very simple sort of Boolean toggle. CHARLES: In a couple of my earlier demos, I should dust off that talk that I gave to the Austin Ember meetup where I was able to create an input with a dropdown menu with basically, some pretty advanced mouse behavior, all without having any component state or like storing it all in microstates and a lot of pushback was, "Aren't you putting logic in the template?" and the answer is, "Absolutely not." The logic is in the models but what I'm doing is I'm composing the actions that operate on those models inside the templates but at the template level, the action is data. If you're thinking about, we always want to have, we always want to lift state and then push that state down to the application, what this is really saying is that the actions are part of the data. It is implicit to the value that you've got. TARAS: I think that's really powerful because we do think about actions as being something that you can invoke. Like with closures, it's an action that you can invoke but considering that operation, that piece of data that invokes a transition in microstates and is derived from the type of the data, I think it's a cool concept. That's probably, one of the things that is kind of new for microstates but how you use it in your application should feel pretty much the same as you would if you were creating action handlers on your components. CHARLES: Yeah, just like kind of bundled action handlers for free. TARAS: Right. CHARLES: Maybe the way that you wrap up on this one when talking about kind of what microstates has to offer for the Ember developer, the Vue developer is really, I would say someone who's used to working with like MobX. Would be another good example is when I first started using Ember back in 2012, Ember Object solved a whole lot of issues in a really profound fundamental way and I really, really was drawn to that as the best API to be working with state. What kind of became apparent was perhaps not the best implementation. This is not like bag on Ember Object. I think it was actually amazing technology for seven years ago when most of it was written and probably, even came from before like SproutCore. It's almost 10 years old, which is incredible but it's still under heavy use in 2018 and it speaks well of how well it was constructed. I actually don't have much of a problem with Ember Object API. I just think that the way in which it's implemented that API means that there are some problems that require a different paradigm, so very much I kind of see microstates as heavily inspired by those types of APIs but with, I want to say a modern implementation but an implementation that is designed to solve the problems that have come to light over the last five years of developing single page JavaScript application. TARAS: I want to add that, when you describe with Ember Object, it exists in every framework that uses immutability. In MobX, the observation introduces the necessity to wait for a bunch of things to resolve. In Angular zones, I saw a similar purpose to ensure that if there are kind of cascading or streams or all of that stuff gets settled in into kind of restful state before you can start to assert on what's going on and with Vue, their computed properties has something similar. I think because of the complexity of having to track lots of objects and then recomputing things based on the result, that complexity in microstates is simplified by the fact that you describe you transitions. When you write them, you describe exactly what changes, so we don't need to wait for things to settle down. When you invoke a transition, that transition is explicit and based on the path of where that transition is invoked, we know exactly what needs to change, so we need to only perform one operation to compute the next state. There is no other things that we need to wait. There's no other side effects that we need to resolve before we know what the final status. I think that simplicity can be applied to all the frameworks that are using immutable APIs and derived computations from those immutable APIs. CHARLES: Uhm-mm [affirmative]. TARAS: Should we jump into talking about what microstates has to offer for people familiar with redux? CHARLES: Yeah, okay. Let's jump right into it. For folks who are familiar with immutable APIs like Ember, like Vue, like other ecosystem using MobX, a shift to microstates might feel like what you can expect. What about people who are just using often React-land and they're just using like set state. TARAS: Set state is a little bit tricky because it does get complicated over time and then you get this kind of funky things going on after a while where you start seeing things like, "I'm going to set state on this component and then once the change happens, I'm going to change some states some other state," so this kind of cascading state changes. The other part that I find particularly more challenging in set state world than it is in, I think in regular components state, like what you have with Vue and Ember. I feel like the way that the transitions, the state change handlers become part of the component, I find that part particularly kind of fragile. When you start doing refactoring, when you need to lift up state, it's like -- CHARLES: What's an example of this? TARAS: When you start off and your component owned old state and now, you need to have that state being controlled by the parent, we get into a situation where like, "What am I going to do? Am I going to do something with props as they're coming into the component or I should probably just flip that state from the child to the parent?" and now, you're refactoring the internals of a component to lift up that state so you can then combined those operation with the parent's state transitions. But then, you have this kind of added complexity of the fact that you're working with immutable data in that place. You've got these three things going on: you're refactoring your child component, you are moving these things into the parent components, you modify a parent component and now, you're also managing the complexity of forming immutable objects. I think the fact that people make it work is kind of a testament to human resilience. The people are able to solve such challenging problems and this is not a super hard one but when a component is complex enough and when stakes are high enough, these changes can become fragile. This is what I think microstates simplifies is that by taking care of the model, it makes components much simpler and makes it possible for you to just render a lot of components that are functional components without their own state. CHARLES: It actually reminds me and like I said, we're talking about what it's like to use them, not so much the implementation but that's the exact same sentiment that the author expressed in his book that was very helpful in writing microstates, which is Brian Marick. He has this book called 'Lenses for Mere Mortals' and he's talking about the practical use cases of using lenses, which microstates leans very heavily on. What he says right in the introduction is it gives you by abstracting the location and compose it the way in which your data structures are composed, it makes them very refactorable. You can say, "I want to change where the state lives. I want to change the structure of this object and I want to move it somewhere else," and it's sounds weird to say this, because the structure of the object is not coupled to the structure of the object, it means that it's very malleable, so you can move and you can say, "You know what? I don't want this address to be embedded in this person. I want this address to be inside this address book and then my person has an address book entry." Being able to make those refactors make those changes is very easy because your method of accessing the data is abstracted. It's something that applies beyond even user interface as a component state but it's something that this is a problem that's very salient when you are authoring complex UIs and compose components. It's something that you can benefit very greatly from. DAVID: Taras, you were telling us earlier about a friend of yours who is learning React for the first time over the past few months and he's mainly been using set state as you would just starting out in this world. You said that he didn't really get why you might have to go and learn some other way to manage your state and I think Charles said it, whenever your application starts to get more complex and you've got a lot of different moving parts, that's really where microstates will come out and shine for you. TARAS: Yeah. My friend kind of feel bad because he's spent the last three months learning how to work with React and how to use set state, "And now, you're telling me, I need to learn something else? Like I'm going to start from scratch?" I kind of reassured him that especially when you're a beginner, when you're learning, you learn how to address very specific challenges but you don't know how complicated these things can get when your UI gets really intricate. In those intricate scenarios is when you have to leverage your experience and you'll be able to solve these problems but if you're learning, you encounter these challenges head on and your tool does not really, like set state. Although it can be used to build really complex UIs very effectively but the complexity that over time increases as you start to manage the state, increases much more later on than does early in the beginning. Basically, with microstates, even if you have some basic proficiency with set state, when you start working with microstate, the things that you can do with microstates, you will be able to do more sophisticated things easier when you need to use them than you might realize when you start. Because microstates API is so consistent, there are a very few concepts to actually learn and they cover a broader range of use cases so when you actually starts using it, you'll encounter these challenges. What you already know it will just work for you and always just continue to work for you. That was part of kind of fundamental design on what Charles and I have spent, a lot of time putting into place from a point when we started two years ago. CHARLES: I think, and you touched on this and this is kind of what I was speaking to earlier is that when you're working with a simple system, it's simple, it's easy to work with and then the complexity starts to grow, it's never a good thing when you have to reach for a more complex tool to manage the complexity. It's a hallmark of a good system and that it can scale with you from a very simple and easy use cases to actually being able to handle very large and complex use cases but your API doesn't have to change and your usage doesn't have to change. If you have a tool that can actually scale with you from a one liner to a hundred thousand liner, that reflects very well on the design of the tool. I think you see that with things like Ruby, you see it with things like Clojure. You see it with, I would say there's even people writing like Haskell, shell scripts now but not so much with like C++. I think the analogy is very similar with microstates in the sense that when I'm looking for evaluating a language, it's not the only thing I look for but I really am looking like how is this going to work for me as a one liner? How's it going to work for me as a hundred thousand liner? If the answer is pretty consistently, then that's something that is going to get a lot of bang for your buck, so to speak. If I invest the time in learning it, I'm actually able to reap the reward of having a tool that's got my back on a whole bunch of different use cases. We talked about, in React, if I'm using set state and that's kind of a sub case of component state because I would say that in the previous systems we talked about -- Ember, Vue -- they have components state but the component state is a little bit more rich in the sense that you've got computed properties and what have you. But if we look at a system that externalize a state like redux, where you have a global state atom in your application, at least that's the way most of the redux applications that I've encountered behave, what does it look like for you? TARAS: I think it's a little bit challenging when talking about redux is redux conflate a few different things together. I think it's helpful to split those things up, so we can talk about them separately. One of the parts is how the state is delivered to components. The way that redux does is the instance is this created so every time you use connect, you essentially wired together. You can connect through the context or... I'm not sure. I think they have an observation mechanism that's internal to redux as well but they essentially connect components to the store and then they view that to deliver the state. It's kind of worth pointing out that for that like microstates bindings for React actually give you something similar out of the box through context. For those who really like the ergonomics of connect, I think it would be pretty easy to make that available for microstates. Usually, we don't even know why they wouldn't be available. CHARLES: But I do think that connect can be problematic like you can encourage you to not make components that are reusable and have isolated state. It's very easy to hitch yourself to the redux store and now, you don't have components that are shareable. TARAS: I think I would personally prefer to pass microstates instances through props because of the stability that's built into microstates and structural sharing, you can get some free optimizations and allow it to use functional components in more cases like out of the box but some people who are really like redux, they really like connect. Although it might be my personal preference, there's no reason why that wouldn't work if somebody wants me to connect function and make it available for people. CHARLES: Right and I think, there's a happy medium there too, right? TARAS: Yeah, I think -- CHARLES: -- You can connect components and then fan out that state to a set of functional components that are not connected. TARAS: There are some places where microstates and redux are very similar. When you're using in redux, you have this dispatch mechanism, where you essential saying, "I'm going to dispatch this action and your action creator is going to create an action for you with the payload," and then you're going to match that action to a reducer. One of the things that I kind of hear redux people really enjoy about redux is the one with data flow that dispatch the action and then, it reduces this next state and pushes that through and you have this kind of ingress point where everything is going through this one point. I think what's really interesting with microstates is you essentially get that. That's exactly how microstates works, in a way. The only difference is that the API is different. Any action that you invoke is going to go through a single entry point, which is going for you. Because we know the structure of the data, we know how to transition that state for you, so you don't need to reducers, so you're just defining your transitions or use the built-in transitions and then when you invoke them, we know the path. We're essentially forming for you. The path where you invoke the transition, conceptually, it kind of forms the name of the action that you are invoking. The path refers to a place where the state is going to be transitioned, then you have your transition, which is the actual reducer for that part but it's contextualize, so you don't have to think about how you need to transition that state in a great, global redux state. CHARLES: There's no matching. The matching is automatic. TARAS: Yeah, the matching is automatic, so you get that same single ingress and one directional dataflow. You get those mechanics except the APIs that you use, instead of writing the actions yourself. Instead of writing, we just use yourself. You get to use microstate types. I've heard some people who use redux who are like, "I really love the fact that microstates has types," but other people don't like types for whatever reason. Microstates comes with 'from,' which allows you to take a POJO and from that POJO, it creates a microstate and then you can invoke transitions the same way as if you had a type microstate. The only thing you don't get is you don't get to create your own transitions. You have to use the transitions that are provided for the primitive types. CHARLES: I think that there's a couple of benefits that you'll realize for free. There's laziness, reducers by default, or eager. When you dispatch an action, it will run against every reducer in the store. If the reducer matches, you're going to run the computation that's associated with that reducer. Microstates by contrast is lazy. Basically, until you try and read the property that is affected by that reducer, the reducer won't run. There's some ways that you can get around this. When you're using redux and first of all, you can actually have your reducers return objects that have getters on them. You can realize some of that laziness but again, it's work that you have to explicitly put in. I think, didn't you actually say that there is a package of plugins? There are plugins. There's basically a set of libraries that you could bundle together, which would give us an experience similar to using microstates. TARAS: Yeah. If you wanted to combine redux and reselect and immutable JS together, you can get some of the benefits, except this benefits are not integrated that well because they're still separate systems that you are essentially using together. Also, like microstates, it's four times smaller than redux and reselect and immutable JS combined together. If size matters to you and ergonomics matter to you, you actually can get a lot of ease out of using microstates while still maintaining the benefits of having redux. CHARLES: But if those things, those packages, like reselect and immutable JS, are things that are familiar and you naturally gravitate for it, then you'll probably absolutely love microstates. Because honestly, one of the ways that I think about microstates is like, what if you could have immutable JS, if there was no cost for composing the types like list and record. Immutable JS has come a long way since I've last used it or it's evolved since I've last used it but I think there's still only about four or five basic types and actually, making your own new immutable structure, your own custom type with its own custom methods that still get the benefits of structural sharing and laziness that you have on immutable JS is not something that you can do. But you could think one way to think about microstates is an immutable JS where you can make any type that you want. You're not just constrained to the record types and to their list types and set types or map types. TARAS: It's worth pointing out that at the moment, microstates doesn't map perfectly to immutable JS simply because immutable JS has certain optimizations for managing lists that kind of a great value of immutable JS and microstates doesn't have some of those pieces but -- CHARLES: They're definitely on the road map. TARAS: Yeah. Because microstates is abstracted high enough, that we can actually change internals and some people who are using microstates now, they will get benefits of ergonomics and there's already performance benefits from the stability that microstates offers but there will be a time when by upgrading to newer versions, you will not basically, need to change anything in your op but you will get the benefit of improvements to performance that we will introduce over time. Some of those improvements might come from what we will learn from immutable JS. CHARLES: Right. I have a couple of thoughts before we wrap up. What are the ramifications no matter who you are? What kind of development background, some of the benefits that you'll experience with microstates that might be a pain point or something you hadn't thought about where you are currently? A couple of things that I have jotted down is first, and this is what brought it to mind is talking about stability. Something that you see in a bunch of frameworks is having to manually track the keys that are associated with data. If I've got a list or I've got an object, being able to say, if that object changes, then I need to actually have some sort of key object, which effectively amounts to a hashing function to say, "Did it really change?" Because no matter what system you're in, you need to know how you're going to re-render. If the reference to this object changes, then the default thing needs to be, "I need to re-render it," right? You see this in Ember, in Vue. In React, there's this ability to pass a key or ask the question, "Should this component actually update?" and with microstates, that's much less of an issue because basically, it keeps the key tracking instability for you. If you are using a model with microstates, if you think of an object as a graph of nodes, no node in the graph will change unless it absolutely has to, at least that's the goal. We still actually have some work to do when you're running queries against the state of a microstate. We can cover that later but that's most largely the way it is now and definitely, the way it's going to be going forward is you don't have to do any extra work as a programmer to figure out what has actually changed. TARAS: That opens up some interesting opportunities. Imagine if you had a rendering engine that did not expect side effects to be significant and you could just say, "If I know whence they'd changes, I will then re-render that." That will be really interesting exercise, seeing like what would that look like for a performance perspective, if you have a very clear picture of what has actually changed and what part of the DOM as a result, need to be updated without having to do diffing. The [inaudible] you could actually do a diffing at much higher up. Actually, [inaudible] to diffing because you know what's changed but you can push a lot of assumptions higher up on the architecture stack. CHARLES: Right. That's actually one of my favorite thing about microstates and one of the unwritten values is like triple equals used to work everywhere and by and large, it does. It's usually simplifying but when you don't have to manually tell the computer what equivalence looks like, you can just say, "Look, are they the same object? They're not the same. If not, then they're not," and keeping that consistent is huge. TARAS: I think this is a good segue for us to kind of bring this conversation to a close and also, kind of set up potentially a third full-on conversation, which we could talk about actual architecture of microstates and design decisions because for people who just want to use microstates, they don't need to know all these details but for people who are curious, they might actually want to understand what are the considerations that remain when we were designing microstates, so maybe in a next conversation about microstates, it could be about architecture and the pieces in microstates today and then where we are going with microstates and what it could give us long term. CHARLES: Yeah, I like that idea. It is a plannable subject that we've been talking about internally for the past two years, so it makes sense that there would be plenty to speak about on the podcast. There is one other thing that I did want to bring up and that is, I think enabling to have a state solution that is composable because it allows you to think about your state first. Because really, if you do have a functional UI, where your view is a pure function of the model, that your view follows the model and so, if the view follows the model, then really, the thing that you should be thinking about first is the model that's going to be required to drive your view. I shouldn't drive. I should say derive your view because that's the primary artifact of which the view is nothing more than a function. It's a reflection onto a surface. I don't think that we have a state management solution yet, that enables that mode of thought, where I'm thinking about my prime artifact first and working forward rather than thinking about my secondary artifact and trying to kind of wishy-washy way, work backwards and reconstruct the primary artifact. I think that we've talked about all the development ergonomics and I think there's a mechanic of thought there that's enabled by this that I hope to see in more and more applications. TARAS: I think that's a really well put. I think that's something that I've been thinking about as well, as how do you convey this shift that microstates allows in terms of how we're thinking about architects and the application. For some people that value, the model, like they'll find that shift easier but regardless, I think that making that shift has a potential of simplifying your view dramatically and I'm very excited about exploring this further and having more conversations about this. CHARLES: Yeah, that's where we really kind of open up the conversation about state machines, which is also central to the conceit of microstates and using state machines as an incredible design tool but anyway, we can all get into that later. You heard it here folks, Episode 3 is coming out, although probably not for a while. We're going to be mixing up and we will be talking about microstates at least for a while. I understand that next time, we actually teased it but we based on how much material there was on microstates, we ended up packing in a second episode. We teased it last time, we're going to be talking next time about running an online conference with Twitch, so definitely look for that. Thank you, Taras. Thank you, David. TARAS: Thank you. DAVID: Yeah, it's been great. CHARLES: This is a wonderful conversation and as always, we are Frontside. As I mentioned at the top of the show, we have availability coming in August, so if working with us is something that you would like to do, we have a range of services, please get in touch. You can get in touch with us at @TheFrontside on Twitter or Contact@Frontside.io. That's it for now. I guess we should also mention that Taras that you are going to be giving a talk on microstates at ManhattanJS. When is that? TARAS: On August 8th. CHARLES: I will be giving a talk on microstates at ReactJS Austin on Monday, the 6th, so that is right around the corner. I'm excited about both of those talks, especially following so closely on the heels of the TorontoJS meetup talk, which I understand is... Is that posted online yet? TARAS: It's recorded but it should be coming out soon. We'll definitely tweet it out. CHARLES: Okay. All right. Look for that and we will see you next time.

In part I of The Frontside's microstates series, Charles Lowell, Taras Mankovski, and David Keathley talk about state management that's easy and fun and transactionality. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Upcoming Conference Talks: Toronto.js - July 30th (Taras) Manhattan.js - August 8th (Taras) ReactJS Austin August 6th (Charles) Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 106. My name is Charles Lowell, a developer here at Frontside and I'm going to be hosting today's episode and we're going to be talking about microstates with fellow Frontside developers, David Keathley and Taras Mankovski. Welcome you all. DAVID: Hello. TARAS: Hello, hello. CHARLES: I'm really, really excited that we finally get to talk about this but before we jump into this, just wanted to let everybody know that last week, we published our roadmap for Big Test, which is a JavaScript acceptance testing framework that we've been building right here, in-house at Frontside, which can work with both Ember applications and React applications, Vue applications. It's in alpha phase and we're looking for feedback but we're really excited about it, so we're going to leave a link to that in the show notes and please go check it out. All right. Finally, the moment has come that we actually get to talk about this publicly. We've been publishing things about microstates for a while now but we feel that it's ready to share with the world and that's really, really exciting. We should probably like wind the clock back a few years because that's about how long we've been working on this and talk about, kind of the why and the what of what microstates are. It's kind of a weird word. What are we doing here? TARAS: Yes. That's interesting question because we were working for so long and after all this time, what is this specifically we're working on. I can speak personally from my personal motivations because we have conversations over the last two years to why we were doing this and I think for me personally, it's always been that I've been mentoring building complex applications for almost five years now and one of the things that I find consistently is that there are patterns for how to build complex stateful UIs that the required solutions, that are fairly reliably consistent. I can teach people certain patterns and then they can use patterns to build complex applications and those patterns scale really well, the challenge is that, there's not an easy way to express them and it's different for every framework. The way that I would teach somebody how to do it, for example in Ember versus how they would do it in React, even though the pattern itself is the same but the implementation of the pattern is different but it's different in such a way that it's very difficult to see where the consistency is, what is the same about these two patterns. It shows me that there is room for improvement. In the same way that if there is an opportunity that in the future, components will get unified under one umbrella or what component spec. The fact that we do states differently across every implementation, across every opinion, it suggests that what we might be missing is something that would unify across frameworks, how we actually do statement management. CHARLES: Yeah, that makes sense because as much as people try to buck the trend of MVC, it can't keep coming back in the rear view. Hopefully, not like a horror villain but like a caring friend, like a reliable pattern. I remember when I was in writing Java applications back in the day, the most important thing when you were writing a swing application was making sure that you had your models right. If you were modeling either a form or a dialogue or a set of pages, the most important thing was to have those models. Back in the day, we modeled those things with event listeners, very similar to where the way like a Backbone application used to work or if you're familiar with Ember Object, the way that it worked basically, adding observers to some model so that when that model change, you were able to react to that. Your representation was able to be 100% dependent on this model. That was like a Java Swing Application, which was then inherited from this pattern from Smalltalk but we keep on seeing this again and again and again. There is this piece, this state, that if you're going to be representing something, then you need to be able to get at the meat of it. That's ultimately what the model is in the MVC pattern. I remember when React first came out, everybody was like, "Oh, MVC is dead," but now in terms of state management and all of the state management solutions that we see, what that really is, is the model trying to reassert itself. Because it's such an important piece of your application, it's going to rear its head and you cannot escape it. I make it sound like a problem. I guess, it is a problem but there's a proliferation of solutions out there that are attacking the problem in order to represent something you have to know what that something is. DAVID: I think when you only work with the one framework, your perspective might be very much shaded by your experience. If you're really good at building React applications and you have subscribed to POJO is king and you don't need anything beyond that, then you're going to get good at handling POJOs and you might not realize that there is actually limitations to what you're doing. I think the same applies to people who use Ember and they're using Ember Object and they have computer properties and now, in Angular, there is observables and subscribing to streams. What was really interesting with the work that we've been doing with microstates is that and one of things that have notice with other state management solutions is that a lot of them emerge as, "Oh, I had this insight. I spend a couple of days working on it. Here's my proposal, in a way, for managing state." I think that's great because insight and understanding is really important but sometimes, taking the time to design something can be really helpful. I think that one of the things that are really interesting with microstates is that because we've been iterating on it for so long, they've been testing it for so long, we've been able to do something in microstates that's really difficult to do when you have a production application that you're like, "I want something different. Something is not enough but I don't have the time to really make it better," or, "I have an idea. I want to release this thing but I don't have any other collaborators that I can talk to and really flush out these ideas," so what you get is a solution but it doesn't always touch on a lot of the angles that you want to touch on. It's really interesting when you think about -- CHARLES: I'd say, we should talk about those angles, like what are some of those angles? DAVID: Yes. You could think about this from a few different perspectives. I would say, from Ember perspective because that's been my personal starting point. For anyone who was listening. Ember and Vue, for all intents and purposes, in this scenario are very similar because they have the same primitive, which is the computer property. The computer property in Ember, the computer property in Vue is almost identical from the way that you actually consume. In Ember, you would use computer properties and in Vue, it's just computer properties to create derived state from data that's passed into the component and then, you would use is derived state to basically, decorate information that comes with the props, so you could present it in your component. This pattern is very nice. This pattern is being used to build LinkedIn, to build applications at Apple. There are huge implications being built by Ember community using this patterns and I'm sure something similar has happening now with Vue but this pattern doesn't really exist in React in the same way. You might opt in to start using this pattern if you start using [inaudible] but it's not quite the same. Writing computer properties in Ember and in Vue is essentially free because it's so effortless, where in React, if you're using [inaudible] to create cache computer properties and memorize computer properties, you are really opting into doing a particular way of computing this properties and writing selectors that's not trivial. I think that's one thing that is available in Vue and Ember and it's a really effective pattern and you can do it in React but it's actually not possible in Angular, unless you're using, I'm guessing something like ngrx, where you can do similar things to what you would do if with redux in React. Creating derived state that you can consume in your component is one of the things that is possible but it's not possible consistently across all frameworks. That's just one of the things. CHARLES: I agree. I think that was one of the things that drew me to Ember at first coming from Backbone as I did and honestly, from the models in Java was that, in order to compute anything, you had to install a listener and then eagerly make that computation and store it somewhere, where as those frameworks, it made you feel effortless where you can just decorate some state and derive it and the information is there, the computation is there when you need to reach for it but you don't have to do expend any extra effort aside from say, "This state is derived off this other state." I think another case that I came across was immutability. Immutability is a means but the end is to have consistency inside your application. I first really started running up against this when I was working with forms and since then, I've realized that actually, a lot of the pain that I was feeling was because things were not being immutable but this is where the fact that things weren't immutable ended up causing me a lot of pain and headaches and I was having the code into being a lot more complex. Essentially, when I wanted to make something transactional if you're editing a form or something like that, then you need to essentially store off a copy of your current state. If you're editing some object, I want to say, open up a dialogue and I'm going to edit it and then I'm going to commit the changes back to that dialogue. What I'm modeling there is a transaction so I kind of need to shave off a copy or make a Xerox copy of the object and then make the changes inside to that object and then somehow, try and merge those changes upstream and then, get them back into the main lines. Really, like a very Git-like operation. It wasn't just at the object level. When you're doing things like dirty checking, you need to make what is the original value of a field versus what does the input currently have. I might be doing any number of transformations in between the actual physical representation of the field, maybe it's a date but the user interacts with it in as a string, so there has to be this kind of parsing serialize thing sitting in between that value and you need to basically, keep a copy of that field as a mini transaction within your macro transaction because you want to say like, "Is it dirty? is it really the same object?" because if you can just do an object comparison, you have to get into all that hairy like equality checking and it gets really complex really fast but it turns out that a very clean solution to this is if you just never actually make the changes in place and whenever you are making changes, you're generating new information without destroying the old information because when a form is the case where we really come up against this, where we're modeling the same object over time, so a form explicitly models the change of an object. Change is part of what it is and so, the definition of change is being able to compare something in its prior state to be able to compare it to its current state. If you're making that change by destroying the prior state, then you're going to run into a lot of trouble. It just turns out that when you're working with forms and it turns out there are a lot of use cases like this but this was the one where I first really just couldn't even... Without immutability, you want to model your change as always rolling forward and not ever destroying prior states but being able to pick and choose and can always be able to look back to where you were and compare where you are now to where you were. That's where immutability comes when you're modeling change. It's actually much easier to model change when you have explicit states that represents what was and what is. But when you start doing that, then things get a little bit messy. You have to do the compromise. There's a tradeoff, like when I say, "Set this property on this object," that is easy and that's something that I think that we can all understand. We're not idiots. That's why immutable models are very conceptually easy to grasp, to wrap your head around. If I'm modeling myself and I'm saying, "Set hand position two feet up in the air and now I'm raising my hand." That's easy to understand and it turns out that when you're changing a data structure immutably, then you have to, for example model a simple set operation as duplicate and swap. Or if say like you're swapping out one property in an array, you actually model that as a map, where you swap out the one element at that index, rather than just saying, "Just set the thing at that index," or if I'm changing a property of an object, I want to copy over all the fields except for that one which I'm going to change. If you start to do that then, you realize the benefit of always being able to look backwards but you've now introduced overhead and complexity in your code, so you've made a tradeoff. I think that's a lot of people look at saying, "I want this to be immutable," then they actually have to come to the grips with the complexity that's going to introduce. There are libraries like Immutable.js that do make that a lot better but even they have the problems. I can talk about those but one of the cases is like being able to reason about a series of states for your object, rather than just only having one copy of it ever and being stuck with having to deal with it as it is. DAVID: Yeah and I think that really important too is being able to mentally track where you've been because in my experience on other large Ember applications, I've run into so many different bugs that I could really track down to people or rather, places in the code where things are just reaching in and mutating your model, where it wouldn't make sense, so as you're writing your code, you're in a completely different state than you might have expected. CHARLES: Yes and it's easy, right? But essentially, when you have some model, you've basically got a global object. There's a lot of recomputations that needs to happen when those things change. As a result, if you look at the actual code that supports computer properties in Ember and I'm sure other frameworks as well, some of the most hairy and complex. If you look at the chain watchers and the chain nodes and all the stuff that's required to support things like computer properties, it's amazing that it works as well as it does. I've tried to actually open that up and understand that code on a number of occasions and every single time, I had to walk away in defeat. TARAS: This problem exists in React applications and Angular applications because if you think of the challenges of working with set state, I think one of the problems with working with set state in React is that your complexity increases very quickly. It starts off kind of simple when you're using immutability with set state in React. They're kind of very light and then, as you start to add features, your complexity starts to grow very quickly in a way that you really start to run into limitations. You start to confront your personal limitations of your abilities to work with immutability, so you're limited to doing immutable structures that only a few levels deep because your ability to use destructuring to create new immutable object is limited by expressiveness of JavaScript. It's gotten a lot better with the destructuring but if you do it a few levels deep, I think everybody's familiar with what happens. It starts to get really hairy. You kind of loose track of where you are. CHARLES: Yeah. The signal-to-noise ratio increases because after probably, two or three levels, the majority of your code has to do with destructuring and restructuring and very little of the actual change that you want to make. TARAS: And this is kind of interesting because people talk about declarativeness versus imperativeness but at certain point when you have a complex immutable state change, if you're doing with destructuring your code, even though it looks declarative but there is so much processing that you're doing, it's actually kind of losing the benefit of its declarativeness. It's actually starts to look more like imperative code than it does what you would expect a declarative system to look like. I think this touches on the other aspect. It kind of compromise that when you work immutably, when it compromises, you make a serialization. Your ability to represent your state as a POJO becomes restricted by the fact that you have this complex system that's wired together and you have systems like zones in Angular and in Ember Object that are able to keep track of changes in these objects but you don't have a way to restore those objects. You don't have a way to do more sophisticated things that you might want to do, especially in situations where if a service feeding you, what do UIs going to look like. In that situation, it's really helpful to be able to say, "Here's a POJO that I got from the server. I'm going to use this POJO to build this component tree that the user is going to interact with and then, as the user interacts with it, I'm going to then, capture that state, serialize it and put it back in the server." When you're using something like Ember Object or if you're doing this kind of stuff in Angular or even if you're doing this stuff with React but without using something like redux, you essentially end up doing so much wiring to accomplish that. By the time you finished writing your application, you've written a ton of code just to handle this particular use case and if you have to do this again in another application, you just rewritten that kind of code in a new application as well. CHARLES: It reminds me of the concept of a Smalltalk image, like there's no way to really get at the state of a Smalltalk thing. It's almost like you're dealing in docker containers and not actually being able to write that state down into JSON or something like that. I'm trying to casting about for an appropriate analogy. Maybe that's not a good one but what's actually happening cannot be made orthogonal. It can only exist in that one run time that you're currently running. If something wrong manifests itself, reproducing it can be extraordinarily difficult, right? TARAS: Yeah. CHARLES: Imagine if there's some render cycle that's making a bunch of mutations and there's this process that you stood up and it runs in completion, some signal comes in and those effects are like ripple through the system, there's no way at any point to have any other representation of that system than the running system itself. TARAS: There's another element to this, which I find really interesting. When you're thinking about how to architect complex UIs, it's actually helpful to get really clear about what kind of changes are happening. A lot of times when I want to see beginners are writing, especially if you task someone who is a fairly junior at building a single page applications, a lot of times what will happen is because they don't have a clear mental model of what is going on in regards to state. They end up setting a lot of properties. Every operation, every time you have an event handler because they don't have a clear model of what's going on, they end up setting like five or six or seven properties. That kind of signals that they don't have a clear picture but what that also does is a lot of times, they usually comes together with cascading state changes. Usually they're not representing a single operation as a single state change because there might actually be a bunch of things that are happening because what they're doing is they're massaging the system into submission. Not like they're not in control of the state transitions, so they use, essentially time and their dedication to kind of sort it out and make it work and eventually, would that ends up looking like that if it works for most of the cases that they are able to test for or that they able to manually see. But then they AR, not accounting for problems that they're not able to understand right now, they become discovered by users when users start to interact with the system and with the components or with that application and the application is there to get into some funky states. The tools that we have, they don't prevent that from happening. They just -- CHARLES: Right. They don't force you. I think what you're saying is that ideally, you want to model your UI as a set of transactions on your state, that you want transactionality to your state so that I basically am saying, "I'm not going around and setting seven properties in reaction to this one event." I'm saying, "This event triggers this transaction and that transaction clearly bundles up every single operation that needs to happen and the tools don't enforce that." Is that a fair --? TARAS: Yeah and then, the problem is we're working with component trees. You start off with having a set of requirements and over time, the requirements change. As the business unit understands your application better, they give you more direction of how accounting should work and then you find out that there's more interconnect at stake but then what's happening now is that the cost of refactoring those state that spread throughout the components, whether that be with set state, whether that be with the actions in Ember or even in Angular. What you end up doing is you start to change the system but change is not trivial because the actual process of changing where that state lives is not linear. It depends on the complexity of the code that you wrote and it just gets really hairy very quickly. That's where companies end up losing a lot of time. A developer could start off with a requirement, you build something and then a new requirement comes in and instead of it being a simple change, it turns into a week or two weeks refactor because you now understand the state ownership should be different. The state that you have should be in a different place. You have to manually make that change. You have no obstruction to help you express that in an easy way. CHARLES: Another thing, because we are doing a kind of a roundup of all the things that you need to account for when you actually embark on managing your state. Another is actually constraining the amount of computation that happens. If your system is based on listeners and large chain reactions of things where it's like, "This property changes so I need to notify these other 10 dependent properties that change." You can do a lot of unnecessary computation, especially if nobody is going to render. That's kind of the thing that you have to do if you're going to be immutable. You have to eagerly walk those change to see which objects are affected so that you can then invalidate those caches. A system like Ember Object, I don't know exactly how Vue works, it mitigates this somewhat by the fact that the computer properties are lazy but you still have to walk all of those chains. That can actually get out of hand. They're eager, not lazy. Then the other concern that you have, where you normally have to make a trade off around is around composability. One of the things that's really nice about immutable systems is they're very composable. If I've got some object that does one thing, I can then just set that object onto another object just by mutating one of its properties and I've effectively composed them. I can then install listeners onto that thing or I can compute properties off of that property and they can post pretty well. That's something that you get but then of course, you're losing all of the benefits of immutability, so things like Immutable.js don't really compose very well or redux doesn't really compose very well. The concept of taking a redux store and embedding it into another redux store, you just don't see that. I would never distribute and I think ultimately, the litmus test there is would I be able to share it on something like npm. Nobody shares an npm package that's just a redux store that you can dispatch actions to and observe and use it with your other redux stores. When it comes to a system like Immutable.js, that does make transitions a little bit easier over lists and arrays and maps but you still run into the exact same set of problems that you have when you have lists of maps of records and you don't really get any help there, so you have to make this tradeoff between immutability and composability, whereas a system like MobX or Ember object actually quite composable. Before we start talking about microstates, I want to say that you just throw those in there because there is just a lot of concerns out there, a lot of edge cases that actually build up but through the course of a real application, you will encounter them all. You might be making tradeoffs at the beginning that you're not realizing that you're going to need or are going to get you into trouble later on. DAVID: This actually happens in the Angular community as well because there's something really great that's happening with observables in the Angular community. I think everyone's embracing them wholeheartedly and I think that's really been pretty great to see but observable streams of composable, but objects that have on them observable stream providers of some kind, like if you have something that you can subscribe to and that is part of a property in a class, composing multiple classes together and consuming properties from those classes, there is no mechanism for composing that. That kind of composition has to be done manually. Again, you're kind of manually wiring together a bunch of objects and the big challenge is that you are manually subscribing to all those streams and unlike what you have with components. Components have lifecycle hooks. When your components is being torn down, you know you can perform some operations. If you need to remove an event listener, you have a hook where you can do that when you have a class instances like JavaScript class instances that have on them properties that have observables that you subscribe to. There are no tear down hooks for class instances, so there are no obstructions from managing unsubscribing from those streams. You essentially end up having the foundation that you can use to build complex reactive systems and you can subscribe in there really fast but wiring those things together at a bigger scale is simply not there. It's something that you have to create and enforce yourself. CHARLES: Right and I think that's probably a perfect segue into talking about microstates, which is the project that we've been alluding to for the past 30 minutes, that is I think in attempts to solve these problems and make sure that you don't actually have to compromise on those things, so you can reason about things locally but have those things be composed into a greater state. But also have them be immutable so that you can look at past states and reason over a data structure over time as opposed to just in one instance. Also, have an intuitive interface that when you're making these changes, doesn't look like half of your code is unpacking some data structure, flipping some bit in it and then repackaging it back up again. That's the context. Should we start talking about what microstates is and how it addresses those? TARAS: That's a good next step and when I start working in the ReadMe, I end up actually, I think I wrote about 40 pages. One thing that's interesting about microstates is that and this was part of the design of microstates from the work that we've done is that we intentionally wanted to make the number of ideas that you haven't microstates very little, so when you use microstates, the number of concepts that you need to remember in your mind is very few. It is a conceptually a different way of thinking about organizing your state in the same way that shifting from managing DOM elements directly to having an obstruction like component that declaratively applies changes to your DOM tree. In a same way, microstates is kind of an abstraction that allows you to declaratively describe how your state will change and it will manage the transitions for you and allows you to give the state transitions names and it allows you to give your states names as well, so you can actually name things. You don't get a POJO that has a shape but has no name. You actually get to give things names. CHARLES: So, why don't we start? I have a list in my mind. I should probably write it down of the things that we just talked about but I think the things that we talked about are ease of representation, like conceptually easy, transactional, basically serializable and immutable, lazy and composable. Those are like five or six things. But I think there are kind of aligning principle around which we gathers that the state management should feel easy. It should feel fun. One of the things that is awesome about working with components, whether you're using web components or React components or Ember components is when you get it right, you're just snapping these things to feel together and it feels great. It's like I'm just passing properties and render blocks down the tree and the framework is just doing all of the grunt work for me and I'm just operating at a very high level. That's what organizing principle with microstates as it needs to feel easy. Maybe we should start there and just say, how does that easy and fun line up with each one of those kind of unique problems around which we typically have to make tradeoffs? We could start with the interface of making a change. TARAS: I'll go back to the starting point. I remember what got me first interested in microstates is Charles, when you said that, when you have a number, there are certain operations that a number can do. We really don't need to be writing an increment operation for every... Like if you a have a number, you can increment it and decrement it. CHARLES: Honestly, every time I see state management tutorial and they tell you how to increment and decrement a number with it and you write the increment code and you track the thing and you store it back into the store, at this point I'm still annoyed with those tutorials because I'm like, "It's a number. We know we can increment it. Just show me where to plug in the code. I should not have to be writing an increment method." TARAS: Yes. And that's the kind of starting point. There are certain operations that you can perform with the primitive types. If you need to add a number or if you increment a number, we already know how to increment the number. It's part of microstates. But that in itself is nice but that's not that important. I think what's really important is that when you need to put a number into another data structure, let's say you have a nap and you're like, "I need to..." I don't know -- CHARLES: Let's say, like a click tracker that has a number of clicks. TARAS: Right. By itself, you can increment the click tracker but if you need to put a quick tracker into another app, essentially you can compose it in and you don't need to figure out how to wire the actual mechanism of how to make sure that you can update the property, like it's part of another class, for example, you don't need the way you would increment the number. When it's a part of another class versus how you would do it when you're working with it by itself is an approximately the same. The amount of work that you need to do to actually perform that operation is the same. Your complexity doesn't increase as you compose one data structure into another. CHARLES: Right. You can just say, "This is an app. It's got a click tracker and this property is a click tracker and I have to do nothing else. I can register clicks on that thing. It doesn't increase the complexity of application at all." TARAS: There's no wiring. Now, you added some new state, that state is very explicit and it's really clear that it is not impacting other parts of the state. You can operate with this thing. If you change it, it's going to work properly with all the other things that are in the type that you are adding this counter to. Those things are just going to fit well together and it's not going to break if you need to transition one more thing. All of the other transitions will work the same way. I think that kind of consistency is really meaningful, over time especially when you start to increase the amount of state that you manage in your application. CHARLES: Just the ability to work with types and just have kind of those implicit operations and have those things compose, kind of indefinitely. Moving down, we talked about easy and the other thing I would put on that is that the way in which you express those transitions, for example if microstates comes bundled with numbers and Booleans and strings and arrays and objects and kind of the stable of types that you would expect in any JavaScript application but those types are expressed using this way for expressing types, essentially. When you actually do make a transition, it feels very object-oriented, I would say, even though it's not. It feels like you're mutating but you're actually doing a transition. Does that make sense? TARAS: I think for anyone who is familiar with what it's like to write queries for GraphQL, if you're not familiar with it, it's fine. You can get a sense of that from microstates but if you're familiar with the ease of just writing a query and if your backend knows how to retrieve the data, then your queries will just give you the data that you want. That feeling is really powerful and just being able to write the query and just gives you what you want. Microstates is kind of like that. Actually, the inspiration came from experiences with GraphQL, which is that sense of ease is what we wanted to have in microstates and so you get that seems sense of like, "I can just do what I want and it just going to work and with this other thing and it just going to work," and you're just like flying through, like adding states to your application and it's just working for you and working for you and working for you and you don't have to do monkey work like gluing things together. It'll change how you are working before because you have a way of opt working with these things at a higher level. CHARLES: Right. Let's talk about transactionally or should we talk about immutability? How does this make immutability easy and fun? TARAS: I think one thing is that you don't have to write reducers and you don't have to do destructuring by hand. I think you have a way of expressing. Thinking about this, if you have a component tree and let's say you have redux and then a bunch of components like your parent component, your root component has some state using sets date and then components further down the tree also have state. You could actually express that as a microstate. What you would do is, essentially the parent component state would be the root and then the children's component states would be composed into it. The nice things about doing that is that at the root level, you have access to transition state of the children declaratively. You know where the states for those children is on the route type and you can write transitions that are going to declaratively perform multiple operations on the children state and I suppose it'll restructure to what happens with components but if you don't use this, you might have multiple sets date operations. The process of wiring data from the root down to the children is kind of complicated, where here, you have a way to represent that and perform a lot of transitions in the way that is going to be just easy at whatever level you need to operate at. CHARLES: Right. I think, for people familiar with redux, in redux you act globally and then you react locally, if that makes sense, so you dispatch an action to the entire store and every single reducer can see that action. There's ways to manage that but effectively, you have this one atom and then you have the reducers that kind of act on local state, whereas with microstates, you're basically acting locally. You're reacting locally but the effect is global. TARAS: You're participating globally. CHARLES: Yeah, participating globally but you never have to consider the context that is above your own, so you never have to be mindful or cognizant of the context in which you're enclosed because from your perspective, it just doesn't exist. DAVID: Every microstate has a set transition which is the basic transition that you can invoke, essentially in any type, so what's interesting is that it's amazing how powerful -- CHARLES: So, we should break it down really simple. Basically, when you create a microstate, with a type, you say like, "I want to create a number with the value five," and then I can just say, "That returns a microstate," and I can say, "microstate.set 10," and that will return a new microstate who's also a number but the value is 10 and that's available on all microstates. DAVID: Yes. If you have a tree of components and your state is presented by a microstate at the root level, then what you can do is you can invoke the transitions on any part of the microstate and it will just know how to properly create the next microstate for you. The example that Charles you gave of one number so that number can be inside of a class that represents state for a particular component and then that can be a part of another class or represents a state for another component but then, when you invoke a transition on one of the leaf nodes, an equal sets state on one of the leaf nodes or equal set on one leaf nodes, it will respond locally but it will actually reflect the changes globally. At the root level you're going to get a new object that causes the components to update. CHARLES: You know what? I have another concern that actually just popped into my head, which is something that I've certainly struggled with in every single application of notable complexity is stability of value. We should put that on the list. We're almost out of time to talk about this. We spend too much time... Well, not too much time, of the issues of state management, which I think you can't spend enough time talking about but I did want to pile one more on there is when you're making that transition, where you're acting locally but you're participating globally. For things that are unaffected by your action, remain unchanged. That is a super power. It's actually very hard to do with a lot of state management, especially when you're cloning a bunch of stuff, being very judicious about what you don't want to clone. Where this really comes into play is if I want to re-render something. A lot of times you have to jump through a bunch of hoops to tell, did my model really change or did only referentially change? With microstates, when you make that local change, if you're embedded in a very large graph of objects, obviously all of the objects above you are going to be changed but what about things that are off to the side of your siblings. They're outside of that scope of that change. They shouldn't be cloned. They shouldn't be copied over. They should remain the same. If you're doing a re-rendering based on the changes that are happening, that's going to be a key feature because you're not going to have to write, basically any hooks to say, should I have to re-render my component. You can always rely on triple equals. DAVID: This quality is going to describe the structural sharing and some of the other tools that are available but I think that's how it's accomplished. I think one thing that's a little bit different with microstates is that when it comes to structural sharing, it's not that difficult to do if you just do structural sharing and value. Meaning that you can do structural sharing on a value using something like lenses and not a lot of people are familiar with lenses in JavaScript but it's actually only three functions that you can use and it can give structural sharing on complex POJOs. It's pretty easy to use relative to how little people know about it but what that doesn't do is it doesn't allow you to graph of objects that have their own operation that you can invoke and that will perform structural sharing. That part, I know that is not available in any solution, I think at the level of completeness and luxury that microstate provides when you write things. CHARLES: Right because every piece of the tree kind of comes bundled with its own things that you can do with it. DAVID: I don't think you should jam everything into this podcast because there's a lot to talk about it. I think one of the things and we've talked about this a lot, which what we want to do is create an implementation for an idea of what it would look like. What would it be like if we had a composable state primitive that we could use to describe state and share state solutions in the same way that we share components like react-virtualized or whatever your particular frameworks or popular component may be. What it would look like if we had solutions to state problems that we could share and we could -- CHARLES: I think the litmus test of an awesome solution is like you look at this current crop of MVC frameworks and what's so awesome about it is they're sharing. That can happen, right? If I'm writing a React component, I can publish it on npm and other people can use it. If I have an Ember add-on, I can publish it and people can use it. They can consume those components. That's awesome and I think it's the hallmark of a great system. What would it look like if I wrote just the state piece of a file upload and I could publish it npm and then anybody, in any framework, could actually use it with their framework without paying any penalty. What would it look like if there was some transactional data store that could be built and shared and the hooks into any framework were minimal. The possibilities are really exciting around that idea, whether it is realizes microstates or not. But clearly, we feel this is something you should be able to do. DAVID: I'll add one more use kind of use case that I personally find really motivating is that there's a lot of companies that are investing into building single page applications and a lot of times, what you see happening is they're building a very similar application to what they had before because their business hasn't changed. The technology has moved on so solutions have improved. The demands for better user experience have increased but the actual business and how the things that people have to do on day to day within their company hasn't changed. What we're seeing right now is we're seeing the same, like whatever was written before in jQuery or an AngularJS is now being rewritten in React or Angular or whatever you might Choose. But whatever you like to see is it has a situation where the domain specific logic of your business is represented as a data structure that knows how to, potentially, in the future talk to the server and retrieve data from the API because that's likely not going to change. But you can use that like that's been tested and published as an npm module within your enterprise and then you can then consumed that in any framework and it's actually easier to do it this way, than to implement it in a framework-specific version of their state management. That's the part that I find the most exciting. I think one of the things, just to connect to the goal is that, we would like to keep this conversation going. If you're interested and I think this is a kind of a call to our audience that if you're interested in this, we would love to have in our podcast to talk about these things because I think there's a lot of things that microstates really is a beginning of a conversation. It's not meant to be a statement. It's meant to be a proposal that we can just talk about this. CHARLES: I agree and that's one of the reasons we're keeping it very small at this point. The core library of microstates is not setting out to accomplish too much. In the core library, there aren't even any side effects. It's actually impossible to have side effects. It means that it cannot be used for anything except for the model but that's very liberating and it let us focus on what would a system like this actually look like. DAVID: It's really exciting because this has been the biggest metric but we have microstates in the JavaScript weekly and that was great and then it got circled around when people know and it's like 800 stars now, which is not a really big deal. It's funny because somebody commented like, "How can you put something in production that only had 100 stars?" CHARLES: I think it's just important to realize that this really is the beginning of a conversation. There's a really exciting set of things to come. We haven't even talked about how we're going to model side effects, although we're going to use microstates to do it. We haven't even talked about what the various framework integrations will look like and what are the best practices for using this to organize state in your application. We've had some lively discussions internally about what that looks like. There's still a lot of questions but it's going to be a really, really exciting and edifying experience to get to answer them. DAVID: Yeah, it's pretty exciting. I'm excited too. There's been a lot of interest from people in microstates, so it's going to really great. I'm looking forward to meeting people and having conversations about how we can use microstates because I'd love to have someone create a really great solution that I could just take off the shelf and just use and not have to implement them myself. CHARLES: All right. Well, I think we could talk about microstates for at least the next three hours but we have to give everybody an opportunity to, at least like go to the bathroom or something. Microstates will return but if you're interested in learning more about microstates and you happen to be in one of the many places on which we're going to be presenting on microstates in the future, who knows? Maybe you can come in and join the conversation in person. Taras is going to be speaking at Toronto.js on July 30th. He's also going to be presenting at Manhattan.js on August 8th and then, yours truly will be presenting on microstates at React.js Austin on the 6th of August. Come out and see us. We'll drop those in the show notes and it's guaranteed to be a good time and we'll have that conversation. Until then, we are the Frontside. We lead with the why, the how and then the what, if you're interested in working with us and that helps us that we guarantee the lowest total cost of ownership for your application. We're always looking for feedback. If you have news items that you'd like to see at the head of the show or just any feedback or questions, we would be happy to answer them. Thanks today to Mandy Moore for producing our show and next time, we'll be talking with Kristian Freeman about what it's like to run an online conference with Twitch, so I'll be looking forward to that. Bye David. Bye Taras. DAVID: Yeah, thanks for having us. TARAS: Bye. CHARLES: Yup, and bye everybody. See you next time. Next Time: Running An Online-Only, Free Conference on Twitch with Kristian Freeman

Special Guests: Brian Douglas and Bex Warner of GitHub. In this episode, the panelists talk about automating GitHub with Probot. The origins of Probot are discussed, as well as making GitHub apps with the GitHub API, automating workflows with Probot, must-have Probots for every repo, and GitHub's V4 GraphQL API. References: Microstates README Probot github.com/integrations/slack github.com/marketplace/pull-reminders platform.github.community/c/integrations probot.github.io/apps/unfurl-links/ probot.github.io/docs/deployment/ probot.github.io/docs/extensions/#scheduler probot.github.io/community This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. TRANSCRIPT: ROBERT: Hello everyone and welcome to Episode 105 of The Frontside Podcast. I'm Robert DeLuca, the director of open source here at the Frontside and I'll be your episode host. Today, we're going to be discussing automating GitHub with Probot with Brian Douglas and Bex Warner. I'm really excited about this topic. The idea of automating GitHub workflows with bots is amazing. This is something that I've been wishing the GitHub have the platform support for since I even started using GitHub for open source. Just being able to have a bot to take care of certain things like somebody doesn't leave enough of a PR description and they open up a PR, you can have a bot that just responds to it and saying, "Can you provide more information?" It's pretty awesome. With me as co-host today is Charles Lowell, who is also a developer here at the Frontside. Hey, Charles. CHARLES: Hey, Robert. ROBERT: Before we get into the discussion, I like to make a tiny little announcement. We've been building a composable and an immutable state container called Microstates. I'm sure Charles can talk about this more at length, then we will in the next podcast episode -- 106, but I would like to make a small announcement that Taras who is an awesome developer here just wrapped up a month's worth of work, creating a new ReadMe to describe the vision of Microstates and what you can do with them and everything about Microstates. If you're interested in that, I highly recommend checking out the ReadMe. I'll drop a link in the show notes for you that are interested. CHARLES: If I can add, it really is [inaudible] because it isn't like any other state management solution out there. ROBERT: No, absolutely not. I've been building something with it in React Native over the weekend of the 4th of July and it's amazing. But enough about that, you'll hear about that next episode. For this episode, I want to talk about Probot with Brian and Bex. Hi are you two doing? BRIAN: I'm well. BEX: I'm good. Thanks for having us. ROBERT: No, thank you for joining. This is really exciting. Like I said in the intro, I've been really excited about this project. I do a good amount of open source, I would say and this has been really helpful in all of our repos. We have, I think like 78 open source repos on the Frontside. We have Microstates, like we just talked about and Big Test and all of those repos use some combination of Probots that people have built and it's really nice, especially with the new Checks API that has just come out. You can integrate Probot into that, right? BEX: Yes. I, actually am currently working on shifting one of our bots from using the commits Statuses API to the Checks API. ROBERT: That's awesome. Before we go too deep into it because I want to come back to that because that sounds really cool and what the integration of that is like and what changes because I'm not even really that familiar with it. I just know it was released. I kind of want to go from the beginning here. Where did Probot come from and can we get a little bit of a history for everybody that might not know what Probot is? BEX: Sure. Probot originally started out as this simple idea to make GitHub scriptable. The original idea was you have a single file in your repository that would be like a JavaScript file and it would essentially spell out how the bot would act on your repository and the goal was to make GitHub apps accessible to people because if you ever look through our GitHub apps documentation, I think it can be a little tough to get started. There's, honestly, a lot of nonsense that you have to go through in order to get set up. For one thing, the way our GitHub app authentication works is it requires a JSON web token followed by using that JSON web token to request an installation access token and that process would be really tough for new people to get started. ROBERT: Yeah, it sounds like it. BEX: Yeah, so Probot was created to abstract all of that away and handle all of that authentication automatically and simply leave you with the payload that you get from listening on web token events and in authenticated GitHub client to make authenticated API requests while authenticating as an app. ROBERT: Cool, so that's where it started like a flat JavaScript file in the root but today, you use like EMO files and a .GitHub folder. How do that kind of progress? BEX: Originally, their use case was much simpler and it quickly became clear that a single JavaScript file in the GitHub repo was not scriptable enough and not easy enough to understand. The goal was to make like an API that could make that JavaScript file really, really easy to customize for every API of GitHub and it quickly became clear that that was not really a feasible thing to do. as time went on, it turned into this way to build Node JS applications and essentially, what the configuration files you're referring to are the way in which we make it customizable because right now, there's no way to be officially supported GitHub apps channels to pass secrets because it means you're a [inaudible] and the owners of GitHub apps, so that was just a way to kind of stop that problem. ROBERT: Gotcha, okay. BEX: The actual code for GitHub apps still lives in a Node JS module basically and the configuration file just specifies how that module runs. ROBERT: Right, so they're deployed like Heroku instances, if you want, like anywhere you can host a node app. BEX: Yup. Heroku, Now, yeah. ROBERT: Interesting. BRIAN: As a reason to that, some explorations of doing serverless deployments for Probot, I think there's a couple of issues of them. I'm not sure if anybody's shipped anything like the way they at but it's pretty much it's possible to. BEX: Just a week ago, we even released a new version in which we update our core from Node JS to TypeScript and now that things are typed, we have big plans for serverless. ROBERT: Nice. That's awesome, so then you'll be able to deploy to a Lambda and off to [inaudible]. BEX: Exactly. CHARLES: Can I actually interject here, as kind of a person who doesn't really know the relationship between GitHub apps and the GitHub marketplace and what exactly a Probot is before we hear the origin story. I would love to hear a very high level view of how this ecosystem fits together. BRIAN: I think a lot of people are pretty familiar with interacting with the GitHub API and OAuth integrations. I think I've just spent a lot of time at different companies previously to GitHub, just like making calls, either to cURL or through Node JS or more recently, [inaudible]. GitHub apps itself are a way to take all the things that you had to do to make an integration to GitHub much easier. It has a lot of cool things like OAuth, scopings, so you no longer have ask for all your repos ask access whenever someone logs in with GitHub and the connection between like, "Now have gone from OAuth to Now to GitHub apps," there was a lot of, as Bex mentioned earlier, ceremony that happens to getting set up with GitHub apps and integrations that Probot is like this tool to speed up the process of getting to the point where you just want to script some automation or some sort of workflow and it gives you all that bullet play for you. I don't know if that was a good high level for you Charles. CHARLES: Yeah. I've kind of witnessed this second hand with Robert installing a bunch of things here, so let's use an example, like you did some sort of automation on our repos, Robert, where when someone files a ticket, there's this workflow that automatically adds a triage label, so that we know that this thing hasn't even been dealt with, so we really need to address that issue. It doesn't need to be as a high priority. It doesn't need to be closed as a duplicate of something. One of the different aspects that you described there, how do they fit in terms of serving this workflow onto the end user? Or was that a good example, even? BRIAN: One of the cool thing about GitHub apps and what Probot does for you is that normally, if you want to add a label to an issue, either you Charles or Robert, would have to be admin or maintainer on the team for the Frontside and you could add labels. But somebody who opens up an issue, doesn't have that ability to have write access to your content, which is adding a label. What a GitHub app does, it actually takes a spot as if you would have another user on your platform, instead of creating a dummy account or a dummy user. Probot is basically building a bot for you to then, give you the ability to add that issue. That's sort of workflow that normally would have to happen through an actual real human could not happen through a bot without taking up a spot of like, "I guess, I probably shouldn't speak so ignorant about our platform and what we actually pay for nowadays for GitHub," but I know we used to have like a limited amount of seats for organization, like that seat no longer has now taken up and now, it could be just be used a bot can do something that normally us would take. ROBERT: Right. You no longer have to create a user to do these things. BRIAN: Correct. BEX: [inaudible] within GitHub. It's sort of built in a way that apps can take a lot of power in your repositories. CHARLES: So then, what is the relationship between Probot and an app? BEX: Probot is essentially the framework for building an app. You can definitely make the equivalent of any Probot app outside of Probot. It abstracts away all of, basically, the horrible parts and leave the easy part. CHARLES: Now, I think I'm ready to participate in this discussion. ROBERT: That was perfect, though. That's a great intro because I actually didn't have a total grasp or understanding of the relationship between GitHub apps and Probots. That's really good. BEX: Yeah. Additionally, going back a second. You mentioned the marketplace before. One thing to note that is that there actually are several Probot apps on the marketplace right now. The marketplace is essentially the home for any larger, usually third-party companies that have made apps and Probot is essentially supporting some of those. ROBERT: Interesting, so then my question would then be, do you know anybody selling their Probots. Does the marketplace charge? I'm going to assume it does. BEX: Yes. ROBERT: Okay. Is there anybody charging for their Probot? BEX: Yes. There is a quite a few, in-fact, charging for it. Recently, a pretty popular example is the GitHub Slack integration, which is if you open new issues, you can have them appear in your Slack channel. That whole application was recently rewritten by GitHub. It was previously owned by Slack and that was built on top of Probot. CHARLES: And I actually remember, we upgraded to that version. It's actually way, way, way better. BEX: I'm glad you feel that way. CHARLES: I didn't know the story behind there. I was like, "Oh, I just got a lot of... Awesome," you know? Although I don't know what's the costing. BEX: Yeah, I think that integration is actually free, so that wasn't the best example. I think it's for open source projects, at the very least. BRIAN: Brandon, one of the maintainers for the Slack integration and work at GitHub, also did a really cool talk at the SlackDev Conference a couple of weeks ago, so if you're interested what were the behind the scenes. That integration is all open source as well, so if you have request or you have features that you would like to add to the Slack integration, you can pop into the repo that hopefully will show up on the show notes because I'm not sure if it's like GitHub/Slack, but I guess we'll find that out in the show notes later on. BEX: It's Integration/Slack. BRIAN: But for an example of a paid app of a non-third party, we're not talking like Travis or Circle or another one with the big names but rather, a solo dev created. It's Pull Reminders, which is on the marketplace as of today and essentially, this gives you reminders of your pull quest, so you can actually ping inside the comments and tell Pull Reminders to say, "Tell me about the pull request like next week because it's Friday and I don't have time to look at this." ROBERT: That's awesome. I've also seen the one that's kind of related, that is like you can set your out of office at GitHub, which is actually kind of a neat concept. BEX: Was that the one where we are already changing that profile photos to have the overlay or the one where is just auto-replying to messages because I've seen a couple of -- ROBERT: I think, it's just auto-replies. BEX: Okay. CHARLES: So, it can change like your profile pictures and really, not just related to repo and history related activities but everything? BEX: Anything that you can access via the GitHub API, you can almost access via GitHub apps. There's a list of end points that I specifically enable for GitHub apps because there's something such as delete a repository that there's basically, a very few circumstances under which you want to give that permission to an app. Also, to things very specific like your profile or your personal page. About a year ago, there was an official internal audit of all of the API endpoints because there are lots of inconsistencies over what was and what wasn't enabled for GitHub apps, so they went there and kind of decided, what endpoints should be enabled and what endpoints actually get enabled. Now, that list is much longer than it was a year ago. Now, it's much more comprehensive. ROBERT: That's awesome and is this for the Rest API and the GraphQL API? BEX: Yes. Probot does support both. The Rest API is the one that specifically had all of these endpoints audited. The GraphQL, since it's a bit newer, we sort of built those and more. ROBERT: Cool. I really like working with the GraphQL API with GitHub. It makes it easier than trying to do a bunch of Rest calls. BRIAN: Yeah, there's a community form, it's like a discourse form that the API team actually manages and sort of pipes in there. Again, going back to like, if there's not something in the Slack integration that you would like to have, the form, that community is actually in there, if there's something not in the GraphQL API, that you would like to see. No promises on shipping it within an x amount of time but if enough people are requesting it obviously, there's going to be some resources [inaudible] at. ROBERT: What do you mean? We're doing open source. It has to be done yesterday. BRIAN: Yeah, exactly. And that form is at Platform.GitHub.Community, just a URL to get there. ROBERT: Awesome, that will be helpful to look through and get some recommendations in there. One of my favorite things I was going to say about the new integration for Slack and GitHub is the fact that I can highlight line numbers, paste that linked in and then it just expands it and the chat in Slack. That is so nice and I use it all the time. BEX: Yeah, I love that they built that feature. Actually, the original feature that was built on GitHub to allow those line expansions in the first place, like on GitHub itself, was actually built last summer by some folks who were also a part of my intern class at GitHub last year. ROBERT: Hey, intern power. That's awesome. BEX: Yeah. ROBERT: Everyone there is doing amazing work. I'm also following along with somebody that is also an intern and it's building a weekly digest program. BEX: Oh, yeah. That's actually a Google Summer of Code student. ROBERT: Oh, interesting. BEX: So, being sponsored through Google Summer of Code by Probot as an open source support. ROBERT: Is there anything more to unpack there? That sounds really interesting. BEX: Essentially, we submitted an application for Google Summer of Code because we thought it'd be a cool way to get more people, more students, a mentorship opportunity for the maintainers, basically and we were honestly overwhelmed. We got like almost 100 applications and it ended up being a huge of a deal but we're -- ROBERT: That's a great problem. BEX: Yeah, definitely a good problem but we were really happy. We, initially wanted to accept more students but Google limited us to only two students, so we have two Google Summer of Code students working on projects and one team of women from Rails Girls Summer of Code working on Probot. ROBERT: That would be awesome. What do they working on? BEX: I'm not sure yet. They actually just started a couple of days ago but the other Google Summer of Code student is working on a background checks API to eventually do sentiment analysis of comment history of someone new to your repository. ROBERT: That's interesting. That sounds like there will be some machine learning in there. I might just throwing out buzzwords? BEX: Most likely, I think they're just using some sentiment analysis API, like the perspective API. I don't think they're actually doing that themselves. ROBERT: Okay. CHARLES: Actually, I have a couple questions. Back on the subject of Probot. How does this square with the classic mode of integration because there was a lot out there? I think the first one that I remember that stuck in my mind was like Travis and I don't know if there had to be like a special relationship between the Travis developers and the GitHub developers, that's like, they was able to make that integration happen so many years ago. I don't know how that happened. I just remember it popped up and I was like, "Woah. This is incredible," and we see kind of the integrations gets more and more rich. For someone who's got, like you mentioned a couple of the big names, is the idea that eventually those would be able to be completely supported is GitHub apps or is it they're always going to be kind of a separate track for kind of the really deep integrations? BRIAN: I wasn't around when Travis first integrated with Lyft GitHub and I think that's a really cool integration and I know they have a very nice sized team that's able to do that. I think if we zoom back out like Probot, the way to get started with Probot is that we have the CLI command, which is to create Probot app. I believe it was intentionally copied off of create React app and the cool thing about create React app and create Probot app is that they abstract all the ceremony and boilerplate to get started really quickly. It was like, what developers or smaller teams can get started with integrating with GitHub apps. I highly doubt that Travis is going to rewrite their entire application with something like create Probot app but they're definitely going to be moving towards the new API calls, which would have been like GitHub apps. Part of the Checks API that we had launched at the end of May, Travis had blog post on how their integration with the Checks API works. They're making, though they have a lot of what Legacy endpoints and a lot of Legacy integrations in the way they integrate with GitHub, they are actively moving towards a GitHub app. I don't know if I could actually comment on their status of where they are today, to be honest but actively, we want all new apps and new integrations to follow the model of being a GitHub app, so that way, out of the box, you have access to all the newer features. You have all the access to all the newer GraphQL endpoints, if you want to use GraphQL and that way, we can serve one market, as opposed to everybody who had a GitHub integration from five or six years ago, that was all piecemeal together and sort of duct tape, like we run move away from duct tape everything together. CHARLES: I see. BEX: I definitely agree that I don't think Travis is going to switch to using Probot anytime soon and I don't think most of the large companies will be doing that but I do think, there will be shift towards GitHub apps in general. For those companies that don't already have the buildings of the GitHub app started, I think that Probot could be, in time to free some of them. BRIAN: In addition to that too, Travis and Circle and all the CI integrations, they're doing a really good job. I think the cool thing about GitHub apps is what you take away all that ceremony of getting your checks to work, now we can start opening up the door of like what's the next sort of CICD thing like? There's another term or another, I guess category of applications that can now be built to improve GitHub. CHARLES: The most amazing thing about having a great platform is the apps that you don't foresee, like it just come completely out of left field and you're like, "Woah. I can't believe that's actually a possibility now." When you have started to see some of those, some Probot or GitHub apps, you're like, "Man, I didn't see that coming. That's awesome." BEX: A hundred percent. I think it's the most exciting part of Probot because I think GitHub as a platform, we all know GitHub is the largest developer platform in the world and I think the idea that developers can build on top of this platform is the most exciting idea right now. I have honestly already seen apps that really excites me. The other day, I saw this app that was definitely not near completion but it was essentially updating and issue a comment box over and over and taking response through like checking a box and then listening on that common edit, in order to specify your coffee order. ROBERT: Woah. BEX: I was like, "Do you want an ice coffee or regular? Do you want milk or sugar and cream?" and it was going one at a time. It didn't actually order you your coffee at the end but it was super exciting to watch that. You're just editing the comment. I had never seen that before. ROBERT: That's pretty slick and that's taking the API pretty far. I'm sure there were some parsing in there and each Webhook response are like, "Was this box edited or not." That interesting. CHARLES: Yeah. Actually, now that we're having this discussion is kind of like changing my mind a little bit. Robert and I were actually talking yesterday about trying to standardize on our release management and our plan was basically to have some software that was going to run inside of our CI provider and have kind of a shared library, just a little ntm package that was shared by all of our repos but I'm thinking now, man, we should really explore doing this as a GitHub app. ROBERT: Yes, please. I've had three ideas that I really want to build out as a Probot. I'm just going to list them off and then we can build them all together and take equity and you know. I'm kidding. But the two that really excite me, that I kind of want to do is one concept that we work on this open source project for our clients and if somebody from the outside that doesn't have commit bits to be able to push to master, it would be really cool if we had a Probot that after it had an approved on the PR, from the maintainer, that the person that open the PR could then tell a Probot say, "This is approved by somebody that manages this project. Can we merge?" and then the Probot would then actually merge. I don't know if that's possible. That's something that I definitely wanted to explore. Then the other one, which is less cool, would just be like if we have a couple branches on some of our projects that we want to continue and we're not ready to put it back into master but we want to continuously run the test suite against it, so the idea there would be to have a Probot that would watch for changes on master and rebase as needed and continue to run the test suite and see where you're at. Those are the two things that I'm really excited about to do with Probot but I just want to automate everything with GitHub now. CHARLES: Right. BEX: Yeah, definitely, that first idea was actually pretty viable. I'm curious to know like how you actually get those commit links -- is that what you called it? ROBERT: Commit bits are more like commit permissions, I guess. BEX: Oh, I see. ROBERT: An outside contributor. CHARLES: Yeah, we want to push responsibility to the person who is the maintainer who can approve it but actually, the way we do it at Frontside is the person who actually is making the change is responsible for merging it. Once you get approval, you still have to hit the go button and that's just going to make sure that you're taking responsibility for saying it's done but that doesn't work for open source because people coming off the internet are going to have the right to push but we would like to give it to them, maybe via an app, if there is a maintainer who's approved it. BEX: Yeah. That's definitely something you can do. I've seen quite a few apps that, essentially add outside collaborators to the repo. Are you familiar with the... I forgot what it is called, like the all contributor section, where you cite everyone in your repo and everything and who's worked on it. There was a GitHub app that would add someone automatically after they merge their first change. CHARLES: That's awesome. ROBERT: I may have seen that on React State Museum but I'm not sure. It's a repo that we've contributed to and it has all the contributors at the bottom. It seemingly just kind of popped up there. BRIAN: There's an app that, I would like to mention too that I'm pretty excited about, that it sounds trivial too and it's almost similar... Not similar but it's sort of related to what you were talking about, Rob, with your first app, which is the WIP bot, which is the work-in-progress bot. This is a pattern of whenever I open a PR and I might not ready for a merge but I want to share my code so I can get feedback earlier on, I'll type in WIP so that append to my title of my PR. What this engineer did was every time you do WIP, it's going to go into the GitHub API and actually block the PR for merging, which is a feature available to GitHub. It's nested in your settings but the cool thing about this it actually blocks the PR for merging, so you don't have to worry about getting your, sort of like show and tell code merging the master without being ready. ROBERT: That's one of the first bots that I installed on all of our repos and then you can correct me if I'm wrong, it didn't always have the ability to block the PR from being merged but with the new Checks API, is that something that was introduced? BEX: Not exactly. The way that blocking of merging works is if you set it as the required status, so you can install any sort of CI on your account and have it not being required and ignore it whenever you feel like it, so it's really up to you to make it required. Otherwise, it just isn't checked and that's true for anyone who uses the Statuses or the Checks API. ROBERT: Okay, so that's a Statuses API. Okay, sorry. BEX: Yes. ROBERT: Also, the cool thing about that that I noticed when that was rolled out was I was now able to pick and choose and use workflows on Circle CI and each workflow is broken out as a different status check. I am now required like linting and the build and the test have to pass for these browsers before it can merge, which is really cool to be able to pick and choose. BEX: Yeah. It's awesome. I know personally on some of my repos, I have a few checks that I just don't require because I know I have to make them pass. ROBERT: Yeah. Speaking specifically about the work-in-progress bot, do you know how that works? It's open source, so I am sure I can go look. I think we want to go make a PR. We had some back and forth about this, Charles. CHARLES: I actually just [inaudible] we disagree. ROBERT: Yes. Charles opened a PR and one of his first commits in the PR had work in progress and the title had work in progress and we have this this Probot on our website and it was a blog post. You know, you make a couple more commits and you're further down, you move the work in progress in the title but the PR were still blocked because the first commit on a PR have work in progress in it. I think if it's the most recent commit or if it's in your PR title with work in progress, it should block but otherwise, it should not and Charles feels differently. CHARLES: I have about six commits and the very first one have WIP in the title or in the commit message and it blocked the whole thing but I kind of felt like it actually made me go back and I had to squash it down to two commits because I actually feel that your commit history should tell the story of the development, not like it should an absolute one-to-one journal of what happens but what you are intending. I actually felt that it could help me out because there's six commits that we're kind of all over the place and just kind of slapdash together have made me kind of go back, rethink it and tell a coherent story. I think it did me a service but it was not obvious. I definitely agree with that but I was like, "Why? Why were you still blocking?" ROBERT: Do I really [inaudible] admin privileges? BEX: I would say, I am friends with the creator of the web app. His name is Gregory Mantis and he is actually got a huge work in progress PR shifting work in progress over to using the Checks API and one of the features that he's using with the Checks API is essentially this mark as now work in progress button that will add the special line, like feel free to merge or something like that into your original PR description at the bottom. If that is there, the work in progress app will no longer be blocking. It's essentially like a hard override and honestly, that's the power at the Checks API versus the Statuses API. That's really exciting. ROBERT: Because I have seen the work in progress bot to get into a weird state, where I did remove the work in progress from the title but it didn't quite update and I'm still blocked. It's okay for me because I have admin privileges but other people on the team maybe not and they might be blocked from something that's actually work in progress. It's a lot like that hard override will be probably pretty helpful. BEX: Yeah, definitely. I think sometimes, there's some confusion with that just because of the way what perks work on GitHub and the way our pages are rendered, that you may need to refresh the page before you actually see it take effect. ROBERT: Right, yeah. Overall though, I love that bot. I go weekly, probably to the Probot apps listing and just go shopping. BEX: Wow. I'm actually the person who approves all the Probot apps to the listings so that's pretty motivating there. ROBERT: It's really nice. I am not even joking when I say shopping, I go through and I open up a bunch of tabs, I read through them, "Oh, this could be useful," that kind of thing. BEX: The first app you mentioned, which was like the one that requests more info is actually one that I built, so that was kind of funny. I guess you got that from the Probot apps too. ROBERT: Yup. That one, we definitely use on a couple of our organizations and repos. It has yelled at me a couple of times because of a blank PR. BEX: It yells at me all the time. I think I get yelled at more than people who are actually doing it wrong. ROBERT: I'm a little embarrassed like, "I should do better. I need to set an example." BEX: Definitely. ROBERT: Cool. I'm curious what both of your favorite Probot app is. This ought to be interesting. BRIAN: The app that I'm really impressed with so far, that I actually only use on a junk project at the moment, is the weekly digest one and it's mainly because I built something for this in my previous role at the company but then we shift it, which is basically go through every single repo. I worked at a company called Netlify previously and we had way too many repos to maintain... Oh, sorry, to keep track of and I was moving further and further away from the backend at the time so I was unable to keep up to date with all that was changing. I built a Lambda to watch Webhooks and then give me a digest of what was shipped like issues and PRs closed. It was way over-engineered and I never actually shipped that to actually make it work. But then the weekly digesting came out maybe a couple of weeks ago and it blew me away because I was like, "This is exactly what I needed," and I was trying to make it overly complicated through like a Lambda and like a bunch of Webhooks and this person, with only a few weeks, has the scaffolding of what I needed. That's the one thing I'm pretty excited about. It was already mentioned earlier too, as well. BEX: I guess, I would say one of my favorite ones is the unfurl a link app. I think that one it so simple but so nice. I don't know. I think having that unfurl link preview is just beautiful. Essentially what it does is it listens on issue comment creation or pull request comment creation or issues your pull request or whatever and read through the text or whatever was that issue or pull request and looks for links and then, essentially unfurls them so you can get a really nice preview of what you're going to. I think that's really beautiful and just so simple. ROBERT: Yeah. I love that one too. I have that added to all of our repos. BEX: It's so much nicer. Why would you not unfurl your links when you could unfurl your links? ROBERT: Exactly. CHARLES: I actually have a question. I think it's been touched on, probably at least twice throughout the conversation. I want to actually create a Probot, how do I actually go about deploying it? What does that look like? What does it look like to deploy and maintain it? BEX: We have a page on our docs about deployment and essentially the TL;DR is you can deploy it on any normal cloud hosting service that you wanted to deploy it. There are a few things you need to specify. For example, GitHub gives you a private key that you need to create your JWT and that private key means to be passed into your hosting service however you do that and then, there's a few bits of information that need to be pass in. We have pretty intense docs about it. Honestly, I'm not a deployment person. I usually try to let other people do that and I have never had a problem going through our docs and just getting it working immediately. BRIAN: It's also mentioned that there are examples like Heroku and Now and a couple of other ones. If you have a service that you already like, it's possible it's already in the docs, like steps to how to get that deployed. BEX: Yup and any other services are more than welcome to be added to the docs. Pull request are welcome. ROBERT: Sweet. It sounds like we need to set up a hack date to create a Probot, Charles. CHARLES: Seriously, my mind is brewing. ROBERT: I guess it's not directly related to GraphQL but there's something that I've always wanted to build. For prior history to everybody [inaudible], then the podcast, Brian and I used to work at a company called IZEA and one of the things that we built and I worked on a lot was we would create a collect metrics on people's social accounts that they're connected and do that and graph it over time. This idea came from when I was building up that feature all the way back in 2013, I want to graph the change in GitHub stars. Is there an API available for me to see like weekly GitHub stars or is that something that I still have to manually store and track? BEX: There's definitely an API endpoint to get the amount of stars and I don't see why you couldn't just do that on weekly basis and compare but I don't think there's any track that change API. ROBERT: Gotcha, like a history of it. I could do this by just stealing and looking at what the weekly digest Probot is doing because there is a change in stars section in there. I was just curious if there was now an API that was available. BRIAN: Yeah, that's more unlikely. I'm going to say no without looking at all the reference documentation. I think as far as that database, it's something you'd probably have to collect on your own but it's also a good candidate for a GitHub app, where you build a service that you can actually track stars once you've installed it and then if you want to monetize it, you can actually pay for private repo or whatever stuff like that, if you wanted to. But it sounds like a great opportunity to see this in the GitHub/Probot listings. BEX: I actually just look this app really quick in our docs because I was curious but apparently, you can receive the star creation timestamps. That could be doable through timestamp usage. ROBERT: Oh, and then I just kind of loop through back and build your graph in there. BEX: Yeah. ROBERT: Interesting. All right. Well, [inaudible] I was going to do today. BEX: Yeah. But I think it's exciting to bot the weekly digest and then what you could extract from that into stargazing is that Probot scheduler, which is essentially this all Probot extension we made that triggers a Webhook on a scheduled time period because right now, the way GitHub apps works are so centered around Webhooks. It can be difficult to find a way to trigger an action on something outside of a Webhook, like on a schedule basis. ROBERT: Yeah, that would be really helpful. I can definitely see how that would be a problem, if it's very, very central to reacting to Webhooks and events that happen on the system. BEX: Exactly. ROBERT: You're just hoping that somebody comes through and creates an event at a specific time. CHARLES: Can I ask you a question about, it's definitely on topic of extending GitHub but currently, just a question about, where the line is between what you can and cannot extend? You mentioned, for example in the rewrite of the WIP bot, being able to throw out a big button that says override this merge. Are there any plans to be able to actually extend the UI in novel ways? Everything there right now is happening with API calls, with I assume, UI elements that are related but the UI elements are static. If someone wants to put a novel piece of the UI, that button is going to require an extension of the GitHub UI by GitHub itself. Are there any plans to be able to, I know it's a dangerous waters, perhaps at a limited fashion at first but maybe more so, add different interactions and the actual application. BEX: I think this is actually the most exciting future of GitHub as a platform. In the past, GitHub APIs have only specifically supporting things that you can do through the command line or you can do through GitHub's UI itself. The Checks API introduced the very first non-integration specific UI element essentially and the merge button that I was referring to in WIP is exactly that. It's essentially this button that you can change the text of it to be whatever you want and you can listen on that action and then you can do as an integration or an app, anything that you want based on that. I think that's the most exciting direction for GitHub. Because if you look at Slack, Slack is a platform that has sort of really impressive integrations in that response. Your apps on Slack can really do all of these things, use custom UI elements, so I think the most exciting features for GitHub as a platform is all of this customization and giving the power to the apps. ROBERT: Yeah, that sounds an awesome way to be able to extend GitHub without having to try and throw the feature on to GitHub developers. BEX: Exactly. I feel that a lot of the struggle right now is that there aren't these nice ways of communicating via apps because I feel lot of the apps and bots end up just commenting on issues and pull requests and taking up a ton of screen real estate as a result and I just think that that's not the way that bot should ideally interact with the GitHub platform. They should have their own space to exist and that's the feature I'm most excited for. CHARLES: Yeah. I can think of having like progress bars for CI checks and your various appointments. It's too exciting. I'm glad. That's definitely the response I was hoping to hear. BEX: Yeah. We're excited for it too. ROBERT: Basically, you all have a massive community of a bunch of developers that would want to do this and are willing to get their hands dirty on it. Enabling that community is probably the root of all Probot is about. That's super awesome. BEX: Yup. CHARLES: That's a good place to end, because gosh, it's going to be so exciting to have the millions of developers on the planet, just like surgeon to the APIs that you're developing. BRIAN: One thing to add to that too, about the whole million developers, there's a number that's been thrown out from Stack Overflow and also, some other people who are saying like there's 50 million developers, there's 24 million developers. As far as GitHub, our public user number is 28 million, the cool thing about Probot and GitHub apps is that there's a good chance that all those people that are using GitHub today are not actually developers. They're like PMs or designers and what's really cool about this, like having interactions with that kind of platform in this way is that you can now enable all the non-developers to be able to interact with your GitHub repos and start bringing more designers and PMs onto to the GitHub platform to interact with the developers. ROBERT: That is an interesting point. That is awesome and something that I'm always looking for is a different ways to collaborate with non-developers on my team because... I don't know, developers tend to think everything is always centered around code but it's not. The shifting at work that are awesome, needs a lot of collaboration from non-devs and non-dev skills. That would be really interesting to see. I'm excited for that to play out. BRIAN: Yeah. There's a blog post that was published a month ago, I think about where the design team, design system teams rather, built the integration to Figma to update their icons effectively. I just posted that in the chat to look into but they also built this as a Probot app as well. ROBERT: That is awesome. BEX: Yeah, that one is super exciting. You would have the app comment, the diff between what the old icon versus what the new icon look like and it's just such a beautiful design change to be able to see that shift. ROBERT: Man, I'm happy that this is happening. The future seems super bright. Where can we direct people to get resources to contribute, to get involved and start really going at this? BEX: Basically, Probot.GitHub.io has all the Probot stuff, /app has all the listings for apps you can install today, /docs is where the docs are, if you want to get started and hopefully from there, we link up to the necessary things that you need to do. BRIAN: Also, what I mentioned too via Probot Slack channel, there's a Slack channel as well and they do a weekly call. I think, it's weekly or bi-weekly call to actually chat with the Probot community. If you have questions, you can actually bring your questions to the team. BEX: Yeah, we call it 'Office Hours' and it's once a week and it's under our community page, where we also have a link to our Slack. We have a link to another podcast we run and basically, how to get involved in the Probot community. ROBERT: Those are really helpful resources. I do remember seeing that Office Hours. It's on Thursdays, right? BEX: Yes. ROBERT: I was going to drop in for one and then, I actually forgot. Actually, it might be going on as we talk right now in this podcast. BEX: It starts in half an hour, I think. ROBERT: That's awesome. Cool. Well, thank you Brian and Bex for having a conversation about Probot. This is really awesome. Is there anything that you would like to plug for yourselves? How people can get in contact with you? BRIAN: Yeah, I am BdougieYO on Twitter. Everything you need to know about me is there and I am happy to say hello. I'm also helping with the GitHub developer program, which is sort of getting a soon-to-be announced rebranding. If you go to Develop.GitHub.com/Program and you want to have more conversation about the API and GitHub apps on the GitHub side, you can go there to sign up. BEX: And I am HiImBexo on Twitter. You can ping me in any Probot stuff. I'd be happy to look at any Probot code. I've been looking at it for a while now so I'm happy to do that. ROBERT: That's awesome. Thank you all for having a conversation with us. This was really fun. I'm so excited about everything you can do with Probot. This is a really fun project. I'm happy that this is happening and I will make a Probot in the future. CHARLES: I'm looking forward too. Robert has been excited for quite some time and he definitely talks a lot about it and now, I have some insight as to what -- ROBERT: It's happening, I'm telling you. Well. Thank you for being here and we are the Frontside. We build UI that you can stake your future on. We are specializing in JavaScript. We can build anything that you want throw at us. We do functional programming, React testing, Vue, anything in JavaScript, we specialize in. As always if you want to suggest anything for us to have on the podcast or talk about, you can reach out to us at Contact@Frontside.io and like I teased earlier in the podcast, next episode is going to be all about Microstates, the immutable and functional state container, composable model system that we've been building, it's controls as a brainchild for the past two years. That is next episode and I'm really excited about that. It's a really fun API and expressive to build models with. Thank you, Mandy for producing our podcast and we'll see you next episode.

In this episode, Chris Martin of Type Classes and Joe LaSala of The Frontside talk about blockchain development. Do you have opinions on this show? Want to hear about a specific topic in the future? Reach out to us at contact@frontside.io or on Twitter at @thefrontside. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. TRANSCRIPT: JOE: Hey, everybody. Welcome to Episode 104 of The Frontside Podcast. I'm Joe LaSala. I'm a developer here at the Frontside and I'm going to be hosting today's episode. Today we're going to be associating blockchains and other cryptographically secure technologies and everything that has to do with the web and the future of the web. We have with us Chris Martin and he's currently with Type Classes. What do you do over there, Chris? CHRIS: Our goal is to teach functional programming with Types, specifically with Haskell and a little bit Nix. We do subscription video service. JOE: There seems to be, I guess a bit of an overlap between people who are into functional programming and people who are involved in this new space that has opened up, this new web, I guess and that's something that I want to talk about based on a tweet that I saw you made recently. You mentioned that there's a big section of the Haskell community that is being drawn into whatever the hot ICO is at that moment there, something along those lines. CHRIS: Some of it are bitcoin people or something else but there's definitely a weird overlap that I can't fully explain. JOE: It seems like strange bedfellows, right? CHRIS: Well, there's a couple of things that make sense, which I think the distributed systems in cryptography are kind of these notoriously hard problems. I think when somebody wants to convince their boss that they really need to use Haskell for this problem, I think they can make a persuasive argument in this case. JOE: That's interesting. There's actually, a lot of technology around blockchains around bitcoins, specifically being written in Haskell. I didn't know they were technologically overlapped like that. I guess I just thought they were two very kind of passionate communities but you're saying that a lot of the bitcoin startups that you might see coming out in any given week are actually being written with an eye towards functional programming. Is that accurate? CHRIS: I don't know about bitcoin along this bit but I think some of the people who are working for banks and trying to develop their own sort of novel internal blockchains and stuff, I think those are the people who see this. Although in the case of banks, we don't necessarily see what's coming out of them, so we can't verify whether they're actually shipping things or not. JOE: Yeah. That means there's a lot to touch on there. I would agree with you on your initial sentiment, also just to extend to say that I think personally that both communities are really evangelical. Functional programmers, people who are into functional programming, for me it hasn't clicked yet and I know that it will come into my heart. I've asked functional programming to kind of where things are starting to fall into line where I'm certain to see the world in that way but for people who have seen the light fully, I'm sure believers once monads and functors kind of enter the conversation. They don't leave. It's similar like when bitcoin first started and everybody's running about the gold standard. Really, it's just nothing. It was hard to find resources on it that did the most of the amount of screaming. CHRIS: Yeah, you're absolutely right, that culturally, they're going to attract the same group of people or the people who are willing to adopt something that's not fully fleshed out yet, people who want to take what they believe and sit in this community and try and spread it to the rest of the world. I think it's the same kind of people. JOE: The early adoption, I think is something I can consider too. I guess it's a very risk-oriented group. CHRIS: Yeah, kind of. I mean, Haskell is pretty old, I guess but -- JOE: That's fair, yeah. CHRIS: -- Some of the changes that really make it, it great and usable lately are pretty [inaudible]. JOE: That's interesting. You mentioned this idea -- we kind of skipped over a little bit but thanks, having their own blockchains and that's something that I think that maybe people not actively following this space, which is I will say, a very hard space to keep up for those of us who are actively following it. But those who may just know blockchain through the name of an iced tea company changing or some sensational news article or what have you or just through bitcoin even, but I know that it's not the blockchain. It's not a singular blockchain. It's very easy to implement the fundamental structure. It's a linked list, essentially, with the kind of a cryptographic thing that keeps from breaking that link. Those links are inserting new history, I guess the further you go back. I guess people are even exploring different data structures like directed acyclic graphs and stuff and how that could be used to map other domains but the reality is it's a linked list and you can spend up as many of them as you want and you can mine blocks based on all this different criteria. Bitcoin is a proof of work associated with the minting of a new block and that's been a problem for them as they scale as a currency but it could be a history of anything and the minting of those blocks can be based on anything. You mentioned banks, the financial kind of sector is certainly interested in these smaller private chains but do you think there's a use for that consumer market as well? How do you think that your personal blockchain or set of blockchains might be a factor in the hobbyist of the futurist life? CHRIS: Oh, wow. That's a different question than I thought. [inaudible] where you're going with that -- JOE: Where do you think I was going? CHRIS: Well, we're talking about banks and so, the question is now everybody other than banks -- JOE: Well, it could be everybody, including banks too, however you want to take it. CHRIS: Yeah. There's a much harder question, I think of what in the world we're actually saying when we are talking about blockchain, right? The notion obviously has started with bitcoin but if what you want to do is bitcoin, then you should just be as in bitcoin, so what are we talking about similar bitcoin and the general phrase people have they like to throw in here is Byzantine fault tolerance. I'm talking about any kind of system that can have multiple participants. We're used to talking about clusters of computers and making systems that can work if one of them fails, if one of them just stops working but now, we're starting to talk about how do we make systems work if one of them gets hacked, then we still have some assurances that the whole system works together as a whole. JOE: Would you consider Byzantine fault tolerance to be the defining factor of a blockchain because I feel like there's the timestamping element that goes along with it. I feel like they're kind of part and parcel, right? CHRIS: Kind of but if you're not considering Byzantine faults, if you're only talking about systems where you have benign faults, which is a machine goes down sometimes, then timestamping isn't really a problem because we can just use NTP and we all have a pretty sensible idea of what time it is. JOE: Time specifically, even just like, I guess order. I always considered sequence to be a massive part of what a blockchain fundamentally was. You have the distributed aspect of the network that gives this sort of resilience to malicious intent but not only is it protected, I guess against demolition and malicious intent by this crowd strength but also just fundamentally through the cryptographic side of it, you can't go in and insert things that didn't happen. Once that order has been said, it's been written in stone, basically, right? Because the way I understood is there were papers coming out of Bell Labs in the early 90s and those two things set as approaches to this independently and it wasn't until the internet advance so we put them together and we're able to achieve Byzantine fault tolerance through that. Is that, I mean...? CHRIS: It does help a lot, I think to buck up and think about what the state of research was in the 90s because I think that's something that a lot of people in blockchain space kind of lose sight of. You have a whole lot of people writing papers now who didn't used to be academics until a couple of years ago. It was the early 90s where we started having faxes and we started having what later turned into what's kind of known as raft. Like you said, they solved the ordering problem. Even something as simple as what we call Lamport clocks which is you have sort of a virtual timestamps and as long as nobody's malicious, if you remove the timestamp forward, then we can all have something that resembles the deterministic forward flow of time. Then, that milestone that I was like to remind people of this in 1999 is when we had the paper practical Byzantine fault tolerance. JOE: That was '99. You're talking about the... was it Castro and --? CHRIS: Liskov, yeah. JOE: Okay. I didn't know it was '99. CHRIS: Interestingly, the same Liskov that the Liskov substitution principles named for, Barbara Liskov. It's also a distributed systems research. JOE: That's swell as well. I kind of heard the concept of Byzantine fault tolerance but I never read this paper. I'm also surprised to find that it didn't come out of that same period of the early 90s and it was as far as '99. I haven't read its entirety but I did fall asleep reading it last night. You mentioned this specifically, I guess, when we're talking today, as a paper that is important. It's the work that we're trying to do at... was it Hijro, I think? CHRIS: Yeah. JOE: Yeah, so what kind of work were you doing there and what is important to you, I guess about this paper specifically, when you look at all the research that went into priming the community for the space that we are now in? CHRIS: When I joined Hijro, I got kind of a difficult and nebulous mission, which was that everyone in and around that space that was trying to sell to banks was if you said the word blockchain, you could get your foot in the door because all the banks were looking at bitcoin and saying, "Well, look, this is clearly something that's going to be big and we don't want to be missing out, so we have to figure out how this applies to us." JOE: What year is this? They were working this in 2014-ish, is that right? CHRIS: '15 or '16, I think. The question was trying to figure out what aspect of it was actually what they wanted here. What Hijro is trying to sell them, the details aren't even important for this conversation but we need an interbank solution. We needed a ledger of accounts that 'we weren't a bank so we couldn't be the one holding everyone's money and keeping track of the flow of money in our network.' We were on something that the banks were truly in charge of but we didn't want to necessarily have our platform be owned by a particular bank. We wanted to be the sort of consortium of all of our partners. JOE: Consortium is a keystone word I think here, that we should definitely come back to that. CHRIS: Yeah and people talk about, if I use the word consortium blockchain, I think sometimes in contrast with the public blockchain, with the 'free anyone can join' blockchain. JOE: Yeah. I'm particularly fascinated by this concept. That is a term that is used. I can confirm this. But you're doing that pretty early then because I feel like that concept didn't make it out into, I guess the public understanding, until recently or maybe I'm just behind at times. CHRIS: Yeah, I guess so. I don't know. When I start working on this, I just spent a couple of months trying to read papers about what was in space and I guess, the only big name that was trying to do something like this was Tendermint. JOE: Tendermint? Interesting. CHRIS: You can pick out technologies like this because the magic number is always one-third. They can tolerate Byzantine failure up to one-third of the nodes. That was a theoretical result that was reached, just sort of the best you can do. Before BFT and then BFT is one of those solutions in that category and Tendermint does something similar. JOE: That, I guess is sort of the background to this paper and it's impacting your life. I guess, what is put forth in this paper is to solve for higher tolerance. Would that be the right way to put it? CHRIS: Did you say higher tolerance? JOE: Yes. You're talking about the Byzantine tolerance is 30%, right? With Tendermint? But you're saying that they're doing something similar to that's before in the paper? CHRIS: The most interesting thing to me, I think is probably, hopefully possible to convey concisely is the rationale behind the one-third number because that took a while for me to really appreciate but I think it really clicked when it did. One of the hardest intuitions to get people to break, I don't know, way of thinking to shift, I guess is convincing people that consensus is even a hard problem because I had this conversation a lot with people that'd say, "I've got this JavaScript library here, for instance that just lets me broadcast a message to all the nodes in a cluster, so why can I just do that?" Why can't we just use one at a time to do it and if I detected someone's trying to cheat, if I get two different messages from someone that are conflicting, maybe I can just ignore them. JOE: Not in finance. That's kind of ironic, I guess that you found it difficult to get people to come to a consensus about the importance of consensus. CHRIS: Right. The basic flow of all these things is we describe them as voting systems. We have voting rounds where each time, like you said the blockchain of the ledger or whatever it is, just a linked list, so the problem of using consensus build database is we're just going to iteratively try to vote or come to consensus on what the next block is. What the next ledger entry should be? Obviously, since we don't have a synchronized wall clock to go by, we have to assume messages can come in any order. We might all sort of speak up simultaneously and propose different blocks as the next one, at which point we have to start over and retry that. But furthermore, I can send different votes to different people if I'm trying to be malicious and that's where the tricky part comes on. The rationale for the one-third number, maybe I can just try to come around to that and say it directly then, is that when we take a vote for what the next block is going to be, we need the supermajority. We need two-thirds of the participants to have all said the same thing and the rationale for that is it's actually easier to think of it backwards. Rather than saying, two thirds of the total, what we say is, "If we're going to allow some fixed number of nodes to fail, to behave maliciously --" you know, we traditionally call that number 'F' in the paper, then what we say is we need 3F+1 total nodes to be participating. JOE: I didn't know that was sort of codified into how conflict is resolved on things like bitcoin during blockchain. It's inherent, I guess. CHRIS: No. This is the total opposite of what bitcoin and Ethereum are going to do. JOE: Because I always thought it was just going to be like a majority, I guess but what you are talking about is more like how the Senate would were to pass a resolution to the constitution, like it has to be an exceptional majority. I'm starting to understand why one-third, specifically. It's 3F+1, I guess. CHRIS: The reason is because for each vote, every time I look at the results of a vote, I have to be able to assume that some number that we called F, of the people that I've heard back from are trying to cheat me. It turns out I need to be sure that the majority of the votes that I've heard back are from people who are actually following the protocol correctly and not lying. We need to be tolerant to two kinds of failure. One is that a node simply goes down and we don't hear from them and we don't receive a vote from them and then the other kind of failure is the Byzantine failure, that they're not following protocol in some way. The reason I need 3F+1 nodes is because we need to be able to make progress, even if F of these number is we didn't hear from at all because they're down and then, I need 2F+1 votes because I need to take into account the possibility that some F of these votes were from cheaters and then we need to have more honest votes than lying votes. JOE: That's pretty profound. I definitely going to finish the rest of this paper while conscious later today. I guess we're a little off with regard to math at this point and it's when you said, you spent I guess a month or so just reading papers around the time you started with Hijro and I guess did you stop because I feel like I've read just more white papers than ever thought I would outside of the academic setting, just trying to keep pace with what's been going on, particularly with regard to the web. I don't if you're familiar with like IPFS but these sort of directed acyclic graph things are popping up all over the place and platforms are even now being built on this concept. I guess, Ethereum feels impractical in a lot of ways. These dime-a-dozen tutorials, when you started talking about the global computer that is Ethereum and the blockchain and it's going to change everything in the internet and you won't have to pay Comcast like some central authority or you just pay for each transactions. The reality of it is every time you do a write against a data store have, first of all, thousands of computers go and verify that and also, you don't want to store your information on a linked list. It's not feasible for storing large data structures and it becomes very expensive for the user and for the person, if you're maintaining a smart contract for the contract itself. These are volatile, all little points of value. It's impractical. CHRIS: It's definitely a cost that you don't want to incur. In all cases, just a confirmation time is a cost you don't want to incur. JOE: Absolutely. CHRIS: There is one nice thing that that you can do in some cases, which is that people is talking about the piggybacking on these blockchains like if I have a system and I just want some extra assurance to keep it honest, then I can do things like periodically publish a hash of my database onto something like bitcoin or Ethereum. JOE: Yeah. That actually happen with anyone in financial... They do publish stuff in the paper and this was before cryptographic ledgers but to basically prove that this was the state of something, I remembered seeing this somewhere, like there would be in financial news, like there'd be some crazy number or string at the top to verify what was on the string. CHRIS: Yes. Of course, the irony there is that you really don't need some kind of blockchain if you want to do that because the fact that we're doing that before the blockchain has existed and doubly, it's funny because the first block of the bitcoin blockchain, the genesis block includes in it, I think a New York Times headline, which was intended as proof that Satoshi or whoever didn't spend years mining bitcoin prior to releasing it. It's supposed to be a proof of the time of the first genesis actually was. It's funny that we are actually already had this verification system and what that demonstrates is sort of a principle of consensus that I like to talk about which is that as you increase the time scale, consensus becomes an easier and easier problem. I think the reason why something like newspaper headlines are reliable means of a timestamp is just mostly because they're big and slow, because there's only one every day. I think the whole challenge like you said of, how a lot of systems kind of boiled down to having the white paper for bitcoin refers it describes bitcoin as a distributed timestamp server, something along those lines. The reason why you need a new technology to do that, I think so that you could have timestamps that are every of couple minutes, rather than every 24 hours. JOE: That's a very interesting take on it. I guess, the more time there is, it is easier to reach a consensus. It's just interesting to think about. It's funny as humans like the longer time passes, the less reliable memory is, I guess, less reliable history as we conceive of it, I guess. It's different when you record something than the way that you hold in the brain that sometimes I wonder how much impact that's had on. It's a little ephemeral, I guess but it's interesting. CHRIS: Yeah. I guess my statement is limited to the on-scale where we can actually fit into memory. JOE: Right, that most of the times, it's the only relevant scale, I guess, like a blockchain doesn't have use outside of our use of it, inherent to it, so it's going to be seen through that lens, I guess of our use of it. I think it is kind of profound, a thing to think about that I definitely considered. You mentioned using blockchains as adding a little bit of... how do you put it? Like truthiness, I guess, we'll say. I know that's not how you put it but adding a little bit of security, maybe around something else but the reality is you can get away with that on a number of other levels. I think that's important and interesting to think about. There seems to be this trend now talking about a blockchain as part of a bigger picture or consortium blockchain or a consortia of blockchains, right? Because a consortia would be multiple and then a consortium would be... No, a consortium would be a single grouping, consortia would be multiple groups. Basically, going back to the problem you're trying to solve with Hijro, you have multiple banks and I believe eventually, I don't know if you work on it, there was a protocol that came out of that company to unify these blockchains, like a few of them. They demoed and everything. That, I think gives you some power with regard to access control but again, I guess, that's not a thing that you really need consensus for. So, where does it fit in? Aside from things like voting and transparent finance for maybe a political cause or in the case of bitcoin, just finance in general. In bitcoin, I feel like we got Mongo DB super hard in the sense that it just got applied to every domain and it applies to very, very few. CHRIS: My boss at Hijro, Lamar Wilson really like to say that people talked about blockchain like it was hot sauce and they sort of sprinkle it on everything to make it better. JOE: That's sad. CHRIS: I guess, two answer to that one. One of the places where it absolutely captivates people's imaginations too far and doesn't work and then places where it doesn't work, so I want to start with the first here because the biggest mistake that people make is that there was this notion of tokenization that came out of Ethereum, where anyone could make a smart contract that represented something and now, also that I can trade digitally. Just like it's money or some kind of digital asset, so people want to talk about putting your car, putting your house on the blockchain or selling it there. But it's just shocking how many times I had to remind people that if I make a smart contract that represents cars and I put my VIN number on it and I transfer you my car, at Ethereum contract in an exchange for a bitcoin, if I call the police and report my car stolen, they're not going to look at the Ethereum contract, right? JOE: Yeah. Man, you're really right. People don't think about that enough. If your car is in the blockchain, your car still on the block. CHRIS: What we had realize when we're selling solutions like this is that they're great for some reasons but you need actual legal agreements to underpin things when you actually make connection to the real world. The magic of bitcoin that can't really be replicated is that the coin actually didn't need a pinning to the real world because the thing bitcoin was running was itself. It just depended on hoping that people were going to find the coin and ledger valuable intrinsically and bitcoin never really purported to control things in the real world. JOE: I guess, definitely not in the paper. There are some place that can buy in from some very specific elements of society that sort of cemented its place as useful but we don't really need to go to that road, I guess. I don't know. You know, my roommate is a lawyer and we have this conversation often and I feel like if we go down law and cryptography, we're going to be talking for too long, where we are at currently. CHRIS: Right and that wasn't your question anyway. It was just what I respond to easiest because being a critic is always the easier thing to do. JOE: I can feel you there. CHRIS: One of the interesting things that I never even found too much about but I noticed this in a couple of passing references as I was reading stuff about Byzantine fault tolerance in general is that it seems to have some application in things like flight control systems and space ships because when you think about a computer that you're going to send into space, you have two things that Byzantine fault tolerance applies to directly. One is you need a lot of redundancy. You need these control systems, maybe you have a dozen things computing the same result because you can't replace the hardware when once you shot something to space. The second thing is once you've sent something outside the atmosphere, all of the sudden, you're being bombarded with a lot more cosmic rays than you were before. Now, you actually really do this idea that computers can fail, not just by stopping but by producing wrong results. All of a sudden, it becomes a lot more real because you actually have physics slipping a bit at your computers. JOE: I don't even think you have to go as far as space if you talk about just like a fleet of something, like self-trading cards. I suppose, in domain where there is an interplanetary file system, it's good to specify the planet we're talking about. Just having worked a little bit with robots in college, they lie all the time and they produce bad data constantly, so not even bad actors just incompetent actors, I guess could definitely... This is something that has to be, I guess on our minds as we move forward as the society that has more connected devices, which I think as much as I would love to have left this conversation off in outer space, I think bringing it around to the internet of things, which is sort of where this all began months and months ago is probably a good place to stop meandering through these cryptographic weeds. You can probably put a pin in this. I think we've been talking about for a while now, I guess and just kind of trying to see what it is and where the applications are. It's constantly changing and never clear, I think is the conclusion that I've come to. I don't know. I think, just kind of shooting the breeze about it is a fitting end to a series of Frontside engagements in this space, for the time being. CHRIS: I've seen several people try to tackle the space of how to stop relying on things like Google Drive to store our data because I think a lot of us have realized that we're tired of losing all of our family photos every time a hard drive dies but a lot of people are uncomfortable with trusting Google with everything. This to me seems like a perfect opportunity for people to start building redundant systems among their home and friends. JOE: Yeah, I completely agree. I'm actively trying to do exactly that right now. CHRIS: Oh, cool. And you don't necessarily want your cluster of machines that's running on all of your family's computers to be able to go down if your 10-year old get some virus, right? JOE: Right and also, there's definitely things that you want just within your home or even just within your section of the home. I guess you could layer chains, to kind of manage those interactions? CHRIS: Sure. I'm not exactly sure what you mean by layering chains. JOE: You could have consortia in this case. If you had like a hypervisor, almost like a control notice, essentially or some type of view from above of this situation, you could say, think of it as a family scenario. We have three different houses on this call that all belong to our immediate family and cousins and whatever and it's like, me and my siblings, we have information that we all want just within the siblings. We don't want Mom and Dad to know. We don't want the cousins to know, so you could basically use like a blockchain to kind of date access to data that is held within that consortium and then the consortia could communicate amongst each other. Only the pertinent information that they wanted to allow access to at that time and then, internally of course, you could have all these different mechanisms for how you actually store that data or how you actually serve it up. It's pretty complicated. CHRIS: Yeah, I think you made a lot of sense, though. JOE: Yeah, cool. I'm hoping so. There's been some work on it out of Microsoft, actually. CHRIS: On the files storage problem, specifically? JOE: I guess this is like with a smart home and kind of just teaching devices to cooperate and ask each other. If you had a section of connected devices that maybe were related to the workflow that a human being might go through to get groceries or something and then a section that's related to doing laundry or whatever, eventually, they would learn to communicate in the laundry grouping and could say, "Hey, grocery people. We're out of soup," or something like that. It's sort of almost happened organically, I guess. I had not actually felt like I found that paper. I've only found references to it. This is where I need to get something like academic access but that was interesting stuff. I don't know how I end up here, either. This has always happening when you're talking about this domain. Anyway -- CHRIS: People's ideas, it's just sort of generally inspiring concept so people is following you everywhere. JOE: Yeah, it's heartwarming. You know, with my ICT, I could look back and see exactly where I usually came from than [inaudible], the name of the farmer who grew with. I don't know. It'd be so much easier to fake most things, really when you think about it. On that note, I hope that this conversation was... I know that there was no JavaScript and I apologize for that but I hope that our audience finds it interesting on some level and I want to thank you for your time. Chris, it was really great talking to you and getting your take on these things as somebody who's been in the industry for a while. Definitely, some fascinating points to consider and definitely, I will finish that white paper, probably this evening because it's pretty cool. If anybody in the audience has anything they'd like to ask you about pertinent to this conversation or anything else, where is a good place to get a hold of you? CHRIS: For me, it's mostly Twitter. I'm @chris__martin. I'm also at Type Classes, if you want to talk to me about our new business. JOE: Cool. This has been Episode 104, I believe of The Frontside Podcast. Frontside, we're a consultancy based in Austin, Texas and we love writing elegant, sustainable code and just producing good stuff, really. I think that's what we're all about. I think, we can agree at least, that's a core tenet of what we do and if you would like us to produce some good stuff for you, feel free to get in touch with us. Also, feel free to reach out via email if you have any ideas for future topics or any feedback about this episode. I also want to thank Mandy for producing this episode. You can catch us next week, I believe for our talk with Brian Douglas on Probot and Robert will be hosting that one, as far as I know. Thank you all for your time and feel free to reach out. This has been The Frontside Podcast. I'm Joe LaSala. Chris Martin, thank you for joining us and have a good day, everybody.