Forem: sparsh sharma

From Kubernetes to Career Advice: A Day of Grafana, Gyan, and Giggles at Microsoft Noida

sparsh sharma — Wed, 28 May 2025 19:54:43 +0000

Date: 24th May, 2025
Location: Microsoft Office, Noida
Event: Grafana & Friends Delhi Meetup (feat. MLSA)
Mood: Techy with a touch of philosophical chaos

While the sun was melting Noida outside, inside the cool, corporate air of Microsoft’s office, I attended an event that promised dashboards, dev-ops, and just the right amount of existential dread (read: AI talks). The Grafana & Friends May’25 meetup didn’t disappoint — and neither did my barrage of slightly off-topic but extremely necessary questions to the speakers.
One of the most memorable conversations? With none other than Dr. Umesh Pandit, Advisor Solution Architect at DXC Technology. Sure, he spoke about visualising Azure metrics with Grafana in minutes — but I was here for the real talk. So, I went off-script.

Here’s what happened when I asked him the questions no one dares to ask at tech events.

Q1: If you had today’s experience at the beginning of your career, what kind of project or product would you have pursued first—and why?

Dr. Umesh gave me the “I’ve seen things” look and said:
“If I had the skills and exposure I have now, I’d help students who are struggling — especially the ones around me. Some of my old batchmates are still stuck, and honestly, if I was capable back then, I’d be training freshers for free. Sometimes, all someone needs is a bit of guidance to build a better career.”
Translation: Be the mentor you never had, and maybe skip the part where you're 10 years deep in your career thinking, “Ah, I should've helped someone instead of binge-watching ‘Friends’ again.”

Q2: Is there something you avoided early in your career that you later found valuable?

“Coding. I decided early on that I wasn’t going to code. Then I realized... maybe I should’ve. Better packages, better placements, better everything. Coding builds your logical thinking, and that mindset is gold when solving real-world problems.”
Translation: Coding is like spinach. You avoid it as a kid, but one day you realize it's the reason Popeye had abs and you don’t.

Q3: If your younger self asked, ‘Will coding ever get easier?’ would you smile… or just walk away?

“I’d definitely smile. Thanks to AI, coding has become a lot easier. Think it, type it, boom — you get the code. But understanding the output, debugging, and proper prompting? That’s where real learning comes in. I've seen even kids doing crazy calculations — smart ones start early.”
Translation: Yes, AI helps. No, it won’t save you from your own poorly written prompts. Sorry.

Q4: What advice would you give to people who are just starting to learn coding or thinking about getting into it?

“First, choose a language — Java, .NET, PHP, whatever. Don’t try to learn everything at once. Figure out where the good packages are, because, let’s be honest, money matters. Second, master that one language. Once you’ve nailed one, switching to others becomes way easier.”
Translation: Don’t try to marry every programming language on the planet. Fall in love with one, master it, and you can date the rest casually later.

Final Thoughts (Because I’m Emotionally Exhausted)
From Kubernetes to career lessons, this event had it all — tech, tacos (okay fine, dal chawal), and truth bombs from people who’ve been in the game longer than my attention span during Zoom meetings.
So if you ever attend a tech meetup, don’t just sit through slides. Ask weird questions. Ask life questions. Ask "what if" questions. You never know — someone might give you an answer that changes your path... or at least makes for a killer blog post
Until next event,

– Shelby

Frontend, Backend, or Full Stack? Let’s Finally End Your Confusion

sparsh sharma — Thu, 03 Apr 2025 10:21:59 +0000

So, you’ve decided to become a developer? Nice. Welcome to a life of:
Sleepless nights
Googling "why is my code not working?" 50 times a day
An unbreakable bond with Stack Overflow
-----------------------------
But before you start flexing your "coding skills," you need to pick a side—Frontend, Backend, or Full Stack. And no, "I'll learn everything" isn’t a valid answer unless you have a death wish.

Let’s break it down, so you don’t waste months binge-watching tutorials without writing a single line of actual code.

1️⃣ Frontend: Making Things Pretty (and Functional... Sometimes)

**
What is it?

Frontend is everything you see and interact with on a website. Buttons, layouts, animations, sliders—this is where all the visual magic happens. It’s also where designers and developers argue over pixel alignment, and users still somehow manage to complain.

Tech You’ll Need to Learn:

HTML – The structure of your page (like bones, but digital).
CSS *– Makes things look nice (because plain HTML is ugly).
**JavaScript *– Adds interactivity (so your website isn’t just a boring document).
**React, Vue, Angular – Because nobody writes raw JavaScript anymore.
Figma, Tailwind CSS, GitHub – Designing, styling, and saving your work before it disappears.

Who Should Pick Frontend?
You enjoy designing things and making them interactive.
You want to see instant results when you code.
You love animations, transitions, and aesthetics.
Debugging CSS doesn’t make you want to throw your laptop.
** Starter Project:** Build a personal portfolio website (because nothing screams "I’m a developer" like a website about yourself).

2️⃣ Backend: The Hidden Powerhouse (Where the Real Work Happens)

**
What is it?**
Backend is the invisible but essential part of a website. It handles logic, databases, authentication, and security. Basically, it’s the brain, while frontend is just the pretty face.
Think of it like a restaurant kitchen—you don’t see what’s happening, but without it, you’re not getting any food.

Tech You’ll Need to Learn:
Languages: Python (smooth), JavaScript (confusing but everywhere), Java (strict but reliable).
Databases: MySQL, PostgreSQL, MongoDB (because data has to live somewhere).
APIs: REST, GraphQL (so frontend and backend can have a conversation).
Authentication: *OAuth, JWT (because you don’t want people logging in as Elon Musk).
*
Who Should Pick Backend?
You enjoy logic, problem-solving, and organizing data.
You love efficiency and making things run fast.
You don’t mind that your work is crucial but never seen.
You get a weird thrill from breaking into systems (legally, of course).
** Starter Project:** Build an API that generates random excuses for not doing assignments (useful for students and lazy coworkers).

3️⃣ Full Stack: Because Why Not Suffer Twice?

What is it?
Full Stack means you do both frontend and backend. You’re basically a one-person tech army, great for freelancing, startups, or impressing people who don’t know what a developer does.
It’s the perfect mix of beauty (frontend) and brains (backend), but also means double the debugging pain.

Tech You’ll Need to Learn:
Everything from Frontend + Backend (yes, all of it).
Deployment tools: Docker, AWS, Firebase (because localhost isn’t real life).
DevOps basics: CI/CD, Nginx, Kubernetes (they sound fancy, but they just keep things running).

Who Should Pick Full Stack?
You can’t decide between frontend and backend.
You want complete control over your projects.
You love the idea of building your own apps from scratch.
You don’t mind juggling 50 different technologies at once.
Starter Project: Build a blog website—no one will read it, but recruiters will be impressed.

4️⃣ How to Pick the Right Path Without Regret

Love colors, layouts, and making things look nice? → Frontend
Enjoy logic, problem-solving, and working behind the scenes? → Backend
Like both but can’t commit to just one? → Full Stack
Still confused? Do this:
1️⃣ Try Frontend for a week (build a simple portfolio).
2️⃣ Try Backend for a week (build a basic API).
3️⃣ Stick with the one that frustrates you less.

5️⃣ The Beginner’s Roadmap (So You Don’t Get Lost)

Step 1: Learn basic coding (HTML, CSS, JavaScript, Python).
Step 2: Build mini projects (a calculator, weather app, anything simple).
Step 3: Choose Frontend or Backend (or suffer through Full Stack).
Step 4: Contribute to open-source or get an internship.
Step 5: Create a portfolio and start applying for jobs.

Final Thoughts: Stop Overthinking & Start Coding

**
There’s no perfect choice, only progress. Whether you go for Frontend, Backend, or Full Stack, the real key is to just start building stuff.
** So, what are you picking? Let me know in the comments! 🚀**

shelby

Life With a Hackathon: Where Sleep is a Myth and Debugging is a Personality Trait

sparsh sharma — Mon, 17 Mar 2025 09:08:49 +0000

Ah, hackathons. The modern-day gladiator arena where developers battle sleep deprivation, questionable Wi-Fi, and that one guy who insists on using Vim for everything. It’s a place where caffeine is your only form of hydration, where bugs multiply faster than your stress levels, and where you either emerge victorious or with a newfound existential crisis. To help you navigate this chaos without becoming a ChatGPT-dependent zombie, we’ve crafted the ultimate survival guide.

Step 1: Assemble Your A-Team (or Just Any Team That Shows Up)

Hackathons are a test of both skill and patience. Ideally, your team consists of people who balance each other out—one backend wizard, one front-end artist, a DevOps magician, and, of course, someone who just “vibes” and provides moral support (they usually make the pitch deck). If your team looks more like a randomly generated RPG party, brace yourself for some unexpected challenges—like convincing someone that ‘console.log() debugging’ is not a valid project management strategy.

Step 2: Choose an Idea That Won’t Send You Into a Spiral of Despair

It’s tempting to build the next AI-powered, blockchain-integrated, decentralized metaverse ecosystem that solves everything. But you have 24 hours, not 24 lifetimes. Pick an idea that:

Won’t require you to rewrite the laws of physics.
Doesn’t involve training an AI model overnight (spoiler: it won’t work).
Can be demoed without sacrificing your laptop’s remaining 2% battery life.

Step 3: ChatGPT Is a Tool, Not Your Brain Replacement

Yes, ChatGPT is magical. No, it is not your co-founder. If your entire hackathon experience consists of “copy, paste, pray,” congratulations—you’ve just created an unmaintainable monster. Debugging a ChatGPT-generated function without knowing how it works is like disarming a bomb with a blindfold on. Use AI as a sidekick, not as your CTO.

Step 4: The Debugging Spiral of Doom

At some point, your code will break, and you will descend into the infamous debugging abyss. You’ll start with optimism:

console.log("Checking variable X...");

Then you’ll move to frustration:

console.log("WHY IS THIS NOT WORKING??");

And finally, existential dread:

console.log("Am I the bug?");

The error message won’t help. Google will lead you in circles. Stack Overflow will give you a solution that somehow makes things worse. Accept your fate and embrace the chaos.

Step 5: The 3 AM Hallucination Phase

At 3 AM, reality becomes questionable. The code blurs. Someone suggests rewriting everything in Rust. Your brain starts playing the Windows XP error sound on repeat. You will question all your life choices, but remember: this is just the caffeine withdrawal talking. Drink water. Stretch. Consider blinking.

Step 6: The Last-Minute Deploy That Defies Logic

With five minutes left, you realize:

Your login page crashes on load.
Your API returns ‘undefined’ instead of actual data.
Your CSS styling is more abstract art than functional UI.
Your teammate committed a .env file with hardcoded credentials.

But does that stop you? Absolutely not. Push to GitHub. Deploy with confidence. Pretend everything works as intended.

Step 7: The Art of Presenting a Half-Functional Project

Time to sell your chaotic creation like it’s the next tech unicorn. Some useful phrases:

“It worked right before the demo.”
“This is just the MVP, the full version will have that feature.”
“This was an intentional limitation for security reasons.”

If something crashes mid-presentation, just laugh and say, “Ah, classic live demo moment.” Judges eat that up.

Step 8: The Post-Hackathon Recovery Phase

After the hackathon, you’ll do one of the following:

Sleep for 18 hours straight.
Vow to never do this again (you will, though).
Convince yourself your half-broken project has startup potential.

Regardless of the outcome, you survived. And that’s what matters. So next time, when you see another hackathon event pop up, just remember: you’re totally prepared this time. (You’re not.)

Now go forth, code warriors, and may your Git commits be ever in your favor!

Backend Dev vs. Frontend Dev: Who’s Really Suffering More?

sparsh sharma — Thu, 06 Mar 2025 18:54:44 +0000

The Eternal Battle of Code Warriors

It’s a tale as old as time (or at least as old as JavaScript frameworks): the war between backend developers and frontend developers. Both sides claim they have it harder, both think they’re carrying the project, and both secretly know that without the other, the entire system would collapse faster than a Jenga tower in an earthquake.

So, who’s suffering more? Let’s break it down.

Backend Devs: The Unsung Architects of Chaos

1. The Database Whisperers

Backend devs live in a world where one wrong query can turn a sleek, responsive app into a slow, soul-draining nightmare. Ever tried debugging an unoptimized join query? Backend devs have, and they still have PTSD from it.

2. "It Works on My Machine" Syndrome

Deployed a seemingly innocent API? Works perfectly locally. Push it to production? BOOM—server crashes, and now the entire company is looking at you like you just deleted the internet.

3. The "Do More With Less" Expectation

Frontend devs get the fancy UI, animations, and React hooks. Backend devs? They get a text editor, a terminal, and a silent prayer that the API request doesn’t time out.

4. "Just Make It Fast" Requests

Product managers love saying, "We need faster responses from the server." Sure, let me just bend the laws of physics real quick.

Backend Dev’s Daily Mood: 😵‍💫💀🔥

Frontend Devs: The Pixel Perfectionists in Pain

1. CSS: The Real Dark Magic

Forget Hogwarts. Mastering CSS is the real wizardry. One moment, everything is pixel-perfect. The next, a single flexbox change sends your entire layout into another dimension.

2. Browser Compatibility: The Silent Killer

Ever written a perfect UI, only to check it in Internet Explorer and realize that nothing works? That’s frontend trauma.

3. "Can You Make It Pop More?"

Backend devs complain about performance. Frontend devs suffer through endless design revisions that boil down to: "Make it pop. No, not like that. More. But less. But better."

4. JavaScript Framework Hell

React? Vue? Angular? Svelte? Pick one. Learn it. Master it. Then watch a new framework drop next week that makes everything you just learned obsolete.

Frontend Dev’s Daily Mood: 🤡📏🎨

So, Who’s Suffering More?

Honestly? Both.

Backend devs fight against logic, databases, and impossible performance demands. Frontend devs battle with CSS, design whims, and the horrors of cross-browser compatibility.

The only real winner? The DevOps engineer watching both teams struggle.

At the end of the day, whether you’re a backend or frontend dev, we all share the same struggle: debugging at 3 AM, questioning life choices, and somehow loving it anyway.

Thank you for reading this blog ;)
Shelby

Why AI Won’t Steal Your Job (But That One Intern Might)

sparsh sharma — Thu, 06 Mar 2025 18:46:50 +0000

The AI Panic: Should You Worry?

Every few months, some tech bro on Twitter announces, "AI is going to replace all developers!" And every time, developers everywhere laugh, close their bug-filled VS Code, and get back to Googling why their function isn’t returning the right value.

Let’s be real—AI is powerful. It can write boilerplate code, autocomplete functions, and even generate entire applications. But replacing human developers? Not happening anytime soon. You know who might take your job though? That intern who just learned Tailwind yesterday and now writes cleaner UI than you. 😬

What AI Can Do (And What It Can’t)

✅ AI can:

Help you debug faster (because let’s be honest, you weren’t reading the error messages anyway).
Automate repetitive coding tasks (goodbye, writing ‘if-else’ statements for the 100th time).
Generate basic CRUD apps (great, now we have 10,000 new to-do list apps).

❌ AI can’t:

Understand project requirements better than a junior dev (which is already a low bar).
Make creative decisions (because no one wants an AI-generated dark mode theme that burns their eyes).
Deal with your product manager’s last-minute changes (this alone secures your job forever).

The Real Threat: The Hungry Intern

While you’re out here arguing about AI, that intern is grinding—learning, coding, and absorbing knowledge at an insane speed. They’re writing cleaner, faster, and more efficient code than you did when you started. Worse? They don’t even use Stack Overflow as a crutch. 🤯

AI is predictable, but that intern? They might show up with a new JavaScript framework you have to learn. They don’t fear change; they are the change.

How to Stay Ahead (And Not Get Replaced)

1️⃣ Learn to work with AI, not against it. Use it for automation, debugging, and inspiration. Let it handle the boring stuff while you focus on the complex problems.

2️⃣ Never stop learning. The intern is always watching. New frameworks, better practices, smarter workflows—adapt or be outcoded.

3️⃣ Remember: Soft skills matter. AI can’t communicate with a team, mentor juniors, or negotiate deadlines. Be the dev who can code and talk.

Final Thoughts

AI isn’t coming for your job. But if you stay stagnant, someone will. Whether it's a fresh-faced intern or a hungry junior dev, the industry is always evolving. Keep learning, keep coding, and most importantly—never underestimate that intern. They’re watching. 👀

Stay legendary. 🚀

The Five Stages of Debugging (A Developer’s Emotional Breakdown)

sparsh sharma — Wed, 05 Mar 2025 21:18:15 +0000

Stage 1: Denial – "It’s Not My Code."

You run your program, expecting perfection. Instead, you get errors—tons of them.

"That’s weird," you mutter. "It was working yesterday."
Then, the classic thought: “Maybe it’s a system issue. Yeah, definitely not my code.”

So you restart your IDE, your computer, maybe even your entire career—because obviously, the problem can’t be you.

💡 Reality Check: It’s always your code.

Stage 2: Anger – "What the @$%& is this?!"

Ten minutes in, frustration kicks in. The error messages are as useful as a toaster manual in a spaceship.

"Syntax error?! WHERE?!"
You start furiously pressing Ctrl + Z, as if undoing your existence will help.

Then comes the rage-driven debugging:

Smashing the keyboard ✅
Copy-pasting random Stack Overflow answers ✅
Yelling at the screen ✅

💡 Reality Check: Yelling at code does not make it work (but it does feel good).

Stage 3: Bargaining – "Please, Just Work."

You start making deals with your computer, the universe, and maybe even the dark web.

"If this compiles, I swear I’ll write comments next time."
"Just let it run once, and I promise I’ll never copy-paste code blindly again."

You even attempt the ancient ritual of adding print statements—because if you can’t fix it, at least you can understand how deep in trouble you are.

💡 Reality Check: You won’t write comments, and you will copy-paste again.

Stage 4: Depression – "I’m Not Meant for This."

Nothing works. It’s been five hours. Your coffee is cold, your motivation is gone, and your soul has left the chat.

You question everything:

"Why did I choose this career?"
"Maybe I should open a café instead."
"What if I just… delete everything and start over?"

You stare at the code, hoping it magically fixes itself. It doesn’t.

💡 Reality Check: You’re in too deep. You can’t escape now.

Stage 5: Acceptance – "Fine, I’ll Actually Debug."

Eventually, you do the one thing you should have done from the start:

Read the error message properly.
Check the logic step by step.
Actually understand what the code is doing.

And then… it works. 🎉

You don’t know how. You don’t care. You push it to production and never touch it again.

💡 Final Lesson: Debugging isn’t just fixing mistakes—it’s discovering how lucky you got in the first place.
Final Thoughts: You’re Not Alone.

Every developer goes through these five stages—sometimes all in a single hour. But hey, that’s what makes it fun, right?

So, the next time you’re debugging, just remember: You got this. And if you don’t? Well… Google does. 😎

Happy coding! 🚀

Shelby

Why Your Code Works (But You Have No Idea Why)

sparsh sharma — Wed, 05 Mar 2025 21:00:12 +0000

The Magical World of Accidental Genius

You’ve been there. We all have. You write some code, hit run, and it works. But deep down, a tiny voice inside whispers: “Why did that work?” And the even scarier thought follows: “What if it stops working and I can’t fix it?”

Welcome to the magical world of accidental genius, where developers make things work by pure luck, copy-pasting wizardry, and the divine intervention of Stack Overflow. This blog is here to unpack the most hilarious (yet painfully real) reasons why your code works, even when you have zero idea how.

1. The Stack Overflow Ritual

“Don’t reinvent the wheel,” they said. “Copy and paste this snippet,” they said.

And so, you do. Without question. Without hesitation. That’s how your bug gets magically fixed, and suddenly, you’re a “10x developer.” But here’s the catch—you have no clue what that piece of code actually does. It just... works. Until it doesn’t.

Solution: Next time, spend five minutes reading the answer before copying it. Maybe even run it in a sandbox. Wild, right?

2. The ‘Trial and Error’ Masterpiece

“Let’s try this.” Nope. “Maybe this?” Still nope. “Okay, what if I add a semicolon?” BOOM. It works.

You don’t know which change fixed the bug, but who cares? It runs, and that’s what matters.

Solution: Commit one change at a time, and for the love of debugging, read your error messages!

3. The Code Gremlins

You’re stuck on a bug for five hours. Nothing makes sense. You’re questioning your life choices.

Then, someone walks up and says, “What’s wrong?” And as you start explaining, the code just works—as if the universe is gaslighting you.

Solution: Rubber duck debugging! Explain your problem out loud, even if it’s to an inanimate object. It works. Don’t ask why.

4. The ‘Don’t Touch It’ Rule

Your project is held together by fragile, mysterious forces. The moment you try to refactor, rename, or—heaven forbid—optimize something, the entire system collapses.

So, what do you do? You leave it. Forever. Because if it works, don’t touch it.

Solution: Write documentation! Future-you will thank you. Maybe.

5. The ‘I’ll Fix It in Production’ Mindset

You push the code with a silent prayer. It runs fine locally, so what could go wrong?

Spoiler: Everything.

Solution: Use version control, test locally, and please—just please—don’t push broken code.

Final Thoughts

If any of these scenarios sound familiar, congratulations—you’re a real developer. The truth is, we all have moments of accidental success, and that’s okay. What matters is turning those moments into actual understanding.

So, the next time your code miraculously works, take a moment. Read through it. Ask yourself why it works. And if you still don’t know? Well… as long as it runs, do what every developer does—pretend you meant to do that all along. 😏

Happy coding! 🚀

shelby