July 10, 2026 • 15 mins
Recap of my week, with several different topics where I expanded my knowledge or surfaced some recurring patterns in my efforts.
Highlights:- Repeated prompt iteration can cause LLMs to get stuck in unhelpful loops or produce slightly different code on reruns. Restoring to a checkpoint helps reset context and regenerate cleaner output.
- A personal AI workflow shortcut: using chat models to brain dump and organize ideas into structure before writing.
- Pet projects. Alongside expanding a Goodreads project, there's a potential new personal improvement app idea
- Other tasks: session review for NODES conference, upcoming refresh work on a Knowledge Graph e-book, and plans for short-form video content.
- Article: “Read Less, Steer More” by Ezyang on mentoring code reading, using LLMs to explain code, avoiding auto-accept edits, and writing code by hand when learning fundamentals.
Listen
Watch
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Jennifer Reif (00:05):
You are listening to the Breaktime Tech Talks podcast, a bite-sized
tech podcast for busy developers wherewe'll briefly cover technical topics, news
snippets, and more in short time blocks.
I'm your host, Jennifer Reif, anavid developer and problem solver
with special interest in data,learning, and all things technology.
When I started planning for this episode,I was afraid that I wouldn't have
(00:28):
much to talk about, but here I am withwhat is looking like a full episode.
An added bonus of documenting myweek through this podcast is that
I actually sit down and realize thethings that I accomplish or even
just chipped in on during the week.
I've noticed a common pattern whilebuilding code samples with large
language models for the book, andI also have a consistent part of my
(00:50):
workflow where AI shortcuts my efforts.
I have a few other projects I am jugglingthat I'll mention, and then I found a
relevant article that frames effortsaround technical learning, mentoring,
and work in the current industry.
Grab a cup of your favorite beverage,or at least get settled in for a
few minutes, and I'll fill you in.
Starting us off, I have been workingon the book still, and that's a
(01:14):
common theme that's been comingup if you've been listening to the
podcast for weeks or months now.
If you're not familiar, it's an AI,focused Java book, and I'm working
with a large language model in orderto help build some of the code samples.
As I'm assembling the prompts, I'mtesting those prompts multiple times
usually, maybe with some tweaks.
(01:35):
And sometimes I just wanna adjustmy wording to make it a little bit
more clear, either to the readeror I don't wanna give too much
context or too little context inthe way that I construct the prompt.
Or sometimes I also want to direct theLLM correctly or make the syntax a bit
more clear to the large language model.
So I will back out the changesand run things multiple times.
(01:58):
Now, early on, several weeks,months ago, I noticed that
this was rather challenging.
You would get in these inevitable loopsthat the large language model would
kinda get stuck in, your coding chat Itwould kinda get stuck, and the more you
would iterate, the more you would tryto fix things or try again or get it
to do something it had generated beforebut you'd backed out, the more it would
(02:22):
just spiral and dig the hole worse.
Often you would have to cleaneverything completely out.
You'd have to close the entire applicationdown, try to let it clear its context a
bit, and then come back and reapproach it.
Not only was your brain a little bitfresher and coming from a different
perspective, but the large languagemodel also kinda cleared some of
that looping context out a bit.
(02:44):
And then things would gousually a little bit better.
I have noticed that, inevitably, as yourun something multiple times, the code
that gets generated slightly alterseach time that you run that same prompt.
So if you have something, you removethe changes, you tweak the prompt a
(03:05):
little bit, you run it again, even ifthe output should be pretty consistent-
it's almost like it thinks that, "Oh,she didn't like the code written this
way. Maybe she wanted it written thisway instead." And so very minor tweaks,
like syntax squabbles really, of maybeI need to add this extra variable here,
(03:26):
or maybe the print statement shouldbe more like this, or maybe she wants
a for loop versus a, something else.
Who knows?
This can be really nice when I'm lookingfor something specific, and the initial
run or two isn't getting me there.
But this can also be a bit annoyingwhen the initial code is exactly how
I would write it and what I wanted.
I just want to verify atweak in the prompt doesn't
(03:49):
change that output too much.
And so then you're left with, actually,I liked the way it was generated the
first time around, but now if I tweakthis prompt just a little bit to make
the prompt better, now I'm gettingslightly altered syntax, even though
they practically do the same thing.
It's almost like it just haschanged very minor things.
Another nice feature, at least in Copilotright now, is that I can restore at a
(04:14):
specific checkpoint, which I'm guessingunder the hood is like chopping the memory
and the code back to a certain spot.
This has been working really well forregenerating a code example, because
hopefully, at least in my mind,it clears out the context that can
sometimes muddy the large languagemodel's generation capabilities.
(04:35):
So restoring from checkpoint islike hitting the Back button on your
browser or like a Go Back or Undo,where it chops that back and starts
fresh at a previous point in time.
This can be really helpful when I wannago back to before I even ran a certain
prompt and try it fresh with a correctedsyntax or an adjusted wording on my part,
(04:58):
and hopefully that clears all that outand lets it generate something better,
cleaner, maybe the same code that itinitially generated, but I had to improve
my prompt before it could get there.
All right, so that's that one.
Another one is that I've found myselfdefaulting to a specific use of AI in
(05:18):
my workflow throughout different tasks.
One of the strongest useswhere I plug AI in right now is
organizing my ideas on something.
Through school and throughout training,you might see advice that you brain
dump first, and then you organize yourthoughts after you get them down on paper.
You start just brain dumping everything,and then you organize those and put those
(05:41):
into actual comprehensible thoughts.
I've noticed myself doing this with AI,giving the, a chat model a, my brain dump
and then working back and forth with thechat model to organize those thoughts.
When I want to communicate something,whether that's writing or putting together
a paragraph, I will brain dump my idea.
(06:04):
Here's what I want.
Here's the tone.
Here's what I'm thinking.
How should I structure this?
Or what do you think about this?
How should I incorporate this thought intothis post that I already put together?
And it does a pretty good job sortingand organizing through things, and
then I can clean that up and fillin the blanks and refine that.
I do find that I go back and forthquite a bit, refining those ideas
(06:27):
in the chat until I come up withsomething that I really want.
For instance, when I'mtrying to outline something.
Let's take a blog post as an example.
I will dump a bunch of ideas.
Hey, I want to talk about thisthing and that thing, and here's,
I really found this perspectiveon this topic really cool.
I want to make sure I plug that inthere, And I'll dump all that in and
then work through, and it'll take allthat information and summarize it and
(06:49):
put it together in a structured format.
And then I go back and go, "Eh,oh, I don't really care for this.
Let me tweak this.
Let me move this around.
I'd really like to take this perspectiveor this angle on this section," and so on.
And I work through something untilI refine that and put together a
nice list of ideas or an outlineor whatever it happens to be.
(07:12):
Then I actually go backand write the content.
The chat tools really just help meorganize my thoughts better and faster
than if I had to do that all by hand, asI used to do when I would write papers
and essays and long-form communications,earlier on in my career and in my studies.
To change topics here, I don'treally have a pet project right now.
(07:34):
And yes, I do currently have a bookthat I'm writing, which does leave very
little room for additional projects.
But I have felt like a lot of peoplehave pet projects going on that are
really cool and really interesting, andthey're really excited about, and I just
didn't feel like I really had something.
I've got this Goodreads project thatI've been working on, and there are
(07:57):
several more capabilities and featuresthat I really wanna add to that, that
I'm starting to get excited about.
Again, just finding the time.
But this week, I bubbledup another fun idea.
I have another personal improvementproject that I'm thinking about building.
I don't really wanna drop any spoilersjust yet, but hopefully I will have
some time to at least start on a fewof the initial steps soon, and at
(08:21):
that point, I'm happy to fill youin and give you some more details.
They always tell you to build the appthat you feel would help yourself out,
but I always felt like there was anexisting solution for everything, or that
I had a decent enough process or set oftools to handle the things that I did.
Never really saw a perfect opportunity,but I may have found one as a way to
(08:44):
optimize something that I'm working on indaily, monthly, yearly, quarterly life.
So I'll fill you in on that soon.
The other things that are on my plate.
I have, Nodes session review, which Iwrapped up my piece of that, so some NODES
updates hopefully will be coming soon.
I will keep you informed on the nextsteps and what's going on there.
(09:07):
We also have some updates and reviewcoming for the Knowledge Graph e-book.
If you're not familiar, I helpedco-author an e-book several
months ago that was released.
But a lot has changed in the lastseveral months, so we're looking at
refreshing some of that and gettingthat up to date and having a launch or
a refresh release on that coming soon.
I'll… Again, I'll keep you informed.
(09:28):
And then I have some more shortform content coming soon, which
I'm kind of excited about.
I've always wanted to do a little bitmore video work, and this would give
me some opportunities to do that.
I'm working through draftingsome of my ideas right now.
I just need to sit down and record and dosome post-processing work on those before
they will hopefully be ready to go out.
(09:49):
The article that I read this week iscalled Read Less, Steer More by Ezyang.
The whole site in generalis pretty minimalist.
It's a list of blog posts.
However, I really thought this articlewas short and sweet and had a couple
of little tidbits that were nice.
First is that overall, it talks about thementoring perspective on how to read code.
(10:13):
This person was mentoring somepeople on how to read code and
review the code, because we'rewriting less code by hand, right?
We tend to let codingagents do those things.
Then we spend more time reviewing,debugging, checking, tweaking code than we
do writing all of the code from scratch.
(10:34):
The author recommends actuallycommunicating with the large
language model to have it justifyor explain its code in bits.
Now, I find that this is reallyinteresting that this piece is shifting.
Before, when I would review code atleast, probably others have been in the
same boat as well, we might hesitateto ask the original developer questions
(10:58):
because we don't want to appear inept orlike we don't understand something, or
like we're being a bother or questioningthe process or over-questioning
the changes that were made.
Sometimes we might ask a question ortwo, but we don't dig in too deeply.
However, with an LLM, thatinhibition is much less, and I have
found this to be true of myself.
(11:19):
When I walk through coding changesor I'm working with a coding agent to
build something, I'm much less nervousor actually not nervous at all to ask
the large language model, "Hey, what isthis thing doing and why would we use
that here? Wouldn't it be better to goabout this way?" With a human developer,
I might not ask those questions, orat least not near as many of them.
(11:43):
I thought the recommendation inthe article was also good to turn
off the auto-accept edits, andeven to write some code by hand,
especially when you're starting out.
I find this valuable personallywhen I'm learning something brand
new, and I really want to know andunderstand the ins and outs of it.
Something that is a one-off project,maybe It's just like a hack together,
(12:05):
get me someplace really quickly,then I might not care as much.
But if I'm trying to learn somethingspecific about how an integration
works or how something in Java works,I'm much more interested in learning
the foundations and understandingwhat's going in and how it's working.
When you are learning something,it can be extremely beneficial to
(12:26):
do it by hand once or a few timesuntil you get the feel of it.
As an example, when I was learning aninstrument growing up, I would practice
something new very slowly, and if itwas really complicated, I would break it
apart and focus on the form in this way,and then the tone, and then moving in a
(12:48):
specific way to get this particular sound.
And you assemble all those piecestogether, and eventually you can
play it fast without thinking.
But if you dive right into somethingnew, and you expect to be able to play
it like a professional performing onstage, you're just not going to get there.
It's the same thing with coding.
You don't necessarily want to dive inand use a coding agent to build something
(13:09):
from scratch right out of the gate.
If you really want to understand thosespecific pieces of whatever you're working
on or the technologies you're using, thenyou need to build some of those pieces
by hand or at least some lines of it tounderstand how all that fits together.
I thought of this analogy.
Maybe agents are like riding a bike.
You have to practice with trainingwheels, now kids are often using balance
(13:31):
bikes, first, and then you graduateon up to using an bike with pedals and
brakes, and maybe you start workingon tricks, but you can't start there.
This also encourages me becausemy recent GraphRAG training still
focuses on the inner workings of howretrieval-augmented generation works.
So it starts with very manual, here'show this is working under the hood, even
(13:55):
though there are lots of nice abstractionson top that simplify the interactions.
I wondered if that was still valuablebecause I just gave that training
a week or two ago, and I reallythought hard about do I want to
shift the way that I workshop this?
Is this hands-on, down in the weedscode still valuable since many people
(14:19):
are now working with far more complexarchitectures, things like agents and MCP
and memory and all sorts of other things.
However, I do find it incrediblyvaluable to back up and learn
those building blocks, and thenyou can build the skyscraper, and
this article reminded me of that.
I really enjoy this.
I hope you get some value out of this too.
This week, I picked upsome recurring themes.
(14:42):
AI can get stuck in a tweakingloop when faced with repetitive
prompt testing, but there are acouple of tools to handle that.
I also turn to chat modelsto organize my thoughts.
Finally, I read a short article thatgave me a good perspective on how
learning and mentoring is shifting.
The weight of coding skills mightbe less but the article gave some
insight into how we review code.
(15:02):
Thanks for listening, and happy coding.
You are listening to the Breaktime Tech Talks podcast, a bite-sized
tech podcast for busy developers wherewe'll briefly cover technical topics, news
snippets, and more in short time blocks.
I'm your host, Jennifer Reif, anavid developer and problem solver
with special interest in data,learning, and all things technology.
When I started planning for this episode,I was afraid that I wouldn't have
(00:28):
much to talk about, but here I am withwhat is looking like a full episode.
An added bonus of documenting myweek through this podcast is that
I actually sit down and realize thethings that I accomplish or even
just chipped in on during the week.
I've noticed a common pattern whilebuilding code samples with large
language models for the book, andI also have a consistent part of my
(00:50):
workflow where AI shortcuts my efforts.
I have a few other projects I am jugglingthat I'll mention, and then I found a
relevant article that frames effortsaround technical learning, mentoring,
and work in the current industry.
Grab a cup of your favorite beverage,or at least get settled in for a
few minutes, and I'll fill you in.
Starting us off, I have been workingon the book still, and that's a
(01:14):
common theme that's been comingup if you've been listening to the
podcast for weeks or months now.
If you're not familiar, it's an AI,focused Java book, and I'm working
with a large language model in orderto help build some of the code samples.
As I'm assembling the prompts, I'mtesting those prompts multiple times
usually, maybe with some tweaks.
(01:35):
And sometimes I just wanna adjustmy wording to make it a little bit
more clear, either to the readeror I don't wanna give too much
context or too little context inthe way that I construct the prompt.
Or sometimes I also want to direct theLLM correctly or make the syntax a bit
more clear to the large language model.
So I will back out the changesand run things multiple times.
(01:58):
Now, early on, several weeks,months ago, I noticed that
this was rather challenging.
You would get in these inevitable loopsthat the large language model would
kinda get stuck in, your coding chat Itwould kinda get stuck, and the more you
would iterate, the more you would tryto fix things or try again or get it
to do something it had generated beforebut you'd backed out, the more it would
(02:22):
just spiral and dig the hole worse.
Often you would have to cleaneverything completely out.
You'd have to close the entire applicationdown, try to let it clear its context a
bit, and then come back and reapproach it.
Not only was your brain a little bitfresher and coming from a different
perspective, but the large languagemodel also kinda cleared some of
that looping context out a bit.
(02:44):
And then things would gousually a little bit better.
I have noticed that, inevitably, as yourun something multiple times, the code
that gets generated slightly alterseach time that you run that same prompt.
So if you have something, you removethe changes, you tweak the prompt a
(03:05):
little bit, you run it again, even ifthe output should be pretty consistent-
it's almost like it thinks that, "Oh,she didn't like the code written this
way. Maybe she wanted it written thisway instead." And so very minor tweaks,
like syntax squabbles really, of maybeI need to add this extra variable here,
(03:26):
or maybe the print statement shouldbe more like this, or maybe she wants
a for loop versus a, something else.
Who knows?
This can be really nice when I'm lookingfor something specific, and the initial
run or two isn't getting me there.
But this can also be a bit annoyingwhen the initial code is exactly how
I would write it and what I wanted.
I just want to verify atweak in the prompt doesn't
(03:49):
change that output too much.
And so then you're left with, actually,I liked the way it was generated the
first time around, but now if I tweakthis prompt just a little bit to make
the prompt better, now I'm gettingslightly altered syntax, even though
they practically do the same thing.
It's almost like it just haschanged very minor things.
Another nice feature, at least in Copilotright now, is that I can restore at a
(04:14):
specific checkpoint, which I'm guessingunder the hood is like chopping the memory
and the code back to a certain spot.
This has been working really well forregenerating a code example, because
hopefully, at least in my mind,it clears out the context that can
sometimes muddy the large languagemodel's generation capabilities.
(04:35):
So restoring from checkpoint islike hitting the Back button on your
browser or like a Go Back or Undo,where it chops that back and starts
fresh at a previous point in time.
This can be really helpful when I wannago back to before I even ran a certain
prompt and try it fresh with a correctedsyntax or an adjusted wording on my part,
(04:58):
and hopefully that clears all that outand lets it generate something better,
cleaner, maybe the same code that itinitially generated, but I had to improve
my prompt before it could get there.
All right, so that's that one.
Another one is that I've found myselfdefaulting to a specific use of AI in
(05:18):
my workflow throughout different tasks.
One of the strongest useswhere I plug AI in right now is
organizing my ideas on something.
Through school and throughout training,you might see advice that you brain
dump first, and then you organize yourthoughts after you get them down on paper.
You start just brain dumping everything,and then you organize those and put those
(05:41):
into actual comprehensible thoughts.
I've noticed myself doing this with AI,giving the, a chat model a, my brain dump
and then working back and forth with thechat model to organize those thoughts.
When I want to communicate something,whether that's writing or putting together
a paragraph, I will brain dump my idea.
(06:04):
Here's what I want.
Here's the tone.
Here's what I'm thinking.
How should I structure this?
Or what do you think about this?
How should I incorporate this thought intothis post that I already put together?
And it does a pretty good job sortingand organizing through things, and
then I can clean that up and fillin the blanks and refine that.
I do find that I go back and forthquite a bit, refining those ideas
(06:27):
in the chat until I come up withsomething that I really want.
For instance, when I'mtrying to outline something.
Let's take a blog post as an example.
I will dump a bunch of ideas.
Hey, I want to talk about thisthing and that thing, and here's,
I really found this perspectiveon this topic really cool.
I want to make sure I plug that inthere, And I'll dump all that in and
then work through, and it'll take allthat information and summarize it and
(06:49):
put it together in a structured format.
And then I go back and go, "Eh,oh, I don't really care for this.
Let me tweak this.
Let me move this around.
I'd really like to take this perspectiveor this angle on this section," and so on.
And I work through something untilI refine that and put together a
nice list of ideas or an outlineor whatever it happens to be.
(07:12):
Then I actually go backand write the content.
The chat tools really just help meorganize my thoughts better and faster
than if I had to do that all by hand, asI used to do when I would write papers
and essays and long-form communications,earlier on in my career and in my studies.
To change topics here, I don'treally have a pet project right now.
(07:34):
And yes, I do currently have a bookthat I'm writing, which does leave very
little room for additional projects.
But I have felt like a lot of peoplehave pet projects going on that are
really cool and really interesting, andthey're really excited about, and I just
didn't feel like I really had something.
I've got this Goodreads project thatI've been working on, and there are
(07:57):
several more capabilities and featuresthat I really wanna add to that, that
I'm starting to get excited about.
Again, just finding the time.
But this week, I bubbledup another fun idea.
I have another personal improvementproject that I'm thinking about building.
I don't really wanna drop any spoilersjust yet, but hopefully I will have
some time to at least start on a fewof the initial steps soon, and at
(08:21):
that point, I'm happy to fill youin and give you some more details.
They always tell you to build the appthat you feel would help yourself out,
but I always felt like there was anexisting solution for everything, or that
I had a decent enough process or set oftools to handle the things that I did.
Never really saw a perfect opportunity,but I may have found one as a way to
(08:44):
optimize something that I'm working on indaily, monthly, yearly, quarterly life.
So I'll fill you in on that soon.
The other things that are on my plate.
I have, Nodes session review, which Iwrapped up my piece of that, so some NODES
updates hopefully will be coming soon.
I will keep you informed on the nextsteps and what's going on there.
(09:07):
We also have some updates and reviewcoming for the Knowledge Graph e-book.
If you're not familiar, I helpedco-author an e-book several
months ago that was released.
But a lot has changed in the lastseveral months, so we're looking at
refreshing some of that and gettingthat up to date and having a launch or
a refresh release on that coming soon.
I'll… Again, I'll keep you informed.
(09:28):
And then I have some more shortform content coming soon, which
I'm kind of excited about.
I've always wanted to do a little bitmore video work, and this would give
me some opportunities to do that.
I'm working through draftingsome of my ideas right now.
I just need to sit down and record and dosome post-processing work on those before
they will hopefully be ready to go out.
(09:49):
The article that I read this week iscalled Read Less, Steer More by Ezyang.
The whole site in generalis pretty minimalist.
It's a list of blog posts.
However, I really thought this articlewas short and sweet and had a couple
of little tidbits that were nice.
First is that overall, it talks about thementoring perspective on how to read code.
(10:13):
This person was mentoring somepeople on how to read code and
review the code, because we'rewriting less code by hand, right?
We tend to let codingagents do those things.
Then we spend more time reviewing,debugging, checking, tweaking code than we
do writing all of the code from scratch.
(10:34):
The author recommends actuallycommunicating with the large
language model to have it justifyor explain its code in bits.
Now, I find that this is reallyinteresting that this piece is shifting.
Before, when I would review code atleast, probably others have been in the
same boat as well, we might hesitateto ask the original developer questions
(10:58):
because we don't want to appear inept orlike we don't understand something, or
like we're being a bother or questioningthe process or over-questioning
the changes that were made.
Sometimes we might ask a question ortwo, but we don't dig in too deeply.
However, with an LLM, thatinhibition is much less, and I have
found this to be true of myself.
(11:19):
When I walk through coding changesor I'm working with a coding agent to
build something, I'm much less nervousor actually not nervous at all to ask
the large language model, "Hey, what isthis thing doing and why would we use
that here? Wouldn't it be better to goabout this way?" With a human developer,
I might not ask those questions, orat least not near as many of them.
(11:43):
I thought the recommendation inthe article was also good to turn
off the auto-accept edits, andeven to write some code by hand,
especially when you're starting out.
I find this valuable personallywhen I'm learning something brand
new, and I really want to know andunderstand the ins and outs of it.
Something that is a one-off project,maybe It's just like a hack together,
(12:05):
get me someplace really quickly,then I might not care as much.
But if I'm trying to learn somethingspecific about how an integration
works or how something in Java works,I'm much more interested in learning
the foundations and understandingwhat's going in and how it's working.
When you are learning something,it can be extremely beneficial to
(12:26):
do it by hand once or a few timesuntil you get the feel of it.
As an example, when I was learning aninstrument growing up, I would practice
something new very slowly, and if itwas really complicated, I would break it
apart and focus on the form in this way,and then the tone, and then moving in a
(12:48):
specific way to get this particular sound.
And you assemble all those piecestogether, and eventually you can
play it fast without thinking.
But if you dive right into somethingnew, and you expect to be able to play
it like a professional performing onstage, you're just not going to get there.
It's the same thing with coding.
You don't necessarily want to dive inand use a coding agent to build something
(13:09):
from scratch right out of the gate.
If you really want to understand thosespecific pieces of whatever you're working
on or the technologies you're using, thenyou need to build some of those pieces
by hand or at least some lines of it tounderstand how all that fits together.
I thought of this analogy.
Maybe agents are like riding a bike.
You have to practice with trainingwheels, now kids are often using balance
(13:31):
bikes, first, and then you graduateon up to using an bike with pedals and
brakes, and maybe you start workingon tricks, but you can't start there.
This also encourages me becausemy recent GraphRAG training still
focuses on the inner workings of howretrieval-augmented generation works.
So it starts with very manual, here'show this is working under the hood, even
(13:55):
though there are lots of nice abstractionson top that simplify the interactions.
I wondered if that was still valuablebecause I just gave that training
a week or two ago, and I reallythought hard about do I want to
shift the way that I workshop this?
Is this hands-on, down in the weedscode still valuable since many people
(14:19):
are now working with far more complexarchitectures, things like agents and MCP
and memory and all sorts of other things.
However, I do find it incrediblyvaluable to back up and learn
those building blocks, and thenyou can build the skyscraper, and
this article reminded me of that.
I really enjoy this.
I hope you get some value out of this too.
This week, I picked upsome recurring themes.
(14:42):
AI can get stuck in a tweakingloop when faced with repetitive
prompt testing, but there are acouple of tools to handle that.
I also turn to chat modelsto organize my thoughts.
Finally, I read a short article thatgave me a good perspective on how
learning and mentoring is shifting.
The weight of coding skills mightbe less but the article gave some
insight into how we review code.
(15:02):
Thanks for listening, and happy coding.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
Betrayal Weekly
Betrayal Weekly is back for a new season. Every Thursday, Betrayal Weekly shares first-hand accounts of broken trust, shocking deceptions, and the trail of destruction they leave behind. Hosted by Andrea Gunning, this weekly ongoing series digs into real-life stories of betrayal and the aftermath. From stories of double lives to dark discoveries, these are cautionary tales and accounts of resilience against all odds. From the producers of the critically acclaimed Betrayal series, Betrayal Weekly drops new episodes every Thursday. If you would like to share your story, you can reach out to the Betrayal Team by emailing them at betrayalpod@gmail.com and follow us on Instagram at @betrayalpod and @glasspodcasts. Please join our Substack for additional exclusive content, curated book recommendations, and community discussions. Sign up FREE by clicking this link Beyond Betrayal Substack. Join our community dedicated to truth, resilience, and healing. Your voice matters! Be a part of our Betrayal journey on Substack.