Introduction

Programming begins with a simple human ability: giving instructions.

You already do this in ordinary life. A recipe says, “mix the flour and water, then bake for 25 minutes.” A travel plan says, “take the train to the city center, then walk two blocks.” A checklist says, “if the document is finished, send it; otherwise, revise it.”

Programming is the same kind of activity, but with one important difference: the instructions are written for a computer, and computers follow instructions with extreme literalness. They do not understand hints, intentions, or “you know what I mean.” They do exactly what the program says, according to the rules of the programming language and the system running it.

That is why programming can feel strange at first. It is not because programming requires mysterious talent. It is because it asks you to practice a precise kind of thinking: breaking a task into small steps, naming information clearly, checking assumptions, and improving the result when something does not work.

This book is about learning that kind of thinking from the ground up.

A program is a set of instructions that a computer can run. The written form of those instructions is called code. When you write code, you are not merely typing symbols; you are describing a process. This view of programs as descriptions of processes is central in classic computer science education, including Abelson and Sussman’s presentation of programming as a way to control complexity through procedures and abstraction (Abelson, Sussman, and Sussman 1996).

Here is a tiny example in Python, the language this book will use for most examples:

print("Hello, world!")

This program asks the computer to display the text:

Hello, world!

At first, this may look almost too small to matter. But it already contains several important ideas. The word print names an action. The text inside quotation marks is data, meaning information the program works with. The parentheses show what information is being given to the action. Even a one-line program has structure.

Programming grows by combining small ideas like these.

Why learn to code?

People learn programming for many reasons. Some want to build websites, mobile apps, games, or data tools. Some want to automate repetitive office work. Some want to understand technology more deeply. Some want a new career. Some simply enjoy the satisfaction of making something work.

All of these are valid reasons.

But the deeper value of programming is that it teaches you how to turn a vague goal into an exact working process. Suppose your goal is:

I want to organize my monthly expenses.

A human understands the general intention. A computer needs something more precise:

1. Read a list of expense records.
2. Separate each record into date, category, and amount.
3. Add the amounts in each category.
4. Display the totals.
5. Save the result.

This step-by-step method is called an algorithm. An algorithm is not necessarily code. It is a precise method for solving a problem. You can write an algorithm in ordinary language, in a diagram, in pseudocode, or in a programming language. Later in the book, you will learn how to design algorithms carefully, test them, and reason about whether they solve the intended problem.

This habit is part of what computer scientist Jeannette Wing called computational thinking: formulating problems and solutions in ways that can be carried out by an information-processing agent, whether human or machine (Wing 2006). For our purposes, that means learning to ask questions such as:

• What information do I have?
• What information do I need?
• What steps transform the input into the output?
• What should happen when something unexpected occurs?
• How can I check that the result is correct?

These questions are useful far beyond programming, but programming makes them concrete because your answer must eventually run.

Programming is not memorizing commands

A common beginner mistake is to treat programming as memorization: “I need to remember every command.” That is not how good programmers work.

Professional programmers forget details all the time. They look up documentation. They read examples. They test small pieces of code. They make mistakes, observe the results, and adjust. What matters is not memorizing every feature of a language. What matters is building a reliable mental model of what the computer is doing.

A mental model is your internal explanation of how something works. For example, imagine a variable:

age = 36

A weak mental model says, “This is some Python syntax I must remember.”

A stronger mental model says, “The name age now refers to the value 36, so later code can use that name instead of writing the number directly.”

That difference matters. With the stronger model, the next line makes sense:

print(age + 1)

You can predict that the program will display:

37

This book will repeatedly ask you to predict what code will do before running it. Prediction is one of the best ways to strengthen your mental model. If your prediction is wrong, that is not failure. It is information. It shows exactly where your current understanding can improve.

The computer is fast, not wise

Computers are often described as “smart,” but in ordinary programming it is more helpful to think of them as fast, obedient, and literal.

If you write:

print("2" + "3")

Python displays:

23

Why not 5? Because "2" and "3" are written as text, not numbers. The quotation marks matter. Python follows the rules for combining text strings, so it joins them together.

If you write:

print(2 + 3)

Python displays:

5

The difference is small on the page but large in meaning. Programming requires attention to such distinctions. Over time, this attention becomes natural. You learn to notice whether something is a number, a piece of text, a true-or-false value, a list, a file, or an object with its own behavior.

These categories are called types. A type tells us what kind of value something is and what operations make sense for it. You will study values, types, and variables in Chapter 4, after you have written a few first programs.

You will learn by building small pieces

This book follows a gradual path. It does not begin with large applications, frameworks, or complicated tools. Instead, it starts with the core ideas that make all programming possible:

• instructions
• values
• variables
• input and output
• decisions
• repetition
• collections of data
• functions
• errors
• files
• tests
• program design

Each chapter adds one or two important ideas and connects them to what came before. This matters because programming knowledge is cumulative. A loop is easier to understand after you understand variables and conditions. Functions are easier to understand after you have written repeated code and felt the need to organize it. Testing becomes meaningful after you have enough code that you want confidence when changing it.

The goal is not to rush. The goal is to build stable understanding.

For example, later you might write a small program that asks for a temperature in Celsius and converts it to Fahrenheit:

celsius_text = input("Temperature in Celsius: ")
celsius = float(celsius_text)
fahrenheit = celsius * 9 / 5 + 32
print("Temperature in Fahrenheit:", fahrenheit)

This short program already uses several ideas:

• input reads text from the user.
• float converts text into a decimal number.
• celsius and fahrenheit are variables.
• *, /, and + perform arithmetic.
• print displays the result.

If this feels like a lot, that is normal. You are not expected to understand every line yet. By the time you reach the relevant chapters, each piece will have been introduced carefully.

Errors are part of the work

Sooner or later, every programmer sees an error message. Beginners often read error messages as personal judgment: “I failed.” Experienced programmers read them as evidence: “The system is telling me where to investigate.”

Consider this broken program:

name = input("What is your name? ")
print("Hello, " + Name)

This program uses name on the first line but Name on the second line. Many programming languages, including Python, treat uppercase and lowercase letters as different. So name and Name are not the same name.

The error is not mysterious. The program is simply more literal than a human reader. A human may guess the intention. The computer follows the exact spelling.

Debugging means finding and fixing problems in a program. In this book, debugging will not be treated as an emergency skill used only when something goes wrong. It is part of normal programming. You will learn to reproduce a problem, read the error message, inspect the values in the program, isolate the cause, test the fix, and prevent the same kind of mistake from returning.

This attitude is important. Reliable software is not created by never making mistakes. It is created by using methods that reveal mistakes early and make them easier to correct.

Code is written for people too

A computer runs code, but people must read it. Often the most important reader is your future self.

These two programs do the same calculation:

x = 80
y = 0.15
z = x * y
print(z)

price = 80
tax_rate = 0.15
tax_amount = price * tax_rate
print(tax_amount)

The second version is easier to understand because the names explain the meaning of the values. Good code is not only code that works. Good code is code that can be understood, checked, changed, and trusted.

This is why the book includes chapters on functions, testing, version control, refactoring, and readability. Those topics may sound advanced now, but they are not separate from “real programming.” They are how programmers keep code useful as it grows.

What this book expects from you

This book assumes no previous programming experience. It does assume patience, attention, and willingness to practice.

You do not need to be “a math person” to begin. Some areas of programming use advanced mathematics, but the foundations of coding are mostly about logic, structure, and careful problem solving. You will use arithmetic, comparisons, and simple reasoning. When a mathematical idea appears, it will be explained from the beginning.

You also do not need to understand computers deeply before writing programs. You will learn enough about files, folders, terminals, interpreters, libraries, and databases as they become useful. The book will avoid hiding important ideas, but it will introduce them in an order that supports learning.

Here is the most important habit to bring:

Do not only read code. Run it, change it, predict it, and explain it.

When you see an example, try small experiments:

• Change a number.
• Change a word.
• Remove a line and observe the error.
• Add a new line.
• Predict the output before running the program.
• Explain the result in ordinary English.

For example, if you see:

count = 3
count = count + 1
print(count)

ask yourself: why does this print 4? The line count = count + 1 does not mean “count is equal to count plus one” as a timeless mathematical statement. In programming, assignment means: compute the value on the right side, then store or bind that result using the name on the left side. The old value of count is used to compute the new value.

That is the kind of careful distinction this book will help you build.

Where we are going

The journey begins with the question “What is programming really?” Then you will set up your coding environment and write your first programs. From there, you will learn how programs store information, interact with users, make decisions, repeat work, organize data, and break large tasks into functions.

After the foundations, you will learn practical skills that make programs more reliable: debugging, error handling, testing, documentation, and version control with Git. Then you will build larger programs that work with files, web APIs, and databases. Near the end, you will study code quality and refactoring: improving code without changing what it does.

The final goal is not merely to finish exercises. The goal is to become the kind of beginner who can continue independently: able to read documentation, ask precise questions, test ideas, build small useful tools, and keep learning.

Programming is a craft. You learn it by thinking, making, observing, and improving. Let us begin from the first principle: a program is a precise description of work we want a computer to perform.

References

Abelson, Harold, Gerald Jay Sussman, and Julie Sussman. 1996. Structure and Interpretation of Computer Programs. 2nd ed. Cambridge, MA: MIT Press.

Wing, Jeannette M. 2006. “Computational Thinking.” Communications of the ACM 49 (3): 33–35. https://doi.org/10.1145/1118178.1118215.