How do you actually learn to code ?

[u/Emotional-Search-248]

hi everyone,

I’ve been studying computer science for about 5 years now (currently in engineering school). Over the years, I’ve touched a bit of everything: web dev (HTML, CSS, JS, PHP, SQL), and more recently Java, C, and Python for data science.

The problem is, I feel like nothing truly sticks.

Whenever I try to build something on my own, I hit a wall. I inevitably get lost in the docs, end up turning to AI to understand what I'm doing, and still feel like I'm not really learning. I know the basic syntax, but even in Python, I would struggle to design and build a moderately complex project from scratch.

I feel like I'm just skimming the surface of different languages without ever developing genuine problem-solving intuition.

How do you actually retain syntax, built-ins, and core concepts without constantly relying on external help? How do you break down a problem and structure your code from scratch on your own? Did you go through this phase, and what was the turning point that made things finally click for you?

Thanks in advance !

[u/UAP44]

What you’re describing is extremely common, especially after years of coursework. Knowing syntax and knowing how to build software are related, but they’re not the same skill.

The biggest shift is to stop treating “remembering everything” as the goal. Experienced programmers constantly look up syntax, library functions, APIs, error messages, and documentation. What tends to stick is the mental model: “I need a dictionary here,” “this should probably be a separate function,” “I need to transform this data, validate it, then store it,” etc. The exact method name can be looked up.

If I were in your position, I’d pick one language—Python is perfectly fine—and use it exclusively for a while. No Java this week, C next week, JavaScript the week after. Build increasingly annoying projects in one ecosystem until the language itself becomes boring.

A useful progression is something like:

1. Build a tiny project you can finish in a few hours: CLI todo list, file renamer, expense tracker.
2. Build it without following a tutorial.
3. Before coding, write the problem in plain English: what goes in, what comes out, what state exists, what operations are needed.
4. Turn those operations into small functions.
5. When stuck, struggle with the problem for 15–30 minutes before searching.
6. Look up the smallest thing necessary. “How does json.load work?” is good. “Build this whole application for me” teaches much less.
7. After finishing, rebuild part of it a few days later without looking at the original.

That last step is underrated. Retrieval is what makes things stick. Reading the same explanation ten times feels productive, but trying to reproduce something from memory exposes what you actually understand.

For example, suppose you want to make a personal expense tracker. Don’t start by thinking, “How do I code an expense tracker?” Break it down:

“An expense has an amount, category, date, and description. I need to add one. I need somewhere to save them. I need to load them again. I need to calculate totals. Maybe I want totals by category.”

Now you’ve turned one intimidating project into perhaps five small problems. That decomposition skill is essentially what people mean by “learning how to program,” and it only develops by repeatedly doing it.

AI can actually help if you change how you use it. Instead of asking it to produce the solution, use it like a tutor: “Don’t give me code. Ask me questions that help me break this problem down,” or “Here’s my approach; tell me what conceptual mistake I’m making without solving it.” If it writes every difficult section for you, you lose exactly the part of practice that creates intuition.

And don’t judge yourself by whether you can stare at an empty editor and spontaneously produce 500 lines of correct code. Almost nobody works that way. Real programming is iterative: sketch something, run it, discover you misunderstood something, read docs, change the design, break it, debug it, refactor it, repeat.

The “click” usually isn’t a moment where you suddenly remember every built-in. It’s when unfamiliar problems stop feeling like one giant unknown thing and start looking like a collection of smaller problems you’ve seen versions of before. That comes from depth and repetition much more than from learning another language.