AP Computer Science Principles

The big picture

A computer is a machine that follows instructions to work with information, and a program is just a list of those instructions written for the computer to follow. This whole course is about how that works: how instructions are written, how information is stored, and how computing changes the world. You do not need any prior experience; every idea is explained from the ground up.

Key idea: a computer follows instructions to process information, and a program is the list of instructions.

What is a computer, really?

When people hear "computer" they picture a laptop, but the word is much broader. A computer is any device that can store information and follow step-by-step instructions to change it. That includes phones, game consoles, the chip in a microwave, and the system in a car. The instructions can be swapped out, which is what makes a computer so powerful: the same physical machine can run a game one minute and do your homework the next, simply by loading different instructions.

Think of a computer like a player piano. The piano is the same machine every time, but feed it a different paper roll of holes and it plays a different song. A computer is the piano, and a program is the roll of instructions that tells it what to do.

Key idea: the hardware stays the same while the program changes, so one machine can do countless different jobs.

What is a program?

A program is a sequence of instructions that tells a computer what to do, written in a special language the computer can carry out. When you open an app, you are running a program that someone wrote. Programming, also called coding, is the act of writing those instructions. A programmer is a bit like a recipe author: they write clear, ordered steps so that anyone (or any machine) that follows them exactly gets the intended result.

Here is the important part for this course: writing a program is a creative act. There is almost never a single "correct" program. Just as two authors can write very different stories about the same idea, two programmers can solve the same problem in very different ways, each making choices about how to structure and express the solution.

Key idea: a program is an ordered set of instructions, and writing one is a creative act with many valid solutions.

The five Big Ideas

AP Computer Science Principles is organized around five Big Ideas. They are the five lenses this course keeps returning to, and every module lines up with one of them.

Big Idea	What it is about
Creative Development	How programs are designed, built, tested, and improved, often by teams
Data	How computers store and process numbers, text, images, and sound, and what data reveals
Algorithms and Programming	The building blocks of code and the step-by-step methods that solve problems
Computing Systems and Networks	How the Internet and connected devices move information around the world
Impact of Computing	How computing helps and harms people and society

These are not separate subjects to memorize; they overlap constantly. A weather app touches every one of them: it stores data, runs algorithms, sends information over a network, was built by a team, and affects the people who rely on it.

Key idea: the five Big Ideas are five connected lenses on computing, not five isolated topics.

Computing is for everyone

A common worry is that you have to be a "math genius" to study computing. You do not. The most valuable skills here are the ones you already practice: breaking a big problem into smaller pieces, following and giving clear instructions, and staying patient when something does not work the first time. Computing is a human, collaborative field, and its most interesting problems are solved by people with many different strengths, not by lone geniuses.

Key idea: the core skills of computing are problem breaking, clear instructions, and patience, which anyone can build.

Common misconceptions

• "A computer is smart and understands what I mean." A computer follows instructions exactly and literally; it has no understanding. If your instructions are slightly wrong, it does the wrong thing without noticing, which is why precision matters so much.
• "You must be a math genius to code." Programming leans far more on logical thinking and persistence than on advanced math. Plenty of strong programmers found math ordinary in school.
• "There is one right program for each problem." Almost every problem has many valid solutions that differ in style, speed, and clarity. Programming is a design activity with real choices.
• "Computers can only be laptops and phones." Any device that stores information and follows instructions is a computer, including the chips inside appliances, cars, and toys.

Recap

• A computer is any device that stores information and follows step-by-step instructions.
• A program is an ordered list of instructions; writing one is a creative act.
• The same hardware can do many jobs because the program can be changed.
• The course is organized around five connected Big Ideas.
• Computing rewards clear thinking and persistence, and it is open to everyone.

Sources

1. College Board, "AP Computer Science Principles Course and Exam Description," Big Ideas overview. find source ↗
2. Code.org ↗, "AP Computer Science Principles," unit introductions.
3. Khan Academy, "Computers and the Internet" unit. khanacademy.org ↗
4. MDN Web Docs, Glossary entries for "Computer programming." find source ↗

The big picture

Real software is almost never written perfectly in one straight shot. It is built in small loops of planning, coding, testing, and improving, usually by a team rather than one person. Understanding this process makes programming far less intimidating, because you no longer expect to get everything right on the first try.

Key idea: programs are developed in repeating cycles of design, build, test, and improve.

The development process is a loop

Developers follow an iterative process, which simply means they repeat a cycle many times, improving the work a little each round. A rough version of the cycle looks like this:

1. Investigate and plan: understand the problem and decide what the program should do.
2. Design: sketch how it will work before writing any code.
3. Build: write the actual instructions.
4. Test: run it, look for mistakes, and check it against the goal.
5. Reflect and revise: fix problems and improve the design, then loop back.

Think of it like writing an essay. You do not produce a polished final draft in one pass; you outline, write a rough draft, reread it, and revise, often several times. Software grows the same way, one improved draft at a time.

Key idea: good programs, like good essays, come from drafting and revising, not from a single perfect attempt.

Why collaboration matters

Most real programs are too big for one person, so they are built by teams. Collaboration means people working together, and it makes software better for concrete reasons. Different people notice different bugs, bring different ideas, and catch each other's blind spots. A feature that seems obvious to the person who wrote it may confuse everyone else, and a teammate is the one who says so before users do.

Working well with others is a genuine skill. It includes explaining your thinking clearly, listening to feedback without taking it personally, giving credit, and dividing a large job into pieces different people can build at the same time. The AP course treats collaboration as a core practice, not an afterthought.

Key idea: teams build better software because different people catch different problems and contribute different ideas.

Managing shared work

When several people edit the same project, they need a way to combine their changes without overwriting each other. Programmers use version control systems that track every change, remember who made it, and let people merge their work together. If a new change breaks something, the team can look back through the history and even return to an earlier version. You can picture version control as a detailed undo history for an entire project shared by the whole team.

Key idea: version control lets a team combine everyone's changes safely and roll back mistakes.

Design tools: plan before you code

Experienced programmers plan before they type, because fixing a flaw in a sketch is far cheaper than fixing it in finished code. Two common planning tools are worth knowing:

• Flowcharts are diagrams that show the steps of a program as boxes connected by arrows, with diamond shapes for decisions. They make the flow of a program visible at a glance.
• Pseudocode is a plain-language sketch of the steps, written loosely like code but readable by any human. It lets you think through the logic without worrying about exact syntax.

For example, before coding a program that greets a user, you might write pseudocode: "ask for the user's name; if a name was given, print Hello plus the name; otherwise print Hello, stranger." That is not real code, but it captures the plan clearly enough to build from.

Key idea: flowcharts and pseudocode let you get the logic right before committing to real code.

Program purpose and requirements

Every program should start with a clear purpose: the problem it solves or the need it meets. From the purpose come requirements, the specific things the program must do. Writing these down first keeps a project focused and gives you a way to judge, at test time, whether the program actually works. A program with no stated purpose tends to drift and sprawl.

Key idea: a clear purpose and written requirements keep development focused and make success measurable.

Common misconceptions

• "Good programmers write finished code on the first try." Even experts loop through drafts, tests, and revisions. Expecting a perfect first attempt sets you up to feel like a failure at a normal part of the job.
• "Planning is a waste of time; just start coding." A few minutes of pseudocode or a flowchart usually saves hours, because logic mistakes are far cheaper to fix in a sketch than in built code.
• "Collaboration just slows things down." Coordination has a cost, but teams catch more bugs and produce better designs than a lone coder on any sizable project.
• "Version control is only for huge companies." Even a solo beginner benefits from a saved history that lets them undo mistakes and see how a project changed.

Recap

• Development is an iterative loop: investigate, design, build, test, reflect, repeat.
• Collaboration improves software because different people catch different problems.
• Version control combines a team's changes and lets them undo mistakes.
• Flowcharts and pseudocode plan the logic before real code is written.
• A clear purpose and written requirements keep a project focused and testable.

Sources

1. College Board, "AP Computer Science Principles CED," Big Idea 1: Creative Development. find source ↗
2. Code.org ↗, "AP CSP," Unit on program development and collaboration.
3. Khan Academy, "Intro to programming" process materials. khanacademy.org ↗
4. MDN Web Docs, Glossary entries for "Pseudocode" and version control basics. find source ↗

The big picture

Every programmer writes code that does not work at first. Mistakes in programs are called bugs, and finding and fixing them is called debugging. Learning the kinds of bugs and how to hunt them down turns a frustrating mystery into a calm, step-by-step search.

Key idea: bugs are normal, and debugging is a skill you can learn, not a sign that you are bad at coding.

Why "bug"?

The word bug for a defect is old, but a famous story cemented it in computing: in 1947 engineers found an actual moth stuck in a room-sized computer and taped it into the logbook as the "first actual case of bug being found." Today a bug means any mistake in a program that makes it behave wrongly. There are three main kinds, and telling them apart is the first step to fixing them.

Key idea: a bug is any defect that makes a program behave incorrectly, and there are three common kinds.

Syntax errors

A syntax error breaks the grammar rules of the programming language, so the computer cannot even understand the instruction. It is like a sentence with the punctuation so mangled that no one can read it. Forgetting a closing quotation mark or bracket is a classic example. The good news is that syntax errors are usually the easiest to fix, because the computer refuses to run and often points to the line where it got confused.

For instance, writing print("Hello) with a missing closing quote is a syntax error; the language cannot tell where the text is supposed to end.

Key idea: a syntax error breaks the language's grammar, so the program will not run until it is fixed.

Runtime errors

A runtime error happens while the program is running. The grammar was fine, so it started, but then it hit something impossible and crashed. A well-known example is dividing a number by zero, which has no answer, so the program stops. Runtime errors are like a recipe that reads correctly until step five tells you to add an ingredient you do not have; you cannot continue.

Key idea: a runtime error appears while the program runs, when it tries to do something impossible and crashes.

Logic errors: the sneaky kind

A logic error is the trickiest, because the program runs happily and produces an answer, but the answer is wrong. There is no crash and no complaint; the instructions were simply not what you meant. Imagine a recipe that says to add salt when you meant sugar. Nothing "breaks," but the result is not what you wanted. Logic errors are the hardest to find precisely because the computer gives you no error message; it did exactly what you told it, just not what you intended.

A quick way to remember the three: a syntax error means the computer cannot read it, a runtime error means it crashes partway, and a logic error means it runs but gives the wrong result.

Key idea: a logic error produces a wrong answer with no crash, making it the hardest kind to catch.

Testing: checking that it works

Testing means running a program with chosen inputs to see whether it behaves correctly. Good testing does not just try the easy, expected cases; it also tries edge cases, the unusual inputs at the boundaries, such as an empty entry, a zero, a negative number, or a very large value. Many bugs hide in these corners. A program that adds two numbers might work fine for 2 and 3 but fail when one input is left blank, and only a deliberate test uncovers that.

Key idea: testing tries both normal inputs and tricky edge cases to expose hidden bugs.

How to debug

When something is wrong, a few reliable strategies help you locate the bug without panic:

• Read the error message. It often names the line and the kind of problem. Beginners skip it; experts read it first.
• Print intermediate values. Adding instructions that show what the program is holding at each step lets you see exactly where reality diverges from your expectation.
• Trace by hand. Walk through the instructions on paper as if you were the computer, tracking each value. This catches logic errors the machine cannot flag.
• Change one thing at a time. Make a single small change, test, and repeat, so you always know which change caused what.

Key idea: read the message, print values, trace by hand, and change one thing at a time.

Common misconceptions

• "Errors mean I am bad at programming." Every professional produces bugs constantly. Debugging is a core part of the work, not a personal failing.
• "If the program runs, it must be correct." A logic error runs without any complaint yet gives the wrong answer. Running is not the same as being right.
• "Testing the normal case is enough." Many bugs live in edge cases like empty, zero, or negative inputs, so those must be tested on purpose.
• "The computer misunderstood me." The computer did exactly what the instructions said. A logic error is a gap between what you wrote and what you meant, not a misunderstanding by the machine.

Recap

• A bug is a defect that makes a program behave incorrectly; fixing bugs is debugging.
• Syntax errors break grammar and stop the program from running.
• Runtime errors crash the program while it runs, like dividing by zero.
• Logic errors run without crashing but give a wrong result, and are hardest to find.
• Testing tries normal and edge-case inputs; debugging uses reading messages, printing values, and hand tracing.

Sources

1. College Board, "AP Computer Science Principles CED," program testing and correctness. find source ↗
2. Code.org ↗, "AP CSP," debugging and testing lessons.
3. Khan Academy, "Intro to JS: Debugging your programs." khanacademy.org ↗
4. MDN Web Docs, "What went wrong? Troubleshooting JavaScript." find source ↗

The big picture

Underneath every number, word, picture, and song, a computer stores only two things: on and off. That two-state code is called binary, and learning to read it is the key that unlocks how computers store everything else. In this lesson you will convert small numbers to binary and back by hand and check your answer.

Key idea: computers represent all information with just two states, usually written as 1 and 0.

Why only two states?

Computers are built from billions of tiny electronic switches. A switch is either on or off, like a light switch on your wall: there is no reliable "half on." Because each switch has exactly two states, it is natural and dependable to build the whole machine around a two-symbol code. We write those two states as 1 (on) and 0 (off). Trying to use ten different voltage levels for the digits 0 through 9 would be error-prone, but telling apart just "on" and "off" is easy and reliable, which is why binary won.

Key idea: binary matches the hardware, because each switch is simply on or off, like a light switch.

Bits and bytes

A single binary digit, one 1 or 0, is called a bit. One bit alone can only say on or off, which is not much. So bits are grouped. Eight bits together make a byte, and a byte can represent 256 different combinations, which is enough for a single letter of text. Storage is measured in bytes: a kilobyte is about a thousand bytes, a megabyte about a million, and a gigabyte about a billion. When a photo is "3 megabytes," that is roughly three million bytes of binary.

Key idea: a bit is one binary digit, and eight bits form a byte, the basic unit of stored data.

How decimal really works

To understand binary, first notice how our everyday decimal system works. Decimal uses ten digits, 0 through 9, and each position is worth ten times the one to its right: ones, tens, hundreds, thousands. The number 253 means 2 hundreds, 5 tens, and 3 ones. The position of a digit tells you its value; that is why we call it place value.

Key idea: in decimal each place is worth ten times the place to its right, and position sets a digit's value.

How binary works

Binary uses the very same idea, but with only two digits, so each position is worth two times the one to its right instead of ten. Reading from the right, the place values are 1, 2, 4, 8, 16, 32, 64, 128, each double the last. To find a binary number's value, add up the place values wherever there is a 1.

Place value	128	64	32	16	8	4	2	1
Bits	0	0	0	0	1	1	0	1

The bits 00001101 have 1s in the 8, 4, and 1 places, so the value is 8 + 4 + 1 = 13. That is the whole trick: binary is just place value with doubling instead of times-ten.

Key idea: a binary number's value is the sum of the place values (1, 2, 4, 8, ...) wherever a 1 appears.

Worked example: decimal to binary

Let us convert the decimal number 19 into binary. One reliable method is to find the largest place value that fits, subtract it, and repeat.

1. The largest place value that fits in 19 is 16. Put a 1 in the 16 place. Now 19 minus 16 leaves 3.
2. The next place values 8 and 4 are both bigger than 3, so put 0 in each.
3. 2 fits in 3. Put a 1 in the 2 place. Now 3 minus 2 leaves 1.
4. 1 fits in 1. Put a 1 in the 1 place. Now 1 minus 1 leaves 0, so we are done.

Reading the places 16, 8, 4, 2, 1 gives 1, 0, 0, 1, 1, so 19 in binary is 10011. Let us verify by converting back: the 1s are in the 16, 2, and 1 places, and 16 + 2 + 1 = 19. It checks out. Always verify a conversion by adding the place values back up; it catches almost every mistake.

Key idea: to convert to binary, subtract the largest fitting place value repeatedly, then verify by adding the places back to the original.

Counting in binary

Counting works just like decimal, except you carry after 1 instead of after 9. Zero is 0, one is 1, and then, out of digits, two becomes 10, three is 11, four is 100, and so on. Each time every digit is used up, a new place is added. This is exactly what happens in decimal when 9 rolls over to 10; binary just rolls over sooner because it has fewer digits.

Key idea: binary counts by carrying to a new place after 1, the same way decimal carries after 9.

Common misconceptions

• "Binary is a different, mysterious kind of math." It is ordinary place-value counting with two digits instead of ten. The rules are identical; only the base changes.
• "Computers use binary because it is faster." They use it because hardware switches have two reliable states. Telling on from off is dependable, while many voltage levels would be error-prone.
• "A bit and a byte are the same thing." A bit is a single 1 or 0; a byte is eight bits grouped together. The difference matters for measuring storage.
• "The rightmost binary digit is the biggest." As in decimal, the rightmost digit is the smallest place, worth 1. Place values grow toward the left.

Recap

• Computers store everything as binary: two states written 1 and 0.
• Binary matches hardware because each switch is simply on or off.
• A bit is one binary digit; eight bits make a byte.
• Binary is place value with doubling: 1, 2, 4, 8, 16, and so on.
• Convert to binary by subtracting the largest fitting place value, and always verify by adding the places back.

Sources

1. Code.org ↗, "AP CSP," Big Idea 2: Data, binary numbers lessons.
2. Khan Academy, "Computers and the Internet: Binary numbers." khanacademy.org ↗
3. College Board, "AP Computer Science Principles CED," data representation. find source ↗
4. MDN Web Docs, Glossary entries for "Bit" and "Byte." find source ↗

The big picture

If a computer only stores numbers in binary, how does it hold your name, a photo, or a song? The answer is a simple, powerful trick used everywhere in computing: agree on a code that turns each kind of information into numbers. Once text, images, and sound are numbers, binary can store them all.

Key idea: everything becomes numbers first, and then binary stores the numbers.

Text: every character is a number

To store text, we agree on a character code, a lookup table that pairs each character with a number. The classic one is ASCII, which assigns the letters, digits, and common symbols numbers from 0 to 127. In ASCII, capital A is 65, B is 66, and so on; lowercase a is 97. Storing the word "Hi" means storing the numbers for H and i, which the computer then keeps in binary. It is like a secret code where each letter is swapped for an agreed number.

ASCII only covers English, so the modern standard is Unicode, a much larger table that gives a number to characters from every writing system on Earth, plus emoji. This is why a message with Japanese text or an emoji can travel between phones and still display correctly: everyone agrees on the same Unicode numbers.

Key idea: text is stored by mapping each character to a number using a shared code such as ASCII or Unicode.

Worked example: decoding text

Suppose you receive the ASCII numbers 67, 97, 116. Using the rule that capital A is 65, the number 67 is two letters past A, which is C. The number 97 is lowercase a, and 98 would be b, so 97 is a and the next, well, 116 counts up from a (97) by 19, landing on t. Put together, 67, 97, 116 spells "Cat." The point is not to memorize the table but to see that text is genuinely just numbers under an agreed code.

Key idea: because each character maps to a fixed number, a string of numbers can be decoded straight back into text.

Images: a grid of colored dots

A digital image is a grid of tiny squares called pixels (short for picture elements). Each pixel is one solid color, and up close you can sometimes see them. To store a color, computers usually use the RGB system: every color is mixed from three numbers giving the amounts of red, green, and blue light, each from 0 to 255. Red is 255, 0, 0; pure white is 255, 255, 255; black is 0, 0, 0. So an image is stored as a long list of pixel colors, three numbers per pixel.

This explains resolution. More pixels packed into the image means finer detail but a bigger file, because every pixel needs its own color numbers. A photo that is 1000 pixels wide and 1000 tall holds a million pixels, and at three numbers each that is three million numbers to store. That is why high-resolution photos take up so much space.

Key idea: an image is a grid of pixels, and each pixel's color is stored as red, green, and blue numbers.

Sound: measuring a wave many times a second

Sound in the air is a continuous wave, but a computer can only store numbers, so it measures the wave's height at rapid, even intervals and stores each measurement as a number. Each measurement is a sample, and taking them is called sampling. It is like drawing a smooth curve by plotting many closely spaced dots: from far enough away the dots look like the original curve. Music on a CD is sampled about 44,100 times every second, which is fast enough that human ears hear it as smooth, continuous sound.

Two settings control sound quality. The sample rate is how many samples are taken per second, and the bit depth is how many bits each sample uses, which sets how precisely each height is recorded. Higher values mean better quality and larger files, the same trade-off images face with resolution.

Key idea: sound is stored by sampling a wave's height many times per second and saving each height as a number.

The one unifying idea

Text, images, and sound feel completely different, yet they are stored the same way: pick a scheme to turn the information into numbers, then store those numbers in binary. This single principle, called data representation, is one of the most important ideas in all of computing. Master it once and the storage of every media type stops being mysterious.

Key idea: all media are stored by the same recipe, turn it into numbers, then store the numbers in binary.

Common misconceptions

• "Computers store letters as actual letters." They store numbers from a character code; the letters you see are drawn from those numbers when displayed.
• "A bigger screen automatically means a sharper image." Sharpness depends on the number of pixels (resolution), not the physical size. A big screen with few pixels looks blocky.
• "Sound is stored as one continuous recording." It is stored as thousands of separate height measurements per second; playback reconstructs the wave from those samples.
• "Emoji are pictures sent inside a message." Most emoji are Unicode characters, each a number; your device draws the little picture from that number.

Recap

• All media are stored by first turning them into numbers, then storing the numbers in binary.
• Text uses a character code: ASCII for English, Unicode for all writing systems and emoji.
• Images are grids of pixels, each pixel a color given as red, green, and blue numbers.
• Sound is sampled: the wave's height is measured many times per second and stored as numbers.
• Higher resolution, sample rate, and bit depth mean better quality but larger files.

Sources

1. Code.org ↗, "AP CSP," Big Idea 2: Data, representing text, images, and sound.
2. Khan Academy, "Computers and the Internet: Digital information." khanacademy.org ↗
3. College Board, "AP Computer Science Principles CED," data representation. find source ↗
4. MDN Web Docs, Glossary entries for "ASCII," "Unicode," and "RGB." find source ↗

The big picture

Raw data can be huge: photos, songs, and videos would fill your storage and crawl across the Internet if sent as-is. Compression is the art of making data smaller so it takes less space and travels faster. There are two families of compression, and knowing when to use each is a genuinely useful skill.

Key idea: compression shrinks data so it takes less storage and moves faster over networks.

Why compress at all?

Every byte you store costs space, and every byte you send takes time. A single uncompressed photo could be tens of megabytes; a movie could be enormous. Compression lets a phone hold thousands of songs and lets a video stream without endless buffering. The goal is always the same: represent the same information, or something close enough, using fewer bits.

Key idea: the aim of compression is to carry the same message with fewer bits.

Lossless compression: nothing is thrown away

Lossless compression shrinks data so that the original can be rebuilt exactly, bit for bit, with nothing lost. It works by spotting patterns and describing them more briefly. Imagine a message that reads "aaaaaaaa." Instead of storing eight a's, you could store "8a," meaning eight a's, which is far shorter and can be expanded back perfectly. Real lossless methods are cleverer, but the spirit is the same: find repetition and record it compactly.

Because it loses nothing, lossless compression is essential when every detail must survive: text documents, computer programs, and spreadsheets. You would never accept a "close enough" version of your bank statement or a program's code. Common lossless formats include ZIP files and PNG images.

Key idea: lossless compression rebuilds the original exactly, so it is used where no detail can be lost.

Lossy compression: throw away what you will not miss

Lossy compression makes files much smaller by permanently discarding information the human senses are unlikely to notice. Once thrown away, that data cannot be recovered, which is exactly why the files get so small. Photographs, music, and video use lossy compression heavily. A JPEG photo drops fine color details your eye barely registers; an MP3 song removes sounds too quiet to hear behind louder ones. The result looks or sounds almost the same while taking a fraction of the space.

There is a dial here: compress lightly and the file stays large but nearly perfect; compress hard and the file shrinks but visible or audible flaws (called artifacts) creep in. Choosing the setting is a trade-off between size and quality.

Key idea: lossy compression permanently discards hard-to-notice detail to make media files far smaller.

Choosing between them

The decision comes down to one question: can any information be lost? Use this quick guide:

Situation	Best choice	Why
A program's source code	Lossless	A single changed character could break it
A text document or spreadsheet	Lossless	Every word and number must survive exactly
A photo for a website	Lossy	Small quality loss is invisible and saves lots of space
Streaming music or video	Lossy	Huge size savings with barely noticeable change

Key idea: if losing any detail is unacceptable, choose lossless; if minor quality loss is fine, lossy saves far more space.

There is no free lunch

Compression is powerful but not magic. Lossless methods cannot shrink truly random data with no patterns, because there is nothing repetitive to describe more briefly. And lossy methods buy their small sizes by permanently giving up detail. Understanding these limits keeps expectations realistic: you cannot compress everything infinitely, and every gain in size has a cost in either effort or quality.

Key idea: compression has limits, since random data resists lossless shrinking and lossy savings cost permanent detail.

Common misconceptions

• "Compression always loses quality." Lossless compression loses nothing; it rebuilds the original exactly. Only lossy compression trades quality for size.
• "You can keep compressing a file to make it tiny." Once data is compressed, there is little or no pattern left to exploit, so compressing again barely helps and can even add size.
• "Lossy compression ruins files." Used at sensible settings, the loss is nearly imperceptible while the space savings are large, which is why photos and music rely on it.
• "A ZIP file is a lossy format." ZIP is lossless; unzipping restores the exact original bytes, which is why it is safe for documents and programs.

Recap

• Compression shrinks data to save storage and speed up transfer.
• Lossless compression rebuilds the original exactly by describing patterns compactly.
• Lossy compression permanently discards hard-to-notice detail for much smaller files.
• Use lossless when no detail can be lost; use lossy when minor quality loss is acceptable.
• Compression has limits: random data resists lossless, and lossy savings cost permanent detail.

Sources

1. Code.org ↗, "AP CSP," Big Idea 2: Data, lossless and lossy compression.
2. Khan Academy, "Computers and the Internet: Data compression." khanacademy.org ↗
3. College Board, "AP Computer Science Principles CED," data compression. find source ↗
4. MDN Web Docs, Glossary entries for "Lossless" and "Lossy" compression. find source ↗

The big picture

Data by itself is just raw numbers and facts. It becomes powerful when we process it into information, patterns and meaning that help us decide and predict. That power has a shadow side: data about people can reveal private things they never chose to share. This lesson looks at both the promise and the risk.

Key idea: processing turns raw data into useful information, and the same power raises real privacy concerns.

Data versus information

Data is raw, unorganized facts: a list of temperatures, a column of sales numbers, a stream of clicks. On its own it may mean little. Information is what you get after data is organized, analyzed, or summarized so it answers a question. The numbers 71, 68, 74, 90, 88 are data; noticing that "temperatures rose sharply over the last two days" is information. A helpful way to remember it: data is the ingredients, and information is the meal you cook from them.

Key idea: data is raw facts, and information is the meaning we extract by processing that data.

Finding patterns in data

Computers are extraordinary at sifting huge piles of data for patterns a human could never spot by hand. Analyzing millions of records can reveal trends, correlations, and predictions: which products sell together, when traffic peaks, how a disease spreads. This is the engine behind recommendations, search results, and much of modern science. Turning oceans of raw data into insight is one of computing's greatest strengths.

A caution comes with it: a correlation, meaning two things that tend to happen together, does not prove that one causes the other. Ice cream sales and sunburns rise together, but ice cream does not cause sunburn; hot sunny weather drives both. Good analysis separates real causes from coincidences.

Key idea: computers excel at finding patterns, but a correlation is not proof that one thing causes another.

The privacy problem

Every app you use, page you visit, and purchase you make can generate data about you. Individually, one fact seems harmless. The danger is aggregation: combining many small, harmless-looking pieces of data can reveal something private that no single piece exposed. Your location at 8 a.m. each weekday, plus your purchases, plus your searches, can together paint a detailed portrait, where you live, work, worship, and what your health might be, even if you never stated any of it.

This is why privacy matters even if you feel you "have nothing to hide." The concern is not one embarrassing fact; it is that the combination of ordinary facts can expose things you would reasonably want to keep private, and that this profile can be used in ways you did not agree to.

Key idea: combining many harmless-looking pieces of data can reveal private facts none of them showed alone.

Personally identifiable information

Some data is especially sensitive because it can single you out. Personally identifiable information, or PII, is any data that can identify a specific person, such as a full name, home address, phone number, government ID number, or exact location. PII deserves extra care because in the wrong hands it enables fraud, stalking, and identity theft. A useful habit is to pause before sharing PII online and ask whether the site truly needs it and can be trusted with it.

Key idea: personally identifiable information can single you out, so it needs extra protection.

Protecting your data

You cannot control everything, but sensible steps meaningfully reduce risk:

• Share less. The data that is never collected cannot leak. Give apps only what they truly need.
• Check permissions. Review what apps can access, such as location, camera, and contacts, and turn off what is not needed.
• Read the trade. "Free" services are often paid for with your data. Notice what you are giving in exchange.
• Use strong, unique passwords. This limits the damage if one account is breached, a habit you will study more in the cybersecurity lesson.

Key idea: sharing less, checking permissions, and using strong passwords are practical ways to protect your data.

Common misconceptions

• "Data and information are the same thing." Data is raw facts; information is the meaning you get after processing it. Piles of data are useless until turned into information.
• "If two things rise together, one must cause the other." Correlation is not causation. A hidden third factor often drives both, as with ice cream and sunburns.
• "Privacy only matters if you have something to hide." Ordinary facts combined can expose private things, and profiles can be used in ways you never agreed to, so privacy protects everyone.
• "A free app costs nothing." Many free services are funded by collecting and using your data, which is a real, if invisible, price.

Recap

• Data is raw facts; information is the meaning extracted by processing it.
• Computers find patterns in huge data sets, but correlation does not prove causation.
• Aggregation can combine harmless data into a revealing private profile.
• Personally identifiable information can single you out and needs extra care.
• Share less, check permissions, notice the data-for-service trade, and use strong passwords.

Sources

1. Code.org ↗, "AP CSP," Big Idea 2: Data, information and privacy lessons.
2. College Board, "AP Computer Science Principles CED," data and privacy. find source ↗
3. Khan Academy, "Computers and the Internet: Data and privacy." khanacademy.org ↗
4. MDN Web Docs, Glossary entry for "PII (Personally identifiable information)." find source ↗

The big picture

Programs need to remember things: a score, a name, a running total. A variable is how a program stores a value and gives it a name so it can be used and changed later. Variables are the most basic building block of programming, and once they click, code becomes far easier to read.

Key idea: a variable is a named place that stores a value the program can use and change.

What a variable is

Picture a variable as a labeled box. The label is the variable's name, and inside the box is its value. You can look inside to read the value, and you can put a new value in, replacing the old one. When a program says the score is 10, it has a box labeled "score" holding the number 10. Naming the box lets the rest of the program refer to "score" without caring where in memory it actually lives.

Key idea: a variable is like a labeled box: the name is the label and the value is what is inside.

Assignment: putting a value in the box

Storing a value in a variable is called assignment, and most languages write it with an equals sign. Reading it as "gets" instead of "equals" avoids a classic confusion. The line score = 10 means "the box named score gets the value 10." Crucially, this is not a math equation claiming two things are already equal; it is a command to store. That is why a line like score = score + 1 makes sense in code even though it looks impossible in math: it means "take the current value in score, add 1, and put the result back in score."

Key idea: assignment stores a value into a variable, so read the equals sign as "gets," not "is equal to."

Worked example: tracing a variable

Let us trace these four lines as if we were the computer, writing down the value in the box after each step:

score = 5
score = score + 3
score = score * 2
score = score - 1

1. score = 5: the box gets 5. Value is now 5.
2. score = score + 3: current 5 plus 3 is 8, stored back. Value is now 8.
3. score = score * 2: current 8 times 2 is 16, stored back. Value is now 16.
4. score = score - 1: current 16 minus 1 is 15, stored back. Value is now 15.

The final value is 15. Tracing line by line, and writing the value after each step, is a skill you will use constantly, and it is exactly how you catch logic errors.

Key idea: to understand code, trace it one line at a time and record each variable's value as it changes.

Data types

Values come in different kinds, called data types. The type tells the computer what a value is and what you can do with it. The common types are:

Type	Holds	Example
Integer	A whole number	42
Floating point	A number with a decimal	3.14
String	Text, in quotes	"hello"
Boolean	True or false only	true

A string is any sequence of characters treated as text, and it is written in quotes so the computer knows it is text rather than code. A Boolean, named after logician George Boole, can only be true or false, and it becomes essential when programs make decisions.

Key idea: a data type says what kind of value something is: whole number, decimal, text, or true/false.

Why type matters

Type matters because the same symbol can mean different things depending on type. Consider the plus sign. With numbers, 2 + 3 gives 5. But with strings, "2" + "3" often gives "23", because joining text end to end is called concatenation. The characters look identical, yet the result differs entirely because the types differ. Mixing up a number and a string that looks like a number is one of the most common beginner bugs, so knowing the type of every value is genuinely important.

Key idea: the type changes what an operation does, so the same plus sign can add numbers or join text.

Naming variables well

You choose your variable names, and good names make code readable. A name like totalScore or userAge tells a reader what the box holds; a name like x or temp forces them to guess. Since code is read far more often than it is written, clear names are a kindness to your future self and your teammates. Most languages require names to start with a letter and forbid spaces, which is why programmers join words with capitals or underscores.

Key idea: descriptive variable names make code readable, because code is read far more often than written.

Common misconceptions

• "The equals sign in code means the two sides are equal." In most languages it means assignment, "the left box gets the right value." That is why score = score + 1 is valid.
• "A variable can only be set once." Its whole point is that the value can change; a new assignment simply replaces the old value.
• "The number 5 and the text '5' are the same." One is an integer you can do math on; the other is a string. Adding strings joins them, so "5" + "5" is "55," not 10.
• "Variable names do not matter." Clear names make programs far easier to read and debug; vague names cost you and your teammates time.

Recap

• A variable is a named box that stores a value the program can read and change.
• Assignment stores a value; read the equals sign as "gets," not "is equal to."
• Trace code line by line, recording each variable's value, to understand it and catch bugs.
• Common data types are integer, floating point, string, and Boolean.
• Type changes what operations do, so adding strings joins them instead of doing math.

Sources

1. Code.org ↗, "AP CSP," Big Idea 3: Algorithms and Programming, variables lessons.
2. College Board, "AP Computer Science Principles CED," variables and data abstraction. find source ↗
3. Khan Academy, "Intro to programming: Variables." khanacademy.org ↗
4. MDN Web Docs, "Storing the information you need - Variables" and "Data types." find source ↗

The big picture

One variable holds one value, but programs often need to handle many values at once, like every student's score or every song in a playlist. A list stores many values under one name, and a loop repeats an action for each of them. Together they let a few lines of code do an enormous amount of work.

Key idea: a list holds many values together, and a loop repeats work over them without writing the steps many times.

What a list is

A list (also called an array in many languages) is an ordered collection of values stored under a single name. If a variable is one labeled box, a list is a row of boxes sharing one label, numbered in order. A playlist, a class roster, and a shopping list are all naturally lists. Instead of ten separate variables for ten scores, you keep one list called scores holding all ten.

Key idea: a list is an ordered row of values kept under one name, like a numbered row of boxes.

Accessing items by index

Each item in a list has a position number called its index. Here is the surprise that trips up nearly every beginner: in most languages, counting starts at 0, not 1. So the first item is at index 0, the second at index 1, and so on. If a list colors holds "red," "green," "blue," then colors[0] is "red" and colors[2] is "blue." Think of the index as how many steps you move from the front of the row; the first item is zero steps in.

Key idea: list items are numbered by index starting at 0, so the first item is at index 0.

What a loop is

A loop is an instruction that repeats a block of code. Without loops, printing a list of 100 names would need 100 lines; with a loop, it takes a few. Repetition is also called iteration, and each single pass through the loop is one iteration. A loop is like telling someone "for every plate in the stack, wash it": you state the action once, and it applies to each item in turn.

Key idea: a loop states an action once and repeats it, so a few lines can process many items.

Two common kinds of loop

There are two shapes of loop you will meet constantly:

• A for loop repeats a set number of times, or once for each item in a list. Use it when you know how many repetitions you need, such as "for each score in the list."
• A while loop repeats as long as a condition stays true. Use it when you do not know the count in advance, such as "while the game is not over."

Both save you from copying code, but they answer different questions: a for loop asks "how many times," and a while loop asks "until when."

Key idea: a for loop runs a known number of times, while a while loop runs until a condition stops being true.

Worked example: summing a list

Suppose scores holds 4, 7, and 5, and we want the total. We keep a running total in a variable and add each item as the loop visits it:

total = 0
for each s in scores:
    total = total + s

Trace it, writing total after each iteration. Start with total at 0. First item is 4, so total becomes 0 + 4 = 4. Second item is 7, so total becomes 4 + 7 = 11. Third item is 5, so total becomes 11 + 5 = 16. After the loop, total is 16. This pattern, a variable that accumulates a result across a loop, appears in countless programs and is called an accumulator.

Key idea: a loop plus an accumulator variable can total or combine every item in a list.

The danger: infinite loops

A while loop that never becomes false runs forever, freezing the program. This is an infinite loop, and it is a common bug. If you write "while count is less than 10" but forget to increase count inside the loop, the condition never changes and the loop never ends. The fix is to make sure something inside the loop moves the condition toward becoming false, such as adding 1 to count each pass. Always ask: what will eventually stop this loop?

Key idea: a loop whose condition never becomes false runs forever, so ensure each pass moves toward stopping.

Common misconceptions

• "The first item in a list is at index 1." In most languages counting starts at 0, so the first item is at index 0. Forgetting this causes off-by-one errors constantly.
• "Loops are only for advanced programs." Loops are among the most basic and most used tools in all of programming; almost every real program contains them.
• "A while loop always runs at least once." If its condition is false at the start, the loop body may never run at all. Its check happens before each pass.
• "You need a separate variable for each value." A list holds many values under one name, which is exactly what lets a single loop process them all.

Recap

• A list stores many ordered values under one name, like a numbered row of boxes.
• Items are accessed by index, which starts at 0 in most languages.
• A loop repeats an action; each pass is one iteration.
• A for loop runs a known number of times; a while loop runs until a condition is false.
• An accumulator variable plus a loop can total or combine a whole list, but an unending condition causes an infinite loop.

Sources

1. Code.org ↗, "AP CSP," Big Idea 3: Algorithms and Programming, lists and loops.
2. College Board, "AP Computer Science Principles CED," lists and iteration. find source ↗
3. Khan Academy, "Intro to programming: Arrays and loops." khanacademy.org ↗
4. MDN Web Docs, "Arrays" and "Loops and iteration." find source ↗

The big picture

Programs feel intelligent because they make decisions: show this if the password is right, warn the user if the tank is low. That decision-making comes from conditionals, instructions that run only when a condition is true. Underneath them sits Boolean logic, the true-and-false reasoning that powers every choice a computer makes.

Key idea: conditionals let a program choose what to do based on whether something is true or false.

The if statement

The if statement is the heart of decision-making. It checks a condition, and if that condition is true, it runs a block of code; if not, it skips it. In plain form it reads like an English sentence: "if it is raining, take an umbrella." The condition is a question with a yes-or-no answer, and only a true answer triggers the action.

if temperature > 30:
    print("It is hot")

Here the message prints only when temperature is greater than 30. If temperature is 25, the condition is false and the line is skipped entirely.

Key idea: an if statement runs its block only when its condition is true, and skips it otherwise.

else and else if

Often you want an alternative when the condition is false. That is what else provides: a block that runs when the if condition was not true. And when there are several possibilities, else if (written elif or else if depending on the language) checks more conditions in turn.

if score >= 90:
    print("A")
else if score >= 80:
    print("B")
else:
    print("C or below")

The computer checks each condition top to bottom and takes the first one that is true, then skips the rest. So a score of 85 prints "B": the first test fails, the second succeeds, and the else is never reached. Order matters, because only the first matching branch runs.

Key idea: else gives a fallback, and else if adds more choices, with the first true condition winning.

Boolean expressions and comparisons

The condition inside an if is a Boolean expression, something that evaluates to either true or false. Most are built from comparison operators that compare two values:

Operator	Means	Example that is true
>	greater than	5 > 3
<	less than	2 < 9
>=	greater than or equal to	4 >= 4
==	equal to	7 == 7
!=	not equal to	7 != 8

Notice that checking equality uses a double equals ==, which is different from the single equals of assignment. A single = stores a value; a double == asks "are these equal?" Confusing the two is one of the most common beginner mistakes.

Key idea: a Boolean expression evaluates to true or false, and equality is tested with == , not the single = used for assignment.

Combining conditions: AND, OR, NOT

Real decisions often depend on more than one thing. Three logical operators combine Boolean values:

• AND is true only when both parts are true. "If you are hungry AND it is lunchtime, eat."
• OR is true when at least one part is true. "If it is Saturday OR Sunday, sleep in."
• NOT flips a value: NOT true is false, and NOT false is true. "If it is NOT raining, walk."

For example, age >= 13 AND age <= 19 is true only for numbers that are both at least 13 and at most 19, that is, the teen years. Combining conditions this way lets a program express quite subtle rules from these three simple building blocks.

Key idea: AND needs both true, OR needs at least one true, and NOT flips true and false.

Worked example: tracing a decision

Suppose age is 15 and we run: if age >= 13 AND age <= 19, print "teenager"; else print "not a teenager." Check the condition: is 15 at least 13? Yes. Is 15 at most 19? Yes. Both parts are true, so AND is true, and the program prints "teenager." Now imagine age is 20: 20 is at least 13 (true) but not at most 19 (false), so AND is false and the else prints "not a teenager." Walking through each comparison is exactly how you predict what a conditional will do.

Key idea: to predict a conditional, evaluate each comparison to true or false, then combine them with the logical operators.

Common misconceptions

• "= and == are interchangeable." A single = assigns a value; a double == tests equality. Using the wrong one is a frequent bug.
• "OR means exactly one." In programming, OR is true when at least one part is true, including when both are true. It is not "one or the other but not both."
• "All the branches of an if-else can run." Only the first condition that is true runs; the rest are skipped, so order matters.
• "AND and OR mean the same casual thing as in speech." They have precise definitions: AND needs both true, OR needs at least one true. Reasoning from the casual meaning leads to wrong conditions.

Recap

• Conditionals let a program act only when a condition is true.
• if runs a block when true; else is the fallback; else if adds more choices, first true wins.
• Boolean expressions evaluate to true or false, often using comparison operators.
• Equality is tested with ==, distinct from the single = of assignment.
• AND needs both true, OR needs at least one true, and NOT flips a value.

Sources

1. Code.org ↗, "AP CSP," Big Idea 3: Algorithms and Programming, conditionals and Boolean logic.
2. College Board, "AP Computer Science Principles CED," selection and Boolean expressions. find source ↗
3. Khan Academy, "Intro to programming: If-statements and Boolean expressions." khanacademy.org ↗
4. MDN Web Docs, "Making decisions in your code - conditionals." find source ↗

The big picture

As programs grow, repeating the same steps everywhere becomes a nightmare to write and fix. A procedure packages a set of steps under a name so you can reuse them with a single call. Doing so is an example of abstraction, one of the deepest and most important ideas in all of computing.

Key idea: a procedure names a block of steps so you can reuse it, and that packaging is a form of abstraction.

What a procedure is

A procedure (also called a function or method) is a named, reusable block of instructions. You define it once, then call it by name whenever you want those steps to run. It is like a recipe you have written down: instead of relisting every step each time you bake, you just say "make the cookie dough" and follow the saved recipe. If ten places in your program need to greet a user, you write a greet procedure once and call it ten times.

Key idea: a procedure is a named block of steps you define once and call by name whenever you need it.

Why procedures matter

Procedures pay off in three concrete ways. They remove repetition, since shared steps live in one place. They make code readable, because a well-named call like calculateTax tells a reader what happens without showing the messy details. And they make fixes safe: if the logic is wrong, you correct it in the one procedure rather than hunting down every copy. Writing the same code five times means fixing the same bug five times; a procedure means fixing it once.

Key idea: procedures cut repetition, improve readability, and let you fix a bug in one place instead of many.

Parameters: giving a procedure input

A procedure becomes far more useful when it can work on different values each time. A parameter is a named input a procedure accepts, and the actual value you pass in is called an argument. A greet procedure with a name parameter can say hello to anyone: call greet("Ada") and it greets Ada; call greet("Grace") and it greets Grace. The parameter is like a blank in a form letter that gets filled in each time you send it.

Key idea: a parameter is a labeled input, so one procedure can operate on different values passed in as arguments.

Return values: getting output back

Many procedures compute a result and hand it back to the code that called them. That handed-back result is the return value. A procedure named square that takes a number and returns it multiplied by itself lets you write square(5) and get 25 to use elsewhere. Think of it as a vending machine: you put in an input (press a button), and it returns an output (the snack). A procedure can take inputs through parameters and give an output through its return value.

Key idea: a return value is the result a procedure sends back, so its output can be used by the rest of the program.

Abstraction: hiding the details

Abstraction means hiding complex details behind a simple interface so you can use something without understanding its inner workings. It is the single most powerful idea for managing complexity. The classic analogy is a car's steering wheel: you turn it to steer without knowing anything about the gears, linkages, and hydraulics underneath. The steering wheel is a simple interface hiding enormous complexity, and that is exactly what a good procedure provides.

Abstraction is everywhere in computing. When you call a procedure, you use its name and inputs without caring how it works inside. When you tap an app icon, you launch a program without seeing the code. Each layer hides the one below it, which is what lets people build enormous systems without holding every detail in mind at once.

Key idea: abstraction hides inner complexity behind a simple interface, like a steering wheel hiding a car's machinery.

Layers of abstraction

Computing is built as a stack of abstraction layers, each resting on the one beneath. At the bottom are electrical signals and binary; above that sit basic instructions, then programming languages, then procedures you write, then whole applications. A programmer writing an app rarely thinks about voltages, because the layers below are abstracted away. This layering is why a beginner can build something real without first mastering electronics: you work at your layer and trust the ones below.

Key idea: computing is a stack of abstraction layers, each hiding the details of the layer below it.

Common misconceptions

• "Procedures are only worth it for huge programs." Even a short program benefits, because a named block is clearer and any repeated logic gets a single home.
• "A parameter and an argument are the same word." The parameter is the named input in the definition; the argument is the actual value you pass when you call it.
• "Abstraction hides information you need." It hides details you do not need at the moment, letting you focus. You can always look inside when necessary.
• "Every procedure returns a value." Some procedures just perform an action, like printing a message, and return nothing at all.

Recap

• A procedure is a named, reusable block of steps you define once and call by name.
• Procedures reduce repetition, improve readability, and let you fix bugs in one place.
• Parameters are named inputs; the values passed in are arguments.
• A return value is the output a procedure hands back to its caller.
• Abstraction hides inner complexity behind a simple interface, and computing is built in layers of it.

Sources

1. Code.org ↗, "AP CSP," Big Idea 3: Algorithms and Programming, procedures and abstraction.
2. College Board, "AP Computer Science Principles CED," procedural abstraction. find source ↗
3. Khan Academy, "Intro to programming: Functions." khanacademy.org ↗
4. MDN Web Docs, "Functions - reusable blocks of code." find source ↗

The big picture

An algorithm is a clear, step-by-step method for solving a problem, and it is the beating heart of computer science. The same problem can have several algorithms, some fast and some painfully slow. Learning to compare them, and to recognize that a few problems resist fast solutions entirely, is what separates a coder from a computational thinker.

Key idea: an algorithm is a step-by-step method to solve a problem, and different algorithms for the same problem can differ hugely in speed.

What an algorithm is

An algorithm is a finite sequence of well-defined steps that solves a problem or completes a task. A cooking recipe is an algorithm: precise steps in order that turn ingredients into a dish. Directions to a friend's house are an algorithm. The key traits are that the steps are clear enough to follow without guessing, and that the process eventually ends with a result. Algorithms existed long before computers; computers just carry them out at astonishing speed.

Key idea: an algorithm is a clear, finite set of steps that always leads to a result, like a recipe.

Many algorithms, one problem

Most problems can be solved more than one way. Suppose you want to find a name in a phone book. One algorithm is linear search: start at the first page and check every entry until you find it. Another is binary search: open to the middle, see whether the name is before or after, and repeat on the correct half, throwing away the rest each time. Both find the name, but binary search is dramatically faster on a large, sorted book. Choosing the better algorithm can matter more than any other decision in a program.

Key idea: a single problem often has several correct algorithms, and the choice between them can change speed enormously.

Efficiency: how work grows with size

Efficiency asks how the amount of work an algorithm does grows as the input gets bigger. This matters because an algorithm that is fine for 10 items may be hopeless for 10 million. We compare algorithms by the shape of that growth, not by exact seconds, because the shape is what dominates at large sizes.

Growth shape	What happens as input doubles	Example
Constant	Work stays the same	Grabbing the first item in a list
Linear	Work roughly doubles	Checking every item once (linear search)
Logarithmic	Work grows by just one more step	Binary search on sorted data
Quadratic	Work roughly quadruples	Comparing every item to every other item

The differences are staggering at scale. For a million items, a linear algorithm might take a million steps while a logarithmic one takes about twenty. That is why efficiency, not raw computer speed, is often what makes a program usable.

Key idea: we compare algorithms by how their work grows with input size, and that growth shape dominates at large scales.

Worked example: comparing searches

Imagine a sorted list of 1,000 names and you search for one. Linear search checks names one by one, so in the worst case it makes 1,000 checks. Binary search halves the list each step: 1,000, then 500, 250, 125, and so on, reaching the answer in about 10 checks, because you can halve 1,000 only about ten times before reaching one. Now picture a billion names: linear search could need a billion checks, but binary search needs only about 30. Same problem, wildly different work, purely because of the algorithm.

Key idea: halving the search space each step (binary search) turns a billion checks into about thirty, showing why algorithm choice matters.

When problems are just hard

Some problems have no known fast algorithm at all. A famous example is planning the shortest route that visits many cities and returns home, the traveling salesperson problem. For a handful of cities it is easy, but as cities are added the number of possible routes explodes so quickly that even the fastest supercomputer cannot check them all in any reasonable time. These are called intractable problems: solvable in principle, but not quickly at large sizes. When exact answers are out of reach, programmers use a heuristic, a practical shortcut that finds a good-enough answer without guaranteeing the perfect one.

Key idea: some problems have no fast solution at scale, so we settle for heuristics that give good-enough answers.

Not everything is computable

There is an even deeper limit. A few problems cannot be solved by any algorithm whatsoever, no matter how much time or power you have. Computer scientists proved that certain questions are undecidable, meaning no general algorithm can answer them for every case. This is a profound result: computing is astonishingly powerful, but it is not infinitely so, and knowing where the edges are is part of understanding the field honestly.

Key idea: a few problems are undecidable, meaning no algorithm can solve them, marking a true limit of computing.

Common misconceptions

• "A faster computer removes the need for a good algorithm." Growth shape dominates at scale, so a poor algorithm on a fast machine still loses badly to a good algorithm as input grows.
• "If a program gives the right answer, its efficiency does not matter." Correctness and efficiency are separate. A correct but slow algorithm can be unusable on real-world data sizes.
• "Every problem has a fast solution if you are clever enough." Some problems are intractable at scale, and a few are undecidable, meaning no algorithm can ever solve them.
• "An algorithm must involve a computer." Algorithms are just step-by-step methods; recipes and directions are algorithms too, and they predate computers.

Recap

• An algorithm is a clear, finite sequence of steps that solves a problem.
• One problem can have several algorithms that differ greatly in speed.
• Efficiency measures how work grows with input size; the growth shape dominates at scale.
• Binary search halving beats linear search enormously on large sorted data.
• Some problems are intractable or even undecidable, marking real limits of computing.

Sources

1. Code.org ↗, "AP CSP," Big Idea 3: Algorithms and Programming, algorithms and efficiency.
2. College Board, "AP Computer Science Principles CED," algorithmic efficiency and undecidable problems. find source ↗
3. Khan Academy, "Algorithms" unit (with Dartmouth College). khanacademy.org ↗
4. MDN Web Docs, Glossary entry for "Algorithm." find source ↗

The big picture

The Internet is a worldwide network of connected computers that can pass messages to one another. It has no central control tower, yet billions of devices reach each other reliably. This lesson explains the clever, simple ideas that make that possible: breaking data into packets, giving every device an address, and agreeing on shared rules called protocols.

Key idea: the Internet is a global network with no central controller, held together by packets, addresses, and shared protocols.

Internet versus web

First, a distinction people often blur. The Internet is the physical and logical network, the cables, wireless links, and machines, that connects computers worldwide. The World Wide Web is just one service that runs on top of it, the system of linked pages you browse. Email, video calls, and online games are other services on the same Internet. The Internet is the road system; the web is one kind of traffic that travels on it.

Key idea: the Internet is the network itself, while the web is only one of many services running on it.

Packets: cutting data into pieces

When you send anything over the Internet, it is not shipped as one big blob. It is chopped into small chunks called packets, each carrying a piece of the data plus labels saying where it is going and where it belongs in the sequence. Packets travel independently, possibly by different routes, and are reassembled in the right order at the destination. Picture mailing a book by tearing out the pages, putting each in its own numbered envelope, and letting the postal system deliver them separately; the reader stacks them back in order using the numbers.

This packet approach has a big payoff: many messages can share the same cables at once, and if one packet is lost, only that small piece must be resent, not the whole message.

Key idea: data is split into numbered packets that travel independently and are reassembled at the destination.

Addresses and DNS

For packets to find their target, every device on the Internet has a numeric IP address, much like a postal address for a house. Packets are labeled with the destination IP so the network can route them there. But numbers are hard for people to remember, so the Domain Name System (DNS) acts as the Internet's phone book: you type a friendly name like example.com, and DNS looks up the matching IP address behind the scenes. Type a name, and DNS quietly turns it into the number the network actually uses.

Key idea: every device has an IP address, and DNS translates human-friendly names into those numeric addresses.

Protocols: the shared rules

Because the Internet connects countless different machines, they must agree on how to communicate. A protocol is an agreed set of rules for exchanging data, and open, shared protocols are what let any two devices talk regardless of brand or maker. A few you should know:

Protocol	Job
IP	Addresses and routes packets to the right destination
TCP	Reassembles packets in order and resends any that are lost
HTTP	Rules for requesting and sending web pages
DNS	Translates domain names into IP addresses

TCP and IP work so closely together that they are often named as a pair, TCP/IP. IP gets packets to the right place; TCP makes sure they all arrive and are put back in order. Together they turn an unreliable pile of separate packets into a dependable message.

Key idea: protocols are shared rules, and open ones like TCP/IP let any two devices communicate reliably.

Fault tolerance: surviving failure

One of the Internet's greatest strengths is fault tolerance, the ability to keep working even when parts fail. Because the network is a mesh with many possible paths between any two points, packets can route around a broken cable or a downed machine by taking another way. There is no single point whose failure stops everything. This is like a city's road grid: if one street is closed, drivers simply take a different route and still arrive. The Internet was deliberately designed this way so that damage to some parts does not bring down the whole.

Key idea: the Internet is fault tolerant because its mesh of many paths lets packets route around failures.

Scalability and openness

The Internet is also remarkably scalable, meaning it keeps working as it grows from thousands to billions of devices. It scales because it is decentralized: no central computer has to handle everything, so new networks can join by simply following the shared protocols. That openness, protocols anyone can use without permission, is why the Internet grew so explosively and why a new device or service can join without asking a central authority. The design values are the lesson here: keep the core simple, shared, and open, and let the edges innovate.

Key idea: the Internet scales to billions of devices because it is decentralized and built on open protocols anyone can adopt.

Common misconceptions

• "The Internet and the web are the same." The Internet is the network; the web is one service running on it, alongside email, video calls, and games.
• "Data travels as one whole piece." It is split into packets that move independently and are reassembled at the destination, which is what lets many messages share the cables.
• "There is a central computer that runs the Internet." The Internet is decentralized with no central controller, which is exactly what makes it fault tolerant and scalable.
• "If a cable breaks, the Internet stops." Thanks to many possible paths, packets route around failures, so local damage rarely stops the whole network.

Recap

• The Internet is the global network; the web is one service that runs on it.
• Data is split into numbered packets that travel independently and are reassembled.
• Every device has an IP address, and DNS translates names into those addresses.
• Protocols are shared rules; open ones like TCP/IP let any devices communicate.
• The Internet is fault tolerant and scalable because it is a decentralized mesh with many paths.

Sources

1. Code.org ↗, "AP CSP," Big Idea 4: Computing Systems and Networks, how the Internet works.
2. College Board, "AP Computer Science Principles CED," the Internet and fault tolerance. find source ↗
3. Khan Academy, "The Internet" unit (Code.org ↗ and partners).
4. MDN Web Docs, "How the Internet works" and "What is a URL?" find source ↗

The big picture

Computing reshapes how people live, work, learn, and connect, often for the better and sometimes for the worse, frequently both at once. A thoughtful person does not ask "is technology good or bad?" but "who does this help, who does it harm, and how could it be improved?" This lesson builds that balanced habit of mind.

Key idea: most computing innovations bring benefits and harms together, so the useful question is who is helped, who is harmed, and how it could be better.

Innovations cut both ways

Nearly every computing advance has a bright side and a shadow. Social media connects distant friends and gives a voice to the unheard, yet it can spread misinformation and harm mental health. Navigation apps save time and fuel, yet they can send heavy traffic down quiet residential streets. The point is not to reject technology or to cheer it blindly, but to see both effects clearly. An honest analysis names the benefits and the harms of the same innovation side by side.

Key idea: the same innovation usually produces benefits and harms at once, and both deserve to be named.

Intended and unintended effects

Creators design for an intended effect, but technologies almost always produce unintended ones too. Email was meant to speed communication; spam was an unwelcome side effect. A recommendation system meant to show you interesting videos can accidentally pull people toward more and more extreme content. Unintended consequences are not always negative, some are pleasant surprises, but they are hard to predict, which is exactly why testing with real, diverse users and watching for side effects matters so much.

Key idea: technologies produce unintended effects alongside intended ones, so creators must watch for consequences they did not plan.

How bias sneaks into software

People sometimes assume computers are perfectly objective, but software can be biased, meaning it systematically treats some groups unfairly. Bias usually enters through the data a system learns from. If a program is trained on examples that underrepresent or misrepresent a group, it will perform worse for that group. A face-recognition system trained mostly on lighter-skinned faces has been shown to misidentify darker-skinned faces far more often. The computer was not malicious; it simply learned from skewed data and passed the skew along.

Bias can also come from the choices of the people who build a system, what data to collect, what counts as success, whose needs to prioritize. Because these decisions are made by humans, human blind spots can become built into the software. Recognizing that computers are not automatically fair is the first step toward building systems that are.

Key idea: software can be biased, usually because it learns from skewed data or reflects the blind spots of its makers.

The digital divide

The digital divide is the gap between those who have good access to computers and the Internet and those who do not. Access is not equal: it varies with income, geography, and age. A student with fast home Internet and a laptop can research, apply to jobs, and take online classes; a student without them is shut out of those same opportunities. As more of life moves online, from schoolwork to healthcare to government services, this gap can widen existing inequalities rather than shrink them.

The divide is not only about owning a device. It also includes reliable connection, affordable service, and the skills to use technology well. Closing it is a real policy and design challenge, and it is one of the clearest examples of how computing's benefits are not shared equally.

Key idea: the digital divide is the unequal access to computing and the Internet, and it can deepen other inequalities as life moves online.

Computing for good

The same power that causes harm can be aimed at large problems. Computing helps model climate change, speed medical research, coordinate disaster relief, and put the world's knowledge within reach of anyone connected. Crowdsourcing, gathering small contributions from many people over the Internet, has funded projects, mapped disaster zones, and built free encyclopedias. The lesson is that impact depends heavily on how a tool is used and who gets to use it, not on the tool alone.

Key idea: computing can tackle huge shared problems, so its impact depends on how and by whom the technology is used.

Common misconceptions

• "Technology is either good or bad." Most innovations are both at once. The useful analysis weighs benefits against harms rather than picking a side.
• "Computers are perfectly objective and fair." Software can be biased when it learns from skewed data or reflects its makers' blind spots. Fairness must be designed in, not assumed.
• "Everyone has equal access to technology." The digital divide means access varies with income, geography, and skills, and this gap can widen other inequalities.
• "Side effects only happen with careless design." Even well-built systems produce unintended consequences, which is why creators must watch for effects they did not plan.

Recap

• Most computing innovations bring benefits and harms together and deserve balanced analysis.
• Technologies produce unintended effects alongside their intended ones.
• Software can be biased, usually from skewed training data or its makers' blind spots.
• The digital divide is unequal access to computing that can deepen other inequalities.
• Computing can address large shared problems, so impact depends on how and by whom it is used.

Sources

1. Code.org ↗, "AP CSP," Big Idea 5: Impact of Computing, benefits, harms, and bias.
2. College Board, "AP Computer Science Principles CED," beneficial and harmful effects and computing bias. find source ↗
3. Khan Academy, "Computers and the Internet: Impact of the Internet." khanacademy.org ↗
4. MDN Web Docs, Glossary entries related to accessibility and the digital divide. find source ↗

The big picture

Because so much of our lives lives online, keeping information safe is everyone's concern, not just experts'. This final lesson covers the core ideas of cybersecurity, the practical habits that keep you safe, and then what to expect from the AP exam and the Create Performance Task so you can finish the course with a clear plan.

Key idea: cybersecurity protects information and systems, and simple habits go a long way toward keeping you safe.

Common threats

Understanding a few common threats helps you recognize and avoid them:

• Malware is harmful software, such as viruses, that damages devices or steals data. It often arrives through a sketchy download or attachment.
• Phishing is a trick where a message pretends to be from someone you trust to fool you into revealing a password or clicking a bad link. A fake "your account is locked" email is a classic example.
• A data breach happens when a company's stored information is stolen, exposing many users' data at once, which is why a leak somewhere else can affect you.

The common thread is deception and unauthorized access. Attackers usually rely on tricking a person rather than on some cinematic feat of code, which means an alert human is a strong defense.

Key idea: most attacks rely on deception, so recognizing malware, phishing, and breaches is a real defense.

How encryption protects you

Encryption scrambles data using a secret key so that only someone with the right key can read it. If intercepted, encrypted data looks like meaningless noise. This is what the padlock and HTTPS in your browser mean: your connection to the site is encrypted, so a snoop on the same network cannot read your password or card number. Think of encryption as a lockbox: anyone can carry the box, but only the holder of the key can open it. It is the single most important tool for keeping data private as it travels.

Key idea: encryption scrambles data so only a key holder can read it, which is what HTTPS uses to protect your connection.

Authentication and strong passwords

Authentication is proving you are who you claim to be, usually with a password. Weak or reused passwords are a leading cause of break-ins, so a few rules matter: make passwords long, avoid reusing the same one across sites, and consider a password manager to keep track of many strong ones. Even better is multi-factor authentication (MFA), which adds a second proof, like a code sent to your phone, so a stolen password alone is not enough to get in. That second factor blocks most account takeovers.

Key idea: strong, unique passwords plus multi-factor authentication stop most account break-ins.

Safe-computing habits

A short set of everyday habits prevents the majority of problems:

• Think before you click. Do not open unexpected links or attachments, especially those creating urgency or fear.
• Keep software updated. Updates patch security holes; delaying them leaves known doors open.
• Use unique passwords and MFA. This limits the damage when any single site is breached.
• Verify before you trust. If a message seems off, confirm through a channel you know is real rather than the one it arrived on.

Key idea: think before clicking, keep software updated, use unique passwords with MFA, and verify suspicious messages.

The AP exam: what to expect

The AP Computer Science Principles assessment has two parts. The first is the end-of-course exam, a set of multiple-choice questions taken on paper or computer that test the concepts across all five Big Ideas, the very ideas this course covered. The second is the Create Performance Task, a program you build yourself and submit before the exam. Together they determine your score, so both the ideas and the project matter.

Key idea: the AP CSP assessment combines a multiple-choice exam on the Big Ideas with a program you create and submit.

The Create Performance Task

The Create Performance Task asks you to design and build a program of your own choosing and to explain how it works. You submit your code, a short video showing the program running, and written responses about your design. Certain elements are expected in the program, and knowing them shapes what you build:

• A clear purpose for the program, stated plainly.
• Use of a list (or similar collection) to manage data, showing you can store many values together.
• A procedure you wrote that takes a parameter and includes an algorithm with sequencing, selection, and iteration, that is, ordered steps, a conditional, and a loop.
• A call to that procedure, and a written explanation of how it works.

Notice that these requirements map directly onto skills from earlier modules: lists and loops, conditionals, and procedures with parameters. If you understood those lessons, you already have the building blocks. The best approach is to start early, pick a project you find genuinely interesting, and build it in small, tested steps, exactly the iterative process from the very first module.

Key idea: the Create Task rewards a program with a clear purpose, a list, and your own procedure using sequencing, selection, and iteration.

Common misconceptions

• "Hackers mostly break in with brilliant code." Most attacks rely on tricking a person, through phishing or a reused password, so human alertness is a major defense.
• "A strong password alone keeps me safe." Passwords leak in breaches, which is why multi-factor authentication, a second proof, blocks most takeovers.
• "HTTPS makes everything I do completely safe." HTTPS encrypts the connection, but it does not protect against clicking a bad link, weak passwords, or malware on your device.
• "The Create Task needs a huge, complex program." It rewards clear use of core skills, a purpose, a list, and your own procedure, not size. A focused project done well is the goal.

Recap

• Common threats, malware, phishing, and data breaches, mostly rely on deception.
• Encryption scrambles data so only a key holder can read it; HTTPS uses it to protect connections.
• Strong, unique passwords plus multi-factor authentication stop most break-ins.
• Safe habits: think before clicking, update software, use MFA, and verify suspicious messages.
• The AP assessment pairs a multiple-choice exam with a Create Task featuring a purpose, a list, and your own procedure using sequencing, selection, and iteration.

Sources

1. College Board, "AP Computer Science Principles Course and Exam Description," exam and Create Performance Task requirements. find source ↗
2. Code.org ↗, "AP CSP," Big Idea 5 cybersecurity and Create Task preparation.
3. Khan Academy, "Computers and the Internet: Cybersecurity." khanacademy.org ↗
4. MDN Web Docs, Glossary entries for "Encryption," "HTTPS," and "Phishing." find source ↗