I was kind of bummed to see someone delete their user account after posting a question about how to get started on learning Python and programming in general, so I thought I'd make a post to help people. It's going to start-off probably feeling someone sarcastic and maybe even downright condescending, but I promise - it's intended to be uplifting and helpful.
Misconceptions :
There are numerous misconceptions surrounding programming.
Programming is about writing out special syntax.
Programming is about memorizing complicated syntactical expressions based on the language.
Programming is about "building apps" to make pretty things appear on a screen.
You need a solid understanding of high-order math to program.
I could go on for likely days about further misconceptions, but hopefully this is a start.
The above are misconceptions because they obscure what's really happening in programming.
Does each language have a syntax? Yes, of course. But, memorizing and writing them in special ways like cheat codes in a console game are not the point , they are just things that happen along the way. Most seasoned developers really don't bother to memorize all of the syntax. Heck, most modern Integrated Development Environments (IDE) such as Visual Studio (VS) Code actually have really cool tooltip systems that give you hints about how the syntax of a specific function *should* be written.
Math and Programming - it's not what you think .
Programming is about logic, not about math. This is actually a pretty damning reflection about how bad the Western education really is. Mathematics are an abstraction of the principles of logic, mathematics is not logic unto itself.
The above links can serve to help understand the discussion a bit. Heck, these very principles can extend to most corners of life. Why are most political debates not actual discussions/debates but instead just flame wars? Because people aren't using LOGIC.
Math is an abstraction of Logic.
Here's an example:
Let A = 1.
Let B = 2.
A and B are "abstracts" to represent the Numbers 1 and 2. Heck, the NUMERALS 1 and 2 are themselves abstractions (substitutions, really) for the idea of say - observing One (1) and Two (2) real world objects that happen to have a quantity of 1 and 2.
Continuing the example, if you made it through basic algebra, you would then know that:
A + B = 3.
You would evaluate this as a *True* statement. How? Because you can substitute the A->1 + B->2 = 3.
Does 1+2 = 3? Yes, this is True where the value of 1 = 1 and 2 = 2.
If this layer of abstraction is so simple, why do people struggle so hard to get into programming?
Because the education system does idiotic things when it teaches. It's not teaching you to think, it's teaching you to recognize patterns and just *assume* that you grasp the idea. Instead, we teach logic through an abstraction layer called "basic math" or "algebra" or "geometry". These types of mathematics are very useful for describing a problem in very short phrasing; "If A = 1, then A+A = 2."
Here's a very real example I have encountered:
A=1, B=2, therefore: A + B = 3
to
"If Sally can bake 12 cupcakes an hour, and Bob can bake 6 cupcakes an hour, how many can they make in half an hour?"
The Correct Answer: Insufficient Data.
The Answer you probably got: Sally = 6, Bob = 3.
And the above example was not me being flippant. That is a real logic problem and one that shows just how messed-up our education system really is. If you looked at that problem and thought that you could just divide by 2 to get the answer(s), then you missed the point: it still takes the oven a certain amount of time to bake, regardless of the # of cupcakes involved. Just because you can solve A+B=3, doesn't mean that you understand what other variables could impact a REAL WORLD example. A+B=3 is an ABSTRACTION, it's not real.
Programming works the same way. Yeah, I can write an endless for-loop that recursively jumps back in on itself through the use of recursive functions, but is that the right way? Probably not. Heck, I'm sure any seasoned developer who just read that sentence had an aneurysm and cried a little bit. I certainly did while trying to write such a horrid idea.
So, how do we improve ourselves so that we can become programmers and write cool scripts and build cool applications?
Gain an understanding of some *real* principles about logic. Challenge what you think you know. You can either try to debate (honestly debate, remove all emotion) a topic you think you know - but, try to debate it from a different view/"side". Do this one in earnest, if you think that "A" is the right answer - try to argue from the thought that "B" is the right answer and try to poke holes in your own arguments.
Learn how to grasp *procedures*. Can you genuinely describe exactly how a process works from start to finish? You probably can't. The first test is: Make a Peanut Butter & Jelly Sandwich. This is surprisingly difficult to do. Try to explain to a Ferby, a Child, or even a Robot how to make such a sandwich. Give yourself only one assumption: that the individual that will be performing the task can operate any tools effectively. But, make that the only assumption. You will quickly find that you probably can't do it on the first try. It's a tedious process. If you scoffed at this, you're the same kind of person who said, "when will I ever need this" in math class back in primary school. Either change your mind or quit now.
Learn and accept one of the most fundamental truths about programming: A VERY LOW percentage of *good* programming is about writing code. Most programming is about taking a goal, and describing it into the most tedious details possible. This is done in code comments, wireframes, diagrams, business analysis write-ups, and even writing "story" boards.
Okay, great, you haven't run away yet, now what can a person *DO*, what action's' can a person take to actually get started on really programming?
Congratulations on fighting through the pain of uncomfortable growth. It's time to get serious.
If you want to stick to Python, I recommend having the following installed/accessible:
An advanced IDE such as VS Studio Code.
A simpler IDE such as Thonny (it's super simplistic, is only focused on getting results, and has a built-in "step through my code" button right at the top of the screen that will VERY CLEARLY show you where your mistakes occurred.)
Some sort of "notepad" style text editor. Totally non-descript. No syntax highlighting. No frills. This is where you will want to start ALL of your programming journeys.
A diagramming software of some variety. I use Balsamiq, Lucid, and Draw.io
Once you have these and get just a bit comfortable with them, it's time to start.
Thinking of your first Application .
Tutorial hell sucks. You will *NEVER* get better just watching tutorials over and over.
However, you *WILL* improve if you master the basics. Because programming is about compiling basic actions in LOGICAL and COHERENT ways. Python? It's doing a LOT of the heavy lifting for you. It handles memory. It handles sockets, packets, CPU streams, connections, garbage collection, etc. It flips the bits for you. But, remember your machine is ONLY 1s and 0s being flipped. If you were programming in assembly, you literally have to tell it where to access the memory, and which bits to flip. Python *IS* easy because it's done almost all of the memory abstraction for you (and a lot of other work.) You're writing "sentences" that almost look like English. Now, if you haven't been scared-off yet and you still want to actually write some programs, let's answer your question with an action you can take:
Either do an internet search or come up with a project idea for a VERY simple project. I recommend 21 (Blackjack), A calculator, or something else VERY simplistic.
Then, I want you to break it down into the tiniest components you can comprehend:
What types of information are present? Numbers? Letters? What kinds of numbers? Are they just integers? decimals? Are they just Anglican characters or other character types?
This information, AKA data - will I need to remember things? These translate to variables and need to be "stored" somehow.
Are there actions that are repeated? These translate to functions.
Are there activities AND data which sometimes need to be "built on the fly" - these are classes.
Are there activities which repeat until a certain condition is met? These are usually loops (often "while" loops.) A perfect example is trying to build a mini blackjack game - you want the game to continue until the player wants to "Q(uit)" or they run out of money.
Start with something that hopefully doesn't need classes, or at least not complex ones.
Once you have these concepts broken down as far as you can, it's time to start thinking through how to assemble them into a coherent script/application.
How do those tools/software I mentioned earlier come into play?
You're going to start with a TEXT file. Just raw text. That list of questions I asked earlier? Write it all out into that text file. Heck, write it on freaking paper if it's easier for your memory. For some, the tactile sensation of writing improves their ability to recall it later and keep it all "in mind" as you go.
Write everything about your application. I mean everything. Does it need a logo? What about a favicon? Is it in the browser, an administrative terminal, or a standalone window? What about deaf and blind usage?
In what order does everything occur? If you chose blackjack, you might say, "well, you place a bet" - WRONG! You have to START by wanting to play the game. In real life, you would elect to sit down at a table. But, there could be 10 different tables. That's a MENU! So, we need to start with a "welcome to the casino" message. Then a menu to "start playing, load a game, quit" etc.
This is where diagramming and wireframing comes into play.
Diagram how the decision tree works: if the user says Q(uit) - the program shouldn't try to start a new hand, right? It should probably stop playing, and give a message that reflects the user's desire to leave the game and/or application. Sounds obvious right? Scroll through newb apps on github and you'll find that people screw this up a lot. Remember: making mistakes it OKAY! It's how you learn! So long as you don't os.path into some root directory with administrative privileges and perform a sys.delete() you're probably fine.
Are there exceptions? What sort of messages should be displayed to the user when an oddity/mistake happens? How should the application recover the 'state' (Status) of everything?
Are there choices? (often translates into Cases, If-Else Statements, or similar.)
If you can't accurately depict your ENTIRE application on a wire diagram - you probably don't understand it.
If a totally oblivious person can't follow the simple "go here, go to the next step" like a game of Chutes & Ladders or Candyland - then you haven't simplified and broken-down your parts enough to make it make sense. I'm not making fun of PEOPLE here, I say "oblivious person" because your computer is a moron and is utterly oblivious to your intent. It doesn't know what to do, it just follows the instructions.
Okay, you think you've got all of this figured out? Test your theory:
For your first mini application, try writing your application in NOTHING BUT PRINT STATEMENTS.
Yes, do it: """Print("Welcome to my Blackjack game.")"""
Your code could look something like this:
.
Print("Welcome to my Blackjack game.")
Print("Select from the Menu.")
Print("###################")
Print("# (P)lay - Start a New Game. #")
Print("# (Q)uit - Leave the Application. #")
Print("What is your choice? SPACE FOR CHOICE.")
.
Yes, write-it all out like this, even making assumptions about the user's choices.
So, you would continue with the user pressing "P" and hitting enter. Doing this should raise alarm bells in your head. What about lower case P? What happens if they hit something other than P or Q? Go back and check your notes - did you write-out your answer to this problem in your notes? If you didn't go back and add some notes to your "Exceptions" section.
Continue with this process until you have "played" a game in pure print-text.
Next Steps:
Once you have done this successfully and updated all of your notes (This is called Technical Analysis (TA) - well sort of, it's an aspect of TA.) you can start on the next step:
Need to store the user's choice? That's a variable.
Need to store that "P" will be mean that we start a new game? That's a variable.
Need to store the amount of money that the user has? That's a variable. Go ahead: player_money = 0.
Make that variable. Does your code still make sense?
Generally speaking, where repetition occurs here, you probably have a function.
Can you simplify your code by - taking the collection of print statements that made your beautiful menu and put all of them inside of a function? Sweet. Put that function definition near the top of your code, and then just call the function.
Did the menu get built as intended? Good job! If not - start over again, until you get it right.
Make sure you already have a variable ready to go for this input.
Then find the syntax for taking input and practice assigning the results to the variable... then....
Identify where a decision tree happens,
Take the input, assign it to a variable,
Assess it against any exception handling logic.
Generally speaking, the existence of a decision tree or the necessity to "keep the program running" results in a loop, whether it's using a framework's inherent app.run
In this case, you're going to need:
a while loop to keep the program running until the user quits.
a while loop that keeps forcing the user to make a VALID entry until they enter either P or Q. Do you want to force them to use P/p or will use the python's built in .lower / .upper methods?
a while loop for deciding whether to hit, fold, stay, doubledown?
Baby Steps:
By baby-stepping this process into tiny steps going from pure print statements, to beautiful functions variables, and inputs - and little by little you'll see your application come together into something coherent and functional!
