What does a student learn in
California, Grade 11, Computer Science & Digital Fluency ?

Students break a complex coding problem into parts, then build a solution by writing new logic and reusing code that already works. They don't start from scratch every time.

Students learn to store and work with groups of related data (like a list of names or scores) instead of creating a separate variable for each one. This makes programs shorter, more flexible, and easier to update.

Students explain why they chose a loop or a conditional instead of another approach, weighing whether the code is easy to read, runs quickly, and solves the problem cleanly. The choice always involves tradeoffs.

Students build a working program step by step, testing and improving it along the way. The program responds to real events, like a button click or a keypress, to trigger what happens next.

Students break a big coding problem into smaller, manageable pieces, then write separate blocks of code to handle each piece. This mirrors how professional software is actually built.

Students break a program into smaller, reusable pieces, such as functions or procedures, so the code is easier to read, fix, and build on. Each piece handles one job.

Students plan and revise programs with real input from the people who will actually use them, not just from the original designer's assumptions. Testing with a range of users shapes what the final program does and how it works.

Students learn why borrowed code or software libraries come with rules about how you can use them. A license can limit what students build with that code, who can see it, or whether they can share it.

Students test a program they built, find what breaks or confuses users, and fix it. This cycle of testing and improving repeats until the program works better and more people can use it reliably.

Students work in teams to plan and build software projects, using shared tools like version control or collaborative editors to divide the work and keep everyone's changes in sync.

Students record their design choices as a program takes shape, using notes, diagrams, or walkthroughs that explain why the code works the way it does.

Students explain how AI is built into everyday products, from spam filters that sort email to self-driving cars that read the road. The goal is to see AI as a set of programmed decisions, not a mystery.

Students write code that uses AI techniques, like training a model on sample data, to solve a straightforward problem. The focus is on understanding how the algorithm works, not just running a tool someone else built.

Students write code that searches through data to find a specific value and sorts lists into order. These are two of the most common building blocks in real software.

Students compare two or more ways to solve the same problem and decide which one does it faster or with less work. Think sorting a list of 1,000 names versus 1,000,000: the choice of method starts to matter a lot.

Students learn when to use a list, a table, or a key-value pair to store information, and why the choice matters. Picking the right structure makes a program faster and easier to update.

Students trace how a recursive function calls itself repeatedly, each time with a smaller version of the problem, until it hits a stopping condition and works its way back to a final answer.

Students break a big, messy problem into smaller pieces, then spot patterns those pieces share. Recognizing that pattern lets them write one reusable solution instead of solving the same thing over and over.

Students break a complex problem into smaller, reusable pieces of code, like a custom function that handles one job, then combine those pieces into a working solution.

Students learn to use pre-built code libraries and APIs, collections of ready-made tools other programmers wrote, so they can solve bigger problems without building every piece from scratch.

Students plan, build, and test programs with a real-world development process, thinking about how different people will actually use what they make.

Students write and test programs that run on more than one type of device or operating system, such as a phone, a browser, or a desktop computer.

Students find weak spots in a program where someone could break in, steal data, or crash the system, then fix the code to close those gaps.

Students write a set of test cases before or after coding to confirm the program does what it was designed to do. Each test feeds the program a specific input and checks whether the output matches what was expected.

Students take a working program and add new features to it, then think through what those changes might break or improve elsewhere in the code.

Students read through a finished program and judge whether the code is clear, correct, and easy to maintain. This is the same process professional developers use before releasing software.

Students learn to write code as part of a team, using shared tools that track every change, catch errors, and keep the whole group's work organized in one place.

Students look at two or more programming languages side by side and explain why one fits a task better than another. Python might be the right pick for data analysis while another language suits building a phone app.

Abstractions are the layers that hide how a computer actually works so users don't have to think about it. Students explain why clicking a button or opening an app feels simple, even though thousands of operations are running underneath.

Students examine how apps, operating systems, and physical hardware depend on each other, moving from the keys a user presses down to the electrical signals a chip reads. Each layer hides complexity so the one above it can work without knowing every detail.

Students create a step-by-step guide others can follow to track down and fix errors in a computer system. The focus is on building a repeatable process, not just solving one problem.

Students learn how the physical parts of a computer, like circuits and chips, carry out the yes/no decisions that make software run. This connects the code on screen to the actual hardware underneath it.

Students learn what an operating system actually does: managing memory, running programs, and connecting software to hardware like a keyboard or screen. Think of it as the layer that keeps everything on a computer working together.

Students practice converting the same information across different formats, reading a letter as a number, a color as a code, an image as a grid of values. The goal is seeing that all digital data is just numbers stored in different arrangements.

Students weigh the real costs of storing data in different ways, such as choosing between speed and file size, or between easy searching and simple structure.

Students pick a real-world topic, gather data about it, and build a chart or graph that makes the pattern clear to someone who wasn't part of the research.

Students revise a working computer model after comparing its predictions against real data. The goal is closing the gap between what the model says should happen and what the data actually shows.

Students choose the right tool for the job (a survey, a sensor, a spreadsheet) and use it to gather a real set of data they can then analyze.

Students examine real datasets (think weather records, traffic patterns, or health statistics) and use software tools to spot trends or outliers that aren't obvious from a quick look. The skill is learning to read what the numbers are actually saying.

Students test whether a computer model or simulation actually supports the hypothesis it was built to check, then judge what needs to change when the results don't match expectations.

Students look at how computers and the internet shape everyday life: who gets access, who benefits, who gets left out, and what tradeoffs society accepts to keep systems running.

Students examine how bias in the design of apps, algorithms, and digital tools can lead to unfair outcomes, then practice spotting and questioning those problems in real examples.

Students take one algorithm, such as a sorting method or search process, and show how the same step-by-step logic solves problems in fields like medicine, economics, or music. The algorithm doesn't change; the problem does.

Students examine how new technologies (AI, social media, surveillance tools) shape jobs, elections, and daily life, then back up their conclusions with evidence from credible sources.

Students practice using digital tools like video calls, shared documents, or online forums to connect and collaborate with people from different backgrounds or industries.

Students examine how copyright and patent laws can protect creators and reward new ideas, but also how those same laws can slow down future inventors who need to build on earlier work.

Students explain what happens to personal data that apps, websites, and devices collect automatically, and why that collection raises privacy risks. Think location tracking, browsing history, or facial recognition running in the background without a clear opt-out.

Students look at real tradeoffs: what people give up when apps, laws, or companies collect personal data, and what they gain in safety or convenience. The goal is to form a reasoned position, not just list pros and cons.

Students look at apps, algorithms, or digital tools and judge what they help people do well and what harm they might cause. Then they think through changes that would make those tools more fair or less damaging.

Students look at a technology that changed daily life (social media, GPS, streaming) and think through where it might go next and what that could mean for how people live and work.

Students examine who has access to computers and the internet around the world, and consider how wealth, geography, and power shape who benefits from technology and who gets left out.

Students read real laws and argue whether they help or hurt the way software gets built and used. Think copyright rules, privacy laws, or age restrictions on apps.

Students learn what can slow down, disrupt, or break a network, things like too much traffic, hardware failure, or a weak signal, and why those problems matter in the real world.

Students explain how the internet is built to keep working even when parts of it fail. That means understanding why data travels in small packets across multiple paths instead of one fixed route.

Students look at real security threats like hacking or stolen passwords and compare the tools used to stop them, such as firewalls, encryption, and two-factor login. The goal is to understand why different threats need different defenses.

Students compare encryption methods to understand how digital information stays private as it travels across the internet. Think passwords, online banking, and secure messages.

Students learn how the internet stays reliable as it grows, tracing how routers, switches, and servers pass data from one device to another and how addresses and network layout determine which path that data takes.

Students explain how the internet's basic rules (like how data is broken into packets and routed across networks) shape the apps and services built on top of it. A design choice at the network level can ripple up into every website and app that relies on it.

Students identify a security threat, such as a phishing attack or weak password policy, and propose or build a practical fix. The work goes beyond spotting the problem to explaining why the solution actually reduces the risk.

Students study how encryption scrambles data so only the right recipient can read it. They look at real techniques used to protect passwords, messages, and online transactions.