General Advice

TODO formatting.

Keep practicing problems! Don't panic Do a side project of your choice. Organize your notes before the exam Even if you think you can do a problem, try it anyways to make sure. If it's not difficult, you're doing something wrong.

Step through your code and try a few edge cases You don't pass 100% of the classes you don't take.

Move out of your comfort zone. Always make sure every requirement of a spec is accounted for. Get a good night's rest the night before your test. If a problem looks trivial, double check if you've read the spec correctly

Whenever you encounter a problem that looks long and scary, close your eyes, take a deep breath, and clear your mind before reading it. This way, you won't misread a sentence and miss an important detail. Get the fundamental concepts right before jumping into solving problems which test you on that concept Don't take too much stress! CS is done best with a relaxed mind Double-check and triple-check to make sure you don't do the wrong thing and lose a big chunk of points. Or you could just pray.

Be careful and read their code slowly. Smallberg and Nachenberg purposely put a lot of errors into their code to make the problems more difficult. Knowing how code functions with incorrect code is pretty important for their tests Practice makes perfect. There are many many resources for CS31 and CS32. Use them wisely.

Try to think as logically as possible. A computer can't think, it only follows directions. You know that person sitting next to you in class. They do they same projects as you. Maybe you can help each other Write some helper functions

Skip the harder questions, and come back to them at the end Read the question carefully before beginning to code: you don't want to be solving the wrong problem Practice coding on pen and paper. Don't rely on IDEs. You will learn much more about the nitty-gritty of the syntax.

Don't be afraid to take a break on one problem and move on to the next! A fresh perspective after 10 - 15 minutes can really help! Think for some time before writing any code Use visuals/diagrams to map out your tracing/thinking Your grades don't matter as much as you think Don't try to trace non-trivial code in your head. Always write down the values of variables and any changes they undergo.

Set aside twice as much time for your projects as you think you need.

Spend more time on planning out the structure of your code before you start to write it.

Always make sure you document your code as go along. Not everybody thinks the same way you do, and it's no fun trying to figure out what your code does when you need to review it a week later. Work on problems on paper; go through code line by line to see what's going on Start projects early, always ask questions if you don't understand something during lecture or discussion. Work on your own, because you will not be able to ask your friend for help on any exams. Go to the UPE Clubhouse (Boelter 2763) for help if you get stuck and need a hint. Get help early! Put in a good effort to solve the project/problems yourself, but in the words of Carey Nachenberg, if you find yourself "spinning," you will waste a lot of time when help is available.

When writing code, always make sure to check for edge cases. When doing cs31 or 32 projects, test your code in increments (like write one function or part of one) and make sure it works. Or else if you change a ton of stuff and test and it fails, you may not know which part is causing the bug = start over = sad Find a rubber ducky. Now explain your buggy code to said ducky. Ducky will tell you what's wrong. When there's some concept / data structure / behavior that feels weird, but you know is correct, search around a bit to see why / how it acts that way. This might help you understand it more. Spending some extra time/effort to learn about how to efficiently use your debugger can save you lots of time in your programming assignments! Be wary of off by one errors when coding arrays and loops. Write out your thought process before you actually start coding. For example, pseudocode or a general flow of a function's algorithm will help make actually writing the code a lot easier. Write in a test-driven fashion. By testing every peice of code you write as you go, you can avoid time consuming debugging and quickly find assumptions you made about your code that turned out to be incorrect. Just because you know how to implement a piece of code, does not mean that you should rush through it. Even if you have the big picture, it's easy to make small, algorithm-breaking errors, especially when you're hurrying. Slow down, and do it right the first time. Remember the difference between a reference and a pointer. Remember the order or construction and destruction for a class. What are the bitwise properties of a number that is a power of 4? Assuming you are prepared, no problem on a CS exam is designed to be impossible. Do not feel anxious; rather, always try to solve the problem instead of thinking that a nontrivial problem is impossible. Notice that difference. Run through every problem step by step, even if it seems trivial. If you don't look into every detail of an algorithm, there will likely be small errors, such as out-of-bounds violations, that you might not notice. Edge cases ... always remember to look for them. Get into a group, and each of you try to come up with a few that might just break your program. If all else fails, come to me, and I will do my best to break your program or give you my edge cases which will break your program. When thinking about an approach to a problem, try to come up with specific test cases first, even really basic ones. Think about how can I get from the input to the correct output? Do I see any patterns in these test cases? If you're stuck on a problem, it will help a lot more than simply trying to come up with a general solution first or going straight to writing the code in helping you get to the solution. Practice pointer arithmetic (CS31) and recursion (CS32) Start your projects early! Work incrementally. Solve the simplest problems first and build off your solutions. Also, bring multiple (sharpened!) and a good eraser for the midterms/finals, you're gonna need it.

For tests, always remember that each question must be testing something. If you ever feel like a problem is too easy or useless, you may be overlooking something. However, also don't overthink the questions too much. If you've found quite a few points that the test may be checking your awareness of, you're probably good. Learn how to write comments on your code effectively. Not only will it add organization to your code, it also makes debugging your code easier for you and your TA. Go to lectures.

Don't let your memes be dreams. Yesterday, you said tomorrow. So JUST CODE IT Relax, get a good night's sleep, and eat a healthy breakfast! Don't overthink problems! They are designed to be tough, but they aren't designed to be trick problems and are rarely overly complicated. Make sure to get a good night's sleep before exams. Don't attempt to trace a loop in your head! Write out test cases and run them through every line of the code so you won't miss anything! Diagrams are always good

Don't be lazy once and skip class! You'll skip more classes after that if you do. Develop and test programs incrementally Pratice! Also, get good at debugging, as it will be a useful skill to retain for the rest of your life. Don't put everything on your cheat sheet

Write programs out by hand. You won't have your computer to the dirty work on a test! Having an example program on your cheat sheet will help with easing your mind when you think you have incorrect syntax!

Make sure the code your write is clean and easy to read Don't rely too much on syntax checker provide by IDE When determining the accuracy of your code, step through it mentally before running it. This is a good habit to develop as it will test your understanding of what you have written and the language itself -- and this will certainly pay off on exams! Don't spend too much time coding! Remember to take breaks to do other things you enjoy, and come back to the problem refreshed! Do practice problems before exams. Sleep > studying the night before. Also, when writing code, try to go at a deliberate pace, and mentally walk through it before hitting run. Blazing through the coding process won't help if you spend 5 hours trying to figure out what crapped out in your buggy code. Writing deliberately saves you time and boosts your understanding. Think before you start coding

Sleep~ Don't start coding immediately, have a clear idea of what you're doing before you write your first line start projects as early as possible, last minute is not going to work! test bits and pieces of your code as you move along to debug small errors. Let's presume that you've been graciously handed a spec for a function. Before the thought of writing code even begins to consider the possibility of crossing your mind, WRITE YOUR TEST CASES FIRST! Including, of course, every possible edge case you can dream of, and then some. Then, by all means, code along merrily on your way. Always start early on projects and reviews Try to remain calm even if you can't get the solution at first and just remember to think of examples and trace through your code! Practice writing code by hand! You are much more likely to make mistakes when handwritten because typing code becomes muscle memory.

Go through the code on the exams very carefully and don't be afraid to mark up your exam to help you keep track of variables Don't be afraid to ask TAs or professors for help if you need it. "When figuring out where to start, always start out with pseudocode! For the easier problems this might not seem necessary, but for the harder ones, doing so will immensely help you develop your code." Always understand what you want to code, before you start writing/typing it out. Don't forget to eat and sleep

Make sure to take time to think before writing code. "Drawing a diagram is often helpful to visualize the data structure.

Always pay extra attention on edge cases.

For most of the time, cheatsheets are useless, so don’t spend too much time on writing a perfect cheatsheet." If a problem might become confusing, organize your solution on paper. When practicing, make sure to really write full codes on paper, and then try to compile it.

Break down a problem into parts before you start wrting code. Don't forget to comment your code!

"Work with concrete examples first if nothing comes to mind.

" Don't get overwhelmed if the problem seems too big at first glance -- find your footing with simpler examples first! Take it one step at a time. test as you go Don't forget to write your name on the top right of your exam if you have prof Smallberg

Feel free to use all the tool you have. You can introduce new variables and items.

Make sure to pay special attention to specific words in the problem statement.For example, if a problem specifically tells you that you are a given a sorted list, then that will probably make a difference in your final solution.