So, this thread is for tips on programming in general. This isn't about programming in python or programming in java. This is about the fundamental heart of what one needs to do. If anything, it's tips on how to code in PseudocodeTM.
One of the biggest thing about programming is being able to break a problem down into chunks and then break those subproblems down. Keep doing that until you get a picture of what specifically you need to do to accomplish each major step. So, if your program needs to do things in three big steps, start even lower than pseudocode; start with a list.
Then, take each of those steps and do the same thing.
Step 1cStep 2:
Step 2cStep 3:
You may or may not notice the indentation. That brings up my second tip.
Use indentation, called "whitespace", in your programs and even pseudocode. Some languages require you to have whitespace indentation (like python and the never ending tabs v spaces war), but many do not. It is still good practice for writing though. Most languages have interpreters or compilers that ignore anything about whitespace other than whether there is at least one space between two letters, so it won't hurt the program but it will help you. Writing, or at least planning, with whitespace keeps ideas organized. Look at the example in the previous tip. You see each substep, and it's clear where in the logic that it belongs. It makes code easier to read and understand, even if it's not required.
Speaking of readability and understanding, that's where my last two tips come in.
Make good names. Names like "MyFunction" or MY_CONSTANT are bad names. They don't tell you what the function is doing or what the constant is for. Make names descriptive, and your code will be easier to understand and easier to read. Rename (or "refactor") if you need to. Many programming environments will even let you replace all instances of one name with instances of the new name, so it won't even be a long tedious thing. Renaming, if giving a new name, is a good thing. It promotes clarity.
Comment everywhere. Comment to the point that you think you're overcommenting, and then comment some more. Future you will likely have no idea what your code is doing, so leave good notes for future you to use to figure it out.