[00:00:01.26] SY: (Music) Welcome to the CodeNewbie podcast, where we talk to people on their coding journeys, in hopes of helping you on yours. I'm your host Saron and today we're talking about JavaScript frameworks. (Music). If you're getting started with JavaScript and trying to pick a framework to learn, you might be feeling a bit overwhelmed - which makes sense. There are tons of JavaScript frameworks to pick from. So where do you start? We invited Sarah Drasner to help us out.

[00:00:36.04] SD: Hi, I'm really excited to be here, my name is Sarah Drasner, I'm a Vue core team member, I'm cloud developer advocate at Microsoft, and I also work at CSS Tricks as a staff writer and sometimes editor.

[00:00:49.19] SY: She helps us unpack the differences between JavaScript frameworks, and digs into some of the benefits of Vue.js. After this.

One of the best parts of being a coder is finally being able to bring your passions to life. You have the skills to design, to code, to create the thing you're excited about, and share that passion with the world. And Hover can help you with the first step, of sharing your passion with the world - getting your domain name. They've got a really beautiful and easy to use interface where you can find and register your new domain name in just a few steps. And to give you full control, they separate your domain name from your hosting, so you're never stuck with one service. They keep your domain name safe while giving you the flexibility to use whatever hosting service is best for you. They also give you free "who is" privacy, so your personal information is safe, too. To get started, go over to Hover.com/newbie to save ten percent off your first purchase. That's hover.com/newbie. Link is in the show notes. (Music)

[00:01:47.09] I'm so excited to have you on, I've been a Twitter fan for forever, and I DM'd you and I was like, maybe Sarah could make time for me to be on my show, and you said yes, and I'm so excited this is happening!

[00:01:59.25] SD: Oh, the fandom goes both ways. I was so excited that you reached out to me - I feel very honored to be on this podcast.

[00:02:05.16] SY: Oh, awesome, awesome. So you do a bunch of different things, you're an award-winning speaker, as you mentioned developer advocate, Vue.js core team, writer for CSS Tricks, you also co-founded a web animation workshop thingie, you're always talking about SVGs, you're like an author - like an author-author - as well. You're super busy, you've got a lot going on.

[00:02:25.01] SD: Yeah, I try to keep busy. I actually just really, really love coding, so it makes it pretty easy for me to do those kind of projects because I'm just doing stuff that I love all the time.

[00:02:36.21] SY: So, of all the things that you do, the one thing I want to zoom in on and focus this conversation on is Vue.js, especially for our audience, there's a lot of frameworks going on, but when it comes to JavaScript, it feels like the frameworks just won't end, there just needs to be just this long string of frameworks, and there seem to be new ones all the time. So let's start with just describing what Vue.js is.

[00:03:04.14] SD: Yeah, so Vue.js is called a progressive framework, and part of the reason why it's called that is because you can adopt it in a lot of different ways, you can adopt it just like you do jQuery, where you add a script tag, and you just start coding tiny pieces of functionality, you can adopt it by incrementing things into these bigger script tag blocks, you can use vue-cli, and drum up an entire build process with web pack included and all of the bells and whistles. So it's very easy to integrate into projects or just like use very lightly as well. It's got the same weight as something like jQuery, so it's not a huge - you know, sometimes it feels like taking a deep, big plunge in order to work with something, Vue is kind of set up to be a little bit more flexible.

[00:03:49.14] SY: Very nice, so what are some things that Vue can give me that maybe I don't want to build on my own?

[00:03:57.17] SD: Actually, this is something that I really love about Vue, when Evan You started making Vue, he was really considering the things that developers have to kind of do the same thing, over and over again. So those low-hanging fruits. One of them is accepting user input, so there's a really quick thing called a directive - it's just a little piece of HTML that you attach to something like an input or a p tag or whatever, and you can actually just have Vue capture whatever that data is immediately on the fly, which is a lot of - a lot of us build out forms as part of the way that we work with JavaScript, so it allows that to be totally seamless and really awesome. Same with click events, same with any time you're typing in a value and you have to filter as you type, there are these things called computed properties that allow you to do that super quickly and performantly, and it's cashed based on its dependencies, so you can kind of drum up these scenarios that we do over and over again with a lot of ease so it's very nice on beginners, I think.

[00:05:02.00] SY: So how much JavaScript should I know, do I need to know, to use Vue?

[00:05:09.18] SD: I would say, if you're using jQuery, it's not necessarily harder than jQuery. The way jQuery works is it's kind of like pinging the DOM all the time - it says, you keep all the state in the DOM and you're saying like, hey DOM, whatcha doing. And the DOM's like, oh I got this over here, and you're like great, I'm going to store that in JavaScript. Basically Vue kind of flips that on its head and allows you to store the state, and we're basically outputting to the DOM, so it switches that up so that you're not constantly asking for information, you have the information. So I'm coming out with an article on Smashing Magazine that will be about the differences between jQuery and Vue, because I think that's where a lot of people are coming from when they start to adopt frameworks. And it just shows side by side comparisons between really simple things that you might do with jQuery, and really simple - the exact same code in Vue. So just showing side by side, this is what that would look like, this is what this would look like, and this is why one might be better than the other.

[00:06:11.10] SY: Yeah. Can you walk me through a really simple example of what it might look like in jQuery and what Vue does differently?

[00:06:19.07] SD: Sure, so I think typing in an input and capturing that value is a really good one, because a lot of times in forms you're saying, what's your name or what's your email, and then people are typing their name or their email. So if you are doing something like that in jQuery, you might say something like, ok every time they press a key we're going to listen for that key press. We're going to go get what they put into the DOM and then we're going to go store it in a variable and then we're going to go use it somewhere. The thing is if they start deleting something, you gotta listen for the delete key. If they type something that they're not supposed to, that doesn't work as an email or something, you have to do that kind of figuring out the difference between what they typed, which means you're in essence listening to a lot of events. And what Vue does is you attach this V model, and you create a new Vue instance and you're going to say in Data, name=an empty string. And then that V model will say name, and then they'll be attached. It's automatically listening to what you're typing, whether or not it's advancement or you're deleting, or what have you, it's just picking up constantly those things. So you're not having to say, for every step, go do this, go listen here, Vue kind of does that work for you. So that kind of system is called reactivity, D3 is a reactive JavaScript tool as well, so the cool thing about reactivity and probably the best analogy I've ever heard - I didn't make this analogy but I think it's a really good one - is if you've ever worked with an Excel file or a Google sheet, or something, if you have a bunch of tables, and you have one cell that says a certain amount here and another cell that says a certain amount here, and then another cell that you say, ok, go grab those two cells and make the total - if you went to one of the original cells and changed the value, it's automatically going to update that last cell. And that's kind of how reactivity works - you're not constantly saying go back to that other cell, go recollect that data. It updates in accordance to events.

[00:08:31.09] SY: So you're "listening" to attaching yourself to the result, not the ingredients, and keeping an eye on the ingredients.

[00:08:40.02] SD: That's right.

[00:08:40.16] SY: Ooh, that seems way more efficient, why doesn't everybody do that?

[00:08:43.12] SD: Well, I think that a lot of people have talked about this a lot lately - it's kind of a paradigm shift for a lot of JavaScript frameworks right now, is this change and adjustment from imperative to declarative. And imperative means that when you're talking to the computer, you're giving it steps like a recipe, and I think that's how most of us learn how to program - we say go do this, then do this, and there's nothing wrong with that. But as you get a little bit more advanced, or as you work with some of these other technologies, what they attempt to do is a thing called declarative programming where you allow the computer to kind of make these calls for you. You're telling it what the assumption of that final shape of the data, but you're not walking it through every single step of what it needs to do. Which is easier as a programmer in some ways because you're not necessarily having to state every step and possibly introduce errors. It's also can be really easy to read - it's another reason why I really started to pick up on Vue, because when I was working as a consultant, I'd be thrown into projects where they'd have a legacy code base and there's tons of code already there, Vue was really easy to read when I jumped into those projects.

[00:09:58.29] SY: Yeah, so when you think about Vue compared to other JavaScript frameworks we talked about, how it compares to jQuery specifically, is it fair to compare it to React and Angular and Ember and all those others as well, or is this different?

[00:10:16.12] SD: I think that you can't help but have people compare, because they don't know which one to learn. And I hear what you were saying in the beginning, of like wow, there's just so much here. And I think the kind of paradigm shift for me was thinking about JavaScript as a buffet, because I do think it can feel very overwhelming, all of the things that there are to learn. But if you kind of attach yourself to that excited part of like, wow, there's all these things to learn, I don't necessarily think that you shouldn't learn multiple ones. I think it's actually like, if you do have to decide on a direction to go in for these, because it's so subjective, and everyone's going to have a different opinion on it. So what I suggest, if you're in between two frameworks that you think sound good, that look good to you, but you're not sure which you should put more energy in right now, you might want to just work with one for four hours and work with another for four hours. And just see how you feel -

[00:11:13.27] SY: That's a good idea!

[00:11:13.09] SD: Because I work a certain way, my brain works a certain way, someone else's brain might work another way, and a lot of these frameworks are so similar in some ways, that when you really come down to what you should be doing or what you want to be working with, it helps to have that experience yourself.

[00:11:32.13] SY: Yeah, absolutely. And do you feel like four hours is long enough to get a feel for it and make a decision of whether or not you want to stick with it?

[00:11:41.17] SD: Not exactly, but at least that's not a huge time sink for some who's trying to get a job -

[00:11:46.21] SY: That's true.

[00:11:47.17] SD: Or who's trying to learn a marketable skill. I think if you can invest more time, definitely do - they're very interesting, I've invested more time in learning multiple frameworks for sure. But if it comes down to something like I need to get a job, I need to pick a framework, I think that that's probably a good direction. Really four hours won't give you a full sense of the framework, because first of all at scale you'll see all sorts of things that you wouldn't have otherwise, you might not know how to - for instance, Vue has a thing called watchers, which I think is super awesome, and it's a way to plug into that reactivity system. Usually in four hours you won't get there, right, it's a kind of more advanced topic, so you might not see some of the things that might make something like Vue shine. But you will get a sense of how it handles some of the syntax, some very basic things.

[00:12:39.00] SY: And so if you compare Vue with let's say React, because I feel like React is probably - I want to say it's the most popular JavaScript framework, I don't know if that's actually correct - but if we were to compare those two, what would you say are some of the biggest differences?

[00:12:53.08] SD: Yeah, I kind of say, this is one of my least favorite questions, not that we shouldn't address it. I think it's really valuable to address it. It's just because I feel like I like both, and I don't want people to think that they're doing wrong by going for either. I'll talk about the things that I really like about both. React has an amazing community, it has a huge ecosystem, if you are interested in working on something, there's probably a project in there, and they're probably taking contributions, and there's just like a lot of excitement, there's a lot of conferences, there's a lot of stuff around React. I think one of the biggest things that React has to offer that Vue kind of has but not in such a formal way is that React has React Native, which allows you to make one base way of working with React, and then it also works for mobile applications. So that's really cool. Vue has a similar thing, you can work with a number of different frameworks to create that, but it's not as formalized as React Native. Vue is a little bit younger than React, and the reasons why I like Vue so much is that I feel like what it did, and this isn't even that subjective, is that Evan You, after all of these other frameworks, Angular and React and Knockout, so on and so forth, had come out, he kind of purviewed the landscape, and he said, what works from all of these frameworks? So he kind of took some things from each one of them. He's using in React, it's just the view, it's not a model view controller like Angular, he kind of took that from React -

[00:14:25.14] SY: Is that why it's called Vue?

[00:14:26.29] SD: I think it's a play on words for that, but you'd have to ask him.

[00:14:32.13] SY: Oh my god!

[00:14:32.29] SD: Yeah, I think that's why.

[00:14:34.21] SY: My mind is blown. That's awesome. Ok, sorry, go ahead.

[00:14:37.07] SD: I haven't asked him that directly - I should. Um directives were something in Angular, the idea of watchers was something from Knockout - so all of these, wait no I think computed was something from Knockout - so all of these little things were things that he kind of borrowed from other ideas, so a lot of times when someone talks about this cool thing in Vue, someone will be like, hey, but that's from this other thing. Absolutely, it totally is. This is why JavaScript is a buffet, is that we're constantly learning from each other, and we as developers benefit, because as people make mistakes or introduce cool things, people kind of steal from each other, you get the best of all worlds. So I feel like Vue is the most elegant solution to a lot of front-end problems. I don't feel like I'm reinventing the wheel or yak-shaving, I feel like everything is at my fingertips, and incorporating all those different concepts could've been really messy, but he did in a very elegant way. So I just think that every time I work with Vue, I feel like I'm super-productive, I can build things really, really like legos, just do-do-do-do, and I also feel like the documentation, which I'm now helping work on, but which was way great before I even started working on it, I feel like the documentation for Vue is really nice.

[00:15:57.27] SY: So one criticism I've heard about frameworks in general, regardless of what language it's in, at least for newbies, for beginners, is if you focus too much on the framework before you really understand the language, you're leaning too much - you're too dependent on that framework, and you're not really understanding what it's doing or how it's doing it. So when you think about for a newbie, deciding should I - am I ready to learn a JavaScript framework right now, or should I maybe stick with vanilla JavaScript for a little while longer, how do you think about that?

[00:16:33.03] SD: So I used to think that that was true. I used to totally agree with you, that first you should learn vanilla JavaScript and then you have everything that you need, and then you abstract from there. But recently a friend of mine, James Kyle, had a Twitter not rant, but a Twitter thread about how he feels like that's a false dichotomy, that a lot of people who can learn how to program using one tool, but then they go deeper in another way, or they can learn a couple of different tools and it gives them a good synthesis, but by telling people that there's one true way of learning something, you can introduce some anxiety that is unnecessary because there's no real order that you have to do things as programmer. So that thread I was like, yeah, you know what, I think that they may be true, because if I think back, I was even using jQuery way back in the day before I used vanilla JavaScript. I then learned vanilla JavaScript, but I don't think that learning jQuery precluding me from doing so. I learned Ruby very deeply after I learned Rails. So I kind of revisited my own experiences and was like, actually what he's saying is true. So I think - it certainly doesn't hurt and learning vanilla JavaScript will always do you well from here on out, because the frameworks are going to change - they're always going to be evolving, there's going to be new ones, there's going to be old ones, it's just the landscape is ever-evolving. The more you understand about the core concepts of JavaScript, the less you're up a hill without a paddle - that's not the saying (laughs). That makes no sense.

[00:18:21.26] SY: That's ok, we get the sentiment. So if we talk about comparing different JavaScript frameworks - you mentioned if you have to decide, it's very subjective, there are pros and cons to each, and I'm sure you're slightly biased by working on Vue and being a core team member on that project as well. But if you're a newbie and you have this buffet of JavaScript options - what are some of the things you should consider, questions you can ask yourself, to help you make that decision? You mentioned try it for four hours - but even as you're trying it, what are the things you should be looking out for, to help you decide which one to dig into?

[00:19:05.15] SD: I think some of the things that I take into consideration, because I can't really speak to anyone but me, I always check out the dev tools, that's a really important thing to have because you spend a lot of time in there and it kind of allows you to understand the framework in a deeper way and know how you're working with it. I also pay attention to how people are in the community in terms of are they making a lot of advancements, how's the documentation - documentation for me, this is also kind of a biased thing, I work on docs, but I also work on docs because I really believe in them. So good documentation for me is worth its weight in gold. Because that's where you're going to live your life when you're working on a framework, is to try to understand it through the way that people are expressing it, so that tends to be another big one for me. There's a number of things to look out for - I'm quite excited by the fact that there's so much opportunity in Vue right now, because it's kind of like, it's a newer framework, the community is newer, there's just a lot of opportunity to jump in and contribute and there's no right answer and it's kind of malleable how much you want to contribute to that community and make a name for yourself. So I think that that's pretty exciting. Yeah, those are all things that I consider when I look at a framework. I also get plunged into, if you can do consulting, you get plunged into a larger code base which is kind of helpful because you can see it at scale at production, which is something that you can't really see when you are first starting to learn it.

[00:20:49.08] SY: Yeah, absolutely. So, one of the big issues that I see in our community all the time, is that people feel like they need to know every framework, so it's not even about picking. It's about I need to know these top five JavaScript frameworks as soon as possible in order to get a job, to be taken seriously, to be invited on podcasts and speak and write and do all the awesome things that you're doing. So when you think about breadth v. depth in terms of learning and how deep you should go in a particular language or framework and when it's time to try something new, how do you navigate that. How do you make that decision?

[00:21:31.14] SD: Oh, totally, I don't do it in a very formal way, personally. I'm kind of into this passion-driven development idea -

[00:21:41.07] SY: I like that - is that a thing? If that's not a thing, that should be a thing.

[00:21:42.20] SD: I think Chris Coyer was the first one - he's my boss at CSS Tricks - I think he's the first person I heard say that. But I could be mistaken. It's kind of the way that we write CSS Tricks articles, to be totally honest. It's not like we're like, ok, let's go through the spec, you have A through E - it's kind of like whatever, we write articles on whatever we're curious about that week, or whatever we want to do a deep dive, I'm like should I cover this or this, and he's like, do the thing that excites you more, and I'm like oh, that's great. It's - typically, the articles come out better if it's something that you're excited about. So kind of going towards the things that make you curious, make you excited. I tend to be a very curious person, so I'm exploring all sorts of things all the time, which is why I'm kind of all over the place. But you know, deep diving into something is totally legit. It's absolutely, totally fine - you don't have to feel like you have to sample everything. In fact, when you do get a production-level job, they're not going to have you working on five different frameworks, they're going to say, we have a React stack, we have an Angular stack, we have a Vue stack - and that's the thing that we're going to work on. So it might be that the job decides that for you, in some ways, which doesn't mean that you can't explore a bit on your own.

[00:22:58.27] SY: Yeah, and actually that's really good advice - maybe start with what are the jobs that you want, what are the roles that you see posted, what are the companies that you want to work for, see what stack they use, and maybe use that to help make the decision a little bit easier.

[00:23:13.06] SD: Yeah, except that there is a caveat there, because some of this is skate to where the puck is going, so I would say, a couple years ago I was working at a company and we really wanted to adopt React, but they were like, no, Angular is the big one, React is never going to gain adoption.

[00:23:30.25] SY: Oh, wow.

[00:23:31.01] SD: So for a long time, they held out and wouldn't let us use React, and eventually as React grew in community, then that kind of changed. But now I'm seeing the same thing happen with Vue, where people are like no, React is the one that has adoption. So I would say that that stuff, I wouldn't bank too much on that stuff, I would also look at things like a lot of people put out surveys and things like that - look at the stuff that has growth, growth matters just as much as adoption for that stuff. And go to stuff that you're interested in. I think that there are enough jobs out there for developers of all kinds that you probably could work on whatever framework you wanted to, and be happy and find a job. (Music)

[00:24:16.27] SY: Coming up next - we learn more about Sarah herself, and how she got started in tech. It's pretty awesome - she used to be a science illustrator, among other things. She's also got some really great answers to our fill in the blanks - after this.

When I learned to code, I was so excited to finally bring my passions to life. I could build things that I really cared about, and share them with the world. And the first step in sharing is getting a great domain name. That's where Hover comes in. They've got a really slick and easy to use interface, they've got awesome domain names to pick from, and they separate your domain from your hosting so you have full control and flexibility over your online identity. So go to hover.com/newbie to save ten percent off your first purchase. That's hover.com/newbie. Link is in the show notes.

[00:25:04.15] So next I want to switch gears a little bit and talk more about you and just your story and how you got started. So we started this conversation by listing all the awesome things that you're doing and all the stuff that you are involved in. How did you get started in tech?

[00:25:22.09] SD: So it was about fifteen years ago now or something I was right out of college, and I was working as a thing called a scientific illustrator. I worked at the field museum of natural history and I drew dead lizards and snakes and amphibians and reptiles for a living, so for encyclopedias, for science journals, and things like that. And part of the reason why they have people who draw those things is that when you have a camera and you take a picture of a snake or a lizard or something like that, there's a depth of field - there's a thing called an aperture, so there's parts that are in-focus and parts that are blurry. So when you do a drawing, everything can be in focus, so they kind of valued that ability.

[00:26:11.11] SY: That's such a good point - I never thought about the benefits of drawing in that way before, it's like a very technical benefit to illustrating versus photography. Interesting.

[00:26:20.07] SD: Totally, otherwise they wouldn't have done that, because it takes more time and costs more money. I did take photos as well, but mostly it was drawing. And while I was working there, they came out with this type of camera that could take pictures at multiple different levels and then composite them together, which meant that that career I had made was not going anywhere very fast. So I had a good relationship with the people who worked there and they really wanted me to stay on staff, and they were like well, we're probably going to use this camera because the museum just bought it and stuff, but we want to keep you on - we need to make a bunch of websites and this is back in the days of tables and not a lot of stuff. There weren't JavaScript framework kind of things, CSS was still hmm, I'm not sure we'll use this kind of thing. So they asked me if I could make a website for the thing that they were working on, and I was like yeah, sure, of course I can. Having no prior experience or training, so I went -

[00:27:29.19] SY: Good for you, well done!

[00:27:30.04] SD: I'm always kind of like that, I guess. Yeah, sure, I can do it, and then just try to figure it out. So I picked up an HTML for Dummies book at the store and I made my own website that week, just building things out of the book to practice, so then I started working on that project and at the time there was a thing called a webmaster, which is like a person who's in charge of that place on the web. She kind of took me under her wing and was like ok, this is how we do industry-quality websites. So I'm really grateful for her to have done all of that pair programming with me. So yeah, I started websites, so the first two were aquatic snakes of Southeast Asia, and the next one was about millipedes, I think, then it was about goose barnacles, so I made all these crazy random sites. It was really fun, but then I decided that I wanted to go back to grad school and become an art teacher, and while I was in grad school I was low on funds, so I continued to use those skills to make sites for places like Stanford and UCSF in my spare time, so I was still trying to make some money doing that. I become an art professor in the Greek islands, and -

[00:28:52.02] SY: Really? That's so cool.

[00:28:52.12] SD: Yeah, I was a study abroad professor for four years in the Greek islands - I used to take students to Greece and Turkey and all over the place, to different islands every week and teach them about history and stuff -

[00:29:06.19] SY: That's awesome.

[00:29:06.19] SD: Yeah, again, I wasn't being paid very much so I was still making sites on the side. When I moved back to the US, I took a web development job at an agency, and that kind of kicked off really focusing on tech work.

[00:29:18.09] SY: Interesting. Wow, you have such a fascinating backstory.

[00:29:21.25] SD: Thanks!

[00:29:22.24] SY: So at what point in that journey did it go from I'm doing this for money and I need to pay the bills to, oh my god, I actually really love this and I'm passionate about it.

[00:29:34.21] SD: Oh yeah, totally. When I was at the agency, when I first started there, I think that was to definitely like make money, and it kind of like a bootcamp kind of thing, where it was like, we had to clock out to go to the bathroom and if we coded a newsletter in one minute more time one day than another we had to say why - it was very like -

[00:29:53.29] SY: Oh wow, oh my goodness, that sounds really stressful.

[00:29:56.23] SD: Yeah, it was stressful - I also leveled up really hard there, because you just couldn't help but not -

[00:30:05.19] SY: You're not allowed to -

[00:30:06.25] SD: Yeah totally. So that definitely helped level up my skills, but I do remember there was one time I was working on a project for a big tech dude's wife wanted me to build a site for her. And it was like a passion project for her, and it was about fairies and it was really goofy, but we were making a good amount of cash on that one, so I took my work home that night and was experimenting with some new kind of things I could do with CSS to bring that site out, and I was supposed to meet my friends at this club to go see this band play, and I called them and I was like, I can't come out tonight, I'm sorry. And I just kept coding and coding into the night. I think that was the first time I remember feeling like, wow, I am having a blast. This is just the best. So that was kind of the start of my journey, of just poking around and seeing what was possible.

[00:31:05.28] SY: Has that passion ever faded or waned at all over the years?

[00:31:14.20] SD: Yeah, I think there were a couple points - I'm a very excitable point and I'm very curious, and I'm totally into exploring. Unfortunately, there's time when, if you're a really hard worker, you can start to burn yourself out and you can maybe agree to too many things. So there was a point where I was doing a lot of work for giant component systems and big production sites, where I just started to feel like a code monkey. Like I just started to feel really like, ugh, this is just me working on a big system and constantly fixing other people's bugs and constantly triaging things and it got very far away from the stuff I thought was exciting and I think the way that I pulled myself out of that was I found SVG animation, so SVG animation, I started playing on small projects - which were so different from my job. My job was very much like grunt work, and on the weekends, I was doing these silly little cartoon experiments and more fantastical, or just trying to see how animation worked, and that for me created these dopamine rushes that I'd been missing. If you're burnt out and you go on vacation, you come back and for a little while you feel better but you can kind of slip back into not feeling so great. So working on something that was for me and my own project and was just like for me to experiment and find something that I loved, really actually did more than even a vacation could do. I just felt continuously like yay! And so that kind of helped me turn that around.

[00:33:02.03] SY: Yeah, and I don't know if you experience this, but for me, the other part about burning out is - you know, I think when we talk about burnout, we focus very much on oh, you're working too hard, or you're spending too much time working, you need a break. But I think the other side of it is, we're just getting older. I think that's part of it too, like I can't pull the multiple all-nighters I used to in college, I can't just live off of espresso shots, I actually have to stretch now, I have to take breaks, and I have to do things not simply because or only because there's more work to do or I'm working all the time, but just because my body has different needs now than it used to have years ago. So I think that's the other part of it too, that it's work but it's also just your physical needs change over time.

[00:33:51.18] SD: I think also, I think about this a lot with people who have kids. I don't know how they do it -

[00:33:57.27] SY: Oh my god, thank you, I think about this all the time - every time I complain about how tired and busy I am, I just think to myself, oh my god, what if I had a kid? At this point, if there was a small child dependent on me and my husband for food and pooping, I don't know what we would do.

[00:34:15.03] SD: Totally, totally. The people who do open source or the people who are still coding while you're taking care of children - I've got to just do a little shout-out for you people.

[00:34:25.16] SY: They are heroes.

[00:34:25.29] SD: That's amazing, I just think that you deserve a medal or something.

[00:34:30.18] SY: It is so impressive. I think it was the very second episode that we had ever on the CodeNewbie podcast was with Brian Douglas, and it's called coding like a boss and he tells this story of how he was learning to code while doing his full-time, I think it was a sales job and squeezing in coding time at lunch before work at literally four o'clock in the morning, getting four hours of sleep, having a newborn baby - and I'm just like, uh uh, nope, I couldn't do any of that.

[00:35:00.20] SD: I think I did do that, to be honest, I mean I think I did the working schedule that he did when I was starting to burnout and trying to recover, but I didn't have a kid.

[00:35:11.07] SY: Right, the baby part just throws it all off.

[00:35:13.08] SD: That's a huge but.

[00:35:16.21] SY: Yep. Exactly, so shout-out to all the parents who are making it work and taking care of their families, too, that's really impressive. So next let's do some fill in the blanks, are you ready?

[00:35:27.18] SD: Yeah.

[00:35:28.10] SY: Number one - worst advice I've ever received is?

[00:35:31.27] SD: So I think that the worst advice that I've ever received is that you have to be one way or the other. Right, you're right brained or you're left brained, or you're a front-end or you're a back-end, or you're a Vue person or you're a React person. I think those dichotomies are really not helpful and I actually have read a lot about the brain - my mom is a neurologist, and the more different types of things that you do, the more you stretch your brain's capabilities, the stronger it gets. So it's actually totally the opposite of that. So if you're learning -

[00:36:11.26] SY: That is so cool!

[00:36:12.05] SD: Yeah, you're strengthening the - I'm going to say it wrong - the corpus callosum, the thing that's inside the middle of your brain, it's kind of a connective tissue -

[00:36:18.07] SY: Like a bridge.

[00:36:18.19] SD: Yeah, so it allows you to kind of fire synapses across a bunch of different, so you can - being very technical and being very creative, and you can actually solve technical problems by being more creative. Like a lot of how ethernet was made and formed, it was people saying wait a minute, maybe we don't have to do this, like first it was, ok, everybody waits in line for this connection, and then someone was like, what happens if everybody just talks at once and whoever is first goes.

[00:36:53.24] SY: Also don't do that.

[00:36:54.11] SD: That's a gross simplification, but that's a creative way of solving that problem. So I think that don't listen to people who try to tell you that you have to put yourself into some sort of bucket or some other bucket. I think humans are this beautiful spectrum of things, and we just don't exist in those categories.

[00:37:12.11] SY: That is so beautiful, but it also makes me wonder - why are we so intent on putting ourselves in buckets - and putting other people in buckets?

[00:37:23.00] SD: Well, it's good that you asked, actually. So I did a lot of study about this in graduate school, because I was really fascinated by categories and what they reveal about the mind and also the enlightenment, which is basically like when during Western culture we decided that we needed to categorize things to understand them, so that's when we came up with encyclopedias and dictionaries and things like that. Part of my interest in that was because I was a scientific illustrator, and that was what I did, was categorize these animals and plants and stuff. So there's a book called Women, Fire, and Dangerous Things: What Categories Reveal About the Mind by George Lakoff, that's one of my favorite books. And it dives into how different cultures perceive different categories, and how in some ways, you have to categorize to understand a bit. But the way that you categorize can reveal all sorts of things about the way that culture is shaped, about the way that your system is flawed, about the way that systems break down - so some of it is an embracing of these categories, and some of it is a critique of it, and I think that's really healthy - that any system that you love, you should also question.

[00:38:35.17] SY: Yeah. Number two - my first coding project was about?

[00:38:42.02] SD: So I mentioned that the first coding projects that I did for the field museum and stuff - I think the first thing that I made for myself was that site of mine that I was just building to kind of figure out how everything worked. And I just tried everything - it's not something that you could do on a production-level site. On production-level sites you need to make sure that there's consistency and clarity and like everything is put in really readable patterns. I think for that site, I just considered it my playground, and at the time it was just, I wasn't showing people that site or anything, it was just kind of like a garbage place for me to just have random experiments and stuff. So I think I learned a lot by doing that, by giving myself a place to make a mess and make it not make sense, made the other more structured projects a lot easier for me to see - ok, that part was definitely throw-away, don't do that. This part maybe I want to retain because that thing was actually pretty cool.

[00:39:49.16] SY: Yeah, very cool. Number three - one thing I wish I knew when I first started to code is?

[00:39:54.09] SD: One thing I wish that I knew when I first started to code is how to debug properly.

[00:40:01.00] SY: That's a good one.

[00:40:01.00] SD: I give a lot of workshops and the thing that I notice that holds people back the most is not learning the material, it's that people aren't very methodical when they debug, especially when they're just starting out. 'Cause it always seems like you're so close, so they just throw things at the problem, and maybe they'll throw three or four or ten things at the problem at once, and the problem with that is that you may think that you're going faster by doing that, but you're actually going slower. So one thing is isolation - isolation really helps because you're not figuring out if it's ten different things at once, it's this one thing, does that work, ok it does, great. It's another reason why I use CodePen for debugging front-end stuff, because I can work on some small piece in isolation and know that it's not a system that's causing the trouble. It's another reason why you - sometimes people tweet and me and say, I can't get this thing working. And the first thing I'll ask them for is an isolated test case, usually through the process of making an isolated test case they're like, oh, I figured it out. So it's really valuable to do that. It's also really valuable to not change too much at once because then if something else goes wrong, you don't know why, or if you fix one thing you don't know if it's five of things you did. Just taking a deep breath and believing in yourself - like, I've got this, it's ok that there's a bug, I'm going to fix it, one thing at a time. I honestly think that the best developers I know are methodical in that way.

[00:41:35.13] SY: Absolutely. And I think about that a lot because I've been coding for years at this point, and even I have trouble sticking to the process that I know works. And I think part of it is my ego, you know, if I could just quickly figure out and go really fast, I feel smart and like yeah, I nailed it, I'm amazing. But if I just kind of go through my regular, predetermined checklist and just go down that list and figure it out, it's like, eh, yeah, sure, whatever. I don't feel special for it - so don't optimize for your ego, is the lesson in that.

[00:42:13.04] SD: Yeah, I think in the course of coding you kind of vacillate between delusions of grandeur and hating yourself all the time anyway, that debugging process definitely keeps you from either side of that.

[00:42:27.26] SY: It's a nice reality check. Well, thank you so much Sarah for sharing all your knowledge about Vue and JavaScript frameworks - you want to say goodbye?

[00:42:34.16] SD: Oh my god, yes, thank you so much for having me on here, I'm a long-time listener, so I'm so honored that you had me on here, I really appreciate it.

[00:42:42.05] SY: And that's the end of the episode. Let me know what you think. Tweet me @CodeNewbies, or send me an email, hello@codenewbie.org. If you're in D.C. or Philly check out our local CodeNewbie meetup groups, we've got community coding sessions and awesome events each month, so if you're looking for real-life human coding interaction, look us up on meetup.com. For more info on the podcast, check out www.codenewbie.org/podcast, and join us for our weekly Twitter chats. We've got our Wednesday chats at 9 PM EST and our weekly coding check-in every Sunday at 2 PM EST. Thanks for listening, see you next week. (Music).