Incoming unbridled rage
All right little enbies, boys, girls, et al. I was utterly triggered today by what I consider to be a failure of education. Not of learning, but of teaching. Look, there are many professions that I understand require some level of teaching to build any sort of career with. That mandate is guaranteed to produce poor educators. If you are forcing people to perform a function, you are forcing people that should not teach to do so. I don’t like it, but I get it. Programming, however, as far as I understand it, being, you know, my goddamn profession, is not one of them. If you are teaching it, you wanted to, or chased it, in some form. You do not, in my opinion, get the benefit of the doubt as to why you are shit at teaching it. And, listen, I am not exactly sure that I should be teaching it either, but I at least can do a better job than none. So, I am sending this into the non-algorithmic void. Partially for my own sake. But mostly in the hope that somehow, by some miracle, this reaches someone that is stuck and can be used as a guiding light in the path to learning something very dear to me, and very relevant to all of our lives.
With that out of the way, let’s start at the beginning.
Programming Chapter 0 - The part where we don’t even show code yet because why the fuck would you just toss people into the pool first.
Let’s talk about machines. And by that I don’t mean motors, or gears, or clocks. I will be using the term ‘machine’ to mean a computer, of some sort, any sort. If it can run some form of code it’s a machine.
Machines are incredibly stupid. You have probably heard people say this before. But you have to understand just how stupid they are. A good example to start with is crashes. A crash is when a program cannot continue to run, for whatever reason, and it closes itself. Sounds sensible, but let’s think about that for just one second. This is the equivalent of a person walking over to their car, trying the key on the door once, failing to insert the key into the keyhole, and deciding that the only available course of action left to do is to shoot themselves in the head, which they then do. Immediately. And yet this is how every machine you have ever used operates. At all times. If it’s not shooting itself in the head it is because a person wrote explicit, excruciatingly detailed, instructions on what to do at all times, for every conceivable eventuality, such that it doesn’t shoot itself in the head.
Every, single, technology you have ever used. Your phone, PC, those interactive tablets restaurants use to avoid paying people to take your order, literally anything you have ever seen running, that is running code, is literally one unforeseen error away from shooting itself in the head and halting. The reason it doesn’t is because a person (until very recently, now some of it may have been regurgitated by an ‘AI’ that predicts what the most probable word comes next in a piece of text, powered by the magic of mass text theft) wrote a series of instructions, very granularly, to tell the machine exactly what to do for every eventuality the designer could predict. This is, conceptually, asinine. Yet it is what powers most of our world today.
And that’s what code is. This is also why it’s often called a ‘script’. Because you are writing a scene for the machine to follow, but you don’t know what happens in each specific play. You only know what could happen at certain points, what could be the state of the stage, the crowd, the weather, and so forth. So you write instructions that cover every event, and tell the machine to follow this path if A happens, but this other path if B happens, and so forth. And you better be thorough, because if it gets lost at all, bam, head gone. Play over instantly.
Then there’s the problem of specificity. Let’s say that your friend asks for directions to the nearest store. And let’s say, for the sake of argument, that your friend is dense. And I mean really dense. You know to give very specific directions, and you probably say something like “Oh just take the road in front of my house going right, then take a left on the second light, go past the gas station that will be on your right, and it will be the third building on the left.” That seems like a pretty detailed way to get there, right? Well, in the case of a machine, it would then say “got it” slam itself face first onto your front door, because you did not tell it to open it first, or even how to do that, realize it could not go outside and shoot itself in the head.
Look, I know I’m harping on this thing, but it is vital that you understand what it is that you will be dealing with. In that same scenario, depending on what language you are using to code, and what program you are coding for, you may have to tell this friend analogue machine to breathe every second or so, or maybe even to pump its own heart. Code is a series of incredibly specific instructions, that will be followed in order, absolutely literally, by a machine whose only two states are “follow the next command to the letter” or “kill self”. Once you accept this, it becomes a lot easier to understand that your job as coder is to predict everything that could happen, come up with instructions for those eventualities, and write them, clearly, and specifically.
You may read this, or, you know, skim it, I see you, and think to yourself: “Ok but how is that even possible? I can’t predict every possible eventuality, if that’s true I would never get a single program finished!” And that’s… partially true. However, we, and I mean humans, have been coding for a while. So we have a lot of code we re-use everywhere that covers very common events, and “automates” a lot of functionalities. Essentially, we’ve been building these systems layer by layer. Some person a long time ago spent ages making it so that the machine could show text on the screen, and that took years, several gallons of blood, and several swimming pools of coffee. But now we have a way to do that, so we just… use it when we need text on the screen. And this goes for a lot of things. It’s why we only really have three choices for PC operating systems. Windows was designed over decades, and it runs on DOS, which also took years to build. Macs have a similar history, and Linux is based mostly on Unix which is the very first ‘operating system’ ever designed. Oh and Windows and MacOS also borrow heavily from Unix as well. Because good ideas, that solve common problems efficiently, stick around, get re-used, copied over and over. And yes, I know, I am generalizing, don’t fucking @ me, but the core still stands. Humans have been programming for a long time, and a lot of problems are already solved so well that we just re-use that solution so that we can solve the next problem, and so on and so forth.
Every computer today still, at the end of the day, uses something we call “machine code” to actually run. Which is the binary code line by line telling it to beat its heart, pump its blood, breathe, see with its eyes, telling every single little cell in its stupid, dumb, body what to do. Machine code is not human readable, it’s literally just 1s and 0s, so when machines were quite young, and incredibly weak, processing-wise, we created a way to be able to read the 1s and 0s in something other than just those two digits, to make it easier for humans to read. That’s Assembly.
There’s many versions of Assembly, and it’s no longer 1 to 1 with machine code, but it used to be, and, most importantly, it’s the closest you can get that is “human readable”. Every single machine still runs off of Assembly translated to machine code, but we wanted to be able to do more with less words, so we created languages that are even more human readable, are easier for us to understand, and allow us to abstract a lot of individual Assembly commands into just a couple lines of code. When you then want the machine to read it, you ‘compile’ it into Assembly, and the machine runs that. This is what people mean when they say “high level language” it’s “high” because it’s further from machine code, than Assembly is.
You will likely be learning to code something like Javascript, or C#, or Python. What that actually means is that your code runs on other people’s code, that runs on top of yet more people’s code, that all gets compiled into an enormous amount of Assembly code, that then gets translated almost one to one to machine code, that then, finally, gets read by the machine. And it is these layers that empower us to write code that shows 3D objects on the screen without having to also individually control which specific pixels on the screen display what colour 60 times per second, or whatever. But no matter how “high” you get away from machine code, at the end of the day, it’s that same, incredibly dumb, machine following each line blindly, with a gun to its head at all times. Understanding this helps you understand the next step.
Programming Chapter 1 - It’s all flow charts.
Yep. That’s the “secret”. Gave it all away in the title. A program is a flowchart. That’s it. We even use them, all the time, when we propose a new program, or version of an existing program. We use them to teach people how our programs work. They’re very useful. And they’re literally “the program”. It’s just that for the machine to be able to read it we have to describe the flowchart very specifically. But humans can use that thing called brain and just intuit the function. If you remember nothing else from what I am writing today, please remember this: If you can flowchart it, you can program it. YOU can. Yes you reading this. If you can make me a flowchart that describes a series of conditions and what to do for every condition, then you can code it. Notice I have not mentioned a specific language. Because they do not matter. The flowchart is the hard part, the rest is just semantics. Here, let me show you:
Behold! My magnum opus. I call it: EXAMPLE_1
This chart is all that is needed for us to write EXAMPLE_1 in any language we want. We just need our good, old friend: Google any fucking search engine you want.
Here it is in Python:
And here it is in NodeJS
Feel free to try them locally. I recommend using Visual Studio Code, which is free and relatively easy to set up, and remember that you need Python installed on your machine to run .py files, and NodeJS installed on your machine to run .js files.
“Hey! That’s not fair! There’s stuff in these codes that are not in the chart!” What’s ‘import’? And ‘const’? And why is one randomizing between 0 and 10 and the other between 0 and 11? What’s with the brackets? And what the fuck is a ‘console’?” Ok ok ok, I hear you, I will go into detail about those here and more in depth in future chapters, but, puppies, I have to tell you, for some of you, this is where we say goodbye. And not in a sad way.
Some of you just had the light bulb flicker in your heads and you get it. Do you think I sit here constantly remembering how to generate a random number in NodeJS? Or that I always know which brackets a particular language uses, or how all of them declare if statements? Fuuuck no. When I make the flowchart, I define the why, Google tells me the how. Why something needs to be coded is the important question. How is entirely dependent on what language you’re using, and what platform you are using it for. “How” is easy to search for. Just type “python create random number from 0 to 10” into Google. The first result, as of the writing of this rant, is a stack overflow question that has the exact code I’m using in its second answer. The second result is the documentation for Python, specifically the Random library, that has this section:
Bam, badaboom, badabee. A library is a collection of code that can be imported into your project. A library that exists within the language you are using without having to download it, like random does in Python, is called a “native” library.
The documentation itself tells me everything I need to know. This works in Python 3.14.3 (the latest stable version I am using and the default when you install Python 3) and the Lib/random.py tells me the library is native, and all I need to do to import it is the line at the top: import random, now I can use random.randint(a,b) just like the example shows. Python also tells me the N generated will be such that a <= N <= b meaning the generated number can be a, and it can be b so I can just define randint as (0,10) meaning the lowest number I want N to be possible to be is 0, and the largest is 10. But in NodeJS that is not the case. From its documentation:
Min is defined as inclusive, but Max is defined as exclusive, meaning that when you call randomInt(a,b) the generated N could be a, but could not be b, therefore if we want a number between 0 and 10, we need to call randomInt(0,11). Oh and the third example of usage in the same page is:
Which looks familiar dont it. It even includes the import, how helpful!
And that’s it! For some of you that’s all you need. I know you exist I was one of you. Go, be gay, write code. Figure out the why, and Google the how. Now, I understand that is not how everyone learns. And I will do my best to write more detailed chapters covering things like variables, objects, functions, loops, and everything I consider a building block of programming, but the real important lesson is these two chapters. Remember machines are stupider than you can imagine, remember that if you can flowchart it you can code it, remember that I love you, and believe in you, and please be aware that AI is not a reliable tool, and can only be used “safely” if you yourself already know coding enough to be able to read what it vomits and know if it makes sense. Coding is one of my loves, it is incredibly rewarding and pays my bills, but it is also frustrating and unintuitive. It’s ok to get stuck, it’s ok to get frustrated, just remember that the machine is literally just following your instructions in the dumbest and most literal possible way, and that it never means for anything. It has no will, ill or otherwise. You can do this.
