Duolingo for programmers

If you search for a Duolingo for programming, you may be looking for a first way into coding, or a way to keep coding knowledge available when work has moved you elsewhere.

For somebody starting from scratch, short guided lessons can make the first steps less intimidating. A course or guided project is usually the better place to learn how to write a program, use a debugger, and turn an empty folder into something that works. Daily drills can support that work later, once there are concepts worth revisiting.

Maybe you used to write React every day and now spend most of your time in planning meetings. Maybe your team moved from Python to TypeScript. Maybe an AI assistant writes the first pass of code, and you catch yourself accepting a callback, a SQL query, or a type definition without being fully sure why it works.

For people who have built things before, the hard part is often keeping the details close enough that you can reason about them when they matter. Duolingo is a useful analogy for that problem, as long as you do not take it too literally.

What transfers from Duolingo

The useful part of the Duolingo model is the expectation that practice happens often, in a small enough unit that you can do it before your day gets away from you. Points and streaks can make returning easier, but they are only reminders.

Programming knowledge has plenty of things worth revisiting in short sessions. Given a small TypeScript function, can you tell which values are narrowed after an if check? Looking at a SQL query, can you predict what a left join preserves? Can you explain why a React effect runs again, or what a Python closure captures?

Those are not trivia questions when they show up in a review, a production issue, or a conversation where someone proposes a shortcut. They are pieces of working knowledge. You want the answer to come back quickly enough that you can inspect the code in front of you instead of vaguely remembering that you learned this once.

Short daily sessions can remove the setup cost. A 5 minute practice session is easier to start than opening an old tutorial, creating a side project, and deciding what to build. You can fit a few questions between meetings or do them while waiting for a build.

Spaced repetition also transfers well. Research on distributed practice found that returning to material after a gap can improve later retention compared with massing the same practice together. Cepeda and colleagues reviewed the evidence across many studies. If you remember a concept easily, it can wait longer. If you hesitate on JavaScript event loop behavior every time it comes up, that topic should return sooner.

Streaks are useful too, with one caveat. They are a reminder to return, not proof that you learned something. A streak built from tapping through answers is empty. A streak built from retrieving an answer, making a mistake, reading the explanation, and seeing that idea again later has more value.

Where the analogy breaks

Programming is not vocabulary. You cannot become capable of designing a payment system, debugging a distributed job queue, or maintaining a large frontend by completing isolated drills alone.

Real software work includes reading unfamiliar code, deciding which problem is worth solving, tracing behavior across files, dealing with unclear requirements, and changing a system without breaking the parts you did not touch. Those skills need projects, teammates, production mistakes, code review, and time spent in a real codebase.

A daily drill also cannot tell you if your architecture is appropriate for a product that has grown in strange directions over three years. It cannot replace learning a library deeply enough to use it well. And it cannot give a beginner the satisfaction of making something useful from a blank folder.

What drills can maintain is more specific. They give you repeated chances to trace a promise chain, predict a query result, identify a mutation bug, or explain why a type narrows. Building software is where you combine those moves with product context, incomplete information, and the judgment that comes from seeing consequences.

What drilling can actually give you

The honest scope is narrower than “learn to code.” Drills are good at active recall, quick diagnosis, and recognizing patterns you have seen before.

Say you used Redux a few years ago and now work mostly in backend services. A short question about immutable updates will not make you current on every React tool released since then. It can keep the mental model warm enough that you are not starting from zero when you return to a frontend task.

Or say AI produces a plausible looking database migration. You still need enough SQL knowledge to spot an accidental full table update, a missing index, or a migration that fails when existing rows contain nulls. The tool can write the syntax. You are responsible for knowing what the syntax means in context.

This is useful when coding happens less often. A senior developer who spends the week reviewing designs and unblocking teams may want a small place to make code level decisions regularly. A developer moving between Go and React can use drills to revisit concepts from the stack that is no longer part of the day job.

Reading an answer can feel familiar even when producing it unaided is difficult. Retrieval practice is a better check of what you can bring back without the answer in front of you, a result supported by Karpicke and Roediger's study of repeated retrieval. A short prompt cannot prove mastery, but it can expose a gap worth following up.

What a useful daily session looks like

A good programming drill should ask for thought, but not require an hour of setup. It might show a small code sample and ask what runs first. It might ask you to repair a type error, choose the query result, or explain why a test passes locally and fails in CI.

The prompt needs enough context to resemble a real decision. “What is a closure?” is weak for someone who has been shipping software for years. Consider this instead:

function makeRequest(userId: string) {
  return () => fetch(`/api/users/${userId}`);
}

const request = makeRequest("u_42");

If request() runs after makeRequest has returned, what value does the callback use for userId, and why? The code tells you where the value came from and that it is not reassigned. That gives you enough information to reason about a real decision.

The answer should explain the reasoning, including why a tempting wrong answer is wrong. Otherwise the session becomes a memory game about wording.

The session should also stay short. A five minute slot keeps the scope honest. Use it for a bounded question you have seen before, then save a rabbit hole about framework internals for a longer study block or a small experiment. Learning a new subsystem properly usually needs more time and a place to try it.

Who benefits most

Daily practice is especially useful when your work no longer gives you steady reps.

Senior developers often lose touch with details because their role changes. They review designs, unblock teams, talk to customers, and make decisions across several systems. That experience is valuable. A short practice session can give them a low effort way to revisit a reducer, a promise chain, or a database constraint that has not appeared in recent work.

Framework hoppers have a related problem. You may still know Java, but your current job is Go. You may have spent two years in Vue and now work in React. You do not need to maintain expert level depth in every stack forever. Still, keeping the old stack warm makes future switches less expensive and lets you see connections between tools instead of relearning every idea from scratch.

If you are actively building a serious project, project work should take most of your learning time. Use drills as a small supplement. If you have not coded much recently, start with a daily prompt for a week or two, then add a deliberately small build task: fix an old project, reproduce a bug, or make one feature in the stack you want to return to. The drills lower the friction of restarting. The project work is where you find what still needs attention.

Where Unrot fits

Unrot is built around that narrow, useful job: keep your programming fundamentals available through a few minutes of deliberate practice each day.

You pick a stack, answer short questions, and return to ideas that need another rep. Unrot is not a curriculum race or a giant badge shelf. It gives you a regular chance to notice when a familiar concept has become fuzzy, then practice it before you avoid that part of the codebase.

You can try Unrot with a short session, or look through the available tracks if you want to keep a previous stack warm alongside the one you use at work.

A Duolingo for programmers makes sense when it respects the boundary. It can help you remember how the pieces work. It cannot build the software for you, and it should not pretend to. The useful result is simpler: when you open a codebase, you still have enough of the language and fundamentals in your head to think clearly about what you are changing.