EarniculumAlmost every program, in any language, is doing four things:
- Holding values. A number, a name, a list of orders.
- Changing them. Adding, combining, filtering.
- Deciding. Doing one thing if something is true and another if it is not.
- Repeating. Doing the same work for every item in a collection.
That is close to the whole of it. Everything else is detail, tooling, or a way of organising those four so a large program stays understandable.
Why JavaScript
It runs in every browser without you installing anything, which means the exercises in this course run where you are already sitting. The ideas transfer: variables, functions, conditionals and loops look almost the same in Python, Java, C# or Go, and once you have them you are learning a dialect rather than a language.
How this course works
Short explanations, then you write code. The exercises run in your browser and check your work against tests, so a failure tells you what was expected and what your code actually produced. That gap is the useful part.
You will get things wrong constantly. That is not a sign you are bad at this; it is the activity. Professional programmers spend most of their day with something not working.
Make the lesson usable
Reading JavaScript is a state-tracing exercise. At each line, ask what values exist, which expression is evaluated next, and whether execution continues, branches, repeats, returns, or throws. That method is more reliable than guessing from names or staring at the final output.
Trace before you run
- Choose a short function with an input, one conditional, and a return value.
- Make a table with columns for line number, variable, current value, and next action.
- Predict the result for one ordinary input and one boundary input such as zero or an empty array.
- Run the function and locate the first line where reality differs from your trace.
- Change one input at a time and explain the control-flow change before editing the code.
Check your understanding
01What is an expression?
A piece of code that produces a value.
02Why test a boundary input?
It exposes assumptions that ordinary examples hide, especially around emptiness, zero, and limits.
03What is the first useful debugging question?
At which exact line did actual state first differ from expected state?