Part 1: Fundamental Concepts of Computing

1. What Is a Computer & How It Works

What Is a Computer & How It Works

A computer is a machine that follows instructions to store, move, and transform information. It does not "think" the way a person does; instead it performs millions of tiny, exact steps so quickly that the result looks intelligent. Before you write a single line of code, it helps to understand the machine your programs will run on.

Hardware vs Software

Everything about a computer falls into two categories:

• Hardware — the physical parts you could touch: the processor chip, memory sticks, hard drive, keyboard, and screen. Think of hardware as the body.
• Software — the instructions that tell the hardware what to do: the operating system, your web browser, and the programs you will write. Think of software as the knowledge and habits that make the body useful.

A great analogy is a kitchen. The oven, knives, and pans are the hardware. A recipe is the software — a set of instructions. The same kitchen can cook countless dishes depending on which recipe you follow, just as the same computer can run countless programs.

The Core Components

Four kinds of hardware cooperate on every task. Keep these roles in mind — nearly every programming idea eventually connects back to one of them.

The von Neumann Architecture

Almost every modern computer follows a design named after mathematician John von Neumann. Its key idea is simple but powerful: programs and data live together in the same memory. The CPU fetches an instruction from memory, decodes what it means, executes it, and repeats — a loop called the fetch–decode–execute cycle. Information travels between the parts along shared wires called a bus.

How a Task Actually Happens

Imagine you double-click a program. Storage hands the program's instructions to RAM. The CPU's control unit fetches the first instruction, figures out what it means, and directs the ALU (Arithmetic Logic Unit) to do any math or comparison. Results flow back to memory or out to the screen through I/O. This cycle repeats billions of times to produce everything from a moving cursor to a video game.

You now have the mental model that the rest of this course builds on: a computer is a fast, literal instruction-follower that keeps its working data in memory and its permanent data in storage. Programming is simply the craft of writing those instructions clearly enough that this literal machine does exactly what you intend.

2. How Computers Represent Data

How Computers Represent Data

A computer has no concept of letters, colours, or music. Underneath everything it stores and moves numbers, and those numbers are written in a two-symbol system called binary. Understanding this layer removes a lot of the mystery from programming.

Bits and Bytes

The smallest unit of information is a bit — a single switch that is either 0 (off) or 1 (on). A single bit is not very useful, so bits are grouped. Eight bits together form one byte. One byte can represent 256 different values (from 0 to 255), which is enough to store a single character of English text.

Analogy: a bit is like one light switch, which only tells you "on or off". A byte is a row of eight switches — by choosing a pattern across all eight, you can signal 256 distinct messages.

Why Binary?

Computers use binary because electronic circuits are naturally good at two clear states: high voltage or low voltage, current flowing or not. Two states are reliable and cheap to build, so the whole machine is designed around counting in twos instead of the tens we humans use.

Binary Place Values

In our familiar decimal system each column is worth ten times the one to its right (1, 10, 100…). In binary each column is worth two times the one to its right. Here are the place values of one byte:

To read the example, add the place values wherever a bit is 1: 64 + 8 + 4 + 1 = 77. So the binary number 01001101 equals 77 in decimal.

Converting Decimal to Binary

To turn a decimal number into binary, repeatedly ask "does the largest remaining place value fit?" For 77: 128 is too big (0), 64 fits (1, leaving 13), 32 no (0), 16 no (0), 8 fits (1, leaving 5), 4 fits (1, leaving 1), 2 no (0), 1 fits (1). That reproduces 01001101.

Hexadecimal: A Shorthand

Long strings of 0s and 1s are hard for humans to read, so programmers often use hexadecimal (base 16). Hex uses sixteen symbols: 0–9 then A–F (where A=10 … F=15). One hex digit neatly represents exactly four bits, so two hex digits describe one byte.

Text, Images, and Sound Are Numbers Too

• Text: Each character is assigned a number. The old ASCII standard maps A to 65, a to 97, and so on. Modern Unicode extends this to cover every language's characters plus emoji.
• Images: A picture is a grid of tiny dots called pixels. Each pixel stores numbers for its red, green, and blue brightness — typically one byte each, giving millions of possible colours.
• Sound: A microphone measures air pressure thousands of times per second; each measurement is saved as a number. Playing them back in order recreates the sound.

The big takeaway: everything inside a computer — this sentence, your photos, your music — is ultimately just numbers written in binary. When you program, you are arranging and transforming those numbers in meaningful ways.

3. What Is a Program & How Software Runs

What Is a Program & How Software Runs

A program is a set of instructions that tells a computer how to accomplish a task. You write those instructions in a programming language — a carefully defined vocabulary and grammar that is precise enough for a machine to follow, yet readable enough for humans to work with.

Source Code vs Machine Code

The text you type is called source code. It might read print("Hello"). But the CPU only understands machine code — raw binary numbers that correspond to its built-in operations. Something must bridge the gap between the human-friendly source code and the machine-friendly binary. That something is a translator, and there are two main kinds.

Compilers vs Interpreters

A compiler reads your entire source file and translates it, all at once, into a standalone machine-code file that you can then run. A interpreter instead reads and executes your source code line by line, every time the program runs, translating on the fly.

Analogy: a compiler is like translating a whole book into another language and handing over the finished translated book. An interpreter is like a live human interpreter at a meeting, translating each sentence as it is spoken.

Some languages, like Java and modern Python, blend both approaches: source is first compiled to a portable intermediate form, which an interpreter-like "virtual machine" then runs.

High-Level vs Low-Level Languages

• Low-level languages sit close to the hardware. Machine code (pure binary) and assembly (short mnemonics like MOV and ADD) give fine control but are tedious and hardware-specific.
• High-level languages like Python, JavaScript, and Java read much more like English and maths. They hide hardware details so you can focus on solving problems. One line of Python may expand into dozens of machine instructions.

As a beginner you will work in a high-level language — this course uses Python later — precisely because it lets you express ideas quickly without worrying about voltages and memory addresses.

How a Program Runs, Start to Finish

Putting the pieces together: you write source code in a high-level language; a compiler or interpreter translates it toward machine code; the operating system loads that code into RAM; the CPU runs the fetch–decode–execute cycle; and results appear through output devices. Every app you have ever used followed exactly this path.

4. Algorithms: Thinking Step by Step

Algorithms: Thinking Step by Step

An algorithm is a clear, finite sequence of steps that solves a problem or completes a task. Long before computers existed, people followed algorithms: a cooking recipe, directions to a friend's house, or the long-division method you learned in school are all algorithms. Programming is largely the skill of designing good algorithms and then expressing them in code.

What Makes a Proper Algorithm

Not every list of instructions qualifies. A well-formed algorithm has five properties:

• Finite — it must eventually stop; it cannot run forever.
• Definite — each step is precise and unambiguous, with exactly one meaning.
• Inputs — it takes zero or more inputs (the information it starts with).
• Outputs — it produces one or more outputs (the result).
• Effective — every step is simple enough to actually be carried out.

"Add a pinch of salt" is fine for a human recipe but is not definite enough for a computer, which needs exact quantities. Learning to think with this level of precision is one of the most valuable habits in programming.

Worked Example: Making Tea

A friendly, everyday algorithm to warm up the idea:

1. Fill the kettle with fresh water.
2. Switch the kettle on and wait until it boils.
3. Place a tea bag in a cup.
4. Pour the boiled water into the cup.
5. Wait 3 minutes.
6. Remove the tea bag.
7. Add milk or sugar if desired.

Notice it is finite (ends at step 7), definite (each step is clear), has an input (water, tea bag), and an output (a cup of tea).

Worked Example: Find the Largest of Three Numbers

Here is a computing-style algorithm. We keep a "current biggest" and compare it against each new number. Expressed as pseudocode — informal, language-neutral steps:

INPUT a, b, c
SET largest = a
IF b > largest THEN
    SET largest = b
END IF
IF c > largest THEN
    SET largest = c
END IF
OUTPUT largest

Trace it with a=4, b=9, c=2: largest starts at 4; b (9) is bigger, so largest becomes 9; c (2) is not bigger, so largest stays 9; output 9. Correct.

A Flowchart for "Largest of Two"

Algorithms with decisions are often drawn as flowcharts, which you will study next. Here is the simplest comparison as a flowchart:

Why Algorithms Matter

For any problem there are usually many possible algorithms, and they are not equally good. One may be faster, another easier to understand, another more reliable. Great programmers spend much of their thinking time on the algorithm before writing code — because a clear plan written in pseudocode or a flowchart turns the actual coding into a straightforward translation job.

5. Flowcharts & Pseudocode

Flowcharts & Pseudocode

Before writing code, experienced programmers plan their logic in a form that is quick to draft and easy to check. Two planning tools dominate: flowcharts (visual) and pseudocode (textual). Both let you design an algorithm without worrying about the exact rules of a programming language.

Flowchart Symbols

A flowchart is a diagram where each shape has a standard meaning and arrows show the order in which steps happen. The five shapes you will use most often:

When to Use Pseudocode

Pseudocode is a way of writing an algorithm in plain, structured English that resembles code but ignores a language's strict punctuation. It is ideal when the logic has lots of steps, loops, or calculations that would make a flowchart sprawl across the page. Flowcharts shine for showing branching and flow at a glance; pseudocode shines for detailed step-by-step logic. Many programmers sketch a flowchart first for the big picture, then write pseudocode for the tricky parts.

Side-by-Side Example: Is a Number Positive, Negative, or Zero?

The same algorithm expressed both ways. First, pseudocode:

INPUT n
IF n > 0 THEN
    OUTPUT "Positive"
ELSE IF n < 0 THEN
    OUTPUT "Negative"
ELSE
    OUTPUT "Zero"
END IF

And the matching flowchart:

Good Habits

• Keep each step small and do exactly one thing.
• Make every decision a clear yes/no question.
• Check that every path eventually reaches an end.
• Walk through your design with sample inputs (a "dry run") before coding.

Planning with flowcharts and pseudocode costs a few minutes but saves hours of confused debugging. It is the professional habit of thinking before typing.

6. Problem Solving & Computational Thinking

Problem Solving & Computational Thinking

Computational thinking is the mindset that lets you approach any problem the way a computer scientist would — breaking it down, spotting patterns, ignoring irrelevant detail, and writing a clear plan. It is a skill that helps far beyond programming, but it is essential for it. Four pillars form its foundation.

The Four Pillars

• Decomposition — break a big, scary problem into smaller problems you can solve one at a time.
• Pattern recognition — notice similarities and repetition, so you can reuse a solution instead of inventing a new one each time.
• Abstraction — focus on the important details and ignore the rest, creating a simpler model of the problem.
• Algorithmic thinking — design a clear, ordered sequence of steps that solves the problem and can be repeated reliably.

Putting the Pillars Together

Suppose you want to write a program that finds the cheapest flight for a trip. Decomposition splits it into "get the list of flights", "compare their prices", and "report the lowest". Pattern recognition notices that "find the cheapest" is the same shape as "find the smallest number" — a problem you already know how to solve. Abstraction lets you ignore airline logos and seat colours and treat each flight as simply a price. Algorithmic thinking turns it into ordered steps you could write as pseudocode. The hard, fuzzy request has become a clear plan.

A General Problem-Solving Recipe

1. Understand the problem: what are the inputs, and what output do you want?
2. Decompose it into smaller sub-problems.
3. Plan an algorithm for each part (pseudocode or flowchart).
4. Dry run your plan with example values to check it works.
5. Translate the plan into code.
6. Test with many inputs, including tricky edge cases, and fix problems.

Practice Exercises

Try these on paper — describe your approach using the four pillars and write pseudocode. No coding required yet:

• Design steps to find the average of a list of exam scores.
• Describe how you would check whether a word is a palindrome (reads the same backwards).
• Plan an algorithm to make change for a purchase using the fewest coins.
• Decompose the task "organise a birthday party" into sub-tasks, then sub-sub-tasks.
• Spot the repeating pattern in adding up the numbers 1 to 100, and describe a shortcut.

Mastering computational thinking is what separates someone who memorises code from someone who can genuinely solve new problems. Every later topic in this course is an application of these four pillars.

7. Common Algorithms in Action

Common Algorithms in Action

Now that you can describe steps with pseudocode and flowcharts, let's meet the classic algorithms every beginner should know. These small, reusable techniques appear again and again inside real software, so recognising them is a huge head start.

1. Linear Search — Look at Everything

The simplest way to find a value in a list is to check each item from the start until you find it (or run out). This is linear search.

INPUT list, target
FOR each item in list
    IF item == target THEN
        OUTPUT "Found!"
        STOP
    END IF
END FOR
OUTPUT "Not found"

2. Binary Search — The "Guess the Number" Trick

If the list is already sorted, you can do far better. Think of the game where a friend picks a number from 1 to 100 and you guess. A smart player always guesses the middle (50), learns "higher" or "lower", and throws away half the possibilities with every guess. That is binary search: check the middle, then search only the half that could contain the target. A list of 1,000,000 items needs at most about 20 guesses!

3. Finding Max / Min, Summing, and Counting

These "accumulator" patterns keep a running result as they walk through a list — you already saw the idea with "largest of three":

• Max/Min: remember the biggest (or smallest) seen so far, update when you see a better one.
• Sum: start a total at 0 and add each item.
• Count: start a counter at 0 and add 1 whenever an item matches a condition.

4. Bubble Sort — Putting a List in Order

Sorting rearranges a list from smallest to largest. Bubble sort repeatedly compares neighbouring pairs and swaps them if they are out of order; large values "bubble" to the end.

INPUT list
REPEAT
    SET swapped = false
    FOR i FROM 0 TO length-2
        IF list[i] > list[i+1] THEN
            SWAP list[i] and list[i+1]
            SET swapped = true
        END IF
    END FOR
UNTIL swapped is false
OUTPUT list

Here is a trace sorting [5, 1, 4, 2]. Each row shows the list after one full pass:

Why Some Algorithms Are Faster

Two algorithms can both give the correct answer yet take wildly different amounts of work. A useful way to compare them is to ask: as the input grows, how fast does the number of steps grow? Linear search checks items one by one, so doubling the list roughly doubles the work. Binary search throws away half each time, so even a huge list needs only a handful of steps. You do not need heavy mathematics yet — just the intuition that "fewer steps as data grows" means "scales better".

This is why choosing the right algorithm matters so much: the same task can be instant or painfully slow depending on the method. Recognising these classic patterns — search, accumulate, sort — and knowing roughly how they scale is a foundation you will build on for the rest of your programming life.

8. The Software Development Life Cycle (SDLC)

The Software Development Life Cycle (SDLC)

Real software is rarely written in one sitting. Teams follow a repeatable process called the Software Development Life Cycle (SDLC) — a sequence of phases that takes an idea from "wouldn't it be nice if…" all the way to a running, maintained product. Knowing the phases helps you understand where your coding fits into the bigger picture.

The Six Phases

A Real Example

Imagine building a simple to-do list app. Requirements: users want to add, tick off, and delete tasks. Design: sketch the screen, decide each task stores a text and a done/not-done flag, and plan the "mark complete" algorithm as a flowchart. Implementation: write the code. Testing: try adding 100 tasks, deleting the last one, leaving the list empty — does anything break? Deployment: publish the app to a store or website. Maintenance: months later, add a "due date" feature users requested and fix a bug on old phones. Notice how design leaned directly on the flowcharts and algorithms from earlier chapters.

Waterfall vs Agile

There are different ways to move through the phases. The traditional Waterfall model runs each phase once, fully, in strict order — like water flowing down steps. Modern Agile (iterative) approaches do a little of every phase repeatedly in short cycles (often one to four weeks), delivering a small working slice each time and welcoming change.

The SDLC as a Cycle

The word "cycle" is deliberate: after deployment and maintenance, user feedback feeds new requirements, and the loop begins again. Software is never truly "finished" — it grows and adapts.

Where Algorithms and Flowcharts Fit

The Design phase is exactly where the skills from the previous chapters pay off: you use flowcharts, pseudocode, and your knowledge of algorithms to plan a solution before writing code. Good design makes implementation faster and testing easier. The SDLC shows that programming is one important part of a larger, disciplined craft — and that thinking clearly up front is what separates professional software from a pile of hopeful code.