#190 Laurie Barth learns and teaches with use-cases instead of jargon

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Laurie Barth 0:00
I was learning a lot from scratch every time I got a new project and I wasn't able to leverage the previous learnings as much. So I wasn't building upon myself, I was going really broad at all of those different places. And that's useful, and that's valuable. And that has served me well the ability to learn throughout the rest of my career. But I was ready to stop a good quicksand, I found myself frustrated a lot, that I didn't feel like I was standing on solid ground really ever. I wasn't getting to leverage the things I put time into, because I was constantly switching to something else. If you're learning a lot at your building upon it, I think that's a different situation than what I was in. I was learned a lot and found that I was sort of getting burnt out from constantly having to start from scratch. And it was it was great. For the three and a half years I was there. It was just time for me to try something that was going to be diving down deep into something getting to stay there.

Tim Bourguignon 1:04
Hello, and welcome to developer's journey, the podcast, bringing you the making of stories of successful software developers to help you on your upcoming journey. I'm your host team building. On this episode 190 I receive Laurie bath. Laurie is a software engineer who started as a mathematician. She currently works as a senior software engineer at Netflix. Lori is a content creator and technical educator across various mediums, as well as a frequent conference speaker, technical blogger, an active member of the TC 39, educators committee. I think I'll need to know what that is. And gee, Google Developer expert, Laurie, welcome, deaf. True. Hi, thanks so much for having me. It's my pleasure. All right. But before we come to your story, I want to thank the terrific listeners who support the show every month, you are keeping the dev journey lights up. If you would like to join this fine crew and help me spend more time on finding phenomenal guests, then editing audio tracks, please go to our website, Dev journey dot info and click on the Support me on Patreon button. Even the smallest contributions are giant steps toward a sustainable dev journey. journey. Thank you. And now back to today's guests, the show exists to help the listeners understand what your story looked like and imagine how to shape their own future. So as always on the show, let's go back to your beginnings. Where would you place the start of your journey?

Laurie Barth 2:38
Yeah, so that's interesting. It's I'm sure for some people, it's very clear cut. And for some people, they say, Oh, I don't really know, I know. But there are two distinct starts, one that I was conscious of, and one that I was not conscious of. So I'm going to start with the one that I was not conscious of, and I'm going to go through all of the things that happened until I became conscious of it and you're going to be like Laura, you're an idiot. So when I was in high school, I had to take a just required sort of computer course. And we did a lot of things in this class. But one of the things that we did for our final project was use this program called jirtle. Some people have heard of it. Some people have never heard of it. But it's basically a little turtle on like a computer screen graph paper and you give it instructions you say go forward rotate to the Rotate 90 degrees go forward five steps bla bla bla bla bla. And our assignment was to have the jirtle make seven letters of the alphabet. And we got extra credit for every letter of the alphabet we did in addition to it. And I think we had a couple classes to work on it. And then we obviously had to finish in our personal time. I had classmates who were struggling to get seven letters done. I had all 27 done all of them. And I was like, Oh, this is fun. This just makes sense to me. Still didn't realize that I liked development. Okay. So I had signed up to take AP Computer Science. And I didn't like the teacher who was teaching it. I had him for precalculus. And he was just not my favorite. So I switched and I didn't take that class. Oh how different my life could have gone and I took a different AP math class and I went to college. And I was a math major and a political science major planning to go to law school like I had planned since I was seven years old. And I was forced by one of my internship bosses to take computer science one on one. And I said to her, No, I'm not one of those frankly boys who has been sitting in a basement who has been developing since I was 12. Like I can't take a college level computer science class I will fall flat on my face I will fail She's like, Nope, you're gonna do it. It's what I should have done when I was a student, you're gonna go do it. And I did it. And it was in Java. And while there were algorithms and all these other things, and you had to do for loops, and it was like, Oh, this is fun, still didn't realize. So I took that class. And I went to Washington, DC for the semester for my political science major to work to do an internship. And I worked at NASA. And I worked at NASA on their web team, because I had been working with a CMS Through my internship at school. And so I was familiar with them. And they hired me. And CMS and web dev, I would not necessarily say, are, are the same thing, because I was working more on just like uploading content. I wasn't really coding things at the time. But still, I was around the actual full time employees on my team were coders, and they were using the CMS to its full extent. And I was like, Oh, this is cool. Still didn't get it. That summer, I stayed in Washington, DC, and I worked at the White House on their web dev team. And again, working with a different CMS, this time, Drupal. And I was standing over the shoulder of a full time employee, and I will never forget this, I was talking to them about the fact that the nav needed to change for something that we were doing that day. from a content perspective, this was whitehouse.gov. And I was looking at them changing this nav, and I didn't know Drupal at all. And I'm like, you're breaking this in my head, I'm like this is you're completely and utterly breaking this, this needs a parenthesis. And this is not closed in any way and like, and eventually they had to exit out and start from scratch because they broken it so wholly and completely or get someone else to help them. And I was like, I'm an intern who doesn't know Drupal. And I could see that this was broken, I still didn't really get it. I went back to school, said hey, I sort of like this computer science thing. I'm getting it a little more now. And I decided that in my senior year, since I had taken a computer science course, I think I might have taken two by that point. And I had some math classes that were going to count, I was going to try and get my computer science minor in addition to my math major and my political science major because I am that person, I am Hermione Granger personified. At least I was just a student, hopefully not anymore. And I had to take this logic class, this logic class that they have is actually part of the philosophy department. But you can take it as a math class, and it also counts towards the computer science major. It's sort of your typical symbolic logic, a lot of not if, and or that sort of stuff. I thought it was the easiest freakin thing in the world i and that sounds obnoxious. But I was like, Oh, this is just math. This just makes sense. It was I'd been doing proof mathematics because I have a Bachelor of Arts and Mathematics, not a bachelor of science. And so it was very similar, but simplified in a lot of ways, which was nice, it was more fun or less tedious, didn't involve so many symbols to a certain extent. And I really enjoyed it. Still didn't get it. I went, I decided that I wanted to do something, I decided I wasn't going to law school. At this point, I wanted to work for the federal government in sort of the like, Department of Defense Department of Justice, like similar vibe to the legal field, but a little bit different. But I wanted to do something slightly technical, maybe analyst. And I got hired at the Department of Defense. And I was hired to be a technical program manager. So I wasn't doing a full time coding, I wasn't doing any coding at the time. And part of the rules for the program that I joined, was I needed to get my master's degree. And a lot of my colleagues decided to use this opportunity to get an MBA or some other kind of business driven thing. And I was like, well, the federal government's going to pay for my master's degree. And they're like, Yeah, and I was like, great. I'm gonna go get a Master's of Science in Computer Science from Johns Hopkins. And they're like, Okay, and I figured, because I had a Bachelor of Arts, and not a Bachelors of Science in the government, that actually matters quite a bit. So I'm like, Okay, I'm gonna go get, you know, the official degree because this will help me with the credentials I need in government bureaucracy. And two things happened from there. One was I realized that I hated program management. I was like, why am I just telling people how to do the thing? Why can't I do the thing? And two, it became a really big problem that I hadn't finished my Master's of Science, because I had a bachelor of arts and to the government. That meant I wasn't technical enough to transfer into a technical job, not until I finished and even still, they weren't sure they were going to let me there was some really arduous bureaucratic stuff, which is why when people ask me if degrees matter, I say in the private sector, no in the public sector, absolutely. So I I left. And I knew that I liked technical things. At this point, I'd figured out that coding was fun. I still didn't think I was qualified to be a developer, I had half of a master's degree, I had a undergraduate minor, I'd had a number of internships, but not a lot of like, hands on coding that would involve Git is the best way to describe it. I hadn't done a ton of that, especially not in any professional manner. I'd done some Java on the side, sort of cheating when I was in my program management roles. Every time I used to transition, it was, like nine months, I would work in office and then transition to another office, it was a training program.

Laurie Barth 10:40
And every time I transitioned, the head of the pm org, in that division would be like, okay, Laurie, here are your tasks. And then secretly, the head of engineering in that department would discover that their pm intern, they called us interns within the program. Their pm intern, was getting a Masters of Science in Computer Science and had a mathematics degree. And they would secretly give me tasks on the side to help them with things. And this happened a lot. Like I wrote some Java stuff. I did a lot of like very technical manual writing, where it was like, Can you break down these steps of like really detailed steps into what people have to do that sort of stuff. But anyway, I decided to leave the federal government, I wasn't happy. I talked to former internship bosses, family, friends, anyone I could talk to who was in the private sector, because when you're in the public sector, what people don't realize is, it's very insular, everyone works in the public sector, everyone works for the government. And they have all these horror stories. It's built up in their brains of like, sometimes the public sector shitty but the private sector, the private sector, just terrible, the fire everyone at the drop of a hat, like there's, there's no stability, and they treat you badly. And yeah, they pay you a little bit more, but like your benefits are terrible. All of these horror stories don't leave. So I talked to as many people as I could in the private sector. And I said, I think I want to go for sort of a technical analyst job. And they said, you're an idiot, Laurie, I was like, I'm sorry about what I applied for three technical analyst jobs, ignoring all of them, I heard back from literally none of those job applications. And so what they were all telling me was, you think you can't be a junior developer, you are wrong, you should go be a junior developer, they need junior developers, you're more experienced than most of the ones they hire. You're partway through your degree. At that point, I think I only had like two or three classes left, you've been doing things in the real world, like there are things that you should go apply. And I was like, not so sure. And they, a couple of them in particular really helped me with my resume. They sat there and they said, the typical resume that says Job, and school and extracurricular activities that people in their first few years out of school, I've been out of school for about two and a half years at that point, that typical resume isn't gonna work for you. Yours needs to be a timeline, because the timeline is going to show that there's all of this unofficial dev work you've been doing for years, years at that point, like five or six years. And so I did that. And I applied to nine places. I heard back from seven, I had final interviews at three I got offers from too, it was I mean, I will say that was about 10 years ago. Now, that would not happen today. Not with the level of experience I had, but it just the time period made sense. And then I finally figured out I should be a software developer. And that was the conscious start.

Tim Bourguignon 13:40
Wow. That's that's an interesting roller coaster. Where should I start unpacking? Why do you have the feeling that at some point, while being a program manager, it started clicking that this is maybe the wait, why at this moment? And not before?

Laurie Barth 14:00
Yeah, so I think I had built up in my head that the things that you do in school, or the things that you do in internships are like the super watered down version of what real employment looks like in the technical field. Because when you're like, I don't, I didn't know anyone who was a software developer as an adult, like my parents are both lawyers. There's a reason I wanted to go to law school. I don't know any of those people. And so not knowing those people. I sort of assumed what you see in movies, or like what you hear about and it's the super smart people who are working on terminal. I mean, things I didn't even have words for at that time. I'm like, Well, I've never like coded live on terminal. Well, things are breaking on a box and it did it like words I didn't understand at that point. I just assumed that even the junior level developers like that is what they did. And I think when I got to be a PM, and I was working with other developers, I was like, Oh no, this isn't that that add, like, it's not that ridiculous that I could do this, I still didn't think I could do it in the private sector. Because the thing that people don't understand about the public sector, well, some people do is all of the technology there is they have to secure all the technology before they can bring it on to anything that government officials use, or is used for official purposes. So if you're using an older version of Windows, you're using an older version with Java, you're coding with two hands tied behind your back, because you can't look things up on the internet, because you don't have access to the public facing internet. The respect that I have for the hardcore devs in the public sector cannot be understated. I mean, they are doing things. We joke that like Google is an essential lifeline to being a developer, they don't have it, and they still get shit done. So Wow, amazing. But watching things like that, I was like, I can't do this.

Tim Bourguignon 15:54
I remember working with a client where by mistake, the firewall blocked Stack Overflow for one day. From out of space. It was something. So yeah, I totally understand that. Do you think you you could have discovered that your this idealized version or negatively idealized version of development wasn't true? beforehand? And what what would you have needed to realize that beforehand,

Laurie Barth 16:24
I think I could have discovered it, I don't know that it would have sunk in for me, one of the big pieces of this puzzle was working for the DOD, even like, it didn't matter if it was as pm or otherwise, like it was my dream job. And I am a very type a person. And so I went after it whole hog. And I got it. And then I realized I wasn't in the right role there. And I started looking around as to what other roles I could be in. There was there was a bureaucratic shift that happened at that point, that changed my ability to transition into the other job because of the Bachelor of Arts long story. But even looking around, I was like, my dream job isn't here, I thought it was I it was a little too slow. For me, the level of autonomy wasn't quite what I wanted. Things just couldn't, there was too many levels of approval. Like it just wasn't an environment that I would do particularly well in. And I wasn't going to see potential other options. Until I had recognized that the thing that I thought I wanted wasn't right, because I was like single singularly focused for the longest time,

Tim Bourguignon 17:34
tunnel vision really on the target. And only when you reach the target, you stopped and look around and realize, oh, maybe not exactly what I want to do. Right, exactly. Okay, how he has seen it. And then I wanted to highlight something you said, you change the way you wrote your resume. Yeah. And and this is so important. I wait too often see this, this classical resume this job? And that's how a resume should be? And he does not? Have you discovered other ways of building your resume. So you mentioned one more project centric, what is there?

Laurie Barth 18:07
Yeah, so mine was more timeline centric, I'd say. So it didn't matter. It didn't have any categories. It was really based on recency. And I actually have a blog post that I've written on how I did it, if people want to read that, I can put that in the show notes. But other ways to do it is even if you have a job, if you're doing something like boot camp or school, focus almost exclusively on that. And then you can put your job as sort of a secondary piece. It's all about what you want to highlight for some people who have been doing a lot of large variety of things, even in the technical space for a number of years. And you know that you don't want to work with some of those old technologies. Having some really clear like objectives I've heard, I've heard people say, to take out technology names that you don't want to work with anymore. If I did that I would have giant gaps in my resume over the last 10 years. So we're not going to do that. I think you need to be specific, I think you need to talk about what you've worked with. But at the same time, like there's ways to highlight and make clear to people, this is really what I'm looking for. And then the other thing I would say is if you are a career changer. And most of what you have is your previous work experience. Keep that do not discount it, reframe it, you can frame almost anything in a way that's going to be valuable to software development, because when it's problem solving, and to it involves working with computers, which pretty much every job has to do. And three and this is the one that I think most people lose is you are probably more valuable as someone with real hands on work experience than someone who just has theoretical school experience. And if it applies to the domain of what you're building technology for, so if you can highlight those things, I think those are ways to sort of shift the traditional resume format, but a lot of it Doesn't matter unless someone's actually really reading the resume closely and you have to find a way to get someone to do that. Some of that's luck. Some of that's networking. You never really know.

Tim Bourguignon 20:12
Stay with us. We'll be right back.

Tim Bourguignon 20:15
Hello imposters, if you work in tech want to work in tech or are tech curious in any way you'll want to listen to this. We've launched a community of professionals who come together to share information and advice about jobs, roles, careers, and the journeys we all take throughout our lives as the designers, builders, fixers investigators, explainers and protectors of the world's technology. We call it the imposter syndrome network. And all are welcome. So find the impostor syndrome network podcast, wherever you listen to find podcasts, and look for the isn community on your favorite social platform. Hashtag impostor network.

Tim Bourguignon 20:57
That is, unfortunately true. And I'm nodding my head every year you cannot see it or not. According to two audits, you say that is very true. And this is one thing that I learned from these podcasts is that second career devs have so much to offer from their first career. There's so much for infers transferable skill, transferable mindset and grit, that that emerged from doofus careers and this transition, that it needs to be there at some point.

Laurie Barth 21:25
Yeah, I don't know that I have a first career. But I think I have a first job. I don't think when I was pm, I really counted as a software Dev. And it's very interesting to me at this point, to be able to look back at that and see. I mean, I was working on large technical projects, some of the architecture decisions, some of the way those organizations were set up some of the domains that they were working on. And the larger problems that we're solving, from a just conceptual standpoint, have proven to be really helpful in the long term. And like that is more tangentially related than probably most people get. But it's interesting. Yeah. I mean, I don't think I would have understood scale and large software systems until much later in my career, if not, from my experience as a PM.

Tim Bourguignon 22:11
And I'm noting heavily. So So let's, let's step a little bit forward. So you started as software engineer, how did this start look like? It's not really a second career, but a shift, kind of dramatical shift anyway,

Laurie Barth 22:26
definitely a dramatic shift. Looking back, it's sort of like laughable to me that they hired me. I mean, they would never hire me today, to be perfectly honest, like, I did well in solving the tree traversal problem. And then they wanted me to scrape HTML off a website and parse it. And I was basically looking at the docs that they showed me to look at the whole time and following their instructions, and I got it working. And they liked that I was coachable. And that's why they hired me. And that's great. I also think there's a certain extent if they saw DoD on the resume, and I couldn't expand much beyond that. And they were like, Oh, she must have done fancy things. And I was like, I'm gonna let you assume that I had a little bit of there's always that default assumption that people talk about that applies on on gender bounds on racial bounds on educational bounds, any number of things, I sort of got that by lack of information. And I'm very aware of that. So I came on board, and I accepted that job. And I remember my first day they were having me read books for like the first two weeks like deep technical books, because the one of the senior developers who was sort of in charge of coaching the new developers, like that was his approach. He was a very low level build up kind of guy. And I was just miserable. I was like, What is this makes no sense to me. So finally, they gave me a bug to solve. I didn't know how to set up IntelliJ. I didn't know how to run things locally, I didn't know how to do git. I didn't know what JIRA was, like, how to learn all of that. And I'm solving this bug. And I went to the person who's supposed to be helping me for help to make sure I'm doing it right. And he takes the problem that I'm solving takes it seven love levels deeper to how JavaScript works, all of which I would understand now. But at the time, I'm like, What the hell are you talking about dude, and it just didn't work? Because by the time he got seven levels down, I couldn't figure out how we built back up to the original question that I had asked. It was just too far divorced. For me. There was another senior developer at the shop, who had left all of the junior training to this other guy because he didn't think he was good at it. And he didn't really enjoy it. And I decided that I was going to make him enjoy it because I liked the way that he explained things better. He was a much more practical, like use case driven display down sort of person. And I ended up being sort of the only developer that he trained. I would come over and ask him 1,000,001 questions. I mean, he must have never gotten any work done. I was at his desk every five seconds, but we had a rule And the rule was, as long as I never asked the same question twice. And if he had to actually code something for me, or really draw it out, like, practically give me the answer. I had to sit down and read it and understand it and learn it, so that he wouldn't have to show it to me again, as long as I did that we were good. And it worked. I mean, I asked really incessant questions, but then I didn't ask those questions again. And slowly and slowly I built up. And we eventually moved to code review for the projects I was working on with him. And there were four other developer on the team, three of them. Well, I was one of them. One of them was more senior. And then the other two were more senior than me. But still, I would say junior to mid level developers, they had master's degrees and CS, they could get more complicated stuff working. But their code quality was not particularly awesome. We realized during code review, but mine was because mine modeled everything that he had ever done. Because I was learning through patterns that he had created. I was looking around the codebase, and trying to like, figure things out, based on what he'd done. So it's a unique way of learning wouldn't work for everybody required a lot of patience on his part. But I would not be the developer I am without having been able to work for him.

Tim Bourguignon 26:15
I want to come back to that. How did this ruleset emerge? Did you just bugging him and that somebody's got Okay, I'm gonna teach you but and there, you laid out the rule game, or

Laurie Barth 26:27
it was never it was just discovered, like, I would ask a lot of questions. And he would be mildly annoyed, but fine with it. But sometimes, like early on, probably my first month I came over and I asked a question, and he sort of looked at me and he was like, Laurie, this is the same as the thing you solved. Last week, go see if you can figure it out. And so slowly, I learned I was like, Okay, I wasn't able to discover what was similar. But eventually, I started discovering what was similar. And I was like, if he's already answered it, he's not going to tell me, or he's not going to give me a major hit. He's just gonna say, go look at that other thing. And that's how it came to

Tim Bourguignon 27:03
be. Okay, so pure conditioning. Pavlov's dog. I didn't know it is expressed this way. But though that's something that really fascinates me. How will this such rulesets really emerge or don't emerge, are spoken or, or not spoken and are taken as as something very important from one side, maybe both? That that's always a very complex system that I like to observe and discover

Laurie Barth 27:30
it? It did become more concrete later on, once it was already happening, because we were having a conversation. And I said, early on, I asked you just obnoxious number of questions. You never got any work done. Why did you can can like continue to answer stuff. I didn't know. I wasn't googling. I was asking him, right. Anyway, I realized that you were actually learning from the answers I gave you. So I was willing to give them to you. And he said, if you would continue to ask me all the same questions, I wouldn't have thought it was worth the time. But you unlike some of my colleagues, even you didn't make the same mistake twice. And to me that was worth spending the time on. And I probably like pretty this, sort of like a very blunt, sharp person, I'm putting this up through historical recollection. But know that sort of what he was getting at, it's funny to me, looking back, I didn't know how to Google, I knew how to show him my use case. And because of the way he answered it, he didn't use a lot of key words, I got really good at doing a lot of things, and not knowing the words for them, which I think I've had to grow on from moving forward. I talk about this a lot. When we talk about interviewing people, I just think it's kind of funny. Like, it doesn't bother me if they don't know the word for the thing as long as they can communicate it. And people are like, well, how can I communicate something without knowing the word for something, you describe it, you explain it like, you give the definition versus the word. And I'm very sympathetic to that, because that's what I had to do. Once I was no longer in that environment. In that role. I very quickly realized that I didn't have the terminology to explain what I was talking about. I think that's why I expect obsessed No, and I write a lot of blogs and do sort of docs is because of that experience. I knew what I was doing earlier that I maybe otherwise would have. I didn't know how to explain it until later that I probably should have.

Tim Bourguignon 29:36
And then realize in hindsight, oh, I was doing that. This is how it's cold. Oh, exactly. And has this this way of teaching from this colleague onto you colored the way you teach now with other colleagues and all peoples around you?

Laurie Barth 29:51
I think definitely color's the way I teach in general, I have an assumption that you don't need to Use a lot of jargon to explain things to people. And a lot of use cases are better if you could show them a variety of situations where you might want to use something that it's more likely to stay. I also think that you could give real world use cases instead of FUBAR at it again, it'll stick with people.

Tim Bourguignon 30:16
Amen to that. Always. Okay, looking at your LinkedIn profile, I want to say I want to say resume because you you describe your resume by being something else entirely. I recognize some words that for instance, Gatsby, I don't recognize the companies before that, I don't want to jump too quick over those. There's something important to say there. But I would be interested in how you came to working for Gatsby and then I'll just leave on Netflix nowadays.

Laurie Barth 30:43
Yeah. So it's interesting, that first job that I have was a local consultancy. And I left that job after about two years, because I had reached a plateau like I had gotten so much help and grown so fast, even as a junior developer, that by the time I left there, I mean, I was solidly mid level. And I went to another local consultancy shop. And what I realized over those five years, seven years, I don't know, I can't do math. Ironically, what I realized over that time period was I was working on such a variety of projects of such a variety of technologies, that I was growing faster than I otherwise would have. I wasn't working on one soul. Thank you. That meant that my depth in certain areas was not that high, but my breath was so high. And I'm such a pattern matcher by nature that it worked very well, what I found what I was looking to move on from consultancy and sort of break out of the local market. I found that looking around in the I live in the DC area, there were a lot of government contractors that I didn't want to work adjacent to the government ever again. And there were a lot of consultancies, and there were a lot of like telecom companies, but there wasn't a lot else. There were few startups, there were a few other things, but there weren't there wasn't a lot else. I had started doing conference speaking, I had started writing blog post, I had started doing this content creation, I had started being a part of Twitter. And I was exposed to all of these other opportunities. And I had made by website Gatsby, thanks to a friend of mine, Jennifer Whitt, Ella, who had built her as a Gatsby literally, like showed me her repo for how to get started. And I said, Okay, I'm going to apply to a startup I had applied to. I think one other role I applied to Twilio, like a year prior to that did not get that role. But I decided I wanted to move into the education space. And I needed to sort of break out of my local market, something where I could be remote. And that's how I came to work at Gatsby, I had sort of done a lot of the things that they were looking for, I'd done so much for that content creation. They had a developer educator, that wasn't the was developer educator, the official role. I think it was just software engineer on the Docs team. Now that I think about it. That was, for me a really big inflection point, I think, in my career, because I went from working for companies that I was doing solid work, but no one would recognize their name, to have a good resume where someone could look at the name. And they would probably ascribe the some level of competency just by knowing what the company was. And that is luck. It whether you get to that point or not, is luck. Another thing that was part, luck is the wrong word. For this, this was persuasion. But I was untitled. At my first few software developer jobs, they were flat companies, they were consultancies. So everywhere I went, and whatever other company I worked for, as a consultant, I was software engineer, there was no other title. Beyond that. Sometimes I was being an architect, sometimes I was being an implementer. Sometimes I was being a technical writer, I was all sorts of different things, wearing different hats. I didn't have tails. And I was pretty, I was very solidly senior at this point. But there was no title for that. And so when I went to Gatsby, and specifically what I was going to the developer education team, and I've worked on all of these projects, and cross functionally, I was like, You're gonna give me a staff title. And the person that I negotiated with didn't want to do that, but I was like, no, let me explain to you why you're gonna give me a staff title, or I'm not gonna come and they did. And I was fortunate in that circumstance, that I, I was able to get that because I did not have any title on paper, because that's not how the places I've worked before, had been. And so a lot of people talk about how do you make the transition to DC your How do you make the transition to the staff? I think part of the problem is for a lot of people, you have to make the transition on paper because you have a title, but if you start with nothing, that you can sort of explain when you move somewhere that finally has titles, hey, I should be here and you have to prove that right and you have Have to be worthy of that title when you get there and all of those things. But I think most of the time, there are some arbitrary hoops, you have to jump over at whatever company you're in, or in the interview process to another company. And I was just coming from such a blank slate in their mind, because I wasn't like if you're transitioning from Google to Facebook or whatever, like, there's clear reciprocity there between what title maps to what I was coming from a place no one had ever heard of, and I didn't have a title. So what were they going to do with that? They need to go based on my interview process. So yeah, that's sort of how I ended up at staff level.

Tim Bourguignon 35:39
That's very good. And I really understand this of this problem. And I've been in a consultancy for 10 years as well. And really, you're hired to do the job, which is to be done, which is rarely the job that you're asked to do, really the job. So you're you're hired as an engineer, you're doing some architectural clarifications and cleaning up the interfaces to some supplier somewhere, because that's where the problem is. Yep. What's that?

Laurie Barth 36:07
I used to joke that when I was in AI, people talk about how hard like Gatsby was hard. I worked on a lot of really hard problems there. I had not worked in the JavaScript tooling ecosystem, really before I'd done some UIs. But like, the depth of knowledge that I needed to have, and I needed to learn was extensive. I hadn't done that before. At the same time, it was still infinitely easier than the month in my career when I was working on a robotics project, a Java project, a PHP project, and a view project all at the same time. Oh, wait, no, there was also the robotics project was a firmware project. So I was like flashing firmware for the first time in my career. So again, working on JavaScript tooling and learning the depths of yarn workspaces, not easy, figuring out how browsers deal with images, and like calculate all of that really complicated and sort of broke my brain. But the actual act of learning those things is easier when you only have to focus on one of them at a time. But it would be too easy for you. You're striking. Video,

Tim Bourguignon 37:25
why did you at some point decide to leave Gatsby during a pandemic, if I got the timeline? Right.

Laurie Barth 37:29
So startup, time is not real life. I was at Gatsby for a year and a half, I would say that is close to like three years somewhere else. I went through probably three different iterations of that company from a structural standpoint, from a leadership standpoint, from what I was working on, I started as the docks, what are the main docks developers, and I moved on to the themes team, and that I was on the like, tooling extensions team, I was at three different roles while I was there. So it made sense. There's also a level of like stability, outside of startup land that I think I was ready for, I was like, I want something that's going to be a little bit more constant. I hadn't worked in a big organization, other than as a consultant since I was in the public sector. That's a really long time. I'd sort of told myself, I would never work for a big company. But I decided it was time to do an earnest search. So what I went for my first step job to my second dev job, it fell into my lap, literally, I had a conversation with someone over dinner, and I was interviewing, and then I was in that job. When I went to Gatsby they were I liked the job that was open. They were the only place I interviewed, I went there. When I decided I was ready to move on from Gatsby. I was ready to move on from like that startup space. I spent a lot of time I interviewed a lot of places, I talked to a lot of people, it was the first time I was taking sort of a holistic look as someone with skills that people wanted instead of someone begging for a job in my career, and it was stressful, and it was tiring. It was fun. It was frustrating. It was a lot of different emotions. We all know how technical interviewing can be. But I found that the opportunities open to me were sort of infinite. There were very few places I wasn't going if they had a role open. That made sense. For me. There were very few places I wasn't going to be able to get an additional interview at this point in my career with the network I built. That sounds pompous that sounds obnoxious. But it's true. And I want people to recognize that I couldn't get myself a job with my network, but I could get myself an interview by network. There's a huge difference. It has no impact on the interview process you go through at all. But if you're trying to get your foot in the door and you think you could interview well and prove yourself it is a benefit. So what I decided to leave when I did all that search I talked to north of 20. Companies talk to a lot of different places. And I looked at a lot of different factors. And it's sort of the second time in my career, I think I've created what I thought of as a dream job. When I went to Gatsby, that was like, the coolest thing that could have possibly been open. For me, it had all of the dev education stuff, it was a startup, it was a date, people knew it was something I used, it was gonna keep me at the ecosystem of people that I talked to all the time, it was great. But when I was deciding to leave, I needed to look at like, what is my dream job for the rest of my career where so what I can wear somewhere I can be for a really long time. So I knew that was a slightly larger company, I knew that was an established company. I knew that was a company that wasn't going to burn me, I knew that was a company with interesting projects where theoretically over a period of time, I could transition from team to team over the next 10 years, theoretically, at a company, obviously, that's going to have good benefits. And I could work remote for so those were sort of all of the calculations. I wanted a dev tooling role or something in the developer experience arena, because I've grown to sort of enjoy that work. I wanted something where I could leverage a lot of my JavaScript knowledge, but potentially grow a different areas. And that's what I got at Netflix. That's why I picked it

Tim Bourguignon 41:32
up. That's usually the place where I wrap up. But no, how did you come up with this list? What did the introspection look like to actually put some words on those feelings and on those needles, so

Laurie Barth 41:44
it was pretty organic. And it happened over time. Something is like I want to work in developer experience or coated in developer experience. I knew right away, that was a combination of things. eidetic Gatsby, it was what I talked about, it was the stuff that I enjoyed was motivated by so that was that was pretty simple. I went someplace more established was probably a slight knee jerk reaction to having been at startup layoffs. But recognizing that if I wanted to be able to stay somewhere for a long time, there are periods of your career where you're at major growth, though, both that there are periods of your career, where you want to be somewhere it's sort of enjoy it and grow within those walls. And I was ready for the second for that second experience. Knowing that I wanted to be remote, that's just the nature of my life and my personal situation, knowing that I wanted somewhere with good benefits and compensation, again, personal situation, knowing that I wanted a place that was not going to burn me out again, knee jerk reaction to startup land. So some of that, I mean, every place is a reaction to the place you were previously. But recognizing that these things were built up over all of the places I'd been in my career, those were the things I'm looking for, at this point in time, are those the things I'm going to be looking for forever? No. But there were the things I was looking for at this point in time. And so they just they were pretty organic, they came to me pretty naturally, there were obvious things that I needed in order to feel comfortable, confident and ready to take on a new challenge.

Tim Bourguignon 43:16
Let me make sense. Make sense. And now I obviously have a have an idealized version of Netflix in what it should what it is to be working there. And I wonder what the reaction to having worked at Netflix could be to go somewhere else. But I guess we need to talk again in a few years. And I'm

Laurie Barth 43:34
sure for some people it is but I will say when I got to the Department of Defense after It'd be my dream job, I was pretty quickly disillusioned with the fact that it was not at all where I wanted to be aI took less than a month. I've been at Netflix for eight months. And it's just about everything it promised to be.

Tim Bourguignon 43:52
For the usual end of the show advice. I would like to come back to one precise point in time, which was when you left consultancy, yeah, this would you say this was a place where you learn so much you were kind of in hyper growth, having many projects at the same time learning a lot of things, yet you decided to leave at that point, what would be the advice you would give to one person maybe considering such a move, and not sure if that's the right time if they should be leaving this place where they are learning so much and starting a new career

Laurie Barth 44:21
learning so much is great. I described the situation I was at that point as cuts, cuts did quicksand. Which is to say that I was learning a lot from scratch every time I got out a new project and I wasn't able to leverage the previous learnings as much so I wasn't building upon myself. I was going really broad at all of those different places. And that's useful and that's valuable. And that has served me well the ability to learn throughout the rest of my career. But I was ready to stop a good quicksand I found myself frustrated a lot. Not like a regular developer frustration of the bugs, not one arcade. But frustrated that I didn't feel like I was standing on solid ground really ever. I wasn't getting to leverage the things I put time into, because I was constantly switching to something else. So if you're learning a lot, and you're building upon it, I think that's a different situation than when I was in, I was learning a lot and found that I was sort of getting burnt out from constantly having to start from scratch. And it was, it was great. For the three and a half years I was there, it was just time for me to try something that was going to be diving down deep into something and getting to stay there.

Tim Bourguignon 45:38
Okay, that makes sense. Makes sense? Make a lot of sense. Okay. Thank you very much. Thank you.

Unknown Speaker 45:43
So yeah, hope this is interesting.

Tim Bourguignon 45:47
When your cheeks are hurting a little bit, that's a good sign. Where we'd be, that'd be the best place to continue or start a discussion with you.

Laurie Barth 45:54
So I'm at Lauria tech on Twitter, and my bio likes to buy a website, which there's a poly work timeline if you want to follow a logo. Lots of the things I do day to day, I'm working on compilers for humans.com. There's a lot of stuff, but basically Twitter is where it all, it all merges together.

Tim Bourguignon 46:12
Okay. And before we call today, what is the TCP 39?

Laurie Barth 46:15
Oh, yeah, TC 30 died is the Standards Committee basically, that decides what do things are going into ACMA script, which is the basis of JavaScript. And so the TC 30 died educators committee, our role is to write up proposals for potential new features. Normally, things that are around stage three before they're actually going to get adopted in order to help people understand what's coming down the pipe. And if they want to add input to the open GitHub proposals that makes it easier for them than having to read a spec. Gotcha.

Tim Bourguignon 46:46
Awesome. Anything you want to add to the shownotes? Anything time? You're not?

Laurie Barth 46:49
I don't think so just everyone's journey is different, and might involve a lot of luck. I think everybody's involves a bit of luck. But recognize that types are different. And what helps you in a given period of software history is going to differ a lot. A lot of my stories are from over 10 years ago at this point. So it's great. I feel very grateful to have come up during that time of software development. I feel very grateful to have reached where I am right now and that level of success, but it's going to look different for people doing it the next 10 years.

Tim Bourguignon 47:23
Amen to that. Thank you very much, Laurie. Yeah. And this has been another episode of Deborah's journey. We'll see each other next week. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you liked the show, please share rate and review. It helps more listeners discover those stories. You can find the links to all the platforms to show appears on our website, Dev journey dot info, slash subscribe. Creating the show every week takes a lot of time, energy, and of course money. Would you please help me continue bringing out those inspiring stories every week by pledging a small monthly donation, you'll find our patreon link at Dev journey dot info slash donate. And finally, don't hesitate to reach out and tell me how this week story is shaping your future. You can find me on Twitter at @timothep ti m o t h e p or per email info at Dev journey dot info.

Unknown Speaker 48:31
Talk to you soon.