Syllabus


The House of Computing

Let's imagine that computing is a house, maybe one that your parents lived in, maybe one that your grandparents lived in as well. This house was built quite a long time ago, somewhere in the 1940s, and has been lived in by many, many people since. There's a foundation that's been built a few times, there's many, many floors, there's lots of furniture and decoration, some that's stayed around since the house was built! We're going to go exploring through this house! We'll start on the "ground floor", learning about binary numbering systems and a few data encoding schemes, and then work our way up a few floors, through operators, assembly, caches, and memory. These floors, quite literally, build upon each other! Each floor serves as a foundation, as a necessary supporting mechanism, for floors that stand on top of it. In 14x, you perused one of the upper floors and gained an understanding of Java, that's where we'll end this quarter.

Hopefully after we've traversed a few floors, you'll have a much better idea of the foundation that languages like Java sit on, and what keeps that foundation from collapsing. As we go through floor by floor, we'll look at the architecture, decorations and furniture of the floor that we're on, I'll give some history of who's lived here in the past, and we'll discuss why things look the way that they do. We'll go by some features that have aged really well and others that have gotten dingy (or downright unsafe) with time. You might want to know more about some space that we're in; questions like "What's that over there?" and "Why is this like that?" are valid and encouraged!

You might find yourself drawn to staying on one floor or another; maybe we go through a space that you'll want to make into part of your career! Just note that careers and interests change over time. Some of you (especially those in EE) might want to go deeper than the floor that we start on (binary numbering), and might use the understandings that you've developed in this course to check out , , , or . Some of you might want to explore more in spaces that we visited, but didn't linger in for long, like , , or , Some of you might miss the spring (or winter, or fall) breeze that you felt sitting in floors higher up than where we'll be in 351. You might start missing what it felt like to look down at the earth from so high up and watch the details blur together. If this course only makes you feel nostalgic for higher floors, that's ok! We won't be offended, we just ask that you try to keep your heart open to things that might pique your interest, and ask for help when you need it.

Regardless of your interests, many of you might want to remodel some part of this house. In 14x, you learned about existing computing structures, in 351 you'll learn how to improve the structures themselves. Maybe you want to add some more windows to let the morning sun shine across new wood floors. Maybe you want to add balconies, or create rooms specifically for things that you really enjoy. Maybe you want to break down walls, and add space for more people to fit in the house of computing. Just note, if you plan on remodeling, it's critically important to know the existing structure, why features were created in the first place, what walls might be load bearing, and so on, so you can ensure the entire house doesn't come crashing down when you start swinging a sledgehammer. You'll need both technical know-how, and socio-technical understanding (that is, an understanding of interactions between technology and society) to be successful! We'll look to give you both in this course. We wholeheartedly acknowledge that the house of computing isn't perfect, but it's a space that so many of us call home, regardless of what floor we live on.

Even if you don't plan on remodeling some part of this house, you should understand why this house, as it stands now, doesn't work for everyone, and that many have been explicitly blocked from entering this space, let alone living in it. Even if you enjoy every room that we explore, antique charm and all, you should understand that some stylistic choices made decades ago, weren't made with everyone in mind. Some spaces remain inaccessible to many, only allowing for some ways of movement (sets of stairs, for instance, without accessible alternatives). Computing and technology are used for many purposes. Brazilian educator Paulo Freire, for instance, noted that those that seek to oppress others "...are using science and technology as unquestionably powerful instruments for...the maintenance of the oppressive order through manipulation and repression" (Pedagogy of the Oppressed, page 60). Even if you don't plan on spending your career remodeling, we hope that you'll try to use computing in a way that helps people, rather than manipulation and repression! Regardless of what you decide to do with the knowledge you gain in this course, our only ask is that you try to develop an understanding of who you are while you learn this material, so you can decide what requires your attention.



Course Themes

The course has three principal themes:

  • Encoding: How different human representations of data (numbers, strings, addresses) are encoded in memory, how existing encodings reflect the norms and priorities at the time of their creation, and how designer norms are encoded in technical structures.
  • Translation: How high-level languages are translated into the basic instructions embodied in process hardware with a particular focus on C and Java, and what's prioritized in this translation process.
  • Organization: How computers organize the order of their computations, keep track of progress in large programs, and provide the illusion of multiple processes executing in parallel.


Course Objectives

At the end of this course, you should be able to:

  • understand the multi-step process by which a high-level program becomes a stream of instructions executed by a processor;
  • know what a pointer is and how to use it in manipulating complex data structures;
  • be familiar enough with assembly programming (on x86-64) to write simple pieces of code and understand how it maps to high-level languages (and vice-versa);
  • understand the basic organization and parameters of memory hierarchy and its importance for system performance;
  • be able to explain the role of an operating system;
  • know how Java fundamentally differs from C;
  • identify the design priorities present in technical systems, and how they relate to historical context


Course Syllabus

We're going to cover a few spaces:

  • First Floor: Data Representation
    • Memory and data representation
    • Number representation for integers and floats
  • Second Floor: Instructions, C, Data Structures
    • Machine code and the C programming language
    • x86-64 assembly language
    • Procedures and stacks
    • Arrays and other data structures
  • Third Floor: Memory
    • Memory and caches
    • Operating system process model
    • Virtual memory
    • Memory allocation
  • Forth Floor: Returning to Java
    • Implementation of high-level languages (e.g. Java)

An important note: it's much more important that you come away with an understanding of how different floors fit together and how we could translate between them. For instance, how Java could be translated into C, C into assembly, and assembly into binary.



Course Components

The course consists of the following elements:

  • Pre-Lecture Reading: The main technical material will be introduced via interactive readings and check-in questions on the platform. These should be completed before engaging with lecture material. Pre-lecture readings are due at 10:00am PDT of the corresponding lecture day.
  • Lectures: There will be 28 lectures, socio-technical content will be primarily presented during lecture. Synchronous attendance is both highly encouraged and good for your learning! We'll post recordings afterwards, but the in-person interaction, as well as learning collaboratively with a group, should make this course easier. If you aren't finding attending lecture valuable, do let us know! In-person,email, and are all encouraged.
  • Online Assignments (Homework): There are approximately 23 online homework assignments, one roughly every lecture. These are intended to solidify the lecture concepts and are generally due two lectures after being assigned.
  • Reading: There will be corresponding optional readings from the course textbook that correspond to lecture topics. Note: We will be using the (North American) 3rd edition. (list of changes from 2nd edition 2011, Errata) There are electronic versions available for sale or rent for $34.99 from the UW Bookstore. Additionally, you may find a good C programming language reference quite useful. Examples are Kernighan and Ritchie, The C Programming Language, 2nd edition and Harbison and Steele, C: A Reference Manual, 5th edition.
  • Programming Assignments (Labs): There are 6 total labs, due roughly every other week. All the undergraduate lab machines (and the CSE VM) will have access to the necessary tools. We will use these assignments to reinforce key concepts and will strive to have them be as practical as possible.
  • Unit Summaries: For 21su, instead of two exams, we will have three "Unit Summaries" that are meant to replace the reviewing, summarizing, and reflecting that studying for exams provides. These will be take-home assignments that will be due at three different points in the quarter. More information will be provided about these later.
  • Sections: There will be one section meeting per week. Section will provide additional practice with the course material and sometimes introduce new topics.

We'd like for the workload for this course to be around 3 hours per credit hour (that is, 9-12 hours per week, outside of 3 hours of lecture). If this isn't true for you, don't suffer in silence! Reach out, either in-person, through the course email, or through ), and let us know which parts of the course are taking too much time.

Learning science advocates and designers of this course note that successful learners tend to spend a few hours per day on their course learning, rather than a entire days at a time, or so-called "all-nighters" (which are generally terrible for learning). The world outside of academia generally works in consistent time blocks (for instance, a 9-5 workday) for this reason; cramming material into a short time frame isn't sustainable for most folks. Also, if you start early (working a few hours a day), you'll have more time to ask questions (and we'll have more time to answer them) when issues arise.


Policies


Inclusion

You have a right to a learning environment that feels safe, where you are treated with respect and feel that you can contribute ideas constructively. Put another way, you have the right to an inclusive learning environment. We desperately want every student to feel they have a healthy learning environment in 351. At any point, if you feel excluded, disrespectful, uncomfortable, or that your right to an inclusive and safe learning environment has been denied, in any way, by students or staff, please let us know! We'll do what we can to help.

Notably, we're still in a pandemic! Many of us (staff included!) have experienced unforeseen and extenuating circumstances that have required attention away from our work. Some of you might be caring for children or family members, some of you might be in different time zones, some of you might be in the midst of emotional turmoil from any number of events of the past year. Please, let us know what we can do to help. Some things are just more important than this course; we certainly understand that.

For issues that arise, you can contact any member of the course staff, either at office hours, via email, or in a private Ed Discussion post. Knowing sooner (rather than later) gives us more options for resolving these issues, and (most likely) lets us offer help faster! If you aren't comfortable talking to staff members or the course instructor, you can send or contact the .


Grading Policies

Your final grade will be a reflection of your level of mastery of the topics and material covered throughout the quarter. The following assessments will be used to compute your grade. Each assessment is evaluated for some combination of completeness and/or correctness.

  • Lecture Readings (~5%): single attempt, completeness
  • Homework (~20%): unlimited attempts, completeness and correctness
  • Labs and Reflections (~40%): last submission graded, completeness and correctness
  • Section Worksheets (~5%): 100%, free. It's your responsibility to judge whether you need the review or not! Err on the side of coming to section and doing the worksheets, humans are bad at assessing their own knowledge.
  • Unit Summaries (~30%): single submission, completeness, correctness, and clarity of design

Extra Credit (Labs)

We will keep track of any extra credit items you complete on labs. You won't see these affecting your grades for individual labs, but they will be accumulated over the course and will be used to bump up borderline grades at the end of the quarter.

The bottom line is that these will likely have NO effect on your overall grade (and only a small amount if you are on a borderline). You want to be sure you have completed the non-extra credit portions of the lab in perfect form before attempting any extra credit. They are meant to be fun extensions to the assignments, so if you complete some extra credit it *may* positively impact your overall grade.

Extra Credit (Study Guides)

We will keep track of any extra credit earned on study guides. Extra credit may be earned by demonstrating exceptional learning and mastery of the material covered by the study guide assignment. As with extra credit earned on labs, this will likely have little to no effect on your overall grade, and is primarily used to adjust up a borderline grade.



Assignment Policies

All assignment submission deadlines have a 59 second grace period. This means that an assignment turned in at 8:00:59pm is on-time, and an assignment turned in at 8:01:00pm is late. Note that online submissions can be fickle, so we highly recommend trying to make a submission well before the deadline and not "counting on" the grace period when working on an assignment.

  • Online assignments (homework) are autograded and late submissions are NOT allowed. You are allowed an unlimited number of attempts for each quiz and you will receive credit for every question that you answer correctly. Homework assignments are due at 8pm PDT on the date indicated in the assignment lesson on Ed.
  • Pre-Lecture readings are single-submission and are to be completed before lectures. Pre-lecture readings are due at 10:00am PDT of the corresponding lecture day.
  • Programming assignments (labs) are submitted by uploading files to Gradescope assignments. Late lab submissions are subject to the late day policy described below. Note that you will sometimes need to submit the same file(s) to the separate extra credit assignments if you would like to have those graded. Labs are graded by a combination of grading scripts and TAs. Programming Lab due dates are found on the individual lab assignment webpages, linked from the course schedule.
  • Unit Summaries are "take-home" and must be completed within the allotted window of time. See the schedule for dates. Unit Summaries are graded by the staff.

Note that, in general, assignments are due at 8pm PDT.


Late Day Policy (Labs, Unit Summaries)

While turning in assignments on time is the best way to stay on top of the material and on schedule, we realize that this is not a usual quarter and we all may face unexpected challenges. This quarter we are giving each student a total of 7 late days for the entirety of the quarter to utilize on labs and unit summaries (NOT homeworks) should the need arise. Please do not use these casually, as they are meant to provide a buffer to help you get over unexpected events.

  • A late day is defined as the 24 hour period after an assignment's due date: num_late_days = ceil(hours_late / 24).
    • An exception is made for weekends, which count as a single late day. That is, if an assignment is due at 8pm on Friday, submitting before Sunday at 8pm counts as using only ONE late day (submitting by 8pm on Monday would count as using TWO late days). Observed holidays (i.e. July 4th is observed on the 5th) will be considered part of the previous weekend.
  • All lab and unit summary submissions will close two late days past the original due date. (e.g. If a lab or unit summary is due on a Friday, the last day it will be accepted is Monday at 11:59pm.) No labs or unit summaries will be accepted after two late days past the original due date.
  • Note that all assignments are due on Sunday, August 22, at 8pm, regardless of remaining late days. We can't accept work past this date, as we have a UW deadline for final grade submission on Tuesday, August 24.
  • There is no bonus for having leftover late days at the end of the quarter.

What happens if I have used up all my late days? You may still submit any lab or unit summary up to two late days past the original due date (except Lab 5 and Unit Summary 4 as noted above). However, for each late day you use that exceeds the total late days given to you, you will be penalized 20% of your score on one of the items that you submitted late. The penalties will be applied in a manner that maximizes your overall grade (i.e. minimizes your total penalties).


Solutions and Regrades

  • Homework: Solutions will not be provided. Since you are allowed multiple attempts, make sure to go to office hours or talk to classmates if you feel stuck.
  • Labs: Solutions will not be provided. Most labs will include testing tools to allow you to evaluate whether or not your solution is likely working. Your lab grades will provide comments for any portion deemed incorrect.

Learning from our mistakes is often one of the most memorable ways of learning and the staff is not immune from making them, too! If you have a question about a graded assignment, please don't hesitate to ask a staff member about it during their office hours or via private post on Ed Discussion. If, after discussing your question, you feel that your work was misunderstood or otherwise should be looked at again to see if an appropriate grade was given, we ask that you submit an electronic regrade request via the interface, which will open and close automatically. We'll only regrade the portion of the assignment that you feel deserves a regrade, and we won't take away points if we made a mistake.That said, regrades do take time. Please don't reach out "just to see if you can get more points", only submit regrade requests for assignments that you feel deserve it.

  • Homework regrades: These are autograded, but if you believe there might be an error in our answers, please email the instructor or make a private post on Ed Discussion.
  • Lab regrades: Make sure to include a short summary describing why your work should be looked at again.
  • Study Guide regrades: Details TBA. There will be a mechanism to resubmit/regrade tasks to demonstrate learning.


Collaboration

In general, we encourage collaboration, but not at the expense of your learning! We can learn a lot from working with each other and it can make the course more fun, but we also want to ensure that every student can get the maximum benefit from the material this course has to offer. Our goal is for every student to attain mastery of the material, so that they'll be prepared for subsequent courses, job interviews, and wherever the knowledge from this course might come in handy. We fully acknowledge that this course's collaboration policy does not, in any way, match policies around collaboration that you might experience in academia, industry, or, really anywhere else. Our preference would be to have so much more time to prepare this course so that we could have assignment on which it was literally impossible to cheat, as every student would contribute their own ideas and their own work. Alas, other parts of this course needed to change first. So, the collaboration policy that we summarize here is a relic that we're not thrilled with, but one that is necessary, given the current state of the course.

Encouraged Collaboration:

  • Homework: Collaboration and discussion is encouraged (find a homework group!), but you are responsible for understanding the solutions on your own.
  • Labs: Collaboration should be restricted to high-level discussion (i.e., ideas only). A good rule of thumb is that you should never show your own code while helping another student (viewing their code is highly discouraged, as it often leads to problematic situations).

Prohibited Collaboration:

  • Coaching a friend to arrive at a solution by simply following your instructions (i.e., no thinking involved). For example, helping a friend write a program line-by-line, or having a friend "walk you through" their solution
  • Copying code from a similar course at another university or using solutions/code on the web, including GitHub and Chegg.
  • Communicating your solution with another student via electronic or non-electronic means.
  • Sharing code or solutions to assignments by copying, retyping, looking at, or supplying a copy of a file

If we find that you've broken our collaboration policy, you'll receive a zero, you'll likely receive a failing grade, and we may initiate a cheating case at the University level. In general, this is a whole lot of not fun for everyone involved, so, please, please, please, submit work that abides by our collaboration policy! If, by some chance, you've cheated, we have an amnesty policy: send an email to the instructor within 72 hours of your submission detailing what happened. You'll receive a zero for the assignment, but you'll be welcome to continue in the course without further penalty. More importantly, if you're stuck and you don't know what to do, ask for help! You'll learn, and we won't have to go through all the aches of cheating

If you aren't sure if something is cheating, send the instructor an email describing the situation and we will be happy to clarify it for you. For more information, you may consult the school's .



Disability Resources

The is a unit within the Division of Student Life and is dedicated to ensuring access and inclusion for all students with disabilities on the Seattle campus. They offer a wide range of services for students with disabilities that are individually designed and remove the need to reveal sensitive medical information to the course staff. If you have a medical need for extensions of exam times or assignment deadlines, these will only be granted through official documentation from DRS. Browse to to start the process as soon as possible to avoid delays.

You can refer to the university policies regarding for more information.



Religious Accommodations

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 . Accommodations must be requested within the first two weeks of this course using the .