Being Cringe Is Part of Putting Yourself Out There

If you create content in tech long enough, someone will eventually tell you that you're wrong.

Or cringe.

Or that your code isn't clean enough.

Or that the thing you built could have been done in 20 lines instead of 50.

Or that the framework you're using sucks.

Or that you're "not a real engineer" because you use AI.

That's just part of putting yourself out there.

And I think more developers need to be okay with that.

Developers Are Really Good at Nitpicking

Tech is probably one of the easiest spaces to get nitpicked in because there are a hundred ways to solve the same problem.

Post a code snippet and someone will tell you there's a better pattern.

Use React and someone will ask why you didn't use Vue.

Use Vue and someone will tell you React has a bigger ecosystem.

Use a framework and someone will tell you vanilla JavaScript is enough.

Don't use a framework and someone will ask why you're reinventing everything.

Use AI and someone will call you a vibe coder.

Don't use AI and someone will tell you you're falling behind.

You can't win.

And that's the point.

You shouldn't be trying to win everyone's approval in the first place.

The Internet Rewards People Who Actually Publish

For a long time, I think a lot of developers treated building in public as something you only did once you were already an expert.

You needed the perfect portfolio.

The perfect project.

The perfect architecture.

The perfect explanation.

But the internet doesn't really work that way.

The people who get opportunities are often the people who consistently show what they're doing.

They share unfinished projects.

They talk about things they're learning.

They make tutorials.

They post demos.

They explain concepts they only recently understood themselves.

Sometimes they're wrong.

Sometimes the video is awkward.

Sometimes the post gets five likes.

Sometimes someone screenshots it and makes fun of it.

But they published.

And while someone else spent three hours debating whether their implementation was "production-ready enough" to share, they already moved on to the next thing.

You're Probably Going to Be Cringe

Your first videos might be bad.

Your first posts might sound forced.

You might use too many buzzwords.

You might look back at something you posted two years ago and wonder why you ever thought it was good.

That's normal.

I'd actually be more concerned if I looked at everything I made years ago and thought it was still perfect.

Cringing at your old work usually means you've improved enough to recognize what you would do differently now.

The only way to skip having embarrassing early work is to never have early work.

And that's a terrible trade.

Creating Tech Content Is Especially Weird

There's another problem with creating content as a developer.

You aren't just being judged on the content.

You're being judged on the implementation.

Someone can watch a 30-second video showing an app and immediately start asking:

Why did you use that database?

Why isn't this open source?

That isn't scalable.

You could just use X.

This already exists.

Why would anyone pay for this?

Sometimes those are legitimate questions.

Sometimes they're useful feedback.

And sometimes they're just someone demonstrating that they know something.

Learning to tell the difference is important.

Not every criticism deserves a response.

Not every comment requires you to defend your engineering decisions.

And not every piece of content needs to represent the absolute pinnacle of software engineering.

Sometimes you're just showing something cool you built on a Saturday.

That's enough.

"Actually..."

There's a particular kind of comment that every tech creator eventually becomes familiar with.

"Actually..."

You can explain a concept correctly for 99% of beginners, and someone will find the 1% edge case.

You can make a two-minute tutorial and someone will complain that you didn't explain something that would require another 40 minutes.

You can say something is "faster" and someone will ask for benchmarks across six architectures.

Technically, they might even be right.

But communication requires abstraction.

Good educational content isn't an RFC.

If every programming tutorial had to account for every edge case, caveat, exception, historical context, security implication, and architectural alternative, nobody would finish a tutorial.

There is a difference between being inaccurate and simplifying something so people can understand it.

Some Criticism Is Useful

This doesn't mean ignoring everyone who disagrees with you.

Putting yourself out there should also mean accepting that people will catch things you missed.

I've learned things from comments.

I've changed opinions.

I've found bugs because someone pointed them out.

I've discovered better approaches because another developer challenged mine.

That's one of the best things about sharing your work publicly.

The mistake is treating all criticism as equally valuable.

Someone explaining why your approach might cause a race condition is different from someone commenting:

bro doesn't know how to code 💀

Take the useful part.

Leave the rest.

You Don't Need Permission to Teach

One thing that stops developers from creating content is:

"I'm not good enough yet."

Good enough compared to who?

There will almost always be someone better than you.

Someone who has been programming longer.

Someone who understands compilers better.

Someone who can explain distributed systems from memory.

Someone who has worked at a company you've dreamed of joining.

If being the world's foremost expert were a requirement for sharing knowledge, almost nobody would be allowed to teach anything.

You just need to be honest about what you know.

There's nothing wrong with saying:

I'm learning this, and here's what I've understood so far.

In fact, sometimes people who just learned something are better at explaining it to beginners because they still remember what was confusing.

Building in Public Has Compounding Returns

One post probably won't change your career.

Neither will one video.

But hundreds of them can.

Your content becomes a public record of what you're interested in, what you can build, and how you think.

Someone looking for a developer might discover your project.

A founder might see your demo.

A conference organizer might watch one of your explanations.

Another developer might message you about collaborating.

A company might discover you before you ever discover their job posting.

None of these things are guaranteed.

But they can't happen through work nobody knows exists.

Your GitHub repository sitting quietly at zero stars might contain incredible engineering.

Unfortunately, nobody knows that unless they find it.

Content is distribution for your skills.

Ship the Post

If you're thinking about making tech content, make it.

Post the project.

Record the tutorial.

Write the article.

Share the terrible first version.

Explain the thing you learned yesterday.

Someone might think it's cringe.

Someone might correct you.

Someone might tell you they've known it since they were twelve.

That's fine.

You don't need everyone on the internet to think you're smart.

You need to keep learning, keep building, and keep putting your work somewhere people can actually see it.

The goal isn't to never be cringe.

The goal is to become comfortable enough with being cringe that it stops preventing you from doing things.

Because the people laughing from the sidelines aren't the ones shipping your work.

You are.