[00:00:00] Jeroen: find a way to, to work together. With or without those rules. So one thing that I really like with Elm, and which I think applies with this as well, is that it is pretty easy to try out things

[00:00:14] Jared: Hey folks, welcome back to Elm Town. I'm your host, Jared M. Smith. We'll be visiting with Jeroen Engels today.

[00:00:21] Sponsored by Logistically

[00:00:21] Jared: But first let's talk about our sponsor, Logistically. At Logistically, we make intuitive software for logistics industry to help logistics professionals make better decisions and spend less time on manual tasks.

[00:00:34] From quoting to tracking, our transportation management system helps squeeze every drop of efficiency from logistics teams of all sizes. Logistically pays me to record Elm Town episodes, as well as pays for our production and hosting costs. We build the front end for all new features in Elm. If you're interested in our mission and enjoy writing Elm, please drop us a line elmtown at logisticallyinc.

[00:00:55] com. I'll put a link in the show notes.

[00:00:58] Introducing Jeroen Engels

[00:00:58] Jared: But now, let me introduce Jeroen. Jeroen Engels is the creator of elm-review, a static code analysis tool for Elm. He is also the co-host of Elm Radio with Dillon Kearns, who is on "Elm Town 61 – Turning the pages with Dillon Kearns". Jeroen is the maintainer of elm-syntax.

[00:01:17] He occasionally dives into performance optimizations and security concerns. He talks about Elm techniques on his blog and at conferences. He's created several elm-review rulesets, including elm-review Common, elm-review Documentation, elm-review Simplify, elm-review Unused, and many more. Jeroen, welcome to Elm Town.

[00:01:41] Jeroen: Thank you. I already had a little tour and I really like what you've done with the place. Like, uh, lots of trees, nice bike lanes. I like it.

[00:01:50] Jared: Oh, thank you. Yeah, yeah, well, you know, we're always trying to make the town a little bit nicer for the folks that stop by. And hopefully, they'll stick around. Ha ha ha!

[00:02:04] Jeroen: me to start living here?

[00:02:06] Jared: Yeah, yeah, of course. I mean, this is Elm Town. This is for the Elm folks.

[00:02:11] Jeroen: Yeah, I mean, like, if I wouldn't be living here, then who would? Is this a ghost town?

[00:02:18] Jared: That's

[00:02:19] Jeroen: Yeah, I never thought about it that way.

[00:02:21] Jared: Yeah, yeah, you can't just stop by and then head out of town. You know, you got to stick around. Who are the neighbors?

[00:02:31] Awesome. Well, now that we've done that, let me ask you a question.

[00:02:37] It all started with a book

[00:02:37] Jared: How did you get started in computing and programming? Let's go way back.

[00:02:40] Jeroen: All right. Yeah. Let's go way back. Um, so I started in the eighties. My dad had a Commodore 64. And I played with that. No, that's just a joke. I was born in 1990. Um, but it's just, so many people, like, when they tell their story, like, It's the Commodore 64. It's always the Commodore 64, just a variant of it.

[00:03:02] Um, but no, um, yeah, I was born in 90. I, when I was 18, so in 2008, I thought I was going to do economics or trading, not, not, not financial trading, but, um, e commerce, but without e commerce, that's how you say it in French at least. Uh, so, um, and I noticed that I wasn't interested in that, uh, right before I finished high school. So it's kind of lost as to what to do. Um, and my father bought me for my birthday, uh, C++ for dummies, because he thought, well, you know, you're always on your computer playing video games, maybe this could be of interest to you. And, um, I started reading it and it was actually really interesting. Uh, I really enjoyed it. I stopped right around, uh, the chapter around pointers, which yeah, in hindsight made like, yeah, of course. Of, of course. You just stop there. Um, and yeah, that was, that was interesting. So a few months later I started studying computer science. I. Um, at a university that I continued on for five years and right out of the bat, it was something that I really enjoyed doing, uh, mostly programming. Um, that's something that I've felt very comfortable right away with. So anything that had to do with programming, even very low level languages like assembly. Uh, that was fun to me and I did some, uh, short projects like implementing small video games, uh, like, uh, four in a row in a turtle. That was fun to me.

[00:05:01] So, you know, when you, you're interested in something and you, you feel like you're good at it, then you do more of it and then you get better at it. And, well, I continued doing that until now, so that was like 15 years ago. Ah, I feel old now.

[00:05:21] Jared: Hahahahaha,

[00:05:22] Jeroen: Yeah, almost half of my life has been living with programming already. Wow, yeah, yeah. When you put it that way.

[00:05:32] Jared: yeah. You're experienced.

[00:05:36] Jeroen: yeah, I guess.

[00:05:37] Jared: Okay.

[00:05:39] yeah,

[00:05:40] and

[00:05:40] Jeroen: it got started.

[00:05:41] Jared: so you got started by Messing around on the computer and then getting a little nudge with a C++ book up to pointers.

[00:05:51] Jeroen: Uh, yeah, I wouldn't say messing with it, it was just playing video games.

[00:05:56] And my father thought like, oh well. He knows computers now,

[00:06:00] let's let's get to the next level

[00:06:02] or the lower level,

[00:06:04] Jared: Oh,

[00:06:04] Jeroen: I guess.

[00:06:05] Jared: going deeper. Okay.

[00:06:07] Jeroen: Yeah.

[00:06:07] Jared: I like it. Alright.

[00:06:09] Getting a job as a backend developer

[00:06:09] Jared: So you got your computer science degree and then you said, Alright, I'm going to get a job.

[00:06:14] Jeroen: Yeah. I have to pay my bills now, which I didn't have back then. Um, but yeah, I wanted to have a job in computer science. I became a developer, a backend developer at a company called Dashlane, which is a Uh, password manager, which I really like, and I still use today. Um, and then a few months later, so, so, um, I was a backend developer.

[00:06:46] I was doing Node. js. So it was still like in the 0.10, 0.12 days of Node. js. So it was a long time ago. Um, and that's how it got started with JavaScript, uh, or actually CoffeeScript. Um, and yeah, that's how I got it. Um, Started with JavaScript and that whole ecosystem and all the future jobs that I had were around JavaScript until I started doing Elm, uh, later. And, uh, yeah, a few months later I got fired because I was not good enough. Uh, I always like to say that that was a good reason because I was hired. They were looking for a senior developer and I was just right out of college. So like, I've got a good excuse, but. Hey, I did get fired at some point,

[00:07:40] or during a trial period.

[00:07:42] Jared: that's their bad, you know, I mean, how, how would you say, okay, here's what we expect, and then, not really fill that, I, I don't know,

[00:07:55] Jeroen: Yeah,

[00:07:56] Jared: you didn't lie and tell them that, you know, well, I look young, but I'm actually, I've been coding for 30 years.

[00:08:02] Jeroen: I'm actually 52. Uh, no, but, uh, I guess they were expecting me to, to learn more and to bring more to more ideas to the table. Um, which in retrospect I can understand, uh, but also I was not living, um, so it was a job in Paris, but I was not living in Paris. So I had like three hours of commute every day. And that just sucked the, uh, the, my soul and I did not have any time for. Uh, learning more, uh, delving to what npm packages are there, or how do you do better CoffeeScript. Um, I also didn't have time to see friends, basically. So um, so I can understand why they, I was not as good as I, as they expected. But also like, yeah, maybe they shouldn't expect me to learn outside of work when you work 40 hours a week and you have three hours commutes a day. Still like the job, but um, yeah, that ended. and then I got another job, uh, doing JavaScript. Normal JavaScript, uh. Then, uh, mostly as a backend developer, again, with Node. js. And I got started with frontend a little bit, um, during that time, during the three years I was there. and that's where I really had time to, learn about JavaScript, learn about all the frameworks that, uh, people use, all the cool NPM packages. Um, and that's also where I, because I was there for a while. I was able to have the time to get frustrated with the quality of the code or recurring bugs or things that we shouldn't do and that we keep doing over and over again. Um, and that's why I got interested in like, how do we prevent all these issues? So some of my interests were around working with ESLint, which is a static analysis tool for JavaScript, um, and using that at work and figuring out like what kind of things can we use to avoid having these mistakes over and over again. And that's also around that time that I got started with open source. Uh, so mostly contributing to, uh, the ESLint community by making a lot of rules, I think I wrote like 75 rules over the course of a year, which is quite a lot. Um, although they were a lot simpler than the ones I make for elm-review today, because it was easier to be simple. Uh, but we can talk more about that later. Um, so yeah, like I was a bit frustrated with the quality and I got involved with open source and code quality tools. Um, and. Yeah, I spent three and a half years at that company. And then I moved to another company where we started using Elm. And maybe that's, I feel like that's, that's your usual question is when did you get involved with Elm?

[00:11:24] Jared: Right.

[00:11:25] Jeroen: at that next company. So if you have questions for the before Elm, that's now.

[00:11:30] Jared: Okay. Yeah, sure. Let's, let's do that.

[00:11:33] Senior: Figuring out what you're passionate about

[00:11:33] Jared: So you were frustrated with quality and it sounds like to me that you were starting to take on this senior engineer role, right? I mean, you were developing these qualities of expecting higher quality. Um, and, and. Expecting more of the folks and the code base.

[00:12:01] Right? So you can produce, I'm guessing, higher quality code, you know, at a more reasonable rate. Um, you want to elaborate a little bit more on that?

[00:12:10] Jeroen: Yeah. I never saw it that way. Like, that's just like, Oh, well I'm. I'm frustrated by the way that I write code and the way that others write code. Um, and all the problems we're facing, but I didn't ever saw it as a senior thing. I actually only became a senior, uh, at this current company, uh, where I'm at right now, and that also came out of the blue to me, like, Oh, I guess I'm a senior now, which

[00:12:39] Jared: How,

[00:12:41] Jeroen: um, 2021.

[00:12:44] So like after seven years of working full time,

[00:12:48] Jared: Okay.

[00:12:49] Jeroen: which you can say is a long time for computer science and also like that's super quick for other disciplines, like seven years of experience and you're a senior. What happens when you're 30, when you have 30 years of experience, like super

[00:13:07] senior level 45? I don't know.

[00:13:10] Jared: right. Yeah. I think, um, You know, you're expected to code for a few years and then become a manager, right? That's, that's, uh, that's the route that a lot of people take. Or become a entrepreneur or something. You know, like, people expect something else at some point. But, um, I definitely like the, uh, the engineer path where you continue on and, and continue to hone those skills and, and get closer to, So yeah, I'd say, I mean, I have no idea, you know, what an average time to whatever name in a role. I imagine that has also a lot to do with like what company you're at.

[00:13:57] And just the timing at that company if you're starting early, you know some folks maybe their first job is CTO because they just right out of the gate said, Hey, I'm starting a company and this is my title. I get to pick I'm gonna be what I want to be so

[00:14:11] Jeroen: Yeah. I'm a junior CTO.

[00:14:13] Jared: Yeah

[00:14:15] Jeroen: Makes sense, I guess.

[00:14:18] Jared: Yeah

[00:14:20] Jeroen: you could say that that was kind of becoming a senior, whatever that might mean. Yeah. As you said, like, it means different things from, for different companies. So, uh, but it's definitely a path forward to, to care about that kind of thing. Actually, just like the more things you start to care about, the more experience you get and the more valuable you become, right? So if you care about, uh, a nice UI and you start developing those skills, then that gets you closer to a more experienced developer. If you care about accessibility, also, if you care about code quality, also. Yeah, I guess in a way you could say that a junior is just someone who has not found what they're passionate about or what they're, uh, really good with.

[00:15:15] Jared: Yeah, I like that sure let's roll with it

[00:15:19] Jeroen: And that is now the title of this episode.

[00:15:24] Using ESLint to solve challenges with JavaScript

[00:15:24] Jared: So, yeah, so at this point, you've felt these frustrations of writing code in CoffeeScript and Node. js, and did you say at this point you'd done some frontend

[00:15:41] Jeroen: Yeah, I started doing some frontend, uh, at the end, but mostly logical things, not making things look pretty at all. So basically, basically it was starting to be really good at JavaScript, um, but not necessarily HTML and CSS, and I'm still not very good at that, I'd say. Um, I know how CSS works now, so that's an improvement.

[00:16:07] Jared: Can anyone really say they know how CSS works?

[00:16:11] Jeroen: Some claim they do, some claim they do. And I will give them the benefit of the doubt as long as they can do something faster than I can, which is not super hard.

[00:16:24] Jared: I learn it, and then forget it, and then relearn it, and forget it, and relearn it, and that cycle continues on and on. I assume forever, um, until I no longer have to think about it, but maybe not.

[00:16:39] Jeroen: Yeah. So either switch to Elm UI or switch to backend.

[00:16:44] Jared: Yeah, yeah, that's right.

[00:16:50] Okay, so, you're having these challenges, these frustrations. Maybe describe... Some examples of what those might be.

[00:17:00] Jeroen: Things like, Oh, well, there's a straight console log in the code base. Like that shouldn't happen or, um we keep having crashes because there is a variable that is not defined in the codebase. Stuff like that, or... So that's where you put in the basic ESLint configuration and then all those issues get reported for you. Um, and then you start to have a few custom problems that are not covered by... Uh, ESLint out of the box. So I remember for instance, um, one issue that we had where we had, um, we had something called a context where we put a lot of, um, basically all of our shared data, like keys, database, uh, and. the current user and all those kinds of things. And we, we had one object holding all the data and we were passing it around to all the functions that needed something from it. And I remember that at one point we had a console log, uh, Where we passed in the context. So we did console. log, some string, and then context. And, uh, that meant that whenever we ran the code, uh, in production, the context would be logged and our, uh, we, we had a logging system. So all the logs went there,

[00:18:45] Jared: Hmm.

[00:18:45] Jeroen: there were private keys in there, private keys to the database and all those kinds of things, meaning that people who had access to the logs, but not access to the production things. Well, now they had those, right? So, what we decided was, uh, We don't want this to happen ever again. So, we allow console. logs, because actually we did, because that was useful for some of the things. But you're never allowed to do a console. log with context. Because otherwise, you... Just, you're just shouting out all the secrets to the production code base. You don't want that. So, um, I remember that, um, because I started having some, uh, experience writing ESLint rules, I made a rule against that. And since then we haven't had that issue or I haven't heard about them having the issue. So that's where I noticed like, Oh, custom rules, they're pretty good. People should have that more often in their codebase.

[00:19:56] Jared: Okay. Nice. So you were motivated to build this custom rule based on this console log of context just spurting out the private information of your system. So, yeah, that makes sense. That seems like a reasonable thing to do. It seems reasonable that it would only make sense in the context of your company, right?

[00:20:19] Jeroen: yeah, I had a few others, but I don't remember what they were.

[00:20:23] Jared: Sure. Yeah, and

[00:20:25] The refreshing experience of discovering Elm

[00:20:25] Jared: so, You're going along, you're making 75 or so ESLint rules, and then, at some point, you discover Elm. What was that like for you?

[00:20:37] Jeroen: Yeah, um, that was refreshing. Just a nice experience. Um, so I don't remember exactly how I discovered it. It was probably like so many other people like, uh, Dan Abramov, uh, who made Redux for React. Uh, said, oh, well I was inspired by Elm. So I look at Elm and then find all those Richard Feldman talks and I look at those and, oh, that looks interesting.

[00:21:07] And follow the guide and look at that. That looks pretty good. Um, I started going to the Elm meetups in Paris. So that was around 2016 and that was cool, uh, but I didn't use it, uh, in production or at work at all until 2018, right after 0.19 started, uh, was released. Um, but yeah, when I discovered it, uh, I wanted to build something with it to, to play with it. And at the. At the end of 2016, beginning of 2017, um, uh, I built something with it, which was elm-lint, or the precursor to elm-review. Basically, elm-review is my ongoing project, and that was also my first project. So the reason was like, Elm is a language for the frontend, and I don't know how to do frontend. So let's not do, let's not do that. There's one thing that I know quite well, and that is linters. I had not built a linter, but I had built a lot of linter rules and I understood how they worked. Um, so I submitted a, a small linter, uh, just in the browser. You, you paste your Elm code in a text area and it tells you all the problems that are with it. All with um, air quotes, um, for those who are not viewing the YouTube video, because there's a YouTube video for this. And the experience of building that was really nice. Um, even if I had to build the linter myself. Um, mostly I'm thinking about building the, the rules. So, because you had, um, all the custom types and all the safeties around that, like exhaustives checking and, uh, you can't access things if things are Maybe without checking, uh, whether they're Just or Nothing. And that, that felt really nice because I remember that I built... A few ESLint rules where I thought, um, well, in ESLint rules, you, you say, okay, well, whenever I see this kind of constructing in a. In JavaScript code, so let's say a variable declaration, you say var a equals something. And all that data is untyped, or at least it was back then. Maybe you have TypeScript types for that since. And I remember that I assumed that some properties were always there. So for instance, if you have var a equals something, well you have equals something. And Well, if you assume that that's going to be there, then you're going to, uh, access those fields and you're going to do operations on them. And if they turn out to be null or undefined, then all of ESLint crashes because one rule made a mistake on one part of the codebase. And I remember that I built a few rules where I made such a mistake, um, like the var equals something. Uh, well, the assignment is... Uh, optional, so I crashed something and we noticed this at work because we ran my rules as well at work. Um, easy to fix, but still, and when I built it with Elm, it was like, that's not a problem anymore. If there is a field for this AST node, well, it's always going to be there. And if it's a Maybe then I know it's because the Elm compiler will tell me. So whenever I'm done writing the rule, it's not going to crash. And if I forget to handle a kind of AST nodes, well, the compiler will tell me. And it's just like, well, this is a lot easier to write rules for. Like there's all the compiler guarantees. And also know about all the AST nodes, which are a lot less, uh, there are a lot less, uh, for Elm than for JavaScript because Elm is a very simple reduced language and that just felt really nice. Uh, so that was for Elm 0.17. Um, and well, I, I left it at, at, uh, at an experiments. I, I did talk about it at, uh, an Elm meetup, um, in Paris, uh, which was recorded but never published. So I, I never saw it again. Um, and, uh, yeah, so that, that's, uh, stuck with me.

[00:26:13] A greenfield Elm project

[00:26:13] Jeroen: And then, in 2018, I looked for a job, uh, for a new job following the one that I mentioned before. Uh, and there, there was someone at the next job too, that was also interested in Elm and Haskell and functional languages. And, uh, we had the option to, to start a new project. And we're like, what do we, what's tech stack do we use for it? And we're like, well, we could try using Elm and that's what we went for. And, um, that's where it got started with Elm professionally. So that was, uh, a month after 0.19 was released. Uh, so October or November, 2018. Um, and the experience was really nice. Like even, uh, I was acting kind of like the most senior, uh, developer on that project, and even though I didn't know CSS and it was actually like pretty CSS oriented, um, website, or at least something that had to look nice. Well, um, I was able to, to make it quite well, even though, yeah, I didn't have much, um, experience with front end languages, was nice.

[00:27:39] Jared: Excellent. Okay. So, you start a new project at work in Elm after having done the Elm Lint tool, right, after building that, and you're having a nice experience. Do you get this project into production at some point?

[00:28:00] Jeroen: Yes, um, we got, we got it after three months or something, but there were a lot of problems around that, like, uh, um, in, in practice, the, the, the website is still alive today, but it's written in React

[00:28:18] Jared: Mm hmm.

[00:28:19] Jeroen: and I rewrote it from Elm to React.

[00:28:22] Jared: Ah. How's that feel?

[00:28:25] Jeroen: It was actually fun to do because it was just a lot of refactoring, which I quite like, and like, how, how do I make this project and how do I set it up? How do we do things in tiny steps? And that was nice. Uh, but the decision to go from Elm to JavaScript or to React, uh, wasn't really nice. There were a lot of circumstances around it, um, which resemble a lot of what, um, Kevin Yank,

[00:28:55] Jared: Mm hmm.

[00:28:56] Jeroen: We said, uh, during your episode with him, uh, so basically like we had another team that was doing a lot of React and they were investing in like a, a component library and all those kinds of things. Um, And we were still like, it took us like three months to, to release a new project, uh, because like priorities changed and because we were like, well. We're doing a new project, but we don't know if that project will, uh, will stay alive. Not even for technical reasons, just like, will this work? Will this new idea work? If it doesn't work, we'll just throw it out. And then we have no Elm code at work anymore. So then we don't care about Elm. We don't want to invest in it until we've proven it and we have something sizable. Um, so at the same time, there's this other team that is heavily investing in React. Uh, and then the other person who was with me, uh, who was very enthusiastic about Elm, left the company, and then we got a new CTO who was afraid of the, the bus factor, uh, because Evan was the only one working on Elm. And I, for other unrelated reasons, also got, uh, quite mad at the company, which is why I'm not mentioning the name at all. So, like, when they said, like, we're gonna stop Elm, I was like, okay, well, now I just have all the reasons to find something, to find a new job,

[00:30:32] Jared: Yeah, okay.

[00:30:36] Jeroen: And that's when I found Humio, um, which is where I'm at right now, except that it got acquired by a company called CrowdStrike, so I'm now working at CrowdStrike.

[00:30:47] Jared: Right, and the product's called LogScale now, correct?

[00:30:50] Jeroen: Humio has become LogScale.

[00:30:52] Jared: Were you... Introducing Elm when you started this project?

[00:30:56] Jeroen: Yeah, this was our first, well, the company's first project written in Elm.

[00:31:02] Jared: Okay.

[00:31:03] Jeroen: Um, so I had to pitch Elm before that. Uh, I watched Richard Feldman's talks, uh, to get inspiration. Um, and that worked. People were like, okay, let's try it out. If it doesn't work out, if we don't like it, then we're going to switch to something else. Um, but... Yeah, overall, people liked it. there were some concerns about like, uh, from junior developers. Like, "can I, what happens with my career if I only do Elm?" "Can I move to another company?", and those kinds of things. So there were plenty of reasons why they wanted to move away from Elm. Uh, which sure makes sense.

[00:31:48] Um, but also like CrowdStrike, we're using Elm and we're like, yeah, this, this works just fine. Like we're happy with it. No issues, no issues recruiting, the app is pretty stable, so yeah, it's a, I think if you want to find problems, you'll find problems with Elm.

[00:32:11] Jared: Yeah, yeah, I agree. And, so, you're continuing on, you're building this, were you working with anyone else at this point when you're starting out this product? I assume you've got a team

[00:32:25] Jeroen: Yeah, we

[00:32:26] were usually teams of three people, uh, like one backend engineer, um, and two frontend engineers, two frontend engineers, including myself, um, and the teams kept switching. So, I was the only one who stayed on that project the whole time and, uh, the other people kept swapping every three months, which was not really nice, but how things were.

[00:32:56] Jared: Okay, so that's when you're starting out and you're the consistent piece of that puzzle on the front end.

[00:33:04] Starting elm-review

[00:33:04] Jared: Uh, at what point did you decide, okay, I'm going to start building elm-review again?

[00:33:11] Jeroen: Mm. Yeah. In that project, we had, um, a few places where we defined, um, shared things or common things. I remember for instance, we had a module to define all the colors because we had, we had a design somewhere. And it said, use these colors and these colors only. and we, we decided to only use these colors from that color module.

[00:33:36] So every new color needs to be added to that module and then, uh, referenced in the other places of the application. And I kept seeing, uh, new colors being defined in the rest of the code base. So not what we agreed upon. Uh, maybe that was like, uh, people forgetting that was people switching, uh, teams. And I was like. I know of a tool, because I've worked with ESLint, where I could just have a tool look at the code and say, this is not correct. This is not how we decided to do things. Um, and that is called a, uh, static analysis tool or linter. So there was a tool called elm-analyze, uh, back then. So, We just started using Elm 0.19, or 0.19 was just released, I mean. And elm-analyze was still working for 0.18, it was not ported to Elm 19, so we couldn't use that. But we couldn't use that anyway for this problem because it didn't support custom rules. So I was like, I still have an old project called Elm Lint somewhere in my backyard, let me try to... to... take that and build a linter, because like I already have like half of the project already, uh, elm-analyze still doesn't support 0.19, it got it a few months later. Um, and yeah, I was like, okay, let's build a rule that says you can't define any colors, um, outside of this module. And. I mean, I just knew that that would solve the problem, uh, a problem, which is about communication, but constant communication, which is what a linter is good for. So yeah, that's, that's where I felt like. Yeah, that, that's where it could be useful. And that's, that became the, the start of elm-review. Um, a few months in, I was like, I want to quit this company now because I had a lot of issues with it. Uh, and Elm Europe 2019, uh, is coming up and there'll be Richard Feldman and maybe I, I should work at NoRedInk, so maybe I should have something to show. Richard, uh, so I started working for like, uh, the entire month of July or June or whatever, um, to prepare elm-review to be in a showable state. Um, and when Elm Europe 2019 arrived, uh, Richard made a talk and that might be his only talk where he didn't say we're hiring because they stopped hiring at that point.

[00:36:33] Jared: Ah.

[00:36:34] Jeroen: Sorry, I didn't go to NoRedInk, but at least I had a good, uh, thing to show, uh, some people, um, which a few months later, uh, was released as elm-review,

[00:36:48] Jared: Awesome. Yeah, so that would be the silver lining, right? Like you found this motivation. That still allowed you to release elm-review and then you continued on, working there and I

[00:37:05] assume

[00:37:05] Jeroen: now.

[00:37:06] Jared: over four years. Yeah, so, I mean, that sounds like a win.

[00:37:11] Did you build custom rules particularly for your company as a way to sort of dog food elm-review and gain feedback? How did you go about that process of introducing elm-review and getting feedback and building it out?

[00:37:31] Jeroen: Yeah. Um, so I knew what use case case, what use cases I had at work. Um, but it, the initial release of elm-review was like a few months, a few weeks before, um, I switched the code base from Elm to React. So there was not a lot of, uh, use in elm-review anymore. So the, the idea was to dogfood it. Uh, in practice, uh, it wasn't dogfooded at all.

[00:38:05] Jared: Okay, so just so I understand, this was when you worked at the company before you, before Humio. Okay. Yeah, I gotcha. So you're going back talking about that, and then when you came back to start working on elm-review, right, you changed the name, you kind of re released it. Tell me more about that process, about starting that and getting that going and all those fun things.

[00:38:37] Jeroen: So I released it as Elm Lint at some point just to, I think. To try it out. Uh, so it's not just on my machine anymore. Um, I had a talk with Evan, uh, saying, Hey, I have this tool that I want to release. Um, are you okay with it? Because I was pretty afraid, like, I know the potential of a linter and I was afraid that people would build a lot of, uh, nonsensical rules with it. And, uh, there was a big fear I had, like, because. Just opening Pandora's box, uh, so I was wanting to let Evan know and he said like, I'm okay with it. Um, I actually still don't know if he, he's tried it out, uh, since. Uh, but he was just like, well, we should probably rename the, or the name is not great because Lint is not a great name. And, uh, I have looked it up since and yeah, it's not a great name. Like, do you know what Lint is or?

[00:39:42] Jared: Um, Lint to me is what I pull out of my belly button.

[00:39:46] Jeroen: Yeah, exactly. Uh, which for someone who's, uh, who's, um, first language is not English. Like, no, for me, a lint or linter is that tool that we use for JavaScript. Um, um, so yeah, it turns out lint is exactly like those pieces of fabric that you find in your belly button or in your pants and, uh, technically linting is the accumulation of those. Whereas you would say that when you're linting your codebase, you're actually removing them, so that doesn't fit.

[00:40:28] Jared: Yeah.

[00:40:29] Jeroen: Yeah, that's like the opposite of what you want.

[00:40:31] So like, the name is actually not very good. So I prefer saying Static Analysis Tool for Elm, rather than Linter for Elm. But it is a bit long. People understand Linter better.

[00:40:45] Jared: Sure. If they're in the right context. Right. Yeah. If you're coming from, uh, someone who already has experience with linter tools or static analysis tools in other ecosystems, oftentimes, yeah, the, the term linter, uh, will ring true for them, but yeah, for others. Um, that may be confusing. So yeah. Okay. So Evan suggested review, Elm

[00:41:11] Jeroen: he suggested Elm Project Review,

[00:41:14] which I was like, that, that's a bit long. Let's stick with elm-review. And yeah, now I'm happy with that name. And that one stuck.

[00:41:23] Jared: Nice. Okay.

[00:41:25] Jeroen: And then yeah, I was just trying to get it released one way or another. I had a talk with Richard at Elm Europe in 2019 where he said, something along the lines of, the author of a tool or of a package is responsible for the experience of, of the tool, uh, which I took to heart and that led me to spending two additional months working on elm-review before releasing it. Uh, and that made it into a tool that was quite nice. Uh, so that was in September of 2019, I think. Um, and

[00:42:06] elm-review v2

[00:42:06] Jeroen: in practice it was not used at all. Um, like I was able to build three rules, uh, only for the tool, which was like the no debug rules. And unused variables. I think that's it. And it was not the unused variables like you know it today, which catches unused imports. And the reason why is because the tool was only looking at one file at a time. And that was very, very limiting. So I spent like 6 months working on elm-review v2, where I had support for looking at multiple files. And that's the elm-review that you know today, that's elm-review, which knows about your entire project and which is now a reliable, uh, tool, um, that people know and love and that I do too. And that I really enjoy using.

[00:43:09] Jared: Excellent. Yeah. And so, yeah, I remember you wrote a blog post, correct? On jfmengels dot...

[00:43:17] Jeroen: net.

[00:43:19] Jared: net. Yeah. About this, when you... Added Multifile Analysis, correct? Yeah. Cool. Yeah, so I'll add a link to that in the show notes.

[00:43:33] Middle names

[00:43:33] Jared: I have a question for you. This is kind of random. We'll just mix it up a little bit here. This came to me.

[00:43:38] Jeroen: Spice it up.

[00:43:39] Jared: I assume the J is for Jeroen. What's FM?

[00:43:44] Jeroen: is for Jeroen, F is for Franciscus and M is for Maria, which are my second and third middle names.

[00:43:55] Jared: Awesome.

[00:43:56] Jeroen: Or, yeah, in French and Dutch you would say first name, second name, third name.

[00:44:03] Jared: Okay, yeah, or I might say, you have two middle names, right? Yeah, okay, so

[00:44:09] Jeroen: well, now that we're here, what does your M stand for?

[00:44:13] Jared: mine is very boring, it's Michael.

[00:44:17] Jeroen: Jared Michael.

[00:44:19] Jared: Jared Michael, that's right, yeah,

[00:44:21] um,

[00:44:24] Jeroen: For some reason, because my parents are Christian, and like, okay, well, gave Latin names in the Netherlands. Yeah.

[00:44:33] Jared: okay. Cool. Well, now that we got that out of the way, I'm going to mix it up a little bit more.

[00:44:40] Humor, coding, & podcasting

[00:44:40] Jared: I'm going to ask you a question from Dillon, Dillon Kearns, you may know him.

[00:44:45] Jeroen: Rings a bell.

[00:44:47] Jared: Rings a bell? Okay. He said, this is a question from him to you. You used to publish comics at postitontheweb dot tumblr dot com. How does your humor influence your coding and your approach to podcasting? End quote.

[00:45:07] Jeroen: I would say it doesn't. So yeah, I did have a blog where I drew comics at the link that you just said so if people want to check it out, go ahead. It is basically I have a post it and I have a pen and I draw something funny On them, and that's, that's it, like, they're one panel, uh, comics, um, and they're drawn kind of like Cyanide and Happiness, uh, comics, or Explosum, I don't, don't know what they're called exactly anymore, uh, so they're very simple comics because I don't know how to draw very well, uh, but the humor was in my mind, so I let it out. Uh, that's actually kind of when I think I started getting funny. Before that, I was very un, very uninteresting. Uh, now I'm okay. Now, now I, I'm able to make a lot of jokes to make my girlfriend laugh, which I really enjoy doing because that's a very lazy way of making her happy.

[00:46:16] Jared: Yeah, okay.

[00:46:18] Jeroen: Um. And I wouldn't, I would say that has not impacted my way of writing code because I don't put any puns in my code at all. Um, and when I'm recording a podcast with Dillon, I try to stay serious, like, like in the, in my usual, uh, life, I would say I make a lot of puns. But I tend not to do those on the podcast. So I'm usually funnier outside of the podcast. Um, for this recording, I prepared a few jokes, like about the Commodore 64.

[00:46:59] And,

[00:46:59] but, uh,

[00:47:01] Jared: nice. Okay. So you were making these post its and then posting them on the web. I feel like, you know, already we know what kind of humor we're going to get, but, but, but you're keeping the, um, keeping this out of your code and out of your approach to, to podcasting in, in your, in your view.

[00:47:27] I would say that if nothing else, your sense of humor allows you to make those jokes available, if that makes sense. Right. Like in, in the similar way that I like how when you are and Dillon are talking on Elm Radio and maybe Dillon's talking, he's ex explaining something and then you ask a particular question that is, seems aloof, although I already know that you know the answer to this question.

[00:48:04] You're asking the question to guide the conversation in a particular way. So it's very, you know, useful in that. And I think that approach also works for, you know, comedy in the podcast as well. Um, and I would say that maybe it's not humoring, but the fact that you write elm-review rules, you're guiding the way that other folks look at their code, right?

[00:48:36] You're, you're inviting them to observe it in a different way. So I think, you know, if you look at it like observational comedy, if that's, if that's your stick, you know, and, and some puns and things thrown on, thrown in, then, then that, you know, could tie in outside of outside of Post it on the web, which is, I looked through, I don't know, at least 75, at least as many ESLint rules as you've written.

[00:49:02] I've looked at those Post it on the web

[00:49:07] comics,

[00:49:08] Jeroen: there's like a hundred or something. So

[00:49:10] you went through most of them.

[00:49:12] Jared: yeah, it was a good time. Um, so yeah, I think that maybe not directly, but maybe indirectly, it may have some influence there. So, um, cool.

[00:49:25] Jeroen: Well, I feel like recently, because people keep saying that we're funny somehow, or that our jokes are funny. Um, recently I feel like we're trying to have a little bit more fun or to, to give more leeway to funny conversations. Um, whereas like at the beginning of our podcast, it was more like, well. I will try to have something educational, uh, and so I'm going to be more focused on delivering something to teach.

[00:50:00] Jared: Right.

[00:50:01] Jeroen: But yeah, now we're just like, okay, let's, uh, I have an idea, let's throw it out there. And if that's a good joke, good. If it's a bad one, let's joke about that one.

[00:50:13] Let's joke about how bad it was.

[00:50:15] Jared: Okay. So, then,

[00:50:19] Challenges with building elm-review

[00:50:19] Jared: let's get back to... elm-review, right? That's, that's what, uh, ultimately we love talking about here. Um,

[00:50:26] Jeroen: I always do.

[00:50:27] Jared: What challenges did you have with building elm-review?

[00:50:32] Jeroen: I mean, there were plenty of things to do. Like, um, when I look at, uh, some parts of the code base, I'm like. Wow, I wrote that thing? I didn't even know there was a concern anymore. Like that has totally left, uh, left my memory. I would say like just the technical, um, perspective of, um, technical feature of looking at multiple files and keeping that to be efficient. Uh, that was challenging. Improving the performance has been very challenging. Uh, and it's something I've worked on. Uh, several times and over several batches, like I remember, I think last year I improved the, um, fix mode's performance by like 13 times and it was like very needed. so yeah, I feel like performance is mostly what is, uh, complex. Um. Then there's just like trying to get the, uh, the right message out in the documentation. Um, so a linter, in my opinion, or at least since I've released it, is a tool to enforce some communication in a way, in a project. Like, you could replace, um, the linter by having someone on your team dedicated to the same task, where you could say, well, every pull request that comes, uh, through a code base, you look at it and you tell the engineer, um, whether, whether, whether there was a problem or not. And well, people have to respond to that well, so there's a, there was a lot of. I wouldn't say research, but a lot of exploration around how do I communicate an error correctly. How do I make sure that people understand, uh, the problems that they're seeing? How do I communicate, um, me as, uh, as the author of elm-review, how people should configure the tool so that they don't make any mistakes, because I have seen a lot of people misusing, uh, linters, um, in the JavaScript ecosystem with ESLint, like just taking someone's configuration, and putting it into your projects, and then complaining when it starts complaining about something you don't care about. Uh, so those are things that I really didn't want to, uh, to encounter anymore. And so far I feel like it worked out pretty well. Um, yeah. There's a lot of, um, communication concerns, uh, with elm-review and that kind of tools. And especially because in this ecosystem, we have this, um, mentality of, we want things to be just fine, just right. We, we spend a lot of time making the experience very good and handle as many edge cases as we can think of. So definitely there was a lot of work. Working around, uh, communication and having a good documentation. Um, and I think like the documentation for elm-review is like one, one, of the largest ones, uh, out there, like just the review rule module is super huge because it, it has like, uh, Here's why you would use this function. Here's an example where you would use this function, where I basically build a very tiny, but a whole rule, saying, well, you could use this function this way, with this rule example. And also, like, plenty of advice, like, if you want to report an error to the user, you should do it like this. You should have, you should give these pieces of information, you should name your rule this way. Because that's, that way you get, uh, the best kind of communication possible. So a lot of things like that.

[00:54:55] So yeah, communication.

[00:54:59] Jared: Okay, yeah, and your documentation is pretty epic, and I love that though, because those examples are oftentimes where I start, if I'm writing an elm-review rule. Of course I look at the documentation, but then I take that example as a starting point, even if my, I know my rule won't be anything near that, that example at least gets me started.

[00:55:25] Right? Um, and so yeah, I was pairing with somebody at work on, uh, some static analysis that we were looking to do on the, the project. And so we were writing a rule. And it was his first rule, and the first time that I had paired with somebody and, you know, trying to write an elm-review rule. And so definitely, you know, when we came to documentation, I was like, all right, let's look here.

[00:55:49] Okay, look, this, you know, here's an example. Let's copy this and, and try this out and go from there. So that really helped to, to move things along, keep things going when without that, you know, I might have spent a lot more time trying to figure out what to do. So, yeah, I think that's, that's worthwhile.

[00:56:07] Jeroen: Yeah. Yeah. I would just say like, the only downside is it's pretty hard to navigate maybe. Because it's like one giant page. And if I had like a dedicated website. I would order things differently, or split things up differently. Um, but that's like the only downside, otherwise I'm very happy about the documentation.

[00:56:31] Jared: Yeah. Yeah, that's fair. And you talked about that recently on Elm Radio, right? I think you talked about that specific

[00:56:40] Jeroen: We talked about documentation recently, and we talk about elm-review quite often.

[00:56:45] Jared: Yeah, I think you were talking about how... there are a few limits with the way that the package documentation allows you to, you know, you kind of can add some links and things, but, but ultimately, yeah, it's not like if you had complete control over how you design the, the documentation, but okay. Yeah. So, um, cool.

[00:57:07] I'll add a link to that in the show notes. Um, so your challenge is, is communication, you're taking from what Richard said about taking responsibility for user experiences. Right.

[00:57:23] Jeroen: could also add to that just, um, you know, that elm-review doesn't have disable comments, right? So if you have an error and you can't just ignore it. Uh, well, that puts a lot of pressure on the rule author, which is usually me. At least for my rules, it's me, uh, to, to get the, the rule just right. Like the design of the rule has to be right and the, what it reports has to be correct. And that's a lot more work than, um, I did in JavaScript, where I was just like, Oh, well, the delete operator is bad. Let's just make a very, very simple rule. That forbids any usage of that operator. And we're done. In Elm, that doesn't float as well because like every operator that you have, like makes sense in some context or every, every, piece of syntax makes sense in some context. So you have to be a lot more subtle. Uh, about your rules and finding the right balance is really hard. Like I just made a rule, um, right now, which is like moving all the data arguments, uh, to be the last argument because in Elm, um, functions usually take the, the data type as a last argument. And I want to enforce that. And it turns out I can't find a design for this rule, so far, uh, where it works just well, just well for all the cases. So in this case, I think I'm not going to publish this, this rule, unless I have a breakthrough. And that's just something I have to live with. Like, well, we won't have a rule for this and that's fine. And that's not something I would have done in ESLint. I was just like. I would have just been like, well, here's the rule. And if you don't like, uh, there's like an instance where it doesn't make sense. Just add a disable comment. You're good. So it's a lot harder to design rules as well.

[00:59:28] Jared: right. Yeah. You just released a blog post about that, correct? On your blog.

[00:59:33] Jeroen: Uh, no, but by the time that this episode airs, probably.

[00:59:40] Jared: Yeah, there we go. Okay, no, I'm thinking about the one with imports and no unused imports or no unused functions and it now checks if it's only used in tests and will

[01:00:00] allow you to delete that if you so choose.

[01:00:02] Jeroen: Yeah. That's

[01:00:03] again, a case where, well, we have to design the configuration to, to to accommodate the user as much as possible in order to avoid these disable comments. So yeah, like a lot of the design for that new thing, uh, was about like, how do we configure exceptions, which, or to, to remove the false positives and how do we make sure that there are as few false positives as possible?

[01:00:35] Jared: Yeah. So you're putting in a lot of effort and the result of that effort is higher quality, fewer rules, and

[01:00:47] Disable comments

[01:00:47] Jared: another thing that I want to get back to this idea of not allowing disable comments because I think you have a particular thought on that and I want to get to that but one of the things is that you have also written in the documentation how people should go about enabling or choosing whether to enable that rule at all.

[01:01:16] And so I think that is... Something that I believe in your GOTO Copenhagen 2022 talk, why don't you, "Why You Don't Trust Your Linter", I believe you mentioned this. But that's one of the things that is not often found in other static analysis tool ecosystems, correct?

[01:01:38] Jeroen: Yeah. Um, usually there's no documentation that says why you shouldn't reuse a rule. Only why you should. In a way, explains when you shouldn't, but doesn't always do it correctly. And I have not seen a linter that says when to use disable comments or when to use warnings. I think ESLint added a section on when to use warnings recently. Uh, which was a bit, uh, surprising to me, which is, they say, well, you should use warnings for the things that you want to fix later, but that you, like, just as a temporary thing,

[01:02:22] which is absolutely not the way that I understood it when I use ESLint for years.

[01:02:27] Jared: right. Yeah, so there is a little bit of communication going on there with the, the ESLint community. And this might be because of course you gave this talk in 2022, GOTO Copenhagen. And one of the other main points that I believe you were making was about disable comments and how elm-review doesn't have them and how that has affected the tool and the ecosystem around it.

[01:02:58] Do you want to elaborate on that a little bit?

[01:03:00] Jeroen: Yeah, so the first reason why I don't have disable comments is not the one that I mention usually. It's because of elm-format. So usually when you have a disable comment, you put it on the same line. Uh, or at least the, the way that, um, it was, it is done in ESLint is on the same line that there's an error. You say slash slash ESLint disable and then the name of the rule. Uh, I think ESLint disable line. Yeah. Um, um, maybe, um, or you put one, uh, comments on the line above and you say ESLint disable next line. And then the rule name. And the reason why that doesn't work for Elm is because elm-format moves the comments around. Uh, so it actually makes it a little bit tricky to, to put the comments where you want them and to have them stay there because of elm-format. So that, that was like my main reason not to have disable comments in the first place. Um, and I noticed that elm-analyze also didn't have, uh, disable comments. So it was like, you know what, let's try it out and, um, see how that goes without them and turns out. Pretty good. Um, turns out there's a lot of other things you can do to, um, to not need disable comments is: one, you can build a higher quality rules. Two, you can choose not to have a rule. Uh, like even if it makes sense in some cases, if there's too much pain, if there's too many false positives, then you really need to, to weigh the trade off between benefit and pain that it brings you because it is painful. Um, and then there's the suppression system that elm-review introduced, which was really nice because like very often, like, uh, I want to disable something because, right now, I need to move fast, or I want to enable this rule and I have a thousand errors and I want to suppress all of them. Well, I can add disable comments, or I can use a warning level. And, uh, well those don't work very well for several reasons that I outlined in the talk. So yeah, there are better alternatives to disable comments, is what I believe. And honestly, it has worked really, really well for, for Elm, or at least in the context of Elm. I don't know if it would work as well for other languages. Um, I'd be curious to know, because as far as I know, no other languages have tried it. Um, yeah, there are a few linters out there that don't have disable comments as well, but there are also, they tend to be... Just code style linters. So in a way like, um, code formatters, but without the formatting or sometimes with the formatting. But there's also this distinction between, uh, a linter for enforcing code style and a linter to, to find problems and to create guarantees. And I put elm-review more in the find bugs and create guarantees space than the code style one,

[01:06:30] because we have elm-format for 95% of things.

[01:06:35] Jared: Yeah. And I think you outlined this in the documentation about when not to write a rule, right? And, and that is included in there. So, yeah, that, that makes sense. Um, so, you were having challenges with the communication, right? And the performance. And then you, we talked about that. Then you talked about how disable comments were not introduced in elm-review, sort of just by chance, right?

[01:07:06] Because that wasn't already there. And then you observed how, by not having them, you found these other qualities of creating better rules and better communication. And so,

[01:07:19] Stopping the bleed

[01:07:19] Jared: You mentioned suppression. And I wanted to talk about that a little bit because that was something that allowed me to introduce elm-review at Logistically, initially. When I was first looking at it, I wanted to turn it on. You know, I think what you mentioned earlier about a static analysis tool being communication. And the alternative being, you know, feed all the pull requests through this person and then, you know, that person is the, the source of, of communicating all those things.

[01:07:56] Well, that of course was me, right? That, um, and so I was so excited to, you know, be released of this, this burden. Um, but when I first looked at it, this was before suppression rules. Or a suppression feature for rules, so I, you know, would enable something and be like, Oh man, that's going to take a while.

[01:08:18] Like I can't really justify working on this for several hours to fix all of these issues. I wanted to deprecate things, you know, suggest a different, uh, solution, right? Like this is where we're moving toward, even though we have like this, let's say, a Util module, right? That gets a whole bunch of stuff in it.

[01:08:37] We want to move this into things based on their types. Is one of the things that I like to enforce, but as a rule previously, I wasn't able to kind of get started, but as soon as you release the blog post, Stop the Bleed, right, which great title there, um, and, and then, you know, release that tool, that additional feature, for suppression. Then immediately I was able to go in, okay, this is deprecated, this is deprecated, add some, you know, add some documentation in there, you know, when you see that deprecation, you go to that module, you can read, uh, go over here instead, right, or, you know, explain the idea behind that deprecation.

[01:09:25] So that was great.

[01:09:27] And I think That, yeah, the alternative being, let's say, warnings, right? Like, if all those things were warnings instead, obviously that would become noise. Or, in my mind, that would become noise. Maybe other people would be able to continue to endure that and look through them and see additional ones.

[01:09:46] Or maybe build some system on top of it. But, with the suppression system, it does all this. It handles it. And if a new one is introduced, then that's when it lets you know, Hey, you know, this... is a new instance of this deprecated thing. We're trying to get away from that. At least fix one of these, right, in this file.

[01:10:07] And you might end up fixing more. You know, usually what I would do is, as soon as I encounter one, I'm like, Oh, well, I'll just fix them all in this file. That's my goal for today. You know,

[01:10:16] Jeroen: that that was the intent.

[01:10:17] Jared: Yeah, and then, you know, it's, it's better than it was, and it's definitely not worse. In my opinion. So, um, so that was nice.

[01:10:27] And then I get the, you know, the kind of, um, calm joy of, of not having to, to do that myself. Right? To, to enforce those things myself. Um, and I get my time back, which is huge. So, so thank you for that. And I

[01:10:45] want to,

[01:10:46] Jared's failure when introducing NoUnused rules

[01:10:46] Jared: I want to talk a little bit, though, about what kind of happened. After, I talked about this a little bit on the episode with Wolfgang Schuster.

[01:10:54] Um, so, that was all hunky dory, and then we had introduced, uh, another more experienced Elm developer as a contractor onto the team, and then I had, had a meeting with all of the full time engineers, and I had decided, you know what, I think we can introduce the time. Some of these rules. Um, And I was like, here are my concerns.

[01:11:25] You know, I think if we're working on a feature and that feature is incomplete, we're doing feature toggles to allow this to go out incrementally, you know, that's something we may have to handle where this might be a pain. Is this something that we're willing to accept? Everybody on the team that was in that call was cool with that.

[01:11:45] And I think when I originally described this to Wolfgang, I I didn't add in there that everyone on the team, except the one contractor who then later was like, Whoa, what is this, this rule? And you know, this is, this is causing, um, uh, problems with efficiency for me. And so that, um, was ultimately when those, those rules were disabled.

[01:12:09] Um, so... That, I think, is something I'd like to get your take on, as far as, like, how you might approach that, because I'm kind of to the point where now I'm, you know, I can run those myself behind the scenes, right, and fix those things, um, and that's, you know, that's okay. I'm not, if that's the worst thing that happens, it's better than... Having to do it all manually, you know, like if I go into IntelliJ or something and, and go to a file and then delete all the unused in a particular module. No, I can, you know, actually let it elm-review, fix-all of them that are here today and, and, you know, move on. That's, that's not the end of the world, but, um, just that, that experience was, I was kind of like, oh man, like I made a mistake here.

[01:12:59] I did something wrong in how I communicated these rules. I didn't communicate clearly enough to everyone. And I think you made a great point that, you know, if you're going to enable a rule, you have to be willing to disable it later if it doesn't work, and so that was something that I took to heart that you'd, you said.

[01:13:17] I was like, okay, you know, um, I feel strongly about this, but not so strongly that, like, I want to make it not a delight for other folks. Um, and Wolfgang had some, some suggestions as well, you know, about maybe enabling it for a particular, or um, configuring the rule to not enable that on certain folders, um, you know, and kind of pick and choose, um, create a strategy around that.

[01:13:44] So that's something that I will definitely look into. Um, and, so, yeah, I didn't know if you had any thoughts on that.

[01:13:56] Jeroen's tips on introducing rules

[01:13:56] Jeroen: So those rules are still disabled today?

[01:13:59] Jared: That's correct.

[01:14:01] Jeroen: So yeah, a linter is a means of communication, right. And enforcing something to always be true. So it, in my opinion, it is important that you convince that person or, and the entire team, um, in this case, the person. And, um, sometimes that's not easy. Sometimes they don't get convinced. So what you need to mention is, like, what benefits you get out of this. If we do this, then what benefits do we get? Um, of course there'll be some pain, um, associated with it, like even for the unused rules, which are pretty good, but there will be some pain. Like you can't write your code, maybe the way that you wanted, uh, where you have unused code and, uh, well, that's a price you have to be willing to, to, to use those rules. And if that bothers him, then he's in my opinion, uh, fully in his rights to, to mention it and to tell you that, uh, there's a problem and you need to, to find a way to, to work together. With or without those rules. So one thing that I really like with Elm, and which I think applies with this as well, is that it is pretty easy to try out things. So I remember the first time I worked with Elm professionally, I had a few juniors on my team and they were like, "Well, we don't know, we have a problem here, and we have two solutions in mind. We're thinking to go with this one, um, but there's also this other one that is possible." And me as someone who is slightly more experienced I know well, you're going for the wrong one. But the thing is it is pretty easy in Elm to undo something or to change something. So I would be like, yeah, I'm gonna tell you why I think you're wrong Or maybe I'm not even gonna tell them and but I'm gonna tell them like "go ahead with the, the, with your idea and re evaluate it in a while and tell me how it went and whether we should undo it or, uh, keep it." So that's something I really like with Elm, just like play with it, have fun. Uh, and if you feel pain, undo, re evaluate, think of another solution. And I think you could do the same thing with, uh, elm-review in this case is you could tell him, um, let's just try it out. Um, which I guess you did, but, um, maybe for other people, like, let's just try it out.

[01:16:56] Like, um, let's enable this rule always try to respect it whenever it tells you there's an error, try to, um, if it tells you that there's an unused, uh, function somewhere, follow its guidance and remove it. Um, if it makes sense and, um, well, if they just try it out. They will be able to say, well, actually, yeah, they were right.

[01:17:23] That, um, this was not the right way to do things. Uh, like you can do things in a more incremental way, which I think in this case is more like the problem there, they were building functions and not using them, which is, as we talked about on a recent episode of, uh, Elm Radio. Maybe the last one we recorded.

[01:17:43] So it will be out by the time this one is out. Um, we mentioned like, yeah, you should approach your, your way differently. Like you should build something and use it directly because that makes for better feedback and stuff like that. So maybe in this case, that's the way that, uh, you should tell them to, to do their job and if, if, if they're happy with that, okay, if they're not, not happy with, uh, changing their behavior. Let's re- evaluate, um, so if for some reason, like everyone on the team likes this rule, but he doesn't, he still doesn't, what you could say, well, uh, there's a suppression system, right? You could say, well, Uh, try to follow the, the errors and follow the guidance of elm-review. And if you really don't like it, if you really want to keep this unused code, then suppress it. The, the nice thing with the unused rules is they're not, um, a big problem. Like if you have unused code, there's like no impact on the user or there's only an impact on maintenance. And that's relatively minor. So in practice, like, I know everyone likes these rules and I do too, but like, they're pretty low impact in some aspects. So you could just, um, like, whenever you disagree with, with it, um, with the unused rules, at least, uh, just suppress it. But, because you introduced those things, it is technical debt that we can identify. There's a number in those suppression files. There are 5 unused functions and because you're the only one who suppresses those errors, well, we know it's you. So, it is up to you to sometimes, um, go clean those up. And from the way that I understand, the way he works is like... He builds something, uh, and he merges it into master, and then he uses it later. Well then, if that's the way he works, then those functions, um, will be used pretty soon. So, in effect, these suppressions will not last for very long, and there's no issue. So, that's probably how I would approach it. Um, try it out. If he's not happy, suppress the errors. which is fine for those rules. If there was a rule that was like very important where, well, if we don't follow this, the code will, will, will crash. Then you could say the same thing still, but every time there's a suppression, you, the person who would review the code would have to say, Hey, hey, let's, let's talk about this.

[01:20:52] Let's, let's see if there's a better solution. Um, and you can still have that discussion even for the unused functions. Um, yeah, I think that's the way I would approach it. Is that something you tried or does it sound like bad advice?

[01:21:08] Jared: I like that advice. Yeah, I have not tried that. I think to kind of generalize that it's giving tools, right? It's giving options to people. Um, and I think, yeah, I definitely could have done a better job of that, of like, here's how we are handling this today. This is why we can even introduce these rules, right, is because, uh, because of the suppression system.

[01:21:34] So giving that as a tool for folks who are, you know, maybe in the process of building something. And I don't think that applies to just one person. I think that could apply to multiple people. Um, just depends, like you said, on how folks work, right? Are you kind of following a, a test driven development, incremental approach?

[01:21:52] Or are you kind of building out, like, okay, I'm going to, you know, create some little I'm going to take I'm going to set them aside and then, you know, put them all together, right? And so, I like that approach. I like adding suppression. Another thing that I thought of is to make sure that folks know about fix-all.

[01:22:15] Because particularly with this one, um, it is a, a lot of those can be, you know, just automatically fixed, right? Just, you can just... Run it, and it will remove it, and then everything's hunky dory. Um, I love, I'm gonna add that, um, actually I'm gonna write that down right now. Um, Uh, and then, I think, The, the other thing that Wolfgang had suggested was enabling this in particular places, so you know, more of a, introducing the rule.

[01:22:53] Uh, incrementally, in different parts of the code base. So, um, that's, that's definitely a, a particular strategy that, that I want to try.

[01:23:05] Jeroen: Yeah, I would say that the suppression system does most of that job out of the box.

[01:23:15] Jared: That's a good point.

[01:23:16] Jeroen: But yeah, depending on the rule, that could make sense.

[01:23:20] Jared: Cool. Yeah. And then, here's another thing.

[01:23:24] When to run elm-review

[01:23:24] Jared: When do you have elm-review run?

[01:23:28] Jeroen: Oh, uh, ideally, always in your editor. In practice, they're the... IDE integration is not there yet. Um, it's not there in IntelliJ, which I'm using. Uh, it's not super fast in VS Code. Um, so I tend to run it when I think I'm done with the job, uh, or when I think I'll, I'll be, it'll be useful to me, like to, to clean things up. Yeah. Usually when I'm done with my pull request or something. Uh, and then for instance, if I Uh, if, if I notice, uh, there's some unused imports that were removed, then I try to edit my git history, um, to, to not have a fixed elm-review errors commit, which I really dislike, which is not a problem as well, but I don't like those.

[01:24:32] Jared: You're a purist.

[01:24:33] Jeroen: yeah. Oh, by the way, one thing, uh, to tell your colleague is all the things that were, uh, that were unused and were removed. Uh, if at some point they were merged into master, you can recover them through git. So that's also like, one thing to keep in mind.

[01:24:50] Jared: I have to tell myself that sometimes still, you know. I'm getting better, but, you know, when I see code, I'm like, Oh, you know, what if, what if we'll need this in the future? I'm like, oh wait, but yeah, it'll be in the history.

[01:25:01] Jeroen: I mean, I'm giving you this advice, but I've myself never looked back into the git history to find a function because no, I've never really needed something again. So, like, there's this YAGNI, you ain't gonna need it. Well, so far it's been true for all my code for the last three years, so, yeah.

[01:25:26] Jared: Nice. Yeah, I like that. So you run it before you finish your pull request. I assume it's running in CI then?

[01:25:34] Jeroen: yeah, uh, always run it in CI. Like if there's only one place where you run it, um, it's in CI. The second place is in your test suites that you run locally. and then, yeah, I run it myself. Um, whenever I do, I'm done with the progress, I run elm-review, fix, fix all, uh, whatever I feel most comfortable with at the time. Um, but ideally one day, hopefully it will be integrated into editors. Um, and I get the feedback all the time, but that day's not now and I'm not working on that right now either.

[01:26:13] I don't want to work on that. I'm still hoping for some people to take up that job. Hopefully one day.

[01:26:22] Jared: Okay. Well, it sounds like if somebody in the community is excited and looking to take something on, that might be a project to check out. Um,

[01:26:31] Jeroen: out to me. Maybe I can hook you up with people.

[01:26:36] Jared: Awesome. Yeah. And so if folks do want to reach out to you, I can put a link to whatever form you want that to be. in the show notes.

[01:26:47] Jeroen: Probably just the Elm Slack, jfmengels.

[01:26:50] Jared: Okay.

[01:26:51] Jeroen: I'm always there anyway.

[01:26:54] Jared: Awesome. One of the ways that I had ran elm-review and then it just, by happenstance, um, got removed was I have a, a watcher set up. So when you're running code, of course you can rebuild it and it uses elm-watch and it, uh, also, um, runs elm-test after it builds, but that was also running elm-review after, and then just as a, as a matter of, like, refactoring things, right? It was removed, and so that was my fault. And I'm wondering if it would make sense to add that back in. I haven't tried it yet, but of course, like you said, just trying things, seeing how it works, um, is a good route, um, but I didn't know if you have tried that, had any experience with it.

[01:27:48] Jeroen: To do what exactly?

[01:27:49] Jared: To run elm-review when a file changes.

[01:27:54] Jeroen: Yes, so there is a watch mode in elm-review. Um, yeah, I use that quite often as well. Uh, it's just that my computer at the moment is a bit slow, so anything that adds to that, uh, is not welcome.

[01:28:10] Jared: Yeah, yeah,

[01:28:12] Jeroen: But yeah, otherwise, like, otherwise, yeah, elm-review in watch mode and, and, or in fix mode. Um, I really like using that combination together. Yeah.

[01:28:26] Jared: So you can have it watch and prompt you for fixes?

[01:28:29] Jeroen: Yep.

[01:28:30] Jared: Nice, I haven't tried that combo.

[01:28:32] Jeroen: Yeah, and you can also run it with fix-all, uh, if you want to. Um, but yeah, it should... The reason why I don't run elm-review more often is just mostly because I don't think about it. Um, because I need to open a terminal to run elm-review and keep watching it, because, like, it only prompts you, so you need to watch that terminal.

[01:28:57] Um, and I'm mostly usually concerned about the Elm compiler, and that's it. Um, so that's why, that's why I would like to have it in the editor because there I would see all the errors.

[01:29:09] Jared: Yeah, that makes sense. Is there anything else you wanted to talk about before we get on to picks?

[01:29:14] Jeroen: I mean, I've already, I think, beat Dillon's episode in terms of length. So I think I'm gonna say no. I'm always happy to come back if you have more questions.

[01:29:27] Jared: There we go, I like it. Let's do that.

[01:29:30] Picks

[01:29:30] Jared: Alright, well, what picks do you have for us today, Jeroen?

[01:29:32] Jeroen: Yeah so the the first one I have in mind is SegaCAP, which is a Weird little URL SegakCAP, S E G A K C A P dot com, which is the reverse of packages, uh, which John Pavlik made and uh, is a tool to, um, find which projects use which dependencies. And turns out for elm-review, it's actually a really good tool to find all the review packages, which is actually like not so easy to find otherwise. So, um, cheers to John for making that. So if you want to look for elm-review packages, use that. I'm happy that it's there. Um, um, I also want to give a shout out to people who, um, who make Elm, who help make elm-review better through conversations and discussions. Uh, there's also lue and SiriusStarr on Slack who made a...

[01:30:41] A lot of elm-review packages and I'm really appreciative of that. Uh, I know this is not a thanks section, but it's like, well, you check out their, their packages, uh, and, uh, also check out the elm-review documentation. If you want to build a rule, that's like, if you want to, to get better, like that's probably the way to go.

[01:31:01] That's how you improve as a developer. Just make elm-review rules. I don't know. Um, yeah. Yeah, maybe that's one approach. I also want to, uh, mention something different than elm-review and the programming, which is, um, I really like manga, Japanese manga. Um, and there's one that, uh, stuck out to me, like, the last few years, that was, that is called Ajin, A J I N, uh, which is a story about, um, our human, our normal society, but some people are immortal and can't die. And I really like how they, um, push the idea as far as they can. Like, well, what does it mean if you're immortal and well, you get crushed or something, well, what happens then? Oh, and well, can we do something with that? Can we, what happens in this situation? Oh, what are the impacts on human society? If that, if this is true, what, and I really like those stories where. They take one idea and take it very deep. And this is a pretty good manga where they do this. If you have other, um, if some listeners have, uh, stories like that, I'm willing to open, talk to me on Slack. I want to know about those. Um, so yeah, that's my picks.

[01:32:31] Jared: Awesome. Yeah, and so, I just have one picks today that is the Software Unscripted Podcast. I don't think I've picked that before, but other than Elm Radio and Elm Town, it's the... other podcasts that I listen to. It's hosted by Richard Feldman, and he talks about Elm occasionally. Jeroen has been on there talking about elm-review, and, uh, other Elm folks have been on there.

[01:32:58] But, although it doesn't always talk about Elm, I think the principles, the mindset, uh, and of course, it's Richard who, if you have watched a lot of Elm-related videos or tutorials or books. They may be from Richard Feldman. So, um, so that's, that's, uh, something that you might want to check out if that sounds interesting to you.

[01:33:27] Other than that, I just want to say thanks to all the folks listening out there and please rate and share the show if you're enjoying it. And thanks, Jeroen, for coming to Elm Town. Ciao.

[01:33:40] Jeroen: Thank you.