The Relicans

loading...
Cover image for Going Spec Deep with Laurie Barth

Going Spec Deep with Laurie Barth

mandymoore profile image Mandy Moore ・27 min read

Senior Software Engineer at Netflix, Laurie Barth, talks to Relicans host Aisha Blake about approaching individual languages and/or frameworks in varied and interesting ways, learning things (going spec deep) because they’re interesting to her (i.e. Rust) and that when picking a new language to learn, the community most definitely matters.

Should you find a burning need to share your thoughts or rants about the show, please spray them at devrel@newrelic.com. While you’re going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you’d like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @PolyglotShow.

play pause Polyglot

Jonan Scheffler: Hello and welcome to Polyglot, proudly brought to you by New Relic's developer relations team, The Relicans. Polyglot is about software design. It's about looking beyond languages to the patterns and methods that we as developers use to do our best work. You can join us every week to hear from developers who have stories to share about what has worked for them and may have some opinions about how best to write quality software. We may not always agree, but we are certainly going to have fun, and we will always do our best to level up together. You can find the show notes for this episode and all of The Relicans podcasts on developer.newrelic.com/podcasts. Thank you so much for joining us. Enjoy the show.

Aisha Blake: Hello and welcome back to the Polyglot podcast. My name is Aisha Blake. And I am here with my good friend, Laurie Barth, who is here to talk to us a little bit about her journey as a polyglot. Thank you so much.

Laurie Barth: Yeah, I'm happy to be here. It's funny. I was thinking to myself, how many times can we say polyglot programmer in a row before it doesn't sound audible at all?

Aisha: [laughs] I started to say it, and I was like, I'm not going to try. I'm going to save it. I'm going to save it, and we'll come back.

Laurie: [laughs] It's not an easy word to say.

Aisha: Definitely not. So as a polyglot programmer...

Laurie: Polygot programer. No, see, I said polygot, not polyglot. See? I’m already screwing it up.

Aisha: [laughs]

Laurie: I don't think I can call myself a polyglot programmer if I can't say it.

Aisha: You got it. Just don't think about it. Let it flow.

Laurie: Okay. Now I just let it go in my head. This is your fault. [singing] Let it go. Let it flow.

Aisha: So, if you wouldn't mind introducing yourself, who are you? What do you do?

Laurie: I'm Laurie. I'm a software engineer and, in my spare time, a technical educator. That's probably the two-sentence explanation of me as a human.

Aisha: I like that. That feels apt, yeah. You do have this really rich background as a programmer. And I'm interested to know a little bit about the breadth of what you've worked on.

Laurie: So most people don't know my background because it's very different than my public persona because my public persona is a little more specialized. But I started programming technically in middle school and high school, but we're not going to count that. In college, the earliest programming classes I took were Java-based. And then, because of weird things involving different institutions and colleges, and transfer credits, I finished up my computer science education in Python. And then I was employed doing Java with a Struts front end, which is a thing no one's ever heard of, but it's basically like Handlebars or some other non-JavaScript template for the front end. And then, you can have JavaScript functionality embedded in the page, old school script tags for the win. And then I moved to Angular. And then, after I left that role, I was in a consulting role. And when you're a consultant, you do whatever the client tells you to d,o so that was PHP, that was Python, that was a little bit of Java, that was Typescript, that was JavaScript. That was so many different frameworks; it was Vue, it was React. It was a lot of proprietary things that specific clients would have that are things no one's ever heard of in the mainstream.

And then I joined Gatsby, and I use JavaScript and Node and TypeScript and all of those things. So I have this weird background of coming from what I'd consider the more old-school languages, and people are going to give me crap for that because that's the new school-old school. But to do Java and then to be in the JavaScript ecosystem now -- I think there are a lot of people who learn JavaScript and talk about JavaScript who didn't come from that more traditional background. And so the way they learn and approach things is very different than whatever foundational information I keep in my head day-to-day.

Aisha: So, how do you feel like those things differ? What are some variations that you've noticed?

Laurie: So I really appreciated learning Java first, and as early as I did because I tried to switch over to Python, and Python made me angry, which is funny because people love Python. And I appreciate it now, but at the time, I needed the guardrails. Java is very verbose, and you know exactly what type you're using and exactly what its variable name is and exactly what you're assigning it to, and all of these different things. And you can't have arrays with random things in them that aren't the same types. And then you go to Python, and there's just all this magic that's happening for you behind the scenes. It makes it more readable in some cases. It makes it easier to make something that works, but it also means that half the time, you don't realize you did a thing that you did. JavaScript is similar, right? There's a bunch of foot guns and a bunch of things you can get away with. And I appreciate the ability to do that now because now I want to be able to break rules. But at the time I was learning programming, I needed to know what the rules were, and I really needed to be constrained in some ways because otherwise, I was just like, what is happening? Why is this broken? Why is this working? It doesn't make any sense to me. So the verbose stuff was really useful. And I think over time, I've sort of moved away from that. I find TypeScript somewhat challenging because trying to type things that were based on following JavaScript rules, which is the Wild, Wild West of there are no rules means that the types themselves are really complicated.

Aisha: I definitely feel that. My impression of you, I guess, is that you were one that dives deep into things. You mentioned a lot of stuff; that was a whole lot of different languages. I'm wondering how you approached each individual language or framework or whatever it was. Maybe that varies depending on how long am I going to be working on this? Is this a client project? Is this something that I'm doing because I have to? Is this something I need to be up and running with really quickly? What is your approach in general terms when you are beginning to learn a new language?

Laurie: So it absolutely varies, but I think it varies in interesting ways. So the best example of this is PHP. I knew I was going to be solving a specific problem in a specific codebase for a couple of months. So I didn't bother learning PHP. I looked up how to do the thing I wanted to do in PHP, which means I hated working with PHP, and that's not a knock against PHP. I never bothered to learn it. I was just like, do the thing I want to do in Java but do it in PHP, not a great way to use a language because you're fighting against what it's made to do. The functionality worked in the end. I wouldn't recommend it, but it worked because that was my task at the time. Other languages that I learned, like Java and Python, when I learned them in school, I was learning them much more from a computer science-y how do I write algorithms in this language perspective? Which when I went to use them in a working environment, was very different, honestly, way easier to use them in a working environment because you have existing patterns but way more complicated because it's not this cleanroom of an environment where you're running a single main method and nothing else matters.

I will say in more modern times, in my later career or currently where I am, if I need to learn something for work, my approach is to tackle it relative to that problem. If I'm learning something because I'm interested in it (Rust is probably the best example of that), I go spec deep. I'm like, I want to know what loops look like. I want to know what the data types are. I want to look at this holistically from how the language is parsed and compiled perspective, which is a thing that is actually relevant in Rust and isn't really relevant in other languages to a certain extent depending on the level of abstraction. But I will go in a very different direction. In fact, I basically just read docs. I literally look through spec docs of languages because I find it fun because I'm weird that way. But that's very different than something I need to learn to accomplish a specific task. If it's greenfield and I'm learning it just to learn it, very different approach.

Aisha: For sure. So what then would draw you to learn something totally greenfield like Rust? Let's jump into Rust. Let’s talk about Rust because the last time we had a conversation like this, we were on my Twitch channel. And we're meant to be talking about your TC39 work, which we should totally talk about here [laughs], and it turned into --

Laurie: But it turned into Rust.

Aisha: It turned into Rust. It turned into a conversation about Rust. So clearly, there's something there. It sounds like you're enjoying it. And to my knowledge, you're doing this because you want to.

Laurie: Yes.

Aisha: So what drew you to Rust? How has that learning process gone? What's gone into it, and also, what have you got out of it?

Laurie: The villain origin story's name is Chris Biscardi. [laughter] Chris is a good friend of mine, and Chris has been doing a lot of interesting work and learning Rust and teaching Rust. And he knows that I'm a big fan of JavaScript tooling. I find that a very interesting space, both in terms of watching what's up-and-coming but also part of the work I do at Gatsby is building that tooling. And working with Babel and Webpack are things that I enjoy, and compilers and ASTs and all of these things. And the modern generation of JavaScript is adding more and more and more functionality to those things, which brings up the performance burden quite a bit because it's just longer-running. And so Rust, the way it's built, especially for systems-level things like tooling, is faster for many myriad reasons. But he was talking to me about getting into Rust and where he saw it moving in this space. And the more I paid attention and the more people I saw; I was like, “Yeah, you're right. I should learn this thing because this is a space I'm interested in,” and that's sort of where it went. And to be honest, I'm not that far. There was a day randomly where I felt superhuman strength, and I'd written five blog posts in an hour. You know this because you were chatting with me that day. [laughs]

Aisha: Yes, I remember.

Laurie: And I was just like, “I’m going to pick up the run a Rust, follow the first three CLI instructions to download and install and run a Rust program, and I did that. And I wrote a blog post on it, and I was like, okay, let's actually understand what some of this code that you can do in Rust means because Rust is one of the hardest languages, and not one of, it is I've learned since I learned Java. JavaScript is hard in its own way because it seems like you know everything, and then you very quickly realize that you know nothing. Rust is the opposite, you know nothing right away, and you're clear about that fact.

Aisha: [laughs]

Laurie: So it's great if you're a JavaScript developer reading Rust because there are ways in which you can read through, and things make sense. But there are also things that you see, and you're just like, what does mut mean? It means mutable. But what does ownership mean? There are these ampersands everywhere. There are these really specific keywords and concepts that just are unique, and they exist in other languages to an extent, but they're languages that I have not coded before. And so Rust has been a unique experience, and, like I said, there's a whole bunch that I don't know. But slowly, I'm sort of poking around and learning things. I know Chris has some Egghead courses coming up that I'm just going to devour because I'm like, yes, spend the time for me so I can just watch what you learn so I don't have to dig into the docs myself. But the community is also super wonderful. In the fair number of posts that I published, I received a lot of DMs being like, “Hey, if we could ever support you, let us know. Awesome to see you writing about Rust,” which is just a really great thing to see.

Aisha: Yeah, that is lovely, my goodness.

Laurie: Yes. They're delightful people.

Aisha: Honestly, I feel like I was talking about this earlier on in the podcast, but that's one of the things that I look for in a new language that I'm learning, honestly, is the community. Am I going to be able to get help if I need it? Am I going to make connections easily? Am I going to find the resources I'm looking for? If I run into questions, are there people around who know a lot about this thing that are going to be willing to share with me? And in most cases, to an extent, the answer is yes, but definitely to different extents.

Laurie: Yes. It absolutely varies. And this is unique for me because this is the first time I think ever that I'm picking up a language just because. I will not be using this language in my job anytime soon, to my knowledge. I have no side projects using this language. This is literally learning a language to learn a language because I think maybe in the future it might be useful. But I find it interesting. And that's a whole different world of how you decide whether this is worth learning and even what your resources are. In the past, when I've learned things, I've learned them at jobs. Granted, the sort of corollary to that is I've learned plenty of frameworks just to learn frameworks.

Aisha: [laughs]

Laurie: I actually think that's really different, and people may disagree, but I think learning a framework versus learning a language is fundamentally different in my brain because when I learn a framework, I still have landmarks of the language. There are ways in which things integrate and functionality that I understand that needs to be there in order for the project to build, in order for the project to execute, in order for the browser to be able to look at my files. All of these different things around the framework I know have to happen. In a different language, none of those touchpoints are there. And so I start looking for other touchpoints. What is the for loop? What is the string type? How do I assign a variable? How do I make a function? That sort of thing. But even those primitives can vary quite a bit, and ownership in Rust is a perfect example of like, oh, that's not what I'm used to.

Aisha: Yeah. That's definitely something that I'm still working through. I just recently started learning Rust, and to your point about unique concepts, that is definitely a thing that has taken plenty of reading. [laughter]

Laurie: Right? Everyone reads the Rust book, and they're like, “Okay, well, this is a manual for life.”

Aisha: Yeah. It's been largely helpful so far. I did venture out recently because, similar to you, this is the only time in my life that I have just been like, you know what? This sounds interesting. I'm going to learn this language. And it’s been good so far. But what I want to do is really build something out of it. And so I attempted a Rust game tutorial; we did not get very far.

Laurie: That's still pretty cool.

Aisha: I have hope. And it's largely because of the community that I've experienced so far.

Laurie: Yeah, for sure. I also appreciate the fact that -- people are going to disagree with me on this, but again, JavaScript is the Wild West. And depending on what framework you're using and depending on how you're running JavaScript, things cannot work in JavaScript, and you have literally no idea why. [laughs] The stack trace is completely unhelpful, or there is no stack trace. And you're just like, but why? Rust tells you right away, “You are doing these 25 things wrong, and it's going to take a while to make any progress,” but at least you know what the 25 things are.

Aisha: It's true.

Laurie: And I think that differs across languages for sure. So Java, for example, has these really gnarly stack traces that when you first start coding it, you have no idea how to read them. And then, over time, you start recognizing that there's a bunch of form field gobbledygook in that stack trace that's getting spit out. But you can parse through, and you're like, oh, that's my function name, and that's my line number, and that's my variable. And so, over time, I think there are skills I learned from Java that have been transferable throughout my career. The main one is how to Google, specifically take whatever your error message is, look through it for anything you recognize from your specific codebase that you wrote yourself. If there is a function word that you wrote, if there is a variable name that you wrote, if there's a file name, delete those from the error message, insert them into Google, press enter. [chuckles]

Aisha: Yes, 100%. Where would we be without search engines? I mean, really, how would we do our jobs?

Laurie: I genuinely don't know. We're all just piecing together a patchwork quilt of all of these different people who have figured out how code works over time. [laughs]

Aisha: Exactly. Honestly, the thing that drew me to coding in the first place, one of them -- I think we've talked about the fact that I started via Neopets.

Laurie: As all of us should.

Aisha: [laughs]

Laurie: So I definitely did some HTML and CSS in Neopets. I did some stuff in Myspace. I also did some stuff in LiveJournal. I think LiveJournal was the one that sort of sticks out in my brain.

Aisha: Yeah, and I love that. For some people, it's LiveJournal; for some people, it's Myspace; for some people, it’s Neopets.

Laurie: And for the current generation, it's Minecraft.

Aisha: Yeah. And for so many of us, there was this element of discovery. I certainly didn't even think about it as, oh, I could do this as a job one day. At that point, I was like, I'm totally going to be a stage actress. [laughter]

Laurie: Kudos. I never had that particular thought. All the years of musical theater, I was like, yeah, I'm not going to be able to make it. I've heard your voice. I understand why.

Aisha: [laughs] I've already forgotten what we were singing earlier. I know you were singing on my own when I abandoned you by accident.

Laurie: Yes. Oh, at the start of the podcast, you were singing, let it go.

Aisha: Oh, yes.

Laurie: Let it flow, specifically.

Aisha: Let it flow.

Laurie: Which is also a programming language. It's called Flow. It's what people have used instead of TypeScript. Though I think it's kind of fallen out of favor recently. I don't know, though. So don't quote me on that. Don't anyone get mad at me if they're like, “Flow is still very much a thing.”

Aisha: [laughs] I did not know that. I didn't know. There are so many; it’s wild.

Laurie: I feel like I could just spend the entire rest of the podcast, and we’d still have a long time left. I feel like I could spend the entire rest of the podcast just listing jargon, keywords for things in the ecosystem, and that's just JavaScript. Like, how did we get here?

Aisha: Oh my goodness. Yes, absolutely. And let's talk about JavaScript. Let’s talk about JavaScript, Laurie.

Laurie: I don't know what you're talking about. Never heard of the language. Thanks for having me.

Aisha: [laughs] So I know that you are part of the TC39 Educators Committee. Do I have that right, Educators Committee?

Laurie: Yeah.

Aisha: And I know we've tried this; the two of us have tried this before. But I would love to hear more about your work and what the committee does, how folks can get involved/benefit from the work that you're doing.

Laurie: Yeah, absolutely. So TC39 is the standards committee that decides what new features are added to the ECMAScript standard. And the ECMAScript standard is the standard that all JavaScript engines develop against. And JavaScript engines are what decide what JavaScript you write is valid, whether that's in the browser, in Node, et cetera, et cetera. And so basically, they're sort of designing the JavaScript language in a very roundabout way. But the way it works is that it's all community-driven. And so there are proposals that people have for what they think should go in the language, and then they champion that over a long period of time working through the different stages of the process and eventually landing it ideally in the ECMAScript specification. That specification is cut once a year around June, and then whatever features made it to stage four in the previous year are considered part of that release, so the releases get year names. So ES2021 is what we're about to have in June.

TC39 Educators Committee is sort of an offshoot of that which is designed to educate people not just about new features that have actually made it to stage four but about features that are up-and-coming that are currently being debated and being discussed. And the goal of doing this is that we want people who aren't necessarily as steeped into the minutia to be able to bring up use cases that weren't considered and have a say and have input into the future of the language. And so we write short write-ups trying to take these things out of the proposal-based language, which can be a little bit hard to parse depending on what your familiarity with it is, and moving it into a blog post that you would read explaining how to use optional chaining, for example. And yeah, that's what we do.

Aisha: Good example. I think I remember one such article about optional chaining.

Laurie: I actually don't think I wrote that one, but maybe I did. I don't remember. [laughs] There have been so many.

Aisha: That is super useful. I feel like there's a tendency among the general practitioners of JavaScript and probably most if not all of the other languages as well to just take what we're given and not necessarily get involved in the process of creating, iterating on the language itself.

Laurie: Yeah, it's interesting. JavaScript, in general, because of the size of the open-source community, has abstracted some of that into things like libraries, into things like frameworks instead of changing the spec directly. And there's nothing wrong with that. But the perfect example of this is Lodash. So Lodash was a utility that everyone used, and not every piece of Lodash is now in ECMAScript, but huge numbers of those utilities are. Flat and flatMap exists in the language because of Lodash in part. I mean, obviously, there are other reasons; it's not a one-to-one mapping. But that being such a popular library and installed almost by default for so long has informed a lot of those potential features.

Aisha: I wonder if that's just a more approachable avenue for folks or if it's just like, I can have this now.

Laurie: It's a layered topic, so one is time. Championing proposals takes a lot of time. In fact, a lot of proposals will have more than one champion during the course of time it takes. It takes years for the most part. The second piece is I think it's not as well-known as it could or should be. So I stumbled upon TC39, and I happened to mention in a thread that it was this goal I had to be part of TC39. And then I got a DM, and I was connected to someone. And then, all of a sudden, I was involved with TC39. Weird things happen on Twitter. What can I tell you? But in general, I don't think it is well-known. The process is not well-known. We're trying to work on that. There are conversations about the Educators Committee doing a write-up explaining what this looks like and how to get involved. But yeah, it is this sort of gatekeeped thing, not intentionally, just by nature of the fact that there are a limited number of members on the committee in the first place, and they have these meetings, and unless you're sitting in the meetings, you don't necessarily know or understand the proposal. So there's the people who are super spec dorks like I am who start getting involved, and then there's literally 99.999% of the rest of the people who use JavaScript who do not care. And so if they want to build a utility that adds difference and intersection and a bunch of set methods to the set data type in JavaScript, they're going to make a library, publish it on NPM, and walk away. And they're going to do that in 48 hours. And then their library called zet is going to get really popular. And someone is going to propose putting those exact features in the language, and that'll probably get passed in the next few TC39 meetings. So it is sort of a symbiotic relationship. There are ways in which a lot of what comes into the language is things that have been proven in these utility libraries over time. It varies over time. So it's not one or the other; it’s not zero-sum. But it's complicated.

Aisha: Yeah. Honestly, I don't know that I have thought really critically about how we come up with new language features, particularly in JavaScript, because that's where a lot of my work life has been personally. But it's just interesting to think about how these changes come about and how different parts of the community and the industry feed off of each other.

Laurie: Thievery. I mean, it's a joke, but I'm not – I have – a lot of people angry that says, “Work smarter, steal code.” And obviously, I meant it in a very particular way, so don't come at me with pitchforks. But a lot of what has been added to ECMAScript in the past three to five years has been stuff that's worked really well in other languages and was lifted from it, maybe with some syntax tweaks, but there's a lot of stuff that we're pulling over from Python. There are some things that people are looking at from Go. There are some things that have come from Ruby. There are some things that have come from C. Like you are slowly -- and what's great is every time they're like, “We should have this utility, every other language has it,” you then get to list out the five other languages that have it and pick the best one and decide that's the one that's going in an ECMAScript. So, in some ways, it's good that JavaScript was sort of this Band-Aid language for a long time because now it's really maturing and has a lot of lessons learned to fall back on from other languages. Granted, there are certain choices that were made that can't necessarily be undone, which is a whole other thing.

Aisha: Yeah. But that's true of a lot of languages.

Laurie: Yes, absolutely. And I am not a JavaScript purist. I love JavaScript, but I completely recognize where its shortcomings are. I wouldn't say everyone should use it for every project. I wouldn't defend some of the funny quirks about it. I think they're funny, but I understand why other people wouldn't think they're funny, like the Wat video. If anyone hasn’t seen it, it's funny. All those things are funny. But at the same time, I don't think it's this language that's completely unredeemable, and everyone who uses it doesn't actually understand real computer science and all these other terrible things people say. No, it's a really powerful language, and it's a really utilitarian language. You can write front ends. You can write back ends; you can write CLIs; you can write integration scripts. You can write anything you want using JavaScript. And granted, a lot of the critics will say that is exactly the problem.

Aisha: [laughs] Yeah.

Laurie: But I think that's great. I think that's really cool.

Aisha: Yeah. The flexibility is definitely a selling point for a lot of people. And I think, too, it makes JavaScript really attractive to folks coming from a lot of different backgrounds, and I don't necessarily mean I'm learning to code, and therefore, I want to try JavaScript because, you know, web things. [laughter] I mean that maybe I'm an electrical engineer, and I want to do a thing, and I have a basic understanding of programming concepts, but I want to be able to do several different related projects in different domains. Maybe I'm going to do that with JavaScript, and I'm going to be thinking about this whole collection of things in JavaScript.

Laurie: I absolutely think that’s true. And I also think it's a language that a lot of people find themselves in who have taken a similar path as I have where they were in something that they learned in school or in a job earlier in their career, and then they over time evolved out of that. And this is especially true of a lot of people who started back end like I did and realized that a lot of the part of back end that they enjoyed was being moved into the front end as the front end was getting more mature. And so they picked up JavaScript as the back end of the front end and then slowly have had to stumble their way through in the dark. Like, how do I actually make CSS layouts work, and how do I deal with accessibility and localization? And what is this thing called the browser? Because all I know is databases and Elasticsearch and Kafka and all of these weird Cron job things, and none of those will help me anymore.

Aisha: Absolutely. I feel like I've seen a lot of that, just folks trying to orient themselves as the landscape changes. I liked the way that you phrased this “I go spec deep.” [laughter] What about that is powerful for you? What drives you to go spec deep when you're digging into a language?

Laurie: I miss the cleanroom. I miss the cleanroom of college where everything is just -- like, nothing else touches, and it's just literally input/output what happens in the middle, and that is what a spec is. A spec is this is a modular atomic piece of functionality, and this is how it works. And I find that a very empowering way to learn a language because if you look at a completely working solution, and I do that a lot, don't get me wrong, I do a mix of both, but if I look at a completely working solution and I don't know the language yet, every time I encounter a specific piece of syntax, I'm going to go back and look it up and try and parse it relative to the example I'm looking at. If I understand the syntax, then I can fit that into the example I'm looking at. And all of a sudden, I understand at least a part of the example. And when I was getting more in-depth in JavaScript, I knew what everyone else knows when you come from a language to a language. I could recognize the for loops. I knew what the function signature looked like. But when I would see things like optional chaining and spread syntax and fat arrow functions and all of these things, I was like, what is any of this? And so, as I would read the MDN docs on literally the syntax, I could understand a percentage more of the codebase by taking that approach.

Aisha: That makes a lot of sense, having this sort of blueprint that you can then apply to whatever you come across as you're actually trying to apply the language versus starting with that application and trying to sort of parse out the bits and pieces in relation to that.

Laurie: Yeah, absolutely.

Aisha: So in contrast then, what's an example of a time that you have not gone spec deep? And what did that look like?

Laurie: PHP is my example. And I mean, I sort of said this earlier. I literally reverse-engineered how do I do the thing I want to do in PHP? I am breaking down and solving this problem in pseudocode in my brain. What do each of these lines of code require in PHP? And it was a terrible experience. It was just not fun, but it was necessary. And I knew it was okay because I will also say when I started learning JavaScript, I didn't go spec deep. I was in an existing project, and I learned enough to do specific tasks. But over time, I started digging into the spec because I stuck around longer. So for me, it's sort of an investment, and it’s, does it make sense?

Aisha: Yeah. To spend that time and energy into really understanding something that you're maybe not going to use that makes sense versus suffering short-term through just getting enough to get the job done.

Laurie: Yeah, absolutely. And I think this is a decision for every person individually within the context. And there are some people who couldn't skate by the seat of their pants the way I did with PHP, and that's cool. It doesn't work for everybody. But it didn't make sense for me to make the investment.

Aisha: Totally fair. Maybe the answer is just JavaScript. Do you have a favorite language? And if so, what about that language makes it your favorite?

Laurie: The JavaScript AST. Is that a valid answer? [chuckles]

Aisha: I'm going to go with yes, but then I want my follow-up.

Laurie: So JavaScript is my favorite language, and the AST is just a representation of the JavaScript code that you've written in a tree structure where every single token, which is a variable name or the word let or an equals sign or whatever is represented as a node on the tree, not all of those are represented as nodes on a tree, but it's basically what happens when you parse your code before it's compiled and available in the final boss that the browser takes on. It's just a geek thing for me. I just really think it's fun. I love seeing stuff broken down that way. I love being able to look at it and say, “Okay, what can I change and do the same thing or something different, and how minimal are those changes?” But yeah, it's JavaScript, and it's JavaScript because I have been working with it for, oh goodness, since 2013, I think, so like eight years now. And it's the language I know better than any other language I've ever worked with. And it's a language that has been such an integral part of my career. And it has nothing to do with the language itself. At this point, it's just sort of taken on a life of its own.

Aisha: Yeah, I feel that. And it sort of circles back around to what we talked about earlier about the community around the language. I imagine that a lot of your industry friends and connections are also primarily JavaScript developers at this point and that there's some familiarity with the people as well.

Laurie: And again, you can't discount that. You can't unravel that and disconnect that from the language at this point; it's all one and the same in my brain. It's the community that I am a part of that you're a part of. And for all its good and bad, it's something we know, and we appreciate, and we understand, and we've grown up with for a long time now.

Aisha: Yeah, absolutely. Well, we're coming up on time. And I want to thank you so much for doing this with me. I always enjoy our conversations in general.

Laurie: This was a very mellow version of us conversing. I didn't think we had it in us.

Aisha: [laughs] I'm proud of us. I think we did a great job.

Laurie: I think we did a great job too.

Aisha: So, is there anything that you want to shout out? And if you wouldn't mind, share where folks can find you on the internet.

Laurie: My shout-out is to find me on the internet. I like being found; it’s fun. And I'm Laurie on tech pretty much everywhere. I'm laurieontech on GitHub. I'm @laurieontech Twitter. I don't do Instagram, so sorry. I’m laurieontech on NPM. I mean, I'm laurieontech everywhere. So it's well-branded and consistent.

Aisha: For sure. Awesome. Thank you again so much. I had a great time. This is but one of three Relicans/New Relic podcasts that we are putting out, and you can find those at developer.newrelic.com/podcast. You can also find us on Twitch. We stream at New_Relic as well as on our individual Twitch channels. There's a team of 10 of us who are altogether just putting out all kinds of fun and interesting content. It's a good time. So, hopefully, y'all will join us there as well. Thank you again so much to my friend, Laurie Barth. I appreciate you coming to talk to us about your journey.

Laurie: Thanks for having me.

Jonan: Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. You'll also find news there of FutureStack, our upcoming conference here at New Relic. We would love to have you join us. We'll see you next week. Take care.

Discussion (0)

pic
Editor guide