Years ago, a friend sent me a youtube video and said, "You need to check this out."

My mind was blown away in the next five minutes.

I had zero idea what was happening as a guitar beginner. It was the first time I heard about John Mayer and his music.

Years later, I started playing Why Georgia, Slow Dancing In The Burning Room, Belief, and other John's hit songs in bars and earned some pocket money. One day, I found a version of Neon I'd never heard of. It's acoustic, and John's vocal wasn't as polished as in later efforts, yet more honest and heartfelt.

It's the track from his debut EP, Inside Wants Out.

The album is John's earlier work, recorded independently with him on acoustic guitar and no fancy mixes or backing. This early release showcases his formidable skills in all their raw glory.

For me, it's a hidden gem of all his works and gives me a strong incentive to grow.

Fast forward to last year, my team and our 4-year-old software project won the President Quality Award. As a software engineer, it's the most incredible pride I could imagine getting inside a company. I started giving training/ workshops/ talks in my organization, blogging, contributing to open source, and mentoring my partner, who enrolled in a coding boot camp a year ago.

Those experiences helped me construct a solid problem-solving framework. Also, a more substantial feeling grew that I wanted to get a weight off my chest: share in public.

Inside wants out

"I want to share my experience." A dead simple first thought.

I've never worked at FAANG or on a large-scale distributed system or cross-framework micro frontends. Just a guy who codes and shares, whether qualified or not.

Blogging - Topics and hooks

My first blog post was about Svelte: Supercharge Web DX in Svelte way. I also gave my very first tech talk based on this blog post.

For me, the most challenging thing about writing was choosing the topic. I used to write a considerable amount of internal documentation, which shared context only my coworkers could understand. While writing in public is different, you shouldn't aim too high and try to cover a broad spectrum of your topic in the first place.

For instance, you like to share how to spin up an Express.js API server. Don't put everything in a single blog post, e.g., how to set up TypeScript, start MySQL container, build your app using docker-compose, build CI/CD workflow, and deploy to production. For experienced engineers, there may be one or two valuable takes. But for junior engineers, you just bombarded them with cognitive overhead.

Make your content more digestible by distilling it into engaging hooks that people can resonate with. Those hooks might be the issue you suffered the most or something obvious, but you've rarely seen them in other resources. Focus on your topic and make it a series if necessary.

Writing Handbook by Julian Shapiro is a masterpiece you couldn't believe is free.

I recommend this episode from Lenny's podcast: Growth tactics, retention strategies, and becoming a better writer | Julian Shapiro.

Open Source Software - Do your own homework

I kicked off my OSS journey by fixing a dependency bug in our project. Later I became a contributor and author. While instead of talking about the journey, I like to talk about problem-solving.

Troubleshooting is always challenging. It takes a lot of energy and time. Sometimes you wrap your head around the issue and still can't find the answer. Here is my problem-solving methodology that I refined over time to overcome it:

Problem-solving methodology

• Articulate the problem in a proper way

  1. Describe & contain the problem

  2. Analyze the root cause

  3. Create & proliferate solutions

• The life cycle of problem-solving

  1. State the problem

  2. Collect data

  3. Define success criteria

  4. Identify potential root cause

  5. Screen and verify the root cause by reducing variables

  6. Implement and validate corrective action

  7. Standardize and prevent recurrences

  8. Post-mortem and proliferation

If you've ever opened an issue in a large open-source project with an issue template, you've probably gone through this process. Don't be a jerk who always asks for help without effort. Do your own homework by getting your hands dirty, and cultivate your engineering literacy using critical thinking. It'll help you become a better engineer along the way.

For instance, there was a bug that haunted you for a while. The error message was ambiguous and indicated that something went wrong in your node_modules, the library source codes. What would you do?

Red flag

Some would open an issue on the GitHub repo and copy/ paste the error message without context. Keep asking the author when it'll be solved but refuse to provide additional information or reproduction.

Better approach

• Articulate your problem and purpose.

• What's your environment (IDE, OS, Node version, production)?

• What approaches you've tried but failed (ref issue/ PR number)?

• Have you provided a minimal, reproducible repo/ StackBlitz link?

• Have you targeted the problematic version if the bug appeared after you upgraded your dependencies? Or it's a dependency issue, and you might open a ticket in the wrong repo?

There is no one-size-fits-all approach when it comes to problem-solving. If you're inexperienced and need help figuring out where to start, I'd suggest stepping back from the problem and clarifying your issue statement. You might find the way out with a fresh look.

Kudos to janosh, the author of svelte-multiselect. He helped me merge my very first PR on GitHub. His work inspired me to create svelte-component-test-recipes, showcased by the official Svelte blog.

Mentoring - Patience, and empathy

I stumbled upon this video lately and found it super helpful (and his channel as well):

It resonated with me when Steve said, "You should find a mentor just a bit ahead of you", and that is exactly where my partner and I are.

I coded in JavaScript for a couple of years and started backend development a year ago. Meanwhile, my partner pivoted to software engineering and enrolled in a coding boot camp (backend development).

Here are common questions in the first few months:

• Why doesn't it work? What does this error message mean? (doesn't know how to debug)

• This shorthand syntax is so cool. Can I use it all the time? (ternary operator over if/ else)

• Can I use A instead of B because A is more performant? (technical decision based on a single factor)

Of course, there are a lot more questions. After trial and error, I gradually realized how to mentor appropriately.

Give a man a fish, and you feed him for a day; teach him how to fish and feed him for a lifetime.

You, as a mentor, would ruin the chance of learning for both mentor and mentee if you always solve the problem on their behalf.

The key is guiding them in analyzing the problem and watching them figure it out themselves. Here are tips:

• Make sure you're on the same page regarding the problem statement.

• Be cautious about your explanation of a concept/ solution. Is it too difficult to grasp? Are there too many abstractions?

• Demonstrate your troubleshooting approach and explain the thought process with patience

• Help them build their problem-solving muscle instead of feeding them answers.

Through mentorship, I learned how to explain complex ideas to a beginner; I also found room for improvement after revisiting my previous writings. Most importantly, I became a much more patient, empathetic person.

Wrapping up

Thank you for your reading.

This reflection is personal because I learned them the hard way in the last year. I'm also grateful for those amazing people in tech who inspired me to kick off my share-in-public journey. I'd never become a superstar like John Mayer, but his works and improvements motivate me to move forward and become a better coder, thinker, and sharer.

I hope you can learn a thing or two from my experience. Let me know your thoughts, and I love to hear your feedback.

You can find me on mastodon: @davipon@hachyderm.io or on Twitter @davipon.

Achievements I've yet mentioned 🎉:

• Two articles were featured on Hashnode

  • Better Backend DX: Fastify + ESBuild = ⚡️

  • Test Svelte Component Using Vitest & Playwright

• The Epic Hashnode Writeathon - 100 Honorable mentions

• Articles and libraries were showcased by Svelte official blog

Resources that helped me grow 💪:

• Books

  • Backable by Suneel Gupta

  • Good Strategy Bad Strategy by Richard P. Rumelt

• Newsletter

  • The Pragmatic Engineer by Gergely Orosz

• Podcast

  • Lenny's podcast by Lenny Rachitsky

• Courses

  • Master the Code Review by Curtis Einsmann

  • CSS for JS developers by Josh W. Comeau

• People

  • Julian Shapiro