The CS 61 series is an introduction to computer science, with particular emphasis on software and machines from a programmer's point of view. CS 61A covered high-level approaches to problem-solving, providing you with a variety of ways to organize solutions to programming problems as compositions of functions, collections of objects, or sets of rules. In CS 61BL, we move to a somewhat more detailed (and to some extent, more basic) level of programming.

In 61A, the correctness of a program was our primary goal. In CS 61BL, we're concerned also with engineering. An engineer, it is said, is someone who can do for a dime what any fool can do for a dollar. We care not only about the correctness of your program. Here in CS 61BL, you will learn not just how to solve problems, but how to solve them well. Much of 61BL will be concerned with the tradeoffs in time and memory for a variety of methods for structuring data. We'll also be concerned with the engineering knowledge and skills needed to build and maintain moderately large programs.

The courses cover the same content. They count for exactly the same kind of credit as well. The difference is in the structure of the course. 61BL is lab-based, meaning you will spend proportionally more time in lab and proportionally less time in lecture. There are several motivations for this. Studies have shown that students learn better through active learning, a teaching method that is supported by our lab-centric format. The goal is for you to be able to learn not by someone lecturing at you, but by doing.

In addition, 61BL is a partner-based course, where much of the programming is done with a fellow classmate. 61BL strives to create a collaborative rather than competitive environment. All assignments are to be completed with partners (with the exception of proj1). Learning with a partner gives you the opportunity not just to learn, but to truly internalize the information we give you, make it your own, and explain it to another person. Furthermore, the ability to work effectively as part of a team is indispensable in our field and in life.

This class assumes you have taken CS 61A, CS 61AS, or E7, or have equivalent background to a student who has taken one of these courses. The course is largely built upon the assumption that you have taken CS 61A or CS 61AS, and E7 students may find the beginning of the course to be a bit scarier, particularly when it comes to object oriented programming.

We assume you are coming in with zero Java experience. Nonetheless, we will move through basic Java syntax very quickly. Though the syntaxes of Java, Python, MATLAB, Scheme, etc. are enormously different, the underlying computational models are surprisingly similar.

If you already have Java experience, great! We hope that you'll help out your fellow students in lab, and on Piazza, particularly in the first week when everyone is catching up on Java.

This is a course about data structures and programming methods. It happens to also teach Java, since it is hard to teach programming without a language. However, 61BL is not intended as an exhaustive course on Java, the World-Wide Web, creating Android apps, user interfaces, graphics, or any of that fun stuff.

Some of you may have already had a data structures course, and simply want to learn Java or C++. For you, self-study may be a better option. CS 9F (C++ for programmers) and CS 9G (Java for programmers) are both one-unit self-paced courses that will teach you more of what you want to know in less time. There is no enrollment limit for that course, and you work through it at your own pace after the first and only lecture.

Finally, the 1-unit self-paced course CS 47B is for students "with sufficient partial credit in 61B," allowing them (with instructor's permission) to complete the 61B course requirement without taking the full course.

A lot. This is a summer course, which means it is run at twice the speed of a normal course. In addition, 61B naturally has more involved programming than 61A, and 61BL has even more. We strongly recommend not taking any other courses alongside 61BL.

We cannot predict how many hours you will spend on the course; some students take more time than others. However, we can at least give you a brief breakdown of what you will have to do in this course:

During your first lab section, you will receive an instructional account login form. This will give you access to the Soda lab computers.

Feel free to bring your own laptop to work in your own development environment.

Lab sections meet every Monday through Friday, except for Wednesdays and July 4th. You are expected to attend lab whenever your lab section meets. All lab work must be done in pairs.

If you would like to attend a lab section that you are not enrolled in, you must get permission from the lab TA of the section you would like to attend (the TA needs to confirm that there is room in their section). Regardless of which section you choose attend, you must attend that section consistently. Switching sections will not be permitted following the first week of class except for exceptional circumstances.

Every lab will require the submission of several files to receive credit. Some of the files will be graded for completeness while others will be graded for correctness, not just effort/completeness. We will let you know what files contribute to your grade.

Labs are due the next day two hours before your lab's start time (even if there is no lab that day). For example, if your lab begins at 3 PM, Tuesday's lab will be due on Wednesday at 1 PM. This deadline is meant to be fair for those in labs that occur later in the day. You will submit files as a group.

The last lab of the week will additionally require you to fill out a self-reflection form about the labs in the past week.

Each lab section will start with a short written quiz that tests the material from the previous lab. Quizzes are meant to encourage you to keep up with the course material and to help the TAs see where their students are having trouble.

You can only take the quiz in your own lab section. There will be no makeup quizzes. Because of how quiz points are capped, you can miss a couple quizzes without detriment to your overall quiz grade. Please check the grading section below on how quizzes affect the course grade.

EPA stands for effort, participation, and altruism. A small portion of your grade in this course will be based on EPA. Examples of effort include coming to office hours and completing all assignments. Participation points can be earned by being active in lab or in lecture, whether it be by asking great questions or by answering them. Examples of altruism include helping others in lab or on Piazza, as well as creating software, art, or tutorials that help others learn. Pairs who contribute to their repos equally will be rewarded with EPA points. The above is by no means an exhaustive list of ways to earn points. EPA scores are not capped at 15 points; extraordinary contributions to the course community may be rewarded with extra credit. EPA scores will be kept internal, however. Our intent is for full EPA credit to be easily attainable for hard-working, collaborative students... don't sweat it too much!

There are three projects in this course. Projects are larger and more challenging assignments than you would typically find in a lab. The first project is done alone. The second and third projects are done with one partner.

We have set aside three lab days for working on the project (two workdays for project 2 and one workday for project 3). There is no workday for project 1. Take advantage of these workdays for you and your partner to finish the project and ask your TA for guidance/advice on the project.

Note that you should start working on the projects long before their respective workdays. The workdays are intended to reduce the load of learning new material in the day(s) leading up to the project deadline.

This course has two midterms and a final. Please notify the instructors within the first week of the course if you have any conflicts with any of the exam times.

Inspired by the great Paul Hilfinger tradition, exams may cover any material whatsoever. Officially, you are responsible for the sum total of human knowledge since the beginning of recorded history with particular emphasis on the contents of this course. For fear for our lives, exams will almost exclusively test material covered in the course.

If your midterm grades are statistically much worse than your final, we'll replace your midterm grade under the "shadowing" policy below. You should not depend on shadowing to substantially improve your grade. Very few students receive a significant benefit.

Shadowing

Midterm (both MT1 and MT2) grades can be "shadowed" (aka a weaker version of what Dan Garcia calls "clobbering") by the final. The way it works is that if you are X standard deviations from the mean, your midterm scores will be replaced by a score equivalent to X - 0.5 standard deviations from the mean. This policy can only help, and cannot hurt your score.

Effectively, this only applies if you improve substantially on your final: an improvement of over 0.5 standard deviations.

For example, suppose Bilbo scored 0.4 standard deviations above the mean on MT1, 0.9 standard deviations above the mean on MT2, and 1.1 standard deviations above the mean on the final. Then Bilbo's midterm scores will be replaced by 1.1 - 0.5 = 0.6 standard deviations above the mean, as long as this is an improvement.

Since Bilbo already got 0.4 above the mean on MT1, his score would be replaced by 0.6. However, his score on MT2 would not be changed (since he is already 0.9 above the mean).

As another example, suppose Bilbo is -1.1 above the mean on MT1, -0.1 on MT2, and 0.3 on the final, his midterm scores would be replaced by -0.2 (0.3 - 0.5) if that helps. In Bilbo's case, his MT1 score would be replaced by -0.2, and MT2 score would be untouched (since it is already better).

Or in pseudocode:

your_devs = (your_final_score - final_mean) / final_stddev
your_potential_replacement = (your_devs - 0.5) * midterm_stddev + midterm_mean
your_shadowed_midterm_score = max(your_midterm_score, your_potential_replacement)

You are expected to read each lab's contents. Additional optional reading assignments will be posted on the course calendar. You may choose to do these readings for more information/context on the material. The textbooks we are using this semester are:

There are 300 total course points, broken down like so:

Category	Points	Percentage of Total Grade
Labs	60	20%
Quizzes	15	5%
EPA	15	5%
Project 1	15	5%
Project 2	36	12%
Project 3	24	8%
Midterm 1	30	10%
Midterm 2	45	15%
Final	60	20%

Your letter grade will depend on the number of course points you have at the end of the semester:

A+	A	A-	B+	B	B-	C+	C	C-	D	F
[285, 300]	[265, 285)	[255, 265)	[240, 255)	[220, 240)	[205, 220)	[190, 205)	[175, 190)	[160, 175)	[130, 160)	[130, 0]

These ranges may be adjusted downwards at the end of the semester depending on overall student performance (but not the other way around - if you fall in the bucket for a grade you are guaranteed that grade or better).

Departmental guidelines suggest that the average GPA for a lower-division required course be in the range 2.8 - 3.2, with 3.0 (B) being typical. This corresponds to getting 62% on tests (typical for past exams), 75% on projects, and 100% on lab assignments and quizzes.

We will grant grades of Incomplete only for dire medical or personal emergencies that cause you to miss the final, and only if your work up to that point has been satisfactory. Do not try to get an incomplete simply as a way to have more time to study or do a project. That is contrary to University policy.

There are a total of 25 quizzes, each worth 1 points. Thus, while the total point value for quizzes is 25, quiz grades are capped at 15 points. This means that you can miss up to 10 points on quizzes without penalty. In other words, getting more than 15 points on quizzes is equivalent to getting 15 points for your quiz score.

We will not accept late labs. However, if you submit to the autograder past the deadline, you will still get feedback on your work (even if you receive 0 points).

For example, say that you use two slip hours for project 1. Your partner for projects 2 and 3 used eleven slip hours for project 1. You both have an average of 17 hours leftover from project 1. If you and your partner use 30 slip hours for project 2, you will have a total of 11 slip hours for project 3. It's a good idea to conserve your slip hours!

Deadlines can be stressful, and we know that under extreme pressure, it becomes tempting to start rationalizing actions that you would otherwise yourself consider inappropriate. Perhaps you'll find yourself facing a 61B project deadline, and under all this stress you'll convince yourself that you're just going to cheat for the moment so you can get the points, and that you'll come back later and really learn the thing you were supposed to have learned in order to restore your karmic balance (I've heard something along these lines a few times).

This is a terrible idea. Obviously it's important to learn how to deal with deadlines, but far more important than that, giving into this sort of pressure under not-so-dire circumstances is going to do some damage to your moral compass. Someday, when the consequences are higher than potentially losing a 1/3rd of a letter grade, you may find yourself committing dishonest acts at the cost of someone else's livelihood or life.

Plagiarism on any lab or project will result in a score of -30 on that assignment, which will likely reduce your letter grade by several bins. A second instance of plagiarism on a homework, lab, or project will result in an F in the course. All incidents of plagiarism will be referred to the Office of Student Conduct, including carelessly leaving code up on GitHub.

The entire point of labs is to learn. In this course, we are emphasizing active learning and pair programming. For labs, you should feel free to collaborate with others however you choose, though keep in mind that greater independence (between pairs) is likely to give you a better learning experience (as long as you aren't totally stuck). Even though we will allow close inter-pair collaboration on labs, the code you share with your partner should still be your own work! Identical or near identical submissions from separate pairs will be treated as plagiarism.

By contrast, the projects were designed not just for learning (particularly how to be self-reliant in the context of large unfamiliar systems), but also for the dual purpose of evaluating your mastery of the course material. As such, they are intended to be completed primarily independently of any other pair (on your own for the first project), particularly when it comes to writing actual code.

For exams, we will be absolutely unforgiving. Any incident will result in a failing grade for the course, though Berkeley will let you retake 61B next semester. As above, all incidents of cheating will be referred to the Office of Student Conduct.

The golden rule of academic dishonesty is that you should not claim to be responsible for work that is not yours.

This is obviously open to some interpretation, and you'll be getting some help from instructors, the internet, other students, and more throughout the course. This is OK, and we hope that the class is an open, welcoming, collaborative environment where we can help each other build the highest possible understanding of the course material.

To help (but not entirely define) the bounds of acceptable behavior, we have three important rules for projects:

For clarity, examples of specific activities are listed below:

Permitted:

• Discussion of approaches for solving a problem.
• Giving away or receiving significant conceptual ideas towards a problem solution. Such help should be cited as comments in your code. For the sake of other's learning experience, we ask that you try not to give away anything juicy, and instead try to lead people to such solutions.
• Discussion of specific syntax issues and bugs in your code.
• Using small snippets of code that you find online for solving tiny problems (e.g. googling "uppercase string java" may lead you to some sample code that you copy and paste into your solution). Such usages should be cited as comments in your hw, lab, and especially project code!

Permitted with Extreme Caution:

• Looking at someone else's project code to assist with debugging. Typing or dictating code into someone else's computer is a violation of the "By You Alone" rule.
• Looking at someone else's project code to understand a particular idea or part of a project. This is strongly discouraged due to the danger of plagiarism, but not absolutely forbidden. We are very serious about the "By You Alone" rule!
• Working on a project alongside another person or group of people. Your code should not substantially resemble anyone else's!

Absolutely Forbidden:

• Possessing another student's project code in any form before a final deadline, be it electronic or on paper. This includes the situation where you're trying to help someone debug. Distributing such code is equally forbidden.
• Possessing project solution code that you did not write yourself (from online (e.g. GitHub), staff solution code found somewhere on a server it should not have been, etc.) before a final deadline. Distributing such code is equally forbidden.
• Posting solution code to any assignment in a public place (e.g. a public git repository, mediafire, etched into stones above the Mediterranean, etc). This applies even after the semester is over.
• Working in lock-step with other students. Your workflow should not involve a group of people identifying, tackling, and effectively identically solving a sequence of subproblems.

We have advanced cheating detection software, and we will routinely run this code to detect cheating. Every semester, we catch and penalize a significant number of people (71 cases in Spring 2016). Do not be one of them. If you find yourself at such a point of total desperation that cheating begins to look attractive, contact one of the instructors and we can maybe help somehow. Likewise, if 61B is causing massive disruption to your personal life, please contact us directly.

If you admit guilt to an act of plagiarism before we catch you, you will be given zero points on that assignment, and we will not refer your case to the university administration.

Obviously, the expressive power of Java is a subset of the English language. And yes, you can obviously obey the letter of this entire policy while completely violating its spirit. However, this policy is not a game to be defeated, and such circumventions will be seen as plagiarism.

Some course information material derived from Paul Hilfinger's CS 61B handout and Josh Hug's CS 61B syllabus.