ICS 45C / CSE 45C: Programming in C++ as a Second Language
Fall 2016
Course Reference

Instructor information

How best to contact me

I tend to be much easier to reach via email than any other way, so I would suggest using email to contact me under normal circumstances. As it turns out, I'm not in my office all that often, but I am connected online quite a lot.

When you write me an email, it's not a bad idea to be sure you're including enough contextual information in your email that I'll be able to answer the question: your name, your student ID#, and which course you're enrolled in are all good data points to include. Without things like this, it raises the likelihood that I won't understand the context of the question you're asking (e.g., "When is Project 1 due?" is a question that has a different answer in different courses of mine), which means we'll need an additional round trip to get the matter settled.

Office hours

I will be available on Tuesdays and Thursdays from 8:30-9:45pm in DBH 1431 — not my office, as it's in a building that will be locked during at least part of that time — during which I'm available to chat with you about whatever's on your mind.

Course staff

In addition to me, this course is staffed by a number of folks in a few different roles. They are listed below.

Teaching assistants

There are two teaching assistant(s), who will share the duties of attending the lab meetings, will serve as an additional source of assistance on your projects, and will be the primary point of contact with regard to the grading of the projects.


Additionally, we have two readers, who will be primarily tasked with grading projects.

Lab tutors

In addition to the TAs, the following lab tutors will also be staffing the labs at various times, specified further below.

Times and places


A lecture meets on Tuesdays and Thursdays from 5:00-6:20pm in HSLH 100A. Given the course's size, attendance is not graded, but we certainly recommend it. (Naturally, attendance is required on the days when exams are held, which are listed in the Schedule.)


This course has a number of discussion sections scheduled, meeting on various days of the week. Note that while these are listed in the schedule as discussions, we'll actually be using these as a sort of informal lab meeting, staffed by a combination of TAs and tutors. Like laptop-only lab sections in some of our other courses, the objective will be to offer as much one-on-one help as we can as you work on your projects. We're not planning direct classroom instruction, because, in our long experience, programming courses benefit much more from students having the ability to get their own specific issues addressed.

Discussions will begin meeting on Monday, September 29.

Days/Times Location TAs and/or Tutors
M 5:00pm-5:50pm MSTB 110 Sameera Ghayyur
Christopher Lew
M 6:00pm-6:50pm MSTB 110 Tiago Muck
Christopher Lew
Tu 11:00am-11:50am MSTB 110 Preston Ng
Tu 12:00pm-12:50pm MSTB 110 Sameera Ghayyur
F 2:00pm-2:50pm ICS 180 Tiago Muck

C++ requires an attention to detail that is uncharacteristically high, even for programming, so it will be handy to have a place you can go to get help; keep these on your calendar. You're free to come and go as you'd like within these times. While it's best that you attend the discussion you're enrolled in, you can feel free to attend others, provided that there is enough available seating; if more people show up than we have seats available, we'll require students not enrolled in the given section to leave, though we anticipate this will rarely, if ever, be a problem.

The discussions are not a required part of the course, and nothing will be graded in them this quarter, but attendance does offer some significant benefits:

Lab Meetings

Additional to the discussions, we're also offering some informal lab meetings, beginning on Wednesday, October 12. These are similar to the discussions — in the sense that a tutor will be available to answer questions about your work on your projects — though you will not enroll in them and they're not formally listed in the Schedule of Classes.

Times and locations are listed below:

TAs and/or Tutors
W 12:00-2:20pm
ICS2 110 (Kay Family Lab)
Rushabh Shah
Th 2:00-3:30pm
ICS2 162
Rushabh Shah
F 4:00-6:00pm
ICS2 162
Christopher Lew

Note that these lab meetings are laptop-only working spaces (i.e., they are not a computer lab with machines already present).

Office hours

I will be available on Tuesdays and Thursdays from 8:30-9:45pm in DBH 1431 — not my office, as it's in a building that will be locked during at least part of that time — during which I'm available to chat with you about whatever's on your mind.


This course requires no textbook, as I will be providing a complete set of Notes and Examples covering every lecture this quarter.

Note that you might find a book that complements the lecture material and helps you fill in details that you missed while listening to me speak for eighty minutes, though I think the Notes and Examples section will generally be enough information for you to succeed. If you prefer a book (or online supplements of your own choosing) other than what I'm providing, that's generally fine, though do be aware that style and approach among practitioners of a programming language tend to differ, and we'll be expecting you to follow similar conventions to what we're learning about in this course.

Obtaining additional assistance

Asking questions of course staff

You can most easily get course questions answered by coming to the lecture, the discussions, or office hours and asking them. I am happy to help you in person when I'm available. You can also ask questions by sending email to me or a TA (or both); we check our email frequently throughout the day, so you can usually get an answer to course-related questions within a few hours (and often much more quickly). If the questions require a complex or lengthy response, we may ask you to see one of us in person. As projects approach their due date, particularly on days when projects are due, we begin to receive quite a bit of email all at once, so we may not be able to respond to all messages before the project is due. We aren't ignoring you on purpose, but unfortunately it's not always possible for the relatively small course staff to answer questions from a large number of students at once. A great way to mitigate this problem is to get started early and ask questions sooner in the process.

Accommodations for disabilities

Any students who feel that they may need an accommodation based on the impact of a disability should contact me privately to discuss these specific needs. Also, contact the Disability Services Center online or by phone at (949) 824-7494 as soon as possible to better ensure that such accommodations, such as alternative test-taking environments or note-taking services, can be arranged for you in a timely way.


Weights of graded artifacts

Your course grade will be determined from the weighted combination of your scores on each of six programming projects, one Midterm, and one Final Exam. The weights of each of these are:

Determining final grades

Course grades will be determined neither on a normal curve nor a straight scale. It is guaranteed that overall scores over 90% will receive an A- or better, scores over 80% will receive a B- or better, and scores over 70% will receive a C or better. However, the actual cutoffs may be lowered at the end of the quarter. In short, it is not my intention to fail half of the students, nor am I planning on giving only 2% of the students A's, but I prefer not to constrain myself with either a straight scale or a formalized curve.

If you're curious about how you're doing in the course, I'm happy to discuss your estimated grade at any time. It's generally best to have this conversation in person, so that we can explore issues other than just the raw numbers; I'm happy to have this conversation at any time that I'm available, and I'm also glad to do it via email if we can't find a mutually available time.

Dropping the course or changing grade option

Through the end of Week 2 (Friday, October 7), you may drop the course by simply going to WebReg and dropping it. If you wish to drop the course after that date, you will need to use the Enrollment Exceptions system to request a drop; I do not have the final say over those, ultimately, as the Dean of the Bren School (and your major, if you are majoring in something outside of the Bren School) must approve them. It is not generally the case that an exception will be accepted simply because you're not doing well in a course, though extenuating circumstances are certainly considered.

Similarly, changing your grade option (to Pass/NotPass or back again) can be done via WebReg through the end of Week 2 (Friday, October 7), after which you must use the Enrollment Exceptions system to request the change. As with exceptional drops, you must receive approval from the appropriate Deans.

Academic honesty

The policy

As ICS 45C or CSE 45C students, you are expected to know and follow the academic honesty policies of both the Bren School of ICS and the University as a whole. Please take a few minutes to read the policies, which can be found at this link.

All of your project work is expected to be completed solely by you. Worker in larger groups and/or sharing of code between students that are not partners is not permitted. Note that "high-level discussion of course material for better understanding" is permitted and encouraged, but when it comes time to sit down and write code, that is expected to be done by you and you alone. All submissions are compared to one another using an automated plagiarism detection system. This system is extraordinarily good at finding similarities between submissions, even when there are superficial differences. (Note that we also compare your submissions to those submitted during previous quarters whenever one of these assignments was given during a previous quarter, so it is an exceedingly bad idea to turn in, or even refer to, code written by a friend of yours who took the course already.)

Since all of your work is expected to be completed solely by you, you will be held responsible even if you plagiarize only a small portion of someone else's work.

Academic honesty is a two-way street. Providing your code to other students for them to turn in as their own is not permitted any more than turning in someone else's code. Resist the temptation to give code to your friends "for reference." Based on my experience, I can say that your "friends" may very well betray you and turn it in, anyway, and then you'll have a lot to answer for.

Naturally, the Midterm and Final Exam are also expected to be individual efforts. Dishonest behavior during an exam will not be tolerated.

Violators of academic honesty policies are subject to the penalties described in the Bren School of ICS policy. Penalties can include an immediate course grade of F — without the option to drop the course to avoid the grade. You shoud also be aware that I am required to document and report all cases of academic honesty, and that a single documented case of academic dishonesty may preclude you from switching into computing majors, registering for computing minors, joining the ICS Honors Program, and graduating from a computing major with honors. All of this is University and Bren School of ICS policy and is not subject to negotiation.

Knowing when you're being dishonest

I've been asked by students how they know when they're crossed the line between asking for help and being academically dishonest. To me, there is a fairly straightforward way to know the difference. Did you actually write the code in question? That's not a matter of whether you typed it in; that's a matter of whether it was you who wrote it (i.e., it is comprised of your own ideas about how to solve the problem, how to organize the solution, and so on).

The easiest way to determine whether you've crossed the line is whether your work was driven by someone else's existing solution. Here are some examples:

In my view, this really isn't that complicated. We require you to do your own work, because that's how the learning is done in this course. If you're unable to do the work in the course, you're not ready to take courses that follow on from this one; cheating this quarter in an attempt to move forward anyway is simply delaying the inevitable failure that lies ahead until you successfully build your skills.

The lesson

Okay, so the moral of the story is that it's wise to avoid cheating. I believe that it's relatively rare that students enter a course with the conscious intent to cheat their way through it; why come to UCI if you're not planning to get something out of the coursework? So why do people cheat every quarter in every course? The answers vary, but here's the easiest way I can boil down the numerous conversations I've had with students caught cheating in my courses over the years: I fell behind and couldn't figure out how to catch up. Things happen and ten-week quarters are unforgiving. You might get sick, you might have issues crop up in your family, you might have misunderstood one of the earlier topics in the course on which later topics dependend, you might have an off-campus job that's demanding too much of your time, you might be trying to decide whether you're on the path you want to be on... Any of those things (and many others) can make it hard to keep up. You fall a little behind, you fall a little further behind, and pretty soon the situation seems hopeless. You're under pressure, temptation gets the better of you, and suddenly it seems better to submit someone else's work than to submit nothing. It's not.

If you feel like you're beginning to slip off course or things are getting beyond your control, the best thing to do is to talk to us sooner rather than later. We're here to help; we understand. But the reality of taking large-sized courses at a large-sized institution is that we're not going to know you're in need unless you tell us. If things are happening in your life, tell us; you don't have to be specific if you're not comfortable with it. Before the fact, there's often a way to work things out. After the fact, it's usually too late.