Table of Contents
- Course Info
- General Policies
- Graded Work
CS111 is an introduction to the problem solving foundations of computer science. In this course, you will learn big ideas about solving problems, developing algorithms, and organizing programs.
These ideas include:
- Abstraction: capturing common patterns, hiding information, making specifications (contracts);
- Modularity: expressing programs by combining smaller parts;
- Problem solving strategies: divide-conquer-glue, iteration, recursion;
- Models: ways in which programs are executed;
- Interdependence: computational technology should propel humanity.
You will get hands-on experience with these ideas by reading, modifying, debugging, designing, writing, and testing Python programs in the lab sections.
CS111 students in lecture sections 01, 02, and 03 must register for and attend one of the weekly 2-hour laboratory sections in the range L01 through L06.
- Lecture section 04 is for students with significant previous programming experience. Students in lecture section 04 will not attend a weekly lab section, and must register for lab section L07 (the registrar's placeholder for a nonexistent lab.) Students in this section will complete the same lab exercise notebook as all other CS111 students, but on their own time.
CS111 is required for students who wish to major or minor in computer science, data science, or elect more advanced courses in the field. Consult Choosing an Introductory CS Course for more information.
Prerequisite: None. No prior computer science background is expected.
Distribution: Mathematical Modeling. Does not satisfy laboratory requirement.
The aim of this course is to enable students to solve various problems by writing programs utilizing foundational computer science concepts listed above (namely, abstraction, modularity, strategies, and models). Students will use Python to explore these ideas, but will be learning and practicing techniques for solving problems that apply to any programming language and many disciplines.
Students who complete this course should be able to:
- Read, modify, debug, design, write, and test Python programs to solve computational problems
- Reason carefully about computational problems and design algorithmic solutions before writing code
- Work collaboratively with partners or small groups to solve computational problems
- Design and develop programs that use abstraction and modularity
- Develop a toolbox of problem-solving strategies (such as divide-conquer-and-glue, iteration, and recursion), identify appropriate strategies for a particular problem, and apply those strategies to solve the problem
- Use computational models (such as execution frames and memory diagrams) to reason about computational processes
- Translate computational problems, algorithms, and problem-solving strategies between English and Python
- Recognize how computational technology can be used both in beneficial and harmful ways
Responsibility for Course Material
This course has expectations for preparedness for each class meeting, which will in turn help students prepare for exams.
- Lectures: Before lecture, you should review the slides for that lecture (linked on the schedule). If your lecturer does not cover the entire lecture notebook and slides in class, we expect you to go over the remaining material on your own.
- Labs: Labs may have some preparation materials that will be announced beforehand that you are expected to go over. Typically this should not take more than 15-20 minutes per lab. Additionally, try to have a good understanding of all previous lectures before each lab.
- Exercises: In lectures and labs, we will work on graded exercises which are your responsibility. You may often need to work on these beyond class time. There are extra ungraded exercises which do not need to be completed, but serve as extra learning opportunities beyond the basics required for the class.
Accommodations and Disability
We strive to be inclusive and provide an equitable learning opportunity for all in this class, and we believe that accommodations for disability make the class more fair, not less. If you have a disability or condition, either long-term or temporary, and need reasonable academic adjustments in this course, please contact Disability Services to get a letter outlining your accommodation needs, and submit that letter to your instructor. If you are unsure but suspect you may have an undocumented need for accommodations, you are encouraged to contact Accessibility and Disability Resources. They can provide assistance including screening and referral for assessments. You should request accommodations as early as possible in the semester, or before the semester begins, since some situations can require significant time for review and accommodation design.
Accessibility and Disability Resources can be reached at email@example.com, at 781-283-2434, by scheduling an appointment online, or by visiting their offices on the 3rd floor of Clapp Library, rooms 316 and 315.
We will do a lot of work in pairs and groups in this class, including in lectures, in labs, and on projects. We have a pair programming guide that explains how pair work should happen and why we use it so much. However, collaboration should be explicitly permitted by your instructor:
- It is never acceptable to present someone else's work as if it were your own. It violates the basic principles of academic honesty. Unless explicitly instructed otherwise, assume all work you hand in is to be yours and yours alone.
- You cannot use any materials from students who have already taken this course, including notes, solutions to exercises, project tasks, quizzes, and exams. Submitting work that is based on a past semester's solution will be considered an honor code violation, especially if you represent that work as your own individual work.
- When working on a project, you may collaborate freely with other students in the class. You can work on brainstorming, problem solving, and writing code together. However, you cannot submit any code that another person wrote when you were not present.
- When you turn in a project, you must list all other students with whom you collaborated in your code. If you get significant help from any of the course staff, including the TAs, you should acknowledge that, too. Academic honesty requires it, and it helps us advocate for maintaining funding for things like TAs. If you are not sure what constitutes collaboration or significant help, err on the side of caution.
See the section project collaboration section for more details below for more details.
- When working on exercises, you are allowed to freely collaborate
with any other students in the class, including looking at each
others' code and writing code together. When sharing code, it is your responsibility to ensure that:
- You understand and can explain the operation of all code you submit.
- If you are sharing your code with another student, they understand it fully and could explain it themselves. This means you cannot simply send someone your solution to an exercise for them to copy. We encourage students to collaborate in-person (or on Zoom) and not to submit code that was written without them being present.
- When working on quizzes or exams, you may not communicate with other students in any way.
- You may consult public literature (books or articles) for hints, techniques, and even solutions. However, you must reference any sources that contribute to your solution.
- When you use a public computer, save your work, remove the local copy when you are done, and log out. If you find someone else has forgotten to log out, log them out without looking at any files or work in open windows.
- We will interpret a violation of any of the collaboration policies stated above as a violation of the Honor Code, and will bring any such violation to the attention of the Honor Code Council. Sadly, we encounter such violations almost every semester. For your sake and ours, please don't be tempted to cheat. Instead, accept a bad grade, and ask your instructor about opportunities to revise or make up the assignment.
Collaborating on Projects
All project tasks may be worked on individually, but are designed to be tackled by two people (although you can work with more than one person).
We have some guidelines for collaborative project work:
Each student will create solution files for a task. You should write the names of everyone you collaborated with in the "Consulted:" row of your top-of-file information, including other classmates, tutors, and instructors.
Each student will submit their own electronic copy of the solution files. Each student will be given the grade for the file they submit. If you submit a different file than someone you collaborated with, you may receive different grades; it is your responsibility to communicate with your collaborators and make sure you each have a copy of the most up-to-date code to submit.
Although you can work with the same people on multiple tasks throughout the semester, we strongly encourage you to seek different peers for different tasks so that you get a better sense for the range of collaboration styles, and so you do not become too dependent on a particular person.
- All project work must be a true collaboration in which members actively work together on all parts of the task. It is not acceptable for team members/partners to split up the task and work on parts independently. Programming should be done with both partners/collaborators working at the same computer or remotely via a shared screen. Team members must share the responsibility of "driving" (typing at the keyboard), swapping every so often. The only work that you may do alone is debugging code that you have written together and talking with the instructors and drop-in tutors (it is your responsibility to explain what you learned to your team and make sure they understand it).
Note that with COVID, there may be times when two or more people working at the same physical computer is not optimal. In these cases, we suggest the following alternative collaboration methods:
- Remote pair/group programming (recommended). Using Zoom, it is possible for one member of a meeting to take control of the other's computer (the option to request remote control appears when someone is sharing their screen). You can therefore program together on one computer remotely. Remote control offers the advantage of easily supporting the driver/navigator model that is essential to pair programming because both partners can edit the code directly. One student should open up a window with the particular task and then allow access to remote students to control that window.
- You can use screen sharing and discuss each task if you are uncomfortable with the remote control model. However, make sure that each collaborator has an opportunity to write code. This will likely require copy/pasting code back and forth or sharing/emailing python files, which is why we recommend the remote control model. Note that you cannot copy/paste code through Zoom chat, because copying from Zoom chat introduces invisible characters that will break the code.
- Independent work + verification. To ensure that each member of a team actually understands the full solution to a problem, you may work independently on a problem. When you each have an attempt (they need not be working perfectly), you can come together to compare your code and discuss the differences between your attempts. This method is more work than pair programming, but still offers some advantages over individual work, like the ability to discuss your solution in depth at the code level with another student and the opportunity to do debugging together.
Getting Help: Office Hours, Tutors, and Sakai
You can see our whole team on the Instructors page, and see when we are available for help on the Drop-in Schedule page. We also have a super talented crew of tutors who hold afternoon and evening drop-in hours (sometimes we refer to this as "help room").
Tutors and instructor office hours for this course are available to help polish your debugging skills and spot tricky situations when you're stuck on an assignment. To ensure efficiency, our policy for interacting with tutors and with instructors during office hours is:
- Tutors/instructors will not simply give you answers. They will help you reason through problems, so you can develop and apply your programming and debugging skills.
- You can expect a tutor to help you for 5 minutes at a time. You can expect an instructor to help you for ~15 minutes (might vary depending on the instructor). Because of the size of the class, tutoring and office hours will also get very busy, especially as the deadline for each project approaches. Be ready to explain your problem as clearly as you can, including which part of your code is not working as you'd like, and where you have used print statements to investigate the problem further. In many cases, the tutor will be able to help by supplying a critical hint. Work with this hint, and if you get stuck again, feel free to request more help. If a tutor gives you advice that you don't understand, let them know.
- When asking questions, try to make sure you have clearly identified a problem and can explain what you're asking about. "My code doesn't work," is not a question, but "I tried to do X and got Y as the result, when I expected Z, can you help me figure out why?" is a great question.
- Attend drop-in hours ahead of deadlines. They tend to be less crowded, and tutors will be able to devote more time to your concerns. This is also a great time to ask tutors about general class concepts.
You can also post a public or private question using Sakai.
- Submit your questions in Sakai rather than privately e-mailing the instructors: this is more productive because your classmates probably have the same question too!
- If your public question contains part of your solution code, we may remove it. Do not include code in public questions submitted via Sakai. (You can include code in private questions, but should try to ask questions without including code if you can).
Most importantly, you are encouraged to talk to your classmates about exercises and projects. Sometimes bouncing ideas off the person next to you can be helpful and illuminating!
Policy on AI-Powered tools
AI-powered tools are evolving very rapidly. Therefore, our policy is evolving too. Our current policy can be found in this dedicated page.
Faculty Responsibilities on Disclosures of Discrimination, Harassment, and Sexual Misconduct
Pursuant to Wellesley College policy, all employees, including faculty, are considered responsible employees. That means that any disclosure of discrimination, harassment, or sexual misconduct to a faculty member will need to be shared with the College's Director of Non-Discrimination Initiatives / Title IX and ADA / Section 504 Coordinator (see the Wellesley Title IX page for more info). Students who do not wish to have these issues disclosed to the College should speak with confidential resources who are the only offices at the College that do not have this same reporting obligation. On campus, confidential resources include Health Services (781-283-2810 available 24/7), the Stone Center Counseling Services (781-283-2839 available 24/7) and the Office of Religious and Spiritual Life (781-283-2685). You should assume that any person employed on campus outside of these three confidential offices has an obligation to share information with Wellesley College through the Office of Non-Discrimination Initiatives.
In CS111, we believe in both “growth mindset” and “mastery grading.” Growth mindset focuses on the incremental progress we all make as we learn new material and work hard. You are not "good at" or "bad at" computer science, nor do you have a fixed "potential" as a computer scientist. You are "getting better at" computer science, and your improvement depends on how you spend your time.
Mastery grading articulates clear learning goals and evaluates based on the ability to master those goals. In CS111, we want to give students every opportunity to master the learning goals we set out for the course. Exercises, projects, and quizzes will offer multiple opportunities to complete learning goals through revisions and retakes. We want students to continue to improve their knowledge of the material and to look at assignments as less of a judgement of their intellectual capacity, and more as an opportunity to show the skills they have mastered.
For more information on these philosophies, please look at an article on mastery grading by Prof. Oscar Fernandez from Wellesley's math department.
During a typical CS111 week, you will complete exercises, quizzes, and one or more project tasks:
Some graded exercises are completed in lectures and labs, but you will usually have to finish these outside of class time.
- There may be some additional graded exercises to work on beyond those started in lecture or lab.
- Graded exercises from a lecture should generally be completed before the next lecture, even if that's earlier than their due date.
- Additional graded exercises must be completed by the weekly exercise deadline (normally 11 p.m. ET on Mondays), although you will usually want to do these before working on project tasks, because they will help prepare you for the project.
The quiz for each week will be taken at the start of lab. If you are in Professor Turbak's labless lecture, you will take the quiz during one of the evening quiz sessions. All quiz retakes occur in the evening quiz session. Each quiz or retake takes 15 minutes, with a hard stop. If you have a perfect score on a quiz, you do not need to do the retake. Otherwise, you are expected to take the retake quiz the following week to ensure that you understand the problems you got wrong on the original quiz. The retakes will have different questions that cover the same material as the original quiz.
- The weekly project will normally be due at 11 p.m. ET on Tuesday, practicing concepts covered the previous week. Projects are variable: some weeks you may select a task to complete from a set of options, other weeks you may complete multiple sub-tasks.
- You will be able to take an automatic 24-hour extension on the initial project deadline if needed.
- You will also be able to submit revisions after the initial deadline, usually up to 3 days later (normally Friday at 11pm); check the schedule for exact deadlines.
Holidays or other factors may create some deviations from this schedule, check the course schedule page for detailed deadlines.
For any and all deadlines, if you have extenuating circumstances, contact your instructor to request an extension. We accept late make-up work (for partial credit) for exercises and project tasks, but not quizzes without an explicit arrangement.
Exercises are small graded coding challenges that you will work on both in and outside of class. Both lectures and labs will typically have exercises associated with them, and there will be some extra exercises each week to be completed on your own. Exercises differ from ungraded coding examples that will sometimes be used in lecture to explain Python coding. Exercises and examples will appear in different notebooks to help you understand the distinction between them.
Use the schedule to access the exercise pages and links to the code files that contain the exercises.
Each exercise will come with testing code, and when you run the testing code, it will also submit the results to Potluck. You can resubmit as many times as you like until you get it right. Only your best submission will count for your grade. If you are working offline, you can see any error messages produced by your code but cannot submit.
During this process, you will be asked to list the names of people you collaborated with (we will typically work in groups of 2-3 in both lectures and labs, but you may consult other students before submission). Make sure to enter everyone's username correctly so that everyone gets credit. Please also remember to share your code with any partners you work with so that they can revisit it later (e.g., if they need to resubmit). If you are partway through your exercises and need to add more collaborators, restart your kernel in your notebook and re-enter authorship. Collaboration is encouraged, so please be transparent and include everyone you consulted.
On the Potluck server near the top of the dashboard, an overview of submitted exercises will be shown; you can click to expand the individual exercise groups and see details of which ones you've completed or not. Your code must pass the associated tests to count as complete, although you will get partial credit if it passes some of them.
Your average score across all weekly exercises (in terms of % completed) is one portion of your grade (see the grade calculation section).
There are weekly projects in CS111. Projects will typically be due on Tuesday at 11pm of each week and will be released the week before the deadline. You may freely collaborate with other students on projects (see the project collaboration section for more details).
Some projects will present multiple options from which you can choose a single activity/task to be graded on, while other projects will have a set of mandatory graded activities. If you plan on being a CS major or minor and want to deepen your understanding of the material, you are encouraged to complete more than one activity task each week.
Project task scores will be available via the Potluck submission server shortly after you submit. You can re-submit as many times as you like until you are happy with your score. We will check whether your code works correctly, is properly documented, and is submitted to the server on time.
Each task within a project will come with a detailed rubric explaining how it will be graded. The rubric has core goals and extra goals. The core goals are the concepts and tasks that we feel are most pivotal to your understanding of the project material. Extra goals are concepts that provide additional learning and challenges beyond the basic material; the extra goals are not worth any points.
You can receive one of four scores on each task of each project task:
- 100 ("complete" or "excellent") indicates successful completion of all core goals
- 85 ("almost complete") indicates successful completion of nearly all core goals
- 70 ("partially complete") indicates successful completion of at least half the core goals, but not all of them
- 0 ("incomplete") indicates successful completion of less than half the core goals
On top of the 100 coding points for a project task, there are 10 additional timeliness points for timely submission. Therefore, project task scores are based on a total of 110 points.
If you have a submission that earns at least partially complete before the initial deadline (possibly after taking the 24-hour extension) you earn 5 timeliness points.
- If you have any submission that earns at least almost complete points, including during the revision period, you earn the other 5.
Someone who misses the initial deadline and never goes above partially complete would earn 70/110 points (63.6%) for that task;
Someone who submits a partially complete task on-time (including with a 24-hours extension), but never revises it, earns (70+5)/110 = 75/100 points (68.18%) on that task.
Someone who has no on-time initial submission (or has one but it doesn't reach partially complete) but eventually revises up to almost complete, will earn (85+5)/110 = 90/110 points (81.8%).
Someone with a partially complete or almost complete initial submission who revises up to almost complete earns (85+10/110 = 95/110 points (86.36%).
- Someone with a partially complete or almost complete initial submission who revises up to complete earns (100+10/110 = 110/110 points (100%).
Note that you may submit a "revision" even if you didn't submit anything by the initial deadline (all you'll lose is 5 timeliness points). We strongly suggest that you take the time to submit a revision if you score 75/100 or lower on a task, in order to make sure that you understand the concepts from that task going forward.
If you know you will miss the initial deadline, you can take a 24-hour extension by requesting an extension (through the submission page) before the deadline. See the extension policy.
Submission of projects in CS111 is entirely electronic.
Use Potluck for all actions involving projects: submitting initial and revised tasks, declaring a 24-hour initial submission extension, reviewing feedback on your submissions, and reviewing task solutions.
- For the initial submission of a task, use Potluck to navigate to the task entry. Use the Browse button to navigate to your solution.py file on your computer, and click Submit task. You can submit a particular task as many times as you want before the initial deadline. Any new submission will supersede the previous one.
- To take a 24-hour extension for the initial submission, navigate to the project entry in Potluck, and click on the link that says "Take an extension" on the left-hand side underneath the due date. If you took an extension that you no longer need, simply submit your project by the original deadline.
- Submission feedback will be available shortly after you submit. To view this feedback, use Potluck to navigate to the task, and click View initial feedback.
- Once the initial project deadline has passed, there is a revision period (typically 5 days; check the schedule for details) during which you can submit revised versions of any tasks for that project. You can earn full credit for a revised submission, but if your initial submission was incomplete, you will forfeit some timeliness points. You can see revision feedback via the view revision feedback link for each task.
CS111 quizzes use a mastery grading approach that is designed to assess and enhance your learning.
A study guide with solutions will be provided roughly once a week on topics covered that week in class. We strongly encourage you to review the study guide and solutions when preparing for the weekly quiz, and to have a filled-out copy of the study guide on hand as part of your notes when taking each quiz.
There are two versions of every quiz:
The regular quiz (graded): This 15-minute quiz (strict time enforcement) is taken on paper during the lab and will generally test the material from the previous week's lectures + lab. You should also be nearing completion of that week's project by the time you take the quiz. If you do not have a lab section, you will take the quiz during an evening quiz session.
- The retake quiz (graded): This is a second version of the 15-minute quiz, with the same learning goals, that can replace your score from the original quiz. It is optional but we expect you to take it if you did not score well on the regular quiz. The regular quiz may highlight areas where your understanding could still be improved (see details below on Retaking Quizzes).
- Quiz grades and retake quiz grades will be released through Gradescope (you will get an email notifying you when you have graded work to view).
- You can view solutions to individual problems when reviewing your graded quiz in Gradescope.
The regular and retake versions of a quiz are graded by the instructors. Graded quizzes and retakes (and corresponding solutions) are only viewable in Gradescope.
Honor Code Policy
Quizzes are open-notes, but you may not consult other students or look things up on the internet during a quiz or retake, nor may you consult other students who have already taken the quiz. Using Thonny or a Jupyter notebook or anything that runs Python code is explicitly forbidden during quizzes and retakes. Doing so is considered an honor code violation.
You should not talk with other students about a quiz even after you have taken it and/or the deadline has passed, because they may not have taken it due to special circumstances. The instructors are happy to answer any questions you might have about quiz scores or other details.
Exercises and projects are collaborative, but please give attribution to your collaborators and the people you consult with (as described above).
Each quiz will assess a series of learning goals to test students’ comprehension. Each question is designed to target one or more learning goals. Each quiz question will be labeled with the learning goal tested. Upon receiving feedback, we strongly suggest that students examine their performance on each learning goal so they have a complete understanding of what they know and what they need to improve on.
As indicated above, a week after taking a regular version of a quiz, students have the option to take a retake version of the quiz if they want to improve their understanding and/or score on the quiz.
In the retake quiz, students do not need to complete the entire quiz; they only need to complete the questions with the learning goals that they would like to improve. There is no grade penalty or grade limit for retake quizzes.
For each Quiz question (learning goal),your final score on that question will be the maximum of the two scores across the two graded versions (regular and retake) of the quiz.
For example, suppose that on a regular version of a quiz, Wyeth scores 3 out of 8 points on Question 1, 11 out of 12 points on Question 2, and 8 out of 10 points on Question 3. On the quiz retake, Wyeth submits only Question 1 (earning 6 points) and Question 3 (earning 7 points), but does not submit Question 2 (earning 0 points). The following table shows the result of the maximization procedure for this quiz. Wyeth's final quiz score is 6 out of 8 points on Question 1, 11 out of 12 points on Question 2, and 8 out of 10 points on Question 3, for a total of 25 out of 30 points on the quiz.
|Quiz Version||Question 1 Score (max 8 points)||Question 2 Score (max 12 points)||Question 3 Score (max 10 points)||Total (max 30 points)|
|Final Quiz Score||6||11||8||25|
Note that the unit of maximization for a quiz is an entire question. If a question has subparts, you must submit all the subparts of that question on a retake if you want to improve your score on that question.
Exams are graded collectively by the CS111 instructors, and we do our best to be both consistent and fair. If you think we made a mistake grading your exam, submit a regrade request in Gradescope.
You should not communicate with any other person about the contents of any CS111 exam before, during, or after taking it except CS111 instructors (again, your classmates may have extenuating circumstances that warrant taking the exam later than usual). Any violation of this policy will be brought before the Honor Code Council.
In-Class Midterm Exams
There will be two in-class midterm exams during lectures (see the Schedule for the exam date).
These are both pencil-and-paper exams; you are not allowed to use any computers or other electronic devices (including phones, tablets or laptops). This is an open-notes exam: you may bring with you any of your own notes, as well as hardcopies of any course materials from the semester. All your notes must be on paper; we do not permit electronic notes at all. Note that your time to consult your notes during the exam will be limited, so we encourage you to write a one- or two-page paper summary of key notes you may want to consult as part of studying for the exam.
There will be a 2.5-hour fixed final exam that will be on a specific day and time during the final exam period (the day and time will be on the Registrar's website on September 27, 2023). Do not make any travel plans until you know when all of your final exams will occur. The CS111 final exam must be taken in-person on the to-be-determined fixed date.
This is a pencil-and-paper exam; you are not allowed to use any computers or other electronic devices (including phones, tablets or laptops).
This is an open-notes exam: you may bring any of your own notes and hardcopies of any course materials from the semester. All of your notes must be on paper; we do not permit electronic notes at all. We encourage you to write a one- or two-page paper summary of key notes you may want to consult as part of studying for the exam.
We recognize that this academic year is likely to be influenced by the ongoing COVID pandemic. We strongly encourage you to speak with any of the faculty for CS111 for any reason --- whether COVID-related or not --- that might inhibit you from successfully completing your coursework. We are empathetic to the many hardships that students will face as we learn together during this crisis. Do not hesitate to reach out!
Extension Policy for Exercises
If you need extra time to complete exercises, contact an instructor. You should be making some progress on the weekly exercises in lectures and labs each week and then finishing up any leftover exercises as homework.
Extension Policy for Projects
The initial submission for a project is typically due at 11pm Tuesday with revisions typically due 3 days later (check the schedule. If you submit an attempt that receives at least "partially complete" before the initial deadline, you will receive 5 of the 10 timeliness points, and if you submit an attempt that receives at least "almost complete" any time before the end of the revision period, you will receive the other 5 timeliness points. During both periods, you may submit as many times as you like, with each submission replacing the previous one.
In any (or even every) week, you can declare an automatic 24-hour extension for the initial due date. In order to receive the extension, you must declare it via the Potluck submission server before the 11pm deadline. If you feel that you need more than an extra 24 hours, please contact one of the CS111 faculty members directly.
Taking the automatic extension for the initial deadline does not affect the revision deadline.