Intermediate Data Programming

University of Washington, Spring 2024

Kevin Lin

he/him

kevinl@cs.uw.edu

Office Hours

Mondays and Wednesdays 1:30–2:30 PM

Schedule a meeting

The world has become data-driven. Domain scientists and industry increasingly rely on data analysis to drive innovation and discovery; this reliance on data is not only restricted to science or business, but also is crucial to those in government, public policy, and those wanting to be informed citizens. As the size of data continues to grow, everyone will need to use powerful tools to work with that data.

In this course, students will learn:

  1. More advanced programming concepts including how to compose programs with multiple modules.
  2. How to work with different types of data: tabular data, text data, image data, geospatial data, etc.
  3. Data science tools and libraries including Jupyter Notebook, scikit-image, scikit-learn, and Pandas.
  4. Software engineering skills including asymptotic analysis, data settings, and data ethics.

This course is designed to support students who have completed:

CSE 160: Data Programming
Know control structures, file I/O, and data structures in Python. Your first weeks will be a review.
CSE 122: Introduction to Computer Programming II
Know control structures, file I/O, and data structures in Java. Your first weeks will focus on learning these concepts in Python.

What will you learn?

Python

Python Fundamentals

3/25
Welcome
3/27
Control Structures
3/28
SecPython Fundamentals
3/29
Strings and Lists

Data Structures and Files

4/1
File Processing
4/3
Data Structures
AsmPrimer by 4/11
4/4
SecData Structures and Files
4/5
CSV Data

Pandas

Pandas Fundamentals

4/8
Data Frames
4/10
Groupby and Indexing
AsmPokemon by 4/18
4/11
SecPrimer: Code Review
4/12
Data Visualization

Data Visualization

4/15
Data Settings
4/17
Spreadsheets
AsmEducation by 4/25
4/18
SecPokemon: Code Review
4/19
Objects

Software Engineering

Object-Oriented Programming

4/22
Objects (continued)
4/24
Objects (conclusion)
AsmSearch by 5/2
4/25
SecEducation: Code Review
4/26
Asymptotic Analysis

Machine Learning

4/29
Learning Algorithms
5/1
Model Evaluation
PrjProject Proposal by 5/9
5/2
SecSearch: Code Review
5/3
Bias, Variance, Bias, and Bias

Applications

Geospatial Data

5/6
Geospatial Data
5/8
Dissolve, Intersect, and Join
AsmMapping by 5/16
5/9
SecMachine Learning
5/10
Climate Modeling

Computer Vision

5/13
NumPy
5/15
Convolutions
5/16
SecMapping: Code Review
5/17
Neural Networks

Project

Language Models

5/20
Language Models
5/22
The End of Knowledge
5/23
SecPrjProject Code
5/24
Natural Language Processing

Conclusion

5/27
Holiday
5/29
TA Panel
5/30
SecPrjProject Report
5/31
Next Steps

Why should we learn?

The education you receive in this course can help prepare you for programming jobs, but this isn’t the only purpose for computing education.1 Education is not only about yourself and your personal gain, but also about all of us and our capacity to live together as a community.

The University of Washington acknowledges the Coast Salish peoples of this land, the land which touches the shared waters of all tribes and bands within the Duwamish, Puyallup, Suquamish, Tulalip and Muckleshoot nations. Among the traditions of the Coast Salish peoples is a value for the connectedness between all living things and a recognition of the unique ways that each of us comes to know something.2

Modern education has the idea that we all need to know the same thing. At the end of the lesson, everyone will know the same thing. That’s why we have tests, that’s why we have quizzes, that’s why we have homework: to ensure we all know the same thing. And that’s powerful—that’s important—within a certain context.

But for native culture, the idea that each listener divines or finds their own answer, their own meaning, their own teaching from the story is equally powerful—that each person needs to be able to look at the world and define it for themselves within their culture and then also find a way to live in that world according to the teachings of their people in their culture.

Our course emphasizes the following values.

We are responsible for each others’ success
Everyone has a right to feel like they belong in this course. We’ll need to act with compassion and caring to collaborate with each other. Although we will need more than just unexamined commitments to collaboration, listening, empathy, mindfulness, and caring,3 the following guidelines offer a starting point for ensuring compassion toward each other.4
  • Listen with intention to understand first and form an opinion only after you fully understand.
  • Take responsibility for the intended and unintended effects of your words and actions on others.
  • Mindfully respond to others’ ideas by acknowledging the unique value of each contribution.

You should expect and demand to be treated by your classmates and teachers with respect. If any incident occurs that challenges this commitment to a supportive, diverse, inclusive, and equitable environment, please let the instructor know so the issue can be addressed. Should you feel uncomfortable bringing up an issue with the instructor directly, meet our advisors during quick questions or contact the College of Engineering.

We recognize everyone has unique circumstances
Do not hesitate to contact the instructor by private discussion post or appointment. The sooner we are made aware of your circumstances, the more we can help. Extenuating circumstances include work-school balance, familial responsibilities, religious observations, military duties, unexpected travel, or anything else beyond your control that may negatively impact your performance in the class.
It is the policy and practice of the University of Washington to create inclusive and accessible learning environments consistent with federal and state law. If you have already established accommodations with Disability Resources for Students (DRS), activate your accommodations via myDRS so we can discuss how they will be implemented in this course. If you have a temporary health condition or permanent disability that requires accommodations, contact DRS directly to set up an Access Plan.
Washington state law requires that UW develop a policy for accommodation of student absences or significant hardship due to reasons of faith or conscience, or for organized religious activities. The UW’s policy, including more information about how to request an accommodation, is available at Religious Accommodations Policy. Accommodations must be requested within the first two weeks of this course using the Religious Accommodations Request form.
We believe everyone wants to learn
Education is about shaping your identity as much as it is about learning things. In school, the consequences of making mistakes are relatively small. But the habits you form now—repeated over days, weeks, months, or years—determine who you will be in the future. Now is the best time to practice honest habits.
We ask that you do not claim to be responsible for work that is not yours. When you receive substantial help from someone else, include a citation. Don’t post your solutions publicly. Most importantly, don’t deprive yourself or others of the learning opportunities that we’ve created in this course.
Academic honesty reflects the trust (or the lack thereof) between students and teachers. We do our best to design the course in ways that ensure trust, but we know our systems are not perfect. If you submit work in violation of these policies but bring it to the attention of the instructor within 72 hours, you may resubmit your own work without further consequence. Rather than blame students, we want to fix or replace broken systems that compel students to lose trust.

How will you learn?

In a traditional classroom, you attend class while a teacher lectures until time is up. Then, you go home and do the important work of applying concepts toward practice problems or assignments on your own. Finally, you take an exam to show what you know.

Today, we know that there are more effective ways to learn science, engineering, and mathematics.5 Learning skills like software engineering and algorithm analysis requires deliberate practice: a learning cycle that starts with sustained motivation, then presents tasks that build on prior knowledge, and concludes with immediate, personalized feedback. Each module in the course will involve several different activities that are designed so that we can make the most of our class time together.

Before lecture, skim the class activities and ask questions in the discussion board.
Optionally, in Ed Discussion, write your questions in the weekly discussion thread.
During lecture, learn and support each other on the in-class guided coding practice.
In PollEverywhere, submit your responses to complete the coding polls and activities.
In section on Thursday, work with your team to get started on the upcoming weekly programming assessment. Complete the assessment by the following week’s section for code review.
During quiz section, participate in a small-group peer code review evaluated by your TA.
In Canvas, use your browser’s PDF printer to submit your notebook as a PDF for TA review.
In Canvas early the next week, respond to your TA review questions to complete the review.

Code review discussions are the primary means of standardized assessment in this course. Rather than treat your submitted program code as the final artifact for evaluation, it is instead a starting point for a conversation that demonstrates your programming fluencies such as code writing, code reading, code debugging, and code communication skills. Communicating your ideas and explaining your decision-making is important in this course. But we know that live discussions during class may not be accessible for everyone and we would be happy to work with you to design accommodations that would allow you to communicate your programming fluencies in an accessible format for you.

The purpose of all these activities are for you to learn the course concepts, not to prove that you already know them. Working with a team and discussing problem solving approaches is an effective way to learn. You can expect to receive substantial assistance from other students and the course staff before, during, and after class. Regardless of how much help you receive from others, in order to conduct a successful code review discussion, you’ll need to be deeply familiar with all the code that you write. Do not deprive yourself or others of learning opportunities in this course.

Encouraged
Discussing examples shown in class. These examples are part of the course’s learning materials.
Working with a TA to improve your understanding of a task and resolve a particular problem.
Communicating with other students without sharing code or exact details to reproduce a solution.
Permitted with caution
Working alongside one or more other people on an assessment. Peer code review relies on students preparing sufficiently different programs that are then compared against each other.
Sharing or generating small snippets of code that are not specific to any part of an assessment. Code reviews require you to explain, discuss, and compare ideas about code that you wrote.
Prohibited
Obtaining or generating solutions to any part of an assessment in any form for any reason.
Giving, receiving, or generating a walkthrough to an assessment from anyone or anything else.
Posting solutions to an assessment in a public place even after the course is over.

All sources that you consult in completion of your work must be cited and documented, including course materials, lectures, and sections. Assignment completeness will depend on cited sources matching the submitted work.

Expect to spend 4 hours in class and 8 hours outside of class working on this course. Some weeks may require more or less time than other weeks. If you find the workload is significantly exceeding this expectation, talk to your TA.

  • 8:30 AM
  • 9:00 AM
  • 9:30 AM
  • 10:00 AM
  • 10:30 AM
  • 11:00 AM
  • 11:30 AM
  • 12:00 PM
  • 12:30 PM
  • 1:00 PM
  • 1:30 PM
  • 2:00 PM
  • 2:30 PM
  • 3:00 PM
  • 3:30 PM
  • 4:00 PM

  • Monday

    • Office Hours
      10:30 AM–12:30 PM
      MEB 250
    • Lecture
      12:30 PM–1:30 PM
      KNE 120
    • Office Hours
      1:30 PM–3:30 PM
      LOW 102

  • Tuesday

    • Office Hours
      10:30 AM–12:30 PM
      ECE 054
    • Office Hours
      2:30 PM–4:30 PM
      LOW 113

  • Wednesday

    • Office Hours
      10:30 AM–12:30 PM
      ECE 003
    • Lecture
      12:30 PM–1:30 PM
      KNE 120
    • Office Hours
      1:30 PM–3:30 PM
      BAG 108

  • Thursday

    • Sections
      8:30 AM–4:30 PM

  • Friday

    • Office Hours
      10:30 AM–12:30 PM
      LOW 101
    • Lecture
      12:30 PM–1:30 PM
      KNE 120

How is this course graded?

Grading in this course emphasizes both completion and quality trend of coursework received for formal evaluation. Completion is tracked primarily through Canvas module requirements, while quality trend is tracked primarily through the Canvas learning mastery gradebook. Each assessment contributes one alignment to the listed learning outcomes. With the exception of Testing and Writeup, a quality trend is established based on work in the latest 4 alignments: this provides one allowance for a missing peer code review.

1.0 or greater
Completion of Python and Pandas modules.
2.0 or greater
Completion of Python, Pandas, and Software Engineering modules.
Approaching quality trend for all learning outcomes.
3.0 or greater
Completion of Python, Pandas, Software Engineering, and Applications modules.
Satisfactory quality trend for all learning outcomes.
4.0
Completion of Python, Pandas, Software Engineering, and Applications modules.
Exemplary quality trend for all learning outcomes.
Highest marks in Project module.

Grading in this course emphasizes learning by evaluating quality as a trend over time rather than as a fixed score. With the exception of the Project, individual assignment scores do not directly feed into final grades. In Canvas, quality trend is computed using a decaying average. This formula makes several mathematically convenient but ultimately faulty assumptions, such as treating scores as equally distant numbers and that each assessment is equally important. Final grading will address these assumptions and more.

Evaluating Assessment Approaches in Intermediate Data Programming

You are being asked to participate in a research study to find out more about how assessment approaches affect the student experience in an undergraduate data programming courses. You have been asked to participate in this study because you are a student in a class that is being studied or used as a control. The purpose of this study is to create knowledge that has the potential to improve the educational experience for students at the University of Washington and beyond.

What will you be asked to do?
Your data from this class including surveys/evaluations, coursework, and course forum discussions may be analyzed. Your participation involves only agreeing to let us use your data in our analysis. You will not be required to do anything beyond normal educational practice.
There may be additional optional opportunities to participate in follow-up interviews or focus group discussions. These are not required, and details will be provided when they arise.
What will happen to the information you provide?
Data from participants will be retained only for research purposes and stored using codes that provide a degree of confidentiality. Your instructor will not know whether you are participating in this study until after final grades have been posted.
What can you do if you want more information?
Talk to the study team. Kevin Lin is the lead researcher at the University of Washington for this study and can be contacted at kevinl@cs.uw.edu.
Talk to someone else. If you want to talk with someone who is not part of the study team about the study, your rights as a research subject, or to report problems or complaints about the study, contact the UW Human Subjects Division at hsdinfo@uw.edu or 206-543-0098.
What are my options to participate?
By default, you will be included in this study. No additional actions are required to participate.
Participation in this research, however, is optional. You may withdraw at any time without penalty by contacting Suhas Kannam at ksuhas16@uw.edu.

  1. Mark Guzdial. 2021. Computer science was always supposed to be taught to everyone, and it wasn’t about getting a job. ↩

  2. Roger Fernandes. 2012. Roger Fernandes: Artist/Storyteller/Educator. ↩

  3. Brian Arao and Kristi Clemens. 2013. “From Safe Spaces to Brave Spaces: A New Way to Frame Dialogue Around Diversity and Social Justice” in The Art of Effective Facilitation. ↩

  4. Asao B. Inoue. 2019. “Sample Charter for Compassion” in Labor-Based Grading Contracts: Building Equity and Inclusion in the Compassionate Writing Classroom. ↩

  5. Scott Freeman, Sarah L. Eddy, Miles McDonough, Michelle K. Smith, Nnadozie Okoroafor, Hannah Jordt, and Mary Pat Wenderoth. 2014. Active learning increases student performance in science, engineering, and mathematics. ↩

Explore CSE 163

  • Staff - All the teaching and learning assistants.
  • Style Guide - Python style conventions for this course.