# The Half of Computer Science That Practice Won't Teach You

> Writing enough code takes care of your syntax. The conceptual half of the field quietly decays, and nothing warns you.

Source: https://getmemset.app/blog/memset-for-cs-students  
Published: 2026-09-02

---

The first time someone asked me whether spaced repetition would help them learn to program, I said not really, and I still think that was the right answer.

You do not get fluent in a programming language by reviewing its syntax on a schedule. You get fluent by writing a lot of code and reading much more of it. Syntax arrives as a side effect of use. Nobody who has shipped twenty thousand lines of Python is sitting there trying to recall how a list comprehension is spelled. And nobody who made twenty cards about list comprehensions is any closer to writing those lines.

That answer holds up. It is also incomplete, because programming is the one part of a computer science education that practises itself. Every assignment, every side project, every hour spent chasing a bug is unplanned repetition with instant feedback. The compiler tells you when you are wrong. The tests tell you when you are wrong. You could not avoid the reinforcement if you tried.

The rest of the field gets no such treatment, and that is where I lost the most. It is also why [the app I built](https://getmemset.app) schedules returns to material rather than trying to store the material itself.

![A folded paper map covered in faint contour lines on a pale blue background, with several of its routes lifting off the paper into a constellation of connected dark blue nodes above it](https://getmemset.app/blog/memset-for-cs-students.webp)

## Where practice already wins

I have watched people build four-hundred-card decks for Git commands. Git commands are learned by using Git and being mildly annoyed for a month.

The same goes for language syntax, the standard library, your editor's shortcuts, and the reflexes of debugging. All of it sits inside a loop that already exists: you write something, it breaks, you fix it, you remember. Autocomplete and the type checker act as a running review session you never scheduled. And once you know one C-family language properly, picking up the next one's syntax is roughly a weekend of irritation, not a term of study.

Reviewing this layer is one of the more comfortable ways to feel like you are studying while avoiding the editor. If you are making cards about `map` versus `filter`, close the deck and go write something that needs both.

So far, so uncontroversial. The problem starts with everything on the syllabus that is not a keyboard skill.

## The half that never gets practised

Consistent hashing. Write-ahead logs. Bloom filters. Two-phase commit. Back-pressure. Memory hierarchies, TLB misses, the reasons a database picks one join strategy over another, the difference between an at-least-once and an exactly-once delivery guarantee.

You meet each of these roughly once. One lecture, one chapter, one very good blog post at eleven at night. Then you go back to writing CRUD endpoints for two years.

Code failing is loud. You get a stack trace, a red test, a page full of complaint. A concept you have forgotten does not announce itself at all. **It fails silently**, as an idea that never occurs to you. The cost shows up later, as a design you did not consider or a question you could not start answering. There is no error message that reads "you no longer remember what a write-ahead log is for."

This is the part of the degree that decays, and it decays quietly enough that most students only find out in an interview room.

## System design is mostly a map

System design is the clearest case, and it is where scheduled review changed the most for me.

Strip away the diagram-drawing and what remains is a catalogue: problems that engineers ran into at some scale, and the shapes of the solutions they landed on. Rate limiting. Cache invalidation. Leader election. Idempotency keys. Sharding strategies. The [fallacies of distributed computing](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing), which is literally a list of things that are worth knowing exist.

Most of it you will never implement. I have not personally written a leader election protocol and probably never will. What I do need is to recognise the problem when it turns up in someone else's design doc. I need to know a family of solutions exists, and roughly what each one costs.

> You are rarely asked to have solved these problems. You are asked to know that they were solved, and roughly how.

That is knowledge rather than skill, and the two behave completely differently over time. A skill you exercise weekly stays. Knowledge you touched once in March is gone by August, no matter how clearly you understood it in March.

## Why the map fades

None of this is a discipline problem. It is just how memory works without [spaced repetition](https://getmemset.app/learn/spaced-repetition) or something that does its job.

The timing detail that matters most here is easy to get wrong. In one large study of spacing, [the best gap scaled with how long the material needed to survive](https://doi.org/10.1111/j.1467-9280.2008.02209.x): the longer the horizon, the wider the ideal spacing between reviews. If you want to still know what a Bloom filter buys you a year from now, daily drilling is the wrong shape. Weeks and then months is closer.

The other half of the problem is what students actually do when they decide to review. Asked how they study, [they overwhelmingly reread rather than test themselves](https://doi.org/10.1080/09658210802647009), and they rate rereading as more effective than it is. The computer science version is watching another system design video, or opening the same architecture post you have already read three times, nodding along at every paragraph.

Nodding along is **recognition, not recall**. It feels like competence right up until the moment somebody asks you to produce the thing from an empty whiteboard.

## What the interview is actually asking

Sit through enough technical interviews and the questions in this territory collapse into four shapes.

How would you design something like X. How would your answer change if the constraint were Y instead. What does this term mean. What does this abbreviation stand for, and when does it stop being true, which is what a serious interviewer is really asking when they say [CAP theorem](https://en.wikipedia.org/wiki/CAP_theorem).

Notice that none of these are the exact problem you studied. They are neighbours of it. That distinction has been measured directly: repeated testing [produces better transfer to problems you have not seen before](https://doi.org/10.1037/a0019902) than repeated studying does, and transfer is the entire currency of a design interview.

So the review that works is not "read the notes again." It is closing the notes and trying to produce the answer, badly, from memory, before you look.

## A review session that takes five minutes

The mistake here is thinking that reviewing conceptual material means rebuilding it into cards. For most computer science topics, the material is fine where it already lives. The chapter, the paper, your messy notes from that lecture, the post that finally made consistent hashing click.

What you need is **a pointer, not a card**, plus a prompt you can answer out loud.

My version is three questions per topic. What problem does this solve. What are two ways to solve it. What does each one cost you. I answer from memory, out loud, badly at first, then open the source and see what I missed. The gap between what I produced and what is actually written down is the whole lesson. It is usually specific: I remembered that quorum reads exist and forgot what they do to latency.

That is [retrieval paired with spacing](https://getmemset.app/learn/active-recall-and-spaced-repetition) in its plainest form. Five minutes, no diagrams, no new deck to maintain.

## Spreading a whole field across a calendar

Computer science has more reviewable topics than any single exam ever covers, and this is where these systems usually die. Fifty topics, all set to remind you, all arriving on the same Tuesday. You skip the Tuesday. Then you skip the system.

The fix is pacing rather than motivation. I keep separate categories for system design, algorithms, and databases, each with a small daily cap. Three system design topics a day, not thirty. Anything over the cap rolls forward instead of piling onto the screen and daring me to feel guilty about it.

That single constraint is most of the reason the habit survived my first busy sprint at work. A review plan that ignores how much time you actually have is a review plan you will abandon in the second week.

## Where flashcards still make sense

They do have a place, and it is narrower than most students assume.

Discrete facts are genuinely card-shaped: the complexity of common operations, what a given HTTP status code signals, which syscall does what, the default port for a service you touch twice a year. If that is the bulk of what you need, a conventional deck in [a tool like Anki](https://getmemset.app/compare/memset-vs-anki) will serve you well and I would not try to talk you out of it.

"Design a URL shortener for ten million writes a day" is not card-shaped. It is too large for a card and far too small to justify a course. That middle size, a topic worth revisiting rather than a fact worth memorising, is the awkward unit that most study tools have no answer for.

## What it changes outside the interview room

The interview framing undersells this. The better argument is that a wider map makes you a better engineer on ordinary days.

You reach for a queue because you remember queues exist and what they buy you. You notice, two hours into a design, that you are about to reinvent a worse version of something that already has a name and twenty years of literature behind it. You read someone else's architecture doc and follow it, including the part where they explain why they did not do the obvious thing.

None of that comes from writing more code. It comes from having a broad catalogue of computer science still loaded, months and years after you first read about any of it.

Practice will take care of your syntax. For the rest of the field, something has to bring the topics back around on a schedule that fits an actual week, and that is the job [Memset](https://getmemset.app) was built to do.