Transcript from the "Readability and Performance Q&A" Lesson
[00:00:00]
>> Speaker 1: What's your take on using shorthand or the more clever alternatives to coding solution versus just writing the longer but more readable code?
>> Brian Holt: Just like I was explaining here to Emma earlier, I always want people to err on the side of code that they feel is readable, right?
[00:00:17]
To me, because I've been doing this long enough and like I write code like this. And so I often read code like this. This is still readable to me. So I kind of strike the balance here that like I still find that readable and it's a lot shorter to type, right?
[00:00:32]
So I'm gonna do it this way. And once you start getting into these functional paradigms, your brain kind of starts thinking about problems in terms of this, right? It's kind of a different way of thinking about this. This would be called functional programming. This would be more like procedural programming or imperative programming.
[00:00:48]
So not that you ever have to care about those terms, but I always want people on my team and I want myself to choose readable code, right? So if you find this far more readable than this, then you're more imperative to do it this way.
>> Speaker 1: What about people who come after you or that you work with or something, what if they see it differently?
[00:01:13]
>> Brian Holt: Then you tell them that they're wrong.
>> Speaker 1: [LAUGH]
>> Brian Holt: No, so if I was working somewhere that let's say have more engineers that did not know how to program this way, I would probably air on this side of doing it this way. And in the process, try and teach them how to do it this way.
[00:01:31]
So that hopefully we can get there, but I don't want someone to sit there and just like stare at my code and say, what the hell is going on with this, right? That's this is fun to write it this way. But if I'm like slowing up other people, then I'm like doing a disservice to my team, right?
[00:01:50]
So-
>> Speaker 1: When you read JavaScript in the wild, do you not necessarily, in your job where people are probably programming similarly, do you see more code written like that or it's just all different?
>> Brian Holt: All over the place. You'll get some people that are very, very functional oriented that won't write code any other way to the point of being like ideologues and I like I don't like dealing with them.
[00:02:12]
In fact, they're kind of the worst like functional programming purists are the worst. Yeah, I'm just gonna throw that out there. The only one that I still like is Brian Lanstor for the front of master and that's cuz he's just a beautiful human being.
>> Speaker 1: [LAUGH]
>> Brian Holt: But everyone else, they all suck.
[00:02:28]
So I like a little bit of functional programming like here in there. But like I'll still, if I see stuff like this, I'm not upset by this, right? So I'm definitely not an Island. I've fancied myself much more of a pragmatist like just take the approach that solves the problem, right?
[00:02:46]
Try and fit into the code, right? Don't try and enter a code base and make this. Well, this is bad and we have to change everything. No, slow down, sparky. It's okay, just try and fit into the code base, improve incrementally. Don't try and upend the whole thing all at once.
[00:03:03]
So to answer your question, it hugely depends on who you're talking to. Other questions? Other rants you would like me to go on?
>> Speaker 1: Can I ask one more?
>> Brian Holt: Sure.
>> Speaker 1: For the constant, right, person. Did you have to create that as a place to store each iteration or could you have done list I in place of where it says person in each of those?
[00:03:35]
>> Brian Holt: Works just as well.
>> Brian Holt: Honestly, that's probably what I would do, but I was just erring on the side of being explicit. So hopefully more people would get it. Cuz normally like seeing things like person here and there, it's a little bit more clear. It's like that's a person there.
[00:03:51]
What is a list I, right? So yeah, it's all in the sake of clarity.
>> Brian Holt: In general, like if I'm referring to something like list I over and over and over and over again, I would actually plug out of the topic it did here and use person one for clarity second to accessing a list is really really cheap into performance it's not free, right?
[00:04:19]
So that's a micro excuse. It would probably in the text you don't super large code bases, but that's how I justified in my brain.
>> Speaker 1: What time does performance really matter? Is there a set size of list, a size of structure that you're dealing with where you start having like really think about it?
[00:04:45]
>> Brian Holt: I'm sure there are numbers that could be given. I think my general stance is wait to have a problem and then fix it, right? Premature optimization kills companies that, that's a saying that I did not make up. [LAUGH] So if you're sitting there like wringing your hands about like how this can be more performance and like that in general, you're wasting time.
[00:05:06]
And it also leads to people writing really weird and archaic code, right, to try like in the name of performance trying to get something to go faster. But in general, like JavaScript pretty fast. Chrome is really fast. Firefox is really fast. In general, unless you're doing things like operating like millions of numbers.
[00:05:24]
You generally don't have to really concern yourself like I will optimize things to say like 50 milliseconds or 100 milliseconds, but I won't optimize things to say like two. So it depends on what's going on. We're actually gonna be looking at our project at the end of the day that where you're gonna have some performance concerns, right, and you're gonna have to make some optimizations.
[00:05:47]
So that’s because it’s going to be happening hundreds of times a second. When you have code that’s that hot, that’s what you would call something like that. It’s a hot code pass. Something that is run really, really frequently. That’s when you really wanna concern yourself with performance. But if it’s a cold, cold pass like it runs like once a day who gives a shit if it takes five minutes versus four minutes, right?
[00:06:08]
Yeah, does that answer your question?
>> Speaker 1: Yeah.
>> Brian Holt: Cool, thanks. Anyone else?
>> Brian Holt: Yeah.
>> Speaker 1: So in general, when talking about maps, is that basically just like the for statement? Like this one right here?
>> Brian Holt: Yeah, I'm trying to understand that line. They're just-
>> Speaker 1: Sure, so let's make this a little bit more explicit.
[00:06:32]
So they can make a little bit more sense.
>> Speaker 1: Return person.name. Okay, so, that's a bit more explicit. So this extremely similar to forEach, right? You can think it's functionally exactly the same as forEach. The only key difference between forEach and map is that whatever you return in map gets put into a new array, right, whereas for each doesn't return anything.
[00:07:08]
So here, I'm returning person.name. So that after this, I'm going to be left with a list of strings or an array of strings, right, which is gonna be an array of names which is ultimately what I wanted to get out of this right before this was a list.
[00:07:23]
If you come on down this line right here and I don't have this map on here, engineers, it's just gonna be a list of objects which is not what I wanted. I wanted a list of strings.
>> Brian Holt: Okay.
>> Speaker 1: Does that answer your question?
>> Brian Holt: Yeah, it does.
[00:07:36]
>> Speaker 1: Cool.
>> Speaker 1: I'm always like really hesitant to teach this. Like I said, I learned about map filter and reduce like those kind of things, probably about five or six years into my career and it fundamentally changed how I write code once I actually kind of learn how to do it.
[00:07:54]
I think it makes a lot of these things a lot simpler to deal with, right? Like once you understand what this is really doing, it's three lines of code, right, which is pretty cool. And it's becoming more and more common in JavaScript as well, which is why I think it's important that you're exposed to it earlier.
[00:08:11]
Like if you are start writing react which is something that I write a lot of which is the UI library from Facebook, you have to know about map. It's just used everywhere in react. So you'll be ill equipped to deal with it, unless you know how to use it.
[00:08:24]
So anyway, that's my internal monologue for the day.
>> Speaker 1: Okay, so we'll comment that one out. We'll leave this one up here and we'll go down here.