Who Gets Promoted Higher and Faster at Work?

It’s not the best coder. It’s not the one who cranks out more pull requests or lines of code.

The one who gets promoted higher and faster is the one with the best soft skills. The best communicator. The one who’s best at explaining complex subjects to non-tech people. The best at dealing with people.

The best coders are left alone to continue cranking out code in a corner. “Ok, kid. When will you have your PR ready?”

And when the best coders, with poor soft skills, are put in charge of teams, projects tend to go sideways. They fail to communicate expectations, provide context, and coordinate people. They continue thinking in terms of lines of code and pull requests, not in team dynamics.

Start improving your soft skills by reading “How to Make Friends and Influence People.”

If you could take away just one lesson from that book: never tell anyone he’s wrong.

This Is Why We Don't Test Private Methods

Trying to test private methods causes a lot of confusion.

That’s a common question we all have made when finding unit testing for the first time. These days, I found that very same question on Reddit:

Can someone explain to me why unit testing our private methods is bad?

Because we don’t want to break encapsulation.

If you have a private method, how are you going to call it from a test class or method? It’s private. You can only access it from inside the same class. That’s the whole point of access modifiers: restricting access to the fields and properties that hold the internal state of a class.

And please don’t make your private methods public and static to call them directly inside unit tests. They’re private for a reason, right? We don’t want the rest of your code to use them directly.

Exposing internals is the most common mistake when writing tests. I’ve seen it and fixed it before.

Let’s take the HasAdmin() method from the question as an example,

private bool HasAdmin(List<string> relations, bool hasPermission)
{
    // Beep, beep, boop...
}

Unless HasAdmin() has 0 references—if that’s the case, you should remove it—another method from the same class is calling it. And you can trace the chain of method calls back to a public method.

HasAdmin(), or any other private method down in the chain of method calls, is changing something that you can observe from public methods. Probably it’s affecting a return value or changing an internal state you can inspect with getters. That’s what you should test instead.

To test HasAdmin(), create a User object with the right relations and permissions, call the public methods you have, and check what should change when your user is an admin or not. Maybe you return additional data only admins can access or finish an action without throwing a UnauthorizedAccessException.

You test private methods indirectly while testing the observable behavior exposed through public methods.

Et voilà!

To read more about unit testing, check how to write your first unit test in C# with MSTest and four common mistakes when writing your first unit tests. Don’t miss the rest of the Unit Testing 101 series.

Always Be Reading. But Reading More Isn't Always the Answer

Before finding “The Almanack of Naval Ravikant,” I was a ferocious reader.

I was in the “let’s read as many books as we can” team. By pure FOMO, I was trying to follow YouTube trends like “I read 9,999 books about money, here’s what I learned” and the mantra “read one book per week.”

But out of dozens of books I had read, I didn’t remember reading some of them, even when I had notes. I kept one or two ideas from those books in the back of my head but I couldn’t trace them back to where I found them.

Then I found Naval’s reading strategy. Ironically, by reading another book.

Instead of reading as many books as possible, he reads and rereads a few good ones. The ones that have passed the test of time. He meditates on their lessons, acts on them, and then he uses X/Twitter to take public notes.

Naval’s reading strategy changed my mind about reading:

• I don’t have to read books from cover to cover. I can jump straight to a chapter or section to find an answer.
• I can leave books unfinished. For someone trying to increase a book count, leaving books unfinished made it hard to count. If I read only half of the book, should I add 0.5 to my tally?
• It’s OK to reread books. Again, rereading didn’t contribute to my increasing book count.

And more important than reading to increase a book count is acting on what we read. Remember, passive learning is just entertainment.

Once you read a book, write 10 lessons you learned from that book, and find one lesson you can act on immediately. That’s more valuable than a large book count without any taking any action.

Find Your Producer's Switch

That’s Leland Sklar’s strategy, a well-known bass guitar player and session musician. He’s appeared on over 2,000 albums, based on his Wikipedia profile.

While recording in a studio, if a director asked him to change the sound, he simply turned on or off a fake switch and continued playing.

This is what he said during an interview for Guitar World:

“If I’m on a session and the producer asks me to get a different sound, I make sure he sees me flip this switch and then I just change my hand position a bit. There are no wires or anything that go to this switch. It’s a placebo, but it’s saved me a lot of grief in the studio.”

That’s genius!

What would be a director’s switch for coders? A typo in a variable name, missing brackets on 1-line conditionals, misaligned elements on a screen, writing SELECT * instead of SELECT with a list of columns.

What would you add?

The Easiest Way to Be Ignored When Communicating at Work

Only send “Hello, how are you?” in Teams or Slack at work.

You’ll get ignored immediately. Especially if you’re working in a remote team with people all over the world. And especially if you’re reaching out to a busy manager or executive.

This is how that “Hello, how are you?” conversation will look:

• Hello, how are you?
• …
• Good, thanks. And you?
• …
• Good too, thanks.
• Hey, I just wanted…

But, what if your recipient is on the other side of the world? 24 hours could pass between each message. And for sure, you don’t want to wait 48 hours to start the real conversation.

While working remotely at a past job, I used nohello.net as my Slack status. That page shows a fake “hello, how are you?” conversation, getting ignored. And I still got “Hello, how are you?” messages. Arrrggg!

Would you send an email saying just “Hello, how are you” at work?

I know you wouldn’t. Then, why do the same on Slack or Teams at work?

Next time you want to reach out to someone at work:

Don’t send “Hello, how are you?” Say hi and in the same message, without waiting for an answer, say what you really want to say.

That should be “Remote Working 101” when onboarding new team members at any remote company.