Note: this site is still up to serve as a reference for people who took the course in Spring of '20. If you're currently enrolled, please head to the site for the current semester.
Welcome to your first programming course! CS 220 (Data Programming I) is a gentle introduction to coding for students outside of computer science. Our goal is simple: to write Python code to answer questions about real datasets. CS 220 will require you to practice coding a lot this semester (you'll complete 10 programming projects)! It's a lot of work, but if you take this course seriously and invest the time, you'll walk away with an incredible new skill: the ability to make computers work on your behalf.
Additions To Syllabus Made During Semester
New Resubmission Rules (March 23rd 2020)
Resubmits: applies indefinitely for P2 through P9 until April 29th
- You can resubmit a given project for a regrade just once! This is to ensure that TAs don't get overwhelmed trying to support you. So please be considerate of this.
- Contact the TA who graded your assignment for resubmits during their office hours or via email
- Go to Projects -> Select your project -> View Submissions -> Reviewer Contact Email.
- You'll need to walk us through the changes you made and describe how they address previous feedback (if any)
- Work with your grader TA to get a resubmission graded and an extension recorded (so it doesn't count as late)
- You generally won't receive feedback comments on resubmits
- No resubmissions allowed for P10!
- It will take at least a week for Canvas to get updated with the new score, please be patient. If you don't see an update after 10 days, please contact Mike / me.
After a resubmission, please wait a week for us to sync before Canvas before you check again. We don't take off points for resubmissions.
We'll assign readings from three main sources this semester (all free). Stay on top of them!
- Think Python 2nd Edition by Allen B. Downey: Read Online
- Automate the Boring Stuff with Python by Al Sweigart: Read Online
- Course Notes (we'll sometimes write these ourselves)
There are a few ways to get in-person help:
- Ask a TA or mentor for help during your lab session
- Drop in to see us or one of the TAs during our office hours. Check our weekly schedule before visiting because times/location might change from week to week (though we'll try to keep it regular)
- Email us at firstname.lastname@example.org or email@example.com to schedule an appointment outside of office hour time
- Visit peer mentors at the Shelf; these are undergrads who recently took (and did well in!) in CS301
The peer mentors will hangout out here (in the CS building, above the doors leading out towards Union South, to the left):
The Shelf will staffed with CS 220 mentors Sunday (2-8pm), Monday (3-9pm), Tuesday (5-9pm), and Wednesday (3-9pm). Please don't ask non-220 mentors at the Shelf for help because they're only hired to help with other courses (many don't know Python).
There are five ways we'll facilitate communication between everybody (i.e., instructors, TAs, and students) this semester:
1. Piazza: You can ask questions (and see the other questions) here. Do not post code snippets that are >5 lines long, this is considered cheating.
2. Email: You'll received announcement emails on either the firstname.lastname@example.org course list or from Canvas. You may also receive email from no-reply@http://msyamkumar.com/.
If you have a question that's not appropriate for Piazza (e.g., something personal, or a question that involves attaching your code), send an email to your TA; you can lookup their email here. If they don't respond within 48 hours, feel free to CC us at email@example.com or firstname.lastname@example.org. We get lots of emails in a class this size, so we prioritize responding to students who I see tried to get an answer from a TA first. Of course, it's OK for you to contact us directly first if that's more appropriate for your particular question.
3. Class Forms: We have various forms for you to tell us things. The most important forms are (1) a background form, so we can know a bit more about who is taking the course, (2) an anonymous feedback form, where you can bring our attention to any issues with the course, and (3) forms to report exam conflicts.
4. Code Review: You will upload projects using this tool. Via the same tool, TAs will leave comments on your code. Even projects scoring 100% often have a lot of room for improvement, so please take these seriously. When submitting, you can ask for specific kinds of feedback, based on what coding skills you're most interested in developing.
5. Canvas: We'll periodically upload grades to Canvas.
Each week, we'll post a lab document with exercises you can work on to solidify what we've covered in class. Sometimes we'll also introduce topics we didn't have time for in lecture. The emphasis will usually be on preparing for the project, so make sure you work through the weekly lab before asking us for help on the project.
Lab exercises are ungraded, and you're free to do them from home. However, we encourage you to do them during your scheduled lab time. This gives you an opportunity meet other CS 220 students and to get help from the TAs and mentors running the lab. You can also use this time to ask questions about the projects or other course material if you like.
We encourage you to work on your own laptops, but the labs have some Windows desktops you can use if you prefer. In order to sign onto the lab machines, you'll need to activate your CS account.
Grading is based on the following:
- Participation: 1%
- P1 (Project 1): 1%
- P2: 4%
- P3: 4%
- P4: 4%
- P5: 4%
- P6: 4%
- P7: 4%
- P8: 8%
- P9: 8%
- P10: 8%
- Exam 1: 15%
- Exam 2: 15%
- Final Exam: 20%
Participation is based on your online engagement (e.g., filling out the "Who are You?" survey). We'll give more details throughout the semester. Projects primarily focus on your ability to write code, while exams focus more on your ability to read code.
At the end of the semester, we'll look at the distribution of scores and set a curve, with thresholds for each letter grade. When setting the curve, we'll guarantee the following:
- at least 95% guarantees an A
- at least 85% guarantees a B (or better)
- at least 70% guarantees a C (or better)
- at least 60% guarantees a D (or better)
Exams are closed-book and closed-laptop. The exams will be multiple-choice scantron (use a #2 pencil). They are cumulative.
You will be allowed one 8.5-by-11 inch note sheet (may be printed or written on both sides), which you must turn in with your exam.
Please Notify Meena Syamkumar or Michael Doescher within the first two weeks of classes if:
- You participate in religious observances that may conflict with course requirements.
- You have a VISA from the McBurney Disability Resource Center.
- Please let me know if you have any trouble accessing or using the technologies being used in this course (such as the lab computers, Piazza, and the course website).
- If you need special accommodations for exams (or other components of the course), please let us know. We'll do our best to accommodate you.
Tentative Exam Times:
- Exam 1: Friday,February 21 from 7:15-9:15pm
- Exam 2: Wednesday, April 1 from 7:15-9:15pm
- Final: Sunday, May 3, 2020 from 12:25PM - 2:25PM@ 7:25-9:25pm
Find your location here (don't assume students in the same section will be in the same room). Report any exam conflicts at least 10 days in advance here.
Late Policy: You will have 7 late days, which you can use across projects at your own discretion. You may use all your late days on the same project, if you like. Using late days on a project does not defer the deadline for subsequent projects, so be careful not to let work pile up. You may not use late days on the last project. Late days are automatically applied if a project is turned in late (you may reclaim late days by withdrawing earlier projects). After late days are exhausted, anything late will receive zero credit by default. Please talk to me if you're falling this far behind.
Partners: You may work alone, or with one project partner of your choosing. You can partner with different people for different projects if you like. You may also partner with people in a different section of CS 220 . You and your partner should program in pairs (two people sitting in front of a screen at the same time). Take turns driving (i.e., writing code) and giving advice. The point of partners is to learn from your peers, not to do half the work. Some exam questions will be specifically written to find cases where a one partner does the work and the other partner does not understand what is going on.
Submission: You will upload either a .py file or a .ipynb (as specified) file for each project with the submission tool. Only one partner should upload the project on behalf of both people. If you have any issues using the tool, make sure you're using the latest version of Chrome, because that is the only browser I support (and if that doesn't work, I'll help you troubleshoot).
Code Review: A TA will give you detailed comments on specific parts of your assignment. This feedback process is called a "code review", and is a common requirement in industry before a programmer is allowed to add her code changes to the main codebase. Read your code reviews carefully; even if you receive 100% on your work, we'll often give you tips to save effort in the future.
Project Grading: Grades will be based on automatic tests that we run. We'll share the tests with you before the due date, so you should rarely be surprised by your grade. Here are the cases where you might get a different final grade than what you see when you run the tests:
- Configuration Issues: There are ways to write code that will only work on certain computers (e.g., Windows but not on a Mac). We'll talk about these cases in class and teach you to write code that should be able to run anywhere. If you make a mistake that makes the tests fail for us even though you passed them yourself, we'll let you resubmit a corrected version (in a timely fashion).
- Randomness: There are some bugs in code that don't causes problems every time, resulting in tests sometimes failing and sometimes passing. As in the "Configuration Issues" case, we'll work with you to let you fix the issue.
- Cheating: Obviously if you cheated (e.g., copied another student's code), the tests are irrelevant, and you have much bigger things to worry about than your grade on a particular assignment.
- Faking: Sometimes, we will specify that you solve a problem in a specific way (so that you learn a particular skill). If, upon inspection of your code, we see you solved the problem in a way that doesn't meet the project specification, you'll lose points on that project (even if our automatic tests already tentatively gave you a better score). Or, if your code is written specifically to defeat the tests, you'll lose points (see this wikipedia article for an example of a defeat device in the real world). For example, suppose your program is supposed to take the length of a square's side as input and then output the area of a square, and we have a test that verifies your program outputs 100 when we input 10. If you submit a program that always outputs 100 (regardless of the input) because you know we only test with 10, you'll lose points.
- Being a bad partner: if your partner complains that you didn't do any work (or that you did all the work, refusing to let your partner write any code), you may lose points (we'll meet with you first to hear your side, of course).
Project grading is results-oriented. That means it doesn't matter how much effort you put it; it only matters how well your code works. This means it is essential that your code runs. If we can't run your code for a project, you'll get a zero on that project, because the tests will fail. We'll never fix the code for you, and we'll never manually give a better grade for code that "looks" almost correct.
You shouldn't cheat, but what is cheating? This may not be obvious to people taking a CS course for the first time, so everybody should read this. The most common form of academic misconduct in these classes involves copying code for programming projects. Here's an overview of what you can and cannot do:
- any collaboration with your project partner
- talking about code (without looking at it or reading it aloud) with anybody
- sharing pseudocode/diagrams with anybody
- pointing friends to online resources (Piazza, Stackoverflow, etc.)
- doing worksheets with friends
- copying code examples from online examples that is NOT specific to your project (if project solutions are leaked online, you may not use that). If you copy code, you must cite it in your code with a comment (think of it like citing a quote in a essay -- without the cite, you're plagiarizing).
- looking at somebody else's project code and typing it line-by-line
- copying/pasting code to/from a non-partner (with or without citation)
- emailing your code to another student
- taking pictures of project solutions
One action that students wonder about is whether it's acceptable to LOOK at another student's code. While this is not strictly forbidden, it's often dangerous. Many students find it difficult to look without ultimately copying. It is somewhat safer for a student who has completed a problem looks at the code of a student still working on the problem. In this case, the student who has finished can often provide useful advice and debugging tips that help the other student without risking the danger that the student will copy code. Just make sure the you're not telling the student exactly what to type, line by line.
Similarity Detection: of course, with 450+ students, it's hard for a human TA to notice similar code across two submissions. Thus, we use automated tools to looks for similarities across submissions. Such similarity detection is an active area of computer science research, and the result is tools that detect code copying even when students methodically rename all variables and shuffle the order of their code. We take cheating detection seriously to make the course fair to students who put in the honest effort.
Citing Code: you can copy small snippets of code from stackoverflow (and other online references) if you cite them. For example, suppose I need to write some code that gets the median number from a list of numbers. I might search for "how to get the median of a list in python" and find a solution at https://stackoverflow.com/questions/24101524/finding-median-of-list-in-python.
I could (legitimately) post code from that page in my code, as long as it has a comment as follows:
# copied from https://stackoverflow.com/questions/24101524/finding-median-of-list-in-python def median(lst): sortedLst = sorted(lst) lstLen = len(lst) index = (lstLen - 1) // 2 if (lstLen % 2): return sortedLst[index] else: return (sortedLst[index] + sortedLst[index + 1])/2.0
In contrast, copying from a nearly complete project (that accomplishes what you're trying to do for your project) is not OK. When in doubt, ask us! The best way to stay out of trouble is to be completely transparent about what you're doing.
By the end of the course, students should be able to:
- Communicate using computer science terminology. Using the language of programming to talk about concepts helps ease the exchange of ideas between programmers.
- Build large projects in small steps. Creating milestones and breaking large programs down into smaller functions makes complicated projects more achievable.
- Process data from existing files without manual entry. Dealing with large datasets is much more efficient and less error-prone when the process can be automated.
- Write Python code. We will implement all of the concepts and ideas from the course using Python 3.
- Manipulate quantitative information to create models, and/or devise solutions to problems using multi-step arguments, based on and supported by quantitative information.
- Evaluate models and arguments using quantitative information.
- Express and interpret in context models, solutions and/or arguments using verbal, numerical, graphical algorithmic, computational or symbolic techniques.
Sometimes students who have done well in CS 220 later ask us for recommendation letters, for grad school etc. Unfortunately, getting an A in class isn't enough for me to write a great letter. Such did-well-in-class letters (often dismissively called DWIC letters) are typically ignored by those reading them, in part because they're redundant with your transcript.
If you're thinking about asking us to write a letter, you should do an interesting coding project outside of CS 220 and demo it to us sometime so We'll have something to write about. If your scores in CS 220 are really phenomenal (e.g., you are in the top 1-2% of students), I might agree to write you a letter even if I haven't seen any other work you've done, but it still won't be as good as if you show me something cool you've done in Python beyond 220 .