Computer Science in Frontend Development?

Good Monday morning, if you're watching this, I am on vacation, but that doesn't mean that they won't be stuff on the channel. I'm going to be posting three of these videos, which are outtakes from the interviews that we did with many of its speakers at Nordic J/S in October. The one you are allowed to see is with Viadeo, she and David Cole shed, and they are lovely people and I'm sure you're gonna love it. Over to the interview, the one you're about to see is with David Cole [ __ ] and Viadeo. She speaking about the value of computer science in front-end development and a bunch of other things in general. They are amazing people and I'm sure you're going to enjoy this. This interview. Have a further Merry Christmas break. And over to the interview. So we have David invited he. They have spoken today about really interesting subjects that are somewhat related to computer science, so welcome to our live stream.

On top of it, yeah, yeah, the world, exactly, it's very, very superior. So you're not talking to you something about your talk and explain what you're going for. And because a lot of people. Nordic Geist yeah, so actually, you spoke before I did, but my talk this morning was about the JavaScript object model. Yes, you're just interesting, because a lot of us think that it's, you know, pretty fundamental, but you may not know how it works under the hood. So I was kind of diving in, maybe a little bit scary though, right? There's fundamental, basic thing it can be. It's like, you know, you peek under and then you actually know. I think you should investigate. It's fun, but that was my topic, though. Is awesome, I love it. Yeah, what about you, David? How was your talk? How was the experience of speaking of Nordic chess again? Oh, it was so great.

So I was here two years ago and my talk this time was using JavaScript objects to create another fundamental concept state machines. And using that to teach everyone how to read minds. That's not ambitious at all. There was a look at we observed the chat, the live stream chat during your talk, and there was a lot of engagement during. Oh yeah, what the hell it says? And like, a lot of. People posting the links to XState and like, I knew, but Jesus Christ, this thing has a lot of npm downloads. Yeah, I think it reached over one-and-a-half million. Actually, what? Most of those Gatsby's fault, though. Still, it's pretty good, cool. So why don't you tell us a little bit about your background? Did you both do, like, computer science in university? where did you come from? Why did you decide to program? Yeah, my background is actually not in computer science at all. I studied English. Okay, I study theatre. Oh yeah, yeah, humanities.

So, yeah, a good computer sense. I'm bored, no, I think it's interesting, I think both are valid, I think. Ultimately, you end up having to learn some of it. And a question of whether you learn it in school true, or do you learn it because you just fell into it? Or you are curious and you're like, Oh, I have to learn this now. But my background is like, in the humanities, I was a writer and a teacher. And then I went into programming. And yeah, how did you do that? Like, why did you mean, like, into English and university? And why did you think, oh, you know what, I'm just gonna program? How did that happen? It turns out, being a freelance writer is hard. But I started building my own website for my writing. And I was like, Oh, this is fun, maybe I can add this other thing, maybe I can.

The spinner. And slowly, I just started, like, writing, okay, like, into web first thing. Yeah, well, yeah, we started with web development, kind of mostly still working in that. Awesome. Yeah, what about you? David's so funny enough. I went to college for piano, so, if you're wondering, and so, yeah. We had a class at the end of, I guess, my senior year and we had to create a website for ourselves. But we were using this, I wet drag-and-drop thing and I didn't want to do that. I wanted to, you know, just figure out how to do my own website. So that's pretty much how I learned web development. And my instructor said you should do this as a living, so I looked it up. It pays a little bit more than being a piano teacher, it's a little less. Artistic, though, a little bit, but there's a lot of creativity in sports. Yeah, for sure. I mean, there's a lot of very like creative coding talks at this editions.

That's pretty cool. Nice, hello, hello nurse. That says love the base CSS podcast lady, thanks you for reading them. Oh yeah, thank you for listening to it. Tell us a bit more, like, why did you decide create the podcast? What what happened there? Yeah, so, as I mentioned earlier, my background is not computer science. But I at some point was like, Oh, I need to. Everybody knows about this stuff and I don't know that's what I thought. It turns out a lot of people, yeah, I think most of us. So I just started, like, learning it on my own. And I started a writing series called race. Yes, and my friend. She found the writing and she was like, you know, I think people would like this in broadcast format - not everybody learns by writing. Yeah, so we just sort of join forces. She brought her podcasting experience, is so good at it, and I brought the content, and then we created this technical podcast.

Oh my god, that's amazing. I love your videos. Okay, it's really produced. Yeah, thank you, awesome, cool. So we've learned to, like, talk a little bit, like since we. We figured that it would be fun to have you two up here at the same time, and I figured, like, what is the overlap between you two? And I feel like, feels like we want to talk a little bit about, like, ears. Computer science valuable for a front-end developer? Because I think that a lot of people ask themselves that like, a lot of. It feels like whenever I see like these boot camps with like, be prepared you for a job kind of thing, they've got. Like, we go and React. Learn craft girl, learn like this, like, it's very much like, focused on, like, learn these tools. Because that means that this consulting company can now shove you into this company because they can check these boxes.

But it like, we're in a world like, like, like that. I think that a lot of people would like to hear a little bit about, like, why? What is the value of learning more computer science? Or just basic algorithms, or like, do you guys need to use it on your professional life? Or what do you see value in it? [Music] yeah, so I personally think that I did. Ions have a background in computer science like you, but I did take a couple of classes in college. And one of the important realizations is that a lot of the fundamentals in neuroscience are present in our everyday work, but we just don't really realize it. And so what we end up doing is we invent these patterns or pull these libraries, and we don't understand that. There's a fundamental principle to everything that we do, and understanding those first can make things a lot easier. So I talked a lot about state machines.

And I also in my talk today. I threw a little bit of graph theory, in which I mentioned your podcast, because there are some articles about directed graphs, especially distributed systems. You have a great explanation for how those work. In part of that is like some of the principles that XState is based on. Yeah, I totally agree with you. I mean, you could be writing your very first line of code, whether it's HTML or JavaScript, or CSS. And like, there's computer science in that, like the DOM is just a tree, like all the functions you use in JavaScript. Like some of the most basic ones are using algorithms under the hood, and you don't need to know them. Like, you can be productive without knowing it. But at some point, I think either you will run up against it if you go off the happy path. If you find a bug, or you're looking at open source code, yeah.

Or you'll be like, Oh, I want to know. And that's what I think. It's really helpful to know, but I don't think by any means it has to be learned first. But I think organically, everybody sort of fills in the house to converse with that. I think it gives you like a lot of flexibility and debugging, especially because, like when things break down and it goes outside of the box. As you said, layer of the framework that we have. Or like the predictable thing. It's always nice to know and figure out, OK, this could be happening because that, I know. That the JavaScript object from like behaves like this, so it's also always very useful, I think. And what are you going to think about, like job interviews that use like computer science algorithms? A lot of people complain about the Wi-Fi. Yeah, what do you guys think about that? I will take this.

My opinion is that it shouldn't be the determining factor, but also I approach it from like a. People often tell you need to, like, memorize it in order to get a job, but then you're not really learning it. And I think Lee, I think it should be more focused on, like, understanding the concept. And like, a really good job interview with like, teach you something you don't know, like, that's me. That would be helpful for them, and, you know, I like that. Yeah, right, yeah. I remember having to memorize so many big O of N, like first sorting Gallagher B's, and I had no idea, like what they, you know, meant, or whatever exactly. But what I'm more interested in is why, like, how do we approach that? Oh of N, and what does that mean? But for jobs, I don't like those interview questions, for it's just trivial knowledge like, well, what's the big O of this sorting algorithm?

Or what is 7 plus 8? And base-? To which I was actually asked in an interview, right? I no idea how to solve that. I was about to say, therefore, base negative, well, Sophie's negative to it, sort of like a 0 negative 1 to negative 4. So with alternates and when you add them, you're adding and subtracting some, and it's just really weird. So that kind of knowledge, not really useful anywhere, but asking questions where it applies directly to your job, especially if there are computer science questions. I think that's, yeah, I find, I find that, that it's like what I really liked about your talk. Because it comes went to state machines, state machines, and statecharts. That are computer science concepts that are very applicable to Compton engineering. Yeah, like when I was, I was interviewing for Google a couple of years back, when I'm a part of a company that's almost like retired. So they had, like these acquisition consultants training us for the Google interviews, and they pushed so hard.

For time complexity and recursion, like you had to know that, like, so well, because they were pushing that so hard. In the questions, which are comply somewhat useful concepts, but not like the relevance for time complexity. Again, in a fronting application is not like, that's not where your performance problems are gonna be. So that is like, what? What concepts do you think are useful for computer science? That for front-end engineers in particular? Like apart from like statecharts and state machines, well, so time complexity can be useful in some instances. For example, you took computer science and I know, like, you know all of this stuff. But when you see two for loops nested, that's instantly like, Okay, right? But algorithms such as tree traversal algorithms, like, if you tell someone, Hey, finally, you know, do a depth first search of this tree. They're gonna be like, wait, why?

But if you ask them like, find all the paragraph tech, the paragraph tags in this, you know, in the DOM, then they're gonna be like, Oh yeah, how does that work? Guess what? It's an epic searcher, so it is extremely useful, especially for data structures, which we tend to just door stuff forever on the front end, and just like hope, things work. But once we understand data structures, we realize that there's things like linked lists, well, finite state machines and things like queues. That could really help with our, you know, with whatever tasks we're doing. Yeah, what do you think? Do you think there's any other algorithms that not only are good for? Like, preparing for interviews? Because that shouldn't be like the ultimate goal, but like being better at your job as a front-end developer. As far as algorithms, I don't. I don't think there are any algorithms that I have learned specifically. Except for Binary search, where I was like, Oh yes, I can pull this out and finally this.

It's nice to know them. Binary search actually, like Git, Bisect runs binary search, so it's true. Yeah, I actually use it all the time. I agree with you know your opinion completely, which is that, like you, you are using it. You just don't know it yet, you don't know it. And so when the time comes for you to learn it, it's super helpful. And I. I concur on like the trees, state machines, data structures are just really helpful. Like the day that I understood what a stack was, I understood like how programs work. Because, like, oh, time frames, that's what's happening, that's all it is. So it's. It's like I almost want to encourage it because it's a very empowering thing to learn. And I think, like when you get over the hump of learning some of these fundamental concepts, like data structures or even algorithms. If everything that comes a little less scary, because you start to just see it as a shape of a thing you've already seen before.

I'd like to stay on the scary part, like because a lot of people like that I run into have like this thing.

Play from 0:00

Xiety around. Like, Oh my god, there's a new framework coming out kind of thing. And they just feel like I that. Some years ago, I just stopped having that anxiety and realized a little bit because it was because I started. They started seeing like the underlying patterns. So when something like view comes along, you kind of just see like, oh, it's like this adaptation of this, but with this slight variation. While if you're just like in like the React world and doesn't understand like how it fits into a like, the cohesiveness that it fits into like. That means that your entire existence is pulled out from right under you and that super [ __ ] scary shame and like, I feel like a lot of like, going deep. It's especially when you talk about the object model that gives you like this, this nice, fuzzy feeling of foundation. And I think, to your point, we know a lot of developers are like, very married to one way of doing things, especially in the framework Wars.

I can't ever wrap my head around that because frameworks keep changing and, more importantly, all the frameworks learn from each other. So if you really know, like, take a step back and look at them, you'll notice. Like Ember has learned from Angular and React has done something. And Empurpled added and then are sure, you know, some people have learned from view and spelt, which I didn't even really know it. So it's it's sort of like taking a step back and realizing, actually, at the. Core, the fundamentals, they're all the same, and some of the patterns are also the same too, and so you're more empowered. Like tomorrow, if you need to suddenly switch what you're doing, you have the tools to help you navigate that. You're not lost, lying. And they're trying to figure it out on your own. Exactly, sure, yeah, and on that same thought, I find it scary, too. When it's like, alright, here's the new framework, how do I do this in this framework?

But once I started first focusing on patterns like you said, and taking a step back and saying, alright. How would I solve this without a framework? Like, how would I solve it? Just conceptually? What kind of data structures will I have? How would I do? Like reactive updates, then a framework just becomes a way to apply those, and then that frameworks become so much less scary. Because it's like, if someone said, here's vanilla now, here's chocolate now, here's pistachio, you shouldn't be scared of that. You should say, Okay, I don't care what those are. I could put it on the cone and eat it. No, but it's a really good point. Because I think, like, when you and going back to the whole like concepts instead of like direct things such as frameworks. I think the whole thing just becomes so much easier. When you get a grasp on, okay, but what is reactive programming? Because then, like, you could just figure out what React does without never having actually coded, React.

So, like, when you do understand like the base concepts in computing, which not necessarily are gonna be like algorithms per se or computer science things. But when you do understand like coding paradigms, functional programming, improv imperative programming. And you know, like, what the baseline different is, then it becomes so much easier to navigate the new stuff that's coming around. I love this, like, that's so nice, of course, I see all of the points they're making. Like, when David pointed out that switch is a finite state machine during his talk, there was such a aha moment of it for me guys. If you have any questions for Davey Adelphi - he like, please post them on the machine. We're constantly like reading up on the things that you write, and hopefully they'll be. Able to answer, we'll try, but yeah, there was an interesting point in the chat, actually. Like, sometimes, functional programming is also using front-end, and declarative programming doesn't take the traditional imperative approach.

I think that what helps me, and especially because I think functional programming is a little scary. I, I do it a lot, but the whole category thing, I don't know whether Mano it is a Monad, whatever. I always understand it. For like 5 seconds and then just, yeah, withers away. But the idea is we should be pragmatic. First, apply patterns, do them, don't even think about, okay, which? Which category thing am I using? Or which solid design pattern from object-oriented programming am I using? But just solve the problem. And then you layer the pattern on top and you're like, Okay, this fits within this path. It's a great point, actually. That is so cool. Yeah, I think it like. When it comes to functional programming, it's an interesting world because there are some concepts there that are tremendously useful and tremendously simple, like math quits. It's like, after you learned that, you go, like, Okay, I understand immediately how this can be useful.

But then you come to Mona's, which is kind of like, Oh, it's a promise, but it's like, the general, well, maybe, yeah, it's not like. And they kind of use kiss becomes like, less clear, and they can move, screams and like it like. It starts becoming a little bit harder to navigate. And it feels like it would be very nice if somebody has made a little bit of a map of all.

Play from 14:00

What? Yeah, these concepts are, I found, like a useful case, please. But these, sir, perhaps we don't need to learn them, and perhaps we don't need to shove them into our code. Yeah, whenever you're doing, whenever you use Ram de, I just find myself in this can, like, maybe this around, I can use for this. I literally waste half an hour every day trying to figure out what the perfect friend of functions for the things that I'm doing. So, thank you, sir. The RAM, the documentation, is basically the Pinterest of programming. It's awesome. But going back to interviews, can you guys think of what was the worst interview of your entire career? If your [ __ ] comfortable? And Sherry Oh yeah, sure, I rebelled in it. It was to code, so I don't know any PHP, I've never written PHP. Everybody in this interview and they knew that it was the end of, like, a five hour long interview.

The last half an hour was code. Conway's game of life in feel like a genetic algorithm? Yeah, I was like, Conway's what? Beyond that, I don't even know what the problem was, so I never got to writing. [Laughter] yeah, I got to say one of my MO. Because it was actually a great interview. It's just the interview problem that they gave me and I'm definitely not going to name the company here. Josh in life, nothing to do with, Oh, what's this big O of N notation or anything. Computer science? He'd like that, but it was more, hey, make the simple components in this React app that we have. And I was like, Okay, I know how to do this. I could spin up a create React app and do it in literally half an hour. One in their codebase. Oh my God. It was like, first of all, I would ask, why are they using four styles?

They're like, Oh, we made our own thing. I'm like, all right, well, what about scene management? We have something sort of like Flux, it's a little like. Long story short, it was over engineered to the point of no return, and I knew that, just trying. This is why I'm so thankful that some companies have you working. Their code bases. Are that they like, part the job interview. And I just said, like, I would not be happy. So basically they didn't bomb you, you bum then. Wow, that's shocking. Well, but that's thank you guys so much for sharing. That was that was very brave with you. I feel like, so, sandals, boy. I feel like advanced functional programming school for personal project, but also for real work, with multiple developers of varying heights of knowledge. Littering and not code base with known as this kind of a disservice to any juniors.

Unless a category theory stuff is solving a problem that wouldn't be otherwise be possible to solve without it.

Play from 19:00

Yeah, I think, is that the thing that we were just talking like when you use things just for the sake of? Using your be, perhaps disregarding how much your team actually knows about the thing that you're excited about. And that becomes like a code that's hearts reasonable. Yeah, have you guys had any experiences with, like, good practices? And like, team management's in the sense of, like, everybody's on the same page. Where the technologies are you using, or how do you get there? Yeah, so my opinion on this actually is that junior developers could be some of the most valuable developers in your organization. Because a lot of the times we think, okay, the junior doesn't understand this, so we should, you know, we have to spend time teaching them pop-up. But that's actually an asset. Because if a junior developer doesn't understand something or doesn't understand the code that you wrote, then guess what, your code is not good enough.

Even at Microsoft, we encourage each other to teach each other not to throw something that someone might not understand. Like, that's doing it to service to the rest of our team. Yeah, I think that is a great counterpoint for the whole. Won't somebody think of the junior? Which is also a great question? How do you guys think is the best way to mentor? And, like, get juniors suits to eventually grow in their careers like mid developers, earning good practices that you'd like to share. Or how do you do that? Let them do the typing and don't give them the answers, even though you know them. I think I've seen a lot of, I think those are like the two rules that are on the top of my mind. I'm sure there's more, but like, I see a lot of engineers who are mentoring. But what they're really doing is like, they're, they're cutting short the experience of learning because they're like, Oh, I know the answer, let me just take over and type.

And I think that the growth at the real learning happens is when you sort of prompt them and you're like, I wonder why that's not working. Should we try something? But like, let them try that, let them do the exploration and learning. Because if you just type it for them, it's easy for you, but you're taking away that opportunity for them to figure out exactly, you know, so it's awesome. Yeah, I completely agree. And that's why, when teaching, junior developers, stay away from JQuery, stay away from React or View, or any of those frameworks. Like, teach them the hard way, have them do it like manually using the native API's, and then tell them, guess what? I'm sorry you're going to hate me, but there's an easier way to do this. But I really want you to learn this. So I figured go back in time and tell yourself one piece of advice.

When you were a junior developer, what would that be? It could be anything like, yeah, not necessarily technical, but like something that's gonna help you, like, grow faster, perhaps, or, yeah, deal better with the situation that you went through. I don't know if it's so much advice as it is reassurance, but I would tell myself that you are capable of learning more than you think you can. I think, especially at the beginning, I had this feeling of the mountain of things I don't know is way bigger than the things I do know. And so it felt kind of like this daunting task. And like, for example, with computer science or distributed systems, or a new framework or new language. When you're starting out, it sort of feels like power, like ever do this, like I'm never gonna be able to do this, I'm not capable. But if I could tell myself like, yes, actually you are. It's gonna be a little hard, but you will get through it.

Like you have grit and perseverance, you'll get through it. That would have been reassuring. I don't think it would have made anything easier or faster, but at least I would have, like, been like, we're right. I will get through it. It's a journey, a really good piece of advice. I love it, and I also love this. Point by Robert Cables. And dysfunctional IT organization. That senior developer can be one of the highest risk assets that you can have.

Play from 22:00

That's why I really like the emphasis on well supported, you know, give a junior. Devs, make points. DAVID yeah, one of the scariest things is having a team full of senior developers. Like nothing, evil battle all the time. But if I, if I went back in time and gave myself advice, it would be don't try to rewrite Lodash and Sass, no. But going to invite these points, it's more. You could learn more than you think you know, and just be more well-rounded. Like experiments with more server-side languages and the command line. I'm still a command line beginner to be honest, I just try to do things with a GUI. I know my CV and like, it's whatever, I know all those, but yeah, just be more well-rounded. You get by, okay? So, to close off this amazing interview, one last question if you could be any algorithms, what algorithm would you be? I feel like a lot of people on the Internet are gonna make fun of me for this.

But I'm gonna say it anyway. Bubble sort, because everybody hates on it so much, and - bubbles, I feel like. And then I just beat my own little corner where everybody's like, nobody likes you. It's okay anyways. Showing some love for mobile, so awesome. I would be Dijkstra's algorithm. Okay, because just like my last name, his name is also impossible to spell. Okay, and also I'm very lazy. I want to get from point A to point B as fast as possible. Amazing. Well, great answer. Well, would you be? Oh, hey, what's like? No? I think it would be like a some kind of tree search algorithm, because that is one of the first algorithms that I learned. Where actually like, Ooh, this is cool. And then I could actually use it for a Spotify interview problem, and then they actually never use that.

Play from 26:00

During my five years there, it's like, still, what about you? I? I would be red black tree because it's very special, it suits my dress. Cool. Thank you guys so much for being here on our live stream. It was amazing to have you. Hope you have a great time at the conference still, and thank you very much for having us. That's been really fun. Yeah, thank you, it's been great in Hello to all the fun function fans, yeah, and the. The talks of are going to be available on the Nordic J/s YouTube channel for this. And the livestream is going to be available in its archive form. After we go off air as well on the Twitch channel, exactly, tune in. They're actually very fast, so okay, so we have five more minutes of. Talking, we can actually look at questions, perhaps, okay, no, like we could actually go by earlier. Hello natives, hello narrative, as you reflected, unaffected to grow up?

QL can be slow on larger projects, perfect for fright like, like is it? Though? Like, why would it be a bit like slower on larger projects? I never had any issues. No, because I feel like it's like, because the middle thing between the API call and response, yeah, precisely it's you're doing like, should thank your project faster for most parts, like depending on. Like all cases where I've replaced the REST API with graph to all the API, it's always turned out faster. Because you can do it in fewer queries. OK, so, that's a good question.

Play from 28:00

What pieces of tech, or what are you excited about learning right now? Distributed systems? Uh-huh, that's what I'm learning. I'm trying to teach myself because I don't work with a very distributed system. Let it kind, I guess everything's distributed. But I don't know too much about it. I'm trying to learn more about it, so that's what I'm excited about, OK, but why did you decide to start learning about it? Because they were already using, or was there anything else to happen that actually like? I think when you're like, working on like the Ops side of a app or a product like, you start to realize that there are a lot of problems, things being distributed. And then I was like, Oh, there's no such thing as a global clock. What do you mean, basically? I don't know that I have too many answers. I think I've just learned that their district rating systems are hard and there are a lot of things that make them hard.

But that's what makes them fun to worry about. Fair enough, yeah, what about you, David? So I might actually steal your answer. Because it's are distributed systems from the more theoretical level. I've been digging into the actor model, which is the basis of so many distributed systems like Erlang, Elixir. Akka, can you explain us what? The actor model, right? So actor model gave me one of the biggest aha after finite state machines give me that initial aha, and so the actor model. It's essentially you're an actor, I'm an actor, you're an actor. You're an actor, we're all actors and we're all sending each other messages, and so that way we don't have this sort of conflict. Of. You can't read in my mind, you know, you can't read my mind, I cannot in. I cannot directly influence your decisions. I could just talk to you, so that's sending you a message and you could React based on that message.

But so it's sort of the concept of local mutability, like nothing else can touch your local state except you and you. Just. You could send messages, you could receive messages. And when you simplify programming and distributed systems down to that, like this whole message passing idea, things just make so much more sense. They kind of like a pub/sub kind of thing, yeah, in a way, in a way, yeah, it's like pops up, so you're never directly like manipulating anything. I mean, it's, it's less side effects in a way. Yeah, is it like? It sounds to me like it's a structure imposed on top of a pub/sub architecture? Like how you're like, you're not allowed to send messages in a certain way or maintain states, sort of, yeah, it is like pops up, but instead of the B pull method, it's a push. So, you know, we could spawn actors, or we could have references to actors, and we could just push messages onto them.

And it bits like directly into distributed systems. Okay, sounds like I know what I'm supposed to learn about. Next actor model. It's nice to inspire each other. Actually, I have terrible nightmares about hug, hug. Because back in Engler, once there was this thing called the broadcast and the admit, and that created a mess. Together with a yeah, that's double, two-way binding things and your data binding. It doesn't mean that the whole architecture is flawed. That mean that, in that case, it didn't work for us, at least for me. So I think so, like, do you want to watch the talks of you? Like, if you want to go, we're keeping, it's fine. Thank you guys so much. No, not for real, and we're gonna leave you to watching the talk, so thank you, thank you.

Play from 30:00