Friday Links: Politics, highlighting, and death of coding

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

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

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)

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

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