9 Lessons from Writing 10 (Bad) Ideas Daily to Become an Idea Machine

Since October 2024, I’ve written 10 bad ideas every single day and it has transformed my creativity.

I started this practice inspired by James Altucher. I found it on his blog and books. Choose Yourself Guide to Wealth covers it in-depth. He calls it: becoming an idea machine.

The point of writing 10 ideas isn’t to come up with 10 perfect ideas, but to exercise your creativity and possibility muscles. The goal is to write 10 bad ideas about anything every single day.

Here’s what I’ve noticed after writing thousands of bad ideas in six months:

1. You can’t run out of ideas

One of my concerns when I started was running out of subjects to write ideas about. But the more I practice it, the more subjects I find to write 10 ideas about.

2. A 10-idea list could be a post

Most of my social media and blog posts start from a 10-idea list. This very post was a 10-idea list.

Writing 10-idea lists is the first step of my content wheel: 10-idea list, then a social media post, then a blog post.

3. It’s easier to execute ideas starting from 10-idea lists

Starting a big project may feel daunting, with too many moving parts and too much uncertainty.

But it’s easier starting with 10 bad ideas, then writing another 10 to execute one of them.

For example, do you want to write a book? Write 10 subjects you can write a book about. Then, write 10 titles for a book on one of those first 10 subjects. Then, write 10 ideas for chapters. Then, 10 stories to include…and so on and so forth.

4. The first 5 or 6 ideas are the easiest ones

The other 4 or 5 are when you start sweating and stretching your idea muscles. After those 4 or 5, that’s when the aha moments happen.

5. Give away 10 ideas to connect with others

Instead of reaching out to ask for anything, give away 10 ideas.

Since I started this practice, my favorite way to connect with someone on LinkedIn (or via email) is giving away 10 post ideas the other person could write. It surprises them and makes the connection more meaningful because you’re giving, not asking.

6. Writing 10 ideas works like note-taking

After consuming anything, a book or podcast episode, I write 10 ideas I learned from it. It works like taking notes. It helps me recall the main points of what I consumed and remember them more.

7. It’s a perfect exercise to quiet your mind

Write 10 ideas about anything and give your mind a productive task instead of letting it wander off imagining lions behind bushes trying to attack you.

8. It’s a perfect replacement for a to-do list

Since this year, I’ve ditched my to-do lists and replaced them with a done list. Guess how I do it? Yes, with a 10-point list.

At the end of every month, write 10 things you did in that month.

9. Write prompts for future days

As soon as I have a subject to write 10 ideas about, I write it as a prompt on a new page of my idea pad. Otherwise, I forget about it. It’s easier to sit down and write 10 ideas the next day when you already have a prompt ready.

Writing 10 ideas a day helped James Altucher get out of bankruptcy and change his life. For me? It has given me lots of ideas for new content. It helped me with my 100-daily-post challenge. It made me more creative. Because creativity isn’t just about art. It’s also coming up with bad ideas. It’s about becoming an idea machine.

Is Burnout Inevitable in the World of Tech?

In 2023, I burned out.

I checked all the boxes for the first time. The burnout boxes. It wasn’t a good thing. And it took me almost an entire year to recover.

I know I’m not the only one, of course. It’s all over the tech industry.

In recent weeks, I’ve been exchanging emails with another senior software engineer who went through a burnout season. His take? The tech industry is unsustainable.

These days, I’ve been chatting with a group of colleagues and friends. Most of them claimed to experience some sort of boredom at their jobs. OK, boredom isn’t burnout, but it’s a warning sign.

We’re privileged to work in the tech industry.

But, it has its own challenges—YMMV, of course:

  • We work long hours.
  • Coding is mentally exhausting.
  • AI threatens us to take our jobs.
  • Layoffs are always around the corner.
  • Agile and SCRUM take control away from us and trap us in “ceremonies.”
  • We’re problem solvers at heart, but often we don’t get to solve problems.
  • We’re expected to code after hours just to prove we’re “passionate.” Side projects and open source contributions.
  • We have high standards for quality and development practices. But stakeholders’ expectations don’t align ours. They care about different things.

The toll? Our mental health. Burnout.

The solution? I don’t have one.

Yesterday I found on the front page of Hacker News a post about tech being a burnout machine and unionizing as the solution. Mmmm. Dunno.

My best idea? Detach our sense of meaning from our jobs, recognize there’s nothing wrong with coding just to pay the bills, set boundaries between work and non-work, and diversify our sources of joy.

You Don't Need Superpowers to Be a Hero—Save Lives Today!

You don’t need X-ray vision, super strength, or any other superpower to save lives.

Recently, I read about James Harrison’s story, an Australian called the “Man with the Golden Arm.” His blood had a rare antibody used to treat a disease in pregnant women. He saved over 2 million babies, his own grandkids included.

A true hero without any superpowers. Well, a hero with super blood.

One family member, for health issues, has received blood transfusions at least three times in recent years. She has received 8 “units” in total. This means 4 heroes have saved her life. Since then, I’ve decided to donate enough to at least match the units she has received.

James was a hero for millions of babies. Some heroes saved my loved one. Inspired by them, I decided to become a hero for someone else too.

Forget about the red cape and boots, you don’t need them to save lives. Donate blood and be someone’s hero.

I Asked Phind and Copilot to Solve an Interview Exercise—Their Solutions Surprised Me

Did AI kill the tech interview?

Truth is hiring and interviewing have been broken for years. There wasn’t much left to kill. In over 10 years, I’ve witnessed all types of interviews: casual conversations, interrogation-like conversations with rapid-fire questions, take-home coding exercises, and the infamous LeetCode exercises.

I asked Phind and Copilot to solve an interview exercise. I might or might not have been asked that exercise when applying to a FAANG.

Here’s the “made-up” problem—Wink, wink:

You’re given a string containing the words “one” and “two”, and the symbols “+” and “-“ representing a math expression. Write a C# function called “Evaluate” to evaluate that expression after replacing “one” with 1 and “two” with 2. Assume the underlying expression is well-formed. For example, “one+one” should return 2, “two-two-one-two” should return -3, and “one+two-one-one+two+one” should return 4.

I’m using that exact same problem statement as a prompt for both Phind and Copilot. I know…I could have a more advanced prompt.

In this corner, with over 10 years of C# experience, me:

Here’s my “pure string evaluation” solution:

private int Evaluate(string str)
{
    var first = str[..3];
    var result = first == "one" ? 1 : 2;

    var index = 3;
    var lastOperation = '+';
    while (index < str.Length)
    {
        var substring = str.Substring(index);
        if (substring.StartsWith('+'))
        {
            lastOperation = '+';
            index++;
        }
        else if (substring.StartsWith('-'))
        {
            lastOperation = '-';
            index++;
        }
        else if (substring.StartsWith("one"))
        {
            result = lastOperation == '+' ? result + 1 : result - 1;
            index += 3;
        }
        else if (substring.StartsWith("two"))
        {
            result = lastOperation == '+' ? result + 2 : result - 2;
            index += 3;
        }
    }

    return result;
}

OK, that’s ugly and has lots of repetition. I looped through the string to identify if I was visiting a number or a symbol and stored the last known number and operation.

Nothing fancy! Probably I wouldn’t have hired myself with that solution. But, hey, “it works on my machine.”

And, let’s see what Phind and Copilot do. Place your bets…Drum rolls…

In this corner, with its “largest and most performant model to date,” Phiiiiind:

Here’s Phind’s exact solution (here’s my conversation but I don’t know how long it’s stored though):

public static class WordNumberEvaluator
{
    private const string ONE = "one";
    private const string TWO = "two";

    /// <summary>
    /// Evaluates a mathematical expression containing word numbers 'one' and 'two'.
    /// </summary>
    /// <param name="expression">The expression to evaluate</param>
    /// <returns>The numerical result of the expression</returns>
    public static int Evaluate(string expression)
    {
        // Replace word numbers with digits
        string processed = expression
            .Replace(ONE, "1")
            .Replace(TWO, "2");

        // Use DataTable.Compute to evaluate the expression
        var dataTable = new DataTable();
        var result = dataTable.Compute(processed, String.Empty);

        return Convert.ToInt32(result);
    }
}

public class Program
{
    public static void Main()
    {
        Console.WriteLine(WordNumberEvaluator.Evaluate("one+one"));       // Outputs: 2
        Console.WriteLine(WordNumberEvaluator.Evaluate("two-two-one-two")); // Outputs: -3
        Console.WriteLine(WordNumberEvaluator.Evaluate("one+two-one-one+two+one")); // Outputs: 4
    }
}

Phind surprised me a lot.

  1. It used a DataTable to evaluate expressions. I didn’t know DataTable could do that. I wouldn’t have thought about that in a real interview.
  2. It added docstring comments and two comments to explain its solution.

But that didn’t surprise me as much as seeing all the tests turning green when I ran its solution. For a moment, I thought using a DataTable was a hallucination. A veteran coder warned me about them the other day.

If you’re still skeptical, like me when I saw that function working, here’s Microsoft official docs on DataTable’s Compute method. It’s more Excel-like formulas inside a DataTable. The first parameter is an expression and the second one, a filter.

OK, the thing was Phind referenced 4 sources. Two of them were StackOverflow questions, one of them had the trick with the DataTable. But two of them were Medium posts talking about evaluating math expressions, but nothing inside them related to the solution it used.

And in this corner, backed by Microsoft, Copiiiiilot:

Here’s Copilot’s solution:

using System;
using System.Data;

class Program
{
    static void Main()
    {
        Console.WriteLine(Evaluate("one+one")); // Output: 2
        Console.WriteLine(Evaluate("two-two-one-two")); // Output: -3
        Console.WriteLine(Evaluate("one+two-one-one+two+one")); // Output: 4
    }

    public static int Evaluate(string expression)
    {
        // Replace "one" and "two" with their numeric equivalents
        expression = expression.Replace("one", "1").Replace("two", "2");

        // Use DataTable to evaluate the expression
        DataTable table = new DataTable();
        return Convert.ToInt32(table.Compute(expression, string.Empty));
    }
}

OK, I used Copilot on a browser, not inside my Visual Studio or Visual Studio Code. Same trick with DataTable. I wasn’t impressed the second time.

Not even in my dreams, (and I don’t dream about code) I would have thought about using DataTable as the trick under my sleeve here, especially with a clock-ticking on a platform like LeetCode or with a hiring manager looking at my screen.

Did AI kill the tech interview? I’d say yes, at least for data structure and algorithm questions. OK, I only tried it with one coding exercise, but that’s still a yes.

9 Subjects I've Changed My Mind About as a Software Engineer

Many things have changed over the past 10+ years in my career—technologies, mindsets, and even what I value most from my career.

I switched from Java to C#. I switched from JavaScript to Xamarin to ASP.NET to ASP.NET Core. From being the “new guy” in my first job to sitting in meetings with the CEO in one of my last jobs. It was a small company, maybe not that impressive.

Apart from those, here are 9 subjects I’ve changed my mind about:

1. Databases

I used to hate working with databases.

I hated them so much that I traded tasks with a coworker at a past job. He did my database tasks in exchange for his API-related tasks.

Avoiding learning about databases made me take down a server. I wrote a query with a function around a column in a WHERE clause. Ooops! Don’t do that!

Everything changed when I decided to learn about databases from scratch, with a beginner’s mindset. My googling took me to Brent Ozar and his courses.

Databases and SQL Server aren’t my kryptonite anymore.

2. Clean Code

I read Clean Code back in ~2013.

After that, I became a Clean Code police officer. I looked for Clean Code infractions everywhere around me. I was following and preaching the book.

Eventually, I learned that not all code is created equal and worth the same. Everything is a tradeoff. And we shouldn’t blindly follow best practices.

3. Certifications

“Azure Blah Blah Blah Associate” or “Google Blah Blah Blah Developer.” That sounds impressive.

When I started coding, I wanted to pile up all those certifications. Until I learned these certifications are often a marketing strategy from the certifying company. Every once in a while, they change the certification tracks and you have to start again. And of course, pay again.

Instead of certifications to prove my “knowledge,” I opted for just-in-time learning in the context of real projects.

And if you’re chasing certifications to make your CV look good, if your CV is in a pile (physically or virtually), you already lost.

4. Optimizing everything

I went from finding small improvements on a random line of code to finding the biggest improvement I could gain with minimal effort, after gathering the right metrics, of course. That’s one of the lessons I learned from Brent Ozar. See #1 again.

5. Climbing the corporate ladder

I used to believe I could climb all the way up to the top of the corporate world.

I was wrong! Anyone can add new steps to that virtual ladder. Anyone can change the entire ladder and you’ll have to start climbing all over again. At any point, someone can say “you’re not ready yet. Keep working hard. Next year.”

I’ve seen only one successful climb in over 10 years. She joined as an intern and yeeeears later, she became VP of something. It was at my first job. When I joined, she was already VP. Somebody told me the legend.

Instead of climbing somebody else’s ladder, I decided to build my own and define my own success metrics.

6. Working hard

“You only do your job and clock out on time,” he said.

I was on a 1-on-1 with an ex-boss. I don’t remember if he brought up the names of coworkers who worked harder than me. Maybe he implied that in his feedback.

Funny thing is months later, when the Hunger Games of layoffs began, all those who worked harder were the ones leaving first.

Apart from working hard, there are other ways to stand out, of course while being in the right place. Do a good job and clock out on time.

7. Being passionate

I hate seeing “passionate” anywhere online. On job listings, CVs, and personal blogs.

What does passionate even mean? Working extra hours, arguing about code style on code reviews, or contributing to open source? I’m not sure anymore.

For me? All that passion faded away. I learned to diversify my sources of joy and stopped trying to only find fulfillment from a job.

I’m not passionate anymore.

8. Being a full-stack developer

I started writing WebForm apps, then web apps with Bootstrap and Knockout.js, then mobile apps with Xamarin.

Until I wrote my first REST API with ASP.NET Web API. I didn’t like the “pace” of the front-end ecosystem. Too many frameworks and “something.js” libraries. And too many issues about colors and alignment. It wasn’t my type of thing.

I stopped trying to become a “full-stack” developer. Often, that’s an excuse to hire fewer people and overwork others and pay low salaries. Sorry, but not sorry.

Mmmm…Well, now that AI is “taking” our jobs, maybe we all have to become full-stack developers. And maybe I’ll change my mind about this and write anoter post.

9. Being the best coder

I don’t want to be the best coder on a team anymore.

I believed cracking symbols on a page was the way to go. I’ve learned that the best coders stay coding. And there’s more than symbols on a file. The hardest part of software engineering isn’t the code, but “people and interactions.” And that’s where the real growth happens.

Starting out or already on the coding journey? Join my free 7-day email course to refactor your software engineering career now–I distill 10+ years of career lessons into 7 short emails.