Ben Lesh is a senior UI engineer at Netflix, where he works on projects that use reactive programming in JavaScript to manage massive amounts of data. Ben talks with me about a variety of topics, focusing on reactive programming and data stream processing. Ben also gives his advice to you, whether you are a young developer or well into your career. Make sure you Tweet at Ben at https://twitter.com/benlesh and thank him for coming on the show! Today's episode is sponsored by DigitalOcean. Go to https://digitalocean.com to get started, and use the promo code "DeveloperTea" on the billing page after you create your account to get a $10 credit!
Ben Lesh is a senior UI engineer at Netflix, where he works on projects that use reactive programming in JavaScript to manage massive amounts of data. Ben talks with me about a variety of topics, focusing on reactive programming and data stream processing. Ben also gives his advice to you, whether you are a young developer or well into your career. Make sure you Tweet at Ben at https://twitter.com/benlesh and thank him for coming on the show!
Links:
Today's episode is sponsored by DigitalOcean. Go to https://digitalocean.com to get started, and use the promo code "DeveloperTea" on the billing page after you create your account to get a $10 credit!
Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell and today is the second part of my interview with Ben Lesch. In this part of the interview we talk about reactive programming a little bit more and we also talk quite a bit about imposter syndrome and then Ben gives you some really good advice for new and experienced programmers alike. Thank you so much for listening to Developer Tea. While you were listening to this episode, if you didn't do it last time, make sure you open up whatever podcast application that you use. Go ahead and open that up and then subscribe to the show. And what that does, first of all, is it guarantees that you never miss another episode of Developer Tea. It gives you a quick alert whenever a new episode comes out, which is four times a week by the way. We typically do every Monday, Wednesday, Friday, and then either Tuesday or Thursday we'll have an inspiration episode of Developer Tea. So if you're interested in that, go ahead and subscribe to the show. So if you subscribe, you don't miss any of those. And also you don't have to think about it. It takes some time out of your day of having to remember, having that kind of cognitive overload of going and saying, I need to go and check out the newest episode of Developer Tea or just entirely forgetting it altogether and then falling behind on the episodes and all that. So go ahead and subscribe. That is a huge way that you can take a little bit of load off of yourself and help out the show and help out the show. By just listening to it. That's an amazing thing about the show is that you just listening to the show helps me out. It's really awesome. Thank you so much for listening to Developer Tea. Now let's get to the second part of the interview with Ben Lesh. So Ben, you are in a senior role at Netflix, correct? That's right. That's right. And were you hired directly into that role? Yes, I was. So actually, most people that work at Netflix are senior level. So Netflix doesn't really hire junior level developers. Now I'll say that with a disclaimer, maybe they started to now, but generally what they do is they look for people who are already experts in their field. Sure. Like you mentioned in the previous episode. Right, right. So that's really interesting because I've listened to a lot of people who are already experts in their field. So I've listened to a lot of what you, well, let's save that part of this conversation for later. At first, I want to talk to you a little bit about something that I think is a hot topic. Well, it is a hot topic. If you go and just look at Hacker News, I'm sure if you search for the word functional on that page, you get like 30 instances. Can you tell me, just give me like the tweet version of what functional programming is. And then we'll talk a little bit about some of the things that functional programming can address. And I know that also, well, just let's just start there. Okay. Well, the tweet version, I'm not counting characters, but I mean, the real tweet version would be functional programming is programming of functions, right? But no, functional programming is generally where you're trying to program using the scope or the closure of your functions and in a mutable state to pass. Data from one step to the next in your function. So the real thing about functional programming, the reason it's so important is functional programming lends itself very well to concurrency. And while we don't have real concurrency in JavaScript right now, we are definitely going to have it in the future. There's simply no way around it. You know, as I had stated in my other talk, the cores are not getting any faster. We're just getting more of them. So. Now that we're building these larger and larger and larger browser applications with JavaScript, JavaScript, in order to scale these applications, we're going to need to be able to utilize those other cores, which means concurrency. So it's a good idea to learn functional programming now and get used to the ideas behind it to prepare for that future, because imperative programming makes life very hard in a concurrent world. Sure. Yeah. So let me go back on my previous statement. It's impossible to talk about functional programming at a tweet length conversation because it's just a totally different paradigm. It's quite literally, if you were to search programming paradigms, there are entire courses that teach you how to think in these different paradigms, one being imperative and then the other one being functional. Those are the two big ones. And then there's different versions of those of those paradigms. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Functional programming is not. Functional programming is not technically new. Right. We've had lists for years and years. But the reason why it's so important or why functional is seen as kind of the future trademark is because of this concurrency issue. We only have, you know, eight to 16 cores on our computers, depending on if you're hyper threading. Who knows? Who knows? exactly how that works, but I'm sure somebody listening to the show knows how hyper-threading works. I actually don't. I have no idea how hyper-threading works. Anyway, so we only have, you know, a limited number of cores. So our JavaScript is really fast for, I mean, for now, right? It's fast enough to do what we've been needing to do. But the future, as we said on the last show, everything is changing and it's changing very fast. And functional programming addresses this concern because it helps you handle state. And that is really the way that I see kind of the major benefit if I had to package it in a very small amount of words. I would say that functional is, the reason why it works so well for this is because you handle state much better than you handle state. And so I think that's a really good point. When you don't mutate your data or you don't mutate what's in memory with multiple different things coming around and changing whatever is in memory, if it's functional, then you don't have, that data isn't changing. It's just, you're creating new copies of that data and passing them around to those different processes. Right. Yeah. Theoretically, if you're doing it properly, you'll be using what's called a mutable state where you're just making a new copy for each function that's in the data. And so that's a really good point. It's doing something with that data. I mean, I guess for your listeners that don't quite understand what you mean by mutating state, that would be along the lines of, let's say you have two threads or two processes doing something at the same time. And there's one array, let's say that they're both attempting to add something to. You're going to have to block one of those threads and let the other, do its work in order to keep them from both trying to update that array at the same time, that would be mutating the array at the same time. So in that case, the array would be mutable data and that's, that's not, that's not ideal. So generally it's better to allow now that some of that still happens with functional programming. It's just that it's being, generally it's being handled by a framework or it's being handled natively and not by the, the author at the time. And that's usually where you get into some sticky business. So yeah, it's functional programming is very, very important going forward. Yeah. So I work with Ruby quite often and we see the term thread safe, which is thrown around as if it means concurrent and it's not the same thing. Thread safe just means that you're not going to see two things changing that stuff in memory at the same time. You'll have a mutex or something that locks up that other thread and basically keeps the threads from doing things that they shouldn't be doing. And it's not an easy problem to solve even with all those tools. I watched a Ruby Tapas episode. I don't know if you work with Ruby ever, Ben. I'm imagining probably not. No, not much. There's Avdi Grim as a member of the Ruby community and he created this site called Ruby Tapas and it has these videos that he spends like five or six minutes explaining a concept and he goes through a thread safe exercise essentially. And man, if you've never worked with that, it is kind of a brain bender the first time you see it because we aren't used to thinking that way. We're used to relying on... At most, our parallel code working in parallel and then our... When I say parallel, I'm sorry. I mean our synchronous code working synchronously and then at most like asynchronous and event-oriented things where it comes back from whatever call it made and you can respond to it in a callback. Right. But this is totally different from that because it doesn't even know about the other thread necessarily. Right. So yeah, that's... I spent most of my time on that. I spent most of my career actually as a C-sharp developer. So in C-sharp, we did have threads. We had semaphores and locking and all these various mechanisms to deal with that. The one thing that people kind of skip over when it comes to like a functional style of doing things versus the more imperative way in dealing with semaphores and mutexes and things of that nature too is you only have a finite number of threads on... A machine. So you have to... You have to watch. You don't want to have blocked threads. You don't want to have a lot of blocked threads where you have a lot of things sharing something that it's mutating. So, you know, nine threads are locked waiting for one of the threads to do its job to this object and then continue on. That's why things like node and the event loop work so well. Because it's... It's all about, you know, non-blocking IO and that sort of thing. But it does get more difficult when you're talking about taking that same event loop and, you know, getting concurrent or getting parallel. I would not want to be the implementers when they have to finally tackle that issue with JavaScript. It's like promises, but not completely. Right, right. Yeah, that'll be interesting. I would imagine that a lot of... A lot of... Discussion around, you know, how is it different from asynchronous is bound to happen. Right. Go ahead. For sure. That's the biggest... The biggest thing about what I suspect is going to happen is that they'll have things like, say, your maps and your filters and your foreaches. As long as you're dealing with immutable data when you're inside of those functions. That those sorts of things could be parallelized. I'm just taking a stab. But I'm going to guess with JavaScript, they're probably going to lean on ergonomics more than having the raw powerful things like mutexes and semaphores to deal with threading. But, I mean, it's all conjecture right now anyways. Because as far as I know, it's not happening right now. But it has to be discussed. It's something that's absolutely got to happen. Sure. Sure. And it'll probably happen in open source first. I would imagine probably someone's going to fork IO or fork node and then do something that will enable... This is over my head. This is where my... Listeners, this is where my programming knowledge comes to a halt. I don't know how... I would not know how to go about implementing, you know, multi-threading with JavaScript. I would be scared. Even if I did know how, I would be scared too. Because you'd have people with pitchforks and torches. That's your torch. You did this wrong. Yeah, I wouldn't want to be a part of that. But yeah, either way, functional programming is an important thing to learn because of this future. And it also cleans up some other issues that you can run into with imperative programming where you're maintaining a lot of state and having to do a lot of mental math about when what is happening. Those things get a little hard. Have you messed around with... React at all? Not with React. Okay. I've played with it, but I can't say that I've written an app with it. Okay, yeah. So I've done... I could probably say that I've played with it. I haven't really done anything super big with it or anything like that. But that was the first moment where I had the epiphany of, wow, this is why just from a development standpoint, from being a happy developer, at least employing some of these concepts of immutable data and flux, if you want to use the Facebook term, but the one-way data flow, why that can be a very powerful and empowering practice. It's not just about concurrency, although that is a huge part of it, but it's also about this helps you control state. Right. Right now, the pragmatic reason to deal with React, or even with reactive programming, which isn't necessarily React per se, but libraries like Bacon or Most or RxJS, is for that reason of trying to control state, more importantly, trying to control side effects, too, when it comes to reactive streams, libraries in particular, like RxJS. So we use RxJS heavily at Netflix for the app that I'm on, and Rx... Java is very heavily used in my department. RxJS is very heavily used, I believe, for the customer-facing UI. Uh-huh. So we're big proponents of reactive programming at Netflix. Sure. And there's a lot of great reasons for that. I mean, above and beyond the reasons I just gave you for functional programming, you know, reactive programming with functions, not functional reactive programming, which is something different, is very, very important. So tell me what you mean, because I'm sure there's quite a few people listening who this is the first time they're hearing about reactive. Tell me what you mean by a side effect, because that's also talked about quite a bit in functional programming. Right. So the basic thing, the side effect is kind of the final result of, you know, whatever your program is doing. So you would have some series of inputs, and... with that series of inputs, you're going to do something to them, like say maybe an input might be a button click or, you know, an Ajax call coming back, and you're going to massage that into something that you're going to display on this screen and or maybe trigger another event. The act of displaying something on the screen or triggering the other event, that final result is the side effect. And the act of transforming whatever inputs you have into something that you want to send to those outputs, you're going to do something to them. At the same time, you may want toension yourijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijij from these other two properties and so on and so forth. So when you update a property, it goes to this chain and transforms all the data. But the difference between that and say reactive stream processing is that at each step, those properties are broadcasting to everybody, hey, I've changed. So if anybody else needs me for anything, you can do something with my new value. And they say nothing about the intention of why it's changed or it was changed in the process of doing what or why. And so you can incur side effects, right? So it's whereas when you're doing reactive stream programming, what you do is you have a stream, an observable stream of events coming in over time. And you combine them or merge them however you need to. And then you map them and maybe you call some other events and you're like, another Ajax call and you get the result back and it's still part of your stream. And at the very end, you have a do or a for each where you're saying here, this is where I want to express to the outside world what I've done and write to the DOM or make a call over a service. Finally, this is the landing place of my transformed data. Very interesting. Yeah, it's really good because it allows you to control the flow of your application. Very easily and very expressively. Sure. Whereas, you know, I think we all work on very complicated applications where you kind of do, you just get lost in the code and it's not very easy to see the path that something's taking through your application. Yeah, yeah. And so that's implemented. You say, you keep on mentioning streams. I'm assuming that what that is, is like a socket or something like that? Yeah. What I'm specifically talking about generally is observables, which are, they have this concept in RxJS or BaconJS or MostJS, but they are streams of data. An observable is a stream of values. So any collection of values emitted over any amount of time. So it could be instantly, it could be once every so often. What they are, you're familiar with the iterators. Yeah. So an iterator, I'm assuming. Mm-hmm. So that's new. So an iterator is any collection of values. And you technically get them over time, but you get them over time every time you say, next, give me the next one. So you're telling it to give you the next one. And if it has something, it gives it to you. Yep. An observable is the same thing, but instead of you having to tell it to give it to you, it just pushes it at you with an event. Ah, okay. So you can take any collection of things over any amount of time and you can start listening to it. And hear however many you need to hear or receive however many you need to receive and then stop listening to it. So the observable also embodies the setup and tear down of that underlying data stream. It could be a socket or an event listener or something like that. So in other words, it doesn't matter. Right. It doesn't matter. So the fun thing about reactive programming is you could have some widget that expects some input and I can give you this observable that says, here's your inputs and you can just use it. Now you have no idea where that came from. I could be getting that observable stream from voice to text. I could be getting it from joystick input. I could be getting it just from an array. It doesn't really matter. All you know is you've got this stream of values, right? So you've been coupled from whatever my implementation is that is giving you those values. Wow. That's super powerful. Yeah, it is. The neatest thing about it too is that because it's a collection, you can do all of the same fun low dash type things that you could do with an array, right? Yeah. Or even an iterator. So you can merge them. You can zip them. You can do all of these really... Map, reduce, whatever. Right. Very, very expressive. Very expressive way to write your code. Yeah. And you said that's... What library implements that right now? RxJS. Is the library that I use. It's pretty robust. It's got a lot of... It's got a bit more... A few more features, I think, than some of its contemporaries out there right now. But the other ones are really solid too. Sure. Most JS is a promise-based implementation of the same thing. Okay. And then Bacon.js is just another take on reactive streams programming. They're all really powerful. I can't say enough things about RxJS though. I really like it. Is this a... Is this a concept that you think will eventually become like a native JavaScript thing? Or is it more opinionated than that? It's funny you should ask. This is exactly what this is going to be. So there's a gentleman that I work with named Jafar Hussain, who you might have seen at ng-conf talking about Falcor. He has an async generator proposal for ES7. It's got some traction. I think it's... In my opinion, it's going to be implemented. At least it should be implemented. And it's very similar to RxJS. Right now, there's actually an effort around RxJS that I'm a part of to create RxJS 3 as ES6 modules and have it adhere to the same sort of interface that Jafar had come up with for his async generator proposal. So the idea will be once it's native, that if you create an async generator, so that's just a generator, a generator function that has the async keyword in front of it, it will return to you an observable that will be no different than the observables I've just been discussing. Oh, wow. So yeah, it's a very, very, very powerful way to develop applications. It takes some... There is a mental jump. I mean, there is a mental jump that you have to make to start doing real reactive programming as opposed to the imperative programming that we're used to. Mm-hmm. But it's definitely worth learning, in my opinion. Because it's a way to embody all of these asynchronous problems that you see in the web, whether it's animations or AJAX or web sockets or mouse input, you name it, it applies with observables and reactive stream processing. Yeah, that's incredible. And so, like I've said, when I started learning React, which, just again, to clarify, is not specifically reactive programming, but when I started learning React, it was interesting to me that it basically, and this is true for Angular and for Ember, these are meant to be the full application. It's very hard to adopt any one of these things for a widget on your site. You have to kind of adopt... adopt these for a much larger scale of thinking to really get the benefits out of them from what I've researched. Now, I'm sure that it is possible to just consider it like, okay, well, you know, the widget is like a little screen and you could ship a reactive widget and that's the only thing that uses reactive programming. But I think that kind of misses the point of these, which is to shift the entire mindset of a given project over to one of these methodologies. Yeah, that's true. Yeah. I will say that I have seen React used in Angular projects and React used in Ember projects. It's... I don't know if it's a best practice to do that or not, but I have seen that happen. Now, I don't think you'd see it the other way around because of the way that React in particular is structured. But yeah, it's the mental shift with reactive programming is... I mean, here's a good example. So this is... So this is... This is the same example that I brought up on the screen at ng-conf, which is, you know, let's say that you have two variables, A and B. And when one of them changes via some event, you don't know what event could be causing it, but I presume that you know what event causes it. But either way, when one of them changes via some event, you need to produce a new variable where you add them together and you create variable C. And then you do something with C. You display it or whatever. So every time A or B changes, you have to add them together, stick them in C, and then do something. So now whatever you're doing with C is actually tightly coupled to A and B. Like it has to have knowledge of A and B. So reactive programming, the reactive way to do this would be to create a stream of A's and a stream of B's. So you would take the events that are changing A and you would create a stream of A, A, A, and you can use it however you wanted. And you do the same thing with B. Whatever event's changing B, you create a stream of B values. And then you can... You can do a combined latest on them, which just says, hey, give me the last value I got from either one of these streams. I want to add them together and emit a value for C. So every time A pumps out a value, it takes the last value it got from B, adds it to A and gives you a value in the C stream. So now you have this stream of C values. And you can subscribe to that and you can do whatever it is you were going to do with C, display it to the screen or whatever. But the interesting thing, is that code is now completely decoupled from your knowledge of where that stream of C's came from. Right? Yeah. It has no idea that it came from A or B. So you could substitute in anything else. You could merge in another stream of alternate C values if you so chose, and it would not break your code. Sure. So that's sort of a high-level idea of how you can find reactive programming. And it gives an idea of what a stream is fundamentally, which is a changing value over time. Like you said, any collection of values really over time. Right. Right. Awesome. I'm going to take a quick break for a sponsor and then we're going to talk about a different topic altogether with Ben. We're going to talk a little bit about imposter syndrome and an interesting thing that Ben does when he talks and, you know, even when he talked to me when I asked him to be on the show. Today's episode of Developer Tea is sponsored by DigitalOcean. DigitalOcean is simple cloud hosting built for developers. They're dedicated to offering the most intuitive and easy way to spin up a cloud server. And in just 55 seconds, you can deploy a solid-state drive cloud server. Plans start at only $5 per month for 512 megabytes of RAM, a 20 gigabyte solid-state drive, one CPU, and a full terabyte of transfer. So, you can deploy a full terabyte of transfer and a full terabyte of transfer. And you can deploy a full terabyte of transfer In addition to offering simple and affordable SSD cloud hosting, DigitalOcean is dedicated to building out a strong community and supports open-source software. They offer a vast collection of hosting tutorials and invite developers to submit articles and they pay $50 per published piece. Deploy your SSD cloud server with DigitalOcean today by going to DigitalOcean.com. Now, DigitalOcean has been kind enough to provide Developer Tea listeners a discount of $10 when you use the code DEVELOPERTEA. So, go to DigitalOcean.com and use the code DEVELOPERTEA to get $10 off today and you'll get up and running with your own SSD cloud server in just 55 seconds. That's DigitalOcean.com. Are you familiar with the concept of I'm assuming you are, but if not, imposter syndrome? Yeah, imposter syndrome, my understanding is that it's the feeling that you don't quite belong in the shoes you're standing in. So, maybe you don't belong in this room of super smart people or maybe you don't know everything that you thought that you knew or that sort of thing. It's a confidence problem. Right. And so, I've experienced this and I think a lot of other developers have as well. And I think some of it is driven by this perspective of the developer that I should be, which is just a fake perception that I have in my mind of what I kind of aspire to be. And the difference between the developer that I am currently and that developer. And we often drive this based on, you know, the really smart developers that we see online somehow sharing their knowledge in one way or another, whether that's through an open source project or like Ben speaking at ng-conf. But Ben said something at ng-conf that was really interesting to me and it's, it speaks to this idea of imposter syndrome. In the opening of his talk, Ben, you said that you were happy to be wrong, that you were, you were more happy to be wrong because that meant that it was an opportunity for learning. Can you talk a little bit about, about what that means to you, about what being wrong actually is? Because again, let me remind everyone, Ben is working at a, perhaps one of the most important, most important tech companies in our world today. They, they process a ton of data and he's, he's leading, well, he's in a senior position at that company and he's openly saying that he very often is wrong. Can you explain the value of being wrong sometimes? Sure. Well, the value of, the value of being wrong is, is plainly put, it gives you an opportunity to learn why you're wrong, right? So, you know, you, you walk away from being wrong, a smarter person. I'm always, I'm always, always happy when I post something on like a blog or I post something on the internet and somebody comes and corrects me. You know, sometimes it happens in a very argumentative, adversarial way. But, you know, that, that doesn't bother me much. I'm, I'm, the only thing that would bother me is if somebody told me I was wrong and didn't tell me why. And I think, well, great. Now I've, now I have to go figure out why I'm wrong. I'm on my own. And that's, that's a lot less fun than you just telling me why I'm wrong. But it's worth verifying all claims anyways. But yeah, it's, it's, it's something that I have learned over the course of my career. So one thing a lot of people don't know about me is I am entirely self-taught when it comes to programming. So in the early days of my career, there, it was quite frequent that I would run into things that, you know, almost every developer knows some term and I have no idea what it is. And I will, I will say that back then, it did, it made me feel stupid, but then I realized, well, but now I know, right? So I felt stupid for a second, but it's not a big deal because now I know and I'll never feel stupid about that again, right? Right. So that, that was, that was kind of the origins of my, my thoughts around this. And it's, the other thing is if you're, if you're afraid of being wrong, which I think everybody, is, but if you're actively afraid of being wrong or being corrected publicly, then you're going to be afraid to speak up publicly. And it's, it's going to really, it's going to really hinder you. You know, I will, I will say this. I have, I have a few advantages over, you know, when you say imposter syndrome, there's, there's a whole swath of marginalized people in tech right now that have to deal with, to deal with this, this particular issue in ways that I can't imagine every day. You know, because they, you're going to work, you literally don't look like anybody else where you work, right? There's, there's, I can't, I can't imagine what that's like, but it is important, you know, when you, when you encounter fears, at least the, the fear of being wrong or the fear of saying something and sounding stupid, you know, that, that you realize that the worst that can happen is that, you know, you're corrected. And if, if you, if you take that correction well, generally speaking, all that really happens from that is you walk away having learned something. So, and what I mean by taking it well is, you know, not being offended by, you know, someone correcting you that you were technically wrong on something. Sure. Yeah. And I think the emotional side of things is, is one that we often ignore or try to push down and, and deal with it in the wrong kinds of ways. Like for instance, let it affect the way that we're feeling in the future about that same thing. Like very often, if you, if you feel like you were wrong about something and somebody decides to correct you, even if their tone is slightly off or condescending, it's easy to say, oh, wow, that is who I am. That's my identity of whatever that person just pointed out in me that I'm weak at. And now I'm just going to spiral downward. And it's because of some, objective part of who I am rather than, wait a minute, I'm just feeling the emotion of rejection or I'm just feeling the emotion that comes along with like a shame, a moment of shame where you did something wrong. And I think we can mitigate a lot of that if we go ahead and know, number one, the best of the best, like people like Ben, I'm going to go ahead and call you one of the best of the best because I can, they still make mistakes and happily, make mistakes. And you're going to make mistakes forever. Like there's no, there's not going to be a day, probably unless maybe you have a fluke day, but there's not going to be a day in your life where you don't make some mistake in some aspect, whether that's on a relationship level or if it's on an actual, just you're writing bugs in your code. There are mistakes that are going to litter your life. That's just the truth of life. And so what Ben is saying and what I'm also agreeing with Ben and saying is make the best of those mistakes and turn them around to be good things and learn from them. Right. Yeah, absolutely. Absolutely. The other thing to understand too about, you know, the idea of the developer that you think you ought to be this, this, this mythical person that you'd like to become is, you know, I work with a lot of extraordinarily intelligent people. And I have to say that from time to time, I feel I'm intimidated by some of the folks that I work with because they are so smart and they're so brilliant. But the truth is that all of these people, and we've actually sat around and discussed this recently in the office, every single one of them will for the most part admit that on a daily basis, you know, they find themselves utterly confused by something they're doing or, you know, just kind of, it's this thing with developers where really what you do as a developer is you break code like 99% of the time and the 1% that it works, you commit it, right? That's the job essentially. And everybody's got to learn something new. All of these people that I work with would not be as smart as they are if they weren't willing to risk being wrong or, you know, risk admitting that they didn't know something because they have to go out and learn it. So yeah, any developer that will not admit that they don't know what they're doing at least one time a day is probably a narcissist. They probably just won't admit to it because they have too high of an opinion of themselves. Just like any developer who says that there's nothing wrong with a given framework, right? You mentioned that at ng-conf. I thought that was so poignant. Don't trust people like that. People are like, this library that I use is beyond perfect and won't admit to any of the flaws of it. Yeah, they're either dumb or they're lying. I don't know. Or both. They're dumb and they're lying. Right, right. So you've given so much advice in this interview, but I'm going to ask you for a little bit more. And this kind of ends out the interview and I usually do this with guests. So it's kind of interesting to see how much advice can come out of these conversations. And I'm really thankful that you've been on the show. If you had 30 seconds to sit down with a beginner developer or a experienced developer well into their career and give them advice from your experience, what would you say to them? Well, I think I would tell them to just approach software development with a passion. I mean, don't do it because it's a paycheck. Do it because you actually enjoy it. If you're working on something at work that is particularly boring, then work on something on the side that's not or figure out a way to make it not boring. But most importantly, it's learn something new every day. If you find something you don't know or something that's confusing to you, that's perfect. That's what you're looking for. You want to go find the thing that's confusing to you and then make it not confusing. Learn more. Why it's confusing you and learn about it. And then you'll walk away a better person for it. So that would be my advice is always learn new things. It's great advice. Thank you so much for being on the show, Ben. Thank you. Thanks for having me. And thank you for listening to Developer Tea. I really appreciate your time. Ben has been awesome. I hope that you enjoyed this interview as much as I enjoyed interviewing Ben. Absolutely fantastic. If you haven't subscribed, make sure you subscribe. And also, if you would like to support the show, I know that not everybody can do this. There are just a few people who are able to support this show financially. But if you can, go to developertea.com front slash donate. That is a huge help. However, if you can't support us financially, if you leave a review, that actually is a huge help as well. Just go to iTunes and leave a quick review for Developer Tea. That is a huge help. Thanks. Thanks so much to our sponsors. And thank you for listening. And until next time, enjoy your tea.