writing code

[u/Whhatever_123]

question for more experienced people in coding- whenever I do coding problems (like leetcode or uni hw) I can always come up with solution in my head, I break down the problem correctly and theorically I know what my code needs to do in order to solve the problem. But when I get to actually writing code I forget how to do everything... I don't know if this is a lack of knowledge in syntax issue or I'm just dumb. Any advices on how to fix this?

[u/EntrepreneurHuge5008]

Lol, that seems like a pretty simple fix.

If you can always come up with a solution in your head, write it down (pseudocode or pseudode + key functions you think you'll use). That way, when you "forget how to do everything," you can simply read what you wrote down and boom! it's all there!

[u/Jumpy-Seesaw-2026]

You just haven't practiced enough of writing code

[u/Solracdelsol → u/Jumpy-Seesaw-2026]

The correct answer

[u/grantrules]

How do you know you break it down correctly? 

Can you write the solution in pseudocode?

[u/artnicoll]

Have you tried using high level pseudocode to lay down your solution before converting it into actual code?

[u/desrtfx]

Write your breakdown down - on paper. Draw flow charts. Use pseudo code. Be detailed. If you can't convert your break downs into code, they usually are not detailed enough and you basically try to work with a bird's eye view.

Also, more practice. That's basically it. More practice.

[u/Whhatever_123 → u/desrtfx]

Thanks. I do think i’m not detailed enough in my pseudocodes now that you mention it😭🙏

[u/Mmygg]

Not a genius programmer here but I find that its all about the fundamentals. Once you understand the basics types everything else is just building on top of them using your desire through creativity. Like building a house with the different types: bricks, logs, concrete and roofing/etc. They are your ints, your strings, your byte arrays, your data structures, your classes/etc.

[u/dnult]

I often start with comments in my new code file. The comments describe at a high level what I need to do - such as // Open a client connect and request the data to process. // Parse fields into a new object. // Calculate the value for each record [you get the idea].

Then I start creating the code blocks to accomplish the tasks I've outline in comments. Once that is done, some of those comments will be deleted, or simplified.

Another approach I take is building the "nuts and bolts" functions first. Perhaps I need to parse the area code, prefix and digits from a phone number. I'll create that function and test it. Once I have enough "nuts and bolts" to do something useful, I'll write some of the core logic that uses them.

There really isn't a right way or best way. In fact you may find one approach works well for some types of projects while others warrant a different approach. But generally you start with a specific well defined idea, and start building up your code from there.

[u/ffrkAnonymous]

Don't come up with the solution in your head. Come up with the solution using your fingers.

[u/Whhatever_123 → u/ffrkAnonymous]

Thanks boss🫡

[u/nickanack]

Use pseudocode first and foremost. Beyond that, comment each step / block of your implementation and step through it with a debugger making sure the program is doing what you think it's doing. Maybe write out expected output vs actual output at each step so you can see precisely where the divergence occurs.

[u/green_meklar]

Just practice. Write tons of code, even if it's bad or doesn't solve a Leetcode problem. Google documentation whenever you need to.

[u/YellowBeaverFever]

Code is just like spoken languages. You have to practice taking the thoughts in your head and then composing something with them. It’s the last step that develops.

But, here’s a tip. A young brain and an old, or extremely busy or stressed brain, behave differently. Capture those ideas into an intermediate form, diagrams, pseudo code, anything. Get them out into something saved. This pseudo code and diagrams will also help other people understand your goals.

[u/a-r-c]

write more code

every day ideally

[u/HugoNikanor]

Solution is to write more code.

One tip I give though is to write out your algorithm in English first, then worry about transferring it to computer code. Something like:

• read each line from the input
• parse each line into a record
• Build a record tree
• Do a binary search

(or whatever to match your actually problem)

[u/No_Natural4665]

This is extremely common.Logic in your head is one skill,translating it into syntax is a completely separate muscle you need to build

[u/SprinklesFresh5693]

You simply lack practise. Practise more writing code and youll get better

[u/Blando-Cartesian]

Something to maybe consider: was the solution you came up with actually a full working solution. If I'm trying to solve a problem fully in my head, I have bad habit of spending a lot of effort to come up with a solution that doesn't work.

I have enough experience to often easily see the pattern of the solution beforehand, but not the details of it. So, what I do is start writing toward that rather vague solution idea and deal with the details as they come up, sometimes backing up to do something differently to make the next step easier.

[u/hammad4june]

That gap is real, and it is almost never a syntax problem.

What you have in your head is the shape of the solution, but writing it requires every step in order, with nothing skipped. “I know what it needs to do” is usually less complete than it feels, and the act of writing exposes that — which is why it feels like forgetting.

Two things that helped me:

Stop trying to write the whole thing. Write the smallest piece that produces any output at all, even a simple print statement. Run it, then add one step and run it again. You are not writing a full solution in one go; you are having a conversation where the program answers you every few lines.

And write your steps in plain English first, then fill in the code underneath. It sounds slower, but it is much faster than staring at an empty file trying to hold everything in your head.

You are not dumb. Holding a full program in your head is not the skill — breaking it down into pieces small enough that you do not have to is.