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.

9 Lessons I Learned After Following James Altucher's Work

It’s hard to define what James Altucher does.

He’s an investor, podcaster, writer, chess player, and comedian. That’s only what he shares on podcast interviews. Who knows what his next career will be.

I found James Altucher’s work by pure accident. I was looking for ways to get better at writing and found the advice of writing 10 headlines a day. That was inspired by James’ ideas.

Since then, I’ve been binge-watching and binge-reading James Altucher’s work in Quora, Medium, and his own website.

A guy that has made millions and lost it all, not just once but at least twice has a lot to teach. Here is what I’ve learned from him.

1. If you don’t know what to do with your life, start with your health

That’s what I’ve been doing after losing my last job. An end and a start of something new that I still don’t know what it will be.

Uncertainty in a single word. I’ve been questioning my life choices since then.

When facing those moments of uncertainty, James teaches to start with your health and get 1% better every day. That means doing something for your body, mind, and spirit. That’s what he calls the “Daily Practice.”

Since then, my daily practice has been:

• Starting the day with a glass of water,
• Working out,
• Cutting sugar and processed foods,
• Having a moment of silence, and
• Writing.

2. Write 10 ideas a day

This is part of the 1% daily improvement: Do something creative. Every. Day.

Turn yourself into an idea machine by writing 10 ideas a day.

After losing it all for the first time, James bought cheap waiter’s pads and started to write down ideas to get up again. He then wrote ideas for others and gave them away for free. Those ideas brought new opportunities for him.

Write 10 ideas a day or your idea muscle will atrophy.

3. Always be learning from everyone, then write about it

Everyone and every situation around us have something to teach us. Notice it and write about it. That could be part of your 10-ideas-a-day practice.

That’s what I’m doing right now by writing what I’ve learned from James.

4. You don’t need to meet your mentors

You need mentors in your life. But you don’t have to meet them.

I don’t know James in the real world. I will probably never meet him. But he has inspired me a lot since I’ve been following his work. He’s a virtual mentor.

Imagine that your mentor has already passed away and to learn from him, you have to follow the clues he left in his work. Find someone who inspires you and read his books and writings.

The best mentors are books.

5. Find your Plus, Equal, and Minus

To get better at any skill, you don’t only need mentors. You need to find your Plus, Equal, and Minus.

Plus is the people that inspire you. Your teachers, mentors, and favorite authors. James is one of those. Tim Denning, Dan Koe, and Nicolas Cole are some of my Plus in the writing space.

Equal is the people taking the same path with you. Your peers, coworkers, and friends. These people challenge you to continue improving.

Minus is the people you can teach. People one step behind the path you’re taking.

6. Making, keeping, and growing money are different skills

James lost it all multiple times. He shares that he was good at making money, but not at keeping it and growing it. He made the wrong investments and bad purchases.

Money is a totally different set of skills to master.

7. Reinvent yourself every 5 years

That’s from “Reinvent Yourself,” one of James’ books. And that’s from 2017 when AI wasn’t mainstream.

These days the need for reinvention is urgent. Our world is changing dramatically fast. Relying on the same skills we learned five years ago is too risky.

Reinvention means finding new sources of income.

To start your reinvention, start reading 500 books on a subject. If you don’t know where to start, find a book you like, read it, and read another 499 about the same subject. You’re free to drop it and start all over again.

8. Have multiple sources of joy

That’s from an episode of the podcast School of Greatness on YouTube.

During that episode, James shared he had businesses, writing, comedy, and chess. When things didn’t go as expected in one area, he went to another one.

I wish I had learned that before.

For some time, I only tried to find joy in my day job. That was a painful mistake. When things went sideways, I got burned out. I had stopped exercising and doing any of my hobbies. Eventually, all of that made me fall sick. Literally.

Lesson learned the hard way! Have multiple sources of joy.

9. Be like Google, my friend

Google is the go-to resource for information. (Until AI takes over)

We don’t spend too much time on Google. We ask questions and it takes us to somewhere else. In spite of that, we keep going back to Google and it’s one of the most valuable companies in the world. That’s the Google effect.

Be like Google. Be a bank. Be the source of information. Connect people with answers.

Parting Thought

James has a captivating and inspiring story. He has made millions and lost it all, and he’s open about it. From a Computer Science major to be someone difficult to put in a box and label, with multiple careers and skills.

James’ story teaches you can choose yourself, reinvent yourself, and skip the lines.