Three Things to Remember When the Haters Show Up

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

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:

1. Understand the problem to solve
2. Decompose that problem into smaller ones
3. Think at the right level of abstraction
4. 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

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

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

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.