It’s been one full week since I decided to start “teaching myself” how to code now. After building many small programs like a simple calculator, a blackjack game, and a virtual “coffee machine”, learning the fundamentals like loops, conditionals, lists and dictionaries etc, there has been a huge shift in the way I view programming.

Learning the syntax and writing the code is actually quite easy, but not programming. Programming can be a bitch. Just because I know what a nested for loop is, does not mean I understand how to put it to practical use with hundreds of other operations and make it do exactly what I want it to do. In my first few days of learning the concepts, I was just stuck in an infinite while angry loop, not understanding what I was doing or even what I was trying to do at all. The moment I started to feel like I “understand” and truly enjoy this process of programming, was when I stopped thinking in terms of “coding” like a computer, and started to think in terms of step by step problem solving… in English. It’s impossible to understand what I’m thinking or trying to do when in my brain I’m talking to myself like “for i in variable, x = what the hell is happening”. It’s so much easier to understand the problem and solve it when I can break it down in English, like “I want this function to check this condition and if it’s true then I want it to do this”. As soon as I started to view programming in this way of breaking down problems, solving them, and putting it all together to make something real, that’s when I started to really understand why some people really just program for fun because they like it. It’s satisfying and fulfilling.

How to write good code

The greatest difference I notice from my first day of programming to my sixth day (yeah I can really call myself an expert now, 6 whole days) is my workflow, and how much time I actually spend coding. The first “project” I made, a simple Caesar Cipher encryption program (I think anyone who’s a programmer has probably done this exercise), I spent probably 2-3 hours trying to “write” the code. Most of my time was spent going up and down in my code trying to understand what the hell I was even trying to do each line and just in a general state of confusion as to what was making what work. Even after I got the program to work, I still had no idea why it worked (And I made it!!!). The code was ugly and impossible to understand. If you asked me to add a function to it, it would probably explode if I tried. The most recent project I made, a virtual coffee machine, combined everything I had learned up to this point: Nested dictionaries, lists, for loops, functions, conditionals, etc. But I only spent 1 hour writing the code, and I understood exactly what was going on, what was making what work, and why it worked. I don’t think I got smarter, I just got better at mapping out my thoughts and making it clear. Even though I spent only an hour coding, I probably spent another 1-2 hours drawing up a flowchart and a list of like 15 To-Dos, mapping out the entire logic of the program and what I needed to do first. The best part? I did it in English. I could read over it and pretend like I was a 5th grader and understand how the program worked. I test my program every time after I tackle a new problem and tick off another To-Do, and by the time I hit “run code” on my last To-Do, the program just seemed to magically work. Everything came together and worked exactly how it was supposed to. Mapping out your thoughts and just making it clear what the problems to tackle are makes your life so much easier. I’m convinced I would have gotten stuck in an infinite loop in my own mind if I didn’t map out this coffee program. If I tried to understand nested dictionaries and run a for loop to get information from it at the same time while storing it to local variables and returning it to produce a desired output, I would have gotten so lost and might have given up right there to be honest. I would say this skill that I learned - breaking a big problem down into smaller problems that you can tackle one at a time, and if the small problems are still hard to tackle, break it down again into even smaller problems, the daunting, overwhelming logic of the program you’re trying to tackle unravels and appears simple.

A simple way of deciding what to do when looking at the logic hierarchy is to simply run the demo program (or if you’re being innovative then I guess run it in your head) and follow the program in a top-bottom manner like you would if you were coding, and write down everything you see that happens. If the program starts off by giving you two random numbers, the first thing that happens is probably to generate 2 random numbers. Do this 2-3 times, and by the end you’ll have a list of all the To-Dos you need to get started, and if anything comes up while writing the program, simply add it to the To-Do. Adapting to things you didn’t see coming is also a crucial skill.

When I’m writing a program, the best looking ones are always ones with the most amount of functions for actions. That’s just the way I see it right now. If there’s an action to be taken, for example generating 2 numbers, I will write it down first in the crudest way possible (if I don’t already know what I’m planning to do with the function), and after verifying that it works I will turn it into a function and write a docstring explaining what it does. This just makes the code more English and so much easier to understand for me. I obviously don’t turn EVERYTHING into a function, but I would say 90% of my program is functions for actions to be taken, and the other 10% are actions that are repeated in a loop.

The Best Way To Learn and Truly Understand

“If you can’t explain it simply, you don’t understand it well enough” - Albert Einstein.

I think Einstein was onto something. Maybe one of the most intelligent men to ever live actually knew what he was talking about. Learning how to learn, especially in the early stages when I’m taking in the fundamentals, is extremely important. Once you can explain the concept to a 5th grader without using any field specific terms, that’s when you understand. The most effective way I found that helps me truly understand what it is I’m learning is to pretend like I’m writing a speech to a 5th grader. This often involves me to be creative and use the concept in ways outside the generic examples. For example, here is me when I used this technique to understand the modulo (I’m gonna be honest it took me 2 hours to fully understand this but at least I understand how to use it in my programs now beyond if num % 2 == 0, num = even): The modulo is when you divide number of the right by the left, and whatever you can’t divide is what the % returns. If I was a 5th grader, I’d probably still be scratching my head (I wasn’t a very smart 5th grader). So I would rephrase it and say this: When you try to put 5 into 10, you can do it 5 times perfectly right? This means that the modulo is = 0. What happens when you try to put 5 into 13? Well you after putting 5 into 13 twice (5 + 5 = 10), you can’t go into 13 again since you’ll go over and hit 15, so you have 3 left over, which means the modulo is = 3. If I had a pie with 13 pieces and I had to share it with 5 people, each person would get 2 slices, and there would be 3 left over. Then we can get into modulos with a negative number, which has a slightly different concept that I’m not going to explain here because every programmer on earth already knows what a modulo does and I’m the 5th grader. I’m sure you can imagine the look of “what the hell are you talking about” I would’ve gotten from the kid if I said “hey kid the modulo equation is a % b = a - b * floor(a/b) and when it’s negative you can express it like this: a % b = b - (abs(a) % b), alright now put this into practice and give me a caesar cipher encryption program that loops over the alphabet”. I don’t even know what the hell this equation means, but when I explain it and apply it simply, I will force myself to get into the fundamentals and understand why it works on a deeper level. As a bonus, when you write your thoughts down, you’re slowing your mind down and taking the time to truly process everything, and being able to read it over again to understand what you were thinking a minute ago, making it that much better at helping you to grasp a concept.

TL;DR: just use the Feynman method.

Conclusion

Becoming a programmer isn’t about learning the syntax or knowing how different functions work, anything and everything you can use and learn is a tool, it doesn’t make you a programmer. Knowing how to use a hammer does not make you a carpenter, just like knowing what a for loop does not make you a programmer. It’s the application of these tools like using the hammer to build a house, or using functions and the language syntax (programmers hammer) to build a program, that’s what makes you a programmer. In this way, I think programming is not only fun, but allows you to be infinitely creative in your projects, to build whatever you can imagine, to solve problems little by little, and in this way allows you to improve infinitely without a real “ceiling” to limit your skills.

Please take everything I say here, all the “advice” I’m giving with a grain of salt. I’m a very beginner programmer, I like to share and educate, I’m pretty much teaching myself here, and putting my thoughts down helps me better understand the concepts and my own beliefs.