The Best Bad Example I'm Using to Teach Clean Code Principles in My Book

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

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

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

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

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.