30 Sep 2025 #misc
With a book coming out, my next question is how to promote it.
The obvious strategy
The first (and maybe obvious) strategy I’ve found is to share everything about it.
Share when the first draft is done, the edits you left out, the book cover ideas, some excerpts, and the reviews you get. Even I found the idea of a guy who wears a “Ask me about my book” t-shirt when he goes to conferences and networking events to promote his books.
Share anything and everything about your book.
The surprising strategy
But apart from making noise, I found a surprising strategy:
Write a second or a third book.
James Altucher, one of my favorite writers, teaches that strategy in his podcast, posts, and course. “The best way to promote a book is to write another book.” Because when you like a book, you want to binge-read all other books from the same author.
That happened to me. By accident, I found one of James Altucher’s books and I almost devoured all of them. So the strategy works. It worked with me. And that’s proof enough.
29 Sep 2025 #codereview
After sharing two strategies for faster code reviews, I got a comment on Medium that captured the struggle of building a code review culture.
Here it is:
I am trying to get my team to craft smaller PRs as a means to faster reviews, but I am always bombarded with questions like these:
How can someone review the first without knowing what it will be used for? How can the reviewer have the context for the change? And what if the reviewer suggests changes to the 3rd PR that will incur changes to the second or the first?
I get the questions, and I get the pushback, but how can we find a happy middle ground?
I’ve had the same questions as the ones in the comment. I realized how painful code reviews are only after reviewing PRs. That was what made me adopt those two strategies I had already shared.
Here are my two cents to make code reviews smoother and find that “happy middle ground:”
#1. Have clear guidelines on what to review
Code reviews are pointless if we only discuss variable names or nitpick on code style.
The easy fix to avoid discussing formatting:
- Automate code style and conventions with
dotnet format, prettier, or similar tools.
- Use a sample class or module to show naming styles and conventions, instead of documentation nobody ever updates.
Instead of focusing on nitpicks, define the goal of your code reviews. Is it to mentor newcomers, enforce good practices, find bugs? Or all of the above?
#2. Always give and ask for context
At a previous team, we had the guideline to always include a JIRA ticket number in the PR title. You can adopt that one.
If you’re a reviewee, always include a good title and a short description, even if you’re linking to your JIRA ticket. Often, JIRA tickets only describe business requirements, not technical details.
Now if you’re a reviewer, feel free to pass a PR to the right team member if you don’t have enough context. Or you could take it as an advantage and approach the review process from a beginner’s perspective.
#3. Reduce ceremonies (or make PRs easy to open and merge)
At another past job, we had to fill out a form with every review.
It was a stupid rule to comply with a company certification or something. And on top of that, we didn’t have a web-based collaborative tool. The reviewer had to sit with the reviewee, go through the code, and fill out a form with the “findings.” And that was for every round of review. Arrggg!
Make PRs easy to open, review, and merge.
#4. Involve all team members
To create awareness and spread change, involve all team members, even informally.
To involve your team, steal this guideline from a past job. We only merged PRs after approvals:
- From a “default” reviewer. This was someone in charge only of code reviews across the whole company. I know most companies can’t afford this role.
- From the repository owner, if the PR went to a codebase from another team.
- From the team leader
- From another team member
I was only after my stint as a code reviewer that I learned to give valuable feedback and clean my PRs.
Code reviews should be everyone’s responsibility.
Parting thought
Let me tell you, making this kind of change is hard.
As a default code reviewer, it took me months to see people picking up the practices I was preaching, like short PRs and using Conventional Comments.
To spread the change, enforce it (like reject large PRs) or lead by example. The first one is faster. Or try combining the two: a hard rule after an educational campaign. It takes time, but it starts with one PR.
28 Sep 2025 #writing
After maybe a month, I caught up with an old friend and got a surprise critique.
The first thing he told me was, “I had some time without checking LinkedIn. I found one of your posts, but it was too long and I stopped reading midway.” We both laughed. Ouch!
When my friend said that, I realized I do the same thing. I skip big blocks of text on LinkedIn and blog posts.
Truth is, people scroll social media for dopamine, not for depth. And we should write for them, too. We should use attention-grabbing opening lines and short, well-formatted posts.
Graffiti, social media posts, essays, book chapters…They’re all different. Readers come with different goals. The platform sets its own rules and expectations. Our job is to write in a way that fits.
27 Sep 2025 #writing
I binge-watched another TV show again. And to not feel guilty, I’m writing about it.
This time, I watched Black Doves on Netflix, an espionage and action story that takes place in present-day London. The Black Doves, a private intelligence firm, placed an agent close to a top government official to steal secrets and sell them.
After binge-watching the 6 episodes, here are the writing devices I noticed:
#1. It starts with action, blood, and mystery. The first scene shows a triple killing. Enough action to hook anyone.
#2. Every episode complicates the plot more. It felt like watching The Mandalorian, where each alliance pulls Mando away from his goal. The same thing happens in this show.
A simple revenge turns into an entangled plot that involves Britain’s political stability and possibly sparks the next World War.
#3. Almost every episode starts with a time jump to show us the background story of our characters. We see how Helen is recruited and how she turns from an amateur agent into a cold-blooded killer with a double life.
#4. It uses flashbacks to tell us when Helen is lying. The Black Doves have one rule they take seriously: nobody should know about the existence of the organization. But Helen broke this rule and she lies about it all the time. And through flashbacks, we see the truth.
#5. Instead of an omniscient narrator, we get to know about Helen’s past through an interview. She applies to an international company, where her past is questioned during the interview. We get to know her without boring dialog or narration. Clever trick!
#6. They use a line as a connecting element. “If one door closes, a window opens elsewhere,” or something like that. We hear it in almost every episode. It keeps the plot going in spite of every setback.
Other TV show breakdowns? Not Really on Purpose, House M.D., and Six Triple Eight.
26 Sep 2025 #mondaylinks
Hey there.
Here are 4 links I thought were worth sharing this week:
#1. Being a good tech leader isn’t about knowing all the answers. Here’s how a good leader leads a room full of expert (7min). I loved this piece so much that I wrote a reaction post.
#2. Ten years ago, the junior me wanted to optimize every line of code. Newbie mistake. I wish I had found this guide with 9 things every graduate should know about performance (5min).
#3. Hey this is kind-of a pitch, but the new coding gig is vibe-coding clean up (6min). It doesn’t sound that bad.
#4. Without getting into politics, here’s a breakdown of how it’s like using online services from a “banned” country (6min). Well, from that posts I learned about a HTTP response code.
And in case you missed it, I wrote on my blog about the first step for reinvention when we feel lost (2min) and I reacted to how to lead in a room full of experts (3min).
(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.