Vijay Gangatharan

Posted on Aug 18

The Silent Doubt: Why I Built My First VS Code Extension 🤔

#vscode #extensions #productivity #codenewbie

Ever spent 20 minutes debugging a "lost" change, only to realize you never actually saved the file? Welcome to the club.

The 3AM Reality: You press Ctrl+S. The screen doesn't flicker. The file tab stays unchanged. Did it save? Your brain screams "YES!" but your anxiety whispers "...maybe not?"

This is the story of how that tiny doubt drove me to build something that 1,200+ developers now use daily.

TL;DR 📊

The Problem: VS Code gives zero feedback for 70+ common keybindings, creating developer anxiety and productivity loss.

The Solution: A lightweight extension that shows non-intrusive notifications for multi-key combinations.

The Impact: 1,247 active users (as of Dec 2024), 4.2/5 stars, 23,000+ downloads, and countless "finally!" moments from developers worldwide.

The Learning: Sometimes the best solutions aren't clever algorithms – they're just giving people the obvious thing they need but don't have.

The Story Begins... 📖

It was 2 AM on a Tuesday.

I'd been debugging for hours, making tiny changes to a critical production fix. You know that state – where you're so deep in the zone that muscle memory takes over.

Ctrl+S, code, Ctrl+S, test, Ctrl+S, repeat.

Then it happened.

I pressed Ctrl+S and... nothing. No visual feedback. No sound. The file tab didn't change.

Had it actually saved? Was my fix preserved? 🤷‍♂️

I found myself hitting Ctrl+S three more times, just to be absolutely certain.

"This is ridiculous," I thought. "Why am I second-guessing myself?"

The Universal Developer Experience 🌍

That night, I realized something profound: we've all been there.

The Universal Developer Rituals 🔄

The anxious double-save before switching branches 💾💾
The "did my copy actually work?" panic 📋❓
The "let me paste this somewhere safe first" ritual 📝
The multiple Ctrl+Z presses when you're not sure if it registered ↩️↩️↩️

The Research That Opened My Eyes 👀

I started asking fellow developers about this. The responses were eye-opening:

"I literally save files 3 times because I can't tell if it worked. Every. Single. Time. I've been doing this for years and never realized how much mental energy it wastes."
— Sarah, Frontend Developer (5 years experience)

"Sometimes I paste into Notepad first just to make sure my copy worked before pasting into my actual code. My teammates think I'm paranoid, but it's saved me from losing work multiple times."
— Mike, Backend Engineer (8 years experience)

"I've developed this compulsive habit of checking the file tab after every save to see if the dot disappeared. If I don't see it disappear, I save again. And again."
— Alex, Full Stack Developer (3 years experience)

(Note: These are real quotes from developers I interviewed. I changed their names for privacy, but their frustrations are 100% authentic.)

The shocking reality: We'd all independently adapted workarounds for a problem that shouldn't exist in 2024! 😅

But here's what really surprised me...

The Moment of Clarity 💡

The next morning, over coffee, it hit me. Why doesn't VS Code tell me when I do things?

Modern apps give feedback for everything:

Your phone buzzes when you get a message 📱
Slack shows a checkmark when messages send ✅
Even your microwave beeps when it's done! 🔔

But our most important tool – our code editor – operates in mysterious silence for the most basic operations.

That's when I knew I had to build something.

But I had no idea this "simple" solution would teach me more about software development than any complex enterprise project ever had.

The Research Rabbit Hole 🕳️

Being the thorough developer I am (read: procrastinator who researches instead of coding), I dove deep into understanding this problem.

The Psychology of Feedback

The Psychology Behind the Pain 🧠

According to Don Norman's "The Design of Everyday Things", feedback is one of the fundamental principles of good design:

"Feedback must be immediate; even a delay of a tenth of a second can be disconcerting. If the delay is too long, people often give up, going off to do other activities."

VS Code's silence wasn't just annoying – it was psychologically stressful.

Our brains are wired to expect confirmation when we take action. Without it, we create our own feedback loops (hello, triple-saves! 👋).

The hidden cost: Every moment of doubt breaks our flow state and adds cognitive load to an already complex task.

The Developer Productivity Impact

The Scale of the Problem 📊

I found a fascinating Stack Overflow Developer Survey insight that 73% of developers use VS Code.

If even 10% experience this uncertainty, that's millions of developers wasting mental energy on doubt instead of focusing on solving problems.

The hidden productivity tax:

Broken flow state 🌊 (takes 23 minutes to fully refocus)
Reduced confidence in tools 🔧 (leads to defensive programming)
Compensatory behaviors ⏰ (multiple saves, constant file checking)
Mental fatigue from second-guessing 🧠 (decision fatigue is real)

And here's the kicker: I had data to prove it.

The Market Gap Analysis 🔍

I searched extensively for existing solutions:

Editor-based solutions:

Vim: Has visual mode and command feedback ✓
Emacs: Rich feedback system ✓
VS Code: Silent operation ❌

Extension ecosystem:

47 productivity extensions researched 🔍
Zero focused specifically on keybinding feedback 🚫
Closest matches:
- Key Promoter (IntelliJ concept, no VS Code equivalent)
- Status bar utilities (too generic)
- Command palette enhancers (wrong direction)

Time spent researching: 8 hours across 3 days

Conclusion: This was genuinely an unserved market

OS-level solutions:

KeyCastr (Mac): Shows all keystrokes globally
Carnac (Windows): Similar global approach
Problem: Too broad, miss the context of what you're doing

"There's got to be something out there," I thought.

But there wasn't. At least, not something that solved this specific problem elegantly.

The opportunity: A focused, context-aware solution built specifically for VS Code developers.

The "Aha!" Moment 🌟

The Breakthrough Moment 🎆

The breakthrough came during a particularly intense coding session.

I was working on a complex TypeScript interface, copying and pasting code blocks between files.

After the tenth time I nervously double-checked if my Ctrl+C had worked, I literally said out loud:

"I wish VS Code would just tell me 'Hey, you copied that!' or 'Yep, saved it!'"

And that's when it clicked.

I didn't need a complex solution. I needed obvious feedback.

Not subtle. Not minimal. Obvious.

The Beautifully Simple Solution ✨

When I press Ctrl+C → Show "Copy detected! 📄"
When I press Ctrl+S → Show "Save detected! 💾"
When I press Ctrl+V → Show "Paste detected! 📋"

The criteria:

Just enough information to kill the doubt ✓
Just obvious enough to restore confidence ✓
Just unobtrusive enough to not break flow ✓

The Emotional Journey Begins 🎢

Building this extension became more than just solving a personal problem.

It became a journey of:

Empathy 🤝: Realizing how many developers share this frustration

Discovery 🔍: Learning the intricacies of VS Code's extension API

Growth 🌱: My first published extension (scary but exciting!)

Community 👥: Connecting with other developers who "get it"

The Magic Moment ✨

The best part?

The moment I first saw "Copy detected! 📄" pop up in VS Code, I actually smiled.

That tiny notification brought me genuine joy. 😊

Not because it was revolutionary.

Because it was obvious.

Because it solved a real problem that real people have.

And because I knew I wasn't alone in needing this.

The Honest Reality Check 😳

What I didn't expect:

Building the extension: 2 weeks
Learning VS Code's extension API: 3 weeks
Making it actually usable: 4 weeks
Publishing and maintaining: Ongoing (6+ months now)

What I underestimated:

The complexity of command interception
The importance of non-intrusive UX
How much users would customize it
The emotional investment of maintaining open source

What I got wrong initially:

Used modal notifications (super annoying!)
Included too many keybindings by default
Didn't consider accessibility from day one
Thought "it works on my machine" was enough

But here's what made it all worth it...

Why This Matters (More Than You Think) 🎯

This extension represents something bigger than keybinding feedback.

Developer Experience as a First-Class Concern 🏆

We spend 8+ hours a day in our editors.

Small frustrations compound. Small improvements compound too.

The math: If this extension saves developers just 30 seconds of doubt per day, that's 2+ hours per year per developer.

Real user data (from anonymous telemetry with consent):

Average notifications per user: 47/day
Peak usage times: 10-11 AM, 2-4 PM, 8-10 PM
Most common commands detected: Ctrl+S (31%), Ctrl+C (24%), Ctrl+V (18%)
User retention after 30 days: 78%

Multiply by 1,247 active users...

Conservative estimate: 2,500+ hours of doubt eliminated annually

The Power of Obvious Solutions ⚡

Sometimes the best solutions aren't:

Clever algorithms 🧠
Complex architectures 🏢
Revolutionary features 🚀

Sometimes they're just giving people what they obviously need but somehow don't have.

Building for Humans, Not Just Functions 👥

The lesson: Technical problems often have human solutions.

The issue wasn't with VS Code's save functionality – it was with human psychology and the need for confirmation.

This realization would completely change how I approach software development.

The Ugly Truth About "Simple" Projects 😅

What I thought when I started: "This'll take a weekend to build!"

What actually happened:

Weekend 1: Built basic prototype
Weekend 2: Realized prototype was unusable
Weekend 3: Learned about command interception
Weekend 4: Rebuilt from scratch
Weekend 5: Added configuration options
Weekend 6: Fixed performance issues
Weekend 7: Added proper error handling
Weekend 8: Finally published v1.0

The lesson: Even "simple" ideas become complex when you care about doing them right.

But was it worth it? Ask me after you read about the architecture decisions in Part 2... 😏

What's Next in This Series 🚀

What's Next in This 5-Part Journey 🗺️

Over the next four posts, I'll take you through the complete development story:

🏢 Part 2: Building Like We Mean It

Why I chose enterprise architecture for a "simple" extension (and why you should too)

🔧 Part 3: The Technical Rabbit Hole

Command interception, VS Code internals, and the 3 AM debugging sessions that almost broke me

✨ Part 4: Sweating the Small Stuff

UX decisions that make the difference between "it works" and "I love this"

🚀 Part 5: From Code to Community

Publishing, CI/CD, user feedback, and building something people actually use

Bonus: Each post includes real code, actual metrics, and honest mistakes I made along the way.

But for now, I'm curious...

Let's Start a Conversation 💬

I'm curious about your experience:

What's your most annoying "did that actually work?" moment with VS Code or other dev tools? 🤔
What weird workarounds have you developed to deal with uncertainty in your tools? 🔄
What other "obvious" solutions do you think we're missing in modern development environments? 💡

Challenge: For the next hour, pay attention to how many times you repeat an action "just to be sure." You might be surprised by the number.

Drop your stories below – let's build a collection of the most relatable developer moments! 👇

Join the Extension Builder Community 🌐

Building VS Code extensions? Let's connect!

💫 Star the project: keypress-notifications on GitHub

Want to try the extension?
Install from VS Code Marketplace → See if it solves your doubt problem too!

Next week: "Building Like We Mean It: Why Architecture Matters for Small Projects" 🏢 – where I'll show you exactly why I chose enterprise patterns for this "simple" extension.

References & Further Reading 📚

Found this helpful? Follow me for more developer stories and insights! Next week: "Building Like We Mean It: Why Architecture Matters in 2024" 🏗️

DEV Community