DEV Community

Cover image for You’re learning wrong (and that’s why you’re stuck as a mid dev)
<devtips/>
<devtips/>

Posted on

You’re learning wrong (and that’s why you’re stuck as a mid dev)

#webdev #programming #development #devops

Stop bingeing tutorials. Start learning like an engineer.

I once spent three straight weeks grinding through a React course. Twenty hours of video. Dozens of example projects. By the end, I could barely explain how a single hook worked without Googling. That was my rock bottom moment the kind of “wtf am I even doing?” dev crisis you don’t forget.

Here’s the kicker: the frameworks keep coming, the docs keep growing, and now AI is flooding our workflows. If you don’t know how to learn effectively, you’ll get wrecked. Doesn’t matter if you’re “senior” today a new tool can reset you to tutorial hell in seconds.

Me trying to learn Rust while forgetting Python basics?
→ brain.exe has stopped working.

TLDR: In this article, I’ll break down how devs can actually learn like engineers: using memory science (spaced repetition, chunking), active learning (breaking > watching), feedback loops (PR comments hurt but work), and AI (as a sparring partner, not your brain). Expect confessional dev scars, practical strategies, and at least one meme about tutorial hell.

Why devs learn wrong

Let’s be honest: most devs confuse consumption with learning. We binge tutorials, bookmark Medium posts, star GitHub repos like it’s an Olympic sport. But when it’s time to build something without training wheels? Our brains return a crisp, clean 404 Not Found.

This is the infamous tutorial hell. You feel productive (“look, I finished another 8-hour course!”), but you’re really just collecting XP cutscenes instead of actually playing the game.

I fell into this trap hard during onboarding at one job. The internal docs said the service used PostgreSQL schemas in a certain way. I memorized the docs, nodded like a good mid-level dev… then opened production. Turns out half the services were legacy Mongo, nobody had updated the docs, and my “knowledge” was basically fanfiction. Cue three weeks of confusion, PR rejections, and my senior muttering: “you don’t really get this yet, do you?”

Here’s the brutal truth: memorizing docs ≠ shipping features. If you can’t explain it without Stack Overflow, you don’t know it.

Don’t take just my word for it. Stack Overflow’s Developer Survey shows that most devs rate their ability to “keep up with new technologies” as their biggest career stressor. Not system design interviews. Not debugging prod at 3 AM. Just learning fast enough to not fall behind.

Mini-TLDR: Passive learning feels like progress, but it’s wasted XP. Until you apply it, you haven’t leveled up.

Press enter or click to view image in full size

How memory actually works (RAM vs persistence)

Here’s the thing nobody tells you in tutorial hell: your brain isn’t a database. It’s a sketchy cache layer with terrible eviction policies.

When you cram a new concept, it lives in short-term memory think RAM. Fast, volatile, gone as soon as you context-switch to Slack or TikTok. To actually “store” it, you need to commit it to long-term memory think SSD. That process isn’t automatic.

This is where most devs get wrecked. We assume “I watched it once, I know it.” Nope. That’s like loading a library in memory but never writing it to disk. Restart your brain tomorrow, and poof dependency not found.

The fix? Spaced repetition. It’s basically garbage collection for your neurons. Instead of cramming once, you revisit the same idea at increasing intervals: Day 1, Day 3, Day 7, Day 14. Each time, the recall feels easier, and eventually it sticks.

Tools like Anki and SuperMemo automate this. I used Anki to memorize kubectl commands for Kubernetes. The first week, I blanked every time. After 30 days, I could rattle off 8/10 flags without peeking. Without Anki? I remembered maybe 2. Before/after receipts matter.

Here’s an actual Anki-style flashcard I used:

Q: “What flag lists all Pods across namespaces?”
A: kubectl get pods --all-namespaces

Simple? Yes. But after getting roasted in a standup because I froze on this exact command, the card saved me from ever blanking again.

Mini-TLDR: Your brain is RAM. To persist knowledge, you need spaced repetition. Otherwise, you’re one Slack ping away from memory wipe.

Active learning beats passive (doing > watching)

Watching tutorials feels safe. You sit back, nod along, maybe type a few notes. But here’s the problem: watching ≠ wiring neurons.

It’s like watching an Elden Ring speedrun and convincing yourself you could take down Malenia on your first try. Spoiler: you’re getting one-shot in 12 seconds.

The same goes for dev work. Reading Docker docs doesn’t mean you can actually run a container when it matters. You learn by breaking things, debugging, and fixing. That’s the XP grind.

Here’s my personal scar:

# my first attempt at running Postgres
docker run -d --name postgres postgres:latest

I forgot to map ports. Spent hours wondering why my app couldn’t connect. Fixed version:

docker run -d --name postgres -p 5432:5432 postgres:latest

That mistake? Burned into my brain forever. No tutorial could’ve taught it that effectively.

And it’s not just Docker. I learned more about Kubernetes in one week of debugging a broken deployment than I did from 10 blog posts combined. Painful? Yes. Memorable? Absolutely.

Research backs this too. Active learning studies show students who do instead of passively consume retain significantly more. In dev terms: running broken code teaches you more than watching someone else’s perfect demo.

Mini-TLDR: You don’t learn by osmosis. You learn by shipping broken code, getting roasted by errors, and fixing it until it sticks.

Press enter or click to view image in full size

Feedback loops are OP

Here’s a dirty secret about learning: you don’t get better in isolation. You get better when the world smacks you in the face and says, “this sucks, fix it.” That’s what feedback loops are.

The faster the loop, the faster you learn. It’s basically XP farming for your brain.

  • Pair programming → You write garbage, your buddy calls it out immediately.
  • PR reviews → Every nitpick is a free lesson you’ll never forget.
  • Community forums/Discords → You ask a question, someone drops a spicy answer, you either level up or rage-quit.

One of my biggest growth jumps came from a brutal PR review. I’d written a Python function with four nested if-else chains. My senior left one comment:

“This reads like spaghetti made by a drunk raccoon. Refactor.”

It stung. But after rewriting it three times, I finally understood clean code principles more than any book ever taught me. That comment is permanently tattooed in my dev brain.

And it’s not just anecdotal. GitHub’s own PR review guide frames reviews as learning tools, not gatekeeping. The idea is simple: reviews shrink your feedback loop from weeks to minutes.

Ever learned more from one salty PR comment than 20 hours of Udemy? Yeah, that’s the point.

Mini-TLDR: Feedback isn’t pain. It’s compressed XP. The shorter the loop, the faster you level.

Chunking + deliberate practice

Trying to “learn backend development” all at once is like queueing for a raid boss at level 1 with no gear. You’re going to get flattened.

The trick is chunking breaking big, scary concepts into small, testable skills. Instead of “become a backend dev,” you slice it:

  • Auth → routing → persistence → scaling → monitoring. Each is a mini-boss you can grind separately.

This is where deliberate practice comes in. Not just re-doing what you’re already good at, but deliberately targeting your weak spots until they stop being weak.

My scar story: early on, I leaned on libraries for everything auth-related. JWT middleware? Copy-paste. OAuth flow? Magic black box. The day I had to implement custom auth logic from scratch, I crashed and burned. It took me two painful weeks to rebuild it manually but once I did, I finally understood how tokens, sessions, and refresh flows really worked. Now? I’ll never forget.

This is exactly what Anders Ericsson described in deliberate practice research: expertise comes from pushing beyond comfort, not grinding easy reps.

Dev analogy: it’s like fighting the training dummy in Street Fighter. You can mash buttons and feel busy, or you can deliberately practice one combo until it’s muscle memory. Only the second path helps you win real matches.

Mini-TLDR: Don’t grind easy fights. Chunk the boss into parts. Focus on weak spots until they stick.

Learning in the AI era

AI is the best and worst thing to happen to developer learning. On one hand, it’s like having a senior dev on call 24/7. On the other hand, it’s like that senior dev who just does the work for you you get the feature, but you didn’t actually learn a damn thing.

I’ve been guilty of this. Copilot wrote a gnarly regex for me once. It worked flawlessly. Two weeks later, a bug came up in production. Could I explain what that regex did? Nope. I stared at it like it was ancient hieroglyphics. That’s what I mean by memory atrophy.

Here’s the rule of thumb: AI should be your sparring partner, not your save file. Use it to scaffold, to brainstorm, to debug faster. But if you don’t rebuild the solution yourself, you’ll never internalize it.

I tested this with Cursor. First, I let it generate a boilerplate Express app with auth. Then I closed it and rebuilt the exact same thing from scratch. The first attempt felt shaky. The second time, I could write the middleware from memory. By the third? Locked in. AI sped up the first mile, but I had to walk the rest.

To make this clearer, here’s a decision table I wish I had a year ago:

There are entire threads on Reddit and HN about this exact trap: younger devs over-relying on Copilot, then panicking when asked to explain code in interviews. The verdict is consistent AI is a tool, not your brain.

Mini-TLDR: AI is the sparring partner you need, not the brain you wish you had. Generate → rebuild → retain.

Conclusion learning is the real meta-skill

At the end of the day, it’s not JavaScript fatigue, or Rust borrow-checker pain, or Kubernetes complexity that kills most devs. It’s the fact that we treat learning like Netflix. We binge, we nod, we forget. Then we wonder why we’re stuck at “mid.”

Here’s my take that might sting: most devs don’t fail because they’re dumb they fail because they never learn how to learn.

Frameworks will keep multiplying. AI will keep auto-completing. Docs will keep going stale faster than milk in July. The only skill that compounds over decades isn’t your stack of choice it’s how fast and effectively you can level yourself up.

So here’s the bookmarkable 3-step playbook you can actually use:

  1. Break stuff → fix it (active learning beats passive every time).
  2. Space your reps (RAM isn’t enough commit to persistence with spaced repetition).
  3. Use AI as guide, not brain (sparring partner, not save file).

If you just run this loop on repeat, you’ll survive framework churn, AI disruption, and even those brutal PR reviews that feel like personal attacks.

I’ll close with this: ten years from now, the devs who rise won’t be the ones who memorized every API call, or who leaned on Copilot for every function. It’ll be the ones who mastered the meta-skill of learning how to learn.

What’s the scar that taught you the most? Drop it in the comments. I guarantee someone else will learn from your pain.

Helpful Resources

If you want to dig deeper (and actually apply this stuff instead of letting it rot in another “read later” folder), here are some solid places to start:

Top comments (0)