Note: this site is still up to serve as a reference for people who took the course in Fall of '21. If you're currently enrolled, please head to the site for the current semester.

Syllabus

Course Description

Welcome to your first programming course! CS 220 / CS 319 (Data Science 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 / CS 319 will require you to practice coding a lot this semester. CS 220 students will complete 13 programming projects. CS 319 students will complete 9 programming projects and work on a self-chosen graduate level project. 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.

CS319 meets with CS220. Common aspects between CS319 and CS220: lectures, quizzes, exams, and first 9 programming projects.

Additions To Syllabus Made During Semester

Course Credits

Requisites

Satisfied Quantitative Reasoning (QR) A requirement or declared in the Professional Capstone Program in Computer Sciences. Not open to students with credit for COMP SCI 301.

Course Designations and Attributes

Course Instructors

Learning Objectives

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

Readings

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

Lectures (Meeting Time and Location)

LEC001 through LEC004 will be recorded. Kaltura links will be shared post recording.

Instructional Modality

Communication

There are many ways we'll facilitate communication between everybody (i.e., instructors, TAs, peer mentors, and students) this semester:

  1. Piazza: Here you can ask questions and see questions written by other students. Do not post code snippets that are more than 5 lines long. This is considered cheating!
  2. Course Email: You'll receive announcement emails on either the compsci220-1-f21@g-groups.wisc.edu/compsci220-2-f21@g-groups.wisc.edu/compsci220-3-f21@g-groups.wisc.edu/compsci220-4-f21@g-groups.wisc.edu/compsci220-5-f21@g-groups.wisc.edu course list or from Canvas. You may also receive email from "no-reply@msyamkumar.com".
  3. Office Hours: To visit our office hours please see the schedule at: Office Hours Schedule. In-person TA / peer mentor hours will be held at CS1302. Details about online office hours will be updated after first week of classes.
  4. Email: 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 assigned TA (Resources->Who is my TA?). If you don't get a response within 48 hours, feel free to CC us at ms@cs.wisc.edu or kuemmel@wisc.edu or morteza@wisc.edu. We get lots of emails in a class this size, so we prioritize responding to students who try 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. If you have a question about regrading, you shouldn't be emailing your assigned TA, instead email your grader TA - your submission entry should have that information post grade release.
    • Please use the following subject tags so your email is directed to the right staff member.
      [Quiz | Exam | Project | Help | Regrade | Admin] [Quiz #| Exam #| Project # | Topic Name/ lesson #] 5-6 word summary of the query
  5. 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.
  6. 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.
  7. Canvas: We'll periodically upload grades to Canvas (LEC001 through LEC004) and Canvas (LEC005). Note that LEC001 through LEC004 are merged into LEC001 for Canvas.
  8. Lab Hours: Each week, we'll post a lab document with exercises you can work on to solidify what we've covered in class. Lab exercises are ungraded - these are guided learning opportunities that walk through various aspects of the course content. Sometimes we'll also introduce topics we didn't have time for in lecture. However, the emphasis will usually be on preparing for the project. For example, you may develop functions required to complete the lab. So make sure you work through the weekly lab before asking us for help on the project.

    A TA and a peer mentor will be there during lab hours to answer any student questions. All students are expected to complete the weekly lab before attempting to solve the corresponding project. Our recommendation is that you should either go through the lab on your own before the lab timing or attend the lab session. During lab hours, if there are fewer questions about the lab content, TA / peer mentor will be able to answer questions about the project - be sure to only show your code to your project partner / TA / peer mentor.

Grading

Grading is based on the following:

Communication is based on your online engagement (e.g., filling out surveys, signing up for Piazza). We'll give more details throughout the semester. Projects primarily focus on your ability to write code, quizzes help you assess your understanding of course content (lecture and readings), while exams focus more on your ability to read code.

At the end of the semester, we'll be awarding letter grades based on these thresholds:

Our grading scale is more strict than many other courses because it is possible to do very well on all of the projects. We provide test cases so you know when you have the questions correct, and we allow resubmissions if you get something wrong and want to go back and fix it (see Resubmission section). So the projects do not provide a good way to assess who has demonstrated they have earned a particular grade. We believe the projects are an important learning tool and feel it is important to reward students for their work on the projects.

Quizzes

Exams

Projects

Please see the course schedule for project due dates. Projects are due by midnight.

Late Policy: You will have 10 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. After late days are exhausted, anything late will receive zero credit by default. Please talk to us if you're falling this far behind. If you choose to use a late day for a particular project, your project submission will only be graded by next week!

Partners: You may work alone, or with one project partner of your choosing. We strongly encourage you to find a project partner. You can change partners between projects if you like. You may also partner with people in a different section of the course. In a perfect world you and your partner would 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. We will have some advice on how to do this remotely. 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.

Partnering process: CS220 students can partner up with any other CS220 student, immaterial of the enrolled lab or section. CS319 students are allowed to partner only with CS319 students. You can use the Demic app to find partners or for general discussions. Demic tutorial video. Project partners must not work on alternating projects. Project partners must not split the project questions and work on separate half of the project. Both of these will be considered as cheating!

Submission: For each project you and your partner will upload a single .ipynb file with the submission tool. Only one partner should upload the project on behalf of both partners. Uploading two projects will result in our cheating detection tool flagging your work - this is bad. If you have any issues using the tool, make sure you're using the latest version of Chrome, because that is the only browser supported (and if that doesn't work, ask for help).

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 both of you first to hear both sides, 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 will have the opportunity to fix these issues and then request a regrade.

Resubmission Regrade Requests: Based on the code review that you received, you are allowed to fix your mistakes and submit the project just one more time to get a better grade. You are only allowed to fix mistakes in questions you answered during your initial submission. Previously unsolved questions will not be graded in resubmission! Regrade requests must be received within one week of the release date of project scores. Resubmissions for projects are due 2 weeks from the project's original due date. For example, resubmission for P2 will be due on the same date that P4 is due. Resubmissions are not allowed for last two projects.

Accommodations

Please notify the instructor for your lecture section within the first two weeks of classes:

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

Similarity Detection: of course, with 900+ 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.

Recommendation Letters

Sometimes students who have done well in CS 220 / CS 319 later ask us for recommendation letters, for grad school etc. Unfortunately, getting an A in class isn't enough for us to write a 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 / CS 319 are really phenomenal (e.g., you are in the top 1-2% of students), we might agree to write you a letter even if we haven't seen any other work you've done, but it still won't be as good as if you show us something cool you've done in Python beyond 220.

To request a letter, please provide CV / resume, transcripts, statement of purpose (if applicable), code and description of the personal coding project at least 4 weeks before the due date of the recommendation letter.

Official Statements Required on the Syllabus

Credit Hour Policy: Traditional Carnegie Definition – One hour (i.e. 50 minutes) of classroom or direct faculty/instructor instruction and a minimum of two hours of out of class student work each week over approximately 15 weeks, or an equivalent amount of engagement over a different number of weeks. This is the status quo and represents the traditional college credit format used for decades. If you have regular classroom meetings and assign homework, reading, writing, and preparation for quizzes and exams, make this choice.

Official Course Description: Introduction to Data Science programming using Python. No previous programming experience required. Emphasis on analyzing real datasets in a variety of forms and visual communication. Recommended for Data Science majors and other majors

Course Evaluations: UW-Madison now uses an online course evaluation survey tool, AEFIS. In most instances, you will receive an official email two weeks prior to the end of the semester when your course evaluation is available. You will receive a link to log into the course evaluation with your NetID where you can complete the evaluation and submit it, anonymously. Your participation is an integral component of this course, and your feedback is important to me. I strongly encourage you to participate in the course evaluation.

Academic Integrity: By virtue of enrollment, each student agrees to uphold the high academic standards of the University of Wisconsin-Madison; academic misconduct is behavior that negatively impacts the integrity of the institution. Cheating, fabrication, plagiarism, unauthorized collaboration, and helping others commit these previously listed acts are examples of misconduct which may result in disciplinary action. Examples of disciplinary action include, but is not limited to, failure on the assignment/course, written reprimand, disciplinary probation, suspension, or expulsion.

Accommodations for Students with Disabilities: The University of Wisconsin-Madison supports the right of all enrolled students to a full and equal educational opportunity. The Americans with Disabilities Act (ADA), Wisconsin State Statute (36.12), and UW-Madison policy (Faculty Document 1071) require that students with disabilities be reasonably accommodated in instruction and campus life. Reasonable accommodations for students with disabilities is a shared faculty and student responsibility. Students are expected to inform faculty [instructors] of their need for instructional accommodations by the end of the third week of the semester, or as soon as possible after a disability has been incurred or recognized. Faculty will work either directly with the student [you] or in coordination with the McBurney Center to identify and provide reasonable instructional accommodations. Disability information, including instructional accommodations as part of a student's educational record, is confidential and protected under FERPA.

Diversity and Inclusion: Diversity is a source of strength, creativity, and innovation for UW-Madison. We value the contributions of each person and respect the profound ways their identity, culture, background, experience, status, abilities, and opinion enrich the university community. We commit ourselves to the pursuit of excellence in teaching, research, outreach, and diversity as inextricably linked goals. The University of Wisconsin-Madison fulfills its public mission by creating a welcoming and inclusive community for people from every background – people who as students, faculty, and staff serve Wisconsin and the world.