Almost everyone has used a program today: an alarm that goes off, a message that arrives, a receipt that works itself out. Very few people, however, have looked closely at what a program actually is and why a machine that understands nothing at all is capable of doing something useful. This lesson answers that question from scratch, assuming no prior knowledge. By the end of it you will know what an instruction is, what the difference is between the code a person writes and the code the processor runs, and why compilers and interpreters exist.

It is the most important lesson of the course, even though it looks like the simplest. Programming is not about memorising odd words: it is about translating a human intention into unambiguous instructions. If that idea settles properly, everything else — variables, loops, functions, objects — is a matter of form. If it does not settle, the rest of the course becomes copying symbols without understanding them.

You will also meet the case study that will stay with us from beginning to end: Alba Studio and its task manager, EasyTask. Everything we learn will be applied to that project, module by module, until we have a complete program.

1. Programming is translating an intention into instructions
2. Instruction, program and source code
3. Hardware and software in one sentence
4. From source code to execution: machine code
5. Compiler versus interpreter
6. What programming is for: automation, problem solving and scale
7. The course case study: Alba Studio and its problem
8. What EasyTask should do
9. First contact with Python: the program's greeting
10. Common mistakes and tips
11. Exercises
12. Conclusion

Imagine asking a colleague: "get the room ready for the meeting". They will understand. They know what a room is, they know what getting it ready means, and they will work out the missing pieces: chairs, projector, water. They have filled in, on their own, a whole set of gaps you never explained.

A computer fills in no gaps. A computer does exactly what it is told, in the order it is told, without interpreting the intention. If you ask it to get the room ready, it will do nothing: it does not know what "ready" means. You have to put it like this:

1. Count how many people are coming.
2. Place that number of chairs around the table.
3. If there is a presentation, switch the projector on.
4. Put out one bottle of water for every two people.

That, and nothing else, is programming: breaking a human intention down into steps so precise that a machine which understands nothing can carry them out and produce the expected result.

Two real skills of the trade follow from that definition:

• Thinking precisely: spotting the gaps a human would fill in unaided, and closing them. What happens if nobody comes? What if thirty people come and there are only ten chairs?
• Expressing that thinking in a language the machine accepts. This part is the most visible one — it is "writing code" — but it is the easier of the two.

Many people believe they cannot program because they are not good at the technical part. Almost always it is the other way round: syntax is learned in weeks, and what takes years to sharpen is precision of thought.

It is worth dismantling straight away the idea that the computer "knows" things. It knows nothing. Its two virtues are:

• Speed: it executes billions of elementary operations per second.
• Literal obedience: it repeats the same instruction a million times without getting tired, without getting distracted and without correcting you.

That literal obedience is a double-edged sword. If your instruction is correct, it will carry it out perfectly a million times. If it is wrong, it will get it wrong perfectly a million times.

Let us pin down three terms we will use throughout the course.

• An instruction is an elementary order the machine can carry out: adding two numbers, storing a value, showing some text on screen, comparing two quantities.
• A program is an ordered set of instructions which, when executed, solve a specific task.
• The source code is the text written by the programmer, in a programming language, expressing that program in a form humans can read.

Source code is stored in perfectly ordinary text files. A Python file is a text file with the extension .py: you can open it with any editor and read it. There is nothing magical inside.

For what we need right now, a very short distinction is enough:

• The hardware is the physical part: processor, memory, disk, screen, keyboard.
• The software is the set of instructions that tell the hardware what to do.

Hardware without software is an expensive object that gets warm. Software without hardware is a piece of text. Programming means writing software; the hardware is supplied by the computer.

Here comes the first piece that surprises newcomers. The processor does not understand Python. Nor does it understand Java, or C, or any language designed for humans. The processor only understands machine code: sequences of binary numbers (ones and zeros) representing very elementary operations.

A fragment of machine code, written out as it is, looks like this:

Nobody writes modern software that way, for obvious reasons: it is unreadable, specific to each processor model and practically impossible to correct. That is why high-level programming languages were invented, letting us write this:

...and leave it to another program to turn it into the corresponding binary sequences. That "other program" is a translator, and there are two families: compilers and interpreters.

Both solve the same problem — getting from source code to something the processor can run — but with different strategies.

• A compiler translates the whole source code in one go, before running it, and produces an executable file in machine code. That executable can then be launched whenever you like, with no further translation. This is the model used by C or Rust.
• An interpreter reads the source code and runs it as it goes, instruction by instruction, without generating a separate executable. This is the model used by Python.

Here is the path taken in each case:

The practical consequences for a learner are these:

For learning, an interpreted language is convenient: you write a line, run it and see the result in two seconds. That short cycle is gold when you are starting out, and it is one of the reasons this course uses Python. The full comparison between languages, with their virtual machines and their in-between cases, is covered in the lesson Programming languages.

There are three reasons why it pays off for an organisation to have someone programming.

Automation. Any repetitive task with clear rules can go from being done by hand to doing itself. Renaming 400 files, sending the same notice to 50 clients, checking every morning whether a server responds. The computer does not get bored and does not skip file 217.

Problem solving. Programming forces you to define the problem precisely, and very often that definition is already half the solution. While writing the program you discover rules nobody had spelled out: what happens if two tasks have the same priority? Can a task have no assignee? Those questions improve the process even if the program never gets written.

Scale. A manual procedure that works with 10 items usually breaks with 10,000. A correct program handles 10,000 items with the same human effort as 10: the cost lies in writing it once, not in running it many times.

Look at the second row: a program going wrong always in the same way is an advantage, not a defect. A reproducible error can be located and fixed. A random human error cannot.

Alba Studio is a small fictional graphic design studio. It is made up of three people:

• Marta, coordinator. She hands out the work and talks to the clients.
• Luis, designer. He mainly handles visual identity.
• Nuria, designer. She looks after layout and printed materials.

Their current way of organising themselves is this: Marta writes each job down on a paper note and leaves it on the desk of whoever it belongs to. It worked well the first year. Not any more:

• Notes get lost. One client's job disappeared under a pile of colour proofs and was delivered nine days late.
• Nobody knows what anyone else has. Marta asks out loud "how are you getting on?" several times a day, interrupting everybody's work.
• There are no explicit priorities. Every note looks equally urgent because they are all written on the same yellow paper.
• No history is kept. When a client asks what was done in March, nobody can answer.

Marta has decided she wants a program to sort this out. She does not want an expensive commercial tool full of options they will never use: she wants something small, their own, and precisely fitted to how they work. That program will be called EasyTask, and it is what we are going to build over the course.

Notice one important detail: Alba Studio's problem is not a computing problem. It is an organisational problem. Programming is merely the tool we will use to tackle it. This is the norm in the real world: software is almost never an end, it is a means.

Before writing anything, it is worth putting down in writing what we expect from the program. This is called defining the requirements, and it is the step most people skip, with predictable results.

After talking to Marta, Luis and Nuria, the list looks like this:

Each EasyTask task will therefore have five pieces of data:

• Title: a short sentence. Example: "Design a logo for Solé Bakery".
• Description: the detail. Example: "Three proposals in black and white, vector format".
• Assignee: Marta, Luis or Nuria.
• Priority: high, medium or low.
• Status: pending or completed.

We are not going to implement any of this yet. Storing data between runs (R6), for instance, belongs to the lesson Saving data to files, at the end of module 5. What is worth doing is keeping the list in front of us: each module of the course will tick requirements off.

We can now write our first line of real code. It will be modest — showing some text on screen — but it is a complete, working program.

In Python, the instruction for showing something on screen is print:

Let us pick that line apart, because every symbol counts:

• print is the name of the instruction. It means "show on screen". It is written in lower case: Print or PRINT would give an error, because Python distinguishes upper case from lower case.
• The parentheses ( and ) enclose whatever we want to show. Both must always be there, an opening one and a closing one.
• The quotation marks " mark the beginning and the end of a piece of text. Everything between quotes is shown exactly as it is, without Python trying to interpret it. Both of these must be there too.

If we run that file, exactly this appears on screen:

No quotes, no parentheses, no print word. Just the text. The quotes tell Python where the text starts and ends, but they are not part of it.

A program can have several instructions, one per line, and they run in order, from top to bottom. This is a complete welcome screen for EasyTask:

And this is what comes out on screen:

Three observations about this example:

1. Order matters. If you moved the first line to the end, the line of = signs would appear at the bottom. Python reorders nothing on its own.
2. Spaces inside the quotes are preserved. That is why " EasyTask v0.1" appears indented: those two spaces are inside the text.
3. print("") with empty quotes shows a blank line. It is the usual way of separating blocks visually.

That is, quite literally, a program. It does little, but it is a complete program: it has instructions, an order and an observable result. How to write it in a file and run it on your own computer is covered in the lesson Development environments.

Believing you need advanced mathematics. For the vast majority of professional software, adding, subtracting, comparing and reasoning logically is enough. What you do need is tolerance for frustration: you will spend a lot of time with programs that do not work, and that is normal, not a sign that you are no good.

Forgetting to close quotes or parentheses. It is the number one error of the first week. print("Hello) does not work because the text is never closed; print("Hello" does not work either, because the parenthesis is missing. Tip: always write both symbols together — () and "" — and then put the content in the middle.

Writing Print instead of print. Python distinguishes upper case from lower case: print, Print and PRINT are three different names and only the first one exists. The same will apply to the names you invent yourself later on.

Confusing "I don't understand the code" with "I don't understand the problem". When you get stuck, first ask yourself whether you would know how to solve it by hand, on paper. If the answer is no, the problem is not Python. Go back to the statement before touching the keyboard.

Wanting to write the whole program in one go. Nobody does. Software is built in layers: something minimal that works, and something else on top. EasyTask starts out as eight print statements and will end up as a complete program, but the road consists of dozens of intermediate versions.

A tip on method: write down the expected result before running. Before launching a program, jot down on paper what you think will come out on screen. If you get it right, you have understood. If it fails, you have just found a gap in your mental model, which is exactly what you were after.

Write, in English and as a numbered list, the instructions a machine would follow to make a cup of tea. The machine knows nothing: it does not know what a cup is, but it can pick up, pour, wait and check. Be so precise that no gap is left to fill in. Then point out at least two gaps a human would fill in unaided and which you have had to spell out.

For each situation, say whether it describes a compiled or an interpreted language, and justify your answer in one sentence:

1. You change a line of the program and launch it again immediately, with no intermediate step.
2. You hand the client a single executable file; the client does not receive your code.
3. The program stops with an error just as it reaches line 80, having correctly run the previous 79.
4. Before you can test anything, you wait 40 seconds for a translation process to finish.

Write a Python program using only print that shows exactly this on screen:

Note the blank line before the last line: it has to be there.

Solution 1.

A sufficiently precise version would be:

1. Check whether there is water in the kettle. If there is not, fill the kettle with 250 ml of water.
2. Switch the kettle on.
3. Wait until the water reaches 95 degrees.
4. Take an empty cup and place it on the worktop.
5. Take a tea bag and drop it into the cup.
6. Pour the water from the kettle into the cup up to 1 cm below the rim.
7. Wait 3 minutes.
8. Take the bag out of the cup and throw it in the bin.
9. Switch the kettle off.

Gaps a human would fill in unaided and which we have had to spell out:

• The amount of water and the temperature. A human understands "hot water"; a machine needs 250 ml and 95 degrees.
• The brewing time. "Let it brew" is not an instruction: 3 minutes is.
• That the cup is empty and in position. Nobody would say out loud "take an empty cup", but the machine could pick up a full one.
• What to do with the bag at the end. If you do not say so, it stays inside.

Bonus: a check is missing. What if there are no tea bags left? A robust program would have to decide what to do in that case. This is called handling exceptional cases and we will work on it in module 8.

Solution 2.

1. Interpreted. There is no prior translation step: the interpreter reads the code and runs it there and then.
2. Compiled. An executable in machine code has been generated, independent of the source code, and it is the only thing distributed.
3. Interpreted. The error appears on reaching line 80, which indicates that lines are processed during execution and were not all checked beforehand.
4. Compiled. Those 40 seconds are the compiler translating the whole program before anything runs.

Solution 3.

Points where people usually slip up:

• Forgetting the print("") for the blank line. Without it, the last two lines come out stuck together.
• Writing print(### EasyTask ###) without quotes. Python would try to interpret those symbols as code and give an error: all literal text goes between quotes.
• Using six lines of content but in a different order. Remember: they run from top to bottom, exactly as written.

Programming is translating a human intention into instructions so precise that an obedient, fast machine which understands nothing can carry them out. That precise text is the source code; the processor, by contrast, only understands machine code, and between the two there is always a translator: a compiler, which translates everything at once before running, or an interpreter, which reads and runs as it goes, as Python does.

We program for three reasons: to automate what is repetitive, to solve problems by forcing ourselves to define them precisely, and to scale, paying the effort once and running it many times. All three show up in the case that will accompany us throughout the course: Alba Studio loses paper notes and needs EasyTask, whose six requirements we already have in writing. And we have written our first real program: a handful of print statements drawing the welcome screen.

None of this, however, appeared all at once. The languages that today let us write print("Hello") instead of sequences of ones and zeros are the result of almost two centuries of attempts, failures and accumulated good ideas. In the next lesson, History of programming, we will walk that road: not as a list of dates, but by understanding what specific problem each stage solved and why the trade is the way it is today.