Start Here
Before you start
You need: nothing at all. If you have never written a line of code and are not sure what a developer actually builds, this is the right page.
Time: about 20 minutes.
Read this before anything else. Every other page on this site assumes the handful of ideas explained here.
Learning objective
Understand what software is made of, what the school system in every example is, and how to use this site.
Topics
- What an application is made of
- The three parts, in plain terms
- The school system every example uses
- Why one example all the way through
- What you will actually be doing
- How this site is organised
- Words you will meet immediately
What an application is made of
Think about the last time you checked your bank balance on your phone.
You opened an app. You typed a password. A number appeared. That number was not stored on your phone — it lives on a computer in a building somewhere, and your phone asked for it.
Three separate things had to work:
- The screen you looked at — the buttons, the boxes, the layout
- The rules that decided what to do — is this password right? is this person allowed to see this balance?
- The stored information — your account, your balance, every transaction you have made
Almost every application you have ever used is built from those three parts. A food delivery app, a college portal, a railway booking site. Different subjects, same three parts.
A developer builds one or more of those parts. Some people work mainly on screens, some on rules, some on stored information. Some do all three — and that is what this programme trains you for.
The three parts, in plain terms
Because you will meet these words constantly, here they are with the names the industry uses.
| Plain meaning | Industry word | What it is |
|---|---|---|
| The screen you see and click | Frontend | What runs in your browser or phone |
| The rules that decide what happens | Backend | A program on a server that answers requests |
| The stored information | Database | An organised store the backend reads and writes |
An example, end to end. A school clerk types a student's roll number and presses Search:
The screen collects "NCA-2024-0012" and asks for that student
↓
The rules check the clerk is allowed to see this student,
then ask the store for the matching record
↓
The stored data finds the row and sends it back
↓
The rules pick the fields the clerk may see
↓
The screen displays the student's name and class
That round trip is the shape of nearly everything you will build. When something goes wrong, the skill is knowing which of those steps broke — and that is a large part of what this programme teaches.
The school system every example uses
Here is the thing to know before you open any other page.
Every code example on this site is part of one imaginary application: a school management system for a school called NexCoding Academy. Not a different example on every page — the same system, built up piece by piece across six months.
What the system does:
| It manages | Meaning |
|---|---|
| Students | Names, roll numbers, class and section, parent contact |
| Teachers and staff | Who works there, what they teach, their employee code |
| Subjects | Maths, Science, English, and which teacher takes each |
| Exams and results | Marks for each student in each subject |
| Fees | What is owed, what has been paid, receipts |
| Attendance | Who was present on which day |
The people you will keep meeting are made up, and they recur so that examples connect to each other:
Students Ravi Kumar, Priya Sharma, Arjun Reddy, Sneha Patel, Kiran Rao
Teachers Dr. Mehta (Maths), Mrs. Rao (Science), Mr. Sharma (English)
The school NexCoding Academy — short code NCA
Roll numbers NCA-2024-0012 and similar
So when a page says "Ravi Kumar has paid ₹12,000 of ₹15,000", that is not a random example — it is the same Ravi Kumar from the page before, and the fee module you will eventually build yourself.
Why one example all the way through
It would be easier to write a page about calculating averages using shapes, and the next page about storing information using pets. Many sites do exactly that.
This one does not, for three reasons.
You stop learning the example and start learning the idea. By page thirty you know what a student and a fee account are, so a new page can spend all its effort on the actual new thing rather than re-establishing a scenario.
The problems connect. A decision made in the database chapter causes a bug in the screen chapter, and you get to see that happen. That is what real work is like, and disconnected examples cannot show it.
You finish with one thing you built. After six months you have a working school system, not thirty unrelated exercises. That matters enormously when someone asks what you have made — which is the subject of Article 09.
One honest note: a school system is not glamorous. It was chosen because everyone already understands schools — you know what a student, a subject and a fee are without being told, so none of your effort goes on understanding the scenario.
What you will actually be doing
Not watching videos. The work is:
| You will | Roughly |
|---|---|
| Read an article, typing out the examples yourself | 35 minutes a day |
| Practise — exercises where you write your own code and get it wrong | 50 minutes a day |
| Build — add a piece to your own school system each week | Weekends |
| Save your work so there is a record of what you did | Every day, a few minutes |
Typing the examples matters more than it sounds. Copying and pasting teaches almost nothing. You will make small mistakes, the computer will complain, and reading those complaints is a genuine skill you are building from day one.
You will be stuck often. That is not a sign you are unsuited to this; it is the job. Experienced developers are stuck most of the day too — they are just faster at getting unstuck, and this programme teaches that as an explicit skill.
How this site is organised
Eighteen tracks, each covering one subject — the C# language, databases, the browser, and so on. Each track is a folder of articles you read in order.
This playbook is track number 00, and it is the guide to the other eighteen. It tells you which to take, in what order, at what pace, and how to turn it into a job. It does not teach programming itself.
Every article has the same shape, so you always know where you are:
| Section | What it is for |
|---|---|
| Before you start | What you need to know first, and how long it takes |
| Topics | What is covered |
| The body | The actual teaching |
| Errors you will hit | The exact messages you will see, and what they mean |
| Common mistakes | What people get wrong |
| Practice | Exercises. This is where the learning happens |
| You can now | A checklist to tick off |
When you meet a word you do not know, check the glossary. It is written for someone at your stage and you can return to it whenever you like.
Words you will meet immediately
Enough to get through the next few pages. The glossary has the rest.
| Word | What it means |
|---|---|
| Code | The instructions you write for a computer to follow |
| Program or application | A complete set of those instructions that does something useful |
| Bug | A mistake in the code that makes it behave wrongly |
| Debugging | Finding and fixing a bug |
| Frontend | The part you see and click |
| Backend | The part on a server that decides what happens |
| Database | Where information is stored so it survives after you close the app |
| Server | A computer, somewhere else, that runs the backend |
| Codebase | All the code that makes up one application |
| Developer | The person who writes and changes it |
You do not need to memorise these. They will become familiar through use, which is faster and lasts longer than memorising.
Common mistakes
- Skipping to the code because this page has none
- Believing you must already be "good at computers" — you do not
- Expecting to understand everything on first reading. You will not, and that is fine
- Copying and pasting the examples rather than typing them
- Thinking being stuck means you are not suited to this
- Trying to memorise the vocabulary instead of letting it become familiar
Practice
- Open an app you use often. Name its three parts: the screen, the rules, the stored information.
- Think of something that app stores about you. That is its database.
- Read the school system table again and write down, in your own words, what the system does.
- Explain the three parts to someone who does not work in technology. If they follow it, you have it.
- Look at the ten words above. Which three were new? Note them; you will meet them within an hour of reading.
- Open the glossary and skim it. Do not study it — just know where it is.
You can now
- Name the three parts of an application in plain language
- Say what frontend, backend and database mean
- Describe what the NexCoding Academy school system manages
- Say why one example runs through the whole site
- Describe what your study time will actually be spent on
- Find the glossary when a word is unfamiliar
Review questions
- What are the three parts almost every application is built from?
- Where does the information go when you close an app and reopen it later?
- Why does this site use one school system for every example instead of many different ones?
- What should you do when you meet a word you do not recognise?
Next: Your first tech job