We highly recommend that you follow the advice of the Essentials of Time Management section from the Effective Strategies for Remote Learning, and create study blocks for this course. Remember to add them to your calendar.
A typical course expects that you will engage with the course material about 3-4 hours for per unit each week. Since this course is 4 units, you should expect to spend about 12-16 hours per week working on this course. Here’s the rough weekly breakdown of where your time might go:
- 3 hours of class time
- 1-2 hours reviewing course concepts / practice (it’s crucial to ensure that you are following along and catch unclear concepts early); best to schedule the review right after the class or on the same day as the class, so that you can write down the questions while the content is still fresh.
- 2-4 hours reading the book and working on participation/homework activities, preparing for quizzes; we recommend adding these review/study blocks to your calendar and treating them as an appointment.
- 1 hour of scheduled lab to work with mentors and/or your lab partner
- 2-4 hours outside of lab to finish the lab; make sure you work on it a few days before the deadline, so that you have enough time to get help if you get stuck.
- 1-2 hours participating on the forum / debugging / attending office hours (see the posted schedule)
In our course, each week covers roughly 1 chapter, and we have the following course activities: PAs (Participation Activities), CAs (Challenge Activities), LAs (Lab Activities).
|Async activity: Read the book, and work on/finish PA in zybooks before the first class meeting of the week; prepare/review the questions to ask; prep for quiz.|
|Tue||9AM: PAs, CAs||Class 1: Synchronous activities. Join the class via Zoom and be prepared to ask questions or ask for clarifications and additional examples, and to work with your classmates. Be ready for a possible pop-quiz.|
|Async activity: Work on/finish related CAs and LAs|
|Wed||9AM: LAs||Guided tutoring lab sessions: in small groups, students work on the LA (starting and/or finishing), resolving any lingering questions, reviewing materials with mentors. Students have until next week to finish/submit the LA.|
|Async activity: Work on/finish related CA and LA in zybooks|
|Thu||Class 2: Synchronous activities. Join the class via Zoom and ask questions or ask for clarifications and additional examples and/or review the quiz questions. Be prepared to work with your classmates. Be ready for a possible pop-quiz.|
|Async activity: Review concepts, work on/finish related CA and LA|
|Sat||Async activity: Finish the Weekly reflection - review the past week, reflect on your learning, provide feedback, note any lingering questions.|
|Sun||9PM: PA, CA, LA, Reflection||Async activity: Read the book, review concepts, and work on/finish PA, CA, and LA|
✨ Pro Tip✨ : Do not try to complete all chapter sections in one sitting! We recommend spending no more than 2 hours in a row reading through the sections and completing the activities in zyBooks. Your brain will get tired and will need a break. Trust us: even your prof cannot meaningfully work through this material for more than 2 hours, so save yourself some time and allow for at least a 30-minute break between the study sessions. Also, do not debug the same problem for more than 1 hour in a row. If you are unable to figure out why things are not working, ask for help on the forum or during the office hours. See more suggestions in the Workflow section below.
✨ Pro Tip✨ : We recommend reading through the sections and completing the PAs as you read. After you finished reading the chapter, come back to complete the CAs in each section. Please, finish most CAs before you join the labs.
In short: 📖 read carefully, ✍️ practice your understanding of concepts on lots of examples, ⭐ constantly review the material, ❓seek help when lost, have patience 🙏,, and enjoy the process 😃🤯✌️ .
- Read the syllabus and keep track of deadlines
- labs and homeworks are usually due on specific days at a specific time
- begin working on the assignments as soon as they are posted and try to finish it before the due date – this way you will have time to ask for help before the assignment is due.
- begin working on the lab as soon as it is posted (on Tuesday 9AM) and try to finish it before Friday – this way you will have time to ask for help before the assignment is due next week.
- Read the book
- the book shows diagrams, step-by-step visualizations and explanations
- do the practice problems to verify that you are understanding the concepts
- Do the homework yourself
- instead of just trying to answer the homework question, practice the concepts behind the question
- begin working on the homework as soon as it is posted and try to finish it early so that you have time to ask for help during class/open labs/office hours before the assignment is due.
- Attend classes
- after class, review the concepts we covered, take additional notes and/or run the code from class demos
- review the previous material before the next class, write down questions
- ask for additional examples if something is unclear during the class
- Ask questions in class and during open labs/office hours or post them on Piazza
- come to the TAs’ and/or professor’s office hours, even if just to say “Hi” and to see who else is there and what questions they have :-)
- attend open labs, even if just to work on the assignments in the lab
- if something is unclear, make sure to clarify it right away – concepts build on one another, so if you don’t (for example) understand how to write a function or correctly pass arguments into it, it will make it difficult to write helper functions and correctly use them.
- follow the Piazza guidelines to make sure you are using it effectively (e.g., check if someone already asked that question and then respond with a follow-up)
- follow the Piazza guidelines to phrase your questions in a way that makes it easy to respond
- Attend labs
- carefully listen to the demo/explanations by the TAs
- attempt to do most of the lab yourself
- start by reading the instructions and the docstrings for the functions
- work through any provided examples, preferably on paper
- ask yourself: do I understand how to get the correct аnswer or what is being asked of me? if not, ask the mentors for additional examples.
- develop an algorithm to solve the problem, preferably written in pseudocode and added as comments in your code
- if you get stuck, ask the mentors for help, looking at how they help you solve the problem and identifying concepts that you need to practice more
- review the concepts that made the lab challenging by running through examples in the book and/or homework
- begin working on the lab as soon as it is posted and try to finish it as soon as possible so that you have time to ask for help during class/open labs/office hours before it is due.
- Experiment, experiment some more, and play around with code
- Whenever you have a question, you should try testing it yourself
- Use http://pythontutor.com/ to run and visualize Python code in the browser (you can also use https://www.onlinegdb.com/ and switch the language to Python)
- Use the examples from class/homework/labs and come up with your own scenarios and see if you can write code for them (e.g., if the homework asks you to output values using a
range(0, 3), see what happens if you change the starting or the ending point; is there anything else you can change?)
- Change your answers if they were mistaken, but even more important, figure out why you were incorrect (ask during class/open labs/office hours/Piazza).
- Remember: learning computer science requires patience.
- When approaching labs and homework, you should expect to make mistakes and get confused.
- Learning any new skill requires patience and practice (remember the guitar / painting / swimming analogy?)
- You shouldn’t always expect to finish the lab in 50 minutes.
- There are lots of new concepts all the time and it can be hard to grasp how concepts connect. But with patience and diligence (and some help), you will be able to grasp the concepts and begin feeling comfortable with the concepts that just a week ago confused you.
- Learn to enjoy studying (How to Enjoy Studying).
Acknowledgements: Special thanks to April Sanchez and Noemi Rieber for contributing valuable suggestions and insights above.
This section is written for you as a reference that you can use throughout the course and beyond. Our goals in this section are to
- emphasize the importance of developing an algorithm/pseudocode first
- introduce elements of good programming style: documentation, variable names
- describe the tips to keep in mind for the programming workflow
We recommend arranging things for efficiency – when using a programming language, ensuring that the correct windows are simultaneously visible is a huge help!
Try arranging and resizing your windows so that you can see both the browser (these instructions) and your code window/text editor side-by-side. Note: To resize a window, you can double-click the top of the window and then move your cursor to the edge (until it changes its shape) and click and drag the window.
- It’s amazing how much more efficient you can be when you don’t need to click to different windows!
- For the artistically or cooking-show inclined: mise en place matters!
We highly encourage you to adopt an iterative program development, where you break up the problem into smaller parts, and then develop and test each part individually, iteratively improving and refining it.
For instance, if you need to count how many students from each class level are on the roster stored as a CSV, the first step of the iterative program development is to test that you can open and close the file, and read/print its contents. (See the note below, in the Workflow section, regarding working with large files). The next step is to figure out and note down what kind of processing you need to do, what values you need to retrieve, where to store what result, etc. Write down these notes as instructions that someone else can follow.
A set of instructions that we might later translate into code can be represented by pseudocode: it is not real code but provides the steps that can then be converted into any programming language.
Pseudocode can be used a way to represent an algorithm, which describes a solution to a problem.
When you approach a solution to any problem, try to apply the following steps:
- Write down the goal: what does the solution supposed to address or look like? Is it a stepping stone to another process, and if so, how do they align?
- What is given? E.g., what format is it in? Can/should it be changed to another format?
- What do you need to do? This section includes the pre-/post-processing steps, data structures you need to use, functions to call, etc.
- How to verify correctness? It is helpful to think critically of the results that you get, so how would you test that your solution is indeed correct? Can you compute things manually? Use another tool to compare the output?
Before you ever get to coding a solution, you need to come up with its components first. It’s too easy to get lost in the code without having pseudocode/algorithm as a roadmap.
Do not write all of your code all at once and then run it.
Write your code incrementally (remember, incremental program development), execute it frequently (e.g., every 3-5 lines). This will help to avoid or catch errors, especially, syntax and runtime errors.
Write down the steps of your pseudocode/algorithm first, before you start coding. Thinking through these steps will help you structure your code and make you realize what data/clarifications you might need.
If you are developing code to process a really large dataset, then make a small copy of that dataset (one that has just a few lines). This way you can rapidly develop your solution without having to wait for the entire file to be processed each time.
In programming, every little detail counts, so you must get into a habit of paying extreme attention to detail. Such attention can lead you to make fewer mistakes when writing code, writing code that’s correct, thus spending less time debugging.
✨ Pro Tip✨: Do not spend more than 1 hour straight trying to debug an issue. If you do not come up with a fix or a solution in that time, take a break! Get some fresh air and walk for at least 15 minutes; drink some water; stretch a bit. If you come back after a break and are not able to solve the issue within 30 minutes, turn to the resources that you have available to you - post on the forum or attend the office hours.
Do not underestimate the power of taking breaks to give your brain some much-needed rest.