Debug your ideas

It was such a pleasure to speak with Fredrik on the Kodsnack podcast while I was visiting Sweden for Oredev.

Kodsnack 570

Transcript

Fredrik: [00:00:00] Uh, welcome to the podcasting stage, Eric. Thank you. So for people who haven't checked out the show notes or are not at the conference listening to this, uh, who are you, what do you do?

Eric Normand: Um, so I'm a software engineer. Uh, I also love teaching, um, and currently I'm teaching a lot of functional programming.

Yeah, I have a book on functional programming called Rocking Simplicity. And I'm working on another book about domain modeling.

Fredrik: Yeah. That new book is more or less the subject of the presentations you had here, right?

Eric Normand: Uh, yes. Yesterday I gave a talk that, uh, I think showed to me that I'm really onto something.

Yeah. That when I put the talk together, it felt really good, and then I presented it and it was still good. Yeah. Yeah. And people seemed to like it, so Yeah.

Fredrik: Yeah. I, I agree. I, but pure luck, I managed to catch both presentations, Uhhuh and I, I. I'm not sure from where, but I have distinct memory when I started working and read a book, probably some classic where they [00:01:00] had some kind of modeling example where they did coffee.

The coffee shop Yeah. Type stuff, but object oriented or something. Oh, okay. And, and it came back and the reaction was, this version you do is so much clearer. Well, okay, great. I'll, I'll take the compliment. Thank you. Yeah. So, so, so, yeah. I really think it's onto something as well. Yeah. Like. And, uh, yeah. Well, the whole part of, I feel like emphasizing a bit more that it's worth thinking about these things before diving into the details.

Mm-Hmm mm-Hmm. Uh, I feel like that's something that's easy to, easy to lose sight of, uh, the details. Yeah. Uhhuh, I mean, think thinking about the domain and the modeling. Oh, sure.

Eric Normand: Yeah. Yeah. I mean, we're under a lot of pressure. Um, I think certainly that makes it harder because, you know, you just get this Jira ticket and you're told it's like code right now.

Like this is due by the end of the sprint. Yeah. And so you don't get a lot of time to think about it. Uh, I also [00:02:00] think that there's a, there's a kind of anti design trend that happened when, when we switched over to Agile. Yeah. That there was, because if you. You know, in the waterfall world, you would design upfront and then that design would get handed over to the next team and they would implement it.

Yeah. Let's say a simplified model. And so there's this idea of thinking about your code and designing it Yeah. Is bad. It's like an upfront design model, but like you still should design and you're gonna be doing a bad design if you don't think about it. Yeah. You're just gonna be. You know, throwing stuff at the wall and seeing what sticks and there's a lot of stuff you can do.

I mean, one of the takes I try to have in my book is that there's a lot of stuff you can do on the way to code, like on the way to working code that is design activity. Yeah. Like [00:03:00] you're making better design decisions. And you're also making progress Yeah. Toward a working system. Yeah. Yeah. That's the thing.

It it's not like just drawing pictures No. And thinking a lot, like there's you're move, you're moving closer.

Fredrik: Yeah. And uh, and I feel like that came across really well as well, because it would be pretty easy to make a discussion like that feel very abstract. Yeah. And it's like, let me get to the, to the implementation.

Yeah, yeah, yeah. The right level. That's

Eric Normand: the thing is like, you know, you have stuff like, I mean, I don't want to like. You know, step on anybody's, um, favorite, favorite frameworks or anything. Uh, but one of the things I don't like about UL is that it is just drawing pictures. Yeah. And that's very useful because it's easy to communicate with people and it makes you think through it.

Right. That's good. Uh, but then now you have to start over with code. Yeah. And there's another translation step. Yeah. And something can be lost in that translation step [00:04:00] and then. There's no step, you know, to go back to the pictures, you're you. That's, there's no way to do it. That's so

Fredrik: you won't even know if you deviated.

Exactly. You map it back. Exactly.

Eric Normand: You have to like carefully look at the picture and look at the code and that's not always easy. Yeah. Um, so I like the idea of designing in code that me, uh, code can be a medium for design.

Fredrik: Yeah. Yeah. So, so is that's how you. Tend to go about it yourself, like designing it in code?

Eric Normand: Yes. Yeah. Yes. And um, I know a lot of people who do it, and so we're, I'm talking with them to like figure out like what are the practices that we actually do? 'cause coding, you often just do it alone and you don't. Mm-Hmm. Know. How other people are doing it. Yeah. So I want to get more input on like more practices for doing it, but I use closure, which is a, A language with a rep.

Yeah. And we're often running code, trying stuff out all the [00:05:00] time. And so coding and designing are happening in this really tight. Feedback loop and, um, there's, there's just a lot of stuff to learn from that. Yeah. For even in other languages that don't use the bel so much.

Fredrik: Yeah. I had a, I had a guest on the podcast, it was surprisingly long ago now, I guess, because it always is, but who was describing to me talking through like bel based design and I, I really couldn't, I mean, I couldn't quite grasp it myself because I haven't actually done it.

Yeah. But I could see that there's, there's so much here and there's a like more malleable way to. Experiment with code or evolve the code or,

Eric Normand: yeah. Yeah. It's, it's very different. And I'm always surprised when I step out of the closure world and run in a different language. I'm like, but how do you do with this?

And like, I just want to change this and see what happens. Oh, you have to go through a whole compile cycle just to, to figure that out. Yeah. Um, yeah. We we're lucky that we have this really fast feedback loop. Yeah. Really [00:06:00] easy way to experiment and try something and throw it out. It doesn't work. Try another way.

Yeah. Do like, write our program halfway and see what happens. Mm-Hmm. Like is this halfway good?

Fredrik: Yeah. Yeah. So, so that's a lot of experimentation in, in code. That's right. That's right. There's, I think I mentioned that in the email. There's some kind of semi question in my head about, you know, thinking reasoning on different levels about programs.

Mm-Hmm mm-Hmm. And, uh, this level that you are reasoning on. Here and in other other concept, I've listened to a few podcast episodes. It's, uh, sort of a higher level than I'm usually, I feel like I'm not thinking on this, on this the same level usually. And I wonder like what the connections are between the levels or something like that.

Like, like how do you move between the levels? Uh, I don't know. I just, no, it's, I'm

Eric Normand: just talking on the podcast. Exactly. So I don't know. That's what they're good for. Right, exactly. And then stuff drop drop out of it. Yeah.

Fredrik: No, but I mean, uh. Just to try and get a bit more con concrete, like coming up with a concept of lenses, for [00:07:00] example.

Mm-Hmm. Ah, like how did,

Eric Normand: okay. So that's a, that's a story. So I gave a talk back in January, uh, just at a meetup. Yeah. And they invited me to speak about domain modeling 'cause I had been working on it and on, on the book. And when I gave the talk, I really tried hard to make it not. Come across as a process.

Like I'm not saying like, do this step, then do that step, then do that step. But it kind of always came out that way. Mm-Hmm. When I would present it. Mm-Hmm. So I got all these questions about like, you know, how do I convince my boss to do step one before step? I'm like, no, that's not the point. Like, these are not, this is not a step-by-step process.

No. And so I was reading this book called Drawing on the Right Side of the Brain. Oh, I've heard people mention it. I'd like to get better at drawing. And this is [00:08:00] apparently, uh, the book came out a long time ago. Yeah. 30 plus years ago. But it's the book about how to draw and the, the trick is that drawing is not about, you know, moving your hand.

Yeah. That's not the hard part. The hard part is seeing. Hmm, that your brain is interpreting what you see so much into like you, you know. You see what you're seeing is lines and colors and shapes, but you see a rectangle. Yeah. Even though it's at an angle. Yeah. You still think that's a circle. Yeah. But, but the circle is like really Oh, yeah.

Um, for shortened. Yeah. And so the trick is to look at the, uh, the shape that you actually see, like getting the raw data from, from your eyes. And in the introduction she talks about. I think it's five different techniques for helping you do that. Mm-Hmm. So one is instead of drawing the shape. You draw [00:09:00] the background and the, and it's the shape as a whole.

So it just turns your brain to think, to focus on the opposite. Oh, yeah. Yeah. And that helps you see that. Oh yeah. It's not a rectangle. It's like this trapezoid. Yeah. Um, and so she gave a bunch of them. I can't remember them all. No. But it made me think, oh, that's what I wanted to do. I wanna give people these tricks for seeing their domain in a different way.

Yeah. I wanna give them a, like a handful of like, instead of looking at this, look at the opposite or look at the background and then that'll give you a, uh, a better perspective because you're just not used to looking at it that way. Yeah. And, uh, then of course the drawing book. The nice thing about it was that she was like, and that's a complete list.

Like when you think about, and she gave a reasoning why it's a complete list and it made sense. Yeah. But I don't think I have a complete list. [00:10:00] No. I tried to figure out like, is there some way, uh, but no, uh, I couldn't figure it out and the list just kept growing. Yeah. It's mostly stuff like, well, this is important topic and this is an important topic, and so if I could just make each one into.

Like a set of questions. Mm-Hmm. And like concepts that are all very related that. You know, if you just focus on your domain, this way you can extract this information and it might not be complete. So you need to look at it from another angle, from this other lens, and then that kind of completes the picture.

And eventually you're getting enough information that you can constrain the problem. 'cause that's the real big problem. Oh yeah. With software design, there's so many choices. Yeah. Uh, so you want to constrain that. You want to know, oh, well, if I look at it from this angle, it's obvious that I don't have to, that it won't be this, and you can cut this problem space in half.

Yeah. Um, and it's just so multidimensional. Yeah. And, uh, you just wanna look at it from all these angles. [00:11:00] Constrain, constrain until you have some easy choices to make. Yeah. Yeah.

Fredrik: And you were currently at, was it like 10 different lenses? I've got 10 lenses right now. Yeah. And you talked about three of them.

Eric Normand: And it, and it can change. Yeah, of course. It might, it might get, I might throw some out. Yeah. Yeah. But, but I mean,

Fredrik: it's, it's a really good word to put on it, I think a good label because it feels like, it really feels like, yeah, you, you're getting a different perspective Uhhuh, or a different focus uhhuh, but it's not.

It doesn't sound like a rule or a limitation or something like, right. I don't want rules. No, exactly. Exactly. That's just, it's just a different way of seeing it, if that's right. Alters your vision a little bit. Let you see some other details. Yeah. And you switch to the other ones.

Eric Normand: Yeah. I'm trying to be very cautious not to give rules and recommendations.

Uh, I've, I've read a lot of software design books trying to, I mean, just for my own. You know, improve my own programming, but especially since I've started writing a book on it, I've wanted [00:12:00] to like see what other people say. And I'm, I'm just very disappointed that it's just all these rules that are mostly more exceptions than actual regular cases.

And it's, it's hard. And I know it's, it's a hard topic. Yeah, of course. So they're doing their best and like. It's really hard to talk about something you're good at. These people are really good at it. Yeah. You can tell the authors of the books. Yeah, yeah, of course. They're good at it and they have a rule that, that they're articulating something, but it's not quite enough.

No, and what I want to do is make it more like, like I think of it like chess. You're playing this board and every move has consequences all over the board and the more. Chess moves, you can think through the better player you'll be. Yeah. And I feel like these other design books are giving very [00:13:00] basic rules, like, don't, don't sacrifice a piece unless you want to, or, you know, things like that.

Like don't, don't block your pawns. You know, things like that. Right. Except when you do. Yeah, exactly. And, uh. There the rules are, are true until you get better. And then it's not useful anymore. Right. You know, and I want to do something more like here, when you move, when you're thinking about a move, here's five things to think about.

Yeah. You know? And so you can start to see that. And I'm not telling you what the right move is. No, no, no. Exactly. I'm just telling you like, these are useful things to keep in mind. Yeah. And uh, because I have this conjecture, a hypothesis that. The more design decisions you can, the more options you see at each decision point, the better designer you'll be.

Fredrik: Yeah. Yeah. I, I really like, I don't recall exactly how we said it in the presentation, but you, you got it in there very clearly and very nicely, and it's like, yes, of course.

And

Eric Normand: yeah. Right, right. And it seems, it makes sense. Severe few

Fredrik: more options. [00:14:00]

Eric Normand: Right. And so another thing is these lenses will open up your mind to.

New decision points that you didn't even realize were there. Yeah. Right. So I've been having discussions with people, you know, we're here at a conference. Yeah. It's hallway track. It's like one of my favorite things. Yeah. And people will be like, well, should I do this or this or this? I'm like. Yes, that's the right question.

I can't tell you the answer. Like your code base is yours. Like it depends on every, it's all interconnected, but that's the right question. Yeah, exactly.

Fredrik: And yeah, I feel like. It's onto so many good things as well, because I started thinking of a one colleague in particular who's really good at reasoning about the model, and I felt like I'm, I'm getting a lot of useful words and concepts here for Uhhuh describing or thinking about the stuff he does.

Ah, cool. Because he really good, he is really good at reasoning out a good model for something and then you end up getting those in interesting [00:15:00] interactions with the, what, what did you call the levels? The, the. The model level and Oh yeah, the domain.

Eric Normand: Oh, the, and the model Uhhuh. Oh, right, sure. Oh, yeah.

Fredrik: And, and how those interact with each other.

Yeah. Yeah, yeah. Yeah. 'cause he, he can be really good at reaching out a useful model and, you know, yeah. We talked about that as well. You know, you have concepts that are not representable Right. On one, one side and concept exists and sometimes you, you'd realize you can implement.

Eric Normand: Right. Well, that's one of the things I, I've been trying to do is.

Bring a little bit more objectivity Yeah. To design. Yeah. Like it's still intuitive. There's still too much for your brain to really process. Oh, yeah. Uh, you have to use your intuition, but there's a lot that can be maybe more quantified and like you can tell people like, no, this is a problem and this is why.

So the, the thing you were talking about is like, let's say you have a data model for a domain, let's say coffee shop, because, uh, it's easy to talk about. Yeah. So your model [00:16:00] has certain states that are representable and your domain, at least the way you've analyzed it, the way you've conceptualized it, has also a certain number of states that it can be in, and you wanna compare the two.

Like what is the overlap? Yeah. And one, well, this actually, you know, if you look at a Venn diagram, there's gonna be three areas. There's this, the overlap, there's gonna be the area that's in the domain that's not representable in your model. And then there's the part in your model that doesn't have anything corresponding to it in the domain.

Yeah. And if you have a complete overlap, then you have perfect fit. But if you don't, then there's some problem. And. You want to minimize that and you also wanna make sure that you can represent every state you want to. Yeah, exactly. And so it's better to have maybe more states, but then that causes you to have some kind of check [00:17:00] to make sure you don't get into one of those states that Yeah.

It's always, uh, sort of friction there. Right, right. But these are all just trade offs that you're like trying to balance all the time. Yeah. 'cause you're never gonna get a perfect model.

Fredrik: No. And, and you probably shouldn't either. Right. Because. Some of those, I know simplifications or representable things will be what makes the solution more useful to the users.

That's right. Like we have so many things. We make a scheduling system for universities at work. Okay. So, I mean, there's a lot of flexibility that they don't want to expose to people unless they really have to. Right. Permissions. Right, right. You wanna restrict it. Yeah, exactly. Sure. And you can make it seem really simple in the front end to the users or as simple as possible, at least.

But still represent everything that's needed. It's, I see.

Eric Normand: No, that makes sense. No, that's really cool.

Fredrik: Yeah. And sometimes you simplify too much and then it's like, oh, someone needs this aspect. It's a hard, it's a

Eric Normand: hard job. All this design work.

Fredrik: Yeah. But you have [00:18:00] that in there as well. Will, you know, the open, closed, uh, the different levels of how.

Ah, yes. Or the thing is to change. I mean, that's a really useful thing to think about as well.

Eric Normand: Uhhuh. Well, that's another like, uh, pet peeve of mine is, again, I'm not, I don't wanna like step on anybody's, I don't want to kick dirt on anybody. Nope. But I feel like in the, the, the move to agile, because, you know, they, they talk about changing requirements and.

Um, also learning as you're programming. Like you, you put out a feature and you learn, oh, it's not what the users wanted. Like that's all good, right? Yeah. But with that, they have. Um, made this, I, uh, popularized this idea that change is maximal mm-hmm. And unpredictable. Yeah. Like anything might need to change.

Yeah. So in software design, just put indirection everywhere. Yeah, yeah. Always have an [00:19:00] interface in between, you know, classes interacting and, and, uh, it's. It's not true. No. A lot of change is predictable. Yeah. And it's not maximal No, it's, it's not gonna change. Not everything can change and some things is, you know, code is also changeable.

Yeah, of course you can, you can just change the code. That's why we have editors. Yeah. We can do it all the time. It doesn't you like, I, I also think there's this other thing that happens, which is it's, I, I don't think there's one. Cognitive bias that describes it. Mm-Hmm. But it's a thing that happens in casinos where people are gambling and they remember their wins much more than they remember their, their losses.

Yeah, of course. So they could play a hundred games and win three and feel great. Yeah. Even though they've lost 97% of the time.

Fredrik: Yeah. 'cause one of the last ones was a win, so. Yeah, exactly. Or

Eric Normand: they keep and they end [00:20:00] on a win or whatever. Yeah. So. I think that we put in indirection because we're anticipating changes in our code.

And let's say we put in a hundred mm-Hmm. And three of them hit. Yeah. Because some new requirement changes and we're like, yes. You see it was all worth it. Yeah. And it wasn't. No, it was not worth it. For 97% of those, and you spent time on them and you. You know, used valuable resources. Yeah. And made the code more complicated.

Fredrik: Yeah, exactly. You could have had a simpler thing along. That's right. Yeah.

Eric Normand: And it would've been easier to change anyway. Yeah. With the simpler thing. Yeah, of course.

Fredrik: It's just an if statement,

Eric Normand: right? And three cases. That's right. That's right. So we're putting all this, uh, you know, we're, some people say like, you spend 10 lines of code today.

Mm-Hmm. To save 10 lines of code tomorrow, Uhhuh. But that might never happen. No. Yeah. And so why, why are you doing the 10 lines of code? No,

Fredrik: exactly. Yeah. I, I could have written three instead, and I think it, it goes, it goes together so well with, for [00:21:00] example, the last keynote yesterday, Natasha, when she talked about, you know, your code, you often outlives you in a context.

Right. And that rings very true to me. Yeah. We don't really want to admit it, but, but so many things we write and we think, oh, doesn't, it has to be false. I had to do it quickly or, but, but then it goes on, runs for 10 years somewhere. That's right. That's right. And we have to read it as well and it's so scary.

Yeah. Both scary and not, I think, I mean, I, it's kind of, yeah. I think it's a nice counterbalance to realize that when, when you are sprint planning and everything seems like it has to be done so fast. Right. So urgent. It's still Yeah, exactly. It's still worth thinking for 20 more minutes about options.

Yeah. Yeah. Sure.

Eric Normand: Yeah. And we, we were so weird about time. Yeah. You know, I, I watched a talk once where they, they were talking about writing a better commit message. Mm-Hmm. And it was basically like, sit down, you're, you're done. You're write it all out. Yeah. Just [00:22:00] take some time. Write it out. And people are like, oh, but it's gonna take so long.

Yeah. And he's like, I'm just talking about five minutes. Yeah. You spent like three days on this code. Yeah. Take five minutes. Yeah. Write it down. Yeah. Before it's out of your head.

Fredrik: Yeah, exactly. Do it right away. Do it somewhere. Yeah.

Eric Normand: Yeah. But I also feel like, um, that those five minutes, it does only take five more minutes, but we're also so distracted at work.

Yeah. Like we've got slack messages coming, like it does pop out of your head and now it's more than five minutes. 'cause you have to remember where was I? And it's not so easy anymore. Yeah. Yeah.

Fredrik: And we, we keep telling ourselves that for some reason if we write the code well enough that we never have to write anything again.

And that might be true if you took more time on the code. Yeah, it could be. It could be hopefully. But yeah.

Eric Normand: But again, we're just talking about spending more time on it.

Fredrik: Yeah. But not that much. [00:23:00] Yeah, no, it's true. Yeah. It's Maybe we should think about time spent instead of line spent, like you said. Yeah.

Spend some more time now to save some time.

Eric Normand: I mean, I also know, in my experience, I'm often so looking forward to the end Mm-Hmm. Of this whatever ticket I'm working on. Yeah. Like, it's finally working, like, yeah. I just wanna get it out of my hands. Like I totally understand it. Um, especially since. You know, there's a sprint end coming and I want to get it in before then, and I have a meeting coming up in that afternoon, and I haven't eaten lunch yet.

Yeah. And totally. Nobody

Fredrik: really cares how it's done. That's right.

Eric Normand: That's right. I'm not gonna get extra points for doing a better job. No. Uh, so yeah. Yeah. I totally understand it.

Fredrik: Yeah. It's a, it's a trickier Yeah. Tricky situation. So. What, what got you into the path of, like thinking about domain modeling, for example, in, in the first place?

Did you start out like [00:24:00] working program and then started wondering how to make it better or,

Eric Normand: uh, so I, okay. I read, here's a story I read back when I was in college, I guess, uh, I was reading a lot of stuff about programming. M mostly from like Unix hacker culture. Yeah. And one person said that he, he felt like he liked programming.

He was drawn to programming because he liked the control. Okay. Like he liked that you had this hardware that you could totally do what you wanted with. Mm. And I, I kind of got it, but also like, well, that's not me. Yeah. I like that code. Lets me play with ideas. Hmm. I'm not a hardware guy. I'm not a, like, I want to configure my machine just the right way.

I'm more like, I wanna be like, I'm happy working on a whiteboard. Yeah. You know, [00:25:00] but code, what I like about code is it's. It's more formal. Mm-Hmm. So you have to get it right. You can't just draw a picture with some arrows and be like, and then this happens, like, then a miracle occurs. That old joke, uh, I like, I like the fact that code forces you to make it work.

Yeah. And when you realize it doesn't work, it's like you have to now debug your ideas. Yeah. And. Then try something else. Yeah. Uh, and I, I just, that's what I like about it. So it's always been about expressing ideas. Yeah. Which is what domain modeling is. Oh, yeah. Yeah. It's, it's like what are the ideas here that are important?

How can we, how can we encode them in our code?

Fredrik: That's, yeah. That's extremely close by with now that you Yeah. Put it like that.

Eric Normand: Yeah. And I've also found that the jobs that I've liked the most, the companies I've liked working for the most at those jobs, I became. Kind of [00:26:00] ver well versed in the domain. Yeah.

It was, I wasn't just a coder. Yeah. You know, like doing what they said, I was learning really deep stuff about what I was working on. Sometimes more than like the, the boss, you know? It's like I had a better understanding because I had to actually make something work. Yeah. Uh, I had to make trade-offs. I had to simplify it.

I had to figure out what are the edge cases and things like that. And, uh, often. Like the boss had a, you know, more salesy approach to it. You know, like, this is how we can sell it to a client. And that's, that's very useful and everything. But like, in terms of the technical details of like how accounting works or something.

Like I, I knew the corner cases and the, this is what actually goes on here. Yeah, yeah, exactly. And, uh, that was, you know. I, I, I actually use it as a way of judging a company. So like when I'm interviewing at a company Yeah. [00:27:00] I'll ask the programmers there, like, do you feel like your day is spent mostly figuring out why the message queue is dropping your messages?

Mm-Hmm. And how to, you know, deploy your microservice? Or are you thinking about, you know, e-commerce? And are you working in that realm of ideas? So like it's a way for me to judge how, like are they in this overcomplex like ops situation? Yeah. Where they've just become like, I don't know, no server babysitters.

Yeah, exactly. Or are you actually like delving into the realm of ideas and like really reaching in and playing with that? 'cause that's where I want to be. Yeah,

Fredrik: yeah, yeah. It rings a bell because I. Or because, but in relation to that, I often feel like people talks about much about languages and platforms and, but what's really interesting is actually the stuff you were talking about, the model, the domain learning what, what this company does Yeah.

With that code. That's right. And [00:28:00] the, I like to say that I, I don't feel, I know c plus plus, I can't, I'm, I would never call myself a c plus plus programmer, but the c plus plus code we have for our domain and business logic. That I can do because I, uhhuh I know something about our domain, right. I know how our thinking goes.

Right. And that makes me able to write c plus plus in that case. Yeah. Yeah. Yeah. As long as someone else double checks the memory. Well, no, but that's great. Yeah.

Eric Normand: Memory management and c plus plus. I understand. Yeah.

Fredrik: Yeah. Uh, but yeah, it's, it's really about No, that's cool. That's awesome. Yeah. And models, models are powerful.

Eric Normand: Yeah. And.

Yeah.

Eric Normand: I wanna help more people and companies get there. Yeah. You know? Yeah. I, I feel like, uh, places I've worked at, uh, recently, they're just so mired in the complexity and I talked to the people like, you know, people who kind of architected the system and they love it. They're more of those control [00:29:00] people.

They're like, oh, isn't it cool that we can orchestrate this and the deploy happens like this? And I'm like, nah, I mean, it's fun for you, but like, it's not what I want to be doing. Exactly. And, and, and

Fredrik: I, I keep thinking that when it comes to the actual important model and these parts, they shouldn't be that much code.

Right. So when people are talking about these towers of architecture, right, I feel like they're often lost in the woods somewhere. Yes, yes. On some level, I mean, on another level, of course they're talking about important stuff, but,

Eric Normand: well, it's like forest for trees, right? Yes. Yeah. Some, something like that.

They're seeing the, the background, and I'm like, but this, the important thing is the e-commerce thing. You're building, not the, how the cues work. Yeah, exactly. Can someone actually buy something? It doesn't matter if there's a, that's a fax generated in the background. Does your, you know. There people had to invent the idea of the online shopping cart.

Yeah. And does your shopping cart. [00:30:00] Domain model correspond to the operations that the person has, you know? Or is there some like big clj going on? Yeah. That behind the scenes is something totally different. Yeah. Like I think it should be much more similar. Yeah. They should, they should map to each other.

You know, the buttons that you click in your shopping cart should have like a method on that. Object in the database. Yeah, exactly. You know? So, um, I think it's, um, I think there should be a much closer mapping.

Fredrik: Yeah. Yeah. I guess the, the better the fit there, the more obvious everything seems. I think that's right.

Like that's, oh, the object just happens to have a property for everything I want to do. Exactly. Isn't that's strange. Yes, yes.

Eric Normand: That's right. That's right.

Fredrik: Yeah. I also wanna throw in that it feels like if you know the model really well, you can often write simpler code as well. Yeah. Because yeah, this is the constant we're dealing with, but we don't need.

Uh, a clause for that. Right. It can be an if statement for now. Right? Because that's [00:31:00] what it represented at this stage. Exactly.

Eric Normand: Exactly. And, and then the other challenge is we often are learning as we go. Yeah. So we can't really know the model that well. No. Upfront, uh, you can know something. Yeah. And then you have to evolve it over time.

Uh, and so that often means refactoring. Yeah, right? Like, oh, this can't just be an if statement. 'cause we have 25 different things. Yeah. That's just not good code. Uh, and we're at 24, like maybe it's time now before we add the 25th one to find a different system. Could be. Um, and so I'm really fascinated by this idea of refactoring as a way of finding the, the seams in your model.

Right. Ah, yeah. Yeah. That, that is there some way, 'cause when you look at software design and static analysis, like people do like complexity measures and things.

Mm-Hmm. [00:32:00]

Eric Normand: My trouble with it, I mean, it's all useful, but my trouble with it is it's all just looking at the code. Mm-Hmm. Yeah. It's not comparing your code to the domain.

Yeah. To the, you know, what, what is it supposed to look like? It's because maybe your domain is really complicated. Yeah. Maybe a 24 branch ish statement is correct. Yeah. It's the simplest thing it could be. That's right. And so it, I've always had trouble with that, but at the same time, I've seen people who are very skilled who don't know the domain that well.

Mm-Hmm. They look at just the code. And they start to organize it, refactor it, redo it, and they come up with an interesting domain model. Yeah. Without really having ever seen the domain. Yeah. And so they've intuited a way somehow to do that. And so I do think that what they're doing is domain modeling.

Mm-Hmm. Um, and this is another, you know, like again, I'm gonna kick dirt, uh, but [00:33:00] I. The, the problem is they talk about refactoring, they're like, see how important refactoring is? But it's like, okay, refactoring is just your way of modifying code. Yeah. So that the tests don't break while you're doing it.

That's important. But what you're really doing is finding domain, you're finding domain concepts and modeling it into, uh, things in your language classes or types or whatever you do. Yeah. And so I, I'm, I'm following a thread right now. I'm watching all these refactoring talks and I'm pointing out like, Hey, look, they're talking about refactoring, but the important thing is they found a domain concept that we hadn't realized was there, you know, and, and so I'm, I guess I'm, I would like to steer the conversation away from refactoring is, is the answer.

It's like, no, it's part of the answer. Yeah. The other answer is like, finding these interesting. Uh, interesting domain ideas.

Fredrik: Yeah, [00:34:00] yeah, yeah. It's like coding isn't and organizing it better. Yeah. Coding isn't, isn't finger tapping on keyboard. That's right. That's right. That's an important part of it in a way.

That's right. That's not, yeah. Yeah. It's not the whole story. So you're, you're working mainly in closure?

Eric Normand: Uh, yes. Yes.

Fredrik: I,

Eric Normand: I think it's time. I've been doing closure for so long. Now it's time to reach out into other languages. Like so much is new. I. Uh, I have played with TypeScript and I really like it. I think it's a good, uh, maybe the best possible design.

Mm-Hmm. For a super set of JavaScript with a, you know, static type system. Uh, I wanna look at Rust. Now. I have enough friends who are like, yes, rust. I'm like, I've, I was not sold on it. Uh, but. I'm kind of a curmudgeon, you know, I'm kind of like, ah, new technology, like all stuff, like does it have a ripple? I don't, I don't need to spend all my time on new [00:35:00] stuff just to have it disappear.

But rust looks like it's here to stay now. Yeah. This looks like it. So it's worth getting a nice Yeah. And enough people are talking about it. It's worth looking at. Yeah.

Fredrik: Yeah. I, I talked to one of my colleagues in the pod Uhhuh and he was like, I haven't heard a lot about closure in a while. Uhhuh, is there stuff going on?

There

Eric Normand: it is. Yes. It's, it's a, one of the more popular languages. I mean, maybe top 25 or something.

Fredrik: Yeah, I know. You know better than many. Yes, exactly. Larger than many. And

Eric Normand: we're, we're trucking along just fine. Yeah. Uh, the language hasn't had one of those like cool new feature things in a while. Yeah. But it still works really well.

Fredrik: Yeah. I mean, the. Some, you don't need to add new stuff all the time. I know That's

Eric Normand: one of the things that I've been hesitant with rust about. It's like a very big language. Yeah. In terms of the number of features it has and,

Fredrik: but have they sort of stabilized now or are they still adding I, no, I don't know.

I don't either. Yeah.

Eric Normand: Yeah. [00:36:00] No, I remember back in the day. When people were like, I wrote some rust and then I upgraded and now it doesn't work anymore. No. Yeah, yeah. Like I didn't want to be dealing with that. No, but now it's not like that anymore.

Fredrik: No. Now, uh, the same person he discovered because he was maintaining rust packages for a Linux distribution or something, and he discovered sort like chasing a wave, you have to stay, stay in sync with it or your toast.

But it was also clear, like clear, pointing out that. They shouldn't optimize for my use case because I'm a maintainer of these packages. Uhhuh, they shouldn't be doing that. They're doing the right thing right now. Yeah, yeah, yeah. Yeah. It was a couple of years ago as well, so, uh, I'm not up to date. Mm-Hmm

mm-Hmm.

Eric Normand: Yeah, I'm, I'm a fan of closure. One of the reasons is it's a small language. It's relatively, uh, simple. Yeah. Like you can. Learn the all of it. And then you're, you're done. And yeah. Uh, and even then I choose a subset of it, [00:37:00] you know, that I work in. Uh, whereas again, something like Rust or Haskell, I worked in Haskell, like it has this syntax cheat sheet that's like four pages long.

I'm like, ah, what does this thing mean? This is little symbol. I gotta go look it up. And, uh, that, you know, it's fine. But it's not my favorite. No. Yeah. I like to have it small.

Fredrik: Yeah. I'm um, I find that very appealing as well. Yeah. I mostly write JavaScripts JavaScript, looking sideways at TypeScript. I should be doing more types.

That's, that's for sure. Uhhuh,

Eric Normand: I find the types and TypeScript are quite comfortable for modeling. Yeah. Yeah. Yeah.

Fredrik: I mean, uh, they fit in really well in the examples when you're using Yeah. But then the slides became too, too small. Yeah. And I feel like that's also sort of indicative of a, a thing with TypeScript.

Yeah. Sometimes things can get a bit,

Eric Normand: one of the things in Haskell that I like is the type goes above the function. Okay. Ah, instead of having the types be like next to the argument, they're above it. Yeah. [00:38:00] Uh, so the type is really like its own thing. It's clear it's there, and then you don't have to write the types again.

Yeah. Whereas in TypeScript you have to do a colon and put the type name next to it, so then your function gets the, the first line of the function gets really long. Yeah.

Fredrik: Yeah. Exactly. Yeah. It's, uh, so, so looking at other languages. Uh, it's more mostly about curiosity, about the differences or,

Eric Normand: yeah. And, you know, it's time to, to grow.

Yeah. In my personally, uh, you know, I said I teach closure. Yeah. And I, I did that full time selling video courses Mm-Hmm. For five years. Wow. Yeah. And then I was having trouble paying the bills Oh. And making ends meet. And so I had to get a job. Um, and I really think that. The, the community just wasn't big enough.

Mm-Hmm. To support. Yeah. Someone making full-time living, teaching like that. Uh, and so [00:39:00] part of me is like, oh, I could teach rust. Like there's a lot of people who wanna learn rust. There are a lot of touch group people, a lot of TypeScript people. And so if I get better at it and find something to say about it, I want to be unique.

I don't want to just give the same. Lessons that other people would give, uh, but bring my own unique take to it, then, um, I might teach it. Yeah. You know,

Fredrik: so, I mean, it goes along really well with the domain modeling, so Yeah. It's true. It's, uh, yeah,

Eric Normand: that's true. And so, like, you know, I'm writing this book on domain modeling.

Uh, I'm, I think I'm gonna use JavaScript again. Yeah. And because that's what I did my last book in, and it was, you know, good reception, but. I think it would be cool to have like a rust edition or you know, a type script edition. Yeah. You know, things like that. And I need to know the language well enough to not, to not embarrass myself.

Seems like a reasonable way you doing it? [00:40:00] Why Just translate.

Fredrik: Ask the model to do for me. Yes. Yeah. What could possibly go wrong? Yeah. This was. Super interesting. Thank you so much for taking the time. Thanks for the time. This was great.

Or coffee point com, Lanka or Facebook. Let me put it this way, Mr. Raymer, the 9,000 series is the most reliable computer ever made. No 9,000 computer has ever made a mistake or distorted information. We are all by any practical definition of the words, foolproof and incapable of error.