Instructor: Dr. Phill Conrad, Lecturer (PSOE), Dept. of Computer Science (Joint Appointment, College of Creative Studies). TA: Wendy Chun Website: http://www.cs.ucsb.edu/~pconrad/cs8 Course Meetings: Session: B (August 2rd-Sept 10) Lecture: Mon, Tue, Wed: 1100am-1225pm, Phelps Hall 1401  Discussion sections: ESB 1003 (Cooper Lab), Thursdays Enrollment code: 02386: 11am-12:25pm Enrollment code: 02394: 12:30pm-1:55pm Instructor Email pconrad@cs.ucsb.edu TA Email: chun0216@cs.ucsb.edu

Office Hours for both the instructor and TA can be found by consulting the following Google Calendar:

Prof. Conrad and your TA are also available by appointment—use email to request an appointment.

Catalog Description Prerequisites Textbook
Introduction to computer program development for students with little to no programming experience. Basic programming concepts, variables and expressions, data and control structures, algorithms, debugging, program design, and documentation. None: but we do expect familiarity with basic concepts from high school algebra, geometry and trigonometry—we'll review those as needed.

Title: Python Programming in Context
Authors: Bradley N. Miller, and David L. Ranum
Publisher: Jones and Bartlett, 2009.
ISBN-10: 0-7637-4602-5    ISBN-13: 978-0-7637-4602-5

40% Assignments/Quizzes/Homework + 40% Midterm Exams (2 at 20% each) + 20% Final Examination

Quizzes may occur at anytime, announced or unannounced. Missed quizzes may not be made up.

A conventional 10 point scale will be used to map your numeric average into a letter grade, with the lower three and upper three points of each range representing plus/minus.

This 10 point scale represents the minimum letter grade you will be assigned—at the instructor's discretion, the letter grade scale may be altered in the students' favor if this will be better reflect the students' mastery of the material. Thus, if there is a "curve", it will be applied at the end, not to individual assignments.

A Few Course Policies In Brief (more detail later on this syllabus)

• If you are registered for another UCSB course that overlaps with this one, you MUST HAVE specific written permission from both instructors, or I am within my rights to give you a failing grade on any work you miss as a result, and will NOT make any accommodations for you.
• You are permitted one sheet of notes on exams—details later on the syllabus.
• Collaboration is only permitted when specifically allowed for—otherwise, you must do your own work.
• On most homework assignments you may collaborate with at most one other person (who must be named)
• Attendance is required at all lectures and labs (discussion sections) and is checked via homework submission. Therefore:
• you must hand in homework in class
• you may not turn in homework on behalf of another student, or ask someone else to turn in yours
• If you need to miss class once, there is a provision for making up the homework

This course is an introduction to Computer Science, and programming.

Computer Science is the study of abstractions and algorithms.

• In Computer Science, an abstraction is a useful representation of something from the real world that allows us to work with it more easily or efficiently.
• An algorithm is a well-defined, step-by-step sequence of instructions that can be used to mechanically determine the solution to some well-defined problem.

You probably use abstractions and algorithms every day—for example:

• If you pick up any textbook, you'll probably find an index in the back of the book. The index is an abstraction—whether the book is about biology, modern art, political science, or computers, the "way the index works" is the always the same. It is composed of the same pieces (topics and page numbers), and organized in the same way (alphabetically by topic, then lists of page numbers in numerical order from smallest to largest.)
• If you are looking in the index of a U.S. history textbook for "Gettysburg" you'll probably use an algorithm to find the entry quickly. Here the input to the algorithm is some topic, and the output is a list of pages on which that topic appears.
• If you are looking for a parking lot on campus, you might use an abstraction called a "map" to locate the parking lot. You know the features of a map, and how it corresponds to the reality of a college campus, and parking spaces. The way a map can work to help you find a parking lot (or garage) is the same whether it's a map of UCSB, Downtown Santa Barbara, or the Staples Center in LA.
• If you are searching through a parking lot (or garage) to either (a) find a parking space, or (b) determine that there are no spaces left, you probably use an algorithm to do that—again, without even thinking about what you are doing.

In the case of using an index, this is probably an algorithm you may have learned in grade school, and it has been so long since you learned it, that now you don't even think about it—you just do it. Finding a space in a parking lot—and knowing when to give up and look elsewhere—is "just common sense"; this probably isn't something you were ever "taught", or even have to think very much about. You just do it.

Computers don't currently have this capability—i.e. the capability to "pick up things by common sense"—and it seems unlikely that they will within our lifetime—unless there are major breakthroughs in the field of Artificial Intelligence. Such breakthroughs have been predicted for a while, but they haven't happened yet. (Maybe you'll be the one to figure out how to achieve this!)

So, for the time being at least, it falls to humans to design algorithms that computers can use to solve problems. In many cases, these algorithms are "just common sense"—the computer equivalent of looking for an empty parking space in a parking lot (and knowing when to give up). Algorithms like this are easy to design. Many of the algorithms we'll see in this course are like that.

In other cases, the algorithms are very complex, or very subtle, and coming up with them is a deep intellectual challenge. Furthermore, the impact of a better algorithm on society can be very large. For example, new algorithms in the field of computational science—modeling chemical and biological reactions with computer simulations—can lead to breakthroughs such as new drugs to fight disease, or renewable sources of energy.

And often, what goes along with finding a good algorithm is finding a good abstraction of the real world concepts we are interested in: cells, molecules, oil fields, words, sentences, students, courses, GPAs, etc. Algorithms and abstractions really go hand-in-hand.

Programming: expressing algorithms in a programming language

Human languages such as English and Spanish are not very well suited for expressing algorithms—at least not for expressing them to a computer (they have their problems for communicating with humans too!). So, special languages are used. In this course, we'll learn the Python programming language. We choose Python rather than Java or C++ because:

• If you are learning your first programming language, Python is easier to learn than the others
• Learning Python provides a good foundation for learning C, C++ or Java
• If you only learn one programming language, Python is a good choice—in spite of being easy to learn, it is not a "toy" language by any means. It is widely used by scientists and web application developers just for starters. Many internal systems at Google are based on Python code.

This course provides you with the opportunity to become a pretty good beginning programmer, and be well prepared for an intermediate programming course such as CS16 (the first course that counts towards the CS major at UCSB, and which requires at least one quarter of prior programming experience.)

I say that the course "provides an opportunity," because you will only become an good beginning-level programmer if you put a lot of time and effort into this course—that is true no matter how much thought and attention I put in my lectures, assignments, and exams.

(Image credit: http://xkcd.com/353/, used by permission)

The swimming/guitar/painting analogy

You cannot learn to swim, play guitar, or paint from a textbook or a lecture. You can only:

• learn to swim by spending many hours in the pool,
• learn to play guitar by spending many hours playing the instrument
• learn to paint by spending many hours putting brush to canvas.

The same is true of programming. Programming is not a serious of facts to be memorized—you cannot "cram" for a computer science exam. You must practice, practice, practice.

You may find the workload heavy

As a result, the workload in this course may feel heavy. It may even feel unreasonable compared to your other courses.

However, I assure you that it is not unreasonable, given the goal of making you an skilled beginning programmer.
Programming is a skill, and the only way to get good at it is lots and lots of practice, which takes lots and lots of time.

Special note for summer session programming courses

The compressed 6 week term means your work load—reading assignments, homework, and programming assignments—which is already heavy in this class, will have to be 166% of what you'd experience during the normal quarter, just to keep up.

The usual rule of thumb is 8-12 hours per week for a normal college class*. That means you should expect, at a minimum to put in 14-20 hours per week on this summer course, on top of the 6 hours you spend in lecture and lab each week. To put it another way, I really should be giving you around 5 to 7 hours of homework between every lecture. (I probably won't succeed in giving you that much work to do, but I really should, because that's the only way you'll learn what this course is supposed to teach! So, I'll do my best. If the work load is less than that, I apologize in advance for disappointing you. :-) ).

(*see CliffsNotes.com. How much outside class study time is recommended for every hour of class time for college freshmen? 26 May 2009 <http://www.cliffsnotes.com/WileyCDA/Section/id-305397,articleId-7601.html>)

How this course works

There are five components to this course, each of which has a special job to do:

• Reading—Between each class, you'll have reading to do in the textbook. There is too much information you need to learn in this course for you to get all of it in lecture, especially in the six-week compressed time-frame so the readings are essential. The reading assignments for the next class can be found on the homework assignments handed out during each class period.

• Homework—In almost every class, you'll be given a homework assignment that is due in the following class. (The exception is the class period immediately before an exam, where no homework will be given.)

The homework often goes hand-in-hand These are typically pencil/paper type problems, though sometimes you'll need access to a computer to solve them. If you don't have reliable access to a computer at home (or in your dorm), please plan your schedule so that you can spend time in the CSIL computer lab between classes.

Homework assignments are completed on paper—they may NOT be submitted in electronically—and may only be submitted in the class in which they are due. In this way, they also serve as an attendance check. Therefore, you may NOT turn in a homework assignment "on behalf of" an absent classmate, or have someone else turn in your homework for you—doing so in this course is a form of academic dishonesty.

Because I realize that sometimes each student must miss a class due to unavoidable circumstances, or illness, each student is permitted one "personal day/sick day" (one per quarter) where you may make up a missed homework assignment (without penalty) by coming in person during the instructor's office hours, or making an appointment (See the homework page for more details about this policy.)

• Programming Assignments (Labs)—Programming assignments (also called labs) are given once or twice a week, and are typically started in the Thursday lab sessions, and finished on your own time outside of lab. These will typically involve pair programming, which is described later in this syllabus.

• Lectures—Learning is something that you do as a student, not something that is "done to you" by a teacher. Therefore most of the learning you will do in this course takes place when you are actively involved in doing something challenging, i.e. during the homework assignments, and labs. Most of the information you will need to do those assignments will come from the reading.

Therefore, you may ask, what is the purpose of the lectures?

The purpose of the lectures in this course is to guide you through the readings, homeworks, and labs:
• to provide an overview of how everything fits together
• to provide hands-on demonstrations of things you'll do on your own later
• to provide additional information that is not in the textbook
• to provide additional explanations about things in the text that might not be clear

• Exams—There are three exams in this course—two midterms and a final.

You may wonder why there are two midterms in a course that is only six weeks long. The reason is that I've found that in order to succeed at learning the material in this course, many students need two opportunities for feedback on how they are doing before the final exam. Students sometimes are doing better than they think they are, or not as well as think they are, and the exams provide a "reality check".

You can find examples of last summer's exams at the following link:

Keep in mind that the exams from last year's course may have occurred at slightly different points in the quarter, and the pace of material may have been different. So please take these as examples only of the "types" of questions asked on exams, not of what might be asked (specifically) on midterm 1, 2 or the final during this quarter.

Everything is Cumulative—that's just how CS is.

Finally—note that just as in a math class, everything we do builds on all the work that came before. So, everything is cumulative—so, you can't afford to miss any classes unless absolutely necessary. Missing a summer session B class is like missing TWO classes during the normal term. Miss two classes, and you've already skipped more than 10% of the course—it wouldn't be surprising if your performance in the course dipped by a similar amount.

What you need to learn to become a skilled beginning level programmer.

So, what is it that you need to know to be an skilled beginning-level programmer in Python? Here's the list of what you'll need to be ready for CS16 (the next programming course):

 Problem solving breaking down a problem into a sequence of steps abstracting specific problems into general ones and finding general solutions Memory concepts variables, primitive vs. reference variables, name, type, value assignment statements scope of variables Control structures for loops, if/else, while loops Lists in Python (similar to arrays in other languages) index vs. value, finding sum, min, max, average, count of elements matching some condition, making a new list of elements containing only those that match some condition Functions function call vs. function definition formal vs. actual parameters (arguments) Testing How to test your code Input/output concepts Writing to the terminal Reading from the keyboard Reading and writing to files Neatly formatting output Program style How to write code that other people can read and understand

Policies

Attendance

This course moves quickly. So attendance is very important.

We'll be trying to master the material from about 9 chapters in the book over six weeks. We'll sometimes cover two or even three chapters in a given week. We need to go at that pace, because during the last week of the quarter, you can't really start anything new, because there isn't time to put it into practice with programming assignments. If you don't put it into practice, you aren't very likely to learn it in any way that is going to stick with you, so there isn't much point in just "going through the motions".

As a result, there will be something you have to turn in at almost every class. In this way, attendance is taken, and required.

These things you have to turn in will be a combination of in-class activities, and homework completed outside of class, but handed in on paper during class.

Missing in-class activities.

If you miss a class, you miss the opportunity for the points on that in-class assignment, or homework that was due. Period.

There is no makeup, except for:

• excused absences arranged and agreed to by the instructor in advance, for official UCSB activities
• one "sick-day/personal day" per student, per quarter (see below)

To make up an assignment from a "sick-day/personal-day", you must email me within 48 hours of the absence, to make an appointment to make up the assignment during the next scheduled office hours following your absence (or at an appointment time to be negotiated, if you have a conflict with those hours.) This make up must happen within one week of the absence, or 24 hours before the final exam, which ever is earlier.

In rare cases, if there is a documented family emergency, documented extended illness, documented required court appearance, or other situation beyond the students' control (with documentation) the instructor may grant additional make up days entirely at the instructor's discretion—but this is not a guarantee or a right.

Most of the programming work in this course will be done using a style of programming known as "pair programming". This is where two people (in rare cases, three) work together at the same terminal to solve a programming problem.

It is similar, in some ways, to having a "lab partner" in a Biology, Chemistry or Physics course.

For the assignments where pair programming is used, it is required, not optional. Here's why:

• Pair programming is a real-world skill that is highly valued by employers.
• Many companies use pair programming extensively (including the Santa Barbara based software company AppFolio, where several UCSB grads work).
• Companies that employ UCSB CS and CE grads tell us that our graduates have good technical skills but need better skills and working in pairs and groups to solve problems.
• Incorporating pair programming into our curriculum is part of our response to this "real-world" feedback.
• Most students find it helpful and enjoyable—UCSB CS students from 2009-2010 that were surveyed about their pair programming experiences overwhelmingly reported positive results.
• There is also evidence in the scientific literature that it improves student learning, and helps you get better grades.

http://agile.csc.ncsu.edu/pairlearning/educators.php

As mentioned above, one of the things we really want to convey in this course is that real-world software development is very seldom an 'individual sport'—is it much more often a 'team sport'. Companies want to hire CS and CE graduates that know how to collaborate with others on producing software.

In the CS Department at UCSB, we understand the value of this. However, it puts us in a tricky position.

On the one hand, we want to encourage working together in ways that help you develop your skills and teamwork, and help you understand that programming can be a social, collaborative, creative activity—not something done only by loner nerds in cubicles. The sooner you start with activities such as pair programming, code reviews, and other collaborative software development activities, the more skill you'll develop, and the sooner you'll be ready for the real world. Plus, for many people, working together with others is a lot more enjoyable and fun than being a loner.

On the other hand, we need to avoid any situations where freeloaders are "coasting" through courses by leaning too much on others—never developing independent skills as programmers. This situation creates huge problems. Mostly it is damaging to the freeloaders themselves, who eventually crash and burn, perhaps far too late to choose another career path without significant difficulty. However, it also creates problems for everyone else—some hardworking students become demoralized by the unfairness of it all, and the value of a UCSB education is diminished by the freeloaders' lack of accomplishment.

Thus, we must strike a balance.

Our emphasis on collaboration means:

• We will try to create opportunities for you to work in pairs on assignments—in some cases, we may even require it.
• We will try to create opportunities for you to develop the ability to think critically about software development by talking about and reflecting on your own code and other people's code in small groups (code reviews).
• Some in-class assignments will permit discussion with other students.

However:

• You may not "just copy" homework or code from others and claim it as your own work.
• You may not work together on assignments unless you've been specifically told that it is allowed.

The bottom line:

• We'll try to be very specific about what kinds of collaboration are permitted, and what kinds of collaboration are not permitted, and are considered a form of academic dishonesty.
• If you are not sure about whether some kind of collaboration is permitted or not, it is your responsibility to ask questions.

A final note: the emphasis on collaboration in this course does not necessarily extend to other CS courses you may take in the future.

• Each course will have its own policies, and the default policy is still: no collaboration.
• Please be sure you understand each instructor's policy on collaboration carefully, and don't assume it will be the same as that from previous courses.
• And, finally, be sure to review the UCSB Academic Honesty Policy. You should read and understand the UCSB policy on academic honesty listed below. You should also understand that I take academic honesty and personal integrity very seriously, and will do my best to uphold and enforce this UCSB policy.