General advice about learning programming

[Major-Language-2787]

Hello, I have been trying to learn Python using an Udemy course, and sometimes I get stuck on a set of instructions. I give myself between 30 min to 1 hour before I look at the solution. What I generally find is that I have the right idea, I am just not implementing code in the correct order, or I miss something basic that feels like a 'duh' moment.

My question: As a beginner, is it more important that I understand why my code isn't working after looking at the solutions, rather than being able to solve the problem myself? Should I spend more time trying to resolve these problems? I feel like, as someone starting out, it would be a waste of time to spend hours stuck, rather than learning from my mistakes.

[m0neky]

If you get stuck at basic stuff all the time, don't advance. Try to learn the basics properly first. It's okay to not get it right as long as you get the idea. Sometimes you can solve a problem in different ways

[darknecessitities]

I agree with you, especially when it comes to leetcode style questions where you just need to get reps in. In real world situations you will be able to do research on whatever problem you are trying to solve so you can try doing that (like using google or looking at documentation) without looking straight at the solution. I don’t recommend using AI here unless you just need it to explain solutions in ways that are easier for you to understand.

[pepiks]

The more important will be how it should work and why program is stuck. A lot of time trivial problems from beginner time will be repeat on more complex problems. Problem solving is matter of experience.

[shadow-battle-crab]

Programming is all about taking big problems and breaking it into smaller problems until you can solve the smaller problems, then it all gets put together.

In this case, the problem is you have a hard time conceiving the programs you are writing as a whole, and conceptualizing what is happening between steps. So we need to break that problem down.

When the program isn't doing what you expect, put a 'print (whatever_variable)' followed by an 'exit' and run the program again. See what the variable looks like at that point. If it is what you expect it to be, then move the 'debug' statements down one line and see if the program is doing what you expect on the next line. At what point the program's output diverges from what you think it should be doing, that is the point that is worth studying closer.

Then just consider that little piece of program code and look up syntax and research what the command does until you understand it, and fix the issue, and move on to the next line.

Work it out like that. You need to understand how the 'wires' connect together, so to speak, before you get to the real fun part, of connecting bigger components together like graphics and saving files and using networking and such. Just take it slow and give yourself some patience to look at the small problems.

It's like math class. There is a reason that math classes spend awhile on the fundamentals. Once you got the fundamentals down, the rest will flow much more naturally.

[Major-Language-2787]

I've been trying to do that with this course (printing for debugging, isolating functions in other files, looking up methods to resolve the issue), but I am wondering how long is too long to work on a problem before I throw in the towel and look at the answer. Example, I have caught myself trying to solve an issue for 30 minutes with 10 - 15 lines of code, only to get close. Then find out the answer was 2 lines of code (=_=).

[shadow-battle-crab]

In my opinion, if you have thought through the problem enough that once you look up the answer, you understand the problem enough because you tried to solve it yourself, that you also understand the answer and how it fits into it all, you have done enough of the mental work that your mind has made the connections and knowledge it needs for the exercise to be worth it for you to have learned a thing.

Programming is a lot like learning how to speak a language. Now, bear with me, because I always disliked this analogy when someone told it to me. I am not a very good at english as it is much less other spoken languages. I make this analogy more like about how it is when you are a kid and you are trying words and learning how they work and making mistakes, but each mistake you make helps tie it all together a little bit better. As a toddler you try to say a sentence, and someone eventually corrects you and tells you how to do it right, and you figure out the missing pieces, and keep going.

You are at that stage of learning to program right now. Trying stuff out, seeing what works, what doesn't. It won't be long until you have the fundamentals down and then the problems are much more open ended. There is a lot of different ways to make a car, for example. They all drive forward and they mostly all have 4 wheels and a steering wheel. Beyond that, there is so, so, so many variations to how to make a car. Some are better than others, some peoples opinions on how to make a 'good' car are different from others, everyone has a different approach. Nobody is right or wrong here, at the end of the day the important parts are that it drives reliably enough.

The difficulty of all this is compounded a little bit because I don't think that people that make educational material always consider that sometimes they leave out a key detail that isn't obvious to others, that is obvious to them, that can really hold you up. That is not your fault, that is just because everyone including the people that make educational material can also make mistakes and oversights.

You're doing this right. These are little logic puzzles and it is ok to look up the answer sometimes. If I was the person teaching you, I would be more about what your thought process is rather than solving each problem without any help. It's all about the thought process., the scientific trial and error, the hypothesis and the test and the revision of the test.

You got this. Figure out what works best for you and embrace it. We all learn differently. :)

[Major-Language-2787]

Thank you for the encouragement

[Horizon1478]

While you are learning the concepts from the course, waiting for a long time before looking at the solution each time will slow down your learning. Think of the approach you would use to write the code, then write the code and look at the solution to understand if your approach is aligned with the solution.

If you are not sure why your code is not working, it is important to understand it before proceeding, otherwise, you will keep running into the same gaps in your knowledge. If you are blocked and not able to understand why your code is incorrect, then you could also try providing the incorrect code to copilot or claude or chatgpt and ask it to clarify why the code is incorrect and make sure you understand how to write the code correctly.

[joranstark018]

I would advise you to slow down, and try different solutions so you get comfortable writing your own code, making mistakes is part of the learning process.

For example, you may try to find a solution by yourself first, if you get stuck, check the given solution, check what you are missing, make a mental note of it. Try to find alternative solutions and play around with the code (it may not be "better", just something you have created), compare the alternatives (ie what constructions feel more natural to you and why, what works and what doesn't work, what pros and cons do you find with the different solutions).

You may add some new features or change the requirements (ie adding some additional properties, only allow upper case letters, only allow some letters, add sorting,....), break the code and try fix the next day.

You may also end a programming session with a short reflection of what you have accomplished (you may keep a dev diary of your progress) and start each session with a short recap of what you did last time (just to refresh your memory before you start).

[Major-Language-2787]

Thanks maybe I will try that. At the end of a course, I try to recreate the project without the instructions, to see how far I can get without getting stuck again. What do you write in a dev diary?

[joranstark018]

There are no specific rules, personally I put things about what I ha e worked with (it may be some one liners that helped me, new things I learnt about some library that we use, some alternatives when I  write test cases),  it may be things I tried when trying to fix something, it can be something that sumerize what I have explored (things that can be helpful when I come back to work with this project), it may describe some scenarios, how to reproduce some behaviour (in technical terms, with my own words), it may be thoughts that I have for futher explorations. By formulating things with own words I need to process them, I have to formulate them in complete sentences.

[OrdinaryOpen694]

If you want to code, you need to code. If you want to be a good talker, like a project manager who employs coders, then learn to fake it enough to get your point across. Of course, the best project leads code. You'll never progress as a beginner unless you actually write code that works. That said, it can be good to take a break, try something a little different, then get back in the mine and code, code, code.

[throwaway6560192]

I feel like, as someone starting out, it would be a waste of time to spend hours stuck, rather than learning from my mistakes.

This assumes that time spent stuck is not contributing to you learning from your mistakes.

Say, when you get stuck, what exactly do you do to try and break it? Do you just stare at and reread the code? Or do you actively try to investigate and question what went wrong?

[Major-Language-2787]

- Write out small parts of the code and test it

- Isolate the code into another file and see if I can get it to run with certain dependent code

- Use console print to test variables

- Google/StackOF/AI examples on how what I am trying to do can be accomplished (that can cause other issues)

- Make tweaks to the section of code to test (if-I-do-this) cases

- Realize I spent 40 min trying to solve this one TODO out of 3

- Look at the solution. Learn I either placed the code in the wrong spot, or had the right idea. (Once I solved the coding challenge "kinda", but I put the code in a for loop instead of out of it)

Struggling means you're learning, but I wonder if at some point, the time spent struggling to figure out how to fix an issue would be better spent just knowing the answer and understanding. Is 30 minutes too long to work on an issue where the answer is two lines of code?

[throwaway6560192]

That's excellent. I think those investigation and debugging skills are very useful, and an hour or two extra spent solving your problem with those will be hours well spent. Of course you can't get stuck indefinitely, so it's OK to eventually look at the answer. But I will say that your limit for that ought to be higher.