DEV Community: Sonam Choeda

New Personal Thought Blogs

Sonam Choeda — Sat, 30 Aug 2025 12:16:08 +0000

Launching a New Blog: Insights from a Senior Developer & Startup Founder

I'm thrilled to announce the launch of my new blog, where I'll be sharing a wealth of practical knowledge, lessons learned, and behind-the-scenes stories from my journey as a senior developer and startup founder. This platform is dedicated to helping fellow developers and aspiring entrepreneurs navigate the complexities of building products and businesses.

🔗 Check out the blog here
https://sonamusui.com/QUP1IJY7S7pQk6gpsvE6

Do share it and make other people know about it, if you find it useful.

Don’t Let AI Write Your Brain Out

Sonam Choeda — Tue, 19 Aug 2025 05:29:27 +0000

AI is an incredible tool, but it can also make you lazy if you rely on it too much. If you let it write every line of code, you risk forgetting the basics loops, conditions, functions, even how to think like a programmer.

The smarter way to use AI is to learn alongside it:

Attempt the problem yourself first, struggle a bit, and make mistakes

Use AI to explain concepts, point out mistakes, or suggest alternatives

Always read, understand, and debug the code it gives you instead of blindly copying

This way, you’re not just building a solution, you’re training your brain. The fundamentals you master now how to loop, how to structure logic, how to read errors will make everything else easier later, even when AI can write most of the code for you.

Remember, AI should be your teacher and sparring partner, not a replacement for learning. Code with it, not through it.

Ai won't replace people or developer but the people who uses AI will, so take the right step.

Mistakes Are Your First Teacher in Coding

Sonam Choeda — Tue, 19 Aug 2025 05:09:25 +0000

If you’re new to a programming language, don’t chase perfect code.
Make mistakes, even silly or deliberate ones.

The real skill is not avoiding errors, it’s learning to read them.
Once you do, debugging becomes easier and growth becomes faster.

Mistakes aren’t blockers, they’re teachers.

Every great story is written with many hands

Sonam Choeda — Mon, 07 Jul 2025 11:59:14 +0000

Alexander the Great conquered half the known world by the age of 30. But it wasn’t just him. It was his army, loyal generals like Hephaestion, fearless soldiers, brilliant minds, and mentors like Aristotle who shaped him before he even picked up a sword.

When he reached the edges of India, even Alexander had to stop. His army was exhausted. They refused to move forward. And that’s when it hit me…

Even the greatest can’t walk forever alone.

Reminder to myself: I can push hard. I can work late. I can carry the weight alone, for a while. But no matter how far I go, time is limited, energy burns out, and the silence gets heavier.

A vision, no matter how clear, needs voices behind it. A mission, no matter how big, needs hands around it.

So I remind myself, don’t wait to break. Build your army while you climb. Surround yourself with people who believe, challenge, and carry pieces of this dream.

Because the truth is…

“No man walks on his own story for too long. Even legends need footsteps beside theirs.” — Rengo

Every great story is written with many hands.

Proof of Concepts (POC)

Sonam Choeda — Mon, 07 Jul 2025 11:55:19 +0000

I’ve come to learn something important about Proof of Concepts (POC)—a lesson I want to write down so I don’t forget.

When working on ambitious ideas like combining NFTs with AI, I used to think that a POC was just the smallest version of the idea. That if I could build anything at all, no matter how simple, I had done enough. But that's not how it works. Not really.

A POC is not about building the smallest thing possible. It's about building the smallest thing that matters. There’s a difference.

A Misstep I Took
Let me take the NFT and AI example.

At one point, I was excited about the idea of using AI to generate art and minting it as NFTs. I thought, "Let me just generate some AI art, mint it as NFTs, and call it my POC."

But here’s where I was wrong: just generating AI art and turning it into NFTs didn't prove anything useful. It wasn’t hard. It didn’t teach me anything about how my idea would work at scale, or whether it even had value. It was a shallow demo, not a real POC.

What I needed to test was "the part that makes my idea unique." Maybe it was the ability of the AI to customize art based on real-time inputs. Or maybe it was about creating rarity through AI learning from trends. That’s what my POC should have focused on.

What I Realized
A real POC proves the core of your idea. It’s not just a placeholder. It’s a checkpoint.

A good POC asks: "Can this concept work the way I think it will?"

It’s not: "Can I build anything at all that looks kind of like this?"

The smallest concept is often irrelevant if it doesn’t reflect what you actually need to validate.

So now, I approach POCs differently. I ask:

What is the minimum valuable learning I need from this build?

If I can answer that honestly, I can build a POC that actually moves me forward.

Final Reminder to Myself
Don't confuse action with progress.

Just because something is “built” doesn’t mean it’s useful. A POC is not a checkbox or a toy version of your big idea. It's a filter. It helps you know if your idea can stand on its own, even when stripped down.

From now on, I’ll remember:

A good POC is not the smallest thing I can make.
It’s the smallest thing I should make to prove the core of my concept.

Stay focused, test the right thing, and build smarter.

The Best Programmers I Know

Sonam Choeda — Thu, 03 Jul 2025 05:41:43 +0000

Over the years, I’ve met many developers. But I often asked myself, “What makes the best truly stand out?” I want to share what I’ve learned in hopes it helps you the way I wish it helped me when I was starting.

1. Read the Reference
"Don’t guess, read the manual. The answers are already there."

One habit of great programmers is going directly to the source, the official documentation. Whether it’s the Python Standard Library, Apache Docs, or a configuration spec, they read it. They don’t jump to Stack Overflow or chatbots first.

Why?
Because reading the reference gives you a full understanding, not just quick fixes. It helps you learn the “why,” not just the “how.”

2. Master Your Tools
"Know your tools so well that they feel like an extension of your hands."

It’s not enough to “use” a tool. The best devs understand it deeply. They know:

Who made it and why.

Its current maintainers and limitations.

The entire ecosystem around it.

If you're using Kafka daily, don’t just copy-paste snippets. Learn Kafka inside out. That’s what separates users from experts.

3. Read the Error Messages
"Your computer is trying to talk to you. Listen."

Great engineers read every error message carefully. They don’t panic, they pause and analyse. Many bugs solve themselves once you understand what the system is telling you. It’s almost magical.

4. Break Down the Problem
"If it looks too big, make it smaller."

Big problems overwhelm everyone. The best devs break them down into smaller, bite-sized steps. That’s their secret weapon. Complex systems are just a bunch of simple problems stacked together.

Pro Tip: If you're stuck, you're probably trying to solve too much at once. Simplify.

5. Don’t Be Afraid To Get Your Hands Dirty
"Code is just code. Dive in."

Elite devs don’t shy away from unknown or messy codebases. They explore, read, refactor, and make sense of things others avoid. That’s how they grow. They learn by doing.

When others hesitate, they get started.

6. Always Help Others
"Helping others helps you grow."

The best devs are also generous. They’re busy, yet they make time to help teammates. They listen, support, and teach. Not because they’re forced to — but because they care.

Being curious, humble, and helpful is a superpower.

7. Write and Share
"Clear writing reflects clear thinking."

Great programmers also write well. Blogs, tutorials, or open-source documentation — they love sharing. Good writing forces you to think clearly and structure your knowledge.

Bonus: Better writers often become better coders too.

8. Never Stop Learning
"Stay curious, stay young."

Some of the best devs I know are over 60, yet still learning every day. Why? Because they love it.

Bad devs think learning ends with a degree. Great ones know it never ends. They embrace every new tool, language, or framework with joy and a learner’s mindset.

9. Stay Humble — Status Doesn’t Matter
"Everyone has something to teach you."

Whether it’s an intern or a senior architect, the best devs treat everyone equally. They know fresh ideas can come from anywhere. Hierarchy doesn’t block learning.

Humility is strength.

10. Build a Reputation
"Let your work speak louder than your title."

To be truly great, others must know you're great. Not for fame, but for impact.

Ways to build a strong reputation:

Ship important projects.

Write useful tools or libraries.

Speak, write, or contribute to the community.

Your name becomes your brand. Build it slowly and intentionally.

11. Be Patient
"Good things take time — and so does good code."

Patience is underrated. Software breaks, people misunderstand, things move slow. Without patience, frustration takes over.

Patience gives you the power to debug, to teach, and to learn. It helps you stay focused and committed.

12. Never Blame the Computer
"There is always a reason — find it."

When things break, bad devs blame the system. Good devs dig deeper. Computers aren’t random — there's always logic behind the chaos.

The best never stop until they uncover the cause.

13. Say “I Don’t Know”
"Saying ‘I don’t know’ is the first step to knowing."

Smart devs admit what they don’t know. They don’t pretend or guess. They pause, think, and explore.

This honesty builds trust. It also unlocks curiosity and growth.

14. Don’t Guess
"If you’re unsure, don’t assume — find out."

One of the biggest mistakes is guessing under pressure. Guesses become false foundations.

When something is unclear, pause. Go back. Read more. Test.

"In the face of ambiguity, refuse the temptation to guess."
— The Zen of Python

Final Words
"Your journey as a developer is not a race, but a climb. Step by step, day by day."

You don’t have to master all these overnight. Pick one, grow from it, and slowly become the kind of developer others admire and rely on.

Keep showing up. Keep learning. Keep helping.

𝘠𝘰𝘶 𝘮𝘢𝘺 𝘥𝘦𝘭𝘢𝘺, 𝘣𝘶𝘵 𝘵𝘪𝘮𝘦 𝘸𝘪𝘭𝘭 𝘯𝘰𝘵.

Sonam Choeda — Thu, 03 Jul 2025 05:09:52 +0000

WAKE UP CALL:
Get up. Not just from your bed, but from your excuses.
"𝘠𝘰𝘶 𝘮𝘢𝘺 𝘥𝘦𝘭𝘢𝘺, 𝘣𝘶𝘵 𝘵𝘪𝘮𝘦 𝘸𝘪𝘭𝘭 𝘯𝘰𝘵." ~ Benjamin Franklin

Every second you delay is a second someone else uses to outpace you.
This is your life, not a rehearsal.

You’re not just slowing yourself, you’re quietly disappointing the people who rely on you i.e. teammates, clients, even your future self. Procrastination doesn’t protect you, it traps you. It piles guilt, stress and regret on your shoulders, while stealing time you’ll never get back.

You don’t need motivation, you need movement. Start small. Tell yourself, “Just five minutes.” Let momentum carry you. Replace “I have to do this” with “I choose to do this,” and take back control. Don’t wait for perfect conditions.

The world doesn’t stop for hesitation. Either you run your day or it runs you. So breathe, stand up, and move. You’re not here to stall, you’re here to build.

We rise not just for ourselves but for our future, our people, our country. Let’s be right, not when it’s easy, but because it’s right. It’s now or it’s never.

My take on Go-To-Market (GTM)?

Sonam Choeda — Fri, 27 Jun 2025 04:02:36 +0000

It’s not just a strategy. It’s your product’s belief system.

I used to think GTM was all about channels, pricing, and acquisition hacks.
Now I see it differently.

It’s about showing up in someone’s life with purpose, not noise.
The best GTM I’ve seen doesn’t scream “buy this” - it quietly whispers “this was made for you.”

Simon Sinek said:

“People don’t buy what you do, they buy why you do it.”
That changed how I think about building and launching.

A strong GTM isn’t about shouting features.
It’s about earning belief.
It’s about making someone feel like your product understands them before they even use it.

So here’s how I see it now:
GTM isn’t the end of your product build. It’s the beginning of your product’s story. It’s how your idea becomes a movement not just a tool.

If your GTM doesn’t start with why you exist, you’ll just be selling.
But if it does, you’ll be inviting people to belong.

The Illusion of Intelligence

Sonam Choeda — Fri, 27 Jun 2025 03:13:39 +0000

As Sam Altman said, "𝘈𝘐 𝘩𝘢𝘭𝘭𝘶𝘤𝘪𝘯𝘢𝘵𝘦𝘴, 𝘪𝘵 𝘴𝘩𝘰𝘶𝘭𝘥 𝘣𝘦 𝘵𝘩𝘦 𝘵𝘦𝘤𝘩 𝘺𝘰𝘶 𝘥𝘰𝘯’𝘵 𝘵𝘳𝘶𝘴𝘵 𝘵𝘩𝘢𝘵 𝘮𝘶𝘤𝘩." This reminds us that while AI can generate answers, ideas and even code, it can also make up facts with confidence.

It's like a genius that sometimes dreams instead of thinks.

We know this, yet we often forget. We get amazed by how well it writes, answers, or codes, and we start trusting it like it’s always right. But the truth is, even when AI sounds confident, it might be giving you a fake source, a made-up fact, or a logic that breaks down when you look closely.

Sometimes, it even argues both sides of a topic without realizing it's contradicting itself. It can simulate emotions like empathy or urgency, but it's not feeling anything, it's just predicting patterns based on data.

We forget that AI can invent fake research papers, confidently tell you something that doesn’t exist, or carry over strange biases hidden in language. These are not rare glitches, they happen more often than we think, just in subtle ways.

What’s even scarier is how much people are starting to trust it without question. The more polished it sounds, the more we assume it must be right. That blind trust is dangerous. When we stop verifying, stop questioning, and let AI take the wheel without oversight, we risk building decisions, opinions and even systems on foundations that might be flawed or completely fictional.

AI can take us far, but only if we stay awake while using it. It's a guide, not a truth-teller. The goal isn’t to avoid AI, it's to avoid blindly trusting it.

Reflecting on the Air India Tragedy — Lessons and Condolences

Sonam Choeda — Tue, 24 Jun 2025 08:11:29 +0000

I’m deeply saddened by the recent Air India incident that resulted in the loss of innocent lives and injuries to many. My heartfelt condolences go out to the families who lost their loved ones. No words can ever heal such pain, but I hope they find strength and support in the days ahead.

When the news broke about the Air India plane crash, most people saw a headline. Another tragic story. Another flight that didn’t make it. But for me, it felt like something deeper like life had tapped me on the shoulder and whispered, “Pay attention.”

Because behind every tragedy are stories. Real lives. Real people. And from this single, heart-breaking incident, four stories stood out to me. Four reminders that time is not a promise, it's a gift. And one day, that gift runs out.

1. The Family Who Finally Took the Flight… Too Late

They had dreamed of moving to the UK for years. You know the story, life got in the way. Work, kids, aging parents, bills. They postponed their dreams, made sacrifices, waited for the “right time.” And finally, when things lined up, they got on the plane… but never made it to their new life.

That shook me.

Because how many of us do the same? We delay our dreams, thinking we have more time. We tell ourselves “someday”, but someday often turns into never.

The lesson: Stop waiting for perfect. Life doesn’t wait for your plans to align. If something matters, don’t keep pushing it to tomorrow.

2. The Woman Who Was Denied Boarding

She was late. Missed check-in. She begged the staff, pleaded to let her on board. She was furious, angry at herself, at the airline, at the world.

Hours later, when the news came, she was stunned. That missed flight had saved her life.

And suddenly, her anger turned into gratitude.

The lesson: Sometimes, what feels like a setback is actually protection. We don’t always get what we want, because something bigger sees what we can’t. Not every “no” is rejection, some are divine redirections.

3. The Man Who Walked Away

When the plane split in two, fire consumed one half. He happened to be in the other. He survived. Not a scratch. Just shock, silence, and life.

Why him? Why was he spared?

He said he didn’t know. But in that moment, I thought of the verse: "To everything there is a season, a time for every purpose under heaven." – Ecclesiastes 3:1

The lesson: If you’re still here, there’s a reason. You’re not done yet. Your story isn’t over.

4. And Those Who Didn’t Make It

They boarded that flight thinking it was just another day. They kissed someone goodbye. Checked in their bags. Buckled their seatbelts.

They had plans for the next day. Birthdays. Work meetings. Texts left on “read.”

And just like that, their story ended mid-sentence.

The lesson: Life gives no warning. Tomorrow isn’t guaranteed. We are all walking around as if we’ll live forever, until we don’t.

So What Now?

If you’re reading this, take a moment. Place your hand over your chest. Feel that heartbeat? That’s your miracle.

You still have time. Love now. Apologize now. Forgive now. Dream now. Speak now.

Life isn’t asking you to be perfect. It’s asking you to be present.

So don’t wait for the “right time.” Don’t wait until the calendar clears, or the money’s perfect, or the fear is gone.

Because sometimes, next time never comes.

Live like now is all you have. Because one day, it will be.

The way we make sense of success.

Sonam Choeda — Tue, 24 Jun 2025 08:05:45 +0000

“Outliers” by Malcolm Gladwell made me pause and reflect deeply.
There’s a line that struck me:
“I will agree that there is something profoundly wrong with the way we make sense of success.”

It made me think:
What does it really mean to be successful?
Is it the one who has more money?
Is it the one with a loving partner and family?
Is it the one who wakes up happy, even if unnoticed by the world?
So often, we chase success that’s measurable, visible, and applauded but is that the only version that matters?
Or are we allowed to define success on our own terms i.e. quiet, personal, even invisible to others?

And perhaps the biggest question:
Does success have to be recognized by others or can it simply be something that fulfils us?
Reading Gladwell reminded me:

Sometimes success is not what we achieve, but how we grow.
Not what we own, but who we become.
Not how loud the applause, but how at peace we are.

What’s your definition of success?

Remember the Core

Sonam Choeda — Tue, 24 Jun 2025 08:04:23 +0000

AI may have made writing code cheaper—
but engineering judgment remains priceless.

Knowing what to build, delivering high-quality code to production, and crafting maintainable software, these still demand years of deliberate practice, domain intuition, and hard-earned wisdom.