AP Computer Science Principles · Unit 1
Unit 1 · Concept 1 of 5 · ~6 min read · 10–13% of AP exam
Pair programming, peer feedback, and team testing — the practices that make computing a group activity. Built for AP CSP students learning to design, build, and explain programs together.
Collaboration in computing means working with others to design, build, test, or improve a program. Programmers collaborate to catch errors one person missed, share ideas, and create solutions that work for more people. On the AP CSP exam, collaboration shows up in MCQ scenarios about pair programming, peer testing, and group design.
Collaboration in computing is working with others to design, build, test, or improve a program. Real collaboration means sharing ideas, dividing tasks, giving and receiving feedback, and learning from each other. It is not splitting up work so one person does everything, and it is not copying someone else's code.
Programmers almost never work completely alone. Even on individual projects, they ask classmates for feedback, share design ideas, and test each other's code. The reason is simple: two people see problems one person misses. A second perspective catches bugs, points out confusing instructions, and suggests features the original programmer didn't consider.
For AP CSP, collaboration is part of Big Idea 1: Creative Development. The exam treats it as a real skill — not just a nice idea — and tests whether students can identify good collaboration versus poor collaboration. Real collaboration also matters for the Create Task. You can collaborate while planning and learning, but the actual program submission, video, and written responses must be your own work.
Collaboration shows up at multiple points in the program development process. You might brainstorm in the investigate step, share designs in the design step, ask for feedback in the test step, and discuss refinements in the refine step. Each one is a chance for collaboration to make the program stronger.
Healthy collaboration also connects to iterative development: partners test each version, compare notes, and decide what to fix before the next cycle. When you document decisions after a feedback session, you are building habits that help on the program documentation page later in Unit 1.
MCQs rarely ask you to define collaboration in one sentence. They describe a scenario — a classmate tests an app, two students pair-program, a team brainstorms ideas — and ask which action best shows collaboration. The correct answer almost always involves sharing ideas, giving specific feedback, or testing together. Wrong answers often describe copying, ignoring feedback, or one person doing all the work while others watch.
Collaboration matters because no single programmer catches every bug, sees every user perspective, or thinks of every feature. Working with others produces stronger programs — and stronger programmers — because each person learns from the others.
| Benefit | What it means | Example |
|---|---|---|
| Catches errors | A second pair of eyes finds bugs you missed | Classmate notices your score doesn't reset |
| Improves design | Different people suggest different ideas | Teammate suggests a "skip" button you didn't think of |
| Spots usability issues | Other users get confused where you don't | Friend can't find the submit button |
| Builds shared knowledge | You learn how someone else solved a problem | Classmate shows you a cleaner loop |
| Reduces blind spots | Diverse perspectives catch assumptions | Someone tests on an old phone — finds a layout bug |
Each benefit in the table comes from the same idea: other people experience your program differently than you do. After hours on your own code, you know where every button is and what every variable means. A fresh tester does not — and that gap is exactly what AP CSP wants you to notice.
Collaboration also makes program testing more thorough. One partner might think of edge cases the other skipped. A shared test log keeps both people aligned on what "working" means before you refine or document the next version.
In professional teams, collaboration scales beyond pairs — designers, testers, and programmers each bring a specialty. AP CSP focuses on classroom-scale collaboration, but the same principle applies: different roles catch different problems. Even on a solo Create Task, asking one trusted tester to run your app for five minutes often reveals more than another hour of solo clicking.
Collaboration and copying are different. Collaboration is sharing ideas and giving feedback so each person's work gets stronger. Copying is taking someone else's work and presenting it as your own. Collaboration makes you a better programmer. Copying skips the learning that AP CSP is testing.
| Collaboration | Copying |
|---|---|
| Discussing ideas | Submitting someone else's code |
| Giving feedback on someone's project | Taking code without understanding it |
| Testing another student's program | Letting someone else do your assignment |
| Explaining your own code | Using code you can't explain |
| Working together on a planning template | Sharing a finished Create Task project |
The Create Task line: You can collaborate while learning, planning, and brainstorming. You CANNOT collaborate during the video recording or share code segments for your written responses. Your final Create Task submission must be your own work — every line of code, every word of explanation.
On MCQs, if a stem describes a student receiving exact code to paste in, that is copying — not collaboration. If a stem describes asking a classmate what confused them during testing, that is collaboration. Read whether the action builds understanding or replaces it.
How this shows up in the Create Task
Collaboration is allowed during planning and learning, but not during the final submission. You can brainstorm project ideas with classmates, ask them to test your prototype, and use their feedback to improve your code. But the code you submit, the video you record, and the written responses you write on exam day must be entirely your own work.
There are several common forms of collaboration in computing: pair programming, peer testing, brainstorming, code review, and user feedback. Each one happens at a different point in the development process and produces different kinds of improvement.
| Form | What happens | Best used during |
|---|---|---|
| Pair programming | Two programmers work on one program — one writes, one reviews | Building features |
| Peer testing | A classmate tests your program | After iterative development cycles |
| Brainstorming | A team suggests ideas before anyone codes | Investigate / design steps |
| Code review | Someone reads your code and points out issues | After a feature is built |
| User feedback | Real users try the program and report what confused them | Refinement step |
In pair programming, one person is the driver (types) and the other is the navigator (watches, catches typos, thinks ahead). Roles swap often so both people stay engaged. The goal is not to finish faster by splitting keyboard time — it is to catch mistakes and talk through design choices while the code is still fresh.
Peer testing focuses on behavior: does the program work for someone who did not write it? Code review focuses on readability: can another programmer follow your logic? Both are collaboration because they depend on a second person's perspective. Official Big Idea 1 standards on College Board AP Central describe how computing innovations are developed through collaboration and iteration — these forms are how that idea shows up in a classroom.
Other people may see the problem differently. Your classmate might realize your "study app" should also work for parents — a use case you didn't consider. That conversation belongs in the investigate step of the program development process, before you commit to a design that only fits one user.
Reviewers find bugs the original programmer is blind to. After staring at your own code for hours, you stop seeing it clearly. A partner running program testing on your prototype often finds edge cases — blank input, wrong button order, score that never resets — in minutes.
Feedback from someone unfamiliar with your code makes the program easier to use. If they can't figure it out, neither will an AP grader watching your Create Task video. Usability fixes after peer feedback are a normal part of refinement, not a sign that your first version failed.
Different users notice different needs. Someone might point out that your color choices are hard to read, or your text is too small for a phone. Inclusive design often starts with collaboration — asking people unlike you to try the program and report what blocked them.
Scenario: A student is building a study timer app. A classmate tests it and says the pause button is confusing. The student changes the label to "Pause Timer" and adds a restart option.
Question: How did collaboration improve the program?
Answer: The feedback identified a usability issue the original student couldn't see. The classmate's perspective led to a clearer interface (renamed button) and a new feature (restart). This is exactly the kind of collaboration AP CSP tests — specific feedback leading to specific refinement.
Read each scenario and decide: is this collaboration, copying, or something else? You'll get immediate feedback after each answer. Progress saves in this browser session so you can refresh and continue where you left off.
Miss a question? Re-read the collaboration vs copying table above, then use Try again at the end to run all six scenarios again.
Question 1 of 6
Review any missed scenarios in the tables above, then try the AP-style questions below.
| Misconception | Reality |
|---|---|
| Collaboration means everyone writes the same code | Collaboration includes planning, testing, feedback, and design — not just writing |
| Feedback is only useful at the end | Feedback is most useful throughout development, not just before submission |
| Collaboration means copying | Real collaboration still requires you to understand and explain your own code |
| If I get help, the project isn't really mine | Getting feedback and refining is normal — the work is still yours if you understand it |
| Pair programming is just talking, not working | Pair programming is the most efficient form of collaboration when done well |
When an MCQ option sounds like "everyone submits the same file," reject it unless the stem explicitly describes an allowed group project for your class. AP CSP Create Task rules treat the final artifact as individual work even when planning was collaborative.
Another trap is treating "working together" as collaboration when only one person codes and others watch without feedback. Passive observation does not combine perspectives the way peer testing, code review, or pair programming does. On the exam, look for actions where both people contribute observations or decisions that change the program.
These three questions mirror common Unit 1 MCQ patterns about collaboration, pair programming, and where collaboration fits in the development process. Click an answer to see whether you are correct and read the explanation.
1. Which action is the best example of collaboration in program development?
EasyWhy C is wrong: Copying is the opposite of collaboration — you are not building understanding together.
2. Two programmers are working on the same project. One writes code while the other watches and points out issues immediately. What is this called?
Medium3. A student shows their Create Task project to a classmate, asks them to test it, and uses the feedback to fix a bug. What part of the program development process did collaboration help with?
HardAP tip: Peer testing is collaboration; submitting someone else's final project is not.
Tick each line when you can explain the idea without looking at the tables above. When all five are checked, you are ready for the next Unit 1 concept — the program development process.
0 of 5 ready
Collaboration in computing means working with others to design, build, test, or improve a program. It includes pair programming, peer testing, brainstorming, code review, and user feedback. The point is to combine perspectives — not to split up tasks so one person does all the work.
Collaboration is sharing ideas, giving feedback, and learning from each other so each person's work gets stronger. Copying is taking someone's code without understanding it and submitting it as your own. Collaboration makes you a better programmer. Copying skips the part AP CSP is testing.
Pair programming is a form of collaboration where two programmers work on one program together. One person writes the code (the "driver") while the other reviews each line and suggests improvements (the "navigator"). Pair programming often produces fewer bugs because two perspectives catch problems faster.
Yes — but only during certain parts. You can collaborate while planning your project, brainstorming ideas, and asking classmates to test prototypes. You cannot collaborate when recording the final video, selecting code for the Personalized Project Reference, or writing your exam-day responses. The final submission must be your own work.
Collaboration improves programs in five main ways: it catches bugs one person missed, brings in new ideas, exposes usability issues, builds shared knowledge, and reduces blind spots. Each one comes from the simple fact that two people see things differently.
Specific feedback is the most useful. "Make it better" doesn't help. "The submit button is hard to find on mobile" tells you exactly what to fix. When you ask for feedback, ask specific questions — "what confused you?" — and watch where the other person hesitates.
For AP CSP coursework, follow your teacher's rules — they may allow help from anyone or limit it to your class. For your own learning outside school, collaboration with anyone (online communities, tutors, friends) is fine. Just remember that any code in your Create Task submission must be your own.
This is one of the most common collaboration challenges. The best approach is to talk to them directly — name a specific contribution you'd like to see, like "Can you test the next version this week?" — instead of getting frustrated silently. If the problem continues, talk to your teacher early, not after the deadline.