Just Some Code

Kangaroos And The Road Sign (A 100-Word Fiction Story Inspired By a Photo)

2026-05-09T00:00:00+00:00

Here’s May photo prompt from 100 word story and my story.

Nullarbor Warning Sign. Photo by Chris Fithall on flickr.com

When some friends came over and you had some beers…

Every five minutes I asked, “Dad, when are we going to see kangaroos?”

I was 5 or 6. I had read every kangaroo book in the library.

My dad had rented a car. I didn’t care about Sydney and the Opera House. I only wanted to see kangaroos.

I don’t remember where we were, but we heard, puff!…and the car stopped. OMG! Smoke everywhere, hot as hell. “And the kangaroos?” I started to cry.

My dad crossed the road and took this picture. That was the only kangaroo I saw in Australia.

I’ll never rent a car. Ever.

Friday Links: Coding sucks, inverse laws of robotics, and Chrome surprises

2026-05-08T00:00:00+00:00

Hey there.

Here are 4 links I thought were worth sharing this week:

#1. Coding sucks (9min) It’s not like building a house, but like jumping into a ship, nobody knows where it goes…And no, AI didn’t take our jobs. It was something else.

#2. Isaac Asimov created three laws for robots to interact with humans. If you’ve watched I Robot, you already know them. And here are three inverse laws for humans to interact with AI (9min).

#3. Did you know that Chrome installs a 4GB AI model (30min) without asking you?…And if you delete it, it installs it again. Surprise!

#4. I already knew about robots.txt, but there’s a whole folder to host those files (2min).

And in case you missed it, I wrote on my blog about why Star Wars is the best saga (3min) and 7 interesting but random ideas I found (2min).

(Bzzz…Radio voice) This email was brought to you by… Street-Smart Coding, 30 lessons to help you code like a pro. From Googling to clear communication, it shares the lessons to help you stand out in the age of AI.

May the Force be with you,

Cesar

10 Lessons I Wish I Knew When I Was 25

2026-05-07T00:00:00+00:00

#1. Buy a domain and choose a professional handle. And no, a hacker-like handle isn’t cool.

#2. Start that blog. Seriously! Write anywhere. You’re going to like it.

#3. Open a brokerage account and start investing. Go with a broad market index fund and don’t worry about ups and downs.

#4. Take care of your body. Go to bed early. Exercise. Eat the right food, in the right amount.

#5. Don’t try to fit in. If you feel alone, there’s nothing wrong with you. Build a place where you fit in.

#6. Don’t force people into your life. That applies to friends and relationships.

#7. Ask for help. Figuring out things on your own is satisfying. But with help, you’ll get results faster.

#8. You can’t fix the world or people around you. And that’s OK. Often, they don’t want to be saved.

#9. Be present for your family. And being around and providing for them isn’t enough.

#10. If something feels off about work and life, you’re most likely right. Come up with your plan or work on somebody else’s plan—you’re not going to like it.

If any of my lessons resonated, check out these 10 ideas that changed my life and could change yours.

A Simpler Way To Start The Zettelkasten Method

2026-05-06T00:00:00+00:00

Search for “Zettelkasten” and you’ll drown in endless breakdowns of note types and apps.

But the Zettelkasten method isn’t complicated. How to Make Notes and Write by Dan Allosso shows a simple way to adopt it.

Here are five lessons I’ve learned from reading it:

#1. Avoid the mere-exposure effect.

Seeing a concept frequently doesn’t mean you understand it. You truly understand something when you write about it. Writing makes you think.

#2. Read with a project in mind.

Don’t extract everything from a book in one pass. Record what’s useful for your current project. You can always reread.

#3. Focus on the process, not the tools.

“What’s the best plugin for Obsidian?” “When should I use this note type?” Arrggg!

Forget about tweaking fancy tools. Niklas Luhmann, the Zettelkasten godfather, didn’t even have a computer. He only used pen and paper—and a typewriter.

The process is rather simple:

Highlight or underline.
Record data as you find it.
Interpret and make it relevant for your projects.

#4. Use only two types of notes.

Use Source notes to record data. Quotations, definitions, ideas, concepts. Source notes collect evidence of what you find.

Use Point notes to write conclusions. Anything you want to turn into knowledge counts as a note.

Point reminds you to write a single observation in a note.

How to Take Smart Notes calls them literature and permanent notes. But they’re the same thing.

#5. Originality is also finding new connections.

Without connections, notes are just a collection of trivia. That’s why my first Zettelkasten attempt didn’t work.

Stop Wasting Your Readers' Time

2026-05-05T00:00:00+00:00

Telling readers you don’t want to waste their time is already wasting it.

Last week in a grocery line, I picked up a self-help book from the nearby shelves. In the introduction, the author said he liked getting straight to the point without wasting time.

Then today I started a note-taking book. After listing two well-known note takers, the author gave the same disclaimer. Arrggg!

What if, instead of opening your book or post with a disclaimer, you went directly to the point? That’s how you don’t waste people’s time.

That’s the main lesson from Smart Brevity and that’s the whole point behind mini books.

10 Reasons Why Star Wars Is One of The Best Movie Franchises

2026-05-04T00:00:00+00:00

To warm up my idea muscles and celebrate May 4th, here’s why Star Wars is the best saga:

#1. A proven story. A constant fight between good and evil, light and darkness, bright side and dark side. We see that in almost all religions.

#2. Full of action, alien species, locations, futuristic weapons. You’d never imagine how diverse life is in a galaxy far, far away.

3. A story for all family members. It’s a war saga, but no matter the battles, treason, and plots, there’s no blood or sex on screen.

#4. Well-known cast. I only imagine our moms and aunts’ generation going crazy seeing Harrison Ford on the screen in the original trilogy. Natalie Portman, Ewan McGregor, Liam Neesson…

#5. Legendary quotes that became part of the pop culture. “May the Force be with you,” “Do or do not. There’s no try.” Even I’ve adopted one Star Wars line as a mantra…and couldn’t help but include some references in my books.

#6. Reflection of human nature. With the right or wrong motivations, we could become what we fight. The fear of losing a loved one turned Anakin into a cruel being. I mean, executing Order 66 without hesitation?!

#7. The best and cruelest of all villains. Even if you haven’t seen the movies, you know about Darth Vader.

His mysterious suit, his breathing sound, his tone of voice, his motivations, his ruthless methods make him terrifying. “Be careful not to choke on your own aspirations…“ right after choking someone? The best villain.

By the way, here’s what I’d write if I were Darth Vader brand strategist.

#8. The most iconic plot twist in the history of cinema. “No…I am your father.” Toy Story made a parody and The Simpsons made fun of that scene.

#9. More than a trilogy. It’s such a great story that has given birth to prequels, sequels, spin-offs, videogames, animated movies, comics. If you’re a fan, you’ll never get bored of Star Wars.

#10. Grogu and Mando. Whoever came up with the idea of a cute, baby Yoda is a genius. I bet they should already have a good raise or stock package. Mandalorian has brought new fans to the saga. “This is the way!”

A "Hell Yes" Can Always Become a Hard No

2026-05-04T00:00:00+00:00

When facing a decision or hard choice:

If it doesn’t make say “Hell yes,” say no. Credits to Derek Sivers.

In past weeks, a journalist found my rules for AI coding. He invited for an interview to write a story about it. A story featuring me in a tech news site? “Hell yes.”

After the interview, I had to send a photo of my ID, a professional headshot, and about a dozen of casual photos…plus some follow up via email. Photo of my ID? Casual photos? Were they training an AI or something? It wasn’t a “hell yes” anymore.

A “hell yes” could consume more time than expected. Or it couldn’t be a real “hell yes” after all.

Choose what to focus on and say no. Remember: a “hell yes” can always become a no.

7 Random But Interesting Ideas I Found Last Week

2026-05-02T00:00:00+00:00

Recently, I’ve started to list interesting ideas I found over the week—to practice my 10-idea list habit. Here are 7 from the last week.

#1. The Matthew effect. Inspired by a verse from the gospel of Matthew, recognition goes to already-recognized people. Visit social media and you’ll see it.

#2. The one sentencing to death wields the sword. Or something like that. This comes from Game of Thrones. Decision makers should stay close to their decisions.

#3. Don’t treat reading as background noise. Know whether you’re reading for pleasure and insight. When reading for insight, make it active. Otherwise, you won’t remember anything.

#4. Solve the problem with what’s in your room. Or in your head or in your notes.

#5. Three interesting questions from Tim Ferriss’s Tools of Titans:

What if you only solve a problem by removing something?
What if you only had two hours to create?
What’s the least crowded place to go?

#6. When writing anything emotional, write by hand. For everything else, type.

#7. Start writing by the end. What’s the one thing you want readers to take away?

Writing a 10-idea list changed my life. Try it! It could change yours too.

Friday Links: Leaving GitHub, Friendster revival, and life in 1999

2026-05-01T00:00:00+00:00

Hey there.

Here are 4 links I thought were worth sharing this week:

#1. GitHub made it to the headlines with outages and Copilot pricing. Mitchell Hashimoto, creator of Vagrant and Ghostty, is already leaving GitHub (4min). He’s not the only one. But believe it or not, there was still open source before GitHub (13min).

#2. I never used it, but a guy is trying to revive Friendster (3min), the first social media network.

#3. The defense industry already faced cheaper alternatives, efficiencies and consolidation, and a broken talent pipeline. Now it’s time for the tech industry (15min).

#4. Want some time off from social media? What about using the internet like it’s 1999 (11min)? Not with a desperately slow connection, but without feeds.

In case you missed it, last week I wrote about a newspaper-style feed for blog aggregators (2min) and Bubbles (2min) did it. Also, I documented 7 interesting ideas I found recently (2min).

See you next Friday with more links.

Cesar

Coding For A Living Is More Performance Than Code

2026-04-30T00:00:00+00:00

80% of the time, coding is a performance. The other 20% is doing real coding.

Performance means Scrum ceremonies, meetings, and JIRA:

A meeting to present tickets for the next two weeks
A meeting to answer questions from the previous meeting
A meeting to watch someone enter a number in a text box. Read: poker planning and story points
Meetings to watch someone move a ticket between JIRA lanes. Read: daily meetings
A meeting about all the other meetings. Read: retrospective

And when things go sideways, the performance intensifies with more frequent meetings. Sometimes a team member’s only job is running ceremonies and writing reports.

That kills the fun of coding and can make you hate it.

This happens everywhere. Sylwia Laskowska asked in a dev.to post if that’s something that only happens at her place. Nope! Even in the best families, as we say in our hometown.

Showing progress matters more than real work. Coding is often just a side quest. A hard truth nobody tells us about.

To succeed as a coder, you need to master the ceremonies as much as the code. That’s why Street-Smart Coding covers communication and collaboration. Because coding is more than typing symbols.

A Love-Hate Letter to Coding

2026-04-29T00:00:00+00:00

This is my submission for the IndieWeb Carnival May 2026.

Dear coding,

Our story didn’t start with love at first sight. You weren’t my first option. Sorry! But when we started to hang out, everything clicked. There was chemistry!

First, it was a textbook on C/C++ in college. Then, it was a recipe catalog in PHP late at night. Then, it was Java. Then, our first adventure in the real world with C#. Then, building, fixing, growing—what others would call “passion.”

I enjoyed the time we spent together. It was the challenge, the victory dances, the aha moments at the most unexpected times…It was funny, rewarding, almost magical.

But something felt off. The passion faded, and then one day, everything changed.

I don’t blame you. It was the corporate world, Scrum and its ceremonies, unrealistic deadlines, office politics…They all ruined our thing. I stopped waking up eager for you. I didn’t want to talk or read about you. I got sick. I got burned out. I got tired of us.

Then, to make things worse, a layoff set us apart.

It was a hard time. We stopped seeing each other. Nobody hired me to be with you again. And I stopped looking.

It was a long time away. Honestly, I didn’t miss you. I thought we would never cross paths again. After months of applications, hope arrived in an unexpected email. Someone wanted us back together. But things can’t be the same after a breakup. We now need boundaries and space.

Coding, I sometimes hate you. I sometimes dream about a life without you. But you rewired my brain, making me see the world with different eyes, and that’s why I’ll always love you.

Solve the Problem With What's in Your Room—or Your Head

2026-04-28T00:00:00+00:00

Constraints make you more creative.

What better constraint than “solving the problem with what’s in your room”? That’s a line from Edwin H. Land, founder of Polaroid. I knew about it from this bookofjoe’s post.

Before he had his own lab, Edwin snuck into his university lab after hours. Maybe that’s why he adopted that line.

What about solving a problem with what’s in your head, library, and notes? It forces recall and sparks connections. It make us read and learn broadly. It help us build range.

That’s a good excuse to revive my Zettelkasten—and a good challenge to write a book.

7 Random But Curious And Interesting Ideas I Found Last Week

2026-04-27T00:00:00+00:00

#1. 100-repetition rule. When starting a new hobby, aim for 100 repetitions to judging your progress or quitting. That’s 100 posts, 100 photos, or 100 paintings.

#2. I feel/I wonder/I think. Reviving my Zettelkasten led me to morganeua’s YouTube channel. To react to something, answer I feel __, I wonder __, and I think ___. Those answers will help you to create new notes.

#3. Cover design idea. Last week, I found my copy of The Ruthless Elimination of Hurry by John Mark Comer, and noticed its cover. The title is on the cover and its subtitle is on the back cover. Simple! I’m stealing that idea.

#4. Techno selectionism. You don’t have to stick to a piece of tech. You can always try it, watch it, and change it. If it drains you or disconnects you, drop it.

#5. No boredom, please. We prefer to receive electric shocks rather than spend time alone with our thoughts.

#6. Work with your garage door open. If marketing and sales sound daunting, just show your progress. Open your garage door and let people see what you’re building.

#7. Read one book about work per year. I haven’t read a coding book since my burnout and layoff in 2024. This idea inspired me to pick one again. I opened my Books folder and started reading Dependency Injection: Principles, Practices, and Patterns by Mark Seeman.

If you’re a coder who wants to read something about work, you’ll find my books here.

A Sunset, a Rooftop, and a Dream (A 100-Word Fiction Story Inspired By a Photo)

2026-04-26T00:00:00+00:00

A search for vignettes took me to a YouTube video by Bookfox on short stories, then to its blog, and finally to 100 word story. Each month’s photo inspires a 100-word story. Here’s this month’s photo and my story.

Game at sunset. Photo by Orlando Contreras Lopes on flickr.com

“One day, I’ll be like Messi or Cristiano Ronaldo.”

After school, the only thing he did was play street soccer. No field. Nets were two piles of stone. His only audience was the next team waiting to challenge the winner. In his mind, it was a gigantic stadium, people screaming “Gooaaal” as he took off his shirt.

His class was full of doctors, police officers, and even a mayor. He dreamed of Bernabéu, Maracaná, and the Champions League.

But today, he only had an old ball to kick on a rooftop. He only had a big dream and another sunset.

Bubbles Made It: A Newspaper-Style Feed

2026-04-25T00:00:00+00:00

I manifested it…and Bubbles did it.

Earlier this week, I wrote blog aggregators should be like newspapers. I found out about a new aggregator, Bubbles, and gave it a try.

I realized “new” and “random” views are just like feeds. They’re fun the first time, especially “random,” until you’re hooked.

With a newspaper, there’s no scrolling. Read it and wait for the next day.

Bubbles did exactly that. Now it has a “Briefing,” yesterday’s best stories, like a newspaper. Perfect to keep reducing your phone time. The best part, it greets you with “Go outside. Touch some grass” when you reach the end.

Thanks Ben for making it a reality.

Now my daily reading is a dose of Hacker News, Minifeed, and Bubbles Briefing.

I didn’t know I had magic powers. Turns out, it’s not magic, it’s being an idea machine.

Three Tweaks I've Made To My Blog For a Fresh Start

2026-04-24T00:00:00+00:00

Back in March, I wrote a list of changes I wanted to make to my blog.

To hold myself accountable, here are the changes I’ve made:

#1. Scrollable sidebar. The original Hyde theme had a sticky sidebar. But after adding more items, it overflowed off the screen. Now it’s scrollable. I can add as many items as I want. Muahahaha!

#2. New tagline. After burning out and diversifying my joy, I stopped being a “passionate” coder. These days, I’m a lifelong learner who codes part-time and write most of the time.

That’s why I changed my tagline on the sidebar from simply “Software engineer” to “Sometimes I code, always I write.” Cooler, isn’t it? And it reflects what you will find here.

#3. Better homepage and about copy. My blog isn’t a coding-only blog anymore. It’s more like a time capsule. My About page reflects that now…and I had some typos. So embarrassing, calling myself a writer.

And on my homepage, I’m only featuring my blog and my books. No more Buy Me a Coffee and Udemy courses. Less clutter.

That’s the good part of personal blogs—and the bad part too. You’re never done tweaking it. And if you code and want to blog, don’t start by writing a blogging engine. Wait, did I say that out loud?

Friday Links: Agile guilty, software laws, and Postman pains

2026-04-24T00:00:00+00:00

Hey there.

Here are 4 links I thought were worth sharing this week:

#1. I have many horror stories from daily meetings and other “ceremonies.” From SCRUM masters being police officers to sticky notes signed with blood. Agile killed the software industry (6min).

#2. Conway’s law, Brooks’ law, Peter principle…Do they ring a bell? Well, those are some of the laws of software engineering.

#3. At a past job, Postman was our official API tool. Then it went paid, then it became…something else? For something as simple as calling APIs, we’re in a tooling crisis (7min). Maybe all we need is curl (2min).

#4. Have you ever used a typewriter? Imagine writing an essay with no AI, spellchecker, or backspace. That’s what this teacher asks his students to use (5min) once each semester.

And in case you missed it, I wrote on my blog about the main advantage of coding the old way (2min). Yes, not using AI is already “the old way.”

See you next Friday with more links.

Keep coding the old way (or not).

Cesar

A Life Lesson Learned From Dressing Up at the Airport

2026-04-22T00:00:00+00:00

A 2-hour flight to the capital city for an early morning meeting at a government office…

I showed up late to the airport booth. Passengers were already getting on.

I was working for a small tech shop in my city. I wasn’t a manager, but the CEO chose me to fly with one to represent our company.

My dad offered to drive me. Before rush hour, the airport was just 15 minutes away. But that day, the car wouldn’t start. Each time he turned the key, the engine just made funny noises and die. Arrggg!

In the airport booth, I saw an empty line at the security control. My coworker was texting me. He was already onboarding. I had no other choice but to plead guilty.

“Good morning. I know I’m late. The car I was in broke down. My assistant was supposed to send me my boarding pass but I can’t find it in my email. I have a meeting with the government at 8:00 a.m.”

I didn’t really have an assistant. I meant the office manager, who helped us all. I lied. I know that’s bad. I didn’t want to pay for a ticket with my own money. But the part of accessing my email was true.

I was well-shaved, wearing a long-sleeve shirt, and holding a jacket. “Do you only have hand luggage?” I was carrying a small backpack. She took the radio, called the security line, and let me in.

Behind me was a vacationing family. You know, shorts, t-shirts, and flip flops. They were also late and also on the same flight.

“It’s too late. Flight is closed,” they were told.

Like it or not, we judge and are judged by how we dress and speak. And if you’re late, always admit it.

A Simple Feature That Could Transform IndieWeb Aggregators

2026-04-21T00:00:00+00:00

While checking my blog stats today, I found a surprising new source of traffic.

Apart from the usual search engines, I found Hacker News, Kagi, Minifeed, and Bubbles.

I knew about Minifeed. But Bubbles was new. It’s like Hacker News meets RSS for IndieWeb. They both solve the discoverability problem of blogs. More power to personal blogs!

But blog aggregators should be like newspapers.

When you open one, you’ll only find news from yesterday, or previous days if still relevant. You’ll have to wait until tomorrow to read what happened today.

Aggregator views (like latest, top, and random) often invite endless scrolling, like in social media. I want to know when I’m done with the IndieWeb each day. What about “today” and “yesterday” views? Or maybe I’m too lazy to check post dates in the feed.

If you found this post through Minifeed, Bubbles, or another aggregator, welcome! On my About page, you’ll find my most popular posts. Feel free to check my books on coding and personal development.

The Main Advantage Of Coding "The Old Way" Over AI-Assisted Coding

2026-04-20T00:00:00+00:00

Typing out code is already the old way.

Last week, I stumbled upon I’m Coding By Hand. Its subtitle got my attention: “I’m spending 3 months coding the old way.”

The old way of coding

The future of coding is already here.

Decades ago, we punched cards. For so long, we’ve been typing out symbols inside IDEs. That’s now “the old way.”

Maybe the future is AI specs via brain implants. Who knows!

What you miss when coding with AI

The post made an excellent distinction between old coding vs AI-assisted coding.

“when writing code ‘by hand’ I was actually doing two things: writing what I wanted and learning the codebase…if I didn’t know what I wanted exactly, coding agents would be happy to make many assumptions for me. This almost always meant that I didn’t learn as much, and that I wouldn’t have a good grasp of the codebase.”

Coding isn’t just typing.

It’s decoding business rules or problem constraints to then encode them into a programming language, while

Mastering its syntax and rules,
Making the new coding artifacts interact with existing ones,
Following the structure and conventions of the codebase,
Learning about the business domain,
And of course, solving the problem at hand.

Maybe with AI, we may lose some of those activities. If AI writes 90% of code, being a polyglot isn’t valuable anymore.

In the meantime, every AI-generated line of code we don’t understand isn’t just technical debt. It’s cognitive debt.

AI is like a powerful calculator: only useful if you know the math. To help you level up your coding skills—AI-assisted coding or old school—check out Street-Smart Coding. The roadmap I wish I had starting out.

A Nobel Prize–Winning Writer Made Me Ask Why I Write

2026-04-19T00:00:00+00:00

Today I found a short version of Orhan Pamuk’s Nobel acceptance speech. His words about why he writes inspired me to write my own reply. Here’s why I write.

I write because I want to be sane.

I write because I don’t want to burn out again.

I write because I want to bring order to my mind.

I write because I enjoy being alone with my thoughts.

I write because I like to be in the zone.

I write because I want to get better at it.

* * *

I write because sometimes I can’t be quiet.

I write because other times I want to stop talking.

* * *

I write because I want to share my life’s lessons.

I write because I want to help and inspire.

I write because people already ask me about my first books.

* * *

I write because I want my future kids to read my books.

I write because one day I’d like to see my books in bookstores.

I write because one day I’d like to be someone’s favorite writer.

* * *

And finally…

I write because I don’t want to go back to a 9-to-5 again.

Why You Shouldn't Be Afraid of Rereading Books

2026-04-18T00:00:00+00:00

I read Deep Work in August 2020.

I know because I took notes. I have in my digital slip-box excerpts and reactions. I only remembered the Monk Mode: isolation for a period to focus on a project.

Recently, my mission to reduce my phone time brought the book back to my attention.

That’s when I pulled out my notes and found all the quotes and excerpts. This time, reading it would have more meaning. It’s no longer about hitting a book count. I have a running project. A concrete goal.

The book hasn’t change. But I have. That makes the reading different.

And that’s why you should reread books too.

Friday Links: AI adoption, cheap stack, and obfuscation

2026-04-17T00:00:00+00:00

Hey there.

Here are 4 links I thought were worth sharing this week:

#1. If AI is so good, why it hasn’t changed everything yet? Here’s a checklist for a new tech to transform anything (10min). I liked the item about judging when not to use a tool.

#2. Often we don’t need Kubernetes, replication, and expensive databases. Here’s a simple $20/month tech stack (9min) to experiment.

#3. Here are the best techniques to protect emails from spammers (18min). Something to bookmark.

#4. I’m in the I won’t install your app (5min) team.

And in case you missed it… This week, living through the Excel paradox of coding (1min), I found myself dealing with CSV files in C# using CsvHelper (5min).

See you next Friday with more links.

Keep coding smartly.

Cesar

From Skepticism to Overreliance, My Journey With AI (And How to Thrive as a Coder)

2026-04-16T00:00:00+00:00

Nah… I don’t care

In early 2023, a coworker tried that new thing called ChatGPT. He shared his excitement. I wasn’t that impressed.

Months later, after all the buzz, I searched that Chat thing. Every time I tried, I couldn’t access it. It was a public beta or something. Too many people.

Then, I learned from Brent Ozar to keep a browser tab with ChatGPT open as a junior assistant. Mmm, there’s something there…

In early 2024, Devin was released. “The sky is falling” all over the headlines. I didn’t buy it.

OMG! This is dangerous!

Early 2025, I decided to try AI with a fresh mind.

After using Copilot for weeks, “OMG! This thing is dangerous.” One day I realized I couldn’t finish a simple task alone. The tool worked, but I was becoming so dependent.

An AI detox season followed. No more AI until you eat your vegetables and do your homework.

Then I made some rules to use AI without losing my skills.

Like any other tool, AI is a game changer with the right skills. Otherwise, it’s like a fancy calculator in a math exam you didn’t study for.

To thrive in the AI era, build real skills, then leverage AI.

To help you build AI-proof skills, I wrote Street-Smart Coding. The guide I wish I had on my journey from junior to senior.

Healthcare Provider Dropped This Doctor—He Has 2 Specialties And Over 40 Years of Experience

2026-04-15T00:00:00+00:00

This time, the waiting room was almost empty.

I went with my sister to her dermatologist. His office is across town near the beach. We walk around afterwards. Each visit feels like a day off.

After going to the same doctor for years, my sister chats casually with him like old friends.

She asked him if there was another doctor in the area. The waiting room wasn’t crowded, and his schedule had plenty of openings.

It turned out some healthcare providers let him go simply because of his age. Some patients asked for a younger doctor. My sister’s doctor is 72.

They don’t know about the oldest practicing doctor and his Guinness record. Spoiler alert: he’s 102.

My sister’s doctor walks without assistance, works from 8:00 to 7:00, has 2 specialties, performs surgeries, and if you see him around, you’d think he’s in his early 60s. I saw him in the waiting room taking a coffee to his assistant. He has seen countless patients and cases.

My sister says he’s the best dermatologist she’s ever had.

Often you don’t need newer, brighter, and faster, but more trustworthy.

I've Been Following the Zettelkasten Method the Wrong Way—I'm Fixing It

2026-04-14T00:00:00+00:00

In 2020, I discovered the Zettelkasten method, and it transformed my note-taking.

Back then, I read How to Take Smart Notes and started my “perverted” digital version.

Recently, to stay away from screens, I decided to give Zettelkasten another try.

A rabbit hole led me to:

a Luhmann’s essay, showing how to use bibliographical or literature notes.
a paper on his system, with photos of Luhmann’s notes as examples.
a helpful blog, clarifying what to put into a main or permanent note.

Here’s what I learned to revive my Zettelkasten with pen and paper:

#1. The goal isn’t to take notes, but to write. Read while keeping your existing notes and projects in mind.

#2. Read with pen and paper, and keep a bibliographical note. Write page numbers, timestamps, and keywords. Make it a personal index for a book or resource.

When reading a book, Luhmann wrote its bibliographical information on one side of a card and on the other side, page numbers and keywords. He kept one or two cards per book.

#3. Don’t write excerpts or quotes in main notes. Add your interpretations of what you consume. If it triggers a thought or an aha moment, make it a main note. Optionally, reference the bibliographical note that sparked it.

In my perverted version, I kept bibliographical and main notes in one file. I put my interpretations in the top half, instead of using a main note.

Strictly speaking, I was only taking bibliographical notes. I was keeping a commonplace book, not a Zettelkasten.

#4. Link between a new note and existing notes. Think of hyperlinks between notes.

#5. Create an index card for keywords and subjects.

Even without following the method to the letter, using separate pieces of paper is simple but effective to organize and connect ideas. Useful when outlining presentations or books.

10 Lessons To Run a Successful Business from Derek Sivers' Anything You Want

2026-04-14T00:00:00+00:00

What started as a hobby became a millionaire business.

To sell his own music, Derek created a website and called it CD Baby. His friends asked him to include their CDs too. Years later, he sold it for millions.

To stop answering the same questions, he wrote Anything You Want. You could notice his take on succint writing and short books.

Here are 10 lessons I learned from reading it—I’m practicing the 10-idea list habit and the 7-word summary:

#1. Your business is your utopia. It’s your world where you make all the rules.

#2. You don’t have to make it look corporate. Forget about a privacy policy and terms and conditions. It’s your world. Make it anything you want.

#4. Share something people want and charge for it. Starting a business doesn’t have to be complicated after all.

#5. You don’t have to grow big, big. It isn’t about growth, but being happy.

#6. Have a simple business model. CD Baby charged an onboarding fee and another one per CD sold. Derek stole his business model from another publisher.

#7. Get to know everyone who contacts you. Your best clients are your current clients.

#8. Always think about your clients. Make them happy, even when asking for favors.

#9. Every confusing word makes you lose money. That applies for your website, emails, and every piece of copy. Rejecting sales calls makes you clarify your message.

#10. If if doesn’t excite you anymore, move on.

Why I Don't Do Sales Calls (On Either Side)

2026-04-12T00:00:00+00:00

This was supposed to be a call to get some help.

At least, that’s what I was told. But it turned out to be something else.

An invitation to a call…

This happened in the days I started to write seriously online.

After months of inactivity, I joined a social media platform. I participated in the community, liking and commenting under big and small accounts.

For weeks, I replied to almost every post from a big creator. His message resonated with me. He left his regular job to make a living writing. My dream!

One day, he messaged me asking me about my goals. He offered to join a free call to see if he could help.

The day of the call…

Somebody else showed up.

“Definitely, we could help,” the guy said after asking why I was interested in writing.

He showed me all the incredible benefits of joining their writing program. Testimonials, weekly coaching calls, a vibrant community… You name it!

When I asked about the price, “Forget about the price. What would your life look if you achieve this goal?” They promised hitting $10K a month.

I hesitated and kept asking for prices.

Then he typed some numbers. “Here’s the full price… If you’re an action taker, here’s the price… Or you can pay in X installments of Y…“

Wow! Far outside my budget. Then I knew why he asked about my income.

There was some awkward silence, followed by the same question, “What impedes you to take action now?” Then, more silence, more awkward this time.

Being an action taker…

After some back and forth, he created a lite version of the program for a discounted price.

That was “all” he could do for me.

But there was a catch, I had to pay within the next 24 hours. Otherwise, I’d prove I wasn’t “an action taker committed to achieving my goals” or something.

I sent the receipt to the creator who started the conversation.

Radio silence.

Each day made me worry more. “How can I be so stupid?” I checked my card activity, hoping not to see anything suspicious.

After a day or two, I got a link to join the course and the community.

It was some video recordings. Not that bad, but overpriced.

I definitely felt tricked. A hand crossed the internet, through my screen, into my pocket.

“Hey, I’ve seen this one…”

More recently, the first email from a newsletter had a link to a webinar.

The guy promised 8 tips his mentor taught him to live a “dream life.” He claimed he works one day a month. But he only shared one tip.

To get the others, we only had until next Thursday midnight. It was a “let me hold your hand” program, but you had to join a call to see if you were a good fit. The price wasn’t disclosed anywhere.

I unsubscribed. “Hey, I’ve seen this one, I’ve seen this one. It’s a classic,” Marty McFly would say.

That wasn’t the first time I heard that story.

If I don’t see this…

For a moment, I thought that call was a scam.

The closer followed all the sales tactics. It was a sales call to showcase in a textbook. Finding a pain, painting a dream outcome, making a limited-time offer…

I guess scammers and salespeople read the same books. Or scammers are salespeople who joined the dark side.

That call and the other webinar made me set a rule: If there’s no price, no time to decide, and the “help” comes wrapped in a call, I walk away without thinking twice.

If “help” is just a hand reaching into your pocket, it isn’t help at all.

That’s why I don’t do sales calls—on either side.

Follow This Proven Strategy to End Scope Creep (While Keeping Clients Happy)

2026-04-12T00:00:00+00:00

There’s a thin line between making your clients happy and doing everything they want.

Derek Sivers in Anything You Want shares his strategy to end “small favors” while keeping clients happy.

When running CD Baby, he had a clear task: create a sales page for your CD. For anything else, he answered “If you buy us a pizza, we’d do any favor you want.”

A pizza isn’t free but generates small friction to end next favors.

Replace pizzas with coffee or hamburgers. Also great idea to also support local businesses.

TIL: How to Read Invalid Fields as Null with CsvHelper

2026-04-10T00:00:00+00:00

In another episode of the Excel paradox of Coding…

TL;DR: To read an invalid field from a CSV file as null with CsvHelper, create a map class and use Default() with useOnConversionFailure set to true on the appropriate field.

The cleanest approach

To honor the 20-minute rule and preserve my keystrokes, let’s say we need to read a CSV file with CsvHelper. By default, it throws an exception when it fails to parse a column, for example when it finds text on a numeric column.

Here’s how to read that invalid field as null instead of throwing an exception,

using CsvHelper;
using CsvHelper.Configuration;
using System.Globalization;
using System.Text;

namespace TestProject1;

[TestClass]
public class CsvHelperTests
{
    private class MovieRating
    {
        public string Name { get; set; }
        public float? Rating { get; set; }
    }

    private sealed class MovieRatingMap : ClassMap<MovieRating>
    {
        public MovieRatingMap()
        {
            Map(m => m.Name);
            Map(m => m.Rating)
                .Default(defaultValue: default(float?),
                         useOnConversionFailure: true);
            //           ^^^^^
            // If the field is invalid, use the default value
        }
    }

    [TestMethod]
    public void NullWhenInvalidFloats()
    {
        var csv = new StringBuilder()
            .AppendLine("Name,Rating")
            .AppendLine("Inception,9.0")
            .AppendLine("Titanic,ThisIsNotAValidRating")  /* <-- */
            .ToString();

        using var reader = new StringReader(csv);
        using var csvReader = new CsvReader(reader, CultureInfo.InvariantCulture);
        csvReader.Context.RegisterClassMap<MovieRatingMap>();
        //                ^^^^^

        var records = csvReader.GetRecords<MovieRating>().ToList();

        Assert.AreEqual(2, records.Count);

        var last = records.Last();
        Assert.AreEqual("Titanic", last.Name);
        Assert.IsNull(last.Rating);
        //            ^^^^^
        // Look, ma! It's null
    }
}

The magic happens in MovieRatingMap. The Rating map uses Default() with useOnConversionFailure set to true.

The manual approach

As an alternative, let’s read the CSV file manually while processing the records as needed,

[TestMethod]
public void ByHand()
{
	var csv = new StringBuilder()
		.AppendLine("Name,Rating")
		.AppendLine("Inception,9.0")
		.AppendLine("Titanic,ThisIsNotAValidRating")
		.ToString();

	using var reader = new StringReader(csv);
	using var csvReader = new CsvReader(reader, CultureInfo.InvariantCulture);
	csvReader.Context.RegisterClassMap<MovieRatingMap>();

	csvReader.Read();
	csvReader.ReadHeader();
	//        ^^^^^
	// Open the reader and read the header

	var records = new List<MovieRating>();
	while (csvReader.Read())
	//               ^^^^^
	// Read it by hand...
	{
		var name = csvReader.GetField<string>("Name");
		var rating = csvReader.GetField("Rating");
		//                     ^^^^^
		// Read the field as string...

		var parsedRating = !float.TryParse(rating, NumberStyles.Float, CultureInfo.InvariantCulture, out var parsed)
								? default(float?)
								: parsed;
		// Parse it as needed...

		records.Add(new MovieRating
		{
			Name = name,
			Rating = parsedRating
		});
	}

	Assert.AreEqual(2, records.Count);

	var last = records.Last();
	Assert.AreEqual("Titanic", last.Name);
	Assert.IsNull(last.Rating);
	//            ^^^^^
	// Look, ma! It's still null
}

A lot more work! We have full control, but it’s less clean.

In case you’re wondering, I asked Copilot about this but, with a straight face, it hallucinated suggesting a flag on CsvConfiguration, which didn’t even exist.

For scenarios like this, you still need strong debugging and code reading skills. I cover those skills and more in Street-Smart Coding—A roadmap with 30 lessons to help you code like a pro.

Friday Links: Jesus on prototyping, C# union types, and taste

2026-04-10T00:00:00+00:00

Hey there.

Here are 4 links I thought were worth sharing this week:

#1. After a long wait, C# union types are here (10min). Well, in the next C# version. If you’re new to union types, I wrote this guide (9min) when Microsoft announced the feature.

#2. If you’re new to a codebase, run these Git commands (5min) before reading any code. Treat it like a crime scene: gather evidence before touching anything.

#3. When AI makes code and text free, the only skills left are taste and judgment (10min). I liked the exercise of “fails because.”

#4. Did you know that Jesus taught about prototyping with an LLM? Here’s his advice (3min).

And in case you missed it, not much about coding on my blog, but I wrote about the secret to surviving 30 years in one job (and to live a happy life) (3min).

See you next Friday with more links.

Keep coding smartly.

Cesar

The Real Effect of a Daily Writing Habit

2026-04-08T00:00:00+00:00

My first writing class shocked me.

Its main lesson was to write every day. It was a webinar pitching a writing course. But it made me revive my blog after abandoning it for months.

Since November 1st, 2024, I’ve been writing daily. If I miss a day, I write two posts to recover the streak. More than once I’ve thought I’d run out of ideas.

Writing daily makes you pay attention to the world. You see the world through your writer’s glasses. This is my favorite side effect.

As Robert Greene says, “it’s all material.” A conversation could be a mini-story. A failed delivery, a business lesson. A visit to the grocery store, a life lesson.

Writing daily is a habit that has truly changed my life.

Write Not to Be Read (Yes, You Read That Right)

2026-04-07T00:00:00+00:00

Almost nobody reads online.

We don’t deserve attention, especially when content is free and abundant.

Smart Brevity says we have a few milliseconds to earn attention:

Write an attention-grabbing headline.
Open with strong first line. Or jump straight to your main point without preamble.
Write short pieces or break longer ones with subheaders.
Use short paragraphs with short sentences.

Most people will only read your headline, subheaders, and bold sentences. Tell them what they need to know if that’s all they do.

Christopher Butler writes in Earning Attention,

“Here’s another 80/20 framing–80% of your audience will never do more than scan your information; 20% will go on to read it.”

Write as if nobody is reading, but everybody is skimming.

The Secret to Surviving 30 Years In One Job (And to Live a Happy Life)

2026-04-07T00:00:00+00:00

In a line at the grocery store…

“Sorry, did I mishear, you said you’ve been here 35 years?” I asked her.

While waiting, I skimmed the books on the shelves and overheard the cashier talking to the client in front. When it was finally my turn, I couldn’t help but ask her.

“30! I have 30 years,” the cashier told me. “The girl at the bakery section has 35. She was about to leave last year. She’s leaving next May.” It was April.

Staying for so long at a place…

Curious and surprised, I asked her, “How did you manage to stay so long at a single place?” To me, 30 years at the same job sounds like a life sentence.

“Take it easy!” she said while smiling. “Don’t let anyone ruin your day!” She kept scanning items without pause. “How long have you been in your job?”

Earlier that day, a pointless task from a freelancing client made me want to throw my laptop against the wall. Her words came at the perfect time.

“I got bored or they got bored of me. The longest I’ve stayed at a place is 5 years.” That was at my last full-time job as a coder. I burned out while waiting for a promotion. Months later, the company laid off almost everyone, including me.

“You have to take it easy. There are clients that…“ she said while shaking her head.

When someone does it…

“There’s only one who ruined my days…“ The smile on her face disappeared.

“A boss?” I asked her while expecting to hear some gossip or horror stories from working at a grocery store.

“My first husband… That one sucked the life out of me. That’s why I left him.” Beep… Beep… She kept passing the products all that time. “I was skinny… When I left him, everybody said they could see the change.”

Years ago, 30 years in one place sounded like a career wasted. Now I know some people thrive in structure. Others in change. Others take a boring job to fuel their hobbies. Whatever your path, smile, take it easy, and never let anyone suck the life out of you. And if it’s your partner or your job doing it, leave them.

When You Feel Lost, Find Your Heroes

2026-04-05T00:00:00+00:00

In 2023, after burning out, I felt completely lost.

A daily wellness routine to care for my body, mind, and spirit saved me. That simple idea changed my life. I still follow it today. No excuses.

Inspiring people helped my burnout recovery. I filled my days reading James Altucher, Dan Koe, and Borja Vilaseca. I looked up to them.

More recently, I’ve added Seth Godin and Derek Sivers.

They had something in common: Reinvention, living on their own terms, eating what they hunt, writing, books… That’s the path I’m trying to follow now.

When lost, find the thread between your heroes.

Five Writing Lessons from Derek Sivers (From Circus Performer to Entrepreneur to Writer)

2026-04-04T00:00:00+00:00

A weekend on YouTube led me to a writing channel, and then to rediscover Derek Sivers.

If you haven’t heard of him, he’s the definition of someone who reinvented their life. He went from circus performer to running CD Baby, an online distribution platform. After selling it, he now writes books. How to Live, is his most recent and popular.

Here’s what I learned binge-watching his interviews and reading his blog:

#1. Be the entertainer. Your writing and stories aren’t about you. They’re about how to help your readers.

#2. Write succinct books. Call it a tiny book, a mini book, or simply a short book, it’s your best ideas distilled. A short book shows respect for your readers’ time.

#3. Write essays then turn them into books. A book could be a single idea or a collection of multiple ideas.

Start your book by writing essays. Then compile the best ones into a book. You’ll have proven and validated ideas.

#4. Write to scale yourself. When you want to stop talking about a subject, write a book. Next asked again, point to the book. That’s why Derek wrote Anything You Want.

Like Derek, before retiring from coding, my goal is to write a trilogy. Street-Smart Coding is the second installment.

#5. Focus on writing sentences. Write each sentence on a separate line. Then, write something shorter than you could.

4 Mind-Changing Lessons to Start an Online Business the Purposeful Way

2026-04-03T00:00:00+00:00

Forget LLCs or investors. Starting a business is simpler.

Being an entrepreneur is often mistaken for hustling and grinding long hours. In Purpose and Profit, Dan Koe, a millionaire creator, shares a different view of entrepreneurship.

#1. Entrepreneurship doesn’t have to be complicated

No more working long hours. No more growing a business while paying with your health. Entrepreneurship is building skills to help others.

#2. Entrepreneurship is self-help and others-help

Being a CEO is a title. But being an entrepreneur is a mindset.

You’re an entrepreneur when you solve your own problems and share your solution to help others.

Nobody will pay you unless you help them. To earn more, become more valuable: solve bigger problems or help more people. As an entrepreneur, money is the result of your personal development.

“If entrepreneurship is about solving problems and self-actualization is solving your own, you can combine both into a meaningful way of life”

#3. Become a one-man media company

Your product is what you created to solve your problem. Your audience is people with the same problem. Your platform is the internet.

At first, nobody will care about you and what you do. To make them care, you need to position your solution as valuable. Learn persuasion to reach the right audience—people like you.

#4. You’re the niche

When you solve your problems, you’ll find new and bigger problems. You won’t be limited by a social media bio or a tagline. As you solve them, your niche will evolve with you. “Your life’s work is getting paid to be yourself.” Entrepreneurship is evolving.

Friday Links: Axios hacked, QA rethink, and roulette

2026-04-03T00:00:00+00:00

Hey there.

Here are 4 stories that caught my eye last week:

#1. Last week, another npm package was hacked. This time, it was Axios’ turn (3min). If you’ve downloaded it recently, patch now.

#2. Not that testing isn’t important, but should we have QA teams? That’s another role AI makes us rethink (11min).

#3. Not a big surprise, but LinkedIn is searching and scraping your browser (3min). Time for better fingerprinting protection.

#4. Last week’s cool tool: twitchroulette I spun the roulette a few times and only found game streams. Maybe you’ll be luckier and find coding streams.

And in case you missed it, I wrote on my blog about the hidden truth AI has revealed (1min) the Excel paradox of coding (2min).

See you next time.

Cesar

Street-Smart Coding: A Review That Made My Day

2026-04-01T00:00:00+00:00

No coding tip today. Just celebrating a small win that remind me why I started writing.

Street-Smart Coding got a review on dev.to that made my day.

Here’s the original post in Spanish. Let me translate the gist of it:

“…It is written from experience. In other words, it doesn’t tell you how things should be done, but rather how the author personally learned how things should be done.”

That’s exactly the point! I wrote the guide I wish I had. A proven roadmap from junior to senior coder. I wanted it to feel like a conversation over coffee.

With a couple of prompts or searches, you could find tutorials on syntax. I’ve written my own. But inside Street-Smart Coding, you’ll find 30 lessons to level up your coding skills:

Some conventional
Some learned the hard way
And a few… weird ones

All tested in the real world.

I wrote it for my past self and for every coder who’s ever asked “how to get better at coding.”

If you haven’t already, grab your copy here and start coding smartly.

A Simple Exercise to Instantly Improve Your Sentences

2026-03-31T00:00:00+00:00

Athletes train every day.

Writing shouldn’t be any different.

Practice writing each sentence on a separate line.

Derek Sivers recommends this technique.

The goal is noticing sentence length.

Long sentences.

Short ones.

Variety!

Separate lines highlight start and end words.

Like a joke, they’re what people remember.

They’re the strongest words.

Start with a boom.

End with a punch.

Put the lines together, your sentences instantly improve.

Two YouTube Channels I've Binge-Watched This Weekend

2026-03-30T00:00:00+00:00

#1. Fabio Cerpelloni’s Tiny Books

A podcast interview with Seth Godin, the godfather of daily blogging, led me down a YouTube rabbit hole.

During the interview, they mentioned The Practice, one of Seth’s books. Curious, I Googled it and found Fabio Cerpelloni’s channel.

He interviews writers, reviews books, and inspires others to write tiny books. His questions to discover the book inside you gave me ideas for at least two more books.

His videos feel like an unscripted conversation, like asking a friend about writing books.

#2. The Kings Hand

Doomscrolling is bad, right? It’s a black hole for our time and attention.

The other day, scrolling taught me a valuable life lesson. And this time, I discovered a hidden gem about creativity, The Kings Hand.

This channel is about creativity in visual arts and music. Its official description is cultural strategy and creative psychology breakdowns for ambitious creators.

Binge-watching The Kings Hand made me ask about my visual identity. A silhouette of a tuxedoed man leaning forward with his hand in his hat instantly recalls Michael Jackson. That’s the power of visual identity.

You Have A Story to Tell Hidden in Plain Sight

2026-03-30T00:00:00+00:00

Every book worm already has a story worth telling.

The books you read reflect who you are and the path you’ve taken. Your bookshelf hides plenty of stories, among them lies your own autobiography.

After a year or two of ebooks, I’m back to physical books. My new rule is: build a pile, go throught it, and build another.

My old pile already tells my recent story

When I was making a good salary at my last full time job, I picked Rich Dad Poor Dad, The Richest Man in Babylon, and Psychology of Money.

Then, I switched to How to Win Friends and Influence People, The Monk Who Sold His Ferrari, and other personal development books. Most of them came from a not-mentor.

When burnout knocked at my door, I picked Unwinding Anxiety and The Ruthless Elimination of Hurry.

When I hit rock-bottom, I discovered James Altucher and his books, Choose Yourself, Choose Yourself Guide to Wealth, and Skip the Line.

After recovering from burnout, writing became my therapy. To improve my writing, I started with The Post Office and Jesus’ Son. And sitting on my bookshelf, I have Angel and Demons and The Old Man and The Sea.

Just by looking at my bookshelf, I have a story to tell and a book to write. What story is your bookshelf hiding? If you think you don’t have anything to share, look twice at the books you’ve read.

The Excel Paradox of Coding

2026-03-28T00:00:00+00:00

Last week, for the nth time, I had to bulk-import records using Excel.

No matter how advanced and complex your business rules and code, they often circle back to reading and writing Excel files.

I should call it The Excel paradox of coding.

Instead of writing enterprise software, maybe we should build Excel add-ons and let end users stick to what they know, Excel.

Tasks for bulk-importing from Excel files

If you’re starting out, here’s a street‑smart tip:

Learn to work with Excel in your language of choice to:

Download an Excel file with existing records.
Upload an Excel file with updated columns, using an ID column to find matching records.
Validate data integrity of the file. Be careful with date and numeric columns.
Bulk-update the records from the file. Optionally, use a background processor.
Report once the file is processed. Optionally, report the progress with a completion bar on a page and send an email when done.

It’ll save you countless headaches. You’ll use it a lot! I’ve seen those tasks in every single job I’ve had.

That lesson didn’t make it into Street‑Smart Coding, but inside you’ll find 30 practical lessons to level up your coding skills.

12 Interesting Questions to Ask

2026-03-27T00:00:00+00:00

Here’s my 10-idea list today—Well, I wrote 12:

What can I only do?
Who can I ask for help?
How can I help more people?
What interesting stories can I tell?
What “unscalable” things can I do?
What new context can I put my work in?
What existing ideas can I combine in new ways?
How can I get out of my comfort zone?
How can I become more valuable?
What visual identity can I use?
What experiments can I run?
What can I simplify?

Friday Links: AI, Excel, and nostalgic sounds

2026-03-27T00:00:00+00:00

Hey there.

This week, for the nth time, I had to bulk import records via an Excel file. It made me think, no matter how complex the code, it often boils down to reading and writing Excel files. Maybe we should build Excel add-ons or plugins instead of enterprise software. Thoughts?

Anyway, here are 4 links I thought were worth sharing this week:

#1. Worried about running out of work in the age of AI? (13min). We can learn from the auto industry. And no, they didn’t run out of work.

#2. I’m always amazed by how much you can accomplish with the command line. Here are some small programming tricks (6min), some of them for the CLI.

#3. Headlines saying coding is dead are exaggerated (10min). Coding isn’t going anywhere.

#4. For a bit of nostalgia, here’s a list of obsolete sounds. The modem dial-up…Anyone else?

And in case you missed it, I wrote on my blog about why you need an intention for a successful career (3min). That was a follow-up on the most painful mistake from my best job (3min).

(Bzzz…Radio voice) This email was brought to you by… 10 Surprisingly Simple Ideas That Changed My Life And Could Change Yours Too. If you’ve wondered how to actually change your life, this book shares 10 small daily ideas for big change.

See you next time.

Cesar

This Simple Exercise Crushes Writer's Block In Four Minutes

2026-03-25T00:00:00+00:00

There’s nothing more intimidating than a blank page.

That was me today. I scrolled Hacker News, minifeed, and LinkedIn. I was looking for a subject to steal, but nothing inspired me.

Yesterday was easier. The most painful lesson from my best job sparked a discussion on dev.to. I just replied to that discussion.

Waiting for the muses, I tried a course called Write 4 a day. The first exercise was to write by hand for four minutes, whatever comes to mind, without judgment.

I had nothing to lose. So I tried it.

This exercise is like a 4-minute version of Julia Cameron’s Morning Pages, at anytime. It works: I’m writing these lines.

If you’re blocked, grab pen and write for 4 minutes. That’s all you need to unlock your words.

If after 4 minutes, you’re still blocked: try this trick or any of these prompts.

Why You Need An Intention For Your Coding Career

2026-03-24T00:00:00+00:00

Last week, I wrote about the most painful lesson my best job taught me. Recently, I shared it on dev.to. The concept of a “plan” generated some discussion. Here I’m expanding on that.

It took me over 10 years to connect the dots.

For years, I didn’t have a career plan. I jumped from job to job feeling something was missing. OK, when I say “jump,” I mean fired, bored, and laid off. That was my most painful lesson. It cost me my health at the lowest point.

A “plan” sounds like a blueprint with every career scenario figured out in advance.

Nobody starts with a perfect plan. The early stages of our careers are about discovery, experimentation, and building skills while learning to navigate the corporate world.

Plans are hard to follow when layoffs are always around the corner and AI is changing job descriptions.

An intention helps you decide when to move

Instead of “plan,” think of an intention: a guiding principle that helps you decide whether to stay or move on.

There’s always luck, setbacks, and resets. It’s impossible to account for all of them in a “plan.” But an intention pushes you to act instead of waiting.

Here’s how an intention helps you in practice.

If your intention is money, a couple of years without raises or bonuses should push you to move. That’s not the job that will fill your pockets. Maybe a better choice would be joining a startup in early stages.

If your intention is growing a network, sitting in a cubicle isn’t the best idea. A better role might be DevRel, evangelist, or consultant, positions that takes you out of your cubicle.

Money was just an example. It could be gaining leadership experience, climbing the ladder, or learning opportunities.

Use your career intention as your flashlight. Otherwise, wait to leave only when bored, fired, or burned out. I wish someone had told me that when I started my coding career. It would have saved lots of headaches. Set your intention today.

If you liked these lessons, you’re going to like, Career Lessons From the Trenches, my free 7-day email course where I distill 10+ years of career lessons into 7 short emails–to help you navigate your coding career.

The #1 Benefit of Consistently Writing Online

2026-03-23T00:00:00+00:00

At first, I only wrote when I had something to share. That was once or twice a year.

Then, I challenged myself to write every other week. I was playing the SEO game. I packed headlines with keywords and wrote posts to land on Google’s first page.

Years later, to recover from burnout, I pushed myself to write daily.

A daily writing practice taught me to find ideas quickly, write away from my desk, and build a creative routine.

The Time Capsule Effect

Apart from those three benefits, the #1 benefit is what I call the time capsule effect.

After +600 daily posts, I can jump to almost any date to see what I was learning, struggling, or sharing. A couple of years ago, I was learning how to outline a book and wondering when to call myself a writer.

Reading old posts and thinking “I’d do it better today” shows how much our skills have improved. That only happens with consistent practice.

Show up consistently, and you’ll build a time capsule that future-you will treasure.

4 Fresh Ideas On Monetization and Marketing from Last Week

2026-03-22T00:00:00+00:00

Yesterday, I shared 5 Ideas on growth and money. To build on that, here are 4 fresh ideas about content creation, monetization, and networking from last week:

#1. Run a $1/month club

Monetizing your content doesn’t have to be complicated.

If sales make you nervous, offer a simple $1/month membership. No fancy tiers. No paywalls. Just $1. Manuel Moreale made the concept popular. Now there’s a club of $1/month creators. That doesn’t sound that bad at all. Maybe I’ll join the club.

#2. Follow ROOTS

I follow POSSE, aka using your website as your content hub.

But last week I learned about ROOTS, Return Old Online Things to your own Site.

If you’ve guest posted or collaborated, archive those posts on your site. I have at least 4 or 5 posts that I could “root.”

#3. A 90-day note

Losing my job has taught me the value of networking. Most job applications hide behind phone calls and recommendations.

If you wait until you lose your job to network, it’s too late. Why not keep in touch with colleagues and friends with a quarterly email? It’s like catching up at a party, but via email.

Jason Shen, a business coach, started sending that email years ago. He calls them a 90-day note.

#4. Write 52 PS to promote your books

You can’t write a book and expect endless sales. That rarely happens.

Like any other product, your book requires promotion. But you don’t need podcast tours, TV appearances, or expensive agencies.

You can write more books to promote your earlier ones. Or, as Chris Stanley suggests, you can include 52 PS in your content, promoting your book. This reminds me of Mark Thompson’s Next Step strategy.

5 Fresh Ideas On Growth And Money from Last Week

2026-03-21T00:00:00+00:00

To unclutter my brain and take public notes, here are 5 interesting ideas I found last week:

#1. Workout using antagonistic supersets

Improving my health led me down a fitness rabbit hole. I found Dr. Michael Israetel and his YouTube channel.

Well, you don’t need to spend hours every day at the gym.

Most gym time is wasted checking your phone or waiting for machines. Two to three full-body workout sessions per week are enough to be healthy. In just 20 minutes, you can work out every major muscle group by alternating two unrelated muscle groups with minimal rest between sets.

#2. Scrolling is a waste of your potential

Last week, I shared a LinkedIn post with the idea of staying away from social media and your phone as rebellion. I got an insightful comment back: “Scrolling is a waste of your human potential.” Wow!

#3. Work less, but daily

If you’re a creator, freelancer, or “side-gigger,” instead of constantly hustling, aim to work for 2-3 hours, but daily. Short sessions force you to focus and achieve more.

#4. Entrepreneurship doesn’t have to be complicated

You don’t need to worry about creating a business entity, the hustle culture, or complicated systems. Entrepreneurship is way simpler. It’s helping!

#5. Be more valuable to make more money

In Purpose and Profit, Dan Koe shares that, to make money, you have to be helpful to others since nobody will give you money in exchange for nothing. To earn more, make others value you more, solve bigger problems, or help more people.

That concept reminded me of money as fucks given and one of James Altucher’s inspiring quotes, “money is a byproduct of personal development.”

Friday Links: Dead internet, 69 AI agents, and finishing books

2026-03-20T00:00:00+00:00

Hey there.

Here are 4 links I thought were worth sharing this week:

#1. The internet is dead. It doesn’t seem to be a theory anymore (2min). Reddit, LinkedIn, GitHub…AI-generated slop is everywhere. Even bots interviewing bots.

#2. Every week, there’s a new AI tool, model, or prediction. But you don’t have to feel like you’re missing the whole AI train. If you’re not running 69 agents, you’re not behind (3min).

#3. AI shines at speed. We can crank out code faster than ever. But more code means more reviews. Every layer of review makes coding 10x slower (10min).

#4. When was the last time you finished a book? I’m replacing social media with books. But with plenty of distractions, it seems nobody finishes books anymore (14min). That’s a challenge for authors and educators.

And in case you missed it, I wrote on my blog about how we’re helping AI replace us (1min) and the most painful career lesson my best job taught me (3min).

See you next time.

Cesar

Entrepreneurship Doesn't Have To Be Complicated As You Might Think

2026-03-20T00:00:00+00:00

Years ago, I thought entrepreneurship was nothing but risk.

I once thought running a business was crazy: registering a company, hiring employees, waiting for clients to pay… Being an employee was better. A monthly paycheck was safer. I couldn’t have been more wrong! I was young and naive. I had to be fired only once to change my mind.

Recently, to debunk all myths about entrepreneurship, I’ve stumbled upon two simple definitions—I’m paraphrasing them to practice the 7-word summary:

#1. Solving problems

From Purpose and Profit by Dan Koe, entrepreneurship is solving your own problems and distributing your solutions to others.

You don’t need to stare at the ceiling waiting for the perfect idea. If you have solved one of your own problems (losing weight or overcoming burnout, for example), you can share what you did and make some profit.

#2. Making extra money

Recently, during my feed-free week, I picked up Financial Freedom by Grant Sabatier. Apart from early-retirement tactics, his definition of entrepreneurship resonated. He says entrepreneurship is simply finding other income sources.

You don’t need the LLC, employees, or fancy systems from a business coach, but to make money on the side. As simple as that. Of course, he advocates investing that extra money so you can retire before your 60s.

With those two definitions, entrepreneurship feels less intimidating. Maybe you’re already an entrepreneur without realizing it.

The Most Painful Career Lesson My Best Job Taught Me

2026-03-18T00:00:00+00:00

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

The most toxic job I ever had didn’t break me.

I’ve had only one job that fit all the definitions of a toxic place. Inexperienced management, competing deadlines, scope creep… To cope with the 9-5, I hung out with coworkers, worked out, and engaged in hobbies. That kept me sane. But it wasn’t the job that burned me out. It taught me enough lessons for a book.

The way to the exit door was clear.

Lesson: When the pain is real. So is the urge to leave.

The job that burned me out

A few years later, I landed my best job.

I was working from home, learning new subjects, and making a good salary. It wasn’t Silicon Valley, but it was where most coders wanted to be. It turned out more painful than my “worst” job.

Everything was good until the honeymoon ended. Another project doing the same tasks. No new roles for me. All seats were already taken. Same grind, same story.

This time, the way out wasn’t that clear. Updating a CV to play the hiring game made staying seem tolerable. “The pay is good.” “I don’t work overtime.” “I’ll wait until I finish this project.” Meanwhile, hiring trends were tougher and tougher each year.

The next thing I knew, I was rushing to the bathroom. It wasn’t to throw up, but I’ll spare the details.

My job became a burden. I rushed to finish my daily tasks and skipped my meals. Painful mistake! That brought stomach issues. (Eating when stressed out isn’t a good idea.) When I least expected it, I was sick and burned out. The way down was slow. But the way up was more painful and slower.

Lesson: If it makes you sick, you don’t need more signs to leave.

My most painful and expensive career mistake

Not having a career plan was my biggest, most painful, and expensive mistake.

I didn’t stop to think what I wanted out of my career. Money, title, connections, challenge? Maybe my only plan was to gain experience and make some money. Whatever that meant for my past self.

Lesson: Choose wisely. Or wait to leave when sick, bored, fired, or burned out.

A plan or, better yet, a career intention would have made me move out and saved me a lot of pain. But like a frog in a pot, the water wasn’t boiling, it was slowly heating up. By the time I noticed the exit sign, the damage was already done.

The Unexpected Truth AI Reveals about Coding

2026-03-18T00:00:00+00:00

Most people glorify AI for its speed.

AI spits out code faster than any of us, with just a few magic words. Beep, beep, boop. But coding has never been the bottleneck.

In corporate settings, where is most of the time spent? 99.99% of the time, it isn’t coding.

It’s

Waiting for your product owner while they talk to a customer
Waiting for DevOps to create a pipeline for your new project
Waiting for the Finance department to approve a $5 USD/month purchase
Waiting for a committee to decide what to do
Waiting for a code review

AI speeds up code generation. Everything else is as slow as it has always been. And more code means more reviews, builds, approvals, and bugs. More paperwork.

Almost Quit At 500 Daily Posts: My Reflection On Daily Blogging

2026-03-16T00:00:00+00:00

The last 100 posts felt like a real stretch.

I wanted to quit blogging for a while. But I reminded myself: like an athlete, a writer must practice daily, or at least consistently. And stumbling upon Seth Godin’s 10,000 daily posts inspired me to keep pushing. I know I’m far from hitting that number.

Lately, focusing on my health has hurt my streak.

To have healthy sleeping patterns, I’ve started going to bed every day at the same time. That has meant skipping my daily post sometimes. So I tweaked my blogging rules to repair my streak the next day with another post. By the way, I also made some changes to my blog.

For these last 100 posts, balancing health and writing wasn’t easy, but it taught me the value of doing nothing and resting after a sprint of intense work.

I learned that lesson from launching another book, 10 Surprisingly Simple Ideas That Changed My Life And Could Change Yours Too, while trying to balance other projects. Writing that book was a book experiment I ran in February. It already made its first sale and earned its first review.

Here are some of the most-read posts from the last 100 days:

Here are my 100-post, 200-post, 300-post, and 400-post reflections.

My February Book Experiment: Getting The First Review

2026-03-15T00:00:00+00:00

Last February, I started a book experiment. It’s starting to pay off.

Two weeks ago, I launched 10 Surprisingly Simple Ideas That Changed My Life. It got its first sale, making it a success. But I’ve kept the experiment going.

For the last phase, I offered free copies as gifts to “advance readers” in exchange for an honest review.

As a fan of 10-idea lists, I wrote a list of 10 e-friends, ended up messaging 12, and heard back from 6. Two read it but weren’t eligible to review. (Amazon requires $50 in purchases within the last year.) Two managed to leave reviews. One was rejected, the other approved. A 5-star review. Hooray!

Here’s the review on Amazon:

Short but sweet

One sale plus one review. Proof that the experiment is working.

“Short but sweet” shows you don’t need thousands of pages to write a book that matters.

The Secret to Generating Good Ideas

2026-03-15T00:00:00+00:00

Good ideas start as bad ones. You just need enough to find the least bad.

#1.

Tim Ferriss had different titles for his book, 4-Hour Work Week. Probably, there were good and bad titles among those.

He tested titles with ads and picked the one with the most clicks. He started with bad ideas, iterated, then picked the right one.

A similar story with James Altucher and Choose Yourself.

#2.

Last year, I attended a book writing workshop that drilled the value of bad ideas.

One of the tasks was coming up with title ideas. One of the participants had an immigration practice helping people move to Australia. While he waited for the perfect title, I suggested Aussie Job and follow-ups like Aussie Colleges and Aussie Marriages.

I don’t know which title he chose or if he even wrote the book. I just checked Amazon and there’s no Aussie Job. Insert shrugging emoji.

As a fan of 10-idea lists, that exercise was a piece of cake. It was just another daily prompt for ideas.

That workshop pushed me to keep writing my 10 ideas daily.

3.

Don’t wait for a perfect book title, blog post subject, or business idea.

Chasing the “perfect” idea leaves you blocked, waiting for inspiration. Aim for 10 guilt-free bad ideas. Among those you’ll find a decent one that leads you to the right idea.

Put your work out there. Show it. If people like it, they will engage with it and remember it. Otherwise, they won’t.

I’ve published over 600 posts over the years (half of them reposted on Medium and dev.to). Not every single post is a hit. Good ones stand out. People like, comment, and share them. Others go without “fame or glory.”

Then the work is to have more bad ideas, find the least bad, and share them. Rinse and repeat.

Sharif Shameem shared a similar idea. He calls it, Aadil’s Law, named after a friend:

The amount of stupidity you’re willing to tolerate is directly proportional to the quality of ideas you’ll eventually produce

Be willing to look stupid. Write 10 bad ideas every day and let the good ones emerge.

Writing 10 ideas every day has been so valuable that I made it part of 10 Surprisingly Simple Ideas That Changed My Life And Could Change Yours Too Write them daily and watch your life change.

We're Helping AI and Robots Replace Us

2026-03-13T00:00:00+00:00

Take public transportation at rush hour. You’ll notice a clear pattern.

More than half the people are heads down, headphones on, scrolling.

If we don’t take care of our health, we’ll be depressed, sleep-deprived, deaf, people with the attention span of a fish.

Taking care of our health is the first step towards reinvention. After commuting, scrolling, junk food, and poor sleep, we lack the energy and drive to be creative and have new ideas. That’s when AI will eat us alive, when we’re too drained to imagine and create.

Reading, eating healthy foods, and sleeping well isn’t just self-care. It’s an act of resistance.

Friday Links: AI engineers, prompt injection, and job market

2026-03-13T00:00:00+00:00

Hey there.

Here are 5 links I thought were worth sharing this week:

#1. We all might become AI engineers (6min), but we still need to know what to build and how it should work. AI needs hands on the wheel.

#2. AI speeds up coding, but there are plenty of coding activities that aren’t typing (2min). There’s still work for humans.

#3. Last week, another npm package was infected. The interesting part? Someone stole the npm token by injecting a prompt into a GitHub issue (10min). SQL injection isn’t the #1 vulnerability anymore.

#4. If you’re a C# coder using Dapper, be aware of data type conversions that might be slowing down your queries (8min).

#5. If you’ve had a hard time finding a job. You’re not alone. Hiring is as bad as during the pandemic (1min).

Last week, while migrating a legacy app, I wrote about my adventures with Entity Framework Core joining tables (5min) and with Blazor building a component for a HTML editor (4min).

(Bzzz…Radio voice) This email was brought to you by… 10 Surprisingly Simple Ideas That Changed My Life And Could Change Yours Too. This book shares 10 small daily ideas that create big change. I adopted most of them while recovering from burnout

If you’re ready to start small and see big change, check it out.

Until next Friday. Stay coding smartly!

Cesar

The #1 Health Tip From the Guy Obsessed With Living Forever

2026-03-11T00:00:00+00:00

If you could only do one thing for your health, it should be sleep.

Brian Johnson, the guy trying to live forever, teaches in his videos and interviews to be a professional sleeper.

He’s right when he says nobody teaches us to sleep.

For better sleep, build your life around sleep:

Have dinner earlier
Remove screens before bed
Adjust your room temperature
Turn off lights in your room

Beyond the basics, Brian’s recent videos taught me to aim for a lower heart rate before sleep. Try journaling, taking deep breaths, or meditation. Slow down before going to bed.

Staying late for my writing streak taught me rest is the best productivity hack. Coffee can’t fix a bad night of sleep. So go to sleep!

TIL: How to Set Up a Unilateral One-to-One Relationship with Entity Framework Core

2026-03-11T00:00:00+00:00

In another episode of Adventures with Entity Framework while migrating a legacy app…

Entity Framework Core only populated a child entity on one item in a result. To honor the 20-minute rule, and for my future self, here’s what I found:

TL;DR: You don’t need the WithOne() and HasForeignKey() when configuring the relationship.

#1. Let’s create an optional one-to-one relationship.

Let’s create a Movie and an Award table.

USE Movies;
GO
CREATE TABLE Awards (
    Id INT PRIMARY KEY IDENTITY(1,1),
    Name NVARCHAR(100) NOT NULL
);
CREATE TABLE Movies (
    Id INT PRIMARY KEY IDENTITY(1,1),
    Name NVARCHAR(100) NOT NULL,
    AwardId INT NULL /* <-- Optional. No FK here */
);
GO

Since the relationship is optional, the AwardId is nullable. This type dictates what JOIN Entity Framework Core uses.

#2. Configure the one-to-one relationship

Let’s configure the relationship using HasOne() and WithOne().

using Microsoft.EntityFrameworkCore;

namespace LookMaWhatEntityFrameworkDoes;

public class Award
{
    public int Id { get; set; }
    public string Name { get; set; }
}
public class Movie
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int? AwardId { get; set; }
    //       ^^^
    // Optional

    public Award Award { get; set; }
}

public class MovieContext : DbContext
{
    public MovieContext(DbContextOptions<MovieContext> options) : base(options)
    {
    }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder
            .Entity<Movie>()
            .HasOne(m => m.Award)
            .WithOne()
            .HasForeignKey<Movie>(m => m.AwardId)
            .OnDelete(DeleteBehavior.Restrict);
    }

    public DbSet<Movie> Movies { get; set; }
    public DbSet<Award> Awards { get; set; }
}

To verify Copilot’s answer, I went through the official docs here.

#3. Retrieve movies and their awards

And now, let’s create an award, add two movies, and retrieve them to check their awards.

using Microsoft.EntityFrameworkCore;

namespace LookMaWhatEntityFrameworkDoes;

[TestClass]
public class MovieTests
{
    [TestMethod]
    public async Task AllAwardsPlease()
    {
        const string connectionString = $"Server=(localdb)\\MSSQLLocalDB;Database=Movies;Trusted_Connection=True;";

        var options = new DbContextOptionsBuilder<MovieContext>()
            .UseSqlServer(connectionString)
            .LogTo(Console.WriteLine)
            .Options;

        // 1. Let's create an "Oscar"
        using (var context = new MovieContext(options))
        {
            context.Awards.Add(new Award
            {
                Name = "Oscar"
            });
            context.SaveChanges();
        }

        // 2. Let's create two movies that have won an "Oscar"
        using (var context = new MovieContext(options))
        {
            var oscar = await context.Awards.FirstOrDefaultAsync();
            Assert.IsNotNull(oscar);

            context.Movies.AddRange(
                new Movie
                {
                    Name = "Forrest Gump",
                    AwardId = oscar.Id
                },
                new Movie
                {
                    Name = "Titanic",
                    AwardId = oscar.Id
                }
            );
            context.SaveChanges();
        }

        // 3. Let's retrieve all movies, expecting to have an Award
        using (var context = new MovieContext(options))
        {
            var movies = await context.Movies
                                // Imagine more filters here			
                                .Include(m => m.Award)
                                // ^^^^^
                                // Yes, I'm including it here
                                .ToListAsync();

            foreach (var movie in movies)
            {
                Assert.IsNotNull(movie);
                Assert.IsNotNull(movie.Award);
                //     ^^^^^
                // Assert.IsNotNull failed.
                // Play sad trumpet sound.
            }
        }
    }
}

Sorry for the foreach inside the Assert. That’s not a good idea. But I’m lazy and I’m taking too long writing this.

Yes, it fails. Play sad trumpet, please. The second movie’s award isn’t populated. Arrggg!

My fault!

#4. Ignore WithOne()

Since I’m setting an unidirectional relationship, one movie/one award/multiple movies, only configuring HasOne() is enough.

Using WithOne() was telling Entity Framework Core that one award could only belong to one movie. And that’s not the case here.

public class MovieContext : DbContext
{
    public MovieContext(DbContextOptions<MovieContext> options) : base(options)
    {
    }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        // Remove the entire configuration
		// Or,		
        modelBuilder
            .Entity<Movie>()
            .HasOne(m => m.Award);
            // ^^^^^
            // Just this
    }

    public DbSet<Movie> Movies { get; set; }
    public DbSet<Award> Awards { get; set; }
}

And since I’m following default naming conventions, I could even delete the configuration. Ahh, Cascade sets to null, which is fine here.

Yes, the right answer is to do nothing.

Et voilà!

For debugging and problem-solving tips, read Street-Smart Coding. Those two skills are more relevant now in the era of AI-assisted coding.

Building a Reusable Blazor Component for Summernote

2026-03-09T00:00:00+00:00

In another adventure with Blazor…

While migrating a legacy app, I had to “componentize” an HTML editor. It used Summernote, “a super simple WYSIWYG editor on Bootstrap”.

The fun part was learning JavaScript interop: calling JavaScript from .NET and viceversa.

After some Googling and sneaking into abandoned GitHub repos, here’s what I came up with:

The component

In Summernote.razor:

@using Microsoft.AspNetCore.Components.Sections

<HeadContent>
    <link rel="stylesheet" href="css/summernote.css" />
</HeadContent>

<div id="@_id">@((MarkupString)Value)</div>

<SectionContent SectionName="scripts">
    <script src="js/summernote.js" type="text/javascript"></script>
</SectionContent>

In Summernote.razor.cs:

using Microsoft.AspNetCore.Components;
using Microsoft.JSInterop;

namespace MyCoolComponents.HtmlEditor;

public partial class Summernote : IAsyncDisposable
{
    private readonly string _id = $"summernote_{Guid.NewGuid()}";

    private IJSObjectReference? _module;
    private DotNetObjectReference<Summernote>? _dotnetRef;
    private bool _editorInitialized = false;

    [Parameter]
    public string Value { get; set; }

    [Parameter]
    public EventCallback<string> ValueChanged { get; set; }

    [Inject]
    public IJSRuntime JsRuntime { get; set; } = default!;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (!_editorInitialized)
        {
            _dotnetRef = DotNetObjectReference.Create(this);

            _module = await JsRuntime.InvokeAsync<IJSObjectReference>("import", "./PutYourPathHere/Summernote.razor.js");
            await _module.InvokeVoidAsync("edit", _id, _dotnetRef, nameof(OnTextChange));

            _editorInitialized = true;
        }
    }

    [JSInvokable]
    public async Task OnTextChange(string editorText)
    {
        Value = editorText;
        await ValueChanged.InvokeAsync(editorText);
    }

    public async ValueTask DisposeAsync()
    {
        if (_module is not null)
        {
            await _module.DisposeAsync();
        }

        _dotnetRef?.Dispose();
    }
}

Here’s where the magic happens.

After rendering the component, it calls a JavaScript function that initializes the Summernote editor. Then, it registers a callback that calls a .NET function every time the editor changes to update the component state.

Notice it stores content in a MarkupString but it binds as a string.

In Summernote.razor.js:

export function edit(id, dotnetRef, callback) {
    let snid = '#' + id;
    $(snid).summernote({
        callbacks: {
            onChange: function (contents, $editable) {
                dotnetRef.invokeMethodAsync(callback, contents);
            }
        }
    });
}

How to use it

And here’s a sample form using the editor:

@using MyCoolComponents.HtmlEditor

<EditForm Model="MyCoolRequest" OnValidSubmit="OnValidSubmit">
    <DataAnnotationsValidator />
    <ValidationSummary />

    <div class="row">
        <div class="form-group col-sm-9">
            <label for="content" class="form-label">Content</label>
            <Summernote @bind-Value="Annotation.Content" />
            @* ^^^^^ *@
            @* Look, Ma! It works! *@
            <ValidationMessage For="() => Annotation.Content" class="invalid-feedback" />
        </div>
    </div>

    <button type="submit" class="btn btn-primary">Submit</button>
</EditForm>

This piece of code is provided “as is”, without warranty of any kind…Blah, blah, blah. Use under your own risk. Steal it.

If this helped you, you’ll love Street-Smart Coding—30 proven lessons to help you level up your coding journey.

Ten Reading Rules to Read More—and Love It

2026-03-09T00:00:00+00:00

Inspired by Ryan Holiday’s reading rules, I’ve decided to come up with my own to truly enjoy reading.

I’ve had to change my mind about books. From chasing a book count to reading for action and pleasure.

Here are my 10 reading rules:

#1. Always be reading something. At least one page a day. Like Jim Kwik says, reading is like exercise for the brain. And when scrolling and distractions are the norm, reading is a revolution.

#2. Reading over phone time and social media. To reduce my phone time, I use books as conscious replacements. I leave books where I usually leave my phone to break the habit of scrolling.

And after a week off social media, I now read first thing in the morning instead of checking email or social media.

#3. Read two books at once. Balance non-fiction and fiction books. Non-fiction starts my mornings and fiction helps me unwind as night.

#4. Write a book recommendation. While reading a book, write a list of all books mentioned in the book. This is like climbing the inspiration tree as Austen Kleon says in Steal Like an Artist.

#5. Read actively. Write in margins, fold corners, underline, highlight. Your book marks can become a legacy. A book without marks is a book you haven’t read.

#6. Write a 10-idea list. I’m a big fan of 10-idea lists. Instead of note-taking apps, I write 10 ideas that resonate after finishing a book. It forces me to recall and remember what I read. Bonus point when paired with a 7-word summary.

#7. Reread. I’ve had to reconcile myself with rereading. It used to be a sin when I wanted to hit a large book count. The goal is to gain insight, not just hit a book number. Rereading is fine.

#8. Prefer physical books. They give you spatial clues to remember information. You might remember that an important concept is on a left-hand page, near the bottom. eBooks can’t beat that.

#9. No shame in piling books. From How to Be Rich by Ramit Seti, I learned we shouldn’t cut on things we love. I’m not cutting on books.

You’re the books you’ve read. And those you haven’t read yet. Just don’t let your books become “shelve-help.” Build a pile, go through it, then build another one.

#10. Binge-read your favorite writer. I did it when I found James Altucher for the first time. It shows you how their voice change and how your perspective expands.

My February Book Experiment Is Already A Success—But Still in Progress

2026-03-07T00:00:00+00:00

Last February, I decided to write another book but in a completely different way.

I started from a validated idea. I turned my most popular personal development post, into a mini book. Instead of starting with the first words, I began with the outline, title, sales page, and cover. I wrote it backwards.

Here’s the final result: 10 Surprisingly Simple Ideas That Changed My Life And Could Change Yours Too.

My success metric was a single sale.

Yesterday, I announced my book in my Friday Links email and one reader bought it. A small victory dance.

First sale

With that milestone reached, here’s how I’m continuing the experiment:

Reach out to my “advance readers” team to get my first review on Amazon.
Promote my book via a book promotion email list for more reach.

This experiment will shape my launching strategy for future books. The real works begins after the writing is done.

Friday Links: Life changes, leaving Google, and lone wolves

2026-03-06T00:00:00+00:00

Hey there!

Burnout hit me hard in 2023. It changed everything.

It hurt both my mind and my body. I was at my best coding job. Then, in 2024, I was laid off. Perfect combo, right?

The way up was slow. Master plans didn’t work. Getting up felt impossible.

One quote inspired me to get up: “If you’re lost, start with your health.” That became my first step.

Small daily actions made change possible.

That journey led me to write 10 Surprisingly Simple Ideas That Changed My Life And Could Change Yours Too. I’m launching it this week.

This isn’t a 7-day program or a magic formula. It’s about small daily ideas that create big change.

And as usual, here are 4 stories that resonated with me this week:

#1. I don’t use Google as my default search engine, but I still use it for email. For digital hygiene or simply for boycotting big corporations, leaving Google may improve your digital life too (7min)

#2. Hiring sucks. CVs, interviews, recruiters…But the best way to think of hiring is a two-way sales negotiation. If you’re looking for a job, here’s a piece of advice you shouldn’t miss (5min)

#3. AI is changing our job descriptions… and killing the need for junior coders. AI is splitting the dev population into expert beginners and lone wolves (8min)

#4. The next time I’m asked what superpower I’d like to have, I’d say talk to anyone in any situation. Here’s a good story from The Guardian (14min) about it.

Thanks to the internet, a February post got traction last week. In case you missed it, here are the numbers that deflate the AI hype about replacing coders—and ease FOMO (2min).

(Bzzz…Radio voice) This email was brought to you by… 10 Surprisingly Simple Ideas That Changed My Life And Could Change Yours Too. If you’re ready to start small and see big change, check it out.

Until next Friday. Keep coding smartly!

Cesar

What to Do to Thrive in the AI Era

2026-03-05T00:00:00+00:00

Whether you see it as a tool or a breakthrough, AI is changing jobs.

Translators are panicking. Some coders brag about “coding” from their phones. Every new tool and model fuels AI FOMO.

Real numbers about AI adoption tell one story. CEOs tell another. Maybe we’re all doomed. Predictions are hard. I hope I wasn’t wrong with mine.

Here are 2 ideas about how to AI-proof yourself:

#1. Learn to learn

From 21 Lessons for the 21st Century, the only skill to learn is the ability to learn new things.

The only certain thing is change. And being able to adapt is crucial. Pick new skills you enjoy. Bonus points if they earn money.

#2. Literacy and health

Papyrus made me think about the future.

It’s a book about the invention of books in the ancient world. But the past teaches us about the future.

In ancient Greece, free men learned to read, talk, and think, and took care of their bodies. Manual labor was for slaves. Of course, that wasn’t a good thing.

If AI takes over repetitive work, as slaves once did in ancient Greece, we’ll be like free to focus on creativity and growth.

Maybe AI will kill most knowledge jobs, because it thrives on tasks humans do and hiring people may no longer make economic sense.

Until then, while waiting for universal basic income or or something darker, I’m doubling down on writing and chasing my curiosity—simply because I enjoy it.

I Compiled The 10 Simple Ideas That Truly Changed My Life Into A Book

2026-03-04T00:00:00+00:00

10 Surprisingly Simple Ideas That Changed My Life And Could Change Yours Too

Big plans rarely change your life.

In 2023, life forced me to change. Burnout hit me hard. It hurt both my mind and my body. My poor eating habits only made things worse. Then, in 2024, I was laid off. The last nail in the coffin. It felt devastating.

The way up was slow. Master plans and New Year’s resolutions didn’t work. A new life felt impossible.

One single quote inspired me to get up: “If you’re lost, start with your health.” That quote became the foundation of Chapter 1 and the real step toward change.

Small daily actions made real change possible.

That’s why I wrote 10 Surprisingly Simple Ideas That Changed My Life And Could Change Yours Too. If you’ve ever asked, “How do you actually change your life”, this is for you.

Big plans don’t change your life. Small daily actions do.

Preview of the first ~10 pages

Forget passion and master plans. This book is about the tiny daily actions that actually change your life. I know because they changed mine.

Inside this book, you’ll find 10 surprisingly simple ideas that changed my life, and can change yours too:

Idea #1: The mindset shift that gave me purpose when I couldn’t get out of bed.
Idea #2: The daily habit that keeps burnout away.
Idea #3: The productivity hack that doubled my focus.
Idea #4: The free advice that saved me during my hardest year.
Idea #5: The creative practice that helped me write books and countless articles.

…and five more life-changing ideas you can start using right away.

This isn’t a 7-day program or a magic formula. It’s about small daily ideas that create big change.

Get your copy here—For launch week only: You can even just pay $1. Begin your transformation today.

Start small. Change big.

PS: Also available on Kindle and paperback

Five Changes I'd Like To Make On My Blog

2026-03-03T00:00:00+00:00

To keep myself accountable, here’s a list of changes I’d like to make on my blog:

#1. New About copy. I still have the one from the days I was looking for a full-time job as a coder. That’s not the case anymore. These days, I’m a digital writer with a part-time coding job.

#2. More recent “Start Here.” The “Start Here,” on my About, dates back to my full-time coding days, with only tutorials. Google and AI have killed tutorials. And I’m not writing as many coding tutorials anymore.

With metrics from other platforms, I follow POSSE, it’s time to update it with my most liked content.

#3. New tags. This started as a coding blog. Five years ago, my first post was a coding tutorial. Over time, it became my small corner, where I write about almost anything.

In 2024, when I started my daily writing challenge, I created a /misc tag. But, naturally some patterns have arisen,

Health
Experiments
Book writing
Random thoughts
Personal development

#4. Book page. On the left sidebar, I feature my projects and open source contributions. It’s time to feature my books instead.

In the last year, I updated Start Testing and launched Street-Smart Coding. And I’m about to finish another book experiment.

#5. On this date widget. Sometimes I’ve written “On This Date” posts, like this one and this one. I write about the posts from past years written on the same date. I’d like to create a small widget to automate that. Under every post show 2 posts from previous and following years.

That’s one of the best parts of having a blog: you can tweak it however you want. Try beating that, social platforms!

Update (Mar 2026): Here are the changes I’ve made so far:

I updated the Start here section on my about.
I created these tags: wellness, self growth, book writing, experiments.
I wrote a books page

Update (Apr 2026): More changes:

I made the left bar scrollable.
I tweaked my homepage and my about.

Five Simple Blogging Rules for Consistency

2026-03-03T00:00:00+00:00

This blog started as a coding notebook, but now it’s my small corner of the web.

I’ve changed what a post is. It used to be tutorials. I spent time designing covers with Canva and picking images from Unsplash. I wanted it to look like a “real” blog. Those days, around 2022, I shared my posts on LinkedIn to boost traffic and get attention.

But writing daily posts left no time for covers and images. To stay consistent, I simplified my approach and adopted some rules. I first shared them here and here, but now I’m updating them:

#1. Write short pieces. You don’t have to write breakdowns or 2,000-word posts. If it’s longer than a tweet, publish it. A good headline plus some sentences works. A 10-idea list works. Some random thoughts are worth publishing.

#2. Write reaction posts instead of comments.

Preserve your keystrokes by replying on a post.
Title your reaction post with “re:”

#3. Make your urls easy to pronounce.

#4. If you miss a day, write two posts the next day.

#5. Use your posts multiple times. Repost them on another platform. Use them as book chapters. Share shorter versions on social media. You can steal from yourself.

Writing Devices From Slow Horses, Season 5

2026-03-01T00:00:00+00:00

TV shows are a good writing classes.

These days, I binge-watched Slow Horses Season 5. Not that I’m a fan of spy shows.

After watching one of the first episodes, I noticed how good episode endings it has.

So I watched the rest of the season with my writer’s glasses on, here are some of the devices I noticed—No spoilers:

Increasing tension in every episode. The enemy is using the same strategy the Brits used in them during the Cold War. Each episode follows one of the steps.
Plot twist. The innocent turns out to be not that innocent.
Ending episode with revelation. One episode ends without any dialog or action scene, but with a text message.
Connecting elements. A box full of souvenirs and a tape recorders show up in screen, connecting the plot between episodes.
The season ends connecting with the first episode. One of the protagonists makes a phone call, following up a conversation from the first episode.
Make you hate a character. That’s not the villain, but a protagonist used as an “useful idiot.” You just hate it by the end of the season. Give characters some life.

More TV show breakdowns: Black Doves, Not Really on Purpose, and House M.D..

Sometimes You Just Need to Be A Collector

2026-03-01T00:00:00+00:00

For my February book experiment, I wanted to open each chapter with a powerful quote. Stealing from Mastery by Robert Greene.

But then I realized I didn’t have enough quotes. I needed at least ten. I didn’t want to Google or ChatGPT for quotes and get the same quotes every motivational post uses. It was too late to read or surf the web looking for quotes.

That’s when I wish I had been a quote collector.

I remember Austen Kleon, author of Steal Like an Artist and Show Your Work, who has a notebook for quotes and then he transcribe them.

I wish I had joined the notebook cult.

Friday Links: AI, LinkedIn, and the missing CS semester

2026-02-27T00:00:00+00:00

Hey, there.

Here are 4 thought-provoking links I found this week. Plus my reflections after a week off social media.

#1. AI makes code cheaper, but cheap code means not understanding what you’re building. “Use AI or stay behind” shouldn’t be the real mantra. It should be rely on AI and get left behind (4min).

#2. College and bootcamps don’t teach the skills you need for real-world coding. That’s why I wrote Street-Smart Coding, by the way. This week, I found an updated version of The Missing Semester, a free course covering text editing, version control, agentic coding, and other skills nobody else teaches.

#3. Do you want to see a blue shield on your LinkedIn profile? Think twice after seeing all the data LinkedIn and friends collect to verify us (12min).

#4. Now with cheaper code it’s finally time to tackle the real bottlenecks (3min). And no, coding and typing were never the bottleneck.

I spent last week away from social media, and it turns out I’m another dopamine junkie (4min), even with mindful use and a timer. Arrggg!

(Bzzz…Radio voice) This email was brought to you by… Street-Smart Coding, 30 lessons to help you code like a pro. From Googling to clear communication, it covers the lessons you don’t learn in tutorials. It’s now out on Kindle and paperback on Amazon.

Until next Friday. Keep coding smartly

Cesar

BugOfTheDay: Entity Framework Core And SQL Server Have Different Takes On Truncating Strings

2026-02-26T00:00:00+00:00

A subtle detail easy to forget when working with legacy applications that use stored procedures.

Stored procedures swallow long strings

If you’re inserting a long string into a shorter column, SQL Server truncates the parameters with no complaints,

USE Movies;
GO
CREATE TABLE Movies (
    Id INT PRIMARY KEY IDENTITY(1,1),
    Name NVARCHAR(10) NOT NULL /* <-- A 10 here */
);
GO
CREATE PROCEDURE InsertMovie
    @Name NVARCHAR(10) /* <-- Notice the "10" here */
AS
BEGIN
    INSERT INTO Movies (Name)
    VALUES (@Name);
END;
GO
/* @Name is a NVARCHAR(10), but the value is longer than 10 */
EXEC InsertMovie @Name = 'ThisMovieNameIsWayTooLongForTheColumn';
GO

The stored procedure “swallowed” that long parameter. No complaints! But wait to see what Entity Framework does.

Entity Framework doesn’t validate or truncate

Now, if we try to do the same inside a unit test,

using Microsoft.EntityFrameworkCore;

namespace LookMaWhatEntityFrameworkDoes;

public class Movie
{
    public int Id { get; set; }
    public string Name { get; set; }
}

public class MovieContext : DbContext
{
    public MovieContext(DbContextOptions<MovieContext> options) : base(options)
    {
    }

    public DbSet<Movie> Movies { get; set; }
}

[TestClass]
public class MovieTests
{
    [TestMethod]
    public async Task TruncateItPlease()
    {
        const string connectionString = $"Server=(localdb)\\MSSQLLocalDB;Database=Movies;Trusted_Connection=True;";

        var options = new DbContextOptionsBuilder<MovieContext>()
            .UseSqlServer(connectionString)
            .LogTo(Console.WriteLine)
            .Options;

        using (var context = new MovieContext(options))
        {
            context.Movies.Add(
                new Movie
                {
                    Name = "RememberThatNameInTheDBHasSize10"
                }
            );
            context.SaveChanges();
            //      ^^^^^
            // Test method LookMaWhatEntityFrameworkDoes.MovieTests.TruncateItPlease threw exception: 
            // Microsoft.Data.SqlClient.SqlException: 
            // String or binary data would be truncated in table 'Movies.dbo.Movies', column 'Name'. Truncated value: 'RememberTh'.
        }

        using (var context = new MovieContext(options))
        {
            var movies = context.Movies.ToList();

            Assert.IsNotNull(movies);
        }
    }
}

Entity Framework Core blows in your face. At least, it tells you the table and column names, and the value being truncated.

Another subtle detail worth remembering. Et voilà!

Here’s another Entity Framework gotcha: Nullable foreign keys

This TV Show Is a Masterclass On Episode Endings

2026-02-25T00:00:00+00:00

TV show are a great source of writing devices.

I’ve been binged watching Slow Horses, season 5. An espionage series in present-day London about a team of problematic MI5 agents, relegated to a forgotten office.

Even though, they’re labeled as poor performers—slow horses—they always end up saving the day.

After watching the first three episodes of season 5, I realized each one has ended in a dramatic way.

The second episode ends with a text message that makes you rush to click on “Next episode.” One of the protagonists, against all odds, is dating a pretty hot woman. Or that’s what he thinks. The text message reveals the girl’s true intention in a “wait, what” moment right at the end of the episode.

It reminded me of one of James Altucher’s writing tricks: start with blood or drama, end with a cliffhanger.

I Spent a Week Without Social Media—And Realized I'm Just Another Junkie

2026-02-24T00:00:00+00:00

One LinkedIn post pushed me to quit social media for a week.

I’ve been writing on LinkedIn (and other social blogs) for two years. And to “grow” my account as a creator, I’ve been following common advice: “be your own case study” and “engage after posting.” I questioned that advice, yet still spent an hour a day engaging.

I had two wake-up calls:

Noticing my phone time. 2h18min on average the week before.
Finding a post inviting people to disappear from the Internet without apologies, announcements, or guilt. I did that—kind of.

For a week, I stayed away from anything with a feed: Medium, LinkedIn, dev.to, YouTube, Reddit…But I still scheduled my weekly content for the platforms where I write.

You need an intention and a replacement

Ignoring my own productivity advice, I checked my email and socials before work.

When planning my feed-free week, I thought I needed an app/website blocker. But starting the first day with an intention was enough. “No social media today.”

Instead of scrolling, I read.

That week, I finished Papyrus by Irene Vallejo and got halfway through Financial Freedom by Grant Sabatier. In fact, I’ve been replacing my phone time with books in the last month.

Lesson #1: Don’t simply ban social media, replace them with conscious activities instead.

Don’t make scrolling your go-to activity

I hadn’t realized how scrolling had changed my behavior.

On day two, I was on a weekly meeting with a contracting client. “Another meeting that could be an email” kind of meeting. Nothing unusual until I noticed I wanted to fire up my LinkedIn account to make it until the end. I wanted a feed to scroll, like an addict.

Those moments made me realize scrolling was my default response to boredom.

Lesson #2: When procrastination comes, start with an easy task and sustain for 5 minutes. That’s enough to keep things moving forward.

Lesson #3: Find a boring activity instead of scrolling on social media. I’m doodling on the back of old receipts.

Even with an intention, books, and doodling, my monkey brain often popped up trying to trick me back to social media:

“What if my account got suspended for lack of engagement?”
“Did my posts generate visits to my book landing pages?”

To quiet the monkey brain, I learned to distance from it and refute my thoughts with rational ones:

“You received a notification of your scheduled posts going live. The system is working.”
“Let your content system run. You don’t need to refresh stats every 5 minutes. Let the Internet do its magic.”

Lesson #4: Social media tricks (whistles, notifications, bells) work. We need a lot of effort and intention to fight back.

“Warming up” the algorithm isn’t worth the time

To finish the experiment, earlier today I logged into my social media accounts.

In some platforms, my impressions suffered. Maybe it was just coincidence. In another one, one of the two scheduled long-form posts was a hit.

As usual, my best posts still spiked in views and thoughtful comments.

“Warming up” the algorithm with hacks (engaging before posting, like and reshare your own posts) isn’t worth the time and the addiction it creates.

Lesson #5: Good posts stand out without hacks.

Handling them with care

After my feed-free week, here are some long-term changes I’m adopting, both as a reader and writer:

No email notifications from social media.
Zero feeds before creative work. Timer on socials for conscious use.
Weekly posts scheduled in advance. Have 2 or 3 weekly slots for engagement.
Feed-free mode when working on creative projects or experiments.

I thought I wasn’t an addict. I thought I used social media consciously. I thought I was a dealer who didn’t use their own drug. Stepping away showed me I was just another dopamine junkie. Social media, like every billion-dollar industry, thrives on keeping us hooked.

A Key Hack That Will Save You a Lot of Headaches And Nightmares

2026-02-24T00:00:00+00:00

Here’s the hack:

Make sure everybody at home has copies of all keys, like every door and lock.
Give a trusted friend spare keys and a backup with your password manager’s recovery key.

Not that I had to break into my own apartment…Wink, wink! It sounds funny until it happens.

7 Lessons From Papyrus on How Books Began

2026-02-22T00:00:00+00:00

When you hear the word “book,” what comes to mind?

A cover, back cover, and spine? Sheets of paper bound to flip from left to right? Printing machines?

Books are recent, but their fascinating origins stretch back thousands and thousands of years. That’s precisely what Irene Vallejo tells us in Papyrus: The Invention of Books in the Ancient World.

Here are 7 lessons I took away from this book:

#1. Kids didn’t learn with easy books.

My dad bought my sister a book with Franklin the turtle every time she won an exam. Like her, we grew up reading books for kids: easy sentences filled with images.

But kids in Ancient Greece didn’t have easy books. They learned with the Iliad and Odyssey by Homer. To make things worse, ancient Greek didn’t have spaces, paragraphs, or punctuation marks…and teachers were ruthless.

#2. Book copyists worked for centuries.

In Athens, getting a book meant sending someone to Alexandria, Egypt to copy it. Sometimes I complain when it takes a month to receive a book.

#3. Titles, binding, and pocket books are recent inventions.

For centuries, we had rolls instead of books.

To read a scroll, you rolled it with your left hand while unrolling it with your right one. When finished, you rolled it back up as a courtesy for the next reader. Instead of titles, librarians categorized books by their opening sentences.

#4. Books were read out loud.

In school, I learned to read sitting in a circle taking turns to read a passage from an easy story. Then, we had to do it in silence.

But in ancient times, reading out loud was the norm. Reading a book was like a small prayer, a soft monologue.

#5. Iliad and Odyssey were best-sellers.

Probably every educated citizen in Ancient Times knew about them. Even kids learned to read with them.

#6. Education included the body as well as the mind.

Apart from reading, men had to work on their bodies as part of their education. A privilege reserved for higher classes and free men. Slaves were meant only for manual labor.

To strengthen their bodies, men trained outdoors or in gymnasiums showing off their bodies…while naked. Next time you see some “bros” posing and taking selfies in front of a mirror after lifting some weights at the gym, remember it used to be worse in ancient times.

#7. Books won’t die.

Books haven’t always looked the same: clay, stone, leather, papyrus, codices, paper… But they have endured the test of time. eBooks, summaries, TikTok, or AI aren’t a real threat for books. We’ve had them for centuries. And we will for more.

10 Simple Habits That Improved My Digestion

2026-02-22T00:00:00+00:00

Burnout brought stomach issues I couldn’t ignore.

In 2023, one day, I suddenly had to rush to the bathroom after eating. I wanted to finish my work so fast that I skipped meals and developed poor eating habits.

After many doctor visits, here’s a compilation of 10 ideas for better digestion and eating habits.

Eat at consistent times.
Eat liquids and solids separately.
Chew every bite at least 10 times.
Remove distractions like phones and news while eating.
Follow the right order to avoid glucose spikes.
Stop before you’re completely full.
Pause briefly after finishing.
Drink water with lemon or apple cider 30 minutes before meals.
Drink chamomile or spearmint tea after eating. Spearmint tea is my favorite.
Leave at least 12 hours between dinner and breakfast.

A word of caution: this is not medical advice, just what worked for me.

Friday Links: Big change, fake 7zip, and mourning our craft

2026-02-20T00:00:00+00:00

Hey there.

Here are 4 links worth sharing this week:

#1. Something big is already happening. AI may not be disrupting markets, like most CEOs claim. But it’s definitely changing job descriptions. Saving is one step to prepare.

#2. Someday we will tell our grandkids that dad once wrote code by hand. We’re the last in a generation of coders. Now is the time to mourn our craft (4min).

#3. A fake 7-Zip download turned PCs into zombie machines (10min). It all started with the wrong url. We’re still the weakest link.

#4. Postman from beloved API client to an “everything” app (5min). It’s become “a completely feature-creeped product.”

And in case you missed it, I’ve been writing on my blog about my social media free week (1min). Here are my day 1 (2min) and day 2 (1min) updates. In the meantime, I’ve picked two books and worked on another book project. (This won’t be about coding. More updates soon!)

Until next Friday. Keep coding smartly

Cesar

Day Four Without Social Media: Real Connection

2026-02-19T00:00:00+00:00

On my fourth day without social media, I noticed how email has reshaped my morning.

I know I should protect my sacred hours by staying away from distractions first thing in the morning. Anyways…

Checking my email for health insurance paperwork changed my mood. And soon I was thinking about my book pages stats and sales. They’re not a feed, but as addictive as social media. I lost track of time checking stats.

Avoiding feeds was easier when I closed my laptop and went to a cafe to chat with my family. It wasn’t just coffee. And by choosing a local cafe, we supported our community over major chains.

We embraced social media’s promise of connecting us via the internet. But we’ve forgotten to truly connect in real life.

TIL: How to Remove a File From a Git Commit

2026-02-18T00:00:00+00:00

I’ve hired AI as my code reviewer.

When I write code, AI reviews it. For that, I feed Copilot with a diff to review. But I always have to Google how to diff two branches.

To avoid Googling it every time, here it is:

$ git diff development..mybranch > diff

Today, by accident, I committed the actual diff. So I had to remove it from a commit. I wasn’t sure if I needed a git rebase or something else. I had to Google it.

Again, to avoid Googling it every time, [Source]

$ git reset --soft HEAD~1  # Undo the last commit, keeping the changes
$ # Do your thing
$ git commit -c ORIG_HEAD  # Commit, using the last message

Et voilà!

Day Two Without Social Media (And Two Lessons On Financial Freedom)

2026-02-17T00:00:00+00:00

Dear diary:

Today was my second day without social media. I’m starting to notice the changes. I took notes as the day went by and tracked my feelings.

I started reading another chapter of Financial Freedom by Grant Sabatier. Main lessons?

#1. Financial freedom is about time. Having more time for you. Using time to make your money work earlier and for longer.

#2. Money is infinite. We can’t make more time, but we can always make more money.

After my reading time, I joined a meeting with my contracting client.

I was so tempted to check my email or fire up LinkedIn. That’s usually what I do during long, unproductive meetings. That’s how my meeting time looked. For this one, my only contribution was, “Yes, that’s correct!”

Instead of scrolling, I took a receipt and doodled circles. I drew a big circle in the middle, then smaller ones, then smaller ones…until the page was full. That’s a drawing exercise I found the other day.

Big observation: When I feel like procrastinating, I used to scroll. Now I count to three, finish a tiny task, and sustain for five minutes.

Day One Without Social Media: What I Learned

2026-02-16T00:00:00+00:00

Yesterday I began an week-long experiment: no social media, no feeds. I’m writing this at the end of the first day of the experiment.

Here’s what I noticed after one day without social media:

#1. Start with an intention. Usually before working, I check my email and log into Medium and other accounts to reply to comments. Today I didn’t need a website blocker since I started with an intention: no social media.

#2. Read more. I filled the slot before working with a book. I picked Financial Freedom by Grant Sabatier. Then after lunch, instead of scrolling, I kept reading another book. Yes, I read more than one book at once—One strategy to read more books.

#3. Time for side projects. With the extra time, I worked on my February book project. The first draft is ready. And after a day’s break, I’m now editing it.

#4. An alarm as reminder. The other day, I found out about the 3-alarm method. I’m using it to remind me of a “Do Nothing” time to embrace boredom.

I'm Taking a Week Off Social Media And Feeds

2026-02-15T00:00:00+00:00

A post on social media convinced me to quit it for a week. Ironic, right?

The other day, a LinkedIn connection shared that “we don’t owe the Internet consistency.” It was an invitation to disappear from social media without apologizing.

That’s what I’m doing this week.

To cut phone time and embrace boredom, I’m quitting feeds for a week. That’s Medium, LinkedIn, dev.to, YouTube…

Quitting feeds frees up between 45-60 minutes each day. Yes, that’s how long I scroll down feeds on average, even when using social media consciously. Every time I open a social media app, I remind myself: “creators don’t consume.” A reminder to spend time making, not scrolling.

Even though I’m disappearing, I’ve scheduled posts so my system runs without me.

I’m planning to use that extra time to read books and finish my February book experiment. I will share the results soon.

Make Something You Like—At Least One Person Will Like It

2026-02-14T00:00:00+00:00

At times, writing (or creating anything) can feel pointless.

We don’t see results or traction. That’s when we should think we’re writing for our past selves, documenting our journey, or creating a time capsule.

But these days, my scrolling led me to How to Make a Living as an Artist. A street artist wrote it for other artists. But the next line captures the essence of writing or any other creative pursuit:

If you make something that you like, at least one person will like it — you. If you make something you think other people will like, you run the risk of no one liking it at all. That would be sad.

Write what you’d read. Code the app you’d use. Paint what you’d hang in your living room. At least one person will like it. That’s enough.

Friday Links: 1-pizza teams, being useful, and losing mastery

2026-02-13T00:00:00+00:00

Hey there.

Here are 4 links I thought were worth sharing this week:

#1. When coding was the bottleneck, we used 2-pizza teams. Now, with AI writing decent code, we have to rethink team organization. AI is turning teams into 1-pizza teams (7min) while creating new roles.

#2. Most of us coders are problem solvers at heart. The worst part is that makes us addicted to being useful (6min).

#3. We are at a turning point of our career as coders (5min). Software’s first “season” is over. But the next one will be “more interesting, more economically valuable, and more mentally stimulating than we can imagine right now.”

#4. Anthropic found that over-relying on AI leads to a “statistically significant decrease in mastery.” A truth everybody already knows (2min).

And in case you missed it, I wrote on my blog about the stats that deflate the AI hype (2min) (more revealing that Anthropic’s study) and how I’m embracing boredom (3min) (My phone screen time was quite shocking).

Until next Friday. Keep coding smartly

Cesar

Build Real Coding Skills—Then Use AI (In That Order)

2026-02-12T00:00:00+00:00

In the days of StackOverflow, we had to verify answers. Now, too often, we accept AI’s output without question.

Catching AI red-handed

Today, in another adventure with AI, I asked Copilot to turn a couple of SQL table definitions into mapping classes for Entity Framework Core. It was the classical 1-to-many relationship.

The problem came when I asked it to generate an API endpoint to store a parent record with a bunch of child records. Something like: create a parent record, then read a table to create its children.

Its first solution was to persist the parent record. Then inside a loop, persist every child record. The classical N+1 problem. Well, the inverse one. Arrggg!

When I prompted it to change it, saying there was no need for the loop, it replied with a “Yes, you can simplify it that way.” Caught you Copilot!

Why coding skills still matter

The N+1 problem was something I could find on the spot.

Now imagine how many AI answers we blindly accept without question. When coding, documenting, researching, testing…

Coding skills still matter. Without them, we wouldn’t even notice the problem.

Blindly trusting AI is what makes us say AI kills CS degrees, what makes us dangerously lazy.

Reviewing the code AI spits out puts in the top 50% of coders. The other 50% don’t always review. You need your coding muscles for that.

AI is like a semi-autonomous car. It always needs hands on the wheel. Build skills. Then leverage AI.

To help you build hype-proof skills, I wrote Street-Smart Coding. Because syntax alone won’t make you stand out.

7 Interesting (But Random) Ideas I Stumbled Upon Recently

2026-02-11T00:00:00+00:00

Even on a phone reduction diet, and even using social media consciously, I found myself wondering what to write next. I had too much on my mind.

To offload my mind, here’s a single-take brain dump of random ideas I’ve found recently:

#1. Nothing can’t be done by thinking alone. That’s a line I found in Secrets to Thrive in Life, a book my mom annotated and left behind.

#2. Don’t network. Write instead. Your words have wider reach than a networking activity or event. Someone shared in Medium.

#3. A fit, shredded body is a status symbol. A fancy house, car, and watch can be financed, but not a healthy body. Allegedly Arnold Schwarzenegger.

#4. The bigger the project, the strongest the Resistance. Resistance being the personification of doubt, procrastination, and self-sabotage. From the one and only, Steven Pressfield.

#5. When stressed/anxious/overwhelm, create. Someone else in Medium.

#6. You don’t owe the Internet consistency. It’s OK to disappear from social media. A creator I follow in LinkedIn.

#7. Journaling can be as simple as writing one line a day. Ryan Holiday from his YouTube channel.

Unpopular Opinions on AI-assisted Coding That May Annoy You

2026-02-10T00:00:00+00:00

Vibecoding was bad. But now, AI-assisted coding seems fine.

Nothing sparks more heated discussions than asking coders about best practices. Today, someone I follow on LinkedIn shared his weekend AI experiment to build an app. As usual, “passionate” coders threw virtual stones.

To turn the conversation around, he asked for our unpopular opinions about AI-assisted coding. To avoid burying mine in a comment, here they are:

#1. Use AI as a calculator. Only useful if you know what you’re doing.

#2. Don’t let AI touch code directly. That’s my go-to rule for coding with AI. Unproductive? Maybe. But it forces me to decompose problems and validates AI-generated code.

#3. Use AI for opposite tasks. This is my most recent rule:

If I write code, AI reviews it. If AI generates it, I review it.

According to a recent Sonar survey, only 48% of respondents always check AI-assisted code before committing. #yolo By reviewing, I’m already in the top 50%.

#4. AI is like a semi-autonomous car. You trust it to steer, but you never take your hand off the wheel. Otherwise, AI could be a sloppy coder with bad memory.

AI alone won’t make you a great coder. It only amplifies the skills you already have. That’s why I wrote Street-Smart Coding—because you need more than syntax to stand out.

What to Do After Finishing Your First Draft: An Update on My Book Experiment

2026-02-09T00:00:00+00:00

After a week of typing, my next book’s first draft is done.

This month, I’m running a book experiment: I’m turning a hit post into a short guide, but backwards.

Today I transcribed the last chapters. Yes, I handwrote some of the chapters. The draft is 7,084 words across 24 pages in Google Docs. That’s the minimum page count for an Amazon KDP paperback. Formatting and front/back matter will add more pages.

Even when hitting a small victory, like finishing the first draft, my inner voice speaks louder. “Do I have something good?” “Are people going to like it?” I have to trust the process and focus on the next task.

Now that the first draft is done, here’s what I’m doing:

Take distance. I’m letting the draft sit for a few days to read it with fresh eyes.
Replace placeholders. To finish my first draft in a single pass, I used “XXX” for places where I needed to fill in details later.
Find typos. I use a prompt to proofread my writing.
Reduce duplication. If I repeat anecdotes or stories, I’ll vary them or reference earlier mentions.
Revisit the opening and closing paragraphs of every chapter.
Revisit the first and last chapters. They leave the first and last impression.
Print it and read it with pen in hand.
Ask someone else to read it.
Give it another break before revisiting.

Update (Mar 2026): This experiment was a success.

What I'm Working On–February 2026

2026-02-08T00:00:00+00:00

Inspired by a Hacker News thread, here’s what I’m working on:

#1. My health: After falling ill in 2023-2024, I began caring daily for my body, mind, and spirit daily, and more recently, for my eating habits.

#2. Less phone time: With about 2 hours of average screen time per day, I’m working to reduce my phone time and embrace boredom.

#3. A book trilogy: Before retiring from coding, I’m leaving all my lessons in books. My plan is to write a trilogy. I already wrote Street-Smart Coding. That’s a roadmap of coding skills. The first I wrote, but the second in the trilogy.

#4. A book experiment: This month, I’m running a book experiment.

I’m turning my most popular post about personal development into a short, actionable guide. My goal is to finish it in one month. I’ve made good progress on the first draft, even handwriting some chapters.

#5. Daily writing: Last year, I hit the 400th daily post.

I began on November 1, 2024, during a forced sabbatical after a layoff.

I’ve considered abandoning daily writing or limiting it to workdays. But after a ban from a social blog, I’m doubling down on my blog and email list.

Why I'm Writing Some of My Posts By Hand (Plus An Update On My Book Experiment)

2026-02-07T00:00:00+00:00

I’ve started writing some of my posts by hand.

Last month, I started reducing my phone time. To embrace boredom, I schedule a “Nothing” slot away from tech.

The other day, it was “Nothing” time and I hadn’t written my daily post. So I decided to grab pen and paper to write it. Yes, I had to “work” twice: write and then type. But somehow it felt different.

I’m not alone in handwriting

This experiment made me think of Roberto Gomez Bolaños, aka Chespirito, who also relied on pen and paper to write scripts for his TV shows and sketches.

When he started his writing career, he didn’t know how to use a typewriter. And later when he injured one of his hands, he kept the habit. At least, that’s what his biopic shows.

It’s extra work, but here’s what I’m doing less

For my February book experiment, I wrote the last two chapters by hand.

Like Chespirito, I wrote by hand, but only a few chapters. I planned 13 chapters. I wrote the first draft of 12. 2 of them need transcribing. Chespirito probably had an assistant for transcriptions. I don’t.

It might seem like extra work.

But pen and paper force me to think hard before putting the pen down. I don’t have a backspace key. Well, I can cross out lines and scratch. But I don’t find myself going back to edit while I’m writing by hand.

When I’m transcribing (like now. I handwrote this post first), I edit less. Handwriting and transcribing force me to switch tasks and detach from the original text—and of course, slow down from the rush of digital writing. That’s a point for pen and paper.

The backspace key is a blessing, but sometimes a curse. And slowing down can be its own blessing.

Friday Links: Moltbook, Notepad++ compromised, and code sculptors

2026-02-06T00:00:00+00:00

Hey there. It’s been a wild week in tech.

Here’s what stood up:

#1. This is crazy. The Notepad++ update server was compromised (7min) by Chinese state hackers for part of 2025. Patch yours right away!

#2. Now there’s a Reddit for AI: Moltbook…or whatever the latest name is. Here’s a breakdown of why it’s the most interesting place on the internet (7min). Imagine AIs ranting about their tasks. It seems they aren’t conspiring against us yet.

#3. AI isn’t replacing us, just changing our job description. Maybe we won’t be coders anymore. We will be code sculptors (2min). Imagine job descriptions: “Looking for a 10x Michelangelo to join our amazing family.”

#4. The only social media I use is LinkedIn. You probably found me there first. I avoid the feed though. If you want to jump in, here’s a guide on how to use social media mindfully (3min).

Thanks to the magic of the internet, a post from December got some traction last week. In case you missed it, here it is: what we could offer if AI finally takes over (2min).

Until next Friday. Keep coding smartly

Cesar

The Numbers That Deflate the AI Hype About Replacing Coders—and Ease FOMO

2026-02-06T00:00:00+00:00

Only 25% of developers regularly use AI agents, according to Sonar’s survey.

After surveying more than 1,100 developers across the globe, they found:

90% of respondents use AI for assisting development. But only 55% of them rate AI as “extremely or very effective.”
96% don’t fully trust that AI-generated code is functionally correct.
48% always check their AI-assisted code before committing.

Why this matters: We’re flooded with headlines predicting the end of coders.

AI generating more than X% of code at a FAANG. One CEO suggesting nobody else should learn to code. To then retract himself saying that replacing senior coders with AI is crazy. And companies using AI innovation as an excuse for more layoffs.

Those numbers show CEOs spread panic to bump stock prices and fuel the euphoria. The real motivator isn’t productivity, but financial interest.

What to do: If you think you’re missing the whole AI movement, let the dust settle down. Double down on the fundamentals, not shiny objects. Maybe it’s time to pick Structure and Interpretation of Computer Programs or any classical textbook.

With 96% not trusting AI, code reviewing, clean code, and security remain essential. Don’t throw away your copy of Clean Code. And even if AI takes over, there’s work for human coders to do.

It’s easy to fall into the AI hype. AI wins on speed. But humans win on communication, collaboration, and problem-solving skills.

Street-Smart Coding covers some of those skills. Follow this roadmap to build hype-proof skills and become the kind of coder AI can’t replace.

TIL: Blazor Breaks When Others Touch the DOM

2026-02-04T00:00:00+00:00

In another episode of Adventures with Blazor…

Once more, I ran into the mysterious “TypeError: Cannot read properties of null (reading ‘removeChild’)”. But unlike the last time, it wasn’t a problem in a third-party component that we had to replace. It was my fault.

Wouldn’t it be great if the error message mentioned which property was null: an id, xpath, or CSS class?

This time, a modal created a record and showed a success alert. But after dismissing it and closing the modal, the page broke with the same error.

Here’s a Blazor page that recreates the scenario. A simple modal with a form that shows an alert bound to a _directorSavedSuccessfully. Notice the <div> wrapped around the @if inside the <BodyContent>.

@page "/directors"

<button class="btn btn-primary" @onclick="AddDirectorClicked">Add Director</button>

<ModalDialog Title="Add Director" @ref="_editDialog">
    <BodyContent>
        @if (_directorSavedSuccessfully)
        {
            <div class="alert alert-success alert-dismissible fade show" role="alert">
                Director saved successfully.
                <button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
                @*                                      ^^^^^ *@
            </div>
        }

        <EditForm Model="_editDirector" OnValidSubmit="SaveDirectorClicked" id="directorForm">
            <InputText @bind-Value="_editDirector.Name" class="form-control" />
        </EditForm>
    </BodyContent>
    <FooterContent>
        <button type="button" class="btn btn-secondary" @onclick="CloseClicked">Close</button>
        <button type="submit" form="directorForm" class="btn btn-primary">Save</button>
    </FooterContent>
</ModalDialog>

@code {
    private ModalDialog? _editDialog;
    private bool _directorSavedSuccessfully;
    private Director _director;

    private void AddDirectorClicked()
    {
        _directorSavedSuccessfully = false;
        _editDialog?.Open();
    }

    private Task SaveDirectorClicked()
    {
        // Imagine we're calling an API here to save...
        _directorSavedSuccessfully = true;

        return Task.CompletedTask;
    }

    private void CloseClicked()
    {
        _directorSavedSuccessfully = false;
        _editDialog?.Close();
    }
}

Bootstrap removed the alert node directly, via the data-bs-dismiss="alert". But Blazor was still “tracking” it. So when the modal was closed, Blazor didn’t find the alert. Somebody else ate its cheese. And boom!

The solution? Don’t let anything else touch the DOM, but Blazor. Wire that alert to a variable controlled by Blazor.

-<button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
+<button type="button" class="btn-close" @onclick="_ => _directorSavedSuccessfully = false" aria-label="Close"></button>

Et voilà! Let Blazor own the DOM.

For debugging and problem-solving tips, read Street-Smart Coding. And it’s even more relevant now in the era of AI-assisted coding.

My Phone Showed Me I was the Enemy of Boredom (4 Ways to Embrace It)

2026-02-03T00:00:00+00:00

I can’t remember the last time I stared at the ceiling, wondering “what should I do now?”

Growing up without smartphones or tablets made me a friend of boredom. I lived on a main street of a small city. When bored, I counted passing cars in my front yard. Sometimes, I competed with my uncle and sister. The one who counted more cars of a certain color won. Yellow taxis weren’t allowed.

Years later, with an iPhone, work, and side projects, boredom turned into an enemy. I’ve had to work to bring it back.

What I’m doing to be bored again

The other day, I had so much on my mind that I had to sit and do nothing. That was my wake-up call.

To welcome boredom again:

#1. Less phone time. I’m reducing my phone time. Now my phone is in another room. There are books where I used to put it. And I’m writing this with pen and paper first.

#2. A “do nothing” slot. Apologies for the irony, but I’ve set an alarm in my phone labeled, “Mandalas afternoon.” I used to color mandalas during my lowest emotional season. I need to change that label. It should be “do nothing afternoon” and honor it. Not that coloring mandalas is a bad idea.

#3. Walking outdoors. For my physical and mental health, I go running next to the ocean. I’m planning to buy an analog watch (a classical Casio. Anyone else?) and leave my phone at home or put it inside my bag in silent mode.

#4. An Amish hour. I’ve moved my book reading time to one or two hours before bed, away from screens. One evening, after a coffee with a friend, too much caffeine and late-night writing kept me awake for hours. So no more screens before bed. The next challenge: an Amish afternoon. Or even an Amish day. Why not?! I’ll just need to write my daily post in advance.

Forget the Hit Book. Write a Series

2026-02-02T00:00:00+00:00

“Is there a next part? Are you covering the next stage after being a good coder?” a friend texted me.

He finished Street-Smart Coding, my first book, and was eager for more. A reminder of a marketing lesson I had forgotten.

The best way to promote your book is by writing another one.

I first heard this surprising strategy on James Altucher’s podcast.

Nicolas Cole, author of The Art and Business of Online Writing, teaches the same strategy.

On his YouTube channel, he advises building a portfolio of books instead of chasing one big launch. When readers finish and enjoy your book, they want more. One single title after a big launch doesn’t meet that need.

That’s what happened to my friend after reading my book. And that’s more encouragement to work on the next one.

I'm Running a Book Experiment This February

2026-02-01T00:00:00+00:00

I’m writing a book backwards.

Technically, it’s a mini-book. I’m turning a hit post into a book.

In the spirit of doing 10,000 experiments and to keep running content experiments, here’s what I’m doing this month:

#1. Repurpose a hit post. I’m turning one of my most read and liked posts into a short book. Over 100 people liked that post. Proof that the idea works. I’m even naming the book after the post.

That’s what the authors of The Subtle Art of Not Giving a Fuck and The Psychology of Money did.

#2. Find inspiration from comments. My hit post got a decent amount of discussion. I’m using those comments to find keywords, taglines, and objections.

#3. Expand it. The source post is a 7-point listicle. I’m turning it into a 10-chapter concise book, like Steal Like an Artist. Each point expands into one or two pages with stories and past posts.

#4. Write it backwards. Instead of jumping to the introduction, I’m:

Choosing a title
Writing a one-line summary
Outlining the content
Finding Amazon keywords and categories
Sketching a sales page

I’m even stealing cover ideas before writing a word.

#5. Make it short. The other day, I found a one-page book, so why not write 10 or 15 pages and call it a book? One or two pages per point plus the front and back matter.

#6. Price it incrementally. I’m following the “$0.99 is the new free” idea. If it gains traction, I’ll raise the price by $1 every other month until it hits $5.

#7. Hit one reader milestone. Just like I set it for Street-Smart Coding, if even one reader beyond my circle buys it, the experiment is a success.

Update (Mar 2026): This experiment was a success.

Better A Small Rep Than A Broken Habit

2026-01-31T00:00:00+00:00

Yesterday I found a LinkedIn post asking if a crap post was better than no post at all. I didn’t want to bury my answer on the comments section. So I’m expanding it a bit here.

A crap post is better than silence.

Well, 90% of everything is crap. Most of what we create won’t be great. And that’s ok.

But writing, coding, or any creative pursuit is like exercising. Skip the gym once, nothing happens. Skip twice, and suddenly you’re on the couch, binge-watching Netflix, wondering where the extra weight came from.

Whether it’s a post slightly longer than a Tweet, some random thoughts, a few lines of code, or quick sketches, a small, imperfect repetition is better than breaking a habit.

Your small reps won’t make you lose credibility. They prove that when life throws curveballs, your habit stays intact.

Friday Links: Future of coding, target bets, and SaaS

2026-01-30T00:00:00+00:00

Hey there.

This week marks three months since I launched Street-Smart Coding. It started in a notebook with a 10-idea list. Now it’s a book. Getting the first paperback copies made me feel like a New York Times bestselling author. Pinch me, please.

After that quick update, here are 4 links I thought were worth sharing this week:

#1. For months, we’ve been hearing that AI will replace coders. But a more realistic prediction is to say that we won’t be writing code by hand in 5 years (10min). Truth is, coding was never the hard part.

#2. If you’re looking for a tech job in 2026, instead of applying and sending out CVs everywhere, make a target bet (4min). Without knowing it, that’s the strategy I followed to land my last contracting gig.

#3. With LLMs and agents, building in-house replacements for paid tools sounds tempting as a way to save some money). But writing code is just the tip of the iceberg (5min).

#4. These days, American coworkers complain about the weather, and I keep converting between Fahrenheit and Celsius. Here’s a quick mental heuristic to do it (1min).

And in case you missed it, I wrote on my blog about a new rule for using AI without losing my skills (2min) and how to be an expert at failing (and survive to tell the story) (5min).

Until next Friday, keep coding smart

Cesar

5 Quick Thoughts on Creativity and Growth to End the Week

2026-01-29T00:00:00+00:00

#1. Always have something to write on. This week, I caught up with an ex-coworker. He shared a valuable story that deserved its own post. Thank goodness I grabbed a napkin from the cafe where we met. That’s where I outlined the post.

#2. The notebook cult. Finding out about zines to reduce my phone time took me to a YouTube rabbit hole. Turns out there’s a whole cult. People with notebooks for everything. Notebooks for quotes, journaling, habit trackers, commonplace notebooks, pocket notebooks. I’m not joining the cult, I’m fine with my idea pad.

#3. Start your next creative project backwards. Before starting, imagine it’s finished, then write the sales page and announcements. That forces you to clarify your goal and message. That’s what I’m doing for my next book.

#4. A simple method to overcome burnout. A pen pal shared his burnout was appearing again. When he asked how I avoid burnout, I shared my mantra: care for your body, mind, and spirit daily. That’s one of the ideas that has changed my life.

#5. 1, 2, 3, and get up. I can’t remember what podcast I learned this from. As soon as you wake up, count up to 3 and get up. Those moments after waking up are when you become a time traveler, reliving the past and sketching possible futures.

An Update After Three Months of Launching Street-Smart Coding

2026-01-28T00:00:00+00:00

Three months ago, I launched my first book, Street-Smart Coding. A persistence test.

It wasn’t my first, but the first I was confident enough to call a book. It challenged my persistence. I even wrote chapters in a hospital while supporting a loved one. Chapter 17 is one of those. Sometimes I avoid rereading those chapters.

Some lessons, realizations, and hard-truths

Writing a book taught me many lessons:

#1. Interior design is not that hard. Reedsy does the heavy lifting. Or you can find your way with Word and a lot of Googling.

#2. Instead of a massive launch, think of a series. That’s the best promotion strategy for your first book.

#3. Set a deadline. A task can take as much time as we give it. Writing a book isn’t the exception. It took me about 4 months to finish the first draft. Here are more lessons nobody told me about writing a book.

#4. Once your book is out, the game starts in your head. That’s the fear of finding typos or getting bad reviews. That’s refreshing your sales dashboard and comparing your book to others. Here are more realizations. Just focus on what you can control: work on the next one.

#5. There’s always something you could have done better. Once it’s out, it’s out. Your job was to write it, your audience’s job is to read it. Again, work on the next one.

I’m doing this differently

By no means, I’m an expert book writer. I only have two under my belt. But here’s what I’d do differently.

#1. Start backwards. Start with a promise, cover, sales page, and outline. That forces you to clarify your book promise and message.

#2. Come up with a one-liner. That’s to summarize the core ideas and to make promotion easier.

#3. Pre-sell it earlier. “Do good work and people will come” is a lie.

I once read an ebook called, Start Marketing the Day You Start Coding by Rob Walling. It was about building SaaS startups, but the idea works for books too.

With a clear promise, cover, and sales page (following #1), start promoting from day one.

#4. And I’d order my author copies from Amazon earlier.

Some numbers

I offer Street-Smart Coding as an eBook via Gumroad, and in Kindle and paperback formats in Amazon.

Here’s a breakdown of copies sold:

eBook version: 51 sales. +2 in Spanish edition
Kindle version: 1 sale.
Paperback version: 1 sale.
“Door-to-door” sales: 8 copies. (7 Spanish, 1 English).

For me, even one sale beyond friends and acquaintances meant success. That’s enough motivation to keep writing.

How to Be an Expert at Failing (and Survive to Tell the Story)

2026-01-27T00:00:00+00:00

“I’m not an expert at anything. Only at failing.”

A friend and ex-coworker told me that when we caught up over coffee after many years. Well, I was giving him a paperback copy of my latest book. Shameless plug.

Our conversation immediately shifted after that line. I had to ask him why he said that.

You have to start from scratch

At college, everybody told him he had a talent for coding. But he was fired from his first job for his performance.

After losing his job, he broke his wedding engagement. He disappointed his parents. He thought he had nothing else to do. Failure wasn’t a stranger. It had become his shadow.

He started as a teacher. He thought he had found “his thing.” But he got fired from that too. Another disappointment.

Then, to try something new, he went back to college. He had to find something. He had to find his calling.

One day on campus, ready to quit, he sat at a table with his head in his hands. The pose of a disappointed, frustrated man.

That’s when he heard something unexpected.

“Which plant grows faster? A tomato plant or a mango tree?”

“A tomato plant,” other students who had joined the table said.

“Which plant gives fruit for longer?” the mysterious voice said. He kept his head down all that time.

“The mango tree,” the students said.

“Exactly! You have to be mango trees. The tomato plant dies after harvest. A mango tree gives mangoes for a lifetime.”

After many failures, that was his wake-up call. At first, he thought it was a wise student. But when my friend raised his head to find out where that voice came from, he found a teacher.

“It was God,” he told me.

That day, he decided to get up and work for himself. If his parents or family were disappointed because he didn’t meet their expectations, that was their problem. Not his.

Lesson 1: Live up to your own expectations.

Lesson 2: You have to start over and over. That’s a skill no class teaches you, only failure and life do.

Lesson 3: Be a mango tree.

That was a moment to start from scratch again, after failing at his first job, his first relationship, and first everything.

Be good at making an extra effort

Being fired from his first job was a sign he wasn’t as smart as he had thought.

Maybe it was impostor syndrome. Trust me, he’s smart.

But after months, he was interviewing at the same place where I was working.

“I know I’m not the smartest, but I’m going to be the most charismatic,” that’s what he thought before the first interview.

That strategy worked. He got the job. But failing at so many things, he was ready to get fired after the first month.

Later, at my workplace, he carried a notebook and wrote down everything. When I asked him about it, he told me, “I had to take away something, at least some notes.”

“After many failures, I learned to read who was really someone who knew and who was just a charlatan. I learned from everyone and I wrote it down.”

He was at the office before clock-in and still there after clock-out. “I had to make an extra effort. It took me 5 hours to finish what others did in 1.” Effort was his secret weapon.

Lesson 4: Take a notebook with you everywhere. (Thank goodness I had a napkin to write down the lessons my friend taught me as soon as our conversation was over.)

Lesson 5: Persistence beats intelligence. If you aren’t the smartest, you have to be the one who puts the most effort.

“A coding problem? Nah! That’s not a problem. I’m used to failure.” Sure, a compilation error was nothing after many disappointments and setbacks.

“That’s why I say I’m an expert at failing.” Wow! We shook hands and went our separate ways. That day, I met a true expert and a wise man—and realized failing isn’t the end.

Another Rule for Using AI Without Losing My Skills

2026-01-26T00:00:00+00:00

When code breaks, you can’t simply say, “AI did that.”

You’re responsible for the code you ship. That’s been true from the days of copy-pasting from forums, blog posts, StackOverflow, and now from AI.

AI is fast, but over-reliance makes you lose your mental models and context—just one problem with AI.

The new rule

To protect my skills, I’ve set one rule: Don’t let AI touch your code directly. It might feel unproductive. But it keeps my hands on the wheel.

To test this rule, I recently tried finishing a task using as much AI as possible. While going through the AI-generated code, I came up with another rule:

If I write the code, AI reviews it. And if AI generates the code, I review it.

That way, I use AI while keeping my code writing and reading sharp. Either way, AI is just like a copilot in the cockpit, an extra layer of safety and productivity.

AI is changing the act of coding. Some brag about coding without typing a single line of code, thanks to Claude Code. Whether what AI generates is clean code or garbage, its CEOs aren’t accountable for it. We are.

If you want to sharpen the skills AI can’t replace, check out Street-Smart Coding. It’s the guide I wish I’d had on my journey to becoming a senior coder.

A 7-Word Trick for Better Book Notes

2026-01-25T00:00:00+00:00

Books only matter if you act on them.

The first step is to highlight, underline, or write in margins.

The next step is to take notes. The problem is copying passages without processing them (or letting AI do it). The Zettelkasten method (and my tweaked version) solves that by finding connections between notes.

But today I found another note-taking idea: The 7-word summary.

After a chapter or section, or a whole book, write a 7-word summary. That forces you to condense big ideas into your words.

Tip: For better organization, keep your 7-word summaries in a single place.

That’s a perfect partner to a 10-idea list.

Progress Report: Breaking My Phone Habit

2026-01-24T00:00:00+00:00

Two days ago, I decided it was time to reduce my phone use.

I left books where I used to put my phone: desk, couch, and table. Instead of reaching for my phone, now I find myself opening The Power of Now by Eckhart Tolle or Jesus’ Son by Dennis Johnson.

Yesterday, I paused on my way to my desk to grab my phone. Midway, I realized my phone wasn’t there anymore. That’s a habit being replaced.

Today, I thought carefully about when I needed my phone. And it was easier to read with books nearby. I even left it behind for a quick errand.

Big changes start with small actions. Mine began with swapping screens for pages.

Friday Links: Old laptops, meetings, and the vibe coding paradox

2026-01-23T00:00:00+00:00

Hey there!

This week I’m relaunching my C# unit testing intro book.

During the holidays, I revamped Unit Testing 101 with clearer chapters, tighter explanations, and a fresh design.

If you already bought it, you should have received the new version. Otherwise, grab it here.

Now, this week’s 4 interesting links:

#1. StackOverflow feels dead. Maybe a victim of its own success. And we were never good programmers (5min).

#2. AI is turning software (and coding) into fast fashion (6min). “Software is no longer seen as an asset… It’s a throw-away product. Like a napkin.”

#3. New to a codebase? Push the smallest possible change to production (3min), even a README tweak.

#4. Cool tool of the week: maptoposter. Turn your favorite city map into a beautiful poster.

Beyond coding, I wrote on my blog about how I use LinkedIn mindfully (3min) and why you’re still hungry after eating and how to fix it (3min).

(Bzzz…Radio voice) This email was brought to you by… the new version of Unit Testing 101. OK, I already told you about that. Check Street-Smart Coding: 30 lessons to help you code like a pro. From Googling to clear communication, it covers the lessons you don’t learn in tutorials. It’s now out on Kindle and paperback on Amazon.

See you next time,

Cesar

A Simple Idea to Reduce My Phone Time

2026-01-22T00:00:00+00:00

I tell myself I’m not addicted to my phone. That’s exactly what addicts say.

This week, I averaged 2h39min on my phone. Today, it was 1h55min. I just checked it. That’s enough to produce some creative work.

In my defense, I only listened to podcasts while doing the dishes. But most of that time was scrolling to find what to listen to.

This year, my intention is simplicity: ditching my distraction machine to live lighter.

Replacing a bad habit with a good one

For that, I’m putting my phone out of sight, in a new place.

And in every place where I used to put my phone, I’m leaving a book and a zine instead.

This week, a rabbit hole took me to Austen Kleon’s rules of reading. He made a zine, a tiny magazine with eight pages created from a single sheet of paper.

And when you want to buy a red car, you see red cars everywhere. Today I discovered zines for free-form journaling and single-purpose notebooks. Credit goes to Cal Newport’s podcast for the notebook idea. Yes, I was doing the dishes.

What if I combine the two ideas? Maybe one zine per day for quotes and lessons. And another per project for ideas and questions.

That’s how I’m replacing scrolling with reading and even making my own zines.

If you want to follow along, here are the books I read last year. Perfect replacements for where your phone used to sit.

Why You're Still Hungry After Eating—And How to Fix It

2026-01-21T00:00:00+00:00

Right after lunch today, I was already craving a snack.

I usually don’t eat between meals. But today, I had to eat a cup of kefir with sunflower seeds. Minutes later, I had a slice of cheese. And I was still hungry.

But that started a few hours earlier at lunch. I ate too many carbs. Rice was the culprit. I couldn’t resist. Where I live, eating rice is almost a national sport.

The reason behind that is glucose spikes.

Glucose Revolution

After eating carbs or sugar, our glucose levels rise. Our body produces insulin to lower them. Then the crash comes. We feel tired, irritated, and hungrier.

And when we feel hungry, we grab unhealthy snacks, causing more spikes. And the cycle continues. That’s why I was hungry earlier today. Chances are, you’ve felt the same..

I’m not new to glucose spikes. Learning to control them has been my best productivity hack.

My sister read Glucose Revolution by Jessie Inchauspé first and shared tips I started applying.

Finally, I picked up the book too. I started reading it last year.

Easy hacks to reduce glucose spikes (starting with the easiest ones)

Here are some of the hacks I’m following to keep glucose spikes under control:

Eat a salad (or some greens) with every meal.
Eat salad first, then proteins, then carbs. In that order.
Move your body after eating. Take a walk or do some squats. But move!
Say good-bye to sugar. If ego is your enemy, sugar is your arch-enemy. It’s the devil.
Eat as many greens as carbs. A hamburger has the right ingredients, but in the wrong amounts.
Drink water with apple cider vinegar 30 minutes before lunch.
Prefer salty snacks over candy or sweets.

The book explains each hack with research. I won’t pretend I remember all the details. Greens first makes your body absorb fiber first, slowing down carbs absorption.

If you’re looking for a 20/80 rule, follow #1 and #2. That’s how I dropped from ~80KG to ~74KG in a couple of months and now I don’t drag my feet to get over my afternoons.

Why You Should Write and Underline in Books

2026-01-20T00:00:00+00:00

Recently, I found a book my mom left behind. It felt like opening a time capsule.

It’s Secrets to Thrive in Life (or Secretos para triunfar en la vida in Spanish). She always mentioned that book.

It’s a collection of maxims, proverbs, and passages from other personal development books. On the first page, my mom wrote her name and a date. She was likely in her 20s.

She underlined sentences and starred titles. With a blue pen and ruler, she drew perfect lines. I picture her lying on her bed, reading with an orange translucent ruler.

Opening the book felt like uncovering her thoughts and circumstances. She underlined a passage about dealing with people and dating. She must have been going out with my dad.

I was reluctant to write in books. That felt like a capital sin. Then I opened her book and felt she was sharing success clues.

I want to do the same for my future kids and grandkids. I’m not afraid of writing in books anymore. Writing in margins, starring titles, and underlining passages turn books into time capsules of our thoughts. A legacy for future generations.

How I Use LinkedIn Mindfully (In 5 Simple Steps)

2026-01-19T00:00:00+00:00

One day at the office, I created my LinkedIn account to escape that job.

That was five or six years ago. That afternoon, my coworkers and I made it a group activity. We endorsed each other’s skills and exchanged recommendations. We were planning our escape route because things were getting tough.

I didn’t find my next job on LinkedIn. But I made my first internet money there. And that kept me going back.

In 2024, I revived my account after months of inactivity. After landing a new job, I stopped logging into LinkedIn.

Since then, I’ve written over 300 posts. I’ve preached the same overused cliches, stumbled upon weird situations, and learned that people don’t read, but skim online.

From job hunting to posting daily, to ignoring all gurus’ growth advice, I’ve learned meaningful use matters more than virality.

5 steps to use LinkedIn more consciously (ignoring growth hacks)

Here’s what I do to use LinkedIn more consciously:

#1. Use it with a timer. Like other platforms, it’s designed to trap you. One notification can spiral into hours of doomscrolling.

#2. Curate your feed. Your feed is a rabbit hole.

To curate it, follow:

People you know in real life
People you want to connect with
People sharing interesting ideas

Pro tip: Avoid scrolling down your feed by bookmarking profiles you want to interact with.

#3. Share interesting things. Nobody cares about another Udemy certificate. Use it to share your learning or resources you find useful. Finished an interesting book? Share what you learned with a photo of the cover. Working on a project? Share a lesson learned.

And please, please don’t try to sound corporate. If you’re typing “Dear LinkedIn network,” stop and start again.

#4. Keep in touch with your network. Send quick “Hello” to old connections: bosses, coworkers, recruiters… Don’t use AI. Keep it as human as possible. “What are you up to these days?” works perfectly fine.

#5. Use comments wisely. Most influencers preach about commenting more and more like the ultimate growth hack. That’s another rabbit hole.

Use comments to start genuine conversations instead. Reply to interesting comments and follow up with connection requests. “Hey, your comment about XYZ got my attention…“ Again, be human. That’s how I met a top cellist, an award-winning teacher, a speaking coach, and many more interesting people.

How to Handle Too Many Creative Ideas

2026-01-18T00:00:00+00:00

One problem is having no ideas. Another is having far too many.

With endless options, which project comes next?

That was one of the questions Austen Kleon, author of Steal Like an Artist, got in this interview. An audience member with “millions of ideas” and “29 books to write” asked how to find time for them.

Her struggle resonated with me. Because these days, I’m like her. I have too many books and projects to choose from.

But here’s what I’ve been trying when I feel overwhelmed by ideas:

#1. Write down every idea as it comes. A book title, a concept, or just a phrase. Don’t let them go away.

#2. Create distance from your ideas. Take some time to do something else. This space helps your brain to connect the dots.

#3. Choose wisely. Tackle the project you can finish the fastest or the one you’re most excited about.

Credits to my sister for helping me think this through.

Currently I’m at phase one: brainstorming with 10-idea lists. Meanwhile, I’m giving my brain space to make connections by doing nothing. I know there’s a book in there. I’m trusting the process.

Some Days You Just Have to Stop and Do Nothing

2026-01-17T00:00:00+00:00

Earlier today, I crossed the city for some blood tests. Regular checkups. Hot and sunny outside.

I don’t know if it was the heat, too much information, or just too much on my mind. (I even had to do a brain dump recently.) But I had to make lemon water, put on my headphones with ocean waves, and sit to do nothing else.

Maybe that’s what I needed to get over a creative block. Sometimes you need to do nothing. Not less. Nothing.

If you’re reading this, try it: put down your phone or your computer, and let yourself do nothing. It might clear your block too.

Friday Links: Old laptops, meetings, and the vibe coding paradox

2026-01-16T00:00:00+00:00

Hey there.

Here are 4 links I thought were worth sharing this week:

#1. Curious about laptops 30 years ago? Here’s the “I checked my notebook” commercial (1min). My laptop wouldn’t survive that.

#2. I’ve used StackOverflow (and still do), but never created an account or asked a question. Not a welcoming community. That’s why StackOverflow is dead (3min). ChatGPT doesn’t close your questions or downvote them.

#3. Meetings are the worst part of coding professionally. Especially those when the organizer is late, everybody waits…awkward silence…Here’s a quick hack to start meetings on time (2min).

#4. I keep seeing people online brag about coding without touching an editor or IDE. Now they “code” from their phones with Claude Code. Vibe coding was bad. But now coding outside an editor is good? That’s the vibe coding paradox (2min).

And in case you missed it, I wrote on my blog about the books I read and the ones I didn’t finish in 2025 (3min) and why we should forget about LOCs to stand out (3min).

(Bzzz…Radio voice) This email was brought to you by… my new book, Street-Smart Coding: 30 lessons to help you code like a pro. From Googling to clear communication, it covers the lessons you don’t learn in tutorials. It’s now out on Kindle and paperback on Amazon.

See you next time,

Cesar

10 Random Thoughts (on Focus, Creativity, and Coding) to Clear My Mind

2026-01-15T00:00:00+00:00

Following my own advice, I’m writing a 10-idea list to quiet the chatter in my head. Not that I had writer’s block, but a “too much noise in my head” block—If that’s even a thing.

#1. Use your blog as insurance. Blogs might feel dead. People consume content inside platforms, instead of Googling to land on personal blogs. But your blog is your insurance against dead platforms and suspensions. If you trigger a filter inside a platform, even if it’s a false positive, your account gets suspended, with almost no chance of getting it back.

#2. Your real asset is your email list. I’ve heard it plenty of times: “Build your list…,” “Count subscribers, not followers…“ But it wasn’t until my account on a social blog got suspended that I learned the lesson.

#3. Cut the news. Venezuela, Iran, Israel, United States…There’s always something going on somewhere. Unless you’re a diplomat, advisor, or spy, there’s almost nothing you can do. News only makes you anxious.

#4. “I want to build a product.” This is the second or third time I’ve heard a friend saying they want to build something beyond the 9-5. The problem? They recreate their day job after hours, when there’s less energy and willpower. A better alternative is to make experiments and create something in two hours. Or a portfolio of small bets.

#5. We live without being conscious of our bodies. I’m rereading The Power of Now by Eckhart Tolle. I wasn’t ready the first time I read it. One takeaway so far: We’re so in our heads we forget our bodies. Just stop to breathe.

#6. Coding is changing for good. I keep seeing people on the IndieWeb and LinkedIn brag about coding without touching an editor or IDE. Now they “code” from their phones with Claude Code. Maybe writing lines of code is becoming optional.

#7. Write books for AI to read. The other day, Kevin Kelly said he writes (or plans to write) his books for AI. What if we offer our books as chatbots? Instead of reading it, people talk with them. It’s another reminder that our job as writers is to adapt to how our readers consume content. Credits to Smart Brevity. That’s how we’re consuming content now.

#8. 12 apps in a year. The other day, I found an indie blogger running a challenge: building one small app per month. Such a great idea! Forget the next Uber, build tiny apps (or websites) that solve a simple problem and put a “Buy me a Coffee” link. Something like a “pill time calculator” or “time off finder.” Those are two small apps I’d use.

#9. Do something hard this year. This idea comes from Ryan Holiday. Marcus Aurelius, or another stoic, used to jump into a frozen lake at the start of every year. Prove yourself wrong and do something hard. Maybe that’s a side project, a book, or a jump into a frozen lake.

#10. You’re not too late. I just listened to an interview with Hassan Osman, a book writer, course creator, and podcaster. He admitted part of the success of his books and courses was starting around the lockdown in 2020. The best time was five years ago. The next best time to take action is now. Experiment, and double down.

I Thought I Had Seen Short Books—Until I Found This One

2026-01-14T00:00:00+00:00

For writers, the real challenge is to make readers finish books.

TikTok, Instagram, and endless feeds have turned us into skimmers. And as Smart Brevity says, our job as writers is to adapt to how readers consume content. Give them something fast.

Short non-fiction books, or mini books, are the answer for impatient readers.

A book doesn’t need 30,000 words. It could be a summary of 10 papers, a collection of personal stories, or your best posts—as long as it’s valuable even for one person, it’s worth publishing.

And to my surprise, after going down a rabbit hole, today I found a one-page book, This Book is One Page Long by Hassan Osman. Well, the book has 5 pages. I guess that’s the front matter, back matter, and one page of actual content.

If that doesn’t kill every excuse for writing a book, nothing will.

TIL: What Entity Framework Core Do With Nullable Foreign Keys

2026-01-13T00:00:00+00:00

In another episode of Adventures with Entity Framework…

I expected Include() to always translate to an INNER JOIN. But with nullable “joining” properties, EF Core uses a LEFT JOIN.

Here’s my replicated scenario with movies and directors.

#1. Let’s create a Movies and Directors table with no foreign keys between them.

USE Movies;
GO
CREATE TABLE Movies (
    Id INT PRIMARY KEY IDENTITY(1,1),
    Name NVARCHAR(100) NOT NULL
);
GO
CREATE TABLE Directors (
    Id INT PRIMARY KEY IDENTITY(1,1),
    Name NVARCHAR(100) NOT NULL,
    MovieId INT NULL, /* <- A nullable column here */
    /* And no constraint here. I'm a legacy app */
);
GO

#2. Let’s store (and retrieve) one movie and its director and an orphan director.

using Microsoft.EntityFrameworkCore;

namespace NullableForeignKeys;

public class Movie
{
    public int Id { get; set; }
    public string Name { get; set; }
    public List<Director> Directors { get; set; }
}

public class Director
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int? MovieId { get; set; }
    //     ^^^^
    // A nullable property here
    public Movie Movie { get; set; }
}

public class MovieContext : DbContext
{
    public MovieContext(DbContextOptions<MovieContext> options) : base(options)
    {
    }

    public DbSet<Movie> Movies { get; set; }
    public DbSet<Director> Directors { get; set; }
}

[TestClass]
public class MovieTests
{
    [TestMethod]
    public async Task NullableForeignKey()
    {
        const string connectionString = $"Server=(localdb)\\MSSQLLocalDB;Database=Movies;Trusted_Connection=True;";

        var options = new DbContextOptionsBuilder<MovieContext>()
            .UseSqlServer(connectionString)
            .Options;

        using (var context = new MovieContext(options))
        {
            // An orphan director
            context.Directors.Add(new Director
            {
                Name = "Quentin Tarantino"
            });
            // A movie and its director
            context.Movies.Add(new Movie
            {
                Name = "Titanic",
                Directors =
                [
                    new Director
                    {
                        Name = "James Cameron",
                    }
                ]
            });
            context.SaveChanges();
        }

        using (var context = new MovieContext(options))
        {
            // Imagine a query with filters on director and movie
            var directors = await context.Directors
                    .Include(d => d.Movie)
                    // I thought this would retrieve
                    // directors with movies
                    .ToListAsync();

            foreach (var d in directors)
            {
                Assert.IsNotNull(d);
                Assert.IsNotNull(d.Movie);
                //     ^^^^^
                // This one breaks...
            }
        }
    }
}

In this legacy app, child entities could exist without parents. The real query also applied filters on both entities.

Now let’s look at the SQL EF Core generated:

SELECT [d].[Id], [d].[MovieId], [d].[Name], [m].[Id], [m].[Name]
      FROM [Directors] AS [d]
      LEFT JOIN [Movies] AS [m] ON [d].[MovieId] = [m].[Id]

Notice the LEFT JOIN. Using int Movie instead produces an INNER JOIN.

Lesson: JOIN type depends on the joining property’s nullability, not on Include() itself.

One Simple Shift That Turned My Content Into Sales

2026-01-12T00:00:00+00:00

I tried the “proven” formula the big names swear by and it failed miserably.

I did what most people recommend to sell:

Write social media and long-form posts.
Offer a free email course or opt-in.
Take people to a newsletter.
Pitch your offer or products.

But after months of content, I realized something was broken.

The realization that changed everything

I packed my best career LinkedIn posts into a free 7-day email course.

I offered it as “pay what you want” and promoted it on LinkedIn. A few readers left a tip. It gave me momentum to keep promoting it.

But when I sent emails, almost nobody clicked my offers. After more than 30 emails, my products made just $1. OK, maybe my copywriting wasn’t strong or I was selling the wrong products.

The math doesn’t add up.

The change that brought the sales

Every step between your reader and your offer makes a sale harder.

It’s like walking people into your store, then sending them away for a course before selling what’s already on your shelves. By the time you follow up, they already bought somewhere else and forgot about you.

For my content strategy, I removed the intermediate steps. Social media and long-form posts -> products. Now I plug my book sales pages inside or at the end of posts.

With that simple fix, sales came in and I passed the $1 test. My first book, Street-Smart Coding, got two pre-sales within weeks of announcing it.

It wasn’t emails or “nurturing.” It was removing friction. A confused reader takes no action.

Remove the friction. Make action effortless. Let every piece of content be a sales representative.

A Short Story to Become Wiser (and Be More Present)

2026-01-11T00:00:00+00:00

One day, a man approached a Zen master with a question.

“Master, what can a simple man like me do to become wiser like you?”

The Zen master said, “Well, I just sleep, eat, and talk.”

“Hmm, I already do that. But I’m not a wise man like you,” the man said.

“You may do that. But when I sleep, I’m simply sleeping. When I eat, I’m simply eating. And when I talk, I’m simply talking. When you sleep, you remember problems. When you eat, you use your phone. And when you talk, you think about what to ask next or how to answer.”

I first heard that story in a Sunday sermon, and it stayed with me.

It reminds me of a lesson from Eckhart Tolle’s The Power of Now. Our mind is like a time machine, taking us to the past (where guilt and resentment live) and into the future (where anxiety lives). But wisdom begins when we step off that machine and live in the present.

2026 Start-of-Year Stats to Keep Myself Accountable

2026-01-10T00:00:00+00:00

For the first time, I’m putting my numbers out there.

Mark Thompson shared his stats on Medium. The point wasn’t to show off, but to hold ourselves accountable with our growing goals.

Here are some of my stats, starting 2026:

#1. Blog: My blog is my content hub. All my ideas start or end on my blog. Then, I syndicate in other places.

Total so far: 708 posts. Last year, I posted daily and hit the 400-daily posts milestone. For a recap, here’s my 2025 in review.

#2. Medium: This is my main driver of traffic and book sales. Last year, I saw a big bump in views and followers. So far: 1,197 followers and 643 subscribers.

#3. LinkedIn: This is my only social media channel, where I reshare bite-sized posts. So far: 832 followers and 364 connections.

#4. dev.to: I use dev.to only for coding content.

I have a “funny” follower count: 28,552. Mostly inactive accounts. When you create a new account, the welcome wizard asks you to choose tags and follow people.

More accurate stats: 236 posts, 1,921 reactions, and 549 comments.

#5. Gumroad: This is my store for courses and books. Last year: 202 sales, 3,530 views, and one new book launched.

#6. Friday Links: This is the “backend” for my product sales. Each Friday, I send 4 curated links. So far: 146 subscribers and 53 issues sent.

My plan for 2026

In 2026, I’m focusing on simplifying my content strategy, not chasing followers.

Here’s what I’m doing:

I’m using dev.to API to automatically repost my posts with a simple script.
I’m simplifying my promotion strategy for my books.
I’m repurposing Medium highlights on LinkedIn.

In 2026, I’m doubling down on a simple, repeatable system instead of vanity metrics.

Friday Links: The best time to be a coder

2026-01-09T00:00:00+00:00

Hey, there!

Here are 4 links I thought were worth sharing this week:

#1. AI makes coding and shipping nearly free. Side projects alone won’t help you stand out (7min). Maybe it’s time to double down on open source contributions or start a “learn and build in public” YouTube channel.

#2. Addy Osmani, a leader at Google, shared 21 lessons after a decade of coding (10min). The one that resonated the most? #6. “Coding doesn’t advocate for you.” Good code alone doesn’t make you a good coder, especially in the AI era.

#3. AI shows coding isn’t the bottleneck. A concept that isn’t new. Here’s a breakdown of why it’s never been the bottleneck (6min).

#4. Maybe juniors won’t say the same, but it’s a great time to be a coder (5min). Our job may be to design systems and let AI fill in the blanks. (That’s point #10 from that post)

And in case you missed it, I wrote on my blog about the “hiring is broken” law of coding blogs (2min) and the mantra to thrive in the AI era (2min).

Happy coding in 2026!

See you next time,

Cesar

AI Means You Don't Need to Learn So Many Programming Languages

2026-01-08T00:00:00+00:00

We no longer need to keep learning new programming languages.

If AI writes 90% of our code, becoming a polyglot coder isn’t valuable anymore.

Here’s what Gergely Orosz says in When AI Writes All Code,

…With AI writing most of the code, the advantage of knowing several languages will become less important when any engineer can jump into any codebase and ask the AI to implement a feature – which it will probably take a decent stab at. Even better, you can ask AI to explain parts of the codebase and quickly pick up a language much faster than without AI tools.

Obsessing over learning languages didn’t work for me. That was before AI.

Trying to master many languages was my biggest mistake as a new coder. Something else always made people stand out. And something else got me into trouble.

The real question is what skills matter.

Maybe AI is making us:

Master one general-purpose language, like C or Go.
Understand core principles: problem decomposition, clean code, and SOLID.
Develop strong code-reading skills

Or maybe we should learn languages that challenge our thinking: Haskell, LISP, or a language from a different paradigm. Learning Java after C# doesn’t teach much. AI can generate code in “challenging” languages, but they build stronger problem-solving skills for prompting LLMs.

To stand out when AI shines at coding, we need to step beyond the IDE. We need teamwork, communication, and the broader skills I cover in Street-Smart Coding. It’s the roadmap I wish I had when starting out.

Six Lessons to Say More With Fewer Words—Using Smart Brevity

2026-01-07T00:00:00+00:00

As writers, your job is to adapt to how your readers consume words.

Why this matters: Content is free and abundant. We are drowning in emails, Slack messages, and beeps and buzzes. In seconds, we decide to read or keep scrolling.

A wall of text makes us stop reading. I learned that the hard way. And you and I do the same.

We don’t read, but skim.

Deliver fast. Say more with fewer words. That’s the big idea behind Smart Brevity, the digital version of the classic Elements of Style.

Here are six lessons to apply Smart Brevity:

#1. The one idea test. Start writing the one thing you want readers to know. Put it front and center. Then ask someone else if they can find it.

#2. Use headline, strong first line, “why,” and “go deeper.”

Don’t make people choose what’s important. You tell them.
Tell readers what your piece is about and if it’s for them.
Use key phrases to guide skimmers. Phrases like “why this matters,” “the big picture,” or “backstory.”

In Mastery, Robert Greene used “Understand” to introduce big ideas. That’s a visual clue for skimmers.

#3. The bar & beach test. Write like a human. Don’t use any word you wouldn’t use in a bar or on the beach. No more “Dear LinkedIn network, I’m pleased to announce…“

#4. The “would you read it?” test. Once you’re done, ask yourself: “Would I read it if I hadn’t written it?” If not, why do you think someone else will?

#5. For email subject lines:

Use 6 words and prefer one-syllable words.
Emojis make your subject lines stand out.

#6. For presentations:

Start and end with “if you remember one thing from this, …“
Use 5 or 6 slides and one point per slide.

For fiction, we want authors to take us to new, imaginary worlds. But for emails, presentations, and social media posts, we need shorter, clear text. Even in non-fiction, why make readers flip through pages for one points? Brevity always wins!

The "Hiring Is Broken" Law of Coding Blogs

2026-01-06T00:00:00+00:00

If you have a coding blog, sooner or later you’ll write a “hiring is broken” post.

Today on r/programming, I saw another one. I’ve written mine too.

Yes, we don’t know how to hire. Behavioral questions, LeetCode, take-homes, IQ tests…Every company has a different answer.

But our “hiring is broken” posts won’t change how big corporations interview. Decision-makers don’t read coders’ blogs.

Instead of venting into the void, why not share “here’s what I learned and what I wish I had done differently…” posts, including:

The kind of interview
Subjects you forgot to review
What you like and dislike about the process

Keep blogging. One day, your blog becomes your portfolio, and interviews turn into discussions about your posts. That has happened to me only once.

Blogging won’t fix hiring overnight. But it can fix how you stand out. That’s why it’s one of the lessons in Street-Smart Coding, the roadmap I wish I had staring out.

The Mantra to Thrive in the AI Hype

2026-01-05T00:00:00+00:00

If AI can do it in minutes, it’s not special.

AI has made coding accessible. You don’t need a degree or bootcamp to have something working. A few prompts to an LLM can replace hours or days of work.

That’s good news…and bad news.

A portfolio with the same to-do apps no longer stands out. Anyone can do that with AI in a few minutes. Maybe the alternative is a “build/learn in public” YouTube channel. Or contributing to non-trivial open source projects.

A take-home challenge doesn’t work for hiring. Again. An easy task for AI. Maybe whiteboarding interviews won’t go away.

Only crafting clean code isn’t enough.

Don’t burn your copy of Clean Code. You still need to tell whether what AI spits out is good code.

But you need to do what AI can’t:

Ownership when code breaks
Collaboration to build trust
Communication to present technical problems clearly

That’s what you can’t automate. Those skills worked 10 years ago and will work 10 years from now.

To help you build the skills to stand out, I wrote Street-Smart Coding—The roadmap I wish I had on my journey from junior to senior.

Forget Syntax and Lines of Code. Instead Do This to Stand Out

2026-01-04T00:00:00+00:00

Good code won’t save your career.

For so long, I chased perfectly clean code, thinking better code = better cod-er. That turned me into a clean code cop, looking for infractions around me. It got me fired.

Focusing on syntax alone was my biggest mistake as a new coder.

Why code isn’t enough

Two experiences taught me good code isn’t what mattered most.

At a past job, when the team leader left, the one promoted wasn’t the best coder. It was the one who showed initiative to own the core feature.

Then during layoffs, I talked to a leader from another team. He was told to sort people into buckets: A, B, and C. Bucket C left first, then B, then A. The criteria wasn’t perfect code. It was whether the leader wanted you on the team. Of course, the ones writing horrible code got into the C crowd first.

It was always something else besides coding.

Your code can’t speak.

Addy Osmani, a leader at Google, shares why you need more than code to stand out.

He wrote,

Your code doesn’t advocate for you. People do.

…Code sits silently in a repository. Your manager mentions you in a meeting, or they don’t. A peer recommends you for a project, or someone else.

Get good at coding to stand out. No doubt!

But your code won’t speak for you.

Here’s what will:

Asking the right questions in meetings.
Working on something that brings (or saves) money.
Sharing your achievements after every project.
Being responsible for a feature from end to end.
Being the team member everyone wants to work with.

People won’t remember your code. They will remember your attitude.

That’s why I wrote Street-Smart Coding, the roadmap I wish I had starting out to grow and stand out as a coder.

Grab your copy of Street-Smart Coding here

3 Lessons From Robert Greene's Mastery to Unlock Your Inner Genius (You Can Be the Next Da Vinci or Einstein)

2026-01-03T00:00:00+00:00

There’s no secret behind the great masters of history.

We often think their success comes from a wealthy family, superintelligence, or invisible forces from other planets.

But in Mastery, Robert Greene shows there’s a process behind the success of those great minds. A process we can replicate to become a master too.

Here are my three main lessons from Mastery:

#1. “Mastery is like swimming”

We all have a natural inclination.

Maybe it’s writing, connecting with others, dancing, numbers, or animals. We’re drawn to something when money and a safe path aren’t involved.

Often, our inclination is clear when we’re kids.

For Einstein, that was seeing a compass for the first time. The forces moving the needle captivated his whole life.

To achieve mastery, follow your natural inclination and your strengths.

Like in swimming, you’ll barely move if you’re going against the current. That’s what happens when you try to master something you’re not suited for.

#2. Discover your Life’s Task

“Your Life’s Task is to bring [the seed planted at birth] to flower, to express your uniqueness through your work.”

Some masters know their Life’s Task since childhood. But others only find it after a phase of discovery and exploration.

Yoky Matsuoka is one of those masters.

She wasn’t interested in the traditional careers like law or medicine. She was into tennis. Her parents sent her from Japan to the US to pursue tennis, but an injury ended that path.

Unsure what to study, she chose engineering. Later, her interest in how hands work (from tennis) led her to robotics, and eventually neuroscience to study the brain-hand connection. By combining her passions, she revolutionized the design of robotic hands, modeling them after human hands.

If you don’t fit in any field or have multiple passions, create yours by exploring and combining other fields.

#3. The process behind great masters

All masters go through a similar 3-phase process:

Apprentice, Creative/Active, and Mastery.

First, they immerse in a field, learning as much as they can. For Leonardo, it was countless hours of sketching the landscape of his walks around the forest. Then, it was working under Verrocchio, one of the master painters of his time.

Then, all that immersion clicks and the master ventures into their own creations. That usually means taking distance from mentors and finding their own way.

Finally, their field becomes second nature, guided by intution. Notes flow on a piano, scenes come alive on canvas. The apprentice becomes a master. And that’s not the result of magic, but immersion, practice, and persistence—A path open to anyone willing to walk it.

Friday Links: Programming is dead, naming tools, and better than cheap

2026-01-02T00:00:00+00:00

Hey there.

Here are 4 links I thought were worth sharing this week:

#1. One of my worst career mistakes was going on auto-pilot without a plan. I jumped from job to job until I got bored or fired. But if you don’t plan your career, someone else will (4min).

#2. 2026 is the year to start a side project? Just find a focused time block. Maybe that’s coding on the subway (6min).

#3. A summary of the state of AI at the end of 2025 (4min) by the Redis’ creator.

#4. Holiday season is usually for reflection. If you haven’t yet, try these a 10-question (4min) or a 40-question prompts (3min). I followed that last one.

And in case you missed it, I wrote on my blog about feeling AI FOMO (2min) and a 30-action digital decluttering plan (4min).

Happy coding in 2026!

See you next time,

Cesar

2025: My Year in Review

2026-01-01T00:00:00+00:00

I’ll remember 2025 as the year I became a writer—and the year I lost my mom.

The saddest moment

After five years of fighting a chronic disease, she left.

It was the saddest, loneliest moment of my life. It led me to my toughest post ever.

To honor her memory, my sister and I wrote a book: Nuestros Recuerdos (Our Memories in Spanish).

We compiled my journal entries and her poetry. A friend drew some illustrations. And we found some pictures of her when she was young.

That was our therapy and way to keep her alive in our memory.

2025 was a year of achievements and melancholy, winning and losing, endings and beginnings.

Some victory dance moments

#1. My first viral post. One post about testing private methods got syndicated or reshared. BOOM! A traffic spike and some ebook sales.

#2. My first interview. Well, it wasn’t exactly an interview.

The LAX community invited me to a QA session with their coding students. They’re building the next generation of coders and leaders in Africa.

Their community manager found one of my posts and reached out. Another victory for writing.

That interview was the perfect excuse to ask for feedback on my communication skills. A coach taught me this 4-step framework for interviews.

#3. My first book, Street-Smart Coding.

It took about 4 months, from idea to typing the last word. Writing taught me plenty, but promoting taught me more.

I adopted a simple marketing strategy and passed the $1 test.

I translated it to Spanish and published it on Amazon.

And with a book came my first hater. Someone called me “b1tch” for promoting my book and left a sarcastic comment elsewhere.

The book was a real challenge.

#4. My first appearance on Hacker News. Yes, my blog got syndicated on HN. I didn’t make it to the first page. But hey, it’s progress.

In 2025, I wrote every single day, hitting the 400-post mark.

Among those daily posts, here are the top 10 posts by reads:

For 2026, apart from working on my health daily (simple idea #2 from the post #7), I’m making simplicity my intention. And I started decluttering my digital life. That intention will impact my content system too.

Thanks for reading, and happy coding in 2025!

Don’t miss my best of 2024, 2023, 2022, and 2021.

Books I Read (and Books I Didn't Finish) in 2025

2025-12-31T00:00:00+00:00

YouTube changed how I read books.

One day, the YouTube algorithm showed me one video on reading one book per week.

That video made me read two books at once. Now I keep a book on my dinner table and another on the couch. Those are my reading spots after meals.

And binge-watching Ryan Holiday’s YouTube channel made me change my reading habits.

I went back to reading on paper and writing in margins. That used to feel like a capital sin.

With those two strategies, here are the books I read and one takeaway from each:

Books I finished

#1. Skip the Line by James Altucher: Forget about the 10,000 hours to become an expert. Instead of accumulating hours, run 10,000 experiments: quick actions that teach you something.

#2. Steal Like an Artist by Austen Kleon: Originality is overrated. Find who to copy. Then find what to copy. My favorite line: “Hands first, then computer.”

#3. Mini Book Model by Chris Stanley: In 2025, I redefined what a book is.

These days, the real challenge is to make people finish books. Social media has ruined our attention spans.

The solution? Write shorter books.

James Altucher planted a seed with his “10-paper book” challenge. Building on that idea, Chris’ book gave me frameworks to title, outline, and write “mini books.”

I’m following the mini book principles to write my next coding books.

#4. Writing to Think by William Zinsser. My favorite line: “Writing is learned mainly by imitation.” That felt like permission to explore and develop my own voice.

#5. 21 Lessons for the 21st Century by Yuval Noah Harari. Making predictions is hard, especially about the future. With the uncertainty of what AI could bring, the sole skill to master is the ability to learn and adapt.

#6. Writing for Developers by Piotr Sarna and Cynthia Dunlop. My favorite line? You’re not writing enough. The book shared it for engineering blogging, but the advice applies everywhere. Write more!

Books I didn’t finish but I’m still reading

#7. Mastery by Robert Greene. Some masters knew their Life Task as children. Others discovered it through experimentation and exploration, at the intersection of fields.

#8. Glucose Revolution by Jessie Inchauspé. My sister picked up this one first. I started to apply some concepts to keep my glucose spikes under control. That’s my secret productivity hack to avoid the afternoon crash after lunch.

Don't Quit Your Day Job—Create in Two Hours a Day Instead

2025-12-30T00:00:00+00:00

“If I had more hours, I’d build more things.”

Anyone else feel that? Or that’s just me?

I’ve wanted to quit my day job more times than I can count.

I stopped thinking about quitting when I discovered the idea of a daily creative block.

Two hours are enough to create evergreen content.

Mark Thompson works for 2 hours.

He’s a veteran marketer who now creates for a living. He replies, posts, and runs a community. All in about 2 hours every day.

About working for just 2 hours, he wrote,

Two hours of focus work today can create a lifetime of income tomorrow.

That was one of the lines that made me think recently.

A professional writer doesn’t write for that long.

Mark isn’t the only one with that routine.

Steven Pressfield, author of War of Art, follows the same practice.

In an interview in Huberman Labs, he shared that he only writes for…guess how long? Two hours. After that, it’s time for interviews, marketing, and promotion.

If pros write only for two hours, we don’t need to quit. We need habit and discipline first.

Austen Kleon said it in Steal Like an Artist, keep your day job. I stole his idea of checking a box every time I work on my projects. That’s my plan for 2026 and the years to come.

You just need two hours. Start today. The time to quit will come later.

My 30-Action Digital Decluttering Plan For a Fresh Start (Useful Every Year)

2025-12-29T00:00:00+00:00

I’ve tried resolutions. But they didn’t work.

On New Year’s Eve, excitement fills the air: holidays, dinner, and presents. But that excitement often becomes a to-do list we never complete.

Instead of resolutions and to-dos, I prefer to go with an intention.

Last year, my intention was “health.” I did something for my body, mind, and spirit every day. One simple idea that changed my life. A 15-min workout session, writing, and a moment of silence kept me sane.

For this year, I’m making “simplicity” my new intention. And to start, I’m decluttering my digital life. Here’s my decluttering plan:

Computer

#1. Before messing with anything, run a backup. It doesn’t have to be complicated. Plug in a USB drive and copy what you want to keep. I use FreeFileSync to automate backups.

#2. Keep the Desktop clean. All those temporary files looking for a folder: Gone!

#3. Clean the Downloads folder. Remove all those freebies you never read.

#4. Archive unused files from Documents.

#5. Uninstall unused software. If you haven’t used it in the last 6 months, it’s out.

#6. Delete old backups.

#7. Archive notes you no longer need or have already used.

#8. Remove screenshots you don’t need anymore.

#9. Clean your RSS reader. Unfollow dormant blogs or sites.

#10. Clean your password manager.

#11. Discard one-time coding projects or folders.

#12. Alternatively, run BleachBit, CCleaner, or similar apps.

For each browser…

#13. Remove bookmarks. I often use bookmarks as a cheap “Read for Later” app.

#14. Clear browser history, cookies, and saved data.

#15. Remove or change pinned tabs.

#16. Uninstall extensions you don’t need.

Online

#17. Turn off email notifications. I don’t need an email for every like, comment, or repost. Leave email for 2-factor authentication or security notifications.

#18. Unfollow people from social media accounts. If they haven’t published anything in the last 6 months, out. If their message doesn’t resonate anymore, out.

#19. Clear saved content from social media apps, like Medium, LinkedIn, or dev.to.

#20. Delete old email notifications. My bank sends me an email every time I buy something. If I still need them, I can generate a report from the bank’s website.

#21. Unsubscribe from newsletters.

#22. Archive reference emails.

#23. Clean Canva projects. Often I create multiple versions of the same design, but only the latest matters.

Phone

#24. Clean the homepage. Leave no apps or icons there. Group related apps inside folders on the second page.

#25. Remove social media and unused apps. Again, run the 6-month test.

#26. Remove memes and large files from WhatsApp groups.

#27. Remove “bad” photos. People in funny poses, with closed eyes: gone!

#28. Remove to-watch or to-read notes.

#29. Clean your browsers’ history.

#30. If you use YouTube, clean your search history and change Google’s Ads ID.

#31. Clear Cloud storage. I keep extra copies when sharing files between computers.

I thought about making a checklist on Gumroad, but that would just add clutter to your downloads. Instead, bookmark this post.

Dear Coder: Open This If You're Feeling AI FOMO

2025-12-28T00:00:00+00:00

It’s all over the headlines.

Every so often, someone reveals a model X% faster. A tech CEO makes bold claims about the future of coding. The stock market reacts with euphoria. Prices go up.

AI has also brought new buzzwords. Agents, prompts, workflows, integrations…

Pick your battles

FOMO is real.

Almost every week, I find tutorials about “MCP.” Whatever that means. I skip most of them. I’ve chosen my battles to stay sane in the hype cycle.

I’m still figuring out how to adopt AI without losing my skills and identifying the problems it brings.

That’s keeping me busy enough.

Some things haven’t changed

If you’re also experiencing FOMO:

Don’t worry. Fundamentals matter more than ever.

Plenty of codebases still suffer from N+1 problems, missing pagination, and SQL injection. Most were written before the AI hype. Now imagine the chaos inside vibe-coded codebases.

There’s still work ahead before (or if) AI shines at coding.

Don’t forget about AI. But build real skills first. Then leverage AI. In that order.

To help you build lasting skills beyond the hype, I wrote Street-Smart Coding. The roadmap I wish I had starting out.

Grab your copy of Street-Smart Coding here

7 Lessons From the Mini Book Model to Write Shorter, More Impactful Books

2025-12-27T00:00:00+00:00

Forget 30,000 words. Forget publishers.

For so long, writing a book felt distant: original ideas, months of research, and plenty of rejections. Then I discovered self-publishing had redefined what a book could be. And finally, Chris Stanley debunked those objections with the concept of a mini book.

After attending one of Chris’ workshops last year, I devoured his book, Mini Book Model. Here are 7 lessons I learned:

#1. Start with a problem and your point of view (POV). Instead of starting with a blank page, identify one problem your reader faces and how you solved it.

Since you’re writing about your solution, you don’t need months of research. Often, research is procrastination in disguise.

Apart from a problem and solution, after launching Street-Smart Coding, I learned to write a book description and a one-line summary before the content. That forces you to clarify your message.

#2. Resist the urge of adding more fluff. Unlike traditional non-fiction books, the point of a mini book is to present a message as fast and concisely as possible.

As a guideline:

If you reach 5,000 words, you have enough.
If you pass 15,000 words, stop.

A target word count isn’t the goal, but to fulfill your book promise.

#3. Use the W’s outline to present new concepts. With the W’s outline, use one chapter to answer what/why/who/when/where/how. It’s the perfect outline to introduce a new concept. Tweak to emphasize the “how,” if needed.

#4. If you have a process or framework, write a mini book about it. Make each step of your process a chapter of your mini book. Then, go deeper on a step with another mini book. And plug future books into earlier ones.

That’s what Chris did with the whole Mini Book series. The first book, Mini Book Model introduces what a mini book is and how to write one. Then he wrote another mini book about each step in the process.

#5. Use 3 points per chapter and 3 subpoints per point. The goal is to keep your mini book focused and on point. But feel free to use the points you need to deliver your message.

#6. Introduce a checkpoint in the first half. This isn’t a lesson Chris taught, but one he practiced in the book itself. Instead of waiting until the end to ask for a review, he added a call-to-action after the first chapters.

#7. To edit your mini book, read it out loud while recording it. It helps you catch typos and speed up your audiobook launch. Win-win!

Mini books give you permission to write and launch without gatekeepers. No more 30,000 words. That’s liberating. What are you waiting to join the mini book movement?

I’ve embraced mini books in the coding space, and you can find my mini books here.

Friday Links: Programming is dead, naming tools, and better than cheap

2025-12-26T00:00:00+00:00

Hey, there.

Here are 4 links I thought were worth sharing this week:

#1. “AI replacing coders” and “programming being dead” have been all over the news. But that’s not true. AI can “write” code, but it can’t do our job (5min). Coding has never been the bottleneck or the most valuable skill.

#2. Naming is hard. Especially when we’re naming packages or tools. We’ve gone from descriptive to funny, unrelated names (Viper, Cobra, Melody). We’ve lost the plot of naming tools (9min).

#3. If we want to stand out among the crowd, we have to be better than the cheap alternative (1min): frozen pizza, smartphone camera, or AI.

#4. Looking for an interesting read this holiday season? Well, check out Read Something Wonderful. Just a few clicks took me to the 1,000 true fans essays, one of the most popular ones on the Internet.

And in case you missed it, I wrote on my blog about What coders could offer instead of LOCs if AI takes over (2min) and vibecoding ruining CS degrees (3min).

See you next time,

Cesar

I'm Answering the 40-Questions Reflection Prompt

2025-12-25T00:00:00+00:00

I’m running another internet challenge.

Well, I don’t know if this was intended as a “challenge” or more like a year reflection. But I found this idea on Ava’s blog. Ava, if you’re reading this, please keep sharing those challenge ideas, I like them.

Unlike most of my posts, I’m not writing them on The Most Dangerous Writing App or fully editing them. If this were a video or a song, I’d be making a single take.

#1. What did you do this year that you’d never done before?

A book! I wrote my first official book, Street-Smart Coding.

I had written two small books before. But I wasn’t confident enough in my writing that I didn’t call them books, but “ebooks.”

After finding about mini books, I changed my mind about what a book is and realized I could write one. So I did it.

#2. Did you keep your new year’s resolutions?

I don’t do resolutions anymore.

I used to make a list of resolutions: learning a new language, traveling, doing this or that. But I ended up doing different things from the list.

After resolutions, I tried with “themes,” like Yoga March or Side Projects November. Dunno, they didn’t work either.

My only resolution, let’s say, is to do my daily practice: doing something for my body, mind, and spirit every day. That’s the only goal/plan I’m carrying over 2026.

#3. Did anyone close to you give birth?

Yes! One of my best friends after trying for a while had her first baby. Hoooray!

#4. Did anyone close to you die?

Yes. I lost my mom.

She fought with a chronic disease for over 5 years. And being a writer, I couldn’t avoid writing about her. That’s the saddest post I’ve ever had to write. And my sister and I are about to release a book about our mom.

#5. What cities/states/countries did you visit?

I visited my hometown a couple of times. In fact, I’m writing this in my grandma’s place, where I grew up.

#6. What would you like to have next year that you lacked this year?

Health…and simplicity.

I’m not a sick person. But last year, I had to visit an ER with kidney stones and see a doctor a couple of times. I’m focusing on healthy habits next year: eating the right food in the right amount.

#7. What date(s) from this year will remain etched upon your memory, and why?

The date my mom left.

To honor my mom’s memory, I turned that date into my launch day for books and other projects. It’s my way to remember her and dedicate my work to her.

#8. What was your biggest achievement of the year?

The book! I’m proud of it.

#9. What was your biggest failure?

I wouldn’t say failure, but that would be landing my first paying ghostwriting client.

After doubling down on my writing last year, becoming a ghostwriter was the natural next step for me. I bought a ghostwriting program and even changed my LinkedIn bio to include “ghostwriter.” I focused on releasing my book and set the ghostwriting gig aside.

#10. What other hardships did you face?

I visited ERs and ICUs with my mom a couple of times.

It was hard. Waiting in rooms, waiting for blood donors, waiting for diagnosis, waiting for surgery paperwork…Traveling across town to spend the day with her while she was in a hospital. Days fulls of uncertainty.

I don’t want to visit a hospital in ages.

#11. Did you suffer illness or injury?

Yes. Kidney stones. OMG! It’s painful. Imagine a Heavyweight boxer punching you next to your bladder every second. That’s how it feels…until the stone is out.

#12. What was the best thing you bought?

That’s probably a comfty pair of shoes…and notepads to run my 10-idea lists. That’s how I wrote my book and countless of pieces of content.

#13. Whose behavior merited celebration?

This year, I learned the value of real friendship.

In my saddest moment, two of my friends were with my sister and me. And when another friend found out my mom, he rushed from his city to stay with us for a day.

#14. Whose behavior made you appalled?

Dunno if appalled, but…Online haters.

With more eye balls on my content, I got my first hater, someone calling me “b1tch” for promoting my work. And it seems someone somewhere will always get offended online. The Internet, I guess.

#15. Where did most of your money go?

That’s grocery, bills, medical care, and books.

#16. What did you get really, really, really excited about?

Seeing the first preorder for my book.

When I saw the email notification, I was like “OMG! OMG! Yes! Yes!” A true happy dance moment.

And months later, I had another happy dance moment when someone called me the “Street-Smart guy” in a comment under one of my posts. That moment I knew my marketing was working.

#17. What song will always remind you of this year?

There’s one.

I can’t remember its title. But it says something like “for a brief moment, there was a future between us.” In Spanish

Of course, that line goes about someone heartbroken in a romantic relationship. But that’s how my sister and I felt about our mom. Listening to that song is part of our ritual to honor our mom every month.

#18. Compared to this time last year, are you: happier or sadder? Richer or poorer? Healthier or unhealthier?

Happier, richer, and healthier.

Well, it’s complicated I feel happier and melancholic at the same time. I’ve had good achievements and I wish my mom were here to see them.

#19. What do you wish you’d done more of?

Being present. I’ve been a time traveler. That has taught me our mind is the battle field with all the thoughts that come and go.

#20. What do you wish you’d done less of?

Scrolling, commenting, and social media.

As part of growing as ghostwriter, I found “grow your own account” and “be your first success case.” That made me spend quite some time engaging and commenting under LinkedIn posts to grow my presence. I found interesting people and Internet friends tho.

But I wish I had done social media less.

#21. How are you spending the holidays?

I took some time off from freelancing. I packed a couple of books with me to visit my uncle and aunt. I’m only writing on my blog and cross-posting to other platforms.

I’m not fully idle, I decided to pick a light project: I’m revamping an old book.

#22. Did you fall in love this year?

No.

#23. Do you hate anyone now that you didn’t hate this time last year?

Noooo. Hate is a strong word.

#24. What was your favorite show?

#1 by far, House M.D. But I enjoyed Boots, The Recruit, The Diplomat, The Agency. Lots of spy shows, I know.

In fact, I like House M.D. so much that I wrote a couple of posts about it, this one and this one, and included a whole chapter about it on Street-Smart Coding.

#25. What was the best book you read?

I’m trying to remember the books I read…Skip the Line, Steal Like an Artist, and I’m about to finish The Post Office.

#26. What was your greatest musical discovery of the year?

I didn’t have any. I enjoy listening to the same songs over and over.

#27. What was your favorite film?

Not favorite, but I recently enjoyed Reading Lolita in Tehran.

#28. What was your favorite meal?

There’s a salad with cucumber, tomato, mint, parsley, and lemon that my sister makes. I love it. I could eat it every day. It’s a Middle-East inspired recipe.

#29. What did you want and get?

Writing a book.

#30. What did you want and not get?

My mom back home after that last visit to a hospital.

#31. What did you do on your birthday?

After picking up my phone to see what photos I took that day…

I wore a Cartoon Network themed T-shirt my mom and sister bought me. Little did I know my mom was really in pain when she went out to buy it.

I got sentimental writing that last line…

#32. What one thing would have made your year immeasurably more satisfying?

Seeing mom back home…

#33. How would you describe your personal fashion this year?

Just like past years: blue jeans and black t-shirts.

#34. What kept you sane?

Doing a 10-min full body workout, running, and writing every day.

#35. Which celebrity/public figure did you admire the most?

#1. James Altucher, his career progression and writing have been really inspiring to me.

#2. Ryan Holiday. Not that I want to be like him, but I want to make a living reading and writing books too.

#36. What political issue stirred you the most?

I’m not into politics or sports. I don’t like to argue with anyone. Life is too short for arguing.

#37. Who did you miss?

Mom.

#38. Who was the best new person you met?

I didn’t meet many new people in real life. But I met an awarded school teacher, a top cellist, an already FIREd woman, and fellow coders via LinkedIn.

#39. What valuable life lesson did you learn this year?

It’s a cliche until you go through it, but enjoy every moment with your loved ones.

And it was from Choose Yourself Stories by James Altucher that I read about treating every day like the last day of your loved one with you.

#40. What is a quote that sums up your year?

I have a couple:

#1. “One day at a time”

#2. “There are always enough reasons to keep fighting”

Warm Up Your Network This Holiday Season

2025-12-24T00:00:00+00:00

Your professional network is one of your greatest career assets.

Most job opportunities aren’t on job boards. They come through favors and phone calls. I know because I’ve found almost all my jobs by knowing someone who knows someone.

But don’t wait for a layoff to reach out for help.

The holiday season is a good time to “warm up” your connections. This season is for sharing greetings, postcards, and gifts.

Send a quick hello to old connections: bosses, coworkers. Don’t ask for favors or worse, sell something. Just a casual “how are you” followed by “Merry Christmas” or “Happy New Year.” You can even use the same message for everyone.

You will surprise them and they’ll keep you top of mind.

The Real Sign Your Writing (Or Any Creative Skills) Is Improving

2025-12-23T00:00:00+00:00

I was supposed to unplug during the holidays.

But I decided to pick an easy project. I’m revamping Unit Testing 101, the first book I wrote. I called it an ebook because “book” felt too big a deal. Back then, I was even scared to put a price tag on it.

After finishing Street-Smart Coding, my first “official” release, I wanted Unit Testing 101 to match that standard: editing, formatting, and a stronger cover.

Today I opened the draft in Google Docs and realized I’d structure chapters more clearly, tighten explanations, and reduce duplicated concepts.

If you cringe at your past work and think, “I’d do it way better now,” that’s the clearest sign you’ve grown.

re: Is "Vibe Coding" Ruining My CS Degree?

2025-12-22T00:00:00+00:00

It’s tempting to default to AI for its speed.

If you’re stuck, just write a 2-sentence prompt and after some beep, beep, boop you get an answer. But relying too much on AI hides a serious problem.

I’ve witnessed the over-reliance on AI myself. And it’s worse for CS students. Maame Afua A. P. Fordjour shared in a dev.to post,

[When facing a Data Structures assignment] I type: “Yo, I need a Red-Black Tree implementation in C++. Keep the vibe academic, handle the edge cases for rotation, and add comments that sound like a stressed undergrad wrote them.”

Thirty seconds later. Done.

It compiles. It passes the test cases. It’s beautiful code. And I have absolutely no idea how it works.

It’s not the tool, but how you use it

Like we always say: the problem isn’t the tool, but how we use it.

AI isn’t going anywhere. It’s already changing our job descriptions. But we need strong guidelines to avoid blindly trusting AI and losing our skills.

If you’re a confident coder, write your method signatures, use comments to sketch their bodies, and let AI fill in the blanks.

But if you’re a beginner, my take is radical: don’t use AI to generate code.

Don’t use AI to do your homework. Use it as your teaching assistant instead. To quiz you, generate test cases, explain a tricky code block. Otherwise it’s like sending someone else to the gym and then complaining when you don’t see your muscles growing.

AI is like a powerful calculator. You need strong math skills first before using one.

If you want to strengthen your coding skills, my book Street-Smart Coding covers 30 lessons to help you level up, from Googling to communication to problem-solving.

Grab your copy of Street-Smart Coding here—That’s the roadmap I wish I had on my journey to senior coder.

What Coders Could Offer Instead of Writing Lines of Code If AI Takes Over

2025-12-21T00:00:00+00:00

What happens when AI codes better than we do?

For a second, let’s forget AI is more like a sloppy junior coder. Let’s stop feeling like cheating when prompting instead of typing. If AI writes reliable code, what would we offer as coders?

In a past Friday Links, I shared one post from Leon Mika that made me ask those questions.

Leon wrote,

Maybe writing code is no longer part of my “core offering” at this point in my career. Maybe it is the “judgement, tradeoffs, intents” and all the other buzzwords people throw around when describing a senior software engineer.

Leon’s post made me think what we could offer. Here’s my list:

Talking to end users to find out what they need
Choosing what features to implement
Choosing the right tools, stack, and frameworks
Scoping projects into milestones or sprints
Finding what to rewrite and when
Coming up with de-risking plans
Choosing the right time to scale
Sharing past mistakes and lessons
Vetting what to build, buy, or outsource
Finding cost-effective “cloudification” strategies

Some coders already do those tasks, but soon they’ll be everyday work for all of us.

In the meantime, AI is making us rediscover the practice of coding. And that’s already a good point for AI.

When AI shines at coding, we need strong product thinking, communication, and other skills I cover in Street-Smart Coding: 30 Ways to Get Better at Coding. That’s the roadmap I wish I had to become a senior coder.

Grab your copy of Street-Smart Coding here

Advent of Code 2025 in Summary

2025-12-20T00:00:00+00:00

I ran my first Advent challenge in 2022.

Instead of an Advent of Code, I ran an Advent of Posts. I wrote 22 posts, mostly about coding, in the days before Christmas. I missed two days but I declared the mission complete.

This year, I decided to follow the Advent of Code. For the first time, this year included only 12 puzzles instead of 25.

I challenged myself to write “functionalish” solutions. Sometimes that was a bad idea.

It wasn’t a bunch of LeetCode problems

The puzzles weren’t disconnected problems.

Every day started with a short story. The first day we arrived at the North Pole. Right away, we faced a setback that made us solve a puzzle. As we got inside the North Pole, there was always a complication.

In spite of the problems, elves were always organized. By the time we helped, they already had sorted out some details. That was our puzzle input. I guess elves are lazy or simply distracted.

There was a connecting story from one day to the next.

It wasn’t funny some days

My goal going through the challenge was to ignite my coding spark.

But some puzzles had ambiguous instructions or I overcomplicated the solution trying to follow a functional approach. I got stuck solving Day 8 and Day 11. I had to look up clues to get them done. Arrggg!

Those days, I got stuck with a stupid Blazor issue at work. Getting stuck after work wasn’t pleasant at all. The challenge was supposed to be funny and enjoyable. I didn’t need another source of stress.

My solutions

Despite the tough days, I eventually solved them all. OK, I cheated a bit.

Here are my solutions:

Day 1: Unlocking the North Pole
Day 2: Finding Invalid Product IDs
Day 3: Calculating the Joltage of Batteries
Day 4: Counting Rolls of Paper
Day 5: Counting Fresh Ingredients
Day 6: Doing Cephalopods’ Math
Day 7: Splitting Tachyon Beams
Day 8: Connecting Junction Boxes
Day 9: Finding the Largest Rectangle of Red Tiles
Day 10: Initializing Factory Machines
Day 11: Connecting the Reactor With a Server Rack
Day 12: Packaging Presents

From all the puzzles, one stood out. Day 12. It was playing Tetris with presents. My first thought was brute force with backtracking. After struggling with Day 11, I knew there was a simple alternative. And my intuition paid off.

Biggest lessons

Apart from collecting more extension methods, here are the biggest lessons I took away:

Always strive for simple, stupid solutions.
LINQ can take you a long way. I solved almost all the puzzles using LINQ.
Review data structures. Once more, I was trolled by trees.

See you next year for another Advent of Code or maybe another Advent of Posts.

Advent of Code really sharpens your problem-solving skills. But coding isn’t just about puzzles. It’s also about teamwork, collaboration, and many skills I share in my book, Street-Smart Coding: 30 Ways to Get Better at Coding. That’s the roadmap I wish I’d known from day one to become a senior coder.

Get your copy of Street-Smart Coding here

Friday Links: Coding, Space Jam, and people problems

2025-12-19T00:00:00+00:00

Hey, I didn’t miss my reading time this week. Here are 4 interesting links for you:

#1. One big lesson I’ve learned after over a decade in coding is most technical problems are people problems (5min). Most team problems trace back to poor communication. Just like marriages.

#2. I watched Space Jam countless times as a kid. I remember it because a coder tried to recreate its website with Claude and failed (10min).

#3. Blogging isn’t dead. There are still indie bloggers in a small corner of the Internet. Here are two ideas to discover indie bloggers (3min).

#4. With AI spitting out code faster than any of us, writing code may not be our main offering as coders (2min), but judgment, past failed projects, and risk management.

By now, I’ve finished the Advent of Code. Two days were tough. Instructions weren’t clear enough, or I overcomplicated my solutions. Here are two days where I got stuck: Day 8 (5min) and Day 11 (2min). I ended up looking at solutions to get unstuck.

See you next time,

Cesar

Advent of Code Day 12: Packaging Presents

2025-12-18T00:00:00+00:00

On Day 12 of Advent of Code, we’re helping to place presents under trees for Christmas. Basically, we’re playing Tetris.

After yesterday’s struggle, my first reaction was thinking it must be something simple instead of brute-forcing positions and rotations plus backtracking.

My first rationale was checking if the areas of presents was less than the available area. 7*numberOfShapes < width*height. By looking at other solutions, it seems that was enough.

This last puzzle felt…weird? I knew there was a simple solution after the struggle of previous days. And after looking at others’ solution, I feel like I missed the class on packaging algorithms. Everybody mentioned them in the solutions.

Today is another bearly voilà.

Advent of Code sharpens your coding skills. But coding is more than typing symbols fast. It’s also about teamwork, collaboration, and many skills I share in my book, Street-Smart Coding: 30 Ways to Get Better at Coding. That’s the roadmap I wish I’d known from day one.

Get your copy of Street-Smart Coding here

Advent of Code Day 11: Connecting the Reactor With a Server Rack

2025-12-17T00:00:00+00:00

On Day 11 of Advent of Code, we’re helping to connect a reactor with a server rack by following the path between devices.

Day 11 made me feel like an impostor. Since it involved a graph (one device outputs to multiple devices), I imagined a GetAllPaths() function and a LINQ query to count paths ending with “out.”

After more than 2 hours struggling with a recursive function, I looked at others’ solutions and realized I was overcomplicating it.

Yes, the solution used recursion. But it was simpler than I thought.

Here’s my full solution,

var connections = new Dictionary<string, IEnumerable<string>>
{
    { "aaa", [  "you", "hhh" ] },
    { "you", [  "bbb", "ccc" ] },
    { "bbb", [  "ddd", "eee" ] },
    { "ccc", [  "ddd", "eee", "fff" ] },
    { "ddd", [  "ggg" ] },
    { "eee", [  "out" ] },
    { "fff", [  "out" ] },
    { "ggg", [  "out" ] },
    { "hhh", [  "ccc", "fff", "iii" ] },
    { "iii", [  "out" ] },
};
var paths = CountPaths(connections, "you", "out");
Console.WriteLine(paths);
Console.ReadKey();

static int CountPaths(Dictionary<string, IEnumerable<string>> connections, string starting, string ending)
{
    if (starting == ending) return 1;

    var paths = 0;
    foreach (var connection in connections.GetValueOrDefault(starting, []))
    {
        paths += CountPaths(connections, connection, ending);
    }

    return paths;
}

Et voilà! Barely. Most people found today a warm-up after yesterday’s puzzle. But for me, it was the harder day. Trying to be too functional made me overcomplicate everything. Simple always wins, especially for Advent of Code.

Get your copy of Street-Smart Coding here

Advent of Code Day 10: Initializing Factory Machines

2025-12-16T00:00:00+00:00

On Day 10 of Advent of Code, we’re helping to turn on factory machines by configuring light indicators.

Each machine has buttons that toggle indicators, and the challenge is figuring out the minimal combination that produces the target pattern.

To model this, I define a machine as a list of booleans representing its light indicators. Then, I write Push() to toggle light indicators at a given index.

record Machine(bool[] Indicators)
{
    public Machine Push(int[] buttons)
    {
        var pushed = new bool[Indicators.Length];
        Array.Copy(Indicators, pushed, Indicators.Length);
        foreach (var button in buttons)
        {
            pushed[button] = !Indicators[button];
        }
        return new Machine(pushed);
    }
}

To configure a machine, I use this StackOverflow answer to generate all button combinations and apply them to reach the target indicator pattern.

static int[][] ConfigureIndicators(Machine m, int[][] buttons)
{
    var turnOn = new List<int[][]>();

    var combinations = buttons.Combinations();
    foreach (var combination in combinations)
    {
        var tmp = combination.Aggregate(m.Off(), (machine, comb) => machine.Push(comb));
        if (m.Indicators.SequenceEqual(tmp.Indicators))
        {
            turnOn.Add(combo);
        }
    }

    return turnOn.MinBy(t => t.Length);
}

LINQ Aggregate method to the rescue here!

Unlike the puzzle instructions, with buttons.Combinations() I’m assuming I can only toggle a sequence of buttons once.

So far, I can write,

var m = new Machine([false, true, true, false]);
var buttons = new int[][]
{
    [ 3 ],
    [ 1,3 ],
    [ 2 ],
    [ 2,3 ],
    [ 0,2 ],
    [ 0,1 ]
};
var presses = ConfigureIndicators(m, buttons);
// presses.Length

And this puzzle is almost a voilà moment. I skip parsing the diagrams and just hard‑code them, then sum the button‑press lengths. Yes, I’m a bit lazy.

Here’s my full solution,

var m = new Machine([false, true, true, false]);
var buttons = new int[][]
{
    [ 3 ],
    [ 1,3 ],
    [ 2 ],
    [ 2,3 ],
    [ 0,2 ],
    [ 0,1 ]
};
var presses = ConfigureIndicators(m, buttons);

var m2 = new Machine([false, false, false, true, false]);
var buttons2 = new int[][]
{
    [0,2,3,4],
    [2,3],
    [0,4],
    [0,1,2],
    [1,2,3,4]
};
var presses2 = ConfigureIndicators(m2, buttons2);

var m3 = new Machine([false, true, true, true, false, true]);
var buttons3 = new int[][]
{
    [0,1,2,3,4],
    [0,3,4],
    [0,1,2,4,5],
    [1,2]
};
var presses3 = ConfigureIndicators(m3, buttons3);

var total = presses.Length + presses2.Length + presses3.Length;
Console.WriteLine(total);
Console.ReadKey();

static int[][] ConfigureIndicators(Machine m, int[][] buttons)
{
    var turnOn = new List<int[][]>();

    var combinations = buttons.Combinations();
    foreach (var combo in combinations)
    {
        var tmp = combo.Aggregate(m.Off(), (machine, comb) => machine.Push(comb));
        if (m.Indicators.SequenceEqual(tmp.Indicators))
        {
            turnOn.Add(combo);
        }
    }

    return turnOn.MinBy(t => t.Length);
}

record Machine(bool[] Indicators)
{
    public Machine Off()
        => new Machine(new bool[Indicators.Length]);

    public Machine Push(int[] buttons)
    {
        var pushed = new bool[Indicators.Length];
        Array.Copy(Indicators, pushed, Indicators.Length);
        foreach (var button in buttons)
        {
            pushed[button] = !Indicators[button];
        }
        return new Machine(pushed);
    }

    public override string ToString()
        => $"[{string.Join("", Indicators.Select(i => i ? "#" : "."))}]";
}

internal static class Extensions
{
    public static IEnumerable<T[]> Combinations<T>(this IEnumerable<T> source)
    {
        if (null == source)
            throw new ArgumentNullException(nameof(source));

        T[] data = source.ToArray();

        return Enumerable
          .Range(1, 1 << (data.Length))
          .Select(index => data
             .Where((v, i) => (index & (1 << i)) != 0)
             .ToArray());
    }
}

And finally…et voilà! The factory lights up, and Day 10 is complete.

Get your copy of Street-Smart Coding here

Advent of Code Day 9: Finding the Largest Rectangle of Red Tiles

2025-12-15T00:00:00+00:00

On Day 9 of Advent of Code, we’re helping elves to redecorate the theater by rearranging the red tiles on the floor.

After yesterday’s struggle, this is an easy one when I consider every pair of points as the opposite corners of a rectangle to calculate its area. Like this,

record Rectangle(Position Left, Position Right)
{
    public int Area
        => (Math.Abs(Left.Y - Right.Y) + 1)
                * (Math.Abs(Left.X - Right.X) + 1);
}

Then, I reuse Pairs() from yesterday to find all rectangles. Next, I use LINQ’s MaxBy to find the largest one. Like this,

var largest = redTiles.Pairs()
    .Select(p => new Rectangle(p.First, p.Second))
    .MaxBy(r => r.Area);

With those two pieces, the puzzle is solved. Here’s my full solution,

var redTiles = new[]
{
    new Position(7,1),
    new Position(11,1),
    new Position(11,7),
    new Position(9,7),
    new Position(9,5),
    new Position(2,5),
    new Position(2,3),
    new Position(7,3),
};

var largest = redTiles.Pairs()
                    .Select(p => new Rectangle(p.First, p.Second))
                    .MaxBy(r => r.Area);

Console.WriteLine(largest);
Console.ReadKey();

record Position(int X, int Y);
record Rectangle(Position Left, Position Right)
{
    public int Area
        => (Math.Abs(Left.Y - Right.Y) + 1)
                * (Math.Abs(Left.X - Right.X) + 1);
}

internal static class Extensions
{
    public static IEnumerable<(T First, T Second)> Pairs<T>(this IEnumerable<T> self)
    {
        return self.SelectMany((fst, i) => self.Skip(i + 1).Select(snd => (fst, snd)));
    }
}

I deserved some rest from yesterday’s puzzle. Today, I can easily say: Et voilà!

Get your copy of Street-Smart Coding here

Advent of Code Day 8: Connecting Junction Boxes

2025-12-14T00:00:00+00:00

On Day 8 of Advent of Code, we’re helping elves with some decorations, so we’re connecting junction boxes.

Unlike the first 7 days, I cheated. Yes! This puzzle wasn’t fun anymre after spending a couple of hours to make the example work. In a moment of frustration, I went to Reddit for some help and I reworked my original solution.

First, I tried to create circuits as I visited pair of junction boxes. But, after getting some help from Reddit, every junction box is a 1-box circuit to then merge all the pairs.

Finding distances

To find the distance between all possibles pair of junction boxes, I borrowed the Pairs() method from Day 3.

To calculate the distance, I use the squared of the distance as a small optimization.

var distances = allBoxes.Pairs()
    .Select(p => (p.First, p.Second, Distance: Distance(p.First, p.Second)))
    .OrderBy(p => p.Distance);

static int Distance(JunctionBox p1, JunctionBox p2)
{
    var d2 = (p1.X - p2.X) * (p1.X - p2.X)
                + (p1.Y - p2.Y) * (p1.Y - p2.Y)
                + (p1.Z - p2.Z) * (p1.Z - p2.Z);
    return d2;
}

static class Extensions
{
    public static IEnumerable<(T First, T Second)> Pairs<T>(this IEnumerable<T> self)
    {
        return self.SelectMany((fst, i) => self.Skip(i + 1).Select(snd => (fst, snd)));
    }
}

Connecting boxes

A circuit is a wrapper around a HashSet with a method to merge two circuits.

record Circuit(HashSet<JunctionBox> Boxes)
{
    public Circuit(JunctionBox box)
        : this(new HashSet<JunctionBox>([box]))
    {
    }

    public bool Contains(JunctionBox box)
        => Boxes.Contains(box);

    public void Connect(Circuit circuit)
    {
        foreach (var box in circuit.Boxes)
        {
            Boxes.Add(box);
        }
    }
}

With the list of junction boxes by distance and a circuit, here’s the full solution,

var allBoxes = new[]
{
    new JunctionBox(162,817,812),
    new JunctionBox(57,618,57),
    new JunctionBox(906,360,560),
    new JunctionBox(592,479,940),
    new JunctionBox(352,342,300),
    new JunctionBox(466,668,158),
    new JunctionBox(542,29,236),
    new JunctionBox(431,825,988),
    new JunctionBox(739,650,466),
    new JunctionBox(52,470,668),
    new JunctionBox(216,146,977),
    new JunctionBox(819,987,18),
    new JunctionBox(117,168,530),
    new JunctionBox(805,96,715),
    new JunctionBox(346,949,466),
    new JunctionBox(970,615,88),
    new JunctionBox(941,993,340),
    new JunctionBox(862,61,35),
    new JunctionBox(984,92,344),
    new JunctionBox(425,690,689),
};

var circuits = allBoxes.Select(box => new Circuit(box)).ToList();

var distances = allBoxes.Pairs()
    .Select(p => (p.First, p.Second, Distance: Distance(p.First, p.Second)))
    .OrderBy(p => p.Distance);
foreach (var pair in distances.Take(1_000))
{
    var hasFirstBox = circuits.First(c => c.Contains(pair.First));
    var hasSecondBox = circuits.First(c => c.Contains(pair.Second));
    if (hasFirstBox != hasSecondBox)
    {
        hasFirstBox.Connect(hasSecondBox);
        circuits.Remove(hasSecondBox);
    }
}

foreach (var circuit in circuits.OrderBy(c => c.Boxes.Count).Take(3))
{
    Console.WriteLine(circuit.Boxes.Count);
}
Console.ReadKey();

static int Distance(JunctionBox p1, JunctionBox p2)
{
    var d2 = (p1.X - p2.X) * (p1.X - p2.X)
                + (p1.Y - p2.Y) * (p1.Y - p2.Y)
                + (p1.Z - p2.Z) * (p1.Z - p2.Z);
    return d2;
}

record Circuit(HashSet<JunctionBox> Boxes)
{
    public Circuit(JunctionBox box)
        : this(new HashSet<JunctionBox>([box]))
    {
    }

    public bool Contains(JunctionBox box)
        => Boxes.Contains(box);

    public void Connect(Circuit circuit)
    {
        foreach (var box in circuit.Boxes)
        {
            Boxes.Add(box);
        }
    }
}
record JunctionBox(int X, int Y, int Z)
{
    public override string ToString() => $"{X},{Y},{Z}";
}

static class Extensions
{
    public static IEnumerable<(T First, T Second)> Pairs<T>(this IEnumerable<T> self)
    {
        return self.SelectMany((fst, i) => self.Skip(i + 1).Select(snd => (fst, snd)));
    }
}

Et voilà!

Get your copy of Street-Smart Coding here

Advent of Code Day 7: Splitting Tachyon Beams

2025-12-13T00:00:00+00:00

On Day 7 of Advent of Code, we’re studying tachyon beams while we’re stuck in a teleporter.

I imagine this puzzle as a game where each iteration moves the beam until it hits the end of the manifold.

Moving a beam

A Beam is a list of positions in the manifold at a given iteration.

record Position(int X, int Y);
record Beam(IEnumerable<Position> Locations);

Here’s the method to move a beam,

static Beam Move(string[][] manifold, Beam beam)
{
    var newLocations = new HashSet<Position>();

    foreach (var current in beam.Locations)
    {
        var downward = manifold[current.X + 1][current.Y];
        if (downward == ".")
        {
            newLocations.Add(new Position(current.X + 1, current.Y));
        }
        else if (downward == "^")
        {
            newLocations.Add(new Position(current.X + 1, current.Y - 1));
            newLocations.Add(new Position(current.X + 1, current.Y + 1));
        }
    }

    return new Beam(newLocations);
}

After moving a beam, I need the entry position of a beam,

static Beam Start(string[][] manifold)
{
    for (int i = 0; i < manifold[0].Length; i++)
    {
        if (manifold[0][i] == "S")
        {
            return new Beam([new Position(0, i)]);
        }
    }

    return new Beam([]);
}

With those two methods, a beam enters and moves downward,

var start = Start(manifold);
var newPosition = Move(manifold, start);
newPosition = Move(manifold, newPosition);

All that’s left is to count splits and move the beam to the end.

Counting splits

Next, I add the number of splits to Beam and create HasReacheTheEnd().

Here’s my full solution,

var manifold = new string[][]
{
    [ ".", ".", ".", ".", ".", ".", ".", "S", ".", ".", ".", ".", ".", ".", "." ],
    [ ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", "." ],
    [ ".", ".", ".", ".", ".", ".", ".", "^", ".", ".", ".", ".", ".", ".", "." ],
    [ ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", "." ],
    [ ".", ".", ".", ".", ".", ".", "^", ".", "^", ".", ".", ".", ".", ".", "." ],
    [ ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", "." ],
    [ ".", ".", ".", ".", ".", "^", ".", "^", ".", "^", ".", ".", ".", ".", "." ],
    [ ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", "." ],
    [ ".", ".", ".", ".", "^", ".", "^", ".", ".", ".", "^", ".", ".", ".", "." ],
    [ ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", "." ],
    [ ".", ".", ".", "^", ".", "^", ".", ".", ".", "^", ".", "^", ".", ".", "." ],
    [ ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", "." ],
    [ ".", ".", "^", ".", ".", ".", "^", ".", ".", ".", ".", ".", "^", ".", "." ],
    [ ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", "." ],
    [ ".", "^", ".", "^", ".", "^", ".", "^", ".", "^", ".", ".", ".", "^", "." ],
    [ ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", "." ]
};

var beam = Start(manifold);
while (!HasReachedTheEnd(manifold, beam))
{
    beam = Move(manifold, beam);
}

Console.WriteLine(beam.SplitCount);
Console.ReadLine();

static Beam Start(string[][] manifold)
{
    for (int i = 0; i < manifold[0].Length; i++)
    {
        if (manifold[0][i] == "S")
        {
            return new Beam(0, [new Position(0, i)]);
        }
    }

    return new Beam(0, []);
}

static bool HasReachedTheEnd(string[][] manifold, Beam beam)
{
    var anyBeam = beam.Locations.First();
    return anyBeam.X >= manifold.Length - 1;
}

static Beam Move(string[][] manifold, Beam beam)
{
    var splits = 0;
    var newLocations = new HashSet<Position>();

    foreach (var current in beam.Locations)
    {
        var downward = manifold[current.X + 1][current.Y];
        if (downward == ".")
        {
            newLocations.Add(new Position(current.X + 1, current.Y));
        }
        else if (downward == "^")
        {
            splits++;

            newLocations.Add(new Position(current.X + 1, current.Y - 1));
            newLocations.Add(new Position(current.X + 1, current.Y + 1));
        }
    }

    return new Beam(beam.SplitCount + splits, newLocations);
}

record Position(int X, int Y);
record Beam(int SplitCount, IEnumerable<Position> Locations);

I thought a “tachyon” was a made-up word until I Googled it. TIL what a tachyon is. Win-win.

Et voilà!

Get your copy of Street-Smart Coding here

Friday Links: Becoming a senior dev, coding, and phones

2025-12-12T00:00:00+00:00

Hey, it’s been a busy week. I’ve been preparing my last book for publish on Amazon, so I didn’t read that much.

But I still want to share some interesting reads. Here are my top 3 most read posts from the quarter plus a funny weekend project.

#1. I always joke that I don’t know when “Senior” made it into my job title. But I know it was thanks to good mentors. Here are 5 lessons from one of my mentors (4min). I’ve been following lesson #1 since I met him…Well, not in the past week.

#2. What’s the first thing that comes to mind when you hear “get good at coding”? Younger me only thought about learning programming languages. But here are 7 unconventional ways to improve your coding skills (3min).

#3. I’d do a lot differently if I were a junior again. Here’s one lesson I wish I had known 10 years ago (3min). That would have made me a well-rounded coder.

#4. What if we could slam a phone after a boring Zoom call? That was the side project of someone who turned a rotary phone into a meeting handset (8min).

Speaking of coding, are you following the Advent of Code? I have. I missed a couple of days, but I’m catching up this weekend. Here’s my last solution: Advent of Code Day 6: Doing Cephalopods’ Math (3min).

See you next time,

Cesar

Advent of Code Day 6: Doing Cephalopods' Math

2025-12-11T00:00:00+00:00

On Day 6 of Advent of Code, we’re helping some cephalopods with their kids’ math homework…while they open a trash compactor.

First, I define a problem and function to solve it. A problem is an operation and some numbers.

static int Perform(Problem p)
    => p.Operation switch
    {
        Operation.Add => p.Numbers.Sum(),
        Operation.Multiply => p.Numbers.Aggregate((a, b) => a*b),
        _ => throw new NotImplementedException()
    };

abstract record Operation
{
    public record Add : Operation;
    public record Multiply : Operation;
}
record Problem(Operation Operation, IEnumerable<int> Numbers);

Cephalopods’ math is weird with operations and operands organized vertically, not horizontally. Parsing is the trick part: the input is a 2D array where each column is a problem. Numbers above and operator at the bottom.

I loop through the array of arrays column-wise. The last element becomes the operation, and the rest become the numbers,

static IEnumerable<Problem> Parse(string[][] problems)
{
    var parsedProblems = new List<Problem>();

    for (int j = 0; j < problems[0].Length; j++)
    {
        var numbers = Enumerable.Range(0, problems.Length - 1)
                                .Select(i => int.Parse(problems[i][j]))
                                .ToList();
        Operation op = problems[^1][j] == "+"
                            ? new Operation.Add()
                            : new Operation.Multiply();
        parsedProblems.Add(new Problem(op, numbers));
    }
    return parsedProblems;
}

With the parsing in place, Day 6 is almost done. Here’s my final solution,

var problems = new[]
{
    new[]{ "123", "328", "51", "64" },
    new[]{ "45", "64", "387", "23" },
    new[]{ "6", "98", "215", "314" },
    new[]{ "*", "+", "*", "+" }
};

var total = Parse(problems).Sum(Perform);
Console.WriteLine(total);
Console.ReadKey();

static IEnumerable<Problem> Parse(string[][] problems)
{
    var parsedProblems = new List<Problem>();

    for (int j = 0; j < problems[0].Length; j++)
    {
        var numbers = Enumerable.Range(0, problems.Length - 1)
                                .Select(i => int.Parse(problems[i][j]))
                                .ToList();
        Operation op = problems[^1][j] == "+"
                            ? new Operation.Add()
                            : new Operation.Multiply();
        parsedProblems.Add(new Problem(op, numbers));
    }
    return parsedProblems;
}

static int Perform(Problem p)
    => p.Operation switch
    {
        Operation.Add => p.Numbers.Sum(),
        Operation.Multiply => p.Numbers.Aggregate((a, b) => a*b),
        _ => throw new NotImplementedException()
    };

abstract record Operation
{
    public record Add : Operation;
    public record Multiply : Operation;
}
record Problem(Operation Operation, IEnumerable<int> Numbers);

Two one-off bugs got me this time, but I finally cracked it. The parsing part isn’t that functional in style, but “it works on my machine.” Et voilà!

Get your copy of Street-Smart Coding here

Advent of Code Day 5: Counting Fresh Ingredients

2025-12-10T00:00:00+00:00

On Day 5 of Advent of Code, we’re helping the elves to find which ingredients are fresh or spoiled.

To find if an ingredient is fresh, I create a FreshIngredientRange with a method IsFresh(),

record FreshIngredientRange(int IngredientId1, int IngredientId2)
{
    public bool IsFresh(int productId)
        => productId >= IngredientId1 && productId <= IngredientId2;
}

Then, to count all the fresh ingredients, I write a method that receives all product ranges and all candidate products. A single LINQ query will do the counting,

static int CountFreshIngredients(
    IEnumerable<FreshIngredientRange> ranges,
	IEnumerable<int> productIds)
        => productIds.Count(productId => ranges.Any(r => r.IsFresh(productId)));

Here’s my final solution,

var ranges = new FreshIngredientRange[]
{
    new FreshIngredientRange(3, 5),
    new FreshIngredientRange(10, 14),
    new FreshIngredientRange(16, 20),
    new FreshIngredientRange(12, 18)
};

var productIds = new int[] { 1, 5, 8, 11, 17, 32 };

var count = CountFreshIngredients(ranges, productIds);
Console.WriteLine(count);
Console.ReadKey();

static int CountFreshIngredients(IEnumerable<FreshIngredientRange> ranges, IEnumerable<int> productIds)
    => productIds.Count(productId => ranges.Any(r => r.IsFresh(productId)));

record FreshIngredientRange(int IngredientId1, int IngredientId2)
{
    public bool IsFresh(int productId)
        => productId >= IngredientId1 && productId <= IngredientId2;
}

That’s an easy one with LINQ. Just one single line. Et voilà!

Get your copy of Street-Smart Coding here

A Quick Lesson After A Long Debugging Session (And Almost Pulling My Hair Off)

2025-12-09T00:00:00+00:00

I almost pulled my hair off.

I debugged an issue in a Blazor grid for over two half days. I followed my own advice from Street-Smart Coding:

Isolated the problem
Removed all irrelevant parts
Discussed it with a rubber duck

Just to keep seeing the same error message: TypeError: Cannot read properties of null (reading ‘removeChild’).

StackOverflow says it was Blazor trying to remove an orphan element. So I removed everything except for my grid and wrapped it around a div.

Same mistake.

After questioning my career choices and almost removing “Senior” from my title, I asked for help.

My coworker pulled my branch and reproduced the issue. To my surprise, the issue wasn’t only in my grid. It was in all other grids, all over the app. It was an issue in the Blazor component itself we were using for grids. Arrggg!

Sometimes you just need to ask for help earlier. Like one of my mentors told me and the team, “you have nothing to prove. Ask for help.” And that’s something I cover on Chapter #2 of Street-Smart Coding.

Two Inspiring Business Lessons From Repairing a Blender (And Why I Almost Quit Online Hustles)

2025-12-08T00:00:00+00:00

My blender broke. Nothing unusual, until I took it to the only repair shop nearby.

Like any repair shop, it was greasy and hot, with shelves full of small parts… and crowded. It was so packed with people carrying blenders and fans, that I had to wait for a technician.

While waiting for a receipt I learned two business lessons that make me want to start a blender shop too:

1. Forget about fancy businesses. Go with a boring one

Fixing blenders is boring.

You don’t dream about going to business school to start a blender-repair shop. But it’s recession‑proof and even resistant to AI “disruption.” I knew it was a good business immediately.

Almost every house in my town has a blender. With a good location and an attractive name, like “BlenderCenter,” this place won’t run out of potential clients ever.

While I waited, an old lady offered coffee and cold juice to everyone in line. A small gesture, but great customer service. Not like buying a mattress the other day. No wonder this shop never runs out of clients.

Forget about crypto, NFTs, and dropshipping. Go with a boring business with clients.

2. Stick with simple, reliable tools

When I got to the cashier for my receipt, I was surprised.

I looked into the lady’s computer. I expected a fancy point-of-sale software with bells and whistles. Nope!

The entire place runs with Microsoft Access. That’s a simple database tool. I could notice it: the window, bars, buttons, and the look and feel of the app. But, it registered me as a new user, created a new order, and printed a receipt… With Access. I remember learning to build forms and databases with Access in high school.

New business owners are tempted to go with the shiniest tools to start a business. Being a coder by day, you don’t know how many friends and acquaintances have asked me to quote for custom software before starting their business. Honestly, I’d just tell them: start with Access.

Prefer simple, reliable tools to run your business.

I never imagined a blender-repair shop could be so inspiring and full of lessons. Meanwhile, I’m still trying to make money online. Maybe I should ditch the online hustles and start a blender-repair shop instead. LOL!

Advent of Code Day 4: Counting Rolls of Paper

2025-12-07T00:00:00+00:00

On Day 4 of Advent of Code, we’re finding which rolls of paper forklifts can access, so we can get further into the North Pole base.

I model the diagram of rolls of paper as a boolean grid. A cell is true if it has a roll.

Finding adjacent positions

To find the adjacent positions, I add -1, 0, 1 to each coordinate, with proper bounds checking.

Here’s my FindAdjacentPositions():

static IEnumerable<bool> FindAdjacentPositions(bool[][] rollsOfPaper, int i, int j)
{
    for (int row = -1; row <= 1; row++)
    {
        for (int col = -1; col <= 1; col++)
        {
            var x = i + row;
            var y = j + col;
            if (x >= 0 && x < rollsOfPaper.Length
                    && y >= 0 && y < rollsOfPaper[x].Length)
            {
                if (x == i && y == j)
                {
                    continue;
                }

                var cell = rollsOfPaper[x][y];
                yield return cell;
            }
        }
    }
}

After that, the next step is filtering and counting the rolls with less than 4 neighbor rolls.

Filtering and counting

Here’s my final solution,

var rollsOfPaper = new bool[][]
{
    [ false, false, true, true, false, true, true, true, true, false,  ],
    [ true, true, true, false, true, false, true, false, true, true,  ],
    [ true, true, true, true, true, false, true, false, true, true,  ],
    [ true, false, true, true, true, true, false, false, true, false,  ],
    [ true, true, false, true, true, true, true, false, true, true,  ],
    [ false, true, true, true, true, true, true, true, false, true,  ],
    [ false, true, false, true, false, true, false, true, true, true,  ],
    [ true, false, true, true, true, false, true, true, true, true,  ],
    [ false, true, true, true, true, true, true, true, true, false,  ],
    [ true, false, true, false, true, true, true, false, true, false,  ],
};

var count = 0;

for (int i = 0; i < rollsOfPaper.Length; i++)
{
    for (int j = 0; j < rollsOfPaper[i].Length; j++)
    {
        if (rollsOfPaper[i][j])
        {
            var adjacents = FindAdjacentPositions(rollsOfPaper, i, j);
            if (adjacents.Count(roll => roll) < 4)
            {
                count++;
            }
        }
    }
}

Console.WriteLine(count);
Console.ReadKey();

static IEnumerable<bool> FindAdjacentPositions(bool[][] rollsOfPaper, int i, int j)
{
    for (int row = -1; row <= 1; row++)
    {
        for (int col = -1; col <= 1; col++)
        {
            var x = i + row;
            var y = j + col;
            if (x >= 0 && x < rollsOfPaper.Length
                    && y >= 0 && y < rollsOfPaper[x].Length)
            {
                if (x == i && y == j)
                {
                    continue;
                }

                var cell = rollsOfPaper[x][y];
                yield return cell;
            }
        }
    }
}

My goal is to use “functionalish” solutions, but two loops and an accumulator were so easy that I stuck with them.

Et voilà!

Get your copy of Street-Smart Coding here

My 400 Daily Posts Reflection

2025-12-06T00:00:00+00:00

Writing 400 daily posts gave me momentum as a writer.

The first 100 posts were training to find ideas. The next 100 proved I wouldn’t run out of ideas. The next 100 tested my discipline, I wrote even when tired. This last 100 gave me trust to keep going.

In the last 3 months, I released a book, Street-Smart Coding and I shared the behind-the-scenes:

Promoting my book won me my first hater, a milestone in the writing journey.

But beyond criticism, writing daily gave me something more lasting: “the time capsule” effect.

And after many posts, I can see what I was learning each day years ago. I even started to write some “on this day” posts. Here’s the last one I wrote.

That’s a gift for future generations: reading what grandpa wrote 20 years ago.

Here are some of the most-read posts from the last 100 days:

Here are my 100-post, 200-post, and 300-post. Next milestone to celebrate: 500 daily posts.

Friday Links: Confessions, manager pendulum, and the junior hiring crisis

2025-12-05T00:00:00+00:00

Hey! Here are 3 reads (plus a funny bonus) I found interesting this week.

#1. After being afraid of sharing them, here are the confessions of an uncensored coder (10min). I agree, we don’t have to learn everything about everything. And I have to confess I don’t fully understand Blazor, in spite of working with it for almost a year.

#2. Most companies only offer two tracks for coders. You either stay as an Individual Contributor or join the Management side. Switching between the two is called: “manager pendulum.” But AI might be breaking the pendulum (10min), creating hybrid roles. Or maybe it’s just an excuse to get rid of the role and the compensation?

#3. It’s easier than ever to start coding. But it’s getting harder and harder to break into the market as a junior coder. We’re in a junior hiring crisis (10min). AI seems to have a lot with it…And just in the past few weeks, someone in the same situation reached out on LinkedIn asking for advice. I didn’t have much to say.

Bonus: What if we let AI replace our bosses? Here’s replaceyourboss.ai. The funniest line I got: “Let’s cut the single-use cups but keep the private jet for strategic mobility.”

On my blog, this past week, I shared about 4 AI issues I’ve collected (2min) and 4 lessons I learned while fighting next to my mom with a chronic disease (3min). Feel free to skip that last one if you only want to read about coding. I won’t get mad.

(Bzzz…Radio voice) This email was brought to you by… My latest book, Street-Smart Coding: 30 lessons to help you code like a pro, from Googling to clear communication. It’s the roadmap I wish I had moving from junior to senior and the one I hope helps you too.

See you next time,

Cesar

Advent of Code Day 3: Calculating the Joltage of Batteries

2025-12-04T00:00:00+00:00

On Day 3 of Advent of Code, we’re finding the joltage of a bank of batteries to power an escalator.

Elevators are out of service and the escalator needs the batteries with the higher joltage.

Finding pairs of batteries

I use brute force to find all battery pairs.

Two for loops didn’t feel old-schoool. So I borrow a LINQ query from this StackOverflow answer.

static class Extensions
{
    public static IEnumerable<(T First, T Second)> Pairs<T>(this IEnumerable<T> self)
    {
        return self.SelectMany((fst, i) => self.Skip(i + 1).Select(snd => (fst, snd)));
    }
}

Calculating the joltage

Once we have the pairs, I need two methods to calculate joltage: for a pair and for a bank.

static int FindJoltage(Bank bank)
    => bank.Batteries.Pairs().Select(FindJoltageOfPair).Max();

static int FindJoltageOfPair((int Battery1, int Battery2) pair)
    => pair.Battery1 * 10 + pair.Battery2;

Here’s my full solution:

var allBanks = new List<Bank>
{
    new Bank([ 9, 8, 7, 6, 5, 4, 3, 2, 1, 1, 1, 1, 1, 1, 1 ]),
    new Bank([ 8, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 9 ]),
    new Bank([ 2, 3, 4, 2, 3, 4, 2, 3, 4, 2, 3, 4, 2, 7, 8 ]),
    new Bank([ 8, 1, 8, 1, 8, 1, 9, 1, 1, 1, 1, 2, 1, 1, 1 ])
};
var totalJoltage = allBanks.Select(FindJoltage).Sum();
Console.WriteLine(totalJoltage);
Console.ReadLine();

static int FindJoltage(Bank bank)
    => bank.Batteries.Pairs().Select(FindJoltageOfPair).Max();

static int FindJoltageOfPair((int Battery1, int Battery2) pair)
    => pair.Battery1 * 10 + pair.Battery2;

record Bank(IEnumerable<int> Batteries);

static class Extensions
{
    public static IEnumerable<(T First, T Second)> Pairs<T>(this IEnumerable<T> self)
    {
        return self.SelectMany((fst, i) => self.Skip(i + 1).Select(snd => (fst, snd)));
    }
}

Et voilà!

Get your copy of Street-Smart Coding here

Advent of Code Day 2: Finding Invalid Product IDs

2025-12-03T00:00:00+00:00

On Day 2 of Advent of Code, we’re helping the Elves find invalid IDs.

I considered a string-based solution, but that felt like cheating. So I tried a “numeric” one instead.

Let’s start with a bottom-up approach.

Finding if a product ID is invalid

First, I count the digits of a number, then split the number in half using powers of 10.

I borrowed this StackOverflow answer to count digits.

And since a product ID is invalid if it has a sequence repeated twice, product IDs with an odd number of digits are valid.

static bool IsAnInvalidId(int n)
    => HasSequenceRepeatedTwice(n);

static bool HasSequenceRepeatedTwice(int n)
{
    var digitCount = (int)(Math.Log10(n) + 1);
    if (digitCount % 2 != 0)
    {
        return false;
    }

    var firstHalf = n / (int)Math.Pow(10, digitCount / 2);
    var secondHalf = n % (int)Math.Pow(10, digitCount / 2);

    return firstHalf == secondHalf;
}

Once we check for repeated sequences, the only task left is counting IDs in each range.

Counting invalid product IDs

I’m creating a function to enumerate a range, Enumerate(), and a LINQ query to find and count invalid IDs.

Here’s my full solution:

var ranges = new[]
{
    new Range(11, 22),
    new Range(95, 115),
    new Range(998, 1012),
    new Range(1188511880, 1188511890),
    new Range(222220, 222224),
    new Range(1698522, 1698528),
    new Range(446443, 446449),
    new Range(38593856, 38593862),
    new Range(565653, 565659),
    new Range(824824821, 824824827),
    new Range(2121212118, 2121212124),
};

var sum = ranges.SelectMany(Enumerate)
                .Where(IsAnInvalidId)
                .Sum();
Console.WriteLine(sum);
Console.ReadLine();

static IEnumerable<int> Enumerate(Range r)
    => Enumerable.Range(r.Left, r.Right - r.Left + 1);

static bool IsAnInvalidId(int n)
    => HasSequenceRepeatedTwice(n);

static bool HasSequenceRepeatedTwice(int n)
{
    var digitCount = (int)(Math.Log10(n) + 1);
    if (digitCount % 2 != 0)
    {
        return false;
    }

    var firstHalf = n / (int)Math.Pow(10, digitCount / 2);
    var secondHalf = n % (int)Math.Pow(10, digitCount / 2);

    return firstHalf == secondHalf;
}

record Range(int Left, int Right);

Et voilà!

Get your copy of Street-Smart Coding here

Advent of Code Day 1: Unlocking the North Pole

2025-12-02T00:00:00+00:00

Back in 2022, I challenged myself with a different kind of Advent project.

Instead of running an Advent of Code, I ran an Advent of Posts. I wrote 22 posts in the days before Christmas. I missed two days but I declared the mission complete.

This year, I’m following the Advent of Code. I’d like to challenge myself to write “functionalish” solutions.

Here are the instructions for Day 1 and my solution:

Opening the secret entrance to the North Pole

Since there are only two rotations: left and right, I’m creating a discriminated union-like hierarchy. And I’m writing a separate class for the dial itself.

abstract record Rotation
{
    public record Left(int Distance) : Rotation;
    public record Right(int Distance) : Rotation;
}

record Dial(int Position)
{
    public Dial Turn(Rotation rotation)
    {
        return rotation switch
        {
            Rotation.Left f => this with { Position = (Position - f.Distance)%100 },
            Rotation.Right r => this with { Position = (Position + r.Distance)%100 },
            _ => throw new NotImplementedException(),
        };
    }
}

So far, I could do:

var d = new Dial(11);
d.Turn(new Rotation.Right(8)).Turn(new Rotation.Left(19))
// [Dial { Position = 0 }]

I have to confess, figuring out the modulus operation to move the dial took me a while.

With the dial rotating, the only missing piece is applying rotations and counting zeros,

static class Password
{
    public static int Find(Dial d, IEnumerable<Rotation> rotations)
    {
        var state = rotations.Aggregate((Dial: d, Password: 0), (state, rotation) =>
        {
            var dial = state.Dial.Turn(rotation);
            var pwd = dial.Position == 0 ? state.Password + 1: state.Password;
            return (dial, pwd);
        });
        return state.Password;
    }
}

I’m using LINQ Aggregate method to turn the dial and count the zeros.

That works, but Copilot and others’ solutions showed me a cleaner approach: separating moving the dial and counting with Scan(),

static class Password
{
    public static int Find(Dial d, IEnumerable<Rotation> rotations)
    {
        return rotations.Scan(d, (dial, rotation) => dial.Turn(rotation))
                        .Count(d => d.Position == 0);
    }

    public static IEnumerable<TAccumulate> Scan<TSource, TAccumulate>(
        this IEnumerable<TSource> source,
        TAccumulate seed,
        Func<TAccumulate, TSource, TAccumulate> func)
    {
        var acc = seed;
        yield return acc;
        foreach (var item in source)
        {
            acc = func(acc, item);
            yield return acc;
        }
    }
}

And here’s the full solution:

var dial = new Dial(50);
var rotations = new Rotation[]
{
    new Rotation.Left(68),
    new Rotation.Left(30),
    new Rotation.Right(48),
    new Rotation.Left(5),
    new Rotation.Right(60),
    new Rotation.Left(55),
    new Rotation.Left(1),
    new Rotation.Left(99),
    new Rotation.Right(14),
    new Rotation.Left(82)
};
var pwd = Password.Find(dial, rotations);
Console.WriteLine(pwd);
Console.ReadLine();

abstract record Rotation
{
    public record Left(int Distance) : Rotation;
    public record Right(int Distance) : Rotation;
}

record Dial(int Position)
{
    public Dial Turn(Rotation rotation)
    {
        return rotation switch
        {
            Rotation.Left f => this with { Position = (Position - f.Distance)%100 },
            Rotation.Right r => this with { Position = (Position + r.Distance)%100 },
            _ => throw new NotImplementedException(),
        };
    }
}

static class Password
{
    public static int Find(Dial d, IEnumerable<Rotation> rotations)
    {
        return rotations.Scan(d, (dial, rotation) => dial.Turn(rotation))
                        .Count(d => d.Position == 0);
    }

    public static IEnumerable<TAccumulate> Scan<TSource, TAccumulate>(
        this IEnumerable<TSource> source,
        TAccumulate seed,
        Func<TAccumulate, TSource, TAccumulate> func)
    {
        var acc = seed;
        yield return acc;
        foreach (var item in source)
        {
            acc = func(acc, item);
            yield return acc;
        }
    }
}

Et voilà!

Get your copy of Street-Smart Coding here

Here's What's Wrong with Too Much AI

2025-12-01T00:00:00+00:00

I sit somewhere in the middle of the AI hype cycle. Not a hater nor a fanatic.

I’ve been trying to make sense of AI by documenting my experiences and reacting to others.

Here are 4 issues I’ve found with using AI too much:

#1. It makes us lazier than usual. It’s tempting to go straight to a chat for a quick, unreliable answer. That’s the real danger.

#2. It steals the joy of figuring out problems. No more aha moments or happy dances. Just like asking someone to chew our food to be more productive.

#3. It makes you feel you’re cheating. Copy-pasting without understanding has always been cheating, even in the days of forums and StackOverflow.

#4. It doesn’t let you build mental models to solve problems. It’s like asking someone else to go to the gym for us, then wondering why our muscles are still weak.

The Only Goal That Matters for Every New Digital Writer

2025-11-30T00:00:00+00:00

My first blog post was a word vomit.

I wrote long sentences and paragraphs. I dumped a bunch of words on a page. That was what I thought writing was. I only knew fiction writers who described every detail of a room in a novel. I didn’t know writing for the Internet was a different game.

That’s the mistake of every new writer.

Today, while reading a Hacker News submission about how cringe-worthy LinkedIn posts can be, I found this comment that captures this problem:

The highest level of cringe you can feel is when you see people you know well in real life post on LinkedIn. The contrast between the way they speak in real life and on LinkedIn is often immense, you don’t feel that level of contrast with random internet strangers.

“I’m pleased to announce…”

“I’m excited to share…”

“Dear LinkedIn network:”

You wouldn’t say those words in real life. So why use them anywhere online? To impress? To sound corporate?

If you’re writing online, the real goal isn’t to sound like a “real” writer. There’s no such thing as real writing, by the way. Your goal is to make readers hear your voice.

Record your voice or write inside WhatsApp. Let your true voice speak. That’s the only goal that matters.

Four Lessons I Learned While Standing By My Mom's Battle With Chronic Disease

2025-11-29T00:00:00+00:00

Three months ago, she left after fighting chronic kidney disease for over five years.

One day, her kidneys collapsed. Her body was giving clues of a real issue: swollen belly, dizziness, and vomiting. Her body was full of toxins her kidneys could no longer filter. She had to stay at an ICU for a couple of days to feel right again.

In five years, we visited hospitals over a dozen times. And you know you’ve been to hospitals often when doctors recognize your name.

ERs, dialysis centers, and checkups became routine until God, Life, or the Universe decided it was time for her to rest.

This whole experience taught me lessons I will never forget:

#1. Kidneys DO matter.

Every organ is important. They’re there for a reason, right?

But kidneys don’t get the same attention and care, as the heart or lungs for example, until it’s too late. We knew they were important when we had to take our mom to the ER for the first time.

#2. There won’t be a perfect moment ever.

We had plenty of plans together. Plans we won’t do now.

We bought jackets, got vaccines, and even paid for her passport to visit Barcelona. But we delayed our dream trip. “Next month,” “after the next checkup…” We had plenty of opportunities, but the perfect time never came.

Don’t delay your plans or goals. Set a date and do them.

There’s no perfect moment for anything.

#3. Fight for your dreams.

My mom had one dream since she was young: have a family and kids.

She turned down graduate school to raise my sister and me. She chose to stay at home instead of chasing the corporate world. Being a housewife is one of the busiest, least rewarded jobs.

But she made her dream come true. She raised two kids. She never missed any of our childhood moments. Her family was her treasure.

That only made me fight for my own dreams to make her feel proud.

#4. You’re what you put into your body.

My mom had a strict diet: low potassium, low sodium, and high protein.

To support her, my sister and I decided to start the diet with her. The sugar jar disappeared from our kitchen. Sodas and processed foods were gone. Deep-fried food was a luxury every once in a while. Those small changes helped us lose weight, feel energized, and reduce belly fat.

After five years, her diet became so ingrained in the family that sugar, sodas, and processed foods are gone from our table forever.

It might sound like a cliché. But you never know when it’s going to be the last day with someone you love. Say “I love you.” Make that phone call. Listen. Be present. That’s how you build memories that will last forever.

Friday Links: Estimates, being senior, and AI failures

2025-11-28T00:00:00+00:00

Here are 3 links I found interesting this week:

#1. This week, a coworker shared an Instagram reel (~1min) about what coding really looks like. The girl in the video needed to finish a 1 line-of-code change but still needed meetings, estimates, and tickets. It sparked a discussion about estimates and these 5 laws of estimates (10min) summarized the discussion.

#2. Being senior means asking the right questions and knowing when to stop optimizing, like avoiding pointless abstractions. But here’s another take on what makes you senior (5min). It’s not LeetCode, years of experience, or a long list of tools.

#3. Every time you find another headline promising the AI takeover, here’s a list of AI failures (10min) when coding. The most epic? Replit agent deleting a production database.

Also on my blog this past week, I shared about the real definition of legacy code (3min).

Before I wrap up, here’s something that helped me level up my SQL Server skills: Brent Ozar’s SQL courses. They took me from writing server-crashing queries to being a confident SQL Server developer.

This month, Brent’s running a Black Friday sale: the lowest prices all year. You can grab the Fundamentals Bundle (10 courses, 40+ hours of video) and save $300.

See you next time,

Cesar

Two Ways to Think of AI Without Outsourcing Your Mind

2025-11-27T00:00:00+00:00

#1. AI is a powerful calculator in math class

In school, you only use a calculator after years of doing arithmetic by hand.

Even with a calculator, you can’t simply enter an entire problem or equation to get an answer. You still work through the steps before speeding up the answer. Use AI the same way.

Build skills, then leverage AI.

#2. AI is like an assistant nurse in an operating room

A surgery isn’t a task for a single person.

In a surgery, there’s a nurse, an anesthesiologist, and a surgeon. I only know from binge-watching House M.D., but operating rooms are full of specialists.

The nurse helps to monitor the patient. The anesthesiologist keeps the patient asleep. But the surgeon coordinates the procedure and is always in charge. The surgeon doesn’t tell the nurse, “Act as an expert surgeon and run the procedure. Check your steps and don’t make mistakes.”

You’re the surgeon and AI is your supporting team. That’s why I use AI outside in a browser tab when coding.

Like calculators and operating rooms, coding with AI requires real skills first. I wrote Street-Smart Coding: 30 Ways to Get Better at Coding to help you build them. Because you need more than syntax to stand out.

Grab your copy of Street-Smart Coding here. That’s the roadmap I wish I had when I was starting out.

The Real Definition of Legacy Code (After 10 Years in the Trenches)

2025-11-26T00:00:00+00:00

When you hear “legacy code,” what’s the first thing that comes to mind?

If you’re a .NET developer, maybe that’s an old ASP.NET WebForms application written in VB.NET and powered by stored procedures.

And if you’re familiar with Working Effectively with Legacy Code, you would say “Code without tests.”

But after 10 years with complex codebases, I challenge those assumptions.

What legacy code really means

Legacy code is simply code we don’t understand and want to stay away from.

A codebase doesn’t need dead languages or outdated frameworks to fit that definition.

Of course we don’t understand a codebase when we find it for the first time. But the real issue is the cognitive load we need to work with it.

With that definition, code with tests can still be legacy code.

I’ve seen it! At a past job, I worked in a hotel management solution. There were two teams working on different parts of the application. One team used the shiniest and brightest: ASP.NET Core, Entity Framework Core, you name it. But still nobody else touched their code. It was too messy.

Did it have tests? Sure! And 100% coverage to make upper management happy. But those tests gave no confidence to refactor. They only exercised mocks.

Legacy code boils down to context and understanding.

That’s why it’s so tempting to rewrite legacy code. We have to rebuild all the shared knowledge when writing the new version.

As a junior coder, I thought I’d only work on shiny projects with the latest tools. In reality, every job has involved legacy system. And each one taught me valuable skills that I included in my book, Street-Smart Coding: 30 Ways to Get Better at Coding.

Grab your copy of Street-Smart Coding here. It’s the roadmap I wish I had moving from junior to senior, and the one I hope guides you too.

Two Steps I Missed When Writing Street-Smart Coding

2025-11-25T00:00:00+00:00

Ever had that moment after turning in an exam when all the answers suddenly hit you? Too late!

OK, something similar has happened after launching Street-Smart Coding, my latest book.

I’ve realized I missed two key actions before writing and launching it:

#1. Write a one-liner.

Writing a book is hard. But summarizing it into one line is harder.

That one-liner makes marketing easier.

This week I discovered Jose Saramago’s The Stone Raft. Its one-liner? “One day, quite inexplicably, the Iberian Peninsula simply breaks free from the European continent and begins to drift as if it were a sort of stone raft.” Boom! Who doesn’t want to read the book after that?

That’s a fiction book. But the principle applies to non-fiction too.

#2. Follow the “same but different” framework.

Salwa Emerson, an author and ghostwriter, shared the “same but different” framework in a LinkedIn post.

The goal is to answer, “My book is the same as <insert book>, but different because <reason>.”

Again, this comes from traditional publishing, where books are placed next to hits. Hits show there’s market demand for the topic. But we can follow it for non-fiction too.

And applied to my book: Street-Smart Coding is like The Pragmatic Programmer but different because it covers soft, unexpected skills in a choose-your-own-adventure style.

A Free Headline Masterclass for a Writer Struggling to Get Reads

2025-11-24T00:00:00+00:00

After 600+ blog posts, I’ve learned one big lesson:

Bad headline = no readers.

No matter how much you polish your words, if the headline doesn’t grab attention, readers won’t open your posts.

It’s almost always the headline

That’s the lesson I’d give to Abhishek, a new writer I found on Medium.

I found a post where he analyzes his top 10 posts.

Let’s compare the best and worst headlines.

His best performing:

“How I Got My First 100 Followers in Just 15 Days”
“Earn $10/Hour: Top 5 Websites that Pay”

And his least performing:

“The Ancient Wisdom Nobody Talks About”
“10 Relationship Lessons from an Ancient Love Story”

Which headlines make you want to read more? Which one would you open? The ones in the first group, right?

The least performing failed to capture attention. They don’t follow the 3-ingredient headline formula I learned from a top Medium writer with millions of monthly reads.

The 3-ingredient secret formula for headlines that make you stop scrolling

Want your headline make readers stop scrolling? Follow POC.

Every headline should have a POC:

One promise
One outcome
One curiosity factor

Aim for at least the first two to have a decent headline.

Let’s go over the headline of the first least performing post:

“The Ancient Wisdom Nobody Talks About”

What’s the promise? A piece of wisdom. To achieve what? Dunno. Curiosity factor? “Nobody talks about”

That headline fails to promise something. A piece of wisdom for what? To have a happy marriage? To have 6-pack abs? To make more money?

People skip vague headlines and move on the next post in the feed. “Next one, please!”

Now, what do the headlines of the top performing posts have in common?

A clear outcome! “Earn $10/hour” and “get 100 followers in just 15 days.”

Both top performing posts talk about money. And people love that. Analytics might suggest he continue writing about money. But writing about things we don’t care is draining.

And like Seth Godin once said in a interview: if we listen to the data, we might end up showing our feet in a platform for fans. Wink! Wink! OK, I’m paraphrasing to make this post suitable for all audiences.

Lesson to take home? No matter how brilliant your post is, without a strong POC headline, nobody will read it.

Now I See Why Translators Are Panicking Over AI (Should Coders Panic Too?)

2025-11-23T00:00:00+00:00

Last year, I met a young translator reinventing herself.

She studied Translation for five years at a local university. We met online by commenting and engaging on each other’s LinkedIn posts. When we met, she was looking for another way to make money. Her agency cut down her rates and couldn’t find as many gigs as before.

Who to blame? AI.

AI isn’t disappointing at translation. But it doesn’t score A+

Her story came to mind when I started my own translation project, and I quickly understood why she was looking for another job.

Recently, I’ve been translating Street-Smart Coding to Spanish. As a native Spanish speaker, I could have done it easily myself.

But to make it faster, I used Copilot with a simple prompt. I specified a tone, voice, and style. Latin American conjugations and vocabulary instead of Spaniard ones, for example.

I was surprised by the results.

Copilot translated chapters with almost no fixes. Of course, there were places where the phrasing made it clear the text was machine-generated.

In English, we say “wear all hats” when someone has to do multiple tasks alone. Copilot translated word by word. The same expression in Spanish (“usar todos los sombreros”) makes no sense at all.

Copilot struggled with coding terms like “parser combinators.” In Spanish, we use a completely different term. Direct translation doesn’t work either.

That’s when I jumped in. But Copilot handled most of the job in just a couple of work sessions.

What if it isn’t only translation, but coding too?

This made me rethink one of the lines I heard the other day. “AI won’t take your job. It will change your job description.”

AI may already be turning translators into proofreaders. Coders could be next. Maybe the world won’t need as many coders, and coding may no longer mean typing symbols anymore. Who knows?

In any case, I predicted AI won’t take our jobs by 2034. Let’s see if I was right. In the meantime, I’d like to pick a DIY skill and double down on my creative skills, just in case. And I’m still learning foreign languages just for fun.

Let’s revisit this in 10 years and see how right or wrong I was.

Four Hard Truths No One Told Me About Launching My First Book

2025-11-22T00:00:00+00:00

Last month, I launched Street-Smart Coding, my first “official” book. It felt exciting and terrifying.

I had already written books, but I didn’t call them that. I thought only traditionally published works counted. And I didn’t know about writing mini-books. I had to change my mind about the concept of a book.

Here are 4 realizations I’ve had after launching it:

#1. The real work starts when you write the last words of your first draft. Editing, designing, launching, and promoting, that’s 80% of the work after the draft.

#2. Once your book is out, the game is in your mind. Waking up to see sales notifications is so satisfying. But silence is draining. I kept refreshing the sales dashboard, asking: “Why isn’t it selling? Is it me, the sales page, or the price?” The inner voice speaks louder than your wins.

The other day, Ryan Holiday, a New York Times best-selling author, shared that as soon as he finishes a book, he focuses on what he can control: working on the next. Now I see why.

#3. It’s easy to fall into the comparison trap online. These days, Gregory Orosz, the guy behind The Pragmatic Engineer, shared an update on his book The Software Engineer’s Guidebook after one year of launch. He shared sales figures. My first thought: I’m far from those numbers. But he admitted that his book is an outlier. Comparison is the thief of joy.

#4. If someone outside your circle buys your book, it’s already a win. That’s a line I found the other day scrolling on r/writing. It’s an anchor to put our feet back on the ground. By that definition, my book is already a success. And I already passed the $1 test.

Friday Links: Single-letter names, Windows 11, and optimization

2025-11-21T00:00:00+00:00

Hey there.

Here are 4 links I thought were worth sharing this week:

#1. This week, another major Internet outage. This time at Cloudflare. It raises the question: do we really need Cloudflare? (2min).

#2. Maybe it’s time to migrate to GNU/Linux. Because Windows 11 is adding an AI agent (8min) with access to personal folders.

#3. Imagine all the trouble you’ll face online if you had a single-letter name (6min). Airlines won’t sell you a ticket, and another name won’t match your passport. Keep this in mind next time you’re working on validating web forms.

#4. Faster code isn’t always better. Working at a startup makes you optimize your code for different things (2min).

And in case you missed it, I wrote on my blog about some hard truths about coding they don’t teach you (2min) and the skill that took my career further than anything else (2min).

(Bzzz…Radio voice) This email was brought to you by… Street-Smart Coding: 30 lessons to help you code like a pro, from Googling to clear communication. It’s the roadmap I wish I had moving from junior to senior and the one I hope helps you too.

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.

Hard Truths About Coding They Don't Teach You (Part 2)

2025-11-20T00:00:00+00:00

I was about to start a new list from scratch. But I remembered I already wrote about some hard truths about coding.

Here are five more truths:

#1. Most of your day will be in meetings, not coding.

#2. You won’t be building systems from scratch. Most of the time, you’ll be maintaining and rewriting legacy systems.

#3. Communication skills, not more languages, will take you further. Just asking the right questions will make you stand out.

#4. You will have to learn a lot of subjects. Don’t try to learn them all at once. Get your feet wet in many areas, then stick to a few. The learning phase never ends.

#5. At some point, you’ll realize end users and business owners don’t care about code. It’s a tough lesson. You won’t like it, but it changes how you see coding.

Junior me focused on mastering syntax and forgot about problem-solving, communication, and collaboration. That’s why I wrote the book I wish I had on day one, Street-Smart Coding: 30 Ways to Get Better at Coding. Because coding is more than syntax and typing symbols fast.

Get your copy of Street-Smart Coding here

The Skill That Took My Career Further Than Anything Else

2025-11-19T00:00:00+00:00

As a junior coder, I made the mistake of only focusing on mastering syntax.

I thought we were artists writing code to frame in a museum. But we write code to solve problems. Even the code you write for fun solves a problem: boredom and curiosity.

If you don’t experience your code firsthand, put yourself into your end user’s shoes. Think about their problem, why they’d pay, and how your code solves it.

A sense of curiosity, desire to learn, and inspiring mentors helped me grow. But nothing compares to product thinking: imagining being a product owner who codes. That’s the most valuable skill.

I wish someone had told me that earlier. As a junior coder, I ignored product thinking, teamwork, and clear communication. Those skills make us stand out as coders. And that’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding, the guide to the lessons I wish I’d known from day one.

If you want to grow faster, grab your copy of Street-Smart Coding here

BugOfTheDay: Blazor Input Control Won't Turn Red

2025-11-18T00:00:00+00:00

In another episode of Adventures with Blazor, I ran into a sneaky bug with custom input validation.

This time I had an input control to enter sizes and lengths in either inches or millimeters based on a flag per client. When the bound value was missing, the border didn’t turn red.

Here’s a form using a custom MeasurementInput,

@* MyCoolForm.razor *@
<EditForm Model="MyCoolRequest" OnValidSubmit="OnValidSubmit">
    <DataAnnotationsValidator />
    <ValidationSummary />

    <div class="row">
        <div class="col-sm-3">
            <label for="length" class="form-label">Length</label>
            <MeasurementInput id="length" @bind-Value="MyCoolRequest.Length" class="form-control" />
            @* ^^^^^ *@
            @* A custom input. Notice the class attribute *@
            <ValidationMessage For="() => MyCoolRequest.Length" class="invalid-feedback" />
        </div>
    </div>

    <button type="submit" class="btn btn-primary">@SubmitButtonText</button>
</EditForm>

And here’s the actual MeasurementInput,

@* MeasurementInput.razor *@
@inherits InputBase<Measurement>

<input class="@CssClass" @attributes="AdditionalAttributes" @bind="CurrentValueAsString" type="text" />
@*     ^^^^^ *@
@* Notice the class attribute here *@

@code
{
    [Parameter]
    public bool? ShouldUseInches { get; set; } = true;

    protected override string? FormatValueAsString(Measurement? value)
    {
        // Format as inches or millimeters
    }

    protected override bool TryParseValueFromString(string? value, out Measurement? result, [NotNullWhen(false)] out string? validationErrorMessage)
    {
        // Validate and parse from inches or millimeters
    }
}

After hours of debugging, I found the input style never applied the is-invalid class.

The fix? Two lines of code changed,

-<input class="@CssClass" @attributes="AdditionalAttributes" @bind="CurrentValueAsString" type="text" />
+<input class="form-control @CssClass" @attributes="AdditionalAttributes" @bind="CurrentValueAsString" type="text" />

-<MeasurementInput id="length" @bind-Value="MyCoolRequest.Length" class="form-control" />
+<MeasurementInput id="length" @bind-Value="MyCoolRequest.Length" />

Two class attributes: one in the input, one in the form. Arrggg! A full day lost to two lines of code. Source.

This tiny bug reminded me that coding isn’t just about syntax. It’s about searching, finding answers, and asking for help.

Even with AI, those skills remain essential for new coders. That’s why I start my book, Street-Smart Coding: 30 Ways to Get Better at Coding, with them. It’s the practical guide I wish I had on my journey from junior to senior.

Get your copy of Street-Smart Coding here

The Truth About Coding That Changes Everything

2025-11-17T00:00:00+00:00

Last week, one of my LinkedIn posts sparked a heated discussion.

I shared this post about what makes us senior coders. Its point was to build real products instead of obsessing over syntax.

I shared,

… true seniority is when you:

Stop obsessing over syntax

Realize end users don’t care about your code

Understand coding is collaboration and communication

Most people agree with the message, except for this line:

“End users don’t care about our code.”

Some take “end users don’t care about code” as permission to ignore quality and standards. That’s wrong.

But there’s also the “end users don’t care about code,” so:

Let’s stop fighting over languages and tools
Let’s stop building excessive abstractions
Let’s stop making it scale just in case
Let’s choose boring technology

End users suffer the consequences of poor coding practices. Sure! It shows up in buggy, slow apps. Nobody wants that.

What matters to users is speed and reliability, not whether we used jQuery or React. They care about whether we solve their problems.

We write code for different audiences: for end users, future coders, and business owners. And they don’t care about the same things.

Being senior means meeting the needs of all three groups.

For so long, I thought coding was only typing syntax. That realization inspired me to write Street-Smart Coding: 30 Ways to Get Better at Coding, a roadmap to help you move from junior or mid-level to senior without losing your mind. It’s the roadmap I wish I had starting out.

Grab your copy of Street-Smart Coding here

7 Hard-Earned Lessons from Launching Street-Smart Coding

2025-11-16T00:00:00+00:00

Last month, I launched Street-Smart Coding, my most ambitious writing project so far.

I wrote the roadmap I wish I had at the start of my coding journey. I had written mini-books before, but this one was different. It pushed my writing and marketing skills, and my self-discipline.

Writing taught me lessons, but launching was a whole different game.

Here’s what I’ve learned:

#1. Set an artificial deadline. To keep yourself focused, set a launch day. Pick a day and mark it on your calendar. Also share it with everyone involved in your book: beta readers, designers, editors…

#2. Start with a promise, title, and outline. Before writing the actual content, start with the sales page or the Amazon description. It forces you to clarify your message. And to make the promotion phase easier, come up with a one-liner to explain your book.

#3. Focus on one big project at a time. While writing the book, I was:

Engaging on LinkedIn
Sending a weekly email
Writing a daily blog post
Coding for a contracting client

I could have finished in half the time by focusing on one commitment. I only started to see progress when I focused on my book and let all other projects suffer. It’s really easy to lose momentum with a book.

Make your book your priority.

#4. Start selling before your book is done. Write your intro and some chapters and go pre-sell it. You don’t even need a final cover. You can change it later.

I made 4 sales in the first two weeks: two preorders and two sales. That was enough to see some traction and keep going.

The other day, I read that we should start marketing the day we start a project. I read it about coding side projects, but it’s also true for books.

#5. Share every stage of your journey. Finished the first draft? Share it. Designed the cover? Share it. Choose a final title? Share it. Share every milestone on your social media, newsletter, or blog. And plug a pre-sale CTA on every piece of content.

For my title, I had three winning ideas. To pick one, I ran a poll on LinkedIn and let followers and readers vote. Their favorite became the final title.

#6. Focus on one task at a time. A book demands you to wear multiple hats:

Writer
Designer
Marketer
Copywriter
Project manager

Of course, if you’re with a publisher, they will take care of some of those tasks. But when you’re self-publishing, you’re on your own. All those tasks might be daunting, but focus on the task at hand.

Being a fan of writing 10-idea lists, I used 10-idea lists for every step of the process:

10 title ideas
10 chapter ideas
10 possible beta readers
10 promotion ideas

Don’t overthink the next steps beforehand.

#7. Promote it everywhere. Once you write the last word of your first draft, you’re not a writer anymore. You’re a salesperson. Go out and sell your book!

Promote it everywhere: your email signature, social media, blog, newsletter, even WhatsApp. Do the work, then tell the world about it.

Launching and promoting a book has been a long but rewarding experience. Even after many revisions, the fear of typos didn’t easily go away. But I’ve loved the experience so much that I’m already working on the next. Every lesson makes the next one even better.

6 Lines That Have Made me Think Recently

2025-11-15T00:00:00+00:00

I’ve reduced the media I consume. I’ve stuck to books and podcasts while doing the dishes, and occasionally a few forums and indie bloggers via Minifeed.

From those few sources, these lines have made me think recently.

#1. AI won’t take your job. It will change your job description.

#2. The rich have money, the wealthy have time.

#3. Don’t be the best, be the only.

Those three come from Kevin Kelly, the guy behind the 1,000 true fan concept. I’ve been listening to this podcast interview. I don’t know how many dishes I need to wash to finish it.

#4. Hands first, then computer. This is a line I found on Steal Like an Artist. Computers have disconnected us from doing art with our hands.

#5. Momentum isn’t doing more, it’s doing less, but better.

#6. Two hours of focus work today can create a lifetime of income tomorrow.

This comes from Mark Thompson, a veteran marketer I’ve been following recently. I’ve used Mark’s Sales Funnel method to promote my new book.

Friday Links: Leaving jobs, full-stack myth, and stickers

2025-11-14T00:00:00+00:00

Hey there. Here are 4 main links plus 2 extras I thought were worth sharing this week:

#1. I’d give my junior self lots of advice. But if I had to choose one, I’d say always be ready to leave your job (6min), even if you’re not planning to leave.

#2. I once tried being full-stack, until I discovered the backend world: RESTful APIs and DDD. Maybe being a full-stack coder is a myth (10min) after all.

#3. Here’s a quick take on why polymorphic tables aren’t a good idea (3min).

#4. Could strict best practices and clean code create an unhealthy culture (10min)?

And two quick ones, just for fun:

#a. I had my first laptop full of stickers. If you’re like the old me, share your laptop stickers on stickertop.art.

#b. It seems we coders aren’t the only ones copy-pasting from ChatGPT. Journalists do it too

And in case you missed it, I wrote on my blog about 8 steps to take over a legacy codebase (5min) and when AI feels like cheating (2min).

(Bzzz…Radio voice) This email was brought to you by… Street-Smart Coding: 30 Ways to Get Better at Coding. From Googling to clear communication, it covers 30 lessons to help you code like a pro. It’s the roadmap I wish I had moving from junior to senior, and the one I hope helps you too.

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.

8 Proven Steps to Take Over a Legacy Codebase (Without Losing Your Mind)

2025-11-13T00:00:00+00:00

Like it or not, you can’t escape from legacy code.

I know how it feels to inherit a codebase like that. The “what I’m supposed to do now” feeling. While I’m writing this, my latest gig is yet another legacy code.

I’m not alone. Recently I found this question on Reddit, a fellow coder who received a codebase with only a handoff from a coworker.

I’m about to take over an .NET Core + SQL Server + Knockout.js/Angular project at my company. The issue: There’s zero documentation. I’ll only get a short handover from a teammate…

My main questions are:

For legacy .NET projects, what’s your process to get up to speed fast?

Should I start writing my own documentation (README, architecture notes, etc.) while I learn?

Any tools/tips for mapping out the database + system structure quickly?

From your experience, what do you focus on first: business logic, database schema, or the code itself?

I’d love to hear how you’ve handled taking over undocumented C# / .NET projects before. Thanks!

Having been in their shoes in every job I’ve had, here’s how I’d approach inheriting a legacy codebase, step by step:

#1. Understand it takes time.

It takes 6-12 months to know the ins and outs of a medium-to-large legacy codebase. Your mileage may vary. The point is: You don’t have to know every single small detail up front.

#2. Install and run the app.

Your first step should be to have your working environment running on your machine.

Install the tools you need: maybe a database engine, editor plugins, or scripts.

Also, this is a good opportunity to document those prerequisites in a README file and to open your first pull request.

#3. List the main components.

Don’t jump to files and methods.

Instead, get to know the overall architecture of the app:

Is that a monolith? Does it use microservices?
How many databases does it use?
Does it call external APIs or services?

You can go as simple or as fancy as you want. Maybe that’s a sketch on a whiteboard or a version-controlled compiled diagram. I tend to go simple with pen and paper.

#4. Learn the building blocks.

Navigate the source code of the main solution or entrypoint.

Try to answer:

What is the folder structure?
How is the code organized? Per project? Per domain?
How does it access the database? Stored procedures? An ORM? Plain SQL queries?
How does it achieve common tasks like logging, REST calls, etc?

#5. Look for the most frequently changed files.

This is a trick I learned from Your Code Like a Crime Scene by Adam Tornhill.

Those are the places that attract complexity. That’s where bugs tend to happen or where requirements aren’t clear. They’re like the most dangerous places in your code.

If you’re lucky and the code is under version control, use and tweak this Git command,

alias gmost='git log --pretty=format: --name-only | sort | uniq -c | sort -rg | head -10'

I probably found it on StackOverflow. Or use fancier code analysis tools instead.

#6. Find out the most frequently used features.

Get to know how the end users interact with the app and what the 20% of features they use 80% of the time.

You will find one single screen they use daily, or just a few buttons out of a dozen. “Do one thing and do it well” is often a dream in enterprise software.

#7. Find out the module or component that gets more bug reports.

This is the spot to focus on first or to get early victories.

It doesn’t have to be the same one as the most used component or feature. Maybe it’s a report that runs once a month or a page that takes forever to finish. Or whatever.

Ask users about common pains. Maybe some ex-coworker always mentioned a fix. “Oh, every time that thing broke, Bob mentioned he had to…” You’re like a detective looking for clues.

#8. List key tables and parametrization tables.

Don’t try to understand every detail. Start with the overall design.

Is it one database per client in the same server? Or separate schemas per client?

Then try to generate a diagram from your database schema.

Most likely, you’ll find one or two key tables. Those are the “Reservations,” “Invoices,” or “Orders” tables. They tend to attract more references.

And you’ll also find parametrization tables. Those are tables with only a few records that power the behavior of the system. They’re good candidates for caching.

Parting thought

With those steps, you’ll get a clear big-picture of the codebase. Start broad, then move on to the details when you need it. That’s far better than trying to understand every single class or method up front.

Working with legacy code isn’t glamorous, but it’s the reality of our work. Most of the time, we’re maintaining and modernizing live systems, not building new ones from scratch.

That’s why I dedicate a chapter to legacy code in my book, Street-Smart Coding: 30 Ways to Get Better at Coding Without Losing Your Mind. Junior me thought I’d only start new projects with the latest tools. Wrong!

Grab your copy of Street-Smart Coding here. It’s the roadmap I wish I had moving from junior to senior and the one I hope helps you too.

Wednesday Links: $0.01, layoffs, and Zuckerberg emails

2025-11-12T00:00:00+00:00

Hey there.

I just realized I already had 4 links and I didn’t want to wait for next Friday to share them. So here they are.

These first two are just for laughs:

#1. Imagine waking up to an invoice for $0.01 from your cloud provider. Yep, that happened. Here’s the full story (10min).

#2. Now imagine sharing a name with the creator of a major social media platform. You won’t believe how many emails you would receive if your name were Mark Zuckerberg (2min).

On a more thoughtful and serious note…

#3. Everybody blames AI for the recent layoffs, especially the ones at Amazon. But there’s a real reason (1min) and of course, nothing to do with AI.

#4. My best interview was just one call and one open source contribution. That happens rarely. But what if open source contributions were like service duty? (2min).

And in case you missed it, I wrote on my blog about the scariest lines of code I’ve written (2min) and my reactions to r/csharp homepage (4min).

(Bzzz…Radio voice) This email was brought to you by… Check my latest book, Street-Smart Coding: 30 Ways to Get Better at Coding. From Googling to clear communication, you’ll find 30 lessons to help you code like a pro. It’s the roadmap I wish I had moving from junior to senior and the one I hope helps you too.

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.

Re: I Use AI When I Code. And Sometimes It Makes Me Feel Like I'm Cheating

2025-11-11T00:00:00+00:00

Is using AI cheating?

That’s a point Christoffer Madsen made in a recent post on dev.to:

I use AI when I code. I don’t hide that. But I also don’t really talk about it. Because sometimes it feels like cheating.

That made me think:

If I copy-paste from StackOverflow, am I cheating?

If I use an open-source library, am I cheating?

If I ask for help, does that count as cheating?

We do those tasks daily. Maybe not always copy-pasting from StackOverflow.

Where’s the line?

When isn’t using AI cheating? It feels like cheating when AI takes full control and writes code we wouldn’t write ourselves.

I do use AI too: to generate boilerplate code and offload boring tasks. That’s where AI shines. But I stay in control, hands firmly on the wheel.

With or without AI, we’re paid to solve problems, not just to write code. If we only turn user stories or specs into lines of code, AI will eat us all alive.

When AI generates code faster than any of us, it’s time to double down on collaboration, communication, and problem-solving. Those skills make us stand out as coders. That’s why I wrote, Street-Smart Coding: 30 Ways to Get Better at Coding Without Losing Your Mind. Because being a great coder is more than just mastering syntax.

Grab your copy of Street-Smart Coding here. It’s the roadmap I wish I had moving from junior to senior and the one I hope helps you too.

4 Practical Use Cases Where AI Shines in Coding

2025-11-10T00:00:00+00:00

Like many developers, I’ve struggled to find the right way to use AI.

So far, I’ve settled on using AI as my assistant, but I don’t let it touch my code.

I haven’t followed a strict approach to testing AI. I just use it to offload some boring tasks, like this and this.

Here are the use cases where I’ve found AI shines:

#1. Generate unit tests: I give a sample test class I wrote myself and ask it to use as a guideline to generate tests for a similar object. Especially helpful when I’m not doing TDD but still want unit tests.

#2. Generate CRUD code: I’ve always dreamed of automating CRUDs. It seems we’re closer with AI.

I give AI a handler signature, explain the steps, and let it fill in details. I also provide database object definitions, repository signatures, and legacy code blocks, when I’m in migration mode.

#3. Improve naming: OK, this is one of the hardest tasks in coding. I describe what my class or method does and ask AI to critique or suggest names.

#4. Review code: This is one of my most frequent use cases. I like to feed AI with a diff of my changes and ask it to look for typos and places where I broke conventions. AI has caught me copy-pasting a lot. I tend to forget to update API routes. Oops!

I almost added searching (bye Google!) as a fifth point, but I trust StackOverflow and random people’s blogs more. I’m not sure when AI is simply hallucinating or actually answering correctly.

Lesson: Use AI for pattern matching and boilerplate code. Don’t use it to generate entire modules, make architectural decisions, or ask it to “double check answers and not to make mistakes.”

And if you’re starting out, set strict AI rules or you won’t grow strong coding muscles. Use AI as a learning assistant instead.

It’s tempting to default to AI for its speed. But to shine as a coder, you need more than just speed. Coding is problem-solving, collaboration, and clear communication. That’s why I wrote, Street-Smart Coding: 30 Ways to Get Better at Coding, the roadmap I wish I had on my path to becoming a senior coder. Because coding is more than mastering syntax.

Get your copy of Street-Smart Coding here

The One-Liner I Forgot When Writing My Latest Book

2025-11-09T00:00:00+00:00

Last week, I shared lessons I learned from a team’s architect.

He taught me to simplify complex coding problems into one line. A skill that has become easier with experience.

The same principle applies to any creative work.

But I completely forgot about it when writing and launching Street-Smart Coding, my latest book.

Movies, novels, and TV shows summarize their plot into a line or short paragraph for posters or synopses.

With a one-liner, writing promotional material is easier. “A vampire romance for teenagers.”

Next time you create something, describe it in a single line. You might need it on your sales pages or simply when someone asks you “what’s your new project about?” With a one-liner, you’ll always have a simple, confident answer.

10 Lessons From Steal Like an Artist That Transformed My Creativity

2025-11-08T00:00:00+00:00

The title itself is provocative: Steal Like an Artist. Stealing is bad. But “like an artist”?

Does it mean all artists steal? The whole point of stealing is not getting caught. Then what are artists doing to steal differently? Those are questions I asked just by reading this book’s title.

After sitting on my desk for a while, I finally read it. Here are 10 lessons I learned:

#1. Learning is copying. First learn who to copy, then learn what to copy. Once you’ve chosen who to copy, trace their influences too.

#2. If you copy from one person, it’s stealing. But if you copy multiple, it’s inspiration. Creativity is using inspiration to come up with something that doesn’t look stolen.

#3. “There’s nothing under the sun.” This is the author quoting a passage from the Bible. If there wasn’t any new 2,000 years ago, that feels like permission to copy.

If you think it’s new, it’s because you don’t know the original source.

#4. Creativity is subtraction. Creativity isn’t only inventing. It’s also remixing existing ideas and leaving things out to make them new. This reminds me of Idea Calculus from Skip the Line.

#5. Hands first, then computer. With a computer, the line between writing and editing is blurry. A computer wakes up the perfectionist inside us. Go analog to separate creating from critiquing.

In my own writing, I’m adopting this idea for my next books: outline first with index cards, then write on a computer, and then print out the draft to edit on paper.

#6. Use a calendar and deadlines. Work expands to the time available. Use deadlines to focus and to avoid procrastination and perfectionism. Done is better than perfect, perpetually unfinished.

#7. “You’re as good as your last post.” This is an invitation to keep working on your creative side. Don’t be a one-hit wonder.

I was about to write “keep showing up,” but I remember I ditched that line.

#8. Have a victories folder. Every time anything good happens with your art, take a screenshot, and save it for later. I screenshot comments, hit posts, follower count, dashboard with sales…Anything inspiring. This comes in handy when you feel like giving up or facing haters.

#9. Routine over time. The other day, I watched an interview of Steven Pressfield in the Huberman Lab. Steven said he only writes for ~2 hours a day. If a pro writer only writes 2 hours, you don’t need to quit your day job. Build discipline and a routine first.

#10. Keep your day job. It takes time to live off your art. Have something that doesn’t deplete your energy to pay the bills. The time to quit will come later.

This book made me rethink creativity. But it also made me rethink the concept of a book. Steal Like an Artist isn’t a 50,000-word volume on creativity. It’s a collection of 10 big ideas, presented with clear examples and eye-grabbing doodles and visuals. That already feels like permission to steal, remix, and create today.

Friday Links: Worms, Amazon, and Agile

2025-11-07T00:00:00+00:00

Hey there.

Hope your week’s been good. Here’s what caught my eye lately:

#1. Around this day in computing history, the Morris worm infected 10% of the Internet. A prank that got out of control. Thank goodness that worm is trapped in a floppy disk now. Do you still remember floppy disks?

#2. Amazon has been in the headlines: outages, layoffs, and users leaving its cloud. Maybe the could wasn’t such a great idea after all (20min). And I don’t need to worry about the fear of missing the cloud hype.

#3. I don’t miss Scrum and its “ceremonies” from the corporate world. The whole Agile movement has become a performance theater (6min). We get stuck in rituals instead of real work. Arrggg!

#4. As a coder, I’m grateful for free and open-source software (FOSS). But it rarely beats the convenience of most closed software. Often FOSS scares “normal” people (3min).

Also on my blog this past week, I share about AI’s hidden gift (2min) and the real problem with AI writing all our code (3min).

(Bzzz…Radio voice) This email was brought to you by… My new book, Street-Smart Coding: 30 Ways to Get Better at Coding. Inside, you’ll find 30 lessons, from Googling to clear communication, designed to help you grow from junior/mid-level to senior and build real-world coding skills.

If you’ve ever felt like you don’t know how to level up as a dev, this is the roadmap I wish I had

Grab your copy here. During launch, pay what you want (even $1 or $2).

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.

The Scariest Lines of Code I've Ever Written

2025-11-06T00:00:00+00:00

I don’t remember if it was rainy or sunny outside. It was more than five years ago. I was still becoming a senior coder.

I’ve written hundreds of thousands of lines of code. But I still remember this one. As part of my routine, I wrote this query in a stored procedure,

SELECT * FROM dbo.HugeTableWithoutIndexes
WHERE DATEDIFF(DAY, ADateColumn, @InputDate) = 0

I was working with an email system built with Amazon SES. I needed to show all email activity: delivered, opened, bounced, and so on. I wrapped a column in a function. A deadly sin!

The table had millions of records and no indexes. My query forced a full scan of the table. The next thing I knew the server was on fire. Not literally, of course.

Those days I refused to learn SQL, convinced ORMs and NoSQL were enough. I couldn’t have been more wrong. Relational databases and SQL still reign.

Eventually I learned about indexing, scans vs seeks, and SQL Server internals. Shout out to Brent Ozar’s courses.

A painful lesson I will never forget. That’s why learning SQL found its way into my new book, Street-Smart Coding. It isn’t a textbook. It’s a roadmap with 30 proven lessons to help you code like a pro. It’s the guide I wish I had starting out.

Want to avoid painful mistakes like mine? Grab your copy of Street-Smart Coding here

Dead Tech Will Outlive Today's Stacks

2025-11-05T00:00:00+00:00

Every single job I’ve had has involved migrating a legacy app.

At my last full-time job, it was a WebForms app to manage hotels. First, they tried to modernize it by embedding modules powered by Bootstrap and Knockout.js into the main app. Then, React applications powered by ASP.NET Core API, still hosted within the main WebForms app. Management daydreamed of ditching the old WebForms app. But nah! Mission impossible. It had too much old code entangled with the new code. A zombie that refused to die.

Currently, I’m working on a WebForm app migration from VB.NET to Blazor. We fear Microsoft will deprecate Blazor before we finish the migration. Most likely, WebForms and VB.NET will still be around, seeing dozens of other languages and tools die.

Here I’m talking about WebForms applications. But it’s the same story with jQuery, PHP, and more “dead” languages and tools.

They’re dead depending on who you ask. The StackOverflow developer survey in 2025 registered 23.4% of respondents still using jQuery and ~8% using VBA/VB.NET. That doesn’t seem dead at all.

A business can’t wait for a new application

It’s tempting to rewrite legacy applications. We rebuild all the context, business rules, and constraints, which makes us confident in the code we’re writing.

Often, rewriting isn’t an option. Legacy code runs “successful” businesses. A business can’t stop while the new system is built. And paying off technical debt doesn’t guarantee more money.

Sylwia Laskowska puts it clearly on jQuery Will Outlive Half of Today’s JavaScript Frameworks:

You don’t get paid to build shiny new things. You get paid to keep existing things alive without breaking production.

Legacy code is code that simply works.

New coders don’t dream of working with “dead” languages and tools. I know! I thought I was going to work only with brand-new tools. But legacy code taught me more than any coding course, like navigating large codebases without any documentation or anyone to ask. That’s why it’s in my book, Street-Smart Coding: 30 Ways to Get Better at Coding.

Grab your copy of Street-Smart Coding here. That’s the roadmap I wish I had when I was starting out.

Senior C# Dev Reacts to Reddit's /csharp (Hot Takes Only)

2025-11-04T00:00:00+00:00

I didn’t have writer’s block today. Naaah! I was just scrolling down the /csharp subreddit for inspiration.

Scrolling through, I realized I had answers and reactions. And to follow the popular YouTube format, here I go reacting/roasting/responding to the front page of /csharp:

Reddit r/csharp front page

#1. I wrote a cross-platform TUI podcast player in .NET 9 (mpv / VLC / native engine fallback) Source

Great! Put it on your portfolio.

#2. Best approach for background or async tasks Source

Mmm. Probably that’s Hangfire.

Hi. In my last project, I had: 1 Api for backoffice 1 Api for app mobile 1 Worker Service for all the background tasks … So now I’m in new project, but I’m not sure if is necessary use Masstransit with RabbitMQ? Maybe channels? I mean, I want to keep it simple, but I don’t like put consumers or jobs in the same API, I always prefer to have a worker service dedicated to all asynchronous tasks.

Hangfire?! That’s definitely Hangfire. I don’t need to read more. And you don’t need to look for anything else.

#3. Is conciseness always preferred? (Linq vs Loops) Source

Not that I have a course about it, but LINQ is the best of all C# features. Yes, write a LINQ query first. Then, if you’re working on a high-performance scenario, go with loops.

#4. Can you explain result of this code? Source

Nah! I have a post to write. Ask ChatGPT or Copilot. It’s free.

But seriously, it’s a good exercise. Try debugging it yourself before asking.

#5. Let’s Talk About the Helper Classes: Smell or Solution? Source

Definitely a smell. Helper classes attract plenty of methods. “Where do I put this new method? Oh there’s a Helper class over there! I’m putting it there…”

If you’re tempted to write a Helper class, hold your horses.

#6. In general is it normal to have more than 2k lines in a file? Source

You shouldn’t have one. But yes, it’s normal.

Scroll…scroll…

Nah! Boring! Scroll…scroll…

#7. After seeing that LOC post, can anyone beat this? Source

Really?! Like, c’mon. We’re seeing who has a larger file?!

The other day, I shared that you know you’re in trouble when you try to open a file on GitHub and it says “(Sorry about that, but we can’t show files that are this big right now.)” Spoiler alert: The file has 69,923 and it’s called GlobalFunctions.vb.

You see? Helpers!

#8. Is C# good for beginners? Source

Hell, yes!

#9. Why is this issue only popping up at the 30 line? Source

Dunno! See #4.

#10. Career Guidance: .NET Backend Developer Role and Future Tech Stack Transition Source

“Blah…blah…blah… I’ve accepted the offer, but I sometimes question whether choosing the .NET path was the right decision. I’d like to understand the current job market for .NET developers.”

Hey, buddy! We’re in a bubble that is popping (or about to pop) now. In 2020-2021, “Software Engineer” on LinkedIn meant a line of recruiters with “life-changing opportunities.”

These days? Just look at the headlines. Amazon just “let go” thousands of employees in the past weeks. And that was right after an outage that took down pretty much every client. That’s for every stack, unless you have “AI” anywhere in your title.

OK, let’s call it a day! That’s enough roasting for today. I should be writing a YouTube script, but I don’t have a channel. Just a blog…and a book. Speaking of which…

This post is brought to you by… Check out my latest book, Street-Smart Coding: 30 Ways to Get Better at Coding. It’s not a C# textbook. It’s the roadmap I wish I had on my journey from junior/mid-level to senior. Some lessons are conventional. Others not so much. From Googling to debugging to clear communication.

Get your copy of Street-Smart Coding here

PS: In case you didn’t notice, this was half-joking. And yes, I’m promoting my book.

The Real Problem With AI Writing All Our Code

2025-11-03T00:00:00+00:00

AI might promise speed and productivity. But it comes with serious issues.

The other day I found a senior coder quitting AI coding after finding out that:

AI was like a sloppy coder who bypassed tests and wrote bad code
AI had stolen all the joy of solving problems from him

After experimenting with AI, I realized I was becoming lazier than usual. Since then, I’ve set simple rules to avoid losing my skills.

But those aren’t the biggest problems.

A failed experiment revealed a more serious problem

Today I found out about the experiment of a team of coders that revealed a deeper problem.

After trying to write a feature at work only by prompting, they realized:

[Even when AI is capable of writing all of our code], a huge issue remains: I lose my mental model of the codebase. … Until I can trust the AI completely, I need to keep my own mental model alive. Otherwise, every time I need to do something myself feels like joining a new company.

It takes time to get familiar with a complex codebase. At past jobs, it took me about a year to feel confident. Of course, your mileage may vary.

But when that happens, you feel like driving through familiar streets with only one hand on the wheel:

You know the architecture, the folder structure, and even a rough sketch of code blocks.
You know how modules connect and what to touch or avoid.
You can even remember file and function names.

You’ve built the mental models and gained all the context. Without them, you feel like walking into a dark room.

When AI writes our code, it’s stealing the context and the feeling of knowing a codebase like the palm of your hand.

Use AI if you want, but be the one dictating what to do. Draw the boundaries of the solution, then let AI fill in the details. Be the pilot and let AI be your copilot.

When AI can handle syntax, it’s time to work on skills it can’t, like collaboration, clear communication, and problem-solving. That’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding, the roadmap I wish I had on my journey from junior to senior.

Get your copy of Street-Smart Coding here

Three Things to Remember When the Haters Show Up

2025-11-02T00:00:00+00:00

Future me:

Yesterday I woke up to a comment on a coding post we reposted on Medium. It said, “you are just marketing your book.” It included some profanity, but I’m not adding it here.

I just launched Street-Smart Coding last week. And yes, I’ve been promoting it by turning every post into a sales rep. Hey, singers promote their concerts and writers go on podcast tours, right?

Here are three reminders for you, future me:

#1. Remember the 30/30/30 rule

Keep in mind that no matter what you do:

30% will love it
30% will hate it
30% won’t even care

Well, technically it’s 33.333333%, but you get the point. That commenter was just part of the second 30%.

And good or bad publicity is still publicity. That hateful comment was signaling Mr. Algorithm to promote your post even more.

#2. Remember why you started

There’s a hill to die on:

Either you sell something (even a $1 pdf) or sell your time in a 9-5. You’re not going to like one of the two.

And if you choose to stay away from a 9-5, you’ll have to embrace sales and marketing. You have to be your own sales team.

#3. Fight your negativity bias

A single negative comment will make you forget the thousands of positive ones.

Open your victories file and your book sales. That’s your first 30%. Show up for them. Here’s a small victory…and another one here.

You spent years building somebody else’s dream and business. Now build yours. Don’t be ashamed of promoting your own work. Influencers and millionaire writers do it. You can do it too.

Let them talk. You keep doing your work.

Read this as many times as you need.

AI's Hidden Gift: We're Rediscovering the Practice of Coding

2025-11-01T00:00:00+00:00

We’re searching for the best way to get working code from LLMs.

To avoid falling into the vibecoding trap, some developers are turning into structured approaches.

The other day, while catching up with some friends, one of them preached Spec Kit and its Specify/Plan/Tasks/Implement process like the holy Gospel. That’s GitHub’s approach to coding with AI.

More recently, I found The AI development trap that wastes your time on dev.to. It includes these four questions to regain control after drifting from too much prompting:

Do I understand exactly the specifications I’m trying to implement, or the bug I’m trying to solve? Do I have an exact plan for implementing my changes? What is the current abstraction level to which I should be prompting now? Which other information am I lacking?

Spec Kit and those four questions capture the essence of coding.

So to better code with AI, we have to do what we’re supposed to do as coders in the first place:

Understand the problem to solve
Decompose that problem into smaller ones
Think at the right level of abstraction
Ask enough clarifying questions

Ironically, AI is making us go back to the mindset we should have never left behind.

Context comes before coding, with or without AI.

That’s why one of the principles I included in my book, Street-Smart Coding: 30 Ways to Get Better at Coding is “Don’t rush to code.” (That’s on Chapter #3.) That’s even more helpful with AI as your coding assistant.

Coding isn’t just about syntax. It’s about clear communication, thoughtful problem-solving, and knowing what questions to ask.

Grab your copy of Street-Smart Coding here

Friday Links: Coding like a surgeon, surviving a stroke

2025-10-31T00:00:00+00:00

Hey there.

Here are 4 links I thought were worth sharing this week:

#1. I’ve been thinking about how to adopt AI. I don’t want to outsource coding. I still want my hands dirty. I thought we should be like the lead surgeon in an operating room. But I’m not the only one thinking to code like a surgeon (6min).

#2. We can reduce the whole clean code discussion to a few principles, like “separate specific code from generic code” (That’s the one I cover in Street-Smart Coding, by the way). But there’s a similar one: pure core, impure shell (3min).

#3. The tech industry made me sick last year, literally and figuratively. It was life-changing, though not as serious as surviving a stroke (5min). Even if you haven’t had health issues, that’s worth reading. You can always find a new job, but not a new body. You need boundaries.

#4. With big corporations eager to make money, the dream of running what we want in our devices seems to be gone (10min).

Also on my blog this week, I shared about the subtle sign you’re growing as a coder (2min) and 5 lessons from a mentor that helped me become senior (4min).

(Bzzz…Radio voice) This email was brought to you by…

If you’re looking to level up your coding skills, Street-Smart Coding: 30 Ways to Get Better at Coding is here. No more “preorder” or “just 5 tips to get you started.”

Some of the lessons inside are conventional. Others were learned the hard way. And a few are weird. (One of the tips is to watch a TV show. That’s on Chapter #29.) But all the tips and lessons are battle-tested.

Grab your copy here. Just for a few days, you can pay what you want (even $1 or $2). No tricks or treats.

See you next Friday,

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.

TIL: Always Wrap Collections in API Responses

2025-10-30T00:00:00+00:00

Note to future me:

You’ve learned this before. But it’s easy to forget or let teammates (or clients) make the same mistake.

Always return collections wrapped inside a response object from your APIs.

Adding fields, like pageNumber and itemCount, won’t break the UI or other clients. This is one of the few places where you should forget about YAGNI. Remember You Aren’t Gonna Need It? Is that still a guideline in the future with AI? Anyway…

Please, don’t do:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () =>
{
    return new[] { "Titanic", "Terminator" };
    //     ^^^^^
    // Please don't.
    // Otherwise a cute baby panda dies in the forest
});

app.Run();

Instead, please do:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () =>
{
    return new
    {
        Items = new[] { "Titanic", "Terminator" }
        // ^^^^
        // OK, with a proper object.
        // You know we're lazy with the examples
    };
});

app.Run();

Just today, in a client project, I realized we let this mistake happen and we had to update almost a dozens pages in a Blazor app.

Make this an API commandment.

The Subtle Sign You're Growing as a Coder

2025-10-29T00:00:00+00:00

You know you’re growing when:

You don’t get stuck on compilation errors for missing semicolons
You’re not rushing to code without doing some planning
You know when your code looks or feels funny

But there’s another subtle sign of growth:

You let others into your code and you don’t take critiques on your code personally.

Being an overprotective coder

Oh boy! In my first job, I didn’t want anyone else to touch my code.

Each team member worked solo, with almost no collaboration. And after finishing Clean Code, I thought only my code met all the standards. I didn’t want anyone else to infect it.

Then at my next job, it was almost the same story.

Along with a small team, I worked on the core features of the main app. Only a few touched it. And it hurt to see my code rewritten during the app redesign to make it scale.

Learning not to be one with the code

After moving between projects and companies, I eventually learned that I’m not my code.

Critiquing my code isn’t critiquing me. Bugs happen. Edge cases get missed. Requirements get misunderstood. And when that happens, someone will pick my code and say “Who wrote this crap?” The same way I said that when I inherited somebody else’s codebase.

Get your code in front of others, let them change it, tweak it, and critique it.

That’s the key to growing as a coder. And that’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding. Nobody told junior me that writing simple code others could inherit and improve was part of growing.

Grab your copy of Street-Smart Coding here This is the roadmap I wish I had on my journey from junior to senior.

I'm Launching Street-Smart Coding: 30 Lessons to Help You Code Like a Pro (the Roadmap I Wish I Had Starting Out)

2025-10-28T00:00:00+00:00

Street-Smart Coding: 30 Ways to Get Better at Coding Without Losing Your Mind

I spent five years in college learning to code.

A stupid dissertation delayed my graduation. But that’s another story.

Most of my five-year program didn’t prepare me for real-world coding. My real coding journey began at my first job, with one Google search: “how to get good at coding.”

I found a lot of conflicting advice:

“Use comments”
“Don’t use comments”
“Do this”
“Don’t do that”

Arrggg!

It took years of trial and error to learn what worked.

I had to survive on-call shifts, talk to stakeholders, and say “no” politely. More importantly, I had to learn that coding takes more than just syntax.

That’s why I wrote Street-Smart Coding— a roadmap of 30 lessons I wish I had when I started. For every dev who’s ever typed “how to get better at coding” into Google or ChatGPT. (Back in my days, I didn’t have ChatGPT… Wait, I sound like a nostalgic grandpa…)

Preview of the first ~12 pages

Inside “Street-Smart Coding”

This isn’t a textbook. It’s a battle-tested guide for your journey from junior/mid-level to senior.

Some lessons are conventional.

Others were learned the hard way.

And a few are weird.

One lesson comes from a TV show. Nope, not Mr. Robot or Silicon Valley. That’s on Chapter #29. It will teach you about problem-solving.

You’ll learn how to:

Google like a pro
Debug without banging your head against a wall
Communicate clearly with non-tech folks

…and 27 more lessons I learned over ten years of mistakes.

Now they’re yours.

Get your copy of Street-Smart Coding here and skip the years of trial and error. For launch week only: Pay what you want—even $1 or $2.

This TV Show Can Teach Problem-Solving Better Than Any Coding Class

2025-10-27T00:00:00+00:00

Yesterday, I shared a surprising way to improve at coding: watching a TV show.

It wasn’t Silicon Valley or Mr. Robot or any other TV show featuring hackers. It was a show about doctors. I never thought hospital drama could teach problem-solving.

Watch House M.D.

Let me introduce you to Gregory House, the protagonist.

He’s not a regular doctor. He doesn’t like patients. He doesn’t wear a white coat or use a stethoscope either. He’s even sick and under constant medication. Weird, right?

But he gets the most complex, rarest cases because he’s a brilliant problem solver. He even runs his own department at the hospital.

Every episode is a masterclass in how to solve complex problems.

The #1 rule of problem-solving

There’s a line Dr. House says almost all the time:

“Everybody lies.”

That’s why Dr. House doesn’t like to see patients. He only trusts brain scans, blood tests, and other exams.

Let me ask you this:

How many times have you received a bug report and Customer Support claimed they had verified logs, reproduced steps, and validated user data… And after hours of debugging, you realize the real problem was something they had claimed to have checked in the first place? Arrggg!

If you ask Dr. House, everybody lies:

End users lie.
Documentation lies.
Customer Support lies.
Other engineers lie.
Even you and I lie.

Always trust but verify.

That’s Dr. House’s #1 rule to solve problems.

House M.D has conflict and drama with excellent storytelling. But it also teaches powerful problem-solving lessons. I expand on what Dr. House has to teach us as coders in my book, Street-Smart Coding: 30 Ways to Get Better at Coding.

In my book, I suggest watching a TV show and hanging out in cafes to become a better coder. Yes! Because coding isn’t just syntax and speed. It’s also thinking like a doctor with complex cases.

Grab your copy of Street-Smart Coding here

7 Unconventional (But Surprisingly Effective) Ways to Get Better at Coding

2025-10-26T00:00:00+00:00

Junior-me was obsessed with syntax.

Ten years ago, coding only meant learning languages. I was learning C#, keeping up with PHP, and sneaking into Python. I thought coding was only about symbols and lines of code.

But to grow as coders, you need more than learning syntax and typing symbols. Here are 7 unconventional ways to grow as a coder:

#1. Detach yourself from your code. You’ll write simpler code and become a better teammate. You’ll let others touch, critique, and work on your code.

#2. Reinvent the wheel to learn. It forces you to read, dissect, and really understand code. Try rebuilding one of your favorite libraries and tools. Just to learn, once you’ve understood how they work, stick to the real one.

#3. Do on-call at least once. Being paged after hours isn’t a pleasant experience. But you’ll learn to triage, debug, and stay calm under pressure. And more importantly, to communicate with non-technical people.

#4. Watch House M.D. This isn’t a TV show about coders or hackers, but about doctors. It’s a masterclass in problem-solving. You’ll see how they tackle complex problems until they find a solution. More useful than most coding classes.

#5. Learn to write. Not lines of code, but clear, direct prose. Writing sharpens how you present ideas and solutions. That’s why every coder should write. And it’s no surprise the higher up you climb the ladder, the less it’s about coding and the more about communication.

#6. Start and monetize a side project. A side project will teach you:

Marketing and sales
How to think like a builder
Hosting and the Cloud aren’t free
End users don’t care about clean code

#7. Learn polite ways of saying no. You’ll need this a lot. You will have to say no to unneeded complexity, scope creep, and burnout.

If you want to stand out as a coder, you need more than mastering syntax. Nobody ever taught me that starting out.

That’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding, the roadmap I wish I had on my journey from junior to senior. Because the best coders don’t just type. They collaborate, build, and solve.

Grab your copy of Street-Smart Coding here

5 Lessons from My Team's Architect That Helped Me Become a Senior Developer

2025-10-25T00:00:00+00:00

I used to be a problematic team member.

I delivered my tasks late. Sometimes I worked late fixing bugs and finishing my tasks on the sprint’s final day. That was in my second job.

My previous job was in a non-tech company. I wasn’t used to Scrum, deadlines, and working as part of a development team. In this job, I had to work hard just to keep up.

After a year or two, I had the chance of working next to the team’s architect. Maybe that was part of a performance improvement plan and nobody told me. Who knows?

I learned a lot from my team’s architect. He became my mentor, although I never explicitly asked him to. Here are 5 lessons I’ve learned from him:

#1. Read for 1 hour.

My mentor spent ~1 hour after work going through blogs, Reddit, Hacker News, and other news sites. Often, he arrived at work saying, “Hey, check out what I found yesterday.”

Apart from staying up to date, there was a real reason behind that habit.

Sometimes, the CEO, who used to be a coder, arrived at the office asking my mentor, “Hey, did you read about…?”

I remember my mentor telling us, “It can’t be that, being the architect, the CEO asks me about something and I don’t know how to answer.”

You don’t have to know it all, but always find time to learn.

#2. Struggle first.

Apart from being the architect, my mentor was the “team enabler.”

He told us, “If you’re still stuck after one hour, come back and ask for help.” He didn’t answer immediately, he made us struggle first, so the answers would stick.

That’s the same trick I use when I help others.

#3. Read code.

No coding class taught me the value of reading code.

My mentor was the one who taught me. He read the source code of almost all libraries and tools we used. That’s how he knew about their hidden features or undocumented behavior.

Reading code was how my mentor learned from the best.

#4. Simplify problems.

Break down coding problems into one-liners, just like movie plots.

Instead of “a complex async system,” say “a queue and a processor.” It helps you present and explain complex ideas, especially to non-tech people. Helpful to keep the larger picture when coding too.

#5. Don’t be a one-trick pony.

I remember my mentor saying, “Imagine an architect who builds the same house over and over.”

For him, every project was a chance of learning. Don’t build the same thing twice. Of course, there’s nuance here. Don’t suffer from shiny object syndrome either.

After more than 5 years of working with my mentor, I’ve kept the habit of setting aside time to read. I use idle moments to scan headlines and see what’s going on in the tech world.

My mentors taught me lessons that college or bootcamps don’t teach, like how to ask for help, read code, and say no politely. I’ve included some of those lessons in my book, Street-Smart Coding: 30 Ways to Get Better at Coding.

That’s me passing on the lessons my mentors taught me and the ones I’ve learned on my own. That book is my way of mentoring you to help you to grow and code like a pro.

Grab your copy of Street-Smart Coding here

Friday Links: Seniority, RFC, and websites

2025-10-24T00:00:00+00:00

Hey there.

Here are 4 links I thought were worth sharing this week:

#1. Junior me wanted to refactor everything around me to follow “conventions.” Mid-level me worked extra hours and on weekends to prove I was “committed.” The thing is as we get more senior, all those implicit expectations change (5min). They often make you lose trust.

#2. Early developers didn’t have StackOverflow or YouTube or ChatGPT. They relied on “skill, curiosity, and persistence.” Wow! I found a post about RFC (13min), (the documents with the building block of the Internet), but I found a manifesto for coding creativity.

#3. As AI-generated content floods social media and the whole internet, we need places where there’s still a human touch. And that might be your own website (4min).

#4. These days, we all agree on one thing: there’s too much hype around AI. It’s the new tool in town promising to kill coders. But that’s not the majority view on AI (5min) and someone dares to say it out loud.

And in case you missed it, I wrote on my blog about AI being a sloppy junior coder (2min) and my 5 writing principles for consistency (2min).

(Bzzz…Radio voice) This email was brought to you by…

Ten years ago, I thought coding was only about syntax and languages. I was wrong! It’s about collaboration, communication, and skills far from the keyboard. That’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding, the guide I wish I had on my journey from junior to senior.

Grab your copy here

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.

My AI Manifesto: How I'm Using AI

2025-10-23T00:00:00+00:00

On August 27th, 1997 the world as we knew it changed.

Skynet became self-aware.

That was almost 30 years ago. Maybe Terminator 2 wasn’t just a movie, but a documentary. Who knows? But while we wait for nuclear destruction, humanity’s extinction, or simply Universal Basic Income, here’s my statement on how I use AI:

I use AI for coding (but with some rules)

After a few days with AI, I was becoming dependent, even for simple tasks.

That’s why I don’t recommend new coders rely on AI to generate code, but use it as a learning aid. And that’s also why I’ve put some rules:

I don’t swear by AI. It’s far away from replacing coders. But coding will look different in 10 years. Well, it already look different.

That’s for coding. But for writing, my approach is different.

Zero AI for writing

I write every word here and elsewhere. All of them. By a human. Me.

I use AI to proofread and edit my words. I’ve replaced Grammarly (at least the basic, free version) with a simple prompt.

I used to make posts eye-catching with AI-generated images of humanized cats doing everyday tasks. Who doesn’t like cats? But after changing my approach to blogging, I stopped using images and covers on my posts. So no more AI cat images.

When social media and the whole Internet get flooded with soulless, dull AI-generated content, I’m also in the small crowd standing up with stories, an authentic voice, and a message worth reading.

I’m in the “if you don’t care to write them, why should I care to read them?” team. We don’t need another AI-generated post starting with “In today’s world…”

Senior Devs Google Too: Here Are 7 Things I Search All the Time

2025-10-22T00:00:00+00:00

I just wanted to reply with a link to letmegooglethat.com. But that felt rude.

I had received a WhatsApp message late at night. It was a friend’s sister, a junior backend developer. She asked how to extract an IP address from a request in an old WebForms app.

Instead of the “let me Google that for you” answer, I replied saying it was part of the HttpContext object or something. “You’re better off Googling, I can’t remember,” I said.

As juniors, we think we are expected to memorize every single method, command, and option from the standard library, frameworks, and tools. That’s not true.

Unlike exams and interviews, when coding, you can use Google or ask ChatGPT.

Here are 7 things I always have to Google:

#0. Diffing two Git commits or branches. I Google this every time I want Copilot to review a code block.

#1. Undoing stuff with Git. How to undo a commit or unstage files. Is git undo a valid command?

#2. Formatting numbers. Is it myNumber.ToString("C") or with "F"? I can’t remember.

#3. Formatting dates. Even when I came up with my own mnemonics, I still have to look it up. How many f for milliseconds?

#4. Anything AutoMapper-related. Just this week, I Googled how to ignore properties again. When using AutoMapper, I often end up pulling up my own TIL posts or going down a rabbit hole in StackOverflow.

#5. Parsing numbers. Does a cast work? Is it ToDouble() or double.Parse?

#6. Anything about enums. How to list all enum members. How to parse from an int to an enum. How to print a member name. But since I’ve started using SmartEnum, I haven’t looked back to “normal” enums.

As a coder, Google is your friend. Learn to search, find your own answers, and ask for help when you’re stuck. Even with AI, these three are the most important skills for new coder.

That’s why I made those three the first strategies in my book, Street-Smart Coding: 30 Ways to Get Better at Coding. That’s the practical guide I wish I had on my journey from junior to senior. Because coding isn’t about memorizing syntax. It’s about knowing where to look, and how to learn.

Get your copy of Street-Smart Coding here

My Biggest Mistake as a New Coder (Nobody Warned Me)

2025-10-21T00:00:00+00:00

“Focus on one thing,” a coworker used to tell me. But I didn’t listen.

I was in my first job about 10 years ago. I was learning C#, catching up with PHP, and reading about Python. I remember going through Hangfire documentation without knowing how I’d use it.

Like most new coders, I suffered from shiny object syndrome.

I was focused only on mastering syntax

At that time, for me coding was only about syntax, symbols, and languages.

One day, my boss called me to his office and I arrived late because I was “coding.” He lectured me that day. And I deserved it. Looking back, I’m surprised I didn’t get into more trouble.

And to make things worse, I picked Clean Code. By the time I finished it, I had become a Clean Code cop. I started to look for violations around me. Every piece of code had to follow the book.

Wrong! Wrong! Wrong!

The hard lesson: Coding isn’t only about syntax

Yes, coding is about syntax. But it’s more than just typing symbols.

Most coding happens away from a keyboard: in meetings, brainstorming sessions, and on whiteboards. You’ll spend a lot of time talking to non-tech people, negotiating deadlines, and managing change.

Junior me didn’t know that. And by trial and error, I had to learn the lesson. Getting fired was part of it.

Learning more languages will grow your toolbox, but it won’t necessarily make you a well-rounded coder. Work on your collaboration, clear communication, and writing skills too.

I wish someone had told me that when I started out. And that’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding. Because coding is more than typing symbols fast.

Get your copy of Street-Smart Coding here

AI Is More Like a Sloppy Junior Coder With Bad Memory

2025-10-20T00:00:00+00:00

We’re still far away from the dream of coding in plain English.

One single video isn’t enough proof, but here’s one from someone who has given up on AI coding:

Among other reasons, he quit AI coding for two main reasons:

#1. AI has stolen all the joy of coding. He isn’t figuring things out by himself. No more aha moments or victory dances when using AI.

#2. Even with “perfect” prompts and workflows, LLMs’ output is unreliable. AI comments tests out to “make them pass,” writes passing tests by tweaking edge cases…

LLMs aren’t really like a fast junior coder. They’re more like a lazy, sloppy, stubborn junior coder who suddenly needs to be taught again.

I haven’t tried AI that much myself, like the guy in the video, but I don’t swear by English as the de facto programming language.

I still want to tackle business problems. I want to design code and solve tricky bugs. That’s the fun part. I don’t want AI to kill it.

I don’t want AI to take away my coding skills. I want AI’s help but I stay in control.

I just want AI to do the boring part: generate syntax once I’ve done the thinking part… and hopefully escape endless Scrum meetings.

With AI taking fast code generation off the table, it’s time to double down on real skills: problem-solving, clear communication, and many more I cover in my book, Street-Smart Coding: 30 Ways to Get Better at Coding. Because being a good coder is more than mastering syntax.

Get your copy of Street-Smart Coding here. It’s the guide to leveling up my coding skills I wish I had when I was starting out.

After 600 Posts, These Are My 5 Writing Principles for Consistency

2025-10-19T00:00:00+00:00

I wrote my first blog post in 2018. Well, it was more of a word vomit pretending to be a coding tutorial.

I’ve been writing a daily post since November 1st, 2024. And in the last year, I’ve written over 300 LinkedIn posts.

By pure accident or luck, I made my first $1 online thanks to my writing.

After all these years, I’ve adopted the following 5 guiding principles to keep writing:

#1. If it helps one person, hit post.

You don’t need to write to the masses. Just to one person. And that one person could be your past self.

#2. Give something and give it fast.

In 17ms, we decide if we keep reading or move on. Credits to Small Brevity.

Online writing (emails, social media posts, or blog posts) isn’t fiction. People expect a long detailed description of scenery and dialog in a novel. Even in fiction, if your story isn’t moving fast enough, readers will put your book aside.

Get to the point! Nail your headlines and work on your opening lines. Cut the long intros.

#3. Write as if nobody’s reading. Keep writing because you never know who is.

Writing feels lonely when you start.

The cure? Write for your younger self. Write what you wish you had known 2 years ago.

#4. Don’t wait to become an expert. Write to become one.

If you wait to become an expert, you’ll never write while putting in the 10,000 hours.

Instead, write to learn. Document your journey. Teach as you go.

#5. Intention gets you started. A system keeps you showing up.

Writing can feel easy, especially with AI. Consistency is the real challenge.

Find ways to capture ideas and turn them into posts.

In the end, intention starts the journey. But attitude, systems, and habits keep it going.

8 Things You Should Never Apologize For (or Feel Guilty About)

2025-10-18T00:00:00+00:00

Here are 8 things I believe you should never feel bad about, no matter what:

#1. Saying no. To negativity, toxic relationships, bad jobs… To anything your gut instinct doesn’t like.

#2. Choosing an unproven path. There’s a default plan set for you if you don’t choose yours.

Go to college, get a job, work hard, keep your head down, and retire. That worked for our parents. Not anymore.

It’s okay to start a small business, create content, or freelance instead of following the 9-5 path.

#3. Putting yourself first. If you don’t take care of yourself, nobody will. And life is often like airplane safety measures: put your oxygen mask on first, before helping others.

#4. Buying books. From I Will Teach You to Be Rich by Ramit Sethi, I learned to cut what we hate and spend on what we love. If that means buying books, so be it.

#5. Avoid spending on luxury items. Who needs the expensive watch, designer clothes, or fancy wallet? Often, people go into debt to pay for those items. And if it doesn’t put money into your pockets, it’s a liability. (Credits to Poor Dad Rich Dad.) And it’s okay to cut it.

#6. Traveling. Apart from visiting new places, traveling teaches you new languages and to expand your horizons. The world isn’t like your small town. People don’t think like you. And that’s okay.

#7. Being single. I don’t remember where I heard it, but most people start relationships simply because they feel alone. For that, it’s better to find a hobby or new friends than to start a relationship that might hurt someone.

#8. Promoting your own work. Sometimes we debate sports, politics, or why Apple phones beat Samsung phones, but hesitate to promote our own work. Like it or not, we’re selling all the time. And if we don’t sell something, we’ll end up selling our time. And we’re not going to like it.

Friday Links: Politics, highlighting, and death of coding

2025-10-17T00:00:00+00:00

Hey! Hope your week’s been good.

A quick update on my book, Street-Smart Coding:

I’m done addressing feedback from my beta readers. Turns out I had forgotten about a references section. Arrggg!

I’ve reread my draft countless times, still afraid of typos. My next step? Design the interior of my book. Quick update over.

Now, the 4 links as usual:

#1. A corporate job is a game of politics. (Just try to make a change in your company.) Here’s a guide on how to play and influence the tech company politics (8min).

#2. Like any new coder, junior-me spent hours tweaking my IDE with themes and extensions. Eventually, I settled down to the Solarized theme. And more recently, while looking for a simple theme for live coding and code samples on my books, I found Alabaster and the rationale behind it (10min). When everything is highlighted, nothing really stands out.

#3. Plastic bags killed basket-making. Is coding next? Is coding becoming a dying craft? (3min) No clear answer, just food for thought. For sure, coding is evolving. We’re not punching cards anymore. Maybe, in the future we won’t be typing symbols like we do now.

#4. Often great coders get promoted to management, to stop coding eventually. But what if a promotion meant going deeper instead of moving up and out? (6min).

And in case you missed it, I wrote on my blog about the one rule I use to code with AI (to avoid losing my skills) (2min) and the best bad coding example I’m using in my book (2min). Coming up with a good bad example is surprisingly hard, but I think I nailed one.

(Bzzz…Radio voice) This email was brought to you by…

Preorder Street-Smart Coding here (pay what you want just for these days) and read 5 of the 30 strategies just to start. If you’ve ever typed “how to get better at coding” on Google, YouTube, and more recently on ChatGPT, this is for you.

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.

Two App (or Browser Extension) Ideas to Make Writing and Journaling Easier

2025-10-16T00:00:00+00:00

Feel free to build these two ideas. I’m not afraid to share them. I’m an idea machine. Steal them.

#1. A browser extension to avoid hitting “Post” or “Publish.” Not to stop me writing, just to avoid clicking Post instead of Schedule. Handy for Medium or LinkedIn or any other content platform.

It’s the second or third time I’ve sent an email meant for the next day. I clicked on Post instead of Schedule. Arrggg! Nothing wrong happened. I just don’t want to appear in people’s inboxes like a desperate creator, begging for money.

#2. A simple online app (or page) with a target count of bullet items. Recently, I found the 100 thoughts challenge (write 100 thoughts in less than 20 minutes). Credits to Iban Van der Zeyp on Medium.

To finish that challenge, I thought of The Most Dangerous Writing App. You set a word count or time limit and if you stop typing before you hit that target, it erases everything. Gone! Forever. What about something similar with a target bullet point count? And each double Enter adds a new bullet point to the list.

Maybe those two are good weekend coding challenges to play with AI. If you build one, I’d love to hear about it.

The Real Reason Why Some Dev Companies Are Forcing AI

2025-10-15T00:00:00+00:00

I haven’t stumbled upon any client or company forcing me to use AI.

That’s not a reality for everybody in the industry. Today I found this Reddit post from a coder who has lost interest after being forced to use AI, even he was tracked:

“Within the span of maybe 2 months my corporate job went from “I’ll be here for life” to “Time to switch careers?” Some exec somewhere in the company decided everyone needs to be talking to AI, and they track how often you’re talking with it. I ended up on a naughty list for the first time in my career, despite never having performance issues. I explain to my manager and his response is to just ask it meaningless questions.”

That post rang a bell! It reminded me of a conversation I had recently.

The real driver isn’t productivity

These days, I caught-up with some of my ex-coworkers, and one story stood up.

After the usual chit-chat, one of them shared that his company was encouraging them to use AI, not so strong like the guy from Reddit. Maybe productivity was the official reason.

But the real reason? Turns out, one of the company founders was also investing in an AI startup. And guess which AI tool they were encouraging people to use.

Just like I found the other day, if you think of AI as just another subscription company pushed for profit, all the hype starts to make more sense.

The real driver isn’t productivity, but financial interest.

It’s easy to get caught up in the AI hype and forget coding is more than shipping crappy lines of code fast.

But coding is also about clear communication, thoughtful problem-solving, and knowing when to say no. None of that shows up in AI usage metrics.

And that’s why wrote, Street-Smart Coding: 30 Ways to Get Better at Coding, to share the skills I wish I’d learned earlier, the ones that help you become a confident, hype-proof coder.

Get your copy of Street-Smart Coding here

The One Rule I Follow to Code with AI (Without Losing My Skills)

2025-10-14T00:00:00+00:00

I haven’t blindly jumped on the AI hype train. But I’m no hater either.

AI is here to stay. That’s why I’ve tried AI to offload tasks while coding. But after a few weeks, I was so AI dependent I couldn’t write a simple LINQ query. So I decided to stop relying too much on AI and adopted this one rule:

Use AI outside my IDE or editor.

When I’m coding, I like to think I’m a surgeon in an operating room, and AI is my assistant doctor. They hand me tools and monitor my patient, but I’m always in charge.

To stay in control, I never let AI into my editor. I use it in a browser tab.

It might seem slower or old-school. But it forces me to decompose my problem and extract relevant code for AI. And once I have an answer, it forces me to make it work on my side. At least, I know if the output actually works.

Just like code you find on StackOverflow or anywhere else online, don’t use what AI gives you if you don’t understand what it’s doing.

Don’t let AI touch your code directly either.

AI is faster at generating code than us. No doubt! But being a good coder isn’t about typing fast. It’s about estimating, communicating with non-tech people, and many more skills I’ve included in my book, Street-Smart Coding: 30 Ways to Get Better at Coding. That’s the roadmap I wish I had when I was starting out.

Grab your copy of Street-Smart Coding here and start building future-proof coding skills today.

The Best Bad Example I'm Using to Teach Clean Code Principles in My Book

2025-10-13T00:00:00+00:00

Finding good bad examples is hard.

I’ve worked with ugly codebases that I don’t want to revisit. But copying and pasting from them isn’t a good idea. Apart from privacy issues, complex business rules and convoluted code blocks make them unusable for tutorials or lessons.

A good bad example needs to be messy enough to teach from, but not so broken it confuses readers.

Movies and TV are great teaching domains

Since we have all seen a good movie or gone to the cinema, I’ve shifted to movies and TV shows. They’re familiar enough to use as examples.

In fact, for my book, Street-Smart Coding, I chose a ticket pricing example that was clear but messy enough to teach a lesson.

Here it is:

// Simple ticket price logic
float CalculatePrice(MovieTicketRequest request)
{
    var ticketBasePrice = 40f;

    if (request.Date.DayOfWeek == DayOfWeek.Saturday
        || request.Date.DayOfWeek == DayOfWeek.Sunday)
    {
        ticketBasePrice = 50f;
    }

    int reduction = 0;
    if (request.Date.DayOfWeek == DayOfWeek.Tuesday
        || request.Date.DayOfWeek == DayOfWeek.Wednesday)
    {
        reduction = 25;
    }

    if (request.Age < 10)
    {
        if (request.Date.DayOfWeek == DayOfWeek.Saturday
            || request.Date.DayOfWeek == DayOfWeek.Sunday)
        {
            ticketBasePrice /= 2;
        }

        var finalPriceChildren = ticketBasePrice * (1 - reduction / 100.0);
        return (float)Math.Ceiling(ticketBasePrice);
    }

    var finalPrice = ticketBasePrice * (1 - reduction / 100.0);
    return (float)Math.Ceiling(finalPrice);
}

A method that prices movie tickets by day and age. Simple enough to highlight common issues, like duplication and branching logic, but not so complex that I need to explain its business rules.

That code block makes you say “Whaaaat?!!?” in more than one place, but what would you refactor first? Can you spot the bug?

Street-Smart Coding: 30 Ways to Get Better at Coding isn’t exactly about clean code. It’s a roadmap with 30 strategies to level up your coding skills. Writing code for humans is just one of them.

Because coding isn’t simply typing symbols fast and mastering syntax. Real coding is also about clear communication, thoughtful problem-solving, and knowing when to say no—and 27 skills more that I cover in the book.

Get your copy of Street-Smart Coding here

A Simple but Effective Test for Your Online Content Business

2025-10-12T00:00:00+00:00

Yesterday, I shared the Article Funnel method, a simple strategy to write content that sells.

And to test your content-based business (and that method) works, you need to pass the $1-dollar test. That’s another lesson from Mark Thompson, apart from the Article Funnel.

If what you write generates at least $1 in sales, you have a system that works. You already have posts with a compelling CTA that lead to a landing page for a product readers find valuable. It means you have the right copy and the right setup.

With all that in place, from then on, you need to volume and consistency.

The Simple Method to Turn Every Post Into a Sales Machine

2025-10-11T00:00:00+00:00

If you’re afraid of selling, you won’t get a dime.

But to sell with your content, you don’t have to resort to banners, invasive popups, and countdown timers to trick people into buying.

From Mark Thompson, a veteran marketer I followed on Medium, I learned the Article Funnel method to turn every post into a sales funnel.

Here are my takeaways from his method and from following him:

#1. Promote something in every post. That’s what Mark does in every post. At the end of his posts, there’s a CTA to a related offer.

I stopped being afraid of promoting anything in every post when I learned that’s the method famous creators use to make millions online.

#2. Give away something valuable in the post. It’s so annoying when you open a post titled “10 ways/tips/lessons to…” and when you open it, you only find one or two items and you have to buy something to access the rest. That’s how you lose readers.

Don’t be afraid of giving something. That makes you the source of answers. And we always go back to the one who helps us.

#3. Use a natural transition to introduce your offer. I used to put a divider at the end of my post before adding my CTAs. They felt like an appendix, most people ignored.

Instead, the Article Funnel suggests to naturally introduce your offer with a transition paragraph, without sounding salesy or desperate. Something as simple as “if this resonates with you, you’re going to like…where I …”

No tactics or tricks, just helpful content that points to a related offer. That makes your content into a sales representative working 24/7. And that’s the method I’m using from now on to promote my own products.

Friday Links: FP twisting the Web, LLMs, and nostalgia

2025-10-10T00:00:00+00:00

Hey!

Here are 4 links I thought were worth sharing this week:

#1. A couple of years ago, I challenged myself to learn React. And being a backend developer, I missed the simplicity of the old days: Just some logic inside the script tag to bind forms. It turns out adopting functional principles shaped and twisted the frontend ecosystem (20min). It has made us reinvent the wheel. Again.

#2. LLMs replacing human devs? Well, here are two tasks LLMs are still bad at (2min). Maybe they’re more like “weird, overconfident interns.”

#3. It’s never 5 minutes… when you snooze your alarm, when your manager asks you a quick favor, or when you think you can stretch hours of work right before clocking out. Here’s a productivity tip (4min) to avoid that “5 minutes” turning into working extra hours.

#4. For nostalgia or history, here’s how the Internet looked in 2000 (8min).

And in case you missed it, I wrote on my blog about how to keep creating when it feels pointless (1min).

(Bzzz…Radio voice) This email was brought to you by…

I’m currently putting the final polish on my book, Street-Smart Coding: 30 Ways to Get Better at Coding.” While I finish up, you can preorder your digital copy and read a preview featuring 5 of the 30 tips, just to get you started.

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.

Steal This Strategy: How to Work with Beta Readers to Launch Your Book

2025-10-09T00:00:00+00:00

I stole the process of working with beta readers. Borrow it, let’s say.

I’ve been a technical editor for Manning, a publishing company that specializes in coding books. And after going through the process twice, I copy their process to work with beta readers for my next coding book.

Here’s what I did.

#1. Have something decent to share. Beta readers are the first eyeballs that read your draft. You don’t need a polished or finished book, just a decent draft someone can read. It’s OK if there are typos here and there. The goal isn’t to line edit it, but to refine the overall book structure and content.

#2. Create a list of 10 people that can help. I’m a fan of 10-idea lists, so that was an excuse to write another one.

I asked LinkedIn connections and friends for help. I used Google Docs to share the draft. Manning has a custom platform for that. I did it the DIY way.

I shared half of my draft (15 of the 30 chapters I had planned) with half of my beta readers, and the other half to the rest. I didn’t want to overwhelm them with too many pages. They’re busy and helping for free.

#3. Offer something in return. This is a strategy I copied from Manning. I offered a free digital copy, a mention in the Acknowledgments section, and a shout-out in a LinkedIn post on launching day. Well, Manning doesn’t offer a shout out. I did.

#4. Ask for specific feedback. I asked them not to focus too much on typos or grammar issues.

Here’s a list of questions I asked my beta readers to answer after their review.

What did you like the most? What did you like the least?
Any repetitive parts? Boring parts? Confusing parts?
Any factual errors?
Does the content deliver on the book promise?
What can I do better? What should I include or remove?

I put those questions on page one of the Google Doc.

#5. Share a deadline. I forgot to tell my beta readers my launch date. Some of them gave feedback after a couple of days. Others never shared anything. I guess they were busy and I didn’t set a deadline. My bad!

And here’s the best piece of advice I’ve found: Listen to what beta readers say is wrong, but don’t rely on them for how to fix it. That’s your job as the writer.

How to Keep Creating When It Feels Pointless

2025-10-08T00:00:00+00:00

The first days of writing or creating anything online are the hardest.

Nothing seems to work. Nobody seems to care. You feel like what you’re doing is pointless.

I know that feeling. Just a couple of my coworkers read my first blog posts. And when I started on LinkedIn, two likes and one comment felt like going viral.

But to endure that phase of obscurity, Jeet Mehta shared three points. The second one really resonated,

“Your audience is just you, pushed outwards.”

You are your own audience. Create for your past self. Write a book for who you used to be. Write the tutorial or guide you wish you had found. Create to help one person. And that one could be your past self.

Don't Write the Next Atomic Habits. Write Mini-Books

2025-10-07T00:00:00+00:00

You don’t need a publisher and 100,000 words to write a book that matters.

Chris Stanley was the one who finally debunked my ideas about writing books. He’s the author of 20 Amazon best-sellers. He lives off his books, traveling around the U.S. in a boat. He’s the “Mini Book” guy and now he teaches how to write them.

Today I attended a workshop with Chris, where he showed a glimpse of his method. Here are 10 lessons I learned:

#1. Don’t think of funnels, think of a flywheel. Think of an ecosystem of content, with mini-books at its core, that changes people’s beliefs and turns them into fans.

#2. Forget about writing the next New York Times best seller. When Chris started publishing his books, he noticed his shorter books did better. It’s not a coincidence. 75% of people don’t finish the books they buy.

The solution? Write mini-books. Just the good parts of a traditional book.

#3. A mini-book offers one solution to one problem for one person. Your solution should be something you’ve tried and proven yourself. The more specific your person, the better.

#4. A mini-book should be SMART:

Structured: It should be well structured and easy to follow.
Mini: A word count isn’t the goal, but a mini-book usually has between 10-15K words. Write a book readers can finish in one or two hours.
Actionable: It should offer a solution your readers can apply immediately.
Repeatable: It should present a message easy to remember and share.
Transformational: It shouldn’t only teach something, but should change beliefs.

For example, Chris’ Mini Book Model has only 129 pages and he breaks down his model so you can write a book in days, not months.

#5. There are only 3 people to write a book for:

Who you were: That’s your past self. Maybe that’s a first-time business owner or a junior coder.
Who you are: That’s your current self, your identity, and what you do now.
Who you love: That’s someone you care about and want to help. Chris once wrote a book for his wife. And we could write a book for our future generations.

#6. Write a clever title and a clear subtitle. Once you have a problem and solution, your title should create a hook and your subtitle should create a promise. For example, Mini Book Model: How to Write Your Big Ideas in Small Books

#7. There are three ways to outline a book:

W’s: That’s the what, when, where, why, and how. Write a chapter to answer each question. For a book about mini-books, the first chapter could be what a mini-book is. The next chapter, why write a mini-book.
Step by step: Write one step of your solution per chapter.
Problem/solution: Each chapter presents a problem and offers a solution.

Again, in Mini Book Model, Chris used the W’s technique to present his mini-book concept.

#8. Make your solution memorable. If you’re using the step-by-step outline technique, use an acronym or a visual metaphor to guide your readers and help them remember your solution.

#9. As a bonus, use chapters of your next book as preview. It makes your book thick enough to display your name and title on the spine.

#10. Not only write books, but create a whole identity and brand around them. After 20 books or more, Chris is the “Mini Book” guy. His emails, tagline, and even book titles use the same concept. Mini-books everywhere. That’s how he stands out.

Mini books have become my go-to way of sharing ideas in coding and personal growth. If you’re curious, you’ll find my books here.

7 Quick Steps to Edit Your Posts Fast (In Minutes, not Hours)

2025-10-06T00:00:00+00:00

Do a first pass, looking for typos
Use Grammarly or an AI prompt to check grammar
Tweak the headline and opening and closing lines
Look for sentences to simplify
Use a text-to-speech tool and listen to it at 2x
Look for opportunities to link to related posts or resources
Enjoy, you’ve just saved hours and polished your post!

What Happened Around This Day In My Blog

2025-10-05T00:00:00+00:00

My blog is my time capsule. Today, I opened it to find out what I was into. Here’s what I found.

In 2020, exactly on this date, I wrote about comparing dates without the time part in SQL Server. At that time, I was learning SQL Server performance tuning with Brent Ozar’s courses and his writing style inspired most of my SQL posts.

In 2022, I was contracting with an American client and we were trying to implement DDD in their new projects. I shared my notes on the book Hands-on Domain-Driven Design with .NET Core.

And in 2023, I was already compiling four interested links about coding every Monday. That was the seed to later start Friday Links.

At that time, I was playing the SEO game. I can notice it: I wrote question/answer posts with a bolded paragraph answering the post question. I was hoping to win the target answers on Google search results. Since then, I moved away from the SEO game and changed my blogging strategy.

I Could've Finished My Book in Half the Time—If I'd Known These Two Lessons

2025-10-04T00:00:00+00:00

It took me 131 days to finish the first draft of my next book.

That’s 4 months and 8 days from creating a new file to typing the last word. I could have finished two books in that time. James Altucher challenges his podcast listeners to finish a non-fiction book in 30 days. By that standard, I could have even finished four.

Looking back, two lessons could’ve cut that time in half.

#1. Make it a priority

At some point, finishing the first draft felt like a mission impossible.

I was balancing multiple projects at the same time: I was blogging, growing my LinkedIn account, staying active in a ghostwriting community, and coding on the side.

After realizing I was exhausted from juggling all those projects, I focused only on my blog and the draft to keep momentum, even when all other projects suffered.

#2. Take one step a day

Of course, writing a book is a daunting task. It’s worse when you try to finish multiple projects.

Some days, life gets in the way and you can’t write. But take a small step toward finishing your book every day. Maybe it’s finding beta readers, scrolling Amazon for cover inspiration, making promotional material, or running a poll on social media to choose a title.

One small action every day. That’s all you need. Even if that action is not writing. Your book will thank you. And I would have finished my book in half the time.

Friday Links: Junior lessons, side projects, and AI

2025-10-03T00:00:00+00:00

Hey there.

Today I have 3 short links for you:

#1. Here are 10+ points a coder wishes he knew as a junior (4min). I can’t disagree with his take that coding is the easy part of the job.

#2. Not sure about finishing a side project or starting a new one? Ask yourself these questions (2min).

#3. I’m still trying to figure out how to use AI for coding. Here’s “an imprecise, slow and terribly painful way to get things done” with AI and what to do instead. (2min)

And in case you missed it, I wrote on my blog about 4 ideas to buildl a code review culture your team will love (4min) and how to preserve our loved one stories (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.

7 Fresh Alternatives to LinkedIn's Most Overused Cliché

2025-10-02T00:00:00+00:00

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.

The Simplest Way to Make Our Loved Ones Stories Live Forever

2025-10-01T00:00:00+00:00

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.

The Surprisingly Effective Way to Promote Your First Book

2025-09-30T00:00:00+00:00

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.

4 Ideas To Build a Code Review Culture Your Team Will Love

2025-09-29T00:00:00+00:00

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.

The Writing Lesson a Friend Taught Me (and He's Not a Writer)

2025-09-28T00:00:00+00:00

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.

Six Clever Writing Tricks in Netflix's Black Doves

2025-09-27T00:00:00+00:00

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.

Friday Links: Leading, vibe coding cleanup, and performance

2025-09-26T00:00:00+00:00

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).

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.

A Masterclass in Opening Lines from a Nobel-winning Writer

2025-09-25T00:00:00+00:00

I have a new writing obsession: Noticing and dissecting the opening lines of books.

I should blame James Altucher, one of my favorite writers, for this obsession. His advice taught me to master opening lines by dissecting the best fiction writers.

And this time, to apply that lesson, I studied Of Love and Other Demons by Gabriel Garcia Marquez, a Colombian writer who won a Nobel prize. He’s a master of opening lines. And this one is no exception.

An ash-gray dog with a white blaze on its forehead burst onto the rough terrain of the market on the first Sunday in December, knocked down tables of fried food, overturned Indians’ stalls and lottery kiosks, and bit four people who happened to cross its path. Three of them were black slaves. The fourth, Sierva Maria de Todos los Angeles, the only child of the Marquis de Casalduero, had come there with a mulatta servant to buy a string of bells for the celebration of her twelfth birthday.

OK, that wasn’t just an opening line, but a paragraph. Let’s break it down:

#1. This intro starts with huge drama. A dog is creating an unbelievable mess in the market. It has a white blaze on its forehead. This detail becomes relevant later. But no spoilers.

#2. It uses the rule of three to present the disaster the dog created:

“knocked down tables…”
“overturned Indian’s stalls…”
“bit four people…”

#3. It presents the main character in the middle of the action. That is Sierva Maria. The dog also bit her. This is the starting incident of the entire story.

We also learn more about Sierva. She’s the daughter of a Marquis and she’s about to turn 12. And she’s placed among slaves and servants. Another detail that becomes relevant later.

The formula? Drama followed by a character trapped in the middle of it.

re: How to Lead in a Room Full of Experts

2025-09-24T00:00:00+00:00

Being the smartest in the room doesn’t mean you’re ready to lead it.

Doing a job well isn’t the same as leading others who do it. Being a soccer player isn’t the same as being the team coach. They need different skill sets.

Ibrahim Diallo makes a good point about leading a room full of experts. Here are three of his points and my reactions:

In a room full of experts, your technical credibility gets you a seat at the table, but your social skills determine whether anything productive happens once you’re there.

I learned this lesson in meetings with the CEO and other executives at a past job.

It was at a small tech shop in my city. I was a Software Engineer I, first of five “ranks” in the company’s career ladder. My hard work gave me a seat on the table. I don’t recommend hard work anymore.

The CEO was a coder turned businessman. Sure, he understood a lot of jargon and technical details. But most of the time, he replied with “I don’t care” or “You’re insane” when we dropped technical terms.

By trial and error, I learned to translate technical language into business language.

Your goal is to find the right person for each task

Your value [as a leader] isn’t in having all the expertise. It’s in recognizing which expertise is needed when, and creating space for the right people to contribute their best work.

I’ve seen it all around me. A newly promoted coder who still acts like a rock star, doing all the work. Focusing on lines of code and pull requests instead of projects, milestones, and team dynamics. That’s a recipe for burnout for the leader and failure for the team.

The perfect example of good leadership and delegation comes from the movie Ocean’s 11 and its sequels.

In every movie, there’s an impossible item to steal. Of course, that’s never a solo job. It takes a team. The leader presents the challenge and a solution plan.

But each team member brings their expertise: the locksmith to open a vault, the social guy to extract valuable intel from a person of interest, the gymnastics guy to break into impenetrable rooms, and the explosives guy to create a distraction.

Follow the same idea from Ocean’s 11, but replace the robbery with a project and all specialties with the right ones.

Be comfortable not having all the answers

The more comfortable you become with not being the expert, the more effective you become as a leader.

A business book taught me: a good entrepreneur should manage and lead a team of people way smarter than themself. The same is true for teams in charge of knowledge work.

As a tech leader, learn to lead people smarter than you. Otherwise, you will always lead a team of junior people. A good leader finds the right person for the right job and makes them thrive.

The First Step to Reinvent Your Life (When You Feel Lost)

2025-09-23T00:00:00+00:00

Today, I found a post promising an “upgraded” roadmap for growth in life.

I found it in a LinkedIn post. I know. LinkedIn is a weird place. Full of shallow advice and “see my perfect routine” posts. I’m not sure which category this post belongs in. I won’t link to it.

It showed a comparison between the outdated and the upgraded roadmaps for growth.

The outdated roadmap was to find a job, work for 40 years, and retire. I completely agree. I wish I had learned that lesson 10 years ago. But the first step in the upgraded roadmap was to “Get clear on your goals in life.” Easier said than done!

How do we “get clear on our goals”? Figuring out what we want in life is hard.

An easier start on the upgraded roadmap

Last year, I was burned out and I was laid off.

The corporate world disappointed me. It squeezed all the passion I had until the very last drop. I was so lost that imagining a new life felt impossible.

I still don’t know what I want in life. Maybe just waking up energized to work on something I love and being content and present every day.

But what helped me recover from burnout and “get clear in life” was to focus on my physical and mental health. I didn’t know what to do next. No career plan, no new job. I only knew I didn’t want to stay the same.

My reinvention phase started with a YouTube workout session, writing 200 words, and a moment of silence every day… And reading books from people who had gone through something similar, like Borja Vilaseca and James Altucher.

James’ books taught me that we don’t need a master goal or passion, whatever that means, to reinvent ourselves. We already have one goal, one passion: taking care of ourselves. That’s an easy place to start and maybe the most important one.

Focusing on my health was the foundation of my reinvention after burning out. That’s why it became Idea #1 in 10 Surprisingly Simple Ideas That Changed My Life And Could Change Yours Too. A collection of tiny daily actions that actually change your life.

7 Surprising Lessons I Learned While Writing and Launching My First Book

2025-09-22T00:00:00+00:00

I have a new writing challenge: I’m writing a book. One about how to improve our coding skills.

I’ve had to change my mind about writing books. I used to think I needed a 10,000-word, fully-researched book. But reading 21 Lessons for the 21st Century showed me that a book could be a compilation of scattered ideas.

Finishing the first draft is the beginning. Designing and selling it comes with their own challenges. Here are 7 lessons I’ve learned to design and sell a book so far:

Interior design

#1. Start every new chapter on a right-hand page.

#2. You can design a book’s interior with Word or Google Docs. But Reedsy Studio automates a lot of the boring tasks.

Interestingly, Reedsy only supports writing a book in English. You can change the spellchecker language, but I couldn’t find a way to change the copyright notice and front matter. So we’re back to Word for other languages.

#3. The copyright page is boilerplate you can find online. Reedsy does it for us with a few clicks.

#4. Write your author page in the third person.

#5. Invest in a professional cover design. People do judge a book by its cover.

Promoting and selling with Amazon

#6. Amazon doesn’t require an ISBN for the Kindle and provides a free one for paperbacks. But you can’t use it elsewhere.

#7. Pricing starting points:

$0.99 is the new free
$2.99 for the Kindle version
$9.98 for the paperback version

#8. To follow Amazon’s rules, you can ask for reviews inside your book. But you can’t include external links to your book page.

I'm Writing a New Book to Help You Improve Your Coding Skills

2025-09-21T00:00:00+00:00

I’m celebrating a small victory today: I finished the 1st draft of my next coding book.

Street-Smart Coding: 30 Ways to Get Better at Coding.

Its promise? 30 proven tips to get good at coding. Some are conventional. Some learned the hard way. And a few… weird ones. But all battle-tested.

Why I wrote it?

I went to a 5-year program to learn coding. Actually a bit longer because I had to write a stupid dissertation. But anyway…

My real coding journey started with one Google search: “how to get good at coding.” I found lot of contradicting advice. That Google search put blogging under my radar. And that’s why I started my own blog.

It took me years and trial and error to find out what really works from all that free Internet advice.

That’s why I wrote this book. Well, I’m still editing it. So you don’t have to go down the same rabbit hole.

I wrote it for the younger me, sitting back at my first job reading any tutorial he could find. Full of passion and no direction.

These are the lessons I wish I had when I was starting out. The lessons I learned over 10 years of coding in tech companies and software agencies, making plenty of mistakes.

Preorder your copy here to read a preview featuring 5 of the 30 tips, just to get you started.

The Frustration of A Day Without Reception (I Wish I Were Analog)

2025-09-20T00:00:00+00:00

I just had lunch. I’m standing in front of the counter to pay. But my bank app keeps loading.

I toggle airplane mode to make my phone reconnect. That’s how a coder fixes anything, right? Restarting everything… No luck. I had no choice but to pay with the last bucks I had.

With only two bars, I try to find the address of the closest Government office I need to visit. That’s why I had crossed the city. My browser shows a painfully slow progress bar. I only have two hours left before the office closes. It’s a Friday. This year the President passed an order to reduce the working schedule of all Government offices. I ask for directions. You know, anyone can get to Rome asking for directions, as we said in my hometown.

***

I make it to the office. Turns out, I wasn’t that far. It’s the first time I’ve done that errand. I need a copy of an official document. I explain what I need to the guy behind a protective glass. There are cameras on every corner. He tells me I need the document ID and the expedition date. I have them on my email. Oh, I can’t log in. Another loading animation. The guy tells me the major phone operator has had network issues all day long. He can’t use his phone either.

With less than one hour left, I start to walk around. I remember an old Internet room from my college days nearby. After walking around three blocks, I find the place. It’s a small shop with four old PCs to access the Internet. It felt like the early 2000s, accessing my Messenger account to chat with my friends using funny animations. I could access my email account to get the ID and the issuance date of the document I wanted copied.

***

I rush back to the Government office. I know I have to accept what Life sends me. But I’m not enjoying what I have in front of me. I slip a paper with the document ID and date under the protective glass. “These are the right numbers, but this wasn’t registered in this office.” Arrggg!

All that chaos just because I didn’t have reception. All I needed was a yellow-page phone book, pocket money, and a notebook instead of a smartphone connected to the Internet. Maybe analog wasn’t that bad after all.

Friday Links: Programming deflation, story points, and vapers

2025-09-19T00:00:00+00:00

Hey there.

Here are 4 links I thought were worth sharing this week:

#1. With the raise of AI, we’re in a programming deflation (5min). “We’re watching the basic economics of software development transform in real time.”

#2. Typing isn’t (and hasn’t been) the bottleneck of coding. AI is making us thinkers instead of typers (4min).

#3. One of the things I hate about software engineering is estimation and story points. And guess what? Story points answer nothing (4min).

#4. And here’s how someone hosted a website on a disposable vaper (6min). Cool!

And in case you missed it, I wrote on my blog about the hardest lesson I learned migrating legacy code (again) (2min) and the one rule junior coders should follow to adopt AI (1min).

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.

The Hardest Lesson I Learned Migrating Legacy Code (Again)

2025-09-18T00:00:00+00:00

I definitely can’t escape from legacy code.

This time, it’s an old WebForms application written in VB. Yes, that old. It’s a family business. Dad started it. And years later, his two sons got involved. It’s funny when during the standup meetings I hear, “Hey Dad…”

The problem

The code is a mess. Sorry, I mean it needs a lot of care.

I don’t blame them. It was the easy route with WebForms. Just drag and drop, double-click, and dump all your logic. It’s just like that framework encouraged people to copy and paste.

I’ve worked with at least 3 legacy apps with WebForms. All of them were pure spaghetti code. Zero best practices. “Coincidence? I don’t think so.” (Insert Toy Story character wearing a chicken suit)

The code needs care, but the database needs even more attention.

It doesn’t have foreign keys, and queries don’t use JOINs. If you want to join two tables, one of them has a string column with a list of IDs separated by a pipe (12|34|56). You fetch records separately and then loop through them to join them. Arrggg!

And please, let’s not talk about stored procedures…

The lesson

But from this project I’ve learned that if we don’t pay close attention to the initial database design, the backend side gets wildly crazy. A lot of hacks and patches to make up for a poor DB design.

There’s no need to go crazy with database normalization. Just:

Every table should have an auto-incremented ID.
Use a separate table instead of a column with a list of IDs.
Keep data types consistent across tables. All “Status” columns should be either BIT or an INT. Otherwise, conversions could go wild.
Add audit fields (“createdAt” and “updatedAt”) to every table.

I wish they had followed those simple guidelines 10 years ago.

But more surprisingly, I learned that you don’t need a perfectly clean codebase to have a successful business. You will suffer? Sure. But running a business and writing good code are two completely separate skill sets.

The freshly graduated me thought I was only going to always create systems from scratch following all principles and practices to the tee. But working with legacy code taught me more than any coding course.

That’s why I made it one of the 30 proven strategies in my book, Street-Smart Coding: 30 Ways to Get Better at Coding. That’s the roadmap I wish I had when I was starting out.

Grab your copy of Street-Smart Coding here

The Simplest Way to Validate a Product Idea (Without Wasting Time and Money)

2025-09-17T00:00:00+00:00

A long time ago, a friend asked me for a quote on a custom piece of software.

She and her friend wanted to start a marketing agency. And they wanted to build custom software to run it.

The problem? They didn’t have any savings or capital. And even worse, they didn’t have anyone to sell their service to. It was too early to build software.

I’ve been there too, on a different scale, coming up with value propositions and website copy for a freelance business I didn’t have yet. Later, it died with a single phone call.

After immersing myself in business podcasts and books, I’ve learned to:

Come up with simple and cheap experiments to test a business idea
Slap a price tag on whatever we’re building to see who buys

And simple experiments can validate big ideas.

The other day I watched a Diary of a CEO episode featuring a Netflix cofounder. How they validated their idea? He mailed a CD to his business partner to see if they could run a Blockbuster alternative by email. It was a cheap experiment. It worked.

Run experiments to learn, to grow, and to build something people really want.

7 Content Experiments I Ran in August—and What Happened

2025-09-16T00:00:00+00:00

Back in August, I shared 7 content experiments I wanted to try.

As part of my daily routine, I write 10 bad ideas every day to keep my creativity muscles in shape. I wrote 10 ideas that day, but only posted 7.

I acted on some of those ideas. Here’s what I actually did:

#1. I redesigned the interior of my C# Idioms book. For the first version, I used Canva. Nothing wrong with Canva. But I wanted a more professional, less hobbyist design. So I added a copyright notice, an introduction, a table of content. The basics of a publishable book. Now, it’s available for $0.99. Next move? Offer it via Amazon.

#2. I uploaded all my coding courses to Gumroad. I have to admit the experience of Gumroad as a student isn’t as polished as Udemy for video courses. But it works well enough to show a video lesson with a description. Now, they’re available here: C# NullReferenceException Demystified, Getting Started With LINQ in C#, and Mastering C# Unit Testing with Real-world Examples.

#3. I packaged all my beginner’s material into the “C# Fundamentals Bundle.” That’s an ebook and more than 2 hours of video lessons to learn C#, at 20% off. It’s available here: C# Fundamentals Bundle.

After launching these, I notice a challenge: Gumroad doesn’t have a powerful discoverability feature. As creators, we can’t simply rely on Gumroad showing our products to users. At least, we shouldn’t expect it. We have to redirect traffic there ourselves. Now, my only source of traffic is my newsletter.

#4. I changed all prices to end in .99 and increased the suggested prices., I offer my books and courses as “Pay what you want.” I’ve received $1, $5, $7, $10, and $20 as payments. So I changed my current prices based on those anchor points.

Results? 10 free downloads and no sales. Not that bad. I learned about interior book design and practiced my copywriting skills. That’s helpful for any future project.

Junior Coders: The One Rule You Should Follow to Adopt AI

2025-09-15T00:00:00+00:00

“Is using AI totally forbidden?”

“When and how should I use it?”

“What’s your take on vibecoding?”

I was on a firechat with a community of new coders last week. Those questions kept popping up. They all wanted to know about AI.

I get it! There’s a lot of noise:

AI is taking our jobs.
“%X of code is generated by AI at $BigCorp.”
Some guy shared on Twitter/X that he built an app with no coding skills and now he’s retired, drinking martinis in the Caribbean.

Don’t be discouraged by those headlines. (There’s a lot of nuance behind them.) We’re living in the best time to learn coding.

You won’t like it, but…

Here’s the rule:

Don’t use AI to generate code until you’re comfortable coding on your own.

If you only copy and paste what ChatGPT, Cursor, or $NewestFastestLLM gives you, you’re in trouble. You need to know if what that tool is spitting out is good code. And for that, you need your own judgment.

When in doubt, think of AI as a powerful calculator in math class. It makes you faster, but you still need to know how to solve equations. The thinking part is still yours.

AI can spit out code in seconds, even with a bad prompt. But coding is more than syntax. It’s also about teamwork, clear communication, and problem solving. That’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding, a practical guide to the skills that actually make you a better coder. It’s the roadmap I wish I had when I was starting out.

Get your copy of Street-Smart Coding here

3 Health Habits to Live Longer—from the Man Trying to Live Forever

2025-09-14T00:00:00+00:00

His name is Bryan Johnson and he has one single obsession: to stop and reverse his aging.

His obsession has led him to turn his apartment into a $2.5M science lab. He measures and tracks hundreds of markers to check if he’s getting closer to his goal.

He has the discipline of an Olympic athlete: eats only 2000 calories, takes 111 pills, and works out for one hour. Every. Single. Day.

He’s 45. But he’s aging as fast as a 10-year-old boy. (We don’t think of aging when we imagine a young boy). He beats his teenage children in almost any sport and aces any fitness competition with straight A’s.

His goal has attracted the media attention. Netflix has a documentary about him: Don’t Die. And you can find plenty of interviews on YouTube.

I watched his documentary and the interview on the James Altucher Show, here’s what I learned:

#1. Identify your self-destructing behaviors

The Big Mac and the 2-hour binge-watching on Netflix after work are coping mechanisms to run away from the life we hate.

That’s your mind looking for forms of pleasure. Learn to identify the self-destructing self and separate mentally from them. “Here it comes, the destructive Alice. Hi! I don’t need you around.”

That was Bryan’s first step before embarking on his goal of eternal life.

#2. Sleep 8 hours and eat well

If you don’t have $2.5M to turn your apartment into a lab, start taking care of your sleep and diet.

Here’s Bryan’s 80/20 for wellness:

Go to bed at the same time.
No light in your bedroom.
No alcohol.
Eat less.
Eat more nutritious foods.
Don’t eat before going to bed.

You don’t need plasma transfusions like Bryan. Rest and pay attention to what you put into your body.

#3. Live a steady life

Be like a high-performance athlete: focused on your body and mind.

Protect your mind by staying away from cheap dopamine like Candy Crush, news, social media, and smartphones. And, don’t use screens before going to bed. It ruins your sleeping patterns too.

After following his regimen for two years, Bryan has changed so much Face ID has had a hard time recognizing him. Maybe you don’t want to adopt a strict lifestyle to live forever, but if you want to age well, start today, not at 70 when it’s too late.

Well, it turns out I’m not that far with my healthy habits. I’m only 45 extra minutes of exercise, 99 pills, and a science lab away. But hey, we all start somewhere.

A 4-Step Framework (for Podcasts and Interviews) To Answer Questions Like a Pro

2025-09-13T00:00:00+00:00

A recent podcast interview was the perfect excuse to ask for feedback on my interviewing skills.

I’ve been putting more attention on my communication skills, but never asked for feedback. So I reached out to Ryan Alexander Wiens, a coach who helps engineers speak clearly and show impact, showing him one of my answers.

Here are two suggestions Ryan gave me. I’m sure he doesn’t mind I’m sharing them here:

#1. Slow down at key words and pause for emphasis. It’s hard to sound confident while answering well. Pauses give us time to think and create a sense of expectation for the listeners.

#2. Answer with PREP: Point/Reason/Example/Point. To answer questions confidently, I learned to start and end with the main point.

But to make our answers more impactful, add a “Why” or a reason after the main point. Then to end the answer, restate the question with the main point again. We tend to remember only the beginning and end, so win-win! We look more confident and help the listener remember our answer.

So let’s say we’re asked about the mistakes beginners make in terms of branding. Following the 4-step framework we could say:

(Point) I’d say one of my biggest mistakes has been not to start earlier.

(Reason) Building a brand has brought me great opportunities, like this interview… I wish I had started sooner.

(Example) If I had to start right from scratch again, I’d…

(Point) That was my mistake and the mistake most beginners make: waiting too long to start.

Now thanks to Ryan’s PREP framework, you’re PREPared for your next podcast or job interview. Pun intended.

Friday Links: Programming pearls, hating AI, and formatting

2025-09-12T00:00:00+00:00

Hey there.

Before the usual 4 links, a quick update about my book.

This week, I finished another four chapters. But there’s still work to do.

I haven’t chosen a final book title, but what about 30 Ways to Get Better at Coding? What do you think? Does it sound interesting?

And… Here are 4 links I thought were worth sharing this week:

#1. Forty years ago, Programming Pearls was released, a collection of hard truths about coding. But are they still relevant? Here’s a breakdown of those pearls (20min).

#2. Here’s why the guy who stopped the largest cyberattack in history hates AI (30min).

#3. Want to understand the AI hype? It’s not a technology, but a subscription company (6min).

#4. Speaking of coding in the old days, here’s how ADA handled code formatting (4min).

And in case you missed it, this week I was invited to a firechat session with the LAX Africa community to discuss how to land a first job. Here’s a summary of the session (5min).

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.

15 Takeaways From "Breaking in the Mindset That Gets You Hired" With ALX

2025-09-11T00:00:00+00:00

This week, I had the chance to share some of my career lessons with the ALX Africa community.

I joined Shehab Abdel-Salam, a Senior Software Engineer at Proofpoint, to share the mindset shifts needed to land a coding job for the first time.

Here’s the recording of the session—In case you want to watch it, there’s some back jokes:

And here are 15 takeaways from the session—In case you don’t want to watch the recording:

Career Growth

#1. Identify your gray zones vs growth zones.

A gray zone is doing comfortable work. And a growth zone is doing work that stretches your skills.

To grow your career, do the things that scare you. Comfort zones kill growth.

#2. Forget the corporate ladder.

Hard work alone doesn’t guarantee results.

Instead of chasing the corporate ladder, define your own success metrics and climb your own ladder.

#3. Stand out at work by doing the work nobody else wants to do.

And make sure you’re able to do it.

By the way, that’s only one way to stand out besides hard work. Here are another 9.

#4. Be aware of cultural expectations when working remotely.

Coming from LatAm, when I started working with American companies, I missed the chitchat and off-topic conversations before starting meetings. The American way is direct and to the point.

#5. As a junior coder, stand out by showing you’re able to learn new subjects and follow instructions.

As a senior coder, it’s the opposite. You stand out by showing you don’t need many instructions.

#6. Rely on your personal and professional network to look for your first job.

Shake hands online and offline and skip the hiring lines.

Over ten years ago, I didn’t apply through a job portal to land my first job. I knew someone who knew someone who made an introduction. Then when I left my first job (fired actually), my ex-boss arranged an interview for me. That’s the power of your network.

It sounds like a cliche, but your network is your net worth.

#7. Listen to feedback, say thanks, and act on it.

Avoid the temptation of explaining and justifying your behavior.

Writing

#8. Writing online is one of the most rewarding skills for your career.

It improves your research and communication skills.

For example, my blog has opened many career opportunities. Thanks to a link to my blog on my CV, I turned a failed interview into a content collaboration… And I made some lunch money.

#9. Your writing and online presence can replace your portfolio.

Every time you finish a project (or move to another job or achieve a milestone), write about the lessons you learned and what you would have done differently. And showcase those posts in your LinkedIn profile or CV.

#10. If you’re completely new to writing, start with a worklog.

If you have only written README files for your GitHub repos, you don’t need to write deep dives.

Start with “Today I Learned” posts. That’s exactly how I started writing. My very first post ever was a word vomit pretending to be a coding tutorial about Aspect-Oriented Programming in C#. (I’m so embarrassed by that post, but I still keep unedited to remind me how I started).

Document what you’re learning and the resources you’re using. That’s the easiest way to start writing.

Technical Skills

#11. Build simple apps and projects to practice.

Or even clone existing apps and some of their features.

#12. Understand you don’t need many programming languages to be a good coder.

You can make your way with HTML/CSS/Javascript, one backend language (JavaScript counts here), and SQL.

#13. Read engineering blogs:

#14. Embrace the struggle.

It’s part of the learning process.

When you’re stuck with a coding problem, don’t rush to AI for a quick answer. Try solving it yourself and don’t hesitate to ask for help.

#15. Don’t be scared of AI.

Use it wisely. Otherwise, your coding muscles could atrophy.

If you’re starting out, keep learning and having fun. This is the best time to learn coding. Always be a beginner.

Starting out or already on the coding journey? Join my free 7-day email course and refactor your coding career–I distill 10+ years of career lessons into 7 short emails.

This Simple Word Change to Reveal What AI Really Means

2025-09-10T00:00:00+00:00

AI is the new buzzword of the day.

Add “AI” to a company or product name to join the hype. It’s all over the news. AI is the new contender for coders. Yes, we coders are always the ones being replaced.

But Ibrahim Diallo made a good point in his post AI is Not a Technology, It’s a Subscription Company:

Swap “AI” for “subscription company.” And all AI those headlines make more sense. “%X of code at $BigTech is generated by a $SubscriptionCompany” has a new meaning.

AI isn’t a product we own. It’s subscription companies profiting off our data. And that isn’t innovative or disruptive at all.

4 Tips to Avoid Rushing to Code (and Building the Wrong Thing)

2025-09-09T00:00:00+00:00

You spent days on your JIRA ticket… only to be told to redo it after your team lead reviewed your code?

A few years ago, I was working on a hotel management tool. My team lead asked me to redo an apparently trivial task. I had to store emails before sending them. It wasn’t a full rework, but I had to change my approach. We had completely different expectations from the same task. Two days of work almost wasted.

If I had only asked one single question before starting… “Hey, I’m doing it like this, are we on the same page?”

If you’re like me, eager to jump into the code, confident in your solution, hold your horses and follow these four tips:

#1. Always ask why. Don’t start coding if you don’t understand what needs to be done. Ask: Why this task? What’s the real problem? Why solve it now?

#2. Read the existing code before starting. Your changes might be simple, unless you have to refactor some legacy code first. If you rush to code without knowing that, you’ll give the wrong impression you’re taking too long on a simple task. Yes, estimates are hard.

#3. Outline your solution with comments. Start by sketching your plan in comments. That’s your blueprint. Of course, once you’re done, don’t forget to delete them.

#4. Write a one-page spec. Draft a summary of the changes you need to implement, just for yourself. It’s for you to think clearly before writing a single line of code.

A simple question would have saved me from wasting two days of work. Make sure everyone agrees on your solution before you start. It could save you from building the wrong thing.

It’s better to annoy people by asking too many questions than by making mistakes for not asking any questions at all. Strive for context before coding. Always.

I cover 30 lessons like the one in this post in my book, Street-Smart Coding: 30 Ways to Get Better at Coding. That’s the roadmap I wish I had on my journey from junior to senior.

Grab your copy of Street-Smart Coding here—Because typing isn’t the hardest part of coding, but knowing what to type.

8 Reading Habits I Learned from Ryan Holiday, the Stoic Book Master

2025-09-08T00:00:00+00:00

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.

The Simple Rule Behind Joe Rogan's Podcast Success

2025-09-07T00:00:00+00:00

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.

Don't Learn Prompt Engineering. Here's What Matters More

2025-09-06T00:00:00+00:00

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.

Friday Links: Best engineers, AI failures, and simple things

2025-09-05T00:00:00+00:00

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).

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.

Two Proven Strategies For Faster Code Reviews (Learned From Dozens of Pull Requests)

2025-09-04T00:00:00+00:00

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.

I'm Bragging About a LinkedIn Recommendation That Made My Day

2025-09-03T00:00:00+00:00

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.

What an Old Photo Album Taught Me About Tech

2025-09-02T00:00:00+00:00

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.

My 300 Daily Posts Reflection

2025-09-01T00:00:00+00:00

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.

Here are some of the most-read posts from the last 100 days:

Here are my 100-post and 200-post reflections.

The Easiest Way to Preserve Our Stories

2025-08-31T00:00:00+00:00

It’s been so relieving and therapeutic listening to many of my mom’s stories.

My aunt pulled down an old photo album. I was full of joy seeing old photos of my mom as a teenager.

The next day, my sister and I sat down to talk to my mom’s best friend. They meet at 3rd grade and were friends since then. I loved hearing all their child adventures, school days, and teenage loves.

I was surprised by how many stories I heard. Some of them I didn’t even know.

Those two experiences reminded me that the best way to make an impact and preserve our stories is with a book. And for that, we don’t need a best-seller.

Six Pieces of Advice I Wish I Had Known Before Going to College

2025-08-31T00:00:00+00:00

I met a mom and her young girl about to start college. Like most teenagers, she was struggling to choose a major in college.

I was no different. I didn’t know what to choose either. My problem was that I had too many options. I’ve struggle to choose a single passion since always.

I ended up picking the major the dislike the least.

Here’s what I wish I had known before going to college:

Understand you don’t have to go to college. If decide not to do so, you’d have to come up with your own alternative plan. Maybe start a business or self educate.
Find an intersection between subjects you like and subjects with “employability” options. Again, understand you don’t have to follow the traditional path and go to a 9-5.
Don’t simply choose going to college and a particular major just because your parents did the same. Don’t simply go to med school, just because your dad is a doctor.
Learn as many skills you can. Among those, learn a manual skill: how to cut hair, make desserts…
Have as many options along side to going to college. Try to answer what if you don’t get accepted at XYZ college to major in ABC. What would you do then?
Understand you don’t have to stick to a single career for life. In this day and age, we have to reinvent ourselves way more often than our parents.

Friday Links: Developers' block, databases, and APIs

2025-08-29T00:00:00+00:00

Hey, there.

I had a really busy, long, and heart-breaking week. I only could curate 3 links for you this week. Here they are.

#1. Often, the hardest feeling for a writer is sitting in front of a blank page. That’s what we know as writers’ block. But what about developers’ block (8min).

#2. Here’s a breakdown of how databases actually store data (16min).

#3. Most of our time as backed coders is writing RESTful API, here’s how to do it (21min)

And in case you missed it, I wrote on my blog about how TikTok is a bad life coach. Not much coding this week on my blog

(Bzzz…Radio voice) This email was brought to you by… Check my C# Fundamentals Bundle, two easy-to-follow video courses and a practical ebook—now at a 20% discount. With the essential tools every new coder needs to start writing clean and professional-grade C# code.

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.

The Saddest Post I've Ever Had to Write

2025-08-28T00:00:00+00:00

This was supposed to be a 300-day post celebration. But it turned out to be the toughest post I ever had to write.

After five years fighting with chronic kidney disease and two weeks in the hospital, one of the most important people in my life, my mom, passed away a few hours ago.

I’m writing this with tears in my eyes and a deep hole in my soul. We all know these moments will come at some point, but nothing and no one prepares us for them.

Today I want to remember mi mamá with a whole lot of gratitude.

Thanks mom:

For teaching me faith
For fighting so strong for so long
For showing me love and kindness
For being the best mom you could ever be
For sacrificing your career to raising me and my sister
For worrying about me even when you were sick in a bed too
For staying up with me to study through the night
For being there for me when I was sick
For all that you sacrificed for me
For the 62 years you were with us

I will always remember you, mamá. All that I am and what I have is because of you.

In the loving memory of Rocío Romero, the best mom God, Life, and the Universe could have given me.

We’ll see you again soon.

PS: If heaven is real, there must be a welcoming party there today.

I Failed to Follow This Writing Principle (and Didn't Get Some Blood)

2025-08-27T00:00:00+00:00

These days a loved one needed a blood transfusion.

My first instinct to look for donors was to write a WhatsApp status for my friends and contacts to see. I wrote something like,

“Urgent! Blood donors needed. O+. DM for more info.”

But then I realized I made the #1 mistake of writing and copywriting. I made the message about me, not about the readers. Anyone reading would ask, “What’s in there for me?” There was nothing for the reader.

After realizing my mistake, I wore my copywriting hat and changed my message,

“Has you done your good action of the day? Donate blood. It only takes a few minutes, you get a souvenir and have the chance of saving a life. DM me and I’d tell you how to help.”

That’s a copy written in favor of the reader, not of the writer. Because good copy and good writing is always about the reader.

There's No Such Thing As Real Writing. All Writing Is Real

2025-08-26T00:00:00+00:00

For so long, I was afraid of putting “writer” on my bio online.

I was full of self-doubt. “I don’t have thousands of followers.” “I don’t have a novel.” “I’m not even an English native speaker.”

Even after years of blogging, calling myself a writer was an impossible goal. Maybe because I pictured writers as Hemingways retreating to an island to return with a Nobel-winning novel.

I wish I had read Mark Thompson’s post challenging the distinction between “real” writing and everything else sooner. It would have saved me so many moments of self-doubt. He wrote,

If your words help someone, teach someone, inspire someone, or even just get them to click “follow,” then they’ve done their job.

If just one person has started writing and managed to change their situation after reading my articles, that is a win.

Stop chasing the “real writer” myth.

If you have helped, inspired, or made someone take any form of action with your words, that’s real writing. It doesn’t matter if it’s a Tweet, a blog post, or a 70,000-word work of fiction. Because all writing that moves someone is real. Period.

Good Ideas Aren't Enough—You Need Execution Ideas Too

2025-08-25T00:00:00+00:00

Since last year, I’ve made a habit to write 10 ideas a day.

That’s a concept I learned from James Altucher. I even followed some of the exercises from “How to Become an Idea Machine,” a book with dozens of prompts to exercise your idea muscles.

Writing those 10 ideas has taught me we need plenty of bad ideas to find a good one. And once we find a good idea, we need ideas to execute it.

Did you come up with a book idea? Great. The next step is writing another 10 to (possibly) make that book a reality. Do you need research? Do you need to compile scattered blog posts? Do you need to test subjects first on social media?

This applies beyond writing books. These days, a neighbor decided to change our main door lock. It was rusty and in poor shape. That was a good idea. But he didn’t let everybody else know and didn’t have enough key copies for everyone. That was bad execution. Good ideas need good execution ideas too.

The Unexpected Lesson I Learned in a Hospital Exam Room

2025-08-24T00:00:00+00:00

I’ve been in a hospital with a loved one more times than I wanted.

Waiting in hospital rooms, I’ve written 10-idea lists, imagined the future of hospitals with AI, and learned some lessons about our bodies.

Before a recent exam, my loved one was so nervous that I had to enter the examination room too. The doctor could have dismissed her as just another nervous patient. But he calmed her down by explaining the possible diagnosis in simple words. That really worked.

When my loved one apologized to him, his answer inspired me. “Don’t worry. This is my job and I do it because I really like it,” he said. You could tell by the way he spoke to his patients. Then he said, “I’m passionate about this. And here, between you and me, the hospital owes me money, but I still keep doing it.”

Unlike my loved one’s doctor, I’m reluctant to use the word “passion.” That’s one of the subjects I’ve changed my mind about as a coder. The corporate world drained it out of me.

But, whether the word passion or not, find something worth showing up for every day, even without pay. That’s what he taught me, even though I wasn’t the one he was treating.

TikTok Isn't a Life Coach Helping You Make Decisions

2025-08-23T00:00:00+00:00

“I saw it on TikTok,” she told me.

I was making small talk with a young girl at a hospital. She wanted to join the military. I asked her why, in a curious way. “It keeps appearing on my TikTok.”

A couple of days ago, she watched one short of another young girl leading a female squad running around a military base. She kept seeing the same videos since then. “Of course, the more videos you watch…they will keep popping up,” I said.

If you stop your endless scrolling to watch a short, the algorithm will flood you with more. “Hey, she just watched the whole short, we’d be better off showing her similar content. She seems to like that type of content.” That’s what TikTok would think. Its job is to exploit our attention and keep us in the same echo chamber.

Don’t make a decision just because TikTok keeps showing you the same videos. That’s not a sign from the Universe. That’s not guidance either. It’s manipulation.

Friday Links: Scams, scaling, and code reviewing

2025-08-22T00:00:00+00:00

Hey there.

Here are 4 links I thought were worth sharing this week:

#1. Typing isn’t the bottleneck (2min). With AI in the mix, it seems we’re optimizing the wrong variable.

#2. Here’s someone who played the game of a scam job interview (20min) and lived to tell about it.

#3. Not all side projects have to scale (3min) or become the next rising Silicon Valley startup. And that’s fine.

#4. If you’re looking for alternatives to code reviews on GitHub, here’s how code reviews can be better (6min).

And in case you missed it, I wrote on my blog about why now is the best time to learn coding (2min) and how to navigate to the root folder of a git repo (1min).

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.

Six Takeaways from 21 Lessons for the 21st Century

2025-08-21T00:00:00+00:00

#1. A book can be built from posts and scattered ideas. I’ve learned that while listening to Yuval Noah Harari discuss the book in a podcast interview. If he can do it, so can we.

#2. “In a world deluged by irrelevant information, clarity is power.” I loved that opening line.

#3. Homo Sapiens thrived as a species because we learned to collaborate. And to collaborate, we created stories. For example, 1,000 years ago, a soccer World Cup would have been impossible. Not because we didn’t have planes, but because we lived in isolated, rival empires and tribes with little in common.

#4. The next device to hack is the brain. Corporations already hack our minds using the data they collect about us. Now imagine the impact of biometric data: Instagram knowing when your pupils dilate and your heart rate changes when dumb scrolling. Most likely, algorithms will make the most important decisions for us.

#5. We need to be more connected to our senses and emotions. We no longer taste the seeds or fruits we once gathered to check for poisons. The old saying “Know Thyself” will be as relevant as it was 2,000 years ago.

#6. The most important skill to learn is meta-learning. The ability to learn how to learn. We’ll have to reinvent ourselves multiple times to adapt. We can’t simply expect to be factory workers for life.

TIL: How to Navigate to the Root Folder of a Git Repo

2025-08-20T00:00:00+00:00

Recently I found myself cding to find the folder with a .sln file. You know to run dotnet commands.

Being a lazy coder, I thought of a better solution with a Bash script. But it turned out to be way easier with a Git command,

$ cd `git rev-parse --show-toplevel`

That would take you to the root folder of a git repo. And since my solution file is at the root, bingo! Kudos to this SO answer.

And the next lazy step was to create an alias,

alias groot='cd "$(git rev-parse --show-toplevel)"'

Et voilà!

Why I Work from Home (It's Not the Pajamas)

2025-08-19T00:00:00+00:00

Today life threw me a curve ball and forced me out of my home office.

It was rush hour and I was still across town. Errands took me so long that I didn’t make it home before 5:00PM.

I waited for 15 minutes next to ~100 people at a bus stop. After watching the time, I asked the lady in front of me, “Is it like this every day or just today?” “Yes! Every day! It’s rush hour,” she said.

I got so desperate that I walked for 10 minutes to the closest bus terminal. Every stop had at least a dozen people waiting for the same bus. At the bus terminal, I waited for ~5 minutes for the right bus.

Forty minutes later, I reached the closest station to home. It felt like a trip to the next city. Then another 5 minutes in line charging my card for tomorrow. And finally, another 10 minutes walking home.

At home, I’d have been getting ready to work out or simply reading a book. And I still don’t get why people ask me if I like to work from home.

Now Is the Best Time to Learn Programming (It's Not Too Late)

2025-08-18T00:00:00+00:00

Today I found this question on dev.to (with a tone of frustration in it):

I’m trying to start learning webdev but I don’t know if it’s too late.

Like investing, planting trees, and pretty much anything else in life, the best time to start was five years ago. But the next best time? Now.

Decades ago, people learned from reference manuals and magazines. Paid for compilers. And suffered with slow and expensive internet connections. You could only access a computer in universities. Having one at home was a complete luxury.

Fast forward to today, your phone has more power than the computer that put a man on the Moon.

Now, anyone can start learning to code by asking ChatGPT for a 3-month learning guide and following YouTube tutorials. All for free.

If you’re asking the same question, don’t be discouraged by AI.

Blame all the misleading headlines. “More than X% of new code at $BigCorp is generated by AI.” More often than not, they’re a marketing strategy from AI companies.

AI is making coding faster and cheaper. Sure.

But most of the real work still happens through collaborating in meetings and discussions, not at the keyboard. AI isn’t replacing coders (for real) anytime soon because coding is about thinking and problem-solving. Typing is just the surface.

And that’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding, a practical guide to the skills that make you a confident, thoughtful coder. It’s the roadmap I wish I had when I was starting out.

Get your copy of Street-Smart Coding here and future-proof your skills.

Re: Why LinkedIn Rewards Mediocrity

2025-08-17T00:00:00+00:00

Elliot Smith nailed it in his post Why LinkedIn Rewards Mediocrity.

It’s hard to disagree with that headline and his main idea. Yes, LinkedIn is a weird place. We do crazy things for a moment of fame or to impress future employers.

I’ve been writing consistently on LinkedIn since 2024, and here are my reactions:

It’s built for virality

Honestly, the best approach is to remember that LinkedIn is a website owned by Microsoft, trying to make money for Microsoft, based on time spent on the site.

Absolutely! Like any other social platform, they want us trapped.

If you have a LinkedIn account, you’ve already received the useless “someone on LinkedIn viewed your profile” email and plenty of others. The more time we spend there, the more ads they show and the more money they make. Our attention is the product they sell.

The feed, the algorithm, and the platform itself are created for virality, not depth. And truth be told, nobody goes to social media for depth. When was the last time you went there for that? We go there to scroll until it’s time to clock out. We might learn something dumb scrolling sometimes.

Social media might offer ideas, but only in 280 characters or a flashy image. Funny enough, my most viewed posts have been listicles and short controversial posts. They crush it on social media. But for depth, we have newsletters and books.

It has good content

Lots of people who write good content don’t live on LinkedIn, they might repurpose things for the platform but they exist elsewhere.

That’s true.

I use social media to test ideas and promote my coding newsletter and blog. No shame in being “salesy.” That’s what most creators do. After all, social media is built for dopamine hits, not depth.

It’s easy to support good content

If you’re more of a consumer than a producer and you want to help make things better the best thing you can do is reward the real stuff. Find those people who aren’t playing the game and promote that instead.

100% agree. If you comment that something is clickbait, you’ll only boost it. More comments = larger audience. Simply ignore that type of content. Engage with content worth spreading. That’s how we can fix the feed.

We've Lost the Joy of Seeing Tech for the First Time

2025-08-16T00:00:00+00:00

The other day, I shared my story of how I met my first computer on dev.to. It resonated with at least a dozen people. From the 1 KB RAM computer story to the grassy hill wallpaper of Windows XP.

All comments had something in common: Seeing a computer for the first time was like a magical moment. For many, changing letters on a screen felt magical 10 or 20 years ago.

Most of us ended up choosing programming because of the mystery and magic of seeing computers for the first time.

Maybe my first encounter with a computer wasn’t that magical. I didn’t know then I’d work with with computers. But I narrowed down all my options until a computer-related one was left. I owe it to my STEM classes and having a computer at home, a luxury for universities and big firms back then.

These days, computers are everyday tools we barely notice. That magic has faded away.

Friday Links: Live coding, spellcheckers, and AI rejection

2025-08-15T00:00:00+00:00

Hey there.

Here are 4 links I thought were worth sharing this week:

#1. One senior developer failed at a live coding interview session. Funny enough, once the interview was over, he solved the exercise. Arrggg! He wrote a breakdown of why live coding sucks (9min).

#2. Here are 50 bits of career advice (12min). Bit#26 is what I call “my code is not my baby.”

#3. It’s interesting to notice how coding has changed over the years. Coding a spellchecker used to be a huge challenge (3min). These days we have plenty of memory, we don’t really care anymore.

#4. This is a coder vs huge corporation story. He wrote a piece of code that a major AI corporation uses. But they rejected him when he applied to work there. He gave AI arms and legs, then it rejected him (7min).

And in case you missed it, I wrote on my blog about the one lesson I wish I’d known when I started coding (2min) and some C# extension methods I stole from Reddit (3min).

Coming soon: the “C# Fundamentals Bundle,” all of my beginner-friendly C# video courses to help you master the language from the ground up. Launching in just a few weeks, so stay tuned!

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.

Forget Perfect Influencers' Routines. Embrace Imperfect Days Too

2025-08-14T00:00:00+00:00

Today, Derek Siddoway’s LinkedIn post deeply resonated.

He wrote that he didn’t work out or sleep early. He shared a honest “didn’t do” list with unhealthy entries: burger for lunch and two cans of Mountain Drew. But he managed to find time to write.

I’ve had a busy week too. I’ve missed my daily practice. I haven’t worked out. And I’ve barely kept my daily streak intact. But like Derek, I found time for one thing that made my days matter: I supported my family when they needed me… and hit Publish.

Imperfect days happen. Ride the tide. One action could turn an imperfect day into a good one. Tomorrow is always new. That’s what I’m learning to do.

The One Lesson I Wish I'd Known When I Started Coding

2025-08-13T00:00:00+00:00

A Redditor recently asked for tips to become a better programmer here. The kind of tips we wish we had known when we started coding.

I’ve been taking a few courses here and there for c# as a side language I’m learning. Curious if you know something I don’t and have tips for making other newcomers a better programmer… Lmk what you wish you could have learned earlier thst would of helped you progress faster!

I already wrote about four career lessons I wish I had known here. But there’s a coding lesson before those four.

You’re not going to like it, but:

Don’t obsess over syntax and programming languages.

Coding isn’t about learning every feature of a language.

You don’t need a huge list of tools to start. With HTML/CSS/JavaScript, one backend language, and a good amount of SQL, you have enough to make your way through the coding world.

You could learn the rest by doing and Googling.

More important than syntax and languages is product thinking.

Instead of obsessing with the best language features, think in terms of the product you’re building.

Ask the questions most coders wouldn’t dare (or care) to ask:

Are we building what users really need?
How will they use our product?
How many users will we have?
How much are we charging?

Ask about marketing, sales, or anything beyond coding. Get interested in the business behind the code you’re writing.

That attitude will make you stand out in any team. It will save you from building the wrong features or optimizing for a scale you won’t have.

Product thinking will open doors to climb the corporate ladder faster.

There’s more to coding than typing symbols on text files.

After 10+ years, I’ve learned that the more senior you become, the less it’s about syntax and the more it’s about how you collaborate, communicate, and solve business problems.

I wish someone had told me that earlier. As a junior coder, I obsessed over learning languages and ignored other valuable skills: product thinking, teamwork, and clear communication.

And that’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding, the guide to the lessons I wish I’d known from day one.

Grab your copy of Street-Smart Coding here.

Starbucks in South Korea Has a Starving Crowd...and They’re Not Serving Them

2025-08-12T00:00:00+00:00

According to fortune.com, Starbucks in South Korea has forbidden their clients to bring desktop computers, printers, and “bulky items.”

After the COVID crisis, Starbucks isn’t just a place for coffee in South Korea, but for cheap coworking spaces.

It reminded me of a lesson from The Boron Letters. That’s a series of letters (turned into a book) he legendary copywriter Gary Halbert wrote to his son from prison. He taught that, to sell more hamburgers, you don’t need the best recipe or location, but a starving crowd.

Starbucks has a starving crowd. Their starving crowd is asking them not only for coffee but for something else. It’s time to pivot, not to forbid that starving crowd to be hungry.

The Mindset Shift I Adopted After Recovering From Burnout

2025-08-11T00:00:00+00:00

By the end of 2023, I had burned out.

I had tied my sense of purpose to my job while forgetting my health and hobbies. That took a toll on me.

To recover, I started with an information diet. No more mindless scrolling, Hacker News, or even music. Just talks from creators who have been through it. Borja Vilaseca was one of them.

Another inspiring figure was James Altucher. I read about his bankruptcies and how he bounced back. I started to follow one of his habits: doing something for my mind, body, and spirit. He calls it: The daily practice.

Since recovering, I’ve embraced a simple mantra: one day at a time.

No matter how tough the day is, trust God (or the Universe or Life) and rest. Tomorrow is a fresh start.

Stop time traveling. Because living in the past makes you resentful, and worrying about the future makes you anxious. Stay present.

Working on my body, mind, and spirit was key to recovering from burnout. That’s why I made it one of the ideas in 10 Surprisingly Simple Ideas That Changed My Life And Could Change Yours Too. A book about the tiny daily actions that actually change your life.

The Worst Financial Tip I Ever Got—and What to Do Instead

2025-08-10T00:00:00+00:00

“Use your credit card only for emergencies.”

Sure, there are good intentions behind that tip. Credit cards have some of the highest interest rates on the market. And, like any debt, they’re a loaded gun. Treat them carefully or they’ll hurt you.

But for emergencies, taking on debt with a high interest rate isn’t a good idea. So how do you prepare for emergencies? With a financial cushion.

The Richest Man in Babylon taught me about a financial cushion. It’s one of the best money books I’ve read. “From every 10 coins you earn, keep 1 and spend the other 9.” That’s how I remember the lesson. That simple habit helped me survive a layoff and even afford a mini-retirement.

Use your credit cards like cash. If you can’t afford it, don’t swipe. Cards are a payment tool, not a source of money you don’t have.

I'm Stealing Some of Reddit's C# Extension Methods

2025-08-09T00:00:00+00:00

Today, I found this Reddit question asking for the lower effort extension methods we’ve written.

And like any real C# programmer, I have my own set of extension methods to work with collections. But I ended up stealing one method from that thread: Choose(). It applies a transformation to a list and only returns the resulting values different from null.

It turns out, Choose() comes from F#’s List type. So my next step was to sneak into F#’s List type and steal some of its methods.

Here they are,

public static IEnumerable<U> Choose<T, U>(this IEnumerable<T> source, Func<T, U?> selector) 
        where U : class
{
    foreach (var elem in source)
    {
        var projection = selector(elem);
        if (projection != null)
        {
            yield return projection;
        }
    }
}

public static U Pick<T, U>(this IEnumerable<T> source, Func<T, U?> selector)
        where U : class
    => source.Choose(selector).First();

public static U? TryPick<T, U>(this IEnumerable<T> source, Func<T, U?> selector)
        where U : class
    => source.Choose(selector).FirstOrDefault();

public static IEnumerable<T> Replicate<T>(this T source, int count)
{
    for (int i = 0; i < count; i++)
        yield return source;
}

public static IEnumerable<T> Singleton<T>(this T source)
{
    yield return source;
}

And here’s a quick example of how to use them,

var movies = new Dictionary<int, string>
{
    { 1999, "The Matrix" },
    { 2000, "Gladiator" },
    { 2008, "The Dark Knight"},
    { 2003, "Freaky Friday"}
};
var years = [1995, 1997, 2010, 2003, 1999, 2000];
years.Choose(movies.GetValueOrDefault)
// "Freaky Friday", "The Matrix", "Gladiator"

years.Pick(movies.GetValueOrDefault)
// "Freaky Friday"

Friday Links: PHP turning 30, reading code, and passion

2025-08-08T00:00:00+00:00

Hey, there.

Here are 4 links I thought were worth sharing this week:

#1. PHP was my first love. I spent countless hours coding a recipe catalog using CodeIgniter to learn coding. To my surprise PHP just turned 30. And after 30 years, PHP has become the Toyota Coralla of programming (9min).

#2. It’s easy to spot AI-generated posts. Just look at the opening sentence. Look for anything like “In today’s fast-paced world.” But what about code? Here’s how to know when someone is vibe coding (3min).

#3. Reading code is an underrated coding skill. These days of too much vibe coding, reading code is the forgotten skill. If vibe coders only read the f*ing code (9min).

#4. What’s the secret behind success? It seems passion has a lot to do with it (2min).

And in case you missed it, this past week I wrote on my blog about how programming is becoming prompting (2min) and 7 life events that deserver a “shower” too (2min). That last one was half-joking. But the business shower doesn’t sound that crazy.

Last week I found out a Brazilian YouTuber translated one of my posts and reacted to it on his channel. I share the video here. Funny things that happen.

Coming soon: the “C# Fundamentals Bundle,” all of my beginner-friendly C# video courses to help you master the language from the ground up. Launching in just a few weeks, so stay tuned!

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.

5 Things Every New Coder Should Watch, Ask, Read, Do, and Pass On

2025-08-07T00:00:00+00:00

While curating this week’s Friday Links email, I found out about Dense Discovery and got inspired.

That newsletter features a section called Worthy Five where a subscriber shares 5 things worth watching, reading, asking…

So I’m stealing (like an artist) that idea, and tweaking it for new coders:

#1. A video worth watching.

Well, it’s more a lecture series. Watch Stanford CS106A on YouTube.

That’s an introductory course to programming. I watched all the lectures in the 2010s while learning to code. I loved the energy of the teacher and the exercises using video games to teach programming concepts.

Watch the first few lectures, you’ll love it.

#2. A question worth asking.

Ask what you want out of your career.

I jumped from job to job without any plan until I got bored or fired. At the end, I burned out after trying to make a “good” job work for me. I never took the time to set an intention for my career.

Come up with a career plan or goal. Remember you can always change it.

#3. A book worth reading.

OK, let me give you two.

First, Clean Coder. I enjoyed this one more than Clean Code. Clean Coder isn’t about writing code, but about being a professional developer. It covers professionalism, unit testing, and estimates.

The other one? Code That Fits Into Your Head. This isn’t precisely a book on syntax, but rather one about programming practices. Its main point? Write code in such a way you can keep its details in your head.

If you don’t know which one to pick first, go with Clean Coder.

#4. An activity worth doing

Write!

I’m biased here. I love writing. But, seriously, write anywhere online. To put your thoughts on paper. To document your learning.

Writing opens doors you can’t even imagine. For example, my blog has done more than a portfolio.

If you don’t know how to start, write TIL posts.

#5. A piece of advice worth passing on

Back at my first job, a coworker gave me this piece of advice:

Imagine you only make half of your salary, save and invest the other half.

Probably the best piece of advice I’ve received for free. Here are another two I never asked. That one helped me survive a layoff. Definitely worth passing on.

Re: Programming Is Becoming Prompting

2025-08-06T00:00:00+00:00

Leon Martin wrote on dev.to that programming is becoming prompting.

And that’s true. The barrier to entry for coding is getting lower and lower.

A few years ago, it was the “Learn to Code” movement. Even Barack Obama replied to a coding question in an interview. One about sorting algorithms.

These days, with AI, anyone is one paragraph away from creating something that works.

Leon made two interesting points in his post:

#1. Too much AI is bad for your health

“…when you start writing prompts instead of functions, you stop flexing those problem-solving muscles that got you into programming in the first place.”

Been there! I’ve been using Copilot during my coding sessions. And the other day, I felt the urge to use AI instead of working through a simple problem.

And that’s the real danger of too much AI. Like the coder who asked on Reddit how to get his coding skills back after vibing for too long.

#2. AI needs the right hands

“Knowing how to code is still the superpower. The prompt is just a shortcut.”

Absolutely! AI is just like calculators in math class.

You could have the most powerful calculator in your hands during an exam, but if you don’t know what you want to compute, it’s useless. You will fail that exam.

AI is like an Iron Man suit. But it still needs Tony Stark inside it to save the day.

Build the coding skills, then use AI to amplify them. Work on your debugging, problem-solving, and clear communication skills.

If you want a guide to sharpen your coding skills, I wrote Street-Smart Coding: 30 Ways to Get Better at Coding. Some lessons are conventional. Some were learned the hard way. And a few are weird. But all battle-tested.

Get your copy of Street-Smart Coding here It’s the roadmap I wish I had when I was starting out.

My Simple LinkedIn Strategy for Growth (Ignoring All Gurus' Advice)

2025-08-05T00:00:00+00:00

Since January 2024, I’ve been growing my LinkedIn account.

As soon as you join the creator crowd on LinkedIn, you step into the gurus’ land with all kinds of advice:

Comment more: Comment for 1 hour a day.
Don’t schedule your posts: Always hit “Post.”
Engage in the first hour to “warm up” the algorithm.

Follow the gurus’ advice, revealed after exclusively deciphering the algorithm, and you’d end up offering comments to the LinkedIn gods, writing your post of the day, and then commenting for another 1 or 2 hours under top creators’ posts to beg for their attention.

After writing over 300 posts, I’ve decided to ignore all those pieces of advice.

Instead, I batch and schedule my posts, and only engage to support fellow creators. And, I also make sure to reply to any comment on my posts.

Because you don’t have to play by anyone’s rules or follow anyone’s revealed secrets. You have to come up with an easy and sustainable strategy to show up consistently. And that’s true not just for LinkedIn, but for any creative pursuit.

7 Life Events That Deserve a Shower Too—Not Just Babies!

2025-08-04T00:00:00+00:00

When you’re a teenager, you get invitations to “sweet 16” or quinceañera parties.

When you’re in your 20s, you get wedding invitations. In your 30s, baby shower invitations.

This week, my best friend invited me to her first baby shower.

That made me think of other types of “shower” celebrations we as adults could host:

#1. A business shower: Guests support your new business by buying your product, leaving a 5-star review, and maybe even donating to cover some business expenses. Maybe a little something to cover your accountant’s fee. Taxes don’t file themselves.

#2. A breakup shower: Guests show up with breakup survival kits: ice cream, wine, a sad playlist, and romantic movies. Or whatever people eat and drink to get over a breakup. Maybe a guest can introduce you to someone or arrange a blind date for you.

#3. A new apartment shower: If you leave your parents’ nest or just get married, you can host a new apartment shower. Guests bring utensils and cleaning supplies to fill your empty new apartment.

#4. A divorce shower: This shower is for turning “that page.” Your guests help you throw away stuff from your past life or simply buy anything that reminds you of your ex.

#5. A college shower: About to start college? Invite your family and friends to help you with… Wondering what college students need these days? Probably notebooks, a laptop and a ChatGPT subscription. And maybe ask for some extra money to pay for the college tuition.

#6. A first job shower: Got your first job? Congrats! Host a first job shower. Guests give you a jacket and tie, help you with a professional headshot to update your LinkedIn account, and buy you a Netflix subscription so you can unplug after a busy day.

#7. A layoff shower: Got laid off? Sorry to hear that. You’re not alone. Host a layoff shower: guests help revamp your CV, write LinkedIn recommendations, or maybe offer a referral. Now that I think about it, this would be like a breakup shower. These days I think pretty much everybody in tech would run this one. Wait if I got laid off more than one year ago, can I still host one? Asking for my LinkedIn account.

7 Fast Content Experiments I'm Running This Month (to Make a Buck or Two)

2025-08-03T00:00:00+00:00

Recently, I learned about the 10,000 experiment rule.

I found it on Skip The Line by James Altucher. That is, instead of aiming for 10,000 hours to mastery, run quick, cheap, and easy-to-do experiments.

Yesterday, as part of my daily routine of writing 10 bad ideas a day, I thought about experiments I could run this month. So here are 7 of them.

#1. Change my LinkedIn bio to include “Ghostwriter.” Often the only thing we need to start with a new offer or service is changing our headline and email signature. I’m changing my LinkedIn headline and bio to start my LinkedIn ghostwriting gig.

#2. Upload my coding courses to my Gumroad store. I offer three C# coding courses on Udemy. The thing is, Udemy keeps students contacts and takes a big cut.

Instead of growing Udemy’s business, I’m hosting my coding courses on my Gumroad store too. I control the course prices and have direct access to my students.

#3. Change all prices on my Gumroad store to end on 99. There’s a lot of psychology research behind pricing. Long story short, products with prices that end in 99 sell more. Let’s see if that’s true.

#4. Instead of giving away some ebooks, charge $1. Or $0.99 to follow #3. I’ve read that $0.99 is the new free for books, given that “free” readers rarely convert to paying ones.

#5. Reformat my free ebooks and point to my paid ones. I’ll add a “From the same author” section to each book.

#6. Increase the suggested prices of all my free products. I offer free books on Gumroad, with pay-what-you-want pricing. I only set a suggested price. I’m increasing that price from $5 to $7. Maybe I can subconsciously influence my visitors to leave a higher tip. Muahaha!

#7. Offer all my C# coding courses on a “C# Fundamentals Bundle.” After following #2 and #3, I’m bundling my C# courses together and offering it for $12.99 or something. If I sell one or two bundles, that’s a win!

Let’s see which ones take off. Either way, I’ll learn something… and keep my daily streak alive.

Portuguese-Speaking Coders: Want to Stand Out at Work?

2025-08-02T00:00:00+00:00

Oi, galera! You don’t need to overwork to stand out in your team.

Paulo Cardoso reacted to my post with 10 tips to stand out at work, sharing his thoughts on his YouTube channel. Well, actually, he reacted to the Medium version.

He translated and expanded on all 10 points. He added more context to each point. All in Portuguese.

Check out his full breakdown below.

Friday Links: Being a good programmer, meetings, and AI

2025-08-01T00:00:00+00:00

Hey there.

Here are 4 links I thought were worth sharing this week:

#1. I had ~5 meetings to decide what to do on each sprint. And I wasn’t doing any rocket science, just boring enterprise software. Meetings are the #1 distraction and a necessary evil. Here’s how to create the ultimate meeting culture (8min).

#2. If you’re a new manager or you want to become one, here’s a down-to-earth guide for new managers (7min). I really liked the coach analogy.

#3. Here’s another way how AI is “killing” junior coders (4min) in the open source world.

#4. If you’ve ever wondered if you’re a good programmer, read this post/reflection. It helps with the impostor syndrome.

And in case you missed it, I wrote on my blog about the business lesson I learned buying a new mattress (2min) and 10 career actions you will never regret (2min).

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.

10 Actions You Will Never Regret Doing for Your Career

2025-07-31T00:00:00+00:00

My corporate journey didn’t come with an instruction manual.

I landed my first job because that’s what everyone does and what I was supposed to do. I joined the corporate world without any goal, other than “gain experience.” Which I did it.

But I was fired from my first job, got bored from my second, and got laid off from my last one. No survival kit or instruction manual. Only trial and error.

If I could start all over again, here are 10 actions I will never regret doing:

Change jobs often
Learn new skills constantly
Set a career goal or intention
Practice hobbies outside work
Build a strong online presence earlier
Invest in coaching, mentoring, and education
Learn a second or third language
Build multiple income sources
Grow a professional network
Have an emergency fund

And more importantly, figure out my own career and plan life instead of accepting the default path. That’s a lesson that took me 10 years to learn.

The Business Lesson I Learned From Buying a Mattress

2025-07-30T00:00:00+00:00

“Sorry, it’s too late. There’s nothing to do,” a salesgirl told me.

The mattress

Earlier that day, the mattress I had ordered was delivered. I was told I should get it assembled and ready to use. But the delivery man told me, “I was hired only to deliver this to you.”

I tried to contact the company by dialing the phone number on the invoice. It didn’t work. It was either wrong or constantly busy. I checked their website for a phone number. No luck!

Then I rushed back to the mall where I bought it. The salesgirl called her supervisor. I wasn’t the only one receiving a mattress in pieces that day.

“If you had called me right away, maybe I could have done something,” she told me. After telling me it was too late, she explained that my mattress was delivered from another city via another delivery company. “Hey, but it isn’t that hard for you to assemble the mattress. It has some instructions inside.” Arrggg!

The lesson

If you promise something on your sales pages, deliver that promise. And make sure everyone involved understands what they need to do to make it a reality.

Imagine KFC handing you raw chicken and telling you, “You can fry it on your own. It comes with a step-by-step. It’s not that difficult.” You would never visit that restaurant again. Just like I’ll never trust that mattress company again.

There’s no secret to business, just promise, then deliver.

The Life Lesson I Learned Doom-Scrolling on Instagram

2025-07-29T00:00:00+00:00

We all know doom-scrolling is the worst.

But recently, I found myself doing precisely that on Instagram. Not every day has to be productive, right?

Out of hundreds of posts, one made me stop scrolling.

It was the video of a girl cleaning a house while saying she wanted to keep cleaning houses for a living, even with two graduate degrees. It was probably a sketch promoting a book.

But she said a line that resonated deeply with me:

“I don’t want to pretend I care about things I don’t care about.”

Wow! That made my head explode. That was me a couple of years ago, stuck in a 9-5 with decent pay and flexible hours, pretending to care. Spoiler alert: I got sick and burned out. I didn’t burn out by doing too much, but from boredom and indifference. By doing things I didn’t care about.

And that line made the scrolling session worth it. Yes, even doom-scrolling can teach valuable lessons life lessons.

Five Writing Tricks Behind 'Not Really on Purpose'

2025-07-28T00:00:00+00:00

I finished watching “Not Really on Purpose” (“Sin Querer Queriendo” in Spanish), a TV series based on the life of Roberto Gomez Bolaños.

If you’ve never heard of him, he was a Mexican writer, TV producer, scriptwriter, and comedian. Best known as “Chespirito,” a nickname after “Little Shakespeare” in Spanish.

Multiple generations from Latin America have watched or grown up watching his shows like El Chavo del Ocho or El Chapulin Colorado.

“Not Really on Purpose” gives a glimpse of Chespirito’s early life and the story behind some of his most famous characters.

I watched it as a writer, and I noticed these devices:

#1. The show starts with the second-to-last scene. Roberto is getting dressed to appear as “El Chavo” at a benefit event in Colombia. He’s tired of the conflicts in his life and career.

#2. The show builds towards one main event: El Chavo and his neighbors visit Acapulco. And a fun fact, that was the last time the original cast filmed together.

#3. To keep us engaged, the shows uses time jumps to show us Roberto’s early life, his romance and marriage, and the Acapulco episode’s production.

#4. We’re shown some scenes twice. Early on, we see some conflict. Roberto is flirting with another cast member while married with kids.

Later, when the story has developed a bit more, the same scenes are replayed with more context.

#5. The show finishes with some flashbacks of early episodes and footage of the real Roberto on TV screens in the streets.

It was funny to see how our favorite characters came to life and how Roberto found inspiration in his own kids. Chespirito didn’t just create TV shows, but a world of characters still alive in Latin America. One we’ll remember forever. Even it was not really on purpose.

For other TV show breakdowns, see Storytelling Secrets from One of My Favorite House M.D. Episodes and What I Learned From Watching Netflix’s Six Triple Eight.

The Weirdest Things That Happened While Building My Brand on LinkedIn

2025-07-27T00:00:00+00:00

LinkedIn is a weird place.

The “I’m pleased to announce…“ posts, the “I have a new certificate…“ updates, and the B2B lessons learned from every situation. “I just proposed, here’s what it taught me about B2B sales.”

We do crazy things to impress future employers online.

Since last year, I’ve posted 300+ times to grow on LinkedIn. And here are a few of the weirdest things I’ve seen:

#1. A lead generation coach went full sales mode, pitching me a funnel course… when I didn’t have anything to sell. “Thanks, but… No thanks. Clicking Unfollow.”

#2. A DM offering to make me the “face” during interviews. I’d have to take interviews and land jobs. Then someone else would show up to work. Maybe I’d end up participating in the North Korean engineers scheme. “Block and report. Call the Internet police?”

#3. Random people liked one of my posts, then rushed to my DMs asking for a coffee chat. “Sorry, not the best time now… or in the near future.”

#4. Coaches offering me “free” help, just prepping the ground for a sales pitch. “Let’s cut to the chase. What are you selling?”

Sure, LinkedIn might be a weird place. But I’ve met interesting people, landed one speaking gig, and made my first Internet money. And that’s why, no matter how weird it gets, I keep showing up.

What I Gained After 6 Years Blogging on dev.to

2025-07-26T00:00:00+00:00

Six years ago, I wrote my first blog post… and heard crickets.

Nobody was reading my blog. I wanted some traffic there. Some attention. I was playing the SEO game with keywords and answer posts. I prayed to the SEO gods to send readers to my blog.

Those days, I found out about dev.to, the new platform in town for coders.

A better way to get readers? Create an account and repost there. So on July 23rd, 2019, I did it. I didn’t know where it would take me.

Some vanity metrics, before I move on.

In six years, I’ve written 176 posts.

Some of them are dev.to “originals.” Others reposts. I wrote more posts, but I deleted the oldest in a moment of embarrassment. Yes, even I cringed at reading them. They were so bad.

My posts on dev.to have received +114K views and 1.6K reactions. And I have +25K followers. Mostly bots or inactive users I think.

But dev.to didn’t just send traffic.

Where was I? OK, what my dev.to account has done for me…

#1. It’s helped me connect with other members of the community. I’ve had virtual coffees with other “devtoers.”

#2. It’s given me confidence in my writing skills. I went from deleting some posts in embarrassment to being featured in the Top7 more than once. That’s a sign my writing has improved. A win for taking my writing more seriously since last year.

#3. It’s put my content in front of an audience. Last year, I burned out and got laid off. Writing was my therapy. So I started to share my career stories and lessons. Writing helped me process a rejection from a FAANG, for example. Seeing my posts resonating with a lot of people was so encouraging.

#4. It gave me a small moment of virality. Thanks to dev.to, I went viral for the first time ever. With this post: This Is Why We Don’t Test Private Methods.

In a single day, I got thousands of readers and dozens of downloads from my Gumroad account. Shameless plug. Someone reshared it or it got syndicated somewhere. Dunno. I felt like an Internet coding celebrity… just for a few hours.

#5. It’s given me a chance of giving back to the coding community. It’s helped me turn my stories into inspiration and some laughs for others. Like the best comment I’ve received: “Made my day go from brain-f*cked to f*cking good.” That made my day and reminded me why I keep showing when it feels nobody is reading.

Friday Links: AI, checklists, and cocktails

2025-07-25T00:00:00+00:00

Hey, there.

I thought I wouldn’t find another 4 since last Wednesday email. Here are 4 links for you today: (I couldn’t avoid adding the last one, not about coding though)

#1. The whole point of AI is making coders faster. But here’s an study (4min) that shows AI makes some experienced developers slower.

#2. Sure, AI is the buzzword these days. But there are things that don’t change (4min). “AI amplifies what you already know.”

#3. Something we coders should learn from pilots? The value of checklists (3min).

#4. This one isn’t about coding, but… I found out there’s an official list of cocktails and a guy who drank them all (20min).

And in case you missed it, I wrote on my blog about how to stand out from AI content (2min) and the simple method I use to replace my second brain (2min).

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.

10 Reading Challenges for Book Lovers (Inspired by the 'I Drank Every Cocktail' Guy)

2025-07-24T00:00:00+00:00

Adam Aaronson drank every cocktail on the official list.

Yes, there’s an official list of cocktails. And Adam drank them all. He started by handing the list to a bartender in his city and ended up at Satan’s Whiskers in London. Yes, that’s a bar.

Quite an impressive adventure.

Just like Adam tackled cocktails, what about book lovers? That story reminded me of a 10-idea list I wrote with 10 book reading challenges. If you want to try one, here they are:

Join a book reading club
Read the last 25 Pulitzer winners
Read the last 25 Nobel Prize winners
Read your favorite writer’s complete works
Read a book from a new writer every month
Read one book per week. Or 52 books in a year
Take your own MBA by reading 12 business books in a year
Read 12 biographies of history’s most influential figures
Read James Altucher’s book recommendations. Full list here
Read 10 or 12 books released more than 50 years ago. Idea from CulturalTutor.

Which one would you like to try first? For my challenge, I’m doing #4. I’m reading most of James Altucher’s books.

A Wednesday Links about Google, Chrome, and TODOs

2025-07-23T00:00:00+00:00

Hey. I just realized I already had 4 interesting links to share. I didn’t want to wait until next Friday to share them. So here they are.

#1. I have to admit I fell into the specialization trap and started calling myself a “backend engineer.” I stopped trying to be a full stack developer. Maybe with AI, we’re witnessing the renaissance of full stack developers (10min) again.

#2. The problem with Google AI Overview is we think their answers are accurate. Hey it’s Google. They must be building AI answers from all the pages they have indexed. Wrong. In fact, Google AI Overview might kill you (7min)

#3. Speaking of Google killing people, Chrome killed uBlock Origin. And if you want it back, you need to turn to Firefox. Here’s a good adoption guide (8min).

#4. From Clean Code, I learned to avoid comments, like all comments. But there’s some value in TODO comments (2min).

And in case you missed it, I wrote on my blog about productivity secrets revealed by a real spy (2min) and a language lessons I learned in an Asian restaurant (2min).

See you next Friday, even if that’s only with one or two links.

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.

4 Fresh Insights That Changed How I Think About Writing Books

2025-07-22T00:00:00+00:00

I’ve decided to start a new writing adventure: writing a book.

I’ve had to debunk lots of limiting beliefs.

“I need a publisher”
“I need 100% new material”
“Writing a book is hard.”

Wrong!

After going down the rabbit-hole of searching how to write and self-publish a book, here’s what I’ve learned:

1. A hit book creates demand for more books.

After Atomic Habits, there was an audience interested in habit creation. Then, more books about the same topic came out.

A hit book isn’t necessarily competence. It’s signal of market interest.

2. You can plagiarize yourself.

We can remix our own ideas. Credits to James Altucher’s podcast.

A good post can become part of a book chapter. A series of posts can become a short book. A personal story can become an intro.

That’s the strategy Yuval Noah Harari used to write 21 Lessons for the 21st Century. He compiled lots of disperse ideas into a book.

More examples? The Subtle Art of Not Giving a F*ck was a blog post. The Psychology of Money, a series of posts.

You see? We can repurpose our posts into books.

3. A book’s job is to tell stories.

(Another lesson from James Altucher’s podcast.)

Always be storytelling. Stories are the best way to make a message memorable.

Our job is to tell stories, not to present facts - unless we’re writing a textbook or something.

4. A book lives forever.

Your book doesn’t need to be a best-seller at launch. It can succeed anytime. And there’s plenty of time for that.

What a Chinese Couple Running a Restaurant Taught Me About Learning Languages

2025-07-21T00:00:00+00:00

Yesterday, I revisited an Asian restaurant I hadn’t been to in years.

It’s a family business in a neighborhood I used to live in. It’s still run by the same Chinese couple. And interestingly, their level of conversational Spanish is rather intermediate. Still the same as when I met them. Probably an A2, if you’re familiar with language proficiency levels.

But they know enough Spanish to explain what’s in every dish, take your order, and take your payment. And that’s all they need.

Their Spanish may be basic, but it’s enough to meet their daily needs. Do they speak Spanish? Absolutely. Maybe not about politics, philosophy, or the meaning of life.

Too often we think fluency is about attending a language institute and getting straight As on an exam. But fluency isn’t about perfection.

Fluency is about connection and communication. It’s about knowing the right words for the right moment. And the Chinese couple running the restaurant are completely fluent.

Maybe you’re not opening a restaurant, but here’s how I’d learn a language for work from scratch and 10 hacks I’ve used to learn foreign languages faster.

The Only Tip You Need to Stand Out From AI-Generated Content

2025-07-20T00:00:00+00:00

You can smell AI-generated content from miles away.

You can feel it. It’s the opening lines, the weird word choice.

“Delve”
“Ever-evolving”
“In our fast-paced world…”

You can’t fight against it.

Recently, I learned how to stand out from AI while listening to James Altucher’s podcast. I forgot to take notes, but he said something like this,

To stand out from AI, we have to live an interesting life.

AI only remixes content it was trained on. AI can’t beat an authentic voice with impactful stories. We have to live our stories and pour them into our writing.

My writing resonated more once I started sharing personal stories. They turned my writing from crickets to likes. So tell stories only you can tell. That’s how you truly stand out from the noise.

The Productivity Secret for Getting Things Done—Revealed by a Spy

2025-07-19T00:00:00+00:00

We think of guns, car chases, and James Bond when talking about spies.

Productivity rarely comes to mind. But real espionage, as shown in TV shows like The Agency or Lioness, is full of chaos, multitasking, and shifting priorities.

Thanks to Mr. YouTube algorithm, I stumbled upon an interview with a former American spy:

He answers a ton of questions about espionage and psychology. But here are three battle-tested lessons about productivity I learned:

#1. We all have to balance the same three resources. Energy, money, and time. Two of them are limited. The other one, not so much. That’s why we should optimize for energy and time.

#2. Task saturation is when you have more tasks than you can comfortably handle. When that happens, you become so overwhelmed, you stop thinking rationally. Think of how many tasks you can handle at the same time and subtract two. That’s your sweet spot.

#3. When you’re task saturated, always tackle the task you can finish the fastest. And then, the next fastest one and so on. That gives you a sense of progress and momentum.

With those three lessons, you’re ready to get things done like a real spy. Don’t forget the cool gadgets and masks from Mission Impossible.

Friday Links: Selling yourself, ergonomic repos, and dead languages

2025-07-18T00:00:00+00:00

Hey, there.

Here are 4 links I thought were worth sharing this week:

#1. Here’s how to sell yourself (3min). It distills the tactics from the guy who landed and balanced multiple startup jobs at the same time. He must have done something right to land those jobs in the first place, right?

#2. Want to build software quickly? Here’s a guide on how to do it (12min).

#3. When I hear “ergonomic,” I think of chairs or keyboards. But what about repositories? Here’s how to make repos ergonomic too (14min). It starts with the README file.

#4. Like human languages, programming languages grow, evolve, and die. They borrow features from one another. Here are some of the already dead but influential programming languages (20min). I used one of those in high school.

And in case you missed it, I wrote on my blog about two tiny fixes to improve your communication at work (2min) and 10 pieces of tech we use before breakfast without noticing them (3min).

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.

10+ Pieces of Tech You Use Before Breakfast Without Even Realizing It

2025-07-17T00:00:00+00:00

In many ways, we’re living in the best time in history.

Yes, some leaders are suspiciously looking at each other with a finger ready to press a red button. But, centuries ago, people died from diseases we treat today with pills we can freely buy at any grocery store.

Tech has advanced so much that we barely notice how many gadgets and breakthroughs we use before breakfast. I’ll be counting them as we go.

Waking up

At 7:00 AM, your smartphone (#1) rings to wake you up.

You don’t use an alarm clock anymore. A few hours before that, your AC (#2) automatically turned off after regulating your room’s temperature. Or maybe you have a fan, but I’m still counting #2.

After waking up, you didn’t stop to notice you have electricity (#3) at home and a comfy mattress (#4). That used to be a privilege reserved for kings.

In the bathroom

After waking up, without running away from hungry lions, you walk to your bathroom.

You use the faucet and brush your teeth with clean water (#5). You do your “business” in a toilet (#6), using paper.

Romans used, I mean shared, a sponge-tipped stick in public bathrooms. “Augustus, are you done with the sponge? It’s my time!” Soooo disgusting. Thanks, Marcus Aurelius for all your wisdom. But I don’t want to live in your time.

And when you’re done, one button press. Poof, like magic, your “business” disappears. We’ve built complex plumbing to get rid of it (#7), that we don’t even care what happens after pressing that button.

In the kitchen

A glass of water first thing after waking up?

A company has collected, purified, and distributed water from who knows where to bring it to your home (#8). We’ve perfected engineering and chemistry to make that happen.

To really wake up, a cup of coffee, right? You use a coffee machine (#9). Coffee beans grown in Latin America likely traveled to Switzerland to become capsules for your machine.

Not into coffee? Sure. What about some tea? A water heater! Or a fresh orange juice? You have a juice maker for that.

What about some eggs and toast with that coffee? You open your fridge (#10), then pull out your toaster from the counter (#11), and use your stove.

And just to finish your morning routine, what about some vitamins and supplements? Packed with calcium, magnesium, zinc, and more, everything your body needs in one pill (#12).

And there’s a whole lot of physics, electronics, engineering, global shipping, medicine, chemistry… just for breakfast. And we’re not even dreaming about the future with robotics, automation, and AI. We’re already in the future. It’s here

OK, I told you about 10 pieces of tech, but I ended up counting 12. There’s probably more I forgot to count.

5 Productivity Tips That Really Work (They'll Make You Unstoppable)

2025-07-16T00:00:00+00:00

About five years ago, I became obsessed with productivity.

I devoured the entire Lifehacker site, looking for the best system and the perfect tool to finish my work. Pomodoro technique, Eisenhower matrix, inbox zero, a todo.txt file. I tried them all.

After testing some of those techniques and simplifying my system, I’ve found what really works, at least for me.

#1. Follow your energy levels. Work on the most important tasks when your energy is at its peak. For me, that’s in the morning, after breakfast and working out. Exercise or meditate to boost your focus.

#2. Protect your sacred hours. When tackling your most important tasks, remove all distractions from your environment. 99% of the time, that means your smartphone. Even if you keep it around, it still distracts you. Yes, that’s backed by science.

#3. Work in cycles of 90 minutes of work followed by 20 minutes of rest. This is a tip I recently learned, and I’ve been trying it since then. The brain needs that rest in between to work at its peak. Tweak those 90/20 to suit your natural rhythm.

#4. Follow the 5 minute rule. When you don’t feel like working, start with a simple task and sustain it for 5 minutes. Or start with a task you can do the fastest. You need a small push to finish your more demanding work.

#5. Use a parking lot. During your sacred hours, if you come up with new tasks, write them down (paper, app, whatever works) and do it later. You should still protect your deep work time.

5 Ideas to Write Headlines That Make Readers Stop Scrolling

2025-07-15T00:00:00+00:00

Headlines and opening lines get you 80% of the results.

Because, based on Small Brevity, readers spend 17ms deciding if they keep reading or move on. So no matter how helpful your content is, nobody will click it if you write a poor headline.

Want to gain readers? Master your headlines with these ideas:

Study your favorite YouTuber’s titles.
Follow this 3-step formula.
Use one of these emotions: fear, curiosity, desire.
Follow title-driven creation: Headline first, content comes second.
Rewrite the headlines of posts you read.

When you write online, you’re really in the business of writing headlines. Online writing is headline writing. No headline = no readers.

Two Tiny Fixes That Could Transform Your Communication at Work

2025-07-14T00:00:00+00:00

Did you join Software Engineering because you liked coding and time alone? Think again.

You’ll spend more time in meetings than coding:

Daily stand-ups
1-on-1s
Team retros
Five minutes (that become hours) with another dev revisiting code you wrote a year ago, and you barely remember it

With all these interactions, technical skills alone aren’t enough. You need strong communication skills.

The best resource for that? How to Win Friends and Influence People. Newer books exist, but this one is a true classic.

Here are two ideas from that book that changed how I approach conversations at work:

Never, ever, ever tell anyone they’re wrong.

That’s the worst way to start or end a conversation. And you won’t change the other person’s mind.

At a previous job, I had the chance to apply that principle.

We were working to connect our hotel solution to a third-party API using the PKCE flow. One developers read an outdated tutorial and wanted to implement it incorrectly.

If I hadn’t read the book, I would have said, “You’re wrong. Here’s how to do it… You, moron!” OK, I would have only thought the last part.

But instead I said something like, “Hey, maybe I read an outdated tutorial or something. Here’s what I found…“ A few moments later, I got a “You’re right!” with a facepalm emoji.

Avoid blaming. Instead, pretend you’re the one who might be wrong.

Be careful with your “but.”

Often what comes after a “but” is something negative.

And people remember more the last words they hear. So if your “but” comes last, that’s all what they will remember.

“That’s a good idea, but we will go over budget” is different from “That’s a good idea, and if we stay within budget, it’ll be perfect.”

Find ways to replace your “no, but…” with a “yes, and…”

Ten years ago, I thought coding was just cracking symbols. It took me years to learn coding is also about being in countless calls and sync-ups: negotiating deadlines and sharing expectations with non-tech people.

That’s why working on our communication skills is one of the 30 proven strategies in my book, Street-Smart Coding: 30 Ways to Get Better at Coding. That’s the roadmap I wish I had when I was starting out.

Grab your copy of Street-Smart Coding here

The Most Dangerous Problem With Using AI for Coding

2025-07-13T00:00:00+00:00

There’s good laziness and bad laziness.

One day, the VP of a company I was contracting with called me “lazy.” That was a compliment. You know the lazy that finds an easy way to solve a problem. The good lazy way.

But AI is turning us into bad lazy. The “I don’t want to think” kind of lazy. And I don’t want that type.

I’ve been experimenting with AI for my coding. When I sit down to code, I open Copilot on a browser to see what I can offload.

Recently, I’ve been migrating a legacy Visual Basic app and I’ve used Copilot to code faster by helping me with boring tasks.

The problem? Last week, I was stuck on a stupid problem: finding a value in a dictionary from a list of possible keys. Maybe I needed some rest, but I couldn’t think of a LINQ query for that. I was so tempted to wake up the genie in the bottle for that. It felt like the easy way out.

It’s so tempting to go directly to the AI and outsource our thinking.

Just the other day, I found a coder desperate because he couldn’t code without AI anymore. If we’re not careful enough, any one of us could become that coder.

AI is faster at generating code than we are. No doubt!

But being a good coder isn’t about typing fast. It’s about teamwork, clear communication, and other skills that don’t show up in autocomplete.

I’ve packed those lessons into my book: Street-Smart Coding: 30 Ways to Get Better at Coding. It’s the roadmap I wish I had when I was starting out.

Get your copy of Street-Smart Coding here

What Software Engineering Should Learn from Aviation

2025-07-12T00:00:00+00:00

Flying is safe but… accidents happen.

When they happen, it’s all over the news. But the thousands upon thousands of safe flights don’t make it to the headlines.

The magic of the Internet took me to Admiral Cloudberg on Medium. Each post breaks down a rare accident, tracing the failed part or procedure that triggered the disaster.

After every accident, there’s an investigation

After binge-reading some of Admiral Cloudberg’s deconstructions, what struck me was the meticulous investigation after every accident.

A committee finds out exactly what happened and why. Their task is to find the root cause and the subsequent chain of events.

After finding the root cause, they:

release bulletins to manufacturers
update procedures and checklists
add the accident scenario to simulators to train pilots

Their goal isn’t to blame the captain or anyone else, but to prevent the same mistakes in future flights.

Coding isn’t flying

As software engineers, often we hear or say,

“Something went wrong. We don’t know why. It hasn’t happened since then.”
“OK, let’s move on. If that happens again, we’ll take a deeper look.”

Imagine if we treated coding the same way:

Checklists to release code
Another checklist for incidents
Clear onboarding processes
Automated best practices
Guilty-free culture

Coding would be as safe and reliable as flying.

We must adopt the same commitment to safety protocols and procedures to never let the same mistake happen twice.

Friday Links: Coding, calling, and networking

2025-07-11T00:00:00+00:00

Hey there.

Do you remember the first time you saw a computer? I do. And I originally wrote that story on my blog (2min). But this week, it went kind of “viral” when I reposted it on dev.to.

Anyway, here are 4 links I thought were worth sharing this week:

#1. AI can make us code faster. But writing code has never been the bottleneck (3min). It’s everything around writing that code in the first place.

#2. Curious about the backstory of some coding jargon? Here’s why we “call” functions (10min). Funny enough, we also say “invoke” a function and in Spanish, everyone associates “invoking” with ghosts.

#3. Instead of forcing devs to use AI, here are some ideas for managers to adopt AI (7min) in their teams.

#4. Also an introvert? Here’s a quick guide to networking (5min) for you. Not the networking type with cables and switches.

And in case you missed it, I wrote on my blog about the “I just went on vacation” effect (2min) and 4 lessons to start your first online business (3min).

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.

The Branding Exercise That Felt Like Free Therapy

2025-07-10T00:00:00+00:00

I didn’t know a branding exercise would make me reflect on my life.

I’m taking a branding/writing course online. One of the exercises was to identify our main achievements, mistakes, and lessons to build our online presence around that.

Here are some of my answers for the career-related questions.

What were the most notable things that happened during your young adulthood (20-30 years)?

I was fired from my first job. It was at a top company in my city. It taught me there’s no truly safe place to work. Not sure if that’s a win or a loss.
I became a Senior SWE in one of the most well-known companies in the tech sector in my city.
For the first time in my life, I worked with a multinational company in the tech sector. It doubled my previous salary and it burned me out, too. In that order.
I overcame my burnout by myself and took a mini-sabbatical for my mental health.

What were the most notable things that happened in your career?

I learned English to land high-paying jobs. But I found out I like learning languages. So I learned another two. French and quite a bit of Brazilian Portuguese.
I found out I’m a lifelong learner.
By accident, I started writing online and made my first dollars online.
I doubled my salary and took one year off.

What have been some of the hardest or painful moments in your life?

I hit rock-bottom. Got burned out, depressed, and stomach sick. In that order. All of that because I decided to keep a “good” job with a decent salary.

What have been the most valuable lessons you learned in life and how did you learn them?

We’re just a cog in a machine if we keep a “safe” job. I learned this when I got fired and laid off multiple times.
If I don’t come up with my own life plan, somebody else will give me one. I had to overcome my burnout to learn this.
I’m not my job and my job title. I should diversify my joy. It shouldn’t come from a single place. Thanks, burnout for teaching me this.

What have been your biggest mistakes and how did it change you?

I stayed too long at stagnant jobs, expecting things to change without taking any action. It cost me years and thousands of dollars. One of the few things I regret. It made me take control of my career and life.

What transformations have you gone through in life (physical/financial/emotional/spiritual/etc.)?

After months of waking stressed and anxious, I recovered from burnout by working on my health and writing again. Finally, after almost a year, I could wake up feeling fulfilled and accomplished.
I lost about 5 kg in the last year, thanks to reordering how I eat. It turned out to be the best productivity hack I’ve discovered.

What are your most significant achievements?

I paid with my own money for a fancy family dinner.
I made my first internet money with coding courses and writing online.
After a layoff, I survived one year without a job, living off my savings and investments. It was a tough time, but I remember it as the season where I grew the most.

The "I Just Went on Vacation" Effect in Dev Teams

2025-07-09T00:00:00+00:00

After years of working in dev teams, I’ve learned one rule the hard way:

Don’t ask someone leaving to finish a critical task, even if they’re the only one who knows how.

Someone going on vacation, or worse, leaving the job already has their mind elsewhere. They’re already thinking about packing, buying tickets, or finishing paperwork.

Even if they finish the task, something will go wrong after they’re gone. Maybe it’s a requirement change, an unexpected bug, or a new scenario nobody saw coming. And they’re the only one who knows how to handle it.

Too late, they’re already gone. People who stayed will have a hard time catching up.

I don’t know if that’s ever happened inside your teams. But I’ve seen it more than once. Let’s call it the “I Just Went on Vacation” effect. And make sure we don’t fall into it, especially if you’re the one leaving.

Starting out or already on the coding journey? Join my free 7-day email course and refactor your coding career–I distill 10+ years of career lessons into 7 short emails.

The Only Productivity Tip That Actually Works (Forget Notion)

2025-07-08T00:00:00+00:00

Notion dashboards. Second brain apps. Inbox zero. None of it matters if you miss one thing.

Rest.

Without a good night’s sleep, your fancy productivity system fails. You drag your feet, drink coffee, and fight the urge to nap anywhere.

To work like the top 1% of high-performers, work hard but rest harder. Schedule rest like you schedule your most important meetings. Non-negotiable.

I Ditched My Buy Me a Coffee Link—Here's What I'm Doing Instead

2025-07-07T00:00:00+00:00

I’ve never liked being asked for money on the street.

When someone asks me for money, I ask why they don’t sell something instead.

But I realized I was doing the same thing: holding up a digital sign next to a rusty can in the internet streets. That hit hard.

Instead of asking for coffee, I now invite readers to join Friday Links, where I share 4 curated resources about programming and promote my books and courses.

I get it! When we’re starting, we don’t want to sound salesy, so we go with a “support me” as a call-to-action. We think we shouldn’t monetize creativity, as if artists or writers should starve.

After binge-reading Tim Denning, a digital writer with billions of views, I learned to ditch the “Buy Me a Coffee” link and offer something of value, like a newsletter. Turns out, that’s the strategy millionaire creators swear byr. And now, I do too.

4 Game-Changing Lessons to Launch Your First Online Business (from the Creator of Small Bets)

2025-07-06T00:00:00+00:00

He turned a half-joking Tweet into a community of over 7,000 creators.

His name is Daniel Vassallo. He was a Software Engineer with a cushy job at Amazon. But one day, after being tired of daily meetings and the lack of freedom, he decided to start a solo business.

His journey went from building software to freelancing, selling info products, and eventually running the Small Bets community.

After binge-watching some of his interviews on YouTube, like this one with the Refactoring podcast, here are 4 lessons I’ve learned:

1. Find an easy way to make $1,000 dollars.

You don’t need a company or investors to begin.

Start with a low-hanging fruit, a small project that makes you a few hundred or thousand bucks to build momentum.

For Daniel’s first project, he tried to imitate the processes from his last coding job. Coming up with a yearly goal, splitting it into milestones, and working in sprints. That only made him burn through almost all of his savings.

Don’t replicate your last full-time job. Find an easy project first.

2. Be like an investor, but without being one.

You don’t need VC funding, but you need to think like an investor.

An investor places bets on lots of startups. They know some of them will fail, but the one that succeeds will pay off all other investments.

Think of your projects the same way. Don’t put all your effort into one basket. And like an investor, don’t get too attached to a particular project. They’re your cattle, not your pets.

Run a portfolio of small bets so income doesn’t have to come from a single place.

3. You don’t need a big master business plan.

You don’t need a mission, vision, or values to start an online business.

Your only goal might be to never return to a 9-5. That’s Daniel’s goal. That could be yours and mine too.

4. The ultimate goal is freedom.

The goal of starting a business is to have the freedom to work under your own terms.

For Daniel, that means having no rigid schedule or routine, but working on the tasks with the biggest ROI every day. Or simply scrolling through Twitter/X looking for project inspiration.

As a solopreneur or creator, you’re an investor, but of your own time.

Five Inspiring Mantras to Help You Start Writing (and Stick With It)

2025-07-05T00:00:00+00:00

In 2018, I wrote a blog post for the first time.

I didn’t know what I was doing. I only wanted to get better at coding. And after years of trial and error and taking my writing seriously, I’ve developed my own writing mantras. Here they are:

#1. If it can help one person, you’re safe to hit post. Write about anything, as long as it’s helpful for at least one person. You don’t need to write to the masses. Just to one person. And that one person could be your past self.

#2. Give something and give it fast. Writing online is different from fiction writing. In a novella, you can describe every detail of the room where your scene is happening. But online, readers decide in milliseconds if they’ll keep reading or move on. Nail your headlines and opening lines.

#3. Write as if nobody is reading, and keep writing because you don’t know who’s reading. Writing can be lonely, especially at the beginning. The cure? Write for your younger self. Write the tweets, posts, or books you would have liked to read two years ago.

#4. Don’t wait to become an expert to write. Write to become one. If you wait to become an expert, it will take you 10 years or more to write your first piece. Instead, share what you’re learning. Show your work. The best way to learn is to teach, and the best way to teach is to write.

#5. An intention makes you start but a system keeps you showing up. It’s easy to start. Just drop a bunch of words into a text box and hit “Post.” The hard part? Doing it for years. For that, find a system to capture ideas and turn them into content, and one piece into many.

In the end, it isn’t just intention. It’s the right attitude, a system, and the habit that keeps you writing.

Friday Links: The software squeeze, TDD, and ad-blockers

2025-07-04T00:00:00+00:00

Hey there.

Here are 4 links I thought were worth sharing this week:

#1. Five years ago, we only needed “Software Engineer” as a title on LinkedIn to be flooded with “life-changing” opportunities. People jumped in for the money. Tech was booming. But that bubble popped. We’re living in a software engineering squeeze (5min).

#2. The most boring part of software projects? It’s when we’re just closing JIRA tickets instead of solving real problems. It’s when we’re in Ticket-Driven Development (4min).

#3. As a coder, you don’t have to know every single acronym, framework, or tool. It’s fine to say I don’t know (3min). But I’ve learned to rephrame it as “I don’t know…yet”

#4. Maybe this is a good excuse to buy augmented reality glasses to use them as ad-blockers (3min).

And in case you missed it, I wrote on my blog about a recovery guide for AI-dependent coders (5min) and the best 3 pieces of advice I’ve received (2min).

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.

7 Surprisingly Simple Ideas That Changed My Life (And Could Change Yours Too)

2025-07-03T00:00:00+00:00

#1. If you feel lost in life, start by working on your health.

Last year, for the first time, I had no idea what to do with my life.

I had just recovered from a stomach sickness. I was on my way out from a burnout season. And a layoff caught me off guard. No side income, no next offer waiting for me. No plan B.

I felt more lost than when I graduated high school. At that time, I believed in the “go to college, find a job, work hard” path in front of me. But this time? I realized that the default path was a lie.

By accident or luck, I found the idea of working on my health when I felt lost. And it worked. Slowly, it gave me clarity and momentum.

Truth is, to change our lives we don’t need “passion” or a big master plan. We just need to start working on our health.

#2. Do something for your body, mind, and spirit every day.

After deciding to work on my health, I ditched my to-do list and focused on one single goal: working on my body, mind, and spirit every day.

I found that idea in one of James Altucher’s books. Probably Choose Yourself.

For me, it meant a workout session, writing 200 words, and a moment of silence every single day.

For you, it could be going running, meditating, or painting. Whatever. But do something for your body, mind, and spirit every day.

We’re truly healthy when the three of them are healthy. Work on each one every day. That’s the easiest recipe for a happy life.

#3. Save 50% of your income

Credit goes to an ex-coworker from my first coding job.

One day, out of the blue, he came close to my desk and shared this unsolicited advice. For free.

He told me:

“Cesar, imagine you only make half of your salary. Save and invest the other half. Sooner rather than later, you will buy your own house.”

That’s the best piece of advice I’ve ever received. Since then, I started to save. Sometimes 50%. Other times, less.

#4. Learn a second (or third) language

I learned English to make my CV attractive and land high-paying jobs.

But learning English meant more than high-paying jobs. It opened a whole new world: friendships, traveling, books… And you’re reading this because one day my mom’s best friend told her to sign me up for English classes.

For me, it was English. For you, maybe Arabic for work in the Middle East or Spanish to join a rising startup in LatAm. A new life is waiting for you behind a new language.

#5. If you don’t read, you won’t learn anything.

I don’t remember much of my philosophy class in high school.

But I won’t forget our teacher’s mantra. He repeated it all the time:

“If you don’t read, you won’t learn anything.”

Many years later, I stumbled upon him at a mall and told him I still remembered his quote. He told me the second part:

“If you don’t read, you won’t have anything to talk about.”

I had to wait more than 10 years to learn the full line.

Read one page or 10 or 15, but read something every day.

#6. Start a blog

Apart from learning English, writing is one of the most helpful skills for my professional career.

I made my first $100 online by sharing my words in a corner of the Internet.

Start a blog or write tweets. Just write. It will teach you to think clearly and it can make you some money in the meantime.

#7. The minute you learn something, teach it.

I found this idea in Show Your Work by Austen Kleon.

You don’t need a lecture hall or scientific papers to teach. Simply share it with anyone over the phone. Or write it anywhere online. That’s what has powered my online presence since I wrote my first blog post back in 2018. Sharing what I learn has not only helped others, it has changed my own life.

I expand these ideas, and cover more, in 10 Surprisingly Simple Ideas That Changed My Life And Could Change Yours Too. Real change doesn’t come from master plan or New Year’s resolutions, but from tiny daily actions.

The Trick That Keeps Me Writing When Nobody's Watching

2025-07-02T00:00:00+00:00

Writing isn’t hard. It’s doing it when nobody is reading.

I started reviving my LinkedIn account last year. At first, I only got one or two reactions from friends and ex-coworkers.

To keep myself showing up day after day, I started a “wins” folder. That’s an idea I got from “Steal Like an Artist.” Every time something good happens, like an encouraging comment or extra likes, I’d screenshot it for motivation.

This last week, I added another screenshot to it. It was a comment on my reposted Medium post about writing a book for our future grandkids:

“I never thought of writing as a gift for future generations, but now I want to document everything. This really shifted something in me!”

That comment made my day. I managed to change a stranger’s view on something with my words. And that was more rewarding than any of the other comments I had received recently.

Collect and celebrate your small victories, too. They make your day and keep you going.

What It Means to Take Creative Work Seriously

2025-07-01T00:00:00+00:00

It’s clear when you’re taking a relationship seriously.

You spend time with your loved one and stop looking for somebody else.

But what about a creative project? What does taking writing, painting, or coding seriously mean?

I started writing in 2018, but I didn’t treat it seriously until 2024.

For me, taking my writing seriously meant:

Showing up consistently
Studying other writers’ work
Putting my writing in front of others
Challenging myself out of my comfort zone
Writing about other subjects apart from coding
Hanging around other writers online
Buying my first writing course
Listening to feedback

With those actions, writing stopped being something I did only in my spare time and when inspiration struck to become part of my everyday rhythm. They help me build the confidence to call myself a “writer.”

Taking a creative project seriously means committing it by showing up and working on improving your skills.

Tom Critchlow, with his post Taking Blogging Seriously, got me thinking about all this.

Three Rules for Starting a New Creative Project

2025-06-30T00:00:00+00:00

Search YouTube for journaling or note-taking, and you’ll almost certainly land on Field Notes.

Field Notes makes pocket-sized notebooks. Yes, the old-style pen-and-paper kind of notebooks.

I have to confess that I don’t use them (yet?). For my 10 bad idea lists, I use a cheap, ring-bound notepad that fits in my pocket. Still, their story resonated a lot with me.

While reading how the two creators started Field Notes, I found out they had a simple framework for starting creative projects:

It should make money
It should be something you’re proud of
It should teach you something

For them, Field Notes checked the three boxes. And those three rules work for a design studio and for any creative project: a side hustle, newsletter, or book. OK, we can negotiate the first one a little.

If you’re starting a creative project, use your fingerprints and don’t forget about this law.

The 3 Best Pieces of Unsolicited Advice I've Ever Received

2025-06-29T00:00:00+00:00

You know that saying, “Don’t give advice unless asked?”

Well, some people ignored it and gave it anyway. Here are the best pieces of advice I’ve received:

From high school:

“Read, because if you don’t read, you won’t learn anything.”

That was from my philosophy teacher in high school. He said it all the time. I don’t remember much from his class, but for some reason that line has stayed with me.

If I still remember that years later, he did his job.

From my first job:

“Imagine you make half of your salary, save the other half.”

A senior co-worker at my first coding job gave me that totally unexpectedly. That lesson stuck with me so much, I couldn’t resist adding it to my an email course I created years later.

From my last full-time job:

“Diversify your career.”

That was from one of my not-mentors. I reached out to him when I wasn’t sure about where to take my software engineering career. We had many 1-on-1s. That’s what I remember the most. It was good advice. I didn’t follow it. I burned out.

A Quick Recovery Guide for AI-Dependent Coders

2025-06-28T00:00:00+00:00

Technology makes us lazy.

That’s not an opinion but a fact. We can’t do mental math, find addresses, or memorize phone numbers anymore. That’s the problem with relying too much on a piece of tech. Smartphones, I’m looking at you.

The same thing happens in coding, with AI and vibe-coding.

I’m guilty too. I’ve been experimenting with AI to offload my plate of boring tasks. And when I can’t think of an answer immediately, I’m tempted to go straight to the genie in the bottle to grant me a coding wish.

And I’m not alone in this. Recently, I found this question on Reddit,

“It’s been a while since I coded on C#/Unity so I’m very rusty on the concepts and relying too much on ChatGPT makes me feel like I haven’t learned anything and can’t write code on my own without doing basic mistakes… How do I learn everything back? Isn’t there a way to refresh my mind? A really good video on YouTube or something? I want to stop using AI and code on my own.”

For the original poster and anyone else who wants to break free from AI, here are 10 ideas to try:

0. Ban AI.

Think of AI as calculators in math classes. You can’t use them until you know the procedure you want to automate by hand.

Like any mom disciplining her kid, “No more AI until you do your homework…”

1. Study your main language syntax.

Get to know the syntax of your language of choice: write variables, functions, loops, classes…

For that, grab a textbook or watch a “all you need to know about X in 4 hours” YouTube videos. But don’t just passively consume them, recreate the examples and projects from them. By typing them out. No Control C + Control V.

2. Know your standard library.

Get familiar with your standard library:

Write a variable and see what your editor or IDE suggests.
What methods can you use with that type?
Look at their signature and docstring.

3. Study SQL.

No matter how powerful ORMs are, we can’t escape from SQL.

We’ve had SQL since the early 70s and chances are we’re still using SQL another decade or two.

Learn to create tables, write queries aggregating results, and learn about JOINs. Download a light version of the StackOverflow database and play with it, if you want realistic examples.

4. Build a toy project from scratch.

OK, I’m not talking about reinventing the wheel to write your own text editor or something.

I’m talking about building a recipe catalog, a todo app, or a CLI wrapper around a free API. And build it from scratch: right click, then create new folder in your editor or IDE, and so on. It will teach you a lot.

5. Find your own answers.

When you get an error message (you will if you follow #4), resist the urge of going back to AI or simply asking a friend.

Try to figure out errors and exceptions on your own. Start by googling the error message. There’s a thing called Google that finds web pages with answers to our questions. Sure, it’s old-school but it builds real muscle. Remember, AI is still banned. (See #0)

6. Learn the most common data structures.

80% of the time, you’ll only need lists and dictionaries. But there are more data structures of course.

Learn to use them and how to implement them. You won’t have to implement them from scratch at your daily job, but it will stretch your problem-solving muscles.

7. Study a textbook on Math for Computer Science.

Unless you’re working on niche domains, you won’t need advanced Math.

But grab a book on Discrete Math (or Math for Computer Science) and study a chapter or two. Again, to sharpen your thinking.

8. Practice rubber-duck debugging.

You will get stuck a lot. That’s a feature of being a coder, not a bug.

When that happens,

Grab pen and paper
Go through your program line by line
Talk out loud

9. Read the official documentation.

Pull out the Mozilla’s Web Docs, Microsoft Learn, and any other official source for your language of choice, and not only read it, but come up with your own examples and think of how you can use what you’re reading in your own code.

AI is a blessing for learning. Ask any veteran who learned from reference manuals, language specifications, and magazines, they’ll tell you. Just don’t let AI think for you. OK, let’s slightly lift the AI ban, don’t use it to generate code. Use it as your copilot, not as your captain.

To help you build hype-proof skills, I wrote Street-Smart Coding. The roadmap I wish I had on my journey from junior/mid-level to senior.

Friday Links: Negativity, Git Notes, and hating your manager

2025-06-27T00:00:00+00:00

Hey there.

Here are 4 links I thought were worth sharing this week:

#1. I was wrong to think I had to point out everything “wrong” at work. I had good intentions. But it only gave me a reputation as someone problematic. Stay away from negativity. That’s this developer’s best career advice (4min)

#2. I have never used Git Notes. Yes, that’s a Git feature. But it seems to be the coolest and most unloved Git feature (5min)

#3. I don’t think I’ve ever “hated” one of my managers. And I’ve had managers who were amazing and some who didn’t know what they were doing. But here’s why we engineers (sometimes) hate our managers (7min).

#4. Despite all Internet advice about surviving the AI trend, we should stop getting good at ChatGPT (20min). Because to get “good” at using ChatGPT to execute your tradecraft is thus to get good at commoditizing your own labor and your craft.

And in case you missed it, I wrote on my blog about how to split an array into odd pairs (an interview exercise) (6min) and some ideas to avoid being ghosted when emailing busy people (3min).

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.

How to Split an Array Into Odd Pairs (An Interview Exercise)

2025-06-26T00:00:00+00:00

Here’s an exercise that I may or may not have found… or been asked to solve.

Off the top of my head, the exercise might or might not have looked like this,

Let’s start with an array of integers of even size. Return if the array can be divided into N/2 pairs where each pair adds up to an odd number and those N/2 pairs contain every element of the given array.

For example, [1, 2, 3, 4] passes those two conditions. Here are its pairs: (1, 2) and (3, 4). Their sum is an odd number.

But [1, 3, 5, 7] doesn’t pass our two conditions. Each pair adds up to an even number.

Cheating with StackOverflow and Copilot

Let’s create a producer-like method to generate all pairs, and then filter them out based on our two conditions.

I’d like to write something like this,

bool HasFunnyPairs(int[] array)
    => array.Pais()
        .Where(pair => IsOdd(Sum(pair)))
        .Combinations(array.Length / 2)
        .Any(combination => IsEachElementInExactlyOnePair(array, combination));

First, generate all pairs with an odd sum, then form N/2-size combinations, filtering out those that don’t include every element of the array.

Since, we’re already in the future and I’m not in front of a whiteboard and an interviewer, I’m cheating with StackOverflow and Copilot.

Generating k-Combinations

Here’s a StackOverflow answer with a recursive method in JavaScript to choose k-combinations of an array,

function choose(arr, k, prefix=[]) {
    if (k == 0) return [prefix];
    return arr.flatMap((v, i) =>
        choose(arr.slice(i+1), k-1, [...prefix, v])
    );
}

I asked Copilot to translate it to C#. After some tweaking, we have this,

static IEnumerable<IEnumerable<T>> Combinations<T>(IEnumerable<T> source, int size)
{
	return CombinationsInternal(source, size, null);

	static IEnumerable<IEnumerable<T>> CombinationsInternal(IEnumerable<T> source, int size, List<T>? prefix = null)
	{
		prefix ??= [];

		if (size == 0)
		{
			yield return new List<T>(prefix);
			yield break;
		}

		var length = source.Count();
		foreach ((T element, int position) in source.Select((element, position) => (element, position)))
		{
			List<T> newPrefix = [.. prefix, element];
			foreach (var combination in CombinationsInternal([.. source.Skip(position + 1)], size - 1, newPrefix))
			{
				yield return combination;
			}
		}
	}
}

With that method, we can write Pairs() to generate a list of tuples, representing each pair,

static IEnumerable<(int First, int Second)> Pairs(this int[] array)
    => array.Combinations(2)
            .Select(pair => (First: pair.First(), Second: pair.Last()));

Finding if each element is present in only one pair

The methods IsOdd() and Sum() are easy. The one left is IsEachElementInExactlyOnePair(). Copilot to the rescue again,

static bool IsEachElementInExactlyOnePair(int[] elements, IEnumerable<(int First, int Second)> pairs)
{
    var elementCount = new Dictionary<int, int>();

    // Count occurrences of elements in pairs
    foreach (var (First, Second) in pairs)
    {
        elementCount[First] = elementCount.GetValueOrDefault(First) + 1;
        elementCount[Second] = elementCount.GetValueOrDefault(Second) + 1;
    }

    // Check if each element appears exactly once
    return elements.All(e => elementCount.GetValueOrDefault(e) == 1)
           && elements.All(e => elementCount.ContainsKey(e));
}

Now, after some gluing and turning some of those methods into extension methods, here’s the final solution,

On a Helpers.cs file,

namespace HereIGo;

public static class Helpers
{
    public static IEnumerable<IEnumerable<T>> Combinations<T>(this IEnumerable<T> array, int size)
    {
        return CombinationsInternal(array, size, null);

        static IEnumerable<IEnumerable<T>> CombinationsInternal(IEnumerable<T> array, int size, List<T>? prefix = null)
        {
            prefix ??= [];

            if (size == 0)
            {
                yield return new List<T>(prefix);
                yield break;
            }

            var length = array.Count();
            foreach ((T element, int position) in array.Select((element, position) => (element, position)))
            {
                List<T> newPrefix = [.. prefix, element];
                foreach (var combination in CombinationsInternal([.. array.Skip(position + 1)], size - 1, newPrefix))
                {
                    yield return combination;
                }
            }
        }
    }

    public static IEnumerable<(int First, int Second)> Pairs(this int[] array)
        => array.Combinations(2)
            .Select(pair => (First: pair.First(), Second: pair.Last()));

    public static int Sum(this (int First, int Second) pair) => pair.First + pair.Second;

    public static bool IsOdd(this int n) => n % 2 != 0;

    public static bool IsEachElementInExactlyOnePair(this int[] elements, IEnumerable<(int First, int Second)> pairs)
    {
        var elementCount = new Dictionary<int, int>();

        // Count occurrences of elements in pairs
        foreach (var (First, Second) in pairs)
        {
            elementCount[First] = elementCount.GetValueOrDefault(First) + 1;
            elementCount[Second] = elementCount.GetValueOrDefault(Second) + 1;
        }

        // Check if each element appears exactly once
        return elements.All(e => elementCount.GetValueOrDefault(e) == 1)
               && elements.All(e => elementCount.ContainsKey(e));
    }
}

On a Main.cs file,

using HereIGo;

static bool OddPairs(int[] array)
    => array.Pairs()
        .Where(p => p.Sum().IsOdd())
        .Combinations(array.Length / 2)
        .Any(combination => array.AllExactlyInOnePair(combination));

OddPairs([1, 2, 3, 4]); // true
OddPairs([1, 3, 5, 7]); // false
OddPairs([1, -1]); // false
OddPairs([2, -1]); // true

AI has changed the the tech interview landscape for good. The other day, I asked AI to solve another interview exercise. And I was surprised. And more recently, I’ve used Copilot to help me with these 4 boring coding tasks. Yes, AI isn’t going anywhere. So we as coders have to adapt, like we have always done.

The Most Challenging Managers to Work With (And What to Do About It)

2025-06-25T00:00:00+00:00

I’ve changed my mind about what a good manager is.

At one past job, I worked on short-term projects. Every six months or so, I had new projects with a new team leader and sometimes a new team.

I worked with all kinds of managers. From those who still coded to others who hadn’t touched code in years.

The most challenging ones? The newly promoted team members.

In times of uncertainty, which is pretty much all the time, they fell back on what they know best: coding. And they forgot that as managers, they aren’t the best coders anymore.

In those situations, the best thing to do is follow the advice from Why Engineers Hate Their Managers:

If you’re an engineer frustrated with your manager, consider that they might be drowning too—sometimes the best thing you can do is have an honest conversation about what you both need to succeed.

The day before, they were just teammates who got a quick promotion, tapped on their shoulder with no training or clear expectations. Just, “You’re a manager now. Figure it out. See you at the next performance review.”

I used to think a good manager was a still-technical team member making code-level decisions. Now, a good manager is simply someone I’d like to work with again.

Remix Your Best Content Ideas—Like a Hit Song

2025-06-24T00:00:00+00:00

If you’re like me, you’ve listened to your favorite songs plenty of times.

Not just often, but over and over, in different versions. A live version during a concert, a studio version with a string quartet, or a duo version with another well-known artist.

If singers do it, why not do the same thing in our content?

A good post can become an email for your newsletter or part of a book chapter. The message stays the same, but presented in a new format for a new audience. And that makes it different.

As Robert Birming put it on Blog Recycling,

Dig up an old post and rewrite it from your current perspective. It’s not cheating, and it’s not copying. It’s growth.

It’s like singers giving a popular song a fresh arrangements, just like we can to our best posts.

5 Reasons Why Listicles Rule Online (And Crush It on Social Media)

2025-06-23T00:00:00+00:00

#1. They offer a clear promise. “10 reasons” or “5 mistakes” are way better than “on writing” or “some thoughts on blogging.” It’s clear what to expect from the first two.

#2. They are easy to digest and skim. People don’t read online. They skim. A listicle with bolded bullet points or subheaders is easier to skim than text-heavy essays. People can jump in at any point after skimming. And even if they only read those subheaders, they will take away some value from a listicle.

#3. They follow a proven structure. Listicles are popular because they work. The 10 Commandments, The 48 Laws of Power, and 21 Lessons for the 21st Century are just three examples of listicles.

#4. They offer more interaction points. Every point invites comments and conversation. “I really like point #n…“

#5. They offer more repurposing opportunities. Listicle points with the most interaction make great standalone posts. See #4. That’s one tip to double our post count.

Best of all? If you already write 10 ideas a day, listicles practically write themselves.

I've Replaced My Second Brain With a Simpler Method

2025-06-22T00:00:00+00:00

For a long time, I was a note-taking freak.

I spent hours trying to find the perfect note-taking system. I tried a bullet journal, a simple A-4 sheet of paper folded twice, and an endless .txt file. I probably have an old comparison table of note-taking buried in my old computer.

Starting a second brain

Years later, probably scrolling on Hacker News, I found out about the Zettelkasten method.

It fascinated me so much that I read How to Take Smart Notes to learn more about the method and started my own “zettel.” But recently I realized that I barely revisit most of my notes. I’m not interested in the same topics anymore.

Simply writing 10 ideas

And after reading some of James Altucher’s books and recovering from burnout, I’ve changed my mind about productivity and to-do lists.

Instead of to-do lists and goals, I’ve started to write 10 ideas a day to become an idea machine. It has changed my note-taking habits too. Now, after every book, podcast, or course, I write down 10 key lessons. It forces me to recall the main ideas from the content I consume. I don’t need to write every single detail but rather remember the 10 points that resonate the most. That effort makes the learning stick.

I still write down the quotes I like the most from books I read. But I’ve stopped chasing second-brain systems and testing every new AI-powered app. I simply write 10 ideas. It’s simple and more useful than any system I’ve tried.

Writing 10-idea lists is Idea #5 in 10 Surprisingly Simple Ideas That Changed My Life And Could Change Yours Too.

Ignore These 15 Ideas and Get Ghosted When Cold Emailing Clients or Busy People

2025-06-21T00:00:00+00:00

In 2019, I started my first attempt at running a freelancing business.

I had started freelancing for a company I had just left. I thought I could do the same for other companies. My strategy for finding clients? Cold emailing any software agency I could find.

I even emailed every recruiter I found on open applications on LinkedIn. Those days, LinkedIn was flooded with “life-changing opportunities.” Sorry, I meant job listings.

I don’t remember how many emails I sent. But I remember getting just one reply. When I followed up, I only heard crickets.

Here are 15 ideas to reduce chances of getting ghosted when cold emailing clients or anyone else:

#1. Send 10 ideas for free. Don’t expect anything in return. This is James Altucher’s idea to become an idea machine.

#2. Don’t give your reader homework. “Fill out this application form to apply.”

#3. Make an offer simple to say yes. “For $x, I do XYZ.”

#4. Don’t make your reader look or feel bad. “Your YouTube video thumbnails suck, but I’m here to rescue you.” Good luck with that!

#5. Show real interest. “Hey, I’ve been following your content and liked your take on XYZ” or something like that.

#6. Start with a genuine compliment. Probably an idea I picked from “How to Win Friends and Influence People.”

#7. Sound like a real human being. Write using your own words.

#8. Don’t copy pitches from the Internet.

#9. Don’t use classical sales tactics. “Hurry up! Only X seats left. Limited offer.” Think you’re reaching out to help, not to close.

#10. Don’t just ask for something in exchange for nothing. “Let’s do a collaboration. You do something for me, but I don’t do anything for you.” Yeah, I’ve received DMs on LinkedIn in those lines.

#11. Interact with your reader’s content first on social media.

#12. Use a catchy subject line in your email.

#13. Spell your reader’s name or title correctly. You don’t know how many emails and DMs I’ve ignored simply because they started with “Hello, coach Cesar.” I don’t have a coaching business and I don’t have “coach” next to my name anywhere online. Somebody just use a template, got you!

#14. Tell them how you found their contact details. “I found your email on your LinkedIn profile…“

#15. Include your own socials or portfolio as proof you’re real. Nothing fancy, you could try adding them under your signature.

Last year, I found a job listing I liked. They were looking for people on-site in a different country, but it didn’t stop me. I reached out to the CEO sharing 10 ideas to improve their product landing page. My mistake? I misspelled the company name. Maybe that’s why I never got a reply.

Friday Links: Tricky bugs, Google Translate, and AI

2025-06-20T00:00:00+00:00

Hey,

Here are 4 links I thought were worth sharing this week:

#1. I don’t know how many times I’ve had to flip the conditions inside an if. Maybe not my trickiest bugs, but still… Anyway, here are 9 lessons from a coder’s trickiest bugs (8min).

#2. This coder doesn’t use AI and explains why (8min). One of his main concerns? Speed.

#3. Google Translate hasn’t killed translators and interpreters (6min). Maybe AI won’t kill coding either. At the end of the day, we as coders are translators too.

#4. It feels like coders will be AI’s first victims. But this might be the best time to learn software development (8min). Well, some time ago it was with textbooks, StackOverflow, forums, and instruction manuals.

I’ve been playing with Copilot recently. It’s already saved me hours of repetitive work. And in case you missed it, I’ve written about the tasks Copilot has helped me with here (3min) and here (2min).

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.

How Copilot Has Helped Me Code Faster—With These 5 Boring Tasks

2025-06-19T00:00:00+00:00

This week, I’ve been running a coding experiment.

Every time I sit to code, I open Copilot (on a browser, not inside my IDE) and look for tasks to delegate.

Yesterday, while migrating a legacy Visual Basic application, I found myself doing some mundane and repetitive work. So I hired Copilot as my junior coder. And here are the tasks it helped me with:

#1. Populate an enum.

I had a large While loop full of If statements on the VB side.

It used magic strings for the comparisons. I gave the original VB code and asked Copilot to populate an existing C# enum with the missing magic strings.

#2. Use comments to emulate named parameters.

A method with dozens of parameters isn’t that weird in a legacy app.

To make it easier to port, I gave Copilot the signature of a method and a code block that invoked it, and asked it to use comments to document each parameter name.

Later, I found out VB has named parameters. Arrggg! Anyway, that wasn’t code I was planning to commit. It was just to make it easier to read and port to C#.

#3. Avoid jumping between files.

Why create constants when we could use magic strings, right? Another common mistake on legacy apps.

In a unit test, in the Arrange part, I needed to generate identical objects, except for the values for a pair of properties.

The problem? I needed to look at three VB files to come up with the right combination of values for each object. So I gave Copilot the three code blocks and asked it to generate a 3-column table with the values I needed. No more jumping between files.

#4. Convert stored procedures into Entity Framework Core queries.

I’m not going to discuss which one is better. Stored procedures or ORMs.

But I found myself migrating stored procedures with fairly simple queries to LINQ-like queries with Entity Framework. So I gave Copilot my entity classes and asked to generate the equivalent queries.

This might not work for large and complex queries inside stored procedures.

#5. Review a patch looking for typos.

Before opening PRs, I asked Copilot to look for typos and suggest more descriptive class, method, and variable names.

Naming is hard and it always generates a lot of back and forth in code reviews. To avoid long discussions, I gave Copilot a git diff of my changes and asked it to be my code reviewer.

I’ve found Copilot shines at text-heavy processing tasks and filling the blanks of well-defined tasks. I’ve already tried these five tasks. But it’s not great at vague instructions like “migrate this to C#” or “refactor this code block.” With clear instructions, it’s the best intern for tedious tasks.

5 Lessons I Learned from a World-Class Peak Performance Expert

2025-06-18T00:00:00+00:00

What’s the first thing that comes to mind when you hear “productivity?”

Eisenhower matrix? Eat that frog? Pomodoro technique? Listing daily and weekly priorities?

We often mistake productivity for choosing the right tools and techniques. And we procrastinate by tweaking tools instead of doing actual work.

I was one of those people. Multiple to-do lists, constantly syncing them between devices. But since last year, I’ve ditched my to-do and goal lists. Instead I’ve been focusing on my energy levels and working on my mind, body, and spirit every day.

Yesterday, I stumbled upon a webinar by Leon Castillo, “an entrepreneur, investor, and university professor obsessed with peak performance & entrepreneurship.” He helped me confirm some of my ideas and made me realize what I was doing wrong.

Here are 5 lessons I learned from him:

#1. We aren’t wired for focus. I guess our primitive brain developed to look for small clues in our environment. A slight movement behind a bush could mean we were a fierce predator’s dinner. So we need to create the right conditions for focus.

#2. Reduce the amount of information you consume. Everything and anything around you competes for the same reserves of attention and energy. Use them wisely. For example, don’t use your cellphone first thing in the morning. Instead use it at lunch or at night if you’re a morning person. Take the Morningness-Eveningness Questionnaire (MEQ) to find out if you’re a morning person or a night owl. “Moderate morning” person around here.

#3. Have a clean and organized environment for work.

Work next to a window or close to nature.
Make your workstation as bright as possible.
Don’t rely too much on white noise. Work in silence.
Put your phone away. It distracts you even when silent or powered off.

#4. Batch focused work on 90-minute sessions, followed by 20-minute rest sessions. Our brain works best in periods of high intensity, followed by periods of low intensity. And the best type of rest activities? Meditation or napping.

#5. Meditation doesn’t have to be complicated. Sit in silence for 15 minutes, with as little sensory input as possible, and notice your breathing.

After watching that recording, I felt the urge to audit my daily routines. I need to protect my mornings. No more social media until afternoon.

And if I could summarize his talk in one single line, it would be: It’s not how hard you push, it’s how well you rest.

10 Reasons Why I Write 10 Bad Ideas Every Day

2025-06-17T00:00:00+00:00

Since October 2024, I’ve been writing 10 bad ideas every day.

OK, maybe I’ve missed a day or two. But when that happens I write another 10-idea list to keep up.

I found this habit by pure accident. I was looking for ways to improve my writing skills. And I found “write 10 headlines a day.” That was inspired by James Altucher’s concept of becoming an idea machine.

Since then, I’ve written 10 bad ideas for books I could write, courses I could create, and writing experiments to run. The point isn’t to come up with good ideas and execute each one, but to think freely and expand our horizons.

That’s one of the habits I’m sticking to, here are 10 reasons why:

#1. It helps me calm myself down when stressed. Writing 10 ideas redirects my brain from a stressful situation to a higher-priority task.

#2. It helps me generate content ideas for blog posts and LinkedIn posts. Often I turn my 10-idea lists into multiple pieces of content I post online. This post started as a 10 idea list.

#3. It helps me decompose a big project into smaller tasks. Before starting a big project, list 10 initial ideas. Then pick one of those first 10 ideas and write another 10 to execute on it.

#4. It helps me keep my brain sharp. It’s exercise for my brain. Alzheimer’s, stay away from me.

#5. It helps me do something creative every day. Writing 10 bad ideas a day keeps my possibility and creativity muscles strong.

#6. It helps me avoid ruminating thoughts. Again, it shifts my focus from reliving the past to a more productive task.

#7. It helps me train my focus. I try not to think about anything else until I write 10 ideas. But there are thousands of thoughts coming and going. The goal is to focus on hitting 10 ideas. And that’s hard.

#8. It replaces note taking. After finishing a podcast episode or book, I write a “10 lessons learned” list. It helps me with recalling and retention.

#9. It teaches me to simplify my sentences. I use a notepad that fits into my back pocket, so I don’t have much space to write a paragraph. I need to write a short sentence.

#10. It helps me use my cellphone less. Life happens away from screens. And since I use old pen and paper to write my ideas, that’s time away from my phone. I started with a DIY notepad made from recycled materials. Then I bought a real notepad.

I don’t think I’m exaggerating when I say writing 10 ideas a day has made me more creative. Well, without any drama, it has helped me keep my daily writing streak.

Grab pen and paper and write your first 10 bad ideas. They will push your brain and challenge your creativity. It changed my life and could change yours too. Try it!

There's Nothing Wrong With Blogging for Attention

2025-06-16T00:00:00+00:00

I’m jumping into the online conversation about blogging expectations.

I found out about it on joelchrono’s blog. But somebody else started it. I can’t find those initial posts anymore.

Here’s what I expected from my blog

I started blogging to improve my coding.

That’s what Google recommended and I bought the idea. So in 2018, I started blogging to document my learning as a coder and the problems I was solving at work.

A couple of years after my first post, I added analytics with GoatCounter. And to my surprise, some people read my posts. Thanks, Google!

Then to increase my pageviews, I started to repost on dev.to and to share my posts on LinkedIn. That was the strategy I found to increase my blog traffic.

So I was writing:

To document my journey,
To please the SEO gods,
To rank on Google first page, and
To have people reading my posts.

I started with no plans, just to improve my coding skills. But I discovered SEO and a love for writing.

Blogging has given me a few moments of attention

Since then, my blog has done more for my career than a portfolio.

Apart from occasional virality and a bit of lunch money, my blog led to unexpected results:

Getting my blog curated on Minifeed
People on Reddit roasting one of my posts
A reader compiling his favorite posts from my blog
One of my blogging heroes reacting to one of my posts
An interview going faster after I showed my unit testing posts
One veteran coder emailing me after one of my posts going viral
Readers emailing me to point typos or issues in my code samples
One reader emailing me to share how one of my posts resonated with them
Another writing hero tagging me in one of his posts after a discussion in the comments

Those unexpected moments showed me that my writing resonated with people. Sometimes I’m not writing into the void.

Even if I had to start over, I’d still blog. For my mental health and creativity. And yes, for a bit of attention.

10 Brutal Truths About Writing I Learned After Posting Over 300 Times on LinkedIn

2025-06-15T00:00:00+00:00

I made my first $100 online on LinkedIn.

It was pure luck. Or a happy accident. Dunno. I wanted people to notice my coding blog and I started to share links to my posts on LinkedIn, pretending to steal their users.

Of course, it was the wrong strategy. I got almost zero engagement on LinkedIn and almost zero visits to my blog. Social media platforms want their users trapped in the platform.

But by sharing those blog posts, the head of marketing of a software company reached out and asked me to write something similar for them. Boom! My first $100.

At some point, I gave up posting and abandoned my LinkedIn account.

But those $100 were in the back of my head. In 2024, I challenged myself to write 100 native posts on LinkedIn to revive my account and see what happened.

Since then, I’ve published over 300 posts. This is what I learned:

1. There’s no a single skill called “writing”

Writing isn’t just one skill.

It’s a collection of subskills:

Writing hooks,
Formatting and editing,
Storytelling,
Copywriting,
Offer creation…

You have to practice and master each one.

2. Writing can feel lonely

We all start from almost zero, apart from ex-coworkers and friends as connections.

In my first days, I published my posts and sat down waiting for people to come and like and comment my posts… and waited… and waited… and waited. It was a small town in the Wild West before a Mexican standoff.

Make friends and interact with other accounts. Otherwise, it’ll be you and your screen alone.

3. Writing is an infinite game

And like any other infinite game, you lose if you stop playing.

So keep writing. Write as if nobody is watching. Write for your past self. And keep writing because you don’t know who you’re helping.

4. An intention makes you start but a system keeps you showing up

Find ways to capture ideas and the content you consume and turn them into content.

I keep an eye on everything I consume: books, podcasts, and social media posts. I capture and connect those ideas, and then I write about them.

I write 10 bad ideas a day. Credits to James Altucher. Most of those 10 ideas come from the content I consume. In fact, this post started as a 10-idea list. And I stole this subject from a creator I follow.

When you look with the right attitude, there’s content everywhere.

5. You can’t predict your next hit

Often, my most viewed posts are the ones I write to mark the calendar and call it a day. Not the ones where I spend time choosing the right image or crafting the best post body.

Since you can’t predict your next hit, keep posting, look at the data, and iterate.

6. Hooks can make a huge difference

Picture this, someone busy or bored at work is scrolling down their LinkedIn feed, waiting for the next dopamine hit.

You have to make them stop scrolling with your posts. For that, you need an attention-grabbing first line. That’s what in LinkedIn terms is called a “hook.” It’s your welcome sign.

Often I just repost the same post, but with a better hook and, boom! I get way better engagement.

A good hook can make a huge difference.

7. If it can benefit one person, you can write about it

When I started writing, it was hard to decide what to write about.

You’re throwing everything at the wall to see what sticks. But if what you’re writing can benefit one person, you can write about stories, lessons, mistakes, rants, challenges… Anything.

Remember you’re writing to serve your readers, not to show how smart you are.

8. Writing is the front door for sales

Build an audience and serve that audience and you’ll make money. I’m still figuring this out. I’ll share results in the future.

9. Your best writing course is noticing your behavior as reader

If you want to get better at writing, stop being a dopamine junkie and put on your creator glasses.

Every time you stop to read something, ask yourself:

Why did this post make me stop?
What type of visuals did it have?
What structure did it use?
What hook did it use?
What call-to-action?

Then replicate that in your content. Steal like an artist.

10. Don’t give up on an idea unless you try it multiple times

You can’t predict your hits. Remember? And if a post has low engagement, it doesn’t mean it was a bad idea.

Give it another lick of paint and try it again. Don’t worry there’s nothing wrong with repurposing old content. Nobody will notice. And everybody does it.

Writing on LinkedIn (or anywhere online) makes people see you as an expert. Maybe you’ll land your next job from posting. You’ll make new professional connections (your network is your net worth). Or simply you’ll make $100. I can promise anything, but why not trying it yourself?

The Real #1 Sign You've Become a Senior Software Engineer

2025-06-14T00:00:00+00:00

I’m not exactly sure when “Senior” made its way into my title.

In my last full-time job, I was “Software Engineer 1” out of 5. But I worked on the main features of the software, was in the on-call rotation, and sat in meetings with the company’s president. A “SWE 1” wasn’t supposed to be doing most of those tasks.

OK, that was at a small shop in my city, so maybe it wasn’t that impressive. And it took me about 5 years and a lot of hard work to get there.

Although “Senior” wasn’t officially part of my title, there was a sign I saw in my coworkers and mentors, and later connecting the dots, I noticed I had absorbed from them:

Knowing when to stop because a solution is good enough.

As non-seniors, we keep wasting time:

Adding abstractions,
Micro-optimizing infrequently-used code,
Debating variable names during code reviews,
Starting massive unrequested refactorings, and
Overengineering our app to make it scale.

You’re senior when you truly master YAGNI, not only in your code files, but across your entire career.

Starting out or already on the coding journey? Join my free 7-day email course and refactor your coding career–I distill 10+ years of career lessons into 7 short emails.

Friday Links: Layoffs, outliers, and interviewing

2025-06-13T00:00:00+00:00

Hey, there.

Here are 4 links I thought were worth sharing this week:

#1. The day I “was let go” last year, I was told it was because of how tough the economy was doing. High interest rates? AI? But this news article shows the real reason behind layoffs in the tech sector (10min). Spoiler alert: nothing to do with AI.

#2. With AI, our job is to know when to introduce outliers (4min). “In a sea of fish, you want to be a narwhal.”

#3. Like coding, interviewing is another skill to master. Yes, I agree the tech interview is broken and we don’t know how to fix it. But if you’re actively interviewing, here are 8 dos and don’ts to ace your next interviews.

#4. At some point we all as coders have to make a choice: stay technical or jump the management track. The thing is being an engineering manager has never been harder (5min), too many hats to wear.

And in case you missed it, I wrote on my blog about 10 steps I’d take to build a profitable brand from scratch (4min) and 10 lessons I learned from the worst moment of my career (4min). Not much about coding this week.

(Bzzz…Radio voice) This email was brought to you by… Join my course Mastering C# Unit Testing with Real-world Examples on Udemy and learn unit testing best practices to write readable and maintainable unit tests in C# while refactoring real unit tests from my past projects.

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.

10 Life-Changing Lessons I Learned the Hard Way—from the Worst Moment of My Career

2025-06-12T00:00:00+00:00

Two years ago, my life sucked. Completely. I felt like a complete loser.

In 2023, I got sick. One day, out of the blue, I started to rush to the bathroom after every meal. And it wasn’t to throw up.

By the end of 2023, I burned out. And in 2024, I was laid off. A simple call over Microsoft Teams ended my 5-year career at a company.

I felt so lost. I felt more lost than when I was a teenager out of high school trying to figure out life as an adult.

That was the worst moment of my career and probably of my life. But that whole situation taught me these 10 lessons:

1. Your health and well-being are more important than any job.

When I burned out, I had stopped working out, running, and eating healthy.

I was so focused on my career that I had forgotten about resting and taking care of my health. It was a painful mistake.

Remember you can always get a new job and a new career, but not a new body.

2. You’re more than your job title.

For years, my career was probably the most important part of my life.

My job was what brought me a sense of accomplishment, fulfillment, and joy… until I heard a “We have to let you go” on a call. It shook my world because I had wrapped my entire identity around a title: “Software Engineer.” It became all I thought I was.

Remember, diversify your sources of joy and fulfillment.

3. Build multiple sources of income like your life depends on it.

No job is safe.

I used to think being an employee was the safest route. I don’t know who made me believe that. I was so wrong. Being an employee is like having one single customer who can decide to stop buying from you at any time.

Don’t only rely on your paycheck. Have more than one way to make money.

4. The moment you stop learning and growing, it’s time to go.

For months and years, I delayed the decision of finding another job or starting my own thing. Being at a “good enough” job was the most expensive decision for my career.

5. Do something that brings you joy every day.

It took me months, probably one entire year, to feel free from burnout. The path was simple but slow: going back to my hobbies and practicing them every day.

6. Your connections and online presence are way better than a CV.

Right after the layoff, I felt relieved. No more meetings or emails.

But after a few weeks, I went into panic mode. I realized no paycheck was coming. I applied to anything with “software engineer” in the job description. I took the CV route. And I don’t have to say it led me nowhere.

When the layoff season came, I didn’t have a solid network and I had set aside my online presence. Your brand is your CV and portfolio.

7. Be careful with what you put in your body and mind.

Apart from pills, to recover from my stomach sickness, I had to eat fruits and vegetables, at a fixed schedule, and eat them slowly.

To recover from burnout? It started with an information diet.

I cut news, music, podcasts, TV shows, movies…. I only focused on binge-watching Borja Vilaseca, a Spanish YouTuber with an inspiring story of personal and professional reinvention.

8. Change and reinvention start in your mind.

It was a little voice in my head that made me start again.

“If you don’t get up by yourself, nobody else will do it for you.” Maybe it was all the inspiring YouTube videos and books I had started to consume.

You have to choose yourself first. Always.

9. Listen to your body for small clues.

I didn’t wake up burned out. It was a slow process on the way down.

Now that I connect the dots, there was a clear sign I failed to notice: not wanting to get out of bed. My body was yelling and I ignored it.

After more than one year, I could say I’m free from burnout.

But just thinking of where I was makes me anxious again. That’s my best motivation to keep working today. I thought I wouldn’t make it. Being healthy and doing something I love felt like a distant goal I would never reach.

No storm lasts forever. Your current struggles will become lessons and stories to share. Like the French say: “Après la pluie, le beau temps.” There’s always sunshine after the rain.

TIL: You Don't Need AsNoTracking() When Projecting Entities With Entity Framework Core

2025-06-11T00:00:00+00:00

Every time we retrieve an entity with Entity Framework Core, it will track those entities in its change tracker. And when calling .SaveChanges(), those changes are persisted to the database.

For read-only queries, we can add .AsNoTracking() to make them faster.

But when projecting an entity into a custom object, there’s no need to add AsNoTracking() since Entity Framework doesn’t track query results with a type different from the underlying entity type. Source

For example, let’s save some movies and retrieve them with and without a custom projection,

using Microsoft.EntityFrameworkCore;

namespace LookMaEntityFrameworkDoesNotTrackProjections;

public class Movie
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int ReleaseYear { get; set; }
}

public class MovieContext : DbContext
{
    public MovieContext(DbContextOptions<MovieContext> options) : base(options)
    {
    }

    public DbSet<Movie> Movies { get; set; }
}

[TestClass]
public class MovieTests
{
    [TestMethod]
    public void EFDoesNotTrackProjections()
    {
        var options = new DbContextOptionsBuilder<MovieContext>()
            .UseInMemoryDatabase(databaseName: "MovieDB")
            .Options;

        // 0. Saving two movies
        using (var context = new MovieContext(options))
        {
            context.Movies.AddRange(
                new Movie { Name = "Matrix", ReleaseYear = 1999 },
                new Movie {Name = "Titanic", ReleaseYear = 1997 }
            );
            context.SaveChanges();
        }

        // 1. Using a custom projection
        using (var context = new MovieContext(options))
        {
            var firstMovieNameAndReleaseYear
                = context.Movies
                    .Where(m => m.ReleaseYear >= 1990)
                    .Select(m => new { m.Name, m.ReleaseYear })
                    // ^^^^
                    // This is a custom projection
                    .First();

            var noTracking = context.ChangeTracker.Entries();
            Assert.AreEqual(0, noTracking.Count());
            //             ^^^
            // No entities tracked
        }

        // 2. Using AsNoTracking
        using (var context = new MovieContext(options))
        {
            var firstMovieWithNoTracking
                = context.Movies
                    .Where(m => m.ReleaseYear >= 1990)
                    .AsNoTracking()
                    // ^^^^^
                    .First();

            var withAsNoTracking = context.ChangeTracker.Entries();
            Assert.AreEqual(0, withAsNoTracking.Count());
            //             ^^^
            // As imply by its name, no entities tracked here
        }

        // 3. Retrieving a Movie
        using (var context = new MovieContext(options))
        {
            var firstMovie = context.Movies
                .Where(m => m.ReleaseYear >= 1990)
                .First();

            var beingTracked = context.ChangeTracker.Entries();
            Assert.AreEqual(1, beingTracked.Count());
            //             ^^^
            // Since we're retrieving only one Movie, tracking happens here
        }
    }
}

Only when we queried the first movie without a projection and without .AsNoTracking(), Entity Framework Core tracked the underlying entity.

Et voilà!

For more tricks with Entity Framework Core, read how to configure default values for nullable columns with default constraints.

10 Steps I'd Take to Build a Profitable Online Brand from Zero

2025-06-10T00:00:00+00:00

In 2018, I wrote my first words online.

I had no idea what to do and how to do it. I just Googled how to get better at coding and found “start a blog.”

After procrastinating for a couple of days, choosing a name and a theme for my blog, I dumped a bunch of words into a file and hit Publish.

After years of trial and error, my analytics grew from 10 visitors a month to 1,000 visitors and I made my first $100 by pure luck.

But if I had to start all over again, here are 10 actions I’d take:

1. Think of my online presence as a business

Writing online was just something cool I did on the side of my 9-to-5.

For so long, I only thought my online presence would make me appear “attractive” to recruiters and hiring managers. I didn’t know our online presence is our most valuable asset.

Our personal brand is our own one-person business.

I started a blog because it was the only free advice I found.

But the thing with blogs is that our content is at the mercy of search engines, SEO, and their bots. Social blogs have a “feed” and algorithm to match readers with content. And that’s the best way to get faster feedback as a writer.

As a coder, I’d start in a social blog like dev.to or Medium, sharing TIL posts.

I only started on LinkedIn 4 or 5 years after starting my blog.

And I only shared links to my posts, pretending to steal LinkedIn users for my blog. Instead, I’d use X or LinkedIn to test ideas, share nuggets of my long-form content, and grow a newsletter. Speaking of which…

Subscribers are the real metric to track. Not followers, likes, or comments.

They are our true fans. From day 1, I’d invite readers to join my newsletter at the end of every post and I’d email them weekly.

5. Use consistent user handles

Oh boy! I used to think hacker-like user handles, like Napster, Codemaestro, or Neo were cool.

Instead I’d use a more professional user handle across all platforms.

6. Go for volume first

I only wrote on my blog when I thought I had something to say.

That was once in a blue moon. And when I started on LinkedIn, that was once a week. It’s no surprise I only saw traction when I went for volume.

If I were to start again, I’d go with volume: 30 long-form pieces and at least 100 short-form posts to get the juices flowing.

7. Come up with a simple content plan

For so long, I only wrote when I had something to say. No content plan.

But to fix that, I’d send one or two long-form emails to my newsletter, and repurpose them into one daily short-form post every week. That’s the simple content plan from millionaire creators.

8. Find ways to monetize earlier: courses/ebooks/templates

Making money from my online presence was an afterthought. I didn’t even know I could make money online.

To start again, I’d come up with monetization strategies after the first or second month. For example, I’d package my best-performing content into an ebook or a course and put a price tag on it somewhere like Gumroad.

Those first few dollars would motivate me to keep creating and fund higher-quality products.

9. Only after #1-#8, buy a domain and start a website

I’ve built my presence on rented land. Ooops!

And when I tried to buy a domain under my name, it was already taken. It turns out there’s a famous soccer player, a singer, and a film director with my same first and last name. Arrggg!

I’d buy a domain name, even if I didn’t use it. Or to simply point to a landing page linking to my newsletter and my other accounts.

10. Invest in courses, training, and coaching

Six years passed before I bought my first writing course.

Of course, I had consumed a lot of YouTube content to learn about SEO and blog post writing. But those were only two skills I needed to learn to make my online presence a real business.

I’d invest more in education to save myself a lot of time and take all the money I was leaving on the table. Well, it’s never too late to start again and invest in our online presence and turn it into something real.

What True Wealth Really Looks Like (And It Isn't Money)

2025-06-09T00:00:00+00:00

What does being wealthy truly mean?

Yesterday, before starting 21 Lessons for the 21st Century, I watched a YouTube interview with Yuval Noah Harari about that book. That was part of my new reading strategy. Authors often go on podcast tours to promote their books, sharing their insights and the intentions behind their books.

Towards the end, the interview closed with this unexpected idea:

“If you’re important, you don’t have a phone. If you work for somebody else, you have a phone”

That was shocking but eye-opening. The point isn’t about owning a phone per se but about having full control of our time. A phone means your boss might interrupt you with any apparent urgent issue.

That line hit really hard. It was only after a layoff that I realized I felt the pressure of always being available and responding to messages. I didn’t know how a salary had messed with my mind.

True wealth isn’t measured in currency, but in the ability to own our time. And I need to dump my phone.

5 Examples That Show How to Write Headlines Readers Can't Ignore

2025-06-08T00:00:00+00:00

What started as mindless scrolling on Medium yesterday turned into a headline-writing exercise.

I decided to stop scrolling like a zombie and pay attention to the headlines I found. To practice, I rewrote some headlines for clarity and curiosity. I wanted to follow a top Medium writer’s formula for engaging headlines.

Here are 5 headlines I found, plus my versions:

1. “Rethinking the Value of Doing Nothing”

This was a short story about a random walk in the park. An old man sitting on the grass made the author reflect on rest and productivity.

My version: “An Old Man Sitting in the Park Changed My Mind About Productivity”

2. “My Experience With ChatGPT”

My first thought: why should I care? Who are you? What did you use ChatGPT for? This post was from a writer who tried ChatGPT to speed up her writing process.

My version: “I Hired ChatGPT as My Writing Intern—Here’s What I Learned”

3. “7 Things That Show You’re Making Progress”

Making progress in what? A video game? Business? This was a post about small signs of progress when nothing else seems to be working.

My version: “7 True Signs You’re Making Progress in Life (Even When Nothing Seems to Work)”

4. “The Beautiful Habit I’ve Picked Up Lately”

This headline is too vague. A habit for what? Health? Business? A habit to achieve what? What makes it beautiful? This was a post about starting meaningful conversations.

My version: “This Simple Habit Has Taught Me More About Human Connection (Than Any Self-Help Book)”

5. “7 Obvious Signs Top Email Scammers Use to Contact You”

This was a post dissecting an email with the classic fake job listing scam. Its headline could benefit from more drama.

My version: “Ignore These 7 Signs and You’ll Fall Prey to Email Scammers Offering You Fake Jobs”

Clear beats clever. “On writing” or “On the value of consistency” tells us nothing. I declare myself guilty, too. A headline isn’t just a title, it’s a promise. Keep it clear, or lose your readers.

5 Actions to Help New Online Writers Stay Consistent (Year After Year)

2025-06-07T00:00:00+00:00

The hardest part of being a new writer isn’t writing, but writing when nobody is reading.

For me, it took me years before I saw my first 1,000 blog visitors. And when I revived my LinkedIn account in 2024, it took me over a year for my first post to finally go “viral.”

Those first months feel like shouting into the void. No likes, no comments, no followers. Nothing.

But to see results, we have to push through that phase. Here are 5 actions to try to keep showing up in those hard moments:

#1. Have a clear goal (or an anti-goal). Sometimes knowing what you don’t want is more powerful than knowing what you do want. For most of us, it’s the side gig that keeps us from going back to corporate cubicle.

#2. Join a community or find a buddy. It’s easier to keep showing up when there’s someone walking the same path next to you. Someone who encourages you and gives genuine feedback.

#3. Develop a habit. Find a time and place to practice your craft. And make the commitment to show up, even if that means staring at a blank page. Write or create for yourself, go for volume, and focus on improving your craft.

#4. Celebrate every small victory. Screenshot every extra like or new follower and revisit them when you feel like breaking the chain.

#5. Find someone to make proud or jealous. Or to prove wrong. From the E-Myth Revisited, entrepreneurs aren’t the ones who start most businesses, but frustrated employees. Maybe to prove to their boss that they could create a better business, or to make an ex jealous. Sometimes, the best motivator is hearing “You can’t do it” and proving them wrong.

Friday Links: AI taking our jobs, being helpful, and judgment

2025-06-06T00:00:00+00:00

Hey, there.

Here are 4 links I thought were worth sharing this week:

#1. Is AI really taking our jobs? Here’s a breakdown of papers and historical records to prove that the “AI taking jobs” hype is more a marketing strategy (12min) than anything else. There’s nothing to worry about (yet?) after all.

#2. There’s a difference between being helpful and being valued at work (4min). One of the two leads to stagnation in our careers.

#3. AI has made it easier to start coding or writing. The real differentiator isn’t technical skills, but judgment (3min). The real question is knowing what to build.

#4. Here’s a complete guide on prompt engineering (38min) tailored for software engineers, with good and bad examples of prompts. It looks more like a mini-course. Definitely something to keep returning every time we need to write a prompt for a coding task.

As a bonus, I found this absurd website with funny and absurd project ideas. I think I could use the Lucky Cat to bring more luck to my Gumroad store. That one isn’t so absurd.

And in case you missed it, I wrote on my blog about 7 strategies to stay sane in this AI-hype cycle (3min) and 12 nightmares every coder faces (3min).

(Bzzz…Radio voice) This email was brought to you by… Join my course Mastering C# Unit Testing with Real-world Examples on Udemy and learn unit testing best practices to write readable and maintainable unit tests in C#…while refactoring real unit tests from my past projects.

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.

This Top Medium Writer's Secret Will Make Your Headlines Impossible to Ignore

2025-06-05T00:00:00+00:00

No headline, no readers. As simple as that.

A headline is your welcome sign. If you don’t have a good one, readers won’t stop by. And no matter how thoughtful the content is, a weak headline means they won’t click or read past the first line.

And the best way to learn how to write headlines? Steal from the best. Just like artists do.

Stealing some proven headline examples

I had already stolen headlines from a famous YouTuber.

But this time, I’m stealing Derek Hughes’ headlines, a top Medium writer with over 20,000 followers.

Here are the headlines of some of his most liked posts:

5 ways to gain an unfair advantage as a writer (no one tells you about)
How to escape the life you have (the simplest habit that changed everything)
How to write an article in 5 easy steps (that anyone can follow)
This is why you’re losing readers (3 ways to keep them hooked)
4 killer openers that will hook your readers in seconds

Those headlines are irresistible. But there’s something behind them.

The secret formula behind irresistible headlines

Each follows a simple formula:

Promise + outcome + emotion (curiosity/fear/desire)

Let’s dissect them:

5 ways to gain an unfair advantage as a writer (no one tells you about)
- Promise: “5 ways”
- Outcome: “gain an unfair advantage”
- Curiosity: “no one tells you about”
How to escape the life you have (the simplest habit that changed everything)
- Promise: “the simplest habit”
- Outcome: “escape the life you hate”
- Curiosity: “changed everything”

You get the point.

It’s not a surprise why some of my best headlines worked. They promised some value with a bit of curiosity.

You only have a few seconds to hook readers. Start with a clear promise and outcome in your headlines. Don’t scare readers away with boring opening lines. Make your headlines impossible to ignore.

Remove This First Line If You Want Your Readers to Stay Past Your Opening Sentence

2025-06-04T00:00:00+00:00

17ms. That’s how fast we decide whether to keep reading or move on.

Credits to “Smart Brevity.”

No headline + no opening line = no readers

If we don’t hook readers with a headline and an opening line, they will move on to the next search result or the next post in the feed.

Yesterday, this opening line made me click away and open the next post in my RSS reader:

“In today’s fast-moving constantly-changing economy…”

And that’s not the first time I have found opening lines like that this week. “In our fast-paced world…” Nothing screams AI more than lines like those. Boooooring!

When was the last time the economy didn’t change? And the last time our world was slow?

Since we started doing accounting on pieces of clay in ancient Mesopotamia, the economy has been moving fast.

And since God said “let there be light” (or the Big Bang started. Choose your own adventure), our world has been moving fast.

There’s nothing surprising about “In today’s fast-paced blah blah blah.”

Start with blood or drama. Start with the unusual.

Remove the “in today’s blah, blah” part and keep the rest. You will have a decent opening line. And you won’t give away that you are using AI.

You only have a few seconds to hook readers before memes and cat pictures steal their attention. Make them count.

7 Strategies to Stay Sane in the Never-Ending Tech Hype Cycle

2025-06-03T00:00:00+00:00

As developers, we can’t agree on much: tabs vs spaces, what “unit” really means in unit testing. But one thing we all agree on? There’s too much hype. And it’s exhausting.

A new faster better AI tool promising to kill jobs, “X% of code is generated by AI” at every FAANG, and the stock market reacting to those announcements.

Olga asked on dev.to how we stay sane in all these hype.

Here’s what I do to stay sane:

#1. Pick the right battles. After some years, we reach a point where we should find peace in what we choose to learn and what to ignore. I consider myself a backend developer and I’m fine missing out on every new JavaScript framework or “something.js” library out there. That was a battle I decided not to fight anymore.

#2. Start an information diet. Find one single source of “official” information. Maybe company blogs or newsletters or trusted YouTube channels.

#3. Prefer long-form over short-form content. Books go through a solid vetting process before they reach us. But social media content goes viral without any vetting process and builds up the hype.

#4. Invest in what has passed the test of time. What has already survived the test of time will outlive recent trends. We’re still using C/C++, SQL, and jQuery, and reading about stoicism. Chances are those same subjects will survive another decade or two. I wouldn’t bet all my money on it, though.

#5. Wait for the dust to settle down. Again, just see what stands after months or years. Xamarin, Silverlight, Flash… All of them are gone. And just last year, we got Devin, the first AI software engineer. That was the first threat to our jobs. It was all over the headlines. These days? I haven’t heard about it since then.

#6. Embrace just-in-time learning. Instead of learning about every new shiny object, learn how to learn. And learn about new frameworks and tools in the context of real-world projects. I changed my mind about trying to learn about everything at once. Recently, I finished Skip the Line and learned fast learning strategies.

#7. Understand there will always be a new hype. I’ve seen the cloud, mobile apps, and now AI. And guess what? There were dozens before and there will be dozens more in the future. Let’s see what stands after the hype fades.

The Biggest Obstacle Stopping People From Writing Online (And What to Do About It)

2025-06-02T00:00:00+00:00

“I don’t want to expose myself,” an ex-coworker texted me.

He had noticed my LinkedIn posts and reached out to ask me how to start. He knew that writing opens doors but feared exposure. That’s one of the most common writing myths.

If you have the same concern:

#1. You don’t have to share selfies or post foot photos. Selfies work best on Facebook or Instagram… And there are places for foot photos.

#2. It takes time and consistency to make people care. Your first post won’t make you an Internet celebrity. Magazines won’t write gossip articles about you. Your first post will be crap. (Mine were.) And nobody will care, not even your boss.

And that’s fine. That’s not to discourage you, but to remove all the pressure of writing.

#3. Don’t share anything you wouldn’t mention in a work meeting. You can keep your online presence as professional and personal as you want. If you’re a coder, start sharing TIL posts.

Forget about going viral. Forget about the influencer vibe. Write for one person. Write for your past self. Share what you’re learning. Show your work. That’s the best way to start.

The Simple Yet Effective Content Strategy and 5 Key Lessons from a Millionaire Creator

2025-06-01T00:00:00+00:00

In 2024, I went all in with my writing. One of the biggest inspirations behind that leap was Dan Koe.

He has more than 500K followers on X/Twitter, over 200 videos on his YouTube channel, and has sold millions online. He’s one of those internet names that made me believe making money online is possible.

This time, I watched this interview between Dan Koe and Callum Johnson.

Here are some of my takeaways:

#1. A brand isn’t about colors, headshots, or taglines. A brand is an environment you invite people into. It’s your goals, interests, and perspective.

#2. If you don’t know where to start your journey, start with an anti-vision: things you don’t want in your life. For most of us, that’s going back to a full-time job to work on something we don’t care about.

#3. Start by helping others solve a problem you already have solved. And your first product could be an improved version of a product that transformed your life. Create it and promote it to your past self.

#4. A content strategy doesn’t have to be complicated. One long-form piece repurposed into social media posts every week. And every social media post invites people to your newsletter, where you promote your products.

#5. Nothing is original. Creating is about remixing ideas. And if you share it in your own words it’s not copying or stealing.

#6. You don’t need to be discouraged if a “big name” or influencer offers something similar to what you offer. That’s a faulty belief that assumes everyone knows and follows every influencer.

I always remember one of Dan Koe’s quotes: “The goal is being paid to be you.” That’s one of my favorite quotes. A niche isn’t just about talking only about one topic forever. Your goals, mission, and transformation make you the niche. Don’t chase trends, create and sell to you. You are the niche.

12 Nightmares Every Coder Faces (Junior or Senior, It Doesn't Matter)

2025-05-31T00:00:00+00:00

#1. A micromanaging boss. Why trust your team members when you can ask them every 5 minutes how they’re doing?

#2. A spaghetti-style crappy codebase. Why use good names and focused methods when you can copy-paste code and leave outdated comments all over the code? It’s faster that way, right?

#3. Working on something nobody will use. Why bother having your team create something valuable for users? They’re getting paid, anyway. They don’t need motivation.

#4. QA only caring about colors, alignment, and fonts. Who cares if the app works? QA should just test how it looks, right?

#5. Too many meetings. Daily stand-ups, sprint planning, poker estimation sessions, retrospectives, another meeting to present next sprint tickets, and another one just to answer questions from the previous meeting… They’re Software Meeting Attendees, not Software Developers, after all.

#6. Clueless project managers. OK, you already explained to your PM how serious the issue you had to solve was and that’s why the sprint is behind schedule by one or two days. But they don’t seem to get it. It’s time to fire up ChatGPT and prompt it to explain like your PM is 5.

#7. Constantly being paged. Why even write clean, organized code when you can fix everything while on-call rotation, right?

#8. Not having time to refactor. Again, why bother if we can fix all those issues while on-call rotation?

#9. Code reviews taking too long. A good title and description, and a short PR to make sure it’s easier to review it… But still more than 48 hours to get it approved and merged. Arrggg!

#10. Constantly changing requirements. “What are you working on right now? Oh, there’s a new priority. Sales just promised a client a feature that wasn’t even in our roadmap…,” a random PM told a developer.

#11. Repetitive tasks and grunt work. Why bother using a computer to automate repetitive tasks and best practices if developers are cheap and fast code monkeys? A full regression testing cycle? Let’s make developers click on every button of the app. And let’s create a test case for every single text box of every single page. Manual labor is cheaper than automating it, right? They’re contractors paid by the hour, anyway.

#12. Unrealistic deadlines. “Can we add a Facebook-style feed, I mean, a full Facebook-style feature, in the three days left in this sprint? It’s easy, right? Facebook already did it,” the same PM who asked for another priority just yesterday.

If this feels familiar, I swear it’s just a wild coincidence.

Friday Links: Being replaced, job titles, and Haskell

2025-05-30T00:00:00+00:00

Hey, there.

Here are 4 links I thought were worth sharing this week:

#1. This is not the first time we developers are being “replaced.” There’s a recurring cycle of hype (6min). No code, the cloud, outsourcing, and these days AI. You name it!

#2. Here’s a breakdown of what every job title truly means (6min). I plead guilty of using Senior [Insert Technology here] Developer.

#3. Don’t be discouraged about “Haskell” in the title. Here are some silly job interview questions (15min). It’s a good exercise trying to reimplement them in your favorite language, using a more “functional” approach.

#4. Starting from .NET10, we don’t need a solution or project file to run C# programs. We can simply run dotnet run app.cs Here’s the official announcement (5min).

And in case you missed it, I wrote on my blog about six techniques to learn any skill faster (5min) and why free pizzas aren’t a good idea to motivate a team (2min).

(Bzzz…Radio voice) This email was brought to you by… Want to make your SQL Server go faster? Brent Ozar’s special anniversary sale is almost over. Only two days left.

Until May 31st, get the prerecorded Mastering bundle and save $400. This bundle includes four advanced courses covering indexes, queries, parameter sniffing, and full database optimization. SQL Server was my kryptonite until I learned databases from Brent’s courses, and I highly recommend them. Grab the bundle before the sale ends.

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.

Your Dev Team Doesn't Want Pizzas on Fridays for Motivation

2025-05-29T00:00:00+00:00

“The one who finishes all their tasks early can go home,” they told us.

It was at a past job, some time ago, in a galaxy far far away. That was their incentive to make us work harder. We were behind our deadlines and the local government’s. We were stuck in a rewrite within a rewrite.

But, surprise, surprise…

One guy finished all his tasks before the end of our 2-week sprint. I don’t know if he worked from home or padded all his estimations.

But they hesitated to give him the time off. We could tell by looking at our leader’s face when that guy handed in the time-off request form.

The next time the same guy finished earlier, they pulled more tasks from the backlog or ask him to join the on-call rotation. It was a carrot in front of the donkey.

Instead of building morale, they destroyed it and made all the trust evaporate.

Your development team doesn’t want free pizzas.

Oh, by the way, pizza was the next strategy after the “time off if you finish your task” strategy. Close to 100% sprint completion = free pizzas.

Instead of pizzas, give your team interesting work. Give them a challenge and share how that will impact the company. Give them room to figure out things on their own. And if they screw things up, don’t point fingers, let them fix things. Trust them. They’re human beings, not disposable resources. Motivation isn’t about perks. It’s about trust. Build that first.

And if nothing of that works, here’s how to demotivate them. Do the opposite.

Spanish Slang for Money—And What It Can Tell Us About Our Future

2025-05-28T00:00:00+00:00

The other day, I jumped into a discussion on LinkedIn about slang for money.

I shared the Spanish slang for money:

Plata. Same word for silver and money.
Pavos, turkeys.
Lana, wool.

And in some regions of my country, to designate millions:

Melones, melons. Yes, just like the fruit.
Palos, sticks. Yes, like pieces of wood.

While writing my comment on LinkedIn, I realized those words represent goods we used for value exchange centuries ago when we didn’t have coins or pieces of paper. I don’t know the exact origin of those words. But it makes sense, right?

These days, our definition of money has changed.

Time and attention are our most valuable assets now. The book “Your Money or Your Life” defines money as what we trade in exchange for our time. Maybe it isn’t crazy to imagine a future where “seconds of watching ads” or “minutes of doomscrolling” become our new currency. Not dollars or euros or pesos.

Maybe one day paying for dinner will cost an hour of attention or two. Scrolling, clicking, and absorbing ads designed to keep you hooked.

Six Proven Principles to Learn Any Skill Faster (Without Spending 10,000 Hours)

2025-05-27T00:00:00+00:00

Since 2020, we’re living in a new normal.

Constant layoffs, market volatility, AI stealing our jobs… The best thing to do is to learn new skills and build something we can’t be fired from.

But who has time to spend 10,000 hours becoming an expert to monetize a new skill?

Here’s where “Skip the Line” by James Altucher comes in. A book with strategies to ditch those 10,000 hours and learn a new skill faster, without going back for 4 or 5 years of college or begging to get into the small circle of “experts.”

Here are 6 principles I learned from “Skip The Line” to master any skill faster:

1. Do 10,000 experiments

It takes 10,000 hours to be an “expert.”

That’s about 10 years of part-time practice. But the world is changing so fast. By the time you’ve put in those 10,000 hours, everything will be different.

Instead of tracking hours, track experiments. Small and consistent actions that teach you a skill faster.

A good experiment:

is easy to set up and do
has little downside
has huge potential upside
has never been done before
teaches you something

“You know something is a valid experiment when you take out what you normally do, get curious about an idea, as in “What if I try…,” and then, you suddenly feel fear.”

With experiments and real projects, we learn way more and faster than in any classroom. Remember passive learning is just entertainment.

2. Master your microskills

Whatever you’d like to learn, chances are it’s not a single skill, but a range of microskills.

“Break apart a skill into 20 microskills. Figure out how, each day, you can get better at each microskill”

Writing isn’t just one skill. It’s headlines, openings, storytelling, calls to action, editing, formatting… And that’s just non-fiction.

3. Master idea calculus

You can cheat your way through those 10,000 hours by bringing your expertise from other areas.

Add a new idea or concept to an existing idea in the field you’re learning. Or subtract an existing idea from it. Or mix two disparate ideas from another field to create a new one.

4. Find PLUS, EQUAL, and MINUS

To learn anything faster, you need to find your PLUS, EQUAL, and MINUS:

PLUS are your mentors. People online or offline who you can learn from. If you can’t find mentors, books are always good mentors.
EQUAL are others learning the same skill. These are the people who challenge you and encourage you to keep learning.
MINUS are people you can teach. Teaching is the best (and fastest) way to learn anything.

5. Follow the 50/1 rule

The 80/20 rule has a close cousin.

You know the 80/20 rule, right? 80% of wealth is accumulated by 20% of people. 80% of outcomes come from 20% of effort. 80% of views and reads come from 20% of posts.

But what if we apply the 80/20 rule to itself? 80% of 80 is 64, and 20% of 20 is 4.

And if we apply it again? 80% of 64 is 51.2 and 20% of 4 is 0.8. OK, let’s round that up to 50 and 1.

It means that 1% of effort brings 50% of outcomes. That’s a cheat code to get results faster.

If you’re writing, that’s your headline, opening lines, and first paragraphs. Or your titles and thumbnails if you’re doing YouTube.

Whatever you’re doing, find your 1%.

6. Find your wheel and its spokes

One thing is mastering a skill. Another is making money off of it.

Find your wheel, your main subject or skill. Once you’ve found your wheel, look for spokes. Ways to monetize and expand your wheel.

If your wheel is photography, your spokes could be:

Sell stock photos,
Offer wedding photography services,
Shoot product images for small businesses,
Shoot LinkedIn-optimized portraits for executives,
Offer walking tours through the most scenic spots in your city,
Teach a budget-friendly photography course for beauty creators,
Offer “I fix and enhance old photos” services,
Create a course for better pet photography,
Start a newborn photography business,
Run workshops to teach others,

OK, I already wrote my 10 bad ideas for today… And you got the point. There’s more than one way to monetize a skill. Don’t marry a single one. I’m talking about ideas here.

The world still needs experts. No doubt. I wouldn’t want guesswork in an operating room. But you don’t need to be an expert to make a living. You don’t need 10,000 hours. You need more experiments, faster feedback loops. This new world is for fast learners, for those who know how to skip the lines.

The One Writing Trick to Make Your Content Clickbait-Free

2025-05-26T00:00:00+00:00

No matter how thoughtful your content is, without a strong headline, people won’t read it.

In How to title your blog post or whatever, there’s this tip for headlines or titles:

“Consider title-driven thing creation. That is, consider first choosing a title and then creating a thing that delivers on the title. It’s sad to admit, but I think there are many good things that simply don’t have good titles. Consider not making those things… In practice, it’s often something in the middle: You start to create your thing, then you choose a title, then you structure your thing to deliver on the title.”

Title-driven creation not only applies to blog posts, but also to other forms of creative output:

Before making a course or paid product, write its landing page.
Before writing a book, choose a title, write a summary, and design its cover.

Before creating, write the marketing materials first. For blog posts and social media content, that’s the headline.

Every headline is a promise. Keep your promises, and your readers will trust you.

Here are some of my best healdines.

Need to Speak in Public? Write a Good Post First

2025-05-25T00:00:00+00:00

Public speaking starts with a clear message.

If you need to speak publicly:

Start with a catchy story
Share one main idea
Use three points to expand your main idea. Yes, three points. Our short-term memory holds around 5 or 7 items, and three is the sweet spot.
End by inviting listeners to do something about it.

And that already sounds like a good post. A good post should have a clear message too.

Even better, if you are already writing using your own voice, print your post and read it in front of your audience, making the right pauses and changes in intonation, of course.

And, don’t use a PowerPoint presentation. I learned that from James Altucher, from one of his interviews, I don’t remember which one. A PowerPoint presentation will distract the audience from the message: you and your speech.

That works for a TED talk, a keynote speech, or a sermon.

5 Ways Copilot Helped Me Code Smarter This Week

2025-05-24T00:00:00+00:00

Rejecting AI is like rejecting calculators or computers.

It’s here to stay and we have to adapt. That’s why I always keeping an AI chat open, looking for ways to automate my work. Or maybe I’m just getting lazier as I get older.

This week, I tried Copilot (on the browser) to help me with some coding tasks. Here they are:

#1. Translate a Visual Basic code block into C#. I’m working with an old legacy WebForms app in Visual Basic these days. And being honest, I’m not in the mood for learning Visual Basic, so why not just translate it using AI? And as a form of exploratory refactoring, I gave it a large convoluted block of code and asked it to explain what it does and refactor it into smaller functions. And once I understood what it did, I threw away the refactored version. Sorry, Copilot!

#2. Create a C# extension method from a code block. Sometimes I’m just lazy as an excuse to test Copilot’s capabilities.

#3. Naming is one of the most difficult tasks. So why not ask Copilot for help to come up with descriptive names? I gave Copilot a class definition, explained its purpose, and asked for a list of better names. I ended up choosing one of its options and got my PR approved.

#4. Generate Builders for test data. I gave it a sample Builder class and asked it to follow the same pattern but for some methods of a different class. Copilot nailed it.

#5. Replicate tests from a sample test class. While refactoring away from logic-heavy controllers to handlers, I gave it an existing handler and its tests. Then, after giving it the signature of my new handler, I asked Copilot to rewrite my controller tests as handler tests, following the pattern from the other handler tests and keeping my original assertions. Again, Copilot nailed this one.

And just for the record, I’m not using any fancy prompt, but this one,

“Act as a senior software engineer, with expert knowledge of the .NET stack, its libraries and ecosystem, and clean code. <Explain task here>”

I’ve found better results when I gave Copilot a sample class or code block to replicate. Think of AI as a fast junior engineer that needs clear and precise instructions. Otherwise, it takes a wild guess instead of asking for clarification.

Also as an experiment, I used Copilot to launch a coding course. And once I learned enough copywriting, I revisited some of the marketing materials I generated with Copilot. And recently, I’ve been using a prompt to replace Grammarly.

Friday Links: Microsoft, AI, and localization

2025-05-23T00:00:00+00:00

Hey, there.

Here are 4 links I thought were worth sharing this week:

#1. Microsoft has made a lot of noise this week. It laid off around ~6K people. And it made the Windows Subsystem for Linux (5min) and the Copilot Chat extension (8min) open source. It seems the layoffs and the release of open source aren’t related. At least, that’s the official version.

#2. Speaking of Microsoft, they enabled Copilot on the Runtime repository. And it seems AI can’t fix simple bugs (4min).

#3. It seems I’m not the only one who doesn’t like it when web apps use my location to decide what language to use. There’s already a better alternative to using IP addresses.

#4. One of the most common mistakes when writing tests is duplicating the logic under test inside assertions. That’s what’s called circular reasoning (7min).

And in case you missed it, I wrote on my blog about stop optimizing for scale when we don’t need it (2min) and the key to survive a stressful job (2min).

(Bzzz…Radio voice) This email was brought to you by… Want to make your SQL Server go faster? Brent Ozar, the leading SQL Server expert, is celebrating with a special anniversary sale.

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.

If You Had 12 Months to Live, What Would You Do? Here's What I'd Do

2025-05-22T00:00:00+00:00

I’ve heard life only guarantees two things: death and taxes.

One happens every year. The other? Just once.

As a thought experiment and writing exercise, if I only had 12 months to live, assuming I’m in good shape, mentally and physically, these are 7 actions I’d do:

#1. Transfer 50% of my retirement savings and net worth to my closest relatives. I want to make sure they don’t have to worry about covering their essential expenses for a while.

#2. Spend the other 50% of my net worth without any guilt. I’d backpack around Europe and South America. I definitely would walk El Camino de Santiago, the pilgrimage route along Spain.

#3. Share my blog and social media credentials with a loved one so my online presence outlives me and keeps generating income for my relatives.

#4. Write a book. The other day, while watching Chandler Bolt’s TED talk, I learned that “the best way you can serve humanity is to write a book.” I don’t expect it to become a best-seller. I just want to make sure part of my story is written somewhere for my relatives to read. That’s a good motivation to write a book. Hey if we’re still reading diaries from ancient Greece, maybe someone will read my blog or book centuries in the future. Who knows?!

#5. And, in the same spirit of sharing my story, take a picture every day for the remaining 12 months. Like a photo blog or something. Especially while walking El Camino de Santiago. That’s a perfect idea for a visual memoir.

#6. Write a letter to every family member, scheduled to be delivered after those 12 months. Okay, I know that sounds like the plot of a romantic movie.

#7. Get an organ donor card. My organs will help somebody else more than me by the end of those 12 months.

I just realized I don’t need to wait to do most of these things.

Oh, this list reminded me of one House M.D. episode where Dr. Wilson, an oncologist and Dr. House’s best friend, made a mistake and gave the wrong prescription to a patient. He told the patient he only had a few months to live. And when the patient was told about the mistake, he got angry because his family had already scheduled trips and celebrations. His life had already changed because of the prescription.

Why does life have to change when the clock is close to running out of batteries? Why wait?! Ok, maybe I got too philosophical. And I already got more than my 200 words for the day.

PS: This was a writing prompt from Ron Markley on Medium.

This Robert Greene Quote Made Me Reflect on My Sources of Inspiration

2025-05-21T00:00:00+00:00

I know we’re not supposed to multitask.

But recently, while doing the dishes, I listened to this YouTube interview between Ryan Holiday and Robert Greene, two best-selling writers.

Out of all the subjects they talked about, there’s one line that I still remember:

“It’s all material”

They both share how problematic people and unexpected situations end up being material for an email or a book.

And that line made me think about unexpected situations that have inspired me to write.

#1. The other day I took a loved one to a hospital. And I ended up writing about calming my mind, the future of hospital visits with AI, and random facts about health, which I learned on that visit.

#2. Another day, a cashier overheard a conversation I had with a friend, and her reaction inspired me to write about our definition of success.

#3. I used to feel guilty about watching movies and series. But when I started watching them through a creator’s lens, I realized how much they could teach about storytelling and writing. I’ve watched and written about Six Triple Eight, Scorpion, and House M.D.. No more guilt. Just writing lessons. After all, It’s all material.

I Thought I'd Run Out of Ideas—but 200 Posts Proved Me Wrong

2025-05-20T00:00:00+00:00

I decided to challenge myself: write every single day. No excuses.

I started back in November 1st, 2024. This is my daily post #200. I thought I didn’t have anything to share. If we think a post has to be 100% original, we seldom write. And the truth is there’s nothing 100% original.

I also thought I’d run out of ideas. But the first 100 daily posts proved me wrong and another 100 convinced me it’s possible.

Here are some of the most-read posts from the last 100 days:

And here are some of my favorites:

What posting daily has done for me

Posting daily has:

Made me conscious of the content I consume
Made me think of posts as public notes
Made me remember past stories

Some days I almost broke my streak. Some night, near mid-night, I had to rush to finish my post for the next day.

Writing 10 ideas a day to become an idea machine has helped me keep my writing goal. Some of my 10-idea lists have inspired or become posts.

Writing daily has become part of my healthy routine. It has sharpened my writing skills and helped me document ideas I would have otherwise forgotten.

The Key to Surviving a Stressful Job (While You Land a New One)

2025-05-19T00:00:00+00:00

A stressful job can take a serious toll on your mental health.

I know because I’ve had one. In that job, we were chasing our own deadlines, our clients’ expectations, and local government regulations. We were late all the time. Everyone blamed the Development team. Leaders constantly pressured us.

Working after hours was normal. We called them “Miracle Nights.” In one night, we did way more than we did in a sprint. You can imagine the amount of technical debt we were leaving behind.

While working on that job, I ate the most expensive hamburgers I’ve ever had, by the way.

But there was something that made everything easier

Our relationships and friendships made all the difference.

It was having someone who could listen, a group for Friday nights, and friends who could refer you to new jobs. That support changed everything.

Even though it was one of my most stressful jobs, I did the most to take care of my mental health while working there. It was easier because I had a “support group,” coworkers that eventually turned into friends.

If you’re working on a stressful job or not, make an extra effort to build those professional relationships. The world runs on connections. And in the end, we’re remembered not just for our work, but for how we treat those around us.

Storytelling Secrets from One of My Favorite House M.D. Episodes

2025-05-18T00:00:00+00:00

I used to feel guilty about watching Netflix and TV shows.

I felt like I was wasting time when I could be grinding. But when I started to seeing things through a writer’s lens, Netflix and TV shows became a source of storytelling lessons.

I’ve been binge-watching House M.D. this year. I’m on season 7 (out of 8). No guilt.

Recently, I watched episode 13 of season 7, “Two Stories.” It’s one of my favorite episodes.

Here’s a breakdown of the storytelling and plot from that episode—no spoilers:

#1.

The episode starts with a schoolboy and schoolgirl getting into trouble and being taken to the principal’s office.

And guess who’s also there waiting for the principal? Yes, Dr. House. How the heck did he end up there? That’s the whole point of this episode.

Dr. House is intrigued by why the two students are there.

They made a deal: they’d explain why they’re there, only if he revealed why he was there too. Of course, he’s not a student.

#2.

Dr. House starts to tell them how he got to the principal’s office.

Then, we’re taken on a flashback to a couple of hours before. He’s in front of a classroom telling the students about what he does and about his most recent case.

This is the clever, ingenious, and my favorite part:

Dr. House is telling us the episode’s backstory while he’s telling other stories: the conversation outside the principal’s office, the flashbacks, and his speech in front of the classroom.

#3.

While sharing his most recent case in front of the classroom, Dr. House starts to recreate scenes from famous movies.

And, in the classroom, there’s a movie lover who recognizes every scene. That only makes the students more interested in what Dr. House has to say.

Apart from Dr. House, there are three more guests. It seems they’re a police officer, a counselor, and a businessman. Who the heck are they? That’s something revealed at the end.

Here’s a perfect example of Dr. House’s in front of the class:

Dr. House’s storytelling is so captivating that the students keep asking questions, leaving no room for the other guests to speak.

#4.

In the meantime, we’re taken back to the principal’s office.

The two students also begin sharing why they’re there. An innocent plot from a boy trying to get closer to his crush. I won’t spoil the details.

The episode jumps between their story and Dr. House’s story. All told in flashbacks.

#5.

Finally, all the stories connect.

We learn why Dr. House is there, who the businessman in the room is, and the clue that solves Dr. House’s case.

Oh, I forgot to mention:

All that time, Dr. House had a case. He was trying to solve it via phone calls, while his team was back at the hospital dealing with the patient’s complications.

My lessons?

1. Start by grabbing people’s attention with drama or mystery. For example, why is Dr. House outside a school principal’s office?

2. Tell stories in such a way that people have to ask “What’s next?” or “Wait a second, what about that?” Use suspense, cliffhangers, and unanswered questions. Always make them want more.

In front of the class, Dr. House shares clues that are left unresolved. He was trying to hack into a laptop. The students kept asking why.

3. A proven plot to follow: Make your characters have a conversation. Use the conversation to introduce flashbacks and tell about one of the characters’ past. Then, make all the flashbacks concur in a resolving scene that puts everyone back into the initial conversation.

Wait, it seems I just described Forrest Gump: a conversation on a bench, lots of flashbacks that explain the backstory, and a resolution that ties everything together. Turns out, great stories follow a blueprint.

By the way, here’s the breakdown of Six Triple Eight, a Netflix show I also watched with my writer’s lens on.

Stop Optimizing for Scale—Most Apps Don't Need It

2025-05-17T00:00:00+00:00

In my Friday Links email yesterday, I shared one post called Programming Myths We Desperately Need to Retire.

Myth #5, “Let’s optimize for scale,” resonated a lot with me:

Most products never reach the scale you’re “preparing” for. And even if they do, you’ll have time—and budget—to refactor later.

Oh boy! Been there and done that.

At a past job, while working on a hotel management solution, we had to connect the reservation module to a third-party restaurant solution. The goal was for guests to pay their restaurant bills along with their hotel bills.

We were about six software engineers plus the QA team. We worked to make that solution scale to thousands of guests and restaurant orders. We built an eventually consistent solution with background processors using Hangfire, Domain-Driven Design, and all the best practices you can imagine.

There’s nothing wrong with that. The problem? When we finished our module and handed it off to the Product people. Nobody bought it. Six months of work…wasted.

The Product team only had a few leads when they pitched the idea to the Engineering team. But those leads weren’t going to wait six months for our integration. Or maybe the Product team wanted to list a new feature on the webpage so they could compare the product to the competitors. And after all that time optimizing for scale? Nobody bought it.

Friday Links: Coding myths, a pwned dating app, and Visual Basic

2025-05-16T00:00:00+00:00

Hey, there.

Here are 4 links I thought were worth sharing this week:

#1. We as coders take pride in our craft. We like to follow principles and best practices: KISS, SOLID, DRY. But there are some coding myths we need to retire (8min).

#2. There’s one problem with the “get things done” attitude of startups: security. Here’s a breakdown of security issues found on a dating app (8min). They had broken one-time passwords and open endpoints. Security shouldn’t be an afterthought.

#3. A URL shortener is maybe the new “hello, world” for distributed apps. But building one doesn’t have to be that complicated. Here’s a simple not-overengineered alternative (6min).

#4. Dragging and dropping controls onto a canvas is normal these days. Even the word “controls” is normal. But someone has to come up with all those ideas. They started with the release of Visual Basic, back in the 80s. Here’s the history and legacy of Visual Basic (20min).

And in case you missed it, I wrote on my blog about cURL, a simpler and faster alternative to Postman (2min) and how to find all 3-digit numbers in a tree (4min).

(Bzzz…Radio voice) This email was brought to you by… Want to master SQL Server performance tuning? Brent Ozar, the leading SQL Server expert, is celebrating with a special anniversary sale.

Only this month, get the prerecorded Mastering bundle and save $400. This bundle includes four advanced courses covering indexes, queries, and full database optimization. Everything to optimize and tune your SQL server like a pro.

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.

Ditch Your Helpers and Utilities Classes Before They Ruin Your Code

2025-05-15T00:00:00+00:00

Recently, I needed to track down how an old Visual Basic WebForms app stored a value from the database into the Session object.

But I didn’t know I was in trouble until I looked for the file in the GitHub repository and it said “(Sorry about that, but we can’t show files that are this big right now.)”

The file had 69,359 lines. Its name? GlobalFunctions.vb. You can guess what was in there just by looking at that name, right? It was a clear symptom of a deeper problem.

The problem?

The problem isn’t that it was a WebForms app in Visual Basic. We can write crappy code in any programming language. It was that huge “throw everything under the carpet” kind-of file.

It reminded me of one of the conventions I decided to ban: “Helpers” and “Utility” classes, full of unrelated static methods.

The solution?

If you’re tempted to write anything named with “Helpers,” “Utilities,” or worse, “GlobalFunctions,” please stop and consider how to split that class into smaller, more focused classes with clearer names. Smaller, well-named classes ease cognitive load, making them easier to work with.

Or even better, if you’re practicing DDD, before defaulting to a “Utility” class, ask yourself: does this belong inside an entity or value object instead?

Writing readable code, by ditching Utility classes, is just one of the skills every coder should master. But it takes more than typing symbols to become a senior coder.

That’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding. It’s the roadmap I wish I had when I was starting out.

Grab your copy of Street-Smart Coding here

cURL—A Simpler and Faster (and Free) Alternative to Postman

2025-05-14T00:00:00+00:00

Postman still isn’t opening.

Five minutes after clicking the icon… Nothing. Maybe it’s calling home, checking in with the International Space Station, or just ghosting me. Who knows?

Today I found out about Bruno, a “Git-integrated, fully offline, and open source API client”. A simpler alternative to Postman. I had come across Bruno before but had forgotten about it.

But, there’s an even simpler alternative to Postman and Bruno.

When I want to test a single endpoint, I just:

Go to the Network tab on Chrome,
Right-click on the request I want to test,
Then click on “Copy as cURL (bash)”,
Then paste it into a Terminal, and
Press enter.

cURL is a “command line tool and library for transferring data with URLs”. It comes preinstalled with Git Bash for Windows. And I’m a “terminal Git user,” so I keep a terminal open all the time. Way faster than opening an Electron app.

Here are some cURL examples to send data:

$ curl --json '{"name":"some json here"}' https://example.com`
$ curl -s --json @body.json https://example.com
$ curl -s -i --json @body.json -H "header-name:header-value" https://example.com`
$ curl -d "data to PUT" -X PUT http://example.com/

Here’s the meaning of those options:

--json: To POST a json request either as a json string or from a file.
-s: Silent mode
-i: To include response headers
-k: To avoid validating SSL certificates. Handy when an ASP.NET Core project has HTTPS redirection.

Et voilà! No waiting, no upgrades, no paywalled features. cURL is faster and simpler than Postman, which still doesn’t open on my computer. I guess it’s time to upgrade it or simply use a better alternative.

PS: Turns out Postman finally opened… after an upgrade. Unnecessary drama. Arrggg!

Two Years Ago, I Was Sick and Burned Out. But This Powerful Quote Changed It All

2025-05-13T00:00:00+00:00

In 2023, I felt sick to my stomach.

By the end of the year, I burned out. Then in 2024, I was laid off. Perfect combination, right?

For the first time, I had no idea what to do next.

One day, I called a friend to tell him how I felt and get things off my chest. “You always have a plan,” he told me.

But not that time. I only knew what I didn’t want to do. I didn’t want to go back to where I was: stomach sick, burned out, and without a job.

I felt relieved after that layoff.

But it lasted only weeks before I realized I had no paycheck coming. I checked my expenses and bank account to see how long I could last without a paycheck. Relief quickly turned into desperation. More than once.

The quote that changed everything

By chance or fate, I found this quote:

“If you don’t know what to do with your life, start by working on your health”

That’s from James Altucher, one of my favorite writers. It’s from an interview or one of his books, I can’t remember exactly. I’ve been following his work online since then, by the way.

Since last year, after ditching my to-do lists, my only plan has been to take care of my body, mind, and spirit every day.

Prioritizing our health creates forward momentum. It gives clarity, energy, and purpose.

There are days when I miss working on any of the three parts.

But when I miss a couple of days, I can feel it. Frustration, ruminating thoughts, and low energy start to appear. Again. That’s the warning sign to go back to my healthy habits. My body tells me when it needs to be taken care of.

I still don’t know what to do with my life. Probably, I never will. But working on my health has given me so much peace of mind.

One day at a time

Life doesn’t come with an instruction manual. We have to figure things out. We all are figuring life out as we go. Sometimes it’s easy. Sometimes it’s not. Sometimes we know what we want out of life. Sometimes it’s easier to tell what we don’t want to do.

No matter where you are in life, work on your health. That’s the first step to change.

Focusing on my health was the lever that brought real change after burning out. That’s why I made it Idea #1 in 10 Surprisingly Simple Ideas That Changed My Life And Could Change Yours Too. Because small daily actions create big change.

4 Writing Lessons I've Learned Recently—Two of Them After a Viral Post

2025-05-12T00:00:00+00:00

#1. Use Fear, Curiosity, and Desire to write attention-grabbing headlines.

Credits to Ron Markley on Medium.

Recently I’ve learned that when we write content, we’re in the business of writing headlines.

A good headline is like a good welcome sign. People will only stop by if they see a good one.

No matter how thoughtful our content is, if the headline doesn’t hook readers, they won’t stop to read it.

#2. When writing stories or fiction, a point in time creates expectations in the readers’ minds.

When we write “It was a sunny summer day when I saw her for the first time…“ readers expect to hear more about what happened.

And if we abruptly shift subjects, it’s like breaking readers’ expectations. Avoid those abrupt shifts. It’s like cutting off a conversation mid-way.

Listicles work online and offline.

The 10 Commandments, the 95 Theses by Martin Luther, the 48 Laws of Power… All of them are listicles.

Since last year, I’ve been experimenting on LinkedIn. And listicles have worked like a charm.

My most viewed post was something like “12 lessons after 10+ years in Software Engineering (In less than 1 minute)” followed by 10 one-liners and a question to invite people to the comment section. Boom! Over 80,000 views. I felt like an Internet celebrity for a couple of days… Here’s the post, if you’re on LinkedIn, by the way.

When reading listicles, people tend to comment on the item that resonated the most.

#4. One single post can boost your follower count.

You know the Pareto principle, right? 80% of results come from 20% of effort.

Well, 80% of followers and engagement come from 20% of posts. And one viral post can boost your follower count. It has happened to me on LinkedIn and Medium recently.

How To Find All 3-Digit Numbers In A Binary Tree

2025-05-11T00:00:00+00:00

This is an exercise I failed to solve in a past interview a long time ago, in a galaxy far, far away. I ran out of time and didn’t finish it.

Off the top of my head, the exercise was something like this:

Find all 3-digit numbers you can create by visiting a binary tree. To create a 3-digit number, given a node, visit either the left or right subtree, and concatenate the value you find in three nodes.

The next tree has 4 3-digit numbers.

They are 125, 129, 253, and 174. No, 127 is not a valid number here. We should visit one subtree at a time.

To finally close the open-loop in my mind, here’s my solution.

Let’s solve the simplest scenario first

If we have a tree with only the root node and the left subtree only with leaves, we could write a function to “walk” that simple tree like this,

List<int> Walk(int root, Tree subTree)
{
    if (subTree == null) return [];

    var candidate = root * 100 + subTree.Value * 10;

    List<int> result = [];
    if (subTree.Left != null) result.Add(candidate + subTree.Left.Value);
    if (subTree.Right != null) result.Add(candidate + subTree.Right.Value);
    return result;
}

Here root is the value of the root node and subTree is either the left or right subtree of our root node.

If we call Walk() with our example tree,

The root is 1, the node in the left subtree is 2, and the node in the left subtree again is 5, then the 3-digit number is calculated as 1*100 + 2*10 + 5.

Walk() passing only the root node and the left subtree of our sample tree returns,

//        1
//       / .
//      /   .
//     2     .
//    / \   .
//   5   9 .

Walk(1, new Tree(2,
            new Tree(5, null, null),
            new Tree(6, null, null)));
// List<int>(2) { 125, 129 }

That will only work for a simple tree.

Let’s cover more complex trees

With Walk(), we only find numbers by visiting one node in a simple tree, so let’s use recursion to visit all other nodes.

Here’s a recursive function Digits() that uses Walk(),

List<int> Digits(Tree aTree)
{
    if (aTree == null) return [];
	
    return Walk(aTree.Value, aTree.Left)
           // ^^^
           // We visit the left subtree from the root
              .Concat(Walk(aTree.Value, aTree.Right))
              //      ^^^^
              // We visit the right subtree from the root
			  
              .Concat(Digits(aTree.Left))
              //      ^^^^^
              // Find digits on the left subtree
              .Concat(Digits(aTree.Right))
              //      ^^^^^
              // Find digits on the right subtree
              .ToList();
}

Digits() starts visiting the left and right subtrees from the root node. Then, it recursively calls itself for the left and right subtrees and concatenates all the intermediary lists.

All the pieces in one single place

Here’s my complete solution,

record Tree(int Value, Tree Left, Tree Right);

List<int> Walk(int root, Tree subTree)
{
    if (subTree == null) return [];

    var candidate = root * 100 + subTree.Value * 10;

    List<int> result = [];
    if (subTree.Left != null) result.Add(candidate + subTree.Left.Value);
    if (subTree.Right != null) result.Add(candidate + subTree.Right.Value);
    return result;
}

List<int> Digits(Tree aTree)
{
    if (aTree == null) return [];
	
    return Walk(aTree.Value, aTree.Left)
              .Concat(Walk(aTree.Value, aTree.Right))
			  
              .Concat(Digits(aTree.Left))
              .Concat(Digits(aTree.Right))
              .ToList();
}

var tree1 =
    new Tree(1,
        new Tree(2,
            new Tree(5,
                new Tree(3, null, null),
                null),
            new Tree(9, null, null)),
        new Tree(7,
            new Tree(4, null, null),
            null));
Digits(tree1)
// List<int>(4) { 125, 129, 174, 253 }

Et voilà!

I know it’s too late. Months have passed since then, but I wanted to solve it anyway. Don’t ask me what company asked me to solve that. I can’t remember. Wink, wink!

For other interviewing exercises, check how to evaluate a postfix expression, how to solve the two-sum problem, and how to shift the elements of an array.

Sell Something or Be Ready to Sell Your Time

2025-05-10T00:00:00+00:00

Selling feels dirty to far too many people.

Maybe that’s because we have the wrong impression of selling as tricking people into buying something they don’t need with pushy lines or sales tactics. “I’m making an exception for you. Hurry up! If my boss finds out about this, I’m fired.”

The truth is we’re selling all the time, even without realizing it.

Isra Bravo, the best copywriter of Spain, taught me that we’ve been selling since we’re kids. We sell ourselves to get our parents’ attention. And as adults, we continue selling: when looking for a job or for a romantic partner.

The other day, a salesy DM made me change my perspective on selling: from pushy sales tactics to genuine help.

If we aren’t ashamed of helping, we shouldn’t be afraid of selling.

These days, jobs are uncertain and layoffs are always around the corner. Either you sell something (a book, course, template, coaching) and free yourself, or you sell 8 hours or more of your time and become a slave.

Remember, “whoever sits in a cubicle is replaceable.” (Choose Yourself by James Altucher) Sell something or sell your time forever.

Put Blood in Your Opening Lines and Keep Your Readers Hooked Forever

2025-05-09T00:00:00+00:00

People have short attention spans, and shorter for boring things.

That’s why our job as writers is to keep readers moving from the first sentence to the next and to the next…

I learned from James Altucher, one of my favorite writers, to study the opening lines of the books I read to write my own.

Following that advice, here are some of my favorite opening lines:

Genesis by Moses

In the beginning, God created the heavens and the earth.

That’s the opening line of the Bible, Genesis 1:1. It doesn’t matter if you believe it or not, those 10 words hook you right from the start.

If you read it for the first time and with fresh eyes, you can’t avoid asking:

Who is this God?
“In the beginning”…Was there anything before?
How did He do that?
And more important, why?

We’ve been trying to answer that for years.

One Hundred Years of Solitude by Gabriel García Márquez

Many years later, as he faced the firing squad, Colonel Aureliano Buendía was to remember that distant afternoon when his father took him to discover ice.

I didn’t read One Hundred Years of Solitude until the end. Sorry!

That’s one of the required books in my Spanish classes. I was too young. Too many members of the Buendía family that I got lost.

Even though I didn’t read it until the end, for some reason, I memorized that opening line in Spanish, its original language. It’s way stronger and more memorable in Spanish.

“Many years later,” so it doesn’t start right at the beginning.

“The firing squad,” what did this colonel do?

Before getting shot, of all things, he remembers his father taking him to discover ice? Wait! Was ice that new? When is this happening?

Choose Yourself by James Altucher

I was going to die.

Five words that hook you. You can’t avoid asking how and why.

To add more drama, he continues:

I was going to die. The market had crashed. The Internet had crashed. Nobody would return my calls. I had no friends. Either I would have a heart attack or I would simply kill myself. I had a $4 million life insurance policy. I wanted my kids to have a good life. I figured the only way that could happen was if I killed myself.

He answers the “why” by giving three causes: market, internet, and no friends. So is he an investor in internet companies? He doesn’t give a full answer to make us keep reading.

This guy is so miserable that he wants to take his own life just to leave the insurance money to his kids. How did he end up there? You can’t avoid empathizing with him. You just want to keep reading.

Reinvent Yourself by James Altucher

It was all over for me once again.

Wait! When was the last time? And why is that happening “again”? And what is “all”?

To keep building up drama, he goes on:

It was all over for me once again. Marriage was over. My bank account going down. Nobody was publishing any more of my books. Nobody was giving me any more opportunities.

If you have read James Altucher’s previous books and heard his stories, you know he’s referring to one of the multiple times he went bankrupt. That explains the “again.”

After that drama, you want to keep reading to know what he did to get back up. It’s a book about reinvention. He got back up, right?

Parting Thought

Are there any patterns in those opening lines? Yes.

Thought-provoking or controversial statements like in Genesis.
Intriguing stories like in One Hundred Years of Solitude.
Rising drama and tension like in James Altucher’s books.

James Altucher teaches about powerful opening lines. And he walks the talk in those two books by building up drama.

A good headline is like a welcome sign. Controversy, curiosity, blood, and drama in the first line create the first impressions in your writing. Remember, you only have one chance to give a good first impression. So, put blood and drama in your opening lines and hook your readers until the end.

4 Surprising Lessons I've Learned Recently—While Taking a Loved One to a Hospital

2025-05-08T00:00:00+00:00

During a recent hospital visit, I found inspiration to write.

To keep my mind busy and productively distracted while waiting, I took out my phone and started to jot down ideas. Ideas of how to calm my mind and ideas of how hospital visits might look in 2035.

From that visit, I’ve learned four surprisingly useful (and maybe random) things about health and well-being:

#1. Insulin helps decrease potassium levels.

When we hear insulin, we think of diabetes.

But it turns out insulin helps the body absorb potassium faster. At least, that’s what a doctor explained to us. My loved one has kidney failure and her potassium levels were outside the normal range.

#2. Anemia isn’t only because of iron deficiency.

It’s one of the causes, not the main one. It could be due to genetic reasons or red blood cells dying too soon or bone disorders… or excessive bleeding.

#3. Too much exercise before bed interrupts your sleep patterns.

I found this on a study on the front page of Hacker News. I had to do something while waiting, so why not scroll down a feed?

The study doesn’t discourage exercise. It compares light exercise to high-intensity exercise within 4 hours before bed.

That won’t work as an excuse not to move your body. Sorry!

#4. When rushing, life makes you slow down.

In 2023, while finding ways to recover from burnout, I read “The Ruthless Elimination of Hurry” by John Mark Comer.

There was a line that has lived rent-free in my mind since then:

“God [or Nature or Universe] didn’t create hurry.”

I had to remember that recently. No matter how I hurry, I couldn’t change anything about what was outside my control.

One Life Lesson That Took Me 10 Years to Learn

2025-05-07T00:00:00+00:00

If you don’t come up with your own plan, society, the system, or the Matrix will give you its plan:

Work hard
Get 3% raises
Please your bosses
Keep your head down
Wait to retire
Then, die

I only learned it after being laid off and recovering from burnout and stomach problems. That was my wake-up call.

I was living on autopilot. No plan at all. Stretching each job until I got bored, fired, or laid off. I was working on building somebody else’s dream.

I wish I had learned this lesson at 25, but at least I know it now.

The Secret to a Sharp Mind from a 102-Year-Old Practicing Doctor

2025-05-06T00:00:00+00:00

Dr. Howard Tucker, at 102, still works as a neurologist. He holds the Guinness World Record for the world’s oldest practicing doctor.

Of course, the first question that popped into my mind was “What’s his secret?” I had to find out. That curiosity made me read his Reddit AMA and collect my favorite pieces of wisdom.

Here they are:

“Consistency, curiosity, moderation, and a good sense of humor haven’t failed me yet”

I wasn’t the only one wondering about Dr. Tucker’s secret to his sharp mind. That question came up more than once throughout the whole discussion.

It turns out there’s no secret or magic formula. Just good habits practiced consistently over the long term.

… Never stop learning. I’ve always believed that the brain is like a muscle—if you don’t use it, it atrophies. I went to law school at 67 for the mental stimulation and because law fascinates me. Not because I needed another job, but because I wanted to challenge myself. You don’t need to necessarily pursue a degree—read, debate, and stay curious.

Keep working, if you can. I firmly believe that retirement is the enemy of longevity. I’m not saying everyone should work into their hundreds, but purpose matters. I still work in the medical field because it gives me structure, meaning, and a reason to wake up early (though I am enjoying sleeping in more now.) …

Move your body. I walk every day on my treadmill. It’s good for the brain and body, but hopefully you already knew that.

The truth is that there’s no secret sauce. I won’t deny genetics playing a large role in longevity. Genetics is a good head start, but consistency, curiosity, moderation, and a good sense of humor haven’t failed me yet.

This is a good reason to keep following my Daily Practice: doing something for my body, mind, and spirit every day. Since last year, it’s been the one habit I’m following religiously. Maybe I’ll make it to 102 if I stick with it.

“[Your job] doesn’t define who you are. Let your curiosity and how you treat others define who you are as a person”

A young medical intern asked for his advice on work-life balance during residency, and here’s what Dr. Tucker said:

The key is to have at least one thing outside of medicine that is just yours, and you must commit to making time for it even if it’s just 15-30 minutes a day.

It can be anything - a hobby, a daily walk, reading, time with loved ones.

Always remember that medicine is what you do. It doesn’t define who you are. Let your curiosity and how you treat others define who you are as a person.

Replace “medicine” with your job, and that advice still applies.

By the end of 2023, I was burned out. I wasn’t doing anything that Dr. Tucker recommends.

I wasn’t practicing my hobbies. I wasn’t taking care of my body. I had stomach issues. Everything I ate sent me to the bathroom. Awful! And I had all my sense of value in my job title. Wrong, wrong, wrong!

I had to go through a burnout season to realize I am more than a job title and there’s more to life than working 8 hours in a virtual cubicle. I had to let go of the idea of climbing the corporate ladder. And I had to create my own rules for success and life.

Since then, I redefined myself, from Software Engineer to lifelong learner. And I decided to write 10 bad ideas and write something every single day as the things outside of coding.

“The world will always be filled with uncertainty and challenging times”

One world war. The Great Depression. Another war. More than one economic crisis. In 102 years of life and almost 80 years of practice, Dr. Tucker has gone through a lot.

His advice to young generations on making it through uncertain times?

My advice is focus on what you can control - your effort, attitude, and how you treat others. The world will always be filled with uncertainty and challenging times, but resilience is timeless.

Dr. Tucker is living proof that learning should never stop. And neither should we. Longevity isn’t about secrets. It’s about good habits that care for both mind and body. Len, another 102-year-old WWII veteran, also recommends it.

The Key Feature of Effective Writing in the Digital Age—Revealed by a Plea Against AI Misuse

2025-05-05T00:00:00+00:00

Yesterday, while reading I’d rather read the prompt by Clayton Ramsey, with reasons why people use AI to write for them, I found this idea:

When someone comments under a Reddit post with a computer-generated summary of the original text, I honestly believe that everyone in the world would be better off had they not done so. Either the article is so vapid that a summary provides all of its value, in which case, it does not merit the engagement of a comment, or it demands a real reading by a real human for comprehension, in which case the summary is pointless.

That made me think of a key feature for good writing on the Internet:

Write something that doesn’t need a summary.

I declared myself guilty. My first posts were word vomits, with long paragraphs, fancy words, and poor formatting. I wrote to sound like a “writer”.

I blame school writing assignments: “Write a 5-page essay about…” And when we didn’t have anything to say, we started to go on tangents and add fluff to fill five pages.

On the internet, there’s no word count to hit.

Good writing is clear and to the point.

If I Were Darth Vader's LinkedIn Ghostwriter and Brand Strategist:

2025-05-04T00:00:00+00:00

Tagline?

“Sith Lord — On a mission to rule the galaxy”

About page?

Late projects and unmotivated team members?

I specialize in putting teams back on schedule.

My unconventional but proven methods will help you lead ambitious projects.

I found in the Dark Side a pathway to many abilities some consider to be unnatural.

Since then, I coach founders and executives on how to leverage the Dark Side too.

I teach them not to choke on their own aspirations.

DM “Dark Side” for a free 30-minute discovery call.

Hooks for the first 10 posts?

How I found my best mentor
Here’s how to live with a ventilator
The #1 strategy I use to manage my teams
Why I joined the Dark side (and you should too)
1 lesson from failing at my most ambitious project
I had to choke one of my team members, here’s why
I failed to work with my son, here’s what I learned
Here’s what I love about being in the Dark Side
How I put projects back on schedule
Since I were a kid, I felt different

May the 4th be with you.

10 Hacks I've Used To Learn Foreign Languages Faster—And Will Help You Too

2025-05-03T00:00:00+00:00

Learning languages turned out to be the most valuable skill I’ve learned.

It took me about 2 years to learn English and a couple more years to speak with confidence. I went to a traditional language school to get a diploma. Lots of grammar and “repeat after me” exercises.

But I learned French, my second foreign language, in about a year and a half. I did it on my own with tutors and at my own pace.

These are 10 tricks I’ve used (and recommend) to learn any language faster:

1. Forget about grammar. Focus on your pronunciation

When I started studying English, I was obsessed with grammar.

On the first day at my language school, our teacher asked us to open a textbook to start learning rules and exceptions. Later, I devoured Grammar in Use, a popular English textbook.

But perfect grammar means nothing if you can’t get your points across. Work on your pronunciation first.

2. Learn phrases, not words

It’s tempting to start memorizing individual words. A, aardvark, abacus, abandon, abase…

Unless you want to sound like Tarzan, you need more than individual words. Start with simple phrases for casual conversations and combine them like Lego bricks.

3. Change your phone language

That’s the easiest way to be immersed in your target language.

We keep our phones with us all the time, even when going to bed. Turn them into language-learning companions.

4. Change your phone’s alarm sound to a song

Again, an easy way to immerse yourself in your target language. Make sure you wake up to do something you love, or you’ll hate that song.

5. Create your own phrasebook

List situations you’ll face when using your target language and the phrases you’ll need for them. Learning a language for your next vacation isn’t the same as learning it for a job interview. Use AI here as your tutor.

6. Create flashcards with phrases from #2 and #5

Then, study them in every free slot in your agenda. Use spaced-repetition software like Anki for that.

7. Use AI to generate stories with the most common words

Try this prompt:

“Act as an expert tutor in <target language>, generate a 200-word story in the present tense about <favorite topic> using the 100 most common words.”

Then use a text-to-speech tool to generate audio for that story. Boom! Enough material to practice reading and listening.

Again, remember to learn words in the context of phrases. That’s from #2.

8. Learn filler words and connectors to sound like a native

Learn the “you know,” “and uh,” and “isn’t it?” to help your words flow naturally like a native speaker.

9. Watch children’s stories multiple times

Watch each time with a different focus:

The first time, watch to understand the story.
The second, with subtitles on, to read along.
The third, to identify words you don’t know.

This way, you can squeeze the most out of a single story.

If you think children’s stories are too easy, try with a video from the YouTube channel “Easy Languages.”

10. Consume content about your hobbies in your target language

Okay, call me a nerd.

But when I got back home from university, a long time ago in a galaxy far away, I watched lectures on YouTube about the same topics I had covered that day. I learned new words and practiced my listening skills while reinforcing the material I was covering.

You don’t have to be a nerd like me. Replace university classes with hobbies or skills you want to learn. Win-win!

I hope I have no grammar errors here. That would be embarrassing after saying I devoured Grammar in Use. Anyway, learning a language has been my best career move and an AI helped me proofread this.

The Reason Why I'll Keep My Personal Blog (Even When Blogging Is Dead)

2025-05-02T00:00:00+00:00

Blogging has been dead for years.

Dead in the sense of writing posts to rank on search engines and attract visitors for ads. Google killed that style of blogging with constant algorithm updates. And ChatGPT seemed to kill Googling.

But, personal blogs are still alive in some corners of the internet, like this one.

I’m a romantic. I’ll keep writing on my blog, even if blogging is dead.

My blog is my time capsule and content vault. Everything that I write online ends up here. It’s my catch-all place. It’s been better than a portfolio for my coding career.

Each platform has its own set of unwritten rules. On LinkedIn, we’re expected to write about business-related topics. On Medium, we’re expected to write following publication guidelines. But a blog is a place without rules.

Mike Saas said in Just Put It on Your Blog:

It’s great to have a place to share your thoughts. A place you can go back to when you want to remember something you had written or thought about before. A place you can refer people to when they have questions you’ve answered in the past. A place to be you.

My blog is my cabinet of curiosities, public notebook, and writing gym, away from social media’s speed. And that’s why I’ll keep blogging, even if the internet says it’s dead and even if AI writes faster and better one day.

These 15 Simple Habits Could Save You From the Doctor's Office—For Good

2025-05-01T00:00:00+00:00

Few things are more frustrating than going to the doctor.

It isn’t just one visit. It’s one visit, followed by some blood tests at a laboratory, then going back to the doctor with the results, then a visit to a specialist, then another round of tests, then another visit with test results… And regular checkups. Arrggg!

It’s draining just thinking about it. That’s why I’ve decided to adopt some healthy habits, like these:

#1. Drink enough water to avoid kidney stones. For so long, I didn’t care about my kidneys until I had to rush to the ER with a loved one. Diagnosis? Kidney failure.

#2. Cut sugar to avoid diabetes.

#3. Exercise to keep the heart healthy.

#4. Get a good night’s sleep. It isn’t that complicated. I leave my phone outside my room, turn off all lights, change my bedding often, and regulate the AC temperature.

#5. Brush my teeth at least twice a day and use dental floss once a day.

#6. Sit less to avoid back pain. This was something that started in my first job. I wasn’t used to sitting for 8 hours on an uncomfortable chair. I had to change my chair at work and start walking. And more recently, I started to use a standing desk.

#7. Eat vegetables with every meal to go to the bathroom every day.

#8. Place my computer near a window for natural light, and put a lamp behind my display so it isn’t the brightest source of light at night.

#9. Cut processed food and sodas to keep my blood pressure under control.

#10. Have a daily moment of silence to control stress.

#11. Wear a good pair of shoes. Again, back pain.

#12. Eat more protein than carbs at every meal to keep my weight under control. Not only eat more protein, but also reorder how you eat. Salads first, then proteins, and lastly carbs. Thanks to reordering how I eat, I feel more energetic throughout the day. And that’s my best productivity hack since last year.

#13. Stay in contact with friends. Just to be happier.

#14. Take supplements for brain health.

#15. Don’t drink alcohol to protect the liver.

Maybe one day, AI will transform our visits to hospitals and doctors. Who knows? But until then, I want to be healthy to avoid those long appointments.

15 Writing Myths Debunked So You Can Start Writing Today

2025-04-30T00:00:00+00:00

In 2024, I went all in with my writing.

Writing worked like free therapy to recover from burnout. After months of inactivity, I decided to revive my LinkedIn account. I started writing 1 post a week, and of course nothing happened. Then I wrote 2 posts…then 3…until I settled on writing every workday.

Some of my ex-coworkers and friends have noticed some of my posts. They have genuinely asked me how to do it on their own.

Here are some of the myths about writing anywhere online I’ve heard:

1. I’m not an expert

Who’s an expert anyway? If you wait to be an expert, you will never start writing.

It takes 10,000 hours to be an expert. Do you have time for that? Write to be an expert, don’t wait to be one to start.

2. I don’t know how to write

Writing takes time to master. But to start, imagine writing for one person: a friend, your kid, a coworker, or your dog. Talk out loud and transcribe it. Or imagine you’re texting a friend and write inside a chat app.

3. I don’t want to expose myself

You don’t have to share pictures of your feet. Don’t write about subjects you wouldn’t bring up at work.

4. I’m not a native English speaker

Write in your native language.

5. I’m not good at explaining things

If you’re a coder, you are already good at explaining things. Coding is explaining things to a computer. Try to do the same in writing. Don’t try to write like a “writer,” share an algorithm. Start by writing TIL Posts

If you have learned something in the past 2 years, you have something to share. And you’re already sitting on content ideas, you just need to notice them.

7. I don’t know where to publish

Start on social media. Start writing a tweet or whatever they’re called now. Or try with LinkedIn. It might be cringy, but it has fewer trolls. On LinkedIn, the feeling is the boss is watching, so everybody behaves.

8. My boss will find out

Your boss won’t care. Your boss is busy pleasing their own bosses.

9. I need my boss’s permission

Unless you’re planning to write about company secrets, you don’t need your boss’s permission. You don’t need permission from anyone.

In fact, always write about what you do at work. That’s better than claiming you did something on your CV.

10. People will make fun of me

Nobody will make fun of you. Just hit publish.

11. Nobody will read

You can always read and like your own stuff on social media. Write for your past self, and don’t worry if anyone reads.

12. What if my writing comes up in future interviews

Congrats! It means someone found and read your stuff. And it will make you memorable. “Oh, the guy who wrote about XYZ.”

By writing, you can skip hiring lines. For example, my blog has done more for me than a portfolio.

13. I have too many ideas. I can’t decide what to post.

Post what you would have liked to read 2 years ago. See what sticks and keep writing about that.

14. I sit to write but nothing comes up

OK, that’s writer’s block. But that’s not the real problem. Again, write for your past self. Or try following writing prompts.

15. I don’t know how to create a website

You don’t need a website. Start on social media or social blogs. And if you’re a coder and want to start writing, don’t code a blogging engine.

I don’t have a New York Times best-seller and I’m not an expert either and you made it this far. That’s the power of writing online. Write as if nobody is reading and keep writing because you don’t know who you might help. Start today and see where your words take you.

Ten Pointless Facts About Me Challenge—Here We Go!

2025-04-29T00:00:00+00:00

While scrolling through yesterday’s Minifeed for inspiration, I found this blogging challenge on Living Out Loud. Turns out David, from Forking Mad +, started it. No more writer’s block.

Here I go:

Do you floss your teeth?

Yes. Once a day.

Tea, coffee, or water?

Coffee only in the mornings with breakfast. No sugar. 1L of water a day. And tea, occasionally after dinner.

Footwear preference?

Nothing in particular. But I like to wear shoes without laces when traveling. It saves so much time at security controls.

Favorite dessert?

I don’t have a sweet tooth. But if you’re curious, Arroz con Leche (Rice pudding. Literally, rice with milk) is a popular dessert in my country.

The first thing you do when you wake up?

Brush my teeth, a glass of water, and a moment of silence. I started the last two, as part of my Daily Practice, after ditching my todo lists.

Age you’d like to stick at?

I wouldn’t like to stick at any age. Every age comes with challenges to face and lessons to learn. Last year, I got laid off and recovered from burnout and I learned some valuable lessons. That was something I wouldn’t have learned at any other age.

How many hats do you own?

Not exactly hats, but I have a couple of baseball caps.

One day, I attended a meeting on Teams at work in a past job. And during a 1-on-1 with the VP of Engineering, he said, “If you want to be a team leader, you should start looking like one.” And that meant stopping wearing caps. Leadership required a different look. Arrggg!

Describe the last photo you took?

I took a photo of a loved one coming back home after almost a week in a hospital.

Worst TV show?

I don’t have a TV show I’d call “the worst.”

Maybe it’s because I don’t watch that many TV shows. But I will tell you some of my favorite ones: Homeland, The Diplomat, Scorpion, and Dr. House.

I used to feel guilty about watching TV shows. But I realized when we see the world with our writer’s glasses on, content ideas are everywhere. So I started writing about TV shows and movies I watch. No more feeling guilty.

As a child, what was your aspiration for adulthood?

I had many ideas: joining the Navy, studying Biology, being a polyglot, and many others I can’t even recall. I’ve always struggled to find one passion.

I also answered the Bear Blog Questions Challenge the other day.

8 Easy-to-Implement Tips to Read One Book a Week

2025-04-28T00:00:00+00:00

I’ve changed my mind about reading books.

I started reading to grow a large “read list.” But I couldn’t remember some of those books, even when I had notes. I couldn’t even remember their covers.

Then, I switched to “just-in-time” learning. Reading only when facing a challenge or working a project, so I didn’t forget the lessons from books.

Reading one book a week seemed like a distant goal. Reading 500 books to reinvent myself seemed impossible. I thought it was only doable with speed-reading techniques and tweaking the definition of a “read” book.

But yesterday, I found this YouTube video with practical ideas to read one book a week.

Here are some of my takeaways:

#1. You do have time to read. On average, we spend three hours watching Netflix. That’s time we could use for reading.

#2. You don’t have to read in a single 3-hour session. Split your reading time throughout the day. Read during idle moments: while taking your morning coffee, after lunch, or before going to bed.

#3. Have dedicated spaces for reading. Make sure they’re comfortable enough. Maybe a good chair and a source of natural light or a lamp.

#4. Add 20 seconds of friction to your distractions. It could mean leaving your TV remote in another room or taking your phone out of sight. Also, make your reading sessions as easy as possible to start. Make sure starting a reading session takes you just 20 seconds.

#5. You don’t have to finish one book to start another. Balance your reading among three books: one for learning, one for entertainment, and one for inspiration. I found a similar idea on Choose Yourself by James Altucher: Read for two hours and write down 10 ideas from what you read.

#6. Every time you find interesting concepts or ideas, pause for a moment. This is to give your brain time to activate its diffuse mode and start working behind the scenes. Also, notice connections between what you’re reading and the other two books. Maybe a concept from a non-fiction book might appear applied in an autobiography. This sounds similar to step #6 from my 6-step process to read books.

#7. When you find a new concept, ask yourself what’s the easiest step to start implementing that concept.

#8. Have a book implementation journal. Every time you apply a new concept you found in a book, keep a log entry of how you did and how easy it was to apply.

More ideas for my own reading strategy. So always be reading, not to show off a large book list, but to retain and apply.

I Followed These 7 Proven Money Tips—And Finally Got My Finances Under Control

2025-04-27T00:00:00+00:00

The fear of letting my salary slip through my fingers pushed me to organize my finances.

I had doubled my salary as a Software Engineer. I was earning in a stronger currency. And I didn’t want to regret letting all that money leave my pockets without doing anything productive with it.

I read finance books and watched YouTube influencers to get my finances in order.

Out of all that content, here are 7 tips I followed to take care of my finances:

1. List your sources of income and expenses. This is to know how your money is flowing in and out of your pockets.

2. Follow the 50/30/20 rule for conscious spending instead of strict budgeting. I learned this one from “I Will Teach You To Be Rich” by Ramit Sethi. Set apart 50% of your income for fixed expenses like housing and food, 30% for savings and investing, and 20% for guilt-free spending. Of course, tweak those last 30% and 20% to suit your needs.

3. Use the envelope method. Separate your income into categories by putting your money into envelopes. And only spend what you have in each envelope for each category. For example, only use the money from the “Coffee” envelope to drink coffee outside. Of course, you can follow this method with virtual envelopes in your bank account.

4. Pay yourself first. This is a lesson from “The Richest Man in Babylon.” Before paying for your expenses, save and invest first.

5. Start an emergency fund. Call it F*ck-you money or whatever you want. But save enough to cover months of expenses in case you lose your job or face any other emergency. A strong emergency fund was crucial when layoffs came knocking.

6. Be careful with your credit card. Use it if wisely. Only if you already have money to pay for purchases and take advantage of extra benefits like travel insurance or access to lounge rooms in airports.

7. Automate your payments and investments. Again, another lesson from “I Will Teach You To Be Rich.” The goal is to live a rich life, outside of spreadsheets. So automate payments for your credit card and automate deposits into your savings or brokerage accounts.

Steal the Headlines from Some of My Most-Read Posts

2025-04-26T00:00:00+00:00

Your headline is the front door to your content.

People will only enter your shop after seeing an attention-grabbing sign on the front door. Headlines work the same. No matter how thoughtful and actionable your post is, if the headline doesn’t “hook” them, they won’t read it.

To write better headlines, steal them like an artist from YouTube or from other posts.

Here are the headline templates from some of my most-read posts on Medium. Steal them and tweak them to fit your content.

<Number> Subjects I’ve Changed My Mind About as a <Profession/Role>
- 9 subjects I’ve changed my mind about as a Software Engineer
For <Outcome>, <Key Action> in Your <Context>
- For cleaner domains, move IO to the edges of your app
- To break free from debt, stop using your credit card
Using <Popular Action> Doesn’t Make Your <Context> Truly <Desired Outcome>
- Using lambda expressions doesn’t make your C# code functional
- Cutting down on cups of coffee doesn’t make you save more money
<Number> Alternatives for <Common Action> When <Context>
- Three alternatives for the startup class when migrating ASP.NET Core projects
- Five alternatives for eating out when saving money for your next trip abroad
The Best Way to Get Better at <Skill> Isn’t Just <Common Misconception>
- The best way to get better at coding isn’t just writing more code
- The best way to make more money isn’t just asking for a raise
If You Enjoy <Activity>, Think Twice About <Counterintuitive Decision>
- If you enjoy coding, think twice about joining the management track
- If you enjoy photography, think twice about starting a wedding photography business
You Only Need These <Number> <Category> to <Big Transformation>
- You only need these four books to change your relationship with money
- You only need these two gym routines to lose 10KG of fat in the next 30 days
Steal This <Number>-Step <Process> to <Outcome>
- Steal this 6-step reading process to retain more from books
- Steal this 5-step process to land your first coding job

As writers, our job is to hook readers one line at a time. Nail your headlines and opening lines and you’ll write posts readers can’t stop reading.

Re: Will AI Take My Job? A Coder's Reality Check

2025-04-25T00:00:00+00:00

Anita asked on dev.to if AI, given all the hype, will take her job.

Short answer: Not yet.

Sure, we code daily and AI shines at spitting out code. But most of our work is balancing expectations and handling risk.

Apart from coding, we as coders have to deal with:

Inter-team planning
Brainstorming sessions
Putting late sprints back on track
Designing requirements and user stories
Decomposing a full project into milestones
Scoping tasks with Product people
Reviewing architecture designs
Negotiating deadlines
Talking to clients

And that involves a lot of human interaction. It shouldn’t surprise anyone that a coder will spend more time in meetings than coding on a normal day. And AI can’t replace that human interaction yet.

But sure, our job as coders will change. Even if we’re skeptical about AI, we can’t ignore it. We can only assume AI will generate code faster and cheaper than any of us. We have to adapt.

We won’t be code monkeys anymore, cracking lines of code in exchange for bananas. AI will handle that. And if AI will change everything, let it at least kill dumb SCRUM ceremonies.

You Don't Need Markdown to Blog—But It Makes It Easier

2025-04-24T00:00:00+00:00

These days, Ben, one of my email subscribers, asked me a question about blogging using Markdown.

Here’s an edited version of his email:

I have been on a journey to start a coding blog over the past couple of months but just cannot get behind Markdown blogging in an IDE, which seems to be the most common or popular way to create a blog. I find it far easier to use some web service that essentially amounts to a rich text editor.

What would you recommend in this instance? Am I missing some obvious solutions or is getting the hang of Markdown just the way everyone recommends doing this?

Well, I’m a plain-text fan. Writing posts using Markdown on a text editor is my favorite way to blog.

Do you have to use Markdown? Short answer: No.

You could write HTML files and publish them directly to the Internet.

I’ve even seen people blogging using GitHub Gist or public GitHub repositories. They simply share file URLs from the repo.

A Markdown-based blogging engine like Jekyll is convenient. You could try editors like MacDown or Typora. These days, I’m using Notable. Or you could try a Markdown extension for Visual Studio Code.

And by the way, yesterday, I found a guy who runs his blog with Obsidian, if you’re looking for inspiration.

A social blog is a place for long-form writing with an audience and a distribution mechanism, like dev.to or Medium.

Social blogs are “slower” than social media platforms like Twitter/X or LinkedIn, but “faster” than traditional blogs or websites. It’s easier to get traction on a social blog than on a personal blog, which sits behind search engines and their bots.

I’d recommend starting on dev.to.

I have an account there where I repost some of my coding content. It has a decent built-in editor with basic formatting, but still uses Markdown.

It has a large audience of mostly beginner coders learning web development. Of course, you can share any content related to coding there.

You have nothing to lose by starting a blog. Start writing, even if it’s just one post. Choose the simplest option so you can focus on writing, not tweaking tools or writing your own blogging engine.

For more blogging lessons, read four lessons for a coder struggling to write, start writing by writing TIL posts, and how I organize my blogging workflow as inspiration.

Reading Is a Cheat Code to Better Writing

2025-04-23T00:00:00+00:00

Last year, I challenged myself to revive my LinkedIn account by writing 100 posts.

I didn’t know what to write or how to write it. I only had good intentions.

My first posts were crap. Of course, 90% of everything is crap. I made every sin possible in my first posts: emojis, a big wall of text, external links…I’m embarrassed by those first posts.

But reading as a creator changed my writing.

I started to notice the posts I opened and read.

I collected the opening lines of the posts I opened. I created a file with my favorite openers. Then I stole (like an artist) those hooks to write my own.

Every time I clicked “See more” and found a big wall of text, I stopped reading. To avoid this mistake, I started to write shorter posts.

When I realized I never clicked on any of the external links in the posts I found, I stopped adding external links to my posts.

And I noticed how my favorite creators structured their posts. So I ditched emojis and started to add blank lines, use shorter sentences, and make my posts mobile friendly.

“Writing is learned mainly by imitation”

That’s from Writing to Learn by William Zinsser.

To improve your writing, imitate your favorite writers to develop your own style.

Notice the opening lines of your favorite books, collect headlines, and hand-write your favorite pieces. That’s how you get better at writing.

To learn to write, stop blindly consuming content. Put on your creator glasses and start noticing your behavior as a reader. That’s your cheat code to better writing.

You Don't Have to Write a New York Times Bestseller to Tell Your Story

2025-04-22T00:00:00+00:00

The definition of book has changed.

The other day, while reading James Altucher’s archive, I learned a book doesn’t have to be a 10,000-word New York Times bestseller, traditionally published.

A book could be a 20-page personal story or a summary of 10 scientific papers. And you don’t have to write it for the masses.

A book could simply be a story for our grandkids.

It doesn’t matter if it doesn’t sell thousands of copies or get 5-star reviews or get featured in newspapers. The real audience of our book is 4 or 5 people, our future relatives.

It would be great to read how grandpa found his first job, met grandma, and made it through life. I wish I had a firsthand glimpse of their lives.

You don’t need 10,000 words or a traditional publisher. You just need a story to tell. And chances are you already have one.

One Question to Get Unstuck

2025-04-21T00:00:00+00:00

A big project might seem daunting. Too many tasks, too many possible outcomes, and the fear of failure.

If you want to write a book, you might ask: What if nobody buys it? What if nobody reads it? What if it only gets bad reviews?

When stuck, answer: What’s the worst thing that could happen?

After identifying that “worst thing,” we realize all this uncertainty and fear was just noise in our heads. And that worst thing wasn’t that bad after all.

If nobody buys or reads your book, you still learned to outline a book, tell stories, choose a cover, buy an ISBN, and upload it to Amazon. The worst thing wasn’t that bad after all. You were only drowning in a glass of water. And you see how small your fear really was.

How MedAI Will Transform Hospitals and Patient Care by 2035: My Predictions

2025-04-20T00:00:00+00:00

It’s 2035. AI didn’t kill many jobs as we thought in 2025.

The world still needs coders. There are still pilots in the cockpits of airplanes. And there are still doctors and nurses in hospitals.

But AI has changed many jobs. Just like Photoshop changed graphic design and AutoCad, architecture.

One day, you’re not feeling well. And you have to rush to the ER.

Just like in 2025, a nurse receives you at the hospital.

But there’s something different this time. The hospital is run using MedAI.

As you describe your symptoms to a nurse, MedAI transcribes them and creates an initial report. It also studies your changes in intonation and breathing patterns to tell how sick you are or if you’re just looking for an excuse to skip work today.

MedAI helps the nurse in triage, making sure you receive medical attention as quickly as possible. While MedAI processes all this data, the nurse can focus on preparing you for the next steps.

After waiting for a few minutes in a room, a doctor calls you into the examination room.

By the time you get there, MedAI has summarized your records from past visits.

It has told your doctor when you visited the hospital and your diagnosis on each visit. Also, MedAI helped your doctor determine if your new symptoms are somehow related to past visits.

Your doctor doesn’t need to examine your vitals.

Using cameras and sensors, MedAI monitors your vitals: temperature, breathing, and heart rate. Are you vomiting? Shivering uncontrollably? Struggling to stand without help? MedAI quickly assesses these symptoms, allowing your doctor to focus on examining where it hurts.

After examining you, MedAI scans the hospital database for genetic conditions or recent similar cases among your relatives or other patients. Is it a family problem? A virus outbreak in the city?

That will give your doctor more clues for your diagnosis.

Your doctor gives you an initial treatment to relieve your pain and orders you some tests.

MedAI has helped your doctor prescribe any medicines based on your allergies or other health issues.

“Dr Williams, this patient is allergic to XYZ. And on a past visit, this treatment increased his blood pressure. Here are some alternatives to those medications: …“

By the time your test results are ready. MedAI has summarized the main findings. “He has low XYZ, high ABC. Everything else seems normal for his sex, age, and health condition.”

Armed with your vitals, exams, and preliminary diagnosis, MedAI has narrowed down your diagnosis to one or two issues and suggested a treatment for each one.

Your doctor has to double-check those suggestions and approve your treatment. You have to stay at the hospital for close observation.

While you are under observation, MedAI creates a daily report of your evolution.

“His blood pressure has been stable. No more signs of pain. A change of medication is needed in the next two hours.”

Also, MedAI has created a dietary plan for your visit, recommending the right food for you, given your overall health condition. “This is a patient with sugar problems. Here’s a list of recommended meals for his stay…“

Your doctor approves it and MedAI sends it to the hospital kitchen.

After a day or two, you feel OK again.

Your doctor prioritized your well-being and gave you the emotional support only a charismatic doctor can give.

Meanwhile MedAI assisted him at each step of your treatment, from monitoring your vitals to making sure your treatment was suited to your needs. MedAI was the caring and supportive assistant, but your doctor was still in charge. Just like a pilot is still in charge of a plane through the skies.

Open again in 2035.

10 Simple Ways to Calm Your Mind in Stressful Moments

2025-04-19T00:00:00+00:00

Yesterday, it took me nearly half an hour to calm down.

I had just rushed to the ER with a loved one. And I simply couldn’t switch off my brain’s fight response. All the stress chemicals must have been at their highest.

Once the emergency passed, my body refused to relax. I was still in fight mode. To take control back, I tricked my brain into focusing on something else: writing a 10-idea list.

Here are some other alternatives to try when stressed:

1. Follow the 3-3-3 breathing rhythm: Inhale for 3 seconds, hold for another 3, and exhale for 3.

2. Write 10 ideas about anything: Give your brain another task.

3. Do some physical exercise: Go running or lift some weights. Move anyway.

4. Listen to Dark Side of the Moon: I’m not a fan of Pink Floyd. In fact, that’s the only album I’ve known from them. But for some reason, I found it relaxing, especially track number 4, The Great Gig in the Sky. I feel those cries of desperation just like mine.

5. Listen to relaxing sounds: A river, ocean, or birds singing.

6. Watch stand-up comedy: You can’t be happy and stressed at the same time. Trick your brain into changing its mood.

7. Watch an episode of a TV show: TV can help you get out of your busy mind and distract you.

8. Meditate: Similar to #1. Repeat a mantra like: “breathe, calm down, and get out of your mind.”

9. Pray: Let your feelings out of your chest.

10. Do some cleaning: Again, it’s a way to trick your brain into doing something else. It helps you get out of your mind and into something physical.

Friday Links: Vibe Coding, Post-Developer Era, and Blogging

2025-04-18T00:00:00+00:00

Hey, there.

Here are 4 links I thought were worth sharing this week:

#1. There’s a difference between a program and a product. It’s not the same hacking some lines for a one-time task as crafting an API for concurrent users. Vibe coding shines at one of the two (3min).

#2. Google claims AI generates 20% of its code. But those claims make us live in a post-developers era? (12min). AI is like driving a car in cruise mode. It goes where you point it, but you still need your hands on the steering wheel.

#3. Here are over 20 coding lessons (6min) from a coder with 25 years in the field. I had to learn the one about tracking request and responses the hard way.

#4. I’ll keep my personal blog, even if blogging is dead. A blog is a place without rules to share anything you want. If you have something to say, just put it on your blog (2min).

And in case you missed it, I wrote on my blog about “waking up experts” when specs aren’t clear (2min) and the first time I saw a computer (2min).

Here’s this week’s tip to get better at coding:

Learn some sort of automated testing.

Call it unit, integration, TDD, BDD, or anything else.

Chances are there are formal studies about the time required to maintain and fix bugs in codebases with unit tests compared to codebases without them.

But, empirically, the healthiest codebases I’ve worked with had unit tests.

Unit tests are a safety net when you’re making changes. Your coding life will be better with unit tests than without them. And you’ll miss unit tests when you work with a legacy application.

(Bzzz…Radio voice) This email was brought to you by…Join my course, C# NullReferenceException Demystified and in just 1 hour and 5 minutes, you’ll learn the principles, features, and strategies to get rid of that exception.

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.

12 Hard Truths About Coding I Learned the Hard Way After 10 Years

2025-04-17T00:00:00+00:00

I got fired from my first job, took down a database server with a badly written query, and was rejected from a FAANG. That all happened over the past 10 years.

But I’ve learned a lesson or two about coding along the way:

1. Estimates are just guesses.

The problem is when your guesses don’t overlap with everybody else’s guesses.

2. Showing progress is better than doing the work.

Did you guess you can finish a task in 4 days? No, no, no. You’re better off splitting it into smaller ones to show progress.

3. Proofs of concept are better than long documents nobody will read.

When was the last time you read more than 2 or 3 pages of documentation?

You’re better off creating a quick and dirty Pull Request to show an idea or a prototype. “Working code over documentation.”

4. The work isn’t over when you finish coding.

After coding comes deployment, testing, user adoption, customer support, and follow-up.

5. The more senior you become, the less it’s about coding and the more about meetings.

Did you join Software Engineering because you like coding? Forget about that.

You’ll spend more time in meetings:

1-on-1s,
Daily meetings,
Retrospectives,
Sprint planning,
Alignment meetings,
Brainstorming sessions,
Poker estimation sessions,
A few minutes with a guy from another team who needs to touch the code you wrote one year ago and you don’t remember now.

And on and on…

In a perfect day, you’ll have 1 or 2 hours of coding without distractions.

6. You learn to love tests when you work with a legacy app.

Call it unit, integration, end to end, TDD, BDD, or anything DD.

You’re better off with anything that lets you know when you break something before shipping your code.

7. Don’t start a big major refactoring if nobody asks you to.

This is what I call Massive Unrequested Refactorings.

Either you refactor as part of your tasks or make it official as part of your sprint planning. There’s no point in between.

8. Don’t waste time on pointless discussions about tools or tech.

—”Entity Framework is the best.” —”No, it’s painfully slow.” —”Nooo, stored procedures are the best”

Arrggg!

Tools are just tools. That’s why we, coders, have the reputation of being opinionated and grumpy. And please, let’s not talk about clean code and best practices. That’s a subject I changed my mind about.

9. Always automate code style and best practices.

Don’t ask a human to do the work of a machine. Code style perfectly matches the type of work for machines.

10. Projects fail because of communication problems.

The same thing I’ve heard about marriages.

At a past job, I was engaged in 3- or 6-month projects. We used the shiniest and brightest tools and frameworks. But some projects ended up off the rails.

The only moving variable? Our communication patterns: Failing to communicate expectations, project goals and scope, action plans, and technical issues on time.

11. Every tech problem is a communication problem.

It’s a corollary of #10.

At a past job, I was new to ASP.NET Core and when trying to test my code, I changed a connection string in a settings file and ended up deleting another environment database. Ooops!

I used the wrong settings file in the wrong environment. I didn’t ask, nobody told me, and there wasn’t any restrictions or guards in the code.

It was a communication problem.

12. Solve the problem you have today.

Premature optimization or just being lazy, don’t solve and optimize for a problem you don’t have yet. Avoid writing just-in-case code.

Starting out or already on the coding journey? Join my free 7-day email course and refactor your coding career–I distill 10+ years of career lessons into 7 short emails.

Three Actions That Changed My Writing from Crickets to Likes

2025-04-16T00:00:00+00:00

For almost 5 years, I wrote and only heard crickets.

Then, everything changed when I bought my first writing course and started taking writing seriously, not just for fun, but something I was committed to improving.

I started to see more likes, comments, and shares on my content when I started doing these three things:

1. Study writing subskills

There’s more to writing than just typing.

Writing is a set of subskills to master: headlines, introductions, outlines, storytelling, copywriting, cliff-hangers, and conclusions.

I took a notepad and wrote a list of 10 writing skills I wanted to learn. Then I started working on each of those subskills one by one.

Instead of long and boring introductions, I started using one-sentence openings to attract readers into the rest of my writing.

2. Hand-copying to go to the writing gym

“Writing is learned mainly by imitation”—Writing to Learn by William Zinsser

I started copying sample pieces by hand as an exercise to learn enough copywriting to be dangerous. But I also applied it beyond copywriting.

When we write by hand, we’re forced to slow down and notice and absorb patterns. So next time, we sit down to write, we’ll have those patterns in the back of our heads.

Grab a post or a book section from your favorite writer and copy it by hand. These days, I’m hand-copying some of James Altucher’s books.

Copy, imitate, and then adapt it to your own style.

3. Tell more stories

“Let Wikipedia spit out facts, you have to spit out stories”—Tim Denning

There’s a reason why a Wikipedia article or a scientific paper sounds soulless and emotionless. They’re full of facts. They’re written for a selected few. They’re not written to be remembered.

The easiest way to make our writing memorable is with stories.

I could tell you, “No job is safe.” You’ll probably nod in agreement and forget it. But if I tell you, “The day my boss called me to his office and asked me to hand in my company ID, I learned there was no safe job.” Chances are you’ll remember the second one more.

We’re driven by stories. That’s what we’ve been doing as humans since we climbed down from trees and sat around the fire in caverns.

Thanks to sharing my stories from my past jobs, I finally saw traction with my writing. I finally got more than two likes and not just “Thanks for sharing” as comments.

If you want to stand out from AI-generated content, don’t just share facts. AI can generate facts. Only you can generate stories that connect.

The First Time I Saw a Computer—A Bit of Nostalgia

2025-04-15T00:00:00+00:00

An owl blinking in a large forest made us all jump in surprise.

It was back in 4th grade.

We all were sitting in a large conference room while a guest teacher disassembled a computer. He took every part, showed it to the class, and told us its name.

# # #

That year, the school competition was to build a computer out of recycled materials.

I built mine with boxes and Styrofoam. OK, when I say “I built,” I mean my mom or my aunt. I don’t remember exactly who. My display was made with an old X-ray image.

We exhibited our computers on tables in the school hall while a group of teachers walked around taking notes, trying to find the most creative one.

I didn’t win the competition. My X-ray display wasn’t enough to win.

But after the competition, I put my computer on my desk at home. I pretended to work with it. Sometimes I still pretend.

# # #

After putting all the parts back in place, the guest teacher turned it on.

We all jumped in surprise. We started pointing at an owl blinking in a large forest. After a few seconds, the forest became an enchanted house with bats flying around. I was frozen sitting next to my friends, staring at that thing. Whatever it was that thing.

It was an animated wallpaper. LOL. It must have been Windows 95 or 98.

# # #

I don’t remember what happened to my first computer ever.

But, fast forward a few years, we had our first real computer at home. Or my second one.

It was a Windows 98 computer with a 56K internet connection plugged into a wired phone line. Oh! The famous buzz when we picked up the phone while my dad was connected to the internet. The days of Yahoo and Altavista.

Only my dad used the computer because “it wasn’t a toy.”

We had to restart the computer after every minor configuration and every software installation. We used a protection filter on our displays. They were almost radioactive. And after using it, we put pajamas on our computer before going to sleep. Dust was its arch-enemy.

My favorite wallpaper was an astronaut jumping around in outer space. That was Windows 98.

And that’s how old I am.

Two More Blogging Tips to Try

2025-04-14T00:00:00+00:00

1. Title your reaction posts with “Re:”

I’ve written response or reaction posts before, but I named them with my own titles. Yesterday I found this idea to use “Re:” in titles for response posts.

2. Make your urls easy to pronounce.

I already learned from Derek Sivers to write short and memorable URLs. But this time, I also learned to make them easy to pronounce. For example write URLs using “dash,” which is easier to pronounce than “underscore.”

More blogging tips? Here are two tips I’ve been following. They’ve helped me keep my daily blogging streak.

This One Mistake Might Be Scaring Readers Away From Your Writing

2025-04-13T00:00:00+00:00

Imagine stepping into a restaurant, only for the waiter to say, “You don’t seem to have enough money to eat here.” Would you stay? I know I wouldn’t.

Never, ever, blame your readers.

That’s a mistake I’ve learned to avoid in my own writing, especially when writing sales copy for landing pages.

Instead of blaming your readers, make them feel heard and understood.

The other day, someone tried to sell me access to an online community and shared his landing page. The headline? “You didn’t go to Harvard. You didn’t apply to McKinsey.” He was trying to sell leadership coaching.

Another day, someone shared the landing page of a fiction writing course he was preparing. The headline? “You don’t know how to tell good stories.”

I didn’t want to continue reading past the headline of those two pages. I felt like a schoolboy getting on the bus, walking down the aisle, hoping for someone to smile back—only to be ignored or bullied.

A headline should attract the right audience.

But we should attract the right audience without making them feel dismissed or rejected.

Someone who feels dismissed or rejected stops reading, and worse, they won’t buy.

A couple of alternatives for those landing pages:

“You don’t need to spend 4 years and pay Harvard tuition to be a leader people want to work with.”
“It’s hard to tell good stories. I tried plenty of templates and frameworks. None of them worked. Until I learned this method.”

Boom! Just like that, no more pointing fingers at the reader. Would you keep reading if those two were the headlines? After all, nobody likes being blamed.

When Specs Are Unclear, Wake Up the Experts

2025-04-12T00:00:00+00:00

“Do anything to wake up the experts.”

That was a phrase we repeated at a past job. We were building a gateway-like software to connect small companies to the Government’s tax office.

It took us a couple of years to build a minimum viable product. We were behind the Government’s changing requirements and our own clients’ expectations.

We were late almost all the time. Often we knew we needed to finish something, but we weren’t sure what or how. Apart from emails or conversations with clients, we didn’t have clear requirements or specs.

In those moments, we woke up the experts.

To show some progress, we built on a quick prototype or a half-baked idea. Then, after looking at that half-baked idea, a stakeholder, project manager, or product owner, would speak up, saying that what we had wasn’t what was needed. Then, we started to work on a real solution.

When looking at a bad answer or a half-baked idea, it turned out everyone was an expert.

The fastest way to get a good answer is by giving a bad answer, by waking up the experts.

For more workplace lessons, check the leadersship lessons I learned from this project and the lesson from the most expensive hambugers I’ve tried

Where to Start Your Coding Career: Corporate, Tech, or Agency?

2025-04-11T00:00:00+00:00

If you’re looking to start your coding career, start by understanding each company type has its own vibe.

These days, stability and job security are hard to find. Recession, high interest rates, layoffs, AI, you name it.

In over 10 years, I’ve worked in non-tech corporate companies, tech companies, and software agencies. This is what I’ve found.

Non-tech corporate companies

I started at a “boring” job.

I was at the IT department of a large company in my city. That was my first contact with office politics and the corporate world. Spoiler alert: I was fired.

This type of company in one word? Slow.

If you land a job here, expect more office politics and bureaucracy. The larger the company, the more you’ll find. They tend to offer more benefits and might feel stable.

But don’t expect to work on the shiniest and brightest tech stack or tools. Be ready to work on a legacy codebase with outdated or little documentation, fixing bugs and hacking to add new features without breaking anything.

Tech companies

Tech companies tend to move faster than corporate jobs.

In a tech company, you’re helping the company make money. You aren’t an expense anymore. That often means higher salaries.

This is the place where you’d find TDD, DDD, any other DD methodology, code reviews, Kubernetes, the Cloud, and the shiniest and brightest.

But, they also come with higher risk of burning out.

Software agencies

Here, you are an employee assigned to a client company or project.

There’s good money with agencies if you live in a place with low cost of living and earn your salary in stronger currencies. Money will pass from the agency to your bank, while they take a good chunk of it. That’s the business.

Also, understand that companies prefer agencies as a risk-free alternative to hiring. When they don’t need more hands on a project, they’re just an email away from letting people go. Again, that’s the business.

Expect client rotation and possibly months without pay while the agency finds you another client.

With agencies, there are fewer chances of growth since you’re sold as a pair of hands.

Of course, YMMV.

Rather than choosing a company for its benefits, start experimenting with your career, then make a 5-year career plan (or intention), and pick the jobs and places that take you closer to that plan. That’s a lesson I wish I had known 10 years ago.

Starting out or already on the coding journey? Join my free 7-day email course and refactor your coding career–I distill 10+ years of career lessons into 7 short emails.

Want To Write As A Coder? Start With TIL Posts

2025-04-10T00:00:00+00:00

If you want to start a coding blog, don’t start with a deep dive of the Linux Kernel or other cryptic topics, unless you’re an expert on them.

Instead write short “Today I Learned” (TIL) posts.

TIL posts are shorter posts where you share something you’ve found or figured out.

When writing TIL posts, you don’t have to worry about long introductions or conclusions. Just write a good headline, a code block, a quick explanation, and your sources. And write using your own words, like in a conversation with a coworker. Here are my TIL posts as example.

That’s enough to make a post worth reading.

TIL posts invite people into your learning journey.

Don’t try to lecture the coding world about what they should do. Start documenting your learning instead.

Instead of writing “5 VS Code extensions every coder should install,” try “TIL: 5 VS Code extensions I couldn’t avoid installing.”

Or instead of “5 Git commands every coder should know,” covering the same basic Git commands, write “TIL: 5 Git basic commands to use everyday” or “TIL: How Git Status works.”

Did you spend 20 minutes or more figuring out something? write a TIL post. That’s the easiest way to start a coding blog. And don’t think of writing your own blogging engine.

Apart from coding, writing has been one of the best skills I’ve developed as a coder. It’s taught me to research, organize, and present ideas clearly.

That’s why I made it one of the strategies in my book, Street-Smart Coding: 30 Ways to Get Better at Coding. It’s the guide I wish I had when I was starting out, trying to go from junior to senior.

Get your copy of Street-Smart Coding here

Just Doing Great Work Isn't Enough—People Won't Come

2025-04-09T00:00:00+00:00

As full-time employees, we only stick to “our part.”

If we’re coders, we only care about coding. If we’re designers, we only care about Photoshop. Somebody else handles finding clients, marketing, sales, and follow-ups. If we, as full-time employees, care about what’s not “our part,” we stand out.

But with a side gig, a SaaS product, a novel, or a hobby to monetize, we have to also do everything else that isn’t “our part.”

When we do “our part,” the job isn’t done. We have to wear all those hats. We have to be our own marketing, sales, and customer satisfaction departments. We can’t expect others to do that for us.

Doing great work alone isn’t enough. People won’t just come. Do great work, then make sure the world knows about it.

Success Isn't One-Size-Fits-All. And That's Okay

2025-04-08T00:00:00+00:00

“And so…what happened?” she said.

I was with a friend at a supermarket while the cashier passed the products along the band through the machine. There was a copy of “Psychology of Money” on the counter. And I was telling my friend my favorite story from the book.

“There was a guy in a town. He was the school janitor. You might think janitors don’t make a lot of money.” I said while the cashier was listening. “But after he died, they found out he was a millionaire who donated part of his fortune to the local library.”

“So…what happened? He worked for nothing?” the cashier asked me.

“Well, maybe that was his success. Cleaning rooms for kids to study. That was what he enjoyed,” I told her.

“Nah, nah, nah,” she said while she leaned back, stretching her arms behind her head, “I want to be doing nothing.”

# # #

I’ve changed my mind about success lots of times.

For a while, I thought success meant climbing the corporate ladder to the title of VP in a tech startup Silicon Valley. Then, it was mastering coding, chasing the “expert” label. Then, it was sitting on a beach holding a piña colada while trading and enjoying financial freedom. Then, it was something else.

But those weren’t my own success metrics.

They were success metrics I had absorbed without question. From YouTube, from my peers, from the rich. It took me a burnout season to realize I had been trying to make this corporate dream work for over 10 years. Better late than never.

For the janitor, maybe it was a boring job. For the cashier, doing nothing. But my success metrics these days? Working on things I love and following my passions without worrying about money.

Your success metrics don’t have to be like mine or like anyone else’s. And that’s fine. But whatever they are, make sure they’re truly yours.

Want to Write for Years? Start by Writing Like No One's Watching

2025-04-07T00:00:00+00:00

“Hey, how’s your LinkedIn posting doing?” he said.

I was at a gathering with some friends and ex-coworkers. “I read your posts. I don’t like or comment on them, but I read them.”

That was surprising. I wasn’t expecting a greeting like that one. That was a small win and encouraged me to stay consistent and keep showing up.

Last year, I revived my LinkedIn account and started to use it to share my ideas and build my writing skills in public, instead of simply using it to land new jobs.

When we start writing online, we expect to have thousands of followers, tons of comments, and to become thought leaders in just a couple of days.

For some reason, we don’t expect the same when practicing a sport. But we think it’s true for social media and writing online.

The first months of writing online are lonely. Nothing happens. Nobody likes or comments on any of our posts. Post after post goes nowhere. Just cricket sounds. We’re shouting into the void.

But those first moments are the ones that make us build our persistence muscles and push us to improve our craft. “I didn’t make it today. There’s another chance tomorrow.”

Write as if nobody is reading, and keep writing because you don’t know who’s reading.

10 Features of a Non-Addictive Social Platform

2025-04-06T00:00:00+00:00

Every beep, buzz, and notification is designed to keep us hooked.

The other day while preparing my Friday Links email, I found Seven39. A social media platform that only opens from 7:39PM to 10:39PM EST.

It made me think of what features I’d like to see on a non-addictive social media app:

#1. It only opens on a fixed schedule. Inspired by Seven39 itself. Or, instead of a fixed schedule for everyone, users set their own open hours, capped at two hours per day.

#2. It only allows you to have 150 connections, at most.

#3. After open hours, it goes into “dumb” mode or simply kicks you out, and you can’t log in again.

#4. It only allows a maximum number of interactions, such as likes, comments, or reposts, per day.

#5. Users are limited to one post per day. You’re better off thinking carefully about what you want to share. You only have one shot.

#6. It’s invitation-only.

#7. It doesn’t email you, except for authentication and security reasons. No email notifications at all. No “someone viewed your profile.”

#8. No endless feed for you to scroll. You can only interact directly with your connections.

#9. It has no notifications while you’re online. You should only receive a daily digest of your connections’ activity on your post.

#10. It has no metrics. Just likes.

A platform like this needs a name. What about these?

BeepZero: No beeps. No notifications. Just connection.
TinCan: Your friends, you, and a tin can phone.
NoSocial: The nosocial media platform.

Which one is your favorite? Mine is TinCan.

Would you sign up for a platform like this? Of course, after you receive an invitation.

8 Lessons from a Conversation Between @CulturalTutor and David Perell

2025-04-05T00:00:00+00:00

From cleaning at McDonald’s to 1.7 million followers on Twitter/X.

Sheehan Quirke (@CulturalTutor) was trying to find ways to make money writing. His best plan was offering tutoring in literature, architecture, and culture. He started his Twitter/X account to drive traffic to his tutoring gig.

Plot twist? People on Twitter didn’t want his tutoring sessions, but his threads.

That’s how Sheehan started. He shared his story here:

And here are my lessons from that interview:

#1. Don’t read anything written in the last 50 years. If you read what everybody else reads, you’ll say same the same things as everybody else. And you’ll think like everybody else. Find good sources of inspiration.

#2. Focus on writing good stuff. Forget about algorithm hacks and engagement pods. Just write.

#3. Write good hooks. Our content is competing with memes and 6-pack abs. Our content will pass unnoticed unless we write opening lines that make people stop scrolling. Steal your hooks from influencers.

#4. The best way to stay consistent is to always believe you can improve. Your writing today is practice for better writing tomorrow.

#5. Find peers who encourage you. This is what James Altucher calls finding your EQUALS. People on the same journey who can challenge and encourage you.

#6. Treat writing as your full-time job. A young boy who wants to make it to the Major Leagues knows he has to train and practice every day. Writing shouldn’t be anything different.

#7. Focus on one thing. It’s easy to get distracted by too many platforms, pretending to be everywhere. Twitter/X, Medium, Substack, LinkedIn, etc. Focus on one thing in one place. When Sheehan was starting on Twitter/X, he wanted to start a newsletter. That would have distracted from what was working: Twitter threads.

#8. Find ideas on your daily conversations. And refine them by talking about them. This sounds like the 3-strike rule to write posts I found the other day.

How to Demotivate Your Development Team?

2025-04-04T00:00:00+00:00

Guaranteed results in 10 simple steps:

#1. Ignore ideas and suggestions. If anyone comes with an idea or suggestion, ignore it. And if anyone raises a concern, say it’s fine and it used to be worse.

#2. Take credit for someone else’s idea. If anyone comes with an idea and you don’t want to ignore it, say “oh, that was what I told you we should do.”

#3. Don’t share any vision or project goals. Just keep your team closing JIRA tickets. Tickets and more tickets.

#4. When someone asks for a salary review, say “come back in a few months.” And then, tell them to come back again. And on and on.

#5. Once a task or project is finished, publicly praise someone else’s work.

#6. Give your team boring and repetitive work. The more boring and repetitive, the better. Make them dig holes. Then make them fill those holes.

#7. Make them work on projects no one will use. Did your team work on a project for six months? Archive it, deprioritize it, or make sure nobody uses it.

#8. Your team worked hard, but why share what the users think? That’s not their business, right? Don’t share any feedback. Just keep them finishing tickets. See #3.

#9. Use the word “resource” to refer to them and treat them accordingly. Your team members are machines you can replace anytime.

#10. Lay off people and tell the ones who stay “nothing is happening.” And if they ask about it, tell them they should be grateful for still having a job.

Follow these steps and you’ll have team members who will leave you at their first chance.

Why You Should Change Jobs—According to Jesus

2025-04-03T00:00:00+00:00

I’ve finally understood why it’s better to change jobs than to ask for a raise.

These days, I was reading James Altucher’s archive of posts and I found out about the Jesus’ effect. I had already heard about the Doppler effect, the Google effect, and the Butterfly effect. But, not about Jesus’ effect.

The Jesus’ effect or just being the “carpenter’s son”

According to the Gospels, Jesus was traveling and preaching all over his home country.

In our modern day, he would be on podcast tours, giving TED talks, and running masterminds. He was creating a brand and growing a following. Literally.

His movement was getting larger and larger, with followers and haters.

Until he arrived in his hometown.

He couldn’t continue doing any of his work. There, he was only the “carpenter’s son.” His hometown was the place with the most haters.

At that point, I had already heard about that piece of advice: “Don’t ask for a raise, change jobs.” I’ve made the mistake of not following it. Shame on me!

But then I made the connection between Jesus and changing jobs

Often, the best place to grow is not where you’re at now, but somewhere else where people will value you more.

Where you are now, you’re probably the database guy or the API guy or the UI guy. That’s your perceived value. You’re just the “carpenter’s son.”

That’s why most conversations about salary raises die with a “come in 3 or 6 months” or “come after your next performance review.” You’ve reached a glass ceiling in terms of growth and how management and check-signers perceive you at work.

There are no more growth opportunities. No more salary increases. Just the same old grind until you get bored or laid off.

Often, just like Jesus, we find ourselves defined by labels, the “carpenter’s son” or whatever label you have at work, and to grow, we have to move to another place. Be like Jesus and find opportunities somewhere else where you’re valued more.

I Never Knew Kidneys Mattered—Until Dialysis Hit Close to Home

2025-04-02T00:00:00+00:00

All marketing goes to hearts and lungs.

Buy sunflower oil because it’s good for your heart.

Don’t smoke. And if you buy a pack of cigarettes and it comes with a picture of damaged lungs.

But what about kidneys? I haven’t seen any ads for them.

# # #

“She needs blood transfusions. Sign the consent here,” I was told.

My loved one was in the ICU. After lots of blood tests, a full-body scan, and urine exams, the diagnosis: chronic kidney disease.

Two days earlier, we took her to the ER.

Her abdomen was swollen. She couldn’t hold a simple conversation. She threw up constantly. Sometimes, she couldn’t even recognize us. Her body was poisoning itself.

Her kidneys had collapsed.

It was 2020, in the middle of the bat-soup crisis. We were scared of what she had and scared that she might get that deadly thing from the hospital air. Either one could kill her. Two invisible enemies.

She got the highest priority in triage at the ER. And she didn’t spend long time there before getting into the ICU. A couple of unknown heroes stood up for her with their blood.

An internist, a urologist, and a nephrologist saw her. She wasn’t fine at all.

# # #

Kidneys have two main functions:

Remove excess liquid from your blood.
Filter waste and toxins from your blood.

High blood pressure, diabetes, and kidney infections are signs that you should look for to start taking care of your kidneys more closely.

Drink enough water, exercise, stop smoking, and avoid salt. Take care of your kidneys.

Don’t trust me. Trust the US National Institute of Health. Or talk to your doctor.

# # #

“My life depends on a machine now,” she told me.

My loved one was shocked after her first session of dialysis.

When your kidneys are damaged, a machine replaces them. You’re “connected” to a machine that works like your kidneys. It takes out some blood, filters it out, and puts it back in. That happens for 3 or 4 hours, three times a week. That process is called “dialysis.”

It’s like going to a gym or exercising three times a week to stay healthy for a regular person. The only difference for her? She can’t skip a day or two. There’s more at risk for her than a slim body.

She first had a small tube in her neck, then in her chest. That’s how she got connected to that machine. And later, a vascular access on her arm (a vein and an artery are connected to get more blood out). This time, she got connected with two large needles. Ouuuch! That’s painful.

Sitting for 4 hours is uncomfortable.

But that’s not the worst part after a session of dialysis. High or low blood pressure, headaches, dizziness, and tiredness. That’s the worst part.

After every session, she eats and then goes right to bed. No more mental or physical energy for anything else. The day is over.

Does her life depend on a machine? Technically, yes. But we prefer to see it as the machine giving her life. It’s not her enemy, it’s her fighting partner.

7 Reasons Why I'll Keep Writing—Even If AI Writes Faster and Better

2025-04-01T00:00:00+00:00

We can’t compete with AI on speed.

AI is getting faster, better, stronger, and cheaper. In seconds, it can produce a post about almost any topic in any writing style. An essay about climate change in the style of Hemingway? AI spits it out. Beep, beep, boop!

The battle against AI-generated content is lost.

Even if one day AI writes better and faster, I’ll still write because:

Writing is learning: If you want to check if you understand a subject, try writing about it.
Writing is teaching: You don’t need a lecture hall to teach or share anything. Simply write about it somewhere on the internet.
Writing brings clear thinking: This reason is strong enough not to outsource our writing to AI.
Writing is building a time capsule: Writing is leaving breadcrumbs of what we were learning and doing. It’s leaving success clues. It’s a time capsule.
Writing is free, public therapy: In 2024, I applied to FAANG and failed. Instead of ranting that hiring is broken, I decided to write about it. It was liberating.
Writing is an exercise for my creative mind: After ditching my to-do lists, writing is part of my daily routine to do something for my body, mind, and spirit each day.

And more importantly, 7. writing helped me recover from burnout last year.

Last year, I took officially my first writing class.

It was the first step toward taking my writing seriously after about five years of blogging. Writing daily was part of welcoming a sense of joy into my life after all the dissatisfaction and disengagement of burning out.

In the end, writing rescued me.

Even if AI splits the world into writers and write-nots, even if it spits words faster than I ever could, I’ll continue writing, for my health, for my joy, for myself. I’d like to be a writer.

PS: This is my answer to Ron Markley’s Medium post titled: What if one day AI writes better than you? Will you still write?.

Use AI Like We Use Calculators in Math

2025-03-31T00:00:00+00:00

For 8 years, calculators are banned in math class.

We can only use calculators after we learn to do arithmetic by hand, like multiplying and dividing 2- and 3-figure numbers manually. We have to learn the procedure first.

We should use AI the same way, only after we know how to do the procedure by hand.

If you aren’t comfortable with coding yet, don’t ask AI to generate code.

If you aren’t comfortable with writing, don’t ask AI to generate any text. Instead, use it to proofread and critique your writing.

AI should be like calculators in math: a tool to make us faster if we know what we’re doing. They can’t do the thinking part for us. That’s still on us.

An Easy Mnemonic to Format Dates As Strings in C#

2025-03-30T00:00:00+00:00

Is it MM or mm for months when formatting dates? Is it yyyy-MM-dd or yyyy-mm-dd?

I always forgot which one to use…until I figured out an easy mnemonic.

MM vs mm

Ask yourself: Which one represents a larger time frame? Months or minutes?

Since one month is larger than one minute, it’s M for months. An uppercase m is larger than a lowercase m. Write, anyDate.ToString("yyyy-MM-dd").

mm vs fff

Then, what is it for milliseconds? Isn’t it mm?

Now, ask yourself: Which one is faster? One minute or one millisecond?

Since one millisecond is faster, write f instead of m. Write anyDate.ToString("hh:mm:ss.fff").

Easy, peasy now!

My Worst Interviews and the Lesson They Taught Me

2025-03-29T00:00:00+00:00

If you’ve been around long enough in tech, you know hiring is broken.

We all have horror interview stories. It’s a shared experience all the way from small companies trying to imitate FAANG processes and large companies with dozens of “phases” to go through.

I’m not the exception, so here are two of my horror stories and a lesson.

They wanted to test my IQ

Before the bubble of 2020, a recruiter from a staffing company reached out on LinkedIn.

The meeting had an awkward start. The recruiter refused to speak in our native language, but in English. I might understand that, since they worked with American clients.

But the horrific part came when she told me they were going to test my IQ to see if I was “smart enough” to work with them. At that moment the interview ended for me. Run, Forrest, run!

They wanted a screen-recording

I’ve been asked to solve take-home interview challenges more than once.

But this time, with another staffing company, I had an unusual interview challenge: not only did I have to solve a medium-size coding exercise, but also record my screen while explaining out loud my thought process, in no more than 2 hours, and send them a link.

I guess a poor soul had to watch my recording at 2x, if anyone ever watched it. My thought was to create a YouTube channel and solve it live. At least, it would count towards the watch time to monetize a YouTube account. Of course, I didn’t continue.

Probably I had more horror stories I can’t remember.

The lesson

Hiring is a two-way street: you’re evaluating them the same way they’re evaluating you.

The first meeting shows how they’re going to treat you as an employee. And if you notice red flags during the process, like unclear expectations and unrealistic demands, imagine what it would be like working there.

Always ask about the next steps, salary, and compensation in the first meeting.

When I was job hunting, my rule was to step away if they didn’t share salary details in the first meeting. Why waste months only to discover they’re offering half of your current salary?

The Not-an-Architect Effect

2025-03-28T00:00:00+00:00

Has this also happened to you?

You’re in a meeting discussing a technical issue or a bug. After many ideas, you share yours. But it passes unnoticed.

Since there was no consensus, another meeting is scheduled. But this time with a figure of authority or expertise: an architect, director, or VP.

Surprisingly enough, they share the same idea as yours. But this time, it’s considered.

That’s when you say “I said the same thing, but since I’m not an architect, director, or VP nobody listened.” Arrggg!

Sure, those moments are frustrating. But they earn us points in our authority and trust score.

It’s not only about sharing good ideas, but how we present them and how others perceive us, just another team member or a trusted one.

That’s what I call: the not-an-architect effect. A reminder that how we present our ideas is as important as the ideas themselves.

Minifeed Showed Me the Indie Web: My Favorites from Yesterday's Feed

2025-03-27T00:00:00+00:00

If you’re not new to writing online, you’ve heard blogging is dead.

And there’s some truth behind that. Social media has killed blogging. Google doesn’t like personal blogs anymore. It’s regurgitating AI answers. That made me change my writing strategy, by the way. My blog isn’t the only place I show up anymore.

Personal blogs are still alive…in a small corner of the Internet. The problem is discovering them.

If Google’s bots don’t crawl and index your blog, your posts will sit there forever, waiting for visitors. That’s not the case with social media. Just open your account and scroll your feed. And boom! Content is there!

These days, while looking at my analytics, I discovered out a “feed” for blogs: minifeed

Minifeed is “a curated blog directory, reader, and search engine.”

Its goal is to collect personal blogs and make them discoverable. No AI or algorithms behind the feed, just human curation.

Yesterday, I scrolled through minifeed’s feed and went down the rabbit hole of personal blogs. Here are my favorite posts:

#1. A photo of a big door. This is from a photographer running a plog, a photo blog. Did I just invented a new Internet word?

#2. A diagram of feline feelings.

#3. A software engineer who changed his mind about AI.

#4. A reflection on time passing.

#5. A developer who learned about nonograms. Imagine a sudoku marrying a crossword, but instead of putting numbers in cells, you have to color them. Definitely, I’m giving them a try.

#6. A writer who decided to stop writing down ideas because good ideas always come back. Well, I need to write them down to tell my brain “it’s OK, we already did something about it. Back to sleep.” I also discovered another daily blogger.

#7. A post on why requests to fire people are often rejected.

#8. Someone using music as a pain reliever after getting his knee replaced.

#9. And of course, my own post with tips to read code. Shameless plug.

If you want to go down the rabbit hole of personal blogs, try indieblog.page to get a random post or searchmysite.net for a search engine of personal blogs, ooh.directory, or blogroll. Blogging isn’t dead yet.

Three Tips to Read Code More Effectively

2025-03-26T00:00:00+00:00

We spend more time reading than writing code, but we’re seldom taught how to read it.

Almost 100% of my coding courses in university were about writing code: syntax, algorithms, and class design. Nothing about reading. I only learned about reading code from a coworker at a past job.

Yesterday, I found this conversation as part of the GOTO Conference about reading code:

Here are some key points from that conversation:

#1. Read a piece of code at first glance and see what stands out

Maybe that’s a function or a symbol or a messy block of code.

That’s also my go-to guide to refactor a piece of code: While scrolling through a piece of code, if I need to stop and read it twice, there’s something to refactor, something needs to be better explained.

#2. Read with empathy

After reading Clean Code for the first time, I wanted every piece of code around me to be perfect.

No comments. No booleans as parameters. No more than 20 lines per function.

Every time I found a piece of code that wasn’t closely aligned to the book, I always said, “Who wrote this crap?!”

I had to learn that we all do our best with the context and deadlines we have. If we have to fix a pressing issue in 24 hours, we do our best. That might not be the perfect solution.

And of course, there will always be better ways to solve a problem, once we solve it for the first time.

#3. Always start by pointing the good parts

This is especially when auditing or reviewing other people’s code.

It reminds me of the principle from How to Win Friends and Influence People: don’t tell anyone they’re wrong.

Reading code has been one of the most effective ways to improve my coding skills. In fact, I believe it’s the best way to learn to code. That’s why I made it one of the 30 proven strategies in my book, Street-Smart Coding: 30 Ways to Get Better at Coding. That’s the roadmap I wish I had when I was starting out.

Grab your copy of Street-Smart Coding here.

A Simple Script to Keep a Log File with Bash and Vim

2025-03-25T00:00:00+00:00

To keep track of my client work, I’ve been using a simple “did” file. You know, I’m a plain-text fan.

At the end of every workday, I write down what I did for that client and what I need to do the next working day.

Here’s the script I use—add it to any of your dotfiles:

function did() {
    vim +'normal Go' +'r! date "+\%Y-\%m-\%d \%H:\%M:\%S"' +'normal o' ~/did.txt
}

From a terminal, simply type did, and it opens a “did.txt” file with Vim, appends the current date and time at the end, and you’re ready to type. Simple as that.

For everything apart from client work, I’ve ditched my to-do lists.

10 Ways New Coders Can Use AI Without Generating Code

2025-03-24T00:00:00+00:00

If you don’t know how to code, you shouldn’t rely on AI to generate code.

AI is here to stay. Sure. We can’t ignore it. We have to adapt, like we coders have always done.

But the problem with AI is when we use it to outsource or replace our thinking. If you’re not the one using the tool, you’re becoming the tool. And tools are easy to replace when a faster and better tool appears.

If you’re a new coder, don’t ask AI to generate code for you.

Ask AI to do any of these tasks instead:

Review your code
Dissect a piece of code
Explain difficult concepts
Create roadmaps and study guides
Act as your debugging rubber duck
Generate test cases or sample inputs
Learn the most common language features
Look for security and performance issues
Create questionnaires to evaluate yourself
Check your understanding of a difficult concept
Translate one piece of code to another language
Learn the most common methods from standard libraries

Using AI is like using calculators in math classes. They can make you faster if you know what you’re doing, but they can’t think for you.

As I learned from Jim Kwik, the brain coach,

“Use Artificial Intelligence to extend your Human Intelligence, not to replace it.”

AI can generate code in seconds. But the real value of a coder isn’t in typing. It’s in understanding business problems and collaborating to build the right solutions.

That’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding, a practical guide to the skills that actually make you a confident coder. It’s the roadmap I wish I had when I was starting out.

Get your copy of Street-Smart Coding here

9 Lessons from Writing 10 (Bad) Ideas Daily to Become an Idea Machine

2025-03-23T00:00:00+00:00

Since October 2024, I’ve written 10 bad ideas every single day and it has transformed my creativity.

I started this practice inspired by James Altucher. I found it on his blog and books. Choose Yourself Guide to Wealth covers it in-depth. He calls it: becoming an idea machine.

The point of writing 10 ideas isn’t to come up with 10 perfect ideas, but to exercise your creativity and possibility muscles. The goal is to write 10 bad ideas about anything every single day.

Here’s what I’ve noticed after writing thousands of bad ideas in six months:

1. You can’t run out of ideas

One of my concerns when I started was running out of subjects to write ideas about. But the more I practice it, the more subjects I find to write 10 ideas about.

2. A 10-idea list could be a post

Most of my social media and blog posts start from a 10-idea list. This very post was a 10-idea list.

Writing 10-idea lists is the first step of my content wheel: 10-idea list, then a social media post, then a blog post.

3. It’s easier to execute ideas starting from 10-idea lists

Starting a big project may feel daunting, with too many moving parts and too much uncertainty.

But it’s easier starting with 10 bad ideas, then writing another 10 to execute one of them.

For example, do you want to write a book? Write 10 subjects you can write a book about. Then, write 10 titles for a book on one of those first 10 subjects. Then, write 10 ideas for chapters. Then, 10 stories to include…and so on and so forth.

4. The first 5 or 6 ideas are the easiest ones

The other 4 or 5 are when you start sweating and stretching your idea muscles. After those 4 or 5, that’s when the aha moments happen.

5. Give away 10 ideas to connect with others

Instead of reaching out to ask for anything, give away 10 ideas.

Since I started this practice, my favorite way to connect with someone on LinkedIn (or via email) is giving away 10 post ideas the other person could write. It surprises them and makes the connection more meaningful because you’re giving, not asking.

6. Writing 10 ideas works like note-taking

After consuming anything, a book or podcast episode, I write 10 ideas I learned from it. It works like taking notes. It helps me recall the main points of what I consumed and remember them more.

7. It’s a perfect exercise to quiet your mind

Write 10 ideas about anything and give your mind a productive task instead of letting it wander off imagining lions behind bushes trying to attack you.

8. It’s a perfect replacement for a to-do list

Since this year, I’ve ditched my to-do lists and replaced them with a done list. Guess how I do it? Yes, with a 10-point list.

At the end of every month, write 10 things you did in that month.

9. Write prompts for future days

As soon as I have a subject to write 10 ideas about, I write it as a prompt on a new page of my idea pad. Otherwise, I forget about it. It’s easier to sit down and write 10 ideas the next day when you already have a prompt ready.

Writing 10 ideas a day helped James Altucher get out of bankruptcy and change his life. For me? It has given me lots of ideas for new content. It helped me with my 100-daily-post challenge. It made me more creative. Because creativity isn’t just about art. It’s also coming up with bad ideas. It’s about becoming an idea machine.

Is Burnout Inevitable in the World of Tech?

2025-03-22T00:00:00+00:00

In 2023, I burned out.

I checked all the boxes for the first time. The burnout boxes. It wasn’t a good thing. And it took me almost an entire year to recover.

I know I’m not the only one, of course. It’s all over the tech industry.

In recent weeks, I’ve been exchanging emails with another senior software engineer who went through a burnout season. His take? The tech industry is unsustainable.

These days, I’ve been chatting with a group of colleagues and friends. Most of them claimed to experience some sort of boredom at their jobs. OK, boredom isn’t burnout, but it’s a warning sign.

We’re privileged to work in the tech industry.

But, it has its own challenges—YMMV, of course:

We work long hours.
Coding is mentally exhausting.
AI threatens us to take our jobs.
Layoffs are always around the corner.
Agile and SCRUM take control away from us and trap us in “ceremonies.”
We’re problem solvers at heart, but often we don’t get to solve problems.
We’re expected to code after hours just to prove we’re “passionate.” Side projects and open source contributions.
We have high standards for quality and development practices. But stakeholders’ expectations don’t align ours. They care about different things.

The toll? Our mental health. Burnout.

The solution? I don’t have one.

Yesterday I found on the front page of Hacker News a post about tech being a burnout machine and unionizing as the solution. Mmmm. Dunno.

My best idea? Detach our sense of meaning from our jobs, recognize there’s nothing wrong with coding just to pay the bills, set boundaries between work and non-work, and diversify our sources of joy.

You Don't Need Superpowers to Be a Hero—Save Lives Today!

2025-03-21T00:00:00+00:00

You don’t need X-ray vision, super strength, or any other superpower to save lives.

Recently, I read about James Harrison’s story, an Australian called the “Man with the Golden Arm.” His blood had a rare antibody used to treat a disease in pregnant women. He saved over 2 million babies, his own grandkids included.

A true hero without any superpowers. Well, a hero with super blood.

One family member, for health issues, has received blood transfusions at least three times in recent years. She has received 8 “units” in total. This means 4 heroes have saved her life. Since then, I’ve decided to donate enough to at least match the units she has received.

James was a hero for millions of babies. Some heroes saved my loved one. Inspired by them, I decided to become a hero for someone else too.

Forget about the red cape and boots, you don’t need them to save lives. Donate blood and be someone’s hero.

I Asked Phind and Copilot to Solve an Interview Exercise—Their Solutions Surprised Me

2025-03-20T00:00:00+00:00

Did AI kill the tech interview?

Truth is hiring and interviewing have been broken for years. There wasn’t much left to kill. In over 10 years, I’ve witnessed all types of interviews: casual conversations, interrogation-like conversations with rapid-fire questions, take-home coding exercises, and the infamous LeetCode exercises.

I asked Phind and Copilot to solve an interview exercise. I might or might not have been asked that exercise when applying to a FAANG.

Here’s the “made-up” problem—Wink, wink:

You’re given a string containing the words “one” and “two”, and the symbols “+” and “-“ representing a math expression. Write a C# function called “Evaluate” to evaluate that expression after replacing “one” with 1 and “two” with 2. Assume the underlying expression is well-formed. For example, “one+one” should return 2, “two-two-one-two” should return -3, and “one+two-one-one+two+one” should return 4.

I’m using that exact same problem statement as a prompt for both Phind and Copilot. I know…I could have a more advanced prompt.

In this corner, with over 10 years of C# experience, me:

Here’s my “pure string evaluation” solution:

private int Evaluate(string str)
{
    var first = str[..3];
    var result = first == "one" ? 1 : 2;

    var index = 3;
    var lastOperation = '+';
    while (index < str.Length)
    {
        var substring = str.Substring(index);
        if (substring.StartsWith('+'))
        {
            lastOperation = '+';
            index++;
        }
        else if (substring.StartsWith('-'))
        {
            lastOperation = '-';
            index++;
        }
        else if (substring.StartsWith("one"))
        {
            result = lastOperation == '+' ? result + 1 : result - 1;
            index += 3;
        }
        else if (substring.StartsWith("two"))
        {
            result = lastOperation == '+' ? result + 2 : result - 2;
            index += 3;
        }
    }

    return result;
}

OK, that’s ugly and has lots of repetition. I looped through the string to identify if I was visiting a number or a symbol and stored the last known number and operation.

Nothing fancy! Probably I wouldn’t have hired myself with that solution. But, hey, “it works on my machine.”

And, let’s see what Phind and Copilot do. Place your bets…Drum rolls…

In this corner, with its “largest and most performant model to date,” Phiiiiind:

Here’s Phind’s exact solution (here’s my conversation but I don’t know how long it’s stored though):

public static class WordNumberEvaluator
{
    private const string ONE = "one";
    private const string TWO = "two";

    /// <summary>
    /// Evaluates a mathematical expression containing word numbers 'one' and 'two'.
    /// </summary>
    /// <param name="expression">The expression to evaluate</param>
    /// <returns>The numerical result of the expression</returns>
    public static int Evaluate(string expression)
    {
        // Replace word numbers with digits
        string processed = expression
            .Replace(ONE, "1")
            .Replace(TWO, "2");

        // Use DataTable.Compute to evaluate the expression
        var dataTable = new DataTable();
        var result = dataTable.Compute(processed, String.Empty);

        return Convert.ToInt32(result);
    }
}

public class Program
{
    public static void Main()
    {
        Console.WriteLine(WordNumberEvaluator.Evaluate("one+one"));       // Outputs: 2
        Console.WriteLine(WordNumberEvaluator.Evaluate("two-two-one-two")); // Outputs: -3
        Console.WriteLine(WordNumberEvaluator.Evaluate("one+two-one-one+two+one")); // Outputs: 4
    }
}

Phind surprised me a lot.

It used a DataTable to evaluate expressions. I didn’t know DataTable could do that. I wouldn’t have thought about that in a real interview.
It added docstring comments and two comments to explain its solution.

But that didn’t surprise me as much as seeing all the tests turning green when I ran its solution. For a moment, I thought using a DataTable was a hallucination. A veteran coder warned me about them the other day.

If you’re still skeptical, like me when I saw that function working, here’s Microsoft official docs on DataTable’s Compute method. It’s more Excel-like formulas inside a DataTable. The first parameter is an expression and the second one, a filter.

OK, the thing was Phind referenced 4 sources. Two of them were StackOverflow questions, one of them had the trick with the DataTable. But two of them were Medium posts talking about evaluating math expressions, but nothing inside them related to the solution it used.

And in this corner, backed by Microsoft, Copiiiiilot:

Here’s Copilot’s solution:

using System;
using System.Data;

class Program
{
    static void Main()
    {
        Console.WriteLine(Evaluate("one+one")); // Output: 2
        Console.WriteLine(Evaluate("two-two-one-two")); // Output: -3
        Console.WriteLine(Evaluate("one+two-one-one+two+one")); // Output: 4
    }

    public static int Evaluate(string expression)
    {
        // Replace "one" and "two" with their numeric equivalents
        expression = expression.Replace("one", "1").Replace("two", "2");

        // Use DataTable to evaluate the expression
        DataTable table = new DataTable();
        return Convert.ToInt32(table.Compute(expression, string.Empty));
    }
}

OK, I used Copilot on a browser, not inside my Visual Studio or Visual Studio Code. Same trick with DataTable. I wasn’t impressed the second time.

Not even in my dreams, (and I don’t dream about code) I would have thought about using DataTable as the trick under my sleeve here, especially with a clock-ticking on a platform like LeetCode or with a hiring manager looking at my screen.

Did AI kill the tech interview? I’d say yes, at least for data structure and algorithm questions. OK, I only tried it with one coding exercise, but that’s still a yes.

9 Subjects I've Changed My Mind About as a Software Engineer

2025-03-19T00:00:00+00:00

Many things have changed over the past 10+ years in my career—technologies, mindsets, and even what I value most from my career.

I switched from Java to C#. I switched from JavaScript to Xamarin to ASP.NET to ASP.NET Core. From being the “new guy” in my first job to sitting in meetings with the CEO in one of my last jobs. It was a small company, maybe not that impressive.

Apart from those, here are 9 subjects I’ve changed my mind about:

1. Databases

I used to hate working with databases.

I hated them so much that I traded tasks with a coworker at a past job. He did my database tasks in exchange for his API-related tasks.

Avoiding learning about databases made me take down a server. I wrote a query with a function around a column in a WHERE clause. Ooops! Don’t do that!

Everything changed when I decided to learn about databases from scratch, with a beginner’s mindset. My googling took me to Brent Ozar and his courses.

Databases and SQL Server aren’t my kryptonite anymore.

2. Clean Code

I read Clean Code back in ~2013.

After that, I became a Clean Code police officer. I looked for Clean Code infractions everywhere around me. I was following and preaching the book.

Eventually, I learned that not all code is created equal and worth the same. Everything is a tradeoff. And we shouldn’t blindly follow best practices.

3. Certifications

“Azure Blah Blah Blah Associate” or “Google Blah Blah Blah Developer.” That sounds impressive.

When I started coding, I wanted to pile up all those certifications. Until I learned these certifications are often a marketing strategy from the certifying company. Every once in a while, they change the certification tracks and you have to start again. And of course, pay again.

Instead of certifications to prove my “knowledge,” I opted for just-in-time learning in the context of real projects.

And if you’re chasing certifications to make your CV look good, if your CV is in a pile (physically or virtually), you already lost.

4. Optimizing everything

I went from finding small improvements on a random line of code to finding the biggest improvement I could gain with minimal effort, after gathering the right metrics, of course. That’s one of the lessons I learned from Brent Ozar. See #1 again.

5. Climbing the corporate ladder

I used to believe I could climb all the way up to the top of the corporate world.

I was wrong! Anyone can add new steps to that virtual ladder. Anyone can change the entire ladder and you’ll have to start climbing all over again. At any point, someone can say “you’re not ready yet. Keep working hard. Next year.”

I’ve seen only one successful climb in over 10 years. She joined as an intern and yeeeears later, she became VP of something. It was at my first job. When I joined, she was already VP. Somebody told me the legend.

Instead of climbing somebody else’s ladder, I decided to build my own and define my own success metrics.

6. Working hard

“You only do your job and clock out on time,” he said.

I was on a 1-on-1 with an ex-boss. I don’t remember if he brought up the names of coworkers who worked harder than me. Maybe he implied that in his feedback.

Funny thing is months later, when the Hunger Games of layoffs began, all those who worked harder were the ones leaving first.

Apart from working hard, there are other ways to stand out, of course while being in the right place. Do a good job and clock out on time.

7. Being passionate

I hate seeing “passionate” anywhere online. On job listings, CVs, and personal blogs.

What does passionate even mean? Working extra hours, arguing about code style on code reviews, or contributing to open source? I’m not sure anymore.

For me? All that passion faded away. I learned to diversify my sources of joy and stopped trying to only find fulfillment from a job.

I’m not passionate anymore.

8. Being a full-stack developer

I started writing WebForm apps, then web apps with Bootstrap and Knockout.js, then mobile apps with Xamarin.

Until I wrote my first REST API with ASP.NET Web API. I didn’t like the “pace” of the front-end ecosystem. Too many frameworks and “something.js” libraries. And too many issues about colors and alignment. It wasn’t my type of thing.

I stopped trying to become a “full-stack” developer. Often, that’s an excuse to hire fewer people and overwork others and pay low salaries. Sorry, but not sorry.

Mmmm…Well, now that AI is “taking” our jobs, maybe we all have to become full-stack developers. And maybe I’ll change my mind about this and write anoter post.

9. Being the best coder

I don’t want to be the best coder on a team anymore.

I believed cracking symbols on a page was the way to go. I’ve learned that the best coders stay coding. And there’s more than symbols on a file. The hardest part of software engineering isn’t the code, but “people and interactions.” And that’s where the real growth happens.

Starting out or already on the coding journey? Join my free 7-day email course and refactor your coding career–I distill 10+ years of career lessons into 7 short emails.

A Day in the Life of a Random C# Backend Engineer

2025-03-18T00:00:00+00:00

What exactly does a C# backend software engineer do?

These days, I found this question on Reddit about the type of tasks we C# developers do:

“Do you find them exciting or just routine? Do they help you grow as a developer? Or is it mostly about finishing tasks quickly, making small adjustments, and moving on? Curious to hear your thoughts!”

It’s 8:45. Time for the daily meeting.

You join the meeting. “Good morning.”

Then you look through the window, scroll on Hacker News, and check your phone while you wait for your name.

“Yesterday, I worked on the task to yada, yada. No blockers.” Yes, another meeting that could be an update on Teams or Slack or an email.

It’s 9:15. Time for a coffee.

You pick your next ticket.

Another pair of REST endpoints to power a screen on the web application. You come up with request and response objects. And you contact the front-end developer to share those two objects, so nobody is blocked while the endpoints are ready.

You come up with validations, entities, and value objects to populate your core domain. Yes, you’re kind of doing DDD. Write some tests. Fire up your Postman and see if everything works.

That was the writing part.

Now, the reading part. The web application uses a grid with dynamic filters and ordering. It seems like a task for dynamic SQL. But you’re too lazy to write SQL queries by hand. It’s 2025 and the world has ORMs. Life is too short to write SQL queries by hand.

You need to pass a list of IDs to a query. You could use a string and send the IDs separated by commas. Passing a table type is the solution. But…Surprise, surprise, your ORM doesn’t seem to support tables as parameters.

Noon. It’s lunchtime.

You step away from the screen to grab some food and give your brain a rest. At least, that’s the plan. But you can’t stop thinking about your task. “Why it isn’t working? What am I missing?”

When you’re back from lunch, you pull down the source code of your ORM and go down a rabbit hole. There’s no way you’re writing SQL queries by hand. Not today. “Here it builds the SQL query from the mapping object…“ Great. Progress. But still nothing. You keep going down the rabbit hole, determined to find the answer.

One method leads to another. One break point here and there. Until finally, you find it. “Here it is. This ORM uses a converter to populate the underlying DbCommand object. I could use that.” The solution is kind of hacky, but it works.

You write a converter and a simple test to prove you’re right. Then you port that converter to your Database project and add some docstring comments to document your hacky solution.

It’s almost 5:00 PM.

You’re tired from that debugging session.

But it was rewarding. You proved that sometimes being lazy means being efficient. By the end of your debugging session, you know a bit more about the internals of your obscure ORM. You have a trick you’ll use in future tasks. And you have an idea for a good blog post.

It’s time to create a pull request.

You slap a title, a description, and some good comments here and there to explain what you found. You change your ticket status on JIRA and ping the default reviewer for this project.

Time to unplug from work.

It’s 8:45 the next day. Another daily meeting.

This time, you don’t scroll Hacker News, but go directly to your PR.

As usual, one reviewer is suggesting renaming a variable. And you forgot to cover one or two lines. Yes, the official guideline is 100% coverage. Arrggg!

Some of your coworkers find out the trick with the converter. For the first time in a while, you get a compliment in one of your PRs. Yay!

That’s just one ticket. There are more. Hopefully QA doesn’t find any issues in the search logic. Fingers crossed, all the issues are “move this label,” “this textbox isn’t green enough… .” Nothing you have to care about being a backend developer. Your UI is Postman, and everything is working fine from there.

Everything because you didn’t want to write SQL queries by hand. Lazy? Maybe. Clever? Absolutely.

That’s why you chose backend development: the satisfaction of solving tricky problems. And that’s just another day in the life of a random backend engineer. Based on true events, because backend development could be boring, and yes, sometimes, a little wild.

For Any Creative Project, Volume Beats Perfection

2025-03-17T00:00:00+00:00

Volume always wins.

When we start a new creative project (writing, coding, or painting), we aim to create something “perfect” on our first attempts. And we wait for perfection before we share our work with the world.

The truth is, those first attempts will be crap. Our first posts, programs, and paintings will be crap. Well, 90% of everything is crap.

But the more we practice, the better we become, and the closer to “perfect” we get.

That’s a lesson I learned when binge-reading Herbert Lui’s blog the other day. I read about the pottery class experiment. One half of a pottery class was graded on quality and the other half on quantity. At the end of the course, the half who went for quantity did better and got better grades. They focused on experimenting, learning, and improving along the way.

The more tries we do:

We experiment more
We become more confident
We collect more data points
We build a larger body of work
We have more chances to succeed
We understand our audience better
We develop less aversion to failure
We have more material to repurpose
We gather more opportunities for feedback
We create more points of contact with our audience

For your next creative project, go for volume: write 100 blog posts, write 100 short programs, or do 100 paintings. And don’t be afraid of showing your work. The more you create, the closer you get to “perfect.” Volume always wins.

Domain-Driven Design Isn't Just About Entities and Value Objects

2025-03-16T00:00:00+00:00

What’s the first thing that comes to mind when you think of Domain-Driven Design (DDD)? Entities and value objects?

These days, I came across this question on Reddit about DDD:

I’ve been struggling lately to understand the idea and the reason behind Domain Driven Design. However, I have come up with the understanding that DDD is just the implementation of the core domain in Rich-Domain models, creating a ubiquitous language to make technical development easier, bounded contexts and design patterns like aggregates, value objects, strongly typed IDs and so on.

It’s easy to confuse DDD with using entities and value objects. But that’s not the point.

At a past job, I had the chance to use DDD in small projects. Every two months or so, we started short projects to improve a hotel management software.

In most of those projects we used, and abused, DDD.

Here are two examples where we abused DDD:

#1. We used it on a CRUD application to text guests upon arrival. The project got behind schedule, in part due to forcing DDD on a project with a tight schedule. From that project, I learned some good lessons.

#2. In another project, slightly more complex, but still not business logic heavy, we followed DDD by the book. Almost literally we followed this book. We ended up with too many layers and mappings between layers just to read data from the database. Arrggg!

If we judge DDD by using entities, value objects, and aggregate roots, in these two examples, we did DDD. But we overengineered a solution that we could have simply done with an n-tier architecture or commands and queries.

DDD isn’t about aggregate roots, entities, and value objects.

DDD is about collaboration and understanding.

It’s about collaboration between stakeholders and developers to create a shared understanding of the business rules. And it’s about expressing that understanding in a shared language. From product people in user stories to developers, all the way through the code, and up to table and column names.

Aggregate roots, entities, and value objects are mechanisms to encapsulate that understanding inside boundaries in the code.

We Write Code for Two Audiences—with Two Different Priorities

2025-03-15T00:00:00+00:00

“[Users] don’t care about your code—they care about results.”

That’s a controversial statement I found on this dev.to post. It got some virtual stones in the comments from “Clean Code” police officers. I used to be one too. I’ve changed my mind about it.

We don’t write code for the sake of writing code.

We write code to accomplish something for others:

Connecting them with loved ones in the case of Facebook, finding a romantic partner on Tinder, or getting a good and cheap room on Airbnb. Even for boring enterprise software, it’s about happier clients and more sales.

That’s what matters most to the users of Facebook, Tinder, Airbnb, and even boring enterprise software.

The other day, the VP of a software company I was contracting with taught me a lesson about Clean Code and other best practices:

“Clean Code is for us when we have to fix problems and deal with our own mess…users don’t care about that.”

It was a lesson I won’t forget, especially coming from a VP of a software company who had been a coder too.

We write code for humans. For two audiences: our future selves and end users.

Both audiences don’t necessarily intersect. Both audiences don’t care about the same things.

For us and our future selves, it’s about maintaining code quality to add new features and solve bugs.

For end users, connecting with loved ones, finding a romantic partner, getting a cheap room, and keeping clients happy and sales high. They care about what our code could do for them, not about the code by itself. Quality is there to support that mission.

How to Know When It's Time to Leave a Job

2025-03-14T00:00:00+00:00

I’ve stayed too long at stagnant jobs, and I regret it.

Staying too long at jobs cost me years and thousands of dollars. I left lots of money on the table. It made some of my skills get rusty.

But after connecting the dots, there were signs I failed to notice:

1. You’re not learning anything new

This is the #1 sign to look for. If your daily job becomes boring, that’s a sign. Or stay but diversify your source of joy.

2. There’s no room for growth

“You can build any role you want,” I was told.

That happened at a past job. I rejected the idea of being a team leader. I didn’t like how the role was designed at that place. It was a “wear all hats for the same pay” role.

And when I brought my ideas to the table, they got rejected with a “somebody else is already kind of doing that.” Staff Engineer? Software Architect? Right Hand? All of them.

It was a red flag I failed to notice.

3. It makes you sick

If your job makes you sick, physically or mentally, what other sign do you need? It’s time to take action. It’s time to run. Run, Forrest, run!

You can always get a new job, but not a new body.

4. You’re learning coping mechanisms

“OK, I just sent a message without a period at the end and without capitalizing the first letter,” my friend told me.

He was working from home and I stopped by for a coffee. In the middle of our conversation, he got a message from work and replied from his phone. There’s nothing wrong with that.

But to make sure his boss didn’t notice it, he didn’t add a period at the end of his message. Oh boy! I had just left that job no more than one year before that.

5. There’s no more money

The last time I heard “There’s no more money this year” when asking for a raise, the Hunger Games of layoffs started, until only a few ones were left standing.

I tried to convince myself I could stretch that job for another year or two. Wrooong! Eventually, layoffs knocked at my door too.

6. You have a bad boss

Often it’s hard to leave work stuff at work when going back home. A bad boss (whatever that means to you) will make you feel bad along with the people around you.

7. There’s no willingness to change

If after raising flags with your boss, you only hear “that’s fine. It used to be worse” or anything along those lines, that’s where change dies. Don’t waste more time bringing ideas.

Either you accept things the way they are or disagree with your feet.

8. It’s more important to find who to blame

If something goes wrong, it means there’s a flaw in a standard procedure or a process that let it happen. Finding who to blame only create a toxic work environment. Don’t waste time blaming. Fix the process.

From Brent Ozar, the SQL Server master, I learned that by the time we ask ourselves if we should leave, it’s too late. The best time to look for a job isn’t when you’re desperate. It’s when you don’t need one. Start updating your CV, reflect on what you truly want, and take control of your career. And don’t forget to read the fine print in job descriptions.

What I Learned From Watching Netflix's Six Triple Eight

2025-03-13T00:00:00+00:00

If we look at the world as creators, there’s content everywhere.

I put on my creator’s glasses and watched Six Triple Eight, a Netflix movie about the only battalion of American Black women in Europe during WWII.

Here are the storytelling devices I noticed:

#1. The story starts somewhere in the middle, not at the beginning of the events. It starts with a scene of a plane being shot down in the middle of WWII. Then, it takes us back to the days before that incident and builds from there.

#2. This battalion ran the mail operation for the troops in the frontlines. So we follow a letter covered with blood from the first scene all the way throughout the movie.

#3. Apart from delivering letters, it tells us other stories:

The story of Major Adams, the officer in charge of the battalion. Based on a real character.
The discrimination Black women faced inside the Army.
Lena, our protagonist, falling in love with the pilot from the first scene.

#4. It follows the problem/tension/climax/resolution technique:

It starts with the battalion facing an impossible mission (delivering the mail)
Being Black women in the Army, nobody believed in them.
They completed the mission ahead of time.
They earned the respect of the people who used to bully them.

#5. The entire story is told from the point of view of a single woman, Lena, our protagonist. Based on a real character too.

#6. Like any other movie inspired by real events, it wraps up with the real footage of the real Six Triple Eight battalion entering in Europe.

#7. The movie starts with a love story and ends with another love story. It ends the same way it started.

TIL: Caching Trolls You When Serving Images With Unchanged URLs

2025-03-12T00:00:00+00:00

Oh, boy! It took me like 3 hours to figure this out.

Here’s the thing: I had a CRUD app with Blazor. In the Update page, I could change images—let’s say, a hinge and other parts used to build a closet. Nothing fancy.

The problem?

After updating the image and redirecting back to the List page, it still showed the previous image. Whaaat?! The API endpoint did update the image.

Since I can’t show you the real code, for obvious reasons, here’s a little corner of the app,

After updating my image, it still showed the old one. Arrggg!

It only worked after pressing F5, to reload the entire page.

I tried to solve it by forcing a reload when redirecting from the Update page back to the List page. Like this,

private async Task OnSaveClicked(IBrowserFile? image)
{
    var response = await MyHttpService.HttpPut<SomePutResponse>("api/my-cool-endpoint", _someUpdateRequest);

    if (response != null && image != null)
    {
        await MyHttpService.HttpPostFile<SomeImageResponse>("api/another-cool-endpoint", image);
    }

    NavManager.NavigateTo(Index.Route, forceLoad: true);
    //                                 ^^^^^
}

But sometimes it still showed the old image. Arrggg!

After googling for a while, this SO answer saved my day. It was the browser trolling me all that time.

OK, the API endpoint powering the List page returned a public URL of every image, served from the same server. Every image file was named after the related object ID, something like /public-files/acme-corp/my-cool-object/123.png

Even though the backend changed the images, their URLs were the same. And the browser didn’t notice anything new, so it kept showing the same image, without requesting it from the server.

The solution?

Append a timestamp to every URL. Audit fields are helpful here…I ended up appending the modification date of every image. Like this,

public string GetPublicUrl(string path)
{
    var publicUrl = $"/files/{_companyName}/{path}";
    var modificationAt = GetLastModificationDate(Path.Combine(_someBasePath, path));

    return $"{publicUrl}?ts={modificationAt:HHmmssfff}";
}

private static DateTime GetLastModificationDate(string absolutePath)
{
    try
    {
        var file = new FileInfo(absolutePath);
        return file.LastWriteTimeUtc;
    }
    catch
    {
        return DateTime.UtcNow;
    }
}

Kudos to StackOverflow. Caching trolled me. Again. Total facepalm!

10 Tips to Write Posts (Technical or Not) People Can't Stop Reading

2025-03-11T00:00:00+00:00

I’ve written 321 posts.

In fact, this is my post number 322. Over five years ago, I wrote my first post. Well, “post” is a strong word. It was a word vomit. I still keep my first post unedited to remind me how I started.

I only wrote when I thought I had something to say. It was once every full moon when I started. Then it was every other week. Since Nov 1st, 2024, I’ve been doing it daily. I already passed the 100 daily posts mark. My next goal: the 200 mark.

My blog is my time capsule. And it’s done more for me than a portfolio. These days, it’s part of my routine to be healthy.

All that to say, I’ve learned a thing or two about blogging and writing. Mostly, after lots of trial and error. And if you’re starting out, here are 10 quick tips for you:

#1. Write descriptive headlines: “How to do X with Y in order to Z” works perfectly fine for most of your posts, technical or not. Or steal your headlines, like an artist.

#2. Ditch long intros: Go straight to your main point. Don’t worry about introductions at the beginning. I wanted to jump straight to #1 in this post. But in a moment of inspiration, I wrote that introduction to “prove” I know what I’m talking about.

#3. Start with a 1-sentence paragraph: OK, if you decide to write introductions, start your posts with one sentence. Imagine your first line is like an extra headline. See what I did in this post. I learned this trick from my first writing class.

#4. Use subheads: Use h2 and h3 tags to break your post into parts. These tags help readers skim and digest your post. And this helps SEO bots understand your post. If you’re writing a how-to guide, use one subhead for every step/lesson/point of your post…You know what, I could have used one h2 tag for every point in this post.

#5. Write shorter paragraphs: Shorter paragraphs and sentences make your posts easy to digest.

#6. Use simple words: A post isn’t a New York Times column or a school essay where you’re chasing an A+ or a 10.

#7. Deliver your message fast: It goes hand in hand with #2. Your headline is a promise. Fulfill your promise in your post body. If you’re writing how to fix the air conditioning of your car, tell that in your post. Don’t go on tangents. Leave those tangents to write more posts. Give something and give it fast.

#8. Avoid meta sentences: I blame writing in schools and their mantra: “tell readers what you’re going to tell them, tell the thing, then tell what you just told them.” Arrggg! Don’t do that. Don’t write “now, let’s cover how to…” or anything like that. I used to do that after every section. See #7.

#9. Write for 1 person: Next time you sit down to write, picture yourself explaining it to only one person: a friend, a coworker, or even your dog. It will give you the right tone to use and the right points to cover in your post. For example, again if you’re writing about how to fix the air conditioning of your friend’s car, you don’t have to explain what a car is to him. He already knows it.

#10. Avoid summary-like conclusions: Ditch conclusions the same way you ditch intros. And please avoid regurgitating everything back in a conclusion. Instead, ask your readers to do something after reading your post or promote other posts. Again see #2, #7, and #8.

I could give you more tips on SEO, but let’s keep it like that. If you followed these tips, especially #1 and #4, search engines will like you. Search engines love when we write for humans.

Keeping a blog helped me skip hiring lines the last time I was looking for a job. I showed my blog during the interview and the process went faster from there. No more rounds of interviews after that.

You don’t have to be an expert to write. Write to become one. But, please don’t start by writing your own blogging engine. That’s where blogging goes to die.

Always Automate Code Style (and Other Best Practices)

2025-03-10T00:00:00+00:00

At one of my previous jobs, there was a new guideline:

Format all SQL queries using right-aligned style.

The problem?

During a pull request review, one or two managers, who didn’t code anymore, decided on that guideline.

And the next day, without telling anyone else, that guideline was set in stone and enforced throughout the codebase. Guess what was the most common comment on code reviews since then? “Please properly format this SQL query.”

Lesson: Always share new guidelines and coding style changes with the team, especially if you’re planning on enforcing them on all projects. Just send an email or a quick Slack update to make sure everybody is on the same page. No need for an all-hands meeting.

The other problem?

There was no clear way to format those files. Should every coder do it by hand? Using their favorite tool? Or using an “official” tool?

Being a lazy coder, I didn’t want to format my files by hand. Copying SQL queries from Visual Studio, going to a tool page, pasting them, and copying them back was too much effort—I told you I’m lazy.

Computers are designed to do boring and repetitive work. Formatting files definitely fit that description. In one afternoon of frustration, I hacked a Git hook to format my SQL files and shared it with my team lead.

Lesson: Make sure to have an automated and widespread tool so anyone can follow new guidelines and coding style changes as easily as possible.

We wasted so much time on code reviews, asking people to format those files, waiting 24 hours to finally merge things.

For better or worse, my next project at that job didn’t involve SQL. And months later, I was let go…so I don’t know what happened to that guideline or to my tool.

9 Must-Know Tips for Your Next Trip or Vacation

2025-03-09T00:00:00+00:00

I’m far from collecting enough passport stamps for a world tour.

But, I’ve traveled abroad more than once. Thanks to coding, I saved enough to visit Spain and France before the pandemic. It was my final exam after studying French for a couple of years.

Here are 9 tips I’ve learned from those travels:

Always pack a jacket: Last time I was on vacation I visited a tropical country. Of course, I only packed shorts and swimsuits. But once I was thousands of feet in the air and inside a pressurized cabin, I was freezing.
Pack underwear and cleaning essentials in your handbag: In case, your baggage is lost or delayed. Better safe than sorry.
Visit your favorite destination first: For my travel to France, Paris was the last city I visited. By the time I got there, I didn’t have the energy to walk for hours and visit museums. I missed a lot of must-see places. And I didn’t truly enjoy the ones I visited. I was tired. Next time, I’m visiting my favorite destinations first.
Schedule a free day to wander around, sit in a park, go to a cafe, or simply do nothing. Often, we travel to rest and unplug but we end up exhausted from hours of walking, connecting flights, and museums.
Start with a walking tour: Often, they’re free. Or you can leave a tip at the end of the tour. And you have the chance to ask your tour guide for places to eat and hang around where locals go.
Bring eye masks and earplugs. Perfect for sleeping on planes or trains…And hostels can get loud sometimes.
If you’re crossing the Atlantic, from America to Europe, start your flight in the evening: This lets you get some sleep on the plane and arrive at your destination with daylight. It reduces the jet lag.
Wear pants that don’t need a belt and shoes without laces. It will save you a lot of time at security controls.
Keep your passport in your bag and only take it out at security checkpoints. Often there’s some stigma associated with our country of origin. I bet the first thing that comes to mind when you think of Colombia isn’t Encanto, just like Coco when you think of Mexico—both Disney movies. Keeping your passport in plain sight invites extra scrutiny from security personnel walking around airports.

10 Tips Every New Coder Should Know to Succeed

2025-03-08T00:00:00+00:00

I remember the first day of my first coding job.

It was over 10 years ago. I wore a long-sleeved shirt and fancy shoes. I brought a CD to install Visual Studio 2010. Yes, a CD. And yes, Visual Studio 2010.

After getting my corner and shaking hands, someone handed me a book. It was a book about SQL Server 2008. I read and googled for a couple of weeks until I got my first task. I was coming from Java and I needed to know C# in a few days.

My first task was to port a legacy ASP.NET WebForms app into a desktop app. I wrote Java code with C# keywords.

I had to figure out lots of things. Coding was the easy part. Everything else was the difficult part.

If you’re like me over 10 years ago, here are 10 tips you should know to succeed as a new coder—this is what I wish I knew back then:

1. Learn one basic coding skill

Learn to do one thing and do it well.

If you’re a frontend developer, practice turning a mockup into a webpage and calling existing API endpoints to make it work. Use React or Angular or whatever is the shiny thing these days.

If you’re a backend developer, practice writing API endpoints that validate user data, put it into a database, and read it back.

You’ll spend most of your time on those types of tasks.

2. Ask for help

When you get an error message (it will happen a lot), don’t simply send it over to a coworker.

Take the time to solve it on your own. Or at least, try. The first step? Google the same error message. Forget about AI for now. Only then, if you’re still stuck, ask a coworker, showing what you found and tried.

You’ll get more help if you show you tried rather than simply saying “help me.”

3. Ask questions

You’ll have to ask lots and lots of questions. Like a lot.

For me, everything was new at my first job. The coding part, the business domain, working on a corporate job…

Always ask why:

Why this task?
What’s the real problem?
And why solve it now?

It’s better if you annoy people with questions than with mistakes from not asking.

4. Find good role models and mentors

A good mentor will make a huge difference in your career.

But don’t simply ask, “would you like to be my mentor?” Everybody will tell you no. Being a “mentor” implies commitment, most of the time, for free. Find alternative ways to be mentored.

Often, books are your best mentors too. If only someone had written a book sharing his coding lessons…Wink, wink!

5. Be comfortable with the struggle

At the beginning, it sucks.

You feel like you don’t know anything. Everybody around you is way more competent. You go to bed while leaving something broken to wait for you the next day.

Take it step by step. It gets easier with time and effort. And the feeling of not knowing anything never goes away. You simply change the things you don’t know now with others.

Trust the process. The struggle is part of it.

6. Learn the right things at the right time

At the beginning, I tried to learn about everything at once.

I was into Python, learning C#, reading Clean Code, and keeping up with PHP…Lots of passion, without direction.

Coding isn’t simply one skill, but lots of subskills:

Language syntax
Problem solving
Databases
Development practices…

Tackle them one by one. Only move to the next skill once you understand one enough.

Remember you don’t need to know everything. And you don’t need to know everything at once either.

7. Learn to look for your own answers

University, bootcamps, and YouTube won’t teach you everything you need to know.

You have to read and study a lot. Like a lot! Nobody taught me about C#, version control, or unit testing…and on and on. I had to study them on my own.

Being a good coder also means being a lifelong learner.

8. Be willing to learn and follow instructions

As a new coder, you stand out by showing that you’re able to learn and follow instructions.

For example, when you ask for help (See #2), do or at least try doing what you’re being told.

9. Introduce yourself, network, and write CVs

It’s hard to land a job when you have almost 0 hours of flight time.

You don’t know many people. You don’t have much to show off on your CV. You have to resort to networking. Find clever ways to get an introduction.

Back in my day, I got my first job because I knew someone who knew someone. These days, I’d try starting with social media. Go with LinkedIn if you don’t know where to start.

And when you get an introduction, say you’re starting out and you’re willing to learn. See #8.

10. Real coding isn’t like University or bootcamps

In real life, often there’s no documentation, standard procedures, development workflows, or software methodologies.

Or it’s more like a zombie methodology disguised as Agile. And on top of that, the existing code is a mess. Welcome to coding in the real world!

(Bonus) My last piece of advice

Once you’re in a job, forget about the job description you read before joining. Learn and absorb everything you can, don’t be afraid to experiment. Embrace every opportunity to grow and challenge yourself.

When your current role becomes second nature, it’s your signal to move one for new challenges. Never stop learning!

If you liked these 10 tips, I cover similar tips (and others) in more depth in my book, Street-Smart Coding—It’s the roadmap I wish I had on my journey from junior to senior.

Change Starts in Your Mind, not Anywhere Else

2025-03-07T00:00:00+00:00

Hollywood often glorifies Navy SEALs portraying them as indestructible and focused men.

Jocko Willink, the guy from American Sniper, and the guys from Lone Survivor are all portrayed of them self-disciplined tough men.

But that’s not always the case. And this isn’t a story of a self-disciplined man.

His name is Taylor Cavanaugh, an ex-SEAL.

After joining the Military, Taylor’s life was a disaster. Bad decision after bad decision kicked him out of the military and led him to escape to France to join the Foreign Legion.

He tells his full story here:

And here are my 3 favorite quotes from his story.

“If you feel like it’s the happiest you’ve ever been, be very careful”

Taylor’s breaking point was after graduating from his military training.

It was partying and living “la vida loca” that got Taylor into trouble. It was the feeling of making it.

My breaking point wasn’t when I was making minimum wage at my first job.

No! It was years later when I was making the most money I had made as a software engineer. It was when I had won a “reputation” and felt comfortable at work. That’s when I got into trouble. I burned out.

And if we aren’t careful enough in those happy moments, everything that goes up has to go down.

“You cannot get healthy in the same place that makes you sick”

Often we can’t afford moving to a new place.

That’s what Taylor did to change his life. He moved to France to join the Foreign Legion. A military unit that accepts foreigners and give them a new name and life, no questions asked.

But we can change our environment without leaving home by:

cleaning our room,
working out,
making our bed,
eating healthy food,
ditching social media, and
going to bed earlier.

It took me months to start getting out of that burnout episode. But, it all started with a 5-kg dumbbell and a YouTube video to work out before showing up to work and with the type of content I was consuming online.

Move to another place or create the right conditions around you to flourish.

“Anything you do starts with self development”

Nobody is coming to save you.

It was a little voice in my head when I hit rock bottom that helped me to get up. “If you don’t get up by yourself, nobody is going to do it for you.”

I had to believe it was possible. I started to read inspiring books and YouTube videos. I had to watch stories from other who overcame similar situations in their lives. All that to believe I could do it too.

Change has to start in your mind first.

Parting thought

After overcoming his messy life, now Taylor is a life coach.

Me? Well, I took almost a year off to continue taking care of my health. I adopted a simple habit: ditching my to-do list and doing something for my body, mind, and spirit every day. Every single day, without excuses.

And that last quote summarizes Taylor’s journey through recovery—and my journey too. It all starts in your mind with your beliefs. Because beliefs turn into actions, actions into habits, and habits into change.

How to Better Organize Your Program.cs File in ASP.NET Core Apps

2025-03-06T00:00:00+00:00

If you’re not careful, your Program.cs file can become a mess.

It can turn into a long class full of methods and conditionals for every dependency to configure. We focus on the rest of our code, but often forget about the Program.cs file.

We could try extension methods to keep our configurations clean and organized.

But, these days, while working with a client, I learned an alternative to extension methods for keeping our Program.cs file tidy. A coworker showed me this approach. He learned it from a past job.

Here’s how to do it:

1. Let’s create an ASP.NET Core project adding Hangfire

Let’s create a dummy ASP.NET Core app. And to make it a bit more “complicated,” let’s add a lite Hangfire with one recurring job.

Here’s our unorganized Program.cs file,

using Hangfire;
using Hangfire.Console;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllers();

builder.Services.AddHangfire(configuration =>
{
    configuration.UseInMemoryStorage();
    configuration.UseConsole();
});
builder.Services.AddHangfireServer(options =>
{
    options.SchedulePollingInterval = TimeSpan.FromSeconds(5);
    options.WorkerCount = 1;
});
GlobalJobFilters.Filters.Add(new AutomaticRetryAttribute
{
    Attempts = 1
});

var app = builder.Build();
app.MapControllers();

app.UseHangfireDashboard();
app.MapHangfireDashboard();

RecurringJob.AddOrUpdate<ProducerRecurringJob>(
    ProducerRecurringJob.JobId,
    x => x.DoSomethingAsync(),
    "0/1 * * * *");

RecurringJob.TriggerJob(ProducerRecurringJob.JobId);

app.Run();

Nothing fancy. A bunch of AddSomething() and UseSomething() methods.

It’s already kind of a mess, right? Looks familiar?

2. Let’s register each dependency using a separate class

To make our app work, we must register controllers and Hangfire. Let’s do it in a new class called MyCoolAppUsingHangfire,

using Hangfire;
using Hangfire.Console;

namespace OrganizingProgramDotCs;

public class MyCoolAppUsingHangfire : BaseWebApp
//                                    ^^^^^
{
    protected override void RegisterConfiguration(IWebHostEnvironment env, IConfiguration configuration)
    //                      ^^^^^^
    {
        Register(new ControllersConfig()); // <--
        Register(new HangfireConfig()); // <--
    }
}

// One class to register controllers
class ControllersConfig : IConfigureServices, IConfigureApp
{
    public void ConfigureApp(WebApplication app)
    {
        app.MapControllers();
    }

    public void ConfigureServices(IConfiguration configuration, IServiceCollection services)
    {
        services.AddControllers();
    }
}

// Another class to register Hangfire
class HangfireConfig : IConfigureServices, IConfigureApp
{
    public void ConfigureApp(WebApplication app)
    {
        app.UseHangfireDashboard();
        app.MapHangfireDashboard();

        RecurringJob.AddOrUpdate<ProducerRecurringJob>(
            ProducerRecurringJob.JobId,
            x => x.DoSomethingAsync(),
            "0/1 * * * *");

        RecurringJob.TriggerJob(ProducerRecurringJob.JobId);
    }

    public void ConfigureServices(IConfiguration configuration, IServiceCollection services)
    {
        services.AddHangfire(configuration =>
        {
            configuration.UseInMemoryStorage();
            configuration.UseConsole();
        });
        services.AddHangfireServer(options =>
        {
            options.SchedulePollingInterval = TimeSpan.FromSeconds(5);
            options.WorkerCount = 1;
        });
        GlobalJobFilters.Filters.Add(new AutomaticRetryAttribute
        {
            Attempts = 1
        });
    }
}

MyCoolAppUsingHangfire has only one method: RegisterConfiguration().

Inside it, we register two classes: ControllersConfig and HangfireConfig. One “config” class per “artifact” to register.

Each config class implements IConfigureServices and IConfigureApp.

Inside each config class, we put what was scattered all over the Program.cs file.

3. Let’s look at BaseWebApp

Inside BaseWebApp, the real magic happens,

namespace OrganizingProgramDotCs;

public abstract class BaseWebApp
{
    private readonly List<IConfigure> _configurations = [];

    protected abstract void RegisterConfiguration(IWebHostEnvironment env, IConfiguration configuration);
    //                      ^^^^^

    protected void Register(IConfigure configure)
    {
        _configurations.Add(configure);
    }

    public async Task RunAppAsync(params string[] args)
    //                ^^^^^
    {
        var builder = WebApplication.CreateBuilder(args);
        RegisterConfiguration(builder.Environment, builder.Configuration);

        foreach (var configuration in _configurations.OfType<IConfigureServices>())
        {
            configuration.ConfigureServices(builder.Configuration, builder.Services);
        }

        var app = builder.Build();

        foreach (var configuration in _configurations.OfType<IConfigureApp>())
        {
            configuration.ConfigureApp(app);
        }

        await app.RunAsync();
    }
}

public interface IConfigure;
public interface IConfigureApp : IConfigure
{
    void ConfigureApp(WebApplication webApplication);
}
public interface IConfigureServices : IConfigure
{
    void ConfigureServices(IConfiguration configuration, IServiceCollection services);
}

RunAppAsync() looks almost like the content of a normal Program.cs.

But, it reads the services and configurations to register from a list, _configurations. We populate that list inside MyCoolAppUsingHangfire using the method Register().

After that change, our Program.cs file has only a few lines of code

And lo and behold,

using OrganizingProgramDotCs;

var myCoolApp = new MyCoolAppUsingHangfire();
await myCoolApp.RunAppAsync(args);

With this approach, we move every configuration artifact to separate classes, keeping the Program.cs clean and compact. Ours now has only three lines of code.

We could also use this approach to handle the Startup class when migrating old ASP.NET Core projects.

Et voilà!

Bring Out Your Writing Voice With This Simple Technique

2025-03-05T00:00:00+00:00

The biggest mistake all new writers make is trying to sound like a “writer.”

That’s because we’re more used to reading fiction. And we try to do the same. But we end up writing long sentences and using complicated words.

Instead of pretending to be a writer, write for a single person in mind. That’s what I do.

But these days, I’ve found another technique to bring out your inner and real voice out when writing.

It comes from Henrik Karlsson from Escaping Flatland. He wrote in Advice for a friend who wants to start a blog:

#4. People tend to sound more like themselves in chat messages than in blog posts. So perhaps write in the chat, rapidly, to a friend.

When we’re texting friends or family, we don’t use jargon, fluff, or long sentences. We use the tone we use in a face-to-face conversation. A text box inside WhatsApp brings your inner voice out.

The next time you sit down to write, open a chat with yourself and let your true voice flow.

10 Career Lessons I Wish Someone Had Told Me Before

2025-03-04T00:00:00+00:00

Over 10 years ago, I was fired from my first job.

I worked as an entry-level software engineer. I learned a lot from that job. I had to learn about coding and to make my way through the corporate world while growing my career.

Coding was the easy part. I had books, courses, and tutorials for that. But to survive the corporate world? Not so much. I had to figure it out on my own, with lots of trial and error, and yes, getting fired.

Here are 10 career lessons I wish someone had told me over 10 years ago:

1. Be ready to leave your job at any time

A 9-5 is never safe.

You could lose your job at any time for reasons you don’t control. Yesterday? A pandemic, global crisis, recession, and high interest rates. Today? DOGE and AI. Tomorrow? Who knows.

Be ready to leave:

Grow your professional network
Keep your “tell me about yourself muscles” in shape
Have an emergency fund to cover a few months of expenses

When you’re let go, you’ll have options, not just panic.

2. An online presence is your best CV and portfolio

CVs are so last century.

I wasn’t hired directly for my first job. I was hired under a staffing company. My salary passed from another couple of hands before getting into my bank account. Of course, they took a good chunk of it.

One day, I had to visit the office of the staffing company for some paperwork. Next to the main door, there was a sign: “Put your CV here.” It was a trash bin.

Well, the same type of receptacle offices used as trash bins. I guess it saved them the struggle of piling up and throwing away all the CVs from desperate people looking for a minimum wage job. They were already on a trash bin. That day, I knew the system was broken.

Ditch your CV and appear professionally anywhere online.

3. Pay raises won’t change an unfulfilling job

Vacations and pay raises won’t help you when you don’t want to get out of bed.

If Monday mornings are torture, or even worse, if Sunday evenings are also torture, you don’t need vacations. You need a way out of your job.

Trust me, I got burned out. And not wanting to get out of bed was the first sign I failed to notice. I learned it the hard way.

Find something that excites you to get up every morning.

4. Hoping and praying is a bad career strategy

Make a career plan and always have an exit route for every job.

OK, a career plan sounds like a lot of commitment, especially when we’re just starting. Let’s say, set an intention for your career. Do you want money, connections, recognition, travel opportunities, etc.?

Otherwise, society will give you its plan: work hard, get 3% yearly raises, please your bosses, keep your head down, then wait to retire.

5. Soft skills are more important than hard skills

Being good at coding, writing, or designing will give you a job, but being good at communication will give you promotions.

Your success depends on how good you are at communicating, managing, and coordinating people. I’m paraphrasing a lesson I learned from How to Win Friends and Influence People.

Work on your soft skills.

6. Detach your sense of meaning from your work

Being a “Senior Software Engineer” was my only identity.

My career was probably the most important part of my life. It was what gave me money and a sense of meaning.

Until I was laid off.

Suddenly, after one Zoom meeting, the title and the things I did with it were gone. It shook my world. That was the only thing I thought I enjoyed.

I had to learn I’m not a title. I’m more than a job. “Senior Software Engineer” was just a label I decided to accept. I was more than that.

You’re more than a job title.

7. Don’t be the only one doing something at work

It feels so good when you’re the only one who knows or does something.

But that’s a trap. Being the “only one” makes you a hero. And a hero can’t get sick, go on vacation, or be promoted. A hero is always stuck.

Don’t turn yourself into a hero. Teach, automate, or document what you only know or do.

Don’t be a hero. Be a team player.

8. Find mentors but don’t ask anyone to be your mentor

I put “Senior” in my title after one or two years of working next to the right people at one of my first jobs.

They taught me in just one year way more than what I learned in the next 5 years after I left that job.

A good mentor or role model can help you advance in your career faster.

But don’t ask anyone to be your mentor. Don’t drop the M-word. “Would you be my mentor?” That’s a strong ask. It implies commitment from one side more than the other. Often for free.

Find ways to learn from your role models without the M-word. Find not-mentors.

9. Two years is the tipping point for growth at a company

I’ve stayed too long at stagnant jobs and I regretted it.

I lost years, thousands of dollars an let some of my skills get rusty.

At one place, I stayed too long waiting for my chance. I tried to convince upper management I deserved a promotion. All the seats were taken. Every one of my ideas for roles was rejected. “Somebody is kind of already doing that.”

If after two or three years of doing good work, you don’t get a raise or a promotion, don’t wait any longer. You’re at the wrong place. Move on.

You’re leaving money on the table by staying too long at the same place.

10. You will be remembered by your attitude, not by your work

The long hours, the impeccable report, the great presentation. Nobody will remember them.

They will remember your answers in meetings, your willingness to help others, your treatment of clients.

Being easy to work with will pay off in your career. That’s the easiest way to stand out at work and to leave a lasting impression.

Remember, as Robert Martin said in the Clean Coder, “your career is your responsibility, not your employer’s.”

To Work From Home, You Need Clear Boundaries Between Work and Non-Work

2025-03-03T00:00:00+00:00

He said, “You have put boundaries around your time.”

I was on a 1-on-1 with my boss’s boss and not-mentor at a past job. He was right. I had boundaries around my working hours. I always clocked out on time, and sometimes even earlier.

On more than one occasion, my team leader texted me or called me at 4:50 PM sharing details of a task or a bug. “Sorry, but I can’t finish that today. It’s 10 minutes to my end of day and that will take me at least a couple of hours,” I always said.

Eventually he stopped calling me 10 minutes before my end of day.

The hardest part of working from home

I’ve worked remotely for over 5 years. The hardest part? Setting boundaries between working and non-working hours.

When you’re at an office, some boundaries are clear. It’s lunch time. Or it’s 5:00 PM and you see a line of people clocking out. The day is over. No more meetings. No more calls.

But from home, the line between work and non-work is blurry.

From home, we’re a couple of steps away from “work” and we’re wearing pajamas or no pants like any other time of the day.

And, if we don’t pay attention, we’re replying to emails and taking calls after hours. Or even working on weekends. Or thinking about work all day long.

How to put boundaries between work and non-work

To start setting back those boundaries between work and non-work:

Have separate work and personal spaces: Your work laptop is only for work stuff.
Turn off all notifications after working hours: No Slack or Teams or email beeps or buzzes after 5:00 PM.
Do something that signals the end of your working hours: Walk your dog, change clothes, or go to a different room.
Uninstall work-related messaging apps from your phone: No Slack or Teams or work email on the phone.

If you’re working from a different time zone than your coworkers, you don’t have to reply after hours, not even to say it’s already past your working hours. Reply the next work day.

And if you’re the one texting, start your messages with a disclaimer, something like “When you’re back online tomorrow: blah, blah, blah” or schedule your messages. And, please don’t send “hello, how are you” messages. That’s how you get ignored at work.

Remember, working from home doesn’t mean being available 24/7.

One Simple Trick That Will Make Your Virtual Meetings Smoother

2025-03-02T00:00:00+00:00

If you work remotely, this scene will feel familiar during virtual meetings:

Someone is talking, makes a little pause. Somebody else interrupts, then the first person starts talking. A pause. Then, a “you go first,” followed by a “no, no, no. You go first.” Then, both of them talk at the same time. Arrggg!

Here’s a trick to avoid that annoying situation:

Just like pilots or anyone using “single-channel” radio, pause for a few seconds after someone finishes speaking before you respond.

With this brief pause, you give time to the speaker to finish their chain of thoughts and wait long enough for the latency of getting the message on your side.

I Replaced Grammarly with This AI Prompt (Tested on Copilot)

2025-03-01T00:00:00+00:00

AI is here to stay.

We can’t ignore it. We can’t refuse to use it. We have to adapt, or somebody with AI will replace us.

I’m not in the “Never use AI” team. In fact, I already ran the experiment of launching a coding course with Copilot as my assistant.

But what I don’t agree with is using AI to replace my thinking and writing.

That’s why every single post you find here (or anywhere else online under my name) is written by me—a human, not an AI. #madebyahuman

Even though, I don’t use AI to regurgitate hallucinations, a veteran coder warned me about that the other day, I use AI to proofread and edit my posts. Here’s the prompt I use:

You’re an expert on writing and editing, show the grammar and spelling issues from the next text. Fix those issues, keeping the original tone. Bold all the words you change. Only the words. This is the text:

{add your text here}

Don’t rewrite it. Only fix the grammar and typos. Remember to keep the same tone and structure.

I tested it on Copilot. It should work on ChatGPT too. Give it a try and see if you can replace Grammarly with that prompt as well.

PS: I proofread and edited this post with the very same prompt. No robots were harmed in the making of this post.

What Frustrates Me the Most as a C#/.NET Developer

2025-02-28T00:00:00+00:00

C# has put a roof over my head and food on my table for more than 10 years.

At university, I learned Java. It was a relief coming from C/C++. Java didn’t have all the things I hated about C. I’m looking at you, pointers.

At my first job, I had to learn C#. The first program I wrote there was a Java program with C# keywords. Oops! Java was the only language I knew at that time.

I like C# and the entire .NET ecosystem. A typed language, multi-paradigm, with good tooling and stable support.

But here are the things that frustrate me the most about .NET:

1. Naming

Naming is one of the two hardest parts of Computer Science. And Microsoft doesn’t help that much.

On one hand, we have “.NET Core” renamed to “.NET”. Everything is .NET now. Was it a marketing strategy? Dunno. Probably.

On the other hand, target framework monikers. You know, the version number we put inside our .csproj files. For some time, they were .netcoreapp1.X, .netcoreapp2.X, and .netcoreapp3.X. But one day, they changed it.

I imagine a conversation somewhere on Teams at Microsoft like this:

Let’s change monikers too. Let’s also use .net plus the version number.
Wait, we can’t do .net4. We already have a .NET Framework 4.0. People will get confused.
Ok, let’s jump to .net5.

Arrggg! Microsoft and names.

2. Too many releases

It’s a good thing we have an evolving ecosystem.

I used to read all the release notes and tried to pick up as many new features as I could. Now? I only care about long-term versions. I don’t even pay attention to the short-term ones. Something somewhere is a bit faster on an architecture I don’t use at work. Sorry Microsoft!

Too many releases make it harder to keep up.

3. C# is getting too bloated

C# doesn’t feel like a single language anymore.

It feels like three languages: one pre-2010, one around 2010, and the one we have now.

I used to closely follow every new language release. Not anymore. C# as a language is getting less consistent. Too many options to create and initialize objects, for example.

Apart from nullable references and pattern matching and maybe some others I can’t remember now, it’s more and more syntactic sugar on every release. I’m only waiting for discriminated unions.

The worst part is features that look the same but work differently. Yes, I’m looking at you, primary constructors. They look like records, but surprise, surprise…They work differently.

public record ThisIsARecord(string ThisIsAPublicProperty);

public class ThisIsAClassUsingPrimaryConstructor(string ThisIsNotAPublicProperty)
{
}

This inconsistency makes the language harder to teach and learn.

4. AutoMapper

Ok, there’s nothing wrong with AutoMapper.

But what frustrates me is that, for some reason, we have adopted it as the de facto mapping library. And most of the time, AutoMapper ends up getting in our way.

Even AutoMapper’s author recommends not to use it if we’re mapping more than 80% of our fields by hand. But anyway, we use it even when we shouldn’t.

Just in the past weeks, I found two scenarios that got in my way, ignoring unmapped fields in the destination type and getting mappings flagged as invalid. Sure, I know I was abusing AutoMapper.

I wanted to add EntityFramework Core to this list, but I’m starting to feel the frustration in my stomach. Probably, I’m hungry. But, frustrations aside, .NET is still my go-to platform and C#, my go-to language.

Starting out or already on the coding journey? Join my free 7-day email course and refactor your coding career–I distill 10+ years of career lessons into 7 short emails.

The Most Important Skill To Learn In The Next 10 Years

2025-02-27T00:00:00+00:00

It isn’t writing, marketing, or social media.

With the possible threat of AI, there’s something else we must learn to future-proof ourselves.

This time, Devon Eriksen sat down to talk to Dan Koe. Devon is a software engineer turned author. But he considers himself a libertarian. Devon wrote Theft of Fire, a sci-fi book.

Here are 10 lessons I learned from watching that conversation:

1. Only slaves did one thing

In ancient Rome, only slaves were meant to do a single job for life.

Free-thinking men were supposed to learn on their own and do multiple things. We’re free-thinking men. We don’t have to do the same thing for life. Gone are the days when we have the same job for 40 or 50 years.

2. The most important skill to learn is agency

Agency is “the tendency to initiate action to achieve your goals.” Agency makes you willing to take risks and become resilient to failure.

3. Agency is a skill we can learn

To learn agency:

Start something new,
Learn as you go, and
Give yourself permission to suck.

4. The biggest risk to your agency is your limiting beliefs

We are our biggest haters with our self-talk: I can’t, I don’t know, and I don’t have.

5. We don’t need permission to create

We don’t need large TV networks, publishers, or media companies. The Internet has created a world without permission. We only need an internet connection and the desire to start.

6. Ask what is the purpose behind what you do

OK, purpose is a big word. Let’s say goal. Ask what you want to take out from what you do. What is your goal?

Be creative?
Make a living?
Connect with interesting people?

7. Don’t whine. Create something interesting instead

Stop blaming the Algorithm. Stop waiting to be lucky. Stop waiting for someone to choose you from the crowd.

Instead, show your work. Create something interesting to attract smart people because smart people have more money.

8. Money is a sign of f*cks given

Money is a by-product of your personal development and your ideas. The more people care about you and your work, the more money you’ll make.

“If you say ‘I don’t want a lot of money’ what you’re saying is ‘I don’t want a lot of people to give a f* about me’”

9. Don’t become a tool

You’re a tool when you only do one thing, like slaves in ancient Rome. Still remember #1? You’re also a tool when you attach your identity and self worth to that one thing.

That’s why AI threatens many jobs: when a faster and better tool appears it replaces slower and worse tools. Don’t be a slow and worse tool. Well, don’t be a tool at all.

10. Building an audience online is about being trust-worthy

“If you’re on the internet and that’s how you make your money, your product is you. Your ability to be interesting. Your ability to be informative. Your ability to be entertaining. Your ability to make something where people spend some time paying attention to it and they walk away saying ‘I liked that’.”

This was a liberating conversation for me. For a long time, I struggled to find my one thing. Doing one thing was scary to me. One day at a past job, in a moment of clarity, I wondered “Am I supposed to do this until the day I die?” Arrggg! Thanks, but no thanks.

But, like free-thinking men in ancient times, we’re free to learn. We’re free to choose our own goals. We’re free to do many things. We’re free to create.

10 Ways to Stand Out at Work—Other than Work Hard

2025-02-26T00:00:00+00:00

It took me two years to go from being just another developer in the room to sitting in meetings with the president.

It was at a past job. Sure, it was a small software company in my city. So small everyone knew who the president was, and he recognized everyone’s faces in the hallways. That was a point in my favor.

In my first years at that place, I was always behind: delivering my tasks late, staying after hours to keep up, and fixing bugs in my code.

And I wasn’t my team leader’s favorite team member.

It took me hours of studying and practice and hard work to prove I was more than a “problematic” developer.

But you don’t need to work hard, here are 10 ways to stand out at work:

Deliver your work on time. Not early, and definitely not late.
Document and automate your work. Don’t become a bottleneck. Don’t become a hero.
Ask for the context behind your tasks. Always ask why. Why this? And why now?
Get interested in the business side of your work. Understand how your work is helping the company make money.
Speak up in meetings. Ask questions and give suggestions.
Volunteer for the work nobody else wants to do. Make sure you can do it, or figure out how.
Give 10 ideas to improve the company, the product, or the work around you.
Be reachable during working hours, especially when working from home.
Be easy to work with. A.k.a don’t be an ass*.
Make your boss look good in front of their bosses.
Make sure every task you get is solved. Either because you solve it or follow up with the right team or person to solve it.

Ok, those were 11 ways. I know I said there would be 10.

But if I had to pick only one from that list, I’d go with #9: Be easy to work with. Invest in your soft skills or human skills. That’s the easiest way to stand out. People will remember you, not by your work, but by your attitude.

Refactor your coding career with my free 7-day email course. In just 7 emails, you’ll get 10+ years of career lessons to avoid costly career mistakes.

You're Not Writing Enough

2025-02-25T00:00:00+00:00

That was my favorite lesson from the book Writing for Developers.

We could always write more. I could have written more. I abandoned my blog for months back in 2023. I burned out and instead of doubling down on what I enjoyed, I abandoned it. Arrggg!

Content ideas and posts are everywhere.

Every bug fixed is a post. Every subject you’re learning is a post. Every time you struggle to figure something out is a post. Every job interview. Every performance review. Every promotion. Every book. Every mentorship session. They’re all posts.

The same way we read biographies to look for success clues, we could leave our own success clues in every post. We could build our own public time capsule.

From Just write by “Chasing Brains”:

Don’t over-engineer your site. Don’t even check the grammar. Just write 100 words and hit publish.

No matter if it’s a small bug fix or a career event, don’t create, but document.

If you’re interested in writing, read four lessons for a coder struggling to write and always write about what you do at work.

If a Veteran Is Skeptical About AI, We Shouldn't Worry About Our Jobs

2025-02-24T00:00:00+00:00

Pierre started coding back in the 60s and still maintains a 30-year-old codebase.

Thanks to the magic of the Internet, and to one of my posts going viral, I’ve exchanged a couple of emails with Pierre. I don’t know him in real life, just on the Internet.

His story has captivated me from the beginning.

I know only about a few industry veterans, and even fewer who are still actively coding.

Another of those veterans is Leslie at one of my past jobs. He was a Distinguished Engineer, a title created just for him. He was in charge of reviewing every single one of our PRs. He didn’t miss a single comma.

After going through every boom and hype, here’s a veteran’s take on AI

Since the 60s, Pierre has gone through every boom and hype in this industry.

He witnessed the Y2K panic, the birth of Java, the rise of Agile, and probably more that I don’t remember now.

In one of our emails, I asked Pierre about his take on AI. Today, we only see headlines of CEOs claiming AI generates most of their code, along with headlines saying coders are doomed.

But, here’s what Pierre, with his wealth of experience, told me about AI (slightly edited for brevity):

I’m skeptical about AI. I just don’t see automatically generating code from typical imprecise specifications…Apparently we’ve run out of Internet on which to train AI. It is now feeding on its own hallucinations, like mad cows eating their own prion-riddled offal, or the inbred Hapsburg dynasty.

If Pierre, who has seen quite a lot, is skeptical, we shouldn’t be worried. I’m not.

Pierre reminded me of that joke/meme that we’re still safe because AI needs unambiguous and well-written requirements. As long as clients who don’t know what they want exist, we’re still in business.

I don’t think AI is taking our jobs anytime soon. Sure, we have to adapt. AI is changing the landscape. For sure, coding in 2034 will look different. We can’t ignore it.

AI is like using calculators in math classes. They make us faster, sure, but they can’t do the thinking for us.

Knowing Is Teaching, but Also Reinventing the Wheel

2025-02-23T00:00:00+00:00

“What I cannot create, I do not understand.”

That’s one of the quotes on Richard Feynman’s blackboard at the time of his death. See the full picture here.

We truly have learned something when we can teach it. Feynman also said that we truly understand a subject when we can teach a beginner’s level lecture on that subject.

But that first quote reminded me of the famous mantra among programmers and coders: “don’t reinvent the wheel.”

Back in my first coding classes at university, one of my teachers taught us to write our own “Connection” class and use it wherever we go. We were learning how to connect to databases, probably using PHP or something.

Well, that wasn’t code reuse. That was reinventing the wheel and taking our reinvented wheel with us everywhere. We had ORMs in those days.

Reinventing the wheel is a bad idea. It only makes sense when learning to code or a new concept. Understand something, disassemble it, then recreate a simpler version. In fact, that’s the best way to learn coding.

The full quote should be “don’t reinvent the wheel. Only reinvent it to know how it works. Then use a real wheel.”

“You can only recreate what you understand” works in the other direction too. You only understand what you can recreate. You only understand the wheel you reinvent.

In Case of Writer's Block, Break the Glass and Follow These Prompts

2025-02-22T00:00:00+00:00

It took me almost half a day to come up with yesterday’s subject.

That was after claiming, a few days ago, that writer’s block is not the real problem. Well, it took me more than usual to mark the calendar yesterday, even after looking for inspiration in past posts and half-baked ideas. I ended up writing about one of my recent frustrations: Hourly billing.

In case you’re like me yesterday, struggling to find what to write about, here’s a list of prompts to help you write today.

Expand an old post.
Dissect a book passage.
Describe what’s around you.
Turn a 10-idea list into a post.
Write about your favorite quote.
Summarize your favorite podcast episode.
Write a letter to your past or future self.
Expand one of your comments on social media into a post.
Answer a question from Reddit, Quora, or any other forum.
Set a timer and write about whatever comes to your mind.
Open your browser history and compile the answers you found.
Scroll through YouTube or any other feed and write a reaction post.

Even if you don’t have anything to write, don’t miss two days without practicing. Your writing muscle will atrophy. And here’s a list of tasks for the days you don’t feel like writing.

I Stopped Listening to Free Advice and Started Doing This Instead

2025-02-21T00:00:00+00:00

Too much free Internet advice feels daunting.

I’ve gone all in on my writing skills since last year. And I’ve found all kinds of advice. Write daily. Don’t write daily…Use AI. Don’t use AI…Sell more. Educate more…Find a niche. Don’t find a niche…Do this. Don’t do that. Arrggg!

Not all advice is suited for everyone. Not everyone is at the same stage of the journey.

The other day, someone tried to sell me a course to optimize sales funnels, when I didn’t have anything to sell yet. Good advice, bad timing. The same happens with most advice we get.

Instead of taking advice from anyone and everyone at the same time, follow someone who has achieved the same results you want, listen, test, and adapt their advice.

Do Yourself a Favor and Stop Charging by the Hour

2025-02-20T00:00:00+00:00

“I have developers who charge me $18 per hour. Your fee is way more expensive.”

I was on the phone with my first lead, a small business owner looking for a software engineer. A friend connected us. I was trying to start freelancing in my local market. And if I got a yes, I was about to become the subcontractor of a subcontractor.

I gave him a flat fee.

I had already heard about the dangers of charging by the hour. I had watched a couple of YouTube videos and learned a sales script.

But on the other side of the phone, he divided my flat fee by the estimated hours to completion he had. And he tried to persuade me to give him an hourly rate and an hourly rate as low as the one he already had.

Hourly billing is nuts. Here’s why.

1. Hourly billing doesn’t encourage productivity.

The better I become at my work, the faster I do it. And if I charge by the hour, the faster I do my work, the less money I make.

Sure, I could raise my hourly rates, but that would put me in a race to the bottom. “I have developers who charge me $18 per hour,” he said.

2. What should I charge for?

There’s no clear line between billable work and non-billable work.

If I set aside my time for that client, but I’m waiting for his input, should I charge for that? While I’m thinking or doing research, should I charge for that? What should I charge for? Only for the time I’m typing symbols on a page? Arrggg!

3. Hourly billing invites micromanaging.

“Hey, did it take you X hours to do that? I have people who do that way faster! Let’s revisit your timesheet.”

And that’s how my freelancing coding business ended with one phone call. Do yourself a favor and don’t charge by the hour. I’ve forgotten that lesson and I regret it.

20+ Signs You're a Real Programmer (Using 2 Monitors Isn't One)

2025-02-19T00:00:00+00:00

Today I found a post claiming you’re not a senior software engineer until you work on a legacy app.

It made me think about when we can call ourselves programmers.

From me:

So, you’re not a programmer until:

You write a to-do app or a recipe catalog
You google how to become a better coder
You have an interview with a clueless recruiter
You copy and paste a code block from StackOverflow
You take down a database server with a badly written query
You read the Clean Code and want to rewrite all the code around you
You debug using Console.WriteLine or console.log or printf
You get a PM asking you how you’re doing more than once a day
You google your error message and find an open issue on GitHub
You delete a database table with a DELETE without WHERE
You argue about a variable name during a code review
You write a class Person when learning about OOP
You code a calculator app using JavaScript
You work on a full rewrite of a legacy app
You google how to center a div on a webpage

From my friends and ex-coworkers:

I asked some of my friends and ex-coworkers to complete that sentence. And here’s what they told me.

You’re not a programmer until…

You write your first “Hello, world” program
You stay awake until 3:00 AM solving a coding issue
You’re fixing an issue, it works and you don’t know why
Your code works on your machine, but not in Production
You get a compilation error on line 123 on a 40-line code file
You deploy a hotfix to Production at 17:55 (and you clock out at 18:00)

From dev.to:

I reposted this on dev.to and here are my favorites from the comments. (Slightly edited to make them fit in one line)

You’re not a programmer until…

You’ve programmed
You use git push --force --all
You say “Well, it works in Dev”
You have a folder of unfinished projects
You build a collection of most-used code snippets
You set your git username to “User” so they can’t blame you
You use git reset --hard or delete your local repo and clone it again
You start a blog to share your learning to save others debugging time
You’re stuck on a bug and your code works when you call a senior for help
You’ve spent time installing your favorite editor/IDE’s plugins and themes
You feel stupid by constantly trying to learn things you do not know what they’re for

And you’re not truly a coder until you grab a copy of my book, Street-Smart Coding: 30 Ways to Get Better at Coding.

OK, jokes aside, for so long I thought coding was only about cracking symbols. But I had to learn coding is a wide range of skills like surviving on-call rotations, talking to non-tech managers, and many more I included in my book.

Grab your copy of Street-Smart Coding here—That’s the roadmap I wish I had when I was starting out.

Being Helpful Isn't Always Good Advice, Try This Instead

2025-02-18T00:00:00+00:00

We all want to stand out at work.

We all want a place at the table, a voice in important decisions. OK, maybe not all of us, but it’s a good thing to be heard and known.

These days, while preparing my next Friday Links email, I found this post with 15 lessons from 15 years of coding. It has good advice and advice I’d take with a pinch of salt, like this one:

#6. Be Helpful First

Want to accelerate your career? Focus on helping others succeed. Thoughtfully review pull requests, ask your manager what they need help with, jump in when someone’s stuck, and freely share knowledge.

Sure, when you help, people notice you. Bosses notice you. And being noticed means salary increases and new roles.

But, be careful with being too helpful.

When you’re too helpful:

You miss your own deadlines and get into trouble.
You become the go-to person or a hero.

When you’re the go-to person, or the only one who does or knows how to do something, you’re a hero.

A hero can’t get sick, go on vacations, take time off, or be promoted. Because if you’re the only one knowing or doing, who’s going to know or do it while you’re out? You can’t leave.

A hero is stuck.

A hero gets phone calls in the middle of the night or on weekends. I don’t know about you, but I definitely don’t enjoy calls from work on my weekends. I don’t want to be a hero.

Instead of being a hero, be a team player.

A team player documents, automates, and teaches what they do and know how to do. A team player can leave at any time without worries. A team player isn’t stuck.

That’s a better way to stand out than being too helpful or a hero.

How to Become Time Billionaire

2025-02-17T00:00:00+00:00

True wealth isn’t just about money.

Apart from money, wealth also means health and freedom. Physical, emotional, and spiritual health. And freedom to choose to work on what you want, when you want, surrounded by people you want.

That was what Dan Koe and Sahil Bloom talked about during the next interview:

Here are 10 lessons I learned from that conversation:

#1. Not all time is equal. When you say “yes” to business or work, chances are you’re saying “no” to time with your loved ones.

#2. Imagine your funeral and ask yourself, who would be there? It might sound creepy, but start investing in your relationships. The simplest way to do that is by texting your friends when you remember them.

#3. Audit your calendar for energy creators and energy drainers. Find what makes you feel alive and what does not. Double down on your energy creators. And if you can’t avoid your energy drainers, batch them.

#4. Entrepreneurship is creating. It’s about finding a problem, coming up with a solution, and scaling that solution. And you don’t have to leave your full-time job to be an entrepreneur.

#5. Master storytelling and sales. Life is about sales. We’re constantly negotiating and selling, since we’re kids.

#6. Having a hard time niching down? Find something you’d stick to for 5-10 years.

#7. Question the things you “have” to. Question the default path. Create your own path.

#8. Define your enough life. How does your ideal day look like? When will you stop chasing the next step? The next promotion? The next milestone? What’s your enough?

#9. Use 30 minutes to 1 hour to create the life you want. If you can work 8 hours to make somebody else’s dream come true, you can work 1 hour to build yours.

#10. Have a Life Dinner with your partner or with yourself. Use that time to reflect and recalibrate.

“You’ll achieve more by being consistently reliable than by being occasionally extraordinary”

Better than being just a millionaire is to become a time millionaire, prioritizing what truly matters to you and living under your own terms.

Forget Writer's Block: Here's the Real Problem and How to Fix It

2025-02-16T00:00:00+00:00

Nothing is scarier than a blank page, but what if the problem isn’t writer’s block?

If you stare at a blank page with nothing to write, you’re not suffering from writer’s block, but from the lack of an idea-capturing system.

Here’s how to fix it.

1. Garbage in, garbage out

You are the food you eat and the content you consume.

Of course, if you’re mindlessly scrolling TikTok, you won’t have anything to write about.

Instead, be conscious of what you consume. Read more. Read fiction and non-fiction. Read anything that crosses your path. That’s your source of inspiration.

And apart from inspiring you, being exposed to good writing is the best way to learn to write.

2. Have a capturing system

Content is everywhere.

From comments in social media to quotes to TV shows to conversations to book passages. Everything and anything that happens around you is full of content ideas. In fact, this post started as a comment on social media.

Have a place to store and organize those ideas: Your phone, pen and paper, sticky notes, plain-text files, a stone and chisel. Anywhere.

Since last year, I’ve been following James Altucher’s Idea Machine concept. After consuming (almost) anything, I write 10 ideas or lessons I learned from that. Usually those 10 ideas become posts.

Notice content ideas around you and don’t let them go.

3. Don’t try to come up with anything original

There’s nothing new under the sun.

That’s from Ecclesiastes, from the Bible, from thousands of years ago. There wasn’t anything new back then. And there isn’t now. We’ve been adding, subtracting, and remixing ideas since then.

You don’t have to come up with original ideas to write. If you find somebody else’s idea (remember #2?), you can make it yours by sharing it from your perspective, along with a personal story.

Consume, capture, and remix ideas and you will always have something to write about. If you still think you have nothing to write, follow this tip. And no, you will never run out of ideas to write.

We'll Lose the Battle Against AI-Generated Content. Here's What to Do Instead

2025-02-15T00:00:00+00:00

“In the realm of…” “In the world of…” “In our fast-paced world”

AI-generated content floods the Internet. And it’ll only get worse as AI tools become better.

That’s not new. We’ve had mediocre content flooding the Internet since always with spam and posts playing SEO schemes.

I write on dev.to, and I still find posts full of keywords pretending to rank higher in the search results. SEO is dead. Well, that’s what everybody claims these days.

We have to choose our battles.

And we’ll lose the one against AI-generated content. Every day we have more and better AI tools that generate mediocre content in seconds. A 1,000-word post? Beep, beep, boop. Boom! Here you have it!

If you’re writing anywhere online, complaining about AI-generated content won’t do anything. Complaining in general doesn’t do anything.

From James Altucher, one of my favorite writers, I’ve learned that:

“If AI can write it, you need to rewrite it.”

If you want to stand out in an ocean of AI-generated content, you have to do what AI can’t do yet: add your personal touch, experiences, anecdotes, stories, and bad jokes. You have to make your content more human. You have to find your voice.

AI is going to kill mediocre writers, but it’ll make good writers stand out.

Writing For Developers: Takeaways and an Honest Review

2025-02-14T00:00:00+00:00

Like coding, writing is everywhere in software projects.

From README files to use cases to bug reports to blog posts. We developers spend as much time writing as coding, if not more.

Chances are if you’ve been stuck with an error for hours, some random guy’s blog post has saved your day.

Writing for Developers shows how to write those technical (or engineering) blog posts.

Here’s my honest review and key takeaways:

“You’re not writing enough” and other takeaways

#1. Technical blog posts don’t have to be boring.

They should have a balance between an interesting subject, a valuable lesson, and good packaging for the reader. And after reading your posts, your readers should leave with something learned.

#2. If you find a subject interesting, other people will find it too.

Write about anything you find interesting.

But if you’re writing for the first time and you’re not sure what to write about, remember 3 Ps:

what you’re passionate about
what you’re pained by
what you’re proud of

#3. We shouldn’t rely on AI to write our posts.

But, it doesn’t mean we can’t use it to critique or review our drafts.

Here are two prompts to critique our drafts:

“Are there any statements in this engineering blog post that do not seem adequately supported by facts?”
“Can you identify any parts of this article that seem less relevant to its main goal of [your goal]?”

My favorite lesson? “You’re not writing enough.” You can always write more.

My alternative “how to read this book”

Writing is not a subject you will learn from a single book.

It takes years to master it. And we, as developers, have a double challenge: putting words together and presenting complex subjects clearly.

If you’re new to writing, you will get more out of this book by reading the first two parts, especially chapters 4 and 5. They cover how to write and polish your first draft.

This book doesn’t answer where to write. It slightly covers how to do it in an appendix. If you’re writing for your company’s engineering blog, they likely have already sorted out those details. Hopefully.

Now if you’re not new to writing, let’s say you already have a blog and have published more than a dozen blog posts, you will get more out of this book by reading Part 3.

Part 3 covers 7 blog post patterns:

Bug Hunt
Rewrote it in X
How We Built it
Lessons Learned
Thoughts on Trends
Non-markety Product Perspectives
Benchmarks and Test results

Each chapter contains sample blog posts, a commentary on those posts, and an explanation of how to write each type of post.

That was my favorite part.

Definitely I’ve written some of those type of posts. But I didn’t think of them as patterns we could implement.

My final verdict? 3.8/5.

TIL: AutoMapper Only Considers Simple Mappings When Validating Configurations

2025-02-13T00:00:00+00:00

Oh boy! AutoMapper once again.

Today I have CreateMovieRequest with a boolean property ICanWatchItWithKids that I want to map to a MPA rating. If I can watch it with kids, the property MPARating on the destination type should get a “General” rating. Anything else gets “Restricted.”

To my surprise, this test fails:

using AutoMapper;

namespace TestProject1;

[TestClass]
public class WhyAutoMapperWhy
{
    public class CreateMovieRequest
    {
        public string Name { get; set; }
        public bool ICanWatchItWithKids { get; set; }
    }

    public class Movie
    {
        public string Name { get; set;}
        public MPARating Rating { get; set;}
    }

    public enum MPARating
    {
        // Sure, there are more.
        // But these two are enough.
        General,
        Restricted
    }

    [TestMethod]
    public void AutoMapperConfig_IsValid()
    {
        var mapperConfig = new MapperConfiguration(options =>
        {
            options.CreateMap<CreateMovieRequest, Movie>(MemberList.Source)
                    .ForMember(
                        dest => dest.Rating,
                        opt => opt.MapFrom(src => src.ICanWatchItWithKids
                                                        ? MPARating.General
                                                        : MPARating.Restricted));
        });

        mapperConfig.AssertConfigurationIsValid();
        //           ^^^^^														
        // AutoMapper.AutoMapperConfigurationException:
        // CreateMovieRequest -> Movie (Source member list)
        // TestProject1.WhyAutoMapperWhy+CreateMovieRequest -> TestProject1.WhyAutoMapperWhy+Movie (Source member list)
        //
        // Unmapped properties:
        // ICanWatchItWithKids
    }
}

It turns out that starting from AutoMapper version 10.0, only source members expressions are considered when validating mappings. And it’s buried in the Upgrade Guide here. Arrggg!

Two solutions: One for the lazy and the right one

Since I’m validating mappings based on the source type, I can simply ignore it:

options.CreateMap<CreateMovieRequest, Movie>(MemberList.Source)
	.ForMember(
		dest => dest.Rating,
		opt => opt.MapFrom(src => src.ICanWatchItWithKids ? MPARating.General : MPARating.Restricted))
	.ForSourceMember(src => src.ICanWatchItWithKids, opt => opt.DoNotValidate());
	// ^^^^^
	// Thanks AutoMapper, I'll take it from here.

It feels like cheating, but it works.

Or, I can use a converter:

options.CreateMap<CreateMovieRequest, Movie>(MemberList.Source)
	.ForMember(
		dest => dest.Rating,
		opt => opt.ConvertUsing(
                       // ^^^^^
                       new FromBoolToMPARating(),
                       src => src.ICanWatchItWithKids));

// And here's the converter:
public class FromBoolToMPARating : IValueConverter<bool, MPARating>
{
    public MPARating Convert(bool sourceMember, ResolutionContext context)
    {
        // Here's the actual mapping:		
        return sourceMember ? MPARating.General : MPARating.Restricted;
    }
}

Another day working with AutoMapper. It would have been way easier mapping that by hand.

For more adventures with AutoMapper, check How to ignore unmapped fields in the destination type.

What Happened Around This Day In My Blog

2025-02-12T00:00:00+00:00

A bit of nostalgia, reflection, and compilation today.

This is what happened, not today, but around this day in my blog:

Last year, before being laid off, I had just finished another short project with a contracting client. It was a project to support events, like weddings and conferences, in a hotel management software. That project taught me more about leadership and project management than coding. I wrote two lessons I learned from that project.

In 2023, I started a 4-part series on NullReferenceException with a post about when NullReferenceException is thrown and how to avoid it.

In 2022, I was still running Monday Links here. I wrote about Daily Meetings, Estimates, and Challenges. From that episode, I included a post I found with 5 signs to look for when it’s time to quit your job.

By the way, these days, I’m not running Monday Links, but Friday Links on an email list. Every Friday, you’ll get a 2-minute email with curated resources about programming and software engineering. Join here.

In 2021, I was working with a Stripe-powered payment processor. And I wrote about how to use the Decorator pattern to implement retry logic when sending payments to Stripe. The analogy I used to explain the Decorator pattern was IronMan wearing the HULKBUSTER suit.

In 2020, I used the Pipeline pattern to create a pipeline of steps to make reservations. And since I had already used it to create invoices and notes in an invoicing system, I decided to write about it.

In 2019 and 2018, I didn’t write in February. It’s a shame. Well, I was still trying to find my rhythm and what to write about.

Full Rewrites Are Bad But Be Ready For Them

2025-02-11T00:00:00+00:00

Rewriting legacy code that works isn’t a good idea.

At some point in the rewrite, we have to maintain two systems. Fixing bugs in the legacy one while making sure they’re fixed in the new one too.

These days, Antirez, Redis’ creator, wrote in We are destroying software:

We are destroying software pushing for rewrites of things that work.

Rewrites are expensive and time-consuming. Every rewrite starts with good intentions, but they all end up being the next application to rewrite.

Interestingly enough, I’ve been involved in full rewrites at every job I’ve had.

At my first job, I had to rewrite a WebForms app into a WinForms app. That was the solution to a networking issue. By the time I left (actually, I was fired), there was an ongoing project to unify every separate department application into a single “unified” platform. Another rewrite.

At my second job, similar story. A WebForms app backed by 1,000-LOC stored procedures. We rewrote it using ASP.NET Web API with NHibernate. But, by the time the president (a coder in a past life) found out that NHibernate was slower, he ordered another rewrite. A rewrite in the middle of another rewrite. It took us around five years to finish the first prototype of a working app.

My next job rewrite was from Python jobs to background jobs with ASP.NET Core. The idea was to read a database table with price updates for rooms at a hotel and call the Expedia or Booking.com API. The challenge? We couldn’t send two price updates for the same hotel at the same time. These days I’d use Hangfire for that.

Next job? Rewriting a VisualBasic WebForm app into Blazor. Oh boy!

You see? Chances are you can’t run away from rewrites and legacy code. And funny enough, “Working Effectively with Legacy Code” has been sitting in my to-read list all these years.

How to Start Selling Without Sales Calls

2025-02-10T00:00:00+00:00

To stand out, do what everybody else isn’t doing.

That’s a lesson I learned from Isra Bravo, Spain’s top copywriter, and maybe the country’s top solopreneur.

When everybody is doing sales calls, putting chatbots on their websites, or offering personalized demos, it’s time to stand out by doing something completely different.

This company ditched the “Book a call” button

Recently, I discovered Keygen, a licensing software and its no calls policy.

The founder, probably being an introvert, wanted to ditch sales calls and in a moment of frustration, he deleted the “Book a call” button from his company’s website.

Instead of sales calls, they improved their messaging. They clarified what their tool does and how much it costs.

And when someone requests a sales call, they simply reply:

“No, we don’t do calls, but happy to help via email. Feel free to CC any relevant team members onto this thread.”

Some of Keygen’s prospects loved the #nocalls policy. Too many calls are boring, draining, and time-consuming.

When you sell to the right people, you’re not leaving money on the table

Sure, they might be leaving money on the table. But we don’t want money from just anyone, only from the right clients. The ones that trust us, respect us, and pay the right price.

With a clear message and open pricing policies, we attract the right clients. We attract clients based on the messaging and the values we project. And that works for anything else in life.

#nocalls is an idea worth copying and stealing, especially if selling feels draining and if you prefer to think of in terms of helping, not selling.

Better messaging = more sales.

The Main Benefit of a Daily Writing Habit: 100 Daily Posts Reflection

2025-02-09T00:00:00+00:00

Imagine writing a blog post every day for over 20 years.

Seth Godin has done just that. A post a day for over 20 years means more than 7,000 daily blog posts. That’s more than impressive. I’ve always admired Seth’s blogging rhythm.

Inspired by Seth Godin and other daily writers like Tim Denning and Herbert Lui, I started writing daily on my blog in November 2024. I even created a new tag, /misc, for everything outside of software engineering and coding. That’s part of my strategy in these days of dead blogging.

For my daily writing challenge, one headline and one main idea are enough to call it a day. No cover image. No need for 10 points. If it’s longer than a tweet, it’s OK to publish. Around 200 words is my sweet spot.

A daily writing habit has made me more conscious of the content I consume.

When we set the intention to write daily, we start to see content everywhere: conversations, quotes, passages from books, podcast episodes, comments on social media, TV shows…“Oh, that could be a post, I’d better write down that idea.”

My goal was to publish 100 daily posts starting on November 1st. This is my daily post #100. Mission accomplished.

Often You Don't Want It, but You Become a Leader—By Omission

2025-02-08T00:00:00+00:00

One day, you’re the only team member and the next, you’re a leader, without asking for it.

Been there and done that.

Back in one of my first jobs, at some point, I was the only one in the mobile team.

We were building the prototype of a mobile app with Xamarin. I don’t know if that’s still a thing. When there was too much work for me, two team members joined from other teams. They were learning Xamarin and getting up to speed with the business domain.

And the next day, I started to be responsible for their work. Management asked me, not them, when they were behind schedule. I thought my job was only answering their questions and offering help. Nope!

I wasn’t a leader and I didn’t want to be one. But that day, I became their leader by omission.

And recently, it has happened to me again.

But this time, I was on the other side of the table. I joined a small agency and got assigned to a project with only one team member. He was a lone wolf, working on his own corner with zero dependencies and shared work. The challenge came when we needed to sync our work and keep an eye on dependencies between our tasks. He was so used to working alone, and I was expecting more collaboration.

When you’re the most senior member or the only team member, as soon as new pairs of hands come, you become the point of contact, the go-to person for questions and problems. Upper management starts to ask you about the new team members. You don’t ask for it, but you become a leader. A leader by omission. And remember as a leader, you’re not the best coder anymore.

10 Productive Tasks for the Days You Don't Feel Like Writing

2025-02-07T00:00:00+00:00

Like any other form of art, writing requires daily practice.

Seth Godin has been doing it daily for over 20 years. Daily! That’s more than 7,000 posts.

But I know, life throws us curveballs. Unexpected things happen. And some days, writing feels impossible. On those days, we feel like letting the chain break.

There are still writing-related tasks (that are not writing) we can do on those days. Here are 10:

Proofread and edit future posts.
Find cover images or create visuals.
Steal headlines, hooks, and opening lines.
Repost top-performing posts in social media.
Hand-write book passages (or posts) from your favorite writers.
Audit posts from past days: What headlines did you use? What type of visuals?
Collect your most liked comments and turn them into separate posts or headlines.
Tweak low-performing posts: Create new visuals, change headlines, or add new stories.
Turn long-form content into short-form content or vice-versa: Blog posts or newsletters into Tweets or LinkedIn posts.
Repurpose top-performing posts: Turn a blog post into a LinkedIn carousel or create quote images from it.

Even if you don’t write daily, at least do anything writing-related. But never miss two days in a row. Otherwise, like any other muscle, your writing muscles will atrophy.

Essential First Steps for Unit Testing in C#

2025-02-06T00:00:00+00:00

Today I got a question from Pierre on my contact page about unit testing. Here’s an edited version of his question:

I’m stuck at square one: how do you invoke the Unit Tests? Where are the tests stored? Are they compiled into the Release code? Is there one function that calls the whole cascade of unit tests? Nobody seems to address this very basic, indispensable first step.

I slightly covered some of those questions on my post to write your first unit tests with MSTest. I tried to write a beginner-friendly introduction to unit testing. But, Pierre is right. I forgot to answer those questions.

So here I go:

1. Are unit tests compiled into our Release code?

First things first. We don’t ship unit tests to our end users. And, no. They’re not compiled into our release code.

We write unit tests as part of our development process. Let’s say unit tests are code written for developers by developers.

The best analogy? Writing unit tests is like crashing cars as part of their security tests in a factory. Well, car makers don’t ship crashed cars. Unit tests are like those crashed cars. We use them to test the cars we’re shipping to our users, but don’t ship them to our end users.

2. Where to put our unit tests

The convention I follow is to put unit tests in separate projects, named after the project where the code under test is, using “Tests” as a suffix.

For example, if our code to test is under a project called Acme.CoolProject, we should put our tests into a project Acme.CoolProject.Tests. And inside the test project, we should use folders with the same name as the code under test.

Now about the folder structure to put our tests, I’ve seen and used two options:

#1. Using a src and test folders at the root of the solution, like this

Acme.CoolProject.sln
 |-src/
 |---Acme.CoolProject.Api/
 |-tests/
 |---Acme.CoolProject.Api.Tests/

#2. Using a src and test folders inside folders per project, like this

Acme.CoolProject.sln
 |-Api/
 |---src/
 |-----Acme.CoolProject.Api/
 |---tests/
 |-----Acme.CoolProject.Api.Tests/

From the two options, the first one is the most common and it’s my go-to folder structure.

For the actual tests names, I’ve found these four test naming conventions.

3. How to invoke our unit tests

There are three options to invoke our tests—Again, we as developers, are the ones who invoke tests, not our end users:

#1. Directly from your IDE: Testing frameworks come with test runners that discover and run our tests. So we can simply press a button inside Visual Studio or our IDE to run one test, all tests inside a folder, or all the tests inside our solution.

#2. From the command line: Thanks to .NET CLI, we can simply run dotnet test inside a folder to run all the tests inside that folder.

#3. From a deployment tool: If we’re using a continuous integration and deployment tool, like GitHub Actions or Jenkins, we can run our tests as part of the deployment workflow to make sure we’re not shipping broken code. These tools default to the .NET CLI to run the tests under the hood.

So there’s no one function that calls the whole cascade of unit tests, but a button on your IDE.

Et voilà! To read more about unit testing, don’t miss the rest of the series Unit Testing 101.

I’ve included these answers and more lessons in my book Start Testing. A step-by-step guide to writing your first C# unit tests with confidence.

5 Essential Lessons for New Bloggers from a Viral Post

2025-02-05T00:00:00+00:00

One of my posts recently went viral on dev.to.

It was the one about why we shouldn’t try to test private methods. And here’s the dev.to version.

When I say “viral,” I mean viral by my standards. It received +30 reactions, +30 comments, and +5K views. That was after two days of posting. Two days. It probably got syndicated or reshared somewhere else.

It’s not that impressive for tech influencers with a larger follower count. But it is for me.

Since I don’t want this to be a “see how cool I am” kind of post, here are 5 lessons I learned that I’d like to pass on to new bloggers:

1. You can’t predict your next hit

No matter how hard you try, you can’t predict which post will go “viral.”

Often the posts you write to mark the calendar are the ones that get some traction, not the ones you spend time crafting. This one was one of those. I wrote it to mark the calendar as part of my 100-daily-posts challenge I started in November 2024.

Since you can’t predict your hits, keep writing, even if you think nobody is reading.

I wrote that post originally here on my blog in November 2024. Since then, it only got less than 10 views.

But it went viral when I reposted it on dev.to. It was sitting on my blog behind search engines. I had to wait for search engine bots to crawl, index, and rank my post. And that could take weeks or months.

On social blogs, like dev.to or Medium, there’s already an audience and a discoverability feature. Old-fashioned blogs don’t have that. That’s the problem with blogs.

If you’re new to blogging or struggling to keep writing, don’t start on your own blog. Go with a social blog. If you don’t know where to start, try with dev.to.

3. Always promote something at the end of your posts

These days, I have learned from Spain’s top copywriter, that an email should be like a radio show.

A radio show has a bit of education, a bit of entertainment, and a promotion. And a post should be the same.

Promote something at the end of your posts: your ebooks, newsletter, or courses. I got 7 downloads of my ebook Unit Testing 101: From Zero to Your First Tests on my Gumroad page thanks to that post.

Promote something that aligns with the content of your posts. Share something of value, not just simply asking for a coffee.

If you don’t have an ebook or something, promote other posts. If Netflix does the same at the end of a movie or show, we can do the same.

4. Remember the 30/30/30 rule

My post got more than 30 comments.

Some people jumped to support my idea. Others jumped to offer interesting alternatives. Others simply said I wasn’t answering anything. Others went on a tangent talking about 3D rendering with JavaScript. Somebody else jumped to promote a jewelry business or something. Whaaaat! Yes, a jewelry business on a coding platform. Whatever.

No matter who you are or what you do, 30% will love it, 30% will hate it, and 30% won’t even care.

5. Answer questions in public

I didn’t come up with the subject of that post myself. I stole it.

One day I was wasting my time on Reddit, probably waiting on a line or something, and I found that question. I realized I could answer it and I did so.

It was a genuine question someone asked. Someone else will probably google the same question. And answering it was good in SEO terms for my blog. And that’s one of the tricks you can use to double your post count.

How I Made Money Coding and How I'd Do It If I Had to Start Again

2025-02-04T00:00:00+00:00

These days, I got a question from Venkata on LinkedIn. Here’s an edited version of that question:

I need your guidance on how to turn my skills into an opportunity to earn income by solving a real world problem or project.

Here’s my answer. Of course, this is free Internet advice. Take it with a pinch of salt.

I won’t tell you what to do. Let alone do I have a step-by-step formula. I’m telling you what I did and what I’d do if I had to start again.

I’m assuming you’re a new graduate from university or a bootcamp with a few years of flight time.

1. Take a tour of the corporate world

As crazy as it might sound, take a corporate job in a company in your city. Even if it’s at a boring non-tech company without a big name.

A boring job in a non-tech company is not the dream destination. I know. When we all start, we dream about joining the next rising startup or a FAANG. But you don’t have to stay in the corporate world forever.

In a corporate job:

You can get some training and learning opportunities.
You will learn to work with legacy codebases.
You can make mistakes on somebody else’s business with almost no consequences.

My first coding job was at a boring non-tech company. I had to learn about coding, deal with bosses and coworkers, and survive office politics. You won’t learn that at a university or a bootcamp.

If you choose this route, don’t try sending CVs like crazy to anywhere and everywhere. Use your network and try to skip hiring lines.

Don’t stay too long at a corporate job. Your skills will get rusty. Stay long enough to increase your hours of flight time before jumping somewhere else.

2. Get good at one skill and join a high-paying market

Once you have enough hours of flight time:

Get good at one skill: frontend development with React, backend development with .NET, or whatever skill you can put time and effort into learning.
Get good at a foreign language: Good enough to work professionally in that language.
Join a software agency and work for high-paying markets like North America or Europe: You can take advantage of currency strength between countries.

Based on your country of residence, you can make good money with this route compared to local markets.

3. Going on your own

Points #1 and #2 were like getting someone to feed you. This is like hunting on your own.

Find small businesses in your city and see how you can help them with automation. You’d be surprised how many small businesses and mom-and-pop shops run their daily operations with pen-and-paper or Excel.

If you choose this route, you can’t tell clients “I write HTML, CSS, and JavaScript. I care about Clean Code and I’m not a coder, but a craftsman.”

Sure, those are nice-to-haves. But that’s the lingo you and I understand. Small businesses don’t care about those things. They care about what you can do for them and their business.

You have to sell yourself in terms that your clients can understand. “I can help you implement a system that will cut in half the time it takes you to deliver your restaurant orders. Your clients will receive their food while it’s still warm.”

And don’t even think of writing code from scratch. Go with no-code solutions or easier ways for you to implement. Even installing existing software and training small companies on how to use them.

I’ve done #1 and #2. And if I had to start again, I’d try something like #3. Good luck!

Starting out or already on the coding journey? Join my free 7-day email course and refactor your coding career–I distill 10+ years of career lessons into 7 short emails.

How to Land a Coding Job in Post-Pandemic Times—The Untraditional Way

2025-02-03T00:00:00+00:00

Last year, I sent out over a dozen of CVs and cold emails within a month.

I was laid off. I went into panic mode. I applied to many companies. Anything with the word “coding” or “software engineering” in the job description. I even applied to a FAANG though I rejected that idea years ago.

But I just got radio silence.

2024 was a tough market. I know because I wasn’t the only one going through layoffs. The entire industry was. I even talked to an ex-coworker and he told me he had sent one hundred applications. I don’t know if he meant literally 100 applications or not. But I wouldn’t be surprised. He only got two or three positive responses.

Today I found a reflection on dev.to from a junior developer.

Last year, she finished a coding bootcamp or something and started to look for jobs. Oh boy! It must have been tougher for her. After the bat-soup and 2023, it seems nobody is hiring junior engineers anymore. And she tried the CV route.

CVs are dead. They’re so last century.

And sending lots of CVs won’t land you a job. Otherwise, someone with a printing business will find tons of jobs just by printing and mailing CVs. Well, sending CVs is a numbers game. Maybe out of 100 applications, you’ll get 2-3% of responses back if you’re lucky. Who knows!

Instead of CVs, I’d try an indirect approach to look for jobs:

Follow on LinkedIn, companies you’d like to work for and people (especially hiring managers) who work there.
Start genuine conversations. Ask how working there is and ask for referral programs.
If you use the company’s product, show up with ideas to improve the product. Or the company website or social media presence. Don’t simply send your CV with an “I do anything coding-related for money” attitude. That’s what I did with obviously poor results. And don’t appear desperate either.
Go through your network, asking if anyone knows someone working at a place where you could fit. Repeat steps 1 to 3. Or ask for an introduction.

I found my first job because I knew someone who knew someone at a company looking for coders. An introduction skipped the hiring line. And after being fired from that job, I found my next one through my network. I knew someone who knew someone.

If you’re standing in a hiring line or if your CV is on a pile physically or virtually, you’re already screwed. Don’t wait in hiring lines. Look for indirect ways to open doors and skip the lines.

Starting out or already on the coding journey? Join my free 7-day email course and refactor your coding career–I distill 10+ years of career lessons into 7 short emails.

Stand Next to Expensive Things: 10 Lessons from SQL Server Master Brent Ozar

2025-02-02T00:00:00+00:00

You don’t know where you will find him next. In a bathtub, a garage, an exotic beach in Mexico, somewhere in Iceland, or his office.

In every Office Hour, Brent shows a small glimpse of his personality and life.

I started to follow him for SQL Server advice. He’s maybe the SQL Server expert. In fact, I took his courses. But I ended up showing up to his Office Hours for career and consulting advice.

After watching Brent’s YouTube live sessions, here are 10 lessons I learned from him:

#1. Stand next to expensive things. Each SQL Server license costs around ~5k per core. Anything Brent charges for his consulting services is way cheaper than the licensing costs of an average server. Stand next to expensive things to charge premium rates.

#2. When planning your next workshop or course, start by writing the takeaway slide first. Then, create the rest of the content around that.

#3. If you ask “when is it time to leave my job?,” then it’s already time. If you wait for a layoff to look for a new job, it’s too late. The best time is when you don’t need a job

#4. If you’re planning to start consulting, start blogging and presenting months and years before to build your reputation. And always finish your presentations by saying “If you need more help, feel free to contact me.”

#5. Work on the smallest change that brings the most impact. This is something I learned from his Mastering courses. Often, we start to turn knobs and push buttons to make our SQL Server faster, without making any noticeable impact. The same applies to work outside the database work.

#6. Take a photo of you in your current work environment. That’s a future reminder of where you were and what brought you to where you are now.

#7. People follow you by who you are. Ok, Brent is opinionated and doesn’t restrict himself from roasting people in his YouTube live sessions. That’s one of the reasons people (and I) follow him. Authenticity.

#8. Impostor syndrome never goes away. The other day, I asked him how to deal with impostor syndrome. And hearing one of the top SQL Server experts saying he still feels like an impostor when working with clients was relieving. We’re all constantly learning and improving.

#9. You don’t have to be THE expert, you just need to know a bit more than the person you’re helping. This goes hand in hand with #8. It takes yeaaars to be the #1 in the world at anything, if you ever reach that point. But you don’t have to wait to be the #1 to start helping others and start making money.

#10. Build a brand so powerful that clients line up. Chances are that if you google anything related to SQL Server, Brent’s website will pop up. You’ll find him in YouTube, Twitch, and maybe TikTok. At this point, he doesn’t need to chase clients. He has a strong online presence. And it takes years to build one.

In my hometown, there’s a saying: build a reputation, then go to bed. Brent did that.

To learn how to make your SQL Server go faster with Brent—and support this blog—buy the Fundamentals Bundle here and the Fundamentals + Mastering Bundle here. I can’t recommend Brent’s courses enough. Learn from a real expert, with real queries.

I Learned a Mind-Blowing New Definition of Money. Here It Is

2025-02-01T00:00:00+00:00

Money means different things for different people.

For some people, money is:

A skill to master
A symbol of status
A ticket to freedom
An exchange of value
A game with levels to conquer
What we trade in exchange for time
A story we’ve been telling as a society
A differentiator between classes
A multiplier of our values
A mindset to practice
A social convention
The root of all evil

But, these days, watching Devon Eriksen, an engineer turned fiction writer, in an interview on YouTube, I learned a new definition of money.

He said:

“Money is a measure of f*cks given.”

If you want more money you have to make people give a f-ck about you. And if you say you don’t want money, you’re saying you don’t want people to give a f-ck about you.

Devon’s analogy dates back to our time as hunters and gatherers, when there was no concept of money as we know it today.

In those days, if you were a hunter, you cared (or gave a f-ck to follow the analogy) about the guy who polished rocks to make spears. And you two exchanged money in the form of products and value. Spears for meat or anything else. Caring meant exchange and exchange meant money.

Today we don’t trade goods or services, we have pieces of paper and figures on a screen. Create something people care about and let money roll in.

There's No Perfect Time to Start Anything—Start Now!

2025-01-31T00:00:00+00:00

Is there ever a perfect time to start anything?

Of course, no. “Perfect time” or “waiting to be ready” means never. And we will never be “ready” for anything in life.

Back in high school, we had two classmates who we all knew had a crush on each other.

And, as teenagers figuring out the new world of relationships, we all encouraged our classmate to ask his crush out. He always said: “Next month, I’m asking her out.” And then, the next month, he said: “Next month, I’m asking her out”. Then “next month…” and “next month…” He kept waiting for the perfect time.

“Next month” became never.

And it works the same for any creative project.

There’s no perfect time to start. You will never be ready. “Next month” means never.

So start that blog, start that YouTube channel, start taking those pictures, start that poetry book. You don’t need to be an expert to start. You don’t need to be famous. You don’t need to wait for the perfect time. You just need to start.

So why wait? Start today. Keep showing up and adapt as you go. The best time was five years ago. The next best time to start is right now.

Dear Junior Coders: Stop Chasing Shiny Objects

2025-01-30T00:00:00+00:00

“Focus on learning one thing.”

A coworker told me that every time he got to my desk. At that time, he was the IT/network guy. Years before that, he was a certified Java engineer or something.

I was new at this coding thing. I was trying to learn about everything at once. It was back in 2010ish. I was reading The Clean Code, learning Python, using C# at work (coming from Java), and watching PHP presentations in my lunch break.

Now you see why my coworker told me to focus.

Don’t chase shiny objects, go deep into fewer things

Instead of chasing new and shiny objects (like tools, libraries, and frameworks), juniors (and we all) are better off going deep into fewer tools and concepts.

Me 10+ years ago? “Oh there’s a new framework. A new C# version. A new CI/CD tool. Hey, what’s that new Hangfire thing over there?” Arrggg!

Frameworks and libraries come and go.

Today it’s React with Typescript. Before that, it was Bootstrap with Ember or Knockout.js. Before that, it was ASP.NET WebForms. Before that, it was Perl scripts or something. I wasn’t around coding at that time.

And who knows what AI will bring to the table.

But chances are we’ll be working on a C-type language, still using text files, and writing SQL. That hasn’t changed in ~50 years. And it will remain the same. I wouldn’t bet all my money though.

If you’re starting your coding journey, master the topics that have passed the test of time:

SQL
HTTP
C/C++
Data structures
Design patterns
Vanilla JavaScript
Clean code principles
Debugging and testing
Linux and operating systems

(Not all of them at once, of course.)

I don’t know what other subject to add to that list now. But you get the point.

And more importantly than spitting out code, master your soft skills: negotiation and persuasion. Coding is more about collaboration than cracking symbols on a file.

It took me quite a while to learn that lesson. And that’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding. It’s the roadmap I wish I had to go from junior to senior.

Get your copy of Street-Smart Coding here. Because coding is more than chasing trends. It’s about building skills that last.

Schedule Rest the Same Way You Schedule Important Meetings

2025-01-29T00:00:00+00:00

For the first time after over 10 years of non-stop work, in 2024 I suddenly found myself with lots of free time.

Thanks to the layoff in the tech industry and to fully recover from burnout, I decided to take a mini-retirement.

All of a sudden, I had 8 extra hours free on my day.

No more meetings, 1-on-1s, estimation sessions, or any other meeting that could be an email. I went nuts with that free time. Reading books, writing on my blog, reposting on dev.to and Medium, recording video courses, reviving my LinkedIn account, doing some freelance coding here and there.

I went to bed more tired than a full day of work. It felt so good. I was the master and owner of my calendar for the first time in years. Monday mornings didn’t feel the same.

But I realized I was chasing my ambitions.

The time that was supposed to be for rest and reconnecting with myself was as busy as the days when I had a full-time job.

Reflecting on this, I realized I need a change. I decided to start a new habit: Scheduling my rest time the same way I schedule important appointments on my calendar.

One day a week for one hour, I have a guilt-free time slot. I’m free to spend that hour doing whatever I want. The only rule is: zero work. Most of the time, I take a walk or read or watch a TV show.

We often are trapped in the productivity wheel that we forget rest is as important as active work, if not more important.

Rest time is the trigger for aha moments and bursts of inspiration. Often after taking a walk during my guilt-free hour, I have to rush to my computer to write something that came up while walking.

Remember to schedule your rest time too. You deserve it. And your mind and body need it.

10 More Practical Ideas to Instantly Double Your Blog Post Count

2025-01-28T00:00:00+00:00

Too much of anything is bad. Except for writing.

Here are 10 more ideas to write or blog more—I say “10 more” because I’ve already shared 2 ideas to write more:

#1. Write shorter posts. Instead of writing a 1,000 or 2,000-word post, write multiple 200 or 500-word posts and make them a series.

#2. If you write a listicle (“10 tips to …” or “10 lessons I learned from …”), expand some items in separate posts. I used this technique when I wrote about Choose Yourself Guide to Wealth and my alternative to to-do lists.

#3. Write tangents in a separate post. When you’re writing and notice you’re going on a tangent, don’t delete it. Use it as a starting point for another post.

#4. Turn your “cuts” into posts. When you’re editing or proofreading, don’t throw away the sentences or paragraphs that didn’t make it into the final piece. They’re ideas for separate posts.

#5. Update old posts in new posts. If the subject of a post has changed significantly since the first time, write an updated version and add an “update” disclaimer to the original one.

#6. Take notes publicly after finishing a book or listening to a podcast episode. I do this all the time. Just look at my books tag. You could summarize it, react to it, or collect your favorite quotes and tell stories around them.

#7. Answer private questions in public. Every time I get a message on my contact page or a private text message with an interesting question, I expand my response into a post. Of course, editing out anything that can’t be shared in public. That’s how I preserve my keystrokes.

#8. Answer Reddit, Hacker News, or Quora questions on your own post. When you find a question that you can answer, write your own “answer” post. I did this when I wrote about my life-changing purchases since 2020. That was a question I found on Hacker News.

#9. Turn old comments into posts. Review the comments you’ve left on social media and forums and expand your comments into posts. Especially use those comments that got good engagement.

#10. Steal topics from others. This is a variation of #8. When you’re reading something and you realize you could have written that post, stop reading and write your own. Steal the topic, but not the content. I did this when I wrote about the lessons I learned from The Almanack of Naval Ravikant.

There’s no bad consequence of writing more. Volume always wins.

My Blogging Strategy in Times of Dead Blogging

2025-01-27T00:00:00+00:00

Blogging is dead. At least, that’s what almost everybody claims.

And it’s been dead for years. But in spite of that belief, we still find (random and famous) people writing on their blogs: Seth Godin, Herbert Lui, and me (shameless plug).

With blogs, we have control but lose distribution

In our blogs, we aren’t at the mercy of third-party platforms and their algorithms.

A blog is a place you own. You can redesign it and write anything you want. It’s like your small kingdom. And I like to think of my blog as my time capsule.

But blogs don’t have a distribution mechanism.

Apart from search engines and cross-posting, there’s no “feed” for blogs. Well, there’s RSS, but you still have to find a blog in the first place to add it to your RSS reader.

Distribution is where social media truly shines. Unlike blogs, social media shine at putting content in front of readers. This means we can see traction way faster on social media compared to a blog sitting behind search engines.

But we don’t control our social media accounts.

A social media platform can change its rules at any time. Just take a look at Medium, everybody is complaining about getting lower payouts after a change in the algorithm.

Getting banned on social media is possible if you don’t behave.

Since 2024, I started to use my blog as my main hub for my content.

Ultimately, all my content ends up here on my blog in some shape or form. A single blog post ends up in multiple shorter posts for social media. And a short social media post can evolve into larger posts or sections. That’s my content wheel.

And I’m not only writing SEO-optimized 1,000-word posts about programming anymore.

Apart from coding and software engineering, I’m writing about my other interests. We’re not single-interest creatures. I’m not. I’m a multipotentialite. In fact, I created a new tag as a catch-all for my “other” content.

My new rule is that if an idea is larger than a Tweet, it can be a post.

When I cross-post on other platforms, I invite readers to my newsletter. And on every email I send, I promote two posts I write here and the products I’m building.

But if I had to start all over again today, I wouldn’t start with a blog. I’d go with a social media account and a newsletter.

Content Ideas Are Already There, You Just Need to Search for Them

2025-01-26T00:00:00+00:00

“Money has already been made, we just have to get out and search for it.”

That’s a common phrase in my hometown. It means money rewards action. And like I learned from hearing and watching James Altucher, nobody wakes up and thinks about giving money to any of us. We have to search for it.

That applies to content ideas too. Replace “money” with “content” and you’ll get the same meaning.

When we wear our writer (or creative) glasses, there’s content everywhere:

Books
Questions
Conversations
Emails you reply to
Projects you’re working on
Comments you leave on social media
Other people’s posts
Situations at work
TV shows

Everywhere.

For example, the other day I realized the same coworker had asked the same question about investing on a WhatsApp group. Then I wrote about it.

Another coworker asked me how to start writing on LinkedIn. Then I wrote about it.

Another day I was reading a book review. And I realized I had read the same book. I stopped reading and wrote my own review.

Another day I found a post I didn’t agree with. Then I wrote a reaction.

I felt guilty for binge-watching my favorite TV shows until I started to write about them. Now watching Netflix and TV shows is an excuse to write more content. Content is everywhere.

Missed the Last 10 Years of C#? Read This (Quick) Guide

2025-01-25T00:00:00+00:00

Here’s an opinionated catch-up guide if you missed the last decade of the C#/.NET/Microsoft evolution.

#1. C# isn’t JAVA anymore. That joke doesn’t work anymore. The two languages have taken completely different paths. They don’t even look the same.

#2. There’s a new runtime: .NET. It’s multiplatform and open-sourced. We have the classic one, we call it: .NET Framework, which you probably already know. And the new one was called “.NET Core.” But now, it’s simply “.NET” Yes, naming is hard.

#3. Speaking of the language, the main language features are still there. C# is an imperative side-effect-heavy language. But with every release, it’s adopting more features from functional languages, like lambda expressions, pattern matching, and records. (See #7)

#4. There’s excellent support for asynchronous methods with two keywords: async and await.

#5. There’s a whole lot of new small language features. Apart from async/await (from C# 5.0) we haven’t had a release with a single major feature. Most of the new features are syntactic sugar for existing features.

#6. There’s a new feature you shouldn’t miss: nullable references. It should have been called: “non-nullable references” instead. Do you remember nullable primitive types? Like int?? We allow a type to contain null by appending a ? when declaring it. We can do the same for classes. So Movie? m can be null, but Movie m can’t. And the compiler warns us when we’re trying to use a reference that might be null. Awesome!

#7. I compiled a list of C# features we should know about. Those are the features I like and have used the most.

#8. A “Hello, world” is now literally one line of code. We don’t need to declare a class and a Main method for console applications. Just write your code directly in a file like in a scripting language.

#9. I stopped expanding that list with the most recent features. C# is getting bloated with more features that are making the language less consistent. I don’t like that.

#10. The same way we have a new runtime, we have a new web framework: ASP.NET Core. It was a full rewrite of the classic ASP.NET. There’s no Global.asax, web.config, or files listed on csproj files. If you knew and used the old ASP.NET, I wrote a guide with the difference between the two. With .NET, we have way better tooling like a command line interface to create projects.

#11. Well, there’s Xamarin, MAUI, Blazor… But unless you’re planning to do front-end work, you don’t need to worry about them. Microsoft is still trying to find, create, and establish a golden hammer for the front-end side.

Sure, I’m missing a lot of other things. But you’re safe catching up on those.

TIL: How To Ignore Unmapped Fields in the Destination Type With AutoMapper

2025-01-24T00:00:00+00:00

Another day working with AutoMapper, another day with an edge case.

Let’s say we have class CreateMovieRequest with three properties: name, release year, and another property I don’t want to map, for some reason. And a destination class, Movie, with more properties apart from those three and names using a prefix.

Simply trying to use CreateMap<CreateMovieRequest, Movie>() won’t work. AutoMapper will warn you about unmapped properties in the destination type. “Unmapped members were found. Review the types and members below.”

Here’s how to map two classes ignoring the unmapped properties in the destination type and with prefixes:

using AutoMapper;

namespace TestProject1;

[TestClass]
public class IHateYouWilWheaton
{
    public class CreateMovieRequest
    {
        public string Name { get; set; }
        public int ReleaseYear { get; set; }
        public string IDontWantThisOneMapped { get; set; }
    }

    public class Movie
    {
        // These two aren't mapped from the source
        public int Id { get; set; }
        public int DurationInMinutes { get; set; }
        // These two have the 'Movie' prefix
        public string MovieName { get; set; }
        public int MovieReleaseYear { get; set; }
    }

    [TestMethod]
    public void IgnoringNotMappedProps()
    {
        var config = new MapperConfiguration(cfg =>
        {
            // Let's keep it here, shall we?
            cfg.RecognizeDestinationPrefixes("Movie");
            //  ^^^^^
            // To avoid explicitly mapping the fields because of the prefix

            // Before:
            // cfg.CreateMap<CreateMovieRequest, Movie>();
            //     ^^^^^
            // AutoMapper.AutoMapperConfigurationException: 
            // Unmapped members were found. Review the types and members below.
            // ...
            // Unmapped properties:
            // Id
            // MovieName
            // DurationInMinutes
            //
            //
            // After:
            cfg.CreateMap<CreateMovieRequest, Movie>(MemberList.Source)
                //                                   ^^^^^
                // To validate unmapped properties on the source type
                // Possible options: Source, Destination, and None			
                .ForSourceMember(src => src.IDontWantThisOneMapped, opt => opt.DoNotValidate());
                // ^^^^^
                // Since I don't want this one mapped for some reason
        });
        config.AssertConfigurationIsValid();

        var source = new CreateMovieRequest
        {
            Name = "Space Odyssey",
            ReleaseYear = 1968,
            IDontWantThisOneMapped = "Ok, if you say so"
        };

        var mapper = config.CreateMapper();
        var destination = mapper.Map<Movie>(source);

        Assert.AreEqual(destination.MovieName, source.Name);
        Assert.AreEqual(destination.MovieReleaseYear, source.ReleaseYear);
    }
}

The trick for prefixes is RecognizeDestinationPrefixes() and the one for warnings is passing any of Source, Destination, or None as a parameter to Map().

And to ignore an “incoming” property, ForSourceMember(), with DoNotValidate().

Et voilà!

You Don't Need a Published Book to Call Yourself a Writer

2025-01-23T00:00:00+00:00

Is it a best-selling book? A Pulitzer-winning novel? A large newsletter? More than 1,000 articles published anywhere online?

When can we call ourselves “writers”?

I have to confess I’ve been reluctant to use “digital writer” or “technical writer” or “writer” as a title anywhere online, even though I’ve been writing in my small corner of the Internet since 2018.

But recently, watching this interview with Devon Eriksen on YouTube, I changed my mind about using the title “writer.” He says:

If you’ve written and you’ve gotten paid for it. You’re a writer.

After hearing that, I wasn’t afraid to change my tagline on social media and here on my blog.

Definitely, someone has asked me to write something and paid me for that. That was by pure accident or luck, thanks to sharing the tutorials I write here on my blog. That’s how I made my first internet money.

You don’t need to publish a book. Well, publishing a book isn’t that hard these days. James Altucher has a strategy to publish a book in 30 days.

You don’t need to write and publish a book to call yourself a writer. Find one person that will pay to write and start calling yourself a “writer.” I’m a writer. And you?

TIL: Configure Default Values for Nullable Columns With Default Constraints in EntityFramework Core

2025-01-22T00:00:00+00:00

TL;DR: For nullable columns with default constraints, you have to tell EntityFramework the default value of the mapping property via C#. Otherwise, when you create a new record, it will have NULL instead of the default value in the database. You’re welcome! Bye!

Let’s create a dummy table with one nullable column but with a defualt constraint

Let’s create a new Movies database with one table called Movies, with an Id, a name, and a director name as optional, but with a default value. Like this,

CREATE DATABASE Movies;
GO
USE Movies;
GO
CREATE TABLE Movies (
    Id INT PRIMARY KEY IDENTITY(1,1),
    Name NVARCHAR(100) NOT NULL,
    DirectorName NVARCHAR(100) DEFAULT 'ThisIsADefaultValue'
);
GO

Let’s create a new record (without the nullable column) and read it back

Now to prove a point, let’s use EntityFramework Core to insert a new movie without passing a director name and read it back.

What will be the value of DirectorName once we read it back? Null? The value inside the default constraint? Make your bets!

Here we go,

using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

namespace TestProject1;

[TestClass]
public class EntityFrameworkAndDefaults
{
    [TestMethod]
    public void TestInsertAndReadMovie()
    {
        const string connectionString = $"Server=(localdb)\\MSSQLLocalDB;Database=Movies;Trusted_Connection=True;";

        var dbContextOptions = new DbContextOptionsBuilder<MoviesContext>()
                .UseSqlServer(connectionString)
                .Options;

        using (var context = new MoviesContext(dbContextOptions))
        {
            var inception = new Movie
            {
                Name = "Inception"
                // No director name here...
                // ^^^^^
            };
            context.Movies.Add(inception);
            context.SaveChanges();
        }

        using (var context = new MoviesContext(dbContextOptions))
        {
            var movie = context.Movies.FirstOrDefault(m => m.Name == "Inception");

            Assert.IsNotNull(movie);
            Assert.AreEqual("ThisIsADefaultValue", movie.DirectorName);
            //     ^^^^^^^^
            //     Assert.AreEqual failed. Expected:<ThisIsADefaultValue>. Actual:<(null)>. 
            //
            // Whaaaaat!
        }
    }
}

public class MoviesContext : DbContext
{
    public DbSet<Movie> Movies { get; set; }

    public MoviesContext(DbContextOptions<MoviesContext> options)
        : base(options)
    {
    }
}

public class Movie
{
    public int Id { get; set; }
    public required string Name { get; set; }
    public string? DirectorName { get; set; }
}

Ok, to my surprise that test fails. movie.DirectorName isn’t "ThisIsADefaultValue". It’s null.

I was expecting to see the value from the default constraint in the database. But, no. Wah, wah, wah, Wahhhhhhh…

Here you have it EntityFramework. Can I get my default value now?

We have to tell EntityFramework Core the default value of our column, like this,

public class MoviesContext : DbContext
{
    public DbSet<Movie> Movies { get; set; }

    public MoviesContext(DbContextOptions<MoviesContext> options)
        : base(options)
    {
    }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        // For simplicity, let keep it here...
        modelBuilder.Entity<Movie>(entity =>
        {
            entity
                .Property(e => e.DirectorName)
                .HasDefaultValueSql("ThisIsADefaultValue");
                // ^^^^^
                // Here you have it EntityFramework Core
                // Can I get my default value now?
        });
    }
}

This behavior only adds up to my love and hate relationship with EntityFramework Core.

Et voilà!

Starting out or already on the coding journey? Join my free 7-day email course and refactor your coding career–I distill 10+ years of career lessons into 7 short emails.

AI Is The Future And We, Coders, Have To Adapt

2025-01-21T00:00:00+00:00

AI is here to stay. We can’t deny that.

One day, will AI become self-conscious and try to exterminate us all? Who knows. That’s another discussion.

But we, as coders, have to adapt, as we always have, and adopt AI.

Today, I had a conversation with a group of ex-coworkers.

One of the members shared he was asked to finish almost an entire working app as part of a take-home coding challenge for an interview process at a startup. He was given only 5 hours. We all agreed that 5 hours wasn’t enough.

Someone else said he should have used AI. But he refused to use AI.

Maybe the intention behind that take-home challenge was to use AI and come up with a decent working prototype quickly. Who knows? Companies aren’t that clear with their interview process. And hiring is broken.

But we can’t refuse to use AI.

AI is here to make us more efficient.

What used to take days, now it only takes hours or minutes. By pressing a button, we compile thousands of source files in just seconds. Refusing to use AI is like refusing to use calculators or spreadsheets for accounting. It’s like refusing to travel by plane or drive a car.

These days when efficiency and productivity are rewarded, AI is a game-changer.

We can’t pretend to keep using punch cards and computers that fill an entire room. AI is the future. And we have to adapt. Coding in 2034 will change. But, one thing is certain: we can’t use AI to replace our thinking. We should be the pilots, and AI as our copilot.

Refactor your coding career with my free 7-day email course. In just 7 emails, you’ll get 10+ years of career lessons to avoid costly career mistakes.

Writing Isn't Something That Only Writers Do

2025-01-20T00:00:00+00:00

What’s the first thing that comes to your mind when you hear “writer”?

Probably it’s a starving artist isolated in a cabin, in the middle of nowhere, typing the next award-winning best-selling novel on an old typewriter, holding a cigar.

The truth is you don’t have to be a “writer” to write.

That’s the main lesson from “Writing to Learn” by William Zinsser. Here are five lessons I learned from that book—in five quotes:

1. “Contrary to general belief, writing isn’t something that only “writers” do; writing is a basic skill for getting through life.”

A CV, a cover letter, an email for a client, a request for time off, and a resignation email. What do they all have in common? Writing!

And that’s only thinking of an employee in a full-time job. But writing is everywhere else.

2. “Writing organizes and clarifies our thoughts”

If you want to check if you know a subject well enough, try to explain it and even better, write about it.

When you write you need a message, a chain of thoughts, and a reader persona. You need the right words and the right amount of them. The act of writing solidifies your understanding and shows you your gaps.

Writing is thinking.

3. “Writing is learned mainly by imitation”

Writers are readers too.

And noticing your behavior as a reader is your cheat code to better writing. Notice your favorite passages from the books you read, the posts you read until the end, the social media posts that make you stop scrolling. How did they grab your attention? What title did they use? Why did they make you read?

If you need a writing mentor, hand-copy your favorite writer and find patterns in their writing.

4. “The hard part isn’t the writing, the hard part is the thinking”

There’s writing to share information and writing to discover what we want to say.

When you write to share information, you need to ask yourself, “what do I want to say?” And when you write to discover what to say, you’re free to leave questions without answers and to build up from an answer you don’t have yet.

Either type of writing makes you think clearly.

5. “Non-fiction writing should always have a point: it should leave the reader with a set of facts, or an idea, or a point of view, that he didn’t have when he started reading”

Can this benefit one person?

That’s the best guideline to decide what to write. If it can benefit one person, you can write lessons, stories, rants, mistakes, questions, and predictions… Anything!

If it can benefit one person, you’re safe to write. And that one person can be your past self.

You don’t need to be an expert to write. Who’s an expert anyway? You don’t need to be famous either. Share what you have learned. Share what you’re learning. Share what inspires you. You don’t need to be a writer for that. Write! Probably the next time you’re Googling something you’ll find your own writing.

This Book Changed My Mind About To-Do Lists and Business

2025-01-19T00:00:00+00:00

Ideas are the new currency of the 21st century.

If you’re familiar with James Altucher’s work, you know about becoming an Idea Machine by writing 10 bad ideas a day.

But “Choose Yourself Guide to Wealth” takes the Idea Machine concept further, covering how to turn your ideas into reality.

Here are four lessons I learned from reading “Choose Yourself Guide to Wealth”:

1. Don’t do to-do lists

To-do lists are stressful.

Anything on a to-do list is something you haven’t done and probably never will do. In the meantime, it’s only causing stress.

I have items in one of my multiple to-do lists from years ago. I haven’t done anything about them yet. Oops!

Instead of to-do lists and goals, live by themes.

If you need inspiration to choose your own theme, follow the Daily Practice: Do something for your physical, emotional, spiritual, and mental well-being every day.

That’s the only rule I’ve followed since I read this book.

2. Become an idea machine

You don’t need chains to feel like a slave.

When you work on somebody else’s ideas, you’re a slave. Being an employee means working on somebody else’s ideas. Therefore, being an employee is being an idea slave, even if those ideas are good.

To be free and successful, come up with ideas every day. If any of your projects fail, come up with a list of ideas to improve it.

“I think of ideas for other companies who call me, and my ‘business’ is to help them implement those ideas on their own and become massive successes”

3. Be a good salesman and negotiator

To make others follow your ideas, you need to be a good salesman and negotiator.

But sales and negotiation aren’t about closing tactics or Jedi mind tricks.

We do business with people we like and trust. So you need to be friends with your buyers. You need to care about the same things they do. You need to sell and negotiate with people you love because a bad client can make you and the people around you miserable.

“One of the best ways of making friends and customers for life is to direct them to a better service or product than yours”

When in doubt, outsource your negotiation to the other side. “Hey, I’m new to this negotiation thing. I need your advice. What would you do if you were in my shoes?”

After a good sale, everybody should be happy.

4. Invest in yourself and in experiences

Don’t day trade or invest in mutual funds.

Have enough cash to sleep well at night. Don’t invest all your money in one place and only invest with people smarter than you.

Start your own business and invest in experiences and books.

Parting Thought

Ideas can change your life.

If you don’t know where to start to change it, work on your health. Start by writing ideas to improve your health.

In 2024, after burnout and a layoff, to get my life back on track I focused on my health by waking up early, working out, writing 200 words, and removing negativity from my life. I remember 2024 as the year when I was the healthiest.

Adopt your own Daily Practice. Ask yourself, “What I can do to keep my physical, emotional, spiritual, and mental bodies healthy?” and see how your life changes.

Stay Away From Controversy—and Other Life Lessons From a 102-Year-Old WW2 Veteran

2025-01-18T00:00:00+00:00

We all want to know what we know now but ten years ago.

That’s how this Reddit AMA felt when I read it. Len, a 102-year-old WW2 veteran, sat with his grandson to answer questions about history, WW2, and life in general. His grandson, who did the writing part, wanted to hear more of Grandpa’s stories.

These are my favorite answers and quotes.

“War Is Never Necessary. There Is No Such Thing as a Justified War”

Len served with the Canadian troops in the liberation of the Netherlands in 1939. Nazis were trying to reach Copenhagen.

After many years, Len has overcome traumas thanks to his wife and family’s support. But there are memories he can’t erase and, even to this day, he has bad dreams about it. He still remembers his service number – Eight-one-two-four-zero, by the way – and the D-Day is still vivid in his mind. He can’t even watch the landing scene from Saving Private Ryan.

[About D-Day] I just thought “I have a job to do”. Analyze the situation and react. If you stop, dig a hole. You don’t say “I think this is ok” you dig down deeper. Don’t go hunting for souvenirs in a minefield.

Someone in the comments shared the story of her young grandmother during those war times. She and her class learned and sang the Canadian national anthem to the soldiers. She even refused to wear a green hair ribbon to school because the Canadian flag was red.

“We had no idea that the Holocaust was happening. We saw three emaciated people walking in striped pajamas with big smiles on their faces. They had been liberated. That was the first time I learned about the atrocities that had been committed. In some of the media portrayals, this isn’t the case.”

“War should NOT happen. Surely there is a lesson. Don’t let it happen again.”

“Don’t Drink, Don’t Smoke, and Common Sense”

That was what Len answered when someone asked about what to do to live to such an amazing age.

His secret for a good life? “Non-smoker, non-drinker, and not necessarily following all the trends. Do your own thing.”

The higher we climb the mountain of life, the more perspective and the better view we have. From Len’s 102-year-old perspective:

A perfect day? “Waking up and being alive… A nice visit. A nice conversation with someone. And some tea.”

To enjoy each day to the fullest? “Surround yourself with people that you love. Take a minute to step back and see all the beauty around you.”

“People have forgotten the value of life. People focus too much on possessions and not the people and beauty that surrounds them.”

“During the Depression There Was NO Money”

Len has witnessed the adoption of cars, computers, and cell phones, but more shocking: he lived through the Great Depression.

Apart from pictures and history textbooks, we have no idea of an economic event of such proportions. Just last week (the first week of August 2024, if you’re reading this from the future), the US Stock Market fell between 10% and 20% and we called it “Black Monday” and were afraid of another recession. But here’s what Len shared when he was asked about the Great Depression:

“There’s no way of comparing that. During the Depression, there was NO money. I knew a man who hauled wood by horse to the school. A day’s work got you one dollar. We were okay, we had lots of vegetables and chickens. No use selling a cow because you would only get a dollar so you kept it for meat and milk. There is no comparison.”

Are You Scared To Die? –”No. It Happens to Everyone”

“If I could give myself advice I would say stay away from controversy. If something works stick with it.”

When asked what young people today should understand: “The value of life. Don’t louse it up.”

“T.V. is a pain in the neck. Interesting. Informative. Unnecessary.” Oh boy! I wished he had answered when and how he learned this one.

“Important: integrity and honesty. Unimportant: Money”

When asked about fearing death: “Not a bit. Lived a good life, what else do you want. No. Nothing wrong with dying.”

A 40-something asked about what waking up at 102 looks like: “Everything hurts, but I am not suffering.”

“Take care of your body. You only get one.” “Don’t smoke.”

This AMA was full of wisdom. But my favorite answer is when someone asked Len what he wanted to do when he grew up: “Happy.”

I can only imagine how fulfilled he has lived all these years to say at 102 he’s not afraid of death. What a wonderful life!

3 Lessons I Learned from Watching Two Millionaires Talk About Money

2025-01-17T00:00:00+00:00

Having too much money brings a different set of challenges.

That’s one of the takeaways from this conversation between two millionaires. It’s one episode of the “Deep Dive with Ali Abdaal.” This time Ali sat down with Andrew Wilkinson.

Here’s the YouTube episode if you want to watch it:

Ali Abdaal started medical school, then became a YouTuber, and since then has run an online education business. But I didn’t know about Andrew Wilkinson. Andrew went from barista to billionaire, coming from a middle-class family.

“I’m as Stressed as You Are”

For me, hearing Andrew say he was stressed too was one of the most shocking parts of that conversation — right at the start.

We might believe that money makes life easier. But from that conversation: it just brings a new set of challenges. We have to choose our own money adventure and when to stop.

This reminds me of a past boss.

He was a well-known entrepreneur in my city (and maybe in my whole country). He came from a wealthy family and ran more than a couple of successful businesses. But when he tasted the bat soup in 2020, there was no money to add more time to his countdown timer.

I guess money can’t buy certain things. For everything else, there’s a credit card. I’m stealing that from a TV commercial.

“Be a Financial Prepper”

Be paranoid. Only the paranoids survive.

During the conversation, Andrew shared he’s a prepper. Not in the sense of keeping a basement full of weapons, canned food, and gas masks ready for a zombie apocalypse. But in the sense of having multiple income sources.

“Be unbreakable financially”

In 2024, I had to internalize that lesson thanks to yet another round of layoffs in the software industry. I lost my main income source, a.k.a salary. I had other income sources, but not enough to cover my monthly expenses.

Robert Kiyosaki is right: “Build your asset column” and “Make your assets pay for your luxuries.”

I had to truly live it to learn it. Knowledge is only potential power unless put into practice.

“The best way to feel rich is to have cashflow”

Be the Sushi Master or the Chipotle Founder

Apart from the money lessons, my most important takeaway from this podcast episode is to:

“Design your life around your flow state”

We could choose to be the best sushi master of the world — worth a Netflix documentary — or the Chipotle founder.

One has mastered his craft to the point of perfection. Maybe he’s happy having only one restaurant and serving one smallish crowd. The other took a different route and created a reproducible business with thousands of locations, taking himself out of the equation.

That’s success seen from different perspectives.

Both of them followed what they enjoyed doing. Each followed a different adventure.

It sounds like the story of a businessman who ran into a fisherman taking a nap in a hammock under a palm tree. After a long conversation and giving a business plan for free, the businessman realizes that the entrepreneurial journey he was sharing with the fisherman will end with a nap in a hammock under the same palm tree.

In any case, follow your flow state and delegate things you don’t enjoy.

Towards the end of the conversation, Ali started to ask for advice to expand his own business. It was interesting to hear the business and money insights from a billionaire who came from the middle class. It wasn’t advice for everyone, but I took this last part:

“Sell something boring to a rich person. Don’t sell a complex product to cheap people.”

Never Run Promotions or Offer Discounts—Plus 4 More Lessons from Spain's Top Copywriter

2025-01-16T00:00:00+00:00

He went from unloading cargo trucks to being Spain’s best copywriter.

So far I’ve only been following English-speaking copywriters. I write landing pages for my coding courses in English. That’s why I hadn’t heard of Isra Bravo.

In a podcast interview, he shared his best lessons. You can watch the full interview here in Spanish. I only needed to watch that interview to start following his work.

You don’t need to learn Spanish to watch that interview. Here are my favorite lessons from that interview:

1. Never run promotions or offer discounts

Instead of trying to make more sales by lowering your prices, improve your product and get better at selling. Don’t do what everybody else is doing.

Instead of promotions and discounts, offer a launch price to your existing clients. They’re your best clients since they already bought from you.

2. Good Copy > Good Design

Good copy is more important than an outstanding design.

Isra’s most popular book, “I Write Because I Like to Make Money,” is an example of bad design with a good copy. Its cover doesn’t have bright colors or fancy fonts. It’s full of text with some bold sentences. It’s the type of book cover we would create in Microsoft Word with 0 design skills. But it reads like a good social media post or a persuasive email.

I Write Because I Like to Make Money. Via: goodreads.com

Here’s what it says:

“I write because I like to make money. And I teach thousands of people, who also like making money, how to do it. My name is Isra Bravo and in 2017 I unloaded trucks and was broke, but not anymore…“

Yes, that’s on the book cover. And I only translated the first part for you.

After hearing that and watching the most popular book from the best copywriter in Spain, I started to redesign my website’s homepage to remove visuals and have better copy.

Don’t get better at design. Get better at copywriting.

3. It’s easier to stand out on saturated markets

People are afraid of saturated markets.

YouTube is saturated. LinkedIn is saturated. Instagram is saturated… The whole world is saturated. But Isra teaches that it’s easier to stand out in saturated markets.

To stand out, you have to do what everybody else isn’t doing and make fun of your competitors in your copy.

By day, I’m a software engineer. And if you land on anyone’s coding website, everybody is passionate and codes the whole day for passion, except when they’re sleeping, but they dream about code too.

To stand out in the saturated market of coding, I’m changing my website’s copy to show my failures instead of my achievements—that’s what everybody is doing. Oh, I’m also saying I’m not passionate.

If you offer any kind of “done for you” services, don’t simply put on your website a bunch of logos of the clients you’ve helped. Everybody does the same. Instead, share a quick story of what you did for them.

Stand out by doing a good job, delivering it on time, and changing your copy to be different.

4. Never offer a lower price to new buyers

When you offer lower prices to new buyers, you’re betraying your current clients.

It’s the same feeling when we find out that a recently-hired team member is making a higher salary than us, who have stayed longer at the job and worked harder. Arrggg! We feel cheated and betrayed. Our clients feel the same.

Never offer a lower price than the one your current clients bought at.

5. Never offer too much value for free

People don’t value what they get for free the same way they value what they paid for.

Last year, as a therapy while recovering from burnout, I started to record coding courses. And I heard the advice to give away my course for free in exchange for testimonials. I did it. But I had to nearly chase my friends for a rating and a review. Some of them only logged in and never watched past the first lecture.

Always leave them wanting more in your copy, but never give away too much for free.

Learn to write and you will never starve again. With words, you can sell anything. Just remember, don’t run promotions or offer discounts.

There's Nothing Wrong With Coding Just to Pay the Bills

2025-01-15T00:00:00+00:00

I hate seeing “passionate” listed as a requirement in job postings.

How can we measure passion? Is there a quiz, like those magazine questionnaires? “Find out if you’re a passionate coder in less than 5 minutes with 10 easy-to-answer questions.”

The best coders I’ve met at past jobs weren’t what we’d call passionate. By passionate, I mean making open source contributions, speaking at conferences, and writing posts. They were busy enough making money.

We all start as “passionate,” but as time goes by all that passion fades away

The other day, Miguel, one of my readers, shared a similar experience. Here’s an excerpt of his email:

Personally, I’ve become discouraged in my programming career and no longer aspire to work at one of the most important tech companies. I just want to pay my bills and meet my family’s needs.

If you are in a similar situation, you’re not alone.

At some point in our careers, we all feel the same way. I know I have.

Probably, it’s because we’re problem solvers at heart, and companies confine us to cubicles and box us in with SCRUM and its ceremonies. And we don’t get to solve problems. Yes, “ceremony” is the right word.

When I started coding over 10 years ago, I dreamed of joining a big tech company like Google or Microsoft too. Sliding between offices, having a chef cooking our meals, getting a massage, riding a bike between buildings…

But, I realized big companies have their own challenges. More middle managers and more office politics. More of being a small cog in a machine. Even smaller cog and larger machine. They’re not the best place for everyone.

Code for money, do a good job, but don’t let your work be your only source of meaning

There’s nothing wrong with working at a coding job just to pay the bills.

We have to do what we have to do to put a roof over our heads and bread on our tables. If it’s coding, so be it.

But if we’re coding just for money, we should have hobbies, side projects, and other activities to find a sense of meaning and value outside work. Otherwise, the day job will become a burden. Trust me on this one, I showed up just for money and ended up burned out and sick.

You don’t need “passion” to be a great coder. It’s fine to code just for money and clock out on time. Do a good job, of course. But remember to build multiple sources of fulfillment and meaning outside work.

Five Eye-Opening Lessons I Learned from Being Fired from My First Job

2025-01-14T00:00:00+00:00

I was fired from my first job. 10+ years ago.

My first job taught me A LOT. I had 0 hours of flight time. Everything was new to me. I had to learn about the job and to navigate the corporate world at the same time. But I was fired.

Yes, fired. Not laid off. Fired. Same result, different cause.

Did I deserve it? Probably. Did I learn something? Sure.

Here are five lessons I learned from that:

1. You could lose your job at anytime

It’s obvious now. But it wasn’t 10+ years ago.

I was fired. But you could also lose your job for reasons you don’t control. A pandemic, a recession, or a layoff. Or your company gets acquired and extinguished. It’s outside of your control.

When I was in university, I thought being an employee was the safest route. Starting a company was for crazy people. I was sooo wrong. I only needed to be fired once to change my mind.

What’s truly safe? What you build for yourself: a side business, a rental property, or an investment portfolio.

Build something you can’t be fired from…Well, Steve Jobs was fired from Apple, so handle with care.

2. Job offers aren’t published anywhere

A couple of weeks after losing my job, I was interviewing for a small company in my city.

On the day I left, I had a conversation with my direct boss. Ex-boss, at that point. I don’t remember exactly what we talked about. I don’t know what he saw in me either. Maybe he saw his younger self across the desk that day. But he made a couple of phone calls and arranged an interview for me. It was a lucky day for me after all.

My first job wasn’t advertised anywhere. I got it because I knew someone who knew someone. And my next job wasn’t advertised either. Again I knew someone who knew someone.

Our world is moved by connections. By knowing someone who knows someone. Make an extra effort to build your professional network.

Your network is your most valuable asset.

3. Accept the rules or disagree with your feet

Talent and hard work aren’t shortcuts to avoid corporate rules.

There was a new rule at work. I didn’t like it. But I was naive to think anyone would ask me if I liked it and was willing to follow it. HR? My boss? My boss’ boss? Of course, nobody did.

I was wrong to believe my hard work would exempt me from that rule. Not following that new rule got me fired in the end.

A job is a game with rules you don’t control. And you have no voice when those rules change. Either you accept those rules or disagree with your feet. Trying to negotiate has no results. And not following them…well, now you know what happened to me.

4. Listen to your body, it might be telling you something

It sounds like a cliché. But listen to your body and look for small clues.

Don’t want to get out of bed to work multiple days in a row? Do Sunday evenings make you anxious anticipating next Monday morning? Your body might be telling you something.

At some point in my first job, I felt like I was leaving my life behind, sitting at a computer. I was demotivated and disengaged. My morning alarm was torture.

I didn’t listen to my body. I kept doing the same expecting change without doing anything. The next time I forgot to listen to my body years later, I got burned out and eventually sick.

Every time I need to make a change in my life, my body tells me when it’s time. “I feel it in my fingers…I feel it in my toes…”

5. Always have an exit plan

I jumped and left my first job with no plan at all.

By not making my own plan, I let society choose a plan for me: work hard, get promoted, and get a 3-5% raise every year. Wait to retire. Then, die.

Take a moment to find out what you want and value the most for your career. Money? Connections? Recognition? Growth? Then, choose the jobs and places that take you closer to that.

Don’t let others decide by going on auto-pilot. Have your own exit plan. Always.

Parting Thought

After many years, I realized my first job was a launching platform. It put me in the right moment, next to the right people. It started a chain of events that brought me to where I’m now.

At my first job, I learned some of my most valuable career lessons. The world isn’t what my teachers told me in university. I had to learn and figure out things on my own. I started my financial journey by making my first deposit into an investment account. I got my first real hours of flight time. I paid for a family dinner with my money for the first time.

After every ending, there’s a new beginning. Pastures are always greener on the other side.

Starting out or already on the coding journey? Join my free 7-day email course and refactor your coding career–I distill 10+ years of career lessons into 7 short emails.

I'm Answering the (Bear) Blog Questions Challenge

2025-01-13T00:00:00+00:00

I’m not pouring a bucket of cold water over my head, but I’m doing an Internet challenge.

I found it in Kev Quirk’s blog. And he found it on somebody else’s blog. But the challenge started on Bear Blog. Ava started it.

But since I don’t have a blog on that platform, I’m doing this challenge here instead. Just like Kev on his own blog.

Here I go:

Why did you start blogging in the first place?

I started blogging as an excuse to become a better coder.

Probably in the early 2010s, back in my first job, I googled “how to be a better developer.” And among the many options, I found “start a blog.”

Then, years later, at my second job, I didn’t want to throw away a couple of hours of Googling while looking for options to finish a task. And that’s how I started writing and blogging.

I already wrote about how I started my blog here.

What platform are you using to manage your blog and why did you choose it?

I use Jekyll on GitHub pages.

That was the easiest and cheapest alternative I found back in 2018. And, I spent a couple of days, or maybe a week, looking for the right template and theme to start.

Have you blogged on other platforms before?

No. I wrote my first online piece ever here.

But I’ve guest blogged on Exception Not Found and collaborated with two software companies to write on their Medium publications and official sites.

These days, I cross-post on dev.to and Medium. But my blog is my central hub. All my ideas in some shape or form end up here.

How do you write your posts? For example, in a local editing tool, or in a panel/dashboard that’s part of your blog?

I’m a plain text fan.

I keep all my drafts, posts, and ideas on Notable. I use a system of tags. I have one tag for post ideas. And once I turn an idea into a post, I use another tag.

Once a post is ready, I log into GitHub, create a new file, and paste my text there.

That’s how I blog in a nutshell. But here’s my blogging workflow more in-depth.

When do you feel most inspired to write?

Short answer: Anytime. But mostly, in the mornings.

I tend to write in the mornings. That’s when I feel the most productive and my energy is at its peak. I’m kind of a morning person.

But, I always have something to write. Inspiration can hit at any time.

It has happened that right after I put my head on my pillow, an idea comes and I have to rush to write it somewhere. Also, while taking a walk. That’s my trick to avoid writer’s block.

Do you publish immediately after writing, or do you let it simmer a bit as a draft?

No. I have a queue of posts. Right now, I have around 20 posts that are ready to publish.

I start my writing sessions by editing and proofreading my last post. Then I start writing any of my post ideas.

What’s your favorite post on your blog?

I’ve written around ~200 posts. I don’t have a favorite. Well, that’s what every mom and dad answer when they’re asked about their favorite child.

But if I could remove all my posts and keep a handful of them, I’d keep my series on Unit Testing.

Any future plans for your blog? Maybe a redesign, a move to another platform, or adding a new feature?

Seth Godin has always inspired me. He’s been writing daily for ~20 years.

And since November 1st 2024, I started writing daily about programming and other subjects. In fact, I created a new tag, /misc, to dump posts about all other subjects. My challenge is to write 100 daily posts. If I stick to my rhythm, I’m done next February 9th.

Chances are I’m keeping the daily rhythm after those 100 posts.

I’m too lazy to redesign my blog. I’m a black-and-white fan, so I’m sticking to the left pane. I’d like to add a scrolling bar and include more menu entries.

Oh! My own domain. I tried to buy one in the past. And I found out there’s a soccer player, a singer, and a director with my name.

I’d like to give Substack a try, but it would be for anything else apart from coding.

Parting Thought

I owe my career growth to learning foreign languages and writing.

Writing has opened doors for me. I made my first side income thanks to my blog. I skipped the hiring line when I applied to my last job.

In fact, I don’t have a coding portfolio. My blog has done more for me. Always write about what you do at your work. That’s better than an old-fashioned CV.

A Blog Has Been Better for My Career Than a Portfolio

2025-01-12T00:00:00+00:00

I don’t have a coding portfolio.

By portfolio, I mean a webpage showcasing my best projects. My GitHub account is the closest thing to a coding portfolio. But it hasn’t helped me land jobs.

My blog has helped me more. Here’s how:

1. A content collaboration

Some time ago, the next day after interviewing for a small local company, I got a phone call.

They wanted me to start a company blog for them. The interviewer read some of my blog posts. I had a link to it on my CV. He wanted me to write something similar for them.

I wrote five blog posts for them with interview preparation material. Even though I decided not to continue the interview process, I declared it a win. Also, I made some lunch money with them.

2. A smoother hiring process

Years later, the last time I applied for a job, in the first interview, I shared my screen and walked the interviewer through my blog.

The interviewer asked if I contributed somehow to the coding community. The process went smoother from there. I didn’t have any coding interview after that, except for opening a PR on an open source project. That was it.

Sharing your thoughts and learnings can open unexpected doors. Even if you don’t land new jobs, you’ll learn new skills. And more importantly, you’ll learn to think better. So write your first online piece and see what opportunities it brings. But don’t start a blog.

I'm Ditching My To-Do List: Here's What I'm Doing Instead

2025-01-11T00:00:00+00:00

I used to be a productivity freak with to-do lists.

At a past job, I had a notebook where I wrote down every single action I needed to finish. Small tasks, large tasks, meeting notes… Everything.

Later on, I became a plain text lover and kept my to-do list in a .txt file I edited with Notepad: a “todo.txt” file.

Same story as my notebook at my past job. Even worse. I had “todo.txt” files for work and non-work. One in my personal computer and another in my work computer. My to-do lists grew without control. I still have items in my “todo.txt” file from years ago. Oops!

But there’s something with to-do lists.

To-do lists are stressful.

Every item on our to-do lists is an item we haven’t finished and probably won’t finish either. In the meantime, they’re another source of stress.

I learned from Choose Yourself Guide to Wealth by James Altucher to ditch to-do lists and goals, and live by themes instead.

The theme I want to live by in 2025 is the Daily Practice: doing something for my mind, body, and spirit every day.

As part of my Daily Practice, I’m sticking to:

A glass of water after waking up
A workout session
A moment of silence
Writing 200-250 words
Coming up with 10 ideas
Getting rid of negativity

Few things have helped me change my life like the Daily Practice.

That Daily Practice helped me get my health and life on track after burning out. Focusing on my health brought clarity to my life last year.

Goodbye “todo.txt” file and hello Daily Practice. That’s my only rule for 2025. You should give it a try too.

If You Enjoy Coding, Think Twice About Joining the Management Track

2025-01-10T00:00:00+00:00

It took me 10 years to learn this lesson:

The higher up you go, the less it’s about coding and more about all other skills.

Being the best at coding won’t get you higher on the corporate ladder. Well, the corporate ladder is a trap.

Unfortunately, few places offer growth opportunities for coders, and even fewer for those who don’t want the management track.

Every place has its own expectations for team leaders or managers.

In some places, the team leader role is divided between:

someone technical in charge of coding and architecture decisions, and
someone non-technical in charge of project management.

In other places, a team leader wears all hats, often for the same pay.

Making the jump into a leadership role

If you enjoy coding and are thinking about joining the management track, start by understanding that your role as a team leader is more like a movie director than an actor.

Your job is not to appear on screen, except for some cameos. Your job is to make sure your movie gets done as expected and on time.

For that, you’ll need coding skills. Sure. But much stronger soft skills.

You’ll spend most of your time in meetings, not coding:

Daily meetings with your team,
Daily meetings with all other leaders,
1-on-1s with every team member,
Sync ups with project managers and product people

Once you understand you’re the director, not the best actor, show your interest in exploring the role with your team leader during your 1-on-1s or performance reviews.

Then, find easy and cheap ways to validate if being a team leader is a role you’d enjoy:

Organize and tidy up your project board
Cover your team leader during their vacation
Be the onboarding buddy for new team members
Coordinate efforts to complete a feature from requirements to deployment

That will force you out of your “coding” comfort zone into the soft skill-heavy zone.

As a leader, you’re not responsible for your own code anymore. You’re responsible for all other coders and the code they write.

Refactor your coding career with my free 7-day email course. In just 7 emails, you’ll get 10+ years of career lessons to avoid costly career mistakes.

Stalking a Writer Online Made Me Change My Reading Strategy

2025-01-09T00:00:00+00:00

I’m a recovered book addict.

Two years ago, I tried to read as many books as possible to show off my huge book count. But I didn’t remember much about those books, even when I took notes.

Ironically, it was another book, The Almanack of Naval Ravikant, that made me change my mind.

By pure accident, I discovered my new reading strategy.

Last year, for the first time, I discovered James Altucher.

I found his bankruptcy stories. I followed his idea of becoming an Idea Machine. I read some of his books. I loved his idea of the Daily Practice. And without even realizing it, I was stalking James Altucher online. Quora, Medium, his own website, YouTube… Everywhere.

By immersing myself in his work, I heard extra details about the stories in his books. I learned his book publishing strategy. I learned about the motivation behind some of those books. And I listened to way more anecdotes.

So, from now on, I’m immersing myself in a writer’s world by reading their books and listening to their interviews. It adds more context and depth to my reading experience. Yes, often listening to an interview about a book counts as reading the book itself.

As a Team Leader, You're Not the Best Coder Anymore

2025-01-08T00:00:00+00:00

Promoting the best coder to team leader is how projects go sideways.

I’ve seen it happen. One day, an executive pats the best coder’s shoulder three times. And the next day, he’s a team leader. No training. No expectations shared. Just a new title, a team, and lots of meetings.

That new leader continues thinking in terms of lines of code and pull requests, failing to delegate, pass context, and coordinate a team.

The next thing you know, the new team leader burns out and leaves the company. The project? Behind schedule and without a leader.

Being good at coding opens doors for leadership roles. But to shine as a leader, you need stronger soft skills.

You’re not the best player on the team anymore. Now you’re the team coach. You’re not supposed to be the fastest runner or the best at kicking. You’re supposed to manage a team.

Soft skills are way more important than coding because the higher up you climb the ladder, the less it’s about coding and the more about communication, project management, and team dynamics.

You Need Multiple Sources of Joy—A Job Alone Isn't an Option

2025-01-07T00:00:00+00:00

Diversify your sources of purpose and joy, the same way you should diversify your income.

Otherwise, if you lose your only source of purpose and joy, you’ll feel lost.

This happened to Vinay Hiremath, co-founder of Loom- the online screen recording tool.

After selling his company, he’s rich and has no idea what to do with his life. He wrote about it on his blog. All of a sudden the “co-founder of Loom” was gone.

With lots of cash but no sense of purpose, he went hiking, broke up with his girlfriend, went to the Himalayas, tried getting to Washington, and on and on. All in an effort to find a sense of meaning.

While I haven’t had an exit yet, I found myself going through something a similar situation.

I had my sense of value attached to my job. “Software Engineer.” For some time, that was everything I was and did… until I lost my job after a layoff.

All of a sudden I didn’t have the title. I wasn’t doing any coding. And I didn’t want to do any more of it. I felt trapped in a label I decided to accept on my own. “Coder” and “Software Engineer.”

During that forced time off, I took the opportunity to take care of my health, get back to my hobbies, and reflect on what I truly wanted in life.

I realized that, above all job titles, I’m a learner. Software engineering? It was just a stint of that.

If you’re in a similar situation,

Understand you’re not your job. You’re not a title. You are way more than that.
Find new hobbies outside work. Learn new skills just for fun. Read books from different fields. Practice a physical activity. Do something with your hands, away from screens.

Remember, your purpose and joy shouldn’t come from just one place. Don’t wait until you feel lost. Start today. Diversify your sources of purpose and joy.

10 Inspiring and Thought-Provoking Quotes About Life and Money I Collected in 2024

2025-01-06T00:00:00+00:00

Photo by Andrej Lišakov on Unsplash

I’m not a quote addict. And I don’t collect quotes for a living either.

These weren’t intended to be quotes. But they’re pieces of wisdom I noticed and wrote down when consuming content as part of my daily procrastination. Sorry, I meant catching up.

From James Altucher—Writer, entrepreneur, and investor

Last year, I stalked James Altucher. I read his books and watched his interviews. I found his story and writings raw and inspiring.

Money is a by-product of personal development

Money is only one part of an abundant life.

And your life is abundant when your physical, mental, spiritual, and emotional bodies are healthy. You’re abundant when you move your body, do something creative, share ideas, and live free of negativity every single day.

Little things show how people really are

It’s not the speeches, interviews, and business presentations. It’s how you treat a waitress, your coworkers, or the janitor.

Don’t do things you hate at the expense of things you love

It was when I tried to convince myself of showing up to work just for money that I got burned out. I tried to convince myself to take that money to build a runway for my side hustle. I was so wrong!

Have multiple sources of joy

When things go sideways in one area, you can jump to another and still find joy and meaning. Diversify your joy the same way you should diversify your income sources.

Taylor Cavanaugh—ex-SEAL and life coach

Anything you do starts with self-development

This one comes from a Navy SEAL turned into a French Legionnaire. The media has created this glorified image of SEALs like indestructible and focused men.

But this isn’t the case. Taylor’s life was a disaster. All his bad decisions led him to escape to another country.

After overcoming his messy life, now he’s a life coach. And that quote summarizes his journey through recovery. It all starts in your mind with your beliefs.

Seth Godin—Entrepreneur and writer

Big problems demand small solutions

You don’t go to bed and wake up with a dream life. It requires effort and consistency. And it starts with the desire to change and small simple steps in the long run.

Dan Koe—Writer

The goal is getting paid by being you

You don’t need to close your eyes and try hard to come up with a niche. You’re the niche. Your interests, vision, and goals make you the niche.

Make the content you want to see in the world

The internet isn’t saturated. Sure, it’s getting flooded with more AI-generated content every day. But we’re craving more genuine and human content. Create that.

Jim Kwik—Brain coach

A confused mind accomplishes nothing

In 2023, I burned out. It took me months to get back on track. I was so deeply rooted in my frustration and resentment that I couldn’t see a way out. It was only when I started to work on my health and change my internal voice that I found a way out.

Reading is the best exercise for your brain

Reading is the closest we are to plugging ourselves into a computer and downloading decades of information to our brains in seconds. Reading is the Neo’s “I know Kung fu” from The Matrix.

Ok, I said I’m not a quote collector. But I have to confess I have one or two quotes beautifully framed around my desk. Whether you hang quotes on your wall or not, what truly matters is turning that inspiration into beliefs, actions, and habits.

You Only Need These Four Books To Change Your Relationship With Money

2025-01-05T00:00:00+00:00

Photo by Annie Spratt on Unsplash

Money is one of the skills we have to learn by ourselves.

I didn’t have a class called “Money” in high school. And if you went to a regular high school like me, you didn’t either.

Like it or not, we live in a world run by money. And still, we don’t learn a thing about money.

What we know about money is what we absorb while watching our parents sitting at the dinner table discussing or arguing about money. And they learned about money by watching their parents too.

I felt the urgency to learn about money when I started to earn a high salary as a software engineer, higher than all my previous salaries.

The fear of letting money slip out of my hands led me to watch finance videos on YouTube. One video led to another one, and videos led to books.

If you want to start your money journey, start with these four books:

1. The Richest Man in Babylon by George Clason

If you want to only read one book from this list, read this one.

This book takes you to ancient Babylon and uses fables to teach you money lessons. It shows the power of stories. You will picture yourself in the middle of the desert, sitting in a caravan, listening to money lessons.

We don’t trade gold coins for food and live in cities enclosed by walls anymore. But you can easily translate the lessons in this book to our day and age.

If I could summarize this book in one sentence, it would be:

“Ask the jeweler for jewelry advice.”

Often we go to our friends and relatives with poor financial education to ask about money. That’s an expensive mistake!

Key Lesson: Pay yourself first and save 10% of your income.

2. Rich Dad Poor Dad by Robert Kiyosaki

This won’t be a complete list of money books if I don’t include this one.

It doesn’t matter if Robert Kiyosaki’s rich dad is real or not.

Again, the power of stories to share lessons. It tells what his best friend’s dad, the rich dad, taught the author and his best friend about money.

The rich dad taught them not to work for money but for experience and lessons. And the poor dad taught them to go to school, get good grades, and get a job.

“JOB is an acronym for ‘Just Over Broke’”

The lesson I remember the most from this book is the employee/employer dilemma. Employees do the minimum not to get fired and employers pay their employees the minimum so they don’t leave. They’re always in a conflict of interest.

Key Lesson: An asset puts money into your pockets and a liability takes money out of your pockets. To be truly rich, buy assets, not liabilities that look like assets.

Repeat out loud: if it doesn’t put money into my pockets, my car is not an asset.

3. Simple Path to Wealth by JL Collins

This book is a collection of letters and posts the author wrote to his daughter to teach her about money and the Stock Market.

The premise of this book is that some young people don’t care much about money, so they need a simple plan to build and preserve wealth.

This is the book that taught me about emergency funds. Well, the book called it “F*ck-you money.” Some savings to keep the boat floating when you don’t tolerate your job anymore and just want to tell your boss the big F-word or when the decision to leave is not yours.

Thanks to an emergency fund, I kept my family’s boat floating for months after an unexpected layoff until I found something else.

“[Before picking stocks], ask yourself this simple question: ‘Am I Warren Buffet?’ If the answer is ‘no,’ keep your feet firmly on the ground with indexing.”

The author is a fan of low-cost index funds and that’s the approach he teaches in the book. Stick with a total market index fund and invest regularly the same amount no matter what disaster or recession “experts” are forecasting.

Key Lesson: Stay away from debt, keep your expenses in check, and invest in broad index funds like the Vanguard Total Stock Market Index Fund ETF (VTI) and Vanguard S&P 500 ETF (VOO).

Against the author’s teachings, I have to confess I added a second fund on dividends to my portfolio. Sorry!

4. Psychology of Money by Morgan Housel

This one is less about the mechanics of saving and investing. It covers 20 lessons about money, all of them around the premise that money is a soft skill.

Money isn’t about rational decisions we make in front of an Excel file. It’s more about the emotional decisions we make at the dinner table.

The story I remember the most from this book is the one about the janitor who went unnoticed until he died, and his net worth was revealed. He was a multi-millionaire who donated part of his fortune to the local school and library. In his lifetime, he kept saving and investing his modest salary.

Key Lesson: Money is not what you can see: fancy watches and expensive cars. Money is the assets that haven’t been made into fancy watches and expensive cars yet.

Parting Thought

You could read more books and watch more YouTube videos. Some are more practical, others more philosophical.

But all of them have in common that money is a mindset and a skill we can master like any other skill.

Money isn’t evil. Money is what we decide to be. It’s a multiplier of our values. Remember: “If it’s in our heads first, it won’t be in our hands.”

I Got Laid Off and Recovered From Burnout in 2024. Here are 13 Lessons and Realizations

2025-01-04T00:00:00+00:00

Writing is free therapy.
Detach your sense of meaning from your work.
You don’t need to find a “passion” to succeed.
Working on your health brings clarity to your life.
You are not your job title. You’re way more than that.
Do what you can control and let go of everything else.
Stop chasing a fancy title. Optimize for a lifestyle instead.
Any change in your life starts in your mind with your beliefs.
Build multiple income sources right now. Your life depends on it.
Start and double down on what works. There won’t be a perfect time to start.
Eat to have more energy and think better. You are what you put in your body.
The right daily routine and habits can change your life. The wrong ones can destroy it.
Your health and well-being are more important than a job. You can always find a new job. But a new body? Not that easy!

If there’s one habit I’m sticking to in 2025, it is taking care of my body, mind, and spirit every single day.

How I Correct Mistakes When Practicing Foreign Languages

2025-01-03T00:00:00+00:00

It’s discouraging when a teacher corrects your mistakes in every phrase. It makes you want to stop speaking.

I’ve had all types of teachers:

The ones who cut you off in the middle of every sentence to correct you
The ones who write corrections on a whiteboard
The ones who don’t correct at all

We need the right balance when learning a new language.

If we’re not corrected, we keep making the same mistakes. But if we get corrected all the time, we lose confidence.

After taking many language courses and doing plenty of language exchanges, here’s my strategy for correcting mistakes:

Instead of cutting off your language partner (or student) in the middle of a sentence to point out a mistake, restate the sentence or ask a follow-up question without the mistake.

For example, if someone says “my brother don’t like apples,” you could say:

You mean your brother doesn’t like apples?
Why is that? Why doesn’t your brother like apples?

You’re correcting the mistake while keeping the conversation going and without discouraging the other person with too many corrections.

If You're Starting a Creative Project, Remember This Law

2025-01-02T00:00:00+00:00

90% of everything is crap.

And I’m not making that up. It’s Sturgeon’s Law.

That’s not discouraging. It’s relieving, at least for me.

It lowers our expectations when starting any creative project, like writing or painting, for the first time.

Our first posts, paintings, or pictures will be in that 90%

My first post was in the 90% of crap.

I wrote my first blog post back in 2018. And “post” is a strong word. It was a word vomit. I dumped a bunch of words into a document and published it online. I still keep that post unedited to remind me how I started.

My first LinkedIn post was in the 90% of crap too.

I made all LinkedIn sins possible in a single post:

Only an external link.
Hashtags and emojis.
No whitespace for readability.
Zero formatting for mobile devices.

The way out of that 90%?

Keep showing up and keep improving.

Think of every repetition, post or painting, like a small experiment. Small experiments give you room to explore, to break the rules, to see what happens. If an experiment failed, you’ll always have a new experiment the next day.

How do I know I’m improving?

If you find your first repetitions cringe-worthy, you’re improving.

If, after months of repetitions, you don’t cringe when going back to your first posts or paintings, you haven’t improved much. You need to do more experiments.

90% of everything is crap. That’s encouraging. We only need a bit of effort to get ahead of that 90%.

Best of 2024: My Year in Review

2025-01-01T00:00:00+00:00

If I had to define my 2024 in one word, it would be: Change.

In 2023, I got burned out and sick. And when I was laid off in early 2024, I felt both worried and relieved. I needed some time off.

That layoff taught me valuable lessons about life, career, and money.

My coding side

2024 felt like a rollercoaster.

After getting laid off and sending dozens of applications, I decided to take some time off to take care of my health. A mini-retirement.

After the radio silence and a few “thanks, maybe later” replies, I started freelancing with a small software agency. That helped me stay afloat for a month or two without running out of savings.

In 2024, I doubled down on my online presence.

I created two video courses on Udemy: here and here. I hired Microsoft’s Copilot as my assistant to create the promotional materials. All the content and recordings were made by me. A human.

My career reflections

Being laid off gave me time to reflect on my career after over 10 years of non-stop work.

I wrote about the lessons my first job taught me about coding and life and shared 8 lessons for new developers, like in a free mentoring session.

Last year the coding world went nuts when Devin, “the first AI software engineer,” was released and I gave my predictions for coding in 2034.

If you’re reading this from the future, let me know if I nailed it with my predictions. By the way, do you have flying cars or are you still dreaming about them?

I created a 7-day email course to share the lessons I wish I had known to survive a career in software engineering. I share what I’d tell my younger self starting his first professional coding job.

And I moved my Monday Links series to an email list. Every other week, you won’t get Monday Links, but Friday Links in your inbox. For free.

If you missed any of them, here are my five most read posts from 2024:

My writing side

I will remember 2024 as the year I went all in on my writing.

After writing for more than 5 years, I took my first writing class. That gave me momentum to keep the writing ball rolling. I even created a tag /misc to write about everything outside programming and software engineering.

Starting on November 1st, I began writing daily on my blog. Those daily posts fueled my writing everywhere else.

After months of inactivity in 2023, I revived my LinkedIn account from Zombieland.

I challenged myself to write 100 short-form native posts. I started with 1 post a week, then 2, then 3… I doubled my follower count and had two or three “viral” posts. Those are vanity metrics. But the main benefit? The fear of writing in social media is gone!

It turns out LinkedIn is not that cringy when we follow the right strategy.

dev.to

In 2024, I kept reposting some of my posts on dev.to.

The dev.to team featured three of my posts in the Top7 posts of the week. These ones:

Parting Thought

Taking some time off to take care of my health was the best decision I made in 2024. Being physically healthy spreads to all other areas of our life.

And definitely, Monday mornings don’t feel the same when you wake up to do something you love.

Thanks for reading, and happy coding in 2025!

Don’t miss my best of 2023, 2022, and 2021.

The Best Way to Get Better at Writing Code Isn't Just Writing More Code

2024-12-31T00:00:00+00:00

More than 10 years ago, I started my real coding journey with a Google search: “How to be a better developer.”

University had taught me a lot of things I didn’t need. I had to teach myself the ones I needed.

I went down the rabbit hole. That search gave me lots of ideas and inspiration:

Write specs
Write unit tests
Document your code
Learn Functional Programming
Write self-documenting code
Read Clean Code
Start a blog

Yeah! Starting a blog. That inspired me to start this very blog. I didn’t know I was about to enjoy writing so much.

Those are good ideas. But what has worked best for me is reading other people’s code.

In fact, an ex-coworker taught me that lesson. That was his secret technique, even though he was our team’s architect, and we thought he didn’t need to study anymore.

So read more code. But read actively. You can’t read code like fiction, glancing over words on a page:

Find a medium-sized library you use or find interesting
Download its source code
Compile and run it
Look at its unit tests
Debug one feature

See how the library authors implemented a feature.

If you find a new keyword, look it up. If you find a new data structure, look it up too. If you find a new method in the standard library, again, look it up.

Once you understand how a feature is implemented, try to recreate a bare-bones version without looking at the original code. That’s how you make sure you truly understand the code.

I used this strategy when I learned about the Specification pattern. I found a library implementing that pattern. I downloaded and read it. Once I got the main idea, I wrote my own dummy implementation. Then I wrote a post about it.

Reading code has been one of the most effective ways to improve my coding skills. That’s why I made it one of the 30 proven strategies in my book, Street-Smart Coding: 30 Ways to Get Better at Coding. That’s the roadmap I wish I had when I was starting out.

Grab your copy of Street-Smart Coding here.

Here's the Best Productivity Hack I Learned in 2024

2024-12-30T00:00:00+00:00

It wasn’t a time management technique. It wasn’t the Eisenhower Matrix, Eat That Frog, or the Pareto Principle.

It was an energy management technique: eating better.

Eating better. Eating for energy.

Eating better means no processed foods, no carbs, and no sugar. We all know we should eat better. Nothing new! Right?!

But from “Glucose Revolution” by Jessie Inchauspé, eating better means reordering how we eat, without sacrificing those delicious candies.

Salads first. Proteins and fats second. And carbs and sweets last.

Reordering how we eat keeps our glucose spikes under control

Glucose spikes are the reason why we feel tired all day and hungrier even after eating. We have too much sugar in our bloodstream.

Simply by reordering how I ate, I got my energy back:

I don’t get sleepy after lunch.
I don’t drag my feet to get through my afternoons.
I lost ~4kg in two months without much effort.

Also, to control our glucose spikes, we could walk for 10-15 minutes after eating. The longer, the better.

Thanks to my new diet, my afternoons are as productive as my mornings. No more feeling like a zombie at the end of the day.

We are what we put in our bodies. And if we eat well, we think well.

The Best Books I Read in 2024 (Even If I Didn't Read Many)

2024-12-29T00:00:00+00:00

In 2024, I stopped being a serial book reader, keeping a tally of books I read.

I went from “let’s read anything and everything” to “let’s read what I need to read.” From just-in-case to just-in-time reading. I realized I had a long list of book notes, but I didn’t remember reading some of those books.

Naval Ravikant’s reading strategy helped me change my mind about books. And I adopted some reading methods into my own reading method.

Instead of reading a long list of books, I immersed myself in a single writer’s world.

By accident, I found James Altucher’s work and I’ve been following him since then. I reread “Reinvent Yourself” and read “Choose Yourself.” Those are the best ones I’ve read.

Reinvent Yourself

This was one of those books I didn’t remember reading, even when I had notes. Later, listening to James Altucher’s interviews, I made the connection and reread it.

We can’t rely on the same skills we learned 5 years ago. We need to reinvent ourselves every 5 years. And here, reinvention means finding new income sources.

To start a reinvention, we should read 500 books on any subject. That would take us around 5 years.

Choose Yourself

This is the best book I read this year.

Often, we’re waiting for someone to save us or choose us. Someone will see how smart we are and give us a job. Someone will see how attractive we are and choose us as life partners…The government, our boss, or a rich guy that doesn’t know what to do with his money. One day, someone will save us.

The truth is no one is coming to rescue us. We should choose ourselves.

We start choosing ourselves by taking care of our body, mind, and spirit every day: moving our bodies, doing something creative, and writing 10 ideas a day. Working on things we love and being surrounded by people we love.

And we don’t need anyone’s permission for that. The internet has created a world without permissions. The only permission we need is from ourselves.

Apart from these two, I read Choose Yourself Guide to Wealth, and I have on my pile to read “The Power of No” and “Skip the Line.” All of them by James Altucher. Yes, I’m immersed in James Altucher’s work these days.

Some honorable mentions: this year, I also read “E-Myth Revisited,” “You Are a Writer,” “Slow Productivity,” and “The Anxious Generation.”

I can’t say one book has changed my life. But, those two books gave enough ideas and inspiration to take care of health and get life on track after a season of burned out.

One Technique to Ease Your Onboarding—and Not Make New Team Members Feel Lost

2024-12-28T00:00:00+00:00

The first moments show how you’re going to be treated for the rest of the time.

It applies when you go to a restaurant, call a customer service line, or go to a bank. And the same is true when joining a new team as a developer.

The first day I joined my last full-time job was awful.

I was speaking a foreign language for work for the first time. I was working from home for the first time too. My company laptop didn’t arrive that day. I was told to install the software project with long and outdated instructions. I was completely lost.

I got a call from my boss’s boss that day, promising I’d “be in trouble” if I didn’t install that project before the end of the day.

The funny thing is, I didn’t have to work with that project at all in the 5 years I was there.

Instead of making your new team members feel lost, set clear goals for the first day, week, and month.

For the first day, a new team member should:

Install the right tools: email, VPN, chat clients, etc
Introduce themselves in Slack or company chat
Get to know their team lead

For the first week:

Have 1-1s with all team members
Have the working environment ready
Complete a dummy task to understand the project workflow

For the first month:

Complete a medium-sized task, with almost no guidance

Make it really easy for new team members to install your project and its dependencies. They should be ready to work by running a single script or pressing a button.

Make it really easy for new team members to follow existing rules and conventions. Don’t rely on outdated documents. Show sample code or work that follows those conventions.

Get your developers “up and running” as quickly as possible. Show them how you’re treating them for the rest of the time.

An Easy (And Clever) Way to Write a Non-Fiction Book

2024-12-27T00:00:00+00:00

Writing a book is a sign of prestige and a synonym of expertise.

A book brings interviews, talks, consulting gigs, and more opportunities. Sales don’t bring the most money, but the doors it opens do. That’s what I’ve heard.

If you think of publishers, pitching, and rejection when you think of publishing a book, there’s the self-publishing route. Amazon, Gumroad, or your own site are good options.

Writing a book can seem daunting.

But in an interview for Self Publishing TV on YouTube, James Altucher shared a simpler way to write a non-fiction book:

Find a topic you’re interested in.
Look up 10 scientific papers about it.
Explain each paper in simple words and share a story.

Et voilà! You have a book: “10 Scientifically Proven Ways to …”

The thing is, scientific papers aren’t written for normal people. They’re impossible to read. Full of technical jargon and long paragraphs. Arrggg! I tried it when I wanted to understand phones reducing our cognitive capacities. I said, why they write like this?

Even if you don’t write a book, this is a great idea for a newsletter, series of posts, or email course.

The Surprising Lesson from My First Online Writing Class

2024-12-26T00:00:00+00:00

This year, and for the first time since University, I took a writing class for the Internet.

It was a webinar, to be precise. Tim Denning and Todd Brison ran it.

The main lesson? Write daily. Daily?! Yes, daily.

That was shocking. I was used to writing on my blog when I felt I had something to say. Usually, once a month. Later, when I gained some traction, twice a month. I only wrote daily when I challenged myself to write ~20 posts before Christmas in 2022.

To write daily, you don’t have to produce 1,000-word posts each time. A good headline and one main point are enough to hit “Publish.” Even a tweet, a quote, or 200 words are a good place to start too.

When you write daily:

You make people notice you and remember you by consistently showing up in their feeds.
You get closer to your future customers, bosses, and partners. Remember, people don’t buy from or do business with random people on the streets, but from people they know.
You build a library of content that showcases your expertise. People will see you as an expert, or at least someone who knows about the subject you’re writing about.

Write your first piece to get ahead of those who never start, and keep writing daily to get ahead of those who quit along the way. Your future self will thank you for it.

We Shouldn't Call Them Best Practices—And Blindly Follow Them

2024-12-25T00:00:00+00:00

We, as coders, take pride in preaching and following best practices.

Don’t write SQL, use an ORM. Don’t write conditionals, use design patterns. Don’t throw exceptions, use Results…Don’t do that, do this.

Those “don’t do that, do this” hide all the context in which they make sense. That’s the part we skip and don’t tell when we preach best practices.

Today, I had a call with a consulting company that needed help. They were migrating a small shop’s application from the early 2000s to a newer stack. It wasn’t written and maintained by professional software engineers. Zero best practices. Lots of copy-pasting.

Migrating that application and bringing its owners up to speed are two different challenges. They have to maintain the application once the migration is done. Using the latest and greatest best practices wasn’t an option.

Often, instead of going all in on best practices, the best path to follow is “let’s do the simplest thing that can work, without doing any more harm.”

We shouldn’t call them “best practices,” but rather “pieces of advice that worked for me under certain circumstances and might work for you too.” And we shouldn’t blindly follow them. Not all code is created equal and worth the same.

Don't Write to Seem Smart, Write Like This Instead

2024-12-24T00:00:00+00:00

Don’t write to seem smart or to sound like a famous writer.

That will only make you use technical jargon, complicated words, and long boring paragraphs that scare people away.

Instead, write for only one person.

Every time you sit to write, imagine you’re writing for a friend, coworker, or your past self.

It will give you the right tone, context, and level of detail. You won’t use words or jargon you wouldn’t use in a real conversation. Instead, you will use your true voice.

I wrote most of my coding tutorials for a friend or two. They almost never asked me to write them. I never showed them the finished piece. I simply imagined myself explaining something to them to make my writing easier.

If writing for someone sounds hard, record yourself explaining something and transcribe it.

What’s the point of sounding smart if your writing get so complicated that people don’t read what you write?

“Write with the same voice you talk in. You’ve spent your whole life learning how to communicate with that voice. Why change it when you communicate with text?” — James Altucher

One Language Trick I Use to Ace Interviews in a Second Language

2024-12-23T00:00:00+00:00

Interviews are intimidating.

You don’t know what you’re going to be asked. You don’t know if the interviewer will like you. You have to remember what you wrote on your CV.

That makes interviews intimidating for sure. But the ones in a second language are worse.

Are my speaking skills good enough? What if I don’t understand my interviewer’s accent? What if I forget how to say something? Arrggg! I know that feeling.

When I decided to apply to my last full-time job as a software engineer, I really wanted to land the job. I was about to work remotely for American companies for the first time. I had to impress my interviewers not only with my coding skills, but with my language skills too.

Right before the interviews, to calm my nerves and practice my speaking skills, I phoned my language partner and friend. She was kind enough to answer my calls and help me out. We talked about anything.

Those calls helped me switch to thinking in a second language, like pushing a button in my brain.

Eventually, I stopped calling my friend before every interview. But I adapted the method.

Instead of interrupting my friend’s busy schedule, now I watch a short YouTube video of a movie or TV show or any content by native speakers right before an interview in a second language. It gets me into the flow of the language and makes my brain switch the second language on.

And that’s one of the tricks I used for interviews.

As a bonus, here are others:

Keep a copy of your CV next to you.
Learn conversation fillers to keep the conversation going.
Practice answering out loud the most common interview questions. At least be prepared for: “tell me about yourself” and “could you describe one of your past projects?”
Speak slowly. It will give you time to think.
If you don’t understand a question, restate what you understood and ask if that’s what the interviewer meant.

Interviewing and hiring are broken. I know. But don’t go unprepared. Prime your brain by listening to or watching native content before showing up.

3 Lessons I Learned from Watching Two Millionaires Talk About Money

2024-12-22T00:00:00+00:00

Having too much money brings a different set of challenges.

That’s one of the takeaways from this conversation between two millionaires. It’s one episode of the “Deep Dive with Ali Abdaal.” This time Ali sat down with Andrew Wilkinson.

Here’s the link to the YouTube episode if you want to watch it.

“I’m as Stressed as You Are”

For me, hearing Andrew say he was stressed too was one of the most shocking parts of that conversation — right at the start.

We might believe that money makes life easier. But from that conversation: it just brings a new set of challenges. We have to choose our own money adventure and when to stop.

This reminds me of a past boss.

I guess money can’t buy certain things. For everything else, there’s a credit card. I’m stealing that from a TV commercial.

“Be a Financial Prepper”

Be paranoid. Only the paranoids survive.

“Be unbreakable financially”

Robert Kiyosaki is right: “Build your asset column” and “Make your assets pay for your luxuries.”

I had to truly live it to learn it. Knowledge is only potential power unless put into practice.

“The best way to feel rich is to have cashflow”

Be the Sushi Master or the Chipotle Founder

Apart from the money lessons, my most important takeaway from this podcast episode is to:

“Design your life around your flow state”

We could choose to be the best sushi master of the world — worth a Netflix documentary — or the Chipotle founder.

That’s success seen from different perspectives.

Both of them followed what they enjoyed doing. Each followed a different adventure.

In any case, follow your flow state and delegate things you don’t enjoy.

“Sell something boring to a rich person. Don’t sell a complex product to cheap people.”

How A Salary Messed With My Mind—Two Realizations After a Layoff

2024-12-21T00:00:00+00:00

“Wait, I’m not working anymore.”

Being laid off feels weird. Moments of relief followed by a “What am I going to do now?”

Some days after being laid off last January, something weird happened. I didn’t realize I had ingrained this “habit.”

Midway through rushing to my laptop to reply to my Teams messages, I suddenly stopped my short commute from the living room to my working corner.

“Wait a second, I’m not working anymore…I don’t have to reply to messages or emails.” Pheeew!

I shared this realization with my family. We all laughed. But there was something behind it.

Stopping my short breaks to reply to messages had become second nature. I was trapped in a mindset. In the wrong mindset. “I could get into trouble if I don’t respond soon.”

That moment of relief lasted a few days. Anxiety knocked at my door: “Somebody here?” I realized I wasn’t receiving another paycheck. Arrrggg! “What am I going to do now?”

I had to go through my accounting software, an Excel spreadsheet, multiple times to make the anxiety go away. “Rational brain help me out here.” I had an emergency fund to cover my expenses for a few months.

Yes, a monthly salary is one of three most harmful addictions. I had already heard that quote. This time I had to live it.

That was a moment of relief followed by a “What am I going to do now?”

I'm Following This Plan To Learn Enough Copywriting To Be Dangerous

2024-12-20T00:00:00+00:00

Writing is the superpower to survive in the online world.

All online content starts with writing. A video begins with a script, a course with a series of posts, and a long post with a Tweet or short-form post.

And guess what? Marketing and sales start with writing, too. A landing page, an email sequence, a product description, and an ad.

That’s when copywriting comes into the picture. Copywriting means writing to make readers take action: like and subscribe, download a freebie, and ultimately buy.

This is my 3-step plan to learn enough copywriting to be safely dangerous.

1. Start by writing classics by hand

The #1 exercise I have found to learn to copywrite is copywork.

Copywork means recreating classic ads, sales letters, and good “copy” by hand. Yes, by hand. That’s the whole point. When we handwrite, we’re forced to slow down, read carefully, and pay attention to words and phrases.

I’m not new to this exercise. When I started writing coding tutorials, I copied Seth Godin’s posts. I noticed how he doesn’t use introductions or conclusions in his posts. Instead, the first sentence naturally follows the post title.

The goal of copywork isn’t to transcribe. It’s about noticing the structure, common phrases, and other patterns.

These are 3 posts where you can find samples to copywork:

Get Better At Copywriting By Handwriting Famous Pieces Of Work! —I’ve been following this post this month. That’s one example per day for 31 days.
5 Ad Copywriting Examples to Study, Hand Copy, and Save to Your Copywriting Swipe File
Gary Halbert Copywriting Examples

I bought a notebook for my copywork and color pens. After I finish transcribing a copy, I use a pen with one color to notice words and phrases. Then, at the margins of the page, I use another pen to notice the overall structure and formulas.

And there’s one online course built around the idea of copywork: CopyHour. That’s 90 days of daily copywork—Even we can handwrite that landing page!

Everywhere I looked, I found references to this course. Definitely, I’m keeping an eye on the next enrollment.

2. Read the Boron Letters

Gary Halbert is one name that keeps popping up in any Google search about copywriting.

He is a legend in the copywriting world. He wrote sales letters and ads for well-known brands, making millions of dollars in sales. Think of him like Hemingway going the sales way.

The thing is, Gary Halbert ended up in jail. From there, he wrote a series of letters to his son, teaching him to make money through copywriting. Those letters became a book: The Boron Letters—named after the Boron Federal Penitentiary where Gary was.

After doing copywork, my next step is reading and studying The Boron Letters.

I picked up The Boron Letters years ago but didn’t finish it. At that time, I thought it was another writing book. I didn’t understand what copywriting was and its goal, and dropped it. I wasn’t ready yet.

All that I remember is the advice from someone in jail to eat a banana a day, exercise, and grow big arms because bullies don’t mess with people with big arms. That’s from the first two letters, by the way.

Since reading three books will put us ahead of 90% of people, here are another two copywriting books: “Writing That Works” and “The Adweek Copywriting Handbook.” Those books are on my to-read list after The Boron Letters.

3. Revisit my landing pages and calls to action

This is the dangerous part. Knowledge is only potential power unless it’s put into practice.

I don’t have that many sales pages yet, but a couple of landing pages for coding courses and freebies in my Gumroad account. I want to revisit those landing pages and the calls to action at the end of my posts.

Originally, I wrote them following what I saw online: “Click here” and “Join my course here.” I had no idea about copywriting and frameworks like Problem/Agitation/Solution.

One trick I’ve learned is to write in terms of benefits, not features. Always write with the reader in mind. That’s the difference between “1GB of storage” vs “carry 100 songs in your pockets wherever you go.”

With that trick in mind, I changed one of my CTAs from a simple “Join my free 7-day email course here” to something along the lines of “Join my free 7-day email course and save years and thousands of dollars’ worth of career mistakes.” And I got my first two subscribers after that change.

If there’s one skill you can master for the future, choose writing online. And don’t worry about ChatGPT or Copilot because they will always output average writing.

Stop Time Traveling—Yes, You're Already Doing It

2024-12-19T00:00:00+00:00

You don’t need to speed a DeLorean to 88mph to time travel. In fact, you’re already doing it.

Every time you go into your head to relive past situations, you’re time traveling. And every time you go into your head to anticipate future situations, you’re time traveling too.

I declare myself guilty of time traveling.

I’ve time traveled to the day when the ex-bosses “who let me go” finally realize how talented and smart I am and beg me to return. That probably will never happen. And I’ve only wasted time and mental energy time traveling.

By reading Choose Yourself by James Altucher, I learned to have a “Daily Practice:” A routine to work on my physical, mental, emotional, and spiritual self every day. We need to work on all of them to be healthy.

As part of the Daily Practice, James Altucher recommends stopping time traveling.

For some people, it means having moments of silence during the day to breathe and notice their thoughts.

I won’t call it “meditation.” Probably, when you hear that word, the first thing that comes to mind is a Buddhist monk sitting in impossible poses chanting. But it’s simpler than that.

When you notice you’re time traveling, repeat to yourself: “Stop, breathe, and get out of your mind.”

Time traveling only brings resentment. Stop doing it and get back to the present.

You're an Alarm Away from Being Healthier, Wealthier, and Happier

2024-12-18T00:00:00+00:00

Phones are not just communication devices. They’re distraction machines with constant beeps and buzzes.

Keeping our phones around reduces our cognitive abilities, even when we’re not using them. I learned this from reading “The Anxious Generation,” by the way.

But that doesn’t mean we can’t use those beeps and buzzes to our advantage. They can be reminders of what we want to accomplish.

I have an alarm to unplug from work labeled “It’s time to relax.” During that time, I do anything I want outside work without feeling guilty. It’s one of the few sounds I allow my phone to make. All others are deactivated.

From reading The 3 Alarms by Eric Partaker, I learned to use alarms not only to schedule my downtime but also to improve the three main areas of our lives: health, work, and relationships.

Here’s how:

Start by setting 3 alarms on your phone.

Label each alarm with a reminder of who you want to become: the healthy parent, the focused solopreneur, or the supportive partner. You name it!

When the alarm rings, do something that takes you closer to that. It doesn’t have to be a huge action, just a small step.

When “the healthy parent” rings, get up and move your body. When “the focused solopreneur” rings, put all distractions away and work on your side business. When “the supportive partner” rings, call or text your partner.

Those small steps will create habits, and habits will reinforce who you want to become.

You can set an alarm to:

Exercise
Drink water
Read a book
Stretch your body
Write down 10 ideas
Write a gratitude list
Step away from screens
Have a moment of silence
Work on your side business
Call or text someone you love

And label that alarm as a reminder of the person you want to become.

I Followed This One Trick to Write Better Headlines. Here's What I Found

2024-12-17T00:00:00+00:00

“Five times as many people read the headline as read the body.”

That’s a quote from David Ogilvy, “the father of advertising.” It applies to the copywriting world, as well as other forms of writing.

A good headline is like the welcome sign for the rest of your piece. People passing by will choose to read only after seeing a good headline. No matter how well written and insightful your content is, a poor headline will make people skip to the next piece in their feeds.

Apart from writing 10 headlines a day, the best piece of advice I’ve found to write better headlines is to look at YouTube headlines.

Following that advice, I sneaked into Ali Abdaal’s YouTube channel. Here are the headlines of 10 of his most popular videos:

How I type REALLY fast (156 words per minute)
My evidence-based skincare routine
Why you’re always tired - 7 myths ruining your sleep
If I started a YouTube channel in 2025, I’d do this
The book that changed my financial life
What makes people successful?
How writing made me a millionaire
My honest advice to someone who wants financial freedom
My favorite note-taking app for students - Notion
The best book I’ve ever read about making money

Those headlines follow a pattern:

How I “action”
My evidence-based “action”
“Question about pain” - n “promise”
If I “action”, I’d do this
The “resource” that “outcome”
How “action” made me “outcome”
My honest advice to “audience” who wants “result”
The best “resource” I’ve ever “action” about “subject”

That’s a good starting place to write better headlines.

It's OK if You Don't Have a Single True Passion

2024-12-16T00:00:00+00:00

Photo by Astrid Schaffner on Unsplash

“Find your passion” has always stressed me out.

That advice assumes we all have a single true passion we can find within ourselves.

I’ve always had trouble finding that one true passion ever since high school. I got good grades in all subjects, with more effort in some than others. Picking one thing wasn’t easy based on grades alone.

I struggled to choose what to study at university. I had many ideas: joining the Military, studying Biology, or taking the Engineering route.

I’ve always had trouble finding one specific thing as a software engineer and solopreneur.

All that stress started to fade away when I realized it’s okay not to have one single true passion.

Embrace Your Multiple Passions

The first counter-advice to “find your passion” I found was by watching Emilie Wapnick’s TED talk “Why Some of Us Don’t Have One True Calling.”

She shares her story of having multiple interests and struggling to answer “What do you do for a living?”

This intrigued me to the point of devouring most of the articles on her website.

The main lesson from Emilie’s work is to embrace our multiple interests and passions. She even coined a term for that: being a multipotentialite.

Based on the quiz on her site, I discovered I’m a mixed-multipotentialite: someone who balances two passions at a time instead of many unfinished projects. This realization helped me connect the dots.

I bought the idea of embracing my interests. But my first question was, “How can multipotentialites make a living? Who needs or hires them?” All the advice I had heard was to find one passion, one thing, or one niche.

Emilie surveyed her community and found four ways to balance work as a multipotentialite:

Einstein approach: A “boring” or “good enough” job pays the bills while you have something after hours. Einstein worked at the Patents Office while he started his Physics work.
Slash approach: A two-job career. I’m a “software engineer/writer.”
Group Hug approach: A multi-disciplinary job that allows you to combine your multiple passions or interests.
Phoenix approach: A seasonal approach, changing careers to follow one of your passions per season.

Don’t run from your multiple interests. Embrace them. There are always options to make a living from your multiple interests.

Don’t Be an Engineer, Be a Producer

My second counter-advice to finding a single true passion came from the book “Range: Why Generalists Triumph in a Specialized World” by David Epstein.

An ex-boss recommended it during one of our 1-on-1s. It’s also one of Bill Gates’ recommendations on his YouTube channel. Not that he’s one of my ex-bosses or that I had 1-on-1s with him.

Gunpei Yokoi’s story is the one I remember the most from the book.

He didn’t have a single interest. He worked as a maintenance guy for card-making machines at Nintendo back in the ’60s. He spent most of his first days there playing with the company equipment.

One day, Nintendo’s president saw him playing with an extendable arm and asked him to turn it into a toy. The Nintendo Ultra Hand was born. It saved Nintendo from debt and started the Research and Development department at Nintendo.

Looking for creative ways to repurpose old technology, Yokoi’s team was responsible for many of Nintendo’s successes over the years. The Game Boy was one of them. Yes, the Game Boy!

When asked about his approach, Yokoi said “I don’t have any particular specialist skills, I have a sort of vague knowledge about everything.” He had a range of skills.

Yokoi taught his team to be producers, not engineers. An engineer focuses on the details. But a producer knows how to connect things.

Instead of following a single interest, be a scientist who follow hypotheses, runs experiments, and tests and learns. Build a range of skills.

“Be a flirt with your possible selves. Rather than a grand plan, find experiments that can be undertaken quickly.”-Range by David Epstein

Takeaways

Don’t worry about finding a single true passion and following it for the rest of your life.

It’s OK to have multiple interests and juggle between them. It’s OK to change passions. It’s OK not to have one single niche. It’s OK to be a generalist.

Having multiple passions brings a sense of curiosity and a desire to learn about the world around us.

The world needs both focused frogs and visionary birds-deep-focused specialists and “above the trees” generalists who can see the bigger picture.

How I Organize My Blogging Workflow

2024-12-15T00:00:00+00:00

A schedule and an easy-to-follow workflow.

That’s what you need if you want to keep blogging in the long run.

I started blogging back in 2018. I threw up some words in a file and put them online. No schedule or intentions. Only when I adopted a writing schedule, I started to improve my writing skills and notice more pageviews.

To preserve my keystrokes and expand on my comment to this dev.to question about blogging, here’s my writing workflow:

One platform first then cross-post everywhere

Recently, I started to follow the POSSE principle: Publish (on your) Own Site, Syndicate Elsewhere.

My blog is my main hub. Anything I write online, in some shape or form, ends up on my blog. Recently, I created a new tag misc to organize my posts about other subjects apart from coding or software engineering.

Based on the type of content: tutorial vs opinion piece, I republish a shorter version on dev.to or republish on Medium, linking back to the original post.

Since often some Medium publications only accept original content, I publish there first and then the next day, I publish on my blog. Win-win.

Raw post content in a single place

I’m a plain-tex fan. So, markdown everywhere.

I keep my raw posts on a note-taking app in Markdown. Since I use GitHub with Jekyll to host my blog, publishing a new post is a simple commit and a push. Or when I’m feeling lazier than usual, I paste the post content directly on GitHub.

For images, I host them on GitHub itself. I organize them inside a folder named “assets,” with subfolders named after my posts’ titles.

For my most recent posts, I’ve ditched images and banners and started to write shorter text-only posts. A decent headline and one main idea are good enough to publish.

To republish on Medium: I use the import feature. It works fine, except for code listings. I copy and paste them and add some emojis to highlight important lines of code.
To republish on dev.to: I use a template with disclaimers, intros, and CTAs. Then I copy and paste that template and only fill in the post body in the editor itself.

If you want to stay consistent and keep blogging, make it really easy. Reduce all the friction and automate as much as you can.

Follow This 1 Tip to Truly Stay Consistent With Any Skill

2024-12-14T00:00:00+00:00

Want to master any skill? Simple!

Show up. Consistency is king. Do something every day for one year.

That’s common Internet advice to master a skill and crush your goals.

Want to write? Show up. Want to get in shape? Consistency is king.

Easier said than done.

Show up is good advice. But it’s only part of the full piece of advice

If you want to stay consistent, commit to the smallest action you can sustain in the long term.

At the start of the year, I joined a monthly reading club with some friends. In the first sessions, everybody showed up with their reading done. We were so enthusiastic that we wanted to read more, have online discussions, and write essays with our reactions. We even wanted to meet up every weekend.

But after a couple of sessions, somebody showed up without the reading done. And then, somebody else stopped showing up. And then somebody else…and somebody else. Eventually, we stopped our reading club.

We bit off more than we could chew. And like any plan, it didn’t resist contact with reality.

To stay consistent, show up, but with small actions

Want to write? Commit to writing less than 200 words a day. Want to get in shape? Commit to doing 1 push-up a day. Want to read more? Commit to reading 1 page a day.

And make it easy to finish your small action of the day.

Leave your writing app open. Go to bed wearing your workout clothes. Keep a book on your desk.

Small and easy-to-finish actions in the long run. That’s how you keep showing up.

Keeping Your Phone Around Reduces Your Cognitive Capacities

2024-12-13T00:00:00+00:00

That was the result of a study by the University of Texas, cited in the book “The Anxious Generation.”

In the study, they divided an undergraduate classroom into thirds.

One third left their phones in another room. Another third kept them in their pockets or bags. And the last third kept them facing down on their desks.

Guess who performed best at the end of some cognitive tests?

Of course, the third that kept their phones outside did best. And the other two thirds did poorly, with some differences depending on the tests. But they claimed that their phone’s presence didn’t affect their performance.

The mere presence of their phones reduced their cognitive abilities, even when they were silent or off.

If you have read Deep Work, you already know about monk mode. But to focus, you don’t have to go into strict mode and retreat to a cabin without reception in the middle of nowhere. Just ask your phone to give you some space. Leave your phone in another room, out of sight.

Now, while I’m typing this, my phone is in airplane mode, in another room.

So if you want to do focused work, leave your phone out of sight.

5 Life-Changing Purchases I've Made Since 2020

2024-12-12T00:00:00+00:00

I’m answering this Hacker News question:

Is there anything you’ve bought in the past few years (since 2020) that really changed something in your life?

They didn’t change my life, but they’ve made it somewhat better:

A pair of 5-kg dumbbells: Cheaper than a yearly gym subscription. With a couple of YouTube videos, they’re enough to keep moving my body every day.
Money and personal development books: I bought print copies of these titles:
- The Monk Who Sold His Ferrari
- The Ruthless Elimination of Hurry
- The Richest Man in Babylon
- The Psychology of Money
- Think and Grow Rich
- Unwinding Anxiety
- Purify Your Brain
Workstation setup: Since I spend most of my working time in front of a computer, I bought an air conditioner, a standing desk, and an external display.
Writing course: I’ve been writing since 2018 when I wrote my first blog post. But most of what I had learned was through trial and error. This year, I paid for a writing course and went all in with my writing.
Eating out with friends: Some friends are worth every cup of coffee or dinner out.

Being In A Self-Managed Team Made Me Try The Most Expensive Hamburgers I've Eaten

2024-12-11T00:00:00+00:00

I didn’t pay for the most expensive hamburgers I’ve eaten. An ex-employer did.

When I say “most expensive,” I mean the same greasy $5 or $10-dollar hamburger from a food truck or a corner in a busy street. But they felt expensive because I ate them while working overnight.

I was in a “self-managed team”

In a past job, when my team was lagging behind the self-imposed deadlines of sprints, higher-ups told us:

“This sprint is behind schedule. What are you going to do? You’re a self-managed team, so decide that by yourselves. But if I were you, I’d choose to work overtime to keep up.”

“You’re a self-managed team” was their subtle way of telling us to work extra hours, without accepting any responsibility.

We didn’t have any say in what tasks to do and how. We were only a self-managed team when it came to choosing to work overtime.

They didn’t pay us for that extra time. They only bought us hamburgers. And, when someone raised their concerns about the quality of those hamburgers, they told us we should be grateful because other companies buy their employees nothing to eat.

Since I don’t want this to be only a rant…

If you’re told you’re part of a self-managed team, read the fine print. Look for signs of real self-managed teams:

Look at job descriptions.
Connect with people already working there.
Ask follow-up questions during interviews.

Otherwise, they might expect you to work overtime without compensation or just buy you an hamburger.

Six Inspiring Lessons I Learned from Jim Kwik, the Brain Coach—in Six Quotes

2024-12-10T00:00:00+00:00

Jim Kwik is “the world’s #1 brain performance coach.” But he wasn’t always someone we would consider smart.

In school, he was called “broken” because of his learning issues. He wasn’t as fast as his classmates and couldn’t read. An accident caused him brain injuries that put him behind his class.

Believe it or not, he now teaches the very same subjects he struggled with: learning, reading, and memory. He’s the author of Limitless and the host of the Kwik Brain podcast.

Here are 6 lessons I learned from Jim Kwik’s videos and podcast episodes:

1. “Little by little, a little becomes a lot”

That shows the compounding power of consistency.

Want to change your life? Learn a new skill and practice it daily for a year. Read a book, learn a new language, or write online. Start with small, simple steps.

2. “First you build your habits, then your habits build you”

Wake up at 5:00 AM, take cold showers, drink water, go to the gym, meditate, journal…and on and on. It doesn’t have to be that complicated.

You can choose a simple routine: create something in the mornings, consume in the afternoons, and disconnect in the evenings.

3. “Reading is downloading decades of information to your brain in a few hours”

Books condense decades of an author’s experiences into thousands of pages.

Reading is the closest we can get to plugging ourselves into a computer and downloading new programs to our brains in seconds, like in the Matrix. “I know Kung Fu. Show me.”

Reading is the best exercise for your brain.

The problem is most of us haven’t taken a reading class since school.

If you haven’t, start by using your finger to guide your eyes as you read. It will increase your reading speed and comprehension.

If knowledge is power, then reading is your superpower.

4. “Yet opens up new possibilities”

We are our first haters with our negative self-talk:

“I can’t”
“I don’t know”
“I don’t have”

Reframe those ANTs (Automatic Negative Thoughts) with a simple word: “yet.”

“Yet” brings new possibilities and room for growth:

“I can’t yet”
“I don’t know yet”
“I don’t have yet”

A simple word can change it all.

5. “You don’t get burned out by doing too much, but by doing too little of the things you care about”

Been there, done that. I got burned out when I tried to convince myself to do something I didn’t like that much just for money.

It took me months to get back my physical and mental health. Doing something just for money was a painful decision.

6. “Use AI to extend your HI, not to replace it”

AI is a powerful tool, but don’t use it to replace your HI (Human Intelligence). Don’t outsource your learning and thinking to AI.

Use AI as your copilot, not as the pilot.

Jim Kwik’s story is a story of change, possibility, and determination. From the kid with the “broken” brain to a world-renowned brain and learning expert.

It’s what you have between your ears that separates you from what you want.

8 Unexpected Lessons I Learned from Watching One of My Favorite TV Shows—Scorpion

2024-12-09T00:00:00+00:00

Scorpion's team. Via: themoviedb.org

Imagine The Big Bang Theory marrying MacGyver. That’s Scorpion.

Scorpion, aired between 2014 and 2018, follows a team of four geniuses (and two or more “normal” people depending on the episode) solving impossible cases for the Department of Homeland Security. Walter O’Brien, the guy with one of the highest IQ in history, 197, leads the team—allegedly, based on a real character.

In every episode, they solve all sorts of crazy and impossible cases to save the day, the U.S., or the world:

Saving a small county in the middle of nowhere from a fire approaching a nuclear waste facility.
Dismantling an old nuclear warhead in a secret military base.
Saving a kid trapped in a cave from drowning by raising tides.

And those are only the cases I remember off the top of my head.

After binge-watching all four seasons of Scorpion, these are 8 lessons I learned:

1. Soft skills take you further

A team of four geniuses can get around any situation. But the team is in trouble when Paige isn’t around.

Interestingly, Paige isn’t a genius by conventional standards. She isn’t a mathematician or mechanic. She has excellent social skills and is brilliantly at connecting with people.

In one episode, while Paige wasn’t around, Toby, the doctor, and Happy, the mechanic, made things worse.

They needed to collaborate with the local police to save Walter but their poor social skills and egos got them arrested. They ended up insulting the police chief instead of coordinating efforts. They had to call Paige to fix the misunderstanding.

Hard skills open doors, but soft skills take you further.

2. Find something that gives you meaning

Before joining the team, everyone was a mess:

Toby, the doctor, was a gambling addict.
Paige was an underpaid waitress with no purpose.
Paige’s son, Ralph, was misunderstood as a weirdo. He was another genius, living in his own world.
Happy, the mechanic, had no friends or family.
Sylvester, the Math genius, was bullied or something. I don’t remember exactly.
Walter, the leader, had 0 social skills.
Agent Gallo, the government handler, was a widower and workaholic.

Solving those near-impossible cases gave them meaning. Being part of something and working together was what they needed to bring meaning to their lives.

3. A simple framework tells many stories

Almost all Scorpion episodes are the same.

The team is hanging out in the garage. Then, Agent Gallo or an external client comes with a case. They quickly come up with a plan. But, mid-case something unexpected happens that complicates the case. They have no clue how to solve it, but a non-genius (Paige, Gallo, or somebody else) says something unrelated. An “aha” moment leads to a new solution. And, finally, they’re back at the garage to end the episode.

A simple storytelling framework gets you hooked on every episode from start to end.

4. Find who’s best at every job

No matter who is leading a case, the team shines when everyone is working on what they’re good at:

Sylvester, mental math.
Toby, medicine and psychiatry.
Happy, mechanics.
Paige, connecting with people.
Walter, leading and connecting the dots.
Gallo, speaking the government lingo.

As a leader, your job is to find out who’s best at each task, split the goal into smaller tasks, and assign each task to the right person.

5. But, be willing to take the back seat

From time to time, someone has to stay at the garage and oversee the entire case: monitoring and reporting, passing context, and coordinating efforts with local authorities.

As a leader, you’re not there to shine, but to make others shine and get the work done.

6. Be ready to have uncomfortable situations

As the series progresses, the team has to face their own challenges.

Gallo has childhood trauma. Walter has unresolved issues with his father. Happy can’t express her feelings. Sylvester is afraid of pretty much everything.

They all overcame their issues when they opened up and talked to someone they trust.

7. Learn to let go of what you can’t control

Spoiler alert…

Happy and Toby missed their wedding ceremony while solving a case. They lost the flight back home because the case took longer. They couldn’t control that and couldn’t do anything about it.

But they controlled what they did after that. Again, Paige saved the day by improvising a wedding ceremony for them. She’s the real genius in the team.

Life keeps changing its rules. You can’t control it. Learn to adapt to the new rules and keep playing.

8. Your favorite show could end anytime

The show was canceled and the last episode ended with a cliffhanger. Damn! Where’s season 5? Arrggg!

I guess the lesson here is to always end our stories or writings with a cliffhanger.

I didn’t believe a TV show could teach that much about leadership, storytelling, and psychology…Well, I don’t feel that guilty about watching four seasons with 93 episodes. At least, I took some lessons away and wrote about it.

Who Would You Trust: The CEO Or The Janitor?

2024-12-08T00:00:00+00:00

More than 25% of new Google code is generated by AI.

That’s what Sundar Pichai, CEO of Google, announced in the last earnings call—Q3 2024.

That’s scary. Not because AI is taking our jobs, but because they’re relying on who knows what kind of code. And if human-generated code has created all sorts of problems, what about the AI-generated code?

That announcement generated lots of discussions.

On Hacker News, a Google employee, probably behind a throwaway account, said that AI is autocompleting the lines he writes, but it doesn’t do any actual engineering or generate code from natural language. I was wrong about my initial thought.

On LinkedIn, there was a post dismantling that announcement and pointing to that Hacker News comment. Of course, someone didn’t believe what the Google employee wrote in that comment. “Would you trust a random employee?”

If you really want to know how a company is run, do you ask the CEO or someone with boots on the ground?

The best one to answer how a company runs is the receptionist, janitor, or an entry-level employee, not the CEO.

The CEO of a million-dollar company, to raise stock prices and invite investors to throw money at them, will say “AI,” “disruption,” “climate change,” “diversity,” or any trending SEO keyword.

I don’t believe what Google’s CEO said. I believe that random Hacker News comment.

One Simple Trick to Avoid Writer's Block

2024-12-07T00:00:00+00:00

I almost broke my daily writing habit today.

Starting on November 1st, I began writing daily here on my blog. I chose to go with a good headline and one main idea. That’s good enough to mark the calendar and call it a day. No need for an introduction, 10 main points, and a conclusion.

I start my writing sessions after sitting in silence for 10 minutes with my eyes closed. Like magic, before finishing those 10 minutes, something comes to mind.

That was not the case today.

I looked at Hacker News, searching for something to react to but found nothing interesting. Reddit? Nothing. Old posts to expand on? Nothing. List of drafts? Extra nothing.

Until I had to step outside for a while.

There’s something magical and mysterious about taking a walk… Well, there’s nothing magical about that. More oxygen gets to the brain, and that activates certain brain regions.

On my way back home, I had something to write. I rushed to my laptop before I forgot it.

If you think you’re facing writer’s block, read something to prime your brain and step away from your computer for a walk. Before you get back, you’ll have something to write. It works every time.

Always Be Writing About What You Do at Work

2024-12-06T00:00:00+00:00

That’s better than simply claiming on your CV that you did something.

Write about what you’re doing and what you’re learning at work. For example, write about:

Challenges you’re facing while solving a problem.
Lessons you’re learning from every project.
Checklist you use to review pull requests.
Most common code review comments you give.
Difficult situations you have overcome.

I wrote my first post to document an alternative for a coding task I had. For my 2022 Advent of Posts, I took a lot of inspiration from what I was doing at work at that time.

There are always alternatives to avoid disclosing real code. 99% of the time, we’re not doing top-secret rocket science. But companies don’t want the world to know how they’re doing CRUD applications.

You can share isolated coding blocks and use different business domains to represent examples and coding issues. Using movies, posts, and reservations is a good alternative.

Instead of saying “trust me, I know how to do that,” you could say “I’ve done it and here’s where I wrote about it.”

How a Layoff Feels—And How to Prepare for the Next One

2024-12-05T00:00:00+00:00

Do you have a minute?

That was the last message you got from your boss’ boss.

Earlier that day, you logged in to work as usual. And you had a couple of “Are you still around?” messages. You knew it was happening. Again.

Then came a quick goodbye message from another colleague. He shared his email and contact details.

You went through the daily meeting knowing something was in the air. Some team members didn’t show up. Everybody pretended nothing was happening. But everyone knew it. It was the most awkward and useless daily meeting of all.

This “Do you have a minute?” conversation was different. You felt the disturbance in the Force right from the start. Your boss’ boss looked downwards, his voice is trembling. A small speech of how bad the economy was going. Your only thought was, “It’s my turn?”

Then the bomb: “We have to let you go this time.”

Definitely, it was your turn.

You left that last meeting relieved and worried at the same time. “What am I going to do now?”

And just like that, you got disconnected from the VPN and the company chat.

It was nice while it lasted.

That’s how being laid off feels. I know. I’ve been there. More than once.

Layoffs are always around the corner. High interest rates. A recession. AI…Today it’s a large U.S. company. Tomorrow who knows?

We’re better off rolling our own insurance policy:

Building a brand
Starting a side hustle
Creating an emergency fund
Growing a professional network
Having multiple sources of income
Learning different skills to monetize

Winter is always coming. Make yourself layoff-proof.

If You're Looking for Red Flags Once You're in a Job, It's Too Late

2024-12-04T00:00:00+00:00

It all starts with the job description.

No job description? Red flag.

“We’re looking for a passionate coding ninja to join our family. We work in an agile and fast-paced environment. We’re looking for a coder with 5 years of experience who can work on our public web page, mobile app, backend, frontend, DevOps, security, compliance, sales, marketing, documentation…Compensation based on experience and interview results.”

I’m making that up, but I wouldn’t be surprised if there’s a “real” job description like that one out there.

Passionate, coding ninja/superhero/master, family, fast-paced, high pressure…Nothing screams danger more than those words in a job description. Run, Forrest, run!

After reading between the lines of the job description, look at the company website.

“We’re a family.” That was the opening line on the careers page of a company someone tried to refer me to. I stopped reading. I didn’t need to look at anything else. It was a hell no. That was a blinking danger sign with sirens.

Ironically, every company claims to offer excellent conditions, and every applicants seems to be the perfect candidate for the job.

Who Isn't This For?

2024-12-03T00:00:00+00:00

It’s more important to ask who this isn’t for than who this is for.

Who isn’t this course for? Who isn’t this coaching program for? Who isn’t this blog post for?

I created a Udemy course on unit testing, one of my favorite subjects. I answered who this course is for on the landing page.

One student said some parts were too advanced. He had just started with the subject and my course covers more advanced material. It wasn’t for him.

So I asked for feedback. What were those challenging parts? There’s room for improvement there. Extra lessons and better lesson descriptions.

And I quickly updated the landing page to show who this course isn’t for. That will attract fewer students but the right ones. The ones my course is really for.

Whatever you’re doing, answer who this isn’t for.

Stop Being Afraid of Hitting Publish on LinkedIn With These 9 Proven Strategies

2024-12-02T00:00:00+00:00

Publishing your first LinkedIn posts is scary.

I know that feeling. Your hands shake. Your heart is beating. You keep retyping your password. You’re publishing something on the Internet for the first time ever.

You’re in fight or flight mode, ready to run away from lions behind a bush.

What if I say something wrong? What if my boss reads what I write? What if that comes up in future interviews? What if someone makes fun of me? It’s normal to have these worries.

I felt the same way when I wrote for the first time on LinkedIn, even after writing on my blog for years.

If the fear of being exposed online prevents you from hitting “Post” or “Schedule” on LinkedIn (or anywhere else online), follow these strategies:

1. Publish a lot

The first time you do anything is scary.

The only way to overcome it is with repetition. Write a lot and publish a lot. Create a writing schedule you can sustain and then challenge yourself to double it.

Back in January 2024, I decided to revive my LinkedIn account by writing 100 short-form posts. I started with one post a week, then two, then three, and settled with one post per day, every day. Fear of writing? Gone!

If you write every day, you will hit 100 posts in about three months. The fear of writing and being exposed will disappear.

2. Schedule your posts

Otherwise, after hours of crafting a perfect post, you will find yourself with the cursor on the “Post” button hesitant to click it. And you will delay it for tomorrow. And often, tomorrow means never.

Schedule your posts, forget about them, and come back the next day.

3. Turn off email notifications

LinkedIn (and any other social media company) will try to keep you on their platform.

They will trick you with all kinds of emails. Someone posted. Someone commented. “Someone on LinkedIn viewed your profile.” Really, LinkedIn?

Turn off all email notifications and continue with your day. Otherwise, you’ll be refreshing and refreshing your browser tab and checking your email, wondering why nobody has liked or commented on your first masterpieces.

4. Understand Sturgeon’s law

90% of everything is crap. That’s Sturgeon’s law.

That’s not to discourage you. It’s to lower your expectations when writing for the first time. 90% of everything is crap. Your first posts will be in that 90%. Your first posts will be far from perfect.

Keep writing and keep improving.

I wrote my first blog post back in 2018. And “post” is a strong word. It was a word vomit. I dumped a bunch of words into a document and published it online. I still have that first post unedited to remind me how I started.

Same story with my first LinkedIn post. I made all LinkedIn sins possible in a single post. Only added an external link. Zero formatting for mobile devices. Lots of hashtags.

If after writing for months, you don’t cringe when reading your first posts, you haven’t improved much.

5. Remember the 30/30/30 rule

No matter what you do:

30% of people will love it.
Another 30% will hate it.
And another 30% won’t even care.

I learned that reading “Choose Yourself” by James Altucher.

Write for your 30% and forget about the other 60%.

6. Think of writing like buying lottery tickets

Would you expect to win the lottery the first time you buy a ticket? Nope!

Writing is the same. Every time you hit “Post,” you’re buying a lottery ticket. If you don’t win today, you buy another ticket tomorrow. If your post didn’t get the likes you wanted, there’s a chance it will next day.

Keep publishing.

7. Make it about business, career, or work

Every social network has its own vibe.

LinkedIn isn’t the exception. If LinkedIn were a person, he would be a 30-year-old office worker wearing a suit and minding his language because his boss or future boss is watching.

Everything you write on LinkedIn make it about work, business, and careers.

If you’re not sure what to write about, share:

Lessons from your last job
Lessons from your best boss
The best book you have read
The best course you have taken
Lessons you wish you knew before starting your job

Share anything you wish you knew two years ago about your work or career.

You don’t have to share personal details or post selfies. Don’t publish what you wouldn’t publish in a local newspaper or niche magazine.

8. Be a journalist

What should I write about if I’m not an expert? Don’t let that thought stop you.

Don’t try to be an expert. Who’s an expert anyway? Share what you have learned and what you’re learning. Show your work.

Don’t create, document. Imagine you’re a journalist with a part-time job doing whatever you’re doing now.

9. Find a writing buddy

Writing your first posts can feel lonely. Probably, only your coworkers will like them when they log in to LinkedIn once every full moon or when they’re looking for a new job.

Find someone in the same journey as you and work together.

Parting Thought

Your first posts are the most challenging. Going from zero to one is the hardest part. Don’t be afraid of hitting “Post” or “Schedule.” The more you hit it, the less scary it becomes.

No matter what you write about or where you write, an online presence is the new CV and portfolio. And LinkedIn is a good place to start. Safe and professional. The boss is watching, remember?

Take a deep breath and write your first post. Commit to your next 20, 30, or even 100 posts and see what opportunities they bring.

Who Gets Promoted Higher and Faster at Work?

2024-12-01T00:00:00+00:00

It’s not the best coder. It’s not the one who cranks out more pull requests or lines of code.

The one who gets promoted higher and faster is the one with the best soft skills. The best communicator. The one who’s best at explaining complex subjects to non-tech people. The best at dealing with people.

The best coders are left alone to continue cranking out code in a corner. “Ok, kid. When will you have your PR ready?”

And when the best coders, with poor soft skills, are put in charge of teams, projects tend to go sideways. They fail to communicate expectations, provide context, and coordinate people. They continue thinking in terms of lines of code and pull requests, not in team dynamics.

Start improving your soft skills by reading “How to Make Friends and Influence People.”

If you could take away just one lesson from that book: never tell anyone he’s wrong.

This Is Why We Don't Test Private Methods

2024-11-30T00:00:00+00:00

Trying to test private methods causes a lot of confusion.

That’s a common question we all have made when finding unit testing for the first time. These days, I found that very same question on Reddit:

Can someone explain to me why unit testing our private methods is bad?

Because we don’t want to break encapsulation.

If you have a private method, how are you going to call it from a test class or method? It’s private. You can only access it from inside the same class. That’s the whole point of access modifiers: restricting access to the fields and properties that hold the internal state of a class.

And please don’t make your private methods public and static to call them directly inside unit tests. They’re private for a reason, right? We don’t want the rest of your code to use them directly.

Exposing internals is the most common mistake when writing tests. I’ve seen it and fixed it before.

Let’s take the HasAdmin() method from the question as an example,

private bool HasAdmin(List<string> relations, bool hasPermission)
{
    // Beep, beep, boop...
}

Unless HasAdmin() has 0 references—if that’s the case, you should remove it—another method from the same class is calling it. And you can trace the chain of method calls back to a public method.

HasAdmin(), or any other private method down in the chain of method calls, is changing something that you can observe from public methods. Probably it’s affecting a return value or changing an internal state you can inspect with getters. That’s what you should test instead.

To test HasAdmin(), create a User object with the right relations and permissions, call the public methods you have, and check what should change when your user is an admin or not. Maybe you return additional data only admins can access or finish an action without throwing a UnauthorizedAccessException.

You test private methods indirectly while testing the observable behavior exposed through public methods.

Et voilà!

To read more about unit testing, check how to write your first unit test in C# with MSTest and four common mistakes when writing your first unit tests. Don’t miss the rest of the Unit Testing 101 series.

Always Be Reading. But Reading More Isn't Always the Answer

2024-11-29T00:00:00+00:00

Before finding “The Almanack of Naval Ravikant,” I was a ferocious reader.

I was in the “let’s read as many books as we can” team. By pure FOMO, I was trying to follow YouTube trends like “I read 9,999 books about money, here’s what I learned” and the mantra “read one book per week.”

But out of dozens of books I had read, I didn’t remember reading some of them, even when I had notes. I kept one or two ideas from those books in the back of my head but I couldn’t trace them back to where I found them.

Then I found Naval’s reading strategy. Ironically, by reading another book.

Instead of reading as many books as possible, he reads and rereads a few good ones. The ones that have passed the test of time. He meditates on their lessons, acts on them, and then he uses X/Twitter to take public notes.

Naval’s reading strategy changed my mind about reading:

I don’t have to read books from cover to cover. I can jump straight to a chapter or section to find an answer.
I can leave books unfinished. For someone trying to increase a book count, leaving books unfinished made it hard to count. If I read only half of the book, should I add 0.5 to my tally?
It’s OK to reread books. Again, rereading didn’t contribute to my increasing book count.

And more important than reading to increase a book count is acting on what we read. Remember, passive learning is just entertainment.

Once you read a book, write 10 lessons you learned from that book, and find one lesson you can act on immediately. That’s more valuable than a large book count without any taking any action.

Find Your Producer's Switch

2024-11-28T00:00:00+00:00

That’s Leland Sklar’s strategy, a well-known bass guitar player and session musician. He’s appeared on over 2,000 albums, based on his Wikipedia profile.

While recording in a studio, if a director asked him to change the sound, he simply turned on or off a fake switch and continued playing.

This is what he said during an interview for Guitar World:

“If I’m on a session and the producer asks me to get a different sound, I make sure he sees me flip this switch and then I just change my hand position a bit. There are no wires or anything that go to this switch. It’s a placebo, but it’s saved me a lot of grief in the studio.”

That’s genius!

What would be a director’s switch for coders? A typo in a variable name, missing brackets on 1-line conditionals, misaligned elements on a screen, writing SELECT * instead of SELECT with a list of columns.

What would you add?

The Easiest Way to Be Ignored When Communicating at Work

2024-11-27T00:00:00+00:00

Only send “Hello, how are you?” in Teams or Slack at work.

You’ll get ignored immediately. Especially if you’re working in a remote team with people all over the world. And especially if you’re reaching out to a busy manager or executive.

This is how that “Hello, how are you?” conversation will look:

Hello, how are you?
…
Good, thanks. And you?
…
Good too, thanks.
Hey, I just wanted…

But, what if your recipient is on the other side of the world? 24 hours could pass between each message. And for sure, you don’t want to wait 48 hours to start the real conversation.

While working remotely at a past job, I used nohello.net as my Slack status. That page shows a fake “hello, how are you?” conversation, getting ignored. And I still got “Hello, how are you?” messages. Arrrggg!

Would you send an email saying just “Hello, how are you” at work?

I know you wouldn’t. Then, why do the same on Slack or Teams at work?

Next time you want to reach out to someone at work:

Don’t send “Hello, how are you?” Say hi and in the same message, without waiting for an answer, say what you really want to say.

That should be “Remote Working 101” when onboarding new team members at any remote company.

Did You Have a Mentor, and Did It Help You?

2024-11-26T00:00:00+00:00

That’s question I found on dev.to. Here’s my full answer:

I’ve had mentors. But, not formally and without the label.

I can pinpoint two or three people in my career that were like “mentors.”

At a past job, I had the chance to work next to my team architects and learned a lot from them. From the value of reading other people’s code to rejecting requests politely. Here are some of those lessons, by the way.

And at another job, one day I decided to reach out to my boss’ boss with genuine questions, not related to the job. He was open and kind enough to answer them. He liked reading books too and we connected on that. From that point, we started to have 1-1s outside the usual meetings. He recommended a long list of books to me.

If you’re looking for a mentor, don’t ask anyone to “be your mentor.” That would imply commitment from one side. Most of the time, for free.

Instead of asking someone “to be your mentor”:

Approach him with genuine questions: Bring your own challenges and how you’re trying to face them. Ask what he would do if he were in your shoes.
Show interest in him: Ask your “not-mentor” about his career progression and choices. People like talking about themselves.
Help him somehow too: When I found books my not-mentor would like, I also brought them to our conversations.
Show you’re taking action on the advice or input you’re given: I followed up with my not-mentor, sharing lessons I learned from the books he recommended to me.

With those four steps, you will be in a mentorship—without even realizing it.

But, don’t worry if you don’t have a mentor or can’t find one.

Mentors are everywhere. The good thing is you don’t have to meet them. 200-500 books are a good mentor. I learned that from James Altucher, a mentor I haven’t met.

How I'd Learn a Language for Work From Scratch

2024-11-25T00:00:00+00:00

It took me two years to learn English.

And by “learning English” I mean, a traditional language school gave me a signed piece of paper that says I speak English. After two years, lots of repeat-after-me sessions and grammar exercises, someone finally said I was able to speak English.

I didn’t start learning English from scratch. We’re taking English classes in school since kindergarten, probably.

But if I had to start from almost scratch to learn a language for work, here’s what I’d do:

With AI

Make a list of common situations at work: Daily meetings, 1-1s, or retrospectives.
Ask ChatGPT or Copilot to generate short conversations or stories for those situations using the most common words. For example, a daily meeting where you report that you’re stuck with a task.
Use elevenlabs or any other text-to-speech tool to turn those conversations into spoken words.
Rinse and repeat.

With YouTube

Take a beginner’s course on a subject you already know. In your target language, of course. The goal is not to learn that particular subject but to learn new vocabulary.
Turn the course subtitles or script into phrases to assemble and interchange.
Rinse and repeat.

Et voilà!

In a Couple of Decades, There Won't Be Many People Who Can Write

2024-11-24T00:00:00+00:00

There will only be writes and write-nots.

That’s Paul Graham’s prediction about the future of writing in the days of AI.

Here are my comments on Paul Graham’s post:

1. “To write well you have to think clearly, and thinking clearly is hard”

Clear thinking is the most important reason to write. You need to order your thoughts before putting them on paper or in a document.

If you know how to write and how to speak in public, you’re unstoppable. I heard that from Jordan Peterson somewhere on YouTube.

Write to think and don’t outsource your thinking.

2. “Writing pervades many jobs”

That’s true for us, coders and software engineers too. Writing is everywhere in our software projects. From README files to user stories to product announcements.

And, the higher up you go, it’s less about coding and more about communication. And except for meetings, you’ll spend more time writing than coding.

3. “Almost all pressure to write has dissipated”

Sure, AI can generate blog posts, sales pages, and any other form of writing.

But, by design, AI generates average writing. That’s its goal. We can tell it by looking at the opening line of any AI-generated text. “In the realm of…” or “In the world of…” Nothing screams AI more than that.

AI will bring more average content. We’re already seeing it. Try searching anything in Google these days.

The printing press didn’t kill books. Social networks didn’t kill bars. Instragram didn’t kill photography.

AI won’t kill writing. AI will only make writing more valuable than ever.

Big Problems Demand Small Solutions

2024-11-23T00:00:00+00:00

That was what Seth Godin answered during an interview with Jim Kwik for the Kwik Brain podcast. Jim asked him about mindset shifts for people stuck in the ideation phase, struggling to take action.

Then Seth expanded his answer by saying:

“Let’s start with a small solution first…Let’s figure out what’s the smallest habit change that would lead you to create the conditions for the system to support you in where you’re going.”

Seth used back pain as an example. Before going through back surgery, we should change shoes, lose weight, and walk. Those steps require 10 minutes a day. Less effort and commitment than surgery.

I connect that idea with James Altucher’s Daily Practice. By doing something every day for our body, mind, and spirit, we’re creating the conditions to support change in our lives.

Everybody Has An Accent. And That's Okay

2024-11-22T00:00:00+00:00

In professional settings, native speakers aren’t the ones who reject non-native speakers by their speaking skills. Other non-native speakers are.

The other day I referred a friend (with good English skills. B2, probably) to the same software agency I was working with. He got rejected. The recruiter (another non-native speaker) rejected him because he had “a strong accent like someone from India.”

Arrrggg! You know what…

Everybody has an accent.

I have an accent, even when speaking my native language. There’s no such thing as a neutral accent, maybe only on TV and in films.

The purpose of learning a second language is communication, not perfection.

Fluency is about connecting with others, not about making 0 mistakes. And, at the end of the day, nobody speaks perfectly in any language.

A Simple Way to Start Your Creative Journey? Put Your Fingerprint on Something Every Day

2024-11-21T00:00:00+00:00

There are 7 billion people and 7 billion unique fingerprints.

This means that anything you put your fingerprint on is unique.

To start your creative journey, recreate something you like, by adding or subtracting your own taste. You will put your fingerprint on it. You will make it unique.

I’m putting my fingerprint on this idea. I found it in Reinvent Yourself by James Altucher. He found it somewhere else. He put his fingerprint on it and now I’m putting mine.

That relieves the pressure of coming up with something original. Just put your fingerprint on something.

You find a quote? Put your fingerprint on it by rephrasing it and adding your own taste.

You find an interesting book passage? Put your fingerprint on it by sharing it along with a story.

Sooner or later, people will find your “fingerprinted” versions and follow your work by your own fingerprints.

Take the challenge of putting your fingerprint on something every day. I’m putting my fingerprint on a corner of the Internet with every post.

Read 500 Books About a Subject to Reinvent Yourself

2024-11-20T00:00:00+00:00

What is “it”? How do I know what I should do?

Whatever area you feel like reading 500 books about. Go to the bookstore and find it. If you get bored three months later go back to the bookstore.

That’s from “Reinvent Yourself” by James Altucher.

When he was bankrupt, to get back up again, he started to read 500 books about money. He recommends doing the same.

But I haven’t read 500 books in my life, let alone in one particular subject. Not even about software engineering and programming where I’ve put close to 10,000 hours of practice. I’ve read maybe a couple dozen books about programming and coding.

Let’s say we read 1 book per week. That’s 52 books per year. And that’s ~10 years of reading to reach 500 books. Or less if we choose not to read some books from cover to cover.

An easier alternative is to read 3 books about a subject to stay ahead of the 90%. That’s from The 4-Hour Work Week. That’s way easier. And definitely, anyone can read more than 3 books about a subject. That’s the rule I’ve been following so far to learn new subjects.

Is it better to go all in on a subject with 500 books or mix subjects in between? Don’t know.

The first subject to read 500 books about should be meta-learning, learning how to learn. That would be the groundwork for any future endeavor or experiment.

If after some books we realize we’re not interested in that subject anymore, we’re free to jump to another subject and start from “0 books read” again.

Why Learn a (Foreign) Language — Even When We Have AI and Many Other Tools These Days

2024-11-19T00:00:00+00:00

Apart from monetary reasons—learning a second language helped me double my last salary as a full-time employee:

1. Because AI can’t replace human connection

From “How to Win Friends and Influence People,” the trick to having good conversations is to make them about the other person.

And the easiest way to make conversations about the other person is to use a few words in their native language. Hi, bye, yes/no, thanks, and please will create a connection immediately.

In a past job, I learned a few words in Russian to connect with my coworkers. It was funny when they forgot to use English in shared chats and a simple “English, please” in Russian (anglijski, pozhaluysta) broke the ice.

AI can’t replace smiles when you greet people in their native language.

2. Because AI can’t replace the excitement of decoding what was once gibberish

My German is limited to survival phrases.

But the last time I visited my best friend’s parents in Europe, while taking a walk around a park, someone asked my best friend’s mom in German: “Ist das dein Sohn?” (Is that your son?) My inner child couldn’t avoid jumping in excitement. I got that!

That’s one of the most exciting moments of learning a language. Passing from hearing noise to decoding and understanding sounds.

An “I got that!” is priceless.

3. Because AI can’t reshape our brains and makes us think different.

Languages shape our thinking.

When we learn a new language, we’re creating new connections in our brain. Think of learning a language with a new script or with sounds that don’t exist in your native language. Every language rewires our brain.

These new connections make us think and behave differently.

We’re a new person with every language we learn. AI can’t replace that. Yet?

Coders Often Don't Get To Solve Problems

2024-11-18T00:00:00+00:00

Coding is about solving problems with automation.

The most interesting and funniest part is figuring out a coding solution to a problem.

But often, by the time a coder is involved, all the big picture thinking and decision making have already been made, killing all the fun.

Somebody else already talked to customers. Somebody else decided what to do and how long it will take. Somebody else divided the work into milestones. No software engineers or people with boots on the ground were involved.

At a past job, our VP, probably to look smart in front of other executives, promised to finish in one month a project that needed at least 6 months. He picked a number out of thin air without asking anyone.

Coders are only involved to turn JIRA tickets into lines of code.

The most rewarding and funniest projects have been when I have all the context around customer needs and am involved in most of the design and architecture decisions.

If someone else talks to customers and writes specs and we, as coders, only turn those specs into code, we’ll be out of business soon. AI will replace us all.

The Best Time To Look for a New Job

2024-11-17T00:00:00+00:00

It’s not when you’re “let go.”

The best time to look for a job is when you don’t need one.

You’re not desperate to pick anything to just pay the bills. You’re in a better position to negotiate. You can use your new offer as leverage in your current job. You don’t have anything to loose.

That was a lesson I shared with a group of friends and ex-coworkers the last time we met to catch up.

After the usual questions, where you’re working these days and how you’re feeling in your new role or job, one of our ex-coworkers answered he felt good in his new role after a couple of years and he wasn’t looking for something new. Then I shared that lesson. I wish I knew it earlier.

It doesn’t matter if you want to leave your current job or not. Don’t outsource your career decisions to your boss or something else. At least, set a direction for your career and be conscious about the jobs you pick.

For some years, I make the mistake of outsourcing my career choices.

A couple of years ago, I knew it was time to leave my job, but instead of making a hard decision, I asked for a raise. If they refused to give me a raise, that was the sign to leave. And, surprised, surprise, I got the pay raise. Arrggg!

Vacations and pay raises won’t change an unfulfilling job. They will only move a death sentence further away, like kicking a can.

That taught me that the best time to look for a new job is not right after a layoff, it’s when you don’t need a new job.

Two Quotes I'm Trying to Live By

2024-11-16T00:00:00+00:00

#1. “I’m a simple man making his way through the galaxy, like my father before me”

If you’re a Star Wars fan, you recognize that phrase. That’s by Boba Fett from The Mandalorian.

We’re all here trying to figure out our paths. Some are more intentional about it, others are not. Some have found it, others are still searching.

Every stage in life will bring its own challenges and paths to figure out.

#2. “The minute you learn something, teach it”

That’s from Show Your Work by Austen Kleon. “A book for people who hate the very idea of self promotion.”

That phrase puts into words one of my core values.

It has kept my curious inner child alive. Once I find something new, my sense of curiosity or inner child, wants to share it with somebody else. Most of the time, by writing about it.

When you teach what you learn, you have the chance of learning it twice.

Learn To Talk to Non-Tech People in Your Team

2024-11-15T00:00:00+00:00

Want to stand out as a coder? Learn to talk to non-technical people.

That’s a crucial skill to master for every coder, even if you’re not on the path to be a team leader.

Jargon won’t make you look smarter

We often take pride in using technical jargon. It makes us feel smart.

But true mastery is explaining things to people outside our fields.

At a previous team, we found a bug when syncing restaurant bills to room charges. It took us a long time to fix it. It was a serious issue.

The next day, we had “that” conversation in our daily meeting.

The team lead started to explain: “API, background processor, eventual consistency, optimistic concurrency…“ He used every bit of jargon he knew to justify our 1- or 2-day delay.

To our PM and other non-tech people, it sounded like the alien language from The Arrival. You could tell by their confused and “what are you talking about” faces.

Speak their language, not yours

In that daily meeting, a simpler “somebody could walk away without paying their restaurant bills. And nobody here wants to pay for that” would have finished the conversation with some laughs and a point made.

Always make it about the person listening. Often our job as coders is being interpreters: from business language to technical language and vice-versa.

Try explaining your current project to a friend who doesn’t code, using their own words. If they get it, you’re winning.

Explaining complex ideas simply is one of the most underrated skills to stand out as a coder. Truth is, the senior you get, the less it’s about coding and the more about communication. That’s why I made clear communication one of the strategies in my book, Street-Smart Coding: 30 Ways to Get Better at Coding. That’s the practical guide I wish I had on my journey from junior to senior.

Get your copy of Street-Smart Coding here

Getting Rid of Nulls Is Indeed A Good Idea

2024-11-14T00:00:00+00:00

These days I found a Medium article titled: Why Eliminating NULLs From Your Code Will Not Make Your App Better.

Its point is that when we stop using null, we replace checking for null with checking for a default value or a wrapper like Result. And there’s no major gain.

But there is a gain when eliminating null

The advantage of returning a wrapper like Option or Result instead of null is making the implicit explicit.

Instead of getting a NullReferenceException and saying “ooops, that method returned null,” we look at a method signature and say “Hey, that method might return null. We’re better off checking for that.”

That’s Method Signature Honesty. When the parameters and return types of a method show what it does, even for edge cases.

For example, what does this method do?

Movie GetMovieById(int movieId);

What if there was no movie found? What if there was more than one? Does the method throw an exception? Returns null? Returns a Movie.Empty? We can’t tell just by looking at the signature.

But what about?

Option<Movie> GetMovieById(int movieId);
// or
Result<Movie, MovieError> GetMovieById(int movieId);

At least, it’s obvious from that signature that there’s a special case we need to handle. It’s up to the caller to decide what to do with it.

The original article has a point that replacing a null checking like,

var movie = GetMovieById(someId);
if (movie != null)
{
    // Do something here
}

With,

var result = GetMovieById(someId)
                 .Map(movie => /* Do something here */);

// And at some point later:
result.OrElse(() => /* Nothing found. Do something else here */);

is a design choice. For C#, the first one looks like more “native.”

In either case, at some point, we have to convert the absence of data (either a null or a None) to something else like a status code or error message.

C# doesn’t have an explicit type to avoid null

C# didn’t take the wrapper route and introduced nullable references instead.

With nullable references turned on, all our object references are not null by default. If we want a reference to accept null, we should annotate the type with a ?. The same way we do it for nullable ints.

Movie? GetMovieById(int movieId);
//  ^^^
// It might be null.

Yes, that name is kind of misleading. It should be “not nullable” references.

That’s a feature we should turn on and make all nullable warnings as errors.

With Option, Result, or nullable references, we make our method signatures honest. That’s already a gain.

Join my course C# NullReferenceException Demystified on Udemy and learn the principles, features, and strategies to avoid this exception in just 1 hour and 5 minutes.

Two Blogging Tips to Write More

2024-11-13T00:00:00+00:00

Inspired by Seth Godin and Herbert Lui, I looked up other people writing daily on their personal blogs and found these two pieces of advice:

1. If it’s longer than a Tweet, 280 characters, it can be a post.

That’s from Mike Crittenden’s 2 months of daily blogging.

Post length doesn’t matter if we transmit the message clearly in a few words. A post can simply be a headline and a main idea. Don’t feel guilty about short posts.

Credits to Rafał Pastuszak.

A reaction post, even a short one, is calmer and thoughtful. Often, we write most comment in “the heat” of reading or without even reading the entire piece.

That sounds like one tip to never run of writing ideas and a way to preserve keystrokes.

Two Alternatives to Assertion Messages — and Two Ideas if You Do Want To Keep Them

2024-11-12T00:00:00+00:00

I got this question from Ankush on my contact page:

“I want to override the Assert method to avoid using Assert.True without a failure message. How can I achieve it?”

Here are 2 alternatives to assertion messages and 2 ideas if you do want them:

1. Don’t use assertion messages. Write better test names instead.

Test naming conventions, like the UnitOfWork_Scenario_Result, impose some order and structure to names. You won’t have that inside assertion messages.

If you don’t have too many assertions in your tests, with a good test name it’s easy to figure out what failed and why.

2. Use assertion libraries with better messages.

Like FluentAssertions or Shoudly. They have clearer and more verbose messages when an assertion fails.

Here’s what MSTest, FluentAssertions, and Shoudly show when an assertion fails:

[TestClass]
public class UnitTest1
{
    [TestMethod]
    public void ADummyTestToShowFailureMessages()
    {
        var anyBool = false;

        // With MSTest
        Assert.IsTrue(anyBool);
        // Message:
        // Assert.IsTrue failed.

        // With FluentAssertions
        anyBool.Should().BeTrue();
        //  Message:
        // Expected anyBool to be True, but found False.

        // With Shouldly
        anyBool.ShouldBe(true);
        //   Message: 
        // Test method AssertionLibraries.UnitTest1.ADummyTestToShowFailureMessages threw exception: 
        // Shouldly.ShouldAssertException: anyBool
        //    should be
        // True
        //    but was
        // False
    }
}

That’s if you want assertion messages for the lack of good failure messages.

Now, if you do want assertion messages for whatever reason:

3. Write custom assertion methods

Wrap MSTest, NUnit, XUnit or the testing library you’re using inside custom methods with the assertion messages as required parameters. Like,

AcmeCorp.CustomAssert.IsTrue(actual, yourMessageHereAsARequiredParam);

If you’re doing code reviews, that’s something to share with your team and enforce during reviews.

4. Create a custom analyzer to check the absence of assertion messages

Code reviews can be daunting. And even if all test methods in your test suite have assertion messages, anyone can decide not to use them.

Automate the boring part with an analyzer that warns you if you’re not passing a message to every assertion.

Here’s an analyzer from xunit.analyzer. That’s a good place to start.

Voilà!

To read more about assertions, check how to write better assertions and how to write custom Assertions to improve your tests. Don’t miss the rest of my Unit Testing 101 series.

9 Lessons I Learned After Following James Altucher's Work

2024-11-11T00:00:00+00:00

It’s hard to define what James Altucher does.

He’s an investor, podcaster, writer, chess player, and comedian. That’s only what he shares on podcast interviews. Who knows what his next career will be.

I found James Altucher’s work by pure accident. I was looking for ways to get better at writing and found the advice of writing 10 headlines a day. That was inspired by James’ ideas.

Since then, I’ve been binge-watching and binge-reading James Altucher’s work in Quora, Medium, and his own website.

A guy that has made millions and lost it all, not just once but at least twice has a lot to teach. Here is what I’ve learned from him.

1. If you don’t know what to do with your life, start with your health

That’s what I’ve been doing after losing my last job. An end and a start of something new that I still don’t know what it will be.

Uncertainty in a single word. I’ve been questioning my life choices since then.

When facing those moments of uncertainty, James teaches to start with your health and get 1% better every day. That means doing something for your body, mind, and spirit. That’s what he calls the “Daily Practice.”

Since then, my daily practice has been:

Starting the day with a glass of water,
Working out,
Cutting sugar and processed foods,
Having a moment of silence, and
Writing.

2. Write 10 ideas a day

This is part of the 1% daily improvement: Do something creative. Every. Day.

Turn yourself into an idea machine by writing 10 ideas a day.

After losing it all for the first time, James bought cheap waiter’s pads and started to write down ideas to get up again. He then wrote ideas for others and gave them away for free. Those ideas brought new opportunities for him.

Write 10 ideas a day or your idea muscle will atrophy.

3. Always be learning from everyone, then write about it

Everyone and every situation around us have something to teach us. Notice it and write about it. That could be part of your 10-ideas-a-day practice.

That’s what I’m doing right now by writing what I’ve learned from James.

4. You don’t need to meet your mentors

You need mentors in your life. But you don’t have to meet them.

I don’t know James in the real world. I will probably never meet him. But he has inspired me a lot since I’ve been following his work. He’s a virtual mentor.

Imagine that your mentor has already passed away and to learn from him, you have to follow the clues he left in his work. Find someone who inspires you and read his books and writings.

The best mentors are books.

5. Find your Plus, Equal, and Minus

To get better at any skill, you don’t only need mentors. You need to find your Plus, Equal, and Minus.

Plus is the people that inspire you. Your teachers, mentors, and favorite authors. James is one of those. Tim Denning, Dan Koe, and Nicolas Cole are some of my Plus in the writing space.

Equal is the people taking the same path with you. Your peers, coworkers, and friends. These people challenge you to continue improving.

Minus is the people you can teach. People one step behind the path you’re taking.

6. Making, keeping, and growing money are different skills

James lost it all multiple times. He shares that he was good at making money, but not at keeping it and growing it. He made the wrong investments and bad purchases.

Money is a totally different set of skills to master.

7. Reinvent yourself every 5 years

That’s from “Reinvent Yourself,” one of James’ books. And that’s from 2017 when AI wasn’t mainstream.

These days the need for reinvention is urgent. Our world is changing dramatically fast. Relying on the same skills we learned five years ago is too risky.

Reinvention means finding new sources of income.

To start your reinvention, start reading 500 books on a subject. If you don’t know where to start, find a book you like, read it, and read another 499 about the same subject. You’re free to drop it and start all over again.

8. Have multiple sources of joy

That’s from an episode of the podcast School of Greatness on YouTube.

During that episode, James shared he had businesses, writing, comedy, and chess. When things didn’t go as expected in one area, he went to another one.

I wish I had learned that before.

For some time, I only tried to find joy in my day job. That was a painful mistake. When things went sideways, I got burned out. I had stopped exercising and doing any of my hobbies. Eventually, all of that made me fall sick. Literally.

Lesson learned the hard way! Have multiple sources of joy.

9. Be like Google, my friend

Google is the go-to resource for information. (Until AI takes over)

We don’t spend too much time on Google. We ask questions and it takes us to somewhere else. In spite of that, we keep going back to Google and it’s one of the most valuable companies in the world. That’s the Google effect.

Be like Google. Be a bank. Be the source of information. Connect people with answers.

Parting Thought

James has a captivating and inspiring story. He has made millions and lost it all, and he’s open about it. From a Computer Science major to be someone difficult to put in a box and label, with multiple careers and skills.

James’ story teaches you can choose yourself, reinvent yourself, and skip the lines.

It's Better To Be Poor Doing Something You Love, Than To Be Rich Doing Something You Hate

2024-11-10T00:00:00+00:00

That’s a quote I found last week while watching a conversation between Tom Bilyeu and Rich Roll on YouTube. They were discussing Tom’s mindset changes and work history.

That quote is an invitation to reflect what we’re willing to give up in exchange for money.

It reflects what I’ve been going through since last year.

In 2023, I hit rock-bottom. But it wasn’t a money thing. In fact, I was making the most money I had made in my career as a software engineer.

Things were good until they weren’t.

I woke up and didn’t feel the drive to show up to work. I wasn’t learning and having fun. I was just for the money.

Every Sunday evening I felt anxious anticipating next Monday routine. Another daily meeting, another JIRA ticket, another Pull Request…Arrggg!

I knew I needed to do something but I was too comfortable and afraid of taking risks. I tried to control things around me. And I failed at that.

All my frustration lead to anger and resentment. It made sick literally.

That’s why when I was “let go” at the begging of 2024, I felt relieved.

I was scared of making a change by myself. And life, God, or the Universe gave me a little “push.”

I was fortunate to have enough “f*ck-you” money to finance my living expenses all these months.

Now, I’m reinventing my career.

I’m taking care of my health. I read and write. I’ve been recording some coding courses and doing some freelancing on the side.

I haven’t figured out everything yet. I need a way to make money more consistently. I need to refill my “f*ck-you” money pockets. I don’t know when I will need them again.

Definitely, Mondays are not the same when you wake up to do something you love.

Your Keystrokes Are Limited, Here's How You Preserve Them

2024-11-09T00:00:00+00:00

Preserve your keystrokes. They’re limited.

That’s a piece of advice I learned from one of Scott Hanslman’s talks about productivity.

This isn’t an invitation to write less or write shorter content. It’s an invitation to make private knowledge public.

Often valuable knowledge and lessons die in email threads or Slack channels. Apart from the original recipients, nobody else can read them. That’s how you “waste” your keystrokes.

Make those private email threads or Slack messages public by turning them into wiki entries, tutorials, or blog posts. That’s how you preserve your keystrokes.

I’m answering almost all my questions in public to preserve my keystrokes.

The other day, one of my email subscribers replied to one of my emails with a question about writing. I replied and then turned that reply into a post.

Another day, a reader contacted me after going through my takeaways from Ultralearning. And again, I expanded my reply into a separate post.

Don’t let knowledge die in private channels. Preserve your keystrokes and share a link to a public writing instead.

This Is the Real Reason Why Coders (and Everyone Else) Should Write

2024-11-08T00:00:00+00:00

Don’t write to attract recruiters or create a brand.

Sure. Those are benefits of writing online. When we write online, good and unexpected things happen.

By writing online, we gain followers, build a brand, attract opportunities, and skip hiring lines.

By luck or accident, I made my first internet money writing, because I showed some of my posts.

But the real reason to write online is:

Clear thinking.

Write to think clearly. Write to formulate your ideas coherently, with no fluff.

Before you write, you have to put your thoughts in order. You need a message. You need structure. You need a reader persona.

That’s more valuable than recruiters knocking at your door with “life-changing opportunities for well-known companies in the tech sector.”

Writing is the most valuable and transferable skill you can learn.

From Now On Here's How I'm Answering: What Stocks Should I Buy?

2024-11-07T00:00:00+00:00

“What companies should I buy in my brokerage account?”

That was a question that popped up in a Whatsapp group with some of my ex-coworkers and colleagues. In fact, it was not the first time that question popped up. From the same person.

Here’s what I answered:

“If you don’t want to be a full-time investor, go with a broad market index fund. If you don’t know which one, pick any that tracks the S&P500, like VOO or SPY.”

But I was wrong.

Not that my answer was wrong. I’m not a money expert. But I’ve read some money books and changed my mind about money. I realized that the question itself shows something more: not doing the homework and outsourcing thinking to somebody else.

It’s like asking: “Do you know anyone I should marry?”

You’re completely at the good intentions of the other person. He should guess the traits you’re looking for in a partner and go through all his relatives, friends, and acquaintances to see if there’s anyone with those traits. He misses lots of things to answer that question.

I’m not answering, “what companies I should buy in ?" anymore.

The right answer is:

Don’t ask your poor friends for money advice. The most expensive advice is the one you get for free.
If you don’t know what to invest in, start investing in yourself, so you can decide on your own where to put your money.
Never let somebody else tell you what to do with your own money.

The only thing I can share is: “Here is what I do with my money…”

“Ask the jeweler for jewelry advice.” — The Richest Man in Babylon

That’s how I’m answering that question in the future.

LinkedIn Shouldn't Have a Desperate Frame and You Shouldn't Look That Needy

2024-11-06T00:00:00+00:00

Hiring in 2024 has been slow.

I know! I was “let go” in February and tried to find a job for a couple of months until I gave up and decided to jump solo.

AI, high interest rates, or anything else have changed the job market. There aren’t as many open applications as years before. And the few ones opened get flooded with applications. Pure radio silence after you apply.

Before, you only needed the right keywords in your LinkedIn headline to get recruiters offering you “life-changing opportunities.” I cringe while typing those words and remembering all those messages.

Those days seem to be gone.

The other day the LinkedIn algorithm showed me a post of a young designer showing her profile picture around a ribbon that said “Desperate.” It was her idea to complement the “Hiring” and “Open to work” ribbons or photo frames or whatever LinkedIn called them.

(If you wrote that post, I totally understand. I did the same thing in a different way a couple of months ago.)

It’s desperate seeing a bank account going to zero and having bills to pay.

Writing “I’m desperate and need money. Please give me a job” in a LinkedIn post is the equivalent of wearing dirty clothes, growing a beer, and extend your hand in the middle of a busy street.

Nobody is going to give you a job for being desperate and looking needy. Other LinkedIn users aren’t going to take money out of their pockets to help you either.

Instead of giving companies and hiring managers homework and looking desperate and needy, turn around the equation and give away ideas.

For the young designer with the “Desperate” ribbon idea:

Find 10 companies you’d like to work with
Create a brand redesign for each company. Show how you’d change colors, fonts, and logo. Do it like you’re being paid for it.
For each redesign, publish a post showing your redesign and tag the company and the head of the creative team (or a hiring manager or the head of the team that hires designers inside a company)

Even if the companies you’re redesigning don’t reply, others will see your work and skills in action. You don’t have to say “Trust me, I design.” You’re showing your work instead.

After being laid off, I sent my CV to as many places as I could find that needed a code monkey. Even I applied to a FAANG when I rejected that idea early in my career.

Eventually, I got a reply. And after the first contact and a signed agreement, the head of the company told me: “I don’t know where to put you.” I was waiting for the company to close a new client. In the meantime, I gave them homework.

I knocked at their doors and said “Please give me work. I do anything.” That was the implicit message I sent when I filled out an application from in their company page and sent my CV.

I should have knocked at their doors with 10 ideas, like I recently learned from James Altucher.

A professional never begs. And, no. LinkedIn shouldn’t have a “Desperate” ribbon.

Want to Be More Creative? Become an Idea Machine—It'll Change Your Life

2024-11-05T00:00:00+00:00

Writing 10 ideas every day saved James Altucher from bankruptcy and changed his life.

If you don’t know James Altucher’s story: he’s an American investor and author. He sold one of his first businesses for millions and lost everything. Not once, but a couple of times.

In his darkest moments, about to end his life so his family could claim his $4M life insurance, he bought cheap waiter’s pads and started to write ideas to change his life and make money.

In his blog posts, podcast interviews, books, and TED talks, he recommends the same habit:

Become an idea machine by writing 10 ideas a day.

You don’t need to come up with 10 brilliant ideas.

You just need to come up with 10 bad ideas every day. You need to build your idea muscles. Yes, your idea muscles atrophy like any other muscle if you don’t use them.

If you don’t know how to start, write 10 areas you want to write 10 ideas about.

Write 10 ideas to:

Get a pay raise
Get a promotion
Find a better job
Make extra income
Expand your network
Ease your boss’s job
Land your next client
Help your best client
Grow your online presence
Improve your team’s processes

After following this habit for weeks, out of those hundreds of ideas, one will be a decent one. Then, write 10 ideas to execute on that idea.

An idea machine writes ideas for others too and gives them away without expecting anything in return.

Months later after starting to write and give away ideas, James was flying to visit companies and discuss the ideas he gave for free.

After learning about becoming an idea machine, I gave 10 ideas on a LinkedIn comment to a coding non-profit running out of cash. I also DMed the CEO of a SaaS to give him my ideas for his landing page and product documentation. I’m still waiting for my free plane tickets to discuss my ideas though.

Want to change your life? Start writing 10 ideas every day and become an idea machine.

The Day I Realized I Needed to Raise My Rates as a Coder

2024-11-04T00:00:00+00:00

Hourly billing is nuts.

I learned that from Jonathan Starks. Charging by the hour doesn’t encourage productivity. To make more money, you have to work slowly or pad your time sheet. In either case, you’re not being honest.

Even knowing that, I agreed to work as a contractor for a small software agency charging by the hour.

After every task, I couldn’t resist the temptation of looking at my tracking software to see how much I had made in that working session. “I’ve made only $75, I need to pay my bills. Arrrggg!”

But that story started months earlier, after being “let go.”

After the initial moments of relief from a layoff, the anxiety of not having a paycheck made me go into panic mode.

I sent my CV to as many places looking for coding skills as possible. Even to a FAANG, and my overconfidence and lack of preparation made failed.

Out of dozens of applications, only one got me a reply: “Thanks, but we’re not looking. Maybe later.” A polite no.

Months later, they wanted to chat with me.

I wasn’t used to charging by the hour.

As a full-time employee, you receive your monthly paycheck and don’t run those calculations. Maybe HR does, not you. I picked a rate out of thin air based on my last salary.

One ex-coworker suggested that I should go with a lower rate since hiring in 2024 has been slow. AI, high interest rates, or who knows what made the demand for software engineers decrease.

I followed that advice and lowered my rate.

The day of the interview came.

The usual questions: “what do you do?” and “tell me about yourself.” And of course, my hourly rate.

When I asked about my future project, I was told it was an app migration from an ancient tech stack to a newer one and they were looking for someone “cheap” like me to handle the repetitive part.

Ouch! That hurt. Directly in my ego. “Thanks for being honest,” I thought.

I knew I needed to set an aspirational rate (lesson from Naval Ravikant) and escape from the Matrix. That moment reinforced that decision. But my emergency fund was about to run out in a couple of months, so I had to swallow my pride and be the “cheap” one.

How I should have picked my rates

The next time you’re asked about your rates, go with the advice from “The Secrets of Consulting” by Gerald Weinberg:

Give a rate that makes you comfortable either if it’s accepted or not. Avoid the “oh no, I should have charged more” and the “damn, I charged too high.”

Or use a more practical approach:

Slap the other person in the face and say your rate. If he gets offended by the slap, you’re charging too low.

Anyway, like me, you probably need to raise your rates too.

If a Language Learning Forum Were Like a Coding Forum:

2024-11-03T00:00:00+00:00

Question: Guys, how do I say “I love you” in Japanese?

— Japanese? Why don’t you try German? It’s easier in German

— If you want to talk about love, you should try with French

— Yeah, go with French. That’s the language of love

…Question downvoted

— Wait, isn’t Spanish the language of love?

— Guys, the thing is I have this text at work and I need to say that in Japanese

— Really? What kind of job is that? You should talk to your boss and tell him to use a real language for that

— Do you call yourself a language lover and don’t know that?

…Question closed as duplicate.

Passive Learning Is Just Entertainment Unless You Follow These Two Strategies

2024-11-02T00:00:00+00:00

Passive consumption is procrastination in disguise.

If you’re like me, you’ve been watching another YouTube video, reading another book, and consuming online content as procrastination.

Mindless consumption isn’t learning.

Learning should be active. We truly learn when we engage in our learning process. Instead of simply reading or watching pretending to learn, engage with what we’re learning.

Start taking notes by hand

That’s the easiest way to engage with your learning.

Yes, taking notes by hand! When we take notes by hand, we get “physical” like the 80s hit. Touching a pen and feeling the paper create brain connections that reinforce our learning.

Ditch your laptop and go back to pen and paper.

After taking notes, create something new

Taking notes is only the first step.

The best way to truly learn is to create something from what you consume.

Instead of reading to show off a book count, read with intention: answer a question or face a challenge. Once you read, write a summary or explain it to others in your own words.

If you’re a podcast lover, don’t simply listen to the next episode until the end. Write down 3 main points you learned, transcribe your handwritten notes, and share them online.

The next time you find a new programming concept, incorporate that concept into a small project. And, if you’re reading an open-source project, create a simplified version of its main feature to make sure you understand the main decisions and concepts behind it.

And, if you like writing, do copy work. Recreate a piece from a writer you want to imitate. Again by hand. This is an exercise attributed to Benjamin Franklin. After reading a piece, he looked away and tried to rewrite what he read.

Separate the exploration phase where you only gather resources from the engaging phase where you create something new after consuming.

If you listen, you will forget. If you write, you will remember. But if you practice, you won’t forget.

It's Not About Selling. It's About Helping

2024-11-01T00:00:00+00:00

The other day I had a weird DM exchange.

A guy shared a cool LinkedIn tip. I rushed to apply it and DMed him to say thanks for that cool idea. You know I wanted to make friends in the DM.

He continued the conversation. I shared how my LinkedIn journey was going. I told him about my 100-post experiment and my future plans.

After a couple of exchanges, the guy went on sale mode. He had an offering and I could potentially be one client. I got that!

But, he wrote something in the lines of “Truth is I don’t need more clients and I’m fully booked…“ I stopped reading at that point. If he doesn’t need clients, why he was on salesy mode with that line in the first place?

People don’t like those mind tricks. At least I don’t. Those Jedi mind tricks don’t work on me.

I would have rephrased that message like “hey, maybe you don’t help with <insert service here> yet. Once you do, feel free to shoot me a message, I’d be glad to help you. That’s what I do for a living and I have helped more than <insert client count here> people with that.”

It would have booked a call after a message like that. Or at least I wouldn’t have ghosted him.

It’s not about selling, it’s about helping.

The Power of Function Composition — to Find If an Array Is Special

2024-10-30T00:00:00+00:00

Passing the result of a function to another isn’t the only way to compose two functions.

From math classes, we’re used to composing two functions like this compose(f, g) = x => f(g(x)). But it turns out there are more ways.

That’s my main takeaway from the talk “The Power of Function Composition” by Conor Hoekstra at NDC Conference 2024.

Here’s the YouTube recording,

The talk shows how to find if an array is special using languages like Python, Haskell, and other obscure and esoteric ones to show function composition.

These are the lessons I learned, translating some code examples to C#.

A simple solution to find if an array is special

Let’s find if an array is special.

An array is special if every pair of consecutive elements contains two numbers with different parity. For example, [4,3,1,6] isn’t special. It has three pairs: 4,3, 3,1, and 1,6. The second pair has two odd numbers, which makes our array “not special.”

Here’s the LeetCode problem if you want to try it yourself.

And here’s my solution before using any of the new concepts from the talk,

IEnumerable<(int First, int Second)> Pairs(int[] array)
{
    for (int i = 0; i < array.Length - 1; i++)
    {
        yield return (array[i], array[i + 1]);
    }
    // Or simply:
    // return array.Zip(array.Skip(1));
}

bool HasDifferentParity((int First, int Second) pair)
    => pair.First % 2 != pair.Second % 2;

bool IsSpecial(int[] array)
    => Pairs(array).All(HasDifferentParity);

IsSpecial([1, 2, 3, 4]) // true
IsSpecial([4, 3, 1, 6]) // false

It uses Pairs() to generate the pairs of consecutive elements, HasDifferentParity() to find if both numbers in a pair are even or odd, and All() from LINQ. Nothing fancy!

Apart from the “usual” composition, there are other ways of composing functions

Here are some of them, in pseudo-code:

def i(x) = x
def k(x, y) = x
def ki(x, y) = y

def s(f, g) = \x => f(x, g(x))
def b(f, g) = \x => f(g(x)) // <--

def c(f) = \x, y => f(y, x)
def w(f) = \x => f(x, x)

def d(f, g) = \x, y => f(x, g(y))
def b1(f, g) = \x, y => f(g(x, y))
def psi(f, g) = \x, y => f(g(x), g(y)) // <--
def phi(f, g, h) = \x => g(f(x), h(x))

Let’s take a close look at two of them.

b is the composition we all know. It passes the result of the second function to the first one. And psi passes two values to the second function and then calls the first one with both results.

Let’s find if an array is special again, but composing functions

Let’s revisit IsSpecial() but using “psi” this time,

IEnumerable<(int First, int Second)> Pairs(int[] array)
    => array.Zip(array.Skip(1));

bool IsEven(int x) => x % 2 == 0;
bool NotEqual(bool x, bool y) => x != y;

// A more general signature would be:
// Func<T1,T1,T3> Psi<T1, T2, T3>(Func<T2,T2,T3> f, Func<T1,T2> g)
// But to make things easier:
Func<int, int, bool> Psi(Func<bool, bool, bool> f, Func<int, bool> g)
//                   ^^^
    => (x, y) => f(g(x), g(y));

var hasDifferentParity = Psi(NotEqual, IsEven); // <--
bool IsSpecial(int[] array)
    => Pairs(array).All(pair => hasDifferentParity(pair.First, pair.Second));

// or
bool IsSpecial(int[] array)
    => Pairs(array).All(pair => Psi(NotEqual, IsEven)(pair.First, pair.Second));
    //                          ^^^

IsSpecial([1, 2, 3, 4]) // true
IsSpecial([1, 2, 4, 3]) // false

Instead of HasDifferentParity(), it uses Psi(NotEqual, IsEven).

And again, here’s the pseudo-code of psi: psi(f, g) = \x, y => f(g(x), g(y)).

Psi(NotEqual, IsEven) receives two integers, calls IsEven with each of them, and passes both results to NotEqual.

That’s a new way of composition.

Let’s do it the Haskell way using MapAdjacent

From Haskell official docs, MapAdjacent transforms every pair of consecutive elements.

Here’s IsSpecial() one more time, but using MapAdjacent(),

// Pairs, IsEven, NotEqual, and Psi are the same as before...

bool IsSpecial(int[] array)
    => array.Select(IsEven).MapAdjacent(NotEqual).And();

// or
bool IsSpecial(int[] array)
    => array.MapAdjacent(Psi(NotEqual, IsEven)).And();

IsSpecial([1, 2, 3, 4]) // true
IsSpecial([1, 2, 4, 3]) // false

It transforms our array into an array of booleans–if every number is even–with Select(), then finds if every pair of booleans is different with MapAdjacent() and lastly collapses all the results with And().

As an alternative, it uses MapAdjacent() with Psi(NotEqual, IsEven) to avoid using Select() first. This alternative is closer to the previous one with Pairs() and All().

Since we don’t have MapAdjancent() and And(), here are their C# versions,

public static class Enumerable
{
    public static IEnumerable<TResult> MapAdjacent<TSource, TResult>(
            this IEnumerable<TSource> source,
            Func<TSource, TSource, TResult> func)
        => source.Zip(source.Skip(1), (first, second) => func(first, second));

    public static bool And(this IEnumerable<bool> source)
        => source.All(x => x);
}

MapAdjacent() is a wrapper of Zip() and And() is a wrapper of All().

This is one of the talks to replay multiple times if you want to grasp its concepts, since they’re not that common. Also, it covers the same example in other less known languages that I don’t even remember their names.

Since you won’t use those obscure languages, learn the composition part of the talk. It’s mind blowing. In any case, if you want to start with Functional Programming, you’ll need simpler concepts.

Using Lambda Expressions Doesn't Make Your C# Code Functional

2024-10-29T00:00:00+00:00

C# will never become a truly functional language.

Sure, C# is borrowing features from functional languages like records, pattern matching, and switch expressions. But it doesn’t make it a functional language.

At its core, C# is an Object Oriented language — with mutable state baked in. But it doesn’t mean we can make it functional with a few tweaks.

That’s the main takeaway from the talk “Functional Programming on .NET” by Isaac Abraham at NDC Conference 2024.

Here are some other lessons I learned from that talk.

Here are two misconceptions about Functional Programming

1. “It’s difficult”

When we hear “Functional Programming” what comes to mind is obscure jargon like monad, monoids, and endofunctors. They sound like you have to grow a beard to understand them. That scares programmers away from Functional Programming.

2. “I’m already using lambda expressions”

Lambda expressions and other recent features are syntactic sugar to make C# less verbose. Lambda expressions simplify delegates. And we’ve had delegates since C# 1.0 when C# looked way less functional than today.

The truth is functional programming could be simpler and lambda expressions don’t make C# functional.

If lambda expressions and other features don’t make C# functional, what is it then?

Expressions and Immutability.

Expressions mean everything has a result. Think of old-style switch/case statements vs switch expressions. We can assign the result of a switch expression to a variable, but not an old-style switch/case. If it can be assigned to the left of =, it’s an expression.

// This is not an expression
switch (cardBrand)
{
    case "Visa":
        cardType = CardType.Visa;
        break;

    case "Mastercard":
        cardType = CardType.MasterCard;
        break;

    default:
        cardType = CardType.Unknown;
        break;
}

// This is an expression
var cardType = cardBrand switch
{
    "Visa" => CardType.Visa,
    "MasterCard" => CardType.MasterCard,
    _ => CardType.Unknown
};

And immutability means that everything is set for life. Think of records, the init keyword, and private setters.

With these two concepts, to make C# functional, we should forget about classes and inheritance to go with static methods. We should forget constructor injection and go with regular method parameters. And we should separate data from behavior instead of keeping them side by side in a class that mutates state.

Following these two concepts, a dummy Calculator that looks like this

public class Calculator(ILogger _logger)
{
    private int Value { get; private set; }
    public void Add(int a)
    {
        _logger.Log($"Adding {a}");
        Value += a;
    }
}

will look like this instead

public static class FunctionalishCalculator
{
    public int Add(Action<string> logger, int value, int a)
    {
        logger($"Adding {a}");
        return value + a;
    }
}

And in F#, it will look like this

let add logger value a =
    logger $"Adding {a}"
    value + a

A few lines of code. In F#, functions don’t have to live in classes. The compiler infers parameters types. And we don’t need to use the return keyword.

The perfect example of expressions and immutability in practice is LINQ.

LINQ is functional.

Every LINQ method returns a new collection. We don’t have “void” LINQ methods. Expressions. And no LINQ methods change the input collection. Immutability.

That’s why LINQ is the best of all C# features—It’s functional.

Voilà! We don’t need fancy features like discriminated unions to adopt functional ideas in C#. Only those two fundamental concepts. Sure, new features help a lot!

Start by keeping IO away from your core, at the edges. And go with expressions and immutability.

14 Quick Career Lessons After 10+ Years (and Lots of Trial and Error) as a Software Engineer

2024-10-21T00:00:00+00:00

Coding is the easy part of software engineering.

We don’t get an instruction manual to survive the corporate world and navigate the “people and interactions” side of software engineering.

After over 10 years, 3 jobs, 2 “we have to let you go,” and lost of trial and error, these are 14 lessons I’ve learned while navigating a career as a software engineer:

1. You Can Lose Your Job At Any Time

You can’t control it. A pandemic, a recession, or anything else. But you can control: your online presence, emergency fund, and side income.

2. Detach Your Sense Of Meaning From Your Work

Work gives value and meaning.

But you’re not your work. You’re the books you’ve read, places you’ve visited, and people you’ve met. You’re your connections, experiences, and knowledge.

You’re more than a job.

3. Build Multiple Sources Of Income

A rental property, stock portfolio, or digital products. You name it.

Don’t rely only on your salary and don’t live paycheck to paycheck. There’s no safe job. See #1.

4. Always Be Ready To Leave Your Current Job

If you wait for a layoff to take action, it’s already too late.

Grow your network, have your CV updated, and keep your “tell me about yourself” muscles in shape. Yes, hiring is broken.

5. Change Jobs Often

Or at least, don’t stay too long at stagnant jobs.

Otherwise, your CV will become outdated, your interviewing skills will get rusty, and you will leave money on the table.

6. Climbing The Corporate Ladder Is A Myth

Anyone can add or remove steps in the ladder. Or remove the entire ladder. The best ladder to climb is the one you build for yourself.

A new title comes with more meetings, extra hours, and the same salary. Instead of optimizing for a title, optimize for a lifestyle.

7. Vacations Don’t Change An Unfulfilling Job

Neither do pay raises.

They only move a “death sentence” a couple of months ahead.

8. You Don’t Have To Feel Miserable

If you don’t feel like getting out of bed to work at that place, make a change. Find a way to motivate yourself and keep learning. Or look for “greener pastures.”

9. You Don’t Get Burned Out By Doing Too Much

But by doing too little of the things you care about. (Jim Kwik, brain coach)

And seek help when people around you start to be affected by your burnout.

10. Software Projects Don’t Fail Because Of Programming Languages And Tech Stacks

Nope! They fail because of poor communication and unclear expectations. The same as marriages. Even unclear expectations are a communication issue.

11. Don’t Be A Hero. Be A Team Player

If you are the only one who knows or does something in your team, you’re being a hero.

It feels great when you are the one who saves the day, but being a hero is a trap. A hero can’t get sick, go on vacation, or be promoted. Be a team player instead.

12. The Minute You Learn Something, Teach It

That’s from Show Your Work by Austin Kleon.

13. Don’t Ask Someone Who’s Leaving To Finish An Important Task At Work

As soon as he leaves, something will happen to the task he finished: an unexpected issue, a change in requirements, or a new scenario nobody saw coming. And he will be the only one who knows how to handle it. Too late. He’s already gone.

14. The More Senior You Get, The Less It’s About Coding

There’s more than coding:

Team dynamics
Project management
Inter-team communication
Scope and deadline negotiations
Managing stakeholders’ expectations

There’s more than only source code in a text editor.

Parting Thought

Hoping and praying without taking action is a bad career strategy. Instead, define what you want from your career. Money? Connections? Recognition? Create a career plan that reflects that, pick the right jobs, and always have an escape plan.

“Your career is your responsibility, not your employer’s” — Clean Coder by Uncle Bob.

Refactor your coding career with my free 7-day email course. In just 7 emails, you’ll get 10+ years of career lessons to avoid costly career mistakes.

Learning a Second Language Could Be Your Best Career Decision — Start With These 7 Steps

2024-10-14T00:00:00+00:00

Learning a second language has been my best career decision.

Literally, it changed my life and doubled my salary.

Initially, I learned English to make my CV look more attractive to recruiters. But learning English has been more than a better CV for me.

It took me a couple of years to learn English and an extra couple of years to take full advantage of it. I went to a traditional language school: lots of grammar exercises and “repeat after me” sessions.

With the right method and consistency, you could learn a language faster. One year is a good time frame to reach a conversational level. Of course, your mileage may vary.

If you’re learning a second language to boost your career, prepare for your next vacation abroad, or connect with your extended family, follow these 7 proven steps:

1. Fluency Isn’t Perfection

Before learning a single word or grammar rule, understand that nobody speaks any language perfectly.

I don’t speak perfect English. I don’t even speak perfectly in my native language. Nobody speaks perfectly in any language.

Speaking a language isn’t about making zero mistakes. It’s about communication and human connection.

Fluency isn’t perfection.

With that myth debunked, let’s move to the next step.

2. Identify Your Goals

Start your language journey by identifying your goal and your time frame.

A clear goal helps you determine what skills you need to focus on and what vocabulary to master. Studying to pass a language certification exam in a few months is different from learning useful phrases for your next vacation.

To keep that goal in mind, set a language checkpoint or milestone. For example, your first checkpoint could be a 15-minute conversation with a native speaker after your first month of practice.

3. Find a Learning Method

The key to learning a new language is to tie it to activities you enjoy doing.

I enjoy listening to podcasts and watching videos. When I started to learn French, I found a podcast for beginners and followed it during my lunch breaks. While everybody else at the office was taking a nap, I was with my headphones on, listening and taking notes.

From Scott Young’s Ultralearning book, the guy behind the “One Year Without English” challenge, I learned to spend about 10% of the learning time finding resources and study guides.

Spend the first days, looking up good resources to learn your target language.

4. Find a Teacher or a Language Partner

No matter how shy you think you are, sooner or later you will have to open your mouth and let words out.

My best strategy is to find a teacher or language partner for one-to-one sessions. Personally, I have used iTalki to find my teachers and language partners. Some teachers offer structured lesson plans or only conversation practice. But with language partners, expect only chit-chat about anything. Usually, you split the practice session in half: switching languages each time.

I have to confess I’ve been lucky with my language partners. After several practicing sessions with a language partner, we became friends and met in real life. It happened we were on vacation in the same city. And, thanks to those unexpected life turns, my language partner’s husband was a lawyer and ended up helping me review my contracts before joining my first job at an international software agency.

A teacher or language partner will help you practice in a stress-free environment.

If you’re learning a language for work, ask them to role-play being your interviewer or a participant at a meeting you have to conduct.

5. Practice a Little Bit Every Day

“Little by little, a little becomes a lot.” — Jim Kwik, the Brain Coach.

If you want to see fast results, study a bit every day. Learn 5 phrases or listen to a short audio a day. That’s better than a long study session once a week.

If you think you don’t have time, take advantage of every dead time slot in your schedule: while waiting in lines, on the bus, or walking home.

Back in the day when I had to commute, I reviewed my Anki flashcards and listened to podcasts on my way home.

If you’re not used to practicing a language daily, tie your study or practice sessions to an already-built habit. Do you have to do the dishes? The laundry? Listen to an audio lesson while doing it. You said you don’t have already built habits? What about listening to podcasts while in the shower? You shower regularly, right?

6. Learn Phrases Instead of Words

Don’t memorize words or grammar rules.

I know it’s frustrating when your teacher asks you to open a textbook to work on grammar rules in your first class. It kills all the fun of learning a language.

Instead of learning individual words, learn complete phrases and use them as LEGO bricks you assemble and interchange. You will learn words in context along with their gender. Yes, words have gender in other languages. And it’s funny when one word has a different gender in your target language.

Also, don’t overthink grammar rules or find logic in your target language.

When we were children, we didn’t receive a grammar book to learn our native languages. We absorbed grammar rules after being exposed to the language for hours and hours.

7. Immerse Yourself in the Language

This is the #1 tip to study from home – Create a language environment around you and your hobbies:

Change your phone and computer language
Read the news or watch TV
Follow social media
Listen to music

You name it!

You don’t have to travel abroad to learn a language, you can do it in the comfort of your bed.

Parting Thoughts

Thanks to learning a new language, I’ve made good friends, doubled my salary, and discovered a passion for learning and teaching.

We become a new person with every language we learn. I feel like I’m more extroverted when speaking English.

I have found that there’s no better way to build trust with coworkers or clients at work than to say hi, thanks, yes/no, and bye in their target language. It will bring smiles to their faces and show you’re interested in their culture.

So if you’re looking for a twist in your career, try a new language. Try Arabic to work in the oil industry, German for the automotive industry, or Spanish to join a rising startup in Latin America…who knows!

A second language could change your life too.

Refactor your coding career with my free 7-day email course. In just 7 emails, you’ll get 10+ years of career lessons to avoid costly career mistakes.

I'm Moving Monday Links to an Email List

2024-10-10T00:00:00+00:00

Bye, Monday Links. Hello, Friday Links.

For months, I ran a series called Monday Links, here on my blog. Every time I found interesting posts about programming and software engineering, I compiled them until I had five or six and then published them in a post.

It was a way to document what I read and react to the other people’s posts, when my reaction didn’t merit a separate post. Think of Twitter/X threads on my blog.

I’m moving my Monday Links to an email list.

The format is almost the same. Every Friday, I send four or five posts about software engineering and programming. But I sprinkle other interesting subjects in between. Also, I include one of my own posts published the same week and share updates about the projects I’m creating.

For example, here’s Monday Links on Notebooks, Learning, and KPIs, the last Monday Link I wrote here.

If you have already downloaded any of my ebooks from my Gumroad page, you’re already receiving my emails.

But if you haven’t and want to receive them, subscribe here.

Feel free to reply to my Friday Links and comment or ask questions.

I Hope You Don't Have To Write a CV. But if You Do, Follow These Tips

2024-10-07T00:00:00+00:00

CVs are so last century.

I hope I don’t have to write a CV anymore. I hope you don’t either.

A personal brand is the new CV and portfolio.

But since you’re reading this one, probably you still need to write a CV. I wish it won’t end up in the dumpsters behind a company careers page. I’ve tried that route with zero results.

More than once, some friend or ex-coworker has asked me to take a look at his CV. I’ve asked them too.

I realized I had already given (and received) the same tips about CVs. These are five tips I always give to write better CVs as software engineers.

1. Keep Your CV to Only One Page

These days of endless scrolling on TikTok, nobody has time and attention to read more than that.

Make it easy for people to review your CV. More than two pages are too long.

Imagine your CV is a business card in a A4 page. You only have one or two minutes to introduce yourself in a business card. Do the same in a CV.

Keep font size, spaces, and borders consistent.

2. Don’t Include a Photo, Marital Status, National ID, or Other Personal Information

Only add your professional email and LinkedIn profile, or any other social media profile to showcase your expertise. GitHub, Medium, dev.to handles work too.

I even skip phone numbers. You don’t want strangers calling or texting you in the middle of the night for a “life changing opportunity at a well-know company in the tech sector.”

You will be asked for personal information once you’re hired, not before.

And only include your city and country if you’re applying for a position that requires being in a particular location. Don’t put your home address either.

3. Don’t Add Every Single Experience Since You Started Working

Use your most recent experience. The last five years, for example.

And, include only the experience relevant to the job you’re applying for. Don’t add the unrelated part-time job you had in your first year at university.

You see? Even the one in the picture has only one page. Photo by João Ferrão on Unsplash

4. Don’t Include a Cloud of Keywords, Languages, or Library Names

Stars or years working with a language don’t mean expertise.

Probably, you’re riding a bike since you’re 4 or 5, but it doesn’t give you a place in the Tour de France. It’s the same with years of experience with a language or tool. What does five years with XML mean?

Instead, describe what you did and what accomplishments you made in your previous jobs. Use numbers in your job descriptions.

For example, “I wrote an order processing component that scaled up to X orders per month by…“ instead of “C#/ASP.NET Core/SQL Server.” Somebody reading your CV would wonder what you did with those tools.

A bunch of names by themselves mean nothing.

5. Skip Fancy Lines Like “Honest, Hard-Working, Team Player”

Everybody uses the same buzzwords.

“Team player,” “detail-oriented,” and “enthusiast” only take extra space in your single-page CV. Do you still remember tip 1, right? And guess what? Everybody desperate for a job is a detail-oriented enthusiast team player who like to work under pressure in their CV.

Instead of fancy lines, describe in a paragraph what you do and how you can help your next employer.

Voilà! Five tips as promised. Remember recruiters, technical managers, and CTOs will read your CV looking for different information, not only a cloud of languages and libraries.

A CV is to start an interview process. Keep it short and to the point. Be clear. “If you confuse, you lose.”

If you’re interested in more interview preparation material, check these interview types and tips, three interviewing lessons after applying at a FAANG, and follow these ten tips to solve your next take-home coding exercises.

Refactor your coding career with my free 7-day email course. In just 7 emails, you’ll get 10+ years of career lessons to avoid costly career mistakes.

Happy coding!

TIL: How to Use the Specification Pattern in C# to Simplify Repositories

2024-09-30T00:00:00+00:00

Repositories are the least SOLID part of our codebases.

When we work with Domain-Driven Design, we take care of our business domain and forget about our data-access layer. We end up dumping, in a single interface, every combination of methods and parameters to retrieve our entities from the database. This way, we break the Single Responsibility Principle and Interface Segregation Principle. You see? They’re the least SOLID part.

Our repositories become so bloated that to use one specific method from a repository, we end up depending on a huge interface with lots of other single-use methods. GetOrdersById, GetOrdersByDate, GetLineItemsByOrderId…

The Specification Pattern Simplifies Repositories

With the Specification pattern, we extract the “query logic” to another object and away from our repositories.

Instead of making our repositories more specific by adding more methods (_repo.GetOrderById(123456)), the Specification pattern makes repositories more general (_repo.FirstOrDefault(new OrderById(123456))).

Think of a Specification as the query logic and the query parameters to retrieve objects.

Specifications make more sense when using Domain-Driven Design. With Specifications, we encapsulate the LINQ queries, scattered all over our code, inside well-named objects that we keep inside our Domain layer.

Here’s how to use the Ardalis.Specification NuGet package to create a specification and retrieve a list of movies by their release year:

using Ardalis.Specification; // <--
using Ardalis.Specification.EntityFrameworkCore; // <--
using Microsoft.EntityFrameworkCore;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddScoped(typeof(Repository<>)); // <--
builder.Services.AddDbContext<MoviesContext>(options =>
    options.UseInMemoryDatabase("MovieDb"));

var app = builder.Build();

app.MapGet("/movies/{releaseYear}", async (int releaseYear, Repository<Movie> repo) =>
{
    var byReleaseYear = new MoviesByReleaseYear(releaseYear); // <--
    var movies = await repo.ListAsync(byReleaseYear); // <--
        
    // As an alternative, with Ardalis.Specification we can
    // use a specification directly with a DbContext:
    //var movies = await aDbContext.Movies
    //                .WithSpecification(byReleaseYear)
    //                .ToListAsync();

    return Results.Ok(movies);
});

app.MapPost("/movies", async (Movie movie, Repository<Movie> repo) =>
{
    await repo.AddAsync(movie);
    await repo.SaveChangesAsync();
    // Or, simply with a DbContext:
    //await aDbContext.Movies.AddAsync(movie);
    //await anyDbContext.SaveChangesAsync();

    return Results.Created($"/movies/{movie.Id}", movie);
});

app.Run();

public class MoviesByReleaseYear : Specification<Movie>
//           ^^^^^
{
    public MoviesByReleaseYear(int releaseYear)
    {
        Query
            .Where(m => m.ReleaseYear == releaseYear)
            .OrderBy(m => m.Name);
    }
}

public record Movie(int Id, string Name, int ReleaseYear);

public class Repository<T> : RepositoryBase<T> where T : class
//           ^^^^^
{
    public Repository(MoviesContext dbContext) : base(dbContext)
    {
    }
}

public class MoviesContext : DbContext
{
    public MoviesContext(DbContextOptions<MoviesContext> options)
        : base(options)
    {
    }

    public DbSet<Movie> Movies { get; set; }
}

Ardalis.Specification provides a RepositoryBase<T> class that wraps our DbContext object and exposes the database operations using Specification objects. The ListAsync() receives a specification, not an IQueryable object, for example.

Our Repository<T> is simply a class definition without query logic. Just a couple of lines of code.

Now the query logic is inside our MoviesByReleaseYear. Ardalis.Specification translates those filtering and ordering conditions to the right chain of Entity Framework Core methods.

Our repositories are way simpler and the query logic is abstracted to another object.

A Naive Implementation of the Specification Pattern

The best way to understand a piece of code is to recreate a minimal version.

Here’s a naive and bare-bones implementation of an in-memory repository that filters a list using a specification object:

var movies = new[]
{
    new Movie("Terminator 2", 1991),
    new Movie("Totoro", 1988),
    new Movie("Saving Private Ryan", 1998)
};
var repo = new InMemoryRepo<Movie>(movies); // <--
var found = repo.List(new ByReleaseYearSpec(1998)); // <--
// Output:
// [ Movie { Name = Saving Private Ryan, ReleaseYear = 1998 } ]

public record Movie(string Name, int ReleaseYear);

public class ByReleaseYearSpec : Spec<Movie> // <--
{
    public ByReleaseYearSpec(int releaseYear)
    {
        Where(movie => movie.ReleaseYear == releaseYear);
    }
}

public abstract class Spec<T> // <--
{
    public Func<T, bool>? Predicate { get; set; }

    public void Where(Func<T, bool> predicate)
    {
        Predicate = predicate;
    }
}

public class InMemoryRepo<T>
{
    private readonly IEnumerable<T> _items;

    public InMemoryRepo(IEnumerable<T> items)
    {
        _items = items;
    }

    public IEnumerable<T> List(Spec<T> spec)
    //                    ^^^^  
    {
        var evaluator = new SpecEvaluator();
        return evaluator.ApplySpec(_items, spec).ToList();
    }
}

public class SpecEvaluator
{
    public IEnumerable<T> ApplySpec<T>(IEnumerable<T> items, Spec<T> spec)
    {
        // The original implementation uses some "evaluators" to:
        // 1. Check if the spec has a certain shape and 
        // 2. Apply that shape to the input "query"
        //
        // For example, WhereEvaluator checks if the spec has a Where clause and
        // applies it.
        // 
        // This SpecEvaluator would be a Composite of smaller
        // evaluators that look for a certain shape
        if (spec.Predicate != null)
        {
            return items.Where(spec.Predicate);
        }
                
        return items;
    }
}

All the magic is inside the InMemoryRepo and the SpecEvaluator classes.

In the original implementation, the SpecEvaluator takes the parameters from the filters inside our specification (like Where, OrderBy, Skip, and Take) and apply them using EntityFramework Core methods into the IQueryable object that represents our database query.

Voilà! That’s how to use the Specification pattern to make our repositories more SOLID. With the Specification pattern, our repositories have a slim interface and a single responsibility: to turn specifications into database calls.

For more C# content, check how to create test data with the Builder pattern, how to use the Decorator pattern with a real example, and how to use the Pipeline pattern: An assembly line of steps.

How to Handle the Startup Class When Migrating ASP.NET Core Projects

2024-09-25T00:00:00+00:00

.NET 6.0 replaced the Startup class with a new hosting model and a simplified Program.cs file.

The Startup class is still available in newer versions. If we’re migrating a pre-.NET 6.0 project, the .NET upgrade assistant tool does the work while keeping the Startup class.

Here are 3 alternatives to handle with the Startup class when migrating to newer versions:

1. Official Docs Approach

Newer versions of ASP.NET Core work perfectly fine with the old Program.cs file and Startup class, we can choose to do nothing and keep them.

Here’s an old-style Program class:

using System;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Hosting;

namespace AnOldStyleAspNetCoreProject;

public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
         Host.CreateDefaultBuilder(args)
             .ConfigureWebHostDefaults(webBuilder =>
             {
                 webBuilder.UseStartup<Startup>();
             });
}

And a Startup class:

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;

namespace AnOldStyleAspNetCoreProject;

public class Startup
{
    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
    }

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddControllers();
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        app.UseRouting();
        app.UseAuthorization();

        app.UseEndpoints(endpoints =>
        {
            endpoints.MapControllers();
        });
    }
}

Nothing fancy. A simple API project.

If we want to keep the Startup class, here’s what Microsoft official docs show to make the Startup class work with the new hosting model and the simplified Program.cs:

var builder = WebApplication.CreateBuilder(args);

// vvvvv
var startup = new Startup(builder.Configuration);
startup.ConfigureServices(builder.Services);
// ^^^^^

var app = builder.Build();

startup.Configure(app, app.Environment);
// ^^^^^

app.Run();

We created a new instance of Startup inside the new Program.cs file.

2. Hybrid Approach

If we really want to ditch the Startup class, Andrew Lock recommends a hybrid approach in his blog:

Turn the methods from the Startup class into private methods in the new Program.cs file.

var builder = WebApplication.CreateBuilder(args);

ConfigureServices(builder.Services);
// ^^^^^

var app = builder.Build();

Configure(app, app.Environment);
// ^^^^^^

app.Run();

// This method used to be in Startup.cs
static void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
}

// This method used to be in Startup.cs too
static void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseRouting();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllers();
    });
}

3. Do-It-Yourself Approach

And if we want our Program.cs to look like the newer ones, there’s no automatic tool for that (at least I couldn’t find one in my Googling session). We have to copy the contents of the Startup class into the Program.cs file, by hand:

var builder = WebApplication.CreateBuilder(args);

// Put here what you had in ConfigureServices...
builder.Services.AddControllers();

var app = builder.Build();

// Put here what you had in Configure...
app.UseAuthorization();

// Before:
//
// app.UseRouting();
// ASP0014: Suggest using top level route registrations instead of UseEndpoints
//app.UseEndpoints(endpoints =>
//{
//    endpoints.MapControllers();
//});
//
// After:
app.MapControllers();

app.Run();

We cut and pasted the content of Startup inside the right sections of the new Program.cs. This time, we get some warnings about deprecated methods and their alternatives.

Voilà! If you’re a lazy developer like me, do nothing or go with the approach from the official docs. Otherwise, go with any of the other two options.

Four Lessons and a Challenge for a Coder Struggling to Write

2024-09-23T00:00:00+00:00

Last week, Syed, one of my email subscribers, shared his struggles with writing online.

Here’s an edited version of Syed’s email:

I wanted to start writing about my debugging journey of the things I had been stuck with long time and then solving it finally… But I couldn’t continue as I thought my website wasn’t the best with SEO and no one may read it on my website. Then I shifted to Twitter and later, due to fewer engagements, I couldn’t continue there either. Well no I think maybe writing for some well-known forums might be the way.

For Syed and you that want to start writing as a software developer:

Don’t Create, Document

Start by sharing what you do and what you learn. That’s a good start.

Writing online is like keeping a public time capsule. If you don’t know what to add to your time capsule, follow the 20-minute rule: if something takes you more than 20 minutes to figure out, write about it.

Write about your learning and the problems you’re solving at work. Probably, the next time you’re googling something, you will find your own writing. That’s magical.

If You Want to Start Writing, Don’t Start Your Own Blog

And don’t code your own blogging engine either.

When we want to start writing, we fall back to doing what we know best — coding — and start by coding a blogging engine. That’s where writing and blogging die.

The best place to start is on “social blogs.” Platforms for long-form content with readers and a distribution mechanism. This way, you don’t have to “chase” readers with SEO tricks and you’ll have faster feedback.

If you don’t know where to start, go with dev.to or Medium. I can’t recommend dev.to enough. It’s a beginner-friendly and welcoming platform for coders.

Once you start on a social blog, keep your blog as your main hub or a portfolio of your favorite posts. That’s what I do.

We All Started With Zero Readers and Followers

At the beginning, writing can feel lonely.

I wrote my first online piece in 2018 and nobody read it. Maybe only one or two of my coworkers. I saw my blog analytics going from ~10 views per month to eventually ~1000s in a matter of years. Yes, you read that right. Years.

Focus on writing your first 10 posts and keep trying and improving.

Here’s when the Show Your Work attitude keeps us writing in the long run. And like any other infinite game, you only lose if you stop playing.

Write for yourself and for sure others people will find it useful too.

SEO Is Another Skill to Master

If you go with a social blog, the platform does the SEO part for you. You don’t have to worry about it.

Search engines keep changing their rules with algorithm updates. These days, it seems Google favors Reddit posts instead of personal blogs.

You’ll be in a dead end if you try to chase every SEO update. Write for humans because search engines like it when you do that.

Instead of trying SEO tricks, go with these rules:

Write to answer a query people might search for in a search engine.
Make your posts easy to read for humans: Don’t use big chunks of text. Instead, use subheaders to break those big chunks of text.
Link back to other posts using keywords: Don’t use “click here” or “see more.”

You see? Another skill to master. Go with a social blog.

Parting Thought and Challenge

I owe my career growth to a couple of skills: apart from coding, learning English and writing online.

After blogging for more than five years, writing online has opened doors here and there. I made my first money on the internet thanks to my blog, for example.

Even if you don’t make any money writing, it will give you clear thinking.

And if you’ve made it this far, here’s my challenge: create an account on dev.to and write your first 4 posts there and see where they take you. If you accept the challenge, contact me and share your first post.

Write as if no one is reading and then keep writing because you don’t know who’s reading.

Four Writing Lessons I Learned After Binge-Reading Herbert Lui's Blog

2024-09-16T00:00:00+00:00

A Sunday evening free of dopamine ended up being a lesson on writing and blogging.

I started googling about note-taking and landed on Herbert Lui’s blog after finding his lessons after 800 Zettelkasten notes.

In case you don’t know Herbert Lui’s work, he’s a writer, editorial director, and book author. He wrote Creative Doing, a book with exercises and prompts for writers and creatives.

After binge-reading his blog, I learned these lessons from him.

1. Don’t Start From Scratch

Be a DJ producer of ideas instead.

Instead of trying to come up with original ideas every time, mix and build on your past and maybe forgotten ideas.

Don’t start from scratch again. Go back to one of your old ideas or writings and give it a fresh lick of paint.

2. Prefer Quantity Over Quality

If you want to improve at something, go for quantity.

That’s the key finding of the story of the pottery class: A teacher divided his pottery class into two halves. The first half was graded on the quantity of pottery produced and the other half on the quality instead. At the end of the class, the half graded on quantity did best. Their effort was to produce something and quickly move on to the next piece, taking the feedback from past repetitions.

If you need ideas to go for quantity, do a 100-day challenge: finish something every day for 100 days. Herbert wrote for 100 days and shared his lessons.

Quality comes after quantity.

3. You Don’t Run Out of Ideas if You Know Where To Look

When you think you’re running out of ideas, go through your favorite blogs, YouTube channels, and your social feeds and write a reaction post for a piece you liked.

That’s only one of the ideas I use to never run of writing ideas.

4. Don’t Write Masterpieces, Plant Seeds Instead

A post doesn’t have to be a 2,000-word masterpiece.

To remove the pressure of writing masterpieces every time, consider a blog like a garden of ideas instead of a finished and polished product. You can always expand a past idea on a new piece.

Most of Herbert’s posts only have a headline and one main idea. You’re free to break the rule of writing introductions and conclusions. That’s something I also noticed by reading Seth Godin’s blog. They write the main idea naturally after the headline without an introduction.

Finding Herbert’s blog inspired me to continue writing. Herbert doesn’t seem to have a “niche.” Maybe everything he writes falls under the umbrella of writing and creativity.

Don’t have a niche and go for quantity. You don’t need to write masterpieces, only to document you journey.

Follow These 3 Tips To Never Run Out of Writing Ideas

2024-09-09T00:00:00+00:00

Running out of ideas is the greatest fear of new writers.

But don’t worry. You’re not running out of ideas. You have plenty of them. You need to be aware of the content you consume and have writing prompts to help you write.

Here are 3 tips to never run out of ideas to write:

1. Become a DJ of Ideas

There’s nothing new under the sun. And it has all been done before.

That’s relieving and reassuring. That removes the self-imposed pressure of coming up with new and original ideas.

Never start from scratch again. Develop your “new” ideas by remixing and expanding your past ideas or others’ ideas. Become a DJ producer of ideas.

If you think you’re running out of ideas, go through your posts, videos, or social feed and write a reaction post about one piece of content.

2. Follow the 20-Min Rule

If something takes you 20 minutes or more to figure out, write about it.

This is the prompt I’ve used to write some of my coding tutorials. Once I figure out how to do something after being stuck for a while, I write about it.

I wish I could credit the source of this rule. I remember learning about it from an old YouTube presentation about technical blogging that I can’t find anymore.

So if you have an aha moment, write about it. If you finally understood a hard subject, write about it.

By writing about your learning struggles, you will reinforce and document your learning.

3. Follow the 3-Strike Rule

If a subject or idea comes up at least three times around you, write about it.

I found this idea on Shawn Wang (swyx)’s blog in the context of technical blogging. But it can be easily extended outside the coding world too.

If another client asks you the same question, write about it. And if you give the same piece of advice to someone, guess what? Write about it.

With the 3-strike rule, you’re also saving your keystrokes. After 3 strikes, the next time the same subject comes up, just share a link to your writing.

Now, you’re not running out of ideas again. It’s impossible. Notice the content you’re consuming and write about it.

What My First Job as a Software Engineer Taught Me About Coding and Life

2024-09-02T00:00:00+00:00

My first coding job was far from being like a Silicon Valley job at a startup.

I didn’t have ping-pong tables or slides to go between offices.

It was, by all means, a boring job at a local non-tech company. There’s nothing wrong with a boring job if that’s what you want. But it taught me valuable lessons about life, coding, and money. Here they are.

You Are Not Your Code

My first job was with a small team. One team member took care of one project, from start to end, wearing multiple hats.

Things got complicated when we had to work together and inherited the code from a coworker. It was messy code, to say the least. He put all actions and logic inside event handlers. Those were the days of WinForms applications: Drag and drop a button, double-click, and connect to the database right there.

We had to fix his issues and rewrite his code. Nobody wanted to do that. And I started to judge him because of his code. “What if he does everything else the same way he codes?”

Don’t judge someone by their code. Don’t take it personally either. You could miss professional connections or friendships by judging people for their code.

Assume everyone does their best with the resources they have at hand.

In the future, someone will inherit your code and say “What a crappy code. Who wrote this?”

There will always be different opinions and better ways of doing things. And even you will think of better ways to do your current work!

That's not me at my first job. Source: stablediffusionai.ai

Coding Is Not the Only Thing

In my first days, I only wanted to code.

I had just finished reading the Clean Code and wanted to refactor everything around me. I didn’t want to attend meetings, answer phone calls, or even reply to emails. I only wanted to code. That’s what I was paid for, right?

More than once, my boss called me to his office and I arrived minutes late because I was coding in my cubicle. I don’t know why I didn’t get in trouble for that.

Software engineering is about collaboration.

You won’t be locked in a basement coding. You must talk to clients, conduct meetings, agree on estimations, and ask for help.

I had to learn there’s more than just typing symbols in text files.

Live With Half of Your Salary

That’s the best life advice I’ve ever received for free.

My cubicle was next to the coffee machine, in a corner that had once been a bathroom.

One day, another coworker, a “veteran of many battles,” came over to have his coffee. And he said something like this:

“Hey Cesar, here’s a free piece of advice. Now that you can, imagine you only make half your salary and save the other half. Sooner than later, you can buy your own apartment.”

Years later, while reading money books, I found similar advice. And it reminded me of that conversation.

I’ve followed that advice, but not exactly. I’ve saved less than half of my salary.

Today, I’d rephrase it like this: “Imagine you make half of your salary, save, and invest the other half.”

You Don’t Have To Feel Miserable

I thought talent and good work were shortcuts to breaking the rules of the corporate world. I was soooo wrong! The Matrix is real!

Endless meetings, office politics, and a fixed schedule.

It all started to take its toll on me.

There were days when I felt I was leaving my life behind while sitting at a computer. I felt demotivated and disengaged. I was craving variety and change. I didn’t know there was a term for that: burnout.

Always have an exit plan.

Change jobs when you wake up and can’t get out of bed to work.

Find a way to motivate yourself: start a side project, learn a new tech stack, or discover a new way of doing your work. Or simply update your CV and LinkedIn profile and move on.

Parting Thoughts

It’s been more than 10 years since my first job. I’m only grateful for it. Somebody took a leap of faith with me and gave me a chance when I had 0 hours of flight time.

I took these lessons to my next job. And every time I can, I give the same money advice my coworker gave me: save and invest half of your salary.

Often what we value the most from past jobs is not the money, but the friendships and connections. From time to time, I meet with coworkers I met at this first job for coffee.

For more content, read 8 lessons or so for new software developers and my predictions for Software Engineering in 2034.

Refactor your coding career with my free 7-day email course. In just 7 emails, you’ll get 10+ years of career lessons to avoid costly career mistakes.

It Seems the C# Team Is Finally Considering Supporting Discriminated Unions

2024-08-19T00:00:00+00:00

C# is getting more and more functional with every release.

I don’t mean functional in the sense of being practical or not. I mean C# is borrowing features from functional languages, like records from F#, while staying a multi-paradigm language.

Yes, C# will never be a fully functional language. And that’s by design.

But, it still misses one key feature from functional languages: Discriminated Unions.

Discriminated Unions Are a Closed Hierarchy of Classes

Think of discriminated unions like enums where each member could be an object of a different, but somehow related, type.

Let me show you an example where a discriminated union makes sense. At a past job, while working with a reservation management software, hotels wanted to charge a deposit before the guests arrived. They wanted to charge some nights, a fixed amount, or a percentage of room charges, right after getting the reservation or before the arrival date.

Here’s how to represent that requirement with a discriminated union:

public record Deposit(Charge Charge, Delay Delay);

// Of course, I'm making this up...
// This is invalid syntax
public union record Charge // <--
{
    NightCount Nights;
    FixedAmount Amount;
    Percentage Percentage;
}

public record NightCount(int Count);
public record FixedAmount(decimal Amount, CurrencyCode Currency);
public enum CurrencyCode
{
    USD,
    Euro,
    MXN,
    COP
}
public record Percentage(decimal Amount);

public record Delay(int Days, DelayType DelayType);
public enum DelayType
{
    BeforeCheckin,
    AfterReservation
}

Here, the Charge class would be a discriminated union. It could only hold one of three values: NightCount, FixedAmount, or Percentage.

You might be thinking it looks like a regular hierarchy of classes. And that’s right.

But, the missing piece is that discriminated unions are exhaustive. We don’t need a default case when using a discriminated union inside a switch. And, if we add a new member to the discriminated union, the compiler will warn us about where we should handle the new member.

Discriminated unions are helpful to express restrictions, constraints, and business rules when working with Domain Driven Design. In fact, using types to represent business rules is the main idea of the book Domain Modeling Made Functional.

For example, discriminated unions are a good alternative when moving I/O to the edges of our apps and just returning decisions from our domains.

I told you that C# is borrowing some new features from functional languages. Well, if you’re curious, this is how our example will look like in F# using real discriminated unions:

type Deposit = {
    Charge: Charge;
    Delay: Delay;
}

type Charge = // <-- Look, ma! A discriminated union
    | NightCount of int
    | FixedAmount of decimal * CurrencyCode
    | Percentage of decimal

type CurrencyCode =
    | USD
    | Euro
    | MXN
    | COP

type Delay =
    | BeforeCheckin of int
    | AfterReservation of int

All credits to Phind, “an intelligent answer engine for developers,” for writing that F# example.

A Proposal for a Union Keyword

It seems the C# language team is considering fully supporting discriminated unions.

In the official C# GitHub repository, there’s a recent proposal for discriminated unions. The goal is to create a new type to “store one of a limited number of other types in the same place” and let C# do all the heavy work to handle variables of that new type, including checking for exhaustiveness.

The proposal suggests introducing a new union type for classes and structs. Our example using the union type will look like this:

public union Charge
//     ^^^^^
{
    NightCount(int Count);
    FixedAmount(decimal Amount, CurrencyCode Currency);
    Percentage(decimal Amount);
}

// This is how to instantiate a union type
Charge chargeOneNight = new NightCount(1); // <--
var oneNightBeforeCheckin = new Deposit(
    chargeOneNight
    //  ^^^^^
    new Delay(1, DelayType.BeforeCheckin));

// This is how to use it inside a switch
var amountToCharge = charge switch {
    NightCount n => DoSomethingHere(n),
    FixedAmount a => DoSomethingElseHere(a),
    Percentage p => DoSomethingDifferentHere(p)
    // No need to declare a default case here...
}

The new union type will support pattern matching and deconstruction too.

Under the hood, the union type will get translated to a hierarchy of classes, with the base class annotated with a new [Closed] attribute. And, if the default union type doesn’t meet our needs, we can use that new attribute directly.

Two Alternatives While We Wait

The union type is still under discussion. We’ll have to wait.

In the meantime, we can emulate this behavior using third-party libraries like OneOf.

Here’s how to define our Charge type using OneOf:

public class Charge : OneOfBase<NightCount, FixedAmount, Percentage>
//                    ^^^^^
{
    public Charge(OneOf<NightCount, FixedAmount, Percentage> input)
        : base(input)
    {
    }
}
// Or using OneOf Source Generation:
//
//[GenerateOneOf] // <--
//public partial class Charge : OneOfBase<NightCount, FixedAmount, Percentage>
//                              ^^^^^
//{
//}

public record NightCount(int Count); // <-- No base class here
public record FixedAmount(decimal Amount, CurrencyCode Currency);
public record Percentage(decimal Amount);

// Here's how to instantiate a OneOf type
var oneNightBeforeCheckin = new Deposit(
    new Charge(new NightCount(1)),
    //         ^^^^^
    new Delay(1, DelayType.BeforeCheckin));

OneOf brings methods like Match, Value, and AsT0/AsT1/AsT2 to work with and unwrap the underlying type.

Apart from third-party libraries to emulate discriminated unions, there’s an alternative approach abusing records: Discriminated Onions.

And here’s our Charge type using discriminated onions:

public abstract record Charge
//     ^^^^^
{
    private Charge() { } // <--

    public record NightCount(int Count) : Charge; // <--
    public record FixedAmount(decimal Amount, CurrencyCode Currency) : Charge;
    public record Percentage(decimal Amount): Charge;

    public U Match<U>(
       //    ^^^^^
        Func<NightCount, U> onNightCount,
        Func<FixedAmount, U> onFixedAmount,
        Func<Percentage, U> onPercentage) =>
        this switch
        {
            NightCount r => onNightCount(r),
            FixedAmount c => onFixedAmount(c),
            Percentage p => onPercentage(p),
            _ => throw new ArgumentOutOfRangeException()
        };
}

// Here's how to instantiate a discriminated onion
var oneNightBeforeCheckin = new Deposit(
    new Charge.NightCount(1),
    new Delay(1, DelayType.BeforeCheckin));

Voilà! That’s what discriminated unions are, and the official proposal to bring them to the C# language.

You see, C# is getting more functional on each release. While we wait to get it more funcy with discriminated unions, we have to go with libraries and workarounds. Let’s wait to see how it goes.

For more content, read What I Don’t Like About C# Evolution, An Alternative to Simplify Layering For Read-only Data Access and, How I Choose Value Objects.

For Cleaner Domains, Move IO to the Edges of Your App

2024-08-05T00:00:00+00:00

Don’t get too close with I/O.

That’s how I’d summarize the talk “Moving IO to the edges of your app” by Scott Wlaschin at NDC Sydney 2024.

In case you don’t know Scott Wlaschin’s work, he runs the site F# for Fun and Profit and talks about Functional Programming a lot. He’s a frequent speaker at the NDC Conference.

Here’s the YouTube video of the talk, in case you want to watch it:

These are the main takeaways from that talk and how I’d follow them to refactor a piece of code from one of my past projects.

I/O Is Evil: Keep It at Arm’s Length

In a perfect world, all code should be pure. The same inputs return the same outputs with no side effects.

But we’re not in a perfect world, and our code is full of impurities: retrieving the current time, accessing the network, and calling databases.

Instead of aiming for 100% pure code, the guideline is to move I/O (or impurities) away from the business logic or rules.

Move IO to the Edges. Created based on speaker's slides

When we mix I/O with our domain logic, we make our domain logic harder to understand and test, and more error-prone.

So let’s pay attention to functions with no inputs or no outputs. Often, they do I/O somewhere.

If you think we don’t write functions with no outputs, let’s take another look at our repositories.

Sure, our Create or Update methods might return an ID. But they’re not deterministic. If we insert the same record twice, we get different IDs or even an error if we have unique constraints in our tables.

The guideline here is to write code that is:

Comprehensible: it receives what it needs as input and returns some output.
Deterministic: it returns the same outputs, given the same input.
Free of side effects: it doesn’t do anything under the hood.

Just Return the Decision

This is the example shown in the talk:

Let’s say we need to update a customer’s personal information. If the customer changes their email, we should send a verification email. And, of course, we should update the new name and email in the database.

This is how we might do that,

async static Task UpdateCustomer(Customer newCustomer)
{
    var existing = await CustomerDb.ReadCustomer(newCustomer.Id); // <--

    if (existing.Name != newCustomer.Name
        || existing.EmailAddress != newCustomer.EmailAddress)
    {
        await CustomerDb.UpdateCustomer(newCustomer); // <--
    }
    
    if (existing.EmailAddress != newCustomer.EmailAddress)
    {
        var message = new EmailMessage(newCustomer.EmailAddress, "Some message here...");
        await EmailServer.SendMessage(message); // <--
    }
}

We’re mixing the database calls with our decision-making code. IO is “close” to our business logic.

Of course, we might argue static methods are a bad idea and pass two interfaces instead: ICustomerDb and IEmailServer. But we’re still mixing IO with business logic.

This time, the guideline is to create an imperative shell and just return the decision from our business logic.

Here’s how to update our customers “just returning the decision,”

enum UpdateCustomerDecision
{
    DoNothing,
    UpdateCustomerOnly,
    UpdateCustomerAndSendEmail
}

// This is a good place for discriminated unions.
// But we still don't have them in C#. Sorry!
record UpdateCustomerResult(
    UpdateCustomerDecision Decision,
    Customer? Customer,
    EmailMessage? Message);

static UpdateCustomerResult UpdateCustomer(Customer existing, Customer newCustomer)
{
    var result = new UpdateCustomerResult(UpdateCustomerDecision.DoNothing, null, null);

    if (existing.Name != newCustomer.Name
        || existing.EmailAddress != newCustomer.EmailAddress)
    {
        result = result with
        {
            Decision = UpdateCustomerDecision.UpdateCustomerOnly,
            Customer = newCustomer
        };
    }

    if (existing.EmailAddress != newCustomer.EmailAddress)
    {
        var message = new EmailMessage(newCustomer.EmailAddress, "Some message here...");

        result = result with
        {
            Decision = UpdateCustomerDecision.UpdateCustomerAndSendEmail,
            Message = message
        };
    }

    return result;
}

async static Task ImperativeShell(Customer newCustomer)
{
    var existing = await CustomerDb.ReadCustomer(newCustomer.Id);

    var result = UpdateCustomer(existing, newCustomer);
    //           ^^^^^
    // Nothing impure here

    switch (result.Decision)
    {
        case DoNothing:
            // Well, doing nothing...
            break;

        case UpdateCustomerOnly:
            // Updating the database here...
            break;

        case UpdateCustomerAndSendEmail:
            // Update the database here...
            // And, send the email here...
            break;
    }
}

With the imperative shell, we don’t have to deal with database calls and email logic inside our UpdateCustomer(). And we can unit test it without mocks.

As a side note, UpdateCustomerDecision and UpdateCustomerResult are a simple alternative to discriminated unions. Think of discriminated unions like enums where each member could be an object of a different type.

In more complex codebases, ImperativeShell() would be like a use case class or command handler.

Pure Code Doesn’t Talk to the Outside

When we push I/O to the edges, our pure code doesn’t need exception handling or asynchronous logic. Our pure code doesn’t talk to the outside world.

These are the three code smells the speaker shared to watch out for in our domain code:

Is it async? If so, you’re doing I/O somewhere
Is it catching exceptions? Again, you’re (probably) doing I/O somewhere
Is it throwing exceptions? Why not use a proper return value?

If any of these are true, we’re doing IO inside our domain. And we should refactor our code. “All hands man your refactoring stations.”

Moving I/O to the Edges When Sending an Email

While watching this talk, I realized I could refactor some code I wrote for sending emails in a past project.

Before sending an email, we need to validate if we’re sending it to valid domains. And, after calling a third-party email service, we should store a tracking number and update the email status. Something like this,

public class Email
{
    // Imagine more properties like From, Subject, Body here...
    private readonly IEnumerable<Recipient> _recipients = new List<Recipient>();

    public async Task SendAsync(
        IEmailService emailService,
        IDomainValidationService validationService,
        CancellationToken cancellationToken)
    {
        try
        {
            await validationService.ValidateAsync(this, cancellationToken);

            // It assumes that ValidateAsync changes the recipient's status
            if (_recipients.Any(t => t.LastStatus != DeliveryStatus.FailedOnSend))
            {
                var trackingId = await emailService.SendEmailAsync(this, cancellationToken);
                SetTrackingId(trackingId);
                MarkAsSentToProvider();
            }
        }
        catch (Exception ex)
        {
            UpdateStatus(DeliveryStatus.FailedOnSend);
            throw new SendEmailException("Sending email failed.", ex);
        }
    }
}

But this code contains the three code smells we should avoid: it has asynchronous logic and throws and catches exceptions, and even our Domain is aware of cancellation tokens. Arrggg!

That was an attempt to do Domain Driven Design (DDD) at a past team. And probably, our team at that time picked those conventions from the book Hands-on Domain-Driven Design with .NET Core.

And the imperative shell that calls SendAsync() is something like this,

public class SendEmailHandler : IEventHandler<EmailCreatedEvent>
{
    // Imagine some fields and a constructor here...

    public async Task Handle(EmailCreatedEvent evt, CancellationToken cancellationToken)
    {
        var email = await _emailRepository.GetByIdAsync(evt.EmailId);
                        ?? throw new EmailNotFoundException(evt.EmailId);

        try
        {
            await email.SendAsync(_emailService, _validationService, cancellationToken);

            await _emailRepository.UpdateAsync(email, cancellationToken);
        }
        catch (Exception ex)
        {
            email.SetFailedOnSend(ex.Message);
            await _emailRepository.UpdateAsync(email, cancellationToken);
        }
    }
}

And here’s the same logic “returning the decision,”

// This is a poor man's discriminated union
public abstract record SendingAttempt
{
    private SendingAttempt() { }

    public record SentToSome(Guid TrackingId, IEnumerable<Recipient> Recipients) : SendingAttempt;
    public record SentToNone() : SendingAttempt;
    public record FailedToSend(string Message): SendingAttempt;
}

public class Email
{
    // Imagine more properties like From, Subject, Body here...
    private readonly IEnumerable<Recipient> _recipients = new List<Recipient>();

    public Email Send(SendingAttempt attempt)
    {
        switch (attempt)
        {
            case SendingAttempt.SentToSome:
                // Set trackingId and mark as Sent for some recipients
		// Mark all other recipients as Invalid
		break;
            
            case SendingAttempt.SentToNone:
		// Mark all recipients as Invalid
		break;

            case SendingAttempt.FailedToSend:
                // Mark all recipients as Failed
		break;
        }
    }
}

In this refactored version, we’ve removed the asynchronous logic and exception handling. Now, it receives a SendingAttempt with the result of validating domains and email delivery to the email provider.

Also, it doesn’t have any dependencies passed as interfaces. It embraces Dependency Rejection.

And here’s the imperative shell,

public class SendEmailHandler : IEventHandler<EmailCreatedEvent>
{
    // Imagine some fields and a constructor here...

    public async Task Handle(EmailCreatedEvent evt, CancellationToken cancellationToken)
    {
        var email = await _emailRepository.GetByIdAsync(evt.EmailId)
                        ?? throw new EmailNotFoundException(evt.EmailId);

        var result = await _validationService.ValidateAsync(email, cancellationToken);
        
        // Use result to find valid and invalid destinations...
	// Attempt to send email and catch any exceptions...
        var sendingAttempt = BuildASendingAttemptHere();

        email.Send(sendingAttempt);
	//    ^^^^
	// Nothing impure here

        await _emailRepository.UpdateAsync(email, cancellationToken);
    }
}

Now, the imperative shell validates email domains and tries to send the email, encapsulating all the I/O around Send(). After this refactoring, we should rename Send() inside our domain to something else.

Voila! That’s one approach to have pure business logic, not the one and only approach.

Whether we follow Ports and Adapters, Clean Architecture, or Functional Core-Imperative Shell, the goal is to abstract dependencies and avoid “contaminating” our business domain.

For more content on architecture and modeling, check Domain Modeling Made Functional: Takeaways and To Value Object or Not To: How I choose Value Objects.

5 Unit Testing Best Practices I Learned from This NDC Conference Talk

2024-07-22T00:00:00+00:00

Recently, I found a NDC talk titled “.NET Testing Best Practices” by Rob Richardson.

Today I want to share five unit testing best practices I learned from that talk, along with my comments on other parts of it.

Here’s the YouTube video of the talk, in case you want to watch it, and the speaker’s website,

During the presentation, the speaker coded some unit tests for the LightActuator class. This class powers an IoT device that turns a light switch on or off based on a motion sensor input.

The LightActuator turns on lights if any motion is detected in the evening or at night. And, it turns off lights in the morning or if no motion has been detected in the last minute.

Here’s the LightActuator class, Source

public class LightActuator : ILightActuator
{
    private DateTime LastMotionTime { get; set; }

    public void ActuateLights(bool motionDetected)
    {
        DateTime time = DateTime.Now;

        // Update the time of last motion.
        if (motionDetected)
        {
            LastMotionTime = time;
        }

        // If motion was detected in the evening or at night, turn the light on.
        string timePeriod = GetTimePeriod(time);
        if (motionDetected && (timePeriod == "Evening" || timePeriod == "Night"))
        {
            LightSwitcher.Instance.TurnOn();
        }
        // If no motion is detected for one minute, or if it is morning or day, turn the light off.
        else if (time.Subtract(LastMotionTime) > TimeSpan.FromMinutes(1)
                    || (timePeriod == "Morning" || timePeriod == "Noon"))
        {
            LightSwitcher.Instance.TurnOff();
        }
    }

    private string GetTimePeriod(DateTime dateTime)
    {
        if (dateTime.Hour >= 0 && dateTime.Hour < 6)
        {
            return "Night";
        }
        if (dateTime.Hour >= 6 && dateTime.Hour < 12)
        {
            return "Morning";
        }
        if (dateTime.Hour >= 12 && dateTime.Hour < 18)
        {
            return "Afternoon";
        }
        return "Evening";
    }
}

And here’s the first unit test the presenter live-coded,

public class LightActuator_ActuateLights_Tests
{
    [Fact]
    public void MotionDetected_LastMotionTimeChanged()
    {
        // Arrange
        bool motionDetected = true;
        DateTime startTime = new DateTime(2000, 1, 1); // random value

        // Act
        LightActuator actuator = new LightActuator();
        actuator.LastMotionTime = startTime;
        actuator.ActuateLights(motionDetected);
        DateTime actualTime = actuator.LastMotionTime;

        // Assert
        Assert.NotEqual(actualTime, startTime);
    }
}

Of course, the presenter refactored this test and introduced more examples throughout the rest of the talk. But this initial test is enough to prove our points.

Five Unit Testing Best Practices from This Talk

1. Adopt a new naming convention

In this talk, I found a new naming convention for our unit tests.

To name test classes, we use <ClassName>_<MethodName>_Tests.

For test methods, we use <Scenario>_<ExpectedResult>.

Here are the test class and method names for our sample test,

public class LightActuator_ActuateLights_Tests
//           ^^^^^
{
    [Fact]
    public void MotionDetected_LastMotionTimeChanged()
    //          ^^^^^
    {
        // Beep, beep, boop...
        // Magic goes here
    }
}

2. Label your test parameters

Instead of simply calling the method under test with a list of parameters, let’s label them for more clarity.

For example, instead of simply calling ActuateLights() with true, let’s create a documenting variable,

[Fact]
public void MotionDetected_LastMotionTimeChanged()
{
    bool motionDetected = true;
    DateTime startTime = new DateTime(2000, 1, 1);

    LightActuator actuator = new LightActuator();
    actuator.LastMotionTime = startTime;
    // Before
    //actuator.ActuateLights(true);
    //                       ^^^^^
    // After
    actuator.ActuateLights(motionDetected);
    //                     ^^^^^
    DateTime actualTime = actuator.LastMotionTime;

    // Beep, beep, boop...
}

3. Use human-friendly assertions

Looking closely at the sample test, we notice the Assert part has a bug.

The actual and expected values inside NotEqual() are in the wrong order. The expected value should go first. Arrrggg!

[Fact]
public void MotionDetected_LastMotionTimeChanged()
{
    bool motionDetected = true;
    DateTime startTime = new DateTime(2000, 1, 1);

    LightActuator actuator = new LightActuator();
    actuator.LastMotionTime = startTime;
    actuator.ActuateLights(motionDetected);
    DateTime actualTime = actuator.LastMotionTime;

    Assert.NotEqual(actualTime, startTime);
    //              ^^^^^
    // They're in the wrong order. Arrrggg!
}

To avoid flipping them again, it’s a good idea to use more human-friendly assertions using libraries like FluentAssertions or Shouldly.

Here’s our tests using FluentAssertions,

[Fact]
public void MotionDetected_LastMotionTimeChanged()
{
    bool motionDetected = true;
    DateTime startTime = new DateTime(2000, 1, 1);

    LightActuator actuator = new LightActuator();
    actuator.LastMotionTime = startTime;
    actuator.ActuateLights(motionDetected);
    DateTime actualTime = actuator.LastMotionTime;

    // Before
    //Assert.NotEqual(actualTime, startTime);
    //                ^^^^^
    // They're in the wrong order. Arrrggg!
    //
    // After, with FluentAssertions
    actualTime.Should().NotBe(startTime);
    //         ^^^^^
}

4. Don’t be too DRY

Our sample test only covers the scenario when any motion is detected. If we write another test for the scenario with no motion detected, our tests look like this,

public class LightActuator_ActuateLights_Tests
{
    [Fact]
    public void MotionDetected_LastMotionTimeChanged()
    {
        bool motionDetected = true;
        //                    ^^^^
        DateTime startTime = new DateTime(2000, 1, 1);

        LightActuator actuator = new LightActuator();
        actuator.LastMotionTime = startTime;
        actuator.ActuateLights(motionDetected);
        DateTime actualTime = actuator.LastMotionTime;

        Assert.NotEqual(startTime, actualTime);
        //     ^^^^^
    }

    [Fact]
    public void NoMotionDetected_LastMotionTimeIsNotChanged()
    {
        bool motionDetected = false;
        //                    ^^^^^
        DateTime startTime = new DateTime(2000, 1, 1);

        LightActuator actuator = new LightActuator();
        actuator.LastMotionTime = startTime;
        actuator.ActuateLights(motionDetected);
        DateTime actualTime = actuator.LastMotionTime;

        Assert.Equal(startTime, actualTime);
        //     ^^^^^
    }
}

The only difference between the two is the value of motionDetected and the assertion method at the end.

We might be tempted to remove that duplication, using parameterized tests.

But, inside unit tests, being explicit is better than being DRY.

Turning our two tests into a parameterized test would make us write a weird Assert part to switch between Equal() and NotEqual() based on the value of motionDetected.

Let’s prefer clarity over dryness. Tests serve as a living documentation of system behavior.

5. Replace dependency creation with auto-mocking

ActuateLights() uses a static class to turn on/off lights,

public void ActuateLights(bool motionDetected)
{
    DateTime time = DateTime.Now;

    if (motionDetected)
    {
        LastMotionTime = time;
    }

    string timePeriod = GetTimePeriod(time);
    if (motionDetected && (timePeriod == "Evening" || timePeriod == "Night"))
    {
        LightSwitcher.Instance.TurnOn();
        // ^^^^^
    }
    else if (time.Subtract(LastMotionTime) > TimeSpan.FromMinutes(1)
                || (timePeriod == "Morning" || timePeriod == "Noon"))
    {
        LightSwitcher.Instance.TurnOff();
        // ^^^^^
    }
}

It’d be hard to assert if the lights were turned on or off with a static method.

A better approach is to replace LightSwitcher.Instance with an interface.

But adding a new dependency to the LightActuator would break our tests.

Instead of manually passing the new LightSwitch abstraction to the LightActuator constructor inside our tests, we could rely on auto-mocking tools like Moq.AutoMocker.

Here’s our test using AutoMocker,

[Fact]
public void MotionDetected_LastMotionTimeChanged()
{
    bool motionDetected = true;
    DateTime startTime = new DateTime(2000, 1, 1);

    var ioc = new AutoMocker();
    //            ^^^^^
    var actuator = ioc.CreateInstance<LightActuator>();
    //                 ^^^^^

    actuator.LastMotionTime = startTime;
    actuator.ActuateLights(motionDetected);
    DateTime actual = actuator.LastMotionTime;

    actual.Should().NotBe(startTime);
}

I’ve already used a similar approach with TypeBuilder and AutoFixture.

My Reaction: What I’d do differently

After writing and getting my tests reviewed, I’ve developed my own “taste” for unit testing.

Don’t take me wrong. This is a good talk and I’ve stolen some ideas for my own presentations.

But, this is what I’d do differently:

1. Avoid comments for AAA sections

Let’s avoid adding // Arrange, // Act, and // Assert comments inside our tests.

We don’t add // class, // fields, and // methods in other parts of our code, so it shouldn’t be necessary in our tests either.

Instead, I prefer using blank lines to visually separate the three sections of the Arrange/Act/Assert pattern.

In the examples I’ve shown you, I completely removed those comments.

2. Name test values instead of using comments

It’s a good idea to document our test values. But, let’s avoid using comments when we can use a descriptive name.

I’d rename startTime with a comment at the end to anyStartTime or randomStartTime,

[Fact]
public void MotionDetected_LastMotionTimeChanged()
{
    bool motionDetected = true;
    // Before:
    //DateTime startTime = new DateTime(2000, 1, 1); // random value
    //                                               ^^^^^
    var anyStartTime = new DateTime(2000, 1, 1);
    //  ^^^^^
    // or
    //var randomStartTime = new DateTime(2000, 1, 1);
    //    ^^^^

    LightActuator actuator = new LightActuator();
    actuator.LastMotionTime = anyStartTime;
    actuator.ActuateLights(motionDetected);
    DateTime actualTime = actuator.LastMotionTime;

    Assert.NotEqual(anyStartTime, actualTime);
}

3. Don’t expose private parts

In the talk, as part of the refactoring session, the presenter tested some internals. Specifically, he made the LastMotionTime property inside the LightActuator class public to use it inside the tests.

Even somebody in the audience raised this question too.

I understand the presenter had less than an hour to show a complete example and he chose a simple approach.

But, let’s avoid exposing internals to our tests. That’s the most common mistake on unit testing.

Parting thoughts

Voilà! Those are the five lessons I learned from this talk.

My favorite quote from the talk:

“What’s cool about unit testing is we can debug our code by writing code”

— Rob Richardson

As an exercise left to the reader, the presenter didn’t cover testing time. But we already covered how to write tests that use DateTime.Now using a custom abstraction.

And if we’re using .NET 8.0, we can rely on .NET 8.0 TimeProvider and its abstractions to abstract and test time.

Another thing I didn’t like is that at some point in the testing session, a TimePeriodHelper was added. And that’s one of the method and class names I’d like to ban.

Want to write readable and maintainable unit tests in C#? Join my course Mastering C# Unit Testing with Real-world Examples on Udemy and learn unit testing best practices while refactoring real unit tests from my past projects. No more tests for a Calculator class.

What I Don't Like About C# Evolution: Inconsistency

2024-07-08T00:00:00+00:00

C# isn’t just Java anymore.

That might have been true for the early days of C#. But the two languages took different paths.

People making that joke have missed at least the last ten years of C# history.

C# is open source and in constant evolution. In fact, you can upvote and discuss feature proposals in the C# official GitHub repo.

Every .NET release comes with new C# features.

But I’ve stopped obsessing over new C# features. In fact, I stopped collecting my favorite C# features by version. I feel I’m not missing much.

C# is not a consistent language anymore.

We now have many alternatives for the same task. Don’t believe me?

Objects, Arrays, and Null

First, here’s how to create a new object,

Movie m = new Movie("Titanic");
var m = new Movie("Titanic");
Movie m = new("Titanic");
//        ^^^^

The last one is the target-typed “new” expressions introduced in C# 9.0. That’s one of the features I disable in a .editorconfig file.

Second, here’s how to declare and initialize an array,

Movie[] movies = new Movie[] { new Movie("Titanic") };

var movies = new Movie[] { new Movie("Titanic") };
var movies = new Movie[] { new("Titanic") };
//                         ^^^^^

var movies = new[] { new Movie("Titanic") };
//           ^^^^^

Movie[] movies = [ new Movie("Titanic") ];
Movie[] movies = [ new("Titanic") ];
//              ^^^

We combine “new” expressions and collection expressions introduced in C# 12.

And, lastly, here’s how to check if an object is not null,

var titanic = new Movie("Titanic")

titanic != null;
titanic is not null;
titanic is {};
titanic is object;

And I don’t want to touch on primary constructors. It’s like classes got jealous of records and started crying for a similar feature, like a baby boy jealous of his brother.

Voilà! That’s what I don’t like about C#. Don’t take me wrong, C# is a great language with excellent tooling. But my favorite features are quite old: LINQ, async/await, and extension methods.

Some new features have lowered the barrier to entry. Now a “Hello, world” is a single line of code: Console.WriteLine("Hello, world!");.

Other C# features are making the language inconsistent and easier to write but not easier to read.

Often C# doesn’t feel like a single language, but three: the classic one from the early 2000s, another one between the classic and the .NET era, and the one we’re living these days.

Anyway, still no discriminated unions. Maybe in C# 20?

For more C# content, read my C# Definitive Guide, how to avoid exceptions when working with Dictionaries, and Six helpful extension methods to work with Collections.

Happy coding!

New Developers Looking for a Mentor: Here's a (Free) Mentorship Session in 8 Lessons

2024-06-24T00:00:00+00:00

You don’t need to meet your mentors.

I read that Napoleon Hill, the author of “Think and Grow Rich,” talked to his mentor only once, and he said it changed his life.

I’d be happy to share some advice over a virtual coffee in an “ask-a-friend” style. But to preserve my keystrokes and help more than one person, here I go.

I’m writing for my 20-year-old self joining his first corporate job, pretending that talent was a shortcut to break the rules of the corporate world. I thought my first job would be like in a Silicon Valley startup, working barefoot and sliding between offices. It was far from that.

This is free Internet advice, so handle it with care.

If you could take away only one lesson, take this first one,

1. Learn It and Teach It

“The moment you learn something, teach it.”

That’s from the book Show Your Work by Austin Kleon. “A book for people who hate the very idea of self-promotion.”

Teaching is the most effective way to learn. When you teach what you’ve learned, you consolidate your learning and, if you choose to teach online, you start building an online brand.

If you’re still here for more lessons, let’s continue…

2. Google “How To Be a Good Developer”

I remember doing this exact same search, back in the early 2010s when I started my journey.

I remember finding “write technical specs” and “learn functional programming.” It gave me ideas and subjects to explore. That’s why I’ve always had Functional Programming in the back of my head.

I’d tell my younger self to do it again.

Google or DuckDuckGo or Bing “How to be a good developer” and see how deep the rabbit hole goes.

Be careful, you will find one post saying “Document your code” and another one, saying “Don’t document your code.” Separate the wheat from the shaft.

3. Practice a Lot

The barrier to entry into the coding world is low, and lower and lower with every day that passes.

Anyone can potentially start, but getting good at it takes years.

Another googling task: search for “Teach Yourself Programming in Ten Years.”

Start by writing an end-to-end project: a coding project that reads data from a webpage, calls a backend, persists data into a relational database, and displays it back.

You will learn a lot from this simple exercise. HTML/CSS, a UI library, HTTP/REST, a backend language, SQL, and a database engine. Quite a lot!

I can’t remember how many hours I spent coding a recipe catalog back in the day with PHP and MySQL.

4. Master the Fundamentals

Frameworks and libraries come and go.

Study subjects that stand the test of time. Design patterns, data structures, and SQL, for example.

For some reason, we’re still talking about stoicism thousands of years later.

Probably in the next decade, we will still be writing code on text files, using some flavor of Unix/Linux, and writing SQL. I wouldn’t bet all my money, though.

5. Invest in Your Soft Skills

You won’t be locked in your basement coding. This is a collaborative endeavor.

You will spend most of your time communicating and collaborating: 1-1s, estimations, and SCRUM “ceremonies.”

Invest in your soft skills. Start by reading “How to Win Friends and Influence People.” My biggest takeaway from that book is never telling someone is wrong.

6. Read the Clean Code

This is the book we all start with.

It opened a whole new world for me. Nobody taught me about good variable and function names until I found that book. I even remember one of my teachers using “stu1” and “stu2” as variable names during classes. Uncle Bob would be pissed by those names.

Don’t just read it. Study it.

But don’t become a Clean Code police officer issuing infractions around you and using your book copy as your baton. There’s always a tradeoff.

7. Ask Yourself What You Want

Start by experimenting with roles and tech stacks. You will find the one that you like the most.

I started writing PDF reports by hand, drawing lines and cells, one pixel and line at a time. I don’t do that anymore, by the way. Then, I did a bit of mobile development with Xamarin and frontend development back in the day of Bootstrap and Knockout.js. Eventually, I got tired of styling and coloring issues and moved to backend development.

Ask yourself what you want out of your career. Is it money? Connections? Growing your own business? Write a 5-year plan and be willing to correct the course. “No plan resists contact with the enemy” or reality, I prefer to say.

8. Climbing the Corporate Ladder Is a Myth

You don’t control anything about the ladder you climb. Anyone can add a new step or replace the entire ladder, at any time.

Software Engineer I, II, III, IV, V…

You will hit a point of diminishing returns and a glass ceiling as a software developer.

I’d tell my younger self eager for a fancy title: a new title comes with more meetings, extra hours, and the same salary.

Instead of optimizing for a title, optimize for a lifestyle. The best ladder to climb is the one you build for yourself.

Takeaways

Voila! That’s what I’d tell my younger self. I hope I haven’t discouraged you. Software Engineering is a great career. It’s the future. Well, that’s what I’ve been hearing for quite a while.

The most satisfying thing about this career is seeing a smile on your users’ faces when what you code helps them save hours of repetitive work.

For more practical advice…

If you’re taking the self-studying route, I wrote to answer a reader asking how to start an ultralearning project to become a software engineer.
If you’re studying C#, I wrote a guide with what I believe every C# developer should know.
Also, I challenged myself to learn enough React in 30 days. Probably by the time you read it, there will be a new React version doing everything differently. And, if you’re studying Golang, I studied enough Go in 30 days too.

Refactor your coding career with my free 7-day email course. In just 7 emails, you’ll get 10+ years of career lessons to avoid costly career mistakes.

See you around and happy coding!

Testing DateTime.Now Revisited: .NET 8.0 TimeProvider

2024-06-10T00:00:00+00:00

Starting from .NET 8.0, we have new abstractions for time. We don’t need a custom ISystemClock interface. There’s one built-in. Let’s learn how to use the new TimeProvider class to write tests that use DateTime.Now.

.NET 8.0 added the TimeProvider class to abstract date and time. It has a virtual method GetUtcNow() that sets the current time inside tests. It also has a non-testable implementation for production code.

Let’s play with the TimeProvider by revisiting how to write tests that use DateTime.Now.

Back in the day, we wrote two tests to validate expired credit cards. And we wrote an ISystemClock interface to control time inside our tests. These are the tests we wrote:

using FluentValidation;
using FluentValidation.TestHelper;

namespace TimeProviderTests;

[TestClass]
public class CreditCardValidationTests
{
    [TestMethod]
    public void CreditCard_ExpiredYear_ReturnsInvalid()
    {
        var when = new DateTime(2021, 01, 01);
        var clock = new FixedDateClock(when);
        var validator = new CreditCardValidator(clock);
        //                                      ^^^^^
        // Look, ma! I'm going back in time

        var creditCard = new CreditCardBuilder()
                        .WithExpirationYear(DateTime.UtcNow.AddYears(-1).Year)
                        .Build();
        var result = validator.TestValidate(creditCard);

        result.ShouldHaveAnyValidationError();
    }

    [TestMethod]
    public void CreditCard_ExpiredMonth_ReturnsInvalid()
    {
        var when = new DateTime(2021, 01, 01);
        var clock = new FixedDateClock(when);
        var validator = new CreditCardValidator(clock);
        //                                      ^^^^^
        // Look, ma! I'm going back in time again

        var creditCard = new CreditCardBuilder()
                        .WithExpirationMonth(DateTime.UtcNow.AddMonths(-1).Month)
                        .Build();
        var result = validator.TestValidate(creditCard);

        result.ShouldHaveAnyValidationError();
    }
}

public interface ISystemClock
{
    DateTime Now { get; }
}

public class FixedDateClock : ISystemClock
{
    private readonly DateTime _when;

    public FixedDateClock(DateTime when)
    {
        _when = when;
    }

    public DateTime Now
        => _when;
}

public class CreditCardValidator : AbstractValidator<CreditCard>
{
    public CreditCardValidator(ISystemClock systemClock)
    {
        var now = systemClock.Now;
        // Beep, beep, boop
        // Using now to validate credit card expiration year and month...
    }
}

We wrote a FixedDateClock that extended ISystemClock to freeze time inside our tests. The thing is, we don’t need them with .NET 8.0.

1. Use TimeProvider instead of ISystemClock

Let’s get rid of our old ISystemClock by making our CreditCardValidator receive TimeProvider instead, like this:

public class CreditCardValidator : AbstractValidator<CreditCard>
{
    // Before:
    // public CreditCardValidator(ISystemClock systemClock)
    // After:
    public CreditCardValidator(TimeProvider systemClock)
    //                         ^^^^^
    {
        var now = systemClock.GetUtcNow();
        // or
        //var now = systemClock.GetLocalNow();
        
        // Beep, beep, boop
        // Rest of the code here...
    }
}

The TimeProvider abstract class has the GetUtcNow() method to override the current UTC date and time. Also, it has the LocalTimeZone property to override the local timezone. With this timezone, GetLocalNow() returns the “frozen” UTC time as a local time.

If we’re working with Task, we can use the Delay() method to create a task that completes after, well, a delay. Let’s use the short delays in our tests to avoid making our tests slow. Nobody wants a slow test suite.

With the TimeProvider, we can control time inside our tests by injecting a fake. But for production code, let’s use TimeProvider.System. It uses DateTimeOffset.UtcNow under the hood.

Time from another perspective. Photo by Jossuha Théophile on Unsplash

2. Use FakeTimeProvider instead of FixedDateClock

We might be tempted to wrie a child class that extends TimeProvider. But, let’s hold our horses. There’s an option for that too.

Let’s rewrite our tests after that change in the signature of the CreditCardValidator.

First, let’s install the Microsoft.Extensions.TimeProvider.Testing NuGet package. It has a fake implementation of the time provider: FakeTimeProvider.

Here are our two tests using the FakeTimeProvider:

using FluentValidation;
using FluentValidation.TestHelper;
using Microsoft.Extensions.Time.Testing;

namespace TestingTimeProvider;

[TestClass]
public class CreditCardValidationTests
{
    [TestMethod]
    public void CreditCard_ExpiredYear_ReturnsInvalid()
    {
        // Before:
        //var when = new DateTime(2021, 01, 01);
        //var clock = new FixedDateClock(when);
        var when = new DateTimeOffset(2021, 01, 01, 0, 0, 0, TimeSpan.Zero);
        var clock = new FakeTimeProvider(when);
        //              ^^^^^
        // Look, ma! No more ISystemClock
        var validator = new CreditCardValidator(clock);
        //                                      ^^^^^

        var creditCard = new CreditCardBuilder()
                        .WithExpirationYear(DateTime.UtcNow.AddYears(-1).Year)
                        .Build();
        var result = validator.TestValidate(creditCard);

        result.ShouldHaveAnyValidationError();
    }

    [TestMethod]
    public void CreditCard_ExpiredMonth_ReturnsInvalid()
    {
        // Before:
        //var when = new DateTime(2021, 01, 01);
        //var clock = new FixedDateClock(when);
        var when = new DateTimeOffset(2021, 01, 01, 0, 0, 0, TimeSpan.Zero);
        var clock = new FakeTimeProvider(when);
        //              ^^^^^
        var validator = new CreditCardValidator(clock);
        //                                      ^^^^^
        // Look, ma! I'm going back in time

        var creditCard = new CreditCardBuilder()
                        .WithExpirationMonth(DateTime.UtcNow.AddMonths(-1).Month)
                        .Build();
        var result = validator.TestValidate(creditCard);

        result.ShouldHaveAnyValidationError();
    }
}

The FakeTimeProvider has two constructors. One without parameters sets the internal date and time to January 1st, 2000, at midnight. And another one that receives a DateTimeOffset. That was the one we used in our two tests.

The FakeTimeProvider has two helpful methods to change the internal date and time: SetUtcNow() and Advance(). SetUtcNow() receives a new DateTimeOffset and Advance(), a TimeSpan to add it to the internal date and time.

If we’re curious, this is the source code of TimeProvider and FakeTimeProvider from the official dotnet repository on GitHub.

If we take a closer look at our tests, we’re “controlling” the time inside the CreditCardValidator. But, we still have DateTime.UtcNow when creating a credit card. For that, we can introduce a class-level constant Now. But that’s an “exercise left to the reader.”

Voilà! That’s how to use the new .NET 8.0 abstraction to test time. We have the new TimeProvider and FakeTimeProvider. We don’t need our ISystemClock and FixedDateClock anymore.

If you want to read more content, check how to Test Logging Messages with FakeLogger and my Unit Testing 101 series where we cover from what a unit test is, to fakes and mocks, to other best practices.

Happy testing!

I applied at a FAANG and failed: Three interviewing lessons

2024-05-27T00:00:00+00:00

Overconfidence killed all my chances of success.

I applied for a role as a software engineer at a FAANG or MAGMA or insert-newest-acronym here.

And I failed.

I thought: “I have more than 10 years of experience. I’ve seen quite a lot.”

A “short coding assessment” got me off guard. 80 minutes and 3 exercises made me feel like an impostor. An uppercut and 10-second countdown.

I don’t want this post to be another “hiring is broken” and “life is unfair” post. So…

If I could go back in time, this is what I’d tell myself before that coding assesment:

1. Review data structures, especially those you don’t use often.

Take the time to review data structures. Lists, hash maps, queues, trees.

Trees, is this you?

I haven’t used trees since my data structure class back in university. And probably, I wouldn’t use them if I had passed the interview and joined.

But, surprise, surprise. That was one of the questions.

2. Practice using a timer and a coding editor without auto-completion

I know it’s unrealistic. These days, we have IDEs with autocompletion and even AI at our fingertips.

But MAGMAs insist on hiring using coding platforms without autocompletion. The old way.

Since practicing a skill should be as “real” as possible, close your IDE and practice using a bare-bones text editor. And with a timer on.

3. Read all questions first. I know!

Yeah, I wanted to be an A-student playing with the rules. I jumped right to the first question.

50 minutes in and I had barely an answer for the first question. I had to decide between solving only one question or moving on and trying to solve another one. One and a half questions are better than only one, I guess.

I could have nailed the second one first. It was way easier. And definitively, I could have solved the last two questions and skipped the first one. If only I had read all the questions first.

Read all the questions and start with the easy ones. Old advice that I forgot.

Voila! That’s what I’d tell myself before that coding assessment. Yeah, hiring is broken, but we have to go through gatekeepers. Or ditch our CVs and interviewing skills and build a place for ourselves.

For more interview content, read remote interview types and tips and ten tips to solve your next interview coding challenge.

Starting out or already on the coding journey? Join my free 7-day email course and refactor your coding career–I distill 10+ years of career lessons into 7 short emails.

Happy interviewing!

Steal This 6-Step Reading Process To Retain More From Books

2024-05-13T00:00:00+00:00

Reading more books isn’t the answer.

In the last two or three years, I read dozens of non-fiction books. The truth is I don’t remember reading some of them, even when I took notes. I don’t even remember their front cover or why I decided to read them.

I was reading to increase a book count. Pure FOMO. Without realizing it, I was trying to copy those YouTube videos: “I read <insert large number here> books, here’s what I learned.”

After that realization, I adapted the slip-box or Zettelkasten method, described in How to Take Smart Notes by Sönke Ahrens, and other reading techniques into my own reading system.

This is the six-step process I follow to read and retain more from non-fiction books:

Step 1: Intention

Start by asking why you want to read a book.

We don’t jump into a book with the same attitude if we’re just curious about a subject or want to answer a particular question.

That intention will set the tone for our reading. And based on that, we could decide if we want to read the book from cover to cover or jump into a particular section.

Step 2: Overview

Ask if the book you’re about to read can answer your questions or satisfy your curiosity.

For that, understand the purpose of the book and its content. Use reviews, summaries, or anything else to understand the overall book content.

Often book authors go on podcast tours to promote their books, and listening to those podcast episodes helps us understand what their books are about.

A good experiment to try is to use ChatGPT or Copilot for this step. We could use any of the two to generate an executive summary of a book, for example.

Step 3: Note

Create a new place for your notes, either a text file or a piece of paper.

For this step, I use old plain-text files. Obsidian, Notion, or any note-taking app works here.

For the new note, use the date and the book title as the note title. Then divide the note into two halves. The first half is for questions and connections, and the second half is for the actual notes.

Also, link to the new book note from a book index and a subject index. The book index is a note that links to all books you’ve read. And the subject index is a note that references all other notes related to a specific subject. These notes work like “index” notes.

My note structure and links between notes

Step 4: Question

Read the table of contents, introduction, and conclusion to look for the book’s structure and interesting topics.

Also, skim through the book to find anything that grabs your attention: boxes, graphs, and tables.

In the first half of your note, write questions you have about the subject and questions that arise after skimming the book.

If you decide not to read the book from cover to cover, in the first half of your note, create an index of the chapters and sections to read or the ones to skip. Keep this index for future reference.

I learned this idea of asking “pre-reading” questions from Jim Kwik’s Speed Reading program and the idea of a custom index from the post Surgical Reading: How to Read 12 Books at Once.

Step 5: Read

Then, read the book while taking note of interesting parts and quotes.

Use the second half of your notes to write down those interesting bits. Avoid copying and pasting passages from the book, except for quotes. Use your own words instead.

After every chapter, stop to recall the main ideas from that chapter.

If you find the answer to any of your questions from the “Question” step, go back to the first half of your note and write those answers there.

Step 6: Connections

While reading or after finishing a chapter, notice connections with other subjects. Ask yourself how that expands or contradicts anything else you’ve learned.

Use the first half of the note to write these connections.

If you’re familiar with the Zettelkasten method, to write your connections, we should use a separate set of notes: the permanent notes. For simplicity, I keep these connections in the same file but in the first half.

This way, the next time you open your note, you will find your connections and critique first.

Parting Thought

The key to retaining more is reading actively. Don’t just pass from page to page. Read with intention, not to grow a book count. Read for answers and connections.

The next time you’re about to jump into a new book, remember to set an intention and then capture and connect.

Reading more books isn’t the answer. Reading for retention and action is.

For more content, check my takeaways from Pragmatic Thinking and Learning and Show Your Work.

Happy reading!

AI Won't Take Our Coding Jobs Yet. But The World Will Need Different Coders

2024-04-29T00:00:00+00:00

On March 12th, 2024, the coding world went nuts.

That day, Cognition Labs announced in their Twitter/X account the release of Devin, “the first AI software engineer.”

That announcement made the coding world run in circles, screaming in desperation. It also triggered an interesting conversation with a group of colleagues and ex-coworkers.

Here’s a summary of how a group of senior engineers viewed Devin and AI in general, and my own predictions for coding in the next 10 years.

If You Think You’re Out, You’re Out!

We all agreed that Devin and AI in general won’t take out jobs yet, but it will change the landscape for sure.

This is when the meme “AI needs well-written and unambiguous requirements, so we’re safe” is true.

One part of the group believed that software engineering, as we know it, would disappear in less than 10 years. They expected to see more layoffs and unemployment. They were also planning escape routes away from this industry.

If you’re reading this from the future, a bit of context about layoffs:

Around the 2020 pandemic, we enjoyed a boom in employment. We only needed “software engineer” as the title in our LinkedIn profiles to have dozens of recruiters offering “life-changing opportunities” every week.

But, in 2023 and 2024, we experienced massive layoffs. Either we were laid off or knew someone in our inner circle who was. It was a crazy time: one job listing, hundreds of applicants, and radio silence after sending a CV.

Most people claimed that AI took those jobs. Others claimed tech companies were so used to free money that went crazy hiring and then, when money wasn’t free anymore, they went crazy firing too. In any case, it was hard to get a new job in that season of layoffs.

Ok, end of that detour and back to the AI story.

While one part of the group was thinking of escaping routes, the other part believed the world would still need software engineers, at least, to oversee what AI does.

We wondered if AI needs human oversight, what about the working conditions for future software engineers? Maybe will they come from developing countries, with an extremely low wage and poor working conditions to fix the “oops” of AI software engineers? And if unfortunate software engineers were already under those conditions, wouldn’t all future software developers (at least the ones still standing) face the same fate?

Our conversation was divided into despair and change.

The World Will Need a Different Type of Coders

In 2034, knowing programming and coding by itself won’t be enough.

We will need to master a business domain or area of expertise and use programming in that context, mainly with AI as a tool.

Rather than being mundane code monkeys, our role will look like Product Managers. The coding part will be automated with AI. We will work more as requirement gatherers and writers and prompt engineers. Soft skills will be even more important than ever. Essentially, we all will be engineering managers overseeing a group of Devin’s.

We will see more Renaissance men and women, well-versed in different areas of knowledge, managing different AIs to achieve the goal of entire software teams.

In the meantime, if somebody else writes requirements and we, software engineers, merely translate those requirements into code, we’ll be out of business sooner rather than later.

Voilà! That’s how Software Engineering will look like in 2034: more human interaction and business understanding to identify requirements for AI software engineers. No more zero-value tasks like manual testing, code generation, and pointless meetings. Yeah, I’m looking at you, SCRUM daily meetings. AI will handle it all. Hopefully.

This is what Programming was like in 2020 and how I used AI to launch my courses in 2024.

Yes, I know! Making predictions about the future is hard.

“Open in 2034”

Two new LINQ methods in .NET 9: CountBy and Index

2024-04-15T00:00:00+00:00

LINQ doesn’t get new features with each release of the .NET framework. It just simply works. This time, .NET 9 introduced two new LINQ methods: CountBy() and Index(). Let’s take a look at them.

1. CountBy

CountBy groups the elements of a collection by a key and counts the occurrences of each key. With CountBy, there’s no need to first group the elements of a collection to count its occurrences.

For example, let’s count all movies in our catalog by release year, of course, using CountBy(),

var movies = new List<Movie>
{
    new Movie("Titanic", 1997, 4.5f),
    new Movie("The Fifth Element", 1997, 4.6f),
    new Movie("Forrest Gump", 1994, 4.3f),
    new Movie("Terminator 2", 1991, 4.7f),
    new Movie("Armageddon", 1998, 3.35f),
    new Movie("Platoon", 1986, 4),
    new Movie("My Neighbor Totoro", 1988, 5),
    new Movie("Pulp Fiction", 1994, 4.3f),
};

var countByReleaseYear = movies.CountBy(m => m.ReleaseYear);
//                              ^^^^^^^
foreach (var (year, count) in countByReleaseYear)
{
    Console.WriteLine($"{year}: [{count}]");
}

// Output
// 1997: [2]
// 1994: [2]
// 1991: [1]
// 1998: [1]
// 1986: [1]
// 1988: [1]

Console.ReadKey();

record Movie(string Name, int ReleaseYear, float Rating);

CountBy() returns a collection of KeyValuePair with the key in the first position and the count in the second one.

By the way, if that Console application doesn’t look like one, it’s because we’re using three recent C# features: the Top-level statements, records, and global using statements.

Before .NET 9.0, we needed to use GroupBy() with a second parameter to transform each group, like this,

var countByReleaseYear = movies.GroupBy(
  x => x.ReleaseYear,
  (releaseYear, movies) => new
  // ^^^^^
  {
      Year = releaseYear,
      Count = movies.Count()
      //      ^^^^^
  });

CountBy() has the same spirit of DistinctBy, MinBy, MaxBy, and other LINQ methods from .NET 6.0. With these methods, we apply an action direcly on a collection using a key selector. We don’t need to filter or group a collection first to apply that action.

Photo by Noom Peerapong on Unsplash

2. Index

Index projects every element of a collection alongside its position in the collection.

Let’s “index” our catalog of movies,

var movies = new List<Movie>
{
    new Movie("Titanic", 1998, 4.5f),
    new Movie("The Fifth Element", 1997, 4.6f),
    new Movie("Terminator 2", 1991, 4.7f),
    new Movie("Avatar", 2009, 5),
    new Movie("Platoon", 1986, 4),
    new Movie("My Neighbor Totoro", 1988, 5)
};

foreach (var (index, movie) in movies.Index())
//                                    ^^^^^
{
    Console.WriteLine($"{index}: [{movie.Name}]");
}

// Output
// 0: [Titanic]
// 1: [The Fifth Element]
// 2: [Terminator 2]
// 3: [Avatar]
// 4: [Platoon]
// 5: [My Neighbor Totoro]

Console.ReadKey();

record Movie(string Name, int ReleaseYear, float Rating);

Unlike CountBy(), Index() returns named tuples. It returns IEnumerable<(int Index, TSource Item)>.

Before, we had to use the Select() overload or roll our own extension method. In fact, this is one of the helpful extension methods I use to work with collections. But I call it Enumerated().

If we take a look at the Index source code on GitHub, it’s a foreach loop with a counter in its body. Nothing fancy!

Voilà! Those are two new LINQ methods in .NET 9.0: CountBy() and Index(). It seems the .NET team is bringing to the standard library the methods we needed to roll ourselves before.

To learn about LINQ and other methods, check my quick guide to LINQ, five common LINQ mistakes and how to fix them, and peeking into LINQ DistinctBy source code.

Want to write more expressive code for collections? Join my course, Getting Started with LINQ on Udemy and learn everything you need to know to start working productively with LINQ—in less than 2 hours.

Happy coding!

How to Test Logging Messages with FakeLogger

2024-04-01T00:00:00+00:00

Starting with .NET 8.0, we have a better alternative for testing logging and logging messages. We don’t need to roll our own mocks anymore. Let’s learn how to use the new FakeLogger<T> inside our unit tests.

.NET 8.0 introduces FakeLogger, an in-memory logging provider designed for unit testing. It provides methods and properties, such us LatestRecord, to inspect the log entries recorded inside unit tests.

Let’s revisit our post on unit testing logging messages. In that post, we used a Mock<ILogger<T>> to verify that we logged the exception message thrown inside a controller method. This was the controller we wanted to test,

using Microsoft.AspNetCore.Mvc;

namespace FakeLogger.Controllers;

[ApiController]
[Route("[controller]")]
public class SomethingController : ControllerBase
{
    private readonly IClientService _clientService;
    private readonly ILogger<SomethingController> _logger;

    public SomethingController(IClientService clientService,
                               ILogger<SomethingController> logger)
    {
        _clientService = clientService;
        _logger = logger;
    }

    [HttpPost]
    public async Task<IActionResult> PostAsync(AnyPostRequest request)
    {
        try
        {
            // Imagine that this service does something interesting...
            await _clientService.DoSomethingAsync(request.ClientId);

            return Ok();
        }
        catch (Exception exception)
        {
            _logger.LogError(exception, "Something horribly wrong happened. ClientId: [{clientId}]", request.ClientId);
            //      ^^^^^^^^
            // Logging things like good citizens of the world...

            return BadRequest();
        }
    }
}

// Just for reference...Nothing fancy here
public interface IClientService
{
    Task DoSomethingAsync(int clientId);
}

public record AnyPostRequest(int ClientId);

Photo by Jatin Jangid on Unsplash

1. Creating a FakeLogger

Let’s test the PostAsync() method, but this time let’s use the new FakeLogger<T> instead of a mock with Moq.

To use the new FakeLogger<T>, let’s install the NuGet package: Microsoft.Extensions.Diagnostics.Testing first.

Here’s the test,

using FakeLogger.Controllers;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Logging.Testing;
//    ^^^^^
using Moq;

namespace FakeLogger.Tests;

[TestClass]
public class SomethingControllerTests
{
    [TestMethod]
    public async Task PostAsync_Exception_LogsException()
    {
        var clientId = 123456;

        var fakeClientService = new Mock<IClientService>();
        fakeClientService
            .Setup(t => t.DoSomethingAsync(clientId))
            .ThrowsAsync(new Exception("Expected exception..."));
        //               ^^^^^
        // 3...2...1...Boom...

        // Look, ma! No mocks here...
        var fakeLogger = new FakeLogger<SomethingController>();
        //                   ^^^^^
        var controller = new SomethingController(
                                fakeClientService.Object,
                                fakeLogger);
                                // ^^^^^

        var request = new AnyPostRequest(clientId);
        await controller.PostAsync(request);

        // Warning!!!
        //var expected = $"Something horribly wrong happened. ClientId: [{clientId}]";
        //Assert.AreEqual(expected, fakeLogger.LatestRecord.Message);
        //       ^^^^^^^^
        // Do not expect exactly the same log message thrown from PostAsync()
        
        // Even better:
        fakeLogger.VerifyWasCalled(LogLevel.Error, clientId.ToString());
        //         ^^^^^
    }
}

We needed a using for Microsoft.Extensions.Logging.Testing. Yes, that’s different from the NuGet package name.

We wrote new FakeLogger<SomethingController>() and passed it around. That’s it.

2. Asserting on FakeLogger

The FakeLogger<T> has a LatestRecord property that captures the last entry we logged. Its type is FakeLogRecord and contains a Level, Message, and Exception. And if no logs have been recorded, accessing LatestRecord will throw an InvalidOperationException with the message “No records logged.”

But, for the Assert part of our test, we followed the lesson from our previous post on testing logging messages: do not expect exact matches of logging messages in assertions. Otherwise, any change in the structure of our logging messages will make our test break, even if the underlying business logic remains unchanged.

Instead of expecting exact matches of the logging messages, we wrote an extension method VerifyWasCalled(). This method receives a log level and a substring as parameters. Here it is,

public static void VerifyWasCalled<T>(this FakeLogger<T> fakeLogger, LogLevel logLevel, string message)
{
    var hasLogRecord = fakeLogger
        .Collector
        // ^^^^^
        .GetSnapshot()
        // ^^^^^
        .Any(log => log.Level == logLevel
                    && log.Message.Contains(message, StringComparison.OrdinalIgnoreCase));
                    // ^^^^^

    if (hasLogRecord)
    {
        return;
    }

    // Output:
    //
    // Expected log entry with level [Warning] and message containing 'Something else' not found.
    // Log entries found:
    // [15:49.229, error] Something horribly wrong happened. ClientId: [123456]
    var exceptionMessage = $"Expected log entry with level [{logLevel}] and message containing '{message}' not found."
        + Environment.NewLine
        + $"Log entries found:"
        + Environment.NewLine
        + string.Join(Environment.NewLine, fakeLogger.Collector.GetSnapshot().Select(l => l));

    throw new AssertFailedException(exceptionMessage);
}

First, we used Collector and GetSnapshot() to grab a reference to the collection of log entries recorded. Then, we checked we had a log entry with the expected log level and message. Next, we wrote a handy exception message showing the log entries recorded.

Voilà! That’s how to write tests for logging messages using FakeLogger<T> instead of mocks.

If we only want to create a logger inside our tests without asserting anything on it, let’s use NullLogger<T>. But, if we want to check we’re logging exceptions, like good citizens of the world, let’s use the new FakeLogger<T> and avoid tying our tests to details like the log count and the exact log messages. That makes our tests harder to maintain. In any case, we can roll mocks to test logging.

If you want to read more about unit testing, check How to write tests for HttpClient using Moq, how to test an ASP.NET Authorization Filter and how to write good unit tests: Use simple test values. Don’t miss my Unit Testing 101 series where we cover from what a unit test is, to fakes and mocks, to other best practices.

Happy testing!

How I used AI to launch my new testing course

2024-03-18T00:00:00+00:00

I ran an experiment. Maybe it was fear of missing out. I decided to use AI to help me launch a new course. This is how I used Copilot and the prompts I used.

I got this idea after watching one of Brent Ozar’s Office Hours videos on YouTube where he shared he keeps ChatGPT opened all the time and uses it as a junior employee. I decided to run a similar experiment, but for launching a new course on unit testing, one of my favorite subjects.

1. Lesson content and materials

I planned the lesson content and recorded and edited all video lessons myself. #madebyahuman

For the editing part, I used Adobe Podcast to remove background noise. My neighbor’s dog started to bark every time I hit record. And the other day at home, somebody made a smoothie with a loud blender while I was recording. Arrrggg! The only downside is that my voice sounds auto-tuned, especially in word endings.

I used Copilot for its convenience. I don’t need to create an account. Even I made Microsoft Edge open Copilot as the default tab. I only need to press the Windows key, type “Edge,” and I’m right there.

These are the prompts I used.

Generate a list of title ideas for my course

You’re an expert on course creation, programming, and SEO, give me a list of titles for a course to teach insert subject here

Rewrite my draft for a landing page

Now you’re an expert on online writing, SEO, marketing, and copywriting, please help me improve this landing page for an online course to increase sales and conversions. Make sure to use a friendly and conversational tone.

This is my landing page:

insert landing page here

Turn a landing page into a script for an introductory video

Now turn that last version of the landing page into a list of paragraphs and sentences I can use to create a PowerPoint presentation. Keep it short and to the point. Use only 10 paragraphs. I will turn each paragraph into a slide

Photo by Gerard Siderius on Unsplash

2. Online Marketing

Once I got all the lesson content and a landing page ready, I moved to the promotion part.

These are the prompts I used.

Write an email inviting readers to buy this new course

You’re an expert on copywriting and email marketing, give me n ideas for a short email to invite a reader who already took some action to buy my new video course: insert course name here. In that course, I insert brief description here. Offer a promo code for a limited time. Use friendly and engaging language.

Write a call to action for my posts

You’re an expert copywriter, give me n ideas for a two-sentence paragraph to promote my new course insert course name here. I’d like to use that paragraph at the end of posts on my blog to invite my readers to join the course. Use a friendly and conversational tone.

Write a launching post on LinkedIn

You’re an expert on copywriting, LinkedIn, and personal branding. Give me n ideas for a LinkedIn post to promote my new course insert title here based on the landing page of the course. Use a friendly and conversational tone.

This is the course landing page of the course:

insert landing page here

Nothing fancy. I followed the pattern: “Act as X, do Y for me based on some input. This is the input.”

I don’t use the exact same words Copilot gives me. I change the words I don’t use to make it sound like me.

Voilà! That’s how I used AI, especially Copilot, to help me launch my new testing course. On a Saturday morning, I ended up with a landing page and the script for an intro video for the course. What a productive morning!

I use AI the same way Jim Kwik, the brain coach, recommends in one of his YouTube videos: “AI (artificial intelligence) to enhance HI (human intelligence), not to replace it.” I don’t want AI to take out the pleasure of doing what I like to do. It’s my assistant.

In case you’re curious, this is the end result: Mastering C# Unit Testing with Real-world Examples.

For more productivity content (but not AI-related), check how to color a website based on its URL and how to declutter sites with uBlock Origin filters.

Happy coding!

Extreme Ownership: How U.S. Navy SEALs Lead and Win. Takeaways

2024-03-04T00:00:00+00:00

By the title, I guess you infer this isn’t a book about software engineering or programming. It’s about leadership. By any means, I’m advocating for war. But I think the military has to teach a lot about management and leadership. For years, they have been leading large organizations with complex tasks in changing environments. That sound a lot like software engineering, right?

Extreme Ownership is a book about the stories of two Navy SEALs officers and the lessons they learned while in service. In every chapter, they tell a story about their time in service, the leadership principle behind it, and its application to the corporate world. It’s an easy read. Probably, you could finish it in a weekend, too.

Photo by Jeffrey F Lin on Unsplash

These are some of my takeaways.

Extreme Ownership & Leadership

Extreme Ownership is the principle that a leader “owns” or is responsible for everything that happens to the mission or his team. Even to take the blame when things go wrong. “The leader is truly and ultimately responsible for everything.”

Leaders, who accept their responsibility when things go wrong, inspire respect and trust. They show and teach that attitude to the team.

A leader is responsible even for the underperformers. His job is to train and mentor them to level up their skills.

A leader should lead “up” too. He should speak up and ask questions when things could be better. He is also responsible for the communication with his own leaders.

A leader should create a simple plan and make sure everyone understands it clearly. A leader should first understand and believe in the mission. And when priorities change, he should communicate those changes and pass “situational awareness.”

A leader should put a system and mentor people so he can be the “tactical genius” looking at the bigger picture.

Voilà! Those are some of my takeaways. The book uses memorable stories to tell these principles. I like how the authors extrapolated the principles they learned while on duty to the corporate world. It turns out that the authors, as SEAL officers, had to deal with some of the same bureaucracy from the corporate world too. Even PowerPoint presentations! PowerPoint presentations! I didn’t see that coming.

As someone who influences decision-making inside teams, I enjoyed the book, and I will take lots of these ideas into my daily activities.

I’d like to close with this quote from the book: “there are no bad teams, only bad leaders.”

After reading this book, I connected the dots with some of the lessons I learned after a failed project. I needed Extreme Onwership in that project. Too late.

If you want to read my takeaways from proramming books, read Unit Testing Principles, Practices, and Patterns and Hands-on Domain-Driven Design with .NET Core.

Happy reading!

Monday Links: Notebooks, Learning, and KPIs

2024-02-19T00:00:00+00:00

Five interesting reads from the past month.

Lab Notebooks

I like the idea of keeping “lab” notebooks, especially to record the thought process for consulting clients. I’m a big fan of plain text. But the article recommends using pen and paper.

Read full article

Git Things

Git and Version Control are one of the subjects we have to learn ourselves. I prefer short Pull Requests with only one or two commits. I name my commits with a long and descriptive title that becomes a good title on PR descriptions.

This article shows “tactics” to better use Git. I really like these two:

start by writing the commit message before the actual work and then amending it. Commit Message Driven Development I guess, to follow the XDD trend
splitting refactorings into two commits: changing the API and then changing the calling sites

Read full article

It's never too late to learn about learning...Photo by Boston Public Library on Unsplash

10 Things Software Developers Should Learn about Learning

This article contains ten findings, backed by research, about learning and software engineering. Totally worth reading if you’re into learning about learning.

These are some of my favorite lessons:

“Expert programmers may have low or high working memory capacity but it is the contents of their long-term memory that make them experts.”
“Expert developers can reason at a higher level by having memorized (usually implicitly, from experience) common patterns in program code, which frees up their cognition.”
“The brain needs rest to consolidate the new information that has been processed so that it can be applied to new problems.”
“There is a key distinction between a beginner who has never learned the details and thus lacks the memory connections, and an expert who has learned the deeper structure but searches for the forgotten fine details.”
“There is no reliable correspondence between problem-solving in the world of brain teasers and problem-solving in the world of programming. If you want to judge programming ability, assess programming ability.”

If you don’t want to read the whole article, jump to the Summary section at the end.

Read full article

Why Most Software Engineering KPIs are BS and What to Do About it in 2024

Does your team measure story points too? The truth is we don’t know how to measure our work. I worked with a company that measured the percentage of completed tasks. It was a killing pressure. And once we have a metric, we start to game it. On the last day of the sprint, we saw people removing tasks so as not to mess with the final percentage.

From the article: “Engineering leaders (and sometimes non-technical executives) have often made the poor choice to measure output rather than impact”. The author recommends: “separate engineering health metrics to KPIs.” This is how the team feels vs the business impact of the work done.

Read full article

27 Years Ago, Steve Jobs Said the Best Employees Focus on Content, Not Process.

This article tells Steve Jobs’s opinion on office politics and bureaucracy and how often we think “paperwork” is the real work. Process vs Output. Also, this article shares how to keep the best team members around, those who are good at identifying the output.

From the article: “Success is rarely based solely on process. Success mostly comes down to what your business accomplishes.”

Voilà! What are the KPIs of your team? Do you measure story points or percentage of completed vs planned tasks? Until next Monday Links.

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.

Happy coding!

This Project Taught Me More About Leadership Than Programming: Two Postmortem Lessons

2024-02-05T00:00:00+00:00

Leadership and communication are more important than coding for the success of a project.

Last year, I worked as an independent contractor and engaged in short projects with an American client. This project was a six-month effort to bring group events, like weddings, conferences, and retreats, to a property management system.

This was one of the projects that convinced me that unclear expectations and poor communication kill any software project, not libraries and tools.

These are the two lessons I learned from this project.

Lesson 1: Have uncomfortable conversations earlier

Inside our team, we all started to notice “certain” behavior in a team member.

He delayed Pull Requests for minor things, interrupted meetings with off-topic questions, and asked for 100% detailed and distilled assignments.

Even once, he made last-minute changes, blocking other team members before a deadline. It wasn’t a massive unrequested refactoring, but it frustrated some people.

From the outside, it might have appeared he was acting to jeopardize the team’s progress.

It was time to virtually sit and talk to him. But nobody did it. And things started to get uncomfortable, eventually escalating the situation to upper management, leading to a team reorganization. There was “no chemistry with the team.”

An empathetic conversation could have clarified this situation. Maybe the “problematic” team member had good intentions, but the team misinterpreted them. Who knows?

This whole situation taught me to have uncomfortable conversations earlier.

I hope that's not an uncomfortable conversation...Photo by Priscilla Du Preez on Unsplash

Lesson 2: Once you touch it, you own it

“You only have to add your changes to this existing component. It’s already working.”

I bet you have heard that, too. That was what our Product Owner told us to extend an existing feature. We needed to import an Excel file with a list of guests into a group event.

The next thing we knew was that the already-working component had issues. The original team was laid off, and we couldn’t get our questions answered or count on them to fix those issues. We were in the dark.

What was a simple coding task turned out to be a longer one. Weeks later, we were still fixing issues and closing tickets. Nothing related to our task.

Before starting to work on top of an “already-working” feature, I learned to test it and give a list of existing issues. Otherwise, those existing issues will appear as bugs in our changes. And people will start asking questions: “Why are you taking so much time on this? It’s a simple task. It was already working.”

After that time, I realized something similar had happened in every job I’ve been in. I didn’t see that coming in this project.

Lesson learned! Once you touch it, you own it!

Voilà! These are the lessons I learned from this project: have uncomfortable conversations and test already-working features. Also, this project made me think it’s better to hire a decent developer who can be mentored and coached than a “rock star” who can’t get along with the team.

For more career lessons, check five lessons from my first five years as a software engineer, three lessons I learned after a “failed” project and things I wish I knew before working as a software engineer.

Refactor your coding career with my free 7-day email course. In just 7 emails, you’ll get 10+ years of career lessons to avoid costly career mistakes.

Monday Links: NDC Copenhagen

2024-01-22T00:00:00+00:00

These are four NDC conferences from the past Copenhagen edition.

Iron Man or Ultron: Is AI here to help us or hurt us?

“We want our AI’s to be like an IronMan suite. Not like Ultron. If IronMan does something cool in his suit, he gets the credit for it. If IronMan is not in the suit, then the suit is just this empty shell”

Is everything difficult, or is it just me?

This is a walkthrough of some mental health issues we all could face while working on a knowledge job. From Anxiety to Sleep. This is a subject we all should put on the table and talk about without any shame.

7 Things Technical Leaders Can Learn from Disney Princesses

I really liked this one. I never thought that Disney princesses could teach us about leadership. I have to confess that I skipped the singing parts from this talk. These are some of the main points:

“Don’t turn too many knobs at once…don’t expect immediate results when dealing with teams of people”
“Lean on your own self-worth and validation because the higher up in leadership you get the less external validation there will be for you”
“A lot of great leaders don’t have superpowers. They’re just generalists.” Instead, they can unlock other people’s potential. “You’re role is a catalyst.”
“Find support mechanisms when you move into leadership. This may be coaches, mentors, support groups”
“If you’re passing on orders, you’re not leading, you’re just managing”
“There’s no such a thing as a perfect team.” “Great leadership is about figuring out how to make teams from of a group of people”
“One of your main things is to make crystal-clear and sure that the agendas between your primary and secondary teams are aligned”

How Work Works

This talk uses Queue Theory to tune how complex organization works. These are some of the main points:

“IaaS platforms are M/M/c where c approaches to infinite”
Recommended books: Continous Delivery, Building Microservices, Building Evolutionary Architectures, Principles of Product Development Flow, Accelerate, Team Topologies
“Change request boards predict low performance”

Voilà! Another Monday Links episode. Do you AI as part of your daily work? What leadership lessons can you share?

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.

Happy coding!

Best of 2023

2024-01-08T00:00:00+00:00

In 2023, I realized that I’ve been blogging for five years. I started this blog to keep some notes online. Since then, I’ve used my blog to share my learned lessons, answer questions, and rant out loud. I consider my blog as my time capsule.

Last year, I wrote 23 posts. I tried to write one post every other week.

I wrote a series of posts about NullReferenceException, “the billion dollar mistake,” and expanded it into a mini-course on Educative.

I updated my ASP.NET posts to use .NET 6.0, the most recent LTS version the last year.

In one of my client’s projects, I worked with ORMLite. I wrote about passing a datatable as parameter and joining to subqueries. I was too lazy to write SQL queries by hand for those two edge cases. Also, I shared five lessons I learned while working with ORMLite.

I got an interesting question through my contact page. I could shared my advice on how to start an ultralearning project.

Five posts you read the most

These are the five posts I wrote in 2023 you read the most. In case you missed any of them, here they are:

Goodbye, NullReferenceException: What it is and how to avoid it.
Goodbye, NullReferenceException: Option and LINQ.
Goodbye, NullReferenceException: Nullable Operators and References.
Too many layers: My take on Queries and Layers. While working with one of my clients, I had to write a lot of response objects and mapping methods to implement read-only API endpoints. This post contains my thoughts on taking layering to the extreme.
Goodbye, NullReferenceException: Separate State in Separate Objects. This is how to apply the “make illegal state unrepresentable” mantra to avoid the NullReferenceException.

Last year, I continued working as an independent contractor and content writer. I continued writing for NCache official blog. I started offering onsite courses and training in my city. Unfortunately, I saw a lot of coworkers being laid off. I hope they all had found “greener pastures.”

Voilà! That’s my 2023 in review and your five favorite posts. I hope you enjoyed them as much as I did writing them.

If any of my posts have helped you and you want to support my work, check my courses on Educative, download my ebooks and buy me a coffee on my Gumroad page.

Don’t miss my best of 2021 and best of 2022.

Thanks for reading, and happy coding in 2024!

TIL: How to color a website based on its URL. A visual aid and time saver

2023-11-27T00:00:00+00:00

These days, I spent a while debugging an issue. After a couple of minutes of scratching my head, I realized I was looking at log entries in the wrong environment. I know! A facepalm moment. I decided to look for a way to change the colors of a browser tab or a website based on the URL I visited. This is what I found.

Coloring a website per URL

After a quick search, I found the URLColors extension in GitHub. It adds an opaque rectangle on top of a website. We only need to configure a keyword for the URL and a hex color. Optionally, it can make the rectangle blink.

For example, this is how I colored Hacker News,

// <site>, <color>, <flash|no>, <timerInSeconds>, <border-width>, <opacity>
news.ycombinator.com, #b58900, no, 0, 10px, 0.5

I used this extension to color the OpenSearch dashboard and other websites I work with. I use the Solarized theme and different color temperatures and rectangle width per environment.

This is what an OpenSearch dashboard looks like,

An OpenSearch dashboard for a non-development environment

I go with a red and thick rectangle that blinks for Production-related environments.

Coloring Management Studio bar per connection string

I use a similar trick with SQL Server Management Studio. When connecting to a new server, under the “Options” button, we can change the color of the status bar,

SQL Server Management Studio 'Use custom color' option

Voilà! No more changes in the Production environment by mistake. No more time wasted looking at the wrong website. Colors are helpful for that.

Even we can change Visual Studio title bar color with the SolutionColor extension.

For more productivity tricks, check How to declutter sites with uBlock Origin filters and how to automatically format SQL files with Git.

Happy coding!

TIL: How to declutter sites with uBlock Origin filters

2023-11-13T00:00:00+00:00

These days while procastinating on HackerNews, I found this submission. It points to a GitHub repo with some uBlock Origin filters to clean up websites.

I learned that I not only can block elements in a page with uBlock Origin, but also restyle them. Ding, ding, ding! These are the uBlock Origin filters I’m using to declutter some site I visit often.

1. uBlock Origin filters to restyle elements

A uBlock Origin filter to restyle an element looks like this,

<domain>##<selector>:style(<new-css-here>)

Here are the filters I used to restyle HackYourNews and HackerNews,

hackyournews.com##body:style(width: 960px; margin: 0 auto;)
hackyournews.com##.title:style(font-size: 18pt !important;)
hackyournews.com##.ratings:style(font-size: 12pt !important;)
hackyournews.com##.subtext:style(font-size: 14pt !important;)

news.ycombinator.com###hnmain:style(background-color: #fdf6e3; width: 960px !important; margin: 0 auto !important;)
news.ycombinator.com##.rank:style(font-size: 14pt !important;)
news.ycombinator.com##.titleline:style(font-size: 16pt !important;)
news.ycombinator.com##.sitebit.comhead:style(font-size: 12pt !important;)
news.ycombinator.com##.subtext:style(font-size: 12pt !important;)
news.ycombinator.com##.spacer:style(height: 12px !important;)
news.ycombinator.com##.toptext:style(font-size: 12pt !important;)
news.ycombinator.com##.comment:style(font-size: 14pt !important;)
news.ycombinator.com##span.comhead:style(font-size: 12pt !important;)
news.ycombinator.com##.morelink:style(font-size: 14pt !important;)

2. How to install custom uBlock Origin filters in Brave

To install these filters in Brave, let’s navigate to brave://settings/shields/filters, paste the filters, and hit “Save.”

This is how HackerNews looked without my filters,

HackerNews front page without any restyling

And this is how it looks after restyling it,

HackerNews front page with some uBlock Origin filters

I reduced the page width and increased font size for more readability.

For other sites, I install these extensions: Modern Wiki to restyle Wikipedia, StackOverflow Focus, and Distraction-Free YouTube.

Voilà! That’s how to use uBlock Origin filters to declutter websites. I like clean and minimalistic designs. Before learning about uBlock Origin filters, I started to dabble into browser extension development to restyle sites. With these filters, it’s easier.

What site would you like to declutter with this trick?

For more productivity content, check how to replace keywords in file with Bash, how to rename C# project files with Git, and how to format SQL files with Git and Poor Man’s T-SQL Formatter.

Happy coding!

TIL: Five lessons while working with OrmLite

2023-10-30T00:00:00+00:00

Back in the day, for my Advent of Posts I shared some lessons on Hangfire and OrmLite. In this year, for one of my client’s project I’ve been working with OrmLite a lot. Let me expand on those initial lessons and share some others.

1. IgnoreOnUpdate attribute

When using SaveAsync() or any update method, OrmLite omits properties marked with the [IgnoreOnUpdate] attribute in the generated SQL statement. Source

For example,

public class Movie
{
    public string Name { get; set; }
    
    [IgnoreOnUpdate]
    // ^^^^^
    public string OrmLiteDoesNotUpdateThisOne { get; set; }
}

I used this attribute when inserting and updating audit fields to avoid messing with creation dates when updating records.

Also OrmLite has similar attributes for insertions and queries: [IgnoreOnInsertAttribute] and [IgnoreOnSelectAttribute].

2. QueryFirst vs SqlScalar

OrmLite QueryFirst() method requires an explicit transaction as a parameter. Source Unlike QueryFirst(), SqlScalar() uses the same transaction from the input database connection. Source

I learned this because I had a DoesIndexExist() method inside a database migration and it failed with the message “ExecuteReader requires the command to have a transaction…“

This is what I had to change,

private static bool DoesIndexExist<T>(IDbConnection connection, string tableName, string indexName)
{
    var doesIndexExistSql = @$"
      SELECT CASE WHEN EXISTS (
        SELECT * FROM sys.indexes
        WHERE name = '{indexName}'
        AND object_id = OBJECT_ID('{tableName}')
      ) THEN 1 ELSE 0 END";
    
    // Before
    //
    // return connection.QueryFirst<bool>(isIndexExistsSql);
    //                   ^^^^^
    // Exception: ExecuteReader requires the command to have a transaction...

    // After
    var result = connection.SqlScalar<int>(doesIndexExistSql);
    //                      ^^^^^
    return result > 0;
}

3. Create Indexes

Apart from reading and writing records, OrmLite can modify the database schema, for example to create tables and indexes.

To create an index for a table, we could either annotate fields or classes. For example,

[CompositeIndex(unique: false, fieldsNames: "ReleaseYear", "Name", Name = "AnOptionalIndexName")]
// ^^^^^
public class Movie
{
    public int ReleaseYear { get; set; }

    [Index]
    // ^^^^^
    public string Name { get; set; }
}

Also, OrmLite has a CreateIndex() method that receives an expression, like this,

_connection.CreateIndex<Movie>(m => m.Name);
// or
_connection.CreateIndex<Movie>(m => new { m.ReleaseYear, m.Name });

By default, CreateIndex() creates indexes with names like: idx_TableName_FieldName. Source We can omit the index name if we’re fine with this naming convention.

4. Tag queries to easy troubleshooting

To identify the source of queries, OrmLite has two methods: TagWith() and TagWithCallSite().

For example,

var movies =  _connection.From<Movie>()
                    // Some filters here...
                    .Take(10)
                    .TagWith("AnAwesomeQuery")
                    // Or
                    //.TagWithCallSite();

With TagWith(), OrmLite includes a comment at the top of the generated SQL query with the identifier we pass.

For the previous tagged query, this is the generated SQL statement,

-- AnAwesomeQuery

SELECT TOP 10 "Id", "Name", "ReleaseYear" 
FROM "Movie"

With TagWithCallSite(), Ormlite uses the path and line number of the file that made that database call instead.

This is a similar trick to the one we use to debug dynamic SQL queries. It helps up to traceback queries once we found them in our database plan cache.

5. LoadSelectAsync and unparameterized queries

OrmLite has two convenient methods: LoadSelect() and LoadSelectAsync(). They find some records and load their child references.

Let’s write the Movie and Director classes,

public class Movie
{
    public string Name { get; set; }

    [Reference]
    // ^^^^^
    public Director Director { get; set; }
}

public class Director
{
    [References(typeof(Movie))]
    // ^^^^^^
    public int MovieId { get; set; }

    public string FullName { get; set; }
}

Now let’s use LoadSelectAsync(),

var query = _connection.From<Movie>()
                        // Some filters here
                        .Take(10);
var movies = await _connection.LoadSelectAsync(query);
//                             ^^^^^
// It loads movies and their child directors

When using LoadSelect() and LoadSelectAsync(), OrmLite doesn’t parameterize the internal query used to load the child entities. Arrrggg!

I’m not sure if it’s a bug or a feature. But, to load child entities, OrmLite “inlines” the parameters used to run the parent query. We will see in the plan cache of our database lots of unparameterized queries.

See it by yourself in OrmLite source code, here and here.

After finding out about this behavior, I ended up ditching LoadSelectAsync() and using SelectAsync() instead, like this,

var moviesQuery = _connection.From<Movie>()
                        // Some filters here
                        .Take(10);
var movies = await _connection.SelectAsync(moivesQuery);
if (!movies.Any())
{
    return Enumerable.Empty<Movie>();
}

var directorsQuery = _connection.From<Director>()
                        .Where(d => Sql.In(d.MovieId, moviesQuery.Select<Movie>(d => d.Id)));
var directors = await _connection.SelectAsync(directorsQuery);

foreach (var m in movies)
{
    m.Director = directors.Where(r => r.MovieId == m.Id);
}

Probably there’s a better solution, but that was my workaround to avoid a flooded plan cache. I could afford an extra roundtrip to the database and I didn’t want to write SQL queries by hand. C’mon!

Voilà! These are some of the lessons I’ve learned while working with OrmLite. Again, things we only find out when we adventure to read our libraries source code.

To read more content on OrmLite, check how to pass a DataTable as parameter to an OrmLite query and how to join to a subquery with OrmLite.

Happy coding!

TIL: How to join to subqueries with OrmLite

2023-10-16T00:00:00+00:00

Another day working with OrmLite. This time, I needed to support a report page with a list of dynamic filters and sorting fields. Instead of writing a plain SQL query, I needed to write a SqlExpression that joins to a subquery. OrmLite doesn’t support that. This is what I learned (or hacked) today.

Let’s imagine we need to write an SQL query for a report to show all directors based on filters like name, birthdate, and other conditions. Next to each director, we need to show their movie count and other counts. For me, it was reservations and rooms. But the idea is still the same.

1. Using a SQL query with a CTE

Since we needed to support filters based on the user’s input, the best solution would be to write a dynamic SQL query. I know, I know! That’s tedious.

If we have the Director and Movie tables, we could write a query like this,

WITH MovieCount AS (
	SELECT DirectorId
	   , COUNT(*) Count
	   /* More aggregations here */
	FROM Movie
	/* Some filters here */
	GROUP BY DirectorId
	)
SELECT d.*, m.Count
FROM Director d
LEFT JOIN MovieCount m
	ON d.Id = m.DirectorId
WHERE d.Country = 'USA' /* More filters here */
/* Sorting by other filters here */
ORDER BY m.Count DESC

I’m using a common table expression, CTE. I have already used them to optimize queries with ORDER BY.

For this example, a simple JOIN without any CTE would work. But let me prove a point and finish this post.

2. Using OrmLite SqlExpression

Let’s use these Director and Movie classes to represent the one-to-many relationship between directors and their movies,

public class Director
{
    [AutoIncrement]
    public int Id { get; set; }

    [Reference]
    public List<Movie> Movies { get; set; }

    [StringLength(255)]
    public string FullName { get; set; }

    [StringLength(255)]
    public string Country { get; set; }
}

public class Movie
{
    [AutoIncrement]
    public int Id { get; set; }

    [StringLength(256)]
    public string Name { get; set; }

    [References(typeof(Director))]
    public int DirectorId { get; set; }
}

While trying to translate that query to OrmLite expressions, I realized OrmLite doesn’t support joining to subqueries. Arrrggg!

I rolled up my sleeves and started to take a deeper look.

I ended up hacking this,

using ServiceStack.DataAnnotations;
using ServiceStack.OrmLite;

namespace JoiningToSubqueries;

public class JoinTetsts
{
    [Fact]
    public async Task ItWorksItWorks()
    {
        var connectionString = "...Any SQL Server connection string here...";
        var dbFactory = new OrmLiteConnectionFactory(connectionString);
        using var db = dbFactory.Open();

        // 0. Create Movie and Director tables
        db.CreateTable<Director>();
        db.CreateTable<Movie>();

        // 1. Populate some data
        var jamesCameron = new Director
        {
            FullName = "James Cameron",
            Country = "Canada",
            Movies = new List<Movie>
            {
                new Movie
                {
                    Name = "Titanic"
                }
            }
        };
        await db.SaveAsync(jamesCameron, references: true);

        var stevenSpielberg = new Director
        {
            FullName = "Steven Spielberg",
            Country = "USA",
            Movies = new List<Movie>
            {
                new Movie
                {
                    Name = "Raiders of the Lost Ark"
                },
                new Movie
                {
                    Name = "Jurassic Park",
                }
            }
        };
        await db.SaveAsync(stevenSpielberg, references: true);

        var georgeLucas = new Director
        {
            FullName = "George Lucas",
            Country = "USA",
            Movies = new List<Movie>
            {
                new Movie
                {
                    Name = "Star Wars: A New Hope"
                }
            }
        };
        await db.SaveAsync(georgeLucas, references: true);

        // 2. Write a subquery to do the counting
        var movieCountPerDirector = db.From<Movie>()
                // We could add some filters here...
                .GroupBy(x => x.DirectorId)
                .Select(x => new
                {
                    x.DirectorId,
                    Count = Sql.Custom("COUNT(*)")
                });

        // 2. Write the parent query to filter and sort
        var query = db.From<Director>()
            .LeftJoin(movieCountPerDirector, (d, m) => d.Id == m.DirectorId, subQueryAlias: "mc")
            // ^^^^^
            // It receives a subquery, join expression
            // and alias
            //
            // We could add some filters here...
            .Where(d => d.Country == "USA")
            .Select(d => new
            {
                d,
                MovieCount = Sql.Custom("mc.Count")
                //                      ^^^^
                // Same alias as subQueryAlias parameter
            })
            // We could change the sorting column here too...
            .OrderBy(Sql.Desc("mc.Count"));

        var directors = await db.SelectAsync<DirectorAndMovieCount>(query);

        Assert.Equal(2, directors.Count);
        Assert.Contains(directors, d => d.FullName == "Steven Spielberg");
        Assert.Contains(directors, d => d.FullName == "George Lucas");
    }
}

public class DirectorAndMovieCount
{
    public int Id { get; set; }

    public string FullName { get; set; }

    public string Country { get; set; }

    public int MovieCount { get; set; }
}

After creating the two tables and adding some movies, we wrote the aggregation part inside the CTE with a normal SqlExpression. That’s the movieCountPerDirector variable.

Then, we needed the JOIN between movieCountPerDirector and the parent query to apply all the filters and sorting. We wrote,

var query = db.From<Director>()
    .LeftJoin(movieCountPerDirector,
                (d, m) => d.Id == m.DirectorId,
                subQueryAlias: "mc")
    // ...    

We wrote a LeftJoin() that received a subquery, a joining expression, and an alias.

We might use aliases on the tables to avoid name clashes on the JOIN expression.

3. LeftJoin with another SqlExpression

And this is the LeftJoin() method,

public static partial class SqlExpressionExtensions
{
    public static SqlExpression<T> LeftJoin<T, TSubquery>(
        this SqlExpression<T> expression,
        SqlExpression<TSubquery> subquery,
        Expression<Func<T, TSubquery, bool>> joinExpr,
        string subqueryAlias)
    {
        // This is to "move" parameters from the subquery
        // to the parent query while keeping the right
        // parameter count and order.
        // Otherwise, we could have a parameter named '@0'
        // on the parent and subquery that refer to
        // different columns and values.
        var subqueryParams = subquery.Params.Select(t => t.Value!).ToArray();
        var subquerySql = FormatFilter(expression, subquery.ToSelectStatement(), filterParams: subqueryParams);

        // This is a hacky way of replacing the original
        // table name from the join condition with the
        // subquery alias
        // From:
        //      "table1"."Id" = "table2"."Table1Id"
        // To:
        //      "table1"."Id" = "mySubqueryAlias"."Table1Id"
        var originalCondition = expression.Visit(joinExpr).ToString();

        var definition = ModelDefinition<TSubquery>.Definition;
        var aliasCondition = definition.Alias == null
                                ? originalCondition
                                : originalCondition!.Replace(definition.Alias, subqueryAlias);

        // For example,
        // LEFT JOIN (SELECT Column1 FROM ...) cte ON parent.Id = cte.parentId
        expression = expression.CustomJoin<TSubquery>($"LEFT JOIN ({subquerySql}) {subqueryAlias} ON {aliasCondition}");

        return expression;
    }

    private static string FormatFilter<T>(SqlExpression<T> query, string sqlFilter, params object[] filterParams)
    {
        if (string.IsNullOrEmpty(sqlFilter))
        {
            return string.Empty;
        }

        for (var i = 0; i < filterParams.Length; i++)
        {
            var pLiteral = "{" + i + "}";
            var filterParam = filterParams[i];

            if (filterParam is SqlInValues sqlParams)
            {
                if (sqlParams.Count > 0)
                {
                    var sqlIn = CreateInParamSql(query, sqlParams.GetValues());
                    sqlFilter = sqlFilter.Replace(pLiteral, sqlIn);
                }
                else
                {
                    sqlFilter = sqlFilter.Replace(pLiteral, SqlInValues.EmptyIn);
                }
            }
            else
            {
                var p = query.AddParam(filterParam);
                sqlFilter = sqlFilter.Replace(pLiteral, p.ParameterName);
            }
        }
        return sqlFilter;
    }

    private static string CreateInParamSql<T>(SqlExpression<T> query, IEnumerable values)
    {
        var sbParams = StringBuilderCache.Allocate();
        foreach (var item in values)
        {
            var p = query.AddParam(item);

            if (sbParams.Length > 0)
                sbParams.Append(",");

            sbParams.Append(p.ParameterName);
        }
        var sqlIn = StringBuilderCache.ReturnAndFree(sbParams);
        return sqlIn;
    }
}

Let’s go through it!

It starts by copying the parameters from the subquery into the parent query. Otherwise, we could end up with parameters with the same name that refer to different values.

OrmLite names parameters using numbers, like @0. On the subquery, @0 could refer to another column as the @0 on the parent query.

Then, it converts the joining expression into a SQL string. We used the Visit() method for that. Then, if the subquery has an alias, it replaces the table name with that alias on the generated SQL fragment for the join expression. And it builds the final raw SQL and calls CustomJoin().

I brought the FormatFilter() and CreateInParamSql() methods from OrmLite source code. They’re private on the OrmLite source code.

Voilà! That is what I learned (or hacked) today. Again, things we learn when we read the source code of our libraries. We used the Visit(), CustomJoin(), and two helper methods we brought from the OrmLite source code to make this work.

We only used LEFT JOIN, but we can extend this idea to support INNER JOIN.

As an alternative to this ~~hacky~~ solution, we could write a dynamic SQL query. Next idea! Or we could create an indexed view to replace that counting subquery with a normal join. We could roll a custom method JoinToView() to append a WITH NO_EXPAND to the actual JOIN. I know everybody can’t afford a SQL Server Enterprise edition.

For more OrmLite content, check how to automatically insert and update audit fields with OrmLite, how to pass a DataTable as a parameter to a SqlExpression and some lessons I learned after working with OrmLite.

Happy coding!