Forget Writer's Block: Here's the Real Problem and How to Fix It

Nothing is scarier than a blank page, but what if the problem isn’t writer’s block?

If you stare at a blank page with nothing to write, you’re not suffering from writer’s block, but from the lack of an idea-capturing system.

Here’s how to fix it.

1. Garbage in, garbage out

You are the food you eat and the content you consume.

Of course, if you’re mindlessly scrolling TikTok, you won’t have anything to write about.

Instead, be conscious of what you consume. Read more. Read fiction and non-fiction. Read anything that crosses your path. That’s your source of inspiration.

And apart from inspiring you, being exposed to good writing is the best way to learn to write.

2. Have a capturing system

Content is everywhere.

From comments in social media to quotes to TV shows to conversations to book passages. Everything and anything that happens around you is full of content ideas. In fact, this post started as a comment on social media.

Have a place to store and organize those ideas: Your phone, pen and paper, sticky notes, plain-text files, a stone and chisel. Anywhere.

Since last year, I’ve been following James Altucher’s Idea Machine concept. After consuming (almost) anything, I write 10 ideas or lessons I learned from that. Usually those 10 ideas become posts.

Notice content ideas around you and don’t let them go.

3. Don’t try to come up with anything original

There’s nothing new under the sun.

That’s from Ecclesiastes, from the Bible, from thousands of years ago. There wasn’t anything new back then. And there isn’t now. We’ve been adding, subtracting, and remixing ideas since then.

You don’t have to come up with original ideas to write. If you find somebody else’s idea (remember #2?), you can make it yours by sharing it from your perspective, along with a personal story.

Consume, capture, and remix ideas and you will always have something to write about. If you still think you have nothing to write, follow this tip. And no, you will never run out of ideas to write.

We'll Lose the Battle Against AI-Generated Content. Here's What to Do Instead

“In the realm of…” “In the world of…” “In our fast-paced world”

AI-generated content floods the Internet. And it’ll only get worse as AI tools become better.

That’s not new. We’ve had mediocre content flooding the Internet since always with spam and posts playing SEO schemes.

I write on dev.to, and I still find posts full of keywords pretending to rank higher in the search results. SEO is dead. Well, that’s what everybody claims these days.

We have to choose our battles.

And we’ll lose the one against AI-generated content. Every day we have more and better AI tools that generate mediocre content in seconds. A 1,000-word post? Beep, beep, boop. Boom! Here you have it!

If you’re writing anywhere online, complaining about AI-generated content won’t do anything. Complaining in general doesn’t do anything.

From James Altucher, one of my favorite writers, I’ve learned that:

“If AI can write it, you need to rewrite it.”

If you want to stand out in an ocean of AI-generated content, you have to do what AI can’t do yet: add your personal touch, experiences, anecdotes, stories, and bad jokes. You have to make your content more human. You have to find your voice.

AI is going to kill mediocre writers, but it’ll make good writers stand out.

Writing For Developers: Takeaways and an Honest Review

Like coding, writing is everywhere in software projects.

From README files to use cases to bug reports to blog posts. We developers spend as much time writing as coding, if not more.

Chances are if you’ve been stuck with an error for hours, some random guy’s blog post has saved your day.

Writing for Developers shows how to write those technical (or engineering) blog posts.

Here’s my honest review and key takeaways:

“You’re not writing enough” and other takeaways

#1. Technical blog posts don’t have to be boring.

They should have a balance between an interesting subject, a valuable lesson, and good packaging for the reader. And after reading your posts, your readers should leave with something learned.

#2. If you find a subject interesting, other people will find it too.

Write about anything you find interesting.

But if you’re writing for the first time and you’re not sure what to write about, remember 3 Ps:

1. what you’re passionate about
2. what you’re pained by
3. what you’re proud of

#3. We shouldn’t rely on AI to write our posts.

But, it doesn’t mean we can’t use it to critique or review our drafts.

Here are two prompts to critique our drafts:

1. “Are there any statements in this engineering blog post that do not seem adequately supported by facts?”
2. “Can you identify any parts of this article that seem less relevant to its main goal of [your goal]?”

My favorite lesson? “You’re not writing enough.” You can always write more.

My alternative “how to read this book”

Writing is not a subject you will learn from a single book.

It takes years to master it. And we, as developers, have a double challenge: putting words together and presenting complex subjects clearly.

If you’re new to writing, you will get more out of this book by reading the first two parts, especially chapters 4 and 5. They cover how to write and polish your first draft.

This book doesn’t answer where to write. It slightly covers how to do it in an appendix. If you’re writing for your company’s engineering blog, they likely have already sorted out those details. Hopefully.

Now if you’re not new to writing, let’s say you already have a blog and have published more than a dozen blog posts, you will get more out of this book by reading Part 3.

Part 3 covers 7 blog post patterns:

1. Bug Hunt
2. Rewrote it in X
3. How We Built it
4. Lessons Learned
5. Thoughts on Trends
6. Non-markety Product Perspectives
7. Benchmarks and Test results

Each chapter contains sample blog posts, a commentary on those posts, and an explanation of how to write each type of post.

That was my favorite part.

Definitely I’ve written some of those type of posts. But I didn’t think of them as patterns we could implement.

My final verdict? 3.8/5.

TIL: AutoMapper Only Considers Simple Mappings When Validating Configurations

Oh boy! AutoMapper once again.

Today I have CreateMovieRequest with a boolean property ICanWatchItWithKids that I want to map to a MPA rating. If I can watch it with kids, the property MPARating on the destination type should get a “General” rating. Anything else gets “Restricted.”

To my surprise, this test fails:

using AutoMapper;

namespace TestProject1;

[TestClass]
public class WhyAutoMapperWhy
{
    public class CreateMovieRequest
    {
        public string Name { get; set; }
        public bool ICanWatchItWithKids { get; set; }
    }

    public class Movie
    {
        public string Name { get; set;}
        public MPARating Rating { get; set;}
    }

    public enum MPARating
    {
        // Sure, there are more.
        // But these two are enough.
        General,
        Restricted
    }

    [TestMethod]
    public void AutoMapperConfig_IsValid()
    {
        var mapperConfig = new MapperConfiguration(options =>
        {
            options.CreateMap<CreateMovieRequest, Movie>(MemberList.Source)
                    .ForMember(
                        dest => dest.Rating,
                        opt => opt.MapFrom(src => src.ICanWatchItWithKids
                                                        ? MPARating.General
                                                        : MPARating.Restricted));
        });

        mapperConfig.AssertConfigurationIsValid();
        //           ^^^^^														
        // AutoMapper.AutoMapperConfigurationException:
        // CreateMovieRequest -> Movie (Source member list)
        // TestProject1.WhyAutoMapperWhy+CreateMovieRequest -> TestProject1.WhyAutoMapperWhy+Movie (Source member list)
        //
        // Unmapped properties:
        // ICanWatchItWithKids
    }
}

It turns out that starting from AutoMapper version 10.0, only source members expressions are considered when validating mappings. And it’s buried in the Upgrade Guide here. Arrggg!

Two solutions: One for the lazy and the right one

Since I’m validating mappings based on the source type, I can simply ignore it:

options.CreateMap<CreateMovieRequest, Movie>(MemberList.Source)
	.ForMember(
		dest => dest.Rating,
		opt => opt.MapFrom(src => src.ICanWatchItWithKids ? MPARating.General : MPARating.Restricted))
	.ForSourceMember(src => src.ICanWatchItWithKids, opt => opt.DoNotValidate());
	// ^^^^^
	// Thanks AutoMapper, I'll take it from here.

It feels like cheating, but it works.

Or, I can use a converter:

options.CreateMap<CreateMovieRequest, Movie>(MemberList.Source)
	.ForMember(
		dest => dest.Rating,
		opt => opt.ConvertUsing(
                       // ^^^^^
                       new FromBoolToMPARating(),
                       src => src.ICanWatchItWithKids));

// And here's the converter:
public class FromBoolToMPARating : IValueConverter<bool, MPARating>
{
    public MPARating Convert(bool sourceMember, ResolutionContext context)
    {
        // Here's the actual mapping:		
        return sourceMember ? MPARating.General : MPARating.Restricted;
    }
}

Another day working with AutoMapper. It would have been way easier mapping that by hand.

For more adventures with AutoMapper, check How to ignore unmapped fields in the destination type.

What Happened Around This Day In My Blog

A bit of nostalgia, reflection, and compilation today.

This is what happened, not today, but around this day in my blog:

Last year, before being laid off, I had just finished another short project with a contracting client. It was a project to support events, like weddings and conferences, in a hotel management software. That project taught me more about leadership and project management than coding. I wrote two lessons I learned from that project.

In 2023, I started a 4-part series on NullReferenceException with a post about when NullReferenceException is thrown and how to avoid it.

In 2022, I was still running Monday Links here. I wrote about Daily Meetings, Estimates, and Challenges. From that episode, I included a post I found with 5 signs to look for when it’s time to quit your job.

By the way, these days, I’m not running Monday Links, but Friday Links on an email list. Every Friday, you’ll get a 2-minute email with curated resources about programming and software engineering. Join here.

In 2021, I was working with a Stripe-powered payment processor. And I wrote about how to use the Decorator pattern to implement retry logic when sending payments to Stripe. The analogy I used to explain the Decorator pattern was IronMan wearing the HULKBUSTER suit.

In 2020, I used the Pipeline pattern to create a pipeline of steps to make reservations. And since I had already used it to create invoices and notes in an invoicing system, I decided to write about it.

In 2019 and 2018, I didn’t write in February. It’s a shame. Well, I was still trying to find my rhythm and what to write about.