CSCI 40: Syllabus
Course purpose
This is an introduction to computing for people who have never programmed before. The organizing idea is a hacker’s favorite: automate the boring stuff. Nearly every tool we learn exists to make a computer do a tedious task for us, such as renaming a thousand files, collecting information from a website, answering a question from a pile of documents, or serving a page to the world.
We start on the web with HTML and CSS, spend most of the term on Python, and finish by building web applications backed by a database. Along the way, you will use git, GitHub, automated tests, and large language models. The larger goal is to learn how programmers break a vague task into small steps, test each step, and find their way forward when something fails.
By the end of the course, you should be able to:
- build and publish a clear, accessible webpage with HTML and CSS;
- write Python programs that automate work with files, websites, and text;
- use tests, error messages, and a debugger to locate and fix problems;
- track and share a project with
gitand GitHub; - build a small web application that stores and retrieves data; and
- read unfamiliar code, change it carefully, and explain how it works.
Course materials are adapted from Mike Izbicki’s CSCI 040. Much of the material is his, reorganized here and lightly rewritten.
Prerequisites: None. You do not need any prior programming experience. The course is designed for beginners, and it fulfills the CMC math general education requirement. Programming takes steady practice, so the weekly rhythm below matters more than any knowledge you bring on the first day. There are no exams.
Meetings, resources, and communication
We meet Mondays and Wednesdays from 1:15 to 2:30pm in Robert Day 126. My office hours are Tuesdays from 1:00 to 4:00pm in Adams Hall 213. There is no separate lab section; lab work happens during our class meetings and on your own time.
There is nothing to buy for this course. Each topic has a reading on this site. The two references we use most are Shay Howe’s Learn to Code HTML & CSS and Al Sweigart’s Automate the Boring Stuff with Python. You can step through Python code at pythontutor.com, and I recommend keeping a printed Python cheat sheet nearby when you code.
You submit assignments and receive grades on Gradescope. Please post course questions on the class Discord rather than emailing. Public questions help the whole class, and technical questions are easier to answer when we can see the error message and a small relevant piece of code. Please do not post a complete assignment solution.
The weekly rhythm
CMC’s workload standard for a one-unit course is nine hours each week, including time in class. A typical week in this course should look like this:
| Activity | Typical time |
|---|---|
| Attend both class meetings and participate | 2.5 hours |
| Read before class and try the examples | 1.5 hours |
| Work on labs and projects across several days | 4 hours |
| Practice quiz problems and review | 1 hour |
| Total | 9 hours |
Project weeks may shift the balance, but the total is a useful planning target. Read before the first class meeting on a topic, attend both meetings, and begin each assignment on your own well before it is due. Work for a while, leave it, and return on another day before asking for help. Repeated effort over several days strengthens the neural pathways involved in recall and problem solving. It also turns a confusing error into a useful question you can bring to class, office hours, or Discord.
Grading
You earn points by completing labs, quizzes, and projects. Assignments use a roughly power-of-two scale, so larger builds are worth more than short exercises. The percentages below are planning estimates; the points posted on Gradescope determine the exact totals.
| Category | Approximate weight | What it measures |
|---|---|---|
| Labs | 20% | Focused practice with immediate automated feedback |
| Quizzes | 40% | Independent understanding of the week’s skills |
| Projects | 40% | Combining several skills in a substantial program |
Labs. Most labs are Python files with automated tests, called doctests. Run the tests, fix what fails, and push your code to GitHub, where the same tests run again. Keep working and resubmitting until every test passes and the lab earns 100%.
Quizzes. Quizzes are weekly, open-note, and completed on paper without electronic devices. Each week has a practice bank linked from the schedule, and we work through many of those problems together. The graded quiz is a short selection of the same kinds of problems. A low score on one quiz is recoverable because there are many small quizzes instead of a few high-stakes exams.
Projects. Every two or three weeks, you will build something that you can put on GitHub, such as a webpage, a web scraper, a small language model, or a social web application. Projects let you choose which optional tasks to complete, and many of those tasks offer extra credit. It is possible to finish the course above 100%.
The caveat task. Once during the term, you must complete one nontechnical reading or viewing that introduces part of hacker culture. It does not add points to your numerical score, but leaving it incomplete lowers the final grade by one full letter, such as an A- to a B-. Options include watching WarGames, Citizenfour, or Zero Days, and reading Mike Izbicki’s essay on programmer English. The Gradescope assignment will give the due date and explain how to record completion. Contact me if you need an alternative option.
Your percentage determines your letter grade. The highest threshold you meet determines the grade:
| Grade | A | A- | B+ | B | B- | C+ | C | C- | D+ | D | D- | F |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Minimum percentage | 95 | 90 | 87 | 83 | 80 | 77 | 73 | 70 | 67 | 63 | 60 | 0 |
Late work and missed quizzes
You have a 48-hour, no-questions-asked late bank for the semester. Every hour that a take-home assignment is late comes from the same 48-hour total, so you may use the bank on one assignment or divide it across several. Gradescope timestamps determine the elapsed time, and you do not need to email me before using the bank. The bank applies to labs, projects, and the caveat task, not to in-class quizzes. After the bank is exhausted, late work is not accepted unless you have an accommodation or we arranged an extension. If illness, an emergency, a religious observance, or college travel affects you beyond the bank, contact me as soon as reasonably possible.
If you must miss a quiz for one of those reasons, contact me as soon as reasonably possible so that we can arrange a makeup or an equivalent assessment.
Collaboration and large language models
You are encouraged to discuss labs and projects with other students. You may talk through an approach, compare program output, and look together at the small part of the code needed to locate a bug. Do not copy a completed solution or submit code written by someone else. Type your own code, write your own explanations, and make sure you can explain every part of what you submit.
LLMs are useful programming tools, and we will study them directly near the end of the course. You may use one to explain an error message, clarify syntax, suggest test cases, or discuss an approach after you have tried the problem yourself. Do not submit code or prose from an LLM unless you understand it and have tested it. Early exercises are deliberately small enough to do without generated solutions; completing that practice yourself prepares you for later work that requires combining many ideas.
Academic accommodations
I have tried to make this course as accessible as possible, and we will discuss accessible software design in class. If you have a Letter of Accommodation, please contact me as early in the semester as possible. If you do not have a letter and believe you may be eligible, please contact Accessibility Services at accessibilityservices@cmc.edu. I want you to have a fair opportunity to learn and demonstrate what you know.