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.
03 Sep 2025 #writing
I don’t trust most LinkedIn recommendations.
You can ask a friend or a coworker to say good things about you. And who would showcase bad comments for future employers to see? Nobody!
But, but… Today I got a LinkedIn recommendation I didn’t ask for. A reader/follower wrote this recommendation:
After reading his blog on SQL I connected with Cesar on LinkedIn , and his posts stood out for their clarity, honesty, and practical lessons. He has a ability to take real-world experiences in software engineering and turn them into valuable insights that others can learn from.
When I reached out with a career-related question, Cesar didn’t just give me a quick reply, he went the extra mile and even wrote a full article to share his perspective. That generosity and willingness to help reflect the kind of person and communicator he is. Cesar’s writing and guidance have had a direct impact on the way I think about coding, career growth, and opportunities.
I highly recommend Cesar for his exceptional writing, storytelling, and mentorship. He not only shares knowledge but also inspires others to take action and define their own paths.
It’s great to read that my words have inspired and impacted someone’s career. It means my writing has done its job.
Trying to hit the 300-post mark made me question if I should keep blogging. But that was a confirmation to keep doing it, even when it feels nobody is reading.
That recommendation made my day. And that’s another screenshot I’m adding to my “wins” folder.
02 Sep 2025 #misc
50 or 60 years ago, taking a picture was an event in and of itself.
In the past weekend, I saw dozens of photos of my mom as a teenager and young woman. But one caught my attention.
It was on her 7th birthday. She was dressed up. My grandparents took my uncle and her to the only photo studio in the city for a birthday photo. Then they took her for ice cream.
Seeing that photo made me think about how photography used to work. The photographer had very few tries to get it right. They had to wait weeks to develop the film and see the final result.
These days, we repeat the same shot as many times as we need until we get a decent picture. We tap our smartphones and see the results in seconds.
That’s true for photography, writing, and pretty much anything else. Tech has shortened our feedback loops.
01 Sep 2025 #writing
This is my daily post #304.
The 300-post mark felt hard to complete. I tried to balance multiple writing projects at once. I felt so tired at the end of the day that my writing streak almost suffer. And life threw me a huge unexpected curveball that made me miss a day. I ended up writing two posts the next day to recover.
Finding ideas to write wasn’t the challenge. It was finding the time to write.
My most-read and favorite posts
Here are some of the most-read posts from the last 100 days:
Here are my 100-post and 200-post reflections.