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.

Syllabus

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

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.

Readings

We'll assign readings from three main sources this semester (all free). Stay on top of them!

In-Person Help

There are a few ways to get in-person help:

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).

Online Communication

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 compsci220-1-s20@lists.wisc.edu 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 ms@cs.wisc.edu or mdoescher@wisc.edu. 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. 

Lab

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

Grading is based on the following:

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:

Exams

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.

Accommodations

Please Notify Meena Syamkumar or Michael Doescher within the first two weeks of classes if:

Tentative Exam Times:

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.

Projects

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:

  1. 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).
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Cheating

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:

Acceptable

NOT Acceptable

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.

Learning Objectives

By the end of the course, students should be able to:

Recommendation Letters

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 .