CDS 210 - Fall 2026 Syllabus

Overview

Course description

This course builds on DS110 (Python for Data Science) by expanding on programming language, systems, and algorithmic concepts introduced in the prior course. The course begins by exploring the different types of programming languages and introducing students to important systems-level concepts such as computer architecture, compilers, file systems, and using the command line. It then introduces a high-performance language (Rust), how it manages memory, and how to use it to implement fundamental data structures and algorithms. Then it covers how to use Rust in conjunction with Python and external libraries to perform data manipulation and analysis.

Prerequisites: CDS 110 or equivalent

BU Hub units: this course meets requirements for Quantitative Reasoning II, Creativity/Innovation, and Digital/Multimedia Expression. For details on how the course meets the learning outcomes for each, see the appendix.

Teaching Staff

Instructor (both sections): Lauren Wheelock
Email: laurenbw@bu.edu
Office: CDS 1506

Our TAs and CAs have all taken 210 themselves and are passionate about the subject and teaching it. They are a great resource, so lean on them when you need to!

For anything about the course, Piazza is usually faster than email and helps us track open loops, so please use it over email when possible.

See Office Hours and Coffee Chats below for when we are available.

Meeting Times and Rooms

Both lecture sections meet Mondays, Wednesdays, and Fridays in 871 Commonwealth Ave, CGS 505.

A1 Lecture: 11:15am-12:05pm

B1 Lecture: 12:20pm-1:10pm

Section A Discussions (Wednesdays, 50 min):

• A2: 1:25pm - 2:15pm, 871 Commonwealth Ave CGS 525 (led by Matt)
• A3: 2:30pm - 3:20pm, 871 Commonwealth Ave CGS 525 (led by Gabriel)
• A4: 3:35pm - 4:25pm, 871 Commonwealth Ave CGS 525 (led by Gabriel)

Section B Discussions (Tuesdays, 50 min):

• B2: 11:00am - 11:50am, 111 Cummington St MCS B31 (led by Emir)
• B3: 12:30pm - 1:20pm, 111 Cummington St MCS B31 (led by Kristen)
• B4: 2:00pm - 2:50pm, 665 Comm Ave CDS 164 (led by Nia)

Note: the official schedule lists the B discussion sections as running until 12:15pm, 1:45pm, and 3:15pm, because that is the full length of those time slots. We will typically only use 50 minutes, ending at the times listed above. On code review weeks, B3 and B4 may use the full time.

Note: You must attend the lecture and discussion sessions you are assigned to. We can make one-off exceptions with sufficient notice but, in general, showing up to a different lecture or section without notice will result in no attendance credit and may cause other issues (especially for code reviews and exam corrections).

Office Hours and Coffee Chats

Prof. Wheelock's office hours

Drop-in, no sign-up needed, in CDS 1506.

• Mondays 9:30 - 10:30am
• Wednesdays 9:30 - 10:30am

Come with a question, to work on the project near other people, or to listen to what others are asking. If you want to speak privately let me know in advance.

Staff office hours

All TA and CS office hours will be in the CDS building's 5th floor Pavillion:

• Mon 5-6: Kesar @ East Side
• Wed 4-5: Lingjie @ East Side
• Wed 5-6: Gabriel @ East Side
• Thu 4-5: Kristen @ South Side
• Thu 5-6: Matt @ East Side
• Fri 1:30-2:30: Nia @ West Side
• Fri 2:30-3:30: Emir @ East Side

Coffee chats with Prof. Wheelock

Coffee chats are 20 minute appointments you can book with me, individually or in small groups. There will literally be coffee (or new this semester - tea or hot chocolate). Coffee chats have one rule: we do not talk about the course. No discussion of grades, assignments, or the material. They are for talking about life, career plans, research, what you want to do after this, existential philosophy, whether AI is going to take over the world, or whatever is on your mind.

• Fridays 9:30 - 10:30am
• Every other Tuesday 2:00 - 3:00pm, starting September 8

Sign up at https://calendly.com/laurenbw-bu/coffee-chats. If nobody has signed up for a slot by that morning, it becomes drop-in. To ensure everyone has a chance, please sign up no more often than once every 2 weeks, but you can always drop in.

If none of these times work, let me know and we will work something out individually. Send a private note on Piazza with a few suggestions for times you are available. We may need to use Zoom. Other courses and discussions overlap the times above, so if you have a standing conflict, please do say something, I would love to meet with you.

Course Websites

Course Content Overview

By the end of the course you should be able to read and write programs in a compiled, statically typed language (Rust); explain how a program uses memory and why that affects its speed; form well-reasoned preferences between programs that produce the same output; and use the everyday tools of software work including the command line, version control, and automated testing. More than any single topic, the goal here is for you to come away able to explain what your code does and why you wrote it that way.

• Part 1: Tools and Your First Program (Weeks 1-3)
• Part 2: Building and Judging Programs (Weeks 3-4)
• Part 3: Structuring Data (Week 5)
• Review and Midterm 1 (Week 6)
• Part 4: Memory (Weeks 7-9)
• Part 5: Borrowing and Working with Data (Weeks 9-10)
• Review and Midterm 2 (Week 10)
• Part 6: Collections and Abstraction (Weeks 11-12)
• Part 7: Practice and Payoff (Weeks 13-15)
• Final exam: Monday, December 14, 12:00-2:00pm, in our room (CGS 505)

For a complete list of topics that will be kept up-to-date as we go through the term, see the Schedule.

How the course works

Grading

How your grade is calculated

Your grade will be determined as:

All three projects use the same point structure:

We will use Gradescope to track grades over the course of the semester, which you can verify at any time and use to compute your current grade in the course for yourself. I will also publish "standings" files periodically on Gradescope which will include your attendance and other graded records, along with course average projections after the first and second midterm periods.

Curves

I will use the standard map from numeric grades to letter grades (>=93 is A, >=90 is A-, etc). For the midterms and final, we may add a fixed number of "free" points to everyone uniformly to effectively curve the exam at our discretion - this will never result in a lower grade for anyone. However, I make an effort to design exams such that they result in a fair distribution without adding curve points, and only use this policy in exceptional circumstances. If this comes into play, it will be added after exam corrections, and exam grades will be capped at 100%.

Lectures and Discussions

Lectures will involve extensive hands-on practice. Each class includes interactive presentations of new concepts, small-group activities on paper and on laptops, and built-in review periods. Laptops (and tablets) stay closed unless we are actively coding, so I will print handouts of the lecture notes for you to write on. Because of this active format, regular attendance and participation are important and count for a significant portion of your grade (15%).

Discussions

Discussions will review lecture material, host project code reviews, and run proctored exam corrections. They will also adapt over the semester to the needs of the class.

Pre-work

Pre-work will be assigned before most lectures to prepare you for in-class activities. These typically include readings plus a single quiz question. We will also periodically ask for feedback and reflections on the course between lectures.

Mid-semester update: The pre-work grade will now be calculated by dividing the semester up into third and dropping 2-3 pre-works from each third, accounting for occasional conflicts and forgetting, similar to the attendance policy.

Attendance and participation

Since a large component of your learning will come from in-class activities and discussions, attendance and participation are essential and account for 15% of your grade.

Lecture attendance is recorded in a few different ways, and which one we use varies from day to day:

• In-class activity sheets, where your group writes down everyone's name and turns in the sheet
• In-class Gradescope tasks, submitted individually or as a group during lecture. Some of these ask for a password that I say out loud in the room and post nowhere else
• Cold-calling, which doubles as a check that the people marked present are the people in the room

I also take a headcount most days. If the headcount and the names I collect stop lining up, we will move to stricter methods, and they will be more annoying for all of us. Please do not sign in for someone who is not there.

Discussion attendance is similar, will be taken on weeks when we do not have code review or exam corrections, and will be done on paper or via gradescope or other tools, depending on the week.

This course follows BU's policy on religious observance - if you are absent due to a religious conflict let me know and this will not count against you. If you cannot attend classes for a while, please let me know as soon as possible so we can make a plan so you don't fall behind. If you miss a lecture, please review the lecture notes and lecture recording. If I cannot teach in person myself, I will send a Piazza announcement with instructions.

How attendance is calculated

The 15% is split evenly across three attendance periods, 5% each. Within a period, every session is worth points:

• Lecture is worth 1 point
• Discussion is worth 2 points

Each period contains 18 points of sessions, and you need 16 points to earn the full 5%. That creates an excused-absence allowance of 2 points per period, which is equivalent to two lectures or one discussion, no questions asked and no need to notify me. Extra points do not roll over to the next period.

Some discussions are not on this list, because they already carry their own consequences and do not need attendance points on top: the three code review sessions (D5, D8, D12) and the two exam corrections sessions (D6, D10).

Your broken-week session counts toward period 3 regardless of when it takes place (October for A and November for B).

Cold-calling

Sometimes in class I will ask folks to raise hands to answer questions, and at other times I will call on people who have not volunteered. Since this makes a lot of people nervous, I wanted to share a bit of detail here about how and why I do this.

Why I do it. In most classes, only a few people answer everything while everyone else listens, and it gets worse over the course of the semester. Cold-calling lets us hear more voices, and it tells me what is actually landing for the average student. It also helps folks get comfortable speaking up. Sometimes students who are "called in" this way turn into more engaged participants later. It also serves as a cross-check on attendance.

How I pick people. Each class, I generate a random list, weighted towards students who have not been called on recently or who have been absent. So if you answered something on Monday, you are unlikely to come up again on Wednesday, but it is always possible.

The questions are low-stakes. Some questions are open-ended, like asking about what you noticed or what you think will happen. At other times I might ask a review question with a clear right answer, but give you the chance to think and talk to a neighbor before I call on you.

You can always pass. "I don't know" is a fine answer. I might prompt you with a more basic question, or ask someone else to volunteer, but there is no penalty for passing or getting something wrong. I only track if I called on you and if you spoke, not what you said.

Projects

Projects are three assignments that make up all of your non-exam work. Each includes checkpoints, final automated tests, and a code review in your discussion section.

There are three projects, and they all run on the same four-week rhythm between exams:

1. Released on a Friday
2. Two checkpoints, on the next two Fridays, each worth 1%
3. Due the Friday after that
4. Code review, in your discussion section the following week

Projects are graded once. There is no process for improving your project grade after submission.

Checkpoints

Each project has two checkpoints: earlier deadlines where we run your code against a subset of the tests. Checkpoints exist to encourage and reward work on a project over time, and they let us find out who needs help well before the final deadline.

Missing a checkpoint is not the end of the world. Half of the final visible test points come from re-running the checkpoint tests at the final deadline. So a missed checkpoint costs you that checkpoint's point for being late, but the code itself still earns credit when you submit it. Checkpoints reward being on time; they do not punish you a second time for the same thing.

Checkpoint dates are listed on the schedule, and checkpoint tests will be marked as such in the project base repo.

Visible and secret tests

Some of the tests we grade you on are ones you can run yourself, and some are not.

• Visible tests come with the base repo. You can run them as often as you like and know exactly where you stand.
• Secret tests are run by us after the deadline. You will see your score on them, but not which ones failed.

Secret tests serve two purposes: to get you to think about the overall project and its edge cases in a realistic manner, and to mitigate the overuse of AI.

Working with other people's code

All three projects are individual work.

That said, learning git and GitHub is a major goal of this course, and git exists because real software is written by groups. So each project will involve realistic collaboration "events" staged by the teaching team to practice the tools and moves you'll need in the real world (more on that later).

You are always welcome to talk through approaches with classmates. See the collaboration policy below for where the line is.

Submitting your work

For each task, checkpoint, and project, we publish a Gradescope assignment. For coding work this will link to a base repository on GitHub. You fork it, do your work there, and commit as you go.

To submit, you paste the URL of your fork into Gradescope. We download your repository from that URL and run tests against it.

(If this language is new to you, that's okay! We'll go over all of it in Week 2.)

Everything you submit runs through GitHub, which means your commit history is part of what we see and evaluate.

Code reviews

Code reviews happen during your discussion section in the week following each deadline. A member of the course staff will go through your code and your commit history with you, ask you to explain specific choices, ask "what if" questions, and give you feedback.

You must attend your code review. If you need to reschedule, give us at least 2 days' notice and we will work with you to find another time.

We will review late submissions in whatever state they are in at the time of the code review - we will not postpone review because submissions are delayed.

If you do not attend a code review, you will receive a zero on the entire project, including the autograded portion, even if your tests passed. The code review is where you demonstrate that you understand the work you submitted, and passing tests does not show that on its own. This principle is reflected in the GenAI policy below.

Deadlines and late work

Everything is due at midnight except pre-lecture work, which is due before the lecture it prepares you for.

If your work is up to 48 hours late, you can still qualify for up to 80% credit for the assignment. After 48 hours, late work will not be accepted unless you have made prior arrangements due to extraordinary circumstances.

Note that late project submissions still get reviewed on the normal schedule, in the discussion section following the deadline.

Exams

Exams are two midterms and a cumulative final exam covering theory and short hand-coding problems (which we will practice in class!).

No external resources may be used in exams: no calculators, reference sheets, scrap paper, or electronic devices of any kind. Smart watches and glasses must not be worn, even if switched off.

If you have a valid conflict with a test date, you must tell me as soon as you are aware, and with a minimum of one week's notice (unless there are extenuating circumstances such as a medical emergency) so we can arrange a make-up test.

If you have accommodations for exams, please schedule all three dates (October 9, November 6, and December 14) with the testing center now, in the first two weeks of class. Historically, the testing center has booked up quickly. See below for more about accommodations.

Second chances

Exam corrections. About two weeks after each midterm, we hold proctored corrections during discussion section. You will have the opportunity to redo specific questions in person with your old, completed exam alongside a blank exam. Your final grade for that midterm will be the average of your original and corrected scores. (That is, you can earn back up to 50% of your lost points via corrections.)

A strong final exam counts for more. If you are struggling in the beginning of the course and make an effort to catch up, your grade will reflect that improvement. If your final exam score is higher than your midterm average, we reweight your exams automatically:

You do not need to request this or do anything differently. We compute your grade both ways and use whichever is better for you. Your midterm average here is your score after any corrections.

Regrading

You have the right to request a re-grade of any assignment or test. All regrade requests must be submitted using the Gradescope interface. If you request a regrade for a portion of an assignment, then we may review the entire assignment, not just the part in question. This may result in a lower grade. We only restore missed points when a factual error was made in grading (such as misreading handwriting, or misclicking in Gradescope), not to respond to arguments for more partial credit. This keeps grading consistent and fair to all students.

Policies

Academic honesty

You must adhere to BU's Academic Conduct Code at all times. Please be sure to read it here. In particular: cheating on an exam, passing off another student's work as your own, or plagiarism of writing or code are grounds for a grade reduction in the course and referral to BU's Academic Conduct Committee. If you have any questions about the policy, please send me a private Piazza note before taking an action that might be a violation.

Collaboration

You are free to discuss problems and approaches with other students but must do your own code writing. If a significant portion of your solution is derived from someone else's work (your classmate, a website, an AI, etc.), you must cite that source in your writeup or comments. You will not be penalized for using outside sources as long as you cite them appropriately.

You must also understand your solution well enough to be able to explain it if asked.

AI use

You are allowed to use GenAI (e.g., Claude, ChatGPT, GitHub Copilot, etc.) to help you understand concepts, debug your code, or generate ideas. You should understand that this may help or impede your learning depending on how you use it.

This course is designed so that, largely, I do not have to police that choice. The parts of your grade that carry the most weight - exams and the code reviews on your projects - all require you to explain your work in person. If you lean on AI in a way that leaves you unable to explain what you built, that will become apparent during code review and on exams.

If you use GenAI on a project, you must cite what you used and how you used it (for brainstorming, autocomplete, generating comments, fixing specific bugs, etc.) in your project's README. You must also understand your solution well enough to explain it during a code review or in a follow-up conversation if asked. If it is determined that you overused GenAI to the extent that you fundamentally do not understand the code you submitted, you will receive a zero on the entire assignment, including the autograded portion, even if the autograded tests passed.

Your professor and TAs/CAs are happy to help you write and debug your own code during office hours, but we will not help you understand or debug code generated by AI.

For our departmental policy, see the CDS policy on GenAI. Note that this policy is in the process of being updated and parts of it do not apply in this course (for example, we do NOT require you to submit your entire chat history as an appendix). If you have any questions about the policy let us know.

Accommodations

If you need accommodations, let me know as soon as possible. You have the right to have your needs met, and the sooner you let me know, the sooner I can make arrangements to support you.

This course follows all BU policies regarding accommodations for students with documented disabilities. If you are a student with a disability or believe you might have a disability that requires accommodations, please contact the Office for Disability Services (ODS) at (617) 353-3658 or access@bu.edu to coordinate accommodation requests.

If you require accommodations for exams, please schedule all three dates, October 9, November 6, and December 14, at the BU testing center within the first two weeks of the semester while they still have plenty of availability.

Appendix: BU Hub Learning Outcomes

This course carries three units in BU's Hub: Quantitative Reasoning II, Digital/Multimedia Expression, and Creativity/Innovation. Each Hub area publishes a set of learning outcomes, and here we describe how this course meets those objectives. For students of the course, reading this section is not required.

Quantitative Reasoning II (QR2)

Outcome 1. Students will frame and solve complex problems using quantitative tools, such as analytical, statistical, or computational methods.

Every project asks students to work from a problem statement to a working program. Lectures give students the analytical tools to reason about candidate solutions, and about computational speed and cost, on the way to solving complex problems.

Outcome 2. Students will apply quantitative tools in diverse settings to answer discipline-specific questions or to engage societal questions and debates.

This course applies the quantitative tools of algorithm analysis (considering speed and asymptotic complexity) to many problems: search, sorting, memory layout, graph and game-tree traversal, and concurrency. Late in the term, the lectures on querying data and on calling Rust from Python connect this material back to the rest of the data science pipeline. We also discuss the impact of computing costs on energy use.

Outcome 3. Students will formulate, and test an argument by marshaling and analyzing quantitative evidence.

Each project asks students to make and test hypotheses and argue for their design choices. They must use quantitative evidence from their computational experiments to defend their decisions.

Outcome 4. Students will communicate quantitative information symbolically, visually, numerically, or verbally.

Symbolically, we use Big-O notation, which is how we state a claim about scaling. Numerically and visually, we use benchmark tables and plots, in lecture and in project writeups. Verbally, students defend their work in code reviews, where they explain out loud how their program works and answer questions from the teaching staff about their work.

Outcome 5. Students will recognize and articulate the capacity and limitations of quantitative methods and the risks of using them improperly.

This course focuses on programs that don't just work, but scale and work effectively and efficiently. In projects and on exams, students are asked to make judgements between similar programs that have the same output but that have different limitations around complexity, speed, and memory use. Students must also think holistically about their design decisions, recognizing that some metrics (speed, test coverage, memory use, code simplicity) trade off against each other, and good design requires good judgement in addition to quantification.

Digital/Multimedia Expression (DME)

Outcome 1. Students will be able to craft and deliver responsible, considered, and well-structured arguments, statements, or expressions using appropriate digital media.

Student projects are complex repositories including source code, documentation (a README), a test suite, potentially other media such as images, and a commit history. Projects are evaluated not only by an autograder for correctness, but by a conversation with a teacher who can assess the arguments, style, and the repo as a whole.

Outcome 2. Students will be able to reflect on the ethical use of digital media, considering relevant issues such as accessibility, intellectual property rights, citational practices, and other discipline-specific concerns.

Citations are required for projects in this course. We talk throughout about what it means for code to be "yours", especially in the era of generative AI, and the importance of taking responsibility for your code even if it was derived from multiple sources. We also discuss intellectual property and license types when learning about external crates.

Outcome 3. Students will be able to demonstrate an understanding of the capabilities of one or more digital communication technologies in their assignments.

The technologies of everyday software work are central in this course: the command line, git and GitHub, compilers and interpreters, and automated testing tools. When learning git, students learn best practices about digital collaboration on code projects, and see the version control process as both facilitating communication and producing documentation artifacts for those who come later.

Outcome 4. Students will be able to demonstrate an understanding of the fundamentals of digital communication, such as principles governing design, time-based and interactive media, and the audio-visual representation of qualitative and quantitative data.

Code is a designed artifact with a human audience, and we emphasize that throughout: code is not just something a machine reads, and good code has care put into naming, structure, formatting, and documentation. We frequently consider similar programs side by side and discuss which one we prefer and why. In each project, students collect and present quantitative analysis of their code's performance in defense of their design decisions.

Creativity/Innovation (CRI)

Outcome 1. Students will demonstrate understanding of creativity as a learnable, iterative process of imagining new possibilities.

1A Students practice creative and innovative thinking as an iterative process, for example by revising their ideas or their methodologies in response to feedback from peers or instructors.

The course's projects each run over about four weeks and are built for iteration: the task is released, there are two checkpoints a week apart to ensure progress over time, there is a final deadline with evaluation that overlaps the checkpoints in content to capture iterative improvement, and the project concludes with a code review where students present and defend their ideas and receive further feedback. Indirectly, the course's policy on exam corrections allows for a layer of feedback and reflection after an exam is initially graded, letting students demonstrate growth based on exam feedback.

1B Students will provide a metacognitive reflection, in which they evaluate their choices in relation to risk-taking or experimentation and identify individual and institutional factors that promote and/or inhibit creativity.

Project code reviews are conversations about design choices, where students are asked what they tried, what failed, and what would happen if further changes were made to their code. Each project also requires a written reflection in its README: what the student tried first, why they changed it, and what they would do with more time. The same README must record where generative AI was used and how.

1C Students generate a product based on the above processes.

Each project in this course is such a product.

Outcome 2. Students will be able to exercise their own potential for engaging in creative activity by conceiving and executing original work either alone or as part of a team.

All three projects are individual, and all three leave room for original design. Each also requires students to use a new software tool (git) to combine their own work with changes made by others, which is how software is built in practice. Project 3 adds a competitive component: students enter the strategies they designed into an automated tournament. There is no single correct answer there, and the strategies that perform well are usually the ones with an out-of-the-box approach.