Discovering discovery coding (Friends)

28:55But the problem that outliners often have is that they're unwilling to do that last step. They've come up with a solution. it's actually a bad solution but since they have the outline for it they're just going to finish it and maybe even they're going to ship it and then it comes runs into problems and they're just going to keep going and trying to fix it and fix it and incrementally change it and fix it and what I found is if you like kind of relinquish control a little bit you let yourself let the code tell you where it wants to go you're paying attention to the code itself especially in big complicated legacy systems like we talked about last time you'll discover solutions you just would have never thought so yeah that's what i i really recommend the practice because of that one thing it seems though just looking from the outside or hearing this story is that it seems like the practice of the basic outline which was the four different options that you could then explore led you to discover it was wrong so technically you outlined first to then code to discover the wrong problem yes so right am i wrong no no you're you're not wrong i will say it took me a very long time to write those outlines to come up with the ideas etc and i do believe and I have done it before where I didn't do that and I just started coding and I discovered it much faster right you know the problem solution better than we do let's say for some reason you could have skipped you know the four outlines and you just went to coding and started thinking about the problem could you have gotten to the solution you got to faster than the four outlines yeah the solution I got to was like totally out of left field like it was not related at all to any of the solutions I had listed.

30:49And it was only out of once I started being concrete. I think this is the key that I think maybe is lost. When people hear like discovery coding, they want, you know, they just think you want to fly by the seat of your pants. In fact, in writing, people who don't like this call it pantsing because you're flying by the seat of your pants. So they call discovery writing pantsing. And I thought of doing pantsing coding or something or pantsing programming. When I come from pantsing, also it's the same thing as de-pantsing. And it means you pull someone's pants down. Exactly. And I was like, but that's all I know when I hear that.

31:27Like how you pantsed him. I don't want to associate with that. I like discovery a lot better. Yeah, I was like, that sounds a little pejorative. So let me stay away from that one. But the thing is, when you're staying in this kind of high-level outlining, you're not confronting the concrete problems. that are in existing code bases. So I think this is really useful when there's already existing stuff and there's already existing problems. And maybe it's less useful when you're starting from scratch. I think that's the key insight is that the rubber hits the road faster. Yeah, exactly. That's really the key.

32:03It's like you have to leave the hypothetical area, space, and get into the real world as close as we get digitally to really know whether or not solution A, B, C, or D is even viable. And you won't know that about any of those four until you've actually let the rubber hit the road and realize, ah, you know what? I'm banging up against this. I didn't think I was going to be, but now I am. And the faster you can bang up against it, then you start searching for other things. Exactly. So it might seem like you're trying to, like, skirt, you know, process. You're trying to, like, you're just being lazy, right?

32:37That would be the accusation. Like, come on. Like Leslie Lamport or Dykstra, right? It's, like, very rigorous. We've got to have formal methods. We got to really think about this. We got to prove things. You know, I get that. Like I have that bent. Like I've played with making some like alloy models, which is like TLA plus with a competitor or whatever. I've liked some of this. That's what the landlord stuff is the TLA stuff. Yeah, yeah. Yeah. I like some of that stuff. But I think often when we can replace process with actually doing work, and sometimes what you have to do to get something done is just start doing it.

33:19Right. And let the system itself tell you the constraints that you really have. And then afterwards, you can go write that document. You can go make that proof. You can go do all your formal methods. You can impose your big type hierarchy so that you guarantee that illegal states are unrepresentable. You can do all of the things, but you got to start with something concrete or else all of this is just theoretical and not practical. It's kind of the opposite of flying by the seat of your pants, isn't it? Because you're actually being more realistic sooner. I feel like that's just like, you know, playing fast and loose.

33:55And that's more the world of the hypothetical. I think somebody made up the statement, architecture astronauts. I think I first read it in DHH's writing, but I'm not sure if he coined it. which really spoke to me because it's very easy in the world of architecture to just talk about and think about and maybe even try to formally prove a thing and in the real world that thing is unviable like it just happens and um getting to that to that dirt as fast as you can and start digging to me always made the most sense because when i try to do it the other way around i would wasted a whole bunch of time thinking that I had a solution.

34:38And then I go and try to apply that solution. And then I'd be like, this, this, this doesn't actually work. This is not going to work. And now I got to start figuring something else out. So I guess to me, it doesn't seem like flying by the seat of your pants describes it, but I understand why somebody might think that because you're not quote unquote thinking up front. You're just like coding right away. You know, a cowboy coding as they call it. Yeah. I think the other thing that maybe is hard about this that I kind of have like some brief asides in is like our tools don't really support this style of doing things.

35:11Like part of the reason why people would rather write a design document than go into the code base and try to get some solution together. It's like, it can be really annoying to make changes in code bases. It can take a really long time to find the right place to put something. And then like you try to put something and you have this compile cycle, right i know like i didn't even touch on it in the the blog post because it kind of just like went behind my head but like if you wanted to do a clean build on that legacy system uh when i first joined it was like 10 minutes i think it got down to like seven minutes or something and trying to do even though that's not the like 24 hours i've heard some horror stories of uh like you know having 10 minutes every time you want to make a change to like go explore something is incredibly slow.

36:01And so what you end up having to do is try to plan all of this out ahead of time. And one of the things I found just to be, if you're going to try to do discovery coding, you have to spend that time upfront making tooling so that you can get a fast feedback cycle and you can start discovering. And that just takes a lot of work to get to that point, especially if no one's focused on it. So I do most of my discovery coding at a REPL or try to. What would that look like if it's not an environment-ready loop that you can just program against? Yeah, I mean, I definitely have a bias here because I programmed in Clojure professionally for like five to six years.

36:45And Clojure has, if you've never seen a Clojure programmer with a proper setup do their coding. It's definitely the best out there, in my opinion, in live feedback. They talk about working at the REPL, but what they don't mean is a shell with a prompt. They just have their editor, usually Emacs, and you can evaluate any sub-expression of any bit of code, and it just kind of live evaluates right there in your editor. And you can just start running. like I would have a REPL quote unquote open for a month. That was the state of the whole system. Like it was the running system that I'm modifying on the fly.

37:29So you're just like re-evaluating functions, redefining things. So I will say I now have a lot of things where I work on like big Java apps and I'll just hack in a Clojure REPL in the middle of them so that I can just like, all right, Well, I now have this nice little evaluation. How do you do that? How do you get a Clojure REPL into a Java app like that? So Clojure is on the JVM. So it's actually pretty darn simple to have like, it's like four or five lines of Java to just kind of, you get the jar, you shove it in, you put in a few little things and it opens up a socket and then you just connect to it.

38:06And now you have like the whole, that whole JVM application. You have all of the classes that are loaded into the runtime. You have everything that you can just start messing with. And you mess with it in Clojure or you mess with it in Java? You mess with it in Clojure, but you can do all the Java interop. If you don't have this, I know I have a friend, Brandon Bloom. He did Clojure for a while and then he was doing Go. And he said his replacement for the Clojure REPL was making little tiny shell apps in Go. So like every single one of his like functions, he would like turn into a way he could just evoke it from shell and then like pipe things.

38:45And so like he would like try to take the system and break it up into little bits that you could kind of like isolate and call and then combine those together to make like little interactive environments. You know, I've hacked in my own fake little programming language for a second into an application. yeah you know especially now with like you know llms and stuff you can well the boss isn't looking you know yeah i don't like ship it right just be clear like it's for me right uh it's for me it's just like really useful in production though jimmy you know that little back door just sitting there you can find i think for most systems you can find some little dynamic part of it right you can find something where you can start messing with things even if it's just like you add a bunch of flags like i remember uh in an early job there was this like we went back and forth over and over again on this one form it had like 70 different states error states it could possibly be in based on like different combinations of stuff and it kept we kept having stories on like well if it's this combination the error message should be that and if it's this combination then the error message should be this and like you know over and over again so like i just took that thing and configured it so you could like click on and off every single possible state and see the error message right away like a little dev ui for it and just brought the person as you know as in in office so i just brought them over to my desk and was like what do you want the error message to be right here and then clicked on the next button what about now it's just like walked through all of it right nice and what you know what we discovered is like actually there's like four classes of errors you know and we would have never discovered that had i not taken the time to make the system respond that way it's kind of like one part instinct in a way you know you got to feel how things work it's like a race car driver even like these instincts that happen at uh at millisecond speeds that that only a superhuman can do when you drive formula cars kind of thing you know not an exact one-to-one but it's it's a version of that where you got to sort of feel how the system works and you got to feel this response this push and pull back and forth versus this outline i've got everything in control and i've plotted it out and boom it's done it's just more organic it seems yeah and i think organic coding boom there you go you already named it you don't gotta rename it no i'm just saying like organic is kind of catchy uh that if i want to like you know become a consultant and sell it right the next agile right organic would be a good no jimmy miller's pantsing course

41:34become a pro pantser you know something like that i want to draw a couple corollaries here because at the opening of your post now we're in the meat of this we're in the you know the i would say the practical matters of this but i want to zoom out a little bit on a couple other things which is Stephen King. You've drawn this corollary to him and his style of writing. Is everyone here familiar with Stephen King? I assume you are, Jimmy, because you wrote the quote there for him. Jared, do you know who Stephen King is? I haven't actually read Stephen King, but I do know who he is. I will tell you that I read Stephen King's It as a nine or ten year old, and it forever changed me as a human.

42:10I don't know if it was for a good way or a bad way, but it definitely changed me. So yes, I know Stephen King. Okay. Are you familiar with his writing style? Aside from... I read the quote from Jimmy's, but no, I'm not a Stephen King stylist studier. I've only loosely investigated this. And it's funny that you put this in there, Jimmy, because I have a desire to be an author one day. And I, as of this morning, actually, as of yesterday, I have two book ideas that I may eventually do. Prior to yesterday, I only had one. and now I have a brand new idea and I'm thinking about using the Stephen King method of writing books to get there and the corollary really is this idea that he's got two different style of people that he says writes and you've got the plotters which is like the outliners and it's funny you call the pantsers you've got this terminology because the other writer style he has is called the pantsers P-A-N-S-T-E-R-S I don't know why I don't know the theory behind the name, Pansters.

43:16They write on instinct. They go where the writing takes them kind of thing. And I'm really curious to go down this path because he's got this plan. He's like, you know, I'm also a discovery coder. Having a plan is kind of like, cool. I have an idea and a vision maybe. But like in the tactile, I'm going to just like hit the ground, and see what works and push back against the system and see what I like and don't like. You've got a concept of a plan. Yeah. It's not, you know this, Jared, I'm not telling you ideas all the time. I'm like, dude, I got an idea. Okay. It's not fully formed. Just, just work with me here.

43:55And I bring that rubber to the road right away. And I'm like, here's here. Here's everywhere. That's going to fail. Sometimes it's like, you know what? Actually. Well, actually, I'm just kidding. Sometimes I think it's a good idea, but a lot of times I'm like, here's why that's not good. Yeah. Yeah. Discovery. But he's got a method. And I can paraphrase some of it, but it's really short. He's got three steps. Okay. Write every day. Murder your darlings. Oh, yes. Productive writing environments. No internet, no phone, no TV. Just a laptop, water, tea, hydration, and music. And he likes metal. So Stephen King writes to metal.

44:36Really? Yeah. those are his three steps to getting into a mode to write is this habit of write every day this habit of when you go to write it's in an environment that's suitable for writing and like I said no internet no tv music is all you can have there and and what I've discovered is he gets into flow state quickly and so I kind of wanted to bring up those steps and talk to you about that and i suppose i'd imagine flow state right because you're kind of feeling it you can't get into that deep immersed feeling of what it is until you kind of get to this place where you can sort of be in a trance let's just say transcendental coding what do you think jimmy do you follow those three steps to success i definitely don't follow those three steps in the sense of like uh i don't Maybe I do code every day.

45:29Not as a particular habit. It probably does just happen most times by happenstance. I do really like programming. I do often do it for fun in my spare time. But I definitely have internet when I code. I go to coffee shops most of my coding. So the opposite of a very distracting environment. So you're lucky then you can even get it done. I enjoy, I find I'm much less distracted by having that constant like background stuff going on than I am often focused in. I've never, I've always been of two minds about flow state. I think when I was younger, I definitely think I had flow state type stuff quite a bit where I would stay up to like 4 a.m.

46:18coding and like not realize the time. And I still do have moments of that. but I think most of my coding doesn't happen in a flow state I don't know that I can achieve a flow state very well I get very distracted very easily and jump back and forth between things what I've found but I do think that there's a lot that's good about the general advice like one of the things I've found that I've been really struggling with over time is to stop starting and start finishing to actually push through on a project. And one of the things that has been really helpful for that is being willing to make tiny incremental changes, even if I'm not feeling it.

47:02And I think that's part of this, you know, writing every day, right? Like some days you're going to write like a ton, some days you're not going to feel it at all. And you're only going to write a little bit. And I have found that to be super useful of like, sometimes I'll, I'll not be feeling coding at all, but I really want to make sure I actually get, I'm building a programming language right now. and I really want to actually get it so it's good. And so I'll just spend like 30 minutes fixing one small little bug or cleaning up a comment or whatever. And then I find myself like three hours later still working on stuff.

47:34Actually being productive. Time flies, right? Yeah. I mean, hours will go by if you're in that kind of... Hey, Jimmy, that's called a flow state. Okay, maybe it's a flow state. It may be your version of a flow state. It's not the 4 a.m. coding flow state of his youth. I guess one of the things I always think about with flow state is like the things people always compare it to and maybe i'm just misunderstanding it is like when you're like kind of grooving with music i don't know if either of you play any instruments right but like i play bass and i haven't really played in a while but i play bass guitar and i played stand-up bass as well and orchestra and in that you like kind of do like you're kind of captivated by the music you're really not thinking about where you are what you're doing you're just kind of playing and that is not a feeling i get much with coding would you describe your feeling as effortless momentum no it's always very effortful very very hard over there gosh jimmy okay maybe your flow state is different than yeah i mean usually the things that i'm when i'm doing this stuff uh i guess in my spare time especially it's stuff that's like way beyond i'm trying to find things that are beyond my current ability so i'm often like confused and finding it hard right like the language i'm writing is you know compiled straight to machine code so like i had to right go like i wrote my own like compiling to machine code and then i'm learning all of the like you know intricate bits and parts and it never goes smooth let me rephrase it then is it uh seemingly effortless on the task to stay tasked like to stay on the task that's momentum because you're trying to solve the problem i think that's what momentum is yeah is suggesting there is that it's you're effortlessly on the task of the problem you're trying to solve versus like shiny object youtube here somebody coughed over there yeah you know i mean like you're on the problem and you're sort of iterating towards what okay next hurdle next hurdle next hurdle and then it's two hours later yeah no i would agree with that and i i do find that like the biggest problem i have is coming off of that like trying to transition out back into real life uh takes like quite a while oh yeah you need a buffer there you need like a little cool down yes exactly during the pandemic this was a problem because you know i used i would usually go to coffee shops and do stuff and i would like kind of have a built-in buffer and then during the pandemic i couldn't and i I find that like when I was done with work, I had to commute.

50:07So I would just go on a walk around my neighborhood for like 20 minutes and then come back. Yeah. My brain was all cleared. So yeah, maybe I'm just like overestimating what the flow state has to look like. You've romanticized it. Yeah, exactly. It's better than you think you get to. Yeah. Can't quite achieve that greatness. That's for those other good discovery coders, you know, the good ones. Yeah, yeah. Well, I have another way of describing it, which I think is apt. I just think of it as being locked in. Like it takes a while to get there, but finally, whatever combination of environmental impacts and time and your brain meld to a point that you're locked in on your current problem or your current task, like Adam says, and everything and you're focused and everything else is kind of secondary or just disappears for a little while while you're actually putting all of your thought into it.

51:02to that one problem. And yeah, you may be struggling through that because it's a hard problem. Some of us, Jimmy, just focus on the easy stuff. You know, life's good. When you set the bar low, you know, you can just limp over it. But locked in, I think, is what I picture for flow state is like everything else kind of melts away for a little bit and you can just push forward. Yeah. I think if I'm trying to bring this back to Discovery Coding and be maybe a little bit pedantic i do would say if i'm trying to defend my own notion i'd want to separate those two things right i think you can do discovery coding and not get into flow state and i bet you there's a bunch of outliners being like but the outline is how i get into my flow state right because i know everything i'm working on and that's what like lets me get rid of my distractions no i would definitely agree that these are different things yeah but i do think it can lead to that.

51:58Well, Jimmy, while you're defending and differentiating, you also take some time in the post to differentiate discovery coding from bottom up design or bottom up coding or whatever. Yeah. Versus top down. How do you distinguish that as being different than this? Yeah. So the way I understand, you know, top down design, bottom up design is bottom up is, you know, you're trying to build these kind of little Lego pieces, right? You're trying to get something that's interconnectable. You're not immediately solving some specific problem. Instead, you're making the building blocks to solve lots of problems.

52:35Top-down, kind of the opposite. I think the classic top-down is like, you start with your main method. You're like, I'm going to have this object and it's going to have this method. And the method doesn't exist yet. So I put an empty method body. And then that method, it calls these methods. And you kind of try to solve the problem taking like as you scope you know top down you scope in on the details and you fill them out right and i i when i mentioned discovery coding to a co-worker right before i wrote it he was like oh top down versus bottom up and i was like no that i get i get where you're coming from but like oh yeah at first i was like maybe that's all i've you know i've just reinvented the wheel here just coming up with a new name first had a little moment of crisis there but uh Once I thought about it, it's like, no, I think this is usefully different because I think you can go into a bottom-up approach with kind of that Lamport-esque setup.

53:34You come up with a little calculus. You come up with a little algebra of problems. You'll see Haskellers do this kind of stuff all the time where they come up with all these little parts that they're going to compose together. And you pre-plan ahead of time how you're going to do this. And then you compose them up. You go start coding and doing this. And what I wanted to emphasize with discovery coding is this like kind of emptying of your mind of a solution. That's what I really think is the mark of discovery coding is that you're not just approaching code, trying to solve some concrete issue.

54:10You actually might not even have a problem or a bug or anything like that in mind. What you have is attention. people are not happy with how this thing is working there's like all sorts of issues with it there's this bug over there there's this performance regression here there's this like ugly code there that every time we touch it it kind of breaks there's some security issue over there like you're just coming with like a whole slew of situations and you don't know what you're going to end up coding at the end of it you're just trying to make it better and so you approach it not with like, hey, you know, maybe if I try this, it will work.

54:52You instead of approaching it like, OK, given all this circumstance, all this problem that's going on, where can I first like make a change in the system? Right. Like that's how I approach it is like, where can I like poke at the system? Like maybe it's just I don't know how that subsystem works. And I know it's had lots of problems recently. Maybe I make a little debug interface that just like prints out the state every time it changes. and I start looking at that and I'm like, oh, wait, what's that? Why is the state changing this way? And I'm like, okay, well, how does it relate to that thing?

55:23And you're just starting to connect dots so that you can come up with like, what am I going to do next? And I think that's, you can end up, the result of that process might be a top-down approach, might be a bottom-up approach. It might be you go write a doc, but it's that process of discovery. That's why I like discovery coding because you are trying to learn something. You're not trying to do something. Well, there's no shortage of AI tools out there, but I'm loving Notion and I'm loving Notion AI. I use Notion every day. I love Notion. It helps me organize so much for myself and for others.

56:01I can make my own operating systems, my own, you know, processes and flows and things like that to just make it easy to do checklists, flows, etc. That are very complex and share those with my team and others externally from our organization. And Notion on top of it is just wow. It's so cool. I can search all of my stuff in Notion, all of my docs, all of my things, all of my workflows, my projects, my workspaces. It's really astounding what they've done with Notion AI. And if you're new to Notion, Notion is your one place to connect your teams, your tools, your knowledge, so that you're all empowered to do your most meaningful work.

56:45And unlike other specialized tools or legacy suites that have you bouncing from six different apps, Notion seamlessly integrates. It's infinitely flexible, and it's also very beautiful and easy to use. Mobile, desktop, web, shareable. It's just all there. And the fully integrated Notion AI helps me and will help you to work faster, write better, think bigger and do tasks that normally take you hours to do it in minutes or even seconds. You can save time by writing faster, by letting Notion AI handle that first draft and give you some ideas to jumpstart a brainstorm or to turn your messy notes.

57:29I know my notes are sometimes messy into something polished. You can even automate tedious tasks like summarizing meeting notes or finding your next steps to do. Notion AI does all this and more, and it frees you up to do the deep work you want to do. The work that really matters, the work that is really profitable for you and your company. And of course, Notion is used by over half of Fortune 500 companies. And teams that use Notion send less email, they cancel more meetings, They save time searching for their work and reduce spending on tools, which kind of helps everyone be on the same page.

58:04You can try Notion today for free when you go to Notion.com slash changelog. That's all lowercase letters, Notion.com slash changelog to try the powerful, easy to use Notion AI today. And when you use our link, of course, you are supporting this show. And I think you like it because you're listening. So that's awesome. Again, notion.com slash changelog.

58:34How do you get started then? Like you said it begins with some version of attention. You have tension out there somewhere in the system. And so when you start your day as a discovery coder, do you, are you just trying to learn how the system works kind of thing? Or you're starting with that tension where you've got a C or a slew of different problem sets that you're just trying to figure out why that's happening. Yeah, I do think you got to start with this curiosity of understanding the system. I think a lot of times, especially in day jobs, it's very tempting to just solve problems you're handed or solve bugs that someone reported.

59:12And you can do that if you're a reasonable programmer. You can do that without understanding how the system works almost at all. You just look at the isolated little part. You see that one variable's off and you try to recreate the behavior. But where this always comes from is you want to have a more holistic understanding of the system and you're doing whatever it takes for you to understand that. For me, it's often making a visualizer. So when I write, well, it was really like almost marketing to try to get the job at Shopify working on Ruby's JIT compiler. I spent a little weekend hacking in a live view of all the code that got jitted into Ruby.

59:55So I just kind of shoved a web socket in the middle of Ruby's jit compilation and started sending code and graphs. And then I made a little web interface. You can see this on my, I guess it's on my Twitter. That's the only place I really posted this, which, you know, sad. But anyways, yeah. So you can see that where like, it's like as you're in like IRB in Ruby and you're typing code, you could see like code start compiling and like graphs of it. And that was like how I started being able to understand this like basic block version. I had read the paper on basic block versioning, which is the technique YJIT, Ruby's JIT compiler uses.

1:00:34I had read the paper on it. I had looked at a bunch of stuff, but it all just didn't make sense to me until I made that visualizer. And I didn't have like complete answers, but I started asking the right kinds of questions. Like when do multiple versions of blocks come up? and why it all started because when I tried to visualize it, I just had assumptions. And then when I really tried to visualize, it's like, wait, why is my code breaking? Like, oh, oh, this isn't unique. There's multiple of these. And I didn't realize that it's things like that. So it might not be visualizing it for you. It might be something, you know, it might be making a big bulleted list.

1:01:09It might be whatever. But the goal is to try to understand some aspect of the system that you didn't understand before. and only then do you move to this like and now how do i solve a problem what problems are there to solve compare that to test driven development I have never, I've never, it's just, I just, I don't understand people who love, I feel like the people who love TDDD have to be outliners. and if they tell me otherwise, I'm just confused. Okay. I want to like it. I think it can be good. When I'm writing a parser, I often do kind of more a test-driven development-y thing because it's really easy to be like, hey, I want this thing to parse.

1:01:55Right. Right. But usually I only do that in a language that's not like Clojure where I can just like immediately evaluate and see what it parses to. And usually my tests don't even have assertions. They're just glorified repls. Okay. If you need repls in Java, just write a test and run it and put a breakpoint. Right. But I don't know. I guess, you know, it would be a question for people. If that's the tool that really helps you discover things, great. I've never understood it. I ask because I'm not an Argent TDDR, but I definitely have used it for that purpose.

1:02:38and then I just fall back on the tests as regressions. Then I just have this little asset that I can hold on to as long as it's useful. Where I'm using the test really to explore more than I am to define the way something works. But I'm trying to explore a solution. Perhaps it's an API, perhaps it's a technique, et cetera. And so I use the test for that reason, kind of set up myself in an environment that I can just play in. And yeah, I will basically use Pry if it's Ruby or even Elixir has Pry, which is a lot like you're saying, like get a REPL right here with the whole world around me and just play.

1:03:15But then I'll just leave the tests in because now they're like this little thing that goes green and I can prove I didn't break anything later. But I'm not, I don't TDD at all, all the time or for everything. So I'm not like strict on it, but I have found it to be useful for discovering things. Yeah, I think that's an interesting one. Because I guess when I think of TDD, maybe I'm thinking a little bit more purist. Like greenery factor? Yeah, yeah, yeah. Yeah, I'm not purist. I do write the test before the code, though. So I think of it as TDD. My test is driving out my implementation a lot of the times.

1:03:47In this case, though, wasn't it that there's existing code that you're writing new tests for? Or there's existing, a little bit of both. A lot of times I'll be writing the test for new uses of the same code or modifying code, extending. So it's not always Greenfield, but a lot of times it's for new code as well. But the test comes first, and then I write the code that makes the test work out. So when you do this, do you find that you write a test with your given expectations, and then it turns out, oh, the system doesn't work the way I thought? Is that kind of the goal of writing these tests? Sometimes.

1:04:26yeah that will be well that usually happens more with an existing system that I'm trying to understand versus one that I'm currently building so there's kind of two contexts ones like you seem to be a lot of times modifying a world that is exists and is already gnarly and so discovery is like top of mind oftentimes I already have most of the system in my head and so now I'm extending and changing and I'm making assumptions and make sure those assumptions are true or not and so that's the discovery and then I'm of course like testing out the code that I'm adding to the system as well. So just a little bit different mindsets there, I think.

1:05:02I've only ever come into a system, like remember your best worst code base conversation. Like I've had one of those that I was just comparing it to the whole time. But mostly because I did rescue projects for a while. Ruby on Rails rescue projects contract years ago. But most of the time, the systems that I'm working on aren't so unknown to me that I need to do too much discovery except for i'm trying to discover a solution perhaps to something new you know yeah i do think discovery coding probably is more valuable in those contexts where like the system is too large for you to keep in your head at one time or like there's an external system that's you know complicated enough that like uh you know you can keep your system in your head but like the interactions with that other system are complicated enough that it's like, wait, what is happening with all of that over there?

1:05:59Right. And so like, I do think those are probably the points where I found it, at least for me, I found it to be most valuable is when like, I mean, even for, you know, code that I wrote all myself, like I'm, like I said, I'm building this programming language, but I'm interacting with like a machine code and how it works and you know, what's, And I don't have that full understanding of like the details of arm and how these things are supposed to work and when you have different flags set and et cetera. Right. And that's the point where I find these things really interesting, either where you don't have the system all in your head or you're like interacting with something that's chunky and difficult.

1:06:36Is every time you sit down to code a discovery coding session, like because you are a discovery coder, is all you do discovery coding? I wish. I wish it could be when you was younger it was I find it the most enjoyable when I can I like coding and when I can't I hate it describe give me the version that you don't like it usually happens at work because otherwise you just wouldn't do it so you have some change that somebody else has come up with the details of how you're supposed to implement it and they hand it to you and tell you to go implement it or you have this bug that like, yeah, you know it exists and it should be fixed.

1:07:20But like in order to fix the bug, now there's like 1 ,200 breaking IT tests, you know, integration tests, and you got to go fix all those integration tests and you're just sitting there kind of doing rote work, right? Like so much of the day job of programming is the unsatisfying parts of it. And if you can, what I try to do is I try to sneak in discovery coding into some of those bits. I try to use them as an excuse to like, oh, there's a bug in this part of the system. Yes, I could just fix it by changing that one line that's obviously wrong. But what if I were a more junior developer and didn't just immediately know that that one line was wrong?

1:08:02How about, what would I do? Oh, I would go learn all of this stuff, right? About this part of the system and discover that that one line was wrong. So I'll try to use it as an excuse. And because I think it, you know, again you could think it's maybe a bit self-indulgent but i think it pays off i've had so many times where me knowing a part of a system that i didn't have to know strictly speaking paid off in the long run for the company is there an example of that where you knew that one line was the fix and you went and discovered that it was that plus yeah i'm i'm not sure if i can uh if i have like a good concrete example i do think you know the the The thing I talked about in my article about how I...

1:08:47Did I mention it? I think I did. I debugged one problem for like two years. And it turned out to be this bug in some third-party system where we turned off a cron job. But I was told over and over again when I was solving this problem to stop debugging it and just go write some quick hack that will fix the side effects. and it turns out that that root cause of that bug was actually the root cause of 30 separate bugs that we had in the system that were action at a distance all complicated all weird and had i listened and done what i was supposed to do by my boss telling me to do it we would have never solved all 30 of those problems we would have only solved a handful of them and so like i knew the quick fix for each of them but only by like being willing to go i want to understand this whole system i want to go and dive into uh gil foils code i almost said his real name gil foils code and see all of his craziness he's back yeah i i like by like really feeling that that pull that's how i was able to solve all 30 of them at once instead of duplicating my effort every single time now did you go into your boss's office that day and pick up a microphone and then drop it right in front of him.

1:10:07I found general advice to more junior programmers. If you do something really great, but someone told you not to do it, just don't tell them you did it. I found, I used to brag about those things. So personal satisfaction, you know, you get to tell a cool story on a podcast. Exactly. Don't mic drop your boss when you said I've been disobeying you for two years. Exactly. People don't usually like it, even if it paid off. It just makes them feel like they were stupid. is usually the outcome, right? And you're trying to show them that they were stupid. You said not to do this and I did it and look at all this stuff that paid off.

1:10:43So you just keep it a secret. Just keep doing it. Just keep solving the problems basically. You can live the tale another day or live the discovery code one more day. Yeah. Don't do what you're told. Do what's right. But what if you're wrong and you never figured it out after all those years? If you do enough discovery coding, you'll discover with enough eyeballs all bugs are shallow yeah yeah exactly just open source your code of the world and somebody will find it for you uh-huh that that's good advice you know if you're in a company and you have a problem just open source all their code and then someone i know somebody who did that one time and it really and well someone just like posted a bunch of uh i can't tell you man okay okay okay okay i can tell you i can tell you okay oh my gosh it's been so long since i thought about this but this is one of the stories i won't name names let's just call him dinesh uh it's guilfoyle sidekick uh dinesh got a side gig too and i'll say our main gig okay Dinesh got this sketchy side gig where we were building out a system and in our in our main thing our consultancy we were building out this template let's just say and we wanted to keep improving that and that template was open source but then in this side gig we were doing some things that would make the template we did in the open source better so we He wrote the code for them, but decided to move that code over to here.

1:12:18When I say we, I mean Dinesh did this. I didn't know that. And we had a company together. And it turned into a legal situation. It was bad. And it was the one time I was fired because of somebody else's stupidity, basically. And so Dinesh opened source somebody else's code. Wow. I mean, it's simple boilerplate stuff. It's not like you couldn't rewrite it differently, but it literally was copy and pasted. Like it was line for line the same. And the company found out and they were upset. And they were the kind of people that you don't mess with. The kind of people that the moment they find it, they're not like, oh, you're fired.

1:13:03It's more like, oh, you're fired. And here's my attorney. And they're calling you right now. And don't ever talk to me again, because now you talk to them. Wow. Yeah. So that's my short story on that. Was the Italian Mafia? You know what? I would never mess with him again. Even mentioning the story, I'm a little nervous, honestly. Oh, no. I'm a little nervous. You're going to cease and desist from a lawyer. I have a couple LLCs buffered from that. But I mean, like, it was, you know, that doesn't exist anymore. That's been, that book has closed. It was very scary because I'd never been involved in that.

1:13:34I'm not a sketchy guy, you know? Let me tell a similar story that's lower stakes because it's college. I had a group project one time, four of us in a group. And this is for like a management information systems project, a whole bunch of writing, no coding, very like all outlines, you know, no discovery. And one of my teammates, they just assign you partners, you know, and there's four of us. And he's like, don't worry about it guys. It's like a semester long project. I got the whole thing taken care of. I'm just going to do it. And I was lazy and young and not very discerning. And I thought, awesome, you know, check it off my list.

1:14:11I'm done for the semester on that particular project. Well, the end of the semester rolls around and we all get dragged into the teacher's office. Guess who plagiarized their entire project? Me, alongside three other people. Because the one guy who was willing to do the whole project just plagiarized it. And man, that was a rough day for us. You know, guilty by association, by negligence. so that's why I was nodding along as you got dragged into that when your partner made a really bad decision you were hitched up to it man you know we live and we learn going back into discovery coding I'm curious how it works from sessions I imagine like you said you had that REPL open for a month or whatever how does it work or how do you get back into what you don't call flow what I might call flow okay how do you get back into that zone let's just say to be effective back into discovery mode from yesterday's session to today's session like what do you do to get back into that groove yeah this is something that has been evolving for me for quite a while i watch uh occasionally watch jonathan blow uh do his live coding on twitch i don't know if you're all familiar braid the witness uh he two games that he made he's a he's also making his own programming language uh jai uh he's a very talented programmer um like braid and the witness were all built from scratch and he's working on a third game now that's also the game engine was built in his language that he's building do you say braid yeah braid and the way okay i played that one yeah if you haven't played the witness i definitely highly recommend it it's a kind of a puzzle game almost kind of like a spiritual successor to mist in some senses just in that like it's a beautiful environment that you walk around kind of has that little feeling but very different in terms of like the actual gameplay really great game really like honestly it's it's a little bit of more like a an artsy kind of game so definitely like recommend spending some time playing it uh and he does these live streams and he's just like he i will just go ahead and say i don't agree with all of jonathan blow's opinions i always say this every time i mention jonathan blow because he's like uh he he he can be a little rough around the edges at times, but watching him program is really interesting.

1:16:34And one of the things that he gets to do that's very different from what I get to do in my day job is work on very long time scales. He's building this game for like a decade, right? And these code bases are evolving very slowly over time. And he leaves these very like non-professional, like I'm not saying like they're like rude or anything. They're just like very personal comments in his code base all the time. They're not trying to be for generic programmer to learn what this code's about. They're for him. They're personal notes scattered throughout the code base. And when he comes back, he like can read these comments and actually like understand where his thoughts were at that time.

1:17:18And this is something I've been trying to evolve. I was very much alike. Comments are bad. if you have comments you should just like rename your methods better that was kind of like what i grew up believing in programming and i've gone gone the opposite direction where especially to like get back in the session i will always try to end each session writing one of those comments to myself i will try to write like a sonnet or a haiku how do you write this yeah it's mostly just like stream of consciousness, like every problem that I'm currently feeling, every bit of code that's ugly. I try to like write it down of like, I don't like this.

1:17:56I don't like that. This is working. This isn't, I need to solve this problem. Here's my current theory of what's wrong. That kind of thing, right? Cause usually I have to end these coding sessions very unsatisfied where I haven't solved the problem. Where do you put them at though? These comments, wherever my text editor happens to be open at the time. Okay. or I have a big to do and I also.md and I also have a thinking.md that I have in this repo where I just like put stuff I don't care if they're like ugly I can always delete them later you know they don't have to stay around but that's how I try to end these sessions and I found it to be so helpful because I'll come back and I can hear like my own frustration and voice not like professional you know this method does these things like i just kind of ignore those kinds of comments where if i see my own writing i end up paying attention and getting back into that headspace much more especially frustrations that's the biggest one for me because i'm very it's very easy to jump back into being frustrated yeah i want to talk about this more but i want to mention an idea that you just gave me like is there the concept of personal comments in a code base because i mean that made me think like I would love drops and comments that are shitty like that, let's just say.

1:19:15You know, like John does. But I don't want Jerry reading those comments. They're for me. But I want them in the code where the crap happens, let's just say. You know? Is that a concept that does exist out there? I don't think so. No, this is a tool I've wanted to build for a while. I also am working on my own text editor at some point or other. And that's one of the features that is a killer feature to me. I want to be able to decorate code with my own notes. And make sure it works across revisions. That's the only thing that you have to be careful about, right? It's like, how do you make it so that even if someone goes and changes all this code, it like properly anchors to the right places?

1:19:54Yeah, that should be built into an editor for sure. Yeah, exactly. Like leaving your own trails. And then you could even like, not only just leave your own notes that are for you, you could like make your own notes as like a guided tour of a code base and hand it off to people, right? So you get like collections of notes and then you could have shared notes. I think this is, we don't use our metadata enough. I know that Git has a notion of notes, but everything I've looked at it, it seems like people are saying, don't use it. It's not good. But there is something built into Git, like Git notes that you can put stuff on.

1:20:30I will also leave big commit messages that are just my personal big dumps of thoughts. Yeah, commit messages as close as you get to that. What I like about it seemed like what you were saying is like, and maybe John's practices with them being littered everywhere is that they're where the problem's at or where the angst is at or even where the satisfaction might be at like it good bad ugly whatever it might be it's it's where it should be so when you come back to that place it's like oh and the reason why I asked you this question is like how do you deal with sessions is going back to Stephen King one thing he does is when he sits down for the day like his daily routine his his process is reread the previous I think it's like x chapters like two chapters chapter and a half so he's very much a discovery writer uh if you want to keep the the brand discovery going and so when he sits down for a session and this guy's notorious right like Stephen King's written 60 plus novels 20 uh 20 200 short stories I mean he's more renowned as an effective writer that's skilled and has done a lot and he's written really great stories, whether you like them or not, subjective.

1:21:38But, you know, this idea to drop in, like, these notes in different places or to actually come back to the session with rereading where you left off at, these notes is like, if I'm back here in line 120, well, line 120 is where I'm going to begin this process of it, but here's the hairy monster I had forgotten about but now that i revisit where i went you know my uh my my ram is full with what's what's what's to come yeah i think that's a very important thing to get back into that context i like the idea of going back and reading i think it would it would be interesting to like make yourself a tool that just like looks at your last session of your git history or whatever and let you you know play it out but then like a nice narrative of like what you changed but uh you can even like summarize it or whatever using an LLM or something.

1:22:30But I do think these comments kind of serve as that because going back and reading all your old code, I mean, sometimes you'll spend a few hours and you make like four lines of code change, right? Right, I was going to say, sometimes nothing gets in the Git, right? Like I've spent a long time and I've got nothing to show for it, but it doesn't mean I didn't make progress. Yeah, you just debug. Like that's what I spend a lot of my time doing, especially like when you're working with lower level stuff, right? You're just like trying to debug something that's gone wrong and writing down all of those theories is yeah definitely the key so i like that i i like the the stephen king stuff i might have to look into that even though i don't plan on writing a novel uh i don't know there's something interesting about learning how people do do these things yeah i mean he's he's one of me to follow uh in regards to that but i think you practice a lot of what he does i mean environment wise and not calling it flow and stuff um i think it's cool i think it's cool i'm curious though if you did this personal note stuff like how that would actually work out because it seems like a really good thing that you can do but doesn't really belong in the code forever like some things might some things might not you know because like you explain it like maybe it's documentation maybe it gets extracted to documentation and there's a lot of a lot of potential for this this idea yeah i think you have to get it so that like the the biggest thing i i worry about with it is the ux which is why like when i'm thinking about building my own editor it makes it much easier like you could try to do like a vs code plugin uh for it or something or you could try to do just like i even thought about building a command line tool version oh i have an idea for you sorry yeah yeah great what if it layered on top yeah you know like you know where line 120 is at as an example i used 120 before what if you had an overlay that was on like your database was on top of this the coding database i don't know if i would suggest that you write your own editor unless you're like you're just diehard because wow like getting people to change is oh i don't plan on anyone else using it okay uh yeah this is my editor literally yep yep yeah layer so one of the things i'm thinking of that I think makes this a little harder.

1:24:49It's like, you want some things to be based on like line 120, but you want other things to be like attached to this function or attached to this loop or attached to, and like, when do you decide that those things, if someone renames the function, right? How do you surface that note again? Do you, is it like any, like that's, those are the kinds of questions that I'm unsure about is like, as the code base changes, especially if it's not just you making the changes how do you keep your notes attached to the right points and surface them in a way that you can see them it's kind of like uh caring about the the signs on a row that doesn't exist anymore you know like do you need to know there's a hairpin turn on a road that doesn't exist anymore kind of thing like if somebody deletes the code for example well what if they just like move the functions are around right right rearrange rename you still want that comment but you don't want it on line 120 you now want it on line 420 right oh yeah i lived in an apartment 420 i just have to put this out before i've lived in an apartment that was apartment 420 and right across the uh the hallway from me was 421 no way uh and those people smoked weed like no other and they definitely stole our sign did they really and we had to have a special sign 420 yeah we had to have a special sign that was not removable easily like all the other ones in the apartment yeah so that they wouldn't stop stealing our sign uh we ended up giving a nickname themselves we ended up giving them a nickname which was the 421 of bees ah that's good i like that uh but yeah it was very frustrating to have them constantly stealing our sign.

1:26:42Come on, guys. I like the idea of this. Sign stealing? This personal notes in the code base. You know who you need to talk to, Adam? You need to talk to Nathan Sobo and get him to build it into Zed because somebody with an actual editor that's like wants differentiating features, like that's a pretty cool differentiating feature. They've got the horsepower to actually think through all of these nitty gritty things, these UX things. And maybe they'll build it and then we can just use it. Because we're not going to be able to use Jimmy's, that's for sure. I do think you could do this as a separate thing where, the way I've thought about doing it, if you want to kind of go like the lo-fi route, right?

1:27:22Don't try to make this real nice. You write comments like normal in your normal text editor, but you just give them a little bit of prefix that says personal, like you do to do or whatever. And then just you run a command line script that will take them out before you commit things, right? so you write all the only problem is you might forget right yeah it's just too manual yeah but like if you want to prototype this that would be the way i think you could start doing it and then you can put them back in and then what you can do is you can get those semantics of like how do you do you attach it to a function does it stay on the line what if code changes across commits how do you show these things etc yeah you can also build a standalone app for it that like Yeah, I was thinking an extension which stores, which reads all of the notes out of some get ignored file, which is like personalnotes.md or whatever.

1:28:16And in that file is where you actually store the notes and they're somehow linked to a file name and a line. And then obviously you can get fancier from there. And so when you boot up your editor or start your project or whatever, it's going to take that file, parse it, and put them in. And then whenever you save a file, it's going to take them out or make sure they aren't actually in there, but they're going to look like they're in there. That's as far as I got as we talked. Yeah. The other thing that would make this... We need to discover a solution for this. We can't just make up for some. The other thing that would make this a lot easier is if you kind of got rid of this text-based approach to programming, right?

1:28:50Maybe you go for something like, I don't know if you're all familiar with Unison. So Unison is a language that is being produced right now. They have like a Unison cloud and all of this. And the idea behind it is your code base itself is a big immutable database. So when you make a function, you don't store it as like, like you say you have map, right? You don't store it as the function map as like, this is the name and this is the text I have. You store the hashed contents of that function. And map is just metadata on top of that hash of the AST that you wrote. And so your code is all completely immutable and it's all content addressable.

1:29:33and so what you could now do is you could have very easily hey i want to write a note on this map function right because it's this hash here's my note attached to this hash and what they do when you like refactor and maybe you know someone publishes a new version is instead of having to be like here's this version of a library and i just get all the latest you actually see like oh oh, they changed map from hash one to hash two. Do I want to accept the new map thing? Oh, okay. Everything that in my code base that's pointing to hash one, now I change it to point to hash two. And if you have this kind of setup, it would be very easy to attach these kinds of notes as metadata.

1:30:18And so maybe we're just like, these are all the kinds of things that these more futuristic ideas of programming could unlock for us very trivially. and we're just trying to shove it all onto text. And that's why we're running up against these problems. Right. The, I would call the ones that lose their home, so to speak, let's say you do accept that change. Just call them orphans. They're just orphaned away from its previous. And maybe there's, I don't know if it has a visual or not, but some sort of snapshot of where it was. Like here's before this change was accepted. It was in, it was online 120.

1:30:51It should have been online 420, but it's online 120. And this is how line 20 was when the note was captured yeah you know some sort of before and after state but you've accepted it and now it's orphaned and so it doesn't sort of get visualized in the the editor and that actual line 121 anymore because that world is now changed yeah that's a good point you could and then you maybe you have some actions to be like you know hey take this orphan and move it down to where it needs to be like you kind of have to you know manually keep it up or whatever if it can't automatically figure it out but that that seems and you might be like hey this doesn't matter anymore because it's like you know maybe orphans are actually the ones that are easy to delete yeah but you get just like a little you know little icon little thing that gives you like a count no offense orphans of course of orphans true orphans yeah my brain did say oh if it's orphans you have a little like icon of like a crying child oh god which just sounded really no don't do that don't do that i was gonna start singing the sun will come up tomorrow I like this idea a lot.

1:31:50I really do. I feel like this needs to exist. I feel like this is like the next frontier or one of the versions of it. Cause I think there's some stuff in there that's just like really good for the folks like you and Jared and me is like the discoverers that you kind of like want to use your own breadcrumbs and not everything is public. Especially whenever you're like that it's, it's feelings. It's subjective. It only matters. It really only matters to you. So like your peers may actually reject these comments anyways, if they were true comments in the public code base, let's say. Yeah. You could probably offend some people too, you know, like accidentally, like not cause you're writing something completely rude, but you're like, I don't understand this code.

1:32:28You just frustrated at the time. It's like, this is all garbage. And now it's pertinent for tomorrow's session. Cause if you want to pick up where you left off, you got to put it down raw. You can't like, Oh, it was amazing today. And this function is just so beautiful. You're not going to leave that in there for the longterm though. You're talking about things that you understand or things that you don't understand that are long-term that you might come back to. Not my stream of consciousness from yesterday. I assume, Jimmy, after you consume that and you're back at work, that comment can go away because now you've refreshed your mind.

1:33:00Sometimes they do. Sometimes they don't. I bet you, no. He's a pack rat. He keeps his stuff. Oh, yeah. I definitely. No note left behind is how Jimmy is. I'm a digital hoarder for sure. but you know sometimes it's like you leave these notes knowing that like trying to tackle that problem right now might be a mistake but you need to like remember that context so like I was I built a register allocator that was all really bad and you know I was building it for my language but it worked it worked for everything I could find and I left a big comment about all of the deficiencies with it and how I thought it was probably going to break.

1:33:38And it was until months later that I got code complex enough in my language that broke the way I was doing register allocation that I went back to register allocation and read that comment again that was kind of this like frustrated, like, why am I doing this? Why is this all that I was finally and then I like left at the bottom, like, you should probably if you run into bugs, just actually go read the paper on linear register, linear scan register allocation and actually you understand it. And this last weekend, that's what I did. I went, I read the paper. I actually understood it. I implemented it.

1:34:10And now that bug went away. But like, had I not left that for myself? That's good stuff. Like that's a good comment. You would just check that. You check that in, right? You just left it in there forever. Oh yeah, absolutely. It's my personal project, so I can check anything in, but like for work stuff, I, you know, I wouldn't leave that in there for your, and if it was work code, uh, I would have to clean it up and make it professional. Right. And then it would lose some of the juice. Those I can usually hide. Don't lose the juice, i can usually hide those in commit messages i've had co-workers uh message me and go oh i didn't know commit messages were for rants uh because they'll like go like three paragraphs in and then all of a sudden i'm ranting about the problem uh usually people don't read those so you can get away with it but uh i i feel like a professional courtesy for leaving those when you have to do a hack because someone eventually is going to get mad at you and they'll look at who wrote this stupid code and then hopefully they see a big long commit message and they feel better that could be your next blog post, you can go through some of your old commits and pull out spicy comments.

1:35:09Remember Taxi Cab Confessions? Remember that show on HBO? It's like Commit Message Confessions by Jimmy Miller. But I do think this personal, I agree, Adam. I think this personal notes tool would be really nice. I do think you could probably build it as a plug-in on various editors without too much effort. I think there's some UX things you've got to think about and some problems. So, you know, VCs want to, I'm just joking. I was going to say, if any of our listeners want to solve a problem out there in the world, here's a problem you could solve. Yeah, absolutely. At least three nerds would appreciate it.

1:35:42It's got some legs, man. Good. I'm glad to hear. I think so. Reminds me of Field Notes. I got a friend of mine who just like swears by Field Notes. He literally keeps the Field Notes notebooks that Kudal Partners came up with years and years ago. He keeps one in his back pocket. and it's like his field guide to everything. And it's place and time, where he's at, who he's with, note. And he pulls this thing out like it's his own personal reference guide because it is. And he pulls it out constantly to reference it for whatever. And he keeps them all. It's kind of like that, but in the digital for a code base.

1:36:19I have a little dog whining at me. Give me one second to grab her. This can be on the podcast or not. It doesn't matter. but if i don't grab her she's just gonna keep whining at me it depends on how you grab her you know there you go oh jared i was thinking like by the neck you know like uh we can't put that up there well you know he's strangling his dog on the oh hey he's back uh what's the pup's name this this is lemon um linen lemon like the fruit she's a lemon good i thought you said linen like the weird name lemon's a good name she's a lemon beagle that's her coloring nice she thinks it is 30 minutes later than it is so she thinks it's dinner time but she's wrong you see my pup back there on the couch oh yeah your name's covering but I see now he's right there he makes a little appearance he's sleeping he's just hanging out yeah yeah she thinks it's time for food but she's she's very wrong but the problem is uh when my wife's home she's not as consistent at the time yeah so you know uh she's i get it she's confused it's fine so when will discovery coding become more than this blog post like it's got i think this has got book potential it's got branding potential it's got a ways man yeah Yeah, it's like agile, but, you know, like in terms of its ability to change things.

1:37:53Oh, I will admit that I haven't thought at all about about anything beyond the blog post. But, you know, it's nice to hear. When's your programming language going to come out then? That I am. I am working on that. It's a very long. It's a very long endeavor. I'll say that. Have big ambitions for it. What's it called? It's called Beagle, actually. you can get a little mascot that Doug hunts they're going to call it linen but yeah so it is called Beagle it's a dynamically typed language which I know is like controversial right now it's functional and the goal is for it to be fast and multi-threaded multi-threaded is a very direct thing I think all of our that's the problem all of our dynamically typed languages right now are a little too old.

1:38:49All the popular ones, you know, they're great. I don't have anything bad to say about Ruby, Python, JavaScript, but they all kind of are from an era where we learned lessons since then. One of those lessons, in my opinion, is multi-threading is good. And if you want to really like use all of a modern computer, you need it. So I'm starting with that from the beginning. And then the other thing is like VMs are really, really complicated complicated and trying to like after the fact patch on jit compilers and all sorts of things just takes either a lot of money in the case of like node and v8 and all of that or just a lot of time and effort you look at what ruby and python are doing and so i started with uh just compiled a machine code from the start uh and you know it's it's proof of concept it's very early days but what kind of machine code like specific uh right now i just have it working on my mac so it's an arm uh but making an x86 back end won't be too hard um but you know it's it's like definitely in the like hobby project stages right now but i have you know i just yeah i have multiple garbage collectors that are plug and playable like i have a generational garbage collector a copying garbage collector it has namespaces it has closures it's like i i'm getting some real code in it now it's finally at that stage i've written like two thousands of two thousand lines of code in the language itself.

1:40:12So it's getting beyond just toy, which is fun. Very cool. But it's way... I'll probably never finish it. I'll just make it the one level of ridiculous. Why I have this language is because I built... I have a blog post where I built an editor in Rust that is up there. And I talk about all the problems with it. And then I built a second editor in Rust that I still haven't written the blog post for, where I made all of the plugins WASM. and you could like live hot you could like hot code with wasm and hot reload all of the plugins and like the whole actual editor part was in uh these wasm plugins and i absolutely hated it because like wasm's cool but it's not meant to do hot reloading constantly and so i went and built a programming language just so i can go build my editor um okay so it's so the editor and the language will ship at the same time yeah it's all levels of ridiculous and i don't expect anyone to ever use it but i've learned a lot i highly recommend like just go reinvent the wheel and build stuff that you're never gonna ship uh it's great they always say don't do that you're saying do it jimmy's a he's counterculture yeah yeah i this is okay this is a blog post that i will write uh at some point soon which is i think we have over indexed on the values that are good for our day job and start applying them to our everyday life when we're coding.

1:41:37And I think this is a big mistake that we're doing. In your day job, it's often not good to reinvent the wheel. You should just pull that well-used library that everyone knows. Don't go make your own front-end framework. Use React. Use whatever you want to have. It's fine. I'm not going to be partisan here. But in your day-to-day life when you're coding, yeah, reinvent the wheel. use your own framework, do whatever you want. Because like all of those values are made for the company. They're made to make money. And if that's not your goal, if your goal is to learn and have fun, we need to ignore all those values that we keep shoving on.

1:42:19I agree with that, man. That's the living, you know, like some people want to, that's almost like the safe road, you know, to not reinvent the wheel is the safe road, but it's not the road that you go down to learn how a system works or why. how you would even do it in the first place. There's just so much learning in that. That's why I love to home lab personally. Like I get to solve problems that I don't even have at work, let's just say. I manufacture problems. I create problems. I break things. And then as a result, I'm like, well, dang, that's stupid. Why does that work like that? But now I know, and I've got my own documentation that's bifurcated away from the code base, which is like, come on, Jimmy, solve that problem.

1:43:01you know yeah yeah that you just brought up a great point like the personal code base you know personal notes i'd also love to take notes on other people's code bases right you're trying to solve some problem with your home lab and you're like you know digging into some open source server and it has some weird bug in it like just take notes for yourself yeah it kind of should be it should live in the repository it should like yeah yeah repo yeah like you so should it live in the repo? I know we're like product designing this now, but do I even want it to possibly be public? Well, I think if it doesn't have to live in the repo, if GitHub is always GitHub and some URL github.com slash whatever.get exists, then you can always assume that will exist and you can build that layer on top.

1:43:50Assuming that truth is there and that foundation remains the same, the API may change a little bit and you can always ebb and flow as a result. But if that remains a truth that we developers live in, then you can build that system on top. Yeah, I think going to the Git shaws to make sure that the points in time, that for sure I think is a no-brainer. But I think maybe you should have an option that you store it in your Git, like using Git notes or whatever, right? But I would also want to be able to be like, nah, that one was too spicy. I don't publish that at all. like oops i made that one public exactly like i don't want that you know or you like you know you publish it encrypted in the thing right public private key signed i don't know come on don't do that are you sure you want to drop this spicy thing yeah yeah publicly you know maybe you can have shared ones as well and you can host those as like text files in the repo there's all sorts of ways you could do it well there's your sass plan right there so yeah oh that's good don't let people posted it in the repo at all so that way it's as a service that's right exactly right as a service you gotta control the data and then you get bought by evernote and that's your exit plan bam does evernote still exist i don't know honestly it was huge back in the day it still exists okay yeah okay cool does it still do what it used to do or they've pivoted like 12 times or something I think, I don't know firsthand.

1:45:21I recall seeing somebody talk about how they still use Evernotes. And I think it was actually the guy. No, I don't know what it was. It was somebody promoting Obsidian and using it as a second brain. And I think they were like talking to somebody that was coming from Evernote. And yeah, it still exists. And it's kind of the same. I hadn't heard of Evernote in a long time until I just said it. I was like, dang, is that a thing anymore? I remember when it came out, it was all exciting. but oh yeah it's one of those things for you was probably the reason right yeah like you take pictures and snap it in there and it would ocr it and that was the first like consumer app that would do that plus that cool elephant icon that really got it going man speaking of that like chat gpt will will ocr very well i was just doing that i mean i was on a i was messing around and for whatever reason i just didn't have my laptop near me and all i had was the machine that i was messing with monitor keyboard mouse etc and my phone and so like i'm at the command line dealing with some stuff and i can't go to the internet because i don't have another computer all i have is my phone so i would like take my phone out take a picture of the screen here's this issue throw that in chat gpt and it's like oh it would read it as if it was like the terminal it's the coolest thing ever you know what else does that now quick time player is that right yeah if you like are watching a movie and maybe the credits are rolling you can just like select the credits and copy paste yeah apple has it pretty much for all text and images it's really funny because it used to be like sending screenshots was one of the most frustrating things anyone could do and now like i've found things where like i can't select that text oh wait i'll take a screenshot of it and now i can select and now i can yes uh i just did that today actually i just did today a couple times like let me screenshot this so i can select the text yeah so life really is getting easier after all so one thing i noticed with this discovery coding though is that you've described it you've prescribed it but you haven't defined how to begin like if there's someone like dude i want to go down this road i think i'm this kind of maybe they already are but they're like you know i want to discover discovery coding how will they do it how do you begin yeah i i think that might be a good you talked about you know what how do i take it out of this blog post.

1:47:40It's a good follow-up maybe that I can do. But, you know, I think the key to get into discovery coding is to be willing to not have a solution in mind. I do think that that is easier said than done. I think it's very, very tempting any time you're approaching programming problems to come with solutions. And And I don't know, it sounds almost silly when I say it, but like I found that to be the number one thing that stops me from finding the good solutions is that I already have a solution in mind, even if it's just in the back of my head. And as I'm going and doing this, I will just automatically go towards that solution.

1:48:24So step one, clear your mind, meditate on no solutions, right? Step two, I really think is ask questions. ask questions about the code base about the problem about whatever it is that is this situation you're in and try to find the answers for those and if the answers are frustrating to find if like it just takes too long to find them build a tool that makes it really easy and if you start there the process of discovery coding will start becoming the easy default because every time you want to have an answer, you already have tools available to you to help find that answer. And that ends up being like your inspiration for how to continue.

1:49:09And so like try to, the goal is to try to make it easy to discovery code because if it's not, you're never going to do it. You kind of have to like, you know, do the hard work up front. Like I, in my language, I had a bug. I had no idea what the bug was. literally none when i was running code all of a sudden it would start returning data that like was not even like part of the struct that i had or whatever it was just like all of a sudden arbitrary data and every time i would run it it would be consistent so i was like okay i clearly have a bug somewhere so i spent all of my time building my own really terrible uh compiler explorer or godbolt clone um if you haven't used compiler explorer check it out it like takes you you give it code on the left and on the right, it spits out assembly and it shows you how it connects between the two.

1:50:02So what I did is I've made my code, my intermediate representation IR and then machine code that was disassembled on the right. And I made it so like when I hover over it, it shows me the IR and then it shows me the machine code. And it's an awful tool. Like it's the worst like put together thing I've ever written, but it worked right. It worked. I got it so that my program output that. And I looked at it and I was like, now I will be able to discover the bug. And I looked at this tool and I kept looking and the bug was not there. And what I learned is that the code that the tool was showing me and the code that was actually running were two different bits of code.

1:50:44code and what i realized is the when i'm writing code to memory i wasn't keeping track of the offset properly and i was rewriting over code i had already written and when i looked at the the fact that this tool showed me that like no the code's perfectly fine everything's great and then i compared like what the this is like the actually in memory and what the tool was saying i was like and immediately I knew like where that bug was right I like had discovered something about my system that I wouldn't have discovered I could have I didn't even know what the bug to begin with was I had no idea and I was like I want to have something that will immediately show it to me and then I learned a lot about how my system worked by doing that even though the actually it didn't show me the bug it showed me the absence of the bug right and that was like the funny part But now since then, I've used that tool every single time.

1:51:39Like now I have a tool readily available to me where anytime I write something and it's wrong, I can go look at how does it match up. And that helped me with my register allocation. Like now it becomes the default place to go. Love it. I think that's a good note to end on. I love that note. Such a good note. Build your own discovery tools so you can start to discover other tools and bugs. or non-bugs and it'll still help you. That's right, the absence. I would have stopped right there, Jimmy. I would have been like, see, there is no bug. I'm going to bed. Told you. I knew it the whole time. I just proved that there is no bug.

1:52:20That's right. So why keep telling me that it's not working? I think that's the real method. You discover that you're perfect and that there are no bugs in your code. That's discovery coding. Yeah. Bye, friends. Bye, friends. Bye, friends. All right, that's ChangeLog for this week. Thanks for frenzing with us once again. Are you a discovery coder or more of an outliner? Do you like Adam's personal code comments idea? Are you up for building it? Let us know in the comments. Yes, every episode of the ChangeLog gets a dedicated thread in our totally cool, totally free Zulip community, which you can join, and you should join, I think, at changelog.com slash community.

1:53:08Thanks again to our sponsors of this episode. Please support them because they support us. Also, because they have awesome products and services. Thanks to Fly, to Temporal, to Augment Code, and to Notion. And thanks as always to Breakmaster Cylinder, the best beat freak in the verse. Thanks, BMC. Next week on the Change Log. News on Monday. Tailscale co-founder David Croshaw tells us how he's using LLMs while programming. That's on Wednesday. And on Friday, Adam and I review and analyze the news. Just the two of us. We hope you'll be there too. Have a great weekend. Like and subscribe on YouTube if you dig it.

1:53:46And let's talk again real soon.