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
Follow the wormhole through a path of communities !webdev@programming.dev
Repetition is key here. And solving problems.
I started many years ago with a "for beginners" book, and didn't fully understand a lot of it by the end.
So I started trying to build something, and searched for answers to the things I couldn't figure out (and went back to the book numerous times). I don't think I ever finished that project, but by persisting through it, and figuring out how to solve the problems that I ran into, I learned how to build something, and it stuck.
Yeah. Building something and solving your gaps yourself is much better for learning than following a walkthrough.
A walkthrough can be effective onboarding if you're already familiar with the concepts. Otherwise, it takes the right kind of learning mindset to effectively take away results; not just following along, but internalizing the concepts and constructs.
For beginners, both the language and the concepts are new. Repetition/Multiple occasions help with internalizing.
Problem solving, from simple to hard. I did a lot of stuff on Codewars, and moved from trivial stuff to more complex in course of a few months. It's not like I got really far, but for me it's motivation problem, not a method problem
Generally speaking, programming languages are like spoken languages, in that as a learner you're unlikely to be able to memorize and reproduce long passages without extensive practice, and should instead focus on learning to say what you mean, rather than practicing set dialogues.
Its a true language, you dont hand an illiterate kid shakespear and tell them to have at it, you start them with basic books, even guided readings, and have them read out loud, and then they advance through more complicated books until they get the hang of things and start making their own essays, they continue the process of moving from simpler to more complex books/code-projects until one day the developer becomes minted when they have an idea of their own and they realize they have the vocabulary and strong enough opinions already formed to just make the idea their own - and then the learning is self sustaining.
Dont put the cart before the horse, shovel the shit for a while until you figure out where it lands - theres no workaround to gaining experience - just got to experience it
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.
It sort of depends on what you mean by can't reproduce without looking at hints.
Like, even now if you asked me to write a number guessing game in a language I've had to use a lot (Java) I couldn't do it straight from memory. I haven't needed to read stdin manually for a long time so I'd have to look at the class and docs to see the best way to pull in a line and parse it into a number, I don't remember the specifics of the Random class either, so I'd need to double check the methods available and if they produce inclusive or exclusive ranges.
To me that's normal; I understand the program flow and what needs to be accomplished, but the specific classes and methods are something I don't keep with detail in my head, using the docs and keeping the language reference handy is normal, in my experience.
You'll get there. If you're struggling to remember what to do and in what order... I'd say keep things simple. Re-visit the needed concepts. In case of a number guessing game, that'll probably be conditions, loops, input and output, storing numbers. Make sure you understand each if those individually.
First, write a program which just echoes the input. You could write a separate program which just has two fixed numbers and compares them. You can then extend it to also read one of the numbers from user input. And you're half-way there.
Also make sure you can do those simple things half a day later, without the textbook opened.
I'd tackle the loops seperately (if that's contained in this example). Get comfortable with them. Start with a program that just counts from 0 to 99 and outputs all the numbers. You can then combine that with other concepts, like output "tomato" if a number is divisible by 6. Or if it's less than, greater than or equal something.
And if you don't get the loops... Just tell the user they have 10 tries and copy-paste your code ten times. That'll do it as well. And you can work your way up from there.
I think once you have a grasp of what all these things do, and you did a few super simple things with them on your own, it'll be more clear what to do with more complex things. In this case probably: loop. And inside of that loop, ask for a number, compare it to the secret number, and decide what to output on a condition. That's roughly an average number guessing game. I think you just need to tinker a bit more with each of the 5 concepts that get combined here.
Instead of starting from the code, start from the problem you're trying to solve. You want a program that guesses numbers randomly in a loop? you need a way to make a random numbers and a way to make loops, which are units small enough to maybe remember whenever you need them with a little practice
How does one code by themself?
You really don't! I'll explain:
1. Just like there's no shame to drawing with a reference image (in fact, it's a necessary part of practicing and improving), there's also no shame in referring to documentation, cheat sheets, and things like variable hints and function signature auto-completion to speed up the process of writing code.
The primary skill involved with programming is logic--understanding what you want to do and having some idea of how you want to do it, step by step. From there, the secondary skill is optimization--figuring out ways to do all of this stuff faster and more efficiently in terms of RAM and processing time. If you can remember how things should be written off the top of your head, fine... But memorizing the names of variables and the signature of functions inside of some object is not only not that important, it's arguably a huge waste of time.
Make sure you understand computers enough to begin to develop a sense of logic around basic things like conditionals, loops, objects, etc. Put some thought into how you can cleverly design your program so that it's easy to write and maintain. But remember that it's perfectly ok to USE DOCUMENTATION!
2. Most of the code you work with is code that someone else wrote.
If you want to learn baking, it's smart to start with something simple, like a cake mix that comes in a box. (You add some eggs and some milk, or whatever, pop it in the oven and wait.) You don't start your own farm or milk your own cows. You start by combining and utilizing ingredients and instructions that other people have organized for you.
Programming is the same. Whether you're making something high level (like a game or application) or something lower level (like a driver or an embedded system program), you're almost certainly going to be most effective by learning to use other people's libraries or APIs.
There are thousands of libraries out there that help do basically anything you might want to do, for any programming language or platform that you want to use. What to display a GUI window with some buttons and scrollbars? There are multiple libraries for that. Want to load a song file and play back audio? There are multiple libraries for that too. Basically every programming language that I'm aware of has a "standard library" of some sort with a bunch of basic, expected functionality that most programmers may need, and you should take a little bit of time to familiarize yourself with that (not memorizing, but understanding). But for more niche functionality that's specific to what you want to do, you might have to seek out a specific library that someone else made.
You don't usually just learn a programming language and start writing every function from scratch. Rather, you're also going to want to do a little research into your languages standard library, as well as some other useful libraries relating to whatever program you're trying to make.
In other words, real programming isn't something that happens in a vacuum. You will be constantly using other people's code, you'll be getting help from your compiling and basic auto-completion from your IDE, and you'll be constantly looking up documentation to learn/remember how things are supposed to work.
It takes a lot of practice and patience. Even for experienced programmers it can be a slow process and full of missteps. One of the main skills is to be patient and methodical enough to figure out why something doesn't work. Don't be discouraged or impatient, and don't be tempted to get AI to do it for you or to find your mistakes. You can use AI later but it isn't a good idea when you're trying to learn the skills. Try to do it yourself and, when it doesn't work first time, take time to figure out why. Then do this lots more times.
Writing software is about problem solving skills which improve with practice. Often the process involves breaking down a problem into smaller pieces and breaking each of those down, until you know how to "solve" each problem.
Writing down each "solution" and stringing them together is then the actual "programming" part of this activity .. which brings with it a whole new layer of "problems" to "solve".
It's as much art as it is accounting and the more you do it, the better you get at it.
Source: I've been writing software since 1982.
Don't sweat it if you don't remember syntax stuff right away.
The building blocks will repeat so much - your if statements, loops, variable initialization - that some will stick in your head eventually.
But even when you get it, every once in a while you'll get a brain blip and have to look it up. Don't hesitate to have the language manual readily available. (As a next step, try working from that kind of language reference instead of copying direct from the tutorial.)
Most of the time in you won't even have to know it - in larger projects, you'll find a similar bit of code in an existing file and copy it, then make your modifications. Or depending on your dev environment, the IDE's intellisense stuff will act as a guide rail.
It absolutely is a feature of being a beginner but it is not an issue; it is not a bug.
How many hours total have you been programming for in your life?
Any skill takes hundreds if not thousands of hours of practice to become adept, and tens of thousands to reach mastery.
You’re at the beginning of your journey. It’s completely normal to not have internalised everything you’ve covered so far.
Keep going. That’s all you need to do. Keep practicing. Keep typing. Keep googling. Keep reading. You. Will. Get. Better.
Keeping it simple, have you tried to solve something on your own? Even in the case here, making something similar but not with the exact code from the book, but a "close enough" solution. And putting your own spin on it that makes sense for your structure.
I am not exactly a beginner (nor exactly experienced), but I had this moment with a minesweeper clone. I wasn't quite sure on structure with first attempt. I waited a while and eventually figured out how to actually start and complete it.
