Syllabus

This is the syllabus for the term. For the schedule, click here.

Front Matter

Instructor: Acacia Ackles

Room: Briggs 419

Time:

MW 9:50 AM - 11:00 AM (Lecture)
Th 10:25 AM - 12:10 PM (Lab)

Units: 6

Course Materials

Automate the Boring Stuff with Python, 2nd Edition. Free to read online here. Print copies can be purchased but are not required.

You will also need a personal laptop to bring to class each day. If this is a barrier for you, please let me know ASAP.

Course Communication

We will be using Piazza for all communication in this course, including announcements and discussions. Make sure you are signed up for Piazza so you don’t miss any information.

All correspondance with me should also go through Piazza, including scheduling meetings. You can always post privately so that only I can see it.

Student Drop-In Hours

Office: Steitz 131 (NOTE: NOT BRIGGS)

Mon/Wed/Thu/Fri: 2:00 PM - 3:00 PM
Tue: Appointment Only

These are the times when my schedule is blocked off for nothing but to talk to you. So please do come by!

If you are busy during these times, you can always schedule an appointment with me instead. Or you can swing by Steitz and see if my door is open; if it is, you are completely welcome to stop by.

Overview

This course will teach you the basics of how to program with Python.

It won’t teach you theory of computer science, and it won’t make you a Python magician, but it will make you functional at talking to your computer and asking it to do things for you. Think of it like a 10-week crash course in a foreign language: you won’t become fluent, but you’ll be able to read the bus schedule and ask for the restrooms.

If that sounds like fun to you, then good! Let’s go. If you’re looking for something else, you maybe looking for CMSC 150.

Learning Goals

By the end of this course, you should be able to do the following:

  • L1: Basics: Take a problem, break it down into a series of steps (an algorithm), identify the programming components most appropriate to use for each step, use those components in Python to tell the computer how to solve the problem. Those components include:
    • variables
    • loops (for and while)
    • conditionals
    • functions
    • lists
    • dictionaries
  • L2: Data Processing: Process data from external files and user input to address a specific task related to that data
  • L3: Debugging: Debug syntactic and logical errors in a program in a systematic fashion, and know how to ask good questions when new problems arise
  • L4: Style: Write code that is easy for others to understand because it uses effective variable names and comments, and is well-organized using functions (including main) and objects as appropriate
  • L5: Code Review: Read and explain code written by others and approach that process in a systematic way
  • L6: Collaboration: Use Git and GitHub to handle versioning of projects and sharing of projects with collaborators
  • L7: Reflection: Be able to reflect on your work and identify areas of strength and areas for improvement

Importantly, there are a few things you may find in first courses targeted at CS majors that this course does not cover. In particular, we will not focus on:

  • Object-oriented programming. This is the biggest one; we will touch on what object-oriented programming is, but this is not an OOP class.
  • Graphical user interface tools for Python (though you can optionally explore these in your final project)
  • Big-O notation and computational complexity
  • Efficient sorting and searching
  • Recursion and dynamic programming

This content is covered more thoroughly in CMSC 150, the course for majors. If any of these topics are of great importance to you, I suggest taking CMSC 150 instead of 140.

Assessment

This class will probably be graded very differently than you’re used to. We’ll take time at the beginning of class to discuss the structure and assessment for the class. Please read everything below, but here are the main bullet points:

  • Every assessment (homework, labs, and final project) will be graded on a mastery scale
  • Every learning objective will have associated assessments; demonstrating mastery of those assessments will demonstrate mastery of the learning objective
  • The more learning objectives you demonstrate mastery of, the higher grade I can give you
  • All assessments may be revised however much you wish

For more on why I’m doing this (if you’re interested), see the Pedagogy section.

Homework, Labs, and Final Project

You will have three different kinds of assessments:

  • Homework. These are assessments completed outside of class. They will typically be due one week after they are assigned.
  • Labs. These are assessments completed in class, during our longer Thursday section. They are designed to be started and completed within our lab section, but there is no penalty to you (besides your time) if it takes longer than that.
  • Final Project. This is your sort of “capstone” to the course; it is a single project designed as an example of everything you have learned. For details on this final project, see the Final Project tab. This project can be completed collaboratively or individually, but you will receive an individual score.

Note: You will also have morning reding checks, but these aren’t going to factor into your score. They’re a tool for me to know what people are getting out of the readings.

How to Turn In Work

Homework and Labs will be turned in to Canvas as a .py file.

Your final project will be uploaded to your GitHub as a repository. We will set up your github in the first week of class.

Mastery-Based Grading Scheme

My goal for you this semester is that you come away as both a stronger programmer and a stronger learner. This course uses a version of ungrading or mastery-based grading. Rather than assigning point values to homework, quizzes, or projects, all assessments will be graded on a mastery scale:

Assessment Scale

     
M Mastery Demonstrates clear understanding of the learning objective; could explain the concept to others accurately; can implement without scaffolding
P Proficient Demonstrates some understanding of the learning objective; can sometimes implement but not yet consistently; needs scaffolding to implement properly
N Novice Does not yet have sufficient understanding of the learning objective; is beginning to build understanding but cannot implement consistently even with scaffolding
IC Incomplete Nothing written or turned in
     

Learning Objectives

Each assessment you complete (homework, labs, projects) will have associated learning objectives (see HW1 for an example). You’ll have at least 4 chances to demonstrate mastery of each learning objective.

For each learning objective, you’ll receive a grade on the same mastery scale as each individual assessment.

Learning Objective Scale

     
M Mastery Demonstrates mastery on 75% or more of the associated assessments, and proficiency in remaining
P Proficient Demonstrates proficiency on 75% or more all associated assignments
N Novice Demonstrates novice work on 75% or more of the associated assessments
IC Incomplete Has not submitted at least 75% of the work for that objective
     

Below is an outline of which assessments match to which learning objectives, and how many mastery credits you need for each in brackets. Don’t worry; as the semester goes on, I’ll keep a tally for you of how you’re doing on each (and you can always ask)

L1: Basics [10 of 13]

  • All Homeworks (HW1-HW5)
  • Labs: Week 1-5, Week 7
  • Final Project Draft
  • Final Project

L2: Data Processing [3 of 4]

  • Week 7 Lab: Housekeeping
  • Week 8 Lab: Debug Challenge
  • Final Project Draft
  • Final Project

L3: Debugging [2 of 3]

  • HW5
  • Week 8 Lab: Debug Challenge
  • Revision of any homework where you did not earn mastery credit

L4: Style [9 of 12]

  • All Homeworks (HW1-HW5)
  • Labs: Weeks 1-5
  • Final project draft
  • Final project

L5: Code Review [2 of 3]

  • Homework 3
  • Week 8 Lab: Debugging
  • Final project feedback

L6: Collaboration [3 of 4]

  • Week 1 Lab: Python Setup
  • Week 7 Lab: Housekeeping
  • Week 8 Lab: Debug Challenge
  • Final project

L7: Reflection

This one is slightly different; for mastery credit you must:

  • Complete revisions of any two assessments. These assessments can even be ones you already earned mastery credit for the first time around. There’s always something to tweak or try differently next time!
  • Complete your final project reflection.

You must do all three of these things for Mastery credit. 2/3 will earn a Proficiency; less than that will earn an Incomplete.

Gradebook

This will translate to the gradebook as follows:

LU Grade CMSC 140 Requirements
A Demonstrate mastery (M) for all 7 learning objectives.
B Demonstrate mastery (M) for 4-6 learning objectives and proficiency (P) in remaining objectives. NOTE: Must demonstrate Mastery (M) of L1: Basics.
C Demonstrate proficiency (P) or better in all learning objectives.
D Demonstrate proficiency (P) in 4-6 learning objectives and novice work (N) in remaining objectives. NOTE: Must demonstrate Proficiency (P) of L1: Basics.
F Demonstrates proficiency in fewer than 4 learning objectives OR is not at least proficient in L1: Basics.

If you instead have an Incomplete (IC) in any learning objective, we’ll talk on a case-by-case basis about the best outcome for you for the class.

Revisions

Learning is a non-linear process. One of the best ways to learn something is to do it wrong, then take feedback on how to do it better. For that reason, any and all assessments in this class can be revised up until the end of the term. This is to give you the ability to control your own time management and offer flexibility; however, to protect my own time and flexibility, there are some guidelines.

If you are revising within one week of the original feedback, I will guarantee feedback within a week of your revised submission.

If you are revising after one week from the original feedback, I cannot guarantee how quickly you will receive new feedback; however, it will be taken into account by the end of the term.

Example 1: Homework 3 is due October 6th. You receive your feedback and a mastery score of Proficient on October 9th. You resubmit the assignment on October 16th. You are guaranteed to receive new feedback and an updated mastery score by October 23rd.

Example 2: Lab 2 takes place on September 22nd. You receive your feedback and a mastery score of Novice on September 24th. A while later, you decide to redo the lab and resubmit on October 24th. You may not receive feedback or an updated score until the end of the term. You could also receive it more quickly than that, depending on how busy I might be with other revisions.

Late Work & Extensions

All late work falls under the revision policy and is considered work turned in as Incomplete. “Revise” (i.e. submit) within one week of the original deadline for guaranteed feedback.

That said, the term moves quickly. If you are consistently submitting late work, it will impact your ability to succeed in class, and I may ask you to meet with me to figure out how to help you best succeed in the course.

Collaboration and Plagiarism

None of us want to have to go through the honor council process, so I want to lay out clearly what is and isn’t considered acceptable collaboration for this course.

It is important to note that my primary concern is that you are learning. I allow you to revise and resubmit work on a mastery-based scale specifically to try to alleviate some of the pressure of strict, points-based grading that, in my experience, encourages gaming the system over learning.

If there is ever a situation where you’re unsure if something is acceptable collaboration or not, please just ask, even if you have already turned in the assignment. I will never hold it against you if YOU are the one pointing out the issue. At worst I will ask you to resubmit.

Acceptable Collaboration

The following are always allowed on homeworks, labs, and projects.

  • Posting general questions on Piazza about how to solve the problems in class
  • Attending student hours and asking questions about the approach you are taking, then incorporating that approach into your code.
  • Discussing the concepts in the class with your classmates on a general level, e.g. in words or with pseudocode
  • Having someone else read your code with you and provide suggestions which you then implement yourself
  • Reading someone else’s code to provide them with suggestions
  • Looking online for help to your general problem, or a component of your problem with proper citation. Example: Your homework question is “Implement a program that will randomly generate four dice rolls and drop the lowest value.” It is fine to look up how to randomly generate numbers in python, how to find the minimum value, and how to return those numbers, and then paste the links as comments in your code. It is not fine to look up “python 4d6 drop lowest” and copy the code whole.

Unacceptable Collaboration/Plagiarism

The following are never allowed.

  • Posting actual code on Piazza where other students can see it (posting it privately so I can read it is okay)
  • Copying any code that another student has written
  • Copying code from online without attribution
  • Posting solutions to the course materials to online aggregation sites (e.g. Chegg) or using solutions from such sites
  • Having a friend debug your code for you and then turning in the revised code
  • Looking at a friend’s code (or code on the internet for a similar purpose) and then using what you see to write your own code*
  • Looking at code from someone in class and then reproducing it verbatim in your own files
  • Directly copying code out of the book, or relying heavily on book code and not citing your use of it in the comments when the assignment does not specifically state that you may do so.

* This one is tricky. Sometimes seeing what other people are doing right or wrong can be helpful for understanding our own code, but often when we’re just starting out, it’s hard to find the line between learning something new and implementing something without really understanding how it works. If you are ever unsure, ask first.

Course Policies

Attendance

Attendance is encouraged; it is not mandatory, and it is not tracked. You will likely do better in class if you attend regularly; however, I understand that you may have many responsibilities and commitments outside this classroom.

I will post lecture notes and live coding demos to the course website under Materials so that if you do miss class, you can catch up. As always, you are responsible for learning any material that you miss, and as always, my student hours are available to discuss any material you might need guidance on.

Exception: Per LU policy, attendance is required for the first week of class. If you do not attend the first day AND do not let me know why, I will reach out to you to check if you are still attending; if you do not respond and do not attend the first week, the registrar will drop you from the course.

Accomodations

I make every effort to incorporate universal design and inclusive learning into my course materials, but individualization is an important part of learning.

I will follow the guidance of any academic accomodations you request through the Center for Academic Success.

I will also make a good-faith effort to follow other academic accomodations you may need, regardless of whether or not you have documentation from CAS, a doctor, or otherwise. If there is something I can do that you know will allow you to engage fully with the course, please do not hesitate to ask. (If you need help figuring out what that ‘something’ is, we can chat about that too.)

Illness and Mask Policy

Please do not come to class if you are sick. Please do not come to class if you think you might be sick. Please do not come to class if you were exposed to any sort of highly contagious airborne disease. You do not need a doctor’s note and I do not need an excuse for you to miss class. Just don’t come!

If anybody requests that we all be masked (anonymously), then there will be a masking requirement for our course. Otherwise, we will follow Lawrence University’s guidance on masking for the term.

Other Policies

Here are some other assorted course policies that may be added to over the term.

  • Food and drink are always okay to have in class, but I’m not responsible if your laptop gets drenched.
  • If you are experiencing a childcare or dependent care emergency, you are welcome to bring your child/dependent to class if you choose to attend.
  • Your health and wellbeing as a human are more important than any university course, including mine.

Boilerplate

Here is where I’ll put the Lawrence boilerplate info.

Pedagogy

This section exists because I’m a big believer in transparency. For one, I think many students learn better when they understand their professors’ teaching choices. For another, you’re dedicating quite a lot of your time and money to be in this classroom; it seems only fair that you get insight into how it works. If you aren’t interested in the pedagogy behind this course, feel free not to read this. But it is here for you if you want it.

Metacognition and Student Reflection

Metacognition has been repeatedly shown to enhance student independence and success (1, 2). Metacognition is literally “thinking about thinking”; what leads you to the conclusions you reach when you’re learning a new topic? What assumptions are you making when approaching a new topic that might be helping or hurting your understanding?

Ten weeks is a pretty short time frame to try to get really deep into metacognitive practices, so I really just try to incorporate reflection and revision into the course as much as possible. That’s why one of our first labs is a revision of one of the other labs, and why all assessments can be revised and resubmitted at any time.

Ungrading

My goal is for students to focus more on what they have learned than how many points they have received for learning it. To encourage such focus, I myself prioritize feedback over scoring. This has led me to the mastery-based “grade” scheme that I use.

Ungrading is also a more equitable form of student feedback. In computer science classrooms, ungrading typically enhances recruitment and retention of historically excluded students and reduces student stress, while maintaining a high standard of student work (3, 4).

For more on ungrading, see (5).

This syllabus is based heavily on one by Dr. Anya E. Vostinar. Thanks!