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

Syllabus

Description

Welcome to your first programming course, Data Programming (CS 301)! This course is intended as a gentle introduction to programming for students outside of computer science. CS 301 will approach programming from a data-science perspective. Despite being numbered in the three-hundreds, CS 301 assumes no programming background. We will learn the basics about computers work, learn to program in the Python language, and write Python programs that work with interesting datasets. CS 301 is a data-centric, Python-based, and hands-on introduction to programming.

Data-Centric: Many 301 students are majoring data-rich fields (e.g., mechanical engineering, psychology, economics, and many other quantitative fields). Our emphasis will be on writing code to make use of datasets you will encounter in your various fields of study. We will be writing code to extract information from data sources (in their many forms), run simple simulations, and create plots. In contrast, introductory courses for computer science majors are less data centric, but delve deeper into topics such as object oriented programming and basic theory (e.g., complexity analysis of algorithms).

Python-Based: Just as there are many languages for communicating with humans (e.g., English, Spanish, Hindi, etc), there are many languages for programming computers (e.g., Java, C++, Python). Although Java is a very popular for teaching introductory programming, we will be using Python for several reasons. (1) Python is becoming increasingly popular, making it a valuable career skill. (2) Python is an easy language to learn and use; you'll type much less code relative to how much you would type to create equivalent programs in, say, Java. (3) Python is very powerful, perhaps counter to expectations given its ease of use. Python has been used to build large-scale web applications, such as reddit and Pinterest. Extensions such as numpy (which we will cover in 301) make Python powerful and fast for various analytics.

Hands-On: CS 301 will be very hands-on and pragmatic. At first, most students find programming slow and challenging. As with learning a human language, becoming fluent in a programming simply requires lots and lots of practice. We want you writing lots of code every week is CS 301. Thus, instead of having a few large projects, we'll be giving smaller projects nearly every week. We'll be providing lots of help and support for these projects; we're not trying to make the course difficult, we're trying to help you become proficient coders through practice.

A detailed course schedule is available here. The schedule and content is subject to change based on student feedback and interests, so please check it often.

Learning Objectives

Instructors

This fall 2018, there will be three lecture sections and nine lab sections. Contact information and the typical office hour schedule can be found on the people page. Deviations to the regular office hour schedule can be found in the Google calendar.

Textbook (Free)

Think Python 2nd Edition by Allen B. Downey, ISBN 9781491939369. Amazon link. Free download.

Communication

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

1. Piazza: Any non-private questions you have that may be of interest to other students should be posted to Piazza. This will help us avoid answering the same question many times for different students. Also, feel free to answer other student's questions when you can. This is a place for us all to learn from each other. WARNING: don't post significant chunks of project code (correct or otherwise) to Piazza. Small snippets (e.g., <6 lines) are OK, but giving away solutions to graded work is cheating. When in doubt, ask us privately whether it is OK to post something.

2. Email: You should be automatically enrolled in either compsci301-1-f18@lists.wisc.edu (for section 001) or compsci301-2-f18@lists.wisc.edu (for section 002) or compsci301-3-f18@lists.wisc.edu (for section 003). We'll use these lists for a few important announcements throughout the semester (e.g., before exams). You cannot email these lists yourself. You can, however, email us directly. You can contact all the TAs and instructors at once by emailing cs301-ta@lists.wisc.edu. This is appropriate for grading questions, or when you have a question about your specific code (which should not be posted to Piazza).

3. Feedback Form: At the end of the semester, you'll be asked to provide feedback on the course (materials, lectures, etc). While that end-of-semester feedback will be very helpful for us in future semesters, it doesn't help you right now! We encourage you to leave feedback with this Google form throughout the semester so we can fix any issues quickly. The form also gives you the option to share feedback with us anonymously.

4. Project Submission: You will upload projects using this tool. I (Tyler) developed this tool over the summer, and this is the first semester it will be used, so please directly share feedback with me regarding any technical difficulties you encounter (tylerharter@gmail.com).

5. Canvas: This is a tool that can serve different purposes in different courses. We'll only be using Canvas as a way for us to share your grades with you. We'll upload both project and exam scores here (the only two components of your grade).

6. Clicker Questions: As a lecturer, one of the most important things for me to receive feedback on is pacing. Are students bored, and I should go faster? Do I need to go slower and give more examples? In order to get this feedback, we'll be using a clicker application where I ask questions during lecture and students submit their answers answers on their phones or laptops. If many students are getting a question wrong, that will signal to me that I should slow down. Note that your answers here are not anonymous.

Lecture (Sections 1+2)

We'll meet three times a week (MWF) for a 50 minute lecture. I (Tyler) will cover material with slides (which I'll post here after lecture). I'll also spend a lot of time writing programming on-screen and talking through what I'm doing to help you learn how to deconstruct a problem and turn it into code. Times/Locations:

When I'm writing code in class, it will be very helpful for you to follow along, so I highly encourage you to bring your laptops to lecture. I implore you, however, to use it for writing code, not getting distracted!

Lecture (Section 3)

We'll meet two times a week (TR) for a 75 minute lecture.
Times/Locations:

Lab

Each lab section has about 56 students and will meet once a week for 75 minutes. Each lab section will be led by a TA. The focus of the lab sections will be to work on the weekly project (which is always due Wed at midnight). Usually this will be a flexible time driven by student questions about the projects. The TAs may also present something that will be helpful for your project.

The labs will have Windows desktops you can use, but feel free to bring your own laptop if you so choose. Times/Locations:

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

Exams

Exams are worth 40% of your final grade. We'll have two midterms, each worth 10%, and a final worth 20%. These are closed-book, closed-laptop exams. The exams will be multiple-choice scantron.

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

Times/Locations (for 001):

Times/Locations (for 002):

Times/Locations (for 003):

If you need special accomodations for exams (or other components of the course), please let us know early in the semester. More information about McBurney is here.

Projects

Projects are worth 60% of your final grade. There will 10 graded projects, so there will be a project due most weeks. The first 9 projects will be worth 5% each, and the final project (P10) will be worth 15%. Each project will be due on a Wednesday at midnight and will be posted at least 1 week before the deadline. All the lecture material necessary to complete a project will have been presented by the Friday prior to the due date (at the latest).

Late Policy: You will have 10 late days, which you can use across projects at your own discretion. For example, you could turn each of your 10 projects in one day late, or you could turn in one project 10 days late, and all the others on time. Use your late days judiciously! 10 may sound like a lot, but remember you have as many projects as late days. Furthermore, using a late day on, say, P5 will not change the deadline for P6 or subsequent projects. NOTE: December 15th is a hard deadline for all projects; you may not use late days to submit anything after that date. If you find you're using a lot of late days early in the semester, I encourage you to meet with us sooner rather than later to discuss work habits and strategies for starting projects early. Our hope is that this late day policy will give you flexibility, and not cause work to pile up for you later on.

Partners: You may work alone, or with one project partner of your choosing. You can work with the same partner for many projects, or change partners at any point. Feel free to partner with a student in any of the three sections (001, 002, or 003). You 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 can upload either a .py file or a .zip file for each project with the submission tool. Only one partner is required to upload the project. Following the directions here. 

# my-login: YOUR-NETID
# partner-login: PARTNER-NETID

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. The reviewer (the TA) will comment on the quality/quantity of your documentation, how you name variables and functions, and whether there are more elegant solutions to the problem you are trying to solve. Bad code reviews often rely on simple rules (e.g., put a comment before every method), whereas good code reviews are often more subjective, and a matter of taste. Thus, code reviews will not be part of your grade, so TAs will be free to give useful feedback that does not fit well with a rubric. I highly recommend to read your code reviews carefully and learn from them.

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 never be surprised by your grade. Except for three situations, the tests will tell you exactly what your grade will be even before you hand in your code. The exceptions are:

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

Cheating

Don't cheat! Details on what constitutes cheating in CS 301 are here.

Copying code from a student who is not your partner is definitely cheating. You can, however, 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!