08 Sep 2025 #books
I’ve been binge-watching Ryan Holiday’s Daily Stoic YouTube channel lately.
If you don’t know about his work, he reads and writes books for a living. He wrote The Obstacle is the Way and Life of the Stoics. And just the other day, I watched his appearance on Joe Rogan’s show.
After watching his videos with reading advice, here are 8 lessons I learned:
#1. Read physical books. That’s an excuse to spend less time in front of screens.
#2. Prefer old books. Focus on books that have stood the test of time. If they have survived this long, they will survive a whole lot more.
#3. Reread. I had to change my mind about rereading. I was against it when I tried to grow a large list of books I’d read. When we reread a book, our circumstances have changed. Every time we revisit a book, it’s an opportunity to learn or notice new insights.
#4. Have mentors to point you to more books. If you can’t find one, find a not-mentor instead.
#5. “Not all readers are leaders, but all leaders are readers.” That’s a quote attributed to Harry Truman, one of the U.S. presidents.
#6. Don’t speed read. To read faster, we need to read more. Simple as that.
#7. Interact with the book you’re reading. Reading a book is like a conversation with the author. Highlight, fold corners, and take notes in the margins.
#8. Use notecards for notes. After a break, go back to the parts you highlighted or the pages you folded, and turn those interesting passages into notes. Ryan’s note-taking system sounds like Luhmann’s Zettelkasten method.
And if you want to read more, here are 8 easy-to-implement tips to read one book a week.
07 Sep 2025 #misc
I’ve been binge-watching Ryan Holiday’s videos.
YouTube took me to his appearance on the Joe Rogan Experience
I watched the whole 2-hour video over a couple of days. It’s long and not always about stoicism and books. But there was a gem I found really inspiring.
Joe shared his “secret:” he only invites guests he finds interesting and his only metric is if he does something engaging and entertaining for his audience.
He started the podcast to meet interesting people. And even after it made money, he kept the same strategy.
I’ve been writing online for years. A big follower count seems attractive. But that interview reminded me to stay grounded. Do interesting things and have fun. Everything else is a plus.
Oh, this reminded me of the creative rules from the guys behind Field Notes.
06 Sep 2025 #coding
I’m not an AI evangelist, and I’m not a hater either.
I’ve tried AI for coding. And after a week or two, I noticed how dependent I was becoming. Since then, I’ve used AI for small coding tasks, like generating small functions or finding typos, not to treat English as my main programming language.
Marcus Hutchins, a security researches, puts it boldly in his post Every Reason Why I Hate AI and You Should Too:
I’d make a strong argument that what you shouldn’t be doing is “learning” to do everything with AI. What you should be doing is learning regular skills. Being a domain expert prompting an LLM badly is going to give you infinitely better results than a layperson with a “World’s Best Prompt Engineer” mug.
I agree with the core message. When everybody is relying on AI, it’s time to go back to old-school habits:
- Read code
- Write trustworthy tests
- Devour classic textbooks
- Troubleshoot bugs with pen and paper
And outside coding: read books on paper, take notes by hand, and write our own summaries. To develop taste and judgment.
Using AI is like holding a calculator on a math exam. Even the best calculator is useless if you don’t know what to compute, it’s pretty much useless. Build skills, then leverage AI.
I used to think coding was only about cracking symbols. That’s where AI shines. But coding is also about talking to non-tech managers, negotiating deadlines, and saying no politely.
And that’s why I wrote, Street-Smart Coding: 30 Ways to Get Better at Coding, to share the skills I wish I’d learned to become a confident coder.
Get your copy of Street-Smart Coding here. It’s the roadmap I wish I had when I was starting out.
05 Sep 2025 #mondaylinks
Hey, quick update from my side before sharing the usual four links:
I’m writing a book.
Yes, a book. One with 30 lessons to get better at coding. Those are the lessons I wish I had on my way from Junior to Senior. I’ll share more details in future emails.
OK, the four links as usual:
#1. If every company wants to hire “the best engineers” (5min), who hires the rest of us?
#2. AI can’t replace coders for real anytime soon. Here are five AI screwups (12min) that prove we’re not there yet.
#3. We shouldn’t blindly follow guidelines. Here’s a breakdown of one: doing the simplest things (11min).
#4. Here’s an interesting way of repurposing an old phone into an ereader (15min).
And in case you missed it, I wrote on my blog about two strategies for faster code reviews (3min) and six pieces of advice I wish I had before going to college (2min).
(Bzzz…Radio voice) This email was brought to you by… Check my Gumroad store to access free and premium books and courses to level up your coding skills and grow your software engineering career.
See you next time,
Cesar
Want to receive an email with curated links like these? Get 4 more delivered straight to your inbox every Friday. Don’t miss out on next week’s links. Subscribe to my Friday Links here.
04 Sep 2025 #codereview
Two days into my last full-time job, I thought I had finished my first task. I was wrong.
At my previous job, I was used to going fast and breaking things. But that wasn’t the case anymore. After telling my team leader I was done, they ripped my code apart. I had to rewrite it almost entirely. No stored procedures. New naming conventions. Unit tests. That was my welcoming code review session.
A couple of years after my first code review, I learned the unwritten rules and became one of the company’s “default” code reviewers. Yes, it took quite some time.
As a default reviewer, I had the chance to review code from people outside my team. And after dozens of review sessions, I started to notice some patterns that made me change my reviewing strategy.
1. Follow Pull-Request Driven Development
Occasionally, someone opened a pull request (PR) with thousands of lines.
After noticing that, I adopted Pull-Request Driven Development (PRDD). Before starting a task, think of how to split and organize your changes so they’re easy to review.
Instead of a monstrous PR, split your changes into small, working PRs anyone can review in under five minutes.
And if a task spans multiple projects, label and cross-reference each change for easier navigation. If you’re adding a new field to a form, create three separate PRs:
- PR 1/3 adds the new field
- PR 2/3 updates the REST API
- PR 3/3 changes the database schema.
You can even use “PR #/3” as a title to make things easier for your reviewers.
2. Give clear and actionable feedback
There was another pattern I noticed as a code reviewer: sometimes it took about 24 hours to get a pull request approved and merged.
Some reviewers used “pushy” questions that only hinted at a request for a change. Questions like “What if this parameter is null?” weren’t clear enough. Was the reviewer asking for a change or simply starting a discussion? And since most of us were in different time zones, any interaction took about half or even an entire day.
Those long code review sessions made me adopt three guidelines:
- Write clear and unambiguous comments.
- Always leave a suggestion with each comment.
- Distinguish between actionable items and suggestions.
That strategy turned a comment like “What if this parameter is null?” into “Is it possible that this parameter could be null? If that’s the case, please add the appropriate null checks.”
I kept using that strategy inside my team, after my reviewer rotation ended. And I noticed how other reviewers picked it up as well. Point for preaching by example!
Parting thought
Code reviews feel like a pain in the neck. I know!
But until we put our code in front of others, we might think we’re writing the best code we’ve ever written, just like me before joining my last full-time job.
Code reviews reveal how grumpy and opinionated we as coders can be when talking about code, arguing about variable names, code style, and best practices. Yes, often the stereotype is true.
Sometimes you might want to remote choke your reviewers with the Force. But code reviews don’t just improve your code, they teach you to grow a thick skin and soften your ego.