Special Guest: Carl Mungazi.

Hey folks, I'm a super busy guy and you probably are too. You probably have a lot going on with kids going back to school, maybe some new projects at work. You've got open source stuff you're doing or a blog or a podcast or who knows what else, right? But you've got stuff going on and if you've got a lot of stuff going on, it's really hard to do the things that you need to do in order to stay healthy. And one of those things, at least for me, is eating healthy. So when I'm in the middle of a project or I just got off a call with a client or something like that, a lot of times I'm running downstairs, seeing what I can find that's easy to make in a minute or two, and then running back upstairs. And so sometimes that turns out to be popcorn or crackers or something little. Or if not that, then something that at least isn't all that healthy for me to eat. Uh, the other issue I have is that I've been eating keto for my diabetes and it really makes a major difference for me as far as my ability to feel good if I'm eating well versus eating stuff that I shouldn't eat. And so I was looking around to try and find something that would work out for me and I found these Factor meals. Now Factor is great because A, they're healthy. They actually had a keto line that I could get for my stuff and that made a major difference for me because all I had to do was pick it up, put it in the microwave for a couple of minutes and it was done. They're fresh and never frozen. They do send it to you in a cold pack. It's awesome. They also have a gourmet plus option that's cooked by chefs and it's got all the good stuff like broccolini, truffle butter, asparagus, so good. And, uh, you know, you can get lunch, you can get dinner. Uh, they have options that are high calorie, low calorie, um, protein plus meals with 30 grams or more of protein. Anyway, they've got all kinds of options. So you can round that out, you can get snacks like apple cinnamon pancakes or butter and cheddar egg bites, potato, bacon and egg, breakfast skillet. You know, obviously if I'm eating keto, I don't do all of that stuff. They have smoothies, they have shakes, they have juices. Anyway, they've got all kinds of stuff and it is all healthy and like I said, it's never frozen. So anyway, I ate them, I loved them, tasted great. And like I said, you can get them cooked. It says two minutes on the package. I found that it took it about three minutes for mine to cook, but three minutes is fast and easy and then I can get back to writing code. So if you want to go check out Factor, go check it out at factormeals. Head to factormeals.com slash JSJabber50 and use the code JSJabber50 to get 50% off. That's code JSJabber50 at factormeals.com slash JSJabber50 to get 50% off.

Hey folks, I'm a super busy guy and you probably are too. You probably have a lot going on with kids going back to school, maybe some new projects at work. You've got open source stuff you're doing or a blog or a podcast or who knows what else, right? But you've got stuff going on and if you've got a lot of stuff going on, it's really hard to do the things that you need to do in order to stay healthy. And one of those things, at least for me, is eating healthy. So when I'm in the middle of a project,or I just got off a call with a client or something like that. A lot of times I'm running downstairs, seeing what I can find that's easy to make in a minute or two, and then running back upstairs. And so sometimes that turns out to be popcorn or crackers or something little, or if not that, then something that at least isn't all that healthy for me to eat. Uh, the other issue I have is that I've been eating keto for my diabetes and it really makes a major difference for me as far as my ability to feel good if I'm eating well versus eating stuff that I shouldn't eat. And so, um, I was looking around to try and find something that would work out for me and I found these factor meals. Now factor is great because a, they're healthy. They actually had a keto, uh, line that I could get for my stuff. And that made a major difference for me because all I had to do is pick it up, put it in the microwave for a couple of minutes and it was done. Um, they're fresh and never frozen. They do send it to you in a cold pack, it's awesome. They also have a gourmet plus option that's cooked by chefs and it's got all the good stuff like broccolini, truffle butter, asparagus, so good. And you can get lunch, you can get dinner. They have options that are high calorie, low calorie, protein plus meals with 30 grams or more protein. Anyway, they've got all kinds of options. So you can round that out, you can get snacks like apple cinnamon pancakes or butter and cheddar egg bites, potato bacon and egg, breakfast skillet, you know obviously if I'm eating keto I don't do all of that stuff. They have smoothies, they have shakes, they have juices, anyway they've got all kinds of stuff and it is all healthy and like I said it's never frozen. So anyway I ate them, I loved them, tasted great and like I said you can get them cooked. It says two minutes on the package. I found that it took it about three minutes for mine to cook, but three minutes is fast and easy and then I can get back to writing code. So if you want to go check out Factor, go check it out at factormeals, head to factormeals.com slash JSJabber50 and use the code JSJabber50 to get 50% off. That's code JSJabber50 at factormeals.com slash JSJabber50 to get 50% off.

 

CHARLES MAX_WOOD: Hey folks, before we get started, I just want to let you know about my upcoming book, the Max Coders Guide to Finding Your Dream Developer Job. If you're looking for a job or you think you might be looking for a job in the future and you're trying to up your mobility and meet new people and things like that, this book walks you through the whole process. Go ahead and check it out. It comes out on November 20th. It'll be on Amazon and you can find it as the Max Coders Guide to Finding Your Dream Developer Job. Hey everybody and welcome to another episode of JavaScript Jabber. This week on our panel, we have AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo, coming at you from the snow of Provo. 

CHARLES MAX_WOOD: Dan Shappir. 

DAN_SHAPPIR: Hi, coming all the way from Tel Aviv where it's raining, but still really warm, like seventies, so be jealous. 

CHARLES MAX_WOOD: I was going to say, don't say that again. I'm going to be mad. 

STEVE_EDWARDS: I'm jealous. 

CHARLES MAX_WOOD: We also have Steve Edwards. 

STEVE_EDWARDS: Hello from very cold, clear and windy Portland.

CHARLES MAX_WOOD: Nice. I'm Charles Max Wood from DevChat.tv. And this week we're talking to Carl Mungazi. Did I say that anything close to correct? 

CARL_MUNGAZI: No, that's fine. That's fine. Yeah. 

CHARLES MAX_WOOD: That's fine. That's fine. Means you slaughtered it, man. Go ahead and tell us how to say it right. And then... 

CARL_MUNGAZI: No, that was perfect. That was perfect. 

CHARLES MAX_WOOD: All right. Well, do you want to introduce yourself real quick? Talk about who you are, where you live, what you do, where you work, why you're famous, all that stuff. 

CARL_MUNGAZI: Yeah, sure. So I'm a front-end developer at LimeJump in London, which is a StarTruck in the energy industry. I used to be a journalist actually, so I switched to programming in 2016. Since then, I've just been loving what I'm doing for me in the front end. And lately I've been getting into reading source code and kind of using that to improve my skills in JavaScript and programming in general. So that's kind of what I spend my days doing after work. 

CHARLES MAX_WOOD: Nice. 

 

This episode is sponsored by Hasura.io. Hasura is an open source GraphQL engine that helps you instantly set up a scalable and real-time GraphQL backend. Hasura makes your team super productive by dynamically composing a schema backed by databases and microservices that you can securely query from front end clients. You can check it out at hasura.io to try it out in 30 seconds. Now a few things that I really like about Hasura, one is that it runs on PostgreSQL, which is really easy for me to get set up. It has a core authorization engine that makes the data access secure and doesn't compromise performance. It can also join the other GraphQL services, so if you have microservices or it's as API's like one graph, you can pull them in as well. And finally, they've been working on making it super easy for developers to write custom business logic and rest API's and have Hasura expose them as GraphQL mutations. So go check it out, hasura.io, they're doing really great stuff. 

CHARLES MAX_WOOD: Now, I wanna give a little bit of context here because I remember way back when I was a brand new programmer, I went to a conference and there was a talk there and it was James Edward Gray, who was on RubyRogues for a long time. And he gave a talk on reading code. And so I started reading code a little bit and I kind of got a feel for, Oh, this is, this is a really great way to go. And I, I'd see people do things that, you know, I was like, Oh, I didn't even know you could do that in Ruby or JavaScript or whatever I was learning at the time. So it became this, this method that I use sometimes, especially if I wanted to build something similar to somebody else, I'd go look and see how they did it. And then as I've talked to people over the years, it's become more and more apparent that less and less people are doing it. You know, it's like, well, do you ever go read other people's code? 

CARL_MUNGAZI: Um, no. 

CHARLES MAX_WOOD: And so I'm curious, you know, what's your experience been and, and how did you get into reading code instead of reading books or blogs or watching videos or whatever other people are doing? 

CARL_MUNGAZI: Yeah, sure. So I think for me, it came from having come into programming, not via a course at uni, for example. So I don't know much in terms of fundamentals of, of, of comp sci. So I found that in my first job as a developer, I was struggling to understand some of the concepts that were being used and really finding my way around. And I thought, you know what, let me actually look at the source code for this because obviously at the time we're using a firmware called mithril.js, which is like React, but has a smaller API, smaller code base, and much simpler to use. So I opened up the Node modules folder, looked inside, and I began to read the source code. And because at the time I read it in 2016, I think it was about 3,000 lines of code. So it was one file and that was the entire library. You could actually read from top to bottom, the entire source code. So when I actually read it and then I read the documentation and I began to actually see that actually, even though when you're using the library and you're calling the APIs, it looks like a black box, I actually began to say, okay, actually reading the source code is useful because you understand what's actually happening behind the scenes and actually begin to learn and see how other developers use code and use that to help yourself in your day-to-day job. So that was my entry point into it. 

CHARLES MAX_WOOD: So which project did you start with reading? 

CARL_MUNGAZI: So it's mithril.js is the framework. Yeah. So it's a front-end framework, similar to React, Inferno and Preact. It's more in the Preact and Inferno group because it's very small and it basically is just focused on helping you build fast UIs, performance UIs. So, and at the time as well, I had never understood what the whole virtual drum paradigm was about. And when I read the code for Mythril and also read the documentation, and then also spoke to developers in the community, that actually began to open my eyes. And that actually made me see that actually, I don't have to be scared of going into source code or reading the code that I'm using, and actually using it as a tool to get better at my day-to-day job. 

DAN_SHAPPIR: I think in this context, it might be worth mentioning that Jason Miller, who wrote the initial version of Preact, actually once told me that he wrote it so as to better understand how Virtual DOM works. So yeah, so reading code is one option, and I guess writing the code is another option.

CARL_MUNGAZI: I'm trying to rebuild from scratch different parts of the front end stack. So I'm trying to build a framework, UI framework, build a testing library, a module bundler, and basically going to the projects like Webpack for bundling or just for testing and whatnot, and actually seeing, okay, if I was to build the most basic version of this tool, how would I do so? And so that's now become a step.I basically look at it and say, OK, this is what I want to achieve in terms of the actual problem. So I've got a framework that basically creates DOM elements. And that's using the whole with the DOM  element. So let's say you've got a button. So you pass in an argument for the type of the tag you're going to be using. And then a second argument can be an object which has the attributes for the element and then any child element surrender. And then that basically just spits out a dumb element. I said, fine, if I wanted to test this, how would I do so? I'll go online, look at the source code of other libraries, look at tutorials, and throughout the process, basically bringing together a very basic version of a tool which I use every single day. And in doing so, that actually helps me a lot to understand that, okay, underneath all of this that I'm doing, these are the concepts I need to be burying in mind. And these are the ways that I can actually use this tool to my benefit and to make my coding better and my applications better as well. 

STEVE_EDWARDS: I come at this from a different standpoint. I think a good way to illustrate this is with a language. So I'm a Spanish speaker. And the way I learned Spanish was initially in high school. Took a couple years of high school. And where you sit down and learn, here's verbs, here's how to conjugate verbs, here's the different forms. You know verb forms for past, present, past imperfect, past perfect, so on and so forth. And then after I had all those tools when I was in college, I went and lived in Mexico for a while and was able to put it all together and speak really pretty fluently. But the other way that I hear of learning a language that some people do, and I don't think I could do this, is they don't know any Spanish, but they'll take a conversational Spanish course. You know, we just come in and here's some phrases you can use and here's common phrases, where to put together sentence and that kind of stuff. But it's like you're just learning the top level without knowing the basic structure of the language underneath, and that would drive me absolutely bonkers. I cannot like Spanish because in a conversational Spanish class, I'd be thinking, okay, so why does that verb form work here? Why is it structured that way? Why do you have to use this specific way here, but this specific way here? So for what Carl's suggesting, is heaven for me. It's the way I try to do things. Go in, read the code, understand what it's doing. Because like any tool, once you know your tool, then you can use it so much better because you're going to find out, oh, wow, we can do this. I didn't know you could do this. Or yeah, you can do this. I didn't know you could do that. And it just gives you that much more flexibility. At the same time, you know, I started in IT, my first job really was a troubleshooting tech support type role where dealing with AS 400s and mainframes and, you know, code, this is back in the Windows, when before Windows 95 actually. And what I found was the better I knew my tool, the better I knew the intricate details, how something was working, how it should be working. Then I could compare when something wasn't working and I could tell right away, okay, here's the problem. This is how we need to fix it. And so what Carl's doing here and talking about is knowing the small details on how it works. And that gives you so much more power in using and extending it, but also being able to troubleshoot and figure out when something isn't working the way it should be. 

CARL_MUNGAZI: It's fun actually, because I learned Spanish by doing the method you say would be hard for you. So, yeah, a few years ago actually, I came across a YouTuber, I forget his name, but what he advocates was you basically, take your target language and then you pick a phrase and then you learn many phrases and over time, you're able to speak the language, even though you don't understand the grammar maybe. So for me, that approach actually worked because then when I went back to learning the grammar, it made more sense to me because I had a context where the word had been used before, as opposed to coming at it, calling and saying, okay, this is the grammar for this sentence and then after trying to use it as opposed to doing another round. 

STEVE_EDWARDS: Yeah, I could see that working, but that would just be very frustrating in the beginning for me because I'm like, why does it do that? And then, then you can come back and yeah, okay, now you see how it all fits in later. Yeah. 

CARL_MUNGAZI: When I think developers have been coding for a while or maybe even a while, and then you actually decide, okay, let me actually see this tool that I'm using, what's the code underneath it. And you see that, okay, sometimes the authors tend to leave comments as well. So I remember I was doing a deep dive in React DOM, that render method, and I came across a section where it's talking about how React does updates, and then it talks about how basically the updates are in a linked list. And you have the current UI in a tree of objects, and then it's comparing that with the changes you've made, and then it creates a new tree of objects, which is going to be the future. And so for me, that was quite nice actually to see that way. I know linked lists as a concept in general, but React actually has a use of it internally. And that for me was like, wow, okay. And that kind of encouraged me to actually read more into libraries and seeing what are they doing to actually achieve their aims. 

DAN_SHAPPIR: So you actually read into the React source code in that case? 

CARL_MUNGAZI: Yes, and it was an interesting journey because as you can imagine, React is a massive project. So it required basically putting a whole lot of breakpoints in the browser and then creating a very, very simple, basic toy application that basically rendered a div, and that was it. And then I would basically say, fine, when this is rendering, what's the earliest part of the code looking at the code stack? And then going through the code, finding out, OK, in this function, What's the structure like? What's the intention of this function? If I change the code like this, how will it behave? And yeah, that was the process. And then I wrote a, an article about that, which had a lot of, um, response from, from people because I feel like developers want to be able to understand the internals of these tools, but it can be quite intimidating because you feel like it's so complicated and so complex. So surely I can't understand it because the people that have built it probably have so much experience and so much more than I do in terms of knowledge and ability. But I think if you actually are determined to look into it and have the time and the patience decide, okay, I'm going to actually understand how this tool works, then yeah, there's no reason why. You can actually read through the source code and actually get to the bottom of why that function you're using works the way it does.

DAN_SHAPPIR: It's very interesting to me what you're saying because you know, I got into web development early enough. So back in the day JavaScript code usually was fairly small I mean if you wanted to learn how to do a rollover effect Then you just basically found a website that did a rollover effect did view source It was like ten lines of JavaScript code you copied it over adjusted it a little bit and job done so that was literally the way that we learned how to write JavaScript code in the early days of the web. But like you said, if we're looking at modern libraries these days, they're often like, you know, really huge and complicated with sophisticated algorithms. And while they do have some comments and are available, let's say on GitHub and whatnot, it's still definitely not trivial to work your way through the code. So if you've got like you made some awesome suggestions about maybe writing a very simple application that uses that library, and then single step into that library. But still, with some of the more sophisticated frameworks and libraries out there, it's not such a trivial process. So any other suggestions that you can make regarding that? 

CARL_MUNGAZI: Yeah, it's fundamentally, like said earlier, you basically start with a very basic application, right? And then you need to pick a method. So for example, you could try doing a search in the GitHub repository and seeing, okay, where is this method called? And then working out, okay, is this actually a test file, for example? Because you might see that method in a test file, or is it a main file? But usually, it's a case of opening up the source in Chrome, and then putting a breakpoint where you call the code yourself in your application. And then hopefully you have a call stack, which then you can use to find, to step back and see, okay, this is the first thing that happens for me to get to this stage is in this line, in this function. And usually that then tells you, okay, so this is the entry point for the application. So when I did the work I did with, with, with my, um, react DOM that render method, I saw that I saw that, okay, fine. The function that actually is the step before render takes in more arguments than I give it. And then from there, I just step through the code. But it's basically being able to identify, one, the method you want to use, and being and saying, OK, I'm going to focus only on this method. You then look at the call stack and work out, OK, the entry point for this route to my calling of this code is this function. And then you start from there. And then after that, it's basically being patient enough to actually step through the code, because there'll be times when you will go through a rabbit hole and you find that actually, no, this is the wrong path I've taken. And then you're gonna come back slowly to where you were before. And it's one of those skills that the more you do it, the more you see patterns in how the libraries are structured and how they're called in terms of how authors package their tools. So more recently, I was doing work on creating a very basic module bundler, and I used the Parse or JS source code for that. And as you can imagine, it's fairly complicated, it's fairly complex, and also it runs in the command line. So you haven't got the benefit here of running it in the browser. But because I had the context that I had gained from my React inquiries. When I came to Parcel, I was able to apply those same methods. And also, sometimes you can also even approach the authors of the framework and actually ask them, hey, I'm looking into your framework and I'm learning about this particular method. Can you tell me how that works? I had a good chat online, actually, with one of the maintainers of React Redux. He commented in an article I had written for a blog, and I'd used the connect method in Redux as a case study. And from that, he sent me a link to his blog, where he actually went in even more depth into the method I was looking at and in general about Redux and Reactant and how that works together. So yeah, it's just kind of being diligent and having the patience and also being able to approach authors because, you know, you were surprised. They're very approachable, especially on Twitter or via email. You just basically say to them, hey, I'm looking into your tool. Can you give me a hand? And most times, they'll be more than happy to give you a hand and help you out in what you're doing. 

DAN_SHAPPIR: So when you're saying that you're you know, when we're saying that we were reading source code, it's not just, you know, going into GitHub or something like that and looking at the source code. It's a much more, let's call it, active approach of debugging, single stepping, putting in breakpoints, checking the stack, and so forth. And I guess the fact that with modern dev tools, you also get a stack trace across asynchronous calls. That also helps a lot. 

CARL_MUNGAZI: Yes, definitely. It has to be active, because if it's passive, you won't have any context to, OK, I mean, the code on GitHub and the code you might have in your application is different, because obviously, once in GitHub, it's being developed. And then when it's packaged, it's going to be maybe in one file or in one folder in a couple of files. Whereas when you go to the actual, get up to this code is different. So yeah, it needs the developer to be active in doing so. Basically using tools like you mentioned with the debugger on Chrome, putting in breakpoints and letting the code kind of lead you in terms of, okay, I can see that at this stage in the code, this is happening. And then asking questions as to why. And also crucially, being able to actually change your code to say, okay, If I give it this argument, what's going to happen instead of this? Because if you just step through the code and you read it and then you, and that's it, you don't learn much because you are not actually being active and being involved and actually trying to see. Cause in our, in our jobs every single day, we're given a task to solve. Maybe let's say at work, you've got a task to do, and then it's your job to then go away, do your research and actively develop that tool or that feature. And that process, that same mentality can be shifted into learning how to read source code. Because when you do so, subconsciously, you are reading lots and lots of really well-written code. So I found that when I compare how I write code now to before I started, it's so different. And even how I think about code is different, because I've been exposed and continue to be exposed to other developers' code. And this is code which has been seen by many people across the world and has been refined over time. So it's actually a case of learning almost by, as most as it's absorbing all that you're seeing. 

DAN_SHAPPIR: So in terms of code quality, which framework or library do you like the best? 

CARL_MUNGAZI: Yeah, that's the question, isn't it? Yeah, so it's funny because this journey has kind of turned me into one of those developers who basically is all about just having plain JavaScript, vanilla JavaScript. And as a result, I like Mythril. One, because when I started, it was so accessible. And even now, it's a very small code base. So being able to understand where things are structured is very  for the DOM, you've got the native stuff, and you've got the other platforms as well. It's a big beast. And that makes it kind of hard to grok initially, but I've kind of fallen into the camp where for me, I like to see a library that has as little code as possible, if that makes sense. 

AJ_O’NEAL: Hey, I'm right there with you. I love it. 

CHARLES MAX_WOOD: Doesn't shock me at all. AJ. 

AJ_O’NEAL: I definitely put too much code in libraries sometimes, but no, I, yeah, I like it when fewer layers of abstraction, very, very into the Python Zen. Carl, have you read the Zen of Python? 

CARL_MUNGAZI: I have not. 

AJ_O’NEAL: So open up a terminal. Are you on Mac or Linux? 

CARL_MUNGAZI: Yes, I am. 

AJ_O’NEAL: Okay, so open up a terminal, type Python, hit enter, and then type import space this enter. That's something to print on your wall and keep by you at all times. 

CARL_MUNGAZI: Okay, let's give that a go actually. So you're saying I type in...

AJ_O’NEAL: Just type in Python, hit enter, and then type import space this and hit enter again. 

CARL_MUNGAZI: Import this. Think I'm, I think I'm missing an argument on my end. 

AJ_O’NEAL: Did you enter in the Python rebel? 

CARL_MUNGAZI: Yeah, I did. Okay. So import this. That's how we look. All right. There we go. All right. We got the Zen of Python. Oh, very nice. Yes. No, I'm definitely in that camp. I'm definitely in that camp.

AJ_O’NEAL: Yeah. So this is very much like Python mentality, go mentality. Like it's better to copy a little bit of code than have a little bit of a dependency. Cause you know, you've probably gone through the trouble of installing Create React app before I imagine, or maybe yes. Lent. 

CARL_MUNGAZI: Oh yes. Oh yeah. 

AJ_O’NEAL: Um, a web pack and you see that it's like 1500 dependencies by 7,000 maintainers. And that makes me a little uneasy, you know, it's funny 

CARL_MUNGAZI: Because one of the first things I did as well was I looked at the Express source code. And when I was doing this was just to find out, okay, out of interest, how many libraries are in the Express packages, the JSON file. So I looked at every single module and I actually saw, okay, what is this module there to do? It's amazing that you find that some of the, some modules you find are basically doing one very, very small thing. 

DAN_SHAPPIR: Left pad for the win. 

CARL_MUNGAZI: Exactly. 

CHARLES MAX_WOOD: I was just thinking that. 

CARL_MUNGAZI: Exactly. I mean, for example, when I looked at Express, there was one module, which is called merge descriptors, and I don't know if it's still there now. And so all it did was basically merging two objects using the property descriptors from the source object, and that was it. Literally that's all it did. It amazed me that basically all these frameworks and labels are using are more or less built on smaller Lego bricks. And it actually goes into something I read by a developer called, I think it's Cinder Serhos, I think his name is, and he advocates writing modules that do one thing and one thing only. And then when you go to build your application, you find that you're more productive and you probably are faster because you've taken away various bits of functionality, which you can then call upon. And because it's your code as well, you are more confident in how it works. And you know that if things go wrong, I know where to look. 

AJ_O’NEAL: I would suggest instead creating a blog and titling the blog with what the function does, putting the function there and just writing a bunch of blog articles. And then when you need that function, go and copy and paste it. 

CARL_MUNGAZI: That could work too. I mean, I guess it depends on the, on your goal in mind. I imagine it to be something you'd probably do more for your own projects as opposed to maybe at work, where you end up importing all your own libraries into the code base that are basically maintained by you and nobody else. 

 

This episode is sponsored by Sentry.io. Recently, I came across a great tool for tracking and monitoring problems in my apps. Then I asked them if they wanted to sponsor the show and allow me to share my experience with you. Sentry provides a terrific interface for keeping track of what's going on with my app. It also tracks releases so I can tell if what I deployed makes things better or worse. They give you full stack traces and as much information as possible about the situation when the error occurred to help you track down the errors. Plus, one thing I love, you can customize the context provided by Sentry. So, if you're looking for specific information about the request, you can provide it. It automatically scrubs passwords and secure information and you can customize the scrubbing as well. Finally, it has a user feedback system built in that you can use to get information from your users. Oh, and I also love that they support open source to the point where they actually open source Sentry if you wanna self-host it. Use the code DevChat at sentry.io to get two months free on Sentry's small plan. That's code DevChat at sentry.io. 

 

AJ_O’NEAL: I'm a big fan of the idea of a package more than a library. The idea that something functions as a complete whole in accomplishing a task. So in the JavaScript community, we have a lot of these, they call them micro libraries, I call them microaggressions. They're like, you know, like left pad, for example. Or their collections of things that don't help accomplish a particular task, like Lodash. Lodash doesn't help you do any particular thing. It's just a collection of stuff. And so you get a lot of, a lot of cruft and a lot of dependencies upon dependencies, upon dependencies, upon dependencies, where the, another philosophy to look at is, well, what is it I'm trying to accomplish? I want to communicate with this API. Okay. Well, or write a library around communicating with the API. So I mean, the same mentality, like the words are the same in terms of, write something that does one thing and is really well contained. But where the concept of quote one thing, it doesn't mean performs an operation on a piece of data, but rather means helps a person accomplish a business goal or a personal goal or a task so that you are grouping functions that are not related from the pedagogical sense of like a merge function and a fold function and a map function all go together because they're in the same category of function. That would be say horizontal building. Vertical building would be, well in order to reach out to an API, I need a function that emerges a headers object and I need a function that parses a user parses a cookie. And so rather than creating a library around the idea of, well, I'm going to write computer science functions and package them together, I'm going to accomplish a goal and I'm going to include the things that are necessary for that goal. And in some cases, the things that are necessary for the goal are so complicated that perhaps they deserve their own library. Like for example, a cookie parser. But a cookie parser doesn't need to then include Lodash because a cookie parser only needs to merge, you know, an object for some reason. It doesn't need all it doesn't need to fold, it doesn't need iterators, you know, that kind of thing. 

CARL_MUNGAZI: I agree that because when I was building the testing library, I was a basic version, basically, we basically just tests what I was building. I came to a stage where I needed to, I think it was comparing deep comparisons of objects. So obviously when developing you're tempted, like you said to basically, okay, I'll go to yeah, low dash or a similar library and just basically import that one thing. But thankfully, I actually came across an article by Chris Ferdinandi, which basically explained how you can actually use your own code to write a function that compares objects in that way. And so I basically took that function, modified it somewhat, then added it to my testing library. So I now had a dependency, which was my own dependency as opposed to having had a dependency from Lodash. And this is now part of that framework. And I'd both at myself, if that makes sense. 

DAN_SHAPPIR: I would like just to add on top of that, JavaScript itself has expanded to include a lot of functionality that previously required libraries. So a lot of the stuff that we used to require Lodash for, Lodash is actually a great example in this regard, we can now just do with plain JavaScript. If it's modern JavaScript, then we don't need to bring in that extra library. But I actually wanted to ask you another question. So you were talking about looking to the source code and learning techniques and approaches. Can you maybe give an example of a technique or an approach that you learned from some library and then adopted into your own coding style? 

CARL_MUNGAZI: Yeah, sure. I think the most obvious example for me is now when I'm coding. I'm always thinking about, okay, separating concerns. So before I would maybe mix, let's say with an App and React, I would mix the logic and the UI in the same place. But now I'm more thinking about, okay, I have to make sure that the logic for this component sits on its own and the UI sits on its own. And also I'm now not afraid to write a function that maybe does one thing in terms of being a utility. So for instance, in the current app working on at work, we have to show a loading state when the user logs in. So we have a loading component that we have. You can actually determine, OK, I want to show x number of divs or x number of elements to mimic the actual loaded state when it comes. And so for that, I just wrote a simple function that basically takes in a number and then spits out X number of elements you want to render. Whereas before, doing that would have maybe been something I never thought about because I was always thinking, okay, wow, okay, so to do this, I'm sure it sounds complicated after you look into, after looking, after look online and see what exists, maybe import a library to do that for me. But now I'm no more confident in basically being able to see a problem, go to a library that exists and even actually copy that method and adjust it for my use case if I don't want to import the entire library to do so. Because I think sometimes you find that you'd import a library and really only ever using maybe 10% or 5% of the library. And that 5% you're using can actually be something you can take on yourself and actually maintain internally because it might not be that complicated to do so. 

CHARLES MAX_WOOD: I'm a little bit curious. You've mentioned dependencies and finding ways, I guess, of replacing dependencies with your own code and things like that, which is a very AJ thing, by the way. I'm kind of curious though. I mean, how much time do you spend then actually reading through the dependencies or the tests or some of the things that aren't necessarily core react or core, you know, what a mithril or whatever library you're looking at and instead are kind of the things around the edge, you know, where it's a plugin library, like a, or a test, like I said before, you know, things like that. 

CARL_MUNGAZI: Yeah. So I tend to favor that approach for simple library. So if I open up the framework or whatever I'm using and see that it's actually quite straightforward, then I'll look into it. But if I'd known from the outset that it's fairly complicated, I will not maybe spend the time to do so. It just depends on the tasks I'm doing and how much time I've got. Right now we're doing a migration of a legacy Angular application. And one of the issues we had initially, which we're still looking into now, is to do with the charts that we're using. And we're using high charts. I don't know if you heard of it. So we were looking for a wrapper for React around high charts. And so we found one. We imported it. And then when we looked at it, actually, the framework itself was basically a wrapper itself around high charts. So we had basically built a wrapper on the wrapper for high shots. We found that, okay, actually if we, if we did that ourselves, we would basically cut out that, that layer of having this thing imported in because of what it was doing is not what we thought it was doing. And in doing so it allowed us to maybe be in a case where we can actually handle issues on the line much better because we now having wrapper and now on control ourselves. 

DAN_SHAPPIR: So you're basically advocating for understanding the code that you use in your project? 

CARL_MUNGAZI: Most definitely. I think that it's even though it may slow you down, you'll be thankful longer term because you might come across a bug and you don't know, okay, this bug, where do I even start to look at it? Or in my case, I joined LimeJump in April this year. So when I joined I was given as a nice gift this Angular 1 application, legacy code, and we are in the, we're basically bit by bit writing in React again. So because I was not intimidated by diving into code, which isn't mine, I was able to, okay, just to gradually ease myself into it and look into, okay, what's actually happening. But yes, definitely being able to understand the tool you're using. Even if it's maybe a surface level, not necessarily in depth, but knowing that, okay, conceptually, this is the way that the problem is being solved is very useful because down the line, it helps you be able to tackle your problems with that tool in a much better way. 

CHARLES MAX_WOOD: I love how you said nice gift and legacy code in the same sentence. 

CARL_MUNGAZI: Yeah, it was a nice gift because, um, as you can imagine, when, um, being somebody who joined kind of front end in 2016, and my first foray into development really was Mithril, and then after I react, I'd never touched an Angular 1 before, and I'd always read things about online, about how basically it's something that you don't want to be using today, and I never quite understood why. And when I began to look into it and compare the structure, the paradigms, and then comparing it to how I'd learned how to do frontend. Yeah, it was a very interesting person. And it's something that even today, we're still going through it. And it's a gift that keeps on giving. 

STEVE_EDWARDS: So I got a question for you, Carl. One of the things that we've talked about over past episodes has been debuggers. And for me, that's my preferred method of going through code is in some sort of debugging tool, whether it's the dev tools in the browser or something else, just so I can, as I'm stepping through a particular method, function, whatever, I can see what's going on around it, what are my variables that are set, what are the different values and so on. Because in my experience, just reading through code and just looking at the code, it's really hard to keep track of everything that's going on at that time, because it's sort of important because different things are gonna happen depending upon variable values and so on. So I guess my question is for you. Have you done this enough where you can read through code and just look at the code on the screen and say, okay, it's doing this and doing this, or do you use some sort of debugging tool, whether it's IDE or dev tools, to look at everything that's going on as you're stepping through a given function or method or whatever you're looking at? 

CARL_MUNGAZI: I still very much rely on a debugger. I mean, it's an absolute essential tool to reading code and trying to understand it, but I find that once you've been reading a particular library long enough, you begin to see kind of patterns and function names that you've seen before elsewhere. And you can more or less kind of guess how the output of a particular task or particular function would be if you had run it. And then when you move on to other libraries, so when I started looking at Parcel, because I had done the React deep dive I came in saying, OK, fine. I know that all I have to do is locate the entry method for Parcel. OK, I found it. Cool. So knowing the steps that are needed to bundle code, which is basically, essentially, you specify to the bundler your entry print. So that can either be a HTML file or a JS file. And then from that file, the bundler says, OK, what are the dependencies listed in this file? It then goes to those files and looks for all the other files, all the dependencies of that file. And then it creates a kind of a graph of dependencies. It then also imports any other libraries you're using as well. And it's all then compressed, so it's all bundled together. And then that's what you then see in the browser. So because I had that kind of context from React, I was able to jump in immediately, kind of guess my way around the code until I came to a stage where what I thought would happen was not happening. And then at that stage, they needed to start debugging and either putting in a breakpoint, in my case, because it was parcel and it was more command line, I would be logging out the values that are in certain parts of the code and seeing what came out. And once I was able to now guess correctly what happened, I then go back to reading the code through again until I came to a stage again where the output was not what I was thinking it was going to be. 

DAN_SHAPPIR: Something that sometimes really works well for me when I try to figure out how certain code on the web or library used in a web application works is actually to look at the performance tab in the Chrome DevTools, the flame chart that kind of shows you which function invokes which other function. And the relationship, let's say, between running code and downloaded files and so forth, actually is very useful for me in giving me kind of a high-level view on the overall behavior of either that application or that library or that framework. I don't know if any of you have ever tried using that, but it really works well for me sometimes. 

CARL_MUNGAZI: Yeah, no, it's something I haven't done a lot, actually. It's something I guess after I didn't talk about it, I'll look into a lot more as well. Because I'm still in the case of I'm still learning a lot. And I'm sure there are probably other debugging tools and techniques that exist out there that can actually be useful. So yeah, I'll be keen to find out how you handle this in your kind of day-to-day coding. 

CHARLES MAX_WOOD: So Karl, are there any tools out there that help you read code? I mean, that are specifically designed to help you read code, I guess, because we've talked about some tools that you use to step through code and stuff.

CARL_MUNGAZI: So currently I'm just mainly running on the debugger that comes with Chrome or Firefox or whatever. I couldn't tell you in terms of specific tools, because I've not got that quiet far yet in terms of the steering that I'm on. I just tend to mainly just rely on the debugger at presently, right now. 

CHARLES MAX_WOOD: Cool. Any other questions from the panel or anything that we didn't cover, Carl, that you think would help people out?

CARL_MUNGAZI: Yeah, I think just more just to kind of encourage developers to pick a tool that they use every single day at work, pick a method and just see internally what's happening and use that as a way to kind of learn your language in particular. Because for me, one of the big things that I kind of I knew I found out was that essentially authors of things like React, Lodash, jQuery. They essentially are using the same language as I am, but how they're using it is different to how I'm using it obviously. They're probably doing more complicated and more complex things. And those tools have to be used in a variety of scenarios. They have to meet many edge cases, but fundamentally they're all written in JavaScript. So when that dawned on me, that actually gave me more confidence. And I now saw these tools as a way to actually learn how to code better. I did a kind of simple look and a simple deep dive into how what happens when you are dealing with sample class app extends react component and saying, okay, reacts here is using the new class syntax, but internally what's going on? Because it's still JavaScript, but how it's being used is different how maybe I would use it. So I think that for me is the the thing I'd like to impress the most is just to say that don't be afraid. At the beginning, you may feel like you don't know what you're doing. And even now, still, I have moments where I'm lost in a web of code and I'm trying to get out. But with time and the more you do it, you actually begin to feel more empowered and you're not afraid to take a tool to use it, come across a bug. And actually instead of Googling for a solution, the first thing you do is look at the source code. And then maybe after that, Google for a solution. 

CHARLES MAX_WOOD: Very cool. Carl, if people want to find you online or are there good places for them to go? 

CARL_MUNGAZI: Yeah, sure. So in terms of communication with me, um, Twitter, so at twitter.com forward slash calm and Gazi is where you can find me. Um, in terms of what I'm writing, I've got a blog up on, on dev.to. So it's basically dev.to forward slash common was again, and those are kind of the main areas online, you can find me and also get up as well. Get up common guys as well.

CHARLES MAX_WOOD: Awesome. 

 

One of my favorite communities in programming these days is the Angular community. Every time I go to an Angular conference or meet up with some of my friends who are in the Angular community, I have a great time. And a lot of them have wound up on Adventures in Angular. So if you're doing front-end development, you're looking for a way to keep current on the Angular ecosystem, and you want to have a good time listening to fun people talk about great topics related to Angular, then go check out Adventures in Angular at AdventuresInAngular.com. 

 

CHARLES MAX_WOOD: All right, well, let's go ahead and do some picks, folks. AJ, do you want to start us out with picks? 

AJ_O’NEAL: Yeah. So I already picked my picks. I picked the Zenith Python, which you can arrive at by opening a terminal, typing Python, and then hitting enter and then typing import space this and then hitting enter again. Or, well, not or, but and also the Go Proverbs. And I put a link here to the Go Proverbs or you can just search Go Proverbs. There's also a video with, I think it's Rob is the one that's doing the presentation, explaining the Go Proverbs. And on that note, I'm also going to pick, if you're interested in package management at all, and the problems and wonder like, why through the years have we had like, you know, we had RubyGems and we had Python eggs and we've got NPM modules and everything sucks and none of it works well, why? Take a look at Go with versions because these guys basically analyzed everything that had happened in every package manager ever and then created the perfect package manager. And I find no fault with any of their decisions, which is unbelievable because package managers always suck, but they describe the technical reasons they chose one thing versus another, and then dispelled some common myths that kind of have led to bad package design in the past, kind of straw man arguments that people would bring up. If you don't think about it, it sounds true. And so you make that choice, but then later it bites you. So it's just a really good video. It's called Go With Versions. It's about Go modules. I've linked to that. 

DAN_SHAPPIR: You know, before you continue, you kind of reminded me of how Linus Travandis once described how he designed Git. And it was by looking how CVS did stuff and then just doing the opposite.

STEVE_EDWARDS: AJ, you really need to quit beating around the bush in your opinion. Just be straightforward, okay? 

AJ_O’NEAL: And then I'm also going to pick, yet again, Link's Awakening, particularly the soundtrack. I've been listening to it on repeat and I just love it. The new Switch version. I just, man, they... Because whenever something's redone, movies are always redone terribly. Like, can you name one movie where they remade the movie and you're like, wow they really preserved the artistic quality that the movie had in the past. 

CHARLES MAX_WOOD: Artistic quality? That's hard. Made the movie better? I can name a few. 

AJ_O’NEAL: I'd like to actually hear of ones that you think they made better when they remade them. But you worry about these things when games are remade and just when anything's remade, if you really love the original, if you had just a special connection with the original, you always get worried, are they gonna butcher it? And Link's Awakening is just something that pixel for pixel, sound bite for sound bite, they kept true to the original, even some of the quirks that are maybe not necessarily the things that you loved about it, but preserve the integrity of it and just made it better. It's just so beautifully redone where everything that I love about it is captured and the things that were annoying that didn't contribute to character were smoothed over. 

STEVE_EDWARDS: Yeah. I've always been afraid that somebody is going to remake the original Pong and totally ruin it. So 

CHARLES MAX_WOOD: well, they keep making a star Wars movies and they're kind of ruining that. Anyway, Dan, what are your picks? 

DAN_SHAPPIR: Okay. So since we were picking stuff about other languages, I'm actually going to go the all the way in the other direction. And since we're talking about learning by reading code, I'm going to mention a classic called Programming Pearls, which is actually a book about C++ and where the book actually shows, describes problems, then describes various possible solutions, really analyzes the benefits and drawbacks of each one and really shows you the best solution for a whole list of really. Useful and Usable Problems and it's by John Bentley and it's really considered a classic of programming. So if you can stomach C++, I highly recommend that. My second pick is continuing with my list of mentioning classic fantasy books. So last time I spoke about the Amber series by Roger Zelazny. So I'm going to mention another book of his. It's called Lord of Light. It's a really strange mix. It's kind of in the fantasy and science fiction and whatever, but it's like this world where the gods of the Hindu religion live. Like people have developed technology to such an extent that they've actually become like the Hindu gods. It's an amazing book. One of the best fantasy science fiction books that I've ever read. I can't recommend it highly enough. And by the way, an interesting anecdote about it, if you've watched the movie Argo, where they say they're coming to Iran to supposedly make a movie in order to smuggle out the people who come from the embassy who got stuck there, and they have a script that they're supposedly going to film and it's based on a real story, well, in reality, the script was actually based on this book, Lord of Light. So that's an interesting story about this book in and of itself. But again, I really highly recommend this book. And by the way, it was written in the year when I was born. So that's an interesting bit of trivia as well. And those are my picks. 

CHARLES MAX_WOOD: Steve, what are your picks? 

STEVE_EDWARDS: So I'm gonna go with some electronic hardware and pick my earbuds that I use. I used to use earbuds quite a lot when I was working out or a lot of times just working around the house and doing stuff. And so I got tired of wires and having to stick them under my shirt and so on. So I did some research looking for a good pair of true wireless earbuds. And the ones that always came up at the top of reviews whenever I was looking are from Jabra and they're called the Jabra Elite 65Ts. Well, they're probably a year old, I think, but they are phenomenal really easy to get set up, connect to your phone. You can use them for phone conversations. They fit in your ears really nice and stay snug. The sound is really good. And it comes with a little app on your phone where you can create sound profiles depending on where you're using them. And the nice thing about them is the case is a charger. You charge up the case, connect it to a USB connection. And then when your earbuds get low, you just stick them in the case and that automatically charges them up again. And then obviously when the case lets know gets low, then you need to recharge it again. But they've been really great. The only downside to them is they're small and the case is small, so it's easy to lose them. So I've got to make sure and keep track of them. But yeah, really a great set of headphones. Trey Lockerbie 

CHARLES MAX_WOOD: Nice. I'm going to throw a few picks out. So this morning I kind of got, I was just thinking about stuff and I kind of felt like listening to some stuff that reminded me of my dad. And so I'm going to pick those. The first one is Garth Brooks. I grew up listening to Garth great music. Absolutely love everything that he's put out. Incidentally, he and my dad also had the same birthday. So I can't tell you how many times in my life I heard that over and over and over again. Another one was the Rocky movies. And so I was listening to some of the songs from some of the soundtracks and that that was fun too. Incidentally, I went and looked, I was like, okay, so, you know, when did Rocky come out? And yeah, the movie Rocky is older than I am. So great stuff. Yeah, I've just kind of been, uh, you know, kicking back and enjoying some of that. So, Those are my picks. Carl, do you have some picks for us? 

CARL_MUNGAZI: Yeah, sure. So in the spirit of reading code, I'm going to pick the ECMAScript spec as well as the spec for HTML, because prior to reading code, I had never, ever looked at them. But now I find myself that if I maybe want to actually find out what a particular language construct is meant to do, I'm just maybe keen to do it with this curious. I might look at the spec. I remember once I was looking at, I was writing a small utility for checking inputs in terms of the actual content in the input field. So I was writing a regex and I looked at the HTML spec to find out what is the actual inbuilt methods that they provide for doing that. So from validation, and that's only because, like I said before, I'd come and use to actually looking at the spec or looking at source code. So yeah, so those are my kind of programming picks in terms of non programming picks, I'm going to pick snarky poppy. I don't know if anybody knows them, but they're a jazz fusion band. Uh, they won two Grammys and they currently are touring in the UK and I'm going to be seeing them next month. So I'm well up for that. 

CHARLES MAX_WOOD: All right. Cool. Well, thanks for coming and talking to us, Carl.

CARL_MUNGAZI: Thank you so much. It was great fun. And I'm really thankful for the chance to share my kind of love for reading source code and hopefully encourage more developers to go out there and do the same. 

CHARLES MAX_WOOD: Yeah. I think it's a really useful way to learn. And open source code is free. So you can go read it. 

CARL_MUNGAZI: Exactly. It's basically like a... I look at it as if you've got a massive library online that you can just dive into whenever you want without having to worry about any late fees or taking on any books. Yeah, it's awesome. 

CHARLES MAX_WOOD: Yep. Cool. All right. Well, let's go ahead and wrap this up. And books, we will be back next week. 

STEVE_EDWARDS: Adios. 

CARL_MUNGAZI: Cheers. Thank you. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit c-a-c-h-e-f-l-y.com to learn more.