The Changelog: Software Development, Open Source - Discovering discovery coding (Friends)

Episode Date: February 14, 2025

Fire up a REPL, grab your favorite Stephen King novel, and hold on to the seat of your pants! Jimmy Miller returns to reveal why, at least for some of us, discovery coding is where it's at.

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 nineties, I used to use Microsoft Word. I love the entire experience and 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 2000, 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 lead 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. Cause 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 that they've been like, you know, can you please restart your computer? Okay, I've restarted it. Yeah. You know, it's like, you know, I have 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 at the 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 unify gateway does that the UDM Pro. Oh, yeah, it does versions of that for 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. Because if things went down, you couldn't just unplug something either. I understand 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 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 my case files available.

And so if 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 retail ISPs is getting through the many layers of people they're gonna 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 do find that person. I think it's pretty, that'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? This is 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 my, 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 gonna organize. We have about 10 acreages in the area, all on like three circles. And I found this Great Plains, shout out to Great Plains

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 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 Starlink, Starlink didn't exist. This was during 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 it? I I mean there's times where it was so bad we could have never done this video first then no never no 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 court 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 all the houses that I went to.

We don't usually need it around here. They were, they're kind of isolationists. 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. It's just like anything I look up, it just tells me everything about it. And Janice is like, do you mean Wikipedia?

Is it Wikipedia, my guess? Yeah, yeah, yeah. Wikipedia. And she's like, the original Chai GPT. Exactly. She's, Gangan is what she goes by. She's like, Gangan, do you know gang gang 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. This was the first time in her life that she knew she had used the internet on her own and like discovered it, which I just thought was, it's really funny now, cause she always got mad at people fact checking her, but now she fact checks everybody. Dr. Justin Marchegiani There you go.

Dr. Justin Marchegiani On Wikipedia. Dr. Justin Marchegiani Remember that website, Let Me Google That for You? Did you guys ever use that one? Dr. Justin Marchegiani Oh, yeah. Dr. Justin Marchegiani It's snarky with people because they'd ask you a question that was just easily Googleable. 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? They're like, Here's what Wikipedia says. I've consumed it and I will now act like it's my information. Yeah, I absolutely hate the search feature in ChatGPT. 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 because it's gonna 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 of Secret Service folk, you know, knocking your door down. Yeah, it was really great. I'm glad that I got to come back on Friends. I will say, Friends are definitely my favorite episodes. I like the free form content of Friends.

I 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 changelog interview. 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 listens 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's just kind of nice. Especially in like the background, right? Because 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, 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 task that I don't want to do and I'm fine

with getting distracted and it taking 12 times longer then absolutely. But yeah, if I'm trying to really code, I cannot. I found myself accidentally listening to a podcast and coding, and I just was doing something else, and then I start coding something, and I'm like, why am I so frustrated right now? And it's because those two parts of my brain, the linguistic part of my brain is overloaded right now, it feels like.

So I have to turn off the podcast. It's kinda like when you're reading a book and then you realize you haven't been paying attention for the last five minutes. It's 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 gonna be doing one of the two. I'm not gonna be doing both of them. I can multitask as long as one thing is physical and the other one's mental, but two mental things. Come on now. One of my favorite things is to drive and listen to a book. Like a long drive, not like a short drive, like an 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 still sitting there waiting for me to take another long drive. 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, 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 audiobooks 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 wanna read the book, I'll just get it on audiobook and put it at like two and a half X speed.

Blinkist, man, have you heard of Blinkist? I'm not a sponsor, but I was a big Blinkist fan man, have you 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 non-fictional 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 Win Friends and Influence People, just all that stuff. And I got to the end and I was like, oh, I run out of Blinkists, 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. That's a fascinating idea.

I just love, it's almost dystopian in a lot of ways. It is. Yeah. Like here's all these things you're like, you know, have to do for something and you really don't wanna do them. So you're gonna pay money monthly to like, you know, get the distilled versions. Yes, yeah man. Anomal record is 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, Adam loves these kind of books and he will tell me, like essentialism for instance, and he'll tell me the most important ideas in essentialism. I feel no need to go read that book at this point. And Blinkist kind of does that if you don't have friends. You know, I got Adam, you got big wigs

telling you to read stuff, but. Sounds like you need to do the commercial, you know, Blinkist's book recommendations if you don't have friends. Yeah, that is a good one, you know? But now you're giving the hack 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 because they have to, you know to make 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, like I didn't realize it because I didn't look at the page count. I bought some philosophy books, quote unquote, that were actually just papers, but they took it and put it really big font size and shoved it into a very small book. So if you look at the paper, it's like a 25 page paper,

and then it's like a 100 page but tiny book. 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 Zulip that say, hey, I don't really care that you have a YouTube channel. Or you're gonna turn this into a video first podcast. I don't see the benefit of it.

How's that help me? And you know, to wit we say, to use Guilfoyle'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 specific 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 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. Jimmy, take your blog posts, cause you've written 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, you know, does this make sense as a blog post? Does it make sense on a 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. I think like 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 because 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

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 post 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. And we certainly enjoyed this one. Of course, the last one was the best worst code base. Is that the name of it? Yes.

Yeah. 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 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.

Name us, but don't shame us. You know, we're not all as organized and outlining 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 soap box. 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 do you realize you do it? And why should we not shame people for being like us? Yeah, so I was actually listening Brandon Sanderson, well-known sci-fi fantasy author.

He's got a lecture series 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. he talked about this like discovery writer versus an outline writer. OK, 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 like 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, listening to this lecture and thinking about how much 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. Uh, and I, it was all done in like one sitting right after listing 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.

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 co-pilot 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 gotta 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. If you're writing a new application from scratch, you want a web page that'll play tic-tac-toe, piece of cake to crank that out.

But if you're looking at tens of millions of line codebase, like many of our customers, Lemonade is one of them. I mean, 10 million line mono repo, as they move engineers inside and around that codebase and hire new engineers, just the workload on senior developers to mentor people into areas of the codebase they're not familiar with is hugely painful. An AI that knows the answer and is available 7x24, 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 on 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 Co-suggestions and insights a good next step is to go to augment code.com. That's a you g Mnt c o d e comm Request a free trial contact sales or if you're an open source project augment is free to you to use Learn more at augment code.com. That's A-U-G-M-E-N-T-C-O-D-E.com. Augmentcode.com. You discover what you're gonna 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 Like those people are like no you don't like okay Maybe maybe in the small but not in the large or like there 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 out in the company I'm at currently has been very big on like write ups. You know, you like 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 like 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 like, like, I think the problem that they have, and I've seen it, you know, there's, 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, they're unwilling to do that last step. They've come up with a solution. It's actually a bad solution. But since they have the outline for it, they're just going to finish it and maybe even they're going to ship it. And then it comes runs into problems and they're just going to keep going and trying to fix it and fix it and incrementally change it and fix it. And what I found is if you like kind of relinquish control a little bit you let yourself let the code tell you where it wants to go

You're paying attention to the code itself, especially in big complicated legacy systems Like we talked about last time you'll discover solutions. You just would have never thought so yeah That's what I I really recommend the practice because of that one thing it seems though just looking from the outside or hearing this story is that it seems like the practice 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. 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, et cetera.

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, you know, the four outlines and you just went to coding and started thinking about the problem.

Could you have gotten to the solution you got to faster than the four outlines? Yeah. The solution I got to was like totally out of left field. Like it was not related at all to any of the solutions I had listed. 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 doing pantsing coding or something, or pantsing programming, probably. Well, when I come from pantsing also, it's the same thing as deep and scene. And it means you pull someone's pants down. Exactly.

I was like, but that's all I know. You guys might hear that. Like how you pantsed him. You know, like, 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 stay away from that one.

But the thing is, 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 hypothetical faster. Yeah, exactly. That's really the key is like you can't, you have to leave 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 A, B, C or D is even viable. And you won't know that about any of those four until you've actually let the rubber

hit the road and realize, ah, you know what, I'm banging up against this. I didn't think I was going gonna 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'd be the accusation, like come on,

like Leslie Lamport or Dykstra, right? It's 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 the Lamport stuff is the TLA stuff. Yeah. Yeah. Yeah. Yeah. Yeah. Um, 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 to 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 gotta start with something concrete. Or else all of this is just theoretical and not practical. It's kind of the opposite of flying by the seat of your pants, isn't it? Because you're actually

being more realistic sooner. I feel like that's just like, you know, playing fast and loose 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 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 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 doesn't actually work. This is not going to work.

And now I gotta 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 upfront. You're just like coding right away. You know, 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 found just to be, if you're gonna try to do discovery coding, you have to spend that time upfront making tooling so that you can get a fast feedback cycle and you can start discovering. And that just takes a lot of work to get to that point, especially if no one's focused on it. So I do most of my discovery coding at a REPL or TRITO. 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 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, in live feedback.

So, you know, 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 EmacsX 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 re-evaluating functions, redefining things.

So I will say I now have a lot of things where I work on like big Java apps, and I'll just hack in a closure repel 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 closure ripple into a Java app like that? So closure 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, you mess with it in Java, you mess with it in Clojure, but you can do all the Java interrupt. If you don't have this, I know I have a friend, Brandon Bloom, he did Clojure for a while and then he was doing Go. And he said his replacement for 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 type things. And so like he would turn into a way he could just evoke it from shell and then pipe things. And so he would try to take the system and break it up into little bits that you could isolate and call and then combine those together

to make little interactive environments. 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, okay. It can be 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 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, as in, in office. So I just brought them over to my desk and was like, what do you want the error message to be right here? And then clicked on the next button. What about now? It's just like walked through all of it. Right. Nice. And what you know, what we discovered is like actually there's like four classes of errors, you know,

and we would have never discovered that had I not taken the time to make the system respond that way. It's kind of like one part instinct in a way. You know, you got to feel how things work. It's like a race car driver. Even like these instincts that happen at 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. Organic coding. He already named it, dude. You don't have to rename it. No, I know he did.

I'm just saying like organic's kinda catchy. If I wanna like become a consultant and sell it, right, the next Agile, right right organic would be a good No, Jimmy Miller's pants in course Come a pro-panser, you know something like that I want to draw a couple corollaries here because at the opening of your post now, we're in the meat of this We're in the you know, The we 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. OK. 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 call the Pansers, you've got this terminology because the other writer style he has is called the Pansters, P-A-N-S-T-E-R-S. I don't know why. I don't know the theory behind the name. Pansters. They write on instinct. They go where the writing takes them kind of thing. And I'm really curious to go down this path because he's got this plan.

He's like, you know, I'm also a discovery coder. Like having a plan is kind of like, cool. I have an idea and a vision maybe, but like in the tactile, I'm gonna 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'm not the ideas all the time. I do. I got an idea. OK, it's not fully formed. Just just work with me here. And I 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 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 this habit of write every day. this habit of when you go to write It's in an environment that's suitable for writing and like I said, no internet no TV Music is all you can have there and and what I've discovered is he gets into flow state Quickly and so I kind of wanted to bring up those steps and talk to you about that and I suppose 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.

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, I don't, maybe I do code every day.

Not as a particular habit, it probably does just happen most times by happenstance. I do really like programming. I do often do it for fun, you know, in my spare time. But I definitely have internet when I code. And I go to coffee shops, most of my coding. So like the opposite of like a very distracting environment. Right.

So you're lucky then you can even get it done. I enjoy, I find I'm much less distracted by having that constant like background stuff going on than I am often focused in. I've never, I've always been of two minds about flow state. I think when I was younger, I definitely think I had flow state type stuff quite a bit, where I would stay up to like 4 a.m. coding and like not realize the time. And I still do have moments of that.

But I think most of my coding doesn't happen in a flow state. I don't know that I can achieve a flow state very well. I get very distracted very easily and jump back and forth between things. What I've found, but I do think that there's a lot that's good about the general advice. Like one of the things I've found

that I've been really struggling with over time is stop, you know, to stop starting and start finishing, right? To actually push through on a project. And one of the things that has been really helpful for that is being willing to make tiny incremental changes, even if I'm not feeling it. 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 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 Actually time flies right? Yeah, I mean Hours will go by if you're in that kind of and hey Jimmy, that's called a flow state. Okay It's your it may be your version of a flow state. Okay, maybe it's a flow state. It may be your version of a flow state. It's not the 4 a.m. coding flow state of his youth. I guess one of the things I always think about with flow state is like the things people always compare it to and maybe I'm just

misunderstanding it is like when you're like kind of grooving with music. I don't know if either of you play any instruments right but like I play bass and I haven't really played in a while, but I played bass guitar and I played stand up bass as well and orchestra. And in that you like kind of do like you're kind of captivated by the music. You're really not thinking about where you are, what you're doing. You're just kind of playing. And that is not a feeling I get much with coding. Would you describe your feeling as effortless momentum?

No, it's always very effortful. Very, very effortful. Gosh, Jimmy, okay, maybe your flow state is different than other people's 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 things that are beyond my current ability. So I'm often like confused and finding it hard, right? Like the language I'm writing is, you know, compiled straight to machine code.

So like I had to 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 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. You know what 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. And my brain was all cleared.

So yeah, maybe I'm just like overestimating what the flow state has to look like. You've romanticized it. Yeah, exactly. It's better than you think you get to. Yeah. Can't quite achieve that greatness. That's for those other good discovery coders,

you know, the good ones. Yeah, yeah. Well, I have another way of describing it, which I think is apt. I just think of it as being locked in. Like it takes a while to get there, but finally whatever combination of environmental impacts and time and your brain meld to a point that you're locked in

on your current problem or your current task, like Adam says, and 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. And except the bar low, you know, you can just limp over it. But locked in, I think, is what I picture for flow state is like everything else kind of melts away for a little bit and you can just push forward. Yeah, I think if I'm trying to bring this back to 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 kind of little Lego pieces, right? You're trying to get something that's interconnectable.

You're not immediately solving some specific problem. Instead you're making the building blocks to solve lots of problems. Top down, kind of the opposite. I think the classic top down is like you start with your main method. You're like, I'm going to have this object and it's going to have this method and the method doesn't exist yet. So I put an empty method body and then that method 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 I, I, 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, at first I was like, maybe that's all I've, you know, I've just reinvented the wheel here. Just coming up with a new name for it. 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-esque setup. You come up with a little calculus. You come up with a little algebra of problems. You'll see Haskellers do this kind of stuff all the time where they come up with all these

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

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 gonna 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 is like, where can I like poke at the system? Like maybe it's just, I don't know how that subsystem works. And I know it's had lots of problems recently. Maybe I make a little debug interface that just like prints out the state every time it changes. And I start looking at that. 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 write a doc, but it's that process of discovery. That's why I liked discovery coding, because you are trying to learn something. You're not trying to do something. Well, there's no shortage of AI tools out there, but I'm loving Notion and I'm loving

Notion AI. I use Notion every day. I love Notion. It helps me organize so much for myself and for others. 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 notioning 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.Eye. 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 infallibly 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 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 wanna 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 dot com slash change log. That's all lowercase letters notion dot com slash change log to try the powerful, easy to use notion a I 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 calm change log How do you get started then like to use you said it begins with with some version of attention You have tension out there somewhere in the system. And so when you Start your day as a discovery coder do you are you just trying to learn how the system. And so when you start your day as a discovery coder, do you, are you just trying to learn

how the system works kind of thing? Or you're starting with that tension where you've got a C or a slew of different problem sets that you're just trying to figure out why that's happening. Yeah, I do think you got to start with this like 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 like 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 like the isolated little part, you see that one variables off and you try to recreate the behavior. But like where this always comes from is like 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 I, when I write the, well, it was really like almost marketing to try to get the job at Shopify working on Ruby's JIT compiler. I spent a little weekend hacking in a live view

of all the code that got jitted into Ruby. 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, you know, sad.

But anyways, yeah. So you can see that where like it's like, as you're in like IRB in Ruby and you're typing code, you could see like code starts compiling and like graphs of it. And that was like how I started being able to understand this like basic block version. I had read the paper on basic block versioning, which is the technique why 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 like complete answers, but I started asking the right kinds of questions like, when do multiple versions of blocks come up and why it all started because when I tried to visualize it, I just had assumptions. And then when I really tried to visualize this, like, wait, why is my code break? Like, oh, oh, this isn't

unique. There's multiple of these. And I didn't realize that it's things like that. So it might not be visualizing it for you. It might be something, you know, it might be making a big bulleted list. 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 who love, 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 Clojure, where I can just immediately evaluate and see what it parses to. And usually, my tests don't even have assertions. They're just glorified repels. So if you need repels in Java, just write a test and run it and put a breakpoint. 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 asked because I'm not an Argent TDDR, but I definitely have used it for that purpose. And maybe you're, and then I just fall back on the tests as regressions and like, then I just have this little asset that I can hold onto as long as it's useful. Where I'm using the test really to explore more than I am to define the way something works.

But I'm trying to explore a solution, perhaps it's an API, perhaps it's a technique, et cetera. And so I use the test for that reason, kind of set up myself in an environment that I can just play in. And yeah, I will basically use pry if it's Ruby or even Elixir has pry, which is a lot like you're saying, like get a REPL right here with the whole world around me

and just play. 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. But I'm not, I don't TDD at all all the time or for everything so I'm not like strict on it but I have found it to be useful for discovering things. Yeah I think that's an interesting one because I guess when I think of TDD maybe I'm thinking a little bit more 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 as TDD. Like 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? Or there's existing that 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 green field, 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 exist 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. I've only ever come into a system, like remember your best worst code base conversation, a little bit different mindsets there, I think. I've only ever come into a system like you're, remember your best words code base 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 a while.

We're beyond 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 code that I wrote all myself, like I said, I'm building this programming language, but I'm interacting with machine code and how

it works. And I don't have that full understanding of the details of ARM and how these things are supposed to work and when you have different flags set and etc. 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 I Find it was 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 Usually happens at work because otherwise you just wouldn't do it, right? So you have some change that somebody else has come up with the details of how you're supposed to implement it and they hand it to you and tell you to go implement it. Or you have this bug that like, yeah, you know, it exists and it should be fixed. But like, in order to fix the bug, now there's like 1200 breaking IT tests,

you know, integration tests, and you gotta 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, under, 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 not sure if I can, if I have like a good concrete example. I do think, you know, the thing I talked about with in my article about how I mentioned it, I think I did, I debugged one problem for like two years. 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 wanna understand this whole system. I wanna go and dive into Gil Foyle's code. I almost said his real name, Gil Foyle's code. I almost said his real name, Gil Foyle's code and see all of his craziness. He's back. Yeah. Like by really feeling that that pull, that's how I was able to solve all 30 of them at once instead of duplicating my effort every single time.

Now did you go into your boss's office that day and pick up a microphone and then drop it right in front of him? I've found general advice to more junior programmers. If you do something really great, but someone told you not to do it, just don't tell them you did it. OK. I found I used to brag about those things. And I found that.

So personal satisfaction. You know, you get to tell a cool story on a podcast. Exactly. Don't mic drop your boss when you said, I've been disobe cool story on a podcast. Exactly. 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.

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 can live to tell 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. 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's good advice. 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 did not end well. Someone just posted a bunch of uh, I can't tell you man. Okay. Okay. Okay

Okay, I can tell you I can tell you okay. Oh my gosh It's been so long since I thought about this, but this is one of the stories. I won't name names Let's just call him danesh It's guiltful sidekick Danesh It's Guilfoyle's sidekick. Dinesh got a side gig too, and I'll say our main gig. Dinesh got this sketchy side gig where we were building out a system. And in our main thing, our consultancy,

we were building out this template, let's just say. And we wanted to keep improving that. And that template was open source. But then in 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 a company together and 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 the Nash open source mails is 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

because now you talk to them. Wow. Yeah. So that's my short story on that. Was it the Italian mafia? You know what, I would never mess with them again. Even mentioning the story, I'm a little nervous, honestly. Oh no.

I'm a little nervous. I'm gonna cease and desist from a lawyer. I have a couple LLCs buffered from that, but I mean like, it was, you know. That doesn't exist anymore. That's been, that book is closed. It was very scary, because I'd never been involved in that.

I'm not a sketchy guy, you know. Let me tell a similar story that's lower stakes because it's college. I had a group project one time, four of us in a group, and this is for like a management information systems project, a whole bunch of writing, no coding, very like all outlines, you know, no discovery. And one of my teammates, they just assigned 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 gonna do it. And I was lazy and young and not very discerning. I thought, awesome, check it off my list. I'm done for the semester on that particular project.

Well, the end of the semester rolls around and we all get dragged into the teacher's office. Guess who plagiarized their entire project? Me, alongside three other people, because the one guy who was willing to do the whole project just plagiarized it. And man, that was a rough day for us. Guilty by association, by negligence.

And so that's why I was nodding along as you got dragged into that when your partner made a really bad decision and you were hitched up to it, man. Yeah, you know. We live and we learn. Yep. Going back into discovery coding, though I'm curious how it works from sessions. I imagine, like you said, you had that ripple open

for a month or whatever. How does it work or how do you get back into what you don't call flow, what I might call flow? Okay, how do you get back into that zone, let's just say, to be effective, back into discovery mode, from yesterday's session to today's session? Like, what do you do to get back into that groove? Yeah, this is something that has been evolving for me

for quite a while. I watch, 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. Like Braid and The Witness were all built from scratch.

And he's working on a third game now that's also the game engine was built in his language that he's building. 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 a kind of a puzzle game, almost kind of like a spiritual successor to Myst in some

senses, just in that like it's a beautiful environment that you walk around, kind of has that little feeling, but very different in terms of like the actual gameplay. Really great game really like honestly it's a little bit of more like a artsy kind of game so definitely like recommend spending some time playing it. And he does these live streams and he's just like he I will just go ahead and say I don't agree with all of Jonathan Blow's opinions I always say this every time I mention Jonathan blow. He's like 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 like non-professional, like, I'm not saying like they're like rude or anything. They're just like very personal comments in his code base all the time. They're not trying to be for generic programmer to learn what this code is about. They're for him. They're personal notes to be for generic programmer to learn what this code's about. They're for him. They're personal notes scattered throughout the code base. And when he comes back, he like can read these comments and actually like understand where

his thoughts were at that time. And this is something I've been trying to evolve. I was very much alike. Comments are bad. If you have comments, you should just like rename your methods better. That was kind of like what I grew up believing in programming. And I've gone the opposite direction where, especially to like get back in the session,

I will always try to end each session writing one of those comments to myself. I will try to write like a- Is it a sonnet or a haiku? How do you write this? Yeah, it's mostly just like stream of consciousness, like every problem that I'm currently feeling, every bit of code that's ugly. I try to like write it down of like, I don't like this. 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. Okay. Or I have a big to-do and I also.md and I also have a thinking.md that I have in this repo where I just like put stuff. I don't care if they're like ugly. I can always delete them later.

You know, they don't have to stay around, but that's how I try to end these sessions. And I found it to be so helpful because I'll come back and I can hear like my own frustration and voice, not like professional, you know, this method does these things. Like I just kind of ignored 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 I'm very it's very easy to jump back into being frustrated. Yeah, I want to talk about this more, but I want to mention an idea that you just gave me like is there the concept of personal comments in a code base?

Because I mean that maybe you think like I would love to like drops and comments that are like that Let's just say you know like like John does But I don't want Jerry reading those comments there 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. 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 in to get, of like get 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, seeing like who you're seeing is like, and maybe John's practices with them being littered everywhere is that they're where the problem's at or where the angst is at or even where the satisfaction might be at.

Good, bad, ugly, whatever it might be. It's where it should be. So when you come back to that place, it's like, oh. And the reason why I ask 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 wanna 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, 20, 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 him or not, subjective. But, you know, 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 gonna 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 My my ram is full with what's, what's, what's to come. Yeah, I think that's a very important thing to get back into that context. I like the idea of going back and reading. I think it would, it would be interesting to like make yourself a tool that just like looks

at your last session of your Git history or whatever, and lets you, you know, play it out, but then like a nice narrative of like what you changed. But you can 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? Yeah. I've spent a long time and I've got nothing to show for it, but it doesn't mean I didn't make progress.

Yeah, you just debug. Like that's what I spend a lot of my time doing, especially like when you're working with lower level stuff, right? You're just like trying to debug something that's gone wrong. And writing down all of those theories is yeah, definitely the key.

So I like that. I 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 do these things Yeah, I mean he's he's one of me to follow In regards to that, but I think you practice a lot of what he does I mean environment wise and not calling it flow and stuff I I mean environment wise and not calling it 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 Like some things might, some things might not. You know, cause like you explain it, like maybe it's documentation, maybe it gets extracted to documentation. And there's a lot of potential for this, this idea.

Yeah, I think you have to get it so that it, like the biggest thing I worry about with it is the UX, which is why like when I'm thinking about building my own editor, it makes it much easier. like you could try to do like a VS code plug-in For it or something or you could try to do just like I even thought about building a command line tool version Oh, I have an idea for you. Sorry. Yeah. Yeah, great. What if it layered on top? Yeah, you know like you know where line 120 is at as an example. I used 120 before 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 die hard 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. Okay. Yeah. This is my editor. Literally. Yep. 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 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 row that doesn't exist anymore kind of thing Like if somebody deletes the code for example

Well, what if they just like move the functions are around right right rearrange rename you still want that comment But you don't want it online. 120. You now want it online for 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 for 20 and right across the

the hallway from me was for 21. No way. And those people smoked weed like no other. And they definitely stole our sign. Did they really? And we had to have a special sign. For the real 420. Yeah, we had to have a special sign that was not removable easily,

like all the other ones in the apartment. Yeah. So that they would stop stealing our sign We ended up having a funny a nickname themselves. We ended up giving him a nickname which was the 421 of bees That's good, I like that Yeah, I was very frustrating to have them constantly stealing our sign like Like come on guys. Like what? I like the idea of this. The sign stealing? This personal notes in the code base.

I don't have any- You know who you need to talk to Adam? You need to talk to Nathan Sobo and get him to build it into Zed. Because somebody with an actual editor that's like one's 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 wanna kinda go like the lo-fi route, right? Like don't try to make this real nice,

is 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 attach it to a function? Does it stay on the line? What if code changes across commits?

How do you show these things, etc? Yeah. You can also build a standalone app for it that like you could side by side. Yeah, I was thinking of an extension. Yeah. Which stores, which reads all of the notes out of some like get ignored file,

which is like personalnotes.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 gonna take that file, parse it and put them in. And then whenever you save a file,

it's gonna like take them out or make sure they aren't actually in there, but they're gonna look like they're in there. It's as far as I got as we talked. Yeah, the other thing that would make this- We need to discover a solution for this. We can't just make up for some. The other thing that would make this a lot easier

is if you kind of got rid of this text-based approach to programming, right? Maybe you go for something like, I don't know if you're all familiar with Unison. So Unison is a language that is being produced right now. They have like a Unison cloud and all of this. And the idea behind it is your code base itself is a big immutable database. So when you make a function, you don't store it as like, like you say you have

map, right? You don't store it as the function map as like, this is the name and this is the text I have. You store the hashed contents of that function and map is just a 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? Because it's this hash. Here's my note attached to this hash. And what they do when you like refactor and maybe someone publishes a new version is instead of having to be like,

here's this version of a library and I just get all the latest, you actually see like, oh, 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 is 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 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 kind of 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 calm 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 The editor and that actual line 120 more anymore because that world is now changed Yeah, that's a good point you could and then you maybe you have some actions to be like, you know Hey take this orphan and move it down to where it needs to be like you kind of have to you know

Manually keep it up or whatever if it can't automatically figure it out But that that seems and you might be like hey, this doesn't matter anymore Because yes, 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 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. No just sounded really, no don't do that. Don't do that.

I was gonna 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 wanna 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 because you're writing something completely rude, but you're like, I don't understand this code. You're just frustrated at the time. It's like, this is all garbage. And now-

But it's pertinent for tomorrow's session because 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 the longterm though. You're talking about things that you understand

or things that you don't understand that are long term that you might come back to. Not my stream of consciousness from yesterday. I mean, I assume Jimmy, after you consume that and you're back at work going, like that comment can go away because now you've refreshed your mind and- Sometimes they do, sometimes they don't.

You know, sometimes it's like- I bet you know, he's a pack rat. He keeps his stuff. He's- Oh yeah, I definitely- No note left behind is how Jimmy is. Sometimes they do, sometimes they don't. I bet you know, he's a pack rat. He keeps his stuff. Oh yeah, I definitely. No note left behind is how good he is. I'm a digital hoarder for sure. But sometimes it's like, you leave these notes knowing that trying to tackle that problem right now might be a mistake.

But you need to remember that context. So I built a register allocator that was all really bad. And 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 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 trying to, 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 scan register allocation and actually understand it. And this last weekend, that's what I did. I read the paper, and actually understand it. And this last weekend, that's what I did. 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 would just check that in, right?

You just left it in there for... Oh yeah, absolutely. It's my personal project, so I can check anything in. But like for work stuff, you know. You wouldn't leave that in there for your in 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 co-workers Message me and go. Oh, I didn't know commit messages were for rants

Cuz 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. Because someone eventually is gonna 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 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 UX things you gotta think about and some problems, so you know, VCs wanna, I'm just joking. I was gonna say if any of our listeners

wanna solve a problem out there in the world, here's a problem you could solve. Yeah, yeah, absolutely. At least three nerds would appreciate it. 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 swears by Field Notes. He literally keeps the Field Notes notebooks that Cudall Partners came up with years and years ago. He keeps one in his back pocket, and it's like his field guide to everything. And it's place and time, where he's at,'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 This can be on the podcast or not doesn't matter I have a little dog whining at me. Give me one second to grab her. 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 we can't put that up there. Well, you know, he's straying on his dog. Oh, hey, he's back. What's the pups name? This is lemon.

Linen? Lemon like the fruit. She's a lemon. Good. I thought you said linen. No, no. I thought you said lemon. Weird name. No, no, no. Lemon like the fruit. She's a lemon beagle. That's her coloring. So nice. She thinks it is 30 minutes later than it is. So she thinks it's dinnertime, but she's wrong See my pup back there on the couch. Oh, no. I had oh yeah, you know covering, but I see now Yeah, it's right there nice He's he makes a little appearance every ways He's sleeping. He's just just hanging out yeah

yeah she thinks it's time for food but she's she's very wrong but the problem is when my wife's home she's not as consistent at the time yeah so you know she's I get it she's confused it's fine so when will discovery coding become more than this blog post like it's got I think this has got book potential, it's got branding potential. It's got legs, man. Yeah, it's like agile, but you know, like in terms of its ability to change things.

Ooh. I will admit that I haven't thought at all about anything beyond the blog post, but you know, it's nice to hear. When's your programming language gonna come out then? That I am, I am working on that. Nice to hear. When's your programming language going to come out then? That I am. I am working on that.

It's a very long endeavor, I'll say that. Have big ambitions for it. What's it called? It's called Beagle, actually. I thought it would be fun. Ah, that's a tie in. Yeah, you can get a little mascot. That dog hunts.

Yeah. They're going to call it Linen. But yeah, so it is called Beagle. It's a dynamically typed language, which I know is controversial right now. Not for me. I like them. It's functional.

And the goal is for it to be fast and multi-threaded. Those multi-threaded is a 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 learned lessons since then.

One of those lessons in my opinion is multi-threading is good. And if you want to really like use all of a modern computer, you need it. So I'm starting with that from the beginning. And then the other thing is like, VMs are really, really complicated 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 just compiled a machine code from the start. And you know, it's proof of concept. It's very early days, but kind of machine code like specific right now. I

just have it working on my Mac. So it's arm. But making an x86 back end won't be too hard. But you know, it's like definitely in the like hobby project stages right now. But I have, you know, just 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've gotten some real code in it now. It's finally at that stage. I've written like 2,000 lines of code in the language itself.

So, you know, it's getting beyond just toy, which is fun. Very cool. But it's way, you know, I'll probably never finish it. I'll just make it the one level of ridiculous. Why I have this language is because I built, and I have a blog post where I built an editor in Rust that is up there, and I talk about all the problems with it. And then I built a second editor in Rust

that I still haven't written the blog post for, where I made all of the plugins WASM, and you could like live, you could like hot code with WASM and hot reload all of the plugins, and like the whole actual editor part was in 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. Okay. So it's so the editor and language will ship at the same time. Yeah, it's all levels of ridiculous and I don't expect anyone to ever use it, but I've

learned a lot. I highly recommend like just go reinvent the wheel and build stuff that you're never going to ship. It's great. They always say don't do that. You're saying do it. Jamie's like he's counterculture. Yeah. Yeah. I this is okay. This is a blog post that I will write 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, it's fine. I'm not going to be partisan here. But in your day to day life when you're coding, yeah, reinvent the wheel. Use your own framework. Do whatever you want.

Because like, all of those values are made 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 not reinvent the wheel is the safe road. But it's not the road that you go down to learn how a system works or why, how you would even do it in the first place.

There's just so much learning in that. That's why I love to Home Lab personally. Like I get to solve problems that I don't even have at work, let's just say. I manufacture problems, I create problems, I break things, you know? And then as a result, I'm like, well dang, 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. So should should live in the repository. It should like care. Yeah, yeah, like you

Should it live in the repo? Well, I know we're like we're like product designing this now But do I even want it to possibly be public? so well, I think if it doesn't have to live in the repo if get hub is always github and Some URL get up comm slash whatever dot get exists and some URL, github.com slash whatever dot get exists, then you can always assume that will exist and you can build 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 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 shaws 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 Git, you know, in like using Git notes or whatever, right? But I would also want to be able to be like, nah, that one was too spicy. I don't publish that at all. Like, oops, I made that one public. Exactly. I don't want that. 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 can do it. Well, there's your SAS plan right there. So yeah Don't let people post it in the repo at all. So that way it's as a service. That's right Exactly. I use the cloud as a service. You got to control the data

And then you get bought by Evernote and that's your It was huge back in the day Okay. Yeah, okay cool. Does it still do what it used to do or they've pivoted like 12 times or something I think I don't know firsthand. I recall Seeing somebody talk about how they still use Evernote's and 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 his 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 know it's one of those things. Oh yeah, because it was OCR for you was probably the reason, right? Yeah. Like you'd take pictures and snap it in there and it would OCR it. And that was the first like consumer app that would do that.

Plus that cool elephant icon. That really got it going. Man, speaking of that, like chat Well, well OCR very well. I Was just doing that. I mean I was on a I was messing around and For whatever reason I just didn't have my laptop near me and all I had was the machine that I was messing with Monitor keyboard mouse, etc And my phone and so I 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, if you are watching a movie and maybe the credits are rolling, you can just select the credits and copy and paste them. Yeah, Apple has it pretty much for all texts and images. It's really funny because it used to be sending screenshots was one of the most frustrating things anyone could do and now I've found things where

I can't select that text. Oh wait, I'll take a screenshot of it and now I can select the text. And now I can't. Yes. I Oh wait, I'll take a screenshot of it and now I can select the text. And now I can't. Yes. I just did that today actually. I just did it today. Couple times.

Let me screenshot this so I can select the text. Yeah. Life really is getting easier after all. Yeah. 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 up there thinking like,

dude, I wanna go down this road, I think I'm this kind of, maybe they already are, but they're like, you know what, I wanna 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?

That's a good follow-up maybe that I can do. But you know, I think I think the key, 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 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 strap it in my language. I, 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. Not the same code. And what I realized is that 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, 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 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. Love it. I think that's a good note to end on. I love that note. Such a good note. Build your own discovery tools so you can start to discover other tools and bugs. For sure.

Or non-bugs and it'll still help you. That's right. The absence. I would have stopped right there, Jimmy. I would have been like, see, there is no bug. I'm going to bed. Told you. I knew it the whole time. Look, I just proved that there is no bug. That's right. So why keep telling me that it's not working?

That's right. There's no bug. So why keep telling me that it's not working? I think that's the real method. You discover that you're perfect and that there are no bugs in your code. That's discovery coding. Yeah. Bye friends. Bye friends. Bye friends. All right.

That's changelog for this week. Thanks for frenzing with us once again. Are you a discovery coder or more of an outliner? Do you like Adam's personal code comments idea? Are you up for building it? Let us know in the comments. Yes, every episode of the changelog gets a dedicated thread in our totally cool, totally free Zulip community,

which you can join and you should join, I think, at changelog.com slash community. 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 Breakmaster Cylinder, the best beat freak in the verse. Next week on the changelog.

News on Monday. Tailscale co-founder, David Crosshaw, tells us how he's using LLMs while programming. That's on Wednesday. And on Friday, Adam and I review and analyze the news. Just the two of us. We hope you'll be there too. Have a great weekend. Like and subscribe on YouTube if you dig it.

And let's talk again real soon.