--- title: How to actually learn deeply as a developer | daily.dev description: Lasting developer skill comes from recall, deliberate struggle, and reading real code — rebuild, test, and review to make knowledge stick. canonical: https://daily.dev/blog/how-to-learn-deeply-as-a-developer/ og:type: article og:url: https://daily.dev/blog/how-to-learn-deeply-as-a-developer/ og:title: How to actually learn deeply as a developer | daily.dev og:description: Lasting developer skill comes from recall, deliberate struggle, and reading real code — rebuild, test, and review to make knowledge stick. og:image: https://media.daily.dev/image/upload/s--mrGTRhhr--/f_auto,q_auto/v1/recruiter-landing/6a9a0b07180d85018c31995f_1788483584203_29007eadd5?_a=BAMAMiB80 og:site_name: daily.dev og:locale: en_US article:published_time: 2026-09-04 article:modified_time: 2026-09-04T01:26:33.620Z article:author: Carlos Mendoza twitter:card: summary_large_image twitter:site: @dailydotdev twitter:creator: @dailydotdev twitter:title: How to actually learn deeply as a developer | daily.dev twitter:description: Lasting developer skill comes from recall, deliberate struggle, and reading real code — rebuild, test, and review to make knowledge stick. twitter:image: https://media.daily.dev/image/upload/s--mrGTRhhr--/f_auto,q_auto/v1/recruiter-landing/6a9a0b07180d85018c31995f_1788483584203_29007eadd5?_a=BAMAMiB80 --- **Most people forget more than 50% of new material within 24 hours.** So if I only watch tutorials, read code passively, or let AI fill every gap, I may feel progress without building memory that holds up when I need it. Here’s the short version: if I want to learn code in a way that lasts, I need to **rebuild from memory**, **test my own guesses**, **review over several days**, and **read code written by other people with a clear question in mind**. The point is simple: _stop relying on recognition and start using recall_. What this looks like in practice: - **After a tutorial, I rebuild the main part from memory** - **During daily work, I use a loop: hypothesize → test → reflect** - **I use AI for hints and feedback, not instant answers** - **I do short recall drills instead of one long cram session** - **I trace one path through unfamiliar code** - **I keep a surprise log: what I expected, what happened, and the rule I learned** This article argues that deep learning does not come from more input. It comes from **struggle, recall, correction, and repetition** inside normal coding work. If I can’t rebuild it, explain it, or trace it, I don’t know it yet. ::: @figure {The Developer Deep Learning Loop: 4 Habits That Make Knowledge Stick} ## 1\. Deep learning starts when you stop following and start rebuilding A fast way to check whether you understand something is simple: can you rebuild it on your own? That gap becomes obvious the second you try to remake a tutorial from memory. You thought you had it. Then the screen goes blank, and suddenly you’re not so sure. That’s the fluency illusion. Tutorials mostly teach through recognition. Practice teaches through recall. AI is most useful when it tests your thinking and helps you check your work, not when it does the remembering for you. ### Know the difference between recognizing steps and understanding the system The clearest signs of shallow learning are easy to spot: - You copy a pattern without knowing why it works. - You open a blank editor, hit an error the tutorial never mentioned, and freeze. That doesn’t mean you’re bad at coding. It means recognition is carrying too much of the load, while recall hasn’t kicked in yet. If you cannot rebuild it, you do not yet understand it. Once you see that gap, the next move is to close it with recall right away. ### Rebuild from memory right after a tutorial When the tutorial ends, close it and rebuild the feature from memory before you look anything up. Reach for docs only after you’ve hit a specific point where you’re stuck. The 24-hour window matters. The forgetting curve drops fast, and retrieval practice works best when the material is still fresh but no longer sitting in front of you. That strain of trying to remember is not a problem. It’s the part that helps the knowledge stay with you. And this habit shouldn’t stop with tutorials. The same kind of recall needs to show up in day-to-day work too. ## 2\. Build a deliberate practice loop around real coding work Rebuilding from memory is a strong start. But it only sticks if you turn it into a habit you can repeat. Once you can rebuild something from memory, the next move is to bring that same kind of strain into your day-to-day coding. In plain English: use the work already on your plate as practice. Don't wait for some separate study session that may never happen. ### Pick one skill per session and work just beyond what feels easy Before you begin, write down ONE thing you want to understand. For example: _"Understand how PostgreSQL decides between a sequential scan and an index scan."_ That keeps the session from drifting all over the place. Keep the session short enough that you can stay locked in. Then use immediate feedback to spot gaps fast. That's the line between practice and just getting through tasks. ### Turn bug fixes, refactors, and reviews into practice reps This works inside daily work too. When a bug lands in your queue, don't just patch it and move on. Start with a hypothesis: _why_ does this happen? Then test that idea with the smallest check you can run. It's a small change, but it turns a routine fix into a real mental model workout. Use the same approach with refactors. Instead of rewriting a messy function once, rewrite it two different ways and ask what each version gives up or improves. Log the failure and the rule you learned from it. Code reviews fit the same pattern. Ask why certain design choices were made. These aren't three separate tricks. They're one loop: - Hypothesize - Test - Reflect ### Use AI as a coach, not a shortcut around recall AI helps most after you've tried to solve the problem yourself. Ask for a hint, not the full answer. Once you're done, ask for [360-degree feedback on your code](https://daily.dev/blog/360-degree-feedback-for-developers-complete-guide). That after-the-fact review can catch blind spots you probably wouldn't spot on your own. And when AI explains something, don't paste it straight into your notes. Rewrite it in your own words. The point is still recall, not handing your thinking off to a tool. ## 3\. Use retrieval practice to make knowledge stick Once you’ve rebuilt something from memory, the next step is to **pull it back out again before you check the answer**. That means recalling APIs, logic, and past decisions from memory instead of jumping straight to the docs. A few methods work well for different kinds of material: - **Blank-page recall** for logic - **Free recall** for concepts - **Flashcards** for syntax - **Spaced quizzes** for docs ### Do a blank-page recall after every learning session Start with the hardest kind of recall first. After a learning session, close the docs and write down the steps, APIs, and gotchas from memory before you reopen anything. It’s a simple habit, but it works. When you compare your notes with the source material, the gaps show you exactly what still needs work. ### Space your review over days instead of cramming once If you can pull something from memory once, don’t stop there. Spread that recall over the next few days instead of stuffing it into one long session. Keep each review short. Write the key idea from memory. Or do a small code-based recall task without looking anything up. Repeated recall helps it stay with you. ## 4\. Read code you did not write and note what surprised you Reading code you didn't write builds depth only if you follow the _intent_, not just the syntax. Start with architecture docs. Then move into team code, open source code, or review threads. The easy mistake is to skim, feel familiar with the file, and assume you understand it. You probably don't. Reading unfamiliar code is another retrieval test, not a passive reading task. After reconstruction and recall, the next check is simple: can you read new code without getting lost? > "A 30-minute read of a design document will save you 3 hours of reading source code trying to reconstruct the same understanding from first principles." - Mukul Kadel [\[1\]](https://mukulkadel.com/how-to-do-a-technical-deep-dive/) ### Trace one execution path through unfamiliar code Before you open a single source file, write a one-sentence goal. For example: _How does this API handle authentication?_ That gives you a clear stopping point and keeps you from wandering into unrelated parts of the codebase. Then find the entry point tied to that question, like a route handler, and follow it from start to finish with a debugger, logs, or print statements. On the first pass, pay attention to function names and signatures. Don't get stuck on every line. Check one assumption at a time. If you think a function deletes a record right away, verify it. Code has a way of humbling your first guess. ### Keep a surprise log instead of flat notes Write down the exact thing that surprised you and what you expected instead. Be specific. Maybe it's an API edge case, a lifecycle hook that fires earlier than you thought, or a performance issue tied to a certain data structure. A good surprise log turns into a personal reference built from debugging scars, not a pile of notes you once skimmed. It also makes code review more useful, because surprises in diffs often point straight at weak spots in your mental model. > "A hypothesis that got corrected is understanding that sticks." - Mukul Kadel [\[1\]](https://mukulkadel.com/how-to-do-a-technical-deep-dive/) [daily.dev](https://daily.dev) can help surface reading worth your time, but it only helps if you pair it with reconstruction and notes. ### Treat code review as a learning exercise, not just a quality check Treat code review as a learning rep, not just a quality check. Before opening the diff, set one learning goal for that session. Maybe you want to notice how the author handles errors. Maybe you want to see how they make a design trade-off. That small shift changes how you read. With a clear lens, you start spotting patterns you would've scrolled past. Explaining why a change works is where cracks in your model start to show. And comments that explain the _why_ tell you exactly what you still need to learn. ## Conclusion Deep learning as a developer isn't about consuming more content. It's about what you do **right after** you consume it. The habits that matter most are simple: rebuild from memory after a tutorial, read code you didn't write, and keep a surprise log for the moments that broke your assumptions. This isn't about spending more time studying. It's about repeating the same recall-and-review loop inside your normal work. **Consistency beats intensity.** Turn those habits into a weekly loop: pick one skill, rebuild it, test it, and write down what surprised you. Write correction notes that cover what failed, why it failed, and the smallest rule you can reuse. The best notes don't just record mistakes. They capture failure, cause, and reuse. If the method feels clear, the next step is finding material that's worth practicing on. The companion post [Where do you go to learn beyond tutorials](/blog/where-do-you-go-to-learn-beyond-tutorials) covers exactly that. ## FAQs ### How do I rebuild from memory without getting stuck? Treat getting stuck as a **diagnostic tool**, not a failure. When you hit a mental block, pause and figure out the exact gap. What, specifically, are you missing? Then check the docs or source _only_ to fill that one hole. After that, close them and keep building. That shift matters. It turns recall into something active instead of passive, which helps ideas stick. If you're still stuck, explain the idea in simple terms or write down the exact point where your memory starts to fall apart. ### When should I use AI while learning to code? Use AI to support learning, not to do the work for you. It’s best as a study partner, not a shortcut. Ask it to explain a concept in plain English, point out edge cases you may have missed, quiz you on what you know, or map out dense docs so they’re easier to read. The same idea applies when you build projects. AI can help at the start by shaping an initial spec, and later by reviewing your code with a second set of eyes. But you should still write the code yourself. That’s where the hard-won learning happens. Debugging, getting stuck, testing ideas, and working through problems are the parts that build deep understanding. If AI does those parts for you, you may finish faster, but you’ll learn less. ### What should I write in a surprise log? Write down the surprises you run into while learning or coding. That means the stuff that throws you off a bit: edge cases, default settings that don’t act the way you assumed, and performance behavior that breaks your mental picture of how something works. These notes become a personal reference. More than that, they show you where your understanding stops being solid. Over time, that makes your intuition sharper, because you’re not just recording what worked - you’re tracking where reality pushed back. ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/og-image.png?v=a830cdf1","width":1200,"height":630},"sameAs":["https://twitter.com/dailydotdev","https://www.linkedin.com/company/dailydotdev","https://github.com/dailydotdev","https://www.instagram.com/dailydotdev"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","description":"Free, personalized developer news aggregator. Stay on top of software development news, AI coding tools, and web dev - curated daily from trusted sources.","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}},{"@type":"WebPage","@id":"https://daily.dev/blog/how-to-learn-deeply-as-a-developer/","url":"https://daily.dev/blog/how-to-learn-deeply-as-a-developer/","name":"How to actually learn deeply as a developer | daily.dev","description":"Lasting developer skill comes from recall, deliberate struggle, and reading real code — rebuild, test, and review to make knowledge stick.","inLanguage":"en-US","isPartOf":{"@id":"https://daily.dev/#website"},"timeRequired":"PT9M"},{"@type":"Article","@id":"https://daily.dev/blog/how-to-learn-deeply-as-a-developer/#article","headline":"How to actually learn deeply as a developer","url":"https://daily.dev/blog/how-to-learn-deeply-as-a-developer/","datePublished":"2026-09-04","dateModified":"2026-09-04T01:26:33.620Z","isPartOf":{"@id":"https://daily.dev/#website"},"publisher":{"@id":"https://daily.dev/#organization"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/blog/how-to-learn-deeply-as-a-developer/"},"description":"Lasting developer skill comes from recall, deliberate struggle, and reading real code — rebuild, test, and review to make knowledge stick.","image":{"@type":"ImageObject","url":"https://media.daily.dev/image/upload/s--mrGTRhhr--/f_auto,q_auto/v1/recruiter-landing/6a9a0b07180d85018c31995f_1788483584203_29007eadd5?_a=BAMAMiB80"},"author":{"@type":"Person","name":"Carlos Mendoza"},"timeRequired":"PT9M","potentialAction":{"@type":"ReadAction","target":"https://daily.dev/blog/how-to-learn-deeply-as-a-developer/"}},{"@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://daily.dev/blog/"},{"@type":"ListItem","position":3,"name":"Trends","item":"https://daily.dev/categories/trends/"},{"@type":"ListItem","position":4,"name":"How to actually learn deeply as a developer","item":"https://daily.dev/blog/how-to-learn-deeply-as-a-developer/"}]},{"@type":"FAQPage","@context":"https://schema.org","mainEntity":[{"name":"How do I rebuild from memory without getting stuck?","@type":"Question","acceptedAnswer":{"text":"Treat getting stuck as a \u003cstrong>diagnostic tool\u003c/strong>, not a failure. When you hit a mental block, pause and figure out the exact gap. What, specifically, are you missing? Then check the docs or source \u003cem>only\u003c/em> to fill that one hole. After that, close them and keep building. That shift matters. It turns recall into something active instead of passive, which helps ideas stick. If you're still stuck, explain the idea in simple terms or write down the exact point where your memory starts to fall apart.","@type":"Answer"}},{"name":"When should I use AI while learning to code?","@type":"Question","acceptedAnswer":{"text":"Use AI to support learning, not to do the work for you. It’s best as a study partner, not a shortcut. Ask it to explain a concept in plain English, point out edge cases you may have missed, quiz you on what you know, or map out dense docs so they’re easier to read. The same idea applies when you build projects. AI can help at the start by shaping an initial spec, and later by reviewing your code with a second set of eyes. But you should still write the code yourself. That’s where the hard-won learning happens. Debugging, getting stuck, testing ideas, and working through problems are the parts that build deep understanding. If AI does those parts for you, you may finish faster, but you’ll learn less.","@type":"Answer"}},{"name":"What should I write in a surprise log?","@type":"Question","acceptedAnswer":{"text":"Write down the surprises you run into while learning or coding. That means the stuff that throws you off a bit: edge cases, default settings that don’t act the way you assumed, and performance behavior that breaks your mental picture of how something works. These notes become a personal reference. More than that, they show you where your understanding stops being solid. Over time, that makes your intuition sharper, because you’re not just recording what worked - you’re tracking where reality pushed back.","@type":"Answer"}}]}]} ```