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

7 Hard-Earned Lessons from Launching Street-Smart Coding

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

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.