Stop Being Afraid of Hitting Publish on LinkedIn With These 9 Proven Strategies

Publishing your first LinkedIn posts is scary.

I know that feeling. Your hands shake. Your heart is beating. You keep retyping your password. You’re publishing something on the Internet for the first time ever.

You’re in fight or flight mode, ready to run away from lions behind a bush.

What if I say something wrong? What if my boss reads what I write? What if that comes up in future interviews? What if someone makes fun of me? It’s normal to have these worries.

I felt the same way when I wrote for the first time on LinkedIn, even after writing on my blog for years.

If the fear of being exposed online prevents you from hitting “Post” or “Schedule” on LinkedIn (or anywhere else online), follow these strategies:

1. Publish a lot

The first time you do anything is scary.

The only way to overcome it is with repetition. Write a lot and publish a lot. Create a writing schedule you can sustain and then challenge yourself to double it.

Back in January 2024, I decided to revive my LinkedIn account by writing 100 short-form posts. I started with one post a week, then two, then three, and settled with one post per day, every day. Fear of writing? Gone!

If you write every day, you will hit 100 posts in about three months. The fear of writing and being exposed will disappear.

2. Schedule your posts

Otherwise, after hours of crafting a perfect post, you will find yourself with the cursor on the “Post” button hesitant to click it. And you will delay it for tomorrow. And often, tomorrow means never.

Schedule your posts, forget about them, and come back the next day.

3. Turn off email notifications

LinkedIn (and any other social media company) will try to keep you on their platform.

They will trick you with all kinds of emails. Someone posted. Someone commented. “Someone on LinkedIn viewed your profile.” Really, LinkedIn?

Turn off all email notifications and continue with your day. Otherwise, you’ll be refreshing and refreshing your browser tab and checking your email, wondering why nobody has liked or commented on your first masterpieces.

4. Understand Sturgeon’s law

90% of everything is crap. That’s Sturgeon’s law.

That’s not to discourage you. It’s to lower your expectations when writing for the first time. 90% of everything is crap. Your first posts will be in that 90%. Your first posts will be far from perfect.

Keep writing and keep improving.

I wrote my first blog post back in 2018. And “post” is a strong word. It was a word vomit. I dumped a bunch of words into a document and published it online. I still have that first post unedited to remind me how I started.

Same story with my first LinkedIn post. I made all LinkedIn sins possible in a single post. Only added an external link. Zero formatting for mobile devices. Lots of hashtags.

If after writing for months, you don’t cringe when reading your first posts, you haven’t improved much.

5. Remember the 30/30/30 rule

No matter what you do:

• 30% of people will love it.
• Another 30% will hate it.
• And another 30% won’t even care.

I learned that reading “Choose Yourself” by James Altucher.

Write for your 30% and forget about the other 60%.

6. Think of writing like buying lottery tickets

Would you expect to win the lottery the first time you buy a ticket? Nope!

Writing is the same. Every time you hit “Post,” you’re buying a lottery ticket. If you don’t win today, you buy another ticket tomorrow. If your post didn’t get the likes you wanted, there’s a chance it will next day.

Keep publishing.

7. Make it about business, career, or work

Every social network has its own vibe.

LinkedIn isn’t the exception. If LinkedIn were a person, he would be a 30-year-old office worker wearing a suit and minding his language because his boss or future boss is watching.

Everything you write on LinkedIn make it about work, business, and careers.

If you’re not sure what to write about, share:

• Lessons from your last job
• Lessons from your best boss
• The best book you have read
• The best course you have taken
• Lessons you wish you knew before starting your job

Share anything you wish you knew two years ago about your work or career.

You don’t have to share personal details or post selfies. Don’t publish what you wouldn’t publish in a local newspaper or niche magazine.

8. Be a journalist

What should I write about if I’m not an expert? Don’t let that thought stop you.

Don’t try to be an expert. Who’s an expert anyway? Share what you have learned and what you’re learning. Show your work.

Don’t create, document. Imagine you’re a journalist with a part-time job doing whatever you’re doing now.

9. Find a writing buddy

Writing your first posts can feel lonely. Probably, only your coworkers will like them when they log in to LinkedIn once every full moon or when they’re looking for a new job.

Find someone in the same journey as you and work together.

Parting Thought

Your first posts are the most challenging. Going from zero to one is the hardest part. Don’t be afraid of hitting “Post” or “Schedule.” The more you hit it, the less scary it becomes.

No matter what you write about or where you write, an online presence is the new CV and portfolio. And LinkedIn is a good place to start. Safe and professional. The boss is watching, remember?

Take a deep breath and write your first post. Commit to your next 20, 30, or even 100 posts and see what opportunities they bring.

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?