Friday Links: Single-letter names, Windows 11, and optimization

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)

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

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

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

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