CSC 2001, Fall 2026
Welcome to 2001! The year when I got my masters, probably several years before you were born, and also the number of this course!
This is an exciting quarter, and that’s because this is the first time this course has ever been taught. Will it turn out to be a course about data structures? I sure hope so, that’s what it says in the course description.
However, it will also be a course about software development, about notional machines, about certain powers of two, and maybe about whatever you’re interested in. As the first people to ever experience the course, you have some power to shape what happens, and I look forward to hearing what you have to say.
I have a lot more to say (as you’ll see), I look forward to seeing you in class!
1 Learning Outcomes
Okay, let’s have some course outcomes. At the end of this course, you should be able to:
Use a design methodology to develop programs: structures/objects, functions and methods.
Analyze requirements for a particular problem to choose the best option from a set of standard data structures.
Design, implement, and debug new and modified data structures in a high-level language in order to represent the data elements of a given problem.
Map a program and a set of inputs to an evaluation sequence in order to demonstrate a working notional model of a high-level programming language that has function calls and lexical scope.
Identify the types for nested expressions induced by the types specified for bindings and function inputs and outputs.
Use structural recursion to traverse inductively specified data structures.
Identify an algorithm’s informal worst-case and average-case behavior by mapping it to an evaluation sequence in a notional model.
Design, implement, and debug programs that use functions as values in certain basic contexts.
Link variables to their bindings in an evaluation sequence for a program that uses higher-order functions in basic settings.
Use generative recursion to implement divide- and-conquer algorithms such as merge sort.
Use decomposition and abstraction strategies to break a planned program into pieces to create a high-level and extensible program.
Choose between mutable and immutable data structures based on their advantages and shortcomings in the context of a particular problem.
Choose between object-oriented and procedural program designs based on the advantages and shortcomings of each.
2 Prerequisites
Students taking this class must have completed CSC/CPE 1001 or the equivalent. They must also have open minds, and be willing to support others in their learning.
3 Names, Times, Locations
3.1 Instructor
John Clements, clements@calpoly.edu
Brian Jones, btjones@calpoly.edu
3.2 Lecture & Lab
Lecture: 8:00–8:50, MWF, room 21-238
Lab: 9:00–9:50, MWF, room 14-232a
Lecture: 9:00–9:50, MWF, room 186-C202
Lab: 10:00–10:50, MWF, room 14-301
Lecture: 13:00–13:50, MWF, room 180-113
Lab: 14:00–14:50, MWF, room 14-257
3.3 Office Hours
John Clements: https://brinckerhoff.org/index.html
Brian Jones: https://users.csc.calpoly.edu/~btjones/
4 Web Page
This is the course web page, its link is http://www.brinckerhoff.org/clements/2268-csc2001.
5 Lecture Classroom
I think that an interactive and lively classroom is a better learning environment. In particular, I will almost certainly learn everyone’s name, and I’m likely to notice if you’re missing. My experience is that if you come to class reliably, you’re extremely likely to pass the class—there’s a reason that we conduct classes face-to-face; it keeps you engaged, and ensures that you’re connected to the other students in the class.
In addition, I’m likely to call on you, in places during the lecture where I want to see if you’re following what’s going on. If you don’t know, it’s totally fine to say "no, I have no idea." In particular, this is probably evidence that I’m going too fast or not explaining things well. However, I try to respect the wishes of students for whom this technique is disruptive. Please let me know if you don’t want me to call on you.
Finally, my experience standing in front of classes and more especially my experience of sitting behind classes has convinced me that laptops are useful for note-taking in approximately 1% of cases. Essentially, never.
Indeed, there’s now a mountain of evidence indicating that laptops are distracting to students and to those around them, and that even when these distractions are eliminated, taking notes on laptops fails to create learning in effective ways. I’ll just cite this one paper, because it’s got copious references to other sources.
For this reason, I do not allow the use of laptops in class without special dispensation. If you need to use a laptop to take notes, please come and talk to me; otherwise, just put it away and take notes on paper.
6 Computing Environment
You will be required to complete the assignments in this class using Java 25. It is freely available for all major platforms, including Mac OS, Windows, and UNIX.
We encourage you to use IntelliJ IDEA from JetBrains, along with GitHub Desktop. It will probably be possible to complete the labs and assignments using other applications, but these are the ones we are planning to provide support for.
6.1 Handin Server
We will be encouraging you to do your work in this class in private repositories that you create in GitHub, but handin will be done using Gradescope.
7 Communication
This class will use EdStem. This will be the principal means that I’ll use to notify you of deadlines, organizational updates, and changes to assignments. If you’re not keeping up with the group, you’re going to be missing important information.
It’s also the best way for you to direct questions to me and/or the class. Feel free to e-mail me with personal questions, but use the EdStem group as your main means of communication. It’s possible to post anonymously, if you like.
You should already have received an invitation to the EdStem group; let me know if you need an invite.
Don’t post your code or test cases to the group; anything else is fair game.
Also, please keep in mind that I (and everyone else) judge you based in part on your written communication. Spelling, complete sentences, and evidence of forethought are important in all of your posts & e-mails. One easy rule of thumb: just read over what you’ve written before clicking post or send, and imagine others in the class reading it.
8 Honesty
We strongly encourage collaboration among students in almost every aspect of the course. See, for example, the following section on "Labs", which are designed for collaboration.
One exception is for quizzes and tests, which must be entirely your own work.
The other exception is for programming assignments: you may not copy another team’s code, not even test cases. You are also responsible that no other teams see your code, either during this course or afterwards, either deliberately or through negligence (e.g. via a non-private repo).
A very effective automated tool will review submissions for evidence of copying. Students believed to be cheating, i.e. both parties involved in a transfer of code, will in the first instance typically receive a 0 score for the assignment, and an additional unspecified penalty on the quizzes and tests that follow, often about 10%. We reserve the right to assign a failing grade in the class when appropriate.
Please note that the baseline score for assignments that you DON’T HAND IN AT ALL is typically about 15%. Plagiarism will result in sacrificing that 15% baseline. This means that copying code is likely to produce a score that is lower than doing nothing at all.
8.1 If it is late and you are desperate
Please submit what you have. You will get partial credit, even if the handin server says "handin failed". It is way better to submit something terrible that is your own work than to submit someone else’s code. It’s okay. Let’s talk about it. Keep in mind that I want you to succeed.
9 Generative AI
Generative AI engines such as Codex and Claude Code can currently generate excellent Java code. The goals of these LLMs (which are in fact the same as the goals of their parent companies) are in no way aligned with yours: they make money by making you dependent on their services, and by convincing you that you can’t survive without them.
But actually, you can.
The AI policy in this course is this: you may not use generative AI as any part of writing your assignments or projects, either to generate code, to debug code, to generate written english text, or to critique your written text. The point is that you need to be able to do these things yourself, without assistance; this is how you’re going to develop the understanding that you will need in order to use AI effectively when the time comes to use it.
Note that for certain development environments, this may require disabling certain AI auto-completion tools.
This does not mean that you have to disable all auto-completion tools; most IDE’s have "here are the words you might be trying to type"; that’s just fine. However, if the IDE is suggesting more than a single name, it’s probably using Generative AI.
Also, you will be expected to explain the choices you made in designing your code. If I ask you what a particular piece of code does, you need to be able to explain how you wrote that piece of code and what it does.
To bolster this: if the code you turn in for an assignment turns out to be hugely similar to another team’s code, you will get a zero for that assignment, even if the similarity is because both of you dumped the assignment text into a generative AI tool. Ugh, don’t do that.
10 Labs
Labs in this course take the form of simple exercises to be completed in a week during lab periods, designed to help you understand the lecture material and to lead you toward solutions for the larger assignments.
Some instructors will be checking these labs off during lab. Others will simply ask you to submit them to the handin server. Talk to your instructor to find out what’s happening in your class.
The labs will be due at the end of your lab period on the day specified, typically Friday.
In labs, you are heartily encouraged to collaborate like crazy. Look at everyone else’s code, copy and paste, type on your neighbor’s keyboard, whatever. Labs need not be entirely your own work.
11 Assignments
Programming assignments will be due at 11:00 PM.
12 Quizzes and Exams
There will be quizzes in this course, on paper, taken during lab.
There will be one midterm and a final exam in the course. The midterm will be during the lecture period during the eighth week of class.
The quizzes will be open-note (paper notes only, let me know if you need help printing them out). On exams, you will be allowed a single double-sided page or two single-sided pages of notes.
13 Grades
Grades will be determined by performance on programming projects, the exams, and class interaction. A small fraction of the grade is determined by the labs, and by the instructor’s whim. The breakdown of the grade is as follows:
Assignments : 27%
Quizzes : 14%
Midterm : 14%
Final : 30%
Labs : 10%
Other : 5%
14 Lab Grading
For each of the first two labs, I will be randomly assigning you to work with a lab partner. (Not the same one; I roll the dice twice.) After the second one, we may decide to go with lab partners for the rest of the course... or we may just give up. We’ll see.
When you successfully demonstrate a lab, I will give you a number. You may enter these numbers at https://handin-1.brinckerhoff.org/servlets/standalone.rkt .
15 Assignment Grading
We will be grading your code repeatedly in this class. On most assignments, your score will consist of a part (usually 20 points) based on your performance on a set of test cases automatically administered by the handin server, and a part (usually 6 points) based on my opinion of your code’s clarity, organization, and adherence to rules about purpose statements and contracts/types (in short: you’ve got to have them). As a rule, my "eyeball" score rubric runs something like this:
6 points – Your code displays unusual clarity or elegance, with no problems of consequence.
5 points – some inelegant parts, or one or two purpose statements or contracts/types missing
4 points – an actual misunderstanding, or a widespread lack of purpose statements and contracts/types
3 points – a serious misunderstanding–you didn’t understand some major part of the assignment, or I had to work to try to get your code to compile or run without looping
2 points – your program is seriously incomplete, doesn’t compile, or has widespread major problems
1 point – you didn’t make any apparent progress on the program at all.
Finally, please note that I will place comments in some of your submissions indicating errors or stylistic requests. These will all begin with the string ;;> (in Racket) or ##> (in Python), so you can search for these in the e-mail that you get with your final assignment grade.
15.1 Code Organization
Here’s the most important thing to know about code in this class:
I do actually read it. That means that—
This means that getting your code to work is not the end of the process; after you get your code to work, you have to clean it up, put nice headers on the various parts, collect the test cases, document strange things that you did, and clarify the code.
You should begin with a single-paragraph comment that describes how far you got: did you finish, or did you get stuck on something? If you got stuck, describe what’s done and what’s still left to implement.
As a rule, I like to read code in a "top-down" way. This means that the definition of the top-level, important functions should come first, and the supporting functions should come later. I want to have a good understanding of the big picture before getting into the details.
Another part of cleaning up the code is collecting the test cases in a place that’s sensible and doesn’t interrupt the flow of reading the code. It’s probably best–after you’re done writing the code–to collect the test cases at the bottom of the file (or put them in another file altogether, if appropriate).
Whatever language you use, it’s likely to have a style guide. Here’s the one for Python. Here’s the one for Racket. You’re not required to follow any style guide, but anything that makes your code hard to read could hurt your score.
Finally: dead code is misleading and makes code hard to read. Delete it.
15.2 "But it Works!"
I reserve the right to assign bad scores to programs that work correctly; if I don’t think you’re doing a good job of programming, then you won’t receive a good score. "It works" isn’t a defense for bad code.
15.3 Grading Time Limit
Good code is easy to read. I reserve the right to allocate a fixed period of time to grading a program submission. Don’t be surprised to see comments like "ran out of grading time here."
Naturally, all grades contain an element of subjectivity.
16 Quizzes
My experience suggests that frequent quizzes are a good way to ensure that you’re understanding what I’m teaching, and that I’m teaching things that you understand. You don’t like taking them, and I don’t like grading them, but they do actually seem to help quite a bit.
This class will have quizzes in most weeks of the course. These quizzes will generally be twenty minutes long, and will take place during lab.
17 Assignments
You’ll hand in your assignments using Gradescope.
From time to time, we may examine student code, in lecture. Try to ensure that the code you submit is something you’d be proud to show to the others in the class.
Late Policy: Except for exceptional circumstances, late assignments will be given 0 points.
18 Checking your Grade
I like to share your current grade in the class with you. It usually takes me a few weeks to get this set up, but you should eventually be able to check your student grade at
https://users.csc.calpoly.edu/~clements/student-grades/<your-login>/current-grade.txt
That’s not a clickable link, because you’ll have to edit it to add your login. So, for instance, if your name is Annette Czernikoff and your login is aczernik@calpoly.edu, you’d put aczernik in the login spot.