Discovering discovery coding with Jimmy Miller

Welcome to Changelog and friends, a weekly talk show about commit message confessions. Thanks as always to our partners at Fly, the public cloud built for developers who ship. Learn all about it at fly.io. Okay, let's talk. Well friends, I'm here with Samar Abbas, co-founder and CEO of Temporal. Temporal is the platform developers use to build invincible applications. But what exactly is Temporal? Samar, how do you describe what Temporal does?

I would say to explain Temporal is one of the hardest challenges of my life. It's a developer platform and it's a paradigm shift. I've been doing this technology for almost like 15 years. The way I typically describe it, imagine like all of us, when we were writing documents in the 90s, I used to use Microsoft Word. I love the entire experience, everything. But still the thing that I hated the most is how many documents or how many edits I have lost because I forgot to save or like something bad happened and I lost my document. You get in the habit when you are writing up a document back in the 90s to do control S, literally every sentence you write.

But in the 2000s, Google Doc doesn't even have a save button. So I believe software developers are still living in the 90s era where majority of the code they are writing is they have some state which needs to live beyond multiple request response. Majority of the development is load that state, apply an event, and then take some actions and store it back. 80% of the software development is this constant load and save. So that's exactly what Temporal does. What it gives you a platform where you write a function.

And during the execution of a function of failure happens, we will resurrect that function on a different host and continue executing where you left off. Without you as a developer writing a single line of code for it.

Okay, if you're ready to leave the 90s and build like it's 2025, and you're ready to learn why companies like Netflix, DoorDash and Stripe trust Temporal as their secure, scalable way to build invincible applications, go to Temporal.io. Once again, Temporal.io. You can try their cloud for free or get started with open source. It all starts at Temporal.io. So always convincing the customer support representative that, you know, probably more than they do about what we're talking about is always an awkward thing because you don't want to be a jerk about it. But it's like, no, I've already rebooted things like I've already done whatever's on your checklist there before you pass me on to the next person. Like I've been there, done that. So please let's just dismiss with the pleasantries. And can you please upgrade me to somebody technical?

The number of times they've been like, you know, can you please restart your computer? Okay, I've restarted it. You know, it's like you buy it for half a beat.

Okay.

Yeah. You just pretend you're doing all of the things that they're telling you to do. So that way you get through their checklist and like, I totally get it. You know, they got to follow procedure. But yeah, when you've done it like a few times. Right. And you're like, like what I ended up doing for this, like dropping packets constantly is making a program that just ran and like had a graph of the percent of packet drop I was having over time. And once I could show them like, here's a chart that seemed to be convincing enough to like send it to somebody else. Yeah.

Thankfully the UniFi gateway does that, the UDM Pro.

Oh yeah.

It does versions of that for you. No coding necessary.

Yeah.

It's like, here you go. Here's my dashboard to my enterprise level home network.

Yeah. This was sadly a, the way this apartment was set up, we didn't even have a in unit router. It was all like at the apartment level. So I had access to nothing. And that made it much trickier. Cause like if things went down, you couldn't just like unplug something either. Like it was just, I understand, you know, they wanted to be all fancy. It ended up being way worse having, you know, wired ethernet throughout and all of that with a centralized router set up. It was just like, come on. They at least actually did it secure. I was, I was surprised with that. It was network isolated properly, but.

My ISP is actually awesome. I'm out here in the sticks and there's only one company that would run fiber to where we are and they were a small business provider. So it was like residential fiber, but on a small business provider's network. And so it's kind of the best of both worlds because it's kind of retail pricing. So it's all, it's not like business pricing, which is always, I think overly priced, but I'm one person away from like a highly technical person who remembers me or has, you know, my case files available. And so I can just get past the first person whose job is just to answer the phone and basically route the next person up is very good and knows what's going on and has my history. And so it's been pretty awesome. The hard part with the residential and retail ISPs is like getting through the many layers of people they're going to redirect you to before you actually are talking to somebody who can solve your problem and knows how to, but it's nice to have a graph when you, when you do find that person.

I think it's pretty, it's like a, basically a miracle that you have amazing internet in the sticks.

It is, and not a miracle as much as it is persistence of me demanding it. For years, right? It's like the only time I've been political in my life. It took a couple of years, I think maybe 19 months because I was actually promised by the person that sold me this land that Cox cable internet was run to the property. And I bought the property under that assumption. I did not do my due diligence. I did double check. I told them to double check to make sure it was true. I thought that was due diligence, but apparently they can just double down on the lie. And so I bought it under that assumption and built a house, you know, three years later moved out here and I'm like calling Cox to set up our cable internet. And they're like, we don't have service to your area. Like, Oh, you do the person that sold me this land says you do. And they're like, no, no, we do not. And so I got a price on what it would cost to actually run Cox cable internet out to me. And it was like $65,000 or something like this. Yeah. So I tried to force them to pay that amount, the person that sold the land and that didn't really work. And so then I decided, well, I'm going to organize. We have about 10 acreages in the area, all on like three circles. And I found this great plane shout out to great planes in Nebraska, great ISP. And they're like, yeah, it makes sense for us to run fiber. We had fiber around you, but not directly where you are. If we can get 10 households to like sign a contract that they will buy it for four years or something, we'll go ahead and trench out to you guys. And so I went around to my neighbors and got people to sign papers and everyone was very happy because all we had was DSL that was oversubscribed and they wouldn't even let me on it. That's how oversubscribed it was. So I was using, no, not star link. Starlink didn't exist. This is like 2016, 2017. I was using a Verizon wireless hotspot 5g. And I would tether to that even to record the changelog. And it was dicey. Wasn't at all. I mean, there's times where it was so bad. We could have never done this video first then. No, never.

That would have been, that's, that is one of the big things that is awful is trying to do video on bad connections.

So, you know, I went knocking on doors and I'm like, please vote yes on this initiative. And they're all like, of course, who doesn't want fiber to their house? They're like, of course it was the easiest sell of all time. Right. And so that's how it happened.

So 10 houses for your contract.

Yep. I only got one no out of the, all the houses that I went to.

We don't use the internet around here.

They were, they're kind of isolationist. They're just like, leave us alone. We don't want to talk to anybody about anything. I'm like, this is just fast internet. They're like, no, we're good. Okay. Sorry for asking.

Send them a letter. My wife's grandma lives out in the middle of nowhere and got a smartphone for the first time, like just a few years ago. And she was like, she was telling Janice, my wife, like, I found this thing on my phone and I don't know what it is, but it starts with the W and everything on there. Just like anything I look up, it just tells me everything about it. And just like, do you mean Wikipedia?

Wikipedia, my guess?

Yeah, yeah. Yeah. Wikipedia. And she's like, the original chat GPT.

Yes, exactly.

She's gang. Gan is what she goes by. She's like, gang, gang. Do you know what Wikipedia is? No, it's the internet. And she was like blown away that she had used the internet. The first time in her life that she knew she had used the internet on her own. Discovered it, which I just thought was, it's really funny now because she, she always got mad at people fact checking her, but now she fact checks everybody on Wikipedia.

Remember that website, let me Google that for you. Did you guys ever use that one with people? Cause they'd ask you a question that was just easily Google. I feel like that's what the current crop of LLMs are. They're like, let me Wikipedia that for you. Like instead of going to Wikipedia, you just ask them and they're basically just reading it to you. Aren't they like, here's what Wikipedia says, I've consumed it. And I will now act like it's my information.

Yeah, I, I absolutely hate the search feature in chat GPT. I have to constantly ask it, please stop searching. I don't care what you're searching. I just want like what's in the memory here. Cause it's going to be higher quality than what you're searching.

Yeah, it's too slow too. Like I can search the web faster than you can search the web.

Yeah, exactly.

Fun times, fun times in the internet lands, you know? Well, we brought you back, Jimmy. We had so much fun talking to you last time, hearing your stories. Secret service folk, you know, knocking your door down.

Yeah, it was, it was really great. I'm glad that, I'm glad that I got to come back on, on friends. I, I will say friends are definitely my like favorite episodes. I like the like kind of free form content of friends. Appreciate that. Yeah. Super excited to be back.

It took us a long time to do friends because we didn't think anybody wanted to hear just us chit chatting with people as much as they wanted to hear the classic change log interview, you know? But apparently what do we know?

I think, I think interviews, you know, they can be really good. Like there are great interviews, you know, I've listened to a lot of them on here that are great, but I don't know, after you hear enough interviews, sometimes it just does kind of get a little formulaic. And if you're like, I'm one of those people who just listened to a ton of different podcasts, but I'm also not like a completionist about them. I don't listen to every single episode of every podcast that I listen to. And so I don't know, it can break up that monotony. If you have a bunch of different interviews and then you just get some like people hanging out chatting, it just kind of nice, especially in like the background, right? Cause if people are hanging out chatting and you're just kind of listening in the background, if you miss something, it doesn't really matter.

Yeah. It's lower stakes. You know, that's why I call it like a weekend talk show. Cause it's like, you know, listen on the weekend, if you miss a part, no big deal. Just another one of our stories that don't matter so much. But I'm happy to hear that you like that. Do you now, do you actually listen to podcasts while working or while coding? Cause I can't do that, but a lot of people do.

It depends if it's actually something where I have to focus now, if it's like I'm having at work to do some really tedious, boring, repetitive tasks that I don't want to do. And I'm fine with getting distracted and it taking 12 times longer than absolutely. But yeah, if I'm trying to like really code, I cannot. I've found myself like accidentally listening to a podcast and coding. And like, I just, you know, it was doing something else and then I like start coding something and I'm like, why am I so frustrated right now? And it's because like those two parts of my brains, like the linguistic part of my brain is like overloaded right now. It feels like, so I have to have to turn off the podcast.

It's kind of like when you're reading a book and then you realize you haven't been paying attention for the last five minutes. Like you're still reading it, but you haven't been actually with it. That's how I get when I'm trying to code and I'm listening to podcasts. I'm only going to be doing one of the two. I'm not going to be doing both of them. I can't, I can multitask as long as one thing is like physical. And the other one's mental, but two mental things.

One of my favorite things is to drive and listen to a book.

Like a long drive, not like a short drive, like a hour-ish, you know? And then if you don't drive again for a while, you're like, man, that book is just sort of just still sitting there waiting for me to take another long drive. You don't finish it.

I've tried to do audio books and I found I can do nonfiction because I'm fine with missing. Like moments, but I do the zone out thing whenever I have, you know, if something gets my attention and if it's fiction, then I'm like, wait, what just happened in the story? Like what is, what is going on? Or the only other time I do audio books is if like I'm at a company and some big wig is like, you have to read this book. It's so important. And I really don't want to read the book. I'll just get it on audio book and put it like two and a half X speed.

Blinkist, man. Have you ever heard of Blinkist? I'm not a sponsor, but I was a big Blinkist fan back in the day. This is basically cliff notes for business books. And so they distill down every business book and self-help and like nonfictional things to 12 to 15 minutes of just the high points. Cause that's pretty much how much information is in a two hour.

Listen, you know, no question.

And so it's really good. And then of course you can deep dive if you want to, but I actually was a subscriber of Blinkist. It's like a, you know, 15 bucks a month kind of a thing, like an audible replacement. And they do a really good job with it. I appreciate their product, but I kind of got to the end of Blinkist as a subscriber. And I was like, let's do all the top, you know, 50 business books that everybody says I should read atomic habits, you know, how to win friends and influence people and just all, all that stuff. And I got to the end and I was like, Oh, I run out of Blinkist. So I just canceled the subscription. I'm sure there's more things now as people continue to write, but that's a pretty cool service really.

It's a, that's a fascinating idea. I just love it's almost dystopian in a lot of ways. Here's all these things you're like, you know, have to do for something and you really don't want to do them. So you're going to pay money monthly to like, you know, get the distilled versions.

Yes.

Yeah, man.

And I'm on the record of saying most business books aren't worth the read. Even when somebody tells you that they are, there are things in there that are worth it. But most of the time, like Adam loves these kinds of books and he will tell me like essentialism, for instance. And he'll tell me like the most important ideas in essentialism. I feel no need to go read that book at this point. And that, and Blinkist kind of does that. If you don't have friends, you know, I got Adam, you got a big, we got big wigs telling you to read stuff, but.

Sounds like you need to do the commercial, you know, Blinkist book recommendations. If you don't have friends.

Yeah, that is a good one. You know, but now you're giving the hack to how to get to the end of Blinkist and cancel. Right.

I mean, isn't that kind of the problem, right? Like that's why these business books are so padded out. Cause they have to, you know, make it the value worth it, right?

Right. Like you can't sell a blog post.

Yeah, exactly. Right.

I have a blog post worth of ideas, but I have to turn it into a book length.

I have bought some very awkward, uh, like I didn't realize it cause I didn't look at the page count, but bought some philosophy books, quote unquote that were actually just papers, but they like took it and put it like really big font size and like shoved it into a very small book. So like if you look at the paper, it's like a 25 page paper and then it's like a hundred page, but tiny book.

Yeah.

And it's like, why, why is this what I just bought? I did not realize I was buying this. This is awful.

You know, it's funny though. I think it's packaging that matters though. I think, you know, it may not get past you, but there's some people like, I got the book of this, you know, several manuscripts that was like a one page read basically. And they're like, I got the book and it might motivate them to pick it up potentially or it's like a coffee table thing or whatever. That's true. The packaging I think does kind of matter cause I think here's an example. Potential of packaging is like we've had this podcast for many years, right? And people listen to this show and we have people that hang out in Zillow that say, Hey, I don't really care that you can have a YouTube channel or you're going to turn this into a video first podcast. I don't see the benefit of it. How does that help me? And you know, to wit, we say to use Guilfoe's way of speaking. Yes. Silicon Valley to wit. We would say, well, there's other people out there that like video length or full length video podcasts. And so it may not be specifically for you, but it's packaged differently for somebody else. And so because we've now taken the same audio podcast, somebody may not pay attention to because it's just audio. We've taken the same product, repackaged it as a video podcast.

Right.

A vlog, maybe, you know, I don't know, a VOD.

We need to repackage it as a book. Didn't Tim Ferriss do that? He took all of his interviews. Of course, he's a genius of packaging, isn't he?

He is. Yeah, I think it is. And he took all of his interviews off the Tim Ferriss show and turned them into a book called, I think like Tools for Titans or something like this. And he took like, cause these are long form interviews and he pulled out all like the tools they referenced and what they use and then like turn it into a book and repackaged it. And I'm sure he sold, you know, thousands, if not hundreds of thousands, if not millions of copies of that. So packaging is important. I do think that's why a lot of people turn things into books because A, now I'm an author, right? Now I'm a published author, whether it's self-published or not, for some reason, it's still cooler to be non-self-published, even though it sounds like mostly downsides besides the clout. And I'm an author. I wrote a book. I think that matters. That's clout. And that's just packaging. You know, Jimmy, take your blog posts cause you've written some, some bangers now, man. You've been writing some bangers.

Thanks.

Repackage those suckers, you know, the future of coding the book.

Yeah. Yeah. I have thought about like, uh, you know, does this make sense as a blog post? Does it make sense? So the podcast, like, do I want to do a solo podcast? Things like that. And I do think the thing that I don't like about the repackaging, I think it can work. And I think like the, the video to audio to video, I think that's an easy one. Right. But like podcast to book, I think the translation often is real awkward.

Yeah.

Like you actually really have to do the work cause they're just different mediums. I find the same thing is true. Like if you compare like a well-produced solo YouTube video versus a talk that someone gave remotely, right. A talk that someone gave remotely, it is both cases. They're just sitting in front of their computer talking to the camera.

Right.

But you know, one's more awkward than the other. Yeah. But yeah, no, I'm excited about this blog post. I've had some good luck with people liking my blog posts lately. I spent like a few years trying to write blog posts and just like have no clue how to write at all. And like what my voice was or any of that. And then just recently each blog post I've written since the one you all invite me on, I've kind of felt it better. Right. I'm finally starting to get there.

You're getting your voice and you're getting your groove.

Yeah.

We certainly enjoyed this one. Of course, the last one was the best worst code base. Was that the name of it?

Yes.

Okay. For some reason, I knew it was best worst, but I was thinking, was it code base? Was a big hit. And we had a podcast that we've either named the same or similar talking to you about it, which was awesome. And now Discovery Coding, of course, you also had the being raised by the internet, which I think we kind of actually touched on in our last conversation, or maybe that was post show that we didn't talk about too much. But Discovery Coding now, this most recent post of yours is the one that we're all referencing and would like to talk about and unpack some, because on this particular one, I felt represented all of a sudden because I'm, this is like one of those things when you don't realize you are something until someone tells you I'm a discovery programmer. Like this is what I found out. I didn't know there was a name for it. Of course there wasn't, I guess you're kind of, you're naming us and not shaming us, which is kind of the point of the post, you know, name us, but don't shame us. You know, we're not all as organized and outliney and think ahead. And as I was reading it, we'll talk about the details, of course, and have you summarize as well. But as I was reading, I was thinking about Leslie Lamport. Now there was an interview that you may or may not have heard that I did with a guy who would absolutely despise what you're writing here, because he thinks that you should absolutely think ahead, write everything down, do all the math, think outside of the code, like all. And that's his soapbox. And so I was thinking, oh, Leslie would hate this, but I'm kind of loving it because I was kind of not jiving with what Leslie's preaching, even though he's way smarter than me, but discovery coding, what is it? How'd you realize you do it? And why should we not shame people for being like us?

Yeah. So I was actually listing Brandon Sanderson, well-known like sci-fi fantasy author. He's got a lecture series on that he's put out for a number of years, but he's got the most recent one on like how to write sci-fi fantasy novels. And I will probably never, ever write any sci-fi fantasy novels, but they're fun to listen to. They're really interesting to just kind of hear, you know, behind the scenes, how he thinks about them. And that's where he talked about this, like discovery writer versus an outline writer.

Okay.

And this is where like, like Stephen King is really well known for hating outlines. He thinks as soon as you've written an outline, you've like ruined the story because that is the story now. And the story is supposed to come out as you're writing. And so he never writes outlines. He just sits down and writes. And Brandon Sanderson is very much like the opposite, Ben. He outlines all his books forever. And so I was just thinking about, you know, listening to this lecture and thinking about like how much that, like this idea of discovery writing fits with how I code. And I think that this is one of the things I often find is like, I don't know, we're just, as much as we love to talk about programming, we don't like to reflect on our actual practice much. And I was trying to think, like, is there anything that corresponds to this? Like, have I read this anywhere? And I tried to find something. I was like, surely somebody has written about it. And I'm sure they have, but trying to find it was really, I didn't, I couldn't find anything quite like it. So I just thought, you know what, I need to write this down. And I, it was all done in like one sitting right after listening to that lecture. It took me like an hour or something to just write it down and put it out there. And so it was great to hear that people, so like, you know, the basics of it are really pretty simple. It's when you go to write code, you don't know what you're going to write yet. You discover what you're going to write in the process of coding.

Well, friends, I am here with a new friend of mine, Scott Deaton, CEO of Augment Code. I'm excited about this. Augment taps into your team's collective knowledge, your code base, your documentation, your dependencies. It is the most context aware developer AI. So you won't just code faster. You also build smarter. It's an ask me anything for your code. It's your deep thinking buddy. It's your stand flow antidote. Okay, Scott. So for the foreseeable future, AI assisted is here to stay. It's just a matter of getting the AI to be a better assistant. And in particular, I want help on the thinking part, not necessarily the coding part. Can you speak to the thinking problem versus the coding problem and the potential false dichotomy there?

A couple of different points to make, you know, AIs have gotten good at making incremental changes, at least when they understand customer software. So first and the biggest limitation that these AIs have today, they really don't understand anything about your code base. If you take GitHub copilot, for example, it's like a fresh college graduate understands some programming languages and algorithms, but doesn't understand what you're trying to do. And as a result of that, something like two thirds of the community on average drops off of the product, especially the expert developers. Augment is different. We use retrieval augmented generation to deeply mine the knowledge that's inherent inside your code base. So we are a copilot that is an expert and they can help you navigate the code base, help you find issues and fix them and resolve them over time much more quickly than you can trying to tutor up a novice on your software.

So you're often compared to GitHub copilot. I got to imagine that you have a hot take. What's your hot take on GitHub copilot?

I think it was a great 1.0 product and I think they've done a huge service in promoting AI, but I think the game has changed.

We have moved from AIs that are new college graduates to in effect AIs that are now among the best developers in your code base. And that difference is a profound one for software engineering in particular. You know, if you're writing a new application from scratch, you want a webpage that'll play tic-tac-toe piece of cake to crank that out. But if you're looking at tens of millions of line code base like many of our customers, Lemonade is one of them. I mean, 10 million line monorepo as they move engineers inside and around that code base and hire new engineers, just the workload on senior developers to mentor people into

areas of the code base they're not familiar with is hugely painful. An AI that knows the answer and is available 7 by 24, you don't have to interrupt anybody and can help coach you through whatever you're trying to work on is hugely empowering to an engineer working an unfamiliar code.

Very cool. Well friends, Augment Code is developer AI that uses deep understanding of your large code base and how you build software to deliver personalized code suggestions and insights. A good next step is to go to AugmentCode.com. That's A-U-G-M-E-N-T-C-O-D-E.com. Request a free trial, contact sales, or if you're an open source project, Augment is free to you to use. Learn more at AugmentCode.com. That's A-U-G-M-E-N-T-C-O-D-E.com. AugmentCode.com.

You discover what you're going to write in the process of coding.

Does that, like to me, that's just how it works, but to an outliner, that sounds foolish, right?

Yeah.

Or not true. Those people are like, no, you don't. Okay, maybe in the small, but not in the large. Or you start to attack it from different angles, right?

Yeah. I think this is one of the things that's always been attention with me. I've worked at a lot of different companies that have had different kind of cultures around formality, and a few companies I've worked at in the company I'm at currently has been very big on write-ups. You need to have a design document before you go implement something. And what I recently did is, you know, we don't need to go into the details of what it was, but it's a hairy problem that we're dealing with. And I was told to go write a design document of how we could deal with this. And I came up with four ideas, and I wrote about each of those ideas. And we had a big discussion about it, we had meetings about it, and we picked one of them. We all agreed number three is the best option. Let's go with number three. So Jimmy, go sit down, go start writing a prototype of number three. I got not even an hour into writing the prototype of option three before I realized the whole idea was completely wrong. As I started writing the code, I was like, okay, well, I would need to do... Wait, no, that doesn't make sense. Hold on, I need to do... That doesn't make sense. And I realized that the way we can solve this problem was so much simpler, so much more elegant, and it was one of the options I had never even considered and would have never considered if I didn't sit down to write the code. And so I think that people who don't discovery code would probably say that... I think the problem that they have, and I've seen it... We can talk about the problem with discovery coding. There's lots of problems with it. But 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 gonna finish it. And maybe even they're gonna ship it. And then it runs into problems, and they're just gonna keep going and trying to fix it and fix it and incrementally change it and fix it. And what I've found is if you kind of relinquish control a little bit, you 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 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 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 and solution better than we do. Let's say for some reason you could have skipped 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. And 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 probably

might come from pantsing. Also, it's the same thing as deep and seen, and it means you pull someone's pants down. Exactly.

I was like, but that's all I know you guys when I hear that.

Like how you pantsed him, you know, like, yeah, I don't want to associate with that. I like discovery a lot better.

Yeah, I was like, that sounds a little, you know, pejorative. So like, let me let me stay away from that one. But the thing is, when you when you're staying in this kind of like high level outlining, you're not confronting the concrete problems that are in existing code bases. So I think this is really useful when like, 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 is like you can't you have to leave the the hypothetical, you know, area space and get into the real world as close as we get digitally to really know whether or not solution ABC 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, 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? That that'd be the accusation. Like, come on, like, Leslie Lamport or Dykstra, right? Like very rigorous. We 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 that stuff is the TLA stuff. Yeah, yeah. Yeah. I like some of that stuff. But I think often, when we, we can replace process from actually doing with actually doing work. And sometimes what you have to do to get something done is just start doing it, right? 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.

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. And 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 was 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 get into 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 waste a whole bunch of time thinking that I had a solution. And 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. Like 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 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, 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 like, you know, having 10 minutes every time you want to make a change to like go explore something is incredibly slow. And 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've found just to be, if you're going to try to do discovery coding, you have to spend that time up front 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 other, like, what would that look like if it's not like 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.

Okay.

And Clojure has, if you've never seen a Clojure programmer with a proper setup do their coding, it's definitely like the best out there in my opinion and live feedback. So, you know, they, they talk about working at the REPL, but what they don't mean is like 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. So you're just like reevaluating 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 have, 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. And now you have like the whole, that whole JVM application, you have all of the classes that are in 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 was, did Clojure for a while and then he was doing Go. And he said his replacement for like 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. And 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, I've hacked in my own fake little programming language for a second into a 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 to be clear, like it's for me, right? 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 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, you know, I was 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? And 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 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 got to rename it.

No, I'm just saying like organic is kind of catchy.

That if I want to like, you know, become a consultant and sell it right in the next agile, right? Organic would be a good.

No, Jimmy Miller's pantsing course.

So you become a pro pantser, you know, someone 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, the quote there for him. Jared, do you know who Stephen King is?

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 10 year old and it forever changed me as a human. I 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, a 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, 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 called the, the pantsers that you've got this terminology because the other writer style he has is called the pantsters. P-A-N-S-T-E-R-S. I don't know why I don't know the theory behind the name. Pantsters. They write on instinct. They go where the writing takes them kind of thing. And I'm, 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. Like 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, 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 mean, I tell 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.

Just bring that rubber to the road right away. And I'm like, here's, here's, 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. 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, no internet, no phone, no TV, just a laptop, water, tea, hydration and music. And he likes metal. So Stephen King writes to metal.

Really?

Yeah. Those are his three steps to getting into a mode to write is, 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 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? Cause you're kind of feeling it and 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, I, maybe I do code every day. Not as a particular habit. It probably does just happen, happen most times by happenstance. I do really like programming. I do often do it for fun, you know, in my spare time, but, uh, I definitely have internet when I code. I go to, I go to coffee shops, most of my, uh, my coding. So like the opposite of like a very distracting environment.

Right. So you're lucky then you can even get it done.

Uh, I, I enjoy, I find I'm much less distracted by having that constant, like background stuff going on that 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, uh, where I would stay up to like 4am coding, uh, 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. Uh, 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 stop, you know, to, to stop starting and start finishing, right. To like 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. And 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. Uh, actually 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, maybe it's a flow state.

It's your, it may be your version of a flow state. It's not the 4am 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 played bass and I haven't really played it in a while, but I played bass guitar and I played standup 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. OK, maybe your flow state is different than flow states.

Yeah. I mean, usually the things that I'm when I'm doing this stuff, 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 compiled straight to machine code. So like I had to 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 seemingly effortless on the task to stay task like to stay on the task? That's what 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 cough 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 do find that like the biggest problem I have is coming off of that. Like trying to transition out back into real life 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 find that like when I was done with work, I had to commute. So I would just go on a walk around my neighborhood for like 20 minutes and then come back. Yeah. My brain was all, all cleared. So yeah, maybe, maybe I'm just like overestimating the, what the flow state has to look like.

You've romanticized it. Yeah. It's better than you think you get to.

Yeah. Can't quite achieve that greatness. That's, 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, it takes a while to get there, but finally, whatever combination of environmental impacts and time and your, and your brain mailed 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 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, 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.

Well, 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 kinds 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. Top down, kind of the opposite. You know, 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 calls these methods. And, you know, 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 when I mentioned discovery coding to a coworker 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 day and first had a little moment of crisis there. But 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 ask, you know, set up, you come up with a little calculus, you come up with a little algebra problems. You'll see Haskler's do this kind of stuff all the time where they, you know, come up with all these little parts that they're going to compose together and you like preplan ahead of time how you're going to do this. And then you, you know, 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. You actually might not even have a like 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. You instead of approaching it like, okay, 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. Where can I like poke at the system? 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. 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? And 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 ride a dock, but it's that process of discovery. That's why I liked discovery coding. Cause 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. I 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, et cetera, 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. And 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. I 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. You 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.

How do you get started then? 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, 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 sea 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. And 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 the... Well, it's 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. So 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 is sad. But anyways, so you can see that as you're in IRB in Ruby and you're typing code, you could see code start compiling and graphs of it. And that was how I started being able to understand this basic block version. I had read the paper on basic block versioning, which is the technique YJIT, Ruby's JIT compiler uses. I 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 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, 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. It 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. I feel like the people who love TDD 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 thing, because it's really easy to be like, Hey, I want this thing to parse.

Right.

Right. But usually I only do that in a language that's not like closure 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. So if you need REPLs in Java, just write a test and run it and put a break point. 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've, I'm not a, an Argent TDD-er. Um, but I definitely have used it for that purpose and maybe your, and then I just fall back on the tests as regressions and like, then I just have this little asset that I can hold on to as long as it's useful, um, 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, but 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. Um, 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. Cause I guess when I think of TDD, maybe I'm thinking a little bit more, you know, purist of like you have green factor. Yeah. Yeah. Yeah.

Yeah. I'm not, I'm not purist. I do write the test before the code though. So I think of it as TDD. Like I'm, my test is driving out my implementation a lot of the times, but in this case though,

wasn't it that there's existing code that you're writing new tests for?

Um, 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 a modifying code extending. So it's not always greenfield, but a lot of times it's for new code as well. Yeah. 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 like you, uh, you write the test kind of with like your given expectations and then like, it turns out, oh, the system doesn't work the way I thought. Is that kind of the goal of writing these tests?

Sometimes, yeah. 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. One's 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 it 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, um, I've only ever come into a system. Like you remember your best worst code base, uh, conversation. Like I've had one of those that I was just comparing it to the whole time, but mostly cause I did rescue projects for awhile. Uh, we'll be 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? Right. 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, uh, 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.

Is 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, uh, I find it younger. It was, I find it the most enjoyable, right? When I can, I like coding. And when I can't, I hate it.

Describe like, give me the version that you don't like.

Yeah. It's, you know, it usually happens at work cause otherwise you just wouldn't do it. Right. So you, you have some change that somebody else has come up with the details of how you are 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, but like in order to fix the bug now there's like 1200 breaking IT tests, uh, 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? How 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 cause 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 thing I talked about with, um, in my article about how I mentioned it, I think I did. I debugged one problem for like two years. Uh, and it turned out to be this like 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, uh, Gil Foyles code. I almost said his real name, Gil Foyles code and see all of his craziness. Yeah. I like by the really feeling that, that pool. 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 them?

I found a 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.

Okay.

I found, I used to brag about those things and I found

Personal satisfaction. You know, you get to tell a cool story on a podcast, but don't mic drop your boss. People 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. Um, is usually the outcome, right? That like you're, 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. So you just keep it a secret.

Just keep doing it. Just keep solving the problems. Basically. You know, if you, you can live the tail 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 were 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. That kind of thing.

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, the company's code. 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 them Dinesh. It's Guilfoe's sidekick. Dinesh got a side gig too. And I'll say our main gig. Okay. Dinesh got this sketchy, uh, side gig where we were building out a system and in our, in our main thing, our consultancy, we were building up this template. Let's just say, and we wanted to keep improving that. And that temple was open source. But then in the side gig, we were doing some things that would make the template we did in the open source better. So we wrote the code for them, but decided to move that code over to here. When I say we, I mean, Dinesh did this. I didn't know that. And we had, we had a company together and, uh, it turned into a legal situation. It was bad. And it was the, it was the one time I was fired because of somebody else's stupidity, basically. And so Dinesh, uh, open source mails 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. It'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. Cause now you talk to them.

Wow.

Yeah. So that's my choice for that.

Was the Italian mafia?

You know what? I would never mess with them again, even mentioning the story. I'm a little nervous. Oh no. I'm a little nervous. You're going to get a cease and desist from a lawyer. LLC's buffered from that, but I mean, like it was, you know, that doesn't exist anymore. That's been at that book. That book is closed. It was very scary cause I'd never been involved that I'm not a, I'm not a sketchy guy.

You know, let me tell a similar story.

That's lower stakes cause 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. I thought, awesome, you know, check it off my list. I'd 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, it just plagiarized it. And man, that was a rough day for us, you know, guilty of my association by negligence. And so that's why I was not in a long as you got dragged into that when your partner made a really bad decision and you were, 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? 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 occasionally watch Jonathan Blow do his live coding on Twitch. I don't know if you're all familiar, Braid, the witness, two games that he made. He's also making his own programming language, Jai. He's a very talented programmer. 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. Did you say Braid? Yeah, Braid and the witness.

Okay, I played that one.

Yeah. If you haven't played the witness, I definitely highly recommend it. It's kind of a puzzle game, almost kind of like a spiritual successor to Myst in some senses, just in that it's a beautiful environment that you walk around, kind of has that little feeling, but very different in terms of the actual gameplay. Really great game. Honestly, it's a little bit more like an artsy kind of game, so definitely recommend spending some time playing it. And he does these live streams, and he's just like... 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 can be a little rough around the edges at times, but watching him program is really interesting. And 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 non-professional... I'm not saying they're rude or anything. They're just 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 can read these comments and actually understand where his thoughts were at that time. And this is something I've been trying to evolve. I was very much like, comments are bad. If you have comments, you should just rename your methods better. That was kind of like what I grew up believing in programming. And I've gone the opposite direction, where especially to 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, is it a sonnet or a haiku? How do you write this?

Yeah, it's mostly just like stream of consciousness. Every problem that I'm currently feeling, every bit of code that's ugly, I try to write it down of like, I don't like this. I 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? Because 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.

Oh, okay.

Or I have a big todo.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 my own frustration and voice, not like professional, you know, this method does these things. 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 head space much more, especially frustrations. That's the biggest one for me, because 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 to like drops in comments that are like that, let's just say, you know, like like John does. But I don't want Jerry reading those comments. They're there for me, but I want them in the code where the crap happens. Let's just say, you know, is that concept 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 like is a killer feature to me. Like 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.

Yeah, 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. Like, I think this is, we have way, we don't, you know, 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 of like Git notes that you can put stuff on. I 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 practice is 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. Like good, bad, ugly, whatever it might be, it's where it should be. When you come back to that place, it's like, oh, and the reason why I asked 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 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 if you want to keep 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, 200 short stories. I mean, he's well 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 is subjective. But this idea to drop in like these notes in different places or to actually to 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 ram is full with what's supposed 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 be interesting to like make yourself a tool that just like looks at your last session of your Git history or whatever and lets you, you know, play it out. But then like a nice narrative of like what you changed. But you could even like summarize it or whatever using an LLM or something. But 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 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 like the Stephen King stuff. I might have to look into that, even though I don't plan on writing a novel. I don't know. There's something interesting about learning how people do these things.

Yeah, I mean, he's one of many to follow in regards to that. But I think you practice a lot of what he does. I mean, environment wise and not calling up flow and stuff. 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. Because you explain it, like maybe it's documentation. Maybe it gets extracted to documentation. And there's a lot of potential for this idea.

Yeah, I think you have to get it. So the biggest thing I worry about with it is the UX, which is why 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 for it or something, or you could try to do just like a, I even thought about building a command line tool version.

Ooh, 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 so hard.

Oh, I don't plan on anyone else using it.

Okay.

Yeah.

This is my editor, literally.

Yep. Yeah, so one of the things I'm thinking of that I think makes this a little harder is 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 around, right?

Right. Rearrange, rename.

You still want that comment, but you don't want it on line one 20. You now want it on line four 20.

Right. Oh yeah.

I lived in an apartment for 20. I just have to put this out before I've lived in an apartment that was apartment four 20 and right across the, uh, the hallway from me was four 21.

No way.

Uh, and those people smoked weed like no other. And they definitely stole our sign. Uh, and we had to have a special sign or 20. 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 them a nickname. We ended up giving them a nickname, which was the four 21 of bees.

Ah, that's good. I like that.

Uh, but yeah, it was very frustrating to have them constantly stealing our sign. Like, come on guys.

I like the idea of this, this personal, this personal notes in the code base. I don't know who you need to talk to Adam and you need to talk to Nathan Sobo and get him to build it into Zed because somebody with an actual editor that's like once 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 gonna 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? Like don't try to make this real nice is you, you write comments like normal in your normal text editor, but you just give them like a little bit of prefix that says like 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, et cetera?

Yeah.

You can also build a standalone app for it that like,

yeah, I was thinking an extension.

Yeah.

Which stores, which reads all of the notes out of some like get ignored file, which is like personal notes dot MD or whatever. And 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 like 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 mean 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? Maybe you go for something like, I don't know if you 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. And so what you could now do is you could have very easily, Hey, I want to write a note on this map function, right? Cause 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 versions 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, they changed map from hash one to hash two. Do I want to accept the new map thing? Oh, okay. Every, you know, everything that in my code base that's pointing to hash one, now I change it to point to hash two. If you have this kind of setup, it would be very easy to attach these kinds of notes as metadata. And so, you know, maybe we're just like, these are all the kinds of things that these like more futuristic ideas of programming could unlock for us very trivially. And we're just trying to shove it all on to 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 on line 120. It should have been on line 420, but it's on line 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 editor and that actual line 120 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 reasonable.

And you might be like, hey, this doesn't matter anymore. Cause 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 to 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 gosh.

Which sounded really, no, don't do that. Don't do that. I was going to start singing the sun will come out tomorrow.

I like this idea a lot. I 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 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. You 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 be like, oh, it was amazing today.

And this function is just so beautiful.

You're not going to leave that in there for over the longterm though. You're talking about things that you understand or things that you don't understand that are longterm that you might come back to not my stream of consciousness from yesterday. I mean, I assume Jimmy, after you consume that and you're back at work going like that comment can go away. Cause now you've refreshed your mind.

And sometimes they do. Sometimes they don't, you know, sometimes it's like, he keeps his stuff. He he's, oh yeah, I definitely no, no left behind. 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 and you, 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. And 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, went back to register allocation and read that comment again, that was kind of this like frustrated, like, why am I doing this? Why does 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 understand it. And this last weekend, that's what I did. I went, I read the paper. I actually understood it. I implemented it. And 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 just check that. You check that in, right? You just left it in there. Absolutely. Yeah.

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, 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 don't lose the juice.

Jimmy.

I can usually hide those and commit messages. I've had coworkers message me and go, Oh, I didn't know commit messages were for rants. Cause they'll like go like three paragraphs in. And then all of a sudden I'm ranting about the problem. Usually people don't read those so you can get away with it. But I feel like a professional courtesy for leaving those when you have to do a hack. Cause 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 can be your next blog post. You can go through some of your old commits and pull out spicy comments and they'll be like, remember taxi cab confessions. Remember that show on HBO. It's like commit message confessions by Jimmy Miller.

Yeah, no, but I do think this a personal, I agree. I agree, Adam. I think this personal notes tool would be really nice. I do think you could probably build it as a plugin on various editors without too much effort. I think there's some, there's some UX things you 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. At least three nerds would appreciate it. It's got some, it'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 Kudol 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 he, you know, it's place in time where he's at, who he's with note, and he pulls this thing out. Like it's his, it's his own personal reference die because it is. And he pulls it out constantly to like reference it for whatever. And he keeps that, he keeps them all. It's kind of like that, but in the digital for a code base.

I have a little dog whining at me. Give me one second to grab her. Okay. This can be on the podcast or not. Doesn't matter, but if I don't grab her, she's just going to keep whining at me.

It depends on how you grab her. You know, there you go. Oh, Jared. Oh, I was thinking like by the neck, you know, like, uh, we can't put that up there. He's strangling his dog. Oh, Hey, he's back. What's the pup's name?

This, this is lemon. Linen? Lemon. Like the fruit. She's a lemon. Good.

I thought you said linen, like the cloth. I was like weird name.

No, no, no. Lemon. Lemon's a good name. Yeah. She's a lemon beagle. That's her coloring. So nice. But she thinks it is 30 minutes later than it is. So she thinks it's dinner time, but she's wrong.

See my pup back there on the couch.

Oh no, I had, Oh yeah. Your name's covering, but I see now. Yeah.

He's right there.

Nice.

He's he, he makes a little appearance. Everyone he's possibly, 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. 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 kind of nice man. Yeah. It's like agile, but you know, like in terms of its ability to change things.

Oh, 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. Uh, it's a very long, uh, it's a very long endeavor. I'll say that have big ambitions for it. Um, what's it called? It's called Beagle actually. Uh, you can get a little mascot. Uh, yeah.

I call it linen.

Uh, but yeah, so it is called Beagle. It's a, it's a dynamically typed language, which I know is like controversial right now. You know, for me, uh, it's functional. And, uh, the goal is for it to be fast and multi-threaded. Uh, you know, those multi-threaded, uh, very direct thing. I think all of our, that's the problem. Like all of our dynamically typed languages right now are a little too old. All 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, 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. Uh, so I'm starting with that from the beginning. And then the other thing is like VMs are really, really 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. And you know, it's, it's proof of concept.

It's very early days, but, uh, 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 backend won't be too hard. 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, I'm getting some real code in it now. It's finally at that stage. I've written like 2000s of 2000 lines of code in the language itself. So, you know, it's, it's getting beyond just toy, which is fun.

Very cool.

But it's, it's way, you know, I'll probably never finish it, but I'll just make it the one level of ridiculous. Why I have this language is because I built it. I have a blog post where I built an editor in Rust. That's 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 is 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, so it's, so the editor and the language will ship at the same time.

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 going to ship. It's great.

They always say, don't do that. You're saying do it. Jimmy's like, he's counterculture. Yeah.

Yeah. 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. And 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, you know, whatever you spell, whatever you want to have. Like 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.

I agree with that, man. That's, that's the living, you know, like some people want to, that's almost like the safe road, you know, to, 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. It's just, there's just so much learning in that. That's why I love to, to home lab personally. Like I get to solve problems that I don't even have at work. Let's just say I'm, I'm manufacturer problems. I create problems, I break things. And then as a result, I'm like, well, dang, that's, that's stupid. Why does it work like that? You know, 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. You know?

Yeah. Yeah. 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 carry the repo.

Yeah. Like you shouldn't live in the repo. I know we're like, 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 get hub. Is always get hub and some URL get up.com slash whatever dot get exists. Then you can always assume that will exist and you could build that, that layer on top. Assuming that truth is there and that foundation remains the same. The API may change a little bit and you can always, you know, 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 get shahs to make sure that like, you know, the points in time, that for sure I think is a no brainer, but I think I, I mean, I think maybe you should have an option that you store it in your get, you know, in like using get 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. 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 SAS plan right there. So yeah. Oh, that's good.

Don't let people post it in the repo at all. So that way it's as a service. That's right.

Exactly.

As a service, you got to control the data.

And then you get bought by Evernote and that's your plan. Bam.

Does Evernote still exist?

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 it, I don't know firsthand. I recall seeing somebody talk about how they still use Evernote. 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 your 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 anything anymore?

I remember when it came out, it was all exciting, but I don't. Oh yeah. It's one of those things.

OCR for you was probably the reason, right?

Yeah.

Like you take pictures and snap it in there and it would OCR it. 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 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, et cetera, 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 to 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? Quicktime player. Is that right? Yeah. 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 all texts 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.

I just did that today. Actually, I just did today a couple of times. Let me screenshot this so I can select the text.

Yeah. 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 what? I want to discover discovery coding. How will they do it? How do you begin?

Yeah, I think that might be a good, you talked about, you know, how do I take it out of this blog post? It'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 anytime you're approaching programming problems to come with solutions. 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. So 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. And 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 upfront. 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 compiler explorer or Godbolt clone. 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. So 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. 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 fact that this tool showed me that like, no, the code's perfectly fine. Everything's great. And then I compared like what the, like the actually in memory and what the tool was saying. I was like, ah, 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. Like 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.

I love it. I think that's a good note to end on.

I love that note. It's 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 just proved that there is no bug. So why, why keep telling me that it's not working? I think that's, 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 frenzying 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. Thanks 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 break master cylinder. The best beat freak in the verse. Thanks BMC. Next week on the changelog news on Monday tail scale. Co-founder David cross shot tells us how he's using LLMs while programming. That's on Wednesday. And on Friday at MNI 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 and let's talk again real soon.