A program needs precise steps
A person may guess what “tidy my list” means. A computer needs rules: which tasks, what order, and what to do in each situation. Source code expresses those rules in a programming language.
AI can help write code, but it may also guess the information you leave out. Breaking a goal into inputs, processing, and outputs is a useful way to think before choosing a language.
Input: product prices. Process: keep products within a budget. Output: a list of qualifying products.
Take this with you · Start with concrete inputs and expected results.
Why are there different languages?
JavaScript is common for webpage interactions, Python for scripts and data processing, and SQL for database queries. Their ecosystems and runtimes differ, but many uses overlap.
Choosing a language means considering where the result will run, what the existing project uses, and which tools are available. Ask AI to inspect an existing project before deciding how to change it.
Changing a webpage button starts with understanding the existing frontend, not automatically creating an unrelated Python project.
Take this with you · Define the goal and environment before selecting an implementation language.
Variables, conditions, and loops
A names a value, such as budget. A selects a branch, such as price <= budget. A applies work repeatedly, such as checking every price in a list.
These often work together: read each price, compare it to the budget, and keep it if it qualifies. Even before understanding every symbol, look for the data, decisions, and repeated steps.
With budget 30 and prices 12, 35, and 20, keep 12 and 20. Change the budget to 40 and the output changes.
Take this with you · Trace code with a concrete input instead of guessing its behavior.
Step through a small program
Predict the output, then check the prices one by one. Change the budget to see how a variable affects conditions and results.
budget = 25 prices = [12, 35, 20, 48, 8] for each price in prices: if price <= budget: keep(price)
Output: []
This runs a fixed filtering algorithm with real calculated results, not arbitrary user code.
A programming habit: compose logic before syntax
Think of programming as combining logical steps: name data, choose actions with conditions, repeat work with loops, and give a sequence a function name. Moving variables around means reading, passing, and transforming data while managing state changes. Track what changes after each step and what stays the same.
Trace inputs, decisions, processing, and outputs in plain language, then express them in code. A filtering idea can transfer between JavaScript and Python, and unfamiliar syntax can be looked up. Languages also differ in type rules, execution, concurrency, and ecosystems: replacing a few symbols does not guarantee equivalent behavior.
Start with an empty result → read 12, 35, and 20 in turn → compare each with budget 20 → keep values no greater than the budget → return [12, 20]. Trace an empty list, equality, and all prices over budget on paper too.
Take this with you · Practice defining rules and tracking data changes, then use syntax to express that logic precisely.
Functions and data structures
A gives a name to a reusable operation. It can take inputs and return a result. Arrays hold ordered collections; objects or dictionaries map names to values; trees represent hierarchies.
The structure you choose affects later operations. A list can be an array of task objects, each with an id, title, and completion status. Stable IDs identify which item to update.
A task might be { id: 7, title: 'Practice adding', done: false }. Completing it finds id 7, changes done, then updates the interface.
Take this with you · Ask how the data is organized before asking for a line-by-line syntax lesson.
High cohesion, low coupling
A is code with a clear responsibility, implemented as functions, a file, or several files. High groups closely related work: filtering owns budget rules, while storage owns persistence and storage errors. Ask whether these pieces tend to change for the same kind of requirement.
Low reduces dependence on another module's internals. A page asks to save a result without choosing the storage format or editing the storage module's private variables. Modules collaborate through an explicit . Dependencies remain, but clearer boundaries make the impact of internal changes easier to control.
If page clicks, batch operations, and scheduled reports each contain their own budget checks and storage details, a rule change sends you hunting. Centralizing filtering and storage lets callers pass data and handle results through known boundaries.
Take this with you · Cohesion concerns related work inside a module; coupling concerns dependencies between modules.
Build with LEGO-like pieces: matching connections enable reuse
LEGO pieces can be combined repeatedly because their shapes and connectors fit. Code benefits from the same clarity: a filter that accepts prices and a budget, then returns qualifying prices, can serve both a shopping page and a daily report. Keeping it independent of page buttons and hidden global state makes more uses possible.
A software connection includes input types, output meaning, errors, and whether work is asynchronous. Replacing local storage with cloud storage can spare callers changes only if these contracts still hold. Waiting and failures must be represented in the interface; cohesion and low coupling do not make arbitrary pieces interchangeable.
Modularity does not mean splitting code into as many pieces as possible. Draw boundaries around real responsibilities and changes, then extract shared work when repeated needs appear. If two uses follow different rules, avoid forcing them into one function full of special switches. A small, clear piece of code can be a good building block.
selectWithinBudget(prices, budget) filters products for a page and purchase records for a report. Both can share it if they accept the same inclusive budget rule; presentation and report formatting stay with their respective callers.
Take this with you · Give a module a focused job and explicit inputs and outputs, then check that a new use accepts its rules.
The building-block bench: what changes with a requirement?
Compare mixed responsibilities with focused modules. Small pieces inside each block represent its work; connections between blocks represent calling contracts.
Responsibilities mixed at every entry
Each entry duplicates checks and accesses storage directly. Rules and storage details live in three places.
Build with focused pieces
Related work stays inside each block; contracts connect blocks. Filtering does not need to know how storage works.
Receive actions · call modules · present results
items → Promise<SaveResult>Encode data · write it · report storage errors
prices + budget → pricesCompare budget · keep matches · return list
In this example, mixed code changes in three storage locations; focused code changes in the storage module. This assumes matching inputs, results, errors, and async behavior, with callers already handling waiting and failure.
[12, 35, 20]Budget: 20selectWithinBudgetprice ≤ budget[12, 20]Shopping pageThis area always uses ≤. Inputs and uses change, but the filter function stays the same; each caller decides how to present the result.
Try both changes and switch to the daily report to complete this observation.
Change impact is a preset architecture illustration; the reuse area runs a real filter. No data is saved and no cloud request is made. This does not estimate real refactoring costs.
How does source code run?
Source code needs suitable execution tools. Compiling transforms code into another form; interpreters and runtimes execute it. Real implementations often combine approaches rather than belonging to two rigid categories.
A accepts text commands. Commands run in a working directory, so location matters. Keep the full error and command location when asking for help.
Running npm run dev in this project's web folder starts the configured development server. The same command outside the project may not work.
Take this with you · For a startup problem, report the system, project directory, command, and full error.
Combine existing tools and keep versions
Libraries provide reusable functionality. Dependencies are the libraries and tools a project requires. Installing them makes them available; differences can change behavior, so projects record their dependencies and versions.
records changes so you can compare and restore versions. Ask AI for small, checkable changes and keep working checkpoints rather than losing track of what changed.
Before adding deletion: inspect the project, preserve the working version, change the feature, and check that adding and completing still work.
Take this with you · Writing code is only part of the job. Running it, inspecting changes, and checking behavior matter too.
The rule keeps prices no greater than a budget of 20. Which of 12, 35, and 20 remain?
Choose an answer before reading the explanation.
Ask AI to add task completion and restoration. Describe the whole interaction.
Think first, then uncover help as needed. Later chapters expect more complete descriptions and clearer checks.
Bring this chapter's context to your AI. Going deeper is optional; you can keep reading without it.
Explain variables, conditions, loops, and functions using packing a bag, one idea at a time.
One approach you can make your own
I'm learning computers and AI-assisted programming from scratch. In this chapter I learned: Programming：Recognize variables, conditions, loops, functions, and data structures；Distinguish languages, runtimes, and dependencies；Translate a vague idea into actions and expected results；Design cohesive, loosely coupled modules and explain what makes reuse possible Explain variables, conditions, loops, and functions using packing a bag, one idea at a time. Check my understanding first. Explain one small question at a time with a concrete example and the limits of any analogy. Ask a scenario question, then adapt to my answer. Distinguish facts, guesses, and uncertainty; suggest hands-on ways to check. Confirm the version before giving tool-specific advice, and don't invent features or references.
Complete this chapter
Mark the sections as read and finish the required activities listed below to record completion. You can visit the next chapter at any time.
Read the original references
This is an introduction. These official resources help you check details and explore further.
MDN · JavaScript GuideMDN · JavaScript modulesMicrosoft Learn · Architectural principlesOne machine can follow your steps. Next, let's make two machines communicate.