[00:00:00] Dillon: Yeah. I mean, the, uh, the big headline is, you know, full stack Elm. Uh, so

[00:00:06] Jared: Yeah! Hey folks, welcome back to Elm Town. I'm your host, Jared M. Smith. We'll be visiting with Dillon Kearns today, talking about the pages of his history. We will be submitting the form of his journey to the backend task to the service of the Elm community.

[00:00:32] Introducing Dillon Kearns

[00:00:32] Jared: Dillon is an advocate for Elm and a teacher at incrementalelm.com. Some of his Elm contributions include the co-host of Elm radio with Jeroen Engels. He shares tips and insights on Elm at incrementalelm.Com. He is the author of several Elm tools, including Dillon Kearns elm-graphql, html2elm.com, elm-markdown, elm-ts-interop, of course, elm-pages, and more. Dillon, welcome to Elm Town.

[00:01:07] Dillon: Thank you, Jared. It's a pleasure to be on. It is, uh, been a long time dream of mine to be on Elm Town. And, um, listening to those puns, now I know how Jeroen feels when I throw him those curveballs in our intros.

[00:01:21] Jared: Yeah, yeah, well, um, I figured that was only par for the course. We had to get that in there, yeah.

[00:01:28] Dillon: Taste of my own medicine, finally.

[00:01:32] Jared: Yeah, and if folks, uh, didn't already know, uh, you may recognize... Dillon from the radio on your drive to town today. Um, and I think that's all the puns that I have. Okay. Um,

[00:01:45] Dillon: Not

[00:01:46] Jared: we'll see something might come up. Um,

[00:01:48] Dillon: Yes.

[00:01:50] Jared: so, uh, let's get into it. I wanted to ask you, actually,

[00:01:54] Links between experiences as an agile coach and piano player and how that relates to programming?

[00:01:54] Jared: this is one that, uh, came from Jeroen. So we'll just kind of get started with that.

[00:02:00] I paraphrase this a bit, but Jeroen asks, are there any links between your experiences as an agile coach and piano player and how that relates to programming?

[00:02:12] Dillon: Yeah, Jeroen, Jeroen knows me well. and, and Actually it's, it's interesting to look at the link between agile practices and music, and between agile practices and Elm. Uh, for, for me, these things are all sort of inseparable because I've just sort of built up my mental model through these parts of my life.

[00:02:37] I discovered piano when I was 17 years old, which is relatively late for somebody getting into classical music, but it just sort of, uh, lit a fire in me in a way that taught me how to have like a sustained interest in something rather than fluttering between several interests and really focus my interests for a long period of time to develop skills at it.

[00:03:03] Um, so like music gave me that spark and, um, and then the, the people I was fortunate enough to study with, um, gave me the, the techniques to isolate. So when like a big part of studying classical music is, um, you need to be able to break something down. And I really got this feeling when I, when I was studying with my, with my teacher in college, that I could tackle any problem because like it felt like the limit to me being able to accomplish something was what I was willing to put into it. The approach I was willing to take, like, am I willing to do the hard work, roll up my sleeves, break things down small enough, if something is. Not digestible for me. I just need to slice it down thinner.

[00:04:04] Am I willing to do that? And if I am, I can do it. That's, that's the thing stopping me from doing anything I want to accomplish. Not my abilities. And so, like to me, that was a big mindset shift. It's not like the arrogance of like, I can do anything.

[00:04:20] Do you really want to do what it takes to do that thing?

[00:04:20] Dillon: It's like, do you, do you really want to do what it takes to do that thing?

[00:04:26] And that was a very empowering mindset shift for me. And it, it taught me to sort of take big goals that I wanted to accomplish and turn that energy into sitting down and breaking problems down. And when you look at agile practices, you know, test-driven development, incremental steps, um, slicing things down, you know, uh, doing the simplest thing that could possibly work; all these techniques, it's really the same concepts.

[00:05:04] And I learned the value of that in a visceral way by studying music. Cause it was something I really deeply wanted to master. And so I internalized that, um, connection of really wanting something and then breaking things down into small steps. And I also learned those skills of like, well, what do you actually do?

[00:05:27] Like going into a piano lesson and having a teacher who's, you know, an incredible master at the instrument showing you like being able to hear exactly what, how you've been practicing when you play in front of them and then breaking it down for you and saying, okay, well, um, are you playing this passage over and over with both hands?

[00:05:51] What if you played it with one hand? What if you played it at half of the tempo you're playing it now, or a quarter or an eighth of that tempo? Which sounds excruciating, but what would happen? Let's, let's experiment with breaking things down into smaller pieces and see if you can accelerate your learning.

[00:06:09] Jared: Okay. Yeah. So I know you talked about this, um, in your episode on Elm Radio, Deliberate Practice. Um, and I, that's one of my favorite episodes. So, um, I guess one thing that that comes to mind is, um, it sounds like it would take a lot of discipline, right. To, to do that. Like you said, do you really want to take those steps to break things down to that level?

[00:06:34] Because I think what happens is, um, I have a young son. And, and, and his ability to want to like get to the end goal, you know, it's, it's like, I want to get there as quick as possible, but it really takes a lot to train yourself to say, okay, if that's where I want to be, I'm not going to get there today.

[00:06:56] And yeah, like you said, how do I break it down? Um, how do you isolate, like you said, um, and create that sustained interest so that you can break through those, those thresholds to get to the next, uh, level in the, in whatever you're trying to do.

[00:07:11] Dillon: Right. I, I like that, uh, point you're making about, like, wanting to just get to the end goal. And that's very much been my experience, like, doing, doing agile coaching and technical coaching. Um, I saw a lot of this Um, I don't want to call it impatience, but it's just like thinking that you'll get there faster by just doing it, right?

[00:07:35] That like, tests are going to slow you down, refactoring is going to slow you down. So this is that sensibility that you develop. And I, and I would, um, you know, you mentioned the word, um discipline, and I think that the word discipline means different things to different people and I, um, I have like a mixed feeling about that because, um, sometimes people talk about a discipline like a, you know, martial arts as a discipline or something like that.

[00:08:06] And that, um, that concept I have a very positive association with personally. The concept of like, discipline, disciplining someone, I don't have a positive relationship with that word personally, because to me it makes me think of like, um, what somebody should do, and uh, somebody telling you that something is the wrong approach, and I really like, um, Um, just developing the sense of what causes you to make progress.

[00:08:44] And then that making that feel good, you know, like it, it feels good when I feel that I'm making progress towards a problem. So, whereas like when you first start using test-driven development, it might feel like you're chomping at the bit to just get that code written and you're like, I know what line I need to write.

[00:09:04] Let me just write the whole solution instead of writing it step by step. As you add test cases that show what is not currently implemented and, but then you, you can develop that sensibility and that is a type of discipline, but in the more martial arts as a discipline sense of the word, so you develop that sensibility where you.

[00:09:26] You, you realize, you, it feels good to write a test. It feels good that you write a failing test, you have that read, and that feels good emotionally. And so I feel that that's an important part of the process is to develop that relationship where emotionally you get a little endorphin hit when you get a red test.

[00:09:48] But that's something you can develop intentionally.

[00:09:51] Jared: Yeah. Yeah. That's true. I like that. And I, as you're talking about, yeah, the, the different connotations of discipline, it makes me think about how. You know, some people think of discipline as punishment, right? Like you need to be disciplined. Right. And I think that that is definitely a negative part of it, but there's also, the other side of that is. Adding a reward for something that you do. And so I think that's what you're saying, right? If you focus on getting a test from red to green, you're creating that reward system and training yourself to, to think in that way.

[00:10:25] Dillon: Exactly, and not because of some externalized notion of what you should do, but because you develop that sense that this, um, this is what progress feels like. And so you build that association that it feels good. So it's like, it's kind of like, um, you know, if you're, if you're eating food and you're like, Oh, pizza is bad and salad is good.

[00:10:53] And you can sort of discipline yourself. To say that these foods are bad or good through some, either externalized concept of good or bad for food, or some sort of, like, shame fueled notion of what you should and shouldn't be eating that you impose on yourself. Um, I mean, I'm not, you know, I'm not an expert in these things, but my personal feeling about these things is it feels far better to me to, to sort of, uh, start to connect the dots of like, if I eat some food, how am I going to feel 30 minutes later?

[00:11:33] Jared: Right,

[00:11:34] Dillon: And to start to like, not just feel like the... Dopamine hit of of taking a bite of pizza or like eating some M& M's and and feeling really good in that instant but feeling like as you start to eat some M& M's like am I gonna feel good in half an hour and so to me it's like really developing like a broader sense of what's gonna feel good and with coding it's the same thing like okay I know I know what it feels like when I jump straight to the final solution or what I think is the final solution.

[00:12:12] And I know through experience that I, uh, am often surprised that, uh, I thought I had the final solution and I end up missing one important detail. And I know that when I go through these small steps, I end up with a more robust result. I end up with a test suite that gives me more confidence. I end up refactoring the code through these tiny steps where it's more manageable. I'm not in the middle of a giant step that I can't now change course in, in a, in a fine grained way. So to me, it's about developing that broader sense of how, like, it's almost like extending your nerves to understand the future pain you'll receive from something and wanting to reduce the future pain instead of like imposing some moral system that you think something is good or bad,

[00:13:13] Jared: right. Yeah. And, you know, against coming back to the words discipline, if you think about it in terms of self discipline, right, that's like you are creating what the goal is. You know, there's not some, like you said, external that is telling you. I want to play piano. Right. If that is coming from an external place, that motivation will, it may not be great.

[00:13:36] Right. So, but if that's coming from inside and you're saying this is a goal that I want to get to, then that again, trying to create a positive spin on discipline. I think you're saying this is the constraint and this is where I'm trying to get to, right? This is the goal and, and I know that if I take these steps, I will get to there versus I think you were mentioning that if you just run to the end, right?

[00:14:04] And I, I wrote a little bit about this, um, in, in a blog post where I was thinking of kind of like you're saying with incremental steps, where if you try and run to the solution, you think you're there. But, like you said, you, you're not actually there yet. And... And that is defeating, right? You're like, Oh no, you know, it's, it feels like the goalpost has moved.

[00:14:26] Really. It hasn't. It's that you sprinted and then you got exhausted is the kind of the metaphor that I was thinking of it instead of walking where, and maybe taking some breaks, you know, finding a bench, stopping, taking a break, evaluating where you're at. Okay. I was going to go to the store. Well, actually it turns out the store is going to close. Um, maybe I should, you know, go to this other place now that is still going to be open and I didn't waste my time running to that store. And realizing that it wasn't my goal.

[00:14:57] Dillon: Right.

[00:14:59] Jared: I don't know if that fits, but

[00:15:00] Dillon: Yeah, no, absolutely. Yeah, it's, it's powerful stuff.

[00:15:05] Jared: cool. Um, okay.

[00:15:08] Getting into programming

[00:15:08] Jared: And so I know you have this, this history as an agile coach and playing classical piano. And what I'm curious though, is how did you get into programming? Uh. Where did that happen? What that already there, in your life, or did that come later?

[00:15:27] Dillon: That's a good question. I mean, um, so I. I, I liked computers a lot in high school, I was always editing videos and, um, you know, doing things in Photoshop and, um, just sort of like hacking around as a user on a computer, you know? So I, I definitely liked fiddling around with computers and I also like, somehow I had this sense that I, I really liked logic.

[00:16:00] I don't know why, but for whatever whatever reason I I always like imagined like programming seems like a logic y thing that you do with computers and um, and I actually I got to the point. Um with with classical performance where you know, I was like accepted into a university, um music program and I was um studying and I was um Getting, getting to the level, like kind of my, my goal was to, you know, be able to more or less be, be treated like a fellow music student rather than somebody who plays really well for having started at 17.

[00:16:45] And I, I kind of like got to that point where I was able to just be another music student and I was like feeling good about the level I, I reached. But, um, It got to be where the lifestyle of it was, you, you take, you know, you, you, you do a short weekend camping trip and you, you're like, well, now I'm going to be completely rusty when I come back from this two day trip and, and then you come back and, and you feel like you're behind on things and you, um.

[00:17:26] And it doesn't feel good when you feel rusty and then you, you know, this thing that you want to come from passion is now something that you feel some obligation to do or, you know, and I just realized, like, I really love music, but I don't know if I can wake up every day and have this be the, the professional thing that I'm responsible for. So I, um, decided to change, and I, I changed to, um, to computer science. And, um, basically just started taking all of the university courses for, like a computer science freshman. And, um, changed tracks. And, it, it was kind of a shot in the dark. But, uh, it, it turned out very well. Like, from, from the start, I really loved solving problems with, with code. And I, um, I I'd never programmed before, but I just, I just kind of made that leap of faith for some reason. And, um, and now like doing, um, doing music as a serious hobby. And coding professionally feels so good to me because I can show up and solve problems. And if I, if I want to get really passionate about those problems and dream about them and think about them on my weekend, I can, or if I want to go on a vacation for a couple of weeks and not think about code at all and come back to it, I feel perfectly fine coming back to those problems when I come back.

[00:19:08] So, uh, as a lifestyle, that's felt like a really good balance for me.

[00:19:12] Jared: Yeah. I like that. So one thing I was thinking about when you're talking about this, this transition is, yeah, you're coming from a place where you felt like it was a, uh, not a great feeling, you know, a negative feeling when you're away from it and then coming back and realizing, oh, I, I don't know what's going on anymore.

[00:19:34] And what, what I first thought of with that was, oh, that's how I felt in JavaScript. When I worked in JavaScript all the time, I, I, I could, you know, I, it's 2014, I was kind of burned out from work and I had taken a month or two off. Um, and. Um, and when I came back, I was like, uh, I just felt so, you know, overwhelmed by it, but I mean, I could, that could even happen over a weekend or, you know, you get into a project at work and then, you know, you realize, okay, we need to make some changes to our architecture.

[00:20:07] You have a new project and you're looking at what's new out there. And it felt like there is so much going on that I just don't know about, you know, I didn't keep up on it, but I don't feel like that in the Elm community.

[00:20:20] Dillon: Yeah. I love that. That definitely resonates with me as well.

[00:20:25] Jared: Cool. Um, So, you, you were feeling rusty and you had this sort of, uh, realization that you were wanting to make a change. How old were you when this was going on?

[00:20:38] Dillon: Probably like 21 or so. Yeah. 21.

[00:20:44] Jared: Okay. So, yeah, not too, too long.

[00:20:48] Defining moments

[00:20:48] Jared: I guess then what were the defining moments where you realized this was the thing? Like, was it that where you said, like, you came back to it and you could go away from it? Was there anything else that really stuck where you felt, okay, I, I mean, I know you said also, let me, let me just bring it back.

[00:21:09] You said you could, you felt like you could do anything because of those techniques that you learned, right? In those other disciplines. Um, so maybe you've already answered it and,

[00:21:20] Dillon: Yeah. I mean, it definitely, yeah. I mean, I went, I went on a summer trip. Um, when I was 21, I went, went to South Korea, which was, um, a beautiful experience, uh, it's a place that's very near and dear to my heart. And, uh, yeah, it just was like kind of a soul searching thing for me. Just, um, being on that very peaceful summer trip and then coming back to that feeling of the heaviness of like that burden that I'm not doing enough. Um, and I'm like, that doesn't feel like the work life balance I want. Um, I, I just wanted more flexibility, but, um, but yeah, as you say, like it did, um, it did give me that feeling of being empowered to sort of like transfer that sort of meta learning ability to other things.

[00:22:18] And, and sure enough, like it, like, I really believe that. There is, if at, if at 17, you came back in a time machine and told me what was going to happen when I was 21, that I was going to decide I wanted to go into programming and I would really like it. I would, I don't think I could have chosen a better path to learn the skills I needed to, to equip me as a programmer than studying music.

[00:22:46] Like I really... I'm very grateful to all of the teachers and friends along that path. Um, and, and I have many close friends still from, um, you know, who are musicians who, I mean, are just people I'm very happy to have in my life and who, um, this, this lifestyle and this understanding of how to like. Work hard and break problems down to me is like so, so precious and something that I've really, uh, it forms the foundation for my programming skills.

[00:23:21] Jared: Yeah, I think that's really neat.

[00:23:25] Discovering Elm

[00:23:25] Jared: So you had this realization, you changed, you got into computer science. Um, when does Elm come in?

[00:23:34] Dillon: Right. So I was doing some agile consulting, um, and technical coaching out in Detroit. I was, um, consulting for a team at Ford and, um, And I discovered Elm, um, around that time, I'd been kind of interested in, uh, functional programming languages. Like somehow that was something that piqued my interest and, um, but I didn't have much exposure to it. And like I had. A teacher in college who introduced us to like a little bit of functional Scala, a tiny bit of that, just as like a sort of extra little concept, but it piqued my interest and stuck with me and I was playing around with Elixir and I really liked. The contrast between Elixir and Phoenix versus Ruby on Rails.

[00:24:30] And, um, when I, when I first started, um, working out of college, doing Ruby on Rails work, I, I thought I liked Ruby a lot. I kind of fell in love with Ruby, but then I realized, like, I think I like the sensibility of writing domain specific languages and trying to create abstractions and write high level code, but a lot of these things that are emblematic of rails using a lot of metaprogramming and magic. I actually don't enjoy working with them. It's actually like for me, very stressful. You know, I, I talked a little bit about that in our, um, in our ADD episode of Elm Radio, um, you know, I have ADHD and, uh, I think it, it's a double edged sword, but it definitely, uh, I really feel it when there's a large cognitive load, um, when, when there are a lot of implicit concepts going on and, and a lot of context. And Rails always felt like that. It's like, wait a minute, what, what are the pieces I need to be focusing my attention on here? Like, because things could come from so many different places and the, and can be so implicit.

[00:25:54] So. I was really interested in Elixir. Uh, and then somebody introduced me to Elm, um, at a little hackathon with some friends I was doing. And, um, and then I introduced it, uh, to this team that, uh, I was working with at Ford and, and we started to really enjoy it. And essentially it really like dovetailed with a lot of the things I was trying to, um, coach on this team, you know, trying to take incremental steps and trying to, you know, make things, making things testable, doing things like dependency injection, not just doing Time.now in your view code, but instead extracting something that injects time as a dependency. So it's testable. And extracting view objects to make your view logic testable and practices like this that are like a little hard to wrap your head around in Elm, it's just, there's no other way to do it.

[00:27:03] And so it was a really natural fit.

[00:27:06] Jared: Yeah, I like that. So I, I want to come back to the ADHD thing. But first, when you're at, uh, you've found Elm and you're at this, uh, contract at Ford. Did you happen to work with, uh, Grant Maki?

[00:27:22] Dillon: Yes. Do you know Grant?

[00:27:24] Jared: Yeah, well, I know he gave the talk

[00:27:28] Dillon: Yes, he did.

[00:27:29] Jared: 2018?

[00:27:31] Dillon: exactly.

[00:27:32] Jared: yeah, um, about, uh, you know, developing a culture of experimentation.

[00:27:38] And I thought that was a really great, uh, talk. And then I happened to give an intro to Elm talk at Detroit Tech Watch

[00:27:45] Dillon: Oh,

[00:27:46] Jared: in 2019. And so I got to talk with him a little bit

[00:27:49] Dillon: Oh, great. Yeah. Grant is a great guy. I really enjoyed working with him.

[00:27:53] Jared: Yeah. Yeah. He's, uh, really intelligent and really, I like his demeanor, you know, he really like, uh, thinks through things and just really easy to get along with.

[00:28:01] So yeah. Okay. And so did you introduce Elm to him or was this independent or how did that work?

[00:28:10] Dillon: Yes. I, uh, I introduced Elm to that team, uh, and then, and then Grant joined that team. Yes.

[00:28:17] Jared: Right on.

[00:28:18] Dillon: Yeah. So it's small world, I guess.

[00:28:21] Jared: Yeah. That's really cool. And so, yeah, you felt like Elm made the standards that you were trying to teach the only way to do things. Right.

[00:28:35] Dillon: Right. Exactly.

[00:28:37] Jared: Yeah. I like that.

[00:28:39] ADHD

[00:28:39] Jared: Uh, now going back to the ADHD, I want to talk about that. Um, I, I really liked that episode as well. Uh, my child has been diagnosed with ADHD.

[00:28:48] Um, and, and so I think about that a lot. And then the more that, you know, I hear that episode and I, we talk about, you know, these different things and how you, you break things down and, and that being a, for me, less anxiety ridden, uh, experience. Yeah. Um, there's one particular quote from that episode, uh, Elm Radio 68, ADD, that uh, I think I really connected with.

[00:29:15] And it says, this is what you said. "One of the big things I noticed with my experience with ADD is that if something is not well defined, it repels me." And then Jeroen asks what you meant by that and you say, "I just wanna avoid it. So it's very important to give things clear definitions." And I, I feel that, uh, deep in my bones of like, oh, if it's, if it's not something that is clear, I, uh, I got to figure out how to break it down.

[00:29:43] Right. Like I, and if I don't, then it just, it doesn't happen. It becomes that, what is it? Amorphous blob of,

[00:29:50] Dillon: Of undoability.

[00:29:51] Jared: Yeah. Of undoability. Yeah. Um, and there's a blog post that I read a long, long time ago, a decade ago, at least, uh, it was "the interruptible programmer" by Steve Streeting. Um, I'll, I'll put a link to that in the show notes, but, um, he had talked about that and actually had mentioned getting things done and, you know, creating a next step and, and how to prioritize negatively in these things.

[00:30:21] And like, I was really struggling at that time to, to handle all the things, you know, that I was trying to accomplish. Um, and just that alone really helped me to get a handle on that. So, um, so yeah, I think that was really great. I definitely recommend, um, checking out that Elm Radio episode, but, um, yeah, that that's really neat.

[00:30:43] Um, thank you for

[00:30:44] Dillon: And it's kind of, uh, it's kind of full circle too, because I, I don't know. I mean, maybe it's. Maybe it's just me, but I, to me, I see all of these concepts sort of interacting, um, you know, the, the breaking things down into more manageable slices. And to me, I just see defining your work clearly as a special case of that.

[00:31:08] Because, um, if you just dive in and do it as this, um, atomic unit. You're just like, okay work. It's kind of unmanageable and you say well, how do I split that into pieces. Maybe instead of work I define the work and then I do the work and now you've you've split that into something that is more approachable.

[00:31:37] So you say like well Um, can I, and it, and it really is about like having the facility with being able to break things down. So if, if you're struggling with something, being able to notice, Oh, this is, this feels slow or difficult or unproductive. And then, well, what would make it easier? Well, what if, you know, I'm having trouble just doing this thing.

[00:32:03] Well, what if I just decided what I wanted to do? Could I do that?

[00:32:08] Mentors

[00:32:08] Dillon: So

[00:32:08] Jared: you mentioned a mentor when you were learning to play piano, right? This, the teacher that was helping you create this, uh, this pattern, right? Of breaking things down,

[00:32:20] incremental steps,

[00:32:21] Dillon: Yes.

[00:32:22] Jared: Were there any mentors later specific to programming that you, that you found?

[00:32:31] Dillon: Well, when I was at Ford, I got the opportunity to work with some incredible coaches. Um, we sort of had a team of coaches. We were working side by side to sort of, um, try out some, you know, more iterative and incremental ways of working. And, um, I learned a lot through that experience. It's just, um, You know, there's, there's no substitute for just sitting down with somebody who, who knows their stuff and working with them. And so I got, I got to do that with some, some people who I really respect, uh, and, and really owe a debt of gratitude to. So yeah, I, I learned a lot from that experience and, and, you know, I mean, the, the people on that team were really incredible people too, who, uh, we all sort of, I think learned a lot together on, on that experience.

[00:33:33] Jared: Cool. Okay. So you were working with these other coaches and working with this team.

[00:33:39] Mobster and the Elm community

[00:33:39] Jared: Um, I want to. I'm going to ask you now, because there's a thing that you wrote in Elm, um, and I think this might relate, um, called Mobster. It's at mobster.cc.

[00:33:53] Dillon: That was my first Elm app.

[00:33:54] Jared: that was your first Elm app. Okay. Yeah, that's really cool. Well, first I wanted to tell a story about it, because, um, this is...

[00:34:02] When I met you it was elm-conf 2017. I don't know if you remember

[00:34:06] Dillon: Yes, I do.

[00:34:07] Jared: But yeah, I was hanging out in this this lounge at Strange Loop. I think it was after elm-conf and you and Murphy Randle, the original host of Elm Town about, you know, how things relate and then Andrey Kuzmin, who I built the Elm 3D pool game with

[00:34:27] Dillon: Yeah.

[00:34:28] Jared: You all were hanging out, and you were doing some mob programming, using Mobster,

[00:34:33] Dillon: Exactly.

[00:34:34] Jared: uh, in the corner, and I just happened to be hanging out around there, you know, working on my laptop, and what I found was that the Elm folks there were just so kind, you included, you all were so kind and, and so inviting, I had no Elm experience, I had never used it, basically at that point, I just had this, uh, I had bought into the concept of Elm, you know, so I was like, I need this in my life.

[00:34:58] I'm going to elm-conf to see what it's about. Uh, but yeah, everybody was still inviting there and you'll happen to invite me to join you all basically knowing nothing about mob programming, knowing nothing about Elm and just kind of getting thrown at the keyboard and like, okay, now, you know, tell me what to type.

[00:35:15] Right.

[00:35:15] Dillon: Yeah. Yeah.

[00:35:17] Jared: Um, so that was when I was really hooked with Elm. I was like, okay, you know, not only is this a tool that fits all, you know, checks the boxes of, of things that I was looking for. The, the problems I was trying to solve solutions to challenges. Right. But it also is just this incredibly kind community that, you know, that really, um, accepts anyone and doesn't think twice about it.

[00:35:40] So, um, thank you for that.

[00:35:42] Dillon: lovely. Yeah, that I love that point too. Like I you hear people saying in the Ruby community I think they're saying is "Matz is nice. So we are nice." Which is you know, it's just a great great thought and like yeah, like the ethos that that Evan has created with, um, like really to me his like product management insights, his ability to look at a problem so deeply and really understand, like step back from maybe what existing solutions might do and see what are we really trying to do here and rethink that, um, has really influenced, the whole community, you know, and I mean, of course, you know, Richard Feldman as well, like, I think they really seeded the community, in these early days, with some incredible conference talks and writing and, and package designs and pairing with the community and, um, you know, I mean, I, I feel like, um, that, that is like what, what makes the community, what it is that we have the, this in our DNA as a community, these principles of designing, um, delightful tools, and

[00:37:08] packages and, you know, hopefully making it a delightful place to be.

[00:37:12] So it's, it's really nice to hear that experience.

[00:37:14] Jared: Yeah. Yeah. That makes me think of the "taking responsibility for user experiences" point in that, in that tweet by Evan. Um, yeah. And. So, so mobster was your introduction, the first app that you built with Elm, but, uh, where I thought it tied in here was you're talking about working with these other coaches.

[00:37:39] And I felt like maybe this, you know, this idea, this concept of pairing and mobbing, um, with times of like how you could learn a lot in a short amount of time, still taking incremental steps by doing this process of, of mobbing and pairing. I don't know if you

[00:37:57] Dillon: absolutely. Yeah.

[00:37:57] Jared: have any thoughts on that.

[00:37:59] Dillon: Yeah, I think all of these things tie together for me. Um, mob programming, it really lets you tap in. To the wisdom of the group, you know, and, you see your role in a different way. You know, it's not just, um, writing the code. Sometimes it's more powerful to allow somebody else to have an insight and be silent for a moment when you see somebody starting to have that light bulb go off.

[00:38:32] Um, so it, it really makes you think like, how can I support the shared goal and you see yourself in this context. And to me the idea of mob program which for anybody who isn't familiar with the concept of mob programming. It's Like pair programming where you you have two people working on one computer on one problem, but it's uh It's more than two people working on one computer on one problem.

[00:39:04] To me it's, it's got lean concepts underpinning it, which is, um, instead of. Like, so big batch thinking often, uh, you contrast sort of big, big batch mass manufacturing concepts with lean concepts. Sometimes people, um, use different terms to describe it, but to me, agile and lean are really the same thing.

[00:39:32] Uh, people sometimes use the word Kanban. Sometimes a lot of baggage gets dumped onto these terms that to me doesn't really get it, the core principles of them. But I really love lean principles and I think mob programming really gets at the core of lean, where instead of trying to optimize for units producing at all times and reduce, reducing the downtime of your valuable units, you know. In the case of an engineering organization, that might be fingers of your highly paid developers at a keyboard. And, um, you know, in the case of a car manufacturing process, that would be, um, the production line and the dye that's stamping out chassis and things like that. These are incredibly expensive pieces of machinery that, um, there's a, there's a cost to halting operation of them and not maximizing their uptime. But counterintuitively, if you focus on maximizing that cost, you create a lot of waste.

[00:40:40] You create a lot of wait time where things are, um, you know, you're, you want to keep this one expensive machine operating. So you start stamping things out and leaving them in warehouses. And so you don't find out that there's been an issue in the production line until far later. So you're delaying your feedback to, to when you discover that there's a quality problem. So counter intuitively by optimizing for that, you can create a lot of waste. And, uh, so in lean, you, you optimize much more for the cycle time, the time from concept to cash or from starting work on something to, to shipping something. So in the case of mob programming, it makes you take a whole, a more holistic view of the process of shipping software.

[00:41:34] So what is, what is involved in that? It's not just writing out code. That's one piece of it, but it's pulling in stakeholders to make decisions and drawing on shared context from multiple parties who are involved in these decisions and the history of these systems and... so it it actually reduces the friction in all these other areas that often become the bottlenecks things like code reviews and waiting on decisions and bringing in stakeholders and things.

[00:42:08] So so By counter intuitively having less people typing on their keyboards, you reduce all of these bottlenecks in the process, and they completely go away, and you're building up shared context. So, yeah, I just, uh, I love that it kind of flips some of these traditional concepts on its head.

[00:42:30] Jared: Yeah, I like that. Thank you for that explanation of it and and linking those.

[00:42:36] Jamming on jazz improv

[00:42:36] Jared: And one thing I think that it relates to is you were talking about when you're playing piano and you know, you started your or your teacher started asking you questions like what happens if you play this at halftime or quarter an eighth time, you know, and so you're thinking about it in different ways.

[00:42:55] And I think that's, that's what's happening here, right? You're, you're taking a problem and you're looking at it, you're kind of turning your perspective on it and, and seeing it from a different light and then, um, you know, understanding that, uh, we're still, we're creating constraints, you know, to kind of go back to a lot of terminology we use, um, by saying this person's role in mob programming is only to type on the keyboard.

[00:43:21] They do not type anything that is not told by someone else. So now they can, you know, there's a clear line here. This person's role is this. This other person's role is to tell them what to type. But then they need to take input from other people. And you know, maybe their role is, there's one person that is doing research.

[00:43:40] Or like you said, there's somebody who is a stakeholder. And then, you know, maybe there's somebody who is making sure that everybody's voice is being heard. And, and I really like when you take and you give these different roles and you create these constraints of like, this is your role and then mixing it up too.

[00:43:55] Right? Like you, you throw a wrench in it by saying, okay, now we did that for five minutes, we're switching it up. You know, now your role is to, is to be on the keyboard and my role is to talk. And so, yeah, I think that's really, uh, really cool. Do you still use that, um, regularly?

[00:44:13] Dillon: You know, I've been, I've been doing so much solo coding on open source lately that, um, I ha, I haven't been doing much mob programming at all recently, but, um, but this idea you bring up of sort of constraints and, and sort of gamifying constraints, um, is something that I, I've been thinking about a lot and actually I, I didn't mention it, but, um, I've actually in the, in the past, um, past five years or so, I've, I've actually kind of, uh, changed from classical piano to, to doing a lot of jazz improv. And, uh, that's been a really interesting transition.

[00:44:53] And one of the things that is sort of a, an interesting overlap between, um. Um, you know, some of these, uh, kind of gamifying constraint games that sometimes it can be really fun to do that. Like in things like code kata is where you're doing a test-driven development exercise and you, you can turn it into a game.

[00:45:15] You can say, well, at a random point in time, uh, if your tests are red, then you have to revert your code to the last green state, right? So just like just throwing a wrench in things to see what happens to mix it up. And um, that's been a really interesting exploration for for me with my classical background with jazz piano is because in in classical piano in a sense of course you're trying to have flexibility and and the ability to to shape your interpretation the way that you want to, right?

[00:45:52] You, you don't want to be a robot in classical music, of course, but you, you kind of decide on an interpretation and you want to be able to somewhat reproduce the type of sound and articulations and phrasing and, uh, and tone quality and everything that you're trying to produce. So you, you try to get really good at like producing these, these things reliably. And in jazz improv, like if your lines are sounding similar, it's very easy for that to happen to sort of have a particular improvised style that you, you stick to. So you need to throw yourself curve balls. And so I've been playing around a lot with these types of constraint games in my, in my jazz piano practice, where I'll just have a constraint and say, okay, longer notes like more quarter notes or 16th notes or, um, syncopated rhythms or alternate harmonies, reharmonization, whatever you can like...

[00:47:01] but you have to be able to just put a different lens on it and experiment and see what happens and have a facility with trying on these different outfits and, uh, that keeps you, I mean, if, if you're not, if you're not trying new things, how are you going to be learning? Are you, are you, you know, do you, it's the kind of thing, like, do you want 10 years of the same one year of experience or 10 years of unique experience? Right.

[00:47:37] And you do have to kind of mix things up and you have to be sort of deliberate to achieve that. I think.

[00:47:43] Jared: Yeah. Yeah. I really liked that. Um, so one thing I want to go to is you were talking about classical and how that was, you know, something where you had a little bit of, of leeway, right, but not much. It really made me think of, this is, um. Something from a book that I recommended. I just recorded an episode with, with Wolfgang Schuster and I recorded, or I recommended this, this book Kafka on the Shore, um, by Haruki Murakami.

[00:48:13] And one of the things that I had said, um, was that he had a history as the owner of a jazz bar. And so a lot of the writing in this, it's, it's a fantasy novel Kafka on the Shore, but, um, he talks a lot about music in there and there's this one particular, uh, section that just, it, for some reason gave me chills and I think it fits really well here because he's talking about, um, Schubert and talking about "when I drive, I like to listen to Schubert's Piano Sonatas with the volume turned up"

[00:48:44] Dillon: Nice.

[00:48:45] Jared: and he asked, "do you know why?" He says, "Because playing Schubert's piano sonatas well is one of the hardest things in the world. Especially this, the sonata in D major. It's a tough piece to master. Some pianists can play one or two one or maybe two of the movements perfectly, but if you listen to all four movements as a unified whole, no one has ever nailed it." And it says basically that it's there's always something missing because, it goes on to say the sonata itself is imperfect and they're struggling with this paradox of trying to create something perfect out of it.

[00:49:20] So I, for some reason that, that really, uh, stuck in there. So if you haven't read that, I definitely check it out. That's on page 111 of this version of it. Um,

[00:49:30] Dillon: a very good sign that they're a fan of Schubert, that those Schubert piano sonatas are brilliant. Yeah.

[00:49:37] Jared: But then, yeah, so improv, we're talking about that and how now I'm, I think that if you take music from this perspective, right, you've been doing this for a few years now, you're playing something, you go away on the weekend, right? You're talking about camping and you're not practicing it, trying to get it so called, you know, perfect.

[00:49:59] You come back, this might actually. Create a new idea, right? Because now it's more creative. You have more freedom in, in the different options and what you can bring to it. Um, I played some, uh, improv music back in the day. I mean, you know, just very, uh, I guess not very intentional with how I went about it, but it was basically like a, a jam band thing,

[00:50:23] Dillon: Cool. Cool. Cool.

[00:50:24] Jared: and so, um, I definitely felt like, you know, I could learn something and then go away from it. And then when I would come back a little bit later, I would have a little bit of freedom where it was, it was something that maybe I had the muscle memory, but it was a little bit more lax and because we were in this space where it was, you could, you could play something here and you could, you know, you could kind of try it and see how it goes.

[00:50:47] And then, oh, you kind of mix in this other thing in there and, oh, wow, that sounds really neat together. I hadn't thought of that, but now that I hear it, this really works.

[00:50:56] Dillon: yeah, it gives you a new random seed anytime you sort of change something up.

[00:51:02] Jared: Nice, perfect.

[00:51:04] Dillon: I heard um, I heard an interview with Herbie Hancock, who's a, you know, one of the great jazz pianists and um, I really liked something he was saying that he was, he was talking about like, um, fingerings on the piano that he, he said he liked to use unusual fingerings, like often we, on piano, we don't like to have our thumb on black keys or we don't like to cross under our, our pinky finger.

[00:51:34] We like to cross under fingers that are a little easier to cross over, but he would intentionally practice things like that just to, um, give himself more flexibility when he arrived in an unusual situation so it wouldn't get in the way of his ability to get his ideas out. And he also talked about needing to have your practice routine and your warm up routine and everything before a gig. He said in a sense like well okay what if you're on tour and you and you don't get to practice for a couple of days. Now are you just not gonna do the gig.

[00:52:16] So he's he talked about being prepared for those sort of corner cases. And it's just such an interesting mindset. Like I the the whole jazz mindset has definitely been something that's changed my my perspective on things and in a different way than than classical piano. This sort of like really breaking concepts down. So they're they're almost like pulling my brain in two different directions.

[00:52:45] It's really interesting

[00:52:46] Jared: Yeah, but when you combine them, I think it seems like it's really been powerful.

[00:52:51] Dillon: Yeah.

[00:52:52] Jared: so I guess kind of bringing this back to Elm,

[00:52:55] Finding time for experimentation & learning

[00:52:55] Jared: I know you've been working on Elm tooling for a long time. And, um, and I think that this can kind of relate there. Because how do you build in this time where you're like, okay, now I'm learning, now I'm experimenting, I'm throwing a wrench in there versus I need to, I need to get a thing done, I, I, right, I need to get something from start to finish or, you know, get to that goal?

[00:53:19] Dillon: That's a great, that's a great question. I mean, you know, as you, as you mentioned earlier, if you, uh, you know, if you're, if you're walking to a store that's actually going to be closed by the time you get there, then you may as well save your steps. Right. So, um, in the same way, when you're, when you're doing design work, you don't want to take those unnecessary steps.

[00:53:41] So if you, if you really spend a lot of time working with design assumptions that haven't been validated, then you might end up walking to a store that's, that's closed and having to retrace your steps. It's actually been very interesting for me doing a lot more, um, API design work, um, in the last year or so. Because, you know, a lot of my, uh, kind of ideas and, and, and practices that I built up doing my, my agile consulting and technical coaching and these sorts of things were about not over engineering, you know, building, um, building for a use case, not over abstracting your code over prematurely generalizing your code, not writing all the bells and whistles in at once, just like, how do we get this feature delivering the value that we need?

[00:54:47] And, um, in a weird way, when you're doing API design, you do sometimes have to consider a broader set of use cases. So counterintuitively, even if you're trying to do the simplest thing that could possibly work for an API design, you're not solving for one specific use case, you're solving for something where, so for example, if you're trying to minimize breaking API changes, there's a push and pull there where doing the simplest thing that could possibly work, solving for one use case and shipping it.

[00:55:25] It goes against that idea of trying to minimize breaking changes. So you want to get out in front of that and you want to, but at the same time, I think you can still use that mentality of trying to, um, you know, really like a lean approach. Like, um, I really like this Lean Startup idea of validated learning, like Lean Startup is a fantastic book that essentially is talking about these lean principles of, you know, reducing that cycle time of concept to cash or whatever, um, but for validated ideas, validated learning. I think the same thing applies for API design. If you have an API design concept, how can you validate or invalidate that?

[00:56:17] How can you form a hypothesis and test that out as quickly as possible? And so I guess in a way, like that's, that's one big mechanism that I've used to try to do a more agile form of API design, because you don't want it to be a big upfront design, but you kind of also need to do big upfront design a little bit.

[00:56:39] Jared: Yeah. Yeah. I like that. I mean, it's a balance, right? You know, it's kind of like, like you're talking about kind of combining these different approaches and figuring out the balance between them.

[00:56:49] How to make an incremental learning path with elm-pages

[00:56:49] Jared: And I, this actually ties into a question that I wanted to ask specifically about making elm-pages. Because I wanted to know how do you tackle the challenge of making it simple to start and yet possible to build up to use all those great features? Especially with V3, where I feel like the scope is, you know, is much larger.

[00:57:10] Dillon: That's been a big focus of mine. So one of the things that, um, I've been using as a sort of a tool to put that, to create that feedback loop for myself is trying to create a short video tutorial. So, DHH, the creator of Rails, has this famous, um, "Build a blog in 15 minutes" video where he introduces Ruby on Rails.

[00:57:36] And, and actually he, he really builds it in more like three minutes, and then like adds a comment section and and changes the styling and adjust some things in the, in the rest of the time. So, um, I think that like having that constraint of like, okay, however cool your thing is, if you can't show me how cool it is in three minutes. Or, you know, let's be, uh, you know, a little more forgiving in 15 minutes, then, maybe you should focus on that. Maybe you should take responsibility for those user experiences. It's important to, to put that in your purview and not just say, well, that's not my problem.

[00:58:20] Like with Elm, there, there will be some amount of boilerplate. With Elm, you do have to explicitly wire things and we can't do magic. We can't do meta programming. We should figure these things out. So like some of the things I've been working on for that for Elm pages V3 have been the scaffolding tools that, that are baked into V3.

[00:58:39] So, you know, much like, you know, building a Ruby on rails application, the build a blog in 15 minutes, uh, DHH scaffolds out some pages with some forms that let you submit to the server. And then you can, you know, make your, uh, your database calls from there. So I built some similar tools that help you scaffold out a form.

[00:59:03] And with a single, you know, you, you can clone a starter repo. You can, uh, run a command to, um, scaffold out a route where you give some form fields for that route. And now you have an end to end example where it is doing full stack Elm. It is displaying a form. It has client side validations that shows if any fields are required and missing, and you can start to modify those and add additional validations to those fields, but it gives you all of the wiring and it submits that end to end.

[00:59:42] You receive it in Elm code and you can perform backend tasks, including the BackendTask.Custom.run API function, which lets you call into Node JS code from your own backend. Those are some of the things that I've been trying to do to address, like making that Elm sweet spot, even though it traditionally hasn't been.

[01:00:08] Taking responsibility for that full experience of like, Hey, if I want to get a page up and running quickly, what would that look like in Elm? Also just like the design for this form API, which went through a lot of iterations and I gave it a lot of design love. Um, that was a big part of it too. Just how do we make that as declarative as possible?

[01:00:30] Because the way that the way that we've done forms traditionally in Elm, where we have a message for every field. It was just something I looked at and said, this is one of the bottlenecks to, to be able to give a really great demo and say, like, I want to build a web app where I have an admin panel and I can enter some data into a form, get client side validations, post that data, and update a database or something, right?

[01:01:03] Like if you can't show a really nice demo of doing that, then your framework might not be focused on the right problems. You know? So I was trying to make a really good demo for that.

[01:01:17] Jared: Okay. Yeah, that makes a lot of sense. You've, you've set this goal for yourself of, of being able to do that and, and then using that as a, the, of where you're trying to get to and, and how you can make it something that folks can get started with. And then I, I believe you got paid at some point to work on part of this?

[01:01:40] Dillon: Yes, yes. I, I am getting some, some funding to do that, you know, and it's, uh, I mean, I also have some GitHub sponsors and, uh, GitHub sponsors are always appreciated to help, um, give me more leeway to, to do my open source work. So that's been, um, yeah, I've been really grateful for, for that support

[01:02:01] Jared: awesome. Yeah. And I mean, this really is an ambitious project, but I mean, I feel like the reason you've been able to build all these great things is that you have broken it down, you know, you have taken these incremental steps and, and your approach and building it and, and, and kind of rebuilding it, you know, because I mean that we're on, uh,

[01:02:23] Dillon: Yeah.

[01:02:24] Jared: Elm Pages 2 is completely released and Elm Pages V3 at this point is in beta, correct?

[01:02:30] Dillon: Yes, exactly. Yeah.

[01:02:32] Jared: Yeah, yeah,

[01:02:33] New features in elm-pages v3

[01:02:33] Jared: and that's definitely going to extend the feature set. Do you want to mention what some of those features are?

[01:02:39] Dillon: Yeah. I mean, the, uh, the big headline is, you know, full stack Elm. Uh, so

[01:02:45] Jared: Yeah!

[01:02:47] Dillon: uh, uh, much like something like Next JS or Remix JS gives you the ability to, um, render a React application that fetches data on a server. Um, could be a traditional backend or a serverless function, uh, or edge function.

[01:03:09] It's able to resolve data on the server, send that over the wire and hydrate into a React application. elm-pages V3 allows you to do the same thing. You can do server rendered routes. It's a hybrid framework, so you can also do the statically rendered routes at build time that people are familiar with, with elm-pages V2, uh, it's definitely going to take some time for me to, uh, get the message out there that there's this new paradigm that I think is a really compelling story. When you introduce a server piece to Elm, to, to this framework.

[01:03:43] I think it gives you some really, um, good conveniences for the developer experience and the user experience. So, uh, for example, you can resolve your data. If you're, if you're resolving your data in the same data center where your Elm pages server side piece is hosted, then. That means you don't have to pay the latency cost of making requests back and forth.

[01:04:09] So it might seem like, wait a minute, like I have to wait on getting my data before I send out the initial page. But here's the thing, if you consider, you know, let's say you're building a, uh, a products listing page, something like Amazon or something like that, search results, you know, so you have a search query, you're listing out products matching the search and filters, and you need to display the, the images, uh, for all of the product listing, right?

[01:04:41] So until you see the picture of all of these products you're searching for, you know, until you see the picture of all of these different shoes that you're filtering on, you haven't really provided a meaningful experience. So in a client rendered page, um, if you purely have client rendering, no server side rendering.

[01:05:03] Then what that's going to look like as the life cycle of getting those shoes visible to the user is, you know, you, you download the CDN hosted static assets of the JavaScript bundle and the HTML skeleton page that has whatever skeleton you're going to render while it's hydrating. Once the JavaScript bundle has hydrated.

[01:05:29] Now you can trigger your request. So it, so it needs to make the initial connection to the server, get the HTML. The HTML is parsing. It sees that there's a script tag. It fetches that script tag. It continues fetching the initial resources. It needs CSS, you know, JS, uh, starts rendering the HTML skeleton.

[01:05:54] And now, once the JS is hydrated. It knows that it needs to make an API request to get the listing of search results for the current page. So now, um, it goes and makes that request once it's hydrated, it waits for the server response to get the, uh, API response back. Once it has that API response, it can render the DOM nodes that show the shoe listing. And what does that contain? It contains some image tags with source attributes. So now it needs to go for each of those image attributes. Fetch those in order to show the shoe listing. Right? So if you compare that with a server rendered version, you are going to get the API request, get the initial request from the user it's saying it wants to see the search results, it goes and makes all of the API calls. Whether it's directly making database queries or calling to an API that's hosted in the same data center, either way, you're not paying that latency cost when you make that API request. So the idea is it should be extremely fast. So you very quickly resolve that data. You get the initial HTML rendered.

[01:07:18] So this should all be very fast and performant.

[01:07:23] So you pay, you incur a little bit more of a cost for that initial HTML response. But if you're doing it right, it should be quite fast, especially if you're doing things like proper caching for your API calls and things like that. Right. So ideally you should get very fast, um, resolution of your data. Now you send your initial HTML, which has resolved all of the data for that page for that initial listing of search results.

[01:07:52] So instantly you, uh, start rendering the HTML and the HTML actually shows a meaningful user experience. Now it has the image tag. So the browser can kick off those, uh, image downloads faster. So if you're doing it, right, this is the performance start right. Now, this sort of server rendering architecture does require a different mindset. It does require that you're thinking about the latency between, uh, where your server rendering is happening and where your sort of data resolution is happening, if there's latency between those, it's not going to be a good experience, so you need to think about that in the architecture, but if you're doing that right, then you can get a really compelling user story.

[01:08:39] And at the same time, you can also get a simpler developer experience because that intermediary state of data, the remote data loading state goes away. So those are some of the things that I find really compelling about this sort of server rendered approach, not to mention that it's just full stack Elm.

[01:08:58] You're communicating with form data that you're, you're declaratively writing a parser for in Elm, and you just have that data on the server side with the same shared client side validation logic that you know is being applied and shared in both places. So, um, yeah, to me, the, the story, when you introduce a server becomes quite interesting, not to mention things like.

[01:09:20] Cookie based authentication, which I believe is a lot simpler than JWT-based authentication.

[01:09:28] Jared: Yeah, totally. I mean, that's, that's a really compelling story. And then you also get things like, and I know you've done an episode on elm-pages scripts where you, where you can, you can build things that, you know, need to go out and, uh, perform some task and then, you know, return some data. Right.

[01:09:48] Dillon: Yes, exactly.

[01:09:50] Jared: that's really neat too.

[01:09:51] I mean, I think there are a lot of, uh, a lot of things to explore with it and I'm, I'm really excited.

[01:09:57] Dillon: Yeah, me too. I can't wait to see what people build with it. And yeah, as you say, the, the script, like all these pieces sort of fit together too, because the, um, Elm pages scripts uses the same concept of backend tasks and, um, You know, that are used for resolving the initial data on the page. And the follow up data when you make a form submission is able to resolve a back end task to get data in that follow up request.

[01:10:27] I think it's a really interesting model. And we haven't even touched on one of the really... exciting features, which the, uh, RemixJS team has done a great job sort of talking about these concepts and pioneering them, but elm-pages has been heavily inspired by their approach to managing form state. I think it's really interesting when you start deriving optimistic UI or pending UI from form state that's managed by the framework. So elm-pages, V3 is really built around a lot of these concepts, which allow you to get the best of both worlds, creating user experiences that kind of have this sort of architecture in mind, this is sort of becoming an industry standard in JavaScript these days, you know, all of the, there are all these competing approaches, but

[01:11:14] they're mostly using server rendering in some, in some form or another. Um, and in addition to that, you know, using, um, progressively enhancing these experiences so that you get, you know, the ability to have like very interactive pages that aren't just like a rails app, but getting some of the mental model of a rails app, where you can have cookie based authentication and have a single paradigm for kind of rendering the view and, and resolving data on the backend, but in a more interactive way where you can do things like optimistic UI, where you're showing items that you're submitting, you can show what it would look like when that item is created in the view optimistically. So it's, there are a lot of abstractions for that. I think it's, it's going to be really cool to see what people build with it.

[01:12:06] Jared: Yeah, yeah, I'm excited. And I think, you know, one of the things about the elm-pages scripts is that, like you said, that uses the same concepts as the server side rendering. And I think that that can be one of those places where it's like, I don't want to think about the whole thing right now. I want to kind of learn this one concept in here.

[01:12:26] And, um, I think, you know, at least for me, like, that's nice to have that as an option of like, okay, let me see this hello world. Where does that look like? And, you know, and then kind of build up from there, understand that well, and then move into actually, you know, okay, now, oops, I, I built a page, you know, like you're, you're

[01:12:41] Dillon: exactly. Exactly.

[01:12:43] Jared: that approach and then looking at that code and modifying it.

[01:12:45] So, yeah, this is. Super exciting.

[01:12:48] Elm and AI

[01:12:48] Jared: In general, what are you excited about these days?

[01:12:51] Dillon: I am very excited about being done with elm-pages v3. Hopefully by the time listeners hear this episode, it will no longer be beta. It will be a stable release. I'm very bullish on, uh, Elm and AI. Uh, Jeroen and I did an episode on Elm and AI recently of Elm Radio and, um, I've been playing around with some scripts using elm-pages scripts to, uh, invoke the open AI GPT for API and, um, sort of.

[01:13:24] Feed in some context from types in an Elm application and get it to solve problems through building up a prompt and guiding it through some steps of, uh, doing some Elm tasks and then, uh, generating unit tests, generating Elm unit tests and giving it the Elm compiler and unit test failure feedback so it can iterate to a solution that is a verified correct solution, not a something we have to worry about being hallucinated.

[01:13:52] So that's definitely, um. An area that I think could be really cool for, for the Elm community to kind of be able to have some verification techniques around this. I think that could be Elm strong suit. So it'd be cool to see where that goes.

[01:14:07] Jared: Yeah, that is exciting because I was talking with a coworker about this after listening to the Elm AI episode. And I agree that Elm is a, a, a sweet place for this because It does have these constraints and we can, yeah, use that to add more context, like you said, and I think get better results and, um, to see how that will work versus like, you know, I had Kevin Yank on, uh, recently and he had written a blog post about chat GPT and about, you know, how it's, you know, kind of this, you know, can, you know, Generate these confident, but insane, you know, responses.

[01:14:45] Um, but by using Elm, we can create a constraint that, you know, they can help, um, verify and validate and, and prevent that, you know, create that guarantee,

[01:14:56] Dillon: Yes, exactly. Exactly. That's, uh, that's one thing, uh, you know, I think. If I, if I didn't have this sensibility before, I certainly have it after a few years of, of doing these Elm Radio episodes with Jeroen. This, uh, love for guarantees. Like, I think it's probably solidified this, uh, I don't, I don't know if other people in the Elm community are as, as obsessed with it as we are.

[01:15:25] I think a lot of people are also obsessed with guarantees, but I just think that difference between, uh, 99% confidence and 100% guarantee to me is like a really sweet thing

[01:15:36] Jared: Yeah. Yeah. It's what allows me to sleep at night, I feel like, when I work with Elm.

[01:15:41] Dillon: Me too

[01:15:43] Jared: Yeah, that's great. Is there anything else you want to talk about before we move on to picks?

[01:15:49] Dillon: No, it was a great conversation and I do want to say thank you for uh, picking up the baton on Elm Town, you know, I've um, I've really i've been wishing for uh Elm Town to come back into my feed. And I, I look forward to getting new episodes. Every time I see you posting them, you're just getting started with it, but I'm really excited to have a steady drip again in my podcast feed.

[01:16:13] So thank you for taking the reins on this.

[01:16:15] Jared: Yeah, yeah, no, I'm really excited about it, too. I appreciate that.

[01:16:18] Sponsored by Logistically

[01:16:18] Jared: And I have to be thankful for my company that I work at Logistically because, uh, they sponsor my time to record these episodes and to, um, to take care of the hosting and production costs. So, yeah. Um, and I, I wanted to mention that we are hiring.

[01:16:40] So if you are interested in transportation management, um, you know, allowing, uh, logistics professionals to make better decisions, spend less time on manual tasks, creating efficiency in that process, um, uh, please drop us a line, elmtown@logisticallyinc.com. I'll put a link in the show notes.

[01:16:59] Seeing how other folks are using Elm

[01:16:59] Jared: Um, but yeah, so I think that for me it's really nice to see how other people are using Elm, right? And have these conversations that, that allow us to see, oh, wow. You know, there are, uh, people are using Elm in many different ways and, and also showing that, you know, there are a lot of companies that are using Elm that have been quiet. So I'm, I'm excited to do more with that.

[01:17:24] Dillon: Yeah. The, um, the episode that Jeroen and I recorded on Elm at a billion dollar company was by far our most popular episode ever. So there's definitely like an appetite for hearing about companies building businesses on Elm and sometimes, you know, Elm at a billion dollar company was such a great headline that, you know, our sort of mantra of tools and techniques in the Elm ecosystem.

[01:17:53] It, it was enough to fit it in there that it's like, okay, this is a really, it's not exactly a tool or technique, but this is a really good episode and, and Aaron White was an amazing guest as well. But yeah, having, having Elm Town, this different format to, it's, it's a great venue for talking about more of these stories of people using Elm.

[01:18:15] So I'm really glad that you're doing this.

[01:18:18] Jared: Thank you. Yeah. And I'll put a link to that episode. That's definitely, that's one that you definitely want to check out. Um, but check out all of Elm Radio because Dillon and Jeroen are, are doing an excellent job there. And I wanted to say your ability to explain those concepts and talk about code in a way that I can follow is really impressive.

[01:18:42] When I

[01:18:42] Dillon: Oh, thank

[01:18:43] Jared: getting into that, into that depth, I, uh, I find myself to, uh, to get stuck and caught up and thinking, well, no, wait, hold on. Let me think about this again.

[01:18:53] Dillon: That's very good to hear because sometimes it's hard to know if that, like sometimes we get in the weeds, like talking about the phantom builder pattern and things like that. And we're like, I hope people are following this, but it's good to hear that some of it comes through.

[01:19:08] Jared: yeah, it definitely does. And I think, um, you know, it's, it's just enough that if it's something that I don't quite get, I can, you know, go look it up and then listen again. And then, you know, it's like, oh, okay, now I can put, I can visualize that as you're talking through it. So, um, that works for me.

[01:19:27] Yeah. Cool.

[01:19:29] Picks

[01:19:29] Jared: Well, are you ready to get on to picks?

[01:19:30] Dillon: Let's do it.

[01:19:31] Jared: Okay. What do you have for us today?

[01:19:33] Dillon: I thought I would bring a couple of things that have been like very formative for me. And we've actually touched, touched on a lot of these in some form or another. Um, we talked about Getting Things Done by David Allen, uh, uh, you know, defining your next action, um, amorphous blobs of undoability.

[01:19:52] The book, sometimes people talk about how much it talks about paper systems and having 43 folders for your particular file and things like that that are somewhat antiquated. I think there's an updated version, but to me, it's really a set of principles for how to get your brain to stop bugging you about something because it trusts that it is in a trusted system.

[01:20:17] That's the And so, um,

[01:20:21] I would highly recommend anyone who's interested, read it with that in mind. Just trying to get like extract that principle from it. Cause it's so good.

[01:20:31] Jared: And I want to ask you real quick, what system do you use? Is it paper or is it online?

[01:20:36] Dillon: I have been using Things and I absolutely love it. It's a Mac iOS only application, unfortunately, but if you use those operating systems, it is wonderful. It is like the perfect for me level of balance of simplicity and power. And it allows you to kind of, uh, set aside a, uh, a set of things you want to focus on for the day, which I really enjoy too.

[01:21:03] Jared: Yeah, I do that on paper, but I, I think that would be nice to have that, that system, uh, online, you know, into

[01:21:11] Dillon: I really like being able to just like quickly drop ideas in. And for me, like I'm so much. Like, I, I resist writing on paper, but you got to know yourself and, and if paper works well for you and you don't resist it, then absolutely. Paper systems are great too.

[01:21:28] Jared: cool and the other pics,

[01:21:31] Dillon: Uh, yeah, I also wanted to mention a book called Nonviolent Communication by Marshall Rosenberg. We talked about the idea of, external concepts of morality and judgments versus what you want to achieve. And, um, so actually that book has really influenced me in that, that frame of mind.

[01:21:56] Um, that's sort of the basic idea. Is it the, to me, the core concept is, um, you know, are that it's not very useful to judge people. But rather we should judge how actions affect us. So it's a reframing of that. And I've actually found it to be like a surprisingly relevant frame of mind in open source software, in collaborating with people on software projects in mob programming and things like that.

[01:22:35] It just, and it's, I mean. To me the term nonviolent communication is actually a bit of a misnomer because it's it's not about communicating It's about how you frame things internally.

[01:22:47] Jared: Internal communication.

[01:22:49] Dillon: Yeah, exactly exactly like are you thinking about things as like that's that's wrong. That's messed up Are you like hmm that didn't Like that didn't feel good because I wanted this so it's just a way of reframing that I've found to be very powerful

[01:23:10] Jared: Cool, yeah. I'll have to check that out. I haven't read that one or, I think I've heard that title though. So, yeah, that's, that sounds neat. It makes me think of Stoicism and what I read in there about, Um, people's actions and it does, I guess it has a sense of morality, but it's, it's all based on what I think, you know, what my virtues are, what I think to be the, the, the good things for me to do are mine and only mine and someone else's is theirs.

[01:23:41] And if they do something that appears to wrong me, they're really only wronging themself. Um, you know, and, and that I have to have compassion for that because I also. I'm guilty of that. You know, we come from the same place. We've, you know, we all make mistakes and, and to recognize that. And then to look at kind of the, the, what you said, like reframing it and what they use is the term of, you know, what's in my control.

[01:24:05] So, you know, you talk about, you know, they're, they're wronging me. Well, I can, I can change the way I look at that. You know, maybe I could say, you know what, maybe they're not wronging me. What's the, I think in silver lining and basically everything I do. So it's like, how did, um,

[01:24:21] Dillon: Right.

[01:24:24] Jared: Um, and that's really only changing the way that I look at it, but that's what I have control over. So, uh, and when I think in that, then it, uh, yeah, it definitely, um, creates peace internally. So I think, you know, in terms of like nonviolence, like it's that you're not combating yourself in a way, um, and how you think.

[01:24:43] So, yeah.

[01:24:44] Dillon: Yeah, I, I definitely find it to be more peaceful, like, and to me it's so much easier to say, instead of saying, hey, you should read this book, you know, which is like, okay, like I should, it's like, hey, uh, if these concepts sound interesting to you, you might really enjoy this book. It, I, I know it's like, seems subtle and nitpicky.

[01:25:07] But it actually is kind of like, Why should, why should I read this book? It's like, if, like, If, if you have this goal, and this concept resonates with you, then I believe this would be a good way to fulfill that need. But, like, if it doesn't, then why should you read the book? If that doesn't sound interesting to you, right?

[01:25:27] So,

[01:25:28] Jared: yeah, yeah. Subtly is important. I think it goes back to what we were talking about earlier, the seeds of the Elm community with Evan and Richard and thinking deeply and thoughtfully about a solution and, you know, and thinking about having these principles of, you know, user experience and taking responsibility for that.

[01:25:46] And, and, um, and how you communicate, uh, ties in

[01:25:50] Dillon: Exactly. And even how we communicate about everybody should use Elm

[01:25:55] Jared: Hmm. Mm

[01:25:56] Dillon: like, Hey, if, uh, if you think that using like types, pure functions with like guarantees about their types, sounds interesting, then check, check Elm out. It's really good for that. You know,

[01:26:10] Jared: Yeah. Yeah, for sure. Right on.

[01:26:14] Dillon: and I, I had one last pick, which is, um, there's a talk. Yeah. Uh, by Llewellyn Falco and Woody Zuhl that is, for me, like encapsulates a lot of these, um, ideas about technical practices that I've kind of learned over the years from, from the sort of software craftsmanship world. Um, the talk is called Practical Refactoring and it's just changed my mindset about, um, is the point of.

[01:26:49] Um, is the point of refactoring, like, do you, do you understand the code so that you can refactor it, or do you refactor the code so that you can understand it? I've started to do more of the latter. I've realized that actually, if you're making simple, boring, guaranteed refactoring steps, ideally with tools that can do them for you in a guaranteed way.

[01:27:18] But even with small steps and support from a test suite in a green state, not making changes in a red state, things like that, if you're using that approach, then you can actually just start massaging the shape of your code without needing to understand it. You can just say, well, here's like a blob of code.

[01:27:37] I don't know what it does, but it seems to do something, but I'll understand it better by massaging it out into a function, which. I can do, it doesn't change the behavior of it. And with Elm, it's a lot easier to know that this blob of code isn't going to have different behavior if I extract it from this function to another one.

[01:27:53] So yeah, I really recommend that talk.

[01:27:56] Jared: Yeah, that is a great one. Thank you for sharing that. And actually, uh, you would ask, or I'd asked you in an email, uh, about, you know, some resources and

[01:28:06] Dillon: Oh yes. Right.

[01:28:08] Jared: Yeah. Yeah. Um, and I've, I found that really valuable

[01:28:11] Dillon: Yeah. Yeah.

[01:28:12] Jared: yeah, that's, that's great. Um, So, yeah, I don't have a pick today, but I do have an ask of the Elm community.

[01:28:22] And what I'm asking is if there's anyone that's working on climate change, um, please reach out to me. I would love to have you on to talk about your work and, you know, get anyone else involved in it. Uh, this is the first time I've, I've asked this, but I feel like kind of to your point at the beginning of this episode about, uh, you know, doing things You see as a goal in the future, not getting the immediate feedback, you know, you may not, you know, like you don't eat junk food because you know how it's going to make you feel in 30 minutes.

[01:28:54] Like right now, the weather here is beautiful. Um, you know, uh, but climate is a long term view of that. And And so I think, um, yeah, if there's anyone out there that is, uh, is using Elm in a way that can help, I'd love to have you on. We can get, you know, the community involved. And I know people in the community have talked about this with their packages.

[01:29:13] You know, if you have issues that are related to that, uh, you know, they'll prioritize that work. But I will definitely prioritize that as, uh, as a voice, as getting that voice out there. So however I can help. Please let me know. You can, I'll put a link in the show notes, but you can email me elmtown@jaredmsmith.com. Yeah. All right. Well, thanks Dillon for coming downtown.

[01:29:37] Dillon: My pleasure. It was so much fun. Thank you, Jared.

[01:29:40] Jared: You're welcome. Y'all come back now. Ya here.

[01:29:45] Dillon: Will do anytime.

[01:29:49] ​