Two Quotes I'm Trying to Live By

#1. “I’m a simple man making his way through the galaxy, like my father before me”

If you’re a Star Wars fan, you recognize that phrase. That’s by Boba Fett from The Mandalorian.

We’re all here trying to figure out our paths. Some are more intentional about it, others are not. Some have found it, others are still searching.

Every stage in life will bring its own challenges and paths to figure out.

#2. “The minute you learn something, teach it”

That’s from Show Your Work by Austen Kleon. “A book for people who hate the very idea of self promotion.”

That phrase puts into words one of my core values.

It has kept my curious inner child alive. Once I find something new, my sense of curiosity or inner child, wants to share it with somebody else. Most of the time, by writing about it.

When you teach what you learn, you have the chance of learning it twice.

Learn To Talk to Non-Tech People in Your Team

That’s a crucial skill to master for every coder, even if you’re not in the path to be a team leader.

We take pride in dropping any technical jargon during our conversations. It makes us look smart. But true mastery is explaining things to people outside our fields.

At a past team, while working on a hotel management software, we found an issue when syncing restaurant bills to room charges. It took us long to fix it. It was a serious issue.

The next day, we have “that” conversation in our daily meeting.

The team lead started to explain: “API, background processor, eventual consistency, optimistic concurrency…” He used any jargon he knew to justify our 1- or 2-day delay.

To our PM and other non-tech people in the meeting, it sounded like the alien language from The Arrival. You could tell it by their confused and “what are you talking about” faces.

A simpler “somebody could walk away without paying his restaurant bills. And nobody here wants to pay for that” would have finished the conversation with some laughs and a point made.

Always make it about the person listening. Often our job is being interpreters: from business language to technical language and vice-versa.

Learn to talk to non-tech people in your team—using their own words.

Getting Rid of Nulls Is Indeed A Good Idea

These days I found a Medium article titled: Why Eliminating NULLs From Your Code Will Not Make Your App Better.

Its point is that when we stop using null, we replace checking for null with checking for a default value or a wrapper like Result. And there’s no major gain.

But there is.

The advantage of returning a wrapper like Option or Result instead of null is making the implicit explicit.

Instead of getting a NullReferenceException and saying “ooops, that method returned null,” we look at a method signature and say “Hey, that method might return null. We’re better off checking for that.”

That’s Method Signature Honesty. When the parameters and return types of a method show what it does, even for edge cases.

For example, what does this method do?

Movie GetMovieById(int movieId);

What if there was no movie found? What if there was more than one? Does the method throw an exception? Returns null? Returns a Movie.Empty? We can’t tell just by looking at the signature.

But what about?

Option<Movie> GetMovieById(int movieId);
// or
Result<Movie, MovieError> GetMovieById(int movieId);

At least, it’s obvious from that signature that there’s a special case we need to handle. It’s up to the caller to decide what to do with it.

The original article has a point that replacing a null checking like,

var movie = GetMovieById(someId);
if (movie != null)
{
    // Do something here
}

With,

var result = GetMovieById(someId)
                 .Map(movie => /* Do something here */);

// And at some point later:
result.OrElse(() => /* Nothing found. Do something else here */);

is a design choice. For C#, the first one looks like more “native.”

In either case, at some point, we have to convert the absence of data (either a null or a None) to something else like a status code or error message.

C# didn’t take the wrapper route and introduced nullable references instead.

With nullable references turned on, all our object references are not null by default. If we want a reference to accept null, we should annotate the type with a ?. The same way we do it for nullable ints.

Movie? GetMovieById(int movieId);
//  ^^^
// It might be null.

Yes, that name is kind of misleading. It should be “not nullable” references.

That’s a feature we should turn on and make all nullable warnings as errors.

With Option, Result, or nullable references, we make our method signatures honest. That’s already a gain.

Two Blogging Tips to Write More

Inspired by Seth Godin and Herbert Lui, I looked up other people writing daily on their personal blogs and found these two pieces of advice:

1. If it’s longer than a Tweet, 280 characters, it can be a post.

That’s from Mike Crittenden’s 2 months of daily blogging.

Post length doesn’t matter if we transmit the message clearly in a few words. A post can simply be a headline and a main idea. Don’t feel guilty about short posts.

2. Instead of leaving a comment, write a reaction post and share a link instead.

Credits to Rafał Pastuszak.

A reaction post, even a short one, is calmer and thoughtful. Often, we write most comment in “the heat” of reading or without even reading the entire piece.

That sounds like one tip to never run of writing ideas and a way to preserve keystrokes.

Two Alternatives to Assertion Messages — and Two Ideas if You Do Want To Keep Them

I got this question from Ankush on my contact page:

“I want to override the Assert method to avoid using Assert.True without a failure message. How can I achieve it?”

Here are 2 alternatives to assertion messages and 2 ideas if you do want them:

1. Don’t use assertion messages. Write better test names instead.

Test naming conventions, like the UnitOfWork_Scenario_Result, impose some order and structure to names. You won’t have that inside assertion messages.

If you don’t have too many assertions in your tests, with a good test name it’s easy to figure out what failed and why.

2. Use assertion libraries with better messages.

Like FluentAssertions or Shoudly. They have clearer and more verbose messages when an assertion fails.

Here’s what MSTest, FluentAssertions, and Shoudly show when an assertion fails:

[TestClass]
public class UnitTest1
{
    [TestMethod]
    public void ADummyTestToShowFailureMessages()
    {
        var anyBool = false;

        // With MSTest
        Assert.IsTrue(anyBool);
        // Message:
        // Assert.IsTrue failed.

        // With FluentAssertions
        anyBool.Should().BeTrue();
        //  Message:
        // Expected anyBool to be True, but found False.

        // With Shouldly
        anyBool.ShouldBe(true);
        //   Message: 
        // Test method AssertionLibraries.UnitTest1.ADummyTestToShowFailureMessages threw exception: 
        // Shouldly.ShouldAssertException: anyBool
        //    should be
        // True
        //    but was
        // False
    }
}

That’s if you want assertion messages for the lack of good failure messages.

Now, if you do want assertion messages for whatever reason:

3. Write custom assertion methods

Wrap MSTest, NUnit, XUnit or the testing library you’re using inside custom methods with the assertion messages as required parameters. Like,

AcmeCorp.CustomAssert.IsTrue(actual, yourMessageHereAsARequiredParam);

If you’re doing code reviews, that’s something to share with your team and enforce during reviews.

4. Create a custom analyzer to check the absence of assertion messages

Code reviews can be daunting. And even if all test methods in your test suite have assertion messages, anyone can decide not to use them.

Automate the boring part with an analyzer that warns you if you’re not passing a message to every assertion.

Here’s an analyzer from xunit.analyzer. That’s a good place to start.

Voilà!

To read more about assertions, check how to write better assertions and how to write custom Assertions to improve your tests. Don’t miss the rest of my Unit Testing 101 series.