Making Gatsby easy to understand with Laurie Barth

About Laurie Barth
Laurie Barth, is a staff software engineer at Gatsby. Laurie is also a vivid conference speaker, tech blogger, and egghead instructor.

Read the whole episode "Making Gatsby easy to understand with Laurie Barth" (Transcript)

[Improve this transcript on Github.]

Michaela: [00:00:00] Hello and welcome to the software engineering unlocked podcast. I'm your host, Dr. McKayla. And today I have the pleasure to talk to Laurie Barth also known as laurieontech on Twitter. Laurie is a staff engineer at Gatsby where she works on the learning team. Laurie is also an egghead
instructor and a vivid conference speaker. I love following your content on Twitter, where Laurie always asks many thought provoking questions and helps people increase and reflect on their skills as a leader. So thank you, Laura, for being on my show today.

Laurie: [00:00:33] Yeah, I'm excited to be here,

Michaela: [00:00:35] Laurie. I would like to start with your role at Gatsby. Um, I think you recently transitioned to Gatsby. What do you do on your day to day work? What does it look like on a day to day basis to work there?

Laurie: [00:00:48] Yeah, So I started here in October. No day is the same. I think kind of all software engineers can say that in one way or another. But my job is really to teach in whatever form that may take it, to help people understand how to use Gatsby. And that means every day is a little bit different. Some days I'm collaborating with teammates. Some days I'm writing documentations. Some days I'm prepping for a webinar or a talk. Um, other days we're, you know, kind of in the planning stages and looking at what do we want to do next? How do we want to be innovative? I think a lot of people kind of know Gatsby and our documentation experience and our learning experience is something that's a little bit unique. We put a lot of focus on it and we spend a lot of time on it. And so we're always looking for ways to kind of change our approach and improve it and make it a learning tool that can be helpful to all kinds of different people who kind of understand and get their knowledge in different ways. So, yeah, that's my, my day to day is there is no day to day. I wake up, I go to my office in my house. I sit down at my computer. Yeah. Say, okay, what am I tackling this morning?

Michaela: [00:02:01] Okay. Yeah, sounds really exciting. And would you describe your role a little bit like a developer relations or a developer advocacy role as well? It sounds for me a little bit like that.

Laurie: [00:02:13] Um, so yeah, there are some similarities, there are certainly some overlap in terms of the fact that, you know, we're an open source project. And so, um, every time I'm reviewing someone's PR, Um, or maintaining the project or the docs, I'm interacting with the community, my goal is always to make sure that our docs and our learning experience is something that works for developers because developers are our users. But it also diverges in some other ways in that, you know, it's not my job to say, Um, you know, be traveling all the time or to spend all of my time on Twitter, even though jokingly, it may seem like it. Um, it's, it's not necessarily my job to do all of that interaction. I do it because I enjoy it. Uh, but my focus is a little bit more laser focused on specifically teaching and learning instead of, um, advocating for Gatsby as a platform or a product.

Michaela: [00:03:15] Okay. So you said that the learning experience is different or unique and well different than others. So what would you say makes it unique? What's different there.

Laurie: [00:03:27] Yeah. Um, so. So if you go to the Gatsby documentation site, you'll see. I mean, it's all on gatsbyjs.org for people who don't know, you'll see a bunch of different tabs. And one of them that a lot of people talk about is that we have a tutorial tab and under our tutorial, you do kind of a soup to nuts walk through of how to put together a Gatsby site with all kinds of different bells and whistles. And, um, I saw this great quote that Dan Abramov tweeted yesterday that was, um, "Assume zero knowledge and infinite intelligence". And so that's exactly what we do. We believe that absolutely everyone has the capacity to learn this. We try and make it as straightforward as possible, but we also start from the very basics of what you need to know. We talk about how to install node on your computer. Um, We talk about how to set up, get, or install that if you don't have it, because we're lowering the barrier to entry for creating performance sites that have a great ecosystem of plugins and all of these other things, but lowering that barrier to entry means meeting people at whatever level they're coming into the process. So if they're already a software engineer, they may start at step one of the tutorial. Um, if they're already someone who knows react, they may start a little bit later, but it's about making sure that everyone's experience is covered, um, in our learning tools.

Michaela: [00:04:58] Yeah. I really like this philosophy. That resonates a lot. Yeah. Because sometimes if you're starting out, I actually made the choice last year to use Hugo, uh, for one of my sites, just to try it out. Right. And if you are really new to something you're really. You're dependent on the ecosystem that's around. Right. So you have to decide whether or not the documentation is good enough that you can invest in that technology. Right. So one of my questions is, do you see that from the adoption patterns right. There are different groups of people adopting Gatsby than other, you know, other static site generators.

Laurie: [00:05:39] Yeah. So I can't necessarily say it from a, from a data driven perspective. I've seen various sets of data, but nothing that I could kind of recall off the top of my head, but I can, from an anecdotal point of view, say that we hear a lot about how our documentation helps people onboard a lot faster. We hear a lot from people who say getting started with Gatsby was easy. And that's our goal. And so I would hope and assume that that has some impact on adoption of the technology. Uh, but I don't want to kind of take my anecdotal evidence and turn that into to hard data. Um, I know there are other people at the company who probably do have that data and can point out and say, yes, Laurie, that's a thing. But it’s nothing that I can kind of like cite right now, so I wouldn’t want to speak out of turn.

Michaela: [00:06:27] Yeah, sure. Um, so, and actually, um, because I'm following you on Twitter, I know that you said that you actually switched from architectural role, right. Being a software architect to actively developing software again, and that somehow this changed. It probably felt a little bit rusty coming back to developing, but then you said, well, it actually it's changed how I see the things and I'm, you're even better developer right now. Is that, Is that correct? What I got out from your teeth or was the experience different?

Laurie: [00:06:57] Yeah, it's, it's a slightly more complicated story. I like your simplified version. Um, yeah, complicated story is that my, my previous role to working at Gatsby was as a consultant and that meant that kind of my clients changed and my projects changed and I spent a lot of time doing architecture. Um, and one of the last clients I worked with while I was still in that role. Um, required me to go back and be a lead engineer and, um, work on a Vue project. And I really enjoyed that. And that's what the blog posts that you're thinking of. Um, I believe it's how, uh, being a software architect made me a better coder. Um, this was that blog post blog post came out of, um, I would say in my role at Gatsby, yes, I am still coding. Yes. I'm doing a lot of writing. Um, but some days I still feel like I do a fair amount of architecture and it's not necessarily software architecture, it's, um, information architecture in deciding kind of how are we going to structure this documentation experience or this learning experience for other people. And then if you know, I'm doing a webinar and I have to make a repository, then I go back and put on my software architecture hat.

Michaela: [00:08:12] Yeah. I mean, especially with blog posts and I think this is probably similar to, you know, providing documentation and learning
experience. I started writing something, there comes, you know, more and more things and now i am getting down a rabbit hole. And then later on, I decide, well, actually I have to restructure the whole thing again. Right. Which is very similar to architecture. Right. Where you have to think, okay, which parts are actually belonging together? You know, how can you actually make that? Not. You know, the monster gigantic blog posts ever that nobody wants to read and still it's self contained and things like that. Right. Um, so yeah, uh,

Laurie: [00:08:49] not a science.

Michaela: [00:08:51] Yeah. Well, some of my blog posts that I wrote, I think. Two months ago, three months ago, I go and say, wow, wow, this is way too long. But at that point it was like, no, it cannot be shorter. Cannot be shorter.

Laurie: [00:09:07] One of my first blog post that, um, was more technically heavy, um, included a lot of code samples was actually on Gatsby and it was three parts. I did it in three separate blog posts. And it was about moving my personal site over from Jekyll to Gatsby. Um, and that. The process of doing that, the process of writing that taught me a whole lot. One of those blog posts was adapted into a tutorial that currently exists something gatsby site like, it probably led to the job I have now, you know, super, super impactful. But I looked back at it the other day. Cause I had to look through it for something, the tutorial that was a consequence of that blog post. And I was like, Oh God, I need to rewrite this. This is not good. So, you know, you evolve, you get a lot better. Exactly.

Michaela: [00:09:55] Yeah. Yeah, that's true. So you're already hinted a little bit that this blog post might have impacted you, how you get to gatsby, how you got that role. Can you tell me a little bit about how you started working at Gatsby and you know, what was your interview process like as well?

Laurie: [00:10:16] Yeah. Um, so, so they had an opening, they just posted an opening for Staff software engineer, um, for the learning team. And at the time I had been doing a lot content creation. I was a new egghead instructor. I was writing a blog post every week. I was doing a lot of speaking. Um, so kind of what most people would consider kind of traditional dev-rel activities, but I had much more of a. a specific learning, bent to it. Um, for me, I had never been representing a company and then hearing from developers and bringing that information back to a product team, which is what a lot of dev-rel people are doing. Um, my experience had just been, I was working for a consulting company. I was learning a lot, working on a lot of different projects and I wanted to be able to teach people the things that I had learned. Um, so I applied to the job. Um, after talking to a handful of people on the team and said, Hey, you know, tell me more about this job will I only ever be writing the answer is no. Um, the days you get to write are the good days that you have focused on, cause you don't have a million other things to do. Um, the interview process was honestly pretty, pretty extensive. Um, and I tend to people who follow me on Twitter, know that. I'm anti arduous interview processes. I don't like whiteboarding. Um, I think algorithms are kind of a ridiculous benchmark. Um, so it's, it says something that I went through a set of interviews that were pretty long. Um, but none of them were any of those things. So my first round was just a quick conversation about the job in my experience. My second round, uh, was I think an hour long conversation with my now boss, Marcy Sutton, who people may have seen, um, She's awesome. You should follow her and just love everything she does. Cause it's amazing. And then my next round was to write a short blog post based on there were three different prompts I could choose from that felt very natural to me. It's very much like the work that I do now on the job, then I had another call that was a pairing session, but the pairing session was about, you know, working with GitHub and reviewing PRS and, you know, being an open source maintainer. Um, and then the last, the last round was a paid project. And again, there were three different things I could pick from to do. And so if it's five rounds, like if you tally all that out, that's a lot of rounds, but they do certain things, well they pay you to do the kind of take home pieces of it. They time box them and they want you to actually fit in that time box. Um, but they also give you flexibility about when you're using your time for that. But everything I did in that interview, was directly related to work I would do on the job. And for me, that was the benchmark.

Michaela: [00:13:07] And so when you say they time boxed, how, how long does such a take home exercise or a project take?

Laurie: [00:13:12] Yeah, I don't specifically remember the blog post one, but I remember the final project they said, please spend no more than I can't remember if it was two or four hours. Um, but, but it was specific timebox to that. And I, and I held myself to that, you know, I turned into something that wasn't perfect and polished, but I spent the time I was going to spend on it. Um, and, and I want it to be, I want it to be honest about that, because I think when you're going through an interview process, it's incredibly tempting to want to get everything right. And spend extra time if you have it and then kind of say, Oh, I only spent this much time and like sneak in, but that's not a realistic view of what you can contribute and get done. And you don't want them to come in with an inflated view of that, because then you're going to spend, you know, 60 hours a week trying to do what they think you can do in 40 hours. And nobody wants that that's recipe for burnout.

Michaela: [00:14:09] Yeah. I think also, I mean, if you're, if you are a little bit further in your career, right. And maybe you're also a little bit more self confident, then the interview process is also for you to evaluate the company as well. Right. So especially, I think if you have been burned already in one of your jobs, then you get a little bit more cautious about that. And so if I get a take home project, right, and they say spend not more than four hours and I spent four hours and they see you well it's way, uh, not enough time right then this tells me something, right? Like I had a manager that always overestimated everything right or underestimated what it takes. And that's really annoying and frustrating to work in that environment. Right. It's like, who wants that person that cannot, you know, realistically judge, how long something takes right. A couple of hours and you have done it. Right. And I think, yeah, so. I think it's good that you did that. Yeah. So, well, I saw that and now you're an open source maintainer, right. And I think this also means that you have to look through code reviews. You have to look through. For requests or, or merge requests. So, um, people are sending in their patches to the software and you have to review them and decide, you know, is that work good enough to be integrated? What should be changed? And, um, what do you think what's the most challenging for you in that role?

Laurie: [00:15:41] It's a firehouse. Most people who contribute don't necessarily realize that reviewing these PRS are not the only thing we do every day. And so it's perfectly reasonable. I know this because I was this person, right. Like I put in my tutorial on Gatsby's image and I didn't hear back in, you know, 24 hours or whatever it was. And I was like, Oh, I guess they don't like it. Because I just had no concept of the number of PR is the people we're putting in. And the amount of time it takes to review this stuff, especially something as large as a tutorial, I was completely oblivious to that. And now from the other side, I understand it's so much better. I'm sitting there and I'm thinking, you know, it takes a really long time to review some of these technically complex and extensive write ups or code changes. And so the hardest part is, is trying to be timely with, with reviews as much as possible. I mean, even with the team members, we have both on learning and on core, they're stuff that just, you know, it, it takes a little while. So to anyone out there who has ever contributed, we absolutely value what we do, what you've, you know, taking the time to give to us. We appreciate it so, so much. Um, We're sorry if it, if it doesn't get done and you know, a day or two, when it takes a little bit longer, we try so hard to keep that time down, but it's just not always possible. So that, that would be the hardest part I would say.

Michaela: [00:17:13] And so coming back to code reviews because it's one of my favorite topics. I think it's a very interesting topic because of, well, the technical aspects and the social aspects. Some people don't like, or dislike contributes because they see them as gatekeeping or, you know, hindering people to contribute and things like that. What's your view on it. And how do you do them?

Laurie: [00:17:38] Yeah. So code reviews they're, they're like anything else if done Well, they can be great if done poorly, they can be horrible and bad for your self esteem and, um, kind of, abusive in some ways. So code reviews are for us are important because they're how we vet stuff that's coming into the project. It's open source. We want to make sure we're not including stuff. That's gonna break, um, behavior for other people. We want to make sure that it's going to be useful to not just the person who wrote it or produced it. So we have standards. We have the style guide, we have other stuff that we kind of point people to that ensures consistency across the board. When it comes to making individual choices, we're focused on more on behavior of the code, testing of the code or the writing, instead of did you write this the way I would write this as long as there aren't any serious performance impacts and we think that it is maintainable over time. It's not ticky tack. I think that's where people get frustrated with code reviews and they feel like they go wrong because they're saying, you know, you should have used reduce instead of a for loop here. And it's like, There's an, it's an arbitrary choice based on the person doing the review, instead of something that's either documented as a policy that exists in that code base or something that actually has a measured reason for doing it like performance or accessibility. When it comes to tone I think that's the other thing people really miss. Uh, they talk to, to the person who's code being reviewed and they're dismissive or short or, um, derogatory or any number of other kind of frustrating and upsetting things. So Gatsby has the concept of, you belong here and we try and be incredibly empathetic and kind and communicative with all of our contributors are we are so thankful for their time and their energy and the value that they provide to us just because they want to. So our tone is very important to us and we try very, very hard to both be gracious and to note that any kind of edits are not criticism, it's just, there's a reason for it, whether it be the style guide or, um, impacts elsewhere in the, in the system. So we try not to have arbitrary commentary and I think that helps a lot.

Michaela: [00:20:04] Yeah, I think, and often people also say, Oh, code reviews about the code, not a person. Right. Most of the things are about the person, right? So the feedback that you're writing isn't about the code, the code cannot change itself. So a person will read it and they will understand it in their way and interpret it. Right. And there's so much human issues that are coming up here that I think. We have to put the effort in to understand what's actually happening here. And then as you said, have enough empathy and have enough, put enough thoughts, you know, to, to give the right feedback. Something that I really liked as well is on your Twitter profile. You have a pinned tweet and it says, I'm going to read it now, right? "If you are a lead in any capacity, your primary job is no longer to be the best coder in the room. Your job is to invest in learning the skills you need to effectively communicate and grow those. You lead. The words have the potential to sit with people for years, act accordingly. And I think it has, I don't know, more than 5,000 hearts and likes and things like that. Right. So the first thing that comes to my mind is are there any words that sit with you for several years? Is there something that triggered that very thing? Well, why do you have this word still in my head?

Laurie: [00:21:21] Yeah. So I can specifically say that, um, the trigger for writing that tweet was seeing multiple people talk about feedback from colleagues or superiors, um, that, that didn't sit well with them and had been very upsetting for them and kind of focusing on the negative, even if anything else is positive, if everything else is positive and I was You know, thinking through that. And I was like, you know, it's because we don't, we don't give our leaders the skills, um, in communication and the training and communication, because we continue to focus on technology as the only skillset that matters because we promote people because they're really good coders. They're the best coder in the room. And now they should be a manager when really those are quite different skill sets. And the best coder in the room may be the person who should be manager, but they should get that job because if they're. Potential in management skills, not their code skills. A lot of people disagreed with that tweet. Interestingly enough, they were like, I won't respect, you know, a leader who doesn't code better than I do. Yeah. I'm like, okay, well, that's your prerogative. Um, I think we can all say that something negative that has been said to us, you know, I speak a lot and there are conferences that give you feedback and it's from attendees and the attendees get to be anonymous. And so they'll put comments and sometimes their, sometimes their comments can be very pointed. And it's not about the content of what I spoke about. It's about me as a human it's kind of that code review concept. Right. Um, so I had someone just recently say I was obnoxious. That I was obnoxious speaker and every other comment was glowing and, you know, very kind and I felt really, really good and that was like one of the last comments on the list. And it's the only one I thought about for two days, the only one I thought about. And so I think, um, that that can axe absolutely. Um, be telegraphed to a situation you could see happening with a manager or a leader where that's all you're going to hear. And so you need to be intentional. You need to think about how you're giving that feedback, um, how you are, uh, being critical if you need to be, but in a way that's actionable and constructive instead of just pointing out something, someone did wrong.

Michaela: [00:23:34] So how do you deal with that? How, how do you shake that off? If somebody says you're obnoxious, I mean,

Laurie: [00:23:41] um, I don't know that there's any one right answer. Um, I think in the case of, you know, getting that a speaker feedback, I would love organizers to pay more attention to that and filter their feedback. I don't think they need to be sending those comments out without filtering them first, especially for people who haven't been speaking, as long as I have, if that's their first experience that might deter them from speaking again. And we don't want that. There is a very clear line between feedback that you can actually do something about, and that is constructive and feedback that is just dismissive. So it doesn't feel good to get feedback where someone says, Hey, you explained this thing wrong. You use this word and it's really that word like that doesn't feel great, but it's at least actionable. You can change that for next time. You can improve. If someone says your voice is shrieky, there's nothing you can do about that. And it just feels bad. And. There's no real solution to that. Some people don't even give it a second thought, but other people linger on that. I think a lot of people linger on that. Yeah. And the best thing I can say to you is if you're looking for feedback, if you're looking for ways to improve, ask people, you trust, ask people to review your code that you know, will give you the time and the attention and the thoughtfulness that you deserve. Same with, uh, reviewing your blog posts or a talk you're giving and try not to look at, or even listen to the anonymous feedback. Those people don't necessarily have the time or attention or incentive to be as thoughtful or intentional with what they're saying.

Michaela: [00:25:22] Yeah. I like also what you said about the conferences, right? I mean, this is a community that's actually moderated, right? So there are conference organizers and It's their responsibility to moderate the feedback. Why would you get a feedback like that? I mean, maybe they shouldn't censor it. So if you really wanted, they could send it to you. But as a default, everything, that's just, you know, hater comments. I would, I would filter it out and say, which is creates a toxic environment and the same for communities. I have been part of several communities online now, and I think it really depends on. You know, the moderation of the communities. And I think if it starts off with, with, with a good moderation, so maybe there are one, two, three people that really take care of, you know, keeping the trolls out and, you know, setting the tone, then people understand what's accepted or not, and it was start to self regulate and those are wonderful places to be in. And then you see those communities that don't have such a moderation. And they really got, you know, the can be super toxic places. Um, That, that I, yeah. I don't know why people, I think that most of the time, those places are for all the people that want to be toxic. Hackernews, for example, I mean, how often do I go there? and then they are tearing apart a blog post, but they come and say, Oh, I didn't read the blog post, but you know, it's complete full of shit. Like you didn't read it. I mean, you start your whole conversation. But I didn't read it and then you're ripping it apart. It's how, so it must be really, they must be outliving something that makes them feel good. something like that.

Laurie: [00:27:12] Yeah, Um, I said, you know, who, who just let it roll off their backs. I think a lot of the people who speak that way and, um, kind of let their opinions flow no matter what. If someone said it back to them, they wouldn't care. Um, so it's not always true. Right? Some of those people, um, would be deeply affected by it. But, uh, for people who, you know, don't really care about other people's opinions, um, or don't take feedback seriously. Cause they're so overly confident in themselves that you know, that that person couldn't possibly be right. They don't really give it a second thought because if you show, um, If you show hurt as to something they say, they're like, well, you know, you shouldn't be able, you shouldn't do this job because if you can't take it, um, you need to be able to just move forward and have enough confidence in yourself. And so it's different mindsets people whose personality types are different. It's people whose, uh, levels of empathy are very different. And. You know, I can't say I agree with their view, but, but there's definitely a group of people out there who just, you know, you can say whatever you want to them, they'll say whatever they want to you. And they don't think words matter.

Michaela: [00:28:31] Well, I would like to bring that conversation back to the workplace because well, the internet is somehow unlimited, right? So everybody can in some capacity contribute there, but the workplace is a little bit more, it's a more closed environment. So people are actually hired into that environment, you know? So there's a little bit of do we actually belong together? How do we work together? So I think it's a, it's a more. It's a different group of people. And also they are face to face. There they are in real life, or if they're remote right in real chat or whatever. Um, but there's this concept of psychological safety and that describes if people on the team can take risks, interpersonal risks, and what are not the dare to do that. And if they will face consequences for that, right. Let's for example, say, Your boss tells you something presents a project is super energized and thinks that's the best thing ever. And then you listen to it. Do you really give it a listen? And. After an hour listening, you still, you don't understand why you don't understand the motivation. You think it's strategically not a valid next stop, something like that. And then the question becomes, are you able to raise your concern? Right. So, and that's somehow what psychological safety is about. So if you feel safe, then you will probably say, listen, um, can you explain to me again, what's your main, the idea behind that? And if you're not, you're not able to say that. Have you thought about that concept and you work actively with your team on that in some way?

Laurie: [00:30:10] Yes. So I'm a big part of psychological safety is your personal situation and how much safety you have in your job security. And that, that has a lot of different layers. So for example, if you are living paycheck to paycheck and, um, don't have a lot of economic safety. Then losing your job is incredibly impactful. And therefore, if you fear losing your job for speaking out your psychological safety is nonexistent. And, you know, even if you think you could say whatever you wanted at your job, you're probably less likely to, because you can't afford to be without them. You check the same goes for specifically in minoritized groups. Um, if you do not have. Legal protection because you are, you, you know, identify a certain way, sexual orientation. Yeah. And otherwise, um, then you do not tend to have that same level of psychological safety and it, it doesn't really, it's not completely controlled by, by your workplace. People need to be more conscious and make better choices about being overly safe in their environment in making it explicitly clear that any team member can feel comfortable speaking out about anything, any way they like you don't have to be the person who stands up in a meeting and says to your boss, no, I don't agree with that. Are there ways to give anonymous feedback? Are there ways to skip a level and talk to your manager's manager? If that is something you feel needs to happen, do you have other coworkers that you can vent to or get support from, um, who will listen to you and actually do something about it. Can they take your concerns with their name on it if you don't feel comfortable? So there's a whole lot of layers there. I think in, in most cases I've had psychological safety in my roles because I don't have a lot of risk if I were to lose my job tomorrow. Theoretically, I could go find a new one and it wouldn't be, you know, incredibly challenging. It might be, I don't know, but, but in the abstract it doesn't feel like it would be at this point in my career. Um, so I do not I'm, you know, kind of thing, staff engineer on a team, I am not the manager of the team, but our team has just started to form up. We have now all of our team members and amazingly cool group of people, we think that's going to be a conversation that we have and something that we figure out. As we move forward because we're a relatively new team, we're still learning each other and figuring stuff out. And it's just, it's a super important concept and it's, it's important to make sure everyone feels comfortable and, you know, in the abstract, I would like to say, yeah, I think we're doing great. But at the same time, you know, we haven't had something that's super tense yet. And that's when you get evidence of whether what you're doing is working or if you need to adjust.

Michaela: [00:33:07] Yeah. And that's exactly what I wanted to say because only in the moment that you needed then you realize you don't have it right. Or you have it, um, before it's, it's so abstract that you Oh yeah. I feel comfortable raising my concerns, but then if you're in a situation, right. And it's really about, you know, whatever, something that you haven't expected. You know. Yeah. I really like your view on some of those things are really not part of your workplace. Right. There are something about the person about the individual themselves, right. That they bring with in the workplace. I like also the ideas of, you know, having some strategical way around that. Right. So how can you give feedback anonymously, for example? I think that's a very good question. So. You also talked about being an egghead instructor. And I would like to understand a little bit more what that really means. What is an
egghead instructor? What do you do? And, um, yeah. And how do you prepare those courses and, you know, things like that.

Laurie: [00:34:10] Yeah.So, um, it had his, uh, Platform for learning. And it's a video platform. Um, and I became an instructor this past summer. Joel hooks, one of the cofounders sent me a message on Twitter and he said, Hey, Lori, do you want to be an instructor? And that's how I became an instructor. Um, he had read my blog posts and thought some of them would make good videos is my understanding of it at least. Um, it's, it's a really fun thing to do. Um, I do not learn particularly well from videos, interestingly, but I have gotten so much feedback from people who had previously read my blog posts and went to watch the videos and said, Oh, I found the video is so valuable. That's the way I learned best. And that was my goal to give kind of multi-modality to the way that people could learn from the things that I was trying to teach.

Michaela: [00:34: 57] Very cool.

Laurie: [00:34:59] Yeah. In terms of topics, um, my course was kind of born out of the fact that I've used angular and I've used react and I've used Vue. And I had recently been working on a project with Vue and I was kind of blown away by how great Vue router was. So I made a course about it. Um, Most of my other stuff is one off lessons. So lots of JavaScript syntax, some stuff about working with Vue code. Um, some stuff about RXJS and specific operators. Maybe even some CSS in there I'd have to go back, but it's, it's normally based on what blog posts I'm writing or what new fun trick I just learned that I didn't know about before.

Michaela: [00:35:42] So about you are completely free in deciding to do another video of whatever interests you. What do you think is valuable for the audience?

Laurie: [00:35:50] Whatever I want to do, I can do.

Michaela: [00:35:53] Sure. Cool. That's really cool. Yeah. I actually learned really good with video. I know nowadays always go to YouTube first. I search there. If anybody has done it, I mean, it depends on the video, right? Some of them are just not on a level that you can actually, you know, follow it. And then that really is annoying. But if it's a serious, for example, Hugo Hugo thing, I followed. I followed Mike, I think it's Mike. Um, and Mike really explains very well how to set up a hugo site. And so I went, you know, video per video and I was like, well, that's, that's exactly my style. I like that.

Laurie: [00:36:33] And egghead, has a very particular style. Um, you'll see other video platforms that exist and, you know, they kind of do a set up and they say, Hey, this is what we're going to talk about today. And then this is what we're going to talk about in this section. And then start talking about what we're going to talk about. Um, and so you get 10 minute and send and you're like, wait, the silhouette answered my question. So again, it's very succinct and to the point, and that works well for my teaching style. So I just, you know, I don't prime, anything you can read the description and the title, um, there's a little kind of code pen or code sandbox that will show you what it was that I did. Um, otherwise I'm diving in, I'm starting to code finishing it and you know, most of my videos are Less than a minute. I mean, it's really fast. It's quick and dirty.

Michaela: [00:37:23] Yeah, I think I like that. Yeah. More so for example, I also do things on Pluralsight, but exactly. That's what I don't like is that you're, you know, you're your click somewhere and then, you know, it's the introduction or the introduction and I'm like, but at least you can skip it. So, and you can, you know, make two X or something, which I always also do. But, um, Yeah. I like also more, if it's to the point in unit you're diving in right there. And, uh, but it, as you said at the beginning, um, when we were talking about everything should be, there should be self-contained. I also don't want to be left alone, you know, floating in the universe. Because I don't understand where something comes, you know, some resources suddenly appear on your machine and I have no idea how you get them. Um, so it should be self complained, but, uh, yeah, to the point, I think that's, that's what I like.

Laurie: [00:38:13] Yeah, for sure.

Michaela: [00:38:15] Well, one of the things that I wanted to talk with you is about speaking, because I'm also getting back into speaking this year. Just a few conferences because I have two kids, so I'm not going to fly around, uh, every month. Uh, but I see that you are almost never at home. At least it looks like that. If I look at your speaking website, I'm like, okay, Laurie lives around the globe.

Laurie: [00:38:41] I live in a hotel.

Michaela: [00:38:43] Mmm. Yeah. How do you balance speaking with your day to day work at Gatsby? and your speaking engagement part of your work at Gatsby? Or how does that work?

Laurie: [00:38:52] Yeah, so, um, a lot of the speaking engagements
you'll see is actually last year. Um, and, and last year was a year where I applied everywhere. I was interested in doing more speaking than I'd done before. And it went better than I expected. And by the end of the year, I was getting a lot of acceptances and I still hadn't learned the word. No. Um, I didn't know that you could get accepted somewhere and turn them down. That was not a concept I grasped. I was like, why would I, I do that? You know, I applied. So obviously I should say yes, well, I applied without the context that I'd be at three other places in the same month. So this year is going to be a little bit different. I'm scaling back quite a bit. The goal is to not be, um, more than one place in any given month. Including personal travel. There are certain months where I'm in two places, but I have the entirety of 2020 for me is basically, and book it out and scoped out. Um, I think we benefit from it as a company in the sense that I get to go out and talk to people who use Gatsby and learn from them and get feedback from them directly. That's kind of what a lot of Debra that advocates are looking to do. They're looking to hear from users and customers in that space. Um, for me, it's an opportunity to teach. It's an opportunity to see what is effective in my teaching. Kind of in a real world scenario, see people's facial expressions and engagement and see what's working and what's not working. And it's something I enjoy doing. You know, I work remote. I work from my house, so I like to get out every now and again, but there's definitely, definitely a balance that needs to be struck there. And depending on what your job is, sometimes, you know, it is your job to go out and travel around the world. Sometimes that's a piece of your job. Sometimes that's not part of your job at all. Um, and I'm very lucky, lucky that that Gatsby kind of gives me the latitude to make smart choices. Um, my self until it gets to the point where they think I've not making smart choices. And then they say, okay, Lori, we're renting you in a little bit, but so far so good.

Michaela: [00:40:44] So maybe one of the last topics that I want to, um, pick your brain about is Twitter, because you increased your Twitter following quite a bit over the last year. And I see you, you know, I see that you have a very engaged audience that you have really, you build a community. I'm on Twitter. And I think that's something that I would like to do as well. I would rather have a small community than a large audience. Right. So I really like if people are writing back, if I, you know, hear about them, but I would like to understand. What Twitter means to you and how do you use Twitter to really engage with people? I see that you are asking a lot of questions. Why do you do that?

Laurie: [00:41:27] Yeah. I first got a Twitter account, a professional Twitter account because I was speaking at a conference, one of my first conferences and they said, you know, do you have a Twitter? And I was like, Well, no. And then I made one and I discovered that there was this whole world of tech, Twitter that I had no idea about. I had no idea that there was this wonderful community, these content creators, these people, that shared resources, um, that there were people who had all careers, um, not based around Twitter, but. But Twitter was the vessel by which they shared their information, at least in part. And I was just kind of struck by that. Um, I loved getting to meet and talk with people. Some of whom I have met in person, some of whom I still have not been considered to be good friends, but I loved that it was a community of people who were focused on. Talking about technology, teaching technology, leveraging technology, kind of running the gamut. And so it led to me, you know, You know, posting about conferences I was at, or I'm starting to blog eventually. Yeah. You know, finding people and becoming an egghead instructor or a Google developer expert, or so many of the opportunities. I've had this year is because of my presence on that platform. And I wouldn't say that it was explicitly intentional. My goal was not to, you know, say, you know, get 10,000 followers. Um, Did I want to grow my audience because I thought I would have more of an impact. Yes. Did I learn very quickly that that was a very arbitrary measuring stick? Absolutely. So I think what you'll recognize very quickly is if you do start to grow your audience, Audience and engagement, like you said, are not the same thing. And engagement is something you have some control over, but not actually as much as you think the algorithm has a lot of control over that. So for example, if I go on vacation and I put down my phone because I want to. I'm going to see a huge drop in the number of people who engage with me. And it's not because the people who like what I write have disappeared, it's because they're not seeing what I tweeted on their feet. It's just not getting picked up. And that's okay. So, so you learn that, and you recognize that like what, whether or not your stuff is seen as not really a byproduct of what you wrote or what you said, the questions thing was born out of. Early days, Twitter. I had gotten to the point where I had a thousand, maybe 2000 followers. And I said, I think there's enough people here that I could get some interesting data. Um, so I asked a question and I can't for the life of me, remember what the first one was, and I didn't expect anyone to answer. And it had like over a hundred responses. I was blown away and it just kept traveling from group to group to group, a bunch of people who didn't follow me were answering. And I was like, okay, this is an effective way to interact with people. And I found that I just really liked coming up with interesting questions. I found that they made people think I found that it was a unique way of interacting on Twitter. Cause so many people want to be heard. Um, Or want people to hear them instead of wanting to listen to other people. I think it also gives people who have a smaller platform. Um, you know, you happen to comment on my question and someone liked your answer will, they're now exposed to you as a potential person that they want to follow or learn from. So there's, there's lots of layers there that I thought were really interesting. And so some months I'll go by and not ask any questions and some days will be, you know, lots of questions today. I randomly thought of a question that I thought it was kind of funny and silly and just seems like fun. I was curious if someone wrote a biography about your tech career, what would the title of it be? And I've been laughing all morning at the response. So, you know, sometimes it just, you know, put a little bit of a levity in someone's day and sometimes it's, what are people working on sometimes it's, you know, how do you learn best? Because that directly goes to what I do. It varies.

Michaela: [00:45:34] Yeah, I really like to ask questions. So that's probably why that's so interesting to me because I'm super curious person and I always want to know how others see the world, right? And especially if I have researched something for several years, then having fresh ideas or fresh, you know, perspective on something really, really is super valuable. But. Yeah. As you said, the twitter algorithm doesn't make it really easy because you are asking a question and yeah, I wait for answers and then nobody answers and they're like, Hm. But yeah, if people answer, I'm really super happy, always. So. Yeah. So Laurie, I think that we actually reached the end of my show. Do you want to, you know, talk about something that we haven't covered yet?

Laurie: [00:46:16] No, I think we've talked about some fun stuff. The only thing that I would say is feel free to tweet at me. If you think of anything you'd like to ask. I am Laurieontech, on Twitter. I write a number of blog posts about Javascript, web technologies, other stuff. I do the egghead stuff. I speak at conferences. If you ever see me in the wild, please come up and say, hello.

Michaela: [00:46:40] Yeah, I will put everything in the show notes. And, um, yeah, I just want to thank you for, for this really well rounded interview. I learned a lot today from you. Thanks for taking the time.

Laurie: [00:46:51] time. Absolutely. Thanks so much for having me. I appreciate it.

Michaela: [00:46:55] I hope you enjoyed another episode of software engineering unlocked podcast. Don't forget to subscribe. And I talk to you again in two weeks.

Michaela: [00:47:10] Bye.