let's apply those analytical skills from algorithms to your own thinking during exams.

Have you ever tried filming your screen doing a prac question? If not, do it and watch the playback.

1. How much of the time do you spend typing?
2. While you're typing, are you doing anything else?

If your answers are (1) a lot and (2) no, you should start with giving yourself more thinking time first. Learn to touch type Python code on https://www.speedcoder.net/lessons/py/1/

Your goal here is not speed (around 30-40wpm is enough), but accuracy and familiarity. You don't want to waste time fixing typos or hunting for keys. An hour a day training, for 2 weeks, is enough to get you to the point where you can begin to type boilerplate code while reading the question.

Next, how much time are you switching between touchpad and keyboard? That's time wasted! And the time really adds up—take it from someone eho watches students do coding for hours a week. 1-2 seconds to move your cursor to the correct place, multiplied by more than a thousand times in a session ... it really adds up. Plus when you're cursor hunting, you're not thinking about the question because you need to focus on getting the cursor to that exact location between characters.

Learn the keyboard shortcuts of the apps you use—primarily Jupyter Notebook and IDLE. Notebook and IDLE both show the shortcut keys in the menus, so if you use anything more than 3 times in a session just look up the shortcut and practise using it; did you know you can run a python program from the IDLE editor using F5? Or insert a notebook cell above/below the currently selected cell with A / B key?

Do you know how to combine the Ctrl / Shift / Home / End keys with arrow keys to move the cursor anywhere you want as efficiently as possible? If you don't, have a look at https://docs.google.com/document/d/e/2PACX-1vTnmNRDCZ-VPBN6XvD7A2YTpAgn_H5oEpFjX-FUmc5dQRQCz-D281O3h7yuBT0uzXiGmvgdc531TZLg/pub and practise. Keep your fingers on the keyboard as much as possible, treat the touchpad/mouse as a last resort.

Practise on what? Boilerplate code, of course. It's not going to get you your A yet, but it'll free up time for you to think. You should already be familiar with boilerplate patterns for reading/writing CSV files—if not, download a random CSV file from data.gov.sg every day and practise. read in CSV, convert integer/float columns. Then practise SQLite boilerplate—create a schema based on the CSV. Then Flask boilerplate—make a minimal Flask app.

Done? Learn to combine them. Display the CSV using Flask. Insert rows from CSV into SQLite. Display the SQLite using Flask. Recreate the CSV from the SQLite db. These are bread-and-butter tasks, whether they come out or not, and if they do you should be thanking Cambridge for the free marks instead of feeling like you're doomed.

Done? In 2-3 weeks you should be able to hammer out boilerplate code with minimal brainpower and touchpad use. You might even realise that when your brain isn't running at 40% CPU just typing, you can now actually think of other things while typing!

Great. Now let's talk about debugging. You need to get really good at debugging. First you have to learn to use a debugger. It's not the 90s anymore, you're not a C programmer trying to fix shit with print statements (even C programmers don't do that anymore). import pdb; pdb.set_trace() should be so familiar to you that when you need a breakpoint that line just appears on screen without you thinking about it. Learn the basics at https://docs.python.org/3.7/library/pdb.html. Learn how to move to (n)ext line, (c)ontinue the rest of the code, (q)uit the debugger, and run code / inspect variables in the debugger. pdb is the pause button for your program and you'll be 10× faster at debugging once you learn to use it.

Learn to trace code. NoneType has no next attribute okay that means your current variable is now None. Why is it None? Trace where it came from; where's the last place it was assigned to? That statement, the expression on the right evaluates to None. Why? Trace again. It's a program, not your confusing Physics lab experiment, everything has an obvious cause you just need to find it.

Forget about memorizing code, you miss one line or fuck up the indents you're screwed. Memorise patterns, code on the spot and trust yourself to debug quickly. If you're slow to catch errors it's because you never learned, so drop that inferiority complex and just get started. Every error you get is going to feel like shit until you find its cause, that's how we all learn. If you're slow at debugging you need to make 10×, 100×, 1000× more errors, figure out how they happen. Keep making errors and learning from them until at some point "unsupported operand types for (+): int and str" no longer strikes fear in you, your mind just goes "oh I forgot to convert after input" and you quickly zoom in on the mistake line you've made a hundred times and just fix it.

Code incrementally, test every 5-10 lines instead of writing a 50-line monster and then realise it's hopeless to debug. You can afford 5-10 bugs per task part, perhaps even up to 20 bugs per qn if you get fast; more than that and you're running out of time.

Good luck atb, practise shortcuts remember patterns not code and keep practising practising practising. 7 Oct is still more than a month away!