DEV Community

Cover image for How to share what you know (without becoming an influencer)
Andrea Liliana Griffiths
Andrea Liliana Griffiths

Posted on

How to share what you know (without becoming an influencer)

If you're anything like me, you've talked yourself out of posting something useful at least a dozen times this year.

Yes, this year. It's January 17th.

You had the thought. You knew it would help someone. And then you convinced yourself it wasn't worth saying because you don't have the audience, the credentials, or the “platform” to say it.

This is the biggest lie developers tell themselves.

And it's costing all of us more than you realize.

I want to share a few ideas about why your voice matters more than you think, why sharing incomplete knowledge is actually the point, and why you don’t need anyone’s permission to contribute.

This isn't about building a personal brand. This is about being useful.

Let’s begin.


I. The next breakthrough might come from you

Here's something most people get wrong about innovation. It rarely comes from the center. It comes from the edges.

The person who finally helped me understand Git wasn’t a famous educator. It wasn’t a viral tweet. It was A successful Git branching model by Vincent Driessen. A random blog post I stumbled onto years ago that made everything click.

Their explanation clicked because of how they said it. Their context. Their specific confusion that matched mine.

React came from a Facebook engineer who got frustrated with how they were building UIs. Ruby on Rails came from a guy building a project management tool. The person who writes the tutorial that changes everything for the next generation of developers might be mass-producing screws in a factory right now. Or teaching third grade. Or nursing a baby during lunch breaks.

Your background is different. Your journey is different. The problems you've faced are different. The way you think about solutions is different.

That difference is not a limitation. That difference is the contribution.

I learned to code through freeCodeCamp in 2016. I was in my 30s, learning during lunch breaks while my kid napped. No computer science degree. No tech background. Career changer. Immigrant. None of the “right” credentials.

For years I thought that disqualified me from sharing what I was learning.

I was wrong.

The biggest ideas often come from people who weren’t supposed to be in the room. People who saw the problem differently because they came from somewhere else. People who asked the “dumb” questions that turned out to be the right questions.

You’re not competing with the experts. You’re filling a gap they literally cannot fill. And sometimes that gap is where the next big thing lives.


II. Sharing incomplete knowledge is the point

Here’s where it gets counterintuitive.

You don’t need to wait until you’ve mastered something to share it. In fact, waiting might be the worst thing you can do.

When you share what you’re learning while you’re still learning it, two things happen.

First, you help people who are one step behind you. They don’t need an expert. They need someone who just figured it out. Someone who remembers what it felt like to not understand. Someone who can explain it in words that make sense to a beginner because they were a beginner five minutes ago.

The curse of knowledge is real. Once you become an expert, you forget what it was like to not know. You skip steps. You assume context. The best explanations often come from people still close enough to the confusion to remember exactly where they got stuck.

Second, you refine your own understanding. Writing forces precision. Explaining something reveals whether you actually get it. The gaps in your knowledge become obvious the moment you try to teach, just ask any DevRel person.

I can’t tell you how many times I thought I understood something until I tried to write it down. You start typing and suddenly realize you can’t actually explain why it works. So you dig deeper. You read more. You test your assumptions. And when you finally publish, you understand it three times better than when you started.

Teaching is learning twice.

Danny Adams was tired of looking up the same Git commands. So he made a one-page cheat sheet. Posted it on DEV.to. It’s now one of the most bookmarked Git resources on the platform. He sells the PDF on Gumroad. That’s the whole story.

He didn’t wait until he was a Git expert. He made something that solved his own problem and shared it.

Two developers in Germany thought Git was hard to learn. So they made Oh My Git!, an open-source game with playing cards and real-time visualization. Got funded. 44 levels. Thousands of downloads. They weren’t mass-market game designers. They were developers who wanted the next person to have an easier time.

Your knowledge doesn’t need to be complete to be useful. It just needs to be shared. And the act of sharing will make it better.


III. The influencer industrial complex is not the point

Somewhere along the way, we started believing that sharing knowledge is only worthwhile if it scales.

If it doesn’t get engagement, why bother? If it doesn’t grow your following, what’s the point? If you can’t monetize it, is it even worth your time?

This is creator economy brain rot.

Some of the most important documentation in open source was written by people who will never have a newsletter, a course, or a sponsor. They wrote it because the next person deserved an easier time than they had.

That impulse is the entire foundation of developer culture. It predates influencers by decades. And it will outlast them.

You don’t need a content strategy to be useful. You need a notes app and the willingness to hit publish.

The goal is not to build an audience. The goal is to help one person. That’s not a consolation prize. That’s the actual point.


IV. You don’t need permission

This is the part that matters most.

Nobody is going to tap you on the shoulder and tell you it’s your turn to contribute. (Although it’d be unfair not to mention the people who light a fire under you that makes you do just that. Thanks, @cassidoo.) No credential will ever feel like enough. No follower count will make the fear go away.

The people who share generously? They felt the same resistance you feel. They just decided to post anyway.

Bravery in sharing isn’t about confidence. It’s about caring more about helping than about looking smart. It’s about deciding that the person who needs your explanation matters more than the critic who might nitpick it.

Every single contribution you see online started with someone deciding their perspective was worth sharing. Not because they were certain it was right. Because they were willing to find out.

And here’s what happens when you do. You start a conversation. Someone replies with a correction. Keyboard warriors live for this moment. Someone else adds context. Someone shares a different approach. The knowledge gets better because you were brave enough to put the first draft out there.

That’s how open source works. Not one genius handing down perfect code from the mountain. Thousands of people contributing what they can, reviewing each other’s work, building on what came before.

Your post might be wrong. Someone might fix it. Now the collective knowledge is better than if you’d stayed silent.

That’s not failure. That’s the system working.


V. Individual bravery compounds into collective progress

This is the part people miss.

When you share what you know, you’re not just helping one person. You’re adding to a body of knowledge that didn’t exist before. You’re creating a resource that can be found, shared, built upon.

One person writes a blog post. Another person links to it. A third person writes a better version. A fourth person makes a video. A fifth person translates it into Spanish.

Suddenly there’s a whole ecosystem of resources that exists because one person decided to go first.

Developer communities don’t grow because of a few prolific contributors. They grow because lots of people contribute a little. The person who answers one Discussion. The person who adds one example to the docs. The person who writes one “I figured this out” post.

That’s how knowledge scales. Not through influencers. Through participation.

When you stay silent, you’re not just depriving one person of your insight. You’re breaking a link in a chain that could have led somewhere none of us can predict.

The tutorial that mass-produced screws factory worker writes might inspire a CS student in Lagos who builds the next great developer tool.

But only if it gets written. Only if it gets shared.

Collective progress isn’t waiting for you to be ready. It’s waiting for you to contribute.


VI. The real barrier

Here’s the uncomfortable truth.

The barrier isn’t knowledge. It’s fear.

You’re not afraid of being wrong. You’re afraid of being judged. You’re afraid someone will point out that you’re not qualified. That it’s been said before. That you’re not enough. And if you’re not a bro, would anyone even care.

Let me save you some anxiety. All of those things might happen. None of them matter.

I’ve been there. Early in my career, I closed a GitHub issue and someone replied asking if they’d left out anything “a qualified person” would need. Turns out the next commenter backed me up and told them to fill out the issue template properly.

I wasn’t wrong.

But that “qualified person” line? That one stuck with me anyway.

Regardless, being wrong in public is not the end of your credibility. It’s the beginning of it.

This is what it looked like. Spoiler: I wasn't the one who was wrong.

The developers worth learning from aren’t the ones who never make mistakes. They’re the ones who learn in the open. Who share their confusion. Who update their thinking when they get new information.

There is immense power in changing your mind.

Your perspective is yours. Your context is unique. The way you explain something is different from how anyone else would explain it.

That difference is the value.


VII. What this looks like in practice

You don’t need a brand. You don’t need a niche. You don’t need a posting schedule.

You need to do one thing: write down what you learned and put it somewhere someone else can find it.

That’s it.

Share the solve. When you fix something that took you more than 30 minutes, write it down. Not a polished tutorial. Just what broke, what you tried, and what worked.

Share the confusion. When something doesn’t make sense, say so. “I don’t understand why X works this way” is a valid post. It starts conversations. It surfaces explanations. It helps other confused people feel less alone.

Share the opinion. When you have a take on a tool, a practice, or a trend, say it. Strong opinions, loosely held, are how ideas get refined.

Share the context. When you read something useful, add your perspective. Your annotation makes it more valuable than the original for the right reader.

You don’t have to do all of these. Pick one. Do it once. See what happens.


VIII. This is how things change

Every tool you love using started with someone sharing something incomplete.

Every framework. Every library. Every tutorial that helped you get unstuck. Someone put it out there before it was ready. Before they felt qualified. Before anyone asked them to.

That’s how knowledge spreads. That’s how communities grow. That’s how things get better.

Not from the top down. From everywhere at once. From people who decided their voice mattered even when no one was asking for it.

Sometimes the most meaningful change comes from the simplest act. One person speaking up.

You have something worth saying. You’ve learned things that would help other people. You have a perspective that is genuinely yours.

The question isn’t whether you’re qualified.

The question is whether you’re willing.

You don’t need anyone’s permission to be useful.

Say what you need to say.

With gratitude,

Andrea

Published on Twitter https://x.com/acolombiadev/status/2012554871778545834?s=20

Top comments (0)