Demystifying The Art of Programming: Oversimplified Version

Photo by Adi Goldstein on Unsplash

Believe it or not, programming is simpler than you think. I learned this the complicated way, that programming is simple (this is quite a paradox, isn’t it?).

Many people often associate programming languages with extraterrestrial languages or signs. There are so many cryptic words in a source code that aren’t understandable by non-coders. Something like this:

#include<stdio.h>

int main() {
    printf("Hello world\n");
    return 0;
}

But as complicated as it looks, it simply prints the sentence “Hello World”. It’s like we are telling the computer “Hey my computer, please print ‘Hello World’ on the console, okay??”.

So, what am I trying to say here? Continue reading below.

Language Definition and How It Compares to Programming Languages

According to Wikipedia, Language is a structured system of communication that consists of grammar and vocabulary. Right now, we are talking about programming languages. Do programming languages follow the same principle as the definition above? The answer is yes. That means programming languages are almost similar to those of human languages.

A little bit of example:

Human Communication in a Nutshell

Human-Computer Communication in a Nutshell

The pictures above show that the communication method is almost similar, even though the human-computer communication one is a little bit different, where the human is commanding the computer to print “Hi!”.

So that means, basically with programming languages, we now have the ability to instruct the computer to do something, potentially benefitting us (like instructing the computer to calculate something, a.k.a the calculator app).

Fun fact: Programming languages have fewer vocabulary words than English language, which I’m currently using right now to write this article.

More Practical Example

Let’s say we have to create a game where the player has to move around with only two built-in functions, turn right and move forward. Built-in functions are functions provided by the program by default that we can use immediately.

#include<stdio.h>

int main() {
    // Put the functions here
    return 0;
}

void turnLeft() {
    printf("Turned Left");
}

void moveForward() {
    printf("Moved Forward");
}

If we want to move forward twice and turn left once, we can just simply call these in main function:

int main() {
    // Put the functions here
    moveForward();
    moveForward();
    turnLeft();

    return 0;
}

But what if we want to turn right instead of left? what if we want to move backward instead of moving forward?

That’s where our custom functions are needed. We can create something that we want by utilizing the built-in functions.

void turnRight() {
    // By turning left thrice, we can achieve turning right
    // (from the initial direction, before this function is called)
    turnLeft();
    turnLeft();
    turnLeft();
}

void moveBackward() {
    // We turn backward first by turning left twice
    turnLeft();
    turnLeft();
    // After we turn backward, move forward once
    moveForward();
}

For turnRight function, basically by turning left thrice, we can achieve turning right from our initial direction, which is what we intended to do.

And for moveBackward function, it’s pretty straightforward, it’s the same as the player moving backward once, so we have to turn backward first before moving forward.

See? programming is simpler if we already know about the fundamentals.

The Problem With Programming

The hardest part of programming isn’t about the programming itself, it’s the naming convention. Humans have different naming preferences, so this code snippet might be confusing if we work in a big team:

void turnLeft() { } // This is correct
void executeTurnLeft() { } // This is also correct
void turnToLeft() { } // This is also correct
void left() { } // This is correct, even though it's too ambiguous
void turnToLeftDirection() { } // This is also correct

Now you understand what I mean right? because of this, usually every team has their own naming rules, written in their naming convention documentation or something similar.

The second hardest part is when we try to code, but we don’t know what to write in our code, because we don’t know yet what we are going to do to instruct the computer to do something. Usually every developer will gather the information or draw the program flow first before really diving into the code. This is what we call “requirement gathering”.

Last but not least, we might accidentally create a bug that affects the user experience, and this might be an issue, because we need to solve the bug (we call this debugging) and fix the code to ensure smooth user experience. I am pretty sure that all developers have encountered a bug at least once.

That’s all! I just want to share my experience of coding. I have been coding since 2017 and I hope more people will realize that coding isn’t as scary as it looks!

Oh and if you (or your friends) have ever hit a plateau and struggle to learn coding, As a freelance student tutor, I am currently providing a tutoring service to guide students to understand how to code in a very simple way. You can drop an inquiry to kevinjonathan3010[at]gmail.com (Please replace [at] with the actual symbols) if you want to reach me out!