🔧 Your "Build in Public" journey is not unique. You need that "some-thing".

🕛 Zeit seit Veröffentlichung: 54 Tage, 7 Stunden 12 Minuten
📆 Veröffentlicht am: 15.10.2024 um 19:45 Uhr
Nachrichtenbereich: 🔧 Programmierung
🔗 Quelle: dev.to

On Sept 05, during this time I got an email from LinkedIn that your account is temporarily deactivated.

I am a 22-year-old, have a dream like an average guy to build something of my own.

Also, I am a developer(just to say), currently learning Rust programming.

So, I made a plan.

I saw LinkedIn makes it easy to get eyeballs on your content and it is somehow more transparent than other social media.

So, the plan was to share my journey on LinkedIn, get some followers, launch my own thing and update the bio to "Founder of X" or "Building Y".

A typical build-in public journey.

But I was totally unaware that what I was going to do in the next few days was going to change my whole perspective towards "build-in public".

So, like a normal human being, I watched a bunch of YouTube videos, got some motivation, got some crapy hacks and started posting my hypothetical days on LinkedIn.

My strategy was to post a single piece of content a day but comment on 20+ posts.

So, fortunately, I got some views both on my content and on my profile.

I thought I cracked the game of "build in public" and now I am just a few posts away from my first million-viewed post.

But, the very next day, I got the most beautiful email I ever received from LinkedIn.

You are account is temporarily deactivated.

For some time, I did not get it.

After that, I tried my best to recover it.

But God had some other plans for me.

So, It took me 2 days to plan a new idea.

Now, I am just following that idea.

So, as of now, I changed most of my things.

• Started my open-source journey.
• Started my first open-source guide. (it's been a month now but got 132 stars and 16 forks, the link is here)
• Started my first organization.
• And lots of things in the planning stage. (obviously, I can't share these now.)

No these are not a real success but this is just a sign that I am on the right track.

Now let me uncover the things I realized that you must need to make your "build-in public" journey successful.

You need to remember two things.

Just 2 things.

1. They want you to be successful but first, they want you to suffer.
2. During the competition, People always support the underdogs.

People always relate to normal people like them, who are insecure, under-confident and nervous.

People love to hear the underdog stories like I failed at this, then this happened and now I am this.

And I think every "build in public" journey goes in the same way.

You tried lots of things, you learned so many lessons, and you tried that one last thing and now you are who you want to be or still trying to be like I am.

So, that "some-thing" I promised, you need is "failure".

Because your failures are great lessons for them.

But you need to be a great storyteller to tell your stories effectively and make your journey more relatable to them.

That's why you need to learn to tell stories.

But You do not have to watch the 4-hour course or read 400 pages of a book to learn storytelling.

Here is the simple formula.

Step - 1: Victim - Introduce the challenge or failure

Start by describing an unexpected challenge or a failure you faced. Be specific about the problem.

Were you trying to launch a project that didn’t get traction? Or maybe you were learning something new and hit a frustrating roadblock? This stage is important because it builds empathy.

The reader needs to see you struggling like they might have in their own experiences. Talk about how it felt—were you overwhelmed, embarrassed, or angry?

For example start by explaining a technical challenge or bug you encountered.

Maybe it was a feature that didn’t work, code that kept failing, or a problem you couldn’t crack. Share how frustrating or tricky it was to deal with.

This sets the stage and makes your story relatable to other developers who have faced similar issues.

Step - 2: Realization - Share the lesson or insight

After detailing the challenge, shift the focus to what you learned.

What moment made you realize something had to change? This is a key part of the story because it represents growth. Perhaps you understood a flaw in your approach or discovered a new method that changed everything.

Paint a picture of that moment when things started to click, and you saw a way forward.

The lesson doesn’t have to be grand - it could be something simple that has a big impact.

Like after digging through the problem, share the moment when you figured out the issue.

Maybe it was a missing semicolon, an edge case you hadn’t considered, or realizing you needed a completely different approach. This is the moment of insight that changes your direction.

It’s crucial because it highlights how you solved the problem or found a better path forward.

Step - 3 Decision - Explain your choice and action

Now that you’ve learned from the situation, explain how you turned that lesson into action.

What decisions did you make to overcome the problem? Did you create a new plan or change your mindset? This part of the story should be about how you moved from reflection to execution.

Talk about the challenges of putting your plan into action, the adjustments you made along the way, and any doubts you had.

This helps readers see the full picture of how you turned things around.

Once you learned the lesson, explain the action you took. Did you refactor your code? Switch libraries? Or maybe you rethought your entire approach.

Show the steps you took to implement the solution, even if it wasn’t easy.

This demonstrates your decision-making and problem-solving process, which is key to development.

Step - 4 Hero/Villian - Show your resilience and outcome

In the final stage, present yourself as the hero who kept going despite setbacks.

Even if you didn’t achieve success right away, you kept trying, and that persistence makes you a hero in the story. Contrast this with what would have happened if you had taken the “villain” path and given up.

The idea here is to show that success is not about never failing, but about not giving up when things get hard.

Whether you ultimately succeeded or not, the effort and mindset you applied make you the hero of your story. This is what people will resonate with—how you faced adversity and kept going.

Conclusion

In software development, building in public isn’t about perfect, finished projects—it’s about sharing the process, including the struggles and setbacks.

Bugs failed builds, and unexpected roadblocks are part of the developer’s journey, and sharing how you overcome them makes your story authentic and relatable.

Developers learn through problem-solving, experimenting, and improving. By showing your challenges, decisions, and moments of realization, you help others grow while building your own expertise.

It’s not about flawless code, but about persistence, learning, and sharing those lessons with the community.

Success may not come immediately, but experience, growth, and connection with fellow developers are what truly matter.

That’s the value of building in public as a developer—embracing the journey and sharing it with others.

Have a great day.

GitHub        Twitter/X        Sponsor Me        Oxide Org.

...