Joël: A lot of my Elm, conference talks were based off of conversations I had in the Elm slack and in fact, Helping out in the Elm slack is one of the ways that helped level me up as an Elm developer very early on.

Jared: Hey folks. Welcome back to Elm Town. I'm your host Jared M Smith. We'll be visiting with Joël Quenneville today.

[00:00:19] Sponsored by Logistically

Jared: But first, let's talk about our sponsor Logistically. At Logistically, we make intuitive software to help logistics teams make better decisions and improve efficiency. 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, Elm Town at Logistically inc.com.

[00:00:39] Introducing Joël

Jared: Now, let me introduce Joël. Joël works at thoughtbot. He crafts software mostly on the web. He loves best practices, patterns, and functional programming. He has shared lots of knowledge with the Elm community, including blog posts like "Structuring Conditionals in a Wizard", "Modeling Currency in Elm using Phantom Types", and "Problem Solving with Maybe". Joël has been on Elm Radio 32 "Elm's Universal Pattern" and 52 "Category Theory in Elm with Joël Quenneville", and Software Unscripted "Conditional Cardinality with Joël Quenneville", he has given several conference talks teaching Elm concepts like "Rolling Random Romans" at elm-conf 2016, "A Number by Any Other Name" at Elm in the Spring 2019, and "Inverting a binary tree with one line of Elm" from Elm Online meetup in 2021.

Joël, welcome to Elm Town.

Joël: Thanks for having me.

Jared: Yeah, I am excited about it and I want to get into it. We're gonna talk a bit about pedagogy, about learning and teaching, but before we get into that too much,

[00:01:51] Getting started crafting software

Jared: I wanted to get a little bit about you, a little bit of your history. Why did you choose a career crafting software?

Joël: So my career into software was a little bit of a, almost an accident. I was working, uh, part-time as a wedding photographer and needed a website and stumbled across a tutorial to, that taught HTML. , I used that to build a basic website and really got hooked that like rush of excitement. I got, the first time I wrote Hello World in a text editor, saved an HTML file, double clicked it and opened it in a browser, which I, I didn't even realize that you could do things like that.

And then it, it showed up and the thing that I wrote showed up in the browser. Oh, that was amazing, the feeling of that. And so I've been chasing that ever since it turned into a hobby. Uh, and eventually I was like, you know what? This is what I want for my career. And, uh, went full-time into software.

Jared: Right on. Okay. So you had this experience, particularly with web development, so you got to see it in the browser, and so yeah. You said that you worked mostly on the web. I, I'm guessing that that was part of the influence of why you went that direction. Is that correct?

Joël: Yes. Uh, the web has always had a special place for me. That's something that I've really appreciated about, uh, developing on the web is how, uh, very quick the feedback cycle is. Something that I was able to get hooked on as a beginner, someone who didn't think of myself as like a, maybe the, the nerdy coder stereotype, uh, was that I wrote a few lines of code and then just immediately got feedback visually in the browser and that very quick feedback loop.

Uh. Really got me excited and it sort of helped sustain the momentum that allowed me to push through, uh, the really hard parts of learning to code.

Jared: Yeah. Yeah. I share that sentiment about getting that feedback directly and visual and, and getting that sort of dopamine rush of ex excitement about it that helps carry you through. So what were some of the struggles that you had early on, if you can remember back that far? I know it's been a while.

Joël: Yeah. So early on, uh, I was like entirely self-taught and I struggled to build programs that were more than a few hundred lines of code, uh, that would just sort of implode under the weight of their own complexity. And so I was pretty early on, on the lookout for, uh, what are the patterns that professional developers use such that, uh, changing code in one place doesn't cause five other bugs in another place.

Or where you can, uh, add new features and not break existing parts for the code.

Jared: Mm. Okay. Yeah. And so as you had this struggle getting started, writing larger programs, you're finding patterns, did that lead to understanding larger architecture or how did that flow for you?

Joël: It really did. A big breakthrough for me, I think was the first time I got introduced to Ruby on Rails. Uh, and they, uh, sort of codified the MVC pattern model, view controller, uh, in a way that I think I'd sort of, kind of stumbled into myself in some of my own work, uh, but hadn't encountered it explicitly specified.

And seeing that it was like, oh, that all makes so much sense. Of course, you would organize things in this way. Encountering TDD test-driven development was also, uh, really formative. The idea that you have a test suite that then allows you to, uh, fearlessly refactor or add new features and it'll help you find the places where your code is broken by the changes you've made, uh, or identify pain points where there's really tight coupling in your code.

All of those helped me evolve and grow as a better developer who could write software that was more modular, uh, more reusable, uh, more extensible. I could just grow bigger.

Jared: You mentioned that you were self-taught, but I noticed that it appears early in your career you participated in an apprenticeship, a formal apprenticeship program. What was that like?

Joël: Yeah, so I did, uh, kind of a little bit of everything I, self-taught, in high school. Uh, decided I wanted to, uh, pursue this as a career. Did a traditional CS, uh, degree, which I was a little bit disappointed with. I felt like I didn't teach what I was looking for. And then after that, uh, did an apprenticeship and that the sort of hands-on nature of things there was, uh, really impressive.

Uh, so I did a, it was a three month apprenticeship with Thoughtbot where I still currently work. And what they did is they would pair you up with a mentor for a month. Um, thought Bot is a consulting agency and so you'd work with your mentor, uh, for a month on their project, and the client is not billed for your time.

Uh, so you are able to work on a real project with the support of someone else, but you don't have the pressure of like, oh, I need to be shipping features and being productive. It's so that I'm worth the money that people are paying. , And then every month you switch to a different mentor. So you get to see three different projects, three different experienced developers, um, and within all that you have maybe a little bit of freedom to explore, uh, things.

So maybe you run into something, , where you would grow more by maybe not shipping the next feature for the client, but by, uh, taking some time to read some related articles to a, a pattern that you've run into or something. And so you had the time to do that, and that really helped kickstart my journey.

Jared: That makes a lot of sense. And so you had this hands-on apprenticeship. You said you did a one month mentorship three different times? Correct.

Joël: yes. It's a three month, , apprenticeship each month with a different mentor on a different project.

Jared: Okay, so you learn from various developers. Uh, were they at different points in their career, I assume?

Joël: Yeah, no, they were all sort of at different points in their career. , The types of clients were also different. I did some more backend focused ones, some more front end focused ones. Give you an idea of the era. This is when we were writing backbone js.

Jared: Yeah. Okay. I gotcha. Okay. And so it sounds like this was helpful, and also it sounds like the company, Thoughtbot, is really interested in growth, personal growth, career growth, in addition to providing value for clients. So you're having space in order to do those things.

Joël: That is one of the things that I really admired about the company and one of the reasons why I really wanted to work there. Uh, because they are known, particularly in the Ruby on Rails community for, not only a growth mindset internally for themselves, but, uh, a lot of sharing of that growth with the broader community.

And so, uh, before I went to work there, I had already used, uh, open source tooling that they had put out. I was a frequent reader of their blog. I listened to their podcast. , So there's a lot of growth that happened internally that they then shared back out to the community. And that was something that was really inspirational for me.

Something that I wanted to do.

Jared: Well, I can tell because you've shared a lot.

[00:09:37] Discovering Elm

Jared: At some point in your career you discovered Elm. How did that happen? What was that like?

Joël: Uh, it was an offhand comment by a colleague at Thoughtbot who was just talking about different mental models for working with code and had mentioned that he had dabbled a little bit in Elm and it was a little bit of a different way of doing things. And I went to the website, looked at the, like basic tutorial for it.

And I remember reading through that and actually, I don't even think it was a website at the time. I think it was just a Git repo. And I remember reading through the tutorial and me like, wait a minute, this is a game loop. The model view update pattern, uh, this feels just like a game loop. And that model really clicked for me.

And then I was able to try out some things. I've always really liked, uh, the idea of the interactivity that you can have on the front end, but I was also at a point where I was getting really frustrated with JavaScript. This is 2014, 2015-ish. A lot of the limitations of the languages were really annoying me and so, I'd stepped back from front end work and discovering Elm sort of brought me back into the front end and got me excited about the things you can do in the browser

again.

Jared: So you had been inspired a bit by the Ru Ruby on Rails framework, right? Learning MVC and then later you found this Elm model view update, MVU, if you will, or The Elm Architecture as we call it, uh, in Elm and found a pattern that was related to game development. But I think for me, certainly when I see, you know, these related patterns of model view and something, then I can at least gather some similarities, and sort of take some prior knowledge and bring it along with me. So what was the hardest part for you to learn about Elm?

Joël: I think at the time the hardest thing to understand about Elm was signals, uh, which is something that got removed from the language, um, as part of a simplification that Evan did. I think in 0.15.

[00:11:50] JSON Decoders, and then...

Joël: But I think beyond that, the next thing that was probably the most, uh, challenging to learn, uh, and it's probably one of the most challenging things to learn still for most people is, uh, JSON decoders.

Jared: Yeah. Yeah, that's good. I, I've been working on this joke related to JSON decoders, and so I'll try it on you first. We'll see how it goes. Uh, there are one of, one of one hard problems in Elm: JSON decoders, naming things, and currying, uh, so why are JSON decoders one of your favorite features in Elm?

Joël: I think that they've really helped me understand, uh, how untrustworthy JSON is. I get a better sense of what kind of data I'm working with and what are all the different ways that it can go wrong. Uh, in a way that I think previously having mostly worked in dynamic languages or languages that would allow you to work with, uh, unstructured data like JSON in a very haphazard fashion.

You just sort of assume, yeah, it'll probably be in the shape and I'll try get some values out of it. And it doesn't force you to think about all the possible ways things could go wrong. It also sometimes encourages you to have your internal modeling of the app mirror, the JSON, because you just use the raw JSON or turn it into a object in your language or whatever, in a way where everything mirrors one-to-one.

And the way that things are modeled for the transport layer with the limitations of JSON aren't necessarily going to be ideal for what your app is trying to represent internally. And so one of the big lessons for me was the idea of having a validation step, but also a transformation step. Define data structures that make sense for your app.

Uh, make that modeling mirror the problems that you are trying to solve. Um, make impossible states impossible, all of that. And then find some way to translate the JSON into that. Don't let the transport layer drive your modeling.

Jared: Yeah, I totally agree with that. That is something that I love about JSON Decoders as well, and so much so that even though we wrote some code to generate the base layer of, uh, integrity between our back backend and front end, so that JSON, we generate some decoders for it, I still made sure to require that you do something with that.

Now. I mean, you could choose like to do nothing, like do no mapping of that data, but it at least gives you an opportunity to think about, well, how do I really want to represent this in Elm because this is a sort of, uh, a primitive view of the data, right? Or this transport layer view of the data sometimes mostly related to what the backend's view of that data is, but how does this make sense in terms of our application, as you said.

And yeah, I find that to be crucial to having a nice Elm application on the frontend , because you need that to build out and use Elm's custom types and, and build rich data types as you go along. Any thoughts on that?

Joël: I think it's interesting that you mentioned that, uh, you do the transformation in two steps. One with an auto-generated thing, which I assume generates a, a record of some shape that matches the JSON and then some conversion from that record to whatever, uh, custom thing that you have. And I think oftentimes a lot of frustrations around JSON for people who are coming from other languages is the Oh, why can't,

Elm just auto parse json the way that, uh, other languages can. And the answer is that it already does, uh, under the hood. Uh, and if you've tried to re-implement your own JSON decoder library, you'll quickly realize that what happens is you have a string and not all strings are valid json. And so you need some errors for that.

And what the JSON library does automatically for you is parse that string into an AST that maps the JSON, and that's effectively what you get with other languages that just give you whatever comes outta the parser. What decoders do though is then they give you a safe way to read into that AST where there are no guarantees for anything.

Even reading a key in an object, uh, is not guaranteed because. Pure strings are valid JSON. Numbers are valid JSON, uh, and you might not expect that you might get that, but that will go through a JSON parser. And so what the decoders are really giving you is a way to effectively query that AST in a type safe way.

Jared: Yeah.

Joël: And so you are just adding like another level of transformation from that instead of a string to AST to custom type. Uh, you're doing string to AST to record, to custom type

Jared: Yeah, yeah, that's right. And we do have some types, some very simple INU types that we have on the back end that we can reference in the front end as well. So these generated modules, and that allows us to have one single source of truth on the back end and then be able to use that in the front end. But again, the way that we represent that in the application itself varies depending on the use case.

So yeah, we don't want to assume that whatever exists there, whether it's a record or these primitives or even the enums, are the end transformation or the end data type for the front end for Elm. So yeah, it's definitely a way to help with the integrity more than anything. I don't even, I mean, I find that definitely JSON decoders are a, a thing that is troublesome to learn at first and to wrap your head around.

But I think that it leads to being able to apply that same pattern in different ways. And of course, you know, you mentioned that you definitely had that challenge with JSON decoders, and you've written a lot about them. How did you go about wrapping your head around that concept?

Joël: So interestingly I tried to learn JSON decoders and kind of got stuck and I learned about them in a bit of a ran roundabout way, way. I was wanting to learn Elm, do some harder problems. And decided, okay, I'm gonna do a sample project This summer I just finished reading a book on Ancient Rome and I was like, you know, it would be a great idea.

What if I simulated ancient Roman politics in code? That would be a fun thing. I'm learning Elm. Let's combine these two things together. And the first thing I hit is, okay, I need a random number to generate random events. And oh, hey, how do you do randomness in a purely functional world? And that led me down a whole, side path.

But in the end, uh, I learned about Elm's random generators and how they work and how they compose. And I think I was able to really get a strong mental model. The, the way that they compose with things like map or map2 or, andThen felt, uh, very concrete to me. In terms of are you combining, are you just transforming a role to say, I have a random number and I need to turn that into an enum value?

Am I saying, Hey, I'm doing two independent roles, but I need to combine their, uh, outputs into a new output? Or am I doing two dependent roles, roll one thing, and then based off of that role another? So those all felt like very concrete use cases, and in my mind I was able to say, oh, that's map, that's map2.

That's, andThen, and so I got very comfortable using those to combine things together. And what's been really beautiful is that, randomness is not the only place where these sorts of things work. You have patterns like map, map2, andThen that work on Maybes. You have the same thing that works on JSON Decoders, although with some extra pieces. And so then I started asking myself, how are these things similar and how are they different? Um, and doing a little bit of reasoning by analogy. And so asking myself, well, for Maybes, which also feel a little bit more concrete, uh, what does it mean to do what's effectively like two dependent roles if you're doing a Maybe.andThen, and how is that different in the context of maybe how is that different in the case of, uh, JSON decoding? And that sort of reasoning by analogy is what eventually got me to understand the broader pattern. But in order to understand the broader pattern I had to learn in the concrete and the place where I was able to personally connect and really get a good sense for what was working was randomness.

Jared: Oh, that's great. I like that you mentioned random, because I felt like for me, doing a lot of work where I'd had to query the backend, get some data, or send some data to the backend, I was doing a lot of interaction with JSON decoders, and so I sort of had that as the thing that I had to learn first. And then when I encountered random.

I started to see those patterns and I was like, oh, okay. And it definitely reinforced decoders for me, but I felt like it, you know, it was a leg up for understanding randomness because I had learned how to do JSON decoders. So I think having to encounter some one of these concepts or these libraries, these modules and then carry those concepts to other modules that you use in Elm is, is great.

And you mentioned maybe, I think that's a, a great one. You have an example where you talk about Maybe in, you're sort of solve problem solving with maybe in order to unblock your and build JSON decoders through that analogy.

Joël: Yeah. Yeah. Uh, so I'm a huge fan of reasoning by analogy as a way to solve, uh, programming problems. Uh, when I'm stuck, can I find some smaller, more tractable problem that I can solve that's equivalent and then backport that solution to the place where I'm stuck. And JSON decoders can feel sometimes, well, they're a little bit more complicated 'cause you've got all like the fields and things like that, uh, and the types, but they're also a little bit more abstract.

They're values that you will have, whereas maybe can feel very concrete. You can unwrap it. It's not an opaque type. Uh, you can look inside them anytime you want. And so they're just a little bit easier to wrap my head around. And so what I would do is, transform this JSON decoder problem where I'm stuck into a Maybe problem and say, instead of trying to read these values from JSON, what if I were reading them from a bunch of optional fields? I just have a bunch of maybes. How would I combine them together to get the thing that I want? Uh, and once I have the right, the fancy term here would be combinators. Uh, so, andThen, or map, or map2, or some fancier combination of all of these. I can just convert all the Maybes into JSON and the, the same sort of structure of, andThen and map will stay the same.

Jared: I really like the way that you presented that concept and that analogy there. So I'll definitely have links to all of these blog posts for folks who are interested in exploring these further.

[00:23:57] Inspiration, artifacts, and note-taking

Jared: And so I wanna talk a little bit then about your process, about how you come up with ideas to write about or to give a talk about or to come on a podcast and talk about how do you gather that you have lots of blog posts and talks.

How do you find ideas to write or talk about?

Joël: So a lot of my ideas are grounded in, uh, personal experience. These things that I've personally struggled with were things that I've, uh, helped somebody else, uh, understand. A lot of my Elm, , conference talks were based off of conversations I had in the Elm slack where it was, uh, this is the fifth time I am answering this question for someone.

Th there's probably, uh, some value in turning this into a talk. Uh, and in fact, helping out in the Elm slack is one of the ways that, uh, helped level me up as an a Elm developer very early on. I started off just lurking in there and then answering basic questions that were basically just Googling documentation for people. But you do that enough times, you get to know the docs really well and have a really solid foundation of what's in the core library. You also get a chance to do things like, oh, I have a vague sense of like, how map and andThen work in Maybe and Random. Now somebody's asking a JSON decoder question or maybe they're asking a, uh. test Fuzzer question or anything else that uses that pattern. And you can try to see, can I apply what I know to this other situation? And every time you do that, you, you grow a little bit. And so that was not only a source of inspiration for speaking and writing, but also just a tremendous source of growth for me.

Jared: Yeah, so it was sort of an ad hoc mentorship. You sort of were in these Slack channels and you were able to help people along the way, and that turned into growth for you, it sounds like.

Joël: I'm a huge fan of, of helping others and putting artifacts out there into the world, whether they are writing, speaking, uh, test snippets or code snippets that you put up on a gist somewhere. Those all have, uh, a lot of value for the community at large, but really for yourself as well in terms of driving growth.

Jared: How do you turn those things that you see, those how you've identified one pattern here and now you're gonna use it over here. How do you turn those into works?

Joël: Yeah. Um, I found that, uh, some level of introspection is really value valuable for something like this. Uh, something that I've been doing for the past couple years is I have a pretty, um, sort of formalized system of notes. Uh, they're loosely inspired by the Zettelkasten system and the, uh, Evergreen Notes systems. The idea here is that, you have a bunch of, uh, relatively short notes. They call them atomic notes, so they have a single idea that you're talking about. And in my case, these are typically the title of the note will be thesis statement, something that I think is true about software, and then maybe a paragraph of text explaining why that is the case, and maybe a diagram or a code snippet. And then what these notes do is they are heavily hyperlinked between each other so that you can reference similar concepts. And then when you later come back and add a new note, you can plug into the sort of existing set of notes that you have and you're just sort of building this little mini, almost wiki knowledge base of things you believe about software.

Um, and so a lesson that you learn on one project or from one conversation might all of a sudden have a lot of relevance to something you learned a year ago. And making the connection between those two things might lead to another set of growth for you.

Jared: Okay. Yeah. So you're, you've taken these note-taking systems, Zettelkasten, and Evergreen notes. I've heard of Zettelkasten, but not Evergreen Notes. Could you explain that one a little bit, or both of them? For

Joël: Yeah. Yeah. So they're both similar to what I do. The idea of, uh, individualized notes, um, that are atomic and that link to each other. Um, they're just slightly different in terms of how they, uh, end up doing that. I think they're both a little bit more formal with some rules on how you do things. Zettelkasten in particular has a, like triage step.

Uh, so you'll have typically what they call, uh, literature notes. Uh, this was developed for people, uh, being involved in like scientific literature. Uh, so you're like reading a paper, reading a book, and you're taking notes on that. And those might just be bullet points or stream of consciousness thoughts. And then later on you go and you process those notes into what they call permanent notes, which are the little atomic things that link to each other. And part of that processing is you try to find existing notes in your vault that can connect to them. Um, and the idea is that that processing step isn't just an organization, it's actually forcing you to think about things and that that's where a lot of the growth can happen.

Uh, one of the big ideas from, uh, those two systems is that the value of writing the notes isn't so much in just the notes themselves. It's the connections that are valuable. Uh, being able to have two ideas and realizing there's a connection between the two is where oftentimes uh, the real creative idea generation happens.

Jared: Yeah, that makes sense. And so what tool do you use to organize those notes?

Joël: Um, I use Obsidian, uh, which is a note-taking system. It allows me to write notes and markdown. It has the facilities or the, the ability to, uh, link notes to each other. Um, it's relatively simple. I think the, the danger in going down the path of these note-taking tools, it, it's easy to obsess over the process and focus on finding the perfect system and the folders and the tags and all of that.

And then you never write.

Jared: Mm-hmm.

Joël: so I've kept it really simple. It's just a flat directory of, uh, just a bunch of notes. I keep them small, I link them, and I've not really put in, I'll occasionally put tags and things, but I don't really have a system for those. I've tried to let it grow organically and add more process as it makes sense. But the goal was to really just make sure I'm writing as much as possible.

Jared: Yeah.

Joël: Most of these notes are written in prose. Uh, I try not to do bullet point notes, um, because that forces me then to, uh, develop my thoughts a little bit. But they're small. I'm writing a paragraph.

Jared: So you said you'll do a thesis statement and then a little bit about that, and then like you said, maybe a diagram related to that. So you're, again, kind of building out this idea, but in an atomic way and then linking that to other things in your system. So let's say you're going in and you're going to, you, you've got an idea, you write it down, and then do you search through keywords from that note to try and find other ones to link to it?

Or do you already have in your mind the title of those others?

Joël: Um, I will usually it's a combination of both. I might know, oh yeah, I remember our writing about this last year. I might do a search. Obsidian also has a graph view where you can browse the entire, uh, note graph of like what links to what, either from a note or sort of globally. And so looking at that can help identify clusters of ideas.

And so I might just browse through that and find things that it can be connected to. I've also been able to leverage that view, uh, to help me find, uh, clusters of ideas that would be great to create more content about. So maybe it's conference season and I'm trying to think, what should I write a proposal for?

And I might bring up the graph view and try to find, uh, clusters of notes around a topic and say, oh, this might be a good, a good one. I've since taken things one step further, gotten a little bit fancier and added. Uh, I have a separate directory where I just have a note for every sort of public work that I've done.

So blog post or conference talk. And then links to all of the atomic notes that inspired it, that were sort of supporting material. And in the graph view, I have a query that colors those, uh, public works a different color from the atomic notes. And so now what I can do is look at my graph and see clusters and they'll have colored dots in them where I've already given a talk or written about the topic.

And so what I can then do is find what are clusters that don't have a colored dot in them. Those are probably high value for, uh, writing or speaking. And because I already have prose, I have diagrams, I have code examples. I can just copy paste these things into a slide or a, an article and it gives me already a skeleton of things, uh, such that I don't have that writer's block of looking at a blank page and being like, oh, I wanna talk about this topic that I don't know where to start.

Jared: Yeah, for sure. So, uh, a few years ago I started a note-taking system purely with note cards. So just four by six note cards. And what I really liked about that system was that the barrier to entry was really low. Like I didn't even have to be on the computer. And I would use it to, if I was reading a book, take notes in the side of the book, and then transfer those notes or quotes that I liked that I underlined, I'd put those into that physical system.

And kind of like what, like what you're talking about with seeing the whole graph is you encounter some things that you might not have even thought to search for or wouldn't be in that same relationship if you're doing it in like a directory, you know, of all these concepts related. And so you kind of drill down into it when you see everything there and you kind of are scrolling or you know, in my case, physically flipping through different cards.

I'm like, oh, I forgot all about that thought. And then, and then you say, realize, oh yeah, there is a relationship here and so you, I may might copy that card and, and put it into another one. Um, and so that was really nice for, yeah, just having these sort of ad hoc chance encounters with ideas that I've had in the past and then sort of being inspired by it to, to make connections.

Joël: What you're describing sounds a lot like the original Zettelkasten, which was developed I think in the fifties on uh, note cards. Was that an inspiration for you or did you sort of, uh, convergently, invent this yourself?

Jared: It was an inspiration. Um, I was reading Ryan Holiday's blog post about it. Um, he's a Stoic philosopher guy who, um, is kind of into self-improvement, but he, talked about his process and that was what he learned from his mentor Robert Green. And so I imagine it probably, yeah, was kind of handed down from that Zettelkasten, uh, system.

It's definitely the way that he explained it wasn't super formal, you know, you could have like little tabs of grouping things together and, you know, different boxes with, with cards if you wanted. But, um, not a whole lot of rules for. How to use it, which I liked. Um, because yeah, I could just kind of get started and since then I have started using Obsidian as well for linking notes and having a way to sort of see everything and search everything is, is pretty nice.

And that's also, yeah, like you said, once you've have an idea there, you can start to build out and, and take those little bits, those atomic bits and put them together pretty quickly and, and have something that is starting to make sense. A framework, as you said.

Joël: One of the things that really struck me when I was, uh, I read the book How to Take Smart Notes, um, which was sort of the, the genesis of this journey for me. And one of the things that they mentioned in there is that, uh, this, in this style of note taking, it's not about information capture. The value is not sort of, uh, writing down things to remember to just sort of store and collect it's, synthesis, it's idea generation.

That's where the value is. And so that's why the Zettelkasten system in particular, uh, encourages you to, uh, start by just taking down thoughts and maybe quotes and things. Just sort of like a scratch pad, but then there's a transformation step where you turn them into these atomic notes and sort of turn them into more complete thoughts, and that that is where in this system there's a ton of value.

Jared: One of the things that with the physical system, and I don't know if you can do this with Obsidian in the graph view or not, but you can sort of move those cards around and sort of place them together. Like, you know, you can make piles of cards by, by, um, physically, you know, laying them out and then reordering them.

And one thing that I've, I've used is, uh, Gingko Writer. It's how I, uh, organize the Elm Town podcast episodes. But I use it for a few other things where once I maybe have a more of a concrete idea and I want to sort of architect how those pieces fit together, I'll put it in there because it makes it easy to sort of drag and move and reorder things from, you know, this is the first idea and then go to the second, third.

I don't know if, I mean, Obsidian, obviously there is the graph where you can look at it, but can you interact and sort of, um, rearrange items?

Joël: Not so much. They have the idea of like tabs. So you can have sort of multiple notes open and you can reorganize and there's a like a classic tab view like a browser where you're just tabbing through. And then there's a, a more of like a stack of paper, uh, UI where you're sort of just stacking them one on top of another and flipping through them and those you can reorganize.

Um, but it's not quite the feeling of, oh, I have a workspace and I'm just moving cards around and maybe stacking some together. Um, in, I guess at that point it's three dimensions, right? Um, you don't quite have that.

Jared: Yeah. Yeah, that's true. That's a good point. But anyway, I mean, you know, we're talking a lot about the tools here, and so not to obsess over those.

[00:39:11] Active versus passive growth

Jared: You've written a bit about these, uh, this, this concept of, of sort of what you, your title for your blog post Turning Experience into Growth and, you know, active versus versus Passive.

Do you wanna talk a little bit about that blog post and how you apply these ideas?

Joël: Yeah, so this came out of a conversation I had with some colleagues around, uh, trying to keep growing professionally. Without necessarily having to do a ton of extracurriculars, are you, uh, condemned to plateau as a developer if you're not hacking every weekend? And so the question here is how can we keep growing within a regular sort of 40 hours a week, work week doing work on projects that are not always the newest tech or the most exotic?

And for me, the key thing there is that there's a lot of, uh, room for growth, in your experience, but you have to actively mine it. And I think that's why you often see that years of experience don't always correlate to how good a developer is. Someone can have spent 10 years doing something and still be pretty mediocre, and somebody else has spent five and they're like, amazing.

And part of what I think is, is that mining that experience to get actual growth out of it. So I, I coined two terms, passive growth versus active growth and passive growth. Just being the, like you keep putting in the hours and you'll just keep growing a little bit automatically without having to do anything.

And active growth being various things that you try to do, uh, typically with more of a mindful, uh, approach where you're trying to actually, uh, grow out of that experience. And, uh, one of the things that I've found that works really well for me is this note-taking system. It, you know, helps me to create content and stuff that I want to write and share to the world.

But even if I were not writing and sharing to the world, that note-taking system would still be valuable because it helps me organize my thoughts, it helps me synthesize my experience and understand why did I like or not like that choice I made today? Is there a broader principle that I can pull out here that I think could be applied in other situations?

Does this connect to similar experience I had last year or two years ago? And by slowing down a little bit, sitting with my thoughts, synthesizing and connecting, something that could just be a regular day's work has all of a sudden turned into some maybe like, uh, big professional insights.

Jared: That's great. So you're taking and building these, what you call artifacts, right? These notes and diagrams from your introspection and creating connections from it. And so do you build in reminders throughout the day to do this, or is it so automatic now where you say, oh, this popped in my head, I better go write it down right now?

Joël: It, it's more ad hoc. I think ideally I would have some sort of reminder or like set period of time on my calendar at the end of every day where I write like a, a lot of people do like a daily note or something, where you're just sort of writing thoughts that you had throughout the day. Uh, for a while I kept a daily, like TIL document today.

I learned just for, oh, random library ran across or coding concept or whatever. Uh, just so I could look back and be like, oh, I learned a lot of new things this week. I've fallen out of that practice, uh, because I focused more on the, uh, bigger picture ideas and like things that I could boil down to a thesis statement.

, And like learning a new bit of syntax didn't really fit in there. But that's an area that I'm looking at bringing back into my practice.

Jared: Okay, so looking at things in the small as well as in the large.

Joël: Yeah. And it doesn't all have to fit in my Zettelkasten system. Um, you know, you brought up the word artifact, which I referenced in the article. Uh, artifacts are sort of a broader term, uh, than just these notes that I'm writing. and so oftentimes what I'll do is I might, uh, try to, uh, synthesize some experience I had into, uh, a diagram.

So I'm drawing, uh, to try to better understand what I'm doing. And if I can communicate to somebody else visually, that means I have a better grasp of what's going on. And maybe that just turns into something that gets shared into a Slack channel. Uh, maybe then I'm like, oh, that's a cool diagram I should find if there's a thesis statement that I can tie to that.

Uh, but not always. It could be, uh, maybe it is just put out a tweet in the world. Say, Hey, here's a new bit of syntax. I learned. This is cool. It can be, uh, even something like, I looked at a couple of competing libraries and wanted to pick which one was best. Uh, here are the set of pros and cons I found for each and why I am recommending a particular one.

That's kind of a report that you would write. That's a valuable artifact too. Instead of just being sort of going on your gut and being like, oh yeah, you know, I went and looked at these things and then on a call or in Slack telling people, yeah, I looked at these things and I like this library better. Uh, taking the time to write that document, especially if you hold onto it.

Then if you hit this situation again, you can remember what the trade-offs were, why you liked that. Um, but also just cements it in your mind a little bit more. So I think there's all sorts of things that could fall under that, uh, umbrella of artifacts, uh, which can be totally private, you know, public, just your organization or like fully public on the web.

And all of those are ways of taking sort of a more passive role of just consuming and converting it into an active role. Now you're creating, you're synthesizing, and I think that's where the real, uh, power of growth happens.

Jared: Couple of things I wanna comment on there. So you, it makes me think of your talk at Elm in the Spring 2019, "A Number By Any Other Name", you said it keeps coming back to communicate, right? So as soon as you have to try to communicate an idea, for me, that definitely makes my brain start firing and thinking about things in different ways than what I might have as an intuitive knowledge of it.

Where if I just do it myself, fine. Right? I have some understanding of it. But to have to communicate that to someone else. It definitely levels up my understanding. And it sounds like that's the experience you're having as well.

Joël: That's exactly what it is. And I think that's why, uh, helping and teaching are such valuable resources for your own personal growth. I've definitely felt, you know, I have a topic I think I know, and then I try to explain it to someone else and realize that I'm like fumbling over my words and I'm like seeing the blank expression on their face.

And I'm like, now I'm just throwing metaphors at them and nothing's working. And that's when I realized, oh, I need to step back and like, can I explain this to myself? This is what my shower thoughts are like. I'm like, uh, I had this conversation the other day and I couldn't explain this properly. How would I explain this to myself?

What is the minimum information they need to know to like, get to a effectively a save point in their knowledge where they can then like, understand a little piece of it, they can digest it, then we can move on to the next thing.

Jared: That's a good point. And it makes me think, we were talking about these different places for putting artifacts or maybe a blog where you share information or a Slack channel where you share information. I feel like sometimes if I make that place, then I want to put stuff into that place, right? Like, I mean, it's easy to do on, on Twitter or Blue Sky or whatever, Mastodon, you're able to quickly fill that space.

But you know, with the physical note system, just having that box there is something that I now can fill up, right? It's like emptying your cup in order to fill it back up and, and I think that applies with a blog or a a Slack channel as well.

Joël: Yeah, finding those places where you can put things. And then the other part of it is if they are at least semi-public, you now get a response back. There's now an interaction, and now you're not just communicating sort of with yourself as you're trying to translate thought into written word. You are now having to communicate to another human who's going to respond back to you, and then you're going to respond back to them.

And so now you've sort of evolved beyond just note taking to dialogue. And I think that's also something that I've found has been really powerful for me. And I have a few people that I connect with on a monthly basis where, uh, we'll just have a call and we'll pick a, a theme for the call, a through thesis statement.

We take turns and, uh, then we sort of explore it through dialogue and like find the edge cases of it. , And that's been great for my growth as well.

Jared: You're taking ideas, these connections that you've made, and you're starting to synthesize them in real time, find holes in them, and have a, a conversation, figure out what's understandable, what's not. Like you said, those, those blank expressions and, and trying to, uh, resolve that.

That's good. There's this, I had mentioned Robert Greene before, and he has this idea of alive time versus dead time. And I think when you're actively working on and intentionally thinking about ideas and how to communicate things, I think that's part of that sort of aliveness and, and and being able to recognize, oh, this pattern that I was using with randomness now, you know, connects with this pattern in JSON decoders.

And actually, maybe it's easier if I simplify this down to Maybe all those things that you've done so well really, uh, show how intentional you've been with your learning and it, and it seems like through that process of being an auto didactic or a, you know, that self-taught person, that you have definitely learned to use those techniques very well.

So I appreciate you sharing those.

[00:49:47] Collect mental models and heuristics

Jared: With this is there anything that you wanted to talk about before we move on to picks.

Joël: I think something I would recommend to people who are maybe looking on ways to start with a system like this is collect mental models and collect heuristics. So you just mentioned, uh, the idea of like alive time and dead time. That's a mental model. That's a way to think about the world. And a lot of things will have sort of multiple different mental models, uh, that are just sort of different ways of different lenses through which you can view a topic.

And so oftentimes when you're really sort of meditating on a topic or trying to understand it, you might come up with different mental models. Maybe it happens all at once. Maybe it happens as you keep returning to a topic over various years. Uh, but if you one of those comes up and maybe it's a mental model that speaks to you but doesn't speak to others, that's okay.

But write that down. That's a great thing to start for your note-taking system. For example, I. You know, we've been talking about, andThen, and, uh, map2, uh, which in more formal terms, those are, uh, monads and applicatives. And I have a note in my system that says monads are serial and applicatives are parallel. Uh, a mental model that I have around that. Now it might, you know, a lot of mental models will break down. There are edge cases, but just having that as a mental shortcut that I can use to think about, uh, problems has been really helpful. And then maybe, you know, a year later, I am encountering them in a slightly different way, and I find a different mental model that lines up. And so, keep an eye out for those. I, I think we all generate them on a pretty regular basis. Metaphors, mental models, those are a great thing to write down in a note-taking system. And secondly, heuristics, anytime you have a sort of rule of thumb or a, you know, most of the time I tend to make this decision.

Uh, in these situations, uh, write that down. when, when do you tend to, uh, break down, uh, function or code into smaller pieces? When do you tend to abstract? When do you reach for a certain pattern? When do you like to take a particular solution? Those are all things which you probably have intuition. Uh, so the next time you're trying to, you find yourself just relying on your intuition to make a decision. Pause. Think about what is it in my intuition that's making me make this decision, and is it a sort of an 80 20 situation where you say, most of the time I do this and write that down as a heuristic. and so for me, some that I have around, let's say code organization might be, I tend to, uh, separate branching code from doing code. So if I have a function that has a conditional in it, uh, if else or a case expression, uh, the branches of those cannot have any actual code that does anything. They can only be calls to other functions.

And so a function's either purely dispatching or it can do things, but you're not mixing both. and you know, that has various organizational benefits, but that's a heuristic that I follow and sometimes I break it. But that's a rule of thumb. So I wrote that down in my, in my note-taking system and I realized that I had two or three of these around code organization that all kinda converged towards one place.

And that helped me sort of come up with this not very catchy title, but a thing that I called the Triangle of Separation, where I had sort of three of these heuristics that I felt like, oh, they're all doing the same thing, but viewed from different perspectives. And that again, was another sort of breakthrough in my, my mental model.

And so, yeah, I would recommend to people, uh, mental models, keep track of them, write them down, heuristics, uh, collect them, and you're well on your way to being a more, thoughtful person. And that'll help build the initial, uh, note-taking system if you're trying to get into that.

Jared: I love that. I'm glad you brought up what, uh, Andrew Lenards, uh, mentioned your Joël's triangle. He created a little pamphlet, uh, based on that to share with coworkers. So it's definitely been an inspiration for others and. And so yeah, folks out there, uh, who find this interesting, your work and your self-growth, self-improvement can be inspiring for others as well.

So yeah, definitely check that out and try those things.

[00:54:18] Picks

Jared: And Joël, did you have anything to share with folks? Any picks for us?

Joël: I am gonna recommend the book, uh, _How To Take Smart Notes _by Sönke Ahrens this is the book that started me on, um, my journey. I was having a conversation with a colleague about, um, how I'd been sort of doing these little artifacts, uh, that I was sharing in a Slack channel and my colleague's like, oh, what if you started like taking these mental models and things that you're sharing and like writing them down, here's a book you might wanna read on that.

And I read that and that was eye-opening for me. And so, uh, I would recommend, uh, How to Take Smart Notes.

Jared: I'll put that in the show notes. And it's, uh, definitely brought a lot of fruit to the community, so I'm glad that you were recommended that book and it's helped us have artifacts in the world to, uh, to learn from.

The pick that I have is a musician, Jesse Welles. He is sort of a folk guitarist, singer songwriter. Sort of Americana, if you will. But, um, I, like, I've been really into his music past few months. He talks a bit about sort of things that are going on, particularly in the West, in America.

And he has unique insights, I think, and kind of in the spirit of John Prine, if you've heard of him. Also a sort of American folk artist. But yeah, lots of stuff on YouTube. You can check 'em out there. I'll put link. I'll put a link to that as well. So yeah, thanks to all the folks who are listening out there.

Please rate and share if you're enjoying the show. Thanks, Joël,

for coming to Elm Town

Joël: Thanks for having me on.