Introduction and Logistics #

In this lab, you will compare your solution to Project 1 with 1-3 other students in your lab. The goal of this lab is to get an introduction into the code reviewing process and learn how to effectively explain and communicate their solution to others.

If you cannot attend your regular lab, you may attend any other lab instead, barring room capacity.

If you are physically unable to attend any lab at all, please fill out this exemption form by Friday, February 24th (02/24). We will be verifying each form submission manually, and those with invalid submissions will not be checked off. We will not be accepting any new form submissions after 02/24, and will be automatically checking off valid form submissions through Beacon during the weekend of February 25th (02/25).

If you have approved extensions for Project 1A or 1B that extend past the Lab 6 deadline (02/24), Do NOT fill out the form. You will automatically receive a 5 day extension for Lab 6, and please come to future Lab section or Office Hours to get checked off.

Please find the Lab06 FAQ here. Note that this lab is due Friday, February 24th. Good luck!

Setup #

Follow the assignment workflow instructions to get the assignment and open it in IntelliJ. This assignment is lab06.

git pull skeleton main -X ours
git commit -m "resolved lab merge conflicts"

LinkedListDeque Overview #

Your TA will start the lab by giving a brief overview of the staff solution to LinkedListDeque.

LinkedListDeque Peer Review #

Group up with 1-3 other students and compare solutions. Don’t be afraid of meeting someone new! Programmers in 61B vary widely in their level of experience and comfort with programming. Our goal here is to help each other get better. Please be nice, and don’t feel bad if your solution is less elegant or even downright ugly. I’ve certainly written incredibly ugly, inelegant code! Why here’s a 1600 line monstrosity I wrote in 1997, and a video demo of it running if you’re curious what it does. knaveos will not be on the midterm.

Avoid the temptation to explain exactly how your implementation works to your partner. Instead focus your discussion on more specific questions. Some suggested questions are listed below:

1. What was the most annoying bug you had and how did you fix it? Did you use the debugger? Did you fix it by adding special cases? Did you do any change-and-pray (where you make a tiny change and hope the AG approves)?
2. Did you end up cutting anything out to make your code simpler? If so, what?
3. Do you have any special cases in your code?
4. Do you have any private helper methods?
5. Does your code repeat itself anywhere? Would private helper methods have helped?
6. Were you able to call or reuse code anywhere?

After discussion, fill out self_reflection.txt with your own self reflection.

ArrayDeque Overview #

Your TA will go over the ArrayDeque solution.

ArrayDeque Peer Review #

Now, pair up again and discuss your ArrayDeque solutions as you did for LinkedListDeque. Fill out your self_reflection.txt as you did for LinkedListDeque. We recommend that you talk to different people than you did for LinkedListDeque, but it’s OK to stick with your group for ArrayDeque.

Self Reflection and Submission #

Make sure you’ve filled out at least 4 questions each in self_reflection.txt for LinkedListDeque and ArrayDeque. Ask a staff member to check your self_reflection.txt and give you the magic word to put in magic_word.txt. Push to GitHub and submit to Gradescope.