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, check four common mistakes when writing your first unit tests and the rest of the series Unit Testing 101.

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.

How I Made Money Coding and How I'd Do It If I Had to Start Again

These days, I got a question from Venkata on LinkedIn. Here’s an edited version of that question:

I need your guidance on how to turn my skills into an opportunity to earn income by solving a real world problem or project.

Here’s my answer. Of course, this is free Internet advice. Take it with a pinch of salt.

I won’t tell you what to do. Let alone do I have a step-by-step formula. I’m telling you what I did and what I’d do if I had to start again.

I’m assuming you’re a new graduate from university or a bootcamp with a few years of flight time.

1. Take a tour of the corporate world

As crazy as it might sound, take a corporate job in a company in your city. Even if it’s at a boring non-tech company without a big name.

A boring job in a non-tech company is not the dream destination. I know. When we all start, we dream about joining the next rising startup or a FAANG. But you don’t have to stay in the corporate world forever.

In a corporate job:

• You can get some training and learning opportunities.
• You will learn to work with legacy codebases.
• You can make mistakes on somebody else’s business with almost no consequences.

My first coding job was at a boring non-tech company. I had to learn about coding, deal with bosses and coworkers, and survive office politics. You won’t learn that at a university or a bootcamp.

If you choose this route, don’t try sending CVs like crazy to anywhere and everywhere. Use your network and try to skip hiring lines.

Don’t stay too long at a corporate job. Your skills will get rusty. Stay long enough to increase your hours of flight time before jumping somewhere else.

2. Get good at one skill and join a high-paying market

Once you have enough hours of flight time:

1. Get good at one skill: frontend development with React, backend development with .NET, or whatever skill you can put time and effort into learning.
2. Get good at a foreign language: Good enough to work professionally in that language.
3. Join a software agency and work for high-paying markets like North America or Europe: You can take advantage of currency strength between countries.

Based on your country of residence, you can make good money with this route compared to local markets.

3. Going on your own

Points #1 and #2 were like getting someone to feed you. This is like hunting on your own.

Find small businesses in your city and see how you can help them with automation. You’d be surprised how many small businesses and mom-and-pop shops run their daily operations with pen-and-paper or Excel.

If you choose this route, you can’t tell clients “I write HTML, CSS, and JavaScript. I care about Clean Code and I’m not a coder, but a craftsman.”

Sure, those are nice-to-haves. But that’s the lingo you and I understand. Small businesses don’t care about those things. They care about what you can do for them and their business.

You have to sell yourself in terms that your clients can understand. “I can help you implement a system that will cut in half the time it takes you to deliver your restaurant orders. Your clients will receive their food while it’s still warm.”

And don’t even think of writing code from scratch. Go with no-code solutions or easier ways for you to implement. Even installing existing software and training small companies on how to use them.

I’ve done #1 and #2. And if I had to start again, I’d try something like #3. Good luck!

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.

How to Land a Coding Job in Post-Pandemic Times—The Untraditional Way

Last year, I sent out over a dozen of CVs and cold emails within a month.

I was laid off. I went into panic mode. I applied to many companies. Anything with the word “coding” or “software engineering” in the job description. I even applied to a FAANG though I rejected that idea years ago.

But I just got radio silence.

2024 was a tough market. I know because I wasn’t the only one going through layoffs. The entire industry was. I even talked to an ex-coworker and he told me he had sent one hundred applications. I don’t know if he meant literally 100 applications or not. But I wouldn’t be surprised. He only got two or three positive responses.

Today I found a reflection on dev.to from a junior developer.

Last year, she finished a coding bootcamp or something and started to look for jobs. Oh boy! It must have been tougher for her. After the bat-soup and 2023, it seems nobody is hiring junior engineers anymore. And she tried the CV route.

CVs are dead. They’re so last century.

And sending lots of CVs won’t land you a job. Otherwise, someone with a printing business will find tons of jobs just by printing and mailing CVs. Well, sending CVs is a numbers game. Maybe out of 100 applications, you’ll get 2-3% of responses back if you’re lucky. Who knows!

Instead of CVs, I’d try an indirect approach to look for jobs:

1. Follow on LinkedIn, companies you’d like to work for and people (especially hiring managers) who work there.
2. Start genuine conversations. Ask how working there is and ask for referral programs.
3. If you use the company’s product, show up with ideas to improve the product. Or the company website or social media presence. Don’t simply send your CV with an “I do anything coding-related for money” attitude. That’s what I did with obviously poor results. And don’t appear desperate either.
4. Go through your network, asking if anyone knows someone working at a place where you could fit. Repeat steps 1 to 3. Or ask for an introduction.

I found my first job because I knew someone who knew someone at a company looking for coders. An introduction skipped the hiring line. And after being fired from that job, I found my next one through my network. I knew someone who knew someone.

If you’re standing in a hiring line or if your CV is on a pile physically or virtually, you’re already screwed. Don’t wait in hiring lines. Look for indirect ways to open doors and skip the lines.

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.