What to Do Before You Start Coding: The Foundations Most Beginners Skip

You decide to learn to code. You open YouTube. You find a video titled "Learn JavaScript in One Hour." You start watching. The instructor types something into a terminal. Letters appear on a screen. They say "now let us fetch data from an API." You do not know what an API is. They say "the server returns a JSON response." You do not know what a server is or what JSON means. But the instructor is moving on, and you feel like you should understand this, so you keep watching.

By minute 30, you are copying code you do not understand into an editor you just downloaded. By minute 45, you have an error message that makes no sense. By the end, you close the laptop and think: "I am not smart enough for this."

You are smart enough. The tutorial failed you, not the other way around. It assumed you already understood a layer of knowledge that nobody taught you. And this is not one tutorial. This is almost every beginner coding resource on the internet. They all start at the wrong place.

The right place to start is not code. It is the world that code operates in.

When you type "google.com" into your browser and press Enter, a dozen things happen in under a second. Your browser asks a DNS server for Google's IP address. It sends an HTTP request to that IP address. Google's server receives the request, processes it, and sends back an HTTP response containing HTML, CSS, and JavaScript. Your browser receives that response and renders the page.

If none of that paragraph made sense, that is exactly why you need this foundation before writing code.

As a developer, you will write code that runs in browsers, code that runs on servers, and code that sends requests between them. If you do not understand the request-response cycle, every piece of code you write exists in a vacuum. You will memorise syntax without understanding purpose.

What you need to understand:

• DNS (Domain Name System): the internet's phone book, translating domain names into IP addresses
• HTTP/HTTPS: the protocol (set of rules) for how browsers and servers communicate
• Requests and responses: the browser asks, the server answers
• URLs: what each part of a web address means
• The difference between the internet and the web: the internet is the infrastructure, the web is one application running on it

You do not need to memorise technical specifications. You need a working mental model: "when I visit a website, my browser sends a request to a server, and the server sends back the page." That one sentence clarifies dozens of coding concepts you will encounter later.

The client-server model is the backbone of almost everything you will build as a web developer.

Client: the application the user interacts with directly. Usually a web browser, but also mobile apps, desktop apps, or even another server.

Server: a computer (running software) that waits for requests, processes them, and sends back responses. It stores data, handles business logic, and serves files.

Why this matters for coding: when you eventually learn front-end development (React, HTML, CSS, JavaScript in the browser), you are writing code that runs on the client. When you learn back-end development (Node.js, Express, databases), you are writing code that runs on the server. If you do not understand this split, you will be confused about where your code runs, why certain code works in one place but not another, and how data moves between the two.

A common beginner confusion: "Why can my JavaScript code access the user's browser but not the database directly?" Because browser JavaScript runs on the client, and the database lives on the server. They are separate computers. The client has to ask the server (via an API) to get database data. Without the client-server mental model, this restriction feels arbitrary and confusing. With the model, it is obvious.

API stands for Application Programming Interface. In plain language: it is a way for one program to talk to another program.

When your weather app shows today's temperature, it is not measuring the weather. It is calling a weather API, sending a request that says "what is the temperature in Nairobi?" and receiving a response with the data. When you log in with your Google account on a third-party website, that website is using Google's authentication API. When M-Pesa processes a payment in an app, the app is calling the Daraja API.

APIs are everywhere. As a developer, you will:

• Call other people's APIs (getting weather data, processing payments, sending SMS messages)
• Build your own APIs (so your front-end can talk to your back-end, or so other developers can use your service)

The concept is simple: one program asks, another program answers, using a standard format. But if you do not understand this before starting to code, every time a tutorial says "fetch data from the API," you will be lost.

Understanding APIs also helps you understand why certain things are possible and others are not. "Can my website access the user's phone contacts?" Only if there is an API for that. "Can my app send an M-Pesa payment?" Yes, because Safaricom provides the Daraja API for that purpose. The API is always the bridge.

When your browser receives HTML, CSS, and JavaScript from a server, it does not just display raw text. It goes through a rendering process:

1. It parses the HTML and builds a DOM (Document Object Model), a tree structure of every element on the page
2. It parses the CSS and figures out how each element should look
3. It combines the two and paints the page on your screen
4. It runs any JavaScript, which can modify the DOM and CSS, changing what you see

Why this matters: as a front-end developer, you are writing code that manipulates this process. JavaScript "manipulates the DOM" means it changes the tree structure the browser built from your HTML. CSS "cascading" means styles inherit and override in a specific order. If you understand the rendering process, these concepts click. If you do not, they feel like arbitrary rules to memorise.

You also need to know that browsers are the runtime environment for front-end code. Your JavaScript runs inside the browser, not on a server, not on your desktop. This determines what your code can and cannot do. Browser JavaScript can change the page, respond to clicks, and make API calls. It cannot access files on the user's hard drive, connect to databases directly, or run system commands. Knowing this boundary prevents a lot of confusion later.

A database is where applications store data permanently. When you create an account on a website, your email and password are saved in a database. When you post a photo, the metadata goes in a database. When you check your bank balance, the balance comes from a database.

Without databases, every web page would be static, the same content for everyone, with no memory of who you are or what you did. Databases are what make applications personal, dynamic, and useful.

At this stage, you do not need to learn SQL or know the difference between PostgreSQL and MongoDB. You need to understand the concept: applications need a place to store and retrieve data, and that place is a database that lives on the server.

This understanding prevents a common beginner mistake: trying to store data in front-end code. "I will save the user's information in a JavaScript variable." That data disappears when the user closes the tab. Permanent storage requires a database on the server. When you understand this, the need for back-end development and databases becomes obvious instead of seeming like an unnecessary complication.

Beyond the technical concepts, there is a way of thinking that experienced developers have and beginners usually do not. It is not about intelligence. It is about approach.

Breaking problems into smaller pieces. A beginner looks at "build a to-do list app" and feels overwhelmed. A developer breaks it into pieces: "I need a way to add items, display items, mark items as done, and delete items." Each piece is solvable. The whole thing feels impossible until you decompose it.

Reading error messages instead of panicking. Error messages look intimidating, but they are usually telling you exactly what went wrong and where. Learning to read them calmly and extract the useful information is a skill you develop before writing much code.

Searching effectively. Developers search for solutions constantly. The skill is in knowing what to search for. "JavaScript not working" gets you nowhere. "TypeError: Cannot read property of undefined JavaScript" gets you the answer in seconds. This is a learned skill, not an innate one.

Accepting that confusion is part of the process. Every developer, including senior ones with 15 years of experience, encounters things they do not understand. The difference is that experienced developers know the confusion is temporary and have strategies for working through it. Beginners interpret confusion as evidence that they are not cut out for this. Knowing that confusion is normal (and expected) before you start coding reframes the entire experience.

You have two options:

Option 1: Structured course. Tech Foundations: Before You Code (KES 2,999) covers all six foundations above in a structured, self-paced format designed for people with zero technical background. It is the fastest and most reliable way to build these mental models because the content is sequenced correctly and you do not have to piece together information from 20 different sources.

Option 2: Self-study. You can learn these concepts through free resources. Search for "how the internet works for beginners," "client-server model explained," and "what is an API simple explanation." The information exists. The challenge is that it is scattered, sometimes contradictory, and you will not know what you do not know. You might think you understand APIs but miss a key concept that trips you up later.

Either way, spend 1 to 2 weeks here before touching code. It feels slow. You want to start building. But this patience pays compound interest. Every coding concept you learn after this will click faster because it has a mental model to attach to.

Start with a free McTaba Academy account to preview the material and see if the structured approach works for you.

After you understand how the web works, the sequence is: HTML, then CSS, then JavaScript, then frameworks, then back-end, then deployment. We lay out the full path in the right order to learn coding and the step-by-step starting guide at where to start learning to code.

But here is the point: those articles will make much more sense after you have the foundations. The reason to read this article first is so that when someone says "learn HTML," you know what HTML does and where it fits. When someone says "build a REST API," you know what an API is. When someone says "deploy to a server," you know what a server is.

The foundations are the difference between following instructions you do not understand and learning a skill you can apply independently. One leads to tutorial dependency. The other leads to actual capability.