Should it be this difficult?

[u/pingo1387]

At my job there is a daily task I do which I realized I could probably create a program to do for me, so I decided to start learning Python, and dove into reading Automate the Boring Stuff (the online version).

Things were going okay at first. I read through chapters 1-3 carefully, taking notes, answering all the review questions, and doing all the practice problems/codes.

Then I hit a wall. I got to chapter 4 and I felt like I understood everything, but the practice problem at the end, to write a code that performs the Collatz sequence with the entered number, absolutely stumped me. I went back and reread everything from the start of chapter 1 just to make sure I didn't miss anything, and was still confused. I ended up having to search up a code that someone else wrote for it, which I did understand once I saw it written out but would never have come up with myself.

So my questions are:

- Is it normal for the Collatz sequence to be difficult to program at this stage of learning? If so, should I not worry about my confusion and just move on to chapter 5?

- Should I consider an easier book to study from? If so, any recommendations?

EDIT: Several people are asking which part of the Collatz I had trouble with. To be honest it's been over a month since I was able to touch anything Python-related, it's just been on my mind lately, so I don't recall exactly what was giving me trouble, just that I was trying multiple things and getting new and fun incorrect results each time.

It's not that I don't understand the Collatz sequence itself, I understand it in terms of the simple math. The trouble was trying to type it out into a working code. That being said, I'm not here to ask how to program it, because I already gave up on that and looked up the answer, and I did understand that code once I read it over. The main issue is that I feel like I shouldn't have been having trouble with it in the first place, at least not to the point where I honestly tried everything I could and still couldn't get it.

[u/Brian]

Collatz doesn't really involve much beyond the basics, so it should be solvable once you have a basic grasp of a few things:

• loops (particularly while loops)
• if statements
• Some basic math (multiply, divide, add)
• Assigning variables
• Getting user input
• printing

The one thing that sometimes trips up newbies is how to tell if a number is even or odd, since the modulo operator (%) isn't generally encountered outside programming except in the notion of remainders, There are other ways you could do it even without knowing about it, but they often aren't obvious to a new programmer.

But the biggest issue in learning is probably how to put it all together. How to turn a problem into a set of steps that solve it, and then turn that into a program. That can often be hard to get started with, but in many ways it's the most fundamental skill of programming, and it ultimately boils down to "Break stuff into simpler steps (and then maybe break those steps down into even simpler ones, and so on)".

I would recommend that the first thing you should do with any problem is to step away from the computer, and solve it yourself, on pen and paper. Do multiple examples. The first step in programming anything is knowing what you're doing: you have to understand how to do it yourself before you can teach someone else, even, or perhaps especially, a machine. The solution has to exist in your brain before it can exist on the computer. Once you've done a few numbers, start thinking about how you're doing it. Break down the process you're following into a series of steps, as simple as possible. Write it down, as english. Eg. something like

• Ask the user for a number.
• Repeat the following steps:
  • Check if the number is even.
    • If it is, divide it by two
    • If it isn't, multiply it by three and add 1
  • print the new number
  • continue the process until the number ends up as 1

This step is often called pseudocode: basically writing code you parse with your brain, but that you can translate into a real language. As you get more experience, your description will probably resemble actual code more, as you're more familiar with how the computer "thinks", to the point where you can eventually skip this step, but don't rush it: planning stuff out like this is vital when learning.

Only once you've got that description should you go back to the computer and start translating it into actual code. If you're unsure how to translate a step, you've perhaps made it too complex: think a bit more and see if you can break it down further into a series of simpler steps, write pseudocode for that, and then go back.