DEV Community: Akanksha Sharma

💙 KindLink - Because “I Want to Help” Is Not a Plan 😭

Akanksha Sharma — Sat, 05 Sep 2026 16:04:05 +0000

This is a submission for the Weekend Challenge: Generosity Edition.

Have you ever thought:

“I really want to help people.”

…and then immediately:

“Okay, but HOW?” 🤔

Same.

We often want to be generous but turning that feeling into an actual action isn't always easy.

That little gap between wanting to help and knowing how to help is what made me think:

What if something could connect the two?

So for this challenge, I came up with KindLink. 💙

🌱 What I Created

KindLink is an AI powered platform concept designed to help people discover practical ways to give back based on what they already have.

Because generosity isn't always about money.

You might have:

Free time
A useful skill
Knowledge to share
Resources someone needs
Money to donate

The idea is simple:

“What can I give?” → “Here’s how I can use it.”

🔄 How Would KindLink Work?

Imagine opening KindLink and seeing:

┌──────────────────────┐
│     YOUR PROFILE     │
│                      │
│   Free Time          │
│   Skills             │
│   Interests          │
│   Knowledge          │
│   Resources          │
└──────────┬───────────┘
           ↓
     🤖 KINDLINK AI
           ↓
┌──────────────────────┐
│   YOUR KIND MATCHES  │
│                      │
│    Design for NGO    │
│    Mentor Students   │
│    Social Media Help │
└──────────┬───────────┘
           ↓
       ❤️ TAKE ACTION

No resume required. 😂

1️⃣ Tell KindLink what you can give

For example:

“I have 2 hours every weekend, I'm good at graphic design and I want to help children.”

That's enough for KindLink to understand what you might be able to offer.

2️⃣ AI connects the dots 🤖

Instead of throwing 500 random volunteering opportunities at you, the idea is for KindLink to consider:

Your skills + Your interests + Your availability + Your limitations

…and find opportunities that actually fit.

For example:

┌──────────────┐
│ WHAT I HAVE  │
│              │
│ 2 hrs/week   │
│ Design skill │
└──────┬───────┘
       │
       +
       │
┌──────▼───────┐
│ WHAT I CARE  │
│    ABOUT     │
│              │
│ Helping kids │
└──────┬───────┘
       │
       +
       │
┌──────▼───────┐
│ MY LIMITS    │
│              │
│ Weekends     │
│ Online only  │
└──────┬───────┘
       ↓
   🤖 AI MATCH
       ↓
┌────────────────────┐
│ 🎯 95% MATCH       │
│                    │
│ Create educational │
│ materials for kids │
└────────────────────┘

So instead of:

“Here are thousands of ways to volunteer. Good luck.” 😭

KindLink could say:

“This one looks like you.”

💡 What Could You Actually Do?

For our imaginary graphic designer, KindLink might suggest:

🎨 Create educational materials
Help a nonprofit create worksheets or learning resources.

📱 Help with social media
Use design skills to help a small organization improve its online presence.

📚 Mentor students online
Spend a couple of hours helping students learn something you're already good at.

The goal isn't simply to tell people:

“Go volunteer.”

It's to answer:

“Here’s something YOU can realistically do.”

❤️ From Intention to Action

Because there's a big difference between:

“I should help someday.”

and

“I'm helping this Saturday.”

The journey could look like this:

💭 "I want to help"
          ↓
      🤔 "But how?"
          ↓
     🤖 KindLink
          ↓
   🎯 Find my match
          ↓
   📅 Pick a time
          ↓
     ❤️ "I'll help"

That's the whole idea.

Less friction. More action.

🤖 Why AI?

I didn't want to add AI just because every project apparently needs a chatbot now. 😭

The actual problem is finding the right match.

There are countless ways to help but not every opportunity is suitable for every person.

AI could make that process more personal by connecting:

What you can offer
What you care about
What you actually have time for
What you're realistically able to do

A realistic way to make an impact. 🌱

💭 Why This Idea?

This challenge made me think about generosity beyond donating money.

Sometimes helping someone means giving:

Two hours of your weekend.
A skill you've spent years learning.
Something you know how to teach.
A resource you no longer need.

Or even:

“Hey, I know someone who can help.”

Everyone has something they can give.

Sometimes we just need help figuring out where it can make a difference.

That's the idea behind KindLink.

Less “I should help.”

More “Okay, I know how I can help.” 💙

Thanks to the DEV team for the challenge. It got me thinking about how technology can encourage small, realistic acts of generosity instead of just helping us order food faster. 😂❤️

🤖 Can Vibe Coding Get You Hired as a Developer?

Akanksha Sharma — Tue, 01 Sep 2026 11:26:25 +0000

Yes. But There's a Catch.

Or are you just really good at asking AI to fix the code AI wrote? 😭

Let's be honest.

A few years ago, getting hired as a developer meant proving you could write code.

Today?

You can type:

“Build me a full-stack app with authentication, payments, AI, dark mode and absolutely no bugs.”

30 seconds later…

Congratulations! You are now the CTO. 💀

Welcome to vibe coding.

🤔 What is vibe coding?

It's basically:

Describe → Generate → Run → Break → Ask AI to fix it → Repeat.

And honestly?
It feels amazing.

Don't remember the syntax?
AI knows it.

Don't remember the API?
AI knows it.

Created 17 errors?

AI is already typing:

“I understand the issue.”

Meanwhile you're thinking:

“Same bro. I also understand the issue.” 😭

Except sometimes…

AI doesn't.

And that's the important part.

🧠 Can it actually get you hired?

Yes, but “I can vibe code” isn't the skill companies are hiring for.

The valuable skill is:

“I can use AI to build something, understand what it generated, debug it and make the right technical decisions.”

That's very different from:

“AI built my entire app.”

Companies still need developers who understand:

Programming → APIs → Databases → Git → Debugging → Testing → Security → Architecture

Because AI can generate code that looks perfect…

…and still be completely wrong. 🥲

💻 And here's where vibe coding gets really powerful

You don't even have to be a professional developer to benefit from it.

A designer can build a prototype.

A founder can build an MVP.

A marketer can automate a repetitive task.

A data analyst can create a dashboard.

A product manager can test an idea.

For these people, vibe coding removes the barrier between:

“I have an idea.”

and

“I built something.”

That's genuinely revolutionary.

But if software engineering is your actual job, the bar is different.

Professional software isn't just:

“Does it work?”

It's:

“Why does it work, what can break and is this the right solution?”

🧩 Vibe coding ≠ skipping fundamentals

You don't need to memorize every syntax rule.

You don't need to write repetitive boilerplate for hours.

If AI can save you two hours of boring coding…

LET IT.

But you still need enough fundamentals to judge its output.

Because when AI gives you 400 lines of code, someone has to ask:

“Is this actually a good solution?”

That someone should be you.

AI reduces the amount of code you type.
It doesn't reduce the amount of engineering you need to understand.

⚡ AI can make you faster. Not automatically better.

Imagine two developers.

Developer A:
AI writes everything.
Copies the solution.
Can't explain the architecture.
Something breaks → “ChatGPT, fix this.”

Developer B:
Uses AI for boilerplate, debugging, testing and exploring solutions.

But still:

Reads the code.
Questions the code.
Tests the code.
Owns the final decision.

Who would you hire?

Exactly.

🚀 So what's the future?

I don't think the future belongs to the developer who writes the most code.

It belongs to the developer who can:

Think clearly.
Build quickly.
Understand deeply.
Use AI intelligently.

Don't become:

Prompt → Copy → Paste → Pray 🙏

Become:

Understand → Think → Prompt → Review → Test → Improve

Because when AI-generated code breaks in production at 2 AM…

your manager isn't going to ask the AI what happened. 💀

They're going to ask you.

💡 The goal isn't to code without AI.

It's to become a developer who is better because AI exists.

There's a big difference between:

“AI built this for me.”

and

“I built this with AI.”

And I think that difference is going to matter more and more.

👇 Your turn

Would you hire a developer who can build an entire application using AI but can't explain the code without AI?

Where do you draw the line between an AI-assisted developer and a professional vibe coder? 👀

5 Years Ago, Git & I Met… 💀

Akanksha Sharma — Sat, 29 Aug 2026 12:46:29 +0000

5 years ago, I encountered Git & GitHub for the first time.

And let me tell you…

It was NOT love at first commit. 😭

I watched someone casually type:

git add .
git commit -m "Initial commit"
git push origin main

And I was sitting there like:

“Damn. I’m officially a developer now.” 😎💻

Meanwhile, my brain was running on 2% battery:

"git add ." → “Add WHAT?”
"git commit" → “Commit to WHAT?”
"git push" → “Push WHERE?”
"origin" → “WHO IS ORIGIN? 😭”

But did I ask?

Absolutely not.

Because apparently, beginner confidence is just confusion with good posture. 💀

So I did what every totally confident beginner does:
Copy → Paste → Enter → Pray. 🙏🏻

And then…

💥 ERROR.

Me: “Hmm… interesting.”
Git: another error
Me: “Okay…”
Git: another error
Me: “Why does this feel personal?” 😭

My debugging process was basically:

Google the error 🔎
↓
Open Stack Overflow
↓
Find a command written in 2017
↓
Copy it without understanding anything
↓
Paste
↓
Press Enter
↓
Stop breathing

And when it finally worked?
“Yeah, yeah… I knew what I was doing.” 😌

Narrator:
She absolutely did not. 💀

Back then,
GitHub was basically:
“That website where I upload my code.”

And Git?
“Those scary commands I hope I don't accidentally destroy everything with.” 😭

But eventually, I realized something:

I didn't want to just memorize Git commands.
I wanted to actually understand what Git was doing behind the scenes.

So I started my Git & GitHub Zero to Hero series, starting from absolute zero and explaining things without assuming you already know everything.

Because honestly…

Nobody should have to pretend they know what "origin" is. 😂🤝

And if you're currently in the:

“WHO IS ORIGIN?”

phase…

Welcome. You're among friends. 💀😂

Be honest,what was the first Git command that made absolutely ZERO sense to you? 👇

Read Part 1 here:

[https://akankshasharma.hashnode.dev/git-github-zero-to-hero-1-what-is-git-a-beginner-s-guide]

AI Isn’t Killing Tech Jobs. But It Is Changing Who Gets Hired. 🤖

Akanksha Sharma — Mon, 24 Aug 2026 13:37:11 +0000

If you don't want to read the whole thing, here's the short version:

Yes, AI is affecting the tech industry.

But I don't think the story is simply:

“AI will replace developers.”

I think the bigger story is:

AI is changing what companies expect from developers.

And honestly, that shift has already started.

AI can generate code, explain errors, write unit tests, create documentation, refactor functions, analyze logs and automate repetitive development tasks.

A task that might once have taken an hour can sometimes take 15 minutes with the right AI tools.

And yes, that can affect hiring.

If a smaller team can deliver the same amount of work because every developer is more productive, companies may need fewer people for certain types of work.

That's the part we shouldn't ignore.

But software engineering isn't just typing code.

AI can generate code. Engineering is more than code.

Imagine you're building a payment system.

AI can help you write an API endpoint.

It can generate a database query.

It can suggest error handling.

It can even write tests.

But who decides:

Should the API be REST or event-driven?
How should authentication work?
What happens if the payment succeeds but the database update fails?
How do we prevent duplicate transactions?
What data should be logged?
How should sensitive information be protected?
Will this architecture scale when traffic increases?

Those aren't simply code-generation problems.

They're engineering problems.

AI can suggest solutions, but developers still need to understand the trade-offs and validate those solutions.

AI can generate code. But code isn't the same thing as engineering.

AI is changing the development workflow

Think about a typical development cycle.

Before AI, a developer might:

Requirement → Research → Code → Debug → Test → Review → Deploy

With AI assistance, parts of that workflow can become:

Requirement → AI-assisted research → Generate → Review → Test → Debug → Deploy

The difference is important.

The developer's job doesn't necessarily disappear.

The developer's time shifts toward higher-value decisions.

Instead of spending 30 minutes writing boilerplate, you might spend that time reviewing architecture.

Instead of manually writing every test case, you might use AI to generate a starting point and then verify edge cases yourself.

Instead of searching through documentation for every small syntax issue, you can ask AI for an explanation and validate it against the actual documentation.

That's productivity.

But there's an important catch.

AI can also create problems faster

If you don't understand the code AI generates, you're essentially turning your lack of understanding into technical debt.

AI-generated code can contain:

Logic errors
Security vulnerabilities
Poor database queries
Incorrect assumptions
Unnecessary dependencies
Performance problems
Outdated APIs

And sometimes the code looks perfectly reasonable.

That's what makes it dangerous.

A developer who understands the fundamentals can ask:

“Why did AI choose this approach?”

A developer who doesn't may simply ask:

“Does this code run?”

Those are very different questions.

And that's why fundamentals such as data structures, algorithms, databases, networking, system design, security and debugging still matter.

Possibly more than before.

The developer skill set is changing

The valuable skill isn't simply:

“I can write JavaScript.”

It's becoming:

“I can use JavaScript, understand the system I'm building and use AI to solve problems more efficiently.”

For example, knowing React is useful.

But understanding:

component architecture
state management
rendering behavior
API communication
performance
accessibility
security
testing

is much harder to replace with a code generator.

The same applies to backend development.

Knowing how to generate an Express or FastAPI endpoint is useful.

Understanding authentication, authorization, database indexing, caching, concurrency, API design, observability and scalability is much more valuable.

AI can help you learn and implement these concepts.

But it doesn't remove the need to understand them.

So who is actually at risk?

Probably not simply “developers.”

The bigger risk is for developers whose work consists largely of predictable, repetitive tasks and who don't expand their skill set as the tools around them improve.

And this creates an interesting situation for entry-level developers.

Junior developers traditionally learn by working on smaller tasks:

Fix this bug.
Build this component.
Write this API.
Add this validation.

AI can increasingly assist with many of those tasks.

So beginners may need to differentiate themselves through something beyond simply being able to produce code.

Problem-solving.

Debugging.

Understanding systems.

Communication.

Learning quickly.

And most importantly:

Knowing why the code works, not just how to generate it.

So, what should developers do?

Don't panic.

Don't blindly trust AI.

And don't ignore it either.

Instead:

Strengthen your fundamentals.

Use AI for repetitive work and exploration.

Learn to review AI generated code critically.

Understand security and performance implications.

Get better at debugging.

Learn system design and architecture.

And build projects where you can explain every major technical decision you made.

Because the future probably isn't:

AI vs Developers

It's more likely:

Developers who use AI vs developers who don't.

But there's an even bigger distinction:

Developers who understand what AI generates vs developers who simply copy it.

So maybe the question isn't:

“Will AI take my job?”

Maybe the better question is:

“If AI makes my current skills cheaper, what valuable skills should I build next?”

Because the developers who can combine strong fundamentals + engineering judgment + AI tools may end up being the most valuable ones.

And now I'm curious:

Do you think AI will mostly reduce junior jobs, senior jobs or change both? 👇

I Blamed React for 45 Minutes. The Bug Was One return. 😭

Akanksha Sharma — Thu, 20 Aug 2026 15:19:52 +0000

There are two types of Developers:

People who write clean, predictable code.
People who add console.log() until the browser starts feeling like a crime scene.

I am, unfortunately, Team #2. 🫠

And this story is about the time I spent 45 minutes debugging React only to discover that JavaScript was waiting for me to type one tiny word.

return

It started innocently enough...

I had a React component fetching data from an API and displaying it on the page.

Pretty normal stuff.

The API was working. ✅
The data was coming back. ✅
The component was rendering. ✅

The UI?
Nothing.

Just an empty page.
Beautiful.
Minimalist.
Very intentional-looking.
Definitely not broken.🙂

So obviously, I started investigating.

First thought:

“Maybe the API isn't working.”
Checked it.
Working.

Then:

“Maybe the state isn't updating.”
Checked it.
Working.

Then:

“Maybe something is wrong with the component.”
Checked it.
Also working.

At this point, I reached the most logical conclusion:

React is broken.

Obviously.

So I did what every experienced developer does when they have absolutely no idea what's happening:

console.log("Component rendered");
console.log("API called");
console.log("Data received:", data);
console.log("Users:", users);
console.log("WHY IS THIS EMPTY???");

My console was slowly becoming a conversation with myself.

Then I found the crime scene.

This was the code:

{users.map(user => {
  <div key={user.id}>
    <h3>{user.name}</h3>
  </div>
})}

I stared at it.
It looked fine.

I stared at it again.
Still fine.

Then I noticed it.

There was no return.😭

The problem wasn't React.
The problem wasn't the API.
The problem wasn't my state.

The problem was...

"ME"

When you use curly braces with an arrow function, you need an explicit return.

So instead of:

{users.map(user => {
  <div key={user.id}>
    <h3>{user.name}</h3>
  </div>
})}

I needed:

{users.map(user => (
  <div key={user.id}>
    <h3>{user.name}</h3>
  </div>
))}

And just like that...

THE UI APPEARED.

I genuinely sat there for a few seconds thinking:
“You have got to be kidding me.”

45 minutes.

Forty.

Five.

Minutes.

I had checked the API.
I had checked the state.
I had checked the component.

I had added enough console.log() statements to qualify as a documentary.

I was mentally preparing to rewrite the entire component.

Meanwhile, JavaScript was basically sitting there like:
“You forgot to return the thing.”

Fair enough.

My highly sophisticated debugging methodology

Minute 1:
“This should work.”

Minute 5:
“Maybe it's the API.”

Minute 10:
“Let's check the state.”

Minute 15:
“Let me add a console.log().”

Minute 20:
“Okay, another one.”

Minute 30:
“Why is React doing this to me?”

Minute 40:
“Maybe I'll just rewrite the component.”

Minute 45:
“Oh.”

return. 😭

The actual lesson

The funny thing is, this wasn't some complicated React bug.
I didn't discover some hidden rendering issue.
I didn't need a fancy debugging tool.
I just missed one tiny JavaScript rule.

And honestly, that's probably one of the most annoying things about debugging:

The longer you stare at a bug, the harder it can become to see the obvious.

Sometimes the problem is genuinely complicated.

And sometimes you've spent 45 minutes investigating your entire application because you forgot one word.

So now, before I start blaming React, I'm trying to go through the boring checklist first:

Is the component rendering?
Is the data actually there?
Is the state updating?
Is my .map() returning something?
Did I spell the variable correctly?
Did I accidentally comment something out?
Did I, in fact, forget something incredibly obvious? 👀

Because apparently, that's a real debugging step now.

And yes, I still use console.log().

I'm not going to pretend this experience magically turned me into a debugging expert.

The next time something breaks, I'll probably still do:

console.log("HERE");
console.log("HERE 2");
console.log("HERE 3");

And then I'll stare at the screen.
And refresh.
And refresh again.
And blame React.

But maybe...

I'll check the return first. 😂

Your turn 👇

What's the stupidest bug you've spent way too long debugging?

The kind where you finally find the problem and just sit there thinking:

“...I cannot believe I just did that.”

Please tell me I'm not alone. 😭

First Post on DEV 🚀

Akanksha Sharma — Wed, 19 Aug 2026 12:27:14 +0000

Hello, DEV Community! 👋

After spending a lot of time learning, building, breaking things, fixing them and occasionally wondering “Why is this not working? ” 😅 -I finally decided to make my first post here.

I’m a Software Engineer and my journey so far has taught me something important:

Software engineering isn’t just about writing code.

• It’s about solving problems when there’s no obvious answer.
• It’s about debugging something you were sure was working.
• It’s about making mistakes, learning from them and trying again.

And sometimes, it’s simply about figuring things out one step at a time. 💻

I’ve had my share of challenges, unexpected bugs, learning curves and those small wins that make all the frustration worth it.

From now on, I want to share more of that journey here -not just the final results, but the problems behind them, the mistakes, the solutions and the lessons learned along the way.

No “I know everything” posts.

Just learning, building, experimenting and growing in public.🌱

What’s one lesson software engineering has taught you that you wish you knew when you started?