DEV Community: Abidit Shrestha

I'm a Senior Software Engineer. I Had No Business Writing Courses. I Did It Anyway.

Abidit Shrestha — Wed, 25 Mar 2026 09:04:23 +0000

Let me be upfront about something: I am not a teacher.

I'm a senior software engineer. I write code for a living. I've shipped production systems, reviewed thousands of pull requests, and debugged things that had no right being as broken as they were. But explaining concepts to beginners, structuring a curriculum, deciding what order to teach things in — that is a completely different skill, and I had almost none of it when I started.

I now have six published courses on Programiz, including a full JavaScript game development skill track. Here's the honest story of how that happened.

The opportunity I almost didn't take

When Programiz approached me about building a JavaScript skill track, my first instinct was to say it wasn't really my thing. I'd written some small articles and blog posts over the years, but a full course? Multiple courses? That felt like someone else's job.

I took it anyway.

Not because I was confident. Because I was curious whether I could do something I'd never done before — and because I had tools available that didn't exist a few years ago.

How I actually built it

I want to be honest about this part because I think a lot of people gloss over it: I used Cursor and Claude heavily throughout this process. Not to replace my thinking, but to do things I couldn't do efficiently on my own.

Here's what that actually looked like:

Structuring the curriculum — I'd describe what I wanted students to be able to do at the end, and use Claude to stress-test the sequencing. Does this concept need to come before that one? Is there a gap here? Having something to push back against is faster than staring at a blank page.

Building the reference code — The Brick Breaker capstone project has a Ball class, a Paddle class, a Brick class, a Game class. Getting that code to a point where it was genuinely teachable — clean variable names, strict separation between update() and draw(), no shortcuts that would confuse a beginner — took iteration. Cursor was open the entire time.

Drafting explanations — Writing for beginners is harder than writing for peers. I'd draft an explanation, and use Claude to tell me where it assumed too much prior knowledge. Then I'd rewrite it.

Reviewing my own work — This one surprised me the most. Having an outside read on a draft — even an AI one — catches things you stop seeing after the fifth revision.

None of this felt like cheating. It felt like having a very patient, very fast collaborator who never got tired of my questions.

Where I almost stopped

About three weeks into the first course, I hit a wall.

I was trying to write a comprehensive ES6 fundamentals module — arrow functions, destructuring, modules, iterators, the works. I wanted it to be complete. I wanted to cover everything. The review process destroyed me. Every pass surfaced new gaps, new things I hadn't explained well enough, new topics that felt incomplete without adding three more topics.

I almost quit at that point. Not because the material was too hard, but because I was approaching it wrong.

The shift that saved the project: I stopped trying to be complete and started asking a different question. Which of these concepts actually shows up in the game we're building? If a concept didn't have a clear home in the Brick Breaker capstone, it didn't belong in the course. That constraint made every decision easier and every chapter tighter.

The lesson I'd pass on to anyone trying something similar: plan in chunks, not in coverage. Pick a concept, find two or three real places it gets used, teach it through those. Don't try to give a complete picture on the first pass. Completeness is the enemy of clarity.

What the track looks like now

Build Games with Vanilla JS is live on Programiz as Skill Track 2. Six courses:

Game Logic with JavaScript — variables, conditionals, functions, scope through a game-thinking lens
Whack A Mole — a DOM and events mini-project early, so students get a win before the harder content
Modern JavaScript Essentials — ES6 features placed after the first mini-project, not before, so students have context for why they matter
Canvas Foundations — the <canvas> API: drawing, animation loops, input, collision detection
Brick Breaker with JavaScript — the capstone where every concept from the track lands in one real project
Rapid Build with Claude Code — a standalone weekend course on building and deploying an app with AI tools

The sequencing isn't accidental. Whack A Mole sits before the ES6 module because abstract syntax makes more sense after you've already built something. Canvas Foundations only teaches what shows up in Brick Breaker. Every decision was made by working backward from the capstone.

What I know now that I didn't know then

Writing a course as a senior engineer is humbling in a specific way. The technical part is fine — I know JavaScript well. The hard part is that knowing something deeply and being able to teach it are not the same skill at all.

Teaching forced me to find the edges of my own understanding. If I couldn't explain why the ball position needs to be corrected before the velocity reverses — not just that it does — I didn't actually understand it as well as I thought.

I also learned that AI tools don't lower the bar for this kind of work. They raise what's possible for one person working alone. The courses exist in the form they do because I could iterate faster, get feedback faster, and catch mistakes faster than I could have otherwise. The judgment calls — what to include, what to cut, how to sequence — were still mine.

Why I'm writing this

I'm not writing this to tell you AI makes everything easy. It doesn't.

I'm writing this because I'm a senior engineer who grabbed an opportunity outside his comfort zone, used every tool available, got humbled by it, figured it out, and shipped something real. If that's the kind of person you want to follow — someone who moves toward hard things and works out how to do them — then stick around.

There's more coming.

Abidit Shrestha is a senior software engineer and course author at Programiz, where he builds JavaScript learning tracks. Follow him on Dev.to and Medium for more.

Discovery: The Hidden Bug Killing Learning Platforms

Abidit Shrestha — Mon, 29 Dec 2025 14:12:01 +0000

For a long time, we believed learners struggled because problems were hard.

Turns out, many never even reached the problem.

While working on Guided Projects at Programiz PRO, we started sitting in clarity sessions and talking directly to users. Not surveys. Not analytics. Real conversations.

One pattern kept repeating:

users weren’t stuck — they were lost.

They didn’t ask for new features.

They asked things like:

“Where do I start?”
“What should I do next?”
“Is this part of the course?”

That’s when it became clear:

learning friction often starts before learning begins.

Features don’t matter if they’re invisible

We had content.

We had projects.

We had structure.

But poor discovery made them irrelevant.

No amount of complexity or polish can fix that.

From assumptions to conversations

Instead of guessing, we shifted focus:

User interviews
Clarity sessions
Observing hesitation, not just clicks

The insights were uncomfortable — and incredibly valuable.

What we changed

Our focus moved from “adding more” to:

Clearer entry points
Stronger learning flow
Reducing cognitive load early

Because when users know where to begin, they’re far more likely to finish.

The bigger lesson

Learning platforms don’t fail because content is weak.

They fail because the path isn’t obvious.

And the only way to see that?

Talk to users. Watch them struggle. Listen carefully.

That shift has changed how we build — and how we think about learning.

Turning Complex Algorithms into Interactive Visual Stories: My Journey

Abidit Shrestha — Wed, 27 Aug 2025 14:58:08 +0000

When I started working on algorithm visualizers at Programiz, I didn’t think much about making them interactive. But after tackling a few problems, I realized: algorithms are stories, and everyone learns better when they can see the story unfold.

🎬 Act I: The Stack That Stunned a Professor

The easy part was coding a rough version. The hard part? Polishing it until anyone could follow the story just by watching.

When we finally showed it to a university professor (a Programiz customer), his reaction was priceless.

“This makes debugging and teaching so much easier. You can pause, play, and see exactly what’s happening in every step.”

That’s when it hit me: visualization isn’t about code. It’s about clarity.

🎬 Act II: The Queue That Fooled My Brain

Queues are simple, right? FIFO. Done. No visualizer needed.

Wrong.

I made queue elements slide from right to left (like an array on wheels). Suddenly, everyone got it without me saying a word.

The tricky bit was dequeue. Animations don’t like disappearing acts. It was Stack Pop all over again. After some wrestling with it, I got the motion flowing.

When I demoed it, the professor pointed out something fascinating:

“This left-to-right flow actually matches how our brain tracks objects naturally.”

Turns out, even human cognition agreed with FIFO. 🧠

🎬 Act III: Knapsack — My First Big Heist

The infamous 0/1 Knapsack Problem. Students fear it. Developers avoid it.

I built a Knapsack Visualizer that doesn’t just solve it but lets you:

Step through decision-making at each subproblem
Watch dynamic programming build the table live
Actually see optimal substructure and overlapping subproblems in action

This project taught me: building is easy, polishing is hard.

Animations, UI, logic, storytelling — I had to touch every piece.

But the final result? A tool I wish I had when I first learned DP.

🎬 Act IV: Coin Change in 3 Days

And then came my fastest build: the Coin Change Visualizer.

From scratch to production in just 3 working days.

This wasn’t speed for speed’s sake. It was proof that with the right process, clarity, and focus, even complex algorithms can be made intuitive.

Tested on all ages — from students to professors — it clicked instantly. No blank stares. No groans. Just “aha” moments.

🌍 Why This Matters

Algorithms don’t have to be intimidating walls of logic.

With the right design and engineering, they become stories people can watch, follow, and remember.

That’s what we’re building at Programiz: tools that lower barriers, make learning intuitive, and give anyone the confidence to say, “I understand this.”

For me personally, this journey wasn’t just engineering — it was proof of what happens when creativity and execution meet.

🚀 Closing Thoughts

If you’ve known me, maybe you didn’t expect me to go this deep into building algorithmic visualizers. Surprise 😉

If you didn’t know me before, now you do:

I build things that turn complexity into clarity.

I make algorithms human.

And I’m just getting started.

🔗 Try one of the visualizers here: KnapSack Visualizer

💬 I’d love to hear your thoughts:

What algorithm should I tackle next?
What’s the one concept you wish had a visualizer when you first learned it?

DataStructures #DynamicProgramming #Visualization #SoftwareEngineering #EdTech #Programiz #OpenToWork #NepalDevelopers