Here's the uncomfortable truth: computer science is the one subject where both ways most students study will fail you.
Memorize like it's history? You'll recite Big-O complexities and language syntax all day and still freeze when an exam asks you to actually write a function. Grind LeetCode like it's a video game? You'll solve 300 problems, forget how half of them worked by next month, and still bomb the theory section. CS punishes pure memorization and pure repetition equally, and almost every "how to study computer science" guide online treats it as one or the other.
So let's fix that. CS has a dual structure: a layer you need to remember (syntax, terminology, complexity, data-structure properties) and a layer you need to build (problem-solving, implementation, debugging). The trick is using the right tool for each layer. This guide gives you a science-backed dual-track system for studying computer science, whether you're a CS major, a self-taught programmer, or prepping for a coding exam.
"The only way to learn a new programming language is by writing programs in it."
— Brian Kernighan and Dennis Ritchie, The C Programming Language
Why Is Computer Science So Hard to Study?
Computer science is hard mainly because it's cumulative and constructive: every concept depends on fully understanding the ones before it. Miss how pointers work, and linked lists make no sense. Skip recursion, and trees and graphs become impossible. Small gaps don't stay small. They compound into a wall.
On top of that, CS blends three demanding things at once: programming (a skill), math (discrete math, logic, sometimes calculus and statistics), and brutal attention to detail where one misplaced character breaks an entire program. That combination is why so many students who "studied for hours" still struggle.
But here's the part that matters most: difficulty in CS is not a sign you "aren't a programming person." That myth has done real damage, and we'll bust it later in this post. The difficulty is structural, which means it responds to structure. Study the right way and the wall becomes a staircase.
Computer science isn't unusually hard because it's abstract. It's hard because it stacks. Each topic sits on the one below it, so the way you study has to lock each layer in before you climb to the next.
The Two Layers of Computer Science
This is the idea the rest of the post is built on. Almost everything you study in CS falls into one of two layers, and each layer needs a completely different study method.
| Layer | What it includes | How your brain treats it | Best study method |
|---|---|---|---|
| Declarative (knowing that) | Syntax, keywords, terminology, Big-O complexities, data-structure properties, API names, definitions | Facts to retrieve | Active recall + spaced repetition + flashcards |
| Procedural (knowing how) | Writing code, implementing algorithms, debugging, recognizing problem patterns | Skills to build | Deliberate practice + worked examples + self-explanation |
Declarative knowledge is the stuff you either know or you don't. What does O(n log n) mean? What's the worst-case lookup time for a hash table? What keyword declares a constant in your language? These are facts. Facts are best burned in with retrieval practice: testing yourself, not re-reading.
Procedural knowledge is different. You can't flashcard your way to writing a clean binary search. That's a skill, and skills are built by doing the thing, failing, and adjusting. This is where deliberate practice and worked examples come in.
The reason generic study advice fails for CS is that it optimizes only one layer. "Make flashcards" handles the declarative layer and ignores the skill. "Just build projects" handles the skill and lets the theory rot. You need both tracks running at once.
Try this now: Open your current CS topic and split it into two columns on a page. Left column: every fact you'd need to recall on a closed-book exam (definitions, complexities, syntax). Right column: every thing you'd need to actually do (implement X, debug Y, trace Z). That split tells you exactly which study method each piece needs.
The Science: Why Generic Study Advice Fails for CS
Both tracks are backed by decades of cognitive science. Knowing why they work makes you far more likely to stick with them when they feel harder than re-reading.
The declarative track runs on retrieval and spacing
The single most reliable finding in learning science is the testing effect: retrieving information from memory strengthens it far more than reviewing it. In a classic study, students who tested themselves recalled about 80% of material a week later, versus about 36% for students who just re-read (Karpicke and Roediger, 2008). For CS terminology and complexity facts, that gap is the difference between a B and an A.
Pair that with the spacing effect. A synthesis of 184 studies found that spreading study sessions out beats cramming them together almost every time, with an average recall gain around 15% (Cepeda et al., 2006). Reviewing your Big-O flashcards over five short sessions across two weeks beats one long cram by a wide margin.
The procedural track runs on deliberate practice and worked examples
Skill is different. Research on expert performance shows that what separates strong performers is largely deliberate practice: focused, effortful work on the specific things you can't yet do, with feedback (Ericsson, Krampe, and Tesch-Römer, 1993). Mindlessly re-solving problems you already know how to solve doesn't count. Targeting the exact algorithm that trips you up does.
And before you grind problems, study worked examples. Sweller and Cooper (1985) found that learners who studied fully worked-out solutions solved later problems in about half the time and with roughly one-fifth the errors of those who just attacked problems unaided. For DSA, this means reading and tracing a clean implementation of, say, quicksort before trying to write your own, instead of staring at a blank editor.
Finally, self-explanation supercharges both. Chi et al. (1989) found students who paused to explain each step of a worked example to themselves learned far more deeply. This is the science behind "rubber-duck debugging": explaining your code line by line, out loud, to an inanimate object until you find the flaw.
| Study method | Retention / skill gain | Best for which layer |
|---|---|---|
| Re-reading notes / textbook | ~36% recall after 1 week | Neither (lowest utility) |
| Highlighting / summarizing | Low utility | Neither |
| Flashcards + active recall | ~80% recall after 1 week | Declarative |
| Spaced repetition | +~15% over cramming | Declarative |
| Worked examples | ~50% faster, ~80% fewer errors | Procedural |
| Deliberate practice | Strongest predictor of skill | Procedural |
Data synthesized from Karpicke and Roediger (2008) "The Critical Importance of Retrieval for Learning," Cepeda et al. (2006) "Distributed Practice in Verbal Recall Tasks," Sweller and Cooper (1985) "The Use of Worked Examples," and Ericsson et al. (1993) "The Role of Deliberate Practice."
How to Study Computer Science: An 8-Step Dual-Track System
Here's the workflow. Steps that build the declarative layer use memory science. Steps that build the procedural layer use practice science. Run them together.
Because CS is cumulative, the order you learn things in matters more than in any other subject. Lock in the basics (variables, control flow, functions, pointers or references, recursion) before data structures, and data structures before algorithms. If a new topic feels impossible, the real problem is usually a shaky layer underneath it. Go back and patch the gap before pushing forward.
Every definition, complexity, and bit of syntax goes onto a flashcard the day you meet it. Big-O of common operations, the difference between a stack and a queue, language keywords, the properties of a balanced tree. Use active recall by always trying to answer before flipping the card. This is the declarative track, and flashcards are its engine.
Don't open a blank editor and suffer. First read a clean, correct implementation of the algorithm and trace it by hand with a sample input. Watch the variables change at every line. Only after you understand the worked example should you close it and rebuild it yourself. This cuts your error rate dramatically and stops you from "practicing" wrong patterns.
This is the heart of the procedural track. You don't know an algorithm until you can write it from scratch. Re-implement data structures and core algorithms without looking. For exam prep, write code on paper, because it forces you to hold the logic in your head instead of leaning on autocomplete. This is deliberate practice: aim at the specific thing you can't do yet.
After implementing something, explain how it works in plain English to a friend, a rubber duck, or an empty room. If you stumble, you've found a gap. This is the Feynman Technique applied to code: if you can't explain why your recursion terminates without jargon, you don't fully understand it yet.
Don't do 20 array problems in a row. Mix arrays, trees, and graphs in the same session. Interleaving forces your brain to first figure out which approach a problem needs, which is the actual skill an exam tests (Rohrer and Taylor, 2007). It feels harder and slower. That difficulty is the point.
Once a week, simulate the exam: closed notes, a timer, problems you haven't seen. A practice quiz on theory plus two or three timed coding problems will expose exactly what's still weak. Retrieval under pressure is the closest thing to the real test, and it builds calm alongside competence.
CS knowledge decays fast if you touch it once. Review each topic again after a day, then a few days, then a week, then a month. Spaced repetition handles the scheduling for you so last month's pointers are still sharp when this month's graphs depend on them.
Try this now: Pick one algorithm you "kind of" know (binary search is perfect). Close everything. Write it from scratch, by hand, on paper. Then trace it with the input [1, 3, 5, 7, 9] searching for 7. Where did you hesitate or get an off-by-one error? That hesitation is your real gap, and now you know exactly what to drill.
Watch: How to Study CS in Action
Reading about study methods helps. Watching how strong learners actually apply them sticks better. These two videos cover both tracks.
How to Learn to Code, by CS Dojo
CS Dojo (ex-Google) on how to actually learn to code
YK, a former Google software engineer, walks through choosing resources and projects so your procedural practice has direction instead of being random LeetCode grinding. Key insight: build projects that force you to apply concepts, because applying a concept is what cements the skill.
How to Study for Exams: Evidence-Based Revision, by Ali Abdaal
Ali Abdaal on active recall and spaced repetition
Ali Abdaal breaks down the exact memory science behind the declarative track of this guide. Key insight: active recall and spaced repetition beat re-reading for any fact-heavy material, and CS theory is exactly that.
A Practical Example: Studying Big-O Notation
Let's make the dual-track idea concrete with something every CS student wrestles with: time complexity.
The difference is everything. Attempt 1 collapses the moment the question is unfamiliar. Attempt 2 transfers to anything they throw at you.
How to Study for a Coding Exam
Coding exams reward understanding, not recall of specific solutions. To prepare: practice writing code by hand on paper so you rely on logic instead of an IDE, break each problem into small chunks and solve them one at a time, and internalize common patterns like sorting, searching, and traversal rather than memorizing whole solutions.
A week out, switch into retrieval mode entirely. Stop reading and start testing. Do timed problems closed-book, then review only the ones you missed. The night before, sleep instead of cramming, because sleep consolidates the patterns you practiced into long-term memory.
The most common coding-exam mistake is "studying" by re-reading old solutions until they feel familiar. Familiarity is not the same as the ability to produce code from scratch. The fix: close the solution and rebuild it from a blank page. If you can't, you haven't studied it yet.
How to Study Data Structures and Algorithms
DSA is where the dual-track approach pays off most. The best way to study data structures and algorithms is to implement them yourself, then recognize their patterns, not to memorize solutions.
Start by coding each structure and algorithm from scratch at least once: arrays, linked lists, stacks, queues, hash tables, trees, graphs, and the core sorts and searches. Then shift to pattern recognition. Most interview and exam problems are variations on a handful of patterns: sliding window, two pointers, binary search, depth-first and breadth-first search, dynamic programming. Solve fewer problems but understand each one fully, and tag it with the pattern it uses.
Solve 50 problems deeply, not 500 shallowly. A curated set you understand cold beats hundreds you half-remember. Depth on patterns transfers; volume on specifics doesn't.
Then space your review of those patterns and re-derive the tricky ones from memory. A graph problem you solved last month should still be reachable today, and spacing is what keeps it there.
Quick Reference: Match the CS Material to the Method
| What you're studying | Layer | Use this method |
|---|---|---|
| Syntax, keywords, language APIs | Declarative | Flashcards + spaced repetition |
| Big-O complexities, data-structure properties | Declarative | Flashcards + cloze cards |
| Definitions, theory, terminology | Declarative | Active recall + self-quiz |
| Implementing an algorithm | Procedural | Worked example, then code it yourself |
| Debugging | Procedural | Rubber-duck / self-explanation |
| Recognizing problem patterns (DSA) | Procedural | Interleaved deliberate practice |
| Whole-topic mastery before an exam | Both | Timed self-test, closed book |
Common Mistakes (And How to Avoid Them)
Mistake 1: Treating CS like a memorization subject
Flashcarding your way through an algorithms course feels productive, but you can't memorize problem-solving. The fix: flashcard the facts, but spend the majority of your time implementing and solving. Roughly a 30/70 split between recall and hands-on coding works well for most CS courses.
Mistake 2: Grinding problems with no theory base
Solving 300 problems while skipping the why means you pattern-match without understanding, and you collapse on anything unfamiliar. The fix: for every problem, write one sentence on the pattern it used and why. That single sentence turns blind grinding into deliberate practice.
Mistake 3: Copy-pasting code instead of typing it
Copying a solution that runs gives you the illusion you understand it. The fix: type every line yourself, and better yet, close the source and rebuild it. The act of producing the code is what builds the skill.
Mistake 4: Believing you're "not a programming person"
This one deserves a callout. In 2006 a working paper ("The Camel Has Two Humps") suggested a simple test could split people into those who can program and those who can't. It spread widely. The problem? It was never peer-reviewed, and in 2014 its own author, Richard Bornat, formally retracted it, writing that no programming-aptitude test had actually been found. The fix: treat programming as a trainable dual skill, because that's what the evidence supports. Struggling early means you're learning, not that you lack some innate gene.
Programming aptitude is not innate or bimodal. The most-cited claim that it was got retracted by its own author. Difficulty in CS is a signal to adjust your method, never proof you can't do it.
The Research Behind It
The dual-track system isn't opinion. It's built on cognitive science and CS-education research:
- Testing Effect (Karpicke and Roediger, 2008): Self-testing produced ~80% recall after a week versus ~36% for re-reading, making active recall the backbone of the declarative track.
- Spacing Effect (Cepeda et al., 2006): A synthesis of 184 studies found distributed practice reliably beats massed practice, with an average ~15% recall gain.
- Deliberate Practice (Ericsson, Krampe, and Tesch-Römer, 1993): Expert skill is driven by focused, effortful practice on weaknesses, not by passive repetition or raw talent alone.
- Worked-Example Effect (Sweller and Cooper, 1985): Studying worked solutions cut solving time roughly in half and errors to about one-fifth versus unguided problem-solving.
- Self-Explanation Effect (Chi et al., 1989): Students who explained each step of a worked example to themselves learned significantly more deeply (the science behind rubber-duck debugging).
- Interleaving (Rohrer and Taylor, 2007): Mixing problem types produced much stronger delayed-test performance than practicing one type at a time.
How Notesmakr Helps You Study Computer Science
Notesmakr is an AI-powered notes maker that turns your CS lecture notes, textbooks, and PDFs into the exact tools each layer of this system needs. The declarative track gets the most direct help.
For free, you can build manual flashcards and cloze (fill-in-the-blank) cards for syntax, Big-O complexities, and definitions, then review them on a built-in SM-2 spaced repetition schedule so nothing rots between topics. The cloze cards use Diminishing Cues (progressive letter hints based on your progress), which research links to better retention, useful for drilling exact syntax and complexity terms. Already have an Anki deck of CS terms? You can import .apkg files for free too.
On the Scholar plan, the AI features kick in: upload a lecture PDF or chapter and Notesmakr can generate flashcards from it automatically, build an AI quiz to test yourself under exam conditions, and simplify dense theory into plain language using the Feynman Technique. (The free plan includes AI generation for up to 5 notes so you can try it.)
A quick honest note: Notesmakr is a great note maker and retention layer for the declarative side of CS. It won't write code for you or replace an IDE. The procedural track, the actual coding, is still on you, and that's exactly as it should be. No app builds the skill except practice. For the broader memory toolkit, see our guide to AI flashcards and how to memorize things fast.
Start Today
You don't need a new app or a perfect plan to start. You need to run both tracks this week:
- Split your current topic into declarative facts and procedural skills (the two-column exercise).
- Make flashcards for every fact today, and review them with active recall, not re-reading.
- Study one worked example of an algorithm you find hard, then rebuild it from a blank page.
- Explain it out loud to a rubber duck. Note where you stumble.
- Interleave your next practice session: mix three problem types instead of grinding one.
- Schedule a closed-book self-test for the end of the week, and space your reviews from here on.
CS rewards the students who build the skill and remember the facts. Do both, in the right way, and the wall becomes a staircase. For more subject-specific systems, see how to study math and how to study physics, which share the same problem-solving DNA.
"The only way to learn a new programming language is by writing programs in it."
— Brian Kernighan and Dennis Ritchie, The C Programming Language
Frequently Asked Questions
Is computer science hard to study?
Computer science is challenging because it's cumulative: each topic builds on mastering the previous one, and it blends programming, math, and intense attention to detail. It's hard but learnable. With consistent practice, active recall for theory, and deliberate practice for coding, most motivated students master every concept they meet.
How many hours should I study computer science?
Aim for 2 to 4 focused hours daily rather than long passive cramming sessions. Quality beats quantity: short, deliberate practice using active recall and spaced repetition outperforms marathons. Most CS students need 15 to 20 hours weekly outside class, split between coding practice, reviewing concepts, and finishing assignments early.
Can I study computer science on my own?
Yes. Start by learning to program, then add core topics like data structures, algorithms, and discrete math through free courses and tutorials. Build small projects to apply concepts, practice consistently, and use spaced repetition to retain foundational knowledge over time. Self-study works well if you stay structured and test yourself.
What is the best way to study data structures and algorithms?
Implement each data structure and algorithm yourself instead of memorizing them. Solve fewer problems but understand each fully, then recognize recurring patterns like sliding window, binary search, and depth-first search. Practice consistently, analyze trade-offs, and revisit problems using spaced repetition so the patterns stay reachable long-term.
How do I memorize code for an exam?
Don't memorize code line by line. Understand the concepts and patterns behind it. Type code instead of copy-pasting, draw diagrams of how data flows, and practice variations of the same problem to internalize the structure. Use spaced repetition to revisit key snippets daily, then weekly, until recall becomes automatic.