ICS 32 / CSE 42: Programming with Software Libraries
Fall 2017
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, which course you're enrolled in, and which lab 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 4:30-5:45pm in DBH 4013 — not my office, as it's too small for the occasion — during which I'm available to chat with you about whatever's on your mind. Office hours begin on Tuesday, October 3 and continue throughout the quarter. You don't need an appointment to visit, and you can always assume that I will be there as scheduled unless you hear from me otherwise.


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 five teaching assistants, each of whom is assigned to one or more lab sections; see below for an indication of which TA is assigned to which section. Once you know which section you're enrolled in, you'll want to know who the TA for your seciton is. Among other roles, the teaching assistants are the primary points of contact with regard to the grading of projects.

The names and contact information for the TAs are as follows.

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

Lecture

A lecture meets on Tuesdays and Thursdays from 6:30-7:50pm 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.

Labs (The ICS 32 Help Center)

There are either lab sections, meeting throughout the day on Mondays, Wednesdays, and Fridays. Collectively, we will refer to all of these hours as the ICS 32 Help Center, which meet at the following locations and times:

While you are required to be enrolled in a lab section — and this enrollment does determine who will grade your projects and with whom you are permitted to partner when working in pairs — you are generally free to attend the ICS 32 Help Center whenever you need it, regardless of which lab section you are enrolled in, with two caveats:

While it is not a required part of the course, and nothing will be graded in the labs this quarter, attendance does offer some significant benefits:

Staffing in the ICS 32 Help Center will be as follows. The TAs listed for the sections below are the official TAs of record — so, in general, they would be your first point of contact regarding the grading of projects.

Lab Section Location TA Tutor(s)
Lab 1
MWF 8:00am-9:20am
ICS 192 Mohammad Eletriby Aiyuan Li
Lab 2
MWF 9:30am-10:50am
ICS 192 Mohammad Eletriby Yingyu Yang
Lab 3
MWF 11:00am-12:20pm
ICS 192 Shayang Zang Blake Wakasa
Rachel Dong
Lab 4
MWF 12:30pm-1:50pm
ICS 192 Shayang Zang Vincent Tran
Lab 5
MWF 2:00pm-3:20pm
ICS 192 Tushar Dhadiwal Natasha Gawande
Jiliang Ni
Lab 6
MWF 3:30pm-4:50pm
ICS 189 Abhishek Jindal Keith Chang
Lab 7
MWF 5:00pm-6:20pm
ICS 189 Abhishek Jindal TBD
Lab 8
MWF 6:30pm-7:50pm
ICS 189 Nishanth Devarajan Sijie Lu
Lab 9
MWF 8:00pm-9:20pm
ICS 189 Nishanth Devarajan Edwin Tang


Textbooks

This course doesn't use or require a textbook. Alternatively, I'll be posting a detailed and complete set of Notes and Examples throughout the quarter, which will serve as a sort of textbook for this course.

Additionally, one of the main skills you'll be building in this course, aside from broadening and strengthening your Python programming skills, is the ability to find, analyze, and synthesize information in online documentation, tutorials, and other materials that make libraries — not just those that are included with Python, but also those that are obtained from third parties — accessible to you and useful in solving real programming problems. To that extent, the Internet will serve as a significant "textbook" for us, as well. (Be aware, though, that this does not include using solutions to these projects written by previous students; see the section titled Academic honesty below for more details.)


Obtaining additional assistance

Asking questions of course staff

You can most easily get course questions answered by coming to the lecture, the ICS 32 Help Center, 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 your TA (or both); we check our email periodically 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.


Grading

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.

Some of the programming projects will allow you to employ a technique called pair programming, which is discussed in more detail in the Project Guide. There are times that you will be optionally be able to participate in pair programming; there are other times when it will be disallowed. Each of you will also be asked to fill out an evaluation of your partner after each paired project is due; this will give you an opportunity to let us know, confidentially, whether your experience with your partner was a positive one. I reserve the right to reduce your overall course grade on paired projects down as far as zero if the evaluations you receive from your partners are consistently problematic (e.g., if your partners report that you made no contribution).

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 13), 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 13), 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, and that approval is not guaranteed.


Academic honesty

The policy

As ICS 32 or CSE 42 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 (and your partner, on paired projects). 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.

All violations of academic honesty policies will be reported to the UCI Office of Academic Integity & Student Conduct (AISC) and will trigger an administrative procedure, which is described on their web site. Additionally (and at least as importantly), you can receive a course grade of F — as a number of students in my courses do, because of this issue, every quarter — without the option to drop the course to avoid the grade. A single documented case of academic dishonesty may also have other ramificiations, such as precluding 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 comprises 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. A large part of what you're learning to do is to design and write programs, a skill that can only be built by designing and writing programs. You have to make the decisions about what to do next, how to organize your program, and so on. If someone else is making most of those decisions for you, you're not building the skills necessary to be ready for the courses that follow on from this one. And, from the standpoint of academic honesty, if someone else is making most of those decisions for you, that's plagiarism.

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 this course (or one or more important topics in previous coursework) on which later topics depended, 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 overall life 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. As upwards of 10% of my students (who have cheated like this) can attest, 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.

And, in general, some students won't pass this course with a C or better this quarter, and won't be moving on to ICS 33 next quarter. And that's not as disastrous as it sounds. Most students who get less than a C in introductory courses take them again; most of those who take the course again pass it the second time around, with their feet firmly underneath them and ready to move forward.

Sharing your own solutions online

Some of our past students have wanted to post their own solutions to their projects online, with the goal of helping others or just showing off work that they were proud of. This is also problematic from an academic honesty perspective, because many or all of the projects you're working on will be reused in a future quarter; good problems are good problems, and I don't rebuild five new projects every quarter. Given that, posting your prior work online will absolutely lead to other students finding it and plagiarizing it — this is now one of the more common root causes of plagiarism cases that we find.

I can appreciate, of course, that you might want to build a portfolio of work to demonstrate your skills as you build them, and I'm not unsympathetic about that. However, the reality is that posting solutions to first-year coursework is very unlikely to be of use in job searches or other professional scenarios. I've asked a number of hiring managers over the years, including ones I've worked for in my industry career, and have universally received the same response about it: Hiring managers generally aren't interested in seeing prior homework. Projects in courses like this one are sanitized, in the sense that they're problems that have been designed to be solved using techniques just taught, with the requirements clearly spelled out, and with few enough rough edges that a large number of students can solve them without encountering roadblocks that can't be overcome. Real-world work isn't like this, as it turns out. Figuring out what needs to be built is as important as figuring out how to build it. Building a portfolio is best done with your own solutions to your own problems, containing things you've written to scratch your own technology itches or explore concepts that you wanted to learn more about on your own.

So, in general, despite the fact that you may be proud of the work you've done, you need to understand that there is a very strong likelihood that the only thing you'll be doing is enabling future students to plagiarize your work — and quite possibly becoming embroiled in the investigation yourself and being reported to AISC — while not accomplishing much of anything positive for youself.

Do not share your prior solutions online.