How to Become Time Billionaire

True wealth isn’t just about money.

Apart from money, wealth also means health and freedom. Physical, emotional, and spiritual health. And freedom to choose to work on what you want, when you want, surrounded by people you want.

That was what Dan Koe and Sahil Bloom talked about during the next interview:

Here are 10 lessons I learned from that conversation:

#1. Not all time is equal. When you say “yes” to business or work, chances are you’re saying “no” to time with your loved ones.

#2. Imagine your funeral and ask yourself, who would be there? It might sound creepy, but start investing in your relationships. The simplest way to do that is by texting your friends when you remember them.

#3. Audit your calendar for energy creators and energy drainers. Find what makes you feel alive and what does not. Double down on your energy creators. And if you can’t avoid your energy drainers, batch them.

#4. Entrepreneurship is creating. It’s about finding a problem, coming up with a solution, and scaling that solution. And you don’t have to leave your full-time job to be an entrepreneur.

#5. Master storytelling and sales. Life is about sales. We’re constantly negotiating and selling, since we’re kids.

#6. Having a hard time niching down? Find something you’d stick to for 5-10 years.

#7. Question the things you “have” to. Question the default path. Create your own path.

#8. Define your enough life. How does your ideal day look like? When will you stop chasing the next step? The next promotion? The next milestone? What’s your enough?

#9. Use 30 minutes to 1 hour to create the life you want. If you can work 8 hours to make somebody else’s dream come true, you can work 1 hour to build yours.

#10. Have a Life Dinner with your partner or with yourself. Use that time to reflect and recalibrate.

“You’ll achieve more by being consistently reliable than by being occasionally extraordinary”

Better than being just a millionaire is to become a time millionaire, prioritizing what truly matters to you and living under your own terms.

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.