How to Start Selling Without Sales Calls

To stand out, do what everybody else isn’t doing.

That’s a lesson I learned from Isra Bravo, Spain’s top copywriter, and maybe the country’s top solopreneur.

When everybody is doing sales calls, putting chatbots on their websites, or offering personalized demos, it’s time to stand out by doing something completely different.

Recently, I discovered Keygen, a licensing software and its no calls policy.

The founder, probably being an introvert, wanted to ditch sales calls and in a moment of frustration, he deleted the “Book a call” button from his company’s website.

Instead of sales calls, they improved their messaging. They clarified what their tool does and how much it costs.

And when someone requests a sales call, they simply reply:

“No, we don’t do calls, but happy to help via email. Feel free to CC any relevant team members onto this thread.”

Some of Keygen’s prospects loved the #nocalls policy. Too many calls are boring, draining, and time-consuming.

Sure, they might be leaving money on the table. But we don’t want money from just anyone, only from the right clients. The ones that trust us, respect us, and pay the right price.

With a clear message and open pricing policies, we attract the right clients. We attract clients based on the messaging and the values we project. And that works for anything else in life.

#nocalls is an idea worth copying and stealing, especially if selling feels draining and if you prefer to think of in terms of helping, not selling. Better messaging = more sales.

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