:ericnormand

Summary: I talked to Jordan Miller on her podcast about my origin story. It was so fun!

I talked to Jordan Miller on her podcast about my origin story. It was so fun!

Lost in Lambduhhs - :ericnormand

Transcript

(upbeat music) - Howdy folks, so very special guest today. I am very excited for this. Will you please introduce yourself with your name and your pronouns? - Hello, my name is Eric Normand and I refer to myself as with he, him, his pronouns. - Awesome, and I refer to you as Normie. I hope it's still okay. - That's cool, that's cool. Never heard that before though. You're the first person. - Well, it's just so fond of your work that we had to get a colloquialism. We can't, Eric Normand, every time. It's a hard D in the end. - Uh-huh, that's, I mean, it's very flattering, very flattering to have a pet name from someone that's cool. - From random people. - Yeah, well, you know, that's what you buy into when you're public, you know, in public, so it's cool. - So while getting to a little bit of your past, I know that you're now in New Orleans, is that where you grew up? - Yes, I'm from New Orleans, grew up here, yeah. - Oh, wow, so you've been through a lot. Your house and everything is okay now, and we had some recent turmoil down there. - Yeah, we just had Ida a month and a half ago. And yeah, I mean, it's not back to normal in the city, but we're getting there. - Takes time. - Yeah. - Well, I got first thing, what made you want, what drove you to create content, this instructional content, and become a public figure like you are, and a follow-up question is, do you think it runs in your family? - Mm-hmm, so what led me, so I was in the Peace Corps and I taught, and that's where I really learned how much I liked teaching. I just like taking ideas and finding good ways to present them. And about the public figure thing, like if I look back, I mean, since I was a kid, I always was into media. Like I wanted to publish, like I remember at one summer camp, I was like, I'm gonna make a newspaper, and I'm gonna have stories and stuff and publish it on a photocopier and distribute it to everybody's locker. I didn't realize how much work that whole endeavor would be, but it was a cool experience to do it once or twice. I mean, I remember when before the term podcast came out, I was like, I need an internet radio show. I never did it, but I was always like scheming and planning, and I guess as it became easier and I became more organized as a person, I started actually doing it, so started with videos. I started making videos before I started blogging. - And now you have a newsletter, so that dream came to fruition. - That's true, much easier to write. I mean, it's more like, I guess a column as opposed to like the whole newspaper, so that's a lot easier to do. - Well, it's really interesting, 'cause it must be great for you to look back over it, 'cause as a consumer of that newsletter, that content, you can clearly see the illustration of your growth as a content creator, it kinda used to, I feel like it used to be more technical, how to write a function, tactical, how to write a function, this is it, and then in the last few years, it's gone kinda zoomed out, it's more, how to architect a system, how to design a system, and we'll touch more, I have more questions on this later, but through the newsletter, I really think that that gives a sneak peek into your growth on what you're interested in, I think that's really cool. - Yeah, that's interesting, I think of it as like, I mean, I just make sure that it's not boring for me, you know, and there was a time when I wanted to just talk about all these nitty-gritty technical details, but at some point, I feel like I just run out of ideas of those, what's interesting, and I'm thinking about something else during the week, and so when it comes to write the newsletter, I have to write about those things, 'cause those are the most developed ideas I've got at the time. And right, I mean, that's been my thing since the beginning, is like, if I start to feel bored with it, it feels like a chore, I need to change it, I need to evolve it, and it started as like links, like 10 links, and over time, it's changed into essays. Now it's like an essay and a challenge with a little bit of news if I have something important to talk about, but yeah, it's just, it's evolved with me and what I'm interested in at the time. Keep me interested in it. - How cool is that though, as a, you know, how many developers, you know, have that data to, you know, I had a data, my little data to fall back on. - So look at themselves, yeah, yeah. It's funny, I was talking to someone yesterday and he was like, oh, I want to read this article that you wrote about this. I'm like, I wrote an article about that, and I had to search my own site to find it. You know, it's well past the point where I remember everything I've written. And of course, when I read it, I'm like, oh yeah, I remember writing this, do I still believe it? Yes, no, you know, how would I do it differently now? Those kinds of things go through my head, but yeah, it's good, good time of article. - That'd be interesting segment. Like, self-reflections, recursive reflections, where you go back to your earliest content and you kind of reflect on whether your opinion has changed. - Sure, sure, and you know, sometimes I write it, I take like a mode of writing where it is kind of like, I'm just exploring this idea, I'm not sure where it's gonna go, and I don't even know if I believe it. And then sometimes I try to take a more authoritative mode where, you know, if it's something super technical, there's often like a very clear answer. I take that mode and those, I feel like, if someone's gonna land on this 10 years later from a Google search and they don't know me and they're not like following the sweep of my writing, like I need to go back and revise it if it's wrong, or if it's changed, you know, so I do try to curate my old stuff if it's in that other mode, you know. - Well, that's actually a question I have for you here is, you know, how you manage the responsibility of creating instructional content for things like a framework that is constantly changing, 'cause that's what I'm struggling with as I'm creating instructional content, you know, specifically reframe. There have been some fundamental things that have changed in that framework over the years. And, you know, it's interesting to you sign yourself, I guess, when you don't realize initially when you make a lot of these things, I didn't, that you're signing yourself up for a lifetime of responsibility, of maintaining it. - Yeah, yeah, sure, I didn't realize that either. And, you know, I have to say, I don't think I do it well enough. I don't manage that well enough. My first strategy has always been teach the fundamentals. And those don't change very slowly, right? And the issue is that even one of the problems is like sometimes you'll have, even like your examples don't run anymore. And so someone can't run through your code to get to the fundamentals. So I have tried various things over the years because, so I've been trying, I always try to avoid re-recording the lessons, the videos, but sometimes I have to. And I do have like a bunch of like bash scripts for, so like when I, so for the code, right, for changing the code. So sometimes like there'll be a bug because, you know, like when Java 1.9 came out, there was a bunch of problems with dependencies and XML libraries that no longer existed on, that came with the JVM. So you had to add something to the project file. And I had all these repos with all these different branches, because, you know, each lesson has its own branch so that you can like jump right to that point in the course. And so, you know, I just spent a day figuring out how can I write a bash script that will change to a branch or like list all the branches, loop through them all, change to that branch, copy the project file over, commit it, push it, and then go to the next branch, copy the project file. So basically this bulk update of dependencies and stuff, what you can do with the project file 'cause like it's kind of doesn't change that much. It's hard to do with the code where you're like, oh, now this library function has got a different name or it's in a different namespace. You have to manually do those. But I still feel like I'm figuring it out. I know some online teachers, they actually do just re-record their courses like every year or so, which I'm actually thinking is a very smart thing to do 'cause like I forget what's in my course, you know? And there's probably stuff I forgot that I could say this time, you know? And so it's not just like things are out of date. It's also you're getting better as a teacher and so this course is just constantly improving. And the trick with that though is to have fewer courses. And that has been a challenge for me because I'll try to be very succinct with this. In some communities, there's a lot of customers. And so you can survive or thrive with a handful of courses and you keep them up to date. It's manageable by a person. But I have found that the only way to grow to where it can pay the bills is to have more courses. My existing customers will pay more money for this new course and I needed to do that. And so I have like 41 courses, right? And it needs to be on the order of like three or four. And so I've been in this transition period since about March of moving to a new platform, consolidating courses into frankly more marketable, like easier to understand what you're going to get packages. And also with that, the idea that they will be more manageable, that I'll be able to go through the modules and say, okay, we're going to just update this course. That's first quarter of the year updating this course. And just you might have to add stuff, delete stuff, re-record stuff, and have a real process for doing that. And I'm still in the middle of figuring all that out. - Well, you're also working full time now, is that-- - That's right. - The case? - That's right. I recently joined Biasat on the Lono Cloud team. - Oh, I did not know that's where you landed. That is awesome. I am familiar with that team. - Yeah, it's a great team. - Aaron, and that is so great that you landed there. Oh, yay, that's awesome. - I'm very happy there, so, yeah. - Oh, oh, that is sparkling news. I didn't even realize I would hear today. So, and this is more kind of the reagent space. Why? It seems like there is a shortage of good reagent reframe component libraries. Why do you personally think that is? - Ah, that is, wow, I don't know. - And do you agree, I guess, if the other-- - Well, shortage implies that it's a problem. And I'm not sure if it is a problem. So, I personally don't find it to be a problem, but a lot of, like, people at companies I've talked to where they kind of want to do closure script and they're like asking me, so, where are all the nice component libraries? And I'm like, why do you need a component library? Like, what I would like to do is get at the raw HTML. And I've never found a component library that does what I needed to do. I'll try one and I'm like, ah, this isn't right. And there's bugs in it, so I just never want to use them and I've stopped looking for them. And instead, I leverage the fact that reframe makes it really easy to make components that are super interactive to just custom build the stuff I need. But I can also see the appeal of having reusable components that someone else has made. And I don't know if it's, like, it's sort of my attitude is common where like people are just writing what they need and not publishing it as a component library. It could be that people just find it easy enough to use a regular React component library without wrapping it. Yeah, those are my two ideas that is either it's not a problem or they solve it by using regular React. - Well, that's honestly what I do. I enjoy writing components. Like, don't you dare try to steal in a lot of components that you need when you actually get to a level are kind of domain specific to a certain extent. - Exactly, exactly. - Oh, well, I'm excited to hear your thoughts on a domain-driven design. Well, I guess that leads us very well into talking about your book. So I am a normy disciple, as you know. (laughs) We have a club. We don't tell you about it. - Yeah, we should have, I could have like apostles that would be pretty cool. (laughs) - Just get a discord channel together and a piece of puzzles. - Roamed earth. (laughs) - Together. - Spreading asynchronous, okay. - Yeah. - So the concepts in the books really resonate with me. Obviously, you know, I also, I am a front-end reframe, you know, that's kind of my jam. So a lot of the concepts really resonate with me, but tell me more about who you wrote this book for. 'Cause it kind of seems like you're expanding your audience a little bit and I'd love to hear that. - Yeah, right. So expanding the audience is true. It's, that's insightful. I, like I said before, I feel like the closure community is a little small to make a living off what I do. And that was an attempt to broaden it to functional programming in general instead of just closure. But, to answer your original question, the book was written for two people, two groups. A lot of people ask me what is functional programming and why should they do it? And I, so I had that type of person in mind who's like, they're a programmer already, they're hearing this thing about functional programming, but they go to look it up on Wikipedia and it doesn't help them. And some of the communities have a very strict definition and it looks like you need to use Haskell or some, you know, very, you know, language that they don't, they can't use. And I wanted to write a book that told them about all the hidden assumptions that the other books make. For instance, most books will define functional programming as programming with only pure functions. - Right. - And then they might have one paragraph on what a pure function is. And then, you know, 20 pages in, they're doing Lambda Calculus gymnastics, they've got, they're into category theory now and it's like, wait a second, like I missed something. And so I decided that that idea of pure functions really needs to be taught for a long time. I think I spent five chapters on it and it's not just like, what is it? It's how do you work with it? Why do you wanna use them? How do you create them? How do you identify when something's not up your phone? There's like a ton of skills around that that as functional programmers were so used to doing, we don't even think twice that like maybe someone needs to learn this explicitly. And so yeah, that was the first group. So the second group was people like me who had been asked a lot for recommendations for books and don't need the book to read for themselves, but you know, whenever someone says, hey, do you have a good book on it that will teach me functional programming? Not really, like there's books that are very academic. There's books that are specific to a particular language, but not one that's gonna give you the ideas and the concepts. So yeah. - Well, there's like, there's like SICP and software design for flexibility. And some of, you know, and you even, it seems like you even present all those concepts just in a more accessible way. - Yeah, I just, you spend more pages on them. - But those aren't super attainable and that's currently kind of what, it's like wanna get in a functional programming. Here's a wizard book, have fun. And it's like, what is scheme? - Yeah, well, sure, sure. And if you can get past that, you know, first of all, what's defined is that it was designed for MIT students. So already it's kind of like you've passed a lot of mathematical hurdles, right? So you're, it's, if you look at the exercises, they get complicated really fast. - Oh yeah. - And I wanted something that was like, just a gentler, gentler slope, yeah. And I think another, I'm not sure if this was a intention, but then there's also, you know, the JavaScript developers that maybe do react and they're like, oh, I'm a functional programmer. And I'm like, oh, I don't think that means what you think it means, but-- - Right, I think it's awesome state right there. (laughing) - Yeah, well, I mean, a third purpose, which is kind of like a second order purpose was, I feel like there's not a literature of functional programming for industry. Like, obviously there is an academia, but in the industry, we don't have the kinds of books that you see like the Gang of Four design patterns book. It's kind of like canonical, you can just refer to it and whether you agree with it or not. Like, that's not the point. The point is that it is a fixed thing that you can talk about that you can, you know, if you can reference it in another book and say, oh, there were these problems that were caused by the design patterns or like we use these design patterns and it worked, you can talk about them. And I wanted to spark a conversation in a functional programming in industry. And so part of that was having to define functional programming in a new way that was not just all about pure functions. 'Cause I know that I don't just use pure functions and so that can't be it. And the other thing is if you ask a Python programmer, like, what do you do? They're not like, oh yeah, we're all about the impure functions. Like they don't even have that, like it's not a thing that's on their mind. So like, just the fact that we recognize the importance of pure functions was a fundamental step in functional programming. And so I really tried to, you know, you need to come up with new terms to like to kind of jettison the history in the past and like try to spark a new conversation. And I think paradoxically we're the, because we recognize the problems with mutable state and other side effects, functional programmers have more to say about them. - Oh yeah. - Right, like, I mean, not to pick on anybody, but like in imperative programming, because you're not making that distinction, you just, you just, it just permeates everything. Whereas we try to isolate them and we have techniques for making them safer, for being able to reason about how they operate. And so that wasn't like this kind of ironic thing, is that functional programmers care more about side effects. Right, we spend more time on side effects than other paradigms do. So I wanted to show that, that there was this irony there. - That, I mean, definitely if you want to ask, ask a Closurian's opinion about mutable state and side effects, you will get a earful. - Yeah, yeah, yeah. - So there was an article recently in Hacker News about, you know, now we have all these like great design patterns and frameworks and as you mentioned, there are a lot of them are in OO, but we have all of these books and things to rely on, but all of our software still looks like a giant ball of mud. And if we have all of these things and tools to use, why does it still look like a giant ball of mud? And is that one of the things that you're trying to change? - That's a deep question and I didn't read this article, but I do think about this a lot. I think one of the issues is we are building more sophisticated software. You know, if you look at any modern piece of software, the majority of code in it, I mean, basically no matter what the size is, the majority of code is somebody else's code. It's open source libraries or, and this is what's really different about systems from the past. You know, if you go back in time, it used to be you wrote everything to solve the problem. And now we're sitting on top of a really sophisticated stack. You've got an operating system given to you for free. Your database is free. Your like basic web libraries and all that stuff is free and you're just writing this a little bit at the top. - Okay, so that lets you free your mind to build a bigger system. And so there's that aspect that it's still a ball of mud, but it does more than the old balls of mud. And the other thing is, I think the solution to building fewer balls of mud is that we do need, we do need layers, like we need to build, so like layers build to like a tree structure. And as we know that the depth of the tree can be shallow, even though you have a lot of leaves, right? Like you fit a lot of stuff in a tree. It grows a lot rhythmically. And what we have is basically systems that grow linearly or sometimes worse than linearly. Maybe they're like, they're not quite quadratic, but they're more than linear, right? Because you have like interacting corner cases and stuff. So you have like an if statement to deal with the corner case and then there's another corner case. So you have nested ifs or like ifs on top of each other and it doubles the number of code paths you have. And so now you're dealing with that problem. And so every time you're doing this, you're just really expanding out the number of mistakes you can make. The difficulty of testing is increasing and everything. That slows you down and you finally reach some steady state where you can't really add new features very easily. - And then we have agile design, which is a lot of startups and it's great, but evolving requirements from product is something that we as devs, we maybe wrote it because it was supposed to only be two if columns, but now they want 10 different options. It's like, oh, well, that would have been good to know when I design the system. - Right. - Well, sure. Yeah, we have changing requirements and I think we also, we undervalue or we'll underplay the role that our changing understanding plays. We kind of forget that when we first start building the system, we're very naive about the domain. And as you learn, it starts to feel like, oh man, these are all mistakes we made and we've built in these assumptions that don't hold anymore. I don't believe anymore. And the real problem is that those assumptions get spread out everywhere and just you need to reverse the entropy and reorganize it. You need to be able to like piecewise throw away stuff because it was a mistake and you can see a way that's better. And I mean, I push on this idea of layers a lot. The idea is that as you learn stuff and when I say stuff, I mean, you discover some kind of invariant, some timeless truth, right? Something that is very unlikely to change. Regardless of changing requirements and your new understanding. And I mean, I'm thinking in my head of like all sorts of invariants that we believe, right? Like that there's no such thing as a free lunch. You know, something like that. They were like, yeah, that's kind of a timeless truth. Okay, so you have to find these in your domain and they exist in every domain. People resist like even looking for them when I mention it, but they do exist. And you have to push those down, collect them and push them down into the base layers of your system because those base layers change less frequently. So you have to align the things that change that are more volatile. You have to align that with the structure of the code so that the stuff that changes the least frequently is at the bottom and stuff that changes more frequently is built on top. And unfortunately, we have much more, especially with O code. It's much more of like a peer model where it's like, oh, this object collaborates with this object and sometimes you have to say, no, it's actually a hierarchy. And this object is some combination of these more timeless, more primitive objects. And yeah, so that's my answer. And without going too deep into it, 'cause I think that there's also room for better languages. So you understand your domain, you encode it in a language and now you can express much more easily and change, that means you can change it 'cause it's like a few lines of code. You can just throw it away and rewrite it if as requirements change. - Yeah, and tell, will you elaborate more? I hear this term domain-driven design and I hear it, it's kind of getting more popular lately. Talking to, so I always joke that I wear the functional programming hat. However, inside, I'm secretly a data-driven programmer. - Okay, yeah. HashMap functions on HashMap, it's a whole-- - Data-oriented, yeah. - Yeah, and I would love to hear, I guess, the pitch for domain-driven design 'cause I have had people tell me criticisms of that data-driven design falls apart in larger systems, harder to maintain this than the other. I haven't experienced that, but it may just be from lack of experience. But I'd love to hear your opinion on first what you define domain-driven design as, like just what it is and then how it compares to other design principles such as data-driven. - Right, okay, so domain-driven design is a set of ideas by Eric Evans. He wrote a book called Domain-Driven Design and that kind of started the movement. And I'm not an expert on it, but I can tell you what I like about it. The thing I like about it is that somewhere in the book, early in the book, the idea was if you're writing a piece of software about rocketry, you go sit down with the rocket scientists and you code and show them, is this what you mean when you say thrust? You know, and you build up a model of the domain with the expert because you're not an expert, you're just a programmer, right? - Oh yeah. - And you build this thing and it becomes like, if you do it, right, you're able to capture the important ideas, the relationships between the ideas and the important operations that you can do in that domain. And then when you have that, that's a really great start for building on top of, right? So it's the opposite of what most mostly happens, which is you get one requirement at a time and you've got this monolith, let's say, right? You've got this app and the business side, when you're building, let's say you're building in rocketry, right? The business side says, well, we need to be able to set the thrust with this slider. And you're like, oh, okay, well, we have a table, a column in the table called thrust and we'll just make an API request that lets you set the thrust, right? And then that, oh, check off that Jira ticket and move on to the next one. And you haven't captured the important idea of thrust at all. It's just a field that you have no idea what it means and eventually with enough of that, it aggregates into just a mess where you have all these API calls, changing everything. You have no constraints on what means what and what the relationships are. Like you're supposed to be maintaining this relationship between drag and thrust or something and I'm not a rocket person, so I'm just making that up. But I really appreciate going in from the other side, which is we have this very valuable knowledge contained in an expert's head and we have another equally powerful, I mean, more powerful, more general modeling tool, the programming language that can make a very precise and accurate version of that knowledge that's in their head that is useful 'cause you can build on top of. So that's what I really like about it. I feel like that is often not emphasized enough in the domain-driven design community that they talk about like bounded contexts and universal vocabulary, universal language, no, ubiquitous language. And those things are good too, but I really think that that core of like the domain is important. Okay. - So, I wanna respond to that real quick. So what I'm hearing, and I think this is often to trap us functional programmers get in where we embrace abstractions so much, but you can abstract too much and there are a few wrap things in layers of so many layers of abstraction, you don't even know what it is anymore. Like thrust, you have thrust in a separate place over here, you wrap it in abstraction, that abstraction calls another abstraction, before you know it, you know, where even is thrust. And the other thing, I guess I'm hearing you say, is just trying to think about using this in practice, a developer at a company. It sounds like it would be advantageous for devs to, I think, a lot of us will stick to our little, stick to our team, stick to our dev team, whether that's, you know, in bigger companies, you have a separate front and back and QA, and you really only interact with each other. I've heard the phrase that, you know, throw tickets over the wall, you know, oh, got, you know, and we can cut down on that. If you reach out to your customer success team, you reach out to the people that are using your product that you're building and you reach out to the salespeople and, you know, have an open line of communication with the salespeople that are doing demos all day, because, you know, just having that open line, when they say, "Hey, this isn't working," and you're like, "Oh, that's working exactly how "it's supposed to be working, I built it to work," and they're like, "Oh, no, that's not what we asked for, "you know, because so many things get lost in communication," and that sounds, so would that be an example of kind of how to use it in daily practice and embrace that? - Yeah, for sure, for sure. I mean, there's a lot of value in trying to figure out what the users actually need. I think one of the problems that you're talking about abstraction, I think we've abstracted the understanding of a problem into a succinct statement in a georetic. - In a georetic, yeah, totally. - And if it's a very technical problem and you're talking from one dev to another, you know, I put this ticket in here 'cause they had a bug and we just need to reset the database, you know, something like that, that's fine. Like, we speak the same language, but I think that we have this tendency to put, to make our dev team into kind of a black box where like someone's just dropping little slips of paper in the top and we're like, well, I guess I should do this. You know, garbage in, garbage out. And we need to break that box and push back a little more and say, like, I don't, I don't get how this relates to the domain and like, is this really good for users? And, you know, have a real hard conversation about what's going on. You also were contrasting the domain driven with the data oriented, right? - Yes, yes. I don't think that they are that they are opposed. I think that there are some practices that we do in data oriented that could learn a little bit more from the modeling. So one thing that we do in closure is we say, just use a map, right? And I think we need to put a little more thought into why we're using a map and what the map means, right? Like when I get this map, what do I know about it? What can I assume is true? And what can I not assume? That's important too. And when you start having a bigger system and you have maps flowing all through it and, you know, if you could freeze it and be like, okay, what's that map? What does it mean? It's very hard to do if you haven't captured some higher level thing in the code. And what I mean by higher level is like more specific. So a map is very general, but any keys, any values, right? That's kind of all it guarantees. No order, you can get the values out. If you know the keys, you can list the keys. Like there's an API for them, but it's very general. It's not about rocketry, it's not about accounting, it's just general. - Just data. - Yes. And there are certain operations that are domain-specific. So you're encoding this data in this map and let's say you wanna treat it like like an accounting transaction, right? There's certain operations that you can do in accounting. These are domain-level operations that they translate into the operations on a map. But you wanna make sure that you do them right every time, right? And that they're clearly stated and you don't have to, you know, so you build this thing that's like, I don't know what it would be. I'm just making up this like on the fly, but you have some operation, that's some kind of banking operation that it would mean something to a banker if you told them this, if you told them the name of the function. If you don't do that and you keep building layer up and layer up, but you're still treating it like a hash map. So you're still doing get and association stuff at this higher level where you're talking about like your UI that's trying to control the bank that's just, you just cut through and you jump all the way down, I'm just gonna put whatever I want in this hash map. Or maybe it's not whatever you want, it's correct, it's the right stuff to put in, but now you can't change that hash map. You can't change how it's structured or anything. You've locked the UI to this representation layer and I think that as systems get bigger this happens more and more, and people try to lock it down by putting spec on it. They want a little bit of visibility into the system, they wanna be able to check, I got the right keys, I did it right, and I think that's the wrong answer. I think that what you need is to put a layer in the middle that says, don't treat this like a hash map. It is a hash map, we haven't changed anything, we haven't encapsulated it in an object-oriented way in a new thing now that's opaque what's inside. But hey, if you're above this layer, please use these operations on it because these have meaning and we've tested them and they're what we need to do. And that creates a nice little abstraction barrier that means that you can be a little bit more free and think more clearly and be more flexible. The abstraction barrier also lets you change the representation, so you can change the names of keys now without affecting any of the code above it, above that layer, right? Those things are important, that kind of decoupling. Yeah, so like one example that I've seen before is like people are working with these big nested data structures and so they'll do like a get in and the get in has like 10 or 12 elements in the path. Oh, and you see what that does, it means that this code knows about 12 maps, all the whole structure of this thing, 12 maps deep. How are you ever gonna be able to change that map? Because that's spread all over your code. You really need to start thinking about what does it mean when I have this map? What should I be able to do? And I think that that kind of thought process comes from like more of a domain modeling background. And referring back to your book, like I said, as a norming disciple, I have noticed that you've spent a lot of time in a closure script and reframe and just working with asynchronous code and really understanding that flow. And looking at chapters eight and nine on stratified design, I guess I noticed a similarity to how I understand the signal graph flow is supposed to be intended to be used in reframe to handle state management. Will you elaborate a little bit on whether that's just a co-inky dink or whether that was intentional and how I guess your work with asynchronous code and now your interest in domain driven design, some of the things you were just talking about, kind of how all of that has influenced these stratified design, you know, you recommending a preaching stratified design, preaching a strong work. - Yeah, I've never connected those dots. So, I do have, I know I have a mind for like distributed systems and asynchronous issues, like parallel programming. Like I've always been the one in a team to be like, wait, there's a race condition. You know, I just like can see it somehow. And I wanted to capture that in rocking simplicity. Like, how do I do it? How do I see these and other people can't? And it is hard. - It's hard. - It's hard. - It's hard. - But my mind is always like thinking about them, is always looking on the lookout and like, what am I looking for? Like, what am I looking for that they're not looking for that makes, let's me see it. And I realized that it was, if I slowed down my thinking and really introspect it, it was these timelines. I could see the timelines and see actions on the timelines that could interleave. And so I came up with this scheme of drawing that and trying to make it as mechanical a drawing as possible so that you don't have to be so great at it. And you can learn it, right? That's the idea. I could draw it and you can understand what it's trying to say. But I don't know how that relates to the stratified design, like you were asking. Well, I guess me neither. - Yeah. (laughing) The stratified design. So I've just done another thing about me. When I was younger, I was probably in college, I read an essay that was talking about how programmers in general want to, like they get pleasure out of the control that they have over the computer. That this is a little system that they have total authority over and if they make a mistake, it tells them by crashing or however the computer says and that they can configure it, how they want and stuff like that. And that just didn't resonate with me at all. To me, it was never about control. The computer was always a reflection of my own mind back at me. And so yes, there is a thing like you program something, you get it wrong and you get some feedback from that. But what I loved about it was that I realized, oh, I was thinking about it wrong. And so this thing is teaching me that what I thought doesn't make sense or it doesn't work the way I thought it would. And so that stratified design and just thinking of these layers with their kind of different layers of meaning, it's all about that. It's like you write this code and you're understanding better through this, because the code has to work, right? That's a great thing about it. It has to work, whether it's disorganized or not. So it can't go into an infinite loop, for instance, which sometimes math can. And they just ignore that. They're like, well, we just won't go down that branch. But in programming, it has to work. And so there's a razor there that forces you to make a system that both reflects the ideas and works is correct. And that really helps me deep in my understanding. And I feel like when I'm in a good place, a good company where we're not mired and technical debt and et cetera, that I'm learning so much about the domain that we're in. So, for instance, if it's e-commerce, I'm really understanding e-commerce if it's rocketry. I'm really understanding rocketry. I might become a better domain expert than a rocket scientist, because I have the secret weapon of being able to test my ideas really fast. Does it make sense? Is it consistent? Will this work? And I'm not saying I'm a better rocket scientist in general, but I could tell you the minutia of the corner cases and I can see stuff ahead of time that they couldn't see, stuff like that. - Are you gonna apply your programming brain to a domain? And there's an advantage in that because we do think differently. - That's right. That's right. And it's similar to how a writer can become something of an expert through writing about a topic. Right? It forces them to organize the materials. They write it out and they're like, this doesn't make sense. I gotta go research more. And like, they become, I mean, they're not gonna become an expert with a ton of experience and everything, but they can boil it down, distill it into something that makes sense. And it's because of that, it's reflecting. The writing is reflecting their own understanding back at them. You get a lot of feedback. - Yeah. Well, I really love that you wrote a lot in JavaScript because I do think that JavaScript developers, a lot of them, us, I don't close your script, JavaScript, have this advantage of being able to think and understand asynchronous code because as you said, that is not super common. And I think especially in these functional programming spaces, immutable state is like, we don't deal with that. Everything is pure and it stays the same. And it really is a very special skill. And it's, I mean, I know it 'cause I do adopt these functional programming principles, but then also be able to understand asynchronous flow and the two of them together, it's just so powerful because there are those I can think asynchronously, but if they don't really have a lot of these design prints, you know, they don't have rules, it's just spaghetti code. It's just, you know, and they're so smart, you know, but if you just rein it in with a couple of functional programming rules, it's so powerful. - It is, it's true. And I think that that's another thing I tried to build into Grocking Simplicity, that I think, I mean, I don't wanna generalize too much, but one thing I see a lot that I wanted to correct is people relying too much on the authority of like a library, like a popular library to solve their problems. So they'll say, well, I'm using React, so this must be the right way to do it, right? And like React let me do it, or they're like, well, what queuing library do you use? And I'm like, I wrote my own queue in JavaScript and 12 lines of code, like, I don't need a queuing library. And that's something that I think is pretty unique in closure, I mean, it's not absolutely unique. I'm sure other language communities do this, but we don't mind just sitting down and writing our own thing. - A lot of times we do that rather than use it. - Exactly. - 'Cause, you know, I don't know, is this code even, you know, sometimes I was talking about this somebody recently that it's really hard with closure libraries because like, is it maintained or is it unmaintained or is it just finished? - It just works and it's-- - It just works, yeah. - It hasn't broken since, you know, 2012 or something. - Exactly, exactly. - It's true. - But you know what, I have so much fun writing it, I just write it myself anyway, so. - Yeah, and I think that there's, you know, sometimes you write it and you're like, "Oh, this wasn't worth it." But, you know, I feel like what happens with these libraries is that they are solving lots of problems, lots of people's problems, right? And so then they start taking configuration parameters and like, they need to do this other case, which is common, so like, why not just kind of creep in and solve that too? When all you needed was one little thing, right? You just needed to make sure that things happen in the order that they arrived, you make a queue. You didn't need a whole async library and framework for like, mastering the universe of everything, right? And so I remember when I was writing Grocking Simplicity and my editor would be like, "So wait, did you just write your own queue?" And I was like, "Yeah." And he's like, "Why did you do that? "Why didn't you use something off the shelf?" And I was like, "Well, there isn't anything in JavaScript. "There's like almost no standard library." And so he's like, "You gotta dig into this "because people are gonna look at it. "How did you, like, why would you do that?" Like, for instance, we write our own map, filter and reduce. And he's like, "Can you just do that?" And I was like, "Why not? "It's such a simple function to write. "Why wouldn't you?" And so many people just rely on the built-in map. They'd never think about how it might work. And I wanted to bring that mentality. This is your language, you need to build stuff that you can build more stuff on top of, right? It's the same layered idea that you don't just have to do four loops for the rest of your life. Like, you can build something better and build on top of that. And like, you know, we talk about one of the reasons why it's all a big ball of mud is because they're always working at this base layer. Like, they do not understand the idea of abstracting to a new layer. And one of the things I wanted to talk about in the book is like, you can build a new layer. You can always build a layer that captures your assumptions and deals with the invariance. And now you can write less code and get the same effect. - And you understand it better. You know how to use it better 'cause when you just use it off the shelf thing, you know, you kind of copy paste. You see how they used it and you copy paste across your fingers and you're not. But if you wrote it yourself and everybody knows that code that you wrote yourself is the easiest code to play with 'cause you wrote it, you understand it. - That's right. - But I did really like how, you know, that whole section on like managing timelines, like 15 through 17, you kind of managing timelines. I'm like, is that, is that core dot async under there? It's just like a DIY do-it-yourself core dot async basically a JavaScript. - Yeah, she's referring to how we build a like a reactive framework on top of that with queues. I mean, it's not complicated, it's not sophisticated, but it handles a particular problem that you will find in JavaScript when you're doing async code. You have to do a chain of callbacks and you don't want to start the next thing until that last chain is done. Like, that's a very common problem. - Oh, totally. - And you can solve it with a few lines of code, it's crazy. - Yeah, yeah, it's funny that's something that I'm, because I love core dot async in my soul and I'm always trying to use it, but you know, even though it's core, I'm always trying to bring it, you know, as I said, I do closure script but I'm always trying to bring it into problems and I've had coworkers and people before be like, you don't need core dot async for this, just put it into the callback. You're fine. - Yeah, yeah, yeah, yeah. No, but still core dot async was for a while a secret weapon. I think, so another thing about closure that is great is that it was built to take advantage of the host and that applies for closure and closure script. And so you get all the libraries for free and the distribution of the platform and everything. But JavaScript has changed a lot since JavaScript came out, or closure script came out. Closure script came out in 2011 and that was before ES5 or ES6. You know, whatever one had lambdas and stuff. And it certainly doesn't have async await in it. And so I wonder if it isn't time to like revisit and say we're gonna make like closure script 2.0 that builds on top of that to give you access because core async, I mean, I was using it in like 2013, 2014 when it first came out and running circles around anything I could do before that in just plain JavaScript. And you know, just the fact that you can time something out like with a timer or like time five things out like it's, you know, a lot more flexibility and combining stuff. But now that async await is out, you could build all those really easily in JavaScript, those primitives and you can't do it through closure script. So I wonder if there isn't some way to like reboot on the new JavaScript and get that goodness too. - Yeah, we call it, you know, you can't be in a join. I'm like, leverage the call back hell. Lasso the call back hell, make it your. - Yes, yes, yes. We can do that now, which is pretty cool, pretty cool. So going forward, you know, you're working at VSAT, that must be demanding, you know, your book is released, you're thinking about how to, you know, rebuild your instructional content, you know, tell me what you think the next, oh, and we didn't even your family. - My family. - Your family man, you know, tell me a little bit about what's next for Normie. - Oh, a lot of stuff coming down the pike. So I'm moving from New Orleans. - My wife is a medical resident now and she wants to do a fellowship and she got into a fellowship in Madison, Wisconsin. So we are moving to Madison next summer. So that's a big deal. - They'll see snow for the first time, I imagine, or one of the first times, you're gonna have to like buy them a jacket for, you know. - There will be many jackets purchased 'cause nobody has one that can go through the winter there. - Yeah, so, you know, there's all the work of selling our house, getting a new house, moving our stuff. We found schools for the girls, so that's good. - How old are they now? - My oldest is eight, almost nine, like in a week, four days, actually. And my youngest is three. - Did you ever get the eight-year-old we were talking about getting her into D&D, I think. Or at least thinking, you know, talking. - She loves board games. So I feel like I could be the kind of person who's into D&D, but whenever I've played, I have not wanted to do it again. Like when I think about it, like, "Oh, I wanna go play D&D," and then I play, and I'm like, I'm not, like, so I spend four hours making a character, and then we get 20 minutes of play time in, and I feel like it's not fair. You took, like, an eight in intelligence, but you're trying to plan our next move, and like, you shouldn't even be able to do that. You're not role-playing your character, and I don't know, I just don't have a great time. I like board games, though, and my daughter likes them, too, so we try to play cool stuff. Got her into Catan recently, cool. - Oh, I wonder, you know what I was wondering. Is it Catan or is it Catan? I say Catan. - Oh, Catan, yeah. I mean-- - Is it, I don't know. I think it couldn't be Catan. - When you translate something into another dialect, you have to, you have to make, you know, forgiveness there. I feel-- - So do you get the expansion pack and then play it with the whole bit? Your whole family, with your parents, and your brother, and no? - We don't have enough coordination in our lives to be able to all be in the same room, and learn the rules, and get good enough to make it an enjoy of life. Like, you know, it's the kind of game where like, the first time you lose, and you're like, I don't even know what happened. - Yeah. - And then a few times, and you're like, oh, I get it. And like, you know, that means that people have to play several times before. - Play more than once. - Yeah, yeah, there was that barrier. So do you, are you close with your brother? - I mean, we're brothers. Like, when he's in town, we hang out. But he lives in New York, so he's really far. So we see him for a few times a year, maybe. Just when he comes down. We do Thanksgiving together. That's like his favorite to come down for Thanksgiving. - Yeah, I guess I'll share the little normie tidbit here. I'm asking about his brother, 'cause his brother is a comedian who you may have seen. Is that Mark? - Mark, Mark. - Mark Norman, yeah. - Mark Norman. - Yeah, I'm super proud of him, 'cause that's really hard to do. It's hard because the, I mean, being funny is hard, but also the career is grueling. - Oh, Mark, you imagine. You just have to be on every night practicing, practicing, and then there's so much luck involved. Are you gonna get discovered and, you know, it's hard. - Well, I think it's interesting that you both ended up as, you know, there's that, I don't really subscribe to any particular personality test, but I do think there are different kinds of types of people and you both clearly go towards performing and that, you know, that kind of personality. So I think it's fascinating that, or I guess, intriguing to me that you both kind of have that and I obviously was exposed, you know, knew you. You were the superstar in our household before, I think you posted something on Twitter like, "Hey, if you're in town, look at," I was like, "Oh, no, that's, yeah, that's cool." - No. - Yeah, that was, I was very, very shocked, but that is, I guess, just fascinating little fun, fun fact. If you made it this far, ooh, speaking of which, if you made it this far, we have some more fun facts for you for making it this deep into the podcast. Would you like to tell us more about that? - Yes, two things. Should I share them both? - Yeah, yeah, share them both. - All right, so, manning, their marketing is great. They are really, they want to share the love and they have given a free ebook for Grocking Simplicity, my book. It's hard to read. L-G-R-L-L-H-R-4-5-3-C. If you can type that into many, you can get a free copy. We'll put that in the show notes, right? So it's one, so it might be gone. - So it's one, so first come, first serve, I guess? - Oh, man, and well, the other one is, though, more exciting, 'cause I'm sure a lot of people listen to this, they're like, "Whoa, Grocking Simplicity, "that's out, I can get that, that's a thing." And we've been having lots of conversations about it, so the second one is, I guess, more accessible, exciting. - It is a discount code for 35% off, and it says good for all products in all formats. So if you were waiting to get another book, you know, 35% off your whole order. It's "Pod Lamb Does 21." We'll put that in the show notes. And there's a book I can recommend data-oriented programming by, it's a, his name is Yohannathan Sharvet, and he is another closureist, and he's trying to explain what we do in closure to those outside of the closure community, because no one has done a good job of defining that term, data-oriented programming, and he's done it, he's figured it out. So I-- - Actually, very disappointing. I had him, I interviewed him on this podcast, but it was early in the days of the platform that I use, and the data got corrupt, you know, didn't record, right? The sound quality was horrible, it was just not, and ended up losing the whole interview. And so it was like, you know, I might have to have him on again, you know, now you bring it up, and it was super disappointing, but yeah, Yohannathan is really awesome, just trying to spread the word. - Yeah. - Awesome guy, and he's like, he's figured it out. You know, when I first saw, he gave a presentation and a re-closure, I watched that, and I was like, oh man, you're really onto something. It's not just using maps, like there's something deeper that we're doing, and he's broken it down into principles so you can know if you're doing it or not, and yeah, it's great. - So yeah, that's a book on the Manning list that everyone should look into, and it sounds like your books are very complimentary to one another, 'cause it doesn't sound like domain-driven design, and data-oriented design are mutually exclusive. - No, I would say that. - Sounds like they actually are very compatible. - Right, right. Yeah, I mean, domain-driven design, kind of has a history in, you know, it's flexible. Like, it started in the object-oriented world, and so the book talks a lot about how do you design classes, and fields, and stuff, but then there's a book called, Oh, functional. It's another domain-driven design book, but it's using F#. I can't remember the name of it, but it's in Pragmatic Press, it's by Scott Lation. I don't know if I'm pronouncing his name at all correctly. And he has, you know, translated the ideas into the F# type system and, you know, language, and I would think it would be cool to do something similar. I mean, not domain-driven design itself, but the modeling part that I talked about, to do something like that as more general, like, on typed languages. - Oh, I would love to hear you weigh in on that, you know, I guess the two controversial questions. Well, first of all, I, the first question I've sold. - Types of no types. - Well, the types of no, also, what idea did you use, but I know that because I've done your courses, and I'm stealing that question from Vijay, because that's the question. And I actually have to admit, the first time I took your lessons, I saw EMACS. I had no, you know, I didn't go to call, I had no experience or anything. And I'm like, what is this basic bitch shit? What is this, like, what is this? - No pad. - 'Cause my experience with, at that time, was like the JetBrains Suite. So I, you know, PyCharm and TelJ, you know, that's what I was working with at that time. So the first time I saw you screen share EMACS, I'm like, why is Normi using some basic bitch shit? What? And then, you know, I got learned, and now I'm an EMACS. - You like EMACS, okay. - Oh, very, I, very, very much. - Cool. - I'm, I'm, oh, I don't have it as, like, my desktop, 'cause I know people that are super into it, but yeah, I am pretty cool with the Linux and EMACS, you know? I just kinda, open source, free software. - Yeah. - But, so that was one question, we have that answer, EMACS. - EMACS. - The reason I use EMACS, just to be clear, is 'cause when I, I mean, I've been using it for, like, over 20 years now, and I'm just super comfortable. Like, I don't have it, like, super configured or anything. It's a little bit of a configuration, and it's, go ahead. - I would say, tell me how that worked at VSAT, 'cause I do have some, my understanding is that, I don't wanna give away too many secrets, but there's a fair amount of, you all work at EMACS together, and it, and that, you kinda have to share some, some configuration things, is that true? - Yeah, there's some pair programming, and I don't think it's a secret. They have, you know, like, it's a T Mux or something, set up on a virtual system that you can pair on, and it's got, it's got both, the weird thing to me is it's got both the VIM bindings and the EMACS bindings, and you can switch between them. - Space max on T Mux, yeah, I knew it was something just crazy like that. - And, yeah, so I don't configure mine much at all. I kinda feel like you need to run stock, and mostly just correct the mistakes that you have in the UI. So, like, remove the toolbar, things like that, those are my configuration things. You know, you can choose a nice font, but I've worked with people where we're pairing, and I'm like, oh, let me try something, and I literally cannot type on their keyboard, because they have totally changed every keystroke, and it's like, this is useless. - You have to type everything, you know, I just, okay, whatever. - Like, what do you mean control K isn't kill? - Exactly, exactly, they changed everything, and that, you know, I feel like, I mean, this might be very controversial, but I kinda feel like a team, at least, should converge on a standard, you know? Like, it's not as personal as we think it is, you know? Like, you should be able to use anybody's laptop, and you should be able to, that's, yeah. - Something that, I mean, at least on white space, 'cause I have worked on teams where we at least had a linter where we agreed on, like, a couple of things, you know, no more than 80 characters, which got expanded, but, you know, and even just our formatting, we used the same format-- - Code standards are great, yeah. - Code standards, and just, oh, oh, the debate of, it's a vertical alignment, not, 'cause I'm a vertical liner. - Your arguments? - And, yeah, yeah, where I went everything to a line, I know it's control shift A for me, is I think that's just standard. It's vertical aligning where everything is lined up, and some, that's another one that people feel very differently about, but it is frustrating when you put in a PR and you're trying to give a code review and try to see the discs. - And it's all white space, yeah. - And it's all white space, which-- - There is a flag, I think, in the GitHub, it's not a button, but there's a query parameter, something like W equals one, or something like that, and the diffs will ignore white space. - Oh, that's good to know. - So if you, like, deleted something, like, you removed an if that wrapped a thing, and so now everything is over to characters, it won't show that. It'll just show the removal and the, you know, removal at the top of the bottom. - Okay, like, you removed a let or something where, you know, that looks like the whole thing is, okay, yeah, yeah, I'll have to look into that. - I had a friend who worked at GitHub, and he was like, that's our secret. They had feature flags, and so there were so many commits that were just, we don't need this feature flag anymore, and the feature flag is basically an if statement, so they had all these bits of code that just shifted left, and they wanted a way to remove those from the diff, make them easier to read. - Oh, cool, I will look into those secret files. It's not under a feature flag anymore, is it? - No, no, it's, it's, if you're looking at a diff, or a commit, or a pull request, you just, you put, you know, question mark, W equals one in the URL, and it'll. - Oh, that's what it is. - I think that's what it is. W, that's what I-- - I'm sure Google will have some answers too, if it's all. - People often write like the 10 things about GitHub you didn't know existed, and there's like a keystroke you do on a pull request, and it'll do something, and there's no button for it, it just does it like that. - The next Instagram post, like 10 things you didn't know about it. - There you go, it's great content. - All right, well back to the, I guess the question that started us on this, types or no type, static, strong static typing, or dynamic typing. What is your, what's your, I'm sure you could ask this, like all, what's your spiel on it? What are your thoughts? - Okay, I have a spiel. - Yeah, your spiel. - I think they're both good. - Oh, come on. - Oh, come on. - No, that's not my, it's not the end of my spiel. Wait, that was just the start. They're both good, and they're good at different things though. So, when you're first starting a system, things are very volatile. They're volatile because you haven't finished building it. You know, there's tons of features you need at the beginning, and your understanding of the problem is not so good, and it's getting better. So, everything is changing all the time. You, when something is very volatile, the type system is often, it's not just it slows you down, but it can't handle the evolution. Right, there's, like, most type systems are made to be correct now, right? Like, this is the model, and I want you to tell me if I've broken any consistency rules. But, if I change the type, oh, now everything's broken, and I have to kinda go through every error message and fix it, and you need to be able to explore. It's not just like, oh, I need to follow the error messages, and I get to a point where I wanna be. Sometimes you get there, and you realize, no, that was wrong, I need to roll this back and do something else. So, anything that forces you to maintain that level of consistency, where there's always a mismatch between what you're trying to express and what the type system can express. There's always a mismatch. You wanna, you just need to eliminate that, and you need to operate with the types in your head, where they can just change very fluidly and boom. Now, there's the other side, where it's less volatile. Where you understand the problem really well, you've decided, like, even if we get a new requirement, this is gonna be the same. Like, we're not gonna change this part. Yeah, lock it down as tight as you can, you know? It's not just locking it down. It's like, the type system's like a theorem-prover about your code, that you're like, yeah, throw theorems at it, see what it says, can I do this, and make sure that this makes sense, and check my corner cases and all that. And I think that when you see arguments between types versus untyped, and what you don't see is that they're often solving different problems at different volatilities, and I mean, it's like, I think you need the extremes. You need the super loose, keep it in my head, and the super strong. And in the middle, it's not that valuable, right? The mushy type systems that, like, kind of find stuff, maybe they can find the null pointer exception, like, at statically, but, like, they can't do much else. Like, those aren't that interesting. You need some, you want the tighter stuff. And so, I've actually pleaded to both the closure world and the, like, Haskell world. That's two examples, you know, of popular languages on the two camps, that we need the other extreme. We need to be able to start enclosure and tighten it up when we understand the problem better. And we need, also in Haskell, to be able to do the dynamic stuff. You're exploring a JSON REST API, and you don't know what keys you're gonna have, and you don't know what the invariants are yet with those keys. I've worked with some really messy APIs, and they're certainly not using Haskell to, like, make sure that it's all, it all makes sense. So if you try to do that on your side, it's just gonna not fit. Or you're gonna learn something too late, and you've already thrown the exception, you've lost all your state. So, that's my spiel. We need the two extremes. That's where the value is. And depending on where you're at, or your volatile, less volatile, you choose based on that. - Very, very diplomatic. As we've been talking about some of these concepts, I have this picture on my head of almost like a tree. When I say tree, I mean like a growing outside tree, not like a not like binary tree. - A real tree? - A real tree, where, you know, down below, you're talking about these roots, these truths, these things that don't change. They are under the ground, and they are the basis of your application. They don't change. They are, they're not going anywhere. And, you know, they suck up the fertilizer, and the natural fertilizer, the water, you know, that everything, all the nutrients come up through those truths. And then you have the trunk, and then at the end, you have the branches. And the branches are these, you know, say like mutable state, or the things that change, the things that are, you know, and the leaves drop every year, and they grow back. - Seasons. - Yep, exactly. And you're expecting them to do that. And that, you know, a tree in the winter with no leaves, isn't, it's not an unhealthy tree. - Right. It's just freezing. It's conserving energy, yeah. - Exactly, and, you know, I appreciate talking to you. You know, I kind of have, after our talk here, I kind of have that illustration in my brain, that metaphor of, you know, kind of how you're advocating for designing a system. And it sounds like you would use the strongly-type system in the roots down there. - That's right. - You know, things rely on. - Yeah, less volatile, and you get more value out of your type. Same for testing, you get more value out of your tests when the code doesn't change, right? - And it's not new, because, you know, we all know that if you spend a lot of time writing tests, then the new code that you're going to write is influenced by all the time you took that was boring writing those tests. So you're gonna try and write code and tiptoe around and not change, so you don't break your tests, and that is not a good way. - Oh, goodness. I don't understand, like, people want to build in, they want to build in hooks. I'm in the same way. I used to do this way more. I'm trying to train myself not to do it. But, okay, here's what I think happens. Sometimes you anticipate that something needs to be, it needs to, it's gonna need to change in the future. You anticipate it, and then it happens, and you're like, yes, it worked, it fit. I don't have to change anything. I can just add this one thing, and it's done, and it feels so good. It feels so good that you over-learn that. - Uh-huh, the dopamine puzzle piece. - Yes, yes, like, that your code needs to be, like, infinitely flexible, and be able to handle every situation, and when code is changeable, you don't have to only change by, like, configuration or adding a thing. Like, you can just delete old code, and write it again. You can change how a function works, and just change it. And the layers are kind of acknowledging that, and encouraging you to think, but there's all this stuff at the top that I should be able to just throw away, because the requirements are gonna change, and it just doesn't have to be great, it just has to work for now, and later I'm going to change it again, and maybe I'll learn something that can go, like, just one layer down, right? It's a little more truthy than what's at the top. And, like, just over time, you wanna gently push those nutrients down into the soil, you know, like, one layer at a time. Oh, I see, there's this relationship that's very common. Let me build that in, like, a layer under. I know I'm speaking very abstractly. I have examples, if you want, of, like, of messy, messy domains that have truth in them, even though you, you know. - Almost like you maybe written a book. - Yeah, and these aren't from the book. This is, I've given a talk where I've given it several times, where I'm trying to explain this idea of finding the timeless truths in your domain, and invariably I get someone who raises their hand and says, ah, but, you know, I work in XYZ industry, and, or I work in the government, and, like, you don't understand how many laws, and they don't make sense. There's no consistency, and, et cetera, et cetera. They have a bunch of excuses for even starting to look, right? And, I understand, 'cause I've been there before, where I'm trying to, like, make sense of all this mess, and, like, what they're, what they're missing is that you need to look a layer below where they're looking. So, let me give an example. I was working for a company that was, made a user interface that let you, helped you register to vote. And so, every state in the US has different laws about registration, and what documents you need, and, you know, do you need to, how long you need to live in the state to be considered a resident? Do you even need to be a resident to vote? Like, every state is different. And every state has different elections, and they have different types of elections, you know, so it's very messy, and it can change at any time. Like, if they can just pass a new law, and it'll be done. And now your system is wrong, right? And we had, we struggled a lot to find some, like, framework, like, how does this all fit in? And you cut it one way, and you'd be like, you get halfway through, and be like, no, this isn't gonna capture this case. Okay, let's cut it another way. And, you know, worst cases, you make a big if statement. Like, if you're in California, this is the rule. If you're in Alaska, this is the rule. 'Cause, like, that's the major axis, right? That's where the laws are defined. - Right. - But, after a while, I started to think we're looking at the wrong layer. We're trying to come up with something that kind of works for every state. And, but we're looking at the wrong layer. The things that work for every state are the signature of the function. Can this person X, person P, let's say, vote in election E? True or false, right? It's just that signature is not gonna change among, it's always gonna be, you know, you can implement that function in different ways for different states, but that signature is the same. That is the underlying truth. And now, once you have that signature, you realize, wait a second, I can use the signature to answer sub-questions. Is the person 18, right? Does the person live in the state that this election is for, right? So, like, you can start to build these smaller questions and you know how to compose them. I need to be 18 and I need to live in the state. So, you can make a function that takes two and uses an and to combine the answers of the two other functions, right? - Maybe using a multi-method, perhaps? - Well, I wouldn't go that far. I would start with something much simpler, like less, you know, simpler meaning. Your functions are basically lambda calculus. So, it has like very regular, you know, well-understood laws, whereas multi-methods, now you're getting into like, you know, polymorphism and stuff. Maybe you don't need it. So, just start with that little signature and start, now you can start seeing how you could build up the rules from reusable parts. That are you 18 is probably gonna be useful in a lot of states. Maybe not all of them. You don't have to find a rule that works for all the states, but this rule is gonna be useful. And you start building those things up out of reusable parts. And now you have this language that lets you express any state's laws pretty succinctly. And every time you, you know, something has to change, you have to decide, well, does this change at the state level? Or is this like a global change, right? For, you know, do I have to change that function? Like, are they over 18? Like, that's a lower level function. So, you get to choose what level you're manipulating the stuff at. So, that's the kind of thing that you have to do. You have to go to a deeper level where it's maybe it's gonna be much more abstract, more general, and look for the thing. And, you know, I can't tell you how I found that. I can't tell you why that signature eventually after a lot of trying popped out. Like, I did not go through a mechanical process. But, I found it, right? And I knew that I could, oh, wow, boom, I could compose these up now. - I think that you mentioned something that, you know, we take for granted, and I remember the process in my learning, when I was a more junior developer, I would write code and then be so scared to delete it because I didn't have confidence that I could recreate it. Or, you know, it was something that I felt like I didn't, my views about code as being disposable were different as they are now. And I think you're really advocating, you know, it's the view of a senior developer. It's the view of a developer that is confident in their abilities that they are able to say, yeah, wipe it away. I'll just, you know, winter can come, the leaves can fall. You know, and the leaves turn into fertilizer. That is how trees work, and let winter come, let the leaves fall, I can build it again. It's not a big deal. And I will build it better than it was before. - Yeah. - And that's something, I think that is a view that, you know, it's a more senior view of problem solving instead of wanting to just grip. No, don't throw that thing over the way, no. - You know, I think that it has a lot to do with, I mean, even look at dips, right? Like, what is the small change that you're making to this code? Like, oh, here's the line that you changed. Like, I mean, sure, sometimes you just need to change a line, but sometimes you did it wrong. And you know now that it was wrong. And you just need to, you just need to delete it and do it again. Digital stuff has this weird permanence. I think, you know, if you're typing in a word processor, you're writing an essay or something, at least for me, I'm always thinking, what is the least number of edits I can make to make this work? But it's often why I go back to paper when I'm really writing something, like going longhand. And if I get to a point and I think some, I need to make edits, I have to recopy onto a new paper. And basically, I'm throwing away the old stuff and writing it again. And I'm not trying to optimize edits. Like, that's ridiculous to optimize that. I want to be able to, you know, move a wall or, you know. - Says the guy that wrote the bash script to optimize edits of his old content. - That's true, that's true. - Sorry, sorry, keep going. - But it's good content. I did have one little edit I need to make. But no, you're right, you're right. I mean, digital has its advantages for sure. But I think often we, okay, like, have you ever had your furniture in the living room for like five years? And then one day you're like, I've never moved that couch. Like, actually I think the couch would be better over there. And like, it just never occurred to you for five years to move the couch. It just feels so permanent and fixed. That's what I think that we get into in our code. We're like, oh, this module is this way and it does this. Like, maybe it doesn't have to. You can move it, you can change it, you can delete it, you can totally, you know, refactor it. You can do anything. - And it's easier if you set, and it's easier if you set yourself up for that with good flexible design principles. And that's kind of where it lends itself. Once you start practicing these good design principles, you're able to more easily refactor edit because you provided a good abstraction layer to do so. So it doesn't ruin the whole goal. - Sure. - And I think that it lends itself. - Yeah, I mean, you do kind of learn to anticipate those things, but you also learn to realize that maybe you shouldn't be trying to build in flexibility. The flexibility is in your editor. You just hit backspace, right? Like, if you're anticipating that this is gonna change, like you better have a good reason. It can't just be like, oh yeah, 'cause it feels like it, like if it's gonna change, sure, isolate it. For sure, modularity all the way. But can you think of a reason why it would change? You know, or is it just some vague thing like, oh, it would be, this might change and I'm afraid to edit it. I'm afraid to modify. - Are you building? - Yeah. - Are you building a spaceship when you were asked for an engine? Or you know, you're asked for a wheel and you're building, well, just in case they wanna fly one day, I'll just install these wings. And if you were asked to build a car, dude. - Right, or like, you're building the attachment points for the wheels. Like, or for the wings. Why, like, are you ever gonna build an airplane? Well, maybe like, no, no, no, no, no. Do you have a plan today to put wings on this car? Because, you know, that's the kind of like, real world, or like, real talk you have to have with yourself. Like, do you really have a plan? You know, you're keeping this option open, but like, you can always open it again. Like, you can always add those attachments later. Why now? - It's fighting the over-engineer with them. - Yes. - Is what it is. 'Cause we love over-engineering. - Yes. - Um, and we also love talking. We have talked so much, we've gone so over. I fear that people won't even make it. - Well, the brave few who have made it are listening right now. Good for you, good for you. - Well, if they, if they're listening to this, they probably do closure, and if they do closure, we know they're brave and true. - Oh, yeah, good one. (laughing) - Oh, God, that was a great. Well, any closing thoughts? Anything you wanna leave us with? As mentioned, those codes will be down in the description, but God, this is so great. Thank you for talking to me. - Yeah, well, that's what I wanna say to you. Thank you for having me, but also thank you for doing this podcast, for your videos. Like, it's all great. And you're like a refreshing voice in the community, and I definitely look forward to seeing you at another conference. I think that'd be great. Seeing you in person again. (sighs) Yeah, so thank you. - Oh, no, thank you for inspiring me, 'cause if I hadn't, if I didn't do cooking with closure, and, you know, the, the reframe, all those stuff, you know, that's, that's, that's the stuff. That's the stuff, that's where, you know, so thank, thank you. And what a monumental occasion having you for what I hope will be the first of many times. - Yeah, sure, yeah, cool. - Okay, well, with that listeners, thanks for sticking in, and I will bid you do, and see you next time. ♪ La la la, lost in Lambda, la la la, lost in Lambda ♪