Stream: friends

Topic: 80: Discovering discovery coding

Logbot (Feb 14 2025 at 19:45):

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. :link: https://changelog.am/80

AJ Kerrigan (Feb 15 2025 at 07:47):

This episode was beautiful :heart: . Many thoughts, but to highlight just a few:

• Huge +1 to REPLs and other forms of discovery coding. Both the practice and the terminology. Jimmy credited Brandon Sanderson - he used to be one of the hosts of the Writing Excuses podcast, and that show continues to regularly have ideas that map well to the dev world.
• On the topic of personal notes / annotations for code, my first experience with that sort of idea was seeing the annotated source for underscore.js.
• Tools like VS Code's Code Tour extension take things to another level though - allowing you to build annotated tours within a repo or export them as self-contained units with stable embedded code snippets. For example, I have a 4 year old tour of a codebase I recorded as part of a workshop. It's a giant json blob in a github gist, which is consumable purely in a browser via github.dev for non-VS Code users.
  image.png
  

I'd be curious what other annotation / tour tools people use.

45h15h (Feb 15 2025 at 14:16):

The editor discussion reminded me of literate programming Donald Knuth used to write Tex and other software. I remember using an editor to help with this when I experimented with.

You write your "document" and mix in the code as necessary. Then the tool can extract the full source files out of the document and create your software. Since the document is the main thing and code is what makes the document come alive and inserted with the document, you don't worry about being tagged together.

You could document your frustrations, personal notes or whatever you wanted. The only question is what would you do with stuff you don't want to share?

Chris Duzan (Feb 15 2025 at 14:38):

Great episode! This is timely for me because I've been trying to really pay attention to my work style recently. When are things moving along well and I feel good about my work vs when am I getting really hung up on things.

Some things that came to mind as I listened to the episode:

• Coincidentally, I just heard Brandon Sanderson on Tim Ferriss' podcast and was having this same thought about "outliners" vs "discovery" (Brandon refers to them as "gardeners" in the podcast) writers. Really good episode that touches the surface of a lot of things if you're not ready to dive into Brandon's online lectures.
• The idea of "discovery programming" is something I've been calling "rapid prototyping" for myself (and I definitely prefer it over writing a bunch of docs before I even touch the code). I've found it helpful when there are a lot of unknowns going into planning. Like Mike Tyson said, "Everyone has a plan until they get punched in the face." I have felt this similar to how Jimmy mentioned they spent a bunch of time coming up with potential solutions and ended up being none of them.
• A hybrid approach that seems to work well for me is: rapid prototype -> plan -> prod-level code.
  • It seems like you need the rapid prototype to grok the problem/system first (assuming there are unknowns). This doesn't need to be "clean" code or a perfect implementation. You're just trying to better understand what's going on and come up with a prototype solution.
  • From there, you can come up with a better plan since you've discovered the previous unknowns. And you can fit it into your larger project as a whole (things you already have an understanding of).
  • Lastly, you write the code you want to publish. This is where you can implement whatever your "good practices" are (TDD, "clean code", etc).

All this to say this was a great episode that got me thinking about my own practices more. Which, inevitably, leads me to enjoying coding more.

Chris Duzan (Feb 15 2025 at 14:42):

@AJ Kerrigan I've never used a "code tour" before, but I'm definitely gonna check this out now! If it's what I'm imagining, I could envision a lot of uses for this (onboarding new devs on a team or in a new codebase, introducing new concepts practices in a codebase, etc).

AJ Kerrigan (Feb 15 2025 at 15:02):

Yeah @Chris Duzan it's pretty neat. I hope you get some value out of it, and I'm sure there are similar tools for other environments out there. I just don't know them yet :sunglasses: .

Actually the creator (Jonathan Carter) bundles CodeTour and a bunch of related extensions into CodeSwing which he calls an "interactive coding playground". And he created GitDoc separately, which automatically commits/pushes changes as you work. I think all of that guy's work clicks with the same spot in my brain that Jimmy was hitting here - fast feedback and low friction exploration. (Personally I use GitDoc only in my personal notes repo, I don't like using it on actual projects).

matt wilkie (Feb 16 2025 at 13:08):

45h15h said:

The editor discussion reminded me of literate programming Donald Knuth used to write Tex and other software.

See LeoJS, a vscode extension which is a typescript reimplementation of the Leo Editor, which itself started ~30 years ago inspired by Knuth's work and the More outline editor and has been under continuous development.

Leo exactly addresses how to add and use personal comments in a shared codebase talked about in the Discovery podcast episode (and a whole lot more).

Even if the editors themselves are not to taste - most folks bounce off, it takes willingness to work differently and time to learn - the ideas are solid and battle tested, worth exploring.

• https://boltex.github.io/leojs/
• https://leo-editor.github.io/leo-editor/

Jouni Seppänen (Feb 16 2025 at 18:10):

Another modern implementation of literate programming is nbdev (introductory blog post) where you basically do your coding in a Jupyter notebook, then mark some cells as exportable and compile it into the final code. I tried it a few years ago and it was a bit clunky to get working, but they've probably streamlined it a lot since.

AJ Kerrigan (Feb 16 2025 at 18:20):

I also bounced off notebooks/nbdev for most projects, despite seeing their appeal. Been mucking around with marimo lately though, and it's the most I've jived with a notebook tool's philosophy since an old "unnotebook" tool called Cauldron.

Andrew O'Brien (Feb 16 2025 at 22:39):

I’ve been picking and choosing my way through The Future of Coding podcast since the last time Jimmy was on. Would definitely recommend. Always great discussions about important papers with occasional mindblowing artistic flourishes.

matt wilkie (Feb 17 2025 at 02:19):

marimo is very interesting. I enjoy the interactivity and near simultaneous coding + visualizations, and am very happy it's uv and pixi aware. I've yet to do anything "for real" with it, but am pretty sure that'll happen before long.

Ricky Hussmann (Feb 17 2025 at 03:22):

Was skeptical reading the description of this episode, then really enjoyed listening through. I think mainly because I’m a cynic that doesn’t like to be put into a bucket.

That said, the entire conversation I was labeling myself as a discovery coder, and toward the end when Jimmy said the crux is coming into the space without any predisposition to a solution I was like, ack! I have had so many self realizations that I often come to the party already to rock what I’ve thought through in my head.

That for me was the most poignant take away, and at least for me one of the hardest things to do.

Joel RW (Feb 17 2025 at 15:21):

At first, I thought Discovery Coding was a style of fixing a bug or writing a new feature. That freaked me out because it sounded like it would lead to willy-nilly solutions that would be hard to maintain. Then, Jimmy gave the example of when he drafted a design doc and realized that his designs did not make sense. The entire time I thought, maybe we need to talk about better analysis. Then I realized that Discovery Coding is an analysis tool. It is about better analysis. He's adding code that assists in understanding the system so that his future design ideas are more informed.

Thinking about TDD. I don't see that as a form of analysis. It's an implementation method, writing code to fix a bug or create a new feature. You could design the solution before beginning TDD or as you go, realizing how the thing works as you write acceptance criteria in the form of tests. HOWEVER, writing tests can be done for the sake of analysis. That's not TDD, that's part of the discovery process. It's the same as Jimmy's example of adding debug statements or hacking a REPL so that he can figure things out.

I think Discovery Coding might be a misnomer, only because when someone says, "I'm coding", you imagine that person is fixing a bug or creating a feature. Also, it's important to think about Outlining in the right context. Are we outlining a design or are we outlining the current behavior of the system? If we're comparing Discovery Coding to Design Outlining, then we're comparing apples and oranges.

Matthew Sanabria (Feb 20 2025 at 19:32):

This was a fun episode. I generally do discovery coding in tandem with writing a basic design document. Basic being a general outline and/or notes on what I'm thinking and running into. Then when discovery coding is done I'll write the serious design document.

Things I've found that help are:

• Keep your discovery coding time boxed. Don't just discovery code your way to the final implementation. Give yourself room to think and write down your thoughts and refactor the code. There's nothing worse than a discovery coding implementation that becomes the final production implementation without anything written down describing it. Argue all you want about "productivity" but it's really just laziness.
• Use a language that's ripe for prototyping, if applicable. I think Go really shines here with the way it does implicit interface implementation and encourages you to be more concrete with things.

Matthew Sanabria (Feb 20 2025 at 19:54):

Also love the idea of personal comments in code. I think editors can implement that but it would also be cool to see that implemented at the version control layer. Different users can commit their comments and you can fetch another user's comments in addition to the source code.

Ron Waldon-Howe (Feb 21 2025 at 00:22):

I've seen advice that strict types slow us down too much for good prototyping, but I think this is mostly a familiarity thing
And it probably depends on what you're trying to learn from your prototype
If your question is actually about a specific language or technology choice, then of course your prototype should use those
But if your question is about business logic, or product market fit, or feasibility, then you probably don't want to be learning a new technology at the same time as you're trying to explore a problem

Last updated: Apr 03 2025 at 20:18 UTC