this post was submitted on 15 Jul 2026
21 points (95.7% liked)
Programming
27709 readers
474 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Hard to say without knowing more about the problem. I mean, what went wrong with the code you copied from the book. Could be a simple typo, and example code sometimes also has typos or is just wrong - surprisingly, authors sometimes confidently type in code exampoles without running them. Carefully comparing the code you entered with the code in the book might reveal the problem.
It was not wrong - I literally could not remember what and in what order I had to write, although I did remember most of the general concepts introduced in the program.
The original code worked fine when I was simply rewriting it looking in the book
Next time you can try writing the steps down in plain English first, just to get a feel of the program's flow. If you're comfortable with that and it's just the syntax you don't remember, don't worry, you can always look up commands. After some practice it'll become much easier writing the commands from the beginning.
Absolutely!
This is called “pseudo code” and can help you streamline your thoughts. You can make it more and more rigorous and then swap the english with the programming language of your choosing
Programming is mostly understanding something abstract in your mind not rote memorization.
Even for a very simple program, focus on understanding what it does and how it does it, and why, step by step. Write things down when you learn something new.
Reading and understanding code, especially good code, will make you a good programmer. Just writing a ton of shit code will not. Trust me, I've done this for 3 decades and learn something new almost every day from reading other people's code.
So, focus on understanding what it does, and you will be able to modify and build programs from scratch soon.
Yeah, this is just a skill issue that is solvable with practice. You need to develop a proper intuition on what is actually happening both at the algorithm abstraction level, and the language level so you can express a solution fluently. If you have not studied a lot it is difficult to internalize what tools are in your toolbox that would help you. This includes patterns, abstractions, language features, libraries, and more. The only thing that fixes this is practice reaching for those tools until they feel natural. Keep practicing with the book reference because that is closer to reality than not. But at a certain point you should be able cogently write simple programs from scratch without referencing materials in at least one language.
Memorization is just repetition, and you can build successes and reinforce it for yourself by keeping things very, very small. If even a "simple number guessing game" is too complicated for you to remember at this point, that's not a mark of shame, it might sound simple but one of most important things you can learn as a programmer is that a lot of things that seem or feel simple really aren't. There's sometimes a lot of hidden complexity, and your brain needs to form the internal tools it needs to unpack and untangle that complexity. Eventually you'll develop the skills you need to see the specific issues making it more complex, but for now, all you can do is simplify. If there's a part you're not remembering how to do, discard it. Make it a sidequest. Iterate on one feature at a time, test it and see if it works the way you expect. Refine, and you'll learn a little bit from each refinement. Keep doing little refinements and you'll start learning stuff more permanently. It's like any skill, you have to practice.
If you read through a foreign language dictionary page by page, of course you're not going to remember all the words. It's huge. It's overwhelming. Our brains can't learn that much in a single pass. It's all about doing little bits at a time. The absolute minimum required to get off the ground. Gradually, not overnight, you'll learn it all.
There's a reason the stereotypical "first program" is:
print("Hello world")
It's actually a good starting point. It's all you need to get started, plus the workflow you need to compile/run it, which shouldn't be changing a lot once you've got it established. Other than that, you can build tiny baby steps on top of that. How do you print "Hello again" after "Hello world"? Does it print on the same line or does it print on the next line? Try it out and find out. Learn what it does. Play with it. What's next? How do you let the user type something? Maybe you need to look for some examples. Try them. Not just the first one that works, try them all. See if they do anything differently. Don't copy and paste huge complicated messes of code blocks if you don't understand them, because you're getting back into the "reading the dictionary" problem, but a line here or there is something you can start to pick apart and understand what it's doing as you go. Use your programs to explore and understand what the program is doing, not to create a "finished product". Nothing's ever really "finished" except by accident when at some point in the distant future you realize you haven't needed to modify it in ages. Otherwise, programs are things you change as you go, and you learn something each time you change them.