!!! This is the W16 version of the course !!!

Click here to go to the current course homepage

This 1-credit seminar is designed to teach the essentials of using a computer effectively for EECS students. While the target audience is CS/CE/DS students, any student wishing to learn how to use their computer much more effectively is encouraged to join. Topics covered include shells, environment, scripting, Makefiles, compilers, debugging tools, and version control. The last month of the course will be open to student input for remaining useful topics to cover.


[+] Show older updates

Course Pre-Requisites

The only enforced pre-requisite for this course is ENGN 101/151 or EECS 182/183, however it is advised that students have either taken or are concurrently enrolled in EECS 280. A basic understanding of programming (if/else, for, while) and a passing familiarity with a compiler and command prompt is the only expected background.

Syllabus & Essential Info

Course Staff

Pat Pannuto @marcus-darden Max Smith David Snider Waleed Khan Matt Terwilliger Alex Chojnacki Mo Hussein
Pat Pannuto Marcus Darden Max Smith David Snider Waleed Khan Matt Terwilliger Alex Chojnacki Mo Hussein

Course Resources

Course Q&A / Forum – Piazza

Assignment Submission & Grades – Gradescope

To borrow a CSE laptop for the semester, contact Don Winsor at don@umich.edu.

For general issues, e-mail the course staff at c4cs-staff@umich.edu. For sensitive issues, please e-mail me directly at ppannuto@umich.edu.

Course Meeting Times and Locations

Section 003
1571 GGBL, Friday 1:30-2:30
Section 004
1571 GGBL, Friday 2:30-3:30
Section 005
1013 DOW, Friday 11:00-12:00

In general, you may attend any section, however if the classrooms become overfull, we will have to ask that you attend the section you are officially registered for.

Loading calendar...
Google Calendar link


As this is a new class, the syllabus is subject to change in response to feedback and class needs throughout the term.
Topic Lecture Materials
Week 1 1/8 Welcome to Computing for Computer Scientists
  • Course goals, philosophy, and background
  • Administrivia
  • What is a computer?
Slides Video

Homework 1 [pdf]

Homework 1 [tex]

Advanced Exercise 1 [pdf]

Advanced Exercise 1 [tex]

Week 2 1/15

Shells and environment, basic scripting

  • Unix history, especially in the context of tools
  • The job of a shell
  • $HOME, $PATH, etc
  • history, Ctrl-R, etc
  • .bashrc, alias, export
  • shell variables and functions
  • basic flow control

This week's lecture focused on “the job of a shell”, specifically how programs are launched. The lecture format is a bit of a “choose your own adventure” as students in class ask questions. The 11 and 1:30 lectures spent more time and detail on the window manager and 2:30 lecture went a little more in depth on the behavior of the shell and environment.

Lecture (11a-12p)

Lecture (1:30p-2:30p)

Lecture (2:30p-3:30p)

Note: The tool I used to capture my terminal input and output from the afternoon lectures was not the best, it is a little hard to read. I apologize for that, I will try to find something better for future weeks.

Homework 2 [pdf]

Homework 2 [tex]

Advanced Exercise 2 [pdf]

Advanced Exercise 2 [tex]

Solutions 2 [pdf]

Week 3 1/22



  • Origin and purpose
  • Diversity of editors
  • Text editor vs program that edits text
  • Why terminal-based text editors are still relevant
  • Why terminal-based text editors are not relevant anymore


  • A little on text editing without opening an editor
  • Basic operation of “the big two”
  • Semi-guided exploration of editor capabilities


  • Extending text-based editors: Deep integration with code
  • Extending text-based editors: Third-party additions
  • Extending IDEs: Recovering text-based editor interfaces

This week's lecture focused on “editors”. Lecture opened with an example of an editor most people do not often see or use, a hex editor, and demonstrated how we can edit compiled binaries directly to change their behavior. Then we played with one of the first text editors, ed. The homework explores how some of ed's interfaces live on today. From there we talked about the mental model of a software developer when editing software and how editors play into that. Finally, we closed lecture with a discussion on the distinction between text editors and source code editors, which of those are included in Integrated Development Environments (IDEs), and whether that is the right choice. The advanced homework explores how to bridge this gap in both directions, from source editor to IDE and from IDE with text editor to IDE with source editor.

Lecture (11a-12p)

Lecture (1:30p-2:30p)

Lecture (2:30p-3:30p)

I used two terminal windows to show things side-by-side during lecture. If you are reviewing the terminal output, I recommend opening both and scrolling in parallel.

Homework 3 [pdf]

Homework 3 [tex]

Advanced Exercise 3 [pdf]

Advanced Exercise 3 [tex]

Solutions 3 [pdf]

Week 4 1/29

Revision Control Basics & Git


  • What's version control?
  • Why is it important?
    • Thought Exercise: Why doesn’t everything have version control?
  • Today's VCS of choice: git
  • Git fundamentals
  • Advanced git highlights
  • The era of social coding


  • Intro tutorial to git
  • Setting up a class project with git
  • Basic usage and configuration


  • Rescuing repositories in bad states
  • Commit hooks

This week we introduced version control. We talked a little about what it means to be a version control system, what the fundamental primitives of version control are, and showed at the very end the powerful constructs you can build on version control.

We spent the bulk of lecture doing a deep dive on the basic operation git. We start by introducing the three major logical concepts in git, the working directory, the staging area, and the repository. Next we explore how the various commands move changesets or diffs between these three places.

The major commands we covered were status, add, reset, commit, checkout, and diff.

Lecture (11a-12p)

Lecture (2:30p-3:30p)

Homework 4 [pdf]

Homework 4 [tex] [png]

Advanced Exercise 4 [pdf]

Advanced Exercise 4 [tex]

– – –

Bonus Advanced [pdf]

Bonus Advanced [tex]

Solutions 4 [pdf]

Week 5 2/5

Shells II, Unix Tools & Philosophy


  • Lines of text as a universal interface
  • Examples of unix commands and command synthesis


  • Basics of regular expressions
  • Guided intro to some tools
  • Synthesizing tools into powerful queries


  • Shell scripting
  • (Basic) shell job control
  • Automated testing

This week opened with a recap of commmand that have been encountered by the course thus far. Stay tuned for a post about that coming soon.

The focus of lecture this week shifted a little to trying to learn how to learn about a new tool. Specifically, we started from the notion of, given that tr is a “cool command” that you should learn about, what are the effective ways to learn about how a tool behaves?

At the end of lecture, we explored how we can chain together individually simple commands to build powerful constructs. The homework explores this topic is a guided manner as well.

Lecture (11a-12p)

Lecture (2:30p-3:30p)

Combined list of commands encountered thus far

Homework 5 [pdf]

Homework 5 [tex] [png]

Advanced Exercise 5 [pdf]

Advanced Exercise 5 [tex]

Solutions 5 [pdf]

2/19: Minor corrections to the solutions.

Week 6 2/12

Build Systems


  • Conceptual model for a build system
  • HW2 script, what didn’t it do?
  • Basic operation of make
    • syntax, goals, targets, rules, variables (yours and make's)


  • Basic operation
  • Understanding goals and targets
  • Built-ins and implicit rules
    • Guided digging into how a tool works


  • gcc and make integration
  • Exploring alternative build systems

This week we focused on build systems- which sound crazy complicated, but are actually built realized by simple concepts like graphs and variables. In lecture, we started off by asking "What is a build system? Why do they matter? What do they help us do?"

In the simplest case, a build system allows you to save build or compilation commands to variable names like 'all_tests' or 'submit'. This saves us from trying to remember the gcc arguments for each type of executable or test we want to make or run.

In class, we focused on the 'make' program, which is a build system everyone should be familiar with from 280 and 281. We talked about the syntax of 'make' in terms of targets, dependencies, and rules, and demonstrated it's behavior with a quick example composed of shell scripts.

Lecture (11a-12p)

Lecture (2:30p-3:30p)

Homework 6 [pdf]

Homework 6 [tex]

Advanced Exercise 6 [pdf]

Advanced Exercise 6 [tex]

Solutions 6 [pdf]

Week 7 2/19

Debuggers I

Lecture (lecture notes)

  • (Midterm course evaluation feedback)
  • What a debugger (the tool) does
  • What a debugger (the tool) doesn’t do
  • What a debugger (a person) must do
  • How to reason about debugging a problem?
  • Open: Things that “can’t” be debugged?


  • Building a mental model for debugging
  • Introducing valgrind

This week we talked about debuggers, specifically the gdb debugging utility. This lecture is a little different as early labs in other EECS classes have already introduced gdb, so everyone should already have at least a passing familiarity with gdb. What we try to go through in lecture then is to understand the primitives that gdb provides – the way that gdb lets us examine and modify machine state – and how to stitch those primitives together to debug.

Said differently, recall that debugging is essentially a search problem: At the beginning you have a program starting to run with some inputs and at the end you have the final state with the incorrect outputs. Tracking down a bug requires finding when between a program's beginning and end things went from being correct to incorrect. A debugger, such as gdb, is a tool that lets you stop and examine any point in time between the beginning and end. It is up to you, however, to point the tool to the right points in time in order to identify where things went wrong.

If you were unable to attend lecture this week and are watching online, I think the afternoon lecture was slightly smoother this week and recommend that one.

Lecture (11a-12p)

Lecture (2:30p-3:30p)

Preliminary lecture notesmath.cinf.c

Homework 7 [pdf]

Homework 7 [tex]

Advanced Exercise 7 [pdf]

Advanced Exercise 7 [tex]

Solutions 7 [pdf]

Week 8 2/26

Optional Lecture: Building Basic Continuous Integration

Together as a group, we're going to do Advanced Exercise 5. The end result here is pretty awesome. Every time you commit some work, in the background, your code will automatically build, run all test cases, and run some static analysis (tools that help catch bugs without even writing tests!). When it's all done, it'll pop up a nice notification letting you know how things went.

This lecture was a little more intimate, in honor of spring break.

During class, we went through the thought process for how to approach and complete Advanced Exercise 5. Posted here is a cleaned up and commented version of the script we built in class.

Lecture (1:30p-2:30p)


No homework, enjoy break!
Spring Break
Week 9 3/11

Using Git Effectively


  • Understanding branches
  • Basic merging
  • “Expanding the triangle”
    • Push, fetch, pull
    • Remote branches and remotes as branches
  • Synchronizing work (+stashing)
  • Commit everything, branch often
  • Cleaning history: Rebasing, squashing


  • Thinking in git
  • Practice with merging, conflicts
  • Practice rewriting history


  • Using git to collaborate for real

This lecture digs into git, trying to understand what's going on underneath the hood. We introduce the concept of branching and show how it affects history. Next we introduce merging, which bring branches back together. Then we introduce the concept of remotes and show how remote repositories are really just the same thing as branches.

What we sadly did not quite have time to get to in class was the key git philosophy: commit everything and commit often. Some folks stuck around after the last lecture to go a little longer and talk through some of these ideas. The key thing is commit little pieces of progress. It is easy to get in a trap where you feel like you do not want to commit something until it is working. But if you only commit 1,000-line changes after you have everything, then you may as well not be using version control!

In the supplemental lecture, we introduced the concept of feature branches. The idea is that when you start working on something new, you can create a new branch for that feature. Since this branch is not yet part of the offical history, you should not feel bad about making lots of little commits as you get little pieces working. Once you get all of the way there, you can re-write history!

We also built up a small collection of tips and tricks to make working with git more enjoyable.

Lecture (11a-12p)

Lecture (2:30p-3:30p)

Supplemental Lecture (3:40-4:20p)

Preliminary Lecture NotesGit Niceties

Homework 9 [pdf]

Homework 9 [tex]

Advanced Exercise 9 [pdf]

Advanced Exercise 9 [tex]

Solutions 9 [pdf]

Week 10 3/18



  • What is profiling?
  • How to build a profiler?
  • How to use a profiler?
  • How to understand the results of a profiler?


  • Using gprof
  • Understanding profiling mechanics


  • Introducing gcov
  • Advanced metrics
  • Profile guided optimization

A lighter week this week, we talked about profiling.

Profilers are tools that help you understand where your code is spending its time. Profilers are not debugging tools. Your code needs to work and work as expected before a profiler will be useful. Profiling is the last step, optimization to help figure out how to improve your code.

In lecture, we went through an understanding of how to build a basic profiler from scratch, showing the key concepts of operation. In practice, modern profilers do more (check out the advanced homework for some examples of this). We ended lecture looking at how to use the gprof tool, a real-world profiler.

Lecture (11a-12p)

Lecture (2:30p-3:30p)

Preliminary Lecture Notes

March 21, 5PM: Updated to Revsion 1.1

Homework 10 [pdf]

Homework 10 [tex]

Advanced Exercise 10 [pdf]

Advanced Exercise 10 [tex]

Solutions 10 [pdf]

Nothing below here will be on the final exam
Week 11 3/25

Scripting without bash

“I'm too lazy to do all that by hand, so I just wrote a script to do it”How??

  • Accelerated intro to practical Python for the experienced programmer
  • Quick syntax overview
    • Functions and flow control
    • “Everything is an object”
  • I/O, user and files
    • Argument input
    • Runtime input
    • Finding / reading / writing files
  • Libraries are what makes it magic
    • For just about anything you want to do, someone on the Internet has written a thing that does it
    • Many are built-in
    • Many, many more are not
    • Understanding imports
    • Finding and using libraries: pip and PyPi

This week we talked about Python. We used an RPN calculator as an example to work through during lecture. Grab a copy of the code here.

In lecture, we started with rpn_basic.py, working through its operation and Python constructs. Then we slowly starting fixing bugs and adding features. The idea was to progress towards the features in rpn_class.py during lecture.

Beyond what we able to present in lecutre, the repository includes two more complete files, rpn_class.py which gives an example of how to make a Python class and rpn_kitchen_sink.py, a heavily-commented example that shows off many more advanced features. I encourage you to check these out when you have some time!

Lecture (11a-12p)

Lecture (2:30p-3:30p)

Preliminary Lecture NotesRPN Code

Homework 11 [pdf]

Homework 11 [tex]

Advanced Exercise 11 [pdf]

Advanced Exercise 11 [tex]

Advanced Exercise 11 Deadline Extended to Wed, 4/13 at 3PM

Week 12 4/1

How to best work on my machine?

  • Setting up a local environment
  • How to work remotely?

Lecture this week starts from the idea of a local environment and what that really means. It is not just setting up your machine for “development”, it is setting it up for C++ development, for iOS development, for web development. Each of these environments are unique, and while there are some common threads (editors, version control), ultimately each has some things that make it unique.

That idea brings us to the major topic, package managers. These are tools that help manage libraries, tools, building, distribution, or other things appropriate to the environment you are currently working in. Every environment has its own package management system. Ubuntu has apt, Python has pip, Ruby has gems, OS X has the App Store (it's a package manager, really!). In lecture we go over what a package manager has to do to achieve its goals and how it does it. Along the way we examine how package managers differ.

As some closing thoughts, we look at how the philosophy of a development environment is changing from the older C/C++ model of a global system development environment to project-specific environments. We introduce the idea of virtual environments, their purpose, and how different tools manage these concepts. Finally we briefly discuss how tools such as Vagrant recapture this virtual environment principle for development ecosystems that do not have it built-in.

Lecture (2:30p-3:30p)

Preliminary Lecture Notes

Homework 12 [pdf]

Homework 12 [tex]

Homework 12 Deadline Extended to Wed, 4/13 at 3PM

Advanced Exercise 12 [pdf]

Advanced Exercise 12 [tex]

Final Exam Monday April 4

We have several exam rooms. Please be sure you go to the right room.

Based on the first letter of your uniqname:

  • uniqnames beginning with a-f: AUD CHRYS
  • uniqnames beginning with g-l: 1571 GGBL
  • uniqnames beginning with m-n: 1017 DOW
  • uniqnames beginning with o-w: 1013 DOW
  • uniqnames beginning with x-z: 1010 DOW
  • Overflow and persons needing extra time: 1018 DOW

Practice Exam

Week 13 4/8

Digging into IDEs

  • Decomposing an IDE – all the same tools!
  • How to use IDEs effectively? How to get more effective because you use an IDE?

Lecture (2:30p-3:30p)

Homework 13 [pdf]

Homework 13 [tex]

Advanced Exercise 13 [pdf]

Advanced Exercise 13 [tex]

Week 14 4/15

11:00 – Mo: Security as a User

  • What kinds of things should I be doing to be secure?
  • Why are they important? What's happening under the hood?

1:30 – Alex: VPS / Containers / Etc

  • What is a virtual private server (VPS)?
  • What can I do with a VPS?
  • How do companies use VPSs?

2:30 – Matt: How does the Internet work?

  • Introduction to networking protocols/concepts (OSI model: IPv4/v6, Routing, NAT, DNS, DHCP, etc.)
  • What kinds of tools can inspect networks to understand how they're working (or diagnose and fix when they're failing?)

The 1:30 lecture this week starts off with our very own Marcus Darden winning this year's HKN Best Professor Award.

Congratulations Marcus!!

Lecture (11:00a-12:00p)

Lecture (1:30p-2:30p)

Lecture (2:30p-3:30p)

No homework, good luck on finals!

Attendance, Grading, and Homework

This course is graded on a straight scale, it will not be curved. Each component is graded independently and then combined into a final grade.

Final Grades

[3.67, 4.0]
[3.33, 3.67)
[3.0, 3.33)
[2.67, 3.0)
[2.33, 2.67)
[2.0, 2.33)
[1.67, 2.0)
[1.33, 1.67)
[1.0, 1.33)
(0.0, 1.0)

As example, a student with 19 attendance points, 16 homework points, 3 advanced exercise points, and a 95% on the final exam would receive a final grade of (3.67+3.33+4.0+.95*4.0) / 4.0 = 3.7, 3.7 > 3.67 → A.

Attendance (25%)

Attendance is required for this course. Each lecture will begin with a question from last week’s material. A correct answer is worth 2 points, an incorrect answer is worth 1 point, and no answer is worth 0 points. The week before spring break is optional with no attendance taken. The maximum possible attendance score is thus 13 x 2 = 26.

A+ (4.33) A (4.0) A- (3.67) B+ (3.33) B (3.0) B- (2.67) C+ (2.33) C (2.0) C- (1.67) D+ (1.33) D (1.0) F (0.0)
Attendance Points 24‑26 20‑23 18‑19 16‑17 14‑15 12‑13 10‑11 8‑9 6‑7 4‑5 2‑3 0‑1

Homeworks (25%)

There are 12 homeworks in the course. Homework is due by the beginning of the first lecture the week after it is assigned. Homeworks will be graded on a {0,1,2} scale:

0 points
No / very little effort
1 point
A solid effort, but not complete
2 points
Completed successfully

This is a 1 credit course and the homeworks are designed to be commensurate with that. The goal of the homeworks is to reinforce concepts introduced in lecture and to give hands-on experience working with tools.

An A student will have at least 18 total homework points (e.g. 6 1's and 6 2's).

A+ (4.33) A (4.0) A- (3.67) B+ (3.33) B (3.0) B- (2.67) C+ (2.33) C (2.0) C- (1.67) D+ (1.33) D (1.0) F (0.0)
Homework Points 22‑24 20‑21 18‑19 16‑17 14‑15 12‑13 10‑11 8‑9 6‑7 4‑5 2‑3 0‑1

Advanced Exercises (25%)

Each homework will have at least one advanced exercise option. The intention is to give a guided exploration of topics that people find most interesting. These advanced exercises will also be a little more time consuming, have a little less guidance, and require you to research and discover a little on your own. Over the course of the semester, you are expected to do at least three of the advanced exercises.

The advanced exercises are graded on a simple 0 or 1 system, either you did the whole thing or you did not. Some weeks may have multiple advanced exercise options, however you may only earn 1 advanced exercise point per week (though that shouldn’t stop you from doing more if you are interested!).

A+ (4.33) A (4.0) B (3.0) C (2.0) F (0.0)
Advanced Exercises Points 6+ 3‑5 2 1 0

Final Exam (25%)

The final exam will be cumulative over all of the whole term. We have a 90-minute time slot for the exam. This is a very broad course. The exam is not designed to be “tricky” or test the esoteric corners of things presented in lecture. A student who attended every lecture and completed all the homeworks will likely need minimal studying for this exam.

Useful Links / Resources

  • comp.lang.c FAQ: Next time you're bored, don't facebook, reddit, or google+; instead skim a section. It's really interesting material, presented in short, easy snippets
  • Stack Overflow: Got a problem? Try searching here instead of Google. Odds favor this site will be the first result anyway, and it's answers are much more complete, readable, and useful