Programming

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

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.

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

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.

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 is, 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 language reference handy is normal, in my experience.

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.

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

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.

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 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.

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.

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.

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.