I have three main goals for you in this class. I want to help you improve your independence as a programmer and your ability to write high quality code, and I want you to learn to place the human beings affected by your software at the center of your design and implementation work. Pursuing these goals involves the usual academic emphasis on concepts and vocabulary that you need to learn through study and experimentation. But it also involves lots of practice with the tools of the trade and lots of effort to develop good habits and discard bad ones. Therefore, our in-class discussions will focus on the nature of high-quality code, on how our software affects a variety of people, and on the techniques and habits that best serve the production of good code. We will also use discussion time for code reviews (see below) to help you revise your work to improve it.
I recommend that you do the up-front work required (with guidance from some first-week lab exercises) to set up your own computer for doing the work for this class. Working on your own computer is convenient, of course, but it also gives you the experience of setting up, customizing, and maintaining your own development environment. This experience is empowering, and will give you an important skill set for future professional software development you may do. That said, you are also always welcome to work on the computers in the labs on the third floor of Olin.
Your first task for the term is to make sure your computer is ready to support your CS257 work. See the Week 1 list of tasks and assignments for the course.
Windows, macOS, and Linux computers are all fine for the work we're going to be doing.
If you have any concerns about what computer you plan to use for this class, please contact me early in the term so we can discuss your thoughts.
This class will be in person after a long all-online year last year. It's going to be great to see you all in 3 dimensions this term!
That said, by teaching CS257 twice last year, I learned a lot about how to make it work well online. And many of the techniques I was forced into by circumstances turned out to be quite effective. So this term, I'm asking myself this question: which learning activities are most valuable and most important when done together in person, and which activities can be done just as productively outside of class?
With that in mind, here's the rough structure for the course.
(Here are the times and Zoom link.)
I love talking with you, whether it’s about class content or life as a programmer or tech new & ethics or your personal programming project or your search for internships or Carleton history or a good movie you saw recently or whatever. Really. Conversations with you are the main reason I keep doing this job instead of going out into the software industry.
This thing called "office hours" should probably be called "Jeff's personal invitation to you to come talk". I set aside a few hours per week when I promise to be available for conversation. I'm often available at other times, too, but it depends on what meetings I have to go to, what deadlines I'm working under, etc. So my official office hours are a way for me to clear my schedule for you.
Last year, I thought Zoom office hours worked really well. They enabled students to get quick answers conveniently, and I saw a larger number of students in office hours than I would normally see in person. So I'm going hold office hours by sitting in my office (Olin 301A) and also firing up Zoom, which will enable you to choose whether you want to talk to me in person or online.
If you’re stuck or confused or just have a question you’re having trouble answering via the internet or experimentation, here are some things you can do.
We will take readings from a variety of sources. Enough of the readings will come from one book that I have asked you to purchase it: Don't Make Me Think, Revisited, 3e, by Steve Krug. This book is short, fun to read, and reasonably cheap. It's also packed with ideas that programmers (especially but not exclusively web developers) should think about. You'll get lots of good advice here, plus some advice you disagree with. The disagreement is natural, and the discussion matters.
For several programming and design assignments during this term, we will have code reviews,. We will study each other's code and designs ahead of time, and then spend a small-group meeting talking about the strengths and weaknesses of what the teams have done, as well as alternative ways they might better achieve their goals.
Code reviews are one of the most efficient and powerful tools I know of for improving your software, but of course most people feel a fair amount of apprehension at the idea of discussing their code in detail in front of other people. Thus, it's essential that each participant in a code review show respect, prepare thoroughly, and offer both praise and constructive criticism. Code reviews get easier over time, so we'll do a lot of them.
Your grade will be based on your performance on a variety of assignments, and and on your participation in the code reviews. The assignments will include some writing and several programming assignments. There will be no exams.
Though the precise weighting of the assignments in your grade will depend on the exact nature of each assignment (which I won't determine until the assignment is written and posted online), a good estimate will be the number of days I give you between the last assignment and the current assignment. So if there's a two-week gap, that assignment will be worth approximately 20% of your grade in a ten-week term (with the caveat that I don't count midterm Saturday through Monday as days—I intend for you to have time to rest and catch up on midterm weekend).
Late homework will receive 25% reduction of score during the first 24 hours after the homework was due, and will receive a score of 0 after that. Consult me at least 24 hours before an assignment is due if you have extraordinary circumstances preventing you from handing in your work on time. In real emergencies, contact me as soon as you are able.
Carleton has an Academic Integrity policy. Sometimes when you're programming, it can be tricky to determine whether you're adhering to this policy. Can you take two lines of code from a Stack Overflow post or somebody's tech blog? How about ten lines? etc.
The short answer is that if you use code from a source other than your own head (or your partner's head), you should provide a brief citation in your code. This will typically be a short sentence explaining the source of the code plus a link. The longer answer gets into questions like "just how much code borrowing is too much in an academic context?" and "if I use an example from Python's official documentation, do I have to cite it?" and "if I start with somebody else's function from online but then rewrite some of it and add a bunch of my own code, have I used their code or not?" etc.
If you're uncertain, talk to me.
I may reorder some things along the way, but the schedule will look more or less like this: