The Main Benefit of a Daily Writing Habit: 100 Daily Posts Reflection

Imagine writing a blog post every day for over 20 years.

Seth Godin has done just that. A post a day for over 20 years means more than 7,000 daily blog posts. That’s more than impressive. I’ve always admired Seth’s blogging rhythm.

Inspired by Seth Godin and other daily writers like Tim Denning and Herbert Lui, I started writing daily on my blog in November 2024. I even created a new tag, /misc, for everything outside of software engineering and coding. That’s part of my strategy in these days of dead blogging.

For my daily writing challenge, one headline and one main idea are enough to call it a day. No cover image. No need for 10 points. If it’s longer than a tweet, it’s OK to publish. Around 200 words is my sweet spot.

A daily writing habit has made me more conscious of the content I consume.

When we set the intention to write daily, we start to see content everywhere: conversations, quotes, passages from books, podcast episodes, comments on social media, TV shows…“Oh, that could be a post, I’d better write down that idea.”

My goal was to publish 100 daily posts starting on November 1st. This is my daily post #100. Mission accomplished.

Often You Don't Want It, but You Become a Leader—By Omission

One day, you’re the only team member and the next, you’re a leader, without asking for it.

Been there and done that.

Back in one of my first jobs, at some point, I was the only one in the mobile team.

We were building the prototype of a mobile app with Xamarin. I don’t know if that’s still a thing. When there was too much work for me, two team members joined from other teams. They were learning Xamarin and getting up to speed with the business domain.

And the next day, I started to be responsible for their work. Management asked me, not them, when they were behind schedule. I thought my job was only answering their questions and offering help. Nope!

I wasn’t a leader and I didn’t want to be one. But that day, I became their leader by omission.

And recently, it has happened to me again.

But this time, I was on the other side of the table. I joined a small agency and got assigned to a project with only one team member. He was a lone wolf, working on his own corner with zero dependencies and shared work. The challenge came when we needed to sync our work and keep an eye on dependencies between our tasks. He was so used to working alone, and I was expecting more collaboration.

When you’re the most senior member or the only team member, as soon as new pairs of hands come, you become the point of contact, the go-to person for questions and problems. Upper management starts to ask you about the new team members. You don’t ask for it, but you become a leader. A leader by omission. And remember as a leader, you’re not the best coder anymore.

10 Productive Tasks for the Days You Don't Feel Like Writing

Like any other form of art, writing requires daily practice.

Seth Godin has been doing it daily for over 20 years. Daily! That’s more than 7,000 posts.

But I know, life throws us curveballs. Unexpected things happen. And some days, writing feels impossible. On those days, we feel like letting the chain break.

There are still writing-related tasks (that are not writing) we can do on those days. Here are 10:

1. Proofread and edit future posts.
2. Find cover images or create visuals.
3. Steal headlines, hooks, and opening lines.
4. Repost top-performing posts in social media.
5. Hand-write book passages (or posts) from your favorite writers.
6. Audit posts from past days: What headlines did you use? What type of visuals?
7. Collect your most liked comments and turn them into separate posts or headlines.
8. Tweak low-performing posts: Create new visuals, change headlines, or add new stories.
9. Turn long-form content into short-form content or vice-versa: Blog posts or newsletters into Tweets or LinkedIn posts.
10. Repurpose top-performing posts: Turn a blog post into a LinkedIn carousel or create quote images from it.

Even if you don’t write daily, at least do anything writing-related. But never miss two days in a row. Otherwise, like any other muscle, your writing muscles will atrophy.

Essential First Steps for Unit Testing in C#

Today I got a question from Pierre on my contact page about unit testing. Here’s an edited version of his question:

I’m stuck at square one: how do you invoke the Unit Tests? Where are the tests stored? Are they compiled into the Release code? Is there one function that calls the whole cascade of unit tests? Nobody seems to address this very basic, indispensable first step.

I slightly covered some of those questions on my post to write your first unit tests with MSTest. I tried to write a beginner-friendly introduction to unit testing. But, Pierre is right. I forgot to answer those questions.

So here I go:

1. Are unit tests compiled into our Release code?

First things first. We don’t ship unit tests to our end users. And, no. They’re not compiled into our release code.

We write unit tests as part of our development process. Let’s say unit tests are code written for developers by developers.

The best analogy? Writing unit tests is like crashing cars as part of their security tests in a factory. Well, car makers don’t ship crashed cars. Unit tests are like those crashed cars. We use them to test the cars we’re shipping to our users, but don’t ship them to our end users.

2. Where to put our unit tests

The convention I follow is to put unit tests in separate projects, named after the project where the code under test is, using “Tests” as a suffix.

For example, if our code to test is under a project called Acme.CoolProject, we should put our tests into a project Acme.CoolProject.Tests. And inside the test project, we should use folders with the same name as the code under test.

Now about the folder structure to put our tests, I’ve seen and used two options:

#1. Using a src and test folders at the root of the solution, like this

Acme.CoolProject.sln
 |-src/
 |---Acme.CoolProject.Api/
 |-tests/
 |---Acme.CoolProject.Api.Tests/

#2. Using a src and test folders inside folders per project, like this

Acme.CoolProject.sln
 |-Api/
 |---src/
 |-----Acme.CoolProject.Api/
 |---tests/
 |-----Acme.CoolProject.Api.Tests/

From the two options, the first one is the most common and it’s my go-to folder structure.

For the actual tests names, I’ve found these four test naming conventions.

3. How to invoke our unit tests

There are three options to invoke our tests—Again, we as developers, are the ones who invoke tests, not our end users:

#1. Directly from your IDE: Testing frameworks come with test runners that discover and run our tests. So we can simply press a button inside Visual Studio or our IDE to run one test, all tests inside a folder, or all the tests inside our solution.

#2. From the command line: Thanks to .NET CLI, we can simply run dotnet test inside a folder to run all the tests inside that folder.

#3. From a deployment tool: If we’re using a continuous integration and deployment tool, like GitHub Actions or Jenkins, we can run our tests as part of the deployment workflow to make sure we’re not shipping broken code. These tools default to the .NET CLI to run the tests under the hood.

So there’s no one function that calls the whole cascade of unit tests, but a button on your IDE.

Et voilà! To read more about unit testing, don’t miss the rest of the series Unit Testing 101.

Grab a copy of my ebook, Unit Testing 101: From Zero to Your First Tests and learn to write your first unit tests in C#.

5 Essential Lessons for New Bloggers from a Viral Post

One of my posts recently went viral on dev.to.

It was the one about why we shouldn’t try to test private methods. And here’s the dev.to version.

When I say “viral,” I mean viral by my standards. It received +30 reactions, +30 comments, and +5K views. That was after two days of posting. Two days. It probably got syndicated or reshared somewhere else.

It’s not that impressive for tech influencers with a larger follower count. But it is for me.

Since I don’t want this to be a “see how cool I am” kind of post, here are 5 lessons I learned that I’d like to pass on to new bloggers:

1. You can’t predict your next hit

No matter how hard you try, you can’t predict which post will go “viral.”

Often the posts you write to mark the calendar are the ones that get some traction, not the ones you spend time crafting. This one was one of those. I wrote it to mark the calendar as part of my 100-daily-posts challenge I started in November 2024.

Since you can’t predict your hits, keep writing, even if you think nobody is reading.

2. Go with social blogs to get more traction

I wrote that post originally here on my blog in November 2024. Since then, it only got less than 10 views.

But it went viral when I reposted it on dev.to. It was sitting on my blog behind search engines. I had to wait for search engine bots to crawl, index, and rank my post. And that could take weeks or months.

On social blogs, like dev.to or Medium, there’s already an audience and a discoverability feature. Old-fashioned blogs don’t have that. That’s the problem with blogs.

If you’re new to blogging or struggling to keep writing, don’t start on your own blog. Go with a social blog. If you don’t know where to start, try with dev.to.

3. Always promote something at the end of your posts

These days, I have learned from Spain’s top copywriter, that an email should be like a radio show.

A radio show has a bit of education, a bit of entertainment, and a promotion. And a post should be the same.

Promote something at the end of your posts: your ebooks, newsletter, or courses. I got 7 downloads of my ebook Unit Testing 101: From Zero to Your First Tests on my Gumroad page thanks to that post.

Promote something that aligns with the content of your posts. Share something of value, not just simply asking for a coffee.

If you don’t have an ebook or something, promote other posts. If Netflix does the same at the end of a movie or show, we can do the same.

4. Remember the 30/30/30 rule

My post got more than 30 comments.

Some people jumped to support my idea. Others jumped to offer interesting alternatives. Others simply said I wasn’t answering anything. Others went on a tangent talking about 3D rendering with JavaScript. Somebody else jumped to promote a jewelry business or something. Whaaaat! Yes, a jewelry business on a coding platform. Whatever.

No matter who you are or what you do, 30% will love it, 30% will hate it, and 30% won’t even care.

5. Answer questions in public

I didn’t come up with the subject of that post myself. I stole it.

One day I was wasting my time on Reddit, probably waiting on a line or something, and I found that question. I realized I could answer it and I did so.

It was a genuine question someone asked. Someone else will probably google the same question. And answering it was good in SEO terms for my blog. And that’s one of the tricks you can use to double your post count.