I'm Launching Street-Smart Coding: 30 Lessons to Help You Code Like a Pro (the Roadmap I Wish I Had Starting Out)

I spent five years in college learning to code.

A stupid dissertation delayed my graduation. But that’s another story.

Most of my five-year program didn’t prepare me for real-world coding. My real coding journey began at my first job, with one Google search: “how to get good at coding.”

I found a lot of conflicting advice:

• “Use comments”
• “Don’t use comments”
• “Do this”
• “Don’t do that”

Arrggg!

It took years of trial and error to learn what worked.

I had to survive on-call shifts, talk to stakeholders, and say “no” politely. More importantly, I had to learn that coding takes more than just syntax.

That’s why I wrote Street-Smart Coding— a roadmap of 30 lessons I wish I had when I started. For every dev who’s ever typed “how to get better at coding” into Google or ChatGPT. (Back in my days, I didn’t have ChatGPT… Wait, I sound like a nostalgic grandpa…)

Inside “Street-Smart Coding”

This isn’t a textbook. It’s a battle-tested guide for your journey from junior/mid-level to senior.

Some lessons are conventional.

Others were learned the hard way.

And a few are weird.

One lesson comes from a TV show. Nope, not Mr. Robot or Silicon Valley. That’s on Chapter #29. It will teach you about problem-solving.

You’ll learn how to:

• Google like a pro
• Debug without banging your head against a wall
• Communicate clearly with non-tech folks

…and 27 more lessons I learned over ten years of mistakes.

Now they’re yours.

Get your copy of Street-Smart Coding here and skip the years of trial and error. For launch week only: Pay what you want—even $1 or $2.

TIL: Blazor Breaks When Others Touch the DOM

In another episode of Adventures with Blazor…

Once more, I ran into the mysterious “TypeError: Cannot read properties of null (reading ‘removeChild’)”. But unlike the last time, it wasn’t a problem in a third-party component that we had to replace. It was my fault.

Wouldn’t it be great if the error message mentioned which property was null: an id, xpath, or CSS class?

This time, a modal created a record and showed a success alert. But after dismissing it and closing the modal, the page broke with the same error.

Here’s a Blazor page that recreates the scenario. A simple modal with a form that shows an alert bound to a _directorSavedSuccessfully. Notice the <div> wrapped around the @if inside the <BodyContent>.

@page "/directors"

<button class="btn btn-primary" @onclick="AddDirectorClicked">Add Director</button>

<ModalDialog Title="Add Director" @ref="_editDialog">
    <BodyContent>
		@if (_directorSavedSuccessfully)
		{
			<div class="alert alert-success alert-dismissible fade show" role="alert">
				Director saved successfully.
				<button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
				@*                                      ^^^^^ *@
			</div>
		}

		<EditForm Model="_editDirector" OnValidSubmit="SaveDirectorClicked" id="directorForm">
			<InputText @bind-Value="_editDirector.Name" class="form-control" />
		</EditForm>
    </BodyContent>
    <FooterContent>
        <button type="button" class="btn btn-secondary" @onclick="CloseClicked">Close</button>
        <button type="submit" form="directorForm" class="btn btn-primary">Save</button>
    </FooterContent>
</ModalDialog>

@code {
    private ModalDialog? _editDialog;
    private bool _directorSavedSuccessfully;
    private Director _director;

    private void AddDirectorClicked()
    {
        _directorSavedSuccessfully = false;
        _editDialog?.Open();
    }

    private Task SaveDirectorClicked()
    {
        // Imagine we're calling an API here to save...
        _directorSavedSuccessfully = true;

        return Task.CompletedTask;
    }

    private void CloseClicked()
    {
        _directorSavedSuccessfully = false;
        _editDialog?.Close();
    }
}

Bootstrap removed the alert node directly, via the data-bs-dismiss="alert". But Blazor was still “tracking” it. So when the modal was closed, Blazor didn’t find the alert. Somebody else ate its cheese. And boom!

The solution? Don’t let anything else touch the DOM, but Blazor. Wire that alert to a variable controlled by Blazor.

-<button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
+<button type="button" class="btn-close" @onclick="_ => _directorSavedSuccessfully = false" aria-label="Close"></button>

Et voilà! Let Blazor own the DOM.

For debugging and problem-solving tips, read Street-Smart Coding. And it’s even more relevant now in the era of AI-assisted coding.

My Phone Showed Me I was the Enemy of Boredom (4 Ways to Embrace It)

I can’t remember the last time I stared at the ceiling, wondering “what should I do now?”

Growing up without smartphones or tablets made me a friend of boredom. I lived on a main street of a small city. When bored, I counted passing cars in my front yard. Sometimes, I competed with my uncle and sister. The one who counted more cars of a certain color won. Yellow taxis weren’t allowed.

Years later, with an iPhone, work, and side projects, boredom turned into an enemy. I’ve had to work to bring it back.

What I’m doing to be bored again

The other day, I had so much on my mind that I had to sit and do nothing. That was my wake-up call.

To welcome boredom again:

#1. Less phone time. I’m reducing my phone time. Now my phone is in another room. There are books where I used to put it. And I’m writing this with pen and paper first.

#2. A “do nothing” slot. Apologies for the irony, but I’ve set an alarm in my phone labeled, “Mandalas afternoon.” I used to color mandalas during my lowest emotional season. I need to change that label. It should be “do nothing afternoon” and honor it. Not that coloring mandalas is a bad idea.

#3. Walking outdoors. For my physical and mental health, I go running next to the ocean. I’m planning to buy an analog watch (a classical Casio. Anyone else?) and leave my phone at home or put it inside my bag in silent mode.

#4. An Amish hour. I’ve moved my book reading time to one or two hours before bed, away from screens. One evening, after a coffee with a friend, too much caffeine and late-night writing kept me awake for hours. So no more screens before bed. The next challenge: an Amish afternoon. Or even an Amish day. Why not?! I’ll just need to write my daily post in advance.

Forget the Hit Book. Write a Series

“Is there a next part? Are you covering the next stage after being a good coder?” a friend texted me.

He finished Street-Smart Coding, my first book, and was eager for more. A reminder of a marketing lesson I had forgotten.

The best way to promote your book is by writing another one.

I first heard this surprising strategy on James Altucher’s podcast.

Nicolas Cole, author of The Art and Business of Online Writing, teaches the same strategy.

On his YouTube channel, he advises building a portfolio of books instead of chasing one big launch. When readers finish and enjoy your book, they want more. One single title after a big launch doesn’t meet that need.

That’s what happened to my friend after reading my book. And that’s more encouragement to work on the next one.

I'm Running a Book Experiment This February

I’m writing a book backwards.

Technically, it’s a mini-book. I’m turning a hit post into a book.

In the spirit of doing 10,000 experiments and to keep running content experiments, here’s what I’m doing this month:

#1. Repurpose a hit post. I’m turning one of my most read and liked posts into a short book. Over 100 people liked that post. Proof that the idea works. I’m even naming the book after the post.

That’s what the authors of The Subtle Art of Not Giving a Fuck and The Psychology of Money did.

#2. Find inspiration from comments. My hit post got a decent amount of discussion. I’m using those comments to find keywords, taglines, and objections.

#3. Expand it. The source post is a 7-point listicle. I’m turning it into a 10-chapter concise book, like Steal Like an Artist. Each point expands into one or two pages with stories and past posts.

#4. Write it backwards. Instead of jumping to the introduction, I’m:

• Choosing a title
• Writing a one-line summary
• Outlining the content
• Finding Amazon keywords and categories
• Sketching a sales page

I’m even stealing cover ideas before writing a word.

#5. Make it short. The other day, I found a one-page book, so why not write 10 or 15 pages and call it a book? One or two pages per point plus the front and back matter.

#6. Price it incrementally. I’m following the “$0.99 is the new free” idea. If it gains traction, I’ll raise the price by $1 every other month until it hits $5.

#7. Hit one reader milestone. Just like I set it for Street-Smart Coding, if even one reader beyond my circle buys it, the experiment is a success.

Better A Small Rep Than A Broken Habit

Yesterday I found a LinkedIn post asking if a crap post was better than no post at all. I didn’t want to bury my answer on the comments section. So I’m expanding it a bit here.

A crap post is better than silence.

Well, 90% of everything is crap. Most of what we create won’t be great. And that’s ok.

But writing, coding, or any creative pursuit is like exercising. Skip the gym once, nothing happens. Skip twice, and suddenly you’re on the couch, binge-watching Netflix, wondering where the extra weight came from.

Whether it’s a post slightly longer than a Tweet, some random thoughts, a few lines of code, or quick sketches, a small, imperfect repetition is better than breaking a habit.

Your small reps won’t make you lose credibility. They prove that when life throws curveballs, your habit stays intact.