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

Want to stand out as a coder? Learn to talk to non-technical people.

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

Jargon won’t make you look smarter

We often take pride in using technical jargon. It makes us feel smart.

But true mastery is explaining things to people outside our fields.

At a previous team, we found a bug when syncing restaurant bills to room charges. It took us a long time to fix it. It was a serious issue.

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

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

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

Speak their language, not yours

In that daily meeting, a simpler “somebody could walk away without paying their 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 as coders is being interpreters: from business language to technical language and vice-versa.

Try explaining your current project to a friend who doesn’t code, using their own words. If they get it, you’re winning.

Explaining complex ideas simply is one of the most underrated skills to stand out as a coder. Truth is, the senior you get, the less it’s about coding and the more about communication. That’s why I made clear communication one of the strategies in my book, Street-Smart Coding: 30 Ways to Get Better at Coding. That’s the practical guide I wish I had on my journey from junior to senior.

Get your copy of Street-Smart Coding here

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 a gain when eliminating null

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# doesn’t have an explicit type to avoid null

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.