02 Oct 2025 #misc
Join the LinkedIn creator crowd and you’ll hear one tired phrase everywhere.
“Consistency is key.”
One influencer said it, and everybody trying to sound smart repeated it. And now it’s everywhere.
I roll my eyes every time I see it, not because it’s wrong, but because it’s overused. It’s the “synergies,” “alignment,” and “disruption.” It’s the corporate lingo nobody uses it in a real conversation.
I’m so sick of it, I had to rephrase it.
Here are my 7 alternatives to “Consistency is key:”
- Don’t break the posting chain
- Show up as if your life depends on it
- No successful brand was built in a day
- Post until people recognize you from the feed
- Show up until it becomes second nature
- You only lose if you stop playing
- Just keep doing it
I promise I won’t say “Consistency is key” again. Because every time we say it, a cute baby panda dies in the forest. Let’s save pandas by retiring this and other overused clichés for good.
01 Oct 2025 #writing #books
Imagine an FBI agent arresting a Nazi spy while someone else urges his country to declare war against Germany.
That’s not a Netflix show. It’s a true story Fernando Labastida shared on LinkedIn. The two men were his grandparents. Here’s the original post.
When I read Fernando’s post, my first thought was “this should be a book.” Who wouldn’t like to read a story about arresting Nazis and the political discussions about Mexico entering WWWII? Yes, this story happened in Mexico.
I suggested he write a book, along with a list of mini-stories to include in that book:
- Each of his granddads’ backstories.
- The main event of their lives: arresting the Nazi spy and starting the movement to go to war.
- The crossing point of the two stories. Their daughter and son, respectively, got married. And 40 years later, a family wedding took place in the same building where the Nazi spy was captured.
- A summary of what was happening at that time in Mexico and the other places where the story took place. It turns out that a German U-boat sank a Mexican oil tanker.
- A story of how Fernando found out about his granddads.
I found that story so intriguing that I imagined the first scene of a book or TV show:
One of his granddads packs to go to Mexico after briefing the FBI top officials, while the other rehearses a speech he’s about to give in Mexico City’s main square. Of course, that’s with time jumps and scene breaks.
Fernando said his granddads have passed away, and only a few relatives know the full story. That story could get lost in newspapers and government archives only journalist read, if he doesn’t write it.
A book is the best way to preserve family stories and honor our loved ones. There’s no need to write a New York Times bestseller to tell family stories. Even if only our future kids and grandkids read it, that’s enough to keep the story alive.
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.