Learning to code can turn into a strange loop: watch a tutorial, understand the example, open an editor—and suddenly have no idea where to start.
I’m building licode (https://licode.site) to make the “open an editor and try” part more inviting.
It combines programming lessons, coding challenges, debugging projects, and multiplayer coding battles inside a pixel-art world. The idea is simple: make practice enjoyable while keeping the actual work—writing, testing, and understanding code—at the center.
From reading code to writing it
The learning flow starts with small lessons and exercises.
You read an explanation, try some code, and check what happens. Then you move into practice problems with function templates and test cases.
For example, an early Python problem might start with:
class Solution:
def helloAdventurer(self) -> str:
The task explains what the function should return. The platform handles calling it and checking the result.
That separation matters for beginners: you can concentrate on the concept you’re learning without also figuring out an input parser.
Debugging should involve existing code
Writing a solution from scratch is useful. But working on software also means opening somebody else’s code and asking:
- Where does this value come from?
- Which file owns this behavior?
- What changed between the expected and actual result?
- Can I reproduce the failure with a smaller input?
That’s why licode includes debugging investigations.
Early exercises stay small. More advanced investigations introduce linked files and folders, so you can follow a request through different parts of a program.
The workflow is:
- Run the existing code.
- Compare the result with its contract.
- Find the smallest input that exposes the bug.
- Trace the responsible logic.
- Make a repair and run the tests again.
I want the reward to come from understanding why the fix works—not just getting a green checkmark.
A coding game still needs meaningful practice
licode has a retro interface, progression, and a multiplayer arena. But a game mechanic is only useful here if it encourages a useful learning behavior.
A timed coding battle can give you a reason to practise something you already know. A debugging investigation can encourage patience and careful observation. A small exercise can make it easier to return tomorrow.
My preferred progression is:
Learn a concept → practise it → debug it → try it under pressure.
You don’t need to start with the competitive part.
An AI tutor that leaves the coding to you
The built-in tutor, Lio, is designed to explain the task, discuss errors, and suggest a small next step.
Its instructions discourage complete solutions. Instead, it can offer an empty template, a little syntax, or a tiny example from a different problem.
The intention is to help you continue working without turning every difficult moment into another long tutorial—or an answer to copy.
Where this fits alongside other practice tools
If you use LeetCode or another programming-practice platform, licode offers a different format to explore: lessons, debugging, projects, and coding battles in a game-like environment.
It’s an independent product, and it isn’t affiliated with LeetCode.
I’m still building and refining it, especially the difficulty progression and the experience of moving from a tiny exercise to a larger codebase.
Try it and tell me where you get stuck
You can explore licode here (https://licode.site).
I’d particularly like feedback on these questions:
- Does the first exercise feel approachable?
- Do the test results help you understand a mistake?
- Would you rather practise through debugging projects or timed battles?
- Which part of learning to code makes you lose momentum?
If you try it, tell me one thing that helped—and one thing that felt confusing. That feedback will help shape what I build next.
Top comments (1)
The debugging investigations stood out to me more than the battles. Working through existing code and asking where a value comes from and which file owns a behavior feels much closer to real work than writing a fresh solution. I also like that Lio is set up to suggest a small next step instead of handing over a complete answer. If I had to choose between your two options, I would start with debugging projects, since the five step workflow you describe gives a clear way to practice tracing a bug. How are you deciding when an investigation is hard enough to stretch someone without leaving them stuck?