Coursework will take place in several different modalities: Reading, Discussion, Blogs, Practice, Projects, and a Final Project. Assessment is outlined in Grades & Grading.
You are expected to do all the assigned reading for a given week before class. The reading includes everything in the course schedule as well as all the blog posts made since the previous class. I have done my best to keep the reading short and pointed enough to keep it manageable. (For those of you who have taken a class with me before, you understand what a struggle this is for me.) Do the reading carefully, give it some time, don’t worry so much about mastery—but do worry about engagement.
So that we may have good discussions, you are expected to come with questions, both clarifying (“I don’t understand x.”) and critical (“What do we make of x?”). Beyond the matter of questions, you are expected to be an active participant in class discussions. In seminar, this will mean being responsible to the project of helping us all understand the reading, concepts, and experiences at hand better or differently. In lab, this will mean active posing of questions, and active answering of any socratic-style questioning I may throw at you. On Slack, this will mean participating in discussions and responding to questions.
Your primary writing project this semester will be your blog. Every week, you are expected to write two short (~300–500 words) posts. These posts will break down as follows: one will be engaged with the reading due for seminar that week; the other will be a reflection on the lab (coding/practice) activities of the past week.
The reading post may consist of any of the typical ways one engages with theory in the humanities: a careful explication of a particularly difficult or interesting passage; a set of questions that arise from your reading; a specification of what you don’t understand, along with some ideas about what’s at stake in that failure to understand; an elaboration of a connection between this reading and something else; a development of, or disagreement with, something one of your colleagues wrote.
The practice post should be a bit more autobiographical. Tell us about what you learned, what you felt like you didn’t learn, what it felt like to write this code, what was frustrating, what was exuberating, and so on. Document your process of learning to code and your coding practice.
A few further requirements: 1. Both blog posts are due every week except the first and last of the semester. 2. Blog posts are due not later than midnight on the day before the relevant class. 3. Reading blog posts are meant to be prospective: they account for the reading that is due in the following class. Practice blog posts are meant to be retrospective, reflecting on your process from the previous week. 4. They need not be overly formal, but they should communicate something of substance to the other students in the class (who are your explicit audience). 5. Every student must read every student’s blog, every week. 6. Every post must include an explicit and linked reference to another student’s blog post (from any point in time in the course; the sole exception to this requirement are the first three blog posts of the semester—not your first three, the first three, from any student).
These requirements will serve as initial specs for blog posts: 1. Minimum word count: 300 words. 2. They must incldue a link to another student’s post. 3. They must demonstrate substantial engagement with the material as specified above. 4. They must be on time.
Once this semester, you and a partner will be responsible for writing a “week-in-review” of our seminar. This should be a critical, analytical, synthetic, and evaluative account of the theoretical thinking we got done as a group in a given week. It should be relatively lengthy, it should be collaboratively coauthored, and it should engage everybody’s participation on the blog and in the seminar room. In the week in which you write your week in review, you are expected to remain, if not actually silent, then at least substantially reserved in the seminar room to observe the conversation that is taking place.
Scott will produce the first several weeks-in-review as models.
Weeks-in-review are due not later than midnight the day before the following class.
Especially at the beginning of the course, as we get the basics of coding worked out, I will provide very small practice projects, which I will call “dailies.” These are meant to be basic exercises to help you internalize the conceptual and practical aspects of coding. There will be up to five (yes, five) practice projects in a given week (actually, there may be more, but completing five of 6 or 7 will count as doing all the dailies for that week). They are meant to be brief, and meant to be done a little bit every day. This is because (and I know this firsthand) if you try to do all your coding at once, it will go badly for you: you will have to look up all the things you had at your fingertips by the end of the last coding binge. In this way (and a few others besides), learning a computer programming language (in this case, mostly JavaScript) is not unlike learning a natural language, nor is it unlike learning to play an instrument. Two hours of work spaced out over a week in 20-minute chunks will conduce to learning much more than a single two-hour block of binge-coding.
Dailies are not due at a specific time, but again, cramming dailies in at the end of the semester will go very, very badly for you.
(To aid in this, I will attempt to schedule coding “meetups,” either in State 029 or somewhere else convenient, where we can all help each other work through )
Over the course of the semester, you will have four larger projects due: Sketchy Sketchy (p5.js, due in week 7), Makey Makey (Speculative Design, due in week 9), Mocky Mocky (Analytical Prototype, due in 11), and Tweety Tweety (Twitter Bot, due in week 13). (Nota bene: This is subject to change.)
Preferably in groups, but possibly by yourself, you will develop, specify, and execute a final project. This will almost certainly not be a fully-functioning thing, but may include a design document and functioning prototype. The details of this will be TBD, depending upon student interest, the learning curve of the room, technical capacity, and perhaps the direction of the wind. This final project will be significantly less work than a traditional graduate seminar paper (which, for the record, I take to be: substantial original research leading to 20–25pp. of scholarly writing). This is closer to a conference presentation, or the equivalent of 8–10pp. of scholarly writing that is less thoroughly researched.
All of the grading this semester will be “spec grading.” Which is to say, for each item of work (discussion, blog post, practice, projects, final) there will be a specification. You will either pass or fail that item, based on its specifications. Some of these specs will be worked out collaboratively early in the semester (discussion, blog posts), some of them will be set by me (practice and projects), and some of them will be your responsibility, in consultation with me (final project).
We will work on this together, but effectively, the way to get an A in the class is to meet all the specs. An A- will mean that you’ve missed some small number of specs. A B+ will mean missing a larger number of specs, and so far on down the line. Please be aware that, generally speaking, the minimum passing grade for graduate coursework at Wayne State is a B (graduate students must maintain a 3.0 or better to remain in good standing).
While this class is not pass-fail, what spec grading means is that the individual assignments are. Does the assignment meet the spec? If so, yay! If not, whoops! Then again, almost all of the time, the spec will be crystal clear: no questions or ambiguities.
To pass this class, students must: * Complete no fewer than 12 satisfactory blog posts (2 per week for 7 weeks out of the semester). * Complete one week-in-review with another student. * Complete no fewer than 80% of Dailies to spec. (Dailies are not due at a particular time, but they must be turned in.) * Complete all major projects (Sketchy Sketchy, Makey Makey, Mocky Mocky, Tweety Tweety) to minimum spec. * Complete a final project, individually or in collaboration with other students.
As noted above, these minimum passing requirements will earn you a B in the course. Students who do not complete the minimum passing requirements must negotiate with Scott for a grade that falls below a B, including preparation of a detailed self-assessment of performance in the course and rationale for said below-B grade.
To receive an A in this class, students must: * Complete no fewer than 18 satisfactory blog posts (2 per week for 10 weeks out of the semester). * Complete one week-in-review with another student. * Complete 100% of Dailies to spec. * Complete all major projects to complete spec. * Complete a final project, individually or in collaboration with other students, that demonstrates excellence, in Scott’s judgment.
To receive an A- in this class, students must: * Complete no fewer than 16 satisfactory blog posts (2 per week for 9 weeks out of the semester). * Complete one week-in-review with another student. * Complete 90% of Dailies to spec. * Complete all major projects to complete spec. * Complete a final project, individually or in collaboration with other students.
To receive a B+ in this class, students must: * Complete no fewer than 14 satisfactory blog posts (2 per week for 8 weeks out of the semester). * Complete one week-in-review with another student. * Complete 85% of Dailies to spec. * Complete all major projects to minimum spec. * Complete a final project, individually or in collaboration with other students.
Scott reserves the right to bump students from one grade category to a higher one based on ineffable factors like engagement, excellence, and so on. You will never be bumped lower.
If you fail to meet all criteria in a category, you will not attain that grade, but the highest grade in which you have met all criteria.