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

Syllabus

Welcome to your first programming course! CS 301 (Data Programming) is a gentle introduction to programming for students outside of computer science. Our goal is simple: learn to write Python code to answer questions about real datasets. CS 301 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.

Learning Objectives

Teachers

Caroline Hardin is the instructor for section 1 and Tyler Caraza-Harter is the instructor for sections 2 and 3. There will also be 10 TAs. There are more details on the people page.

Readings

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

Communication

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

1. Piazza: A public question/answer forum for you to get help. Link. WARNING: don't publicly post significant chunks of project code (even if the code doesn't work) to Piazza. That's considered cheating. Small snippets (5 lines max) are OK. When in doubt, seek help individually.

2. Email: We'll use these lists (one for each section) to send general announcements: compsci301-1-s19@lists.wisc.edu, compsci301-2-s19@lists.wisc.edu, and compsci301-3-s19@lists.wisc.edu. You cannot email these lists yourself. We'll also send personalized auto-generated emails from no-reply@caraza-harter.com; in particular, we'll send you project feedback and records of your exam scantron answers from this email. If you want to email us (instructors or TAs), you can do so indivdually, or send mail to all of us at cs301-ta@lists.wisc.edu.

3. Feedback Form: Our goal to to make fast corrections to any issues that may arise during the semester. To help with this, please send us feedback via this Google form. The form lets you share anonymous feedback, but we're grateful when you choose to share your name (it gives us a chance to respond and discuss further).

4. Code Review: You will upload projects using this tool. Via the same tools, TAs will leave comments on your code. In general, the comments will suggest ways for you to write better code and save effort in the future, so we highly recommend you read these.

5. Canvas: We'll periodically upload grades to canvas. Otherwise, there's nothing interesting there (all the course contents are public on this site).

Lab

Labs will give you time to practice what what have covered in lecture. While labs are not themselves graded, the purpose is to prepare you to do the projects on your own time. The labs will be self-guided, but there will be at least one TA there (usually two) to help answer any individual questions that you may have.

The labs will have Windows desktops you can use, but feel free to bring your own laptop if you so choose. There are not enough lab computers for everybody, so please work in pairs during this time.

In order to sign onto the lab machines, you'll need to activate your CS account.

Grading

You'll receive a score in the course based on three things: exams (50%), projects (49%), and participation (1%).

The exams will include two midterms (each worth 15%) and one final (worth 20%).

There will be ten projects, the names of which we'll abbreviate (e.g., "P3" is "Project 3"). The weight is 1% for P1, 4% each for P2-P7, and 8% each for P8-P10.

It is hard to judge participation for most students in a class of this size, so we'll factor engagement on various things we ask you to do (e.g., filling out our surveys, properly recording partner names on projects, etc).

At the end of the semester, we'll look at the distribution of scores and set a curve, with thresholds for each letter grade. The goal is to make the grading fair across semesters (even as we experiment with harder or easier projects). We'll also use our own discretion when setting the thresholds. For example, if everybody produces good results, we won't fail some students just for the purpose of the curve.

Exams

Exams are closed-book and closed-laptop. The exams will be multiple-choice scantron (use a #2 pencil).

You will be allowed one 8.5-by-11 inch notesheet (handwritten only, both sides), which you must turn in with your exam. Later material builds on earlier material, so the exams will be necessarily be cumulative.

If you need special accomodations for exams (or other components of the course), please let us know. We'll do our best to accomodate you. More information about McBurney is here.

Times/Locations (for 001):

Times/Locations (for 002):

Times/Locations (for 003):

Projects

Late Policy: You will have 5 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. However, we encourage you to talk with the instructor for your section if you're having trouble keeping up or there are any special factors requiring extensions (e.g., documented illness). The hope is that everybody keeps pace!

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

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

Yeah, of course 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. What's somewhat safer is when a student who has completed a problem looks at the code of a student still working on the problem. In this case, the more-advanced student can often provide useful advice and debugging tips that help the less-advanced student without causing the less-advanced student to copy code. Just make sure the more-advanced student isn't telling the less-advanced student exactly what to type, line by line.

Similarity Detection: of course, with 500 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: 

  # code 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.