[00:00:01.01] SY: We are launching a brand new show! It's called the base.cs podcast, and I'm so excited about it. We're teaming up with Vaidehi Joshi, developer and creator of the base.cs blog series, to bring you a fun, beginner-friendly podcast on computer science topics. The first episode drops November 8 - that's this Wednesday - so make sure to subscribe, and tell all your friends about it. Link is in the show notes. (Music). Welcome to the CodeNewbie podcast, where we talk to people on their coding journey in hopes of helping you on yours. I'm your host Saron, and today we're talking about how browsers work. I don't know about you, but I don't really think much about the browser. It's there, it shows me my websites, it shows me apps that I build, I'll inspect element or inspect page source, but that's pretty much it. And even though it's a pretty important part of how I code and do my work, I don't think of it as a piece of software. But, obviously, it is. To help us better understand the browser, I invited Lin Clark on the show.

[00:01:05.21] LC: Hi, I'm Lin Clark and I make code cartoons. And I also work in the emerging technologies group at Mozilla.

[00:01:11.17] SY: Now, this episode has two parts. The first part is pretty technical. Lin does an awesome job of breaking down how the browser works into bite-size pieces, and we're going to take your hand and walk through it together. The second part is about cartoons, and the awesome coding cartoons that Lin makes. But first - browsers. So put your thinking hats on and let's get to learning. After this.

[00:01:35.17] If you're building an app, you'll probably have users. And when you have users, you have to talk to those users - usually via email, which means as a developer, you need to pick an email service providers, which means you should check out SparkPost. They are the world's most reliable and fastest growing cloud email service provider, with a robust API to fit right into your app. They're super developer-friendly, they've got free self-service start-up accounts, perfect for solo developers, and sophisticated enterprise options, perfect for teams. So, if you need to send email - which you probably do - check out SparkPost at pages.sparkpost.com/codenewbie. Link is in the shownotes.

[00:02:09.18] When I first learned to code, all I wanted was to be a developer. But then I actually learned to code and realized that you don't become a developer. You become a front-end developer, or a Rails developer, or a full-stack engineer, or a back-end engineer, or the million other job titles that involve coding. So how do you pick? And once you get that first job, how do you turn it into a career? You can use the Dice Careers mobile app. This is the tool I wish I had when I first started. You pick the tech skills you either have or hope to have in the future, you type in your designer job title, and Dice helps you find other job titles you might also be interested in and maybe didn't know about. But they take it a step further, by telling you what skills these job titles require, how much they pay, and based on your profile, they tell you what skills you might want to learn so you can one day apply for those jobs. They simplify a lot of the chaos of job-hunting, and it's totally free. So check out the Dice Careers mobile app. Go to dice.com/CodeNewbie for more info. That's dice.com/CodeNewbie.

[00:03:09.15] When you're looking for a program to develop your skills and get that dev job, there are a few things you should consider. Does the program teach in-demand skills? Is the community supportive? Do they offer real world projects so you can get real world experience? And are they based in a tech hub, so you have job opportunities when you graduate? DigitalCrafts gives you all of that, through sixteen-week full-time classes, and twenty-four week part-time classes. They teach full stack web development, with JavaScript - no JS and Python. It's an intense program, designed to take you from beginner to full stack software engineer. Whenever possible, they also partner with local companies and nonprofits, so you can solve real world problems with real life projects. They have campuses in Houston, Texas and Atlanta, Georgia - the fourth largest tech hub in the US, and support for student housing is coming soon. Their cohorts start in early November, so check out www.digitalcrafts.com. Link is in the show notes.

[00:04:02.25] But we're going to start by talking about browsers. So, how do browsers work?

[00:04:08.01] LC: There are a lot of moving parts in a browser. I'm going to talk about the part that is most key and core to a browser, which is the part that takes the HTML and the CSS and turns that into pixels. And so the part that does that is called the rendering engine. So there are five different steps that it takes to go from HTML and CSS to pixels. But I can group that into two different groups. The first part, the first group, what those steps do is they go from the HTML and CSS to a plan, kind of like a blueprint, of what should show up on the screen. And the second group goes from that blueprint and actually turn that into pixels that show up on the screen.

[00:04:47.09] SY: Ok, you with me so far - group one, HTML to blueprint. Group two - blueprint to pixels. Got it? Good.

[00:04:54.29] LC: The first step of that first group is parsing. So what the parser does, is it takes the HTML and turns it into something that the browser can understand. Because when the HTML comes in, it's basically like a big, long string. I think of it like a big, paper ribbon that has all of these characters all along it, all the way to the end. But what we need is actually a data structure that tells us what the different elements on the page are, and what the relationships between them are. So, like the parent and child relationships between these things. And I think of it as kind of like a family tree. So we need to take this long paper strip that just has characters on it, into a family tree that tells us the relationships of the page. So what the parser does is it basically goes along this paper ribbon and cuts out the different elements and builds a family tree out of it on the wall. That's how I think about it.

[00:05:49.15] SY: Ok, recap. We give the browser some HTML. The browser looks at it like, what's all this crap? And then the parser comes and says, don't you worry, I'll make sense of this. It cuts up the HTML into pieces, connects the pieces together to make a tree, and saves the day.

[00:06:03.20] LC: When it sees the opening tag for an HTML element like it did, it's going to cut it out and put that on the family tree. And then the next element that it gets to - that's going to go under that div, and it'll connect those two in that parent-child relationship, it will basically draw a line between them.

[00:06:17.05] SY: So in that sense, when we are coding our HTML and CSS, I think at least I definitely think about it as that parent-child relationship, that framework exists while I'm coding it. So, it sounds like once it has that really, really long ribbon with that string of HTML, it's kind of recreating the thing that I created, on my end.

[00:06:39.09] LC: Exactly.

[00:06:38.09] SY: Is that fair?

[00:06:38.15] LC: That's exactly what it's doing. So yeah, it will take that element, put it under there, make it the child of the thing that has the opening tag before it. And so this family tree that we're building off, that's called the DOM tree, or the document object model. And it's called that because it provides a model of the document and then you can use that to make changes to the document. So if you want to remove some of those family members from the family tree, JavaScript wants to come in and make a change to the page - it can change that model, and then that change is going to end up being shown in the pixels on the screen. And I'm simplifying this process a little bit, there's a lot of other work that happens. When it comes across files, like CSS files, it'll go and fetch those and start parsing those, too. At the end of this parsing, though, we end up with the family tree, the DOM tree, that tells us about the structure of all of these elements that we want to display, but what it doesn't tell us is what they should actually look like. In order to figure out what they look like, we take the CSS that we downloaded and then we figure out which of those styles apply to which elements. And so that's the next step, that's CSS style computation. And I think of that kind of like a person filling in a form for each of these elements that's in the DOM tree. And the form's going to say what the element should look like. It has a little more than two hundred different form fields in it, for each CSS property, and for each element, you're going to need to have an answer for each one of these form fields. You have to fill in the whole form for each element. Of course, if you've written CSS, you realize that you don't always specify all of the properties for every element in your CSS. You just specify a few. So it needs to go through a few different steps to actually figure out what all of these form fields should be filled in with.

[00:08:26.13] SY: So even the empty ones?

[00:08:29.03] LC: Exactly.

[00:08:29.18] SY: Even if I don't specify, it still needs to be specified somewhere by someone.

[00:08:32.18] LC: Exactly. So, the first thing that we do is we figure out which rules in the CSS apply to this element that we're on right now. And the rule is that thing with phrases around it. For example, if you have something in your CSS that says a div with the class of warning should have a yellow background and red text -

[00:08:49.21] SY: So based on that, my CSS might read div.warning{

background: yellow;

color: red;

}

[00:09:01.09] LC: The rule would be the brace - everything that contains both that background property and the color property. And so the whole process is called selector matching. Out of that, we get this list of rules, and then we can sort the rules, if they were more specific, they get a higher priority, and if they were less specific, they get a lower priority. And so, we take that most specific rule and we take all of the declarations, all of the properties that were in there, and we start filling in the form based on that. And then we go to the next most specific rule and we fill in the form fields that were not already filled in. And we keep going until we get to the end of this set of rules that actually matched. But we still have some empty form fields here. Because we probably only specified a handful of the properties. So in this case, there are some properties that CSS has that always get a default in this case. But there are others that inherit their parent's value. And so we look up to the parent in those cases for those properties, we look up to the parent and see what its value is. And so that process is called the cascade.

[00:10:05.20] SY: Hence, cascading stylesheet?

[00:10:07.11] LC: Exactly. So yeah, at the end of this whole process, we have this filled-in form. It has all of the values filled in. So at the end of the CSS-style computation, every single one of the DOM nodes has one of these forms attached to it that's filled in, that says what it should look like. But there's still a little bit more that we have to figure out. Because we have to figure out how wide and how high things are going to be and where they're going to be on the page. Because CSS you can say is fifty percent, and that's not very specific. So the next step is what takes care of this. And that's layout. In layout, we look at all the dimensions of the browser window, and from that we calculate all of those values - like, something should be fifty percent of the thing that contains it - and we also do things like break up a paragraph into the lines of text that are in that paragraph. So instead of just having one paragraph node in the tree that comes out of this process, we're going to have a node for each one of those lines of text. And the way that the layout algorithm can do this, is it actually knows how wide each character is, and it can actually measure it out and figure out how many lines high it's going to need to be. So, the output of this step is another tree, which in Firefox we call it the frame tree, other browser's it's called the render tree or the box tree. That's the ultimate plan, that's the plan that tell us what this should look like on the screen. So now, we can move onto the next part.

[00:11:38.12] SY: Ok, did you catch that? All those steps we just talked about were still in group one! Turning your HTML into a blueprint. We started with the HTML that we wrote, turned it into a tree - that's actually called a DOM - then we went to each little node of the DOM and gave it a form, all of its styling information. Then, we made a new tree that describes where everything goes. The layout. And that's how we get our blueprint.

[00:12:01.27] LC: Which is actually turning that plan into the pixels that show up on the screen. And so there are two steps in this process, but before I get into the details of that, I want to talk about what that actually means, when you're turning something into pixels on the screen. You can think of the screen like a piece of graph paper. It has lots of boxes that are in rows and columns, and when you're rendering, what you're doing is filling in each one of those boxes with a single color. And of course, there's not actually graph paper, you're not actually going in with a marker and coloring in graph paper in your computer. Instead, what is actually in your computer is this part of memory called a frame buffer. And in that part of memory, each one of the slots in that memory, it corresponds to a pixel. So what you do is you put a color, like the RGBA value for a color into that part of memory that corresponds to the pixel. And so that's what's going to end up being shown on your screen. So the way that the screen gets it is it checks that part of memory, every sixteen milliseconds it will check to see what's in that memory, and whatever's in that memory at that time that it checks is what shows up on the screen. But we don't just have to fill in this memory once for a web page - we actually have to fill it over and over and over again. Every time we have interactivity or something changing on the page, you're going to need to change what's in that memory. So, even if the user's just scrolling or highlighting something on the screen, so even if you don't actually have any interactivity in your site, they can still be changing the pixels that are on the screen, so that means that the browser's going to have to fill in that part of memory again. And of course, it can take a long time to fill in this, because if you have a big display, then that's going to be millions of pixels, like a huge piece of graph paper.

[00:13:57.04] SY: That's what I was thinking, like that seems like a lot of work.

[00:13:59.16] LC: Yeah, it's a ton of work, so it can take a really long time, and because it can take such a long time and you have to do it so often, browsers have tried to find ways to make it faster. So one way that they've done this is by splitting up what gets shown into multiple different layers, and you can think of this like the layers in Photoshop, or I like to think of it like old-timey animation with onionskin layers, like Looney Tunes. You have the background on one layer, then you can have characters on another layer that lays on top, and then the background layer can just stay the same, and just the top layer needs to change when the character moves. So the first step in this process is painting - it's called painting. It's where you actually create these layers, and that just means filling in other parts of memory that are outside of the frame buffer with these pixels. And then the next step is called compositing, which is where you take these layers and you put them together. Basically you're just laying them on top of each other. Then you basically take a picture of that, and that's what you put into the frame buffer and then the display will pick that up. And that's how the page gets rendered - that's the end of the process.

[00:15:08.07] SY: Ok, so of all of those different parts and pieces, is there any particular stage where it is particularly difficult or takes a lot of computational power from the browser?

[00:15:24.00] LC: You know, I'm actually not sure which one of these is the most computationally intensive and probably it does change based on sites. It can be wildly different. I think I've heard that Amazon is very style and calculation heavy, that's why you want a profile when you are building a site, to see where your particular pain points are, where you're spending the most time. And a lot of browser dev tools will actually show you this breakdown of style computation and painting and they'll actually give you the detail to be able to see where exactly you're spending time. But it's also changing as browsers evolve, so one of the things that we're doing at Mozilla, I mentioned that we've been working on Firefox over the past year. We're trying to make it radically faster, and so to do that we've actually be radically changing the way that things like style computation works and the way that painting and compositing works. We've been trying to work with modern-day hardware better, because there's this thing called Moore's Law, and that's the reason why we've been getting major speed increases in computers over the past 60 years. But it's coming to an end. It's just coming to physical limits where we won't be seeing these performance improvements. But the way that computers are going to continue to get faster - because we still want that computational power, we still want computers to be getting faster - the way that's going to happen is by actually adding what are called more cores. Basically, a core is kind of like a brain, and so if you add more cores to the computer, it can think more independent things at the same time. And so we are making use of these cores in a new way with our newest version of Firefox, which is Firefox Quantum, which is coming out in November.

[00:17:19.14] SY: So, when we talk about different browsers - obviously, you work on Firefox, but there's Chrome, Safari, there's a bunch of different browsers around. What are the differences? Do they render things differently, or use different algorithms? Aside from the visual differences, of oh, I put my tabs on top versus going vertically, are there computational differences in how they render websites?

[00:17:48.24] LC: Optimally, they all have the same end result. That's why we have web standards. So the developer can have HTML and CSS that shows up the same way in every browser. That's not always true - that doesn't always actually happen, because there are different rendering engines for the most part. There's been a lot of cross-pollination, there's been a lot of borrowing of ideas from one browser to another, but at the end of the day there are different code bases so sometimes they have different bugs. Most of the browsers have their own rendering engine. We have what's called Gecko, and we're also working on one called Servo, which is we're pulling parts from Servo into Gecko as part of this project Quantum that I was talking about. So, Edge - Internet Explorer became Edge - Edge has Edge HTML. The one in Safari is called WebKit, and that one was actually the base for the one in Chrome, Chrome used WebKit when it first came out, but then it split, it forked off, and that became Blink. So, all of those have their own rendering engines, so they'll have their own bugs. So, Opera actually uses - I think it's Blink that Opera uses. So, Opera and Chrome would have some of the same bugs when it comes to rendering.

[00:19:00.20] SY: So, when you think about the ending of Moore's law, so to speak, how do things like new frameworks and specifically new JavaScript frameworks and new technologies, how do they impact the decisions you make when you're thinking about how to construct the browser, how to make it faster, is it influenced by new frameworks and new ways that we build websites?

[00:19:24.27] JC: So, I'd actually say that the influence is kind of going the other direction. The change in architecture of computers is actually influencing how JavaScript is evolving. One of the things that browsers started putting in this summer was called SharedArrayBuffer, and that's a way to share memory. I talked about how we have different cores, are kind of like different brains? SharedArrayBuffers are a way to share memory between these brains. There's also been some talk - the folks on the WebKit team have actually talked about doing what's called multi-threaded JavaScript. And then there's also this thing called web assembly, which Mozilla - we had this thing called asm.js, it was a way to take C++ code and other languages where you can do multi-threaded code, and compiling that to something that would run in the browser. And so there's web assembly in browsers too, that also happened this year. So we're seeing more and more of a transition to being able to do multi-threaded either JavaScript or web assembly, because the JavaScript engine now supports web assembly. So they kind of fulfill the same role.

[00:20:42.09] SY: So let's talk about that a little bit. What are the benefits of multi-threaded JavaScript?

[00:20:45.26] JC: So, with multi-threading, you can actually make use of those multiple brains I was talking about, those multiple cores. Basically, when people talk about parallelism, they're talking about using all of the cores on your machine. And of course, when you're doing two things at once, with two independent brains, things are going to go faster. So that's the benefit that multi-threading brings.

[00:21:10.08] SY: So what does that mean for me as a web app developer? Let's say I'm making a to-do list, or something simple like that, or maybe an Instagram clone for my projects so I can learn to code and be a better developer - is that a situation where multi-threading really kicks in, or is there a particular domain where it becomes really valuable?

[00:21:33.24] JC: Well, optimally you won't actually notice it, you won't actually have to worry about it. But the framework developers would be the ones to take advantage of it in the frameworks. I actually gave a talk about what web assembly means for React over the summer -

[00:21:48.23] SY: The link to that video is in your show notes.

[00:21:49.02] JC: And that talks about how the React core developers could start doing things in parallel, in React itself.

[00:21:56.15] SY: So has that become really valuable, or as a developer, would I notice things like that if I were doing machine learning, or something that involved doing a lot of data crunching?

[00:22:06.09] JC: Honestly, we think that there can be benefits even just for regular web apps. We think that you could parallelize the reconciliation algorithm and do other things in parallel so you could render the webpage faster. But for sure, with machine learning, I think actually most machine learning already is parallelized because you really need that performance in that case.

[00:22:30.10] SY: So as you were talking, we mentioned hardware a bunch of times, because we were talking about CPUs and GPUs and cores and stuff - that's talking about the actually, physical computer itself. Is having a bunch of cores, is that ubiquitous enough that everybody can take advantage of these really cool changes in the browser, or does it only really matter if you have a really powerful machine?

[00:22:55.03] JC: Almost all machines at this point are going to have multiple cores. Now, if you're talking about a phone, it might only be two, a lot of phones at this point are all moving to four or to six, and laptops, you're probably looking at four, usually. You can get up to, I think, eighteen cores is the most that you can have in a CPU for like a consumer-grade CPU. There's also another part of the hardware that I didn't mention called the GPU. The cores on a GPU, they're a little different, they're more what's called lightweight, they can't really work as independently as the cores on a CPU, but there are a ton of them - you're usually looking at like five hundred and twelve or over a thousand cores. So, GPUs are actually getting bigger and bigger and bigger as things are getting smaller in the chip, the hardware manufacturers are actually starting to expand the GPUs more and more. And so that's one of the things we're actually trying to do in Firefox Quantum, is make better use of the GPU too. We have a project called Web Render, which is moving a lot of that painting that I was talking about - which right now happens on the CPU - moving that over to the GPU.

[00:24:03.09] SY: So, how did you personally learn all this stuff? Because I know you are working on Firefox, you're doing it as part of your job, but I assume there's a point where you have to sit down and research, you were a browser newbie as well, right?

[00:24:15.12] JC: For sure, yes. I would say that it's only been very recently that I had anything more than a very hand-wavy understanding of how this all worked. I'm pretty lucky that in my role in the company, I can basically ask the folks that are working on these subsystems to sit down with me and walk through the code with me. So, it's a privilege and it's something I wish everybody had access to, because it is super helpful. But you can get a lot through going through old conference videos, there are folks like Jake Archibald at Google, Greg Wentworth at Microsoft - a lot of folks, Dave Baron from Firefox, who have given really good talks about how this works.

[00:25:01.28] SY: So, how much of this stuff is important to know as a developer, and nice to know as a developer?

[00:25:10.08] JC: I would say that almost all of it's just nice to know. For pretty much all of my web development career, I did not know these internals, and I was doing just fine. But now that I do know the internals, it really helps so much with understanding exactly why the thing that's not working the way I think it should is not working the way I think it should. And it really solidifies your understanding of those details.

[00:25:35.17] SY: So, I'm wondering, are there things that you see developers - whether they're newbie developers, or senior developers - that they do in their HTML or CSS, that makes it unnecessarily difficult for the browser?

[00:25:50.03] JC: So, one thing that actually is kind of challenging, not necessarily for Gecko at the moment, but for Servo, this other engine that we're working on that's fully parallelized, where we're doing layout in parallel too, is floats. So, when you have something that's parallel, you really want siblings to be pretty independent of each other, where they don't affect each other, because then you can impute them in parallel at the same time. But when you have floats, of course, you are affecting your siblings. In that case, in Servo, we actually have to start going sequential, and so that slows things down a bit.

[00:26:27.03] SY: That's interesting. So, using like Flexbox would be better?

[00:26:31.03] JC: I believe that Flexbox can still be parallel, and I believe grid is the same.

[00:26:35.01] SY: Very cool. I'm very impressed with the browser now. I don't really think of the browser as a coding tool. I think of it as the thing that shows my stuff. It's very easy to not really appreciate it, but after this conversation, I have newfound respect for browsers.

[00:26:53.26] JC: Well, I'm very happy to hear that.

[00:26:55.07] SY: If I'm on a team of developers - usually a product team or dev team - there's developers, designers, there's a PM, there's a few different people with different roles - is there anyone who should be purposefully thinking about the browser, or does this information fall under a certain job title or skillset? Would you consider this maybe part of web performance? Or how does this fit into the ecosystem of coding?

[00:27:22.12] JC: Yes, it probably falls under web performance - a lot of this stuff that I was talking about.

[00:27:27.05] SY: And for more on web performance, check out Episode 7 of Season One with Laura Hogan.

[00:27:32.21] JC: I was focusing a lot more on performance with some of the stuff I was talking about. There's also correctness issues of having the CSS show the right thing, and of course that would fall under your CSS developer, whatever title they have.

[00:27:44.11] SY: Coming up - we switch gears from browsers to cartoons. After this. (Music.).

[00:27:50.15] Getting a job is one thing. Building a career is another. With Dice, you can do both. They've been helping tech professionals advance their careers for over twenty years, which means they have a ton of data and tools to help you navigate yours. Looking for a job right now? They've got thousands of positions available from top companies, like AT&T, Dreamworks, Adobe, IBM, and Dell. Wondering what's next in your career? Use their career pathing tool to find new roles based on your profile and see how much more money you can make. Not sure if you're getting paid what you're worth? Use the dice salary predictor to see real numbers on what your skills are worth. Don't just look for a job - manage your career, with Dice. For more info go to dice.com/codenewbie.

[00:28:30.08] Choosing a boot camp isn't just about the curriculum. It's about the connections that program has to job opportunities, resources, and the local community. This is why you should check out DigitalCrafts. They've got campuses in Houston, TX and Atlanta, GA - the fourth largest tech hub in the US. That means plenty of networking opportunities and neighbors who understand what you're going through. In addition, students and alumni alike - they call themselves builders - get access to rotating elective classes in the evenings, so you can keep learning even after you graduate. They cover skills and topics like UI and UX design, CS fundamentals, and iOS mobile development. A great curriculum - and a community is essential. So check out digitalcrafts.com for a schedule of upcoming classes. They've also got a great list of resources that you can start prepping on your own. Their upcoming cohorts start in early November, so check them out at www.digitalcrafts.com.

[00:29:21.17] One of the most important features of any app is talking to your users, whether it's an email notification, a password reset, a new user welcome, emailing your users is an essential part of the app experience. Which means, you need to pick a reliable email service provider you can count on. SparkPost is the world's most reliable and fastest-growing cloud email provider. They're built on AWS, and trusted by the world's biggest senders to deliver unmatched uptime and resilience. And they're great for developers like you! They've got an amazing resting API to fit right into your app, or you can use plain SMTP. So check out SparkPost, at pages.sparkpost.com/CodeNewbie. Link is in the show notes.

[00:29:58.29] So, the other thing that you do that I absolutely love, is you draw! You make these cartoons about different coding topics. What are some of the topics that you've drawn about?

[00:30:09.27] LC: So, I started off with a lot of things in the React ecosystem, so I did things about Flux and Redux and Relay, which are all ways of handling data in React applications. I've also talked about React's internals, so the new fiber reconciler - I gave a talk about that at the React Conf this year. I've also done a lot of browser stuff, so I've written about web assembly, which I mentioned before. It's a way of taking languages other than JavaScript and making them run in the browser. I've written about things like SharedArrayBuffer, which I've also mentioned before, a way to share memory between threads in JavaScript. And more recently I've been writing about these browser components that we're replacing. So the CSS Stylo engine, I wrote a blog post about that about a month ago, it's called Stylo. And that was really fun because I got to dig into exactly the optimizations that we're using to make it really fast. And now I'm working on one about the rendering, the new way we're going to do painting and compositing in Firefox. I'm really excited to figure out what I'm going to be working on after this.

[00:31:13.27] SY: So it sounds like a lot of the cartoons that you make are related to the job and the work that you're actually doing. Is that fair?

[00:31:22.13] LC: Yeah, well, I actually started Code Cartoons before I joined Mozilla. I was looking for a topic to do a talk at BrooklynJS - I was friends with a lot of the organizers at that event, it's a great event - so I thought, I really want to learn Flux, and I started reading up on Flux. As I was reading, it really seemed to me that the different parts of this system were having conversations with each other. So that's actually where Code Cartoons came from - I figured I'll just make this into stick figures so that other people can see this too and understand it. And it went over so well, people told me how much better they understood Flux because of that. That was what actually got me really started with Code Cartoons.

[00:32:06.01] SY: So what I find really interesting about the cartoons that you draw is unlike a traditional zine, it's not just illustrations. You have illustrations, but you'll also mix it up with more traditional paragraphs and just actual text. I imagine that could be a little bit harder than writing just a zine or just a blog post, because you have to decide what is worth illustrating, and at what point does it make sense to write a block of text and at what point should I bring in a picture. So, when you're thinking of the overall structure of the cartoons, how do you do that? How do you figure out what to start with, when to bring in words, when to bring in a picture - what's your process for that?

[00:32:47.22] LC: It's a very long process. Basically I consume a lot of information and I take lots of walks, I meditate on it a lot, I wait for the metaphors to come to me, and then I'll put them on post-it notes on my wall, in kind of a random order - with a little bit of a structure to it, but not totally structured. And it's actually - I will dictate the posts most of the time. I'll start talking as though I were talking to somebody and explaining to them how this thing works, and I find that this helps me keep the sentences short and to the point and when I'm writing I can get a little bit over-analytical, but when I'm talking I find that I make it more human. So I'll actually record it and then a lot of times I'll transcribe that and then work from there. At that point, then I go through and reread it, and I have a stack of post-it notes next to me, and I'll draw out a sketch wherever I see I've introduced a new metaphor or something like that.

[00:33:49.09] SY: Very cool! I figured that it was a process, because they're just so good that you can't, it sounds like you can't really rush something like that. But wow, those are a lot of steps. How long does it take, say, on average to make one post? How many hours would you say goes into it?

[00:34:04.02] LC: It's a lot of time. I don't know how many hours - I think that the Stylo post which was actually - I'm getting faster as I go, so this most recent post probably took two and half weeks, but I've also been thinking about it in the back of my mind for two months before that.

[00:34:21.07] SY: Yeah, this seems like the kind of thing that's really good just to meditate on and let it sink in and marinate and see what flavors comes out when you're done.

[00:34:29.26] LC: Exactly.

[00:34:33.11] SY: So, tell me about your process for actually creating the illustrations. Do you use Illustrator or Photoshop or something else?

[00:34:40.24] LC: I use Photoshop -

[00:34:47.28] SY: Really?

[00:34:47.28] LC: 'Cause Illustrator, it makes all of the curves smooth, and I feel like it doesn't have the character then.

[00:34:51.12] SY: So when you think about how to structure a blog post in general, we highly highly encourage people to blog and to share their knowledge, not just to be a really great community member, which is important, but also because when you are forced to structure your thoughts in a way that explains it to readers, then it reinforces your own knowledge. So in the process of you creating your own code cartoons, what are some tips and best practices that might be helpful to others writing their own blog posts?

[00:35:23.04] LC: So one thing that I do is I try to make the problem the first thing I talk about. If it's something that rolls out over time, where there have been multiple changes to the browser, I try to introduce the first problem, and the solution and address that, and the problem that you saw with that, and the solution to that. This is actually something that I worked a lot with my intern to show her how to do and she said that it's made her writing so much better. Another thing that I worked with her and that I do a lot myself - I go through and try to break up any large words that I have, any SAT vocabulary, I try to break that up into the most simple, small words that I can. It's not just for people for don't necessarily know those words. It's also for people who know those words but are tired or have divided attention. The more you can reduce the cognitive load, the more it's going to stick.

[00:36:17.17] SY: So how long did it take for people to catch on and find out about these Code Cartoons? Because one of the issues that we see in our community is people say, I'm really excited to write, but how do I know if anyone's reading it? How do I get people to notice that these even exist? So what's that audience growth, I guess - what was that part of the process like for you?

[00:36:38.16] LC: I was pretty lucky. It took off like wildfire to start with, with the first post that I did about Flux. And I've done a number of other projects that have not been this successful, so if you look the arc of all of my projects, it's not that I was immediately successful, but this project was immediately successful. I put that on Medium and two days later it was on Hacker News on the front page for a good portion of the day, so I had something like thirty or forty thousand views that day. And then it has just kept going from there. And to be honest, working, having blog posts that are running on the Hacks blog at Mozilla has also helped people find it, and I've also written for Smashing Mag, so having these avenues where I'm getting it out outside of my own blog, that helps. To be honest, my own blog is terribly out of date at this point - I need to actually change the site so that it references some of these other things that I've been doing since then.

[00:37:41.04] SY: Yeah, that reminds me of Quincy Larson, the creator of Free Code Camp, we had him at CodeLand, our conference, to talk about technical blogging best practices and how to get started and all that. And that was one of the things he said, he said don't just post on your own stuff and just assume people will find it, but also promote it in your talks and mention it in a podcast interview or see if you can get it on the company blog, and finding other outlets to share your work really, really helps people find it.

[00:38:06.15] LC: Definitely.

[00:38:09.20] SY: We actually turned that talk into a podcast episode - you can listen to Quincy's talk on technical blogging on Episode 146, there's also a video of that talk on YouTube. Links to both are in the show notes. So, I'm wondering, especially since you said it was on the front page of Hacker News, did you get any negative feedback?

[00:38:25.12] LC: I get occasional negative feedback, but I think that this is one of those cases where explaining it so very plainly actually helps, because I think a lot of negative comments come from people actually not understanding. So they will jump in and attack their figment - the straw man that they see. So by making it so very plain and clear, I think that removes a lot of the ability for people to jump in and harp on their misunderstandings.

[00:38:58.05] SY: So, next let's do some fill-in-the-blanks. Are you ready?

[00:39:00.20] LC: Yes, I am.

[00:39:03.05] SY: Number one. Worst advice I've ever received is?

[00:39:04.16] LC: One bad piece of advice that does stick to me - I was a few years out of college, and I was being recruited for a research institute. They had this funded Master's position open and it was in a research area that I was super-interested in, but I had to move to a different country. So there was someone in my life who tried to convince me not to do this, and the reason that they had was - I had already ticked off a lot of the boxes of what you're supposed to do after college. I had this pretty nice life set up for myself, so this person thought I was going to be throwing this life away by moving to a different country and completely changing things. But fortunately other people in my life, the people who were directly impacted by this decision, they were supportive, and they didn't try to push against this advice. So I ended up going, and I spent two years doing this research Master's in another country and it opened up all of these opportunities for me. I was able to contribute to W3C Standards and I was able to become a core module maintainer on a big open source project. And if I hadn't taken that risk, if I hadn't actually moved to another country and gone to this research program, then I don't think I would ever have those opportunities. You know, some people might hear that story and think that the take-away is that you should ignore advice, that you should ignore the advice to play it safe, and I don't think that's the right takeaway, because I think it is actually good to play it safe sometimes, but I think that the right takeaway is to cultivate self-awareness. Because when people give you advice, they're basically laying out a strategy to achieve the goals that they would have if they were in your position. But your goals are very likely to be different from theirs, even if the differences are subtle, and so when I get advice, what I do is I try to figure out what the goal would be, if I were to follow that advice, and figure out if it actually does match my goals. And so the only way you can actually do that is if you have a self-awareness of your own goals and your own values.

[00:41:08.20] SY: Absolutely, yeah. That's one thing that I've been very careful, especially with CodeNewbie. There are lots of people who have lots of opinions, especially on what I should do and how I should do it and all that, but at the end of the day, if our goals aren't aligned, especially if we don't share the same values or general world view, then a lot of that advice doesn't really matter. Number two - my first coding project was about?

[00:41:33.03] LC: My first coding project - I taught myself C++ in high school, and it was probably something during that process, but to be honest, I actually can't remember what the project was, so that's probably not too interesting. But the way that I started teaching myself C++ is a more interesting story. I had heard that there was an AP CS class at my high school and that it was one of the best classes in the school, so I wanted to take it, but I hadn't taken the prerequisite computer science class, and so I told my parents about this and they had actually been software developers - they had created their own software company in the 70's, so they knew that you could teach yourself how to program. And they were trying to get me to do that, to teach myself C++ so I could jump into this, but I was still pretty inexperienced and I didn't think that I could do it. I didn't have faith in myself. So, then, you flash forward a few months - my parents had to go out of town because my sister was in a different state and she needed to come home for the summer, and I was taking the SATs that weekend so I couldn't go with them. And of course, if you're an American teenage, what pop culture teaches you to do as soon as your parents leave for the weekend is to throw a party. So, I threw a party but then immediately as soon as my parents got back, I confessed everything that I had done.

[00:42:54.15] SY: You broke the rules! (Laughs)

[00:42:58.05] LC: Yeah.

[00:43:00.18] SY: Did you get in trouble?

[00:43:00.27] LC: Well, so that's the thing. Instead of punishing me, what they did was they used this as an opportunity to force me to teach myself C++ over the summer.

[00:43:09.25] SY: (Laughs). Those are awesome parents!

[00:43:10.17] LC: Yeah, that was how they grounded me. So I ended up getting into that AP CS course and I ended up getting a 5/5 on the exam, so I got to skip class in college. So what that helped, was it helped me see that I shouldn't limit myself and think that if I haven't taken a course in something, I couldn't be good at it. Like, I could teach myself whatever programming skills I needed to learn.

[00:43:31.17] SY: Wow, I love how that one party changed the directory of your whole life.

[00:43:37.16] LC: Yeah, my parents, they were pretty progressive in their punishment style.

[00:43:42.18] SY: That is awesome. Wow, that really changed your whole life. That's so cool. Number three - one thing I wish I knew when I first started to code is?

[00:43:51.24] LC: So, I was thinking about this - earlier in my career, I would look at languages that I should be learning to put myself in the best position, and I wish that I knew at the time that what you should really look for is the community around the language. Is there a community that you want to be a part of, people that you want to be around. Because if you find the community of people that you really enjoy being around and who share your values, you're going to be really, really motivated. So you'll find yourself spending a lot of time learning about all of the things that they are working on and collaborating with them and teaching yourself stuff so you can have interesting conversations with them. Because you want to spend time with these people. And that's going to accelerate your learning so much - it helps you level up your skill so much more than just the raw willpower of banging your head against technical documentation.

[00:44:41.06] SY: I love that - that's probably one of my popular answers when people ask me what programming language that I learn, I say, well, look at the community. For the reasons that you said, which is - are these people that I want to spend time with, what do the communities value, but also, usually, if there's a very beginner-friendly community, it means there are more tutorials and more resources and more books and more accessible - both free and cheap and understandable - material for you to level up as well.

[00:45:09.16] LC: Exactly.

[00:45:10.18] SY: Well, thank you so much for spending some time with us and sharing all this awesome knowledge. You want to say goodbye?

[00:45:14.27] LC: Well, thank you very much for having me, and goodbye, I hope that you all really appreciate the browser now.

[00:45:21.25] SY: Definitely. And that's the end of Episode 2 of Season 2 - ooh, two-two. So let me know what you think. Tweet me @CodeNewbies, or send me 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 interaction, look us up on meetup.com. For more info on the podcast, check out www.codenewbie.org/podcast, and join us for a weekly Twitter chat. We've got our Wednesday chats at 9 PM ET and our weekly coding check-in every Saturday at 2 PM ET. Thanks for listening, see you next week.