03 / The logic of possibility
Computer
Science
Turn curiosity into working code. Learn to reason, debug, and build with an engineer’s perspective, whether you’re starting from zero, studying CS, or changing careers.
Try the algorithm lab Find your starting point
School · University · Adult learners Let’s talk about your goals
7 stages, from unplugged coding in grade school to college projects
6 languages & tools: Python, Java, JavaScript, HTML & CSS, C++, SQL
55 minutes per session
Try it
Programmers who can run code in their heads debug in minutes instead of hours. These two exercises train exactly that.
Pick an algorithm and step through it. Watch which line of code runs, and count the comparisons — that count is what “efficiency” really means.
Turn on JavaScript to run the visualizer.
Pencil check: in sessions we do this with numbered index cards on the table first. Sort eight cards by hand using bubble sort and count your comparisons — then predict how many it takes for sixteen.
Don't run it — read it. Work out on paper what this program prints, commit to an answer, then check the line-by-line trace.
total = 0 for n in range(1, 5): if n % 2 == 0: total += n print(total)
| n | n % 2 == 0 ? | total afterwards |
|---|---|---|
| 1 | no — skip | 0 |
| 2 | yes — add 2 | 2 |
| 3 | no — skip | 2 |
| 4 | yes — add 4 | 6 |
| loop ends (range stops before 5) → print(total) | 6 | |
Where AI fits: once you can trace it yourself, ask an AI to “write five tricky variations of this loop” — and predict each one on paper before running it.
Personal plan
No two beginners get stuck in the same place. The first session is a diagnostic that finds the exact gap — then we write a plan for the student that changes as they do.
In the first session we trace a few small programs together and find the one idea that's actually missing. You get the plan in writing, and we rewrite it as the student grows.
Pace, examples and practice are chosen for this student: a stats tracker for their team, a quiz about the music they love, a mod for the game they actually play.
Online or in person, evenings and weekends, weekly sessions or exam-season sprints. Free rescheduling up to 12 hours before, and a short session note afterward.
One-on-one by default (small groups or siblings only if you ask for one), and no rotating cast. The person who found the gap is the person who closes it — and who knows the student's code line by line.
First three sessions
First three sessions
First three sessions
Illustrative examples — every real plan starts from the student's own diagnostic.
Real-world CS
Lessons are taught by trained professionals with in-industry experience, so the examples are the real ones: how software is actually built, tested and shipped — and how industry checks whether AI can be trusted.
Real teams don't ship code because it looks right. Students write the test first, watch it fail, then make it pass — the habit behind every app that works on a Monday morning.
Read the trace, form one hypothesis, change one thing, run it again. It's the same loop engineers use on real production bugs, so it's the one we practise.
Commit messages that explain why, branches that keep experiments safe, reading someone else's code before changing it, and pulling real data from an API — then handling the day it comes back broken.
Before a team trusts a model or an AI assistant, they test it: baselines, data it has never seen, deliberate attempts to make it fail. Students learn to ask the same questions.
Taught by Mohammed Arafat — a senior software engineer with 10+ years in industry, who evaluates and red-teams AI systems as part of the job. Meet your tutor
The track
Computer science moves fast at the start and then stacks: every concept here assumes the ones before it. Here's the full track, from a grade-schooler's first unplugged puzzle to college-level work.
Where grade-schoolers meet computer science without a screen in sight: algorithms written on paper, loops acted out with cards, “robots” made of people following exact instructions — then Scratch, once the ideas are theirs.
The on-ramp for older beginners, and the one that decides whether the student thinks coding is "for them". If Stage 1 was skipped, we start unplugged — instructions on paper, robots made of people — then block-based tools, then text as soon as they're ready.
Python for most beginners — its syntax reads like English and the feedback loop is instant. JavaScript if the student wants to build websites; Java if AP CS A is coming. Whichever we pick, the concepts transfer.
The mental leap that trips up most students: thinking in objects with responsibilities rather than lists of instructions. We sketch class diagrams on paper first — a deck of cards, a bank account, a game entity — until the design questions feel natural.
Exam-focused preparation for both AP tracks. The AP CS A free-response questions are typed in the exam app with no compiler, autocomplete or syntax checking to catch mistakes — so we draft them by hand first, then practise them under exam timing until it's boring. For CSP, the Create task and its written responses.
The course every CS major's later work stands on. We make each structure concrete — draw the array, walk the tree on a whiteboard — instead of memorising definitions, and practise reading running time intuitively.
The practical layer: version control without fear, debugging as a method rather than luck, and using AI coding assistants the way professionals do — reviewing every suggestion, writing tests, and owning every line that ships.
Half-finished game, broken app, assignment due Friday and nothing compiles? Bring it. We triage what's salvageable, decide what to cut, and build back only what the deadline actually needs — with the student at the keyboard.
Python, Java, JavaScript, HTML & CSS, C++ (intro), and SQL basics. We work in the real environment — VS Code or IntelliJ, the terminal, git, and the debugger — so a first job or college course feels familiar.
Specialised track
A separate, specialised track for advanced high-school and college students. They build small models themselves — and learn the checks that stop people fooling themselves with those models.
Training setTest set · held out
# the number only means something next to the baseline
Features, labels, and why the training set and the test set must never mix.
Why a model has to beat a simple baseline before it means anything — and how leakage and overfitting make a bad model look brilliant.
In Python with scikit-learn, then PyTorch intuition for how neural networks learn — small enough to understand every step.
Accuracy against a baseline, never in a vacuum: a 67% fight-outcome model matters only because a coin flip gets about 50%.
How AI assistants fail, why guardrails matter, and what bias and privacy mean when real people's data is involved.
We never use AI to help students cheat or to complete assignments for them. We teach AI as a holistic learning partner — to explain, to quiz, to critique work the student wrote — always toward the shared goal of real learning, and always within the school's rules.
The track is taught by an engineer who designs AI evaluation and AI-security test suites and red-teams AI assistants professionally — so students learn exactly where AI helps and where it fails.
Test prep
Exam-specific practice for the tests CS students actually sit, rehearsed the way they're graded. For AP CS A, that means writing correct Java with no compiler to catch you — so we draft it by hand first, then time it under exam rules.
Java free-response questions written with no compiler or autocomplete, 2D arrays, ArrayList and recursion — timed until the clock stops being scary.
The multiple-choice exam and the Create task with its written responses — planned early and written in the student's own words.
Tracing, recursion, Big-O and data structures on paper — the format most university CS exams still use.
Arrays, hash maps and recursion, solved at a whiteboard while explaining the approach out loud.
A real past paper under real time, so we see exactly where the points are lost.
We rebuild only what the diagnostic exposed, one topic at a time — not the whole course again.
Full timed practice under exam rules — on paper, by hand, wherever the exam is on paper.
Paper & AI in CS
AI assistants can write a lot of code. They can't tell you whether it's the right code. That judgement comes from tracing, drawing, and debugging by hand — so that's where we start, and AI is where we finish.
We never use AI to help students cheat or to complete assignments for them. AI is a learning partner here: it explains, it quizzes, it critiques code the student wrote — always toward real learning, and always within the school's rules.
Inside a session
The student drives the keyboard — always. We ask questions, point at lines, and think out loud alongside them, but the typing is theirs, because the muscle memory is half of what we're building.
We debug by reading the error message together and forming a hypothesis, the way working programmers do. No "just change it and see", no copy-paste answers. Every line in their code is a line they can explain.
Before running anything, we write down what we expect to happen. That's the hypothesis.
Error messages are the compiler helping. We learn to read the first line, then the first line that matters.
One change at a time, with a prediction first. This is the habit that separates stuck from working.
The student tells us what the fix did. If they can say it, they'll remember it; if not, we draw it out.
Questions
Anywhere they're comfortable. We usually start with a tiny program that does something visible within twenty minutes — a guessing game, a calculator, a drawing — because early wins matter. Then we grow it together.
More than ever. AI writes plausible code quickly — and plausible isn't the same as correct. The people who get the most from AI are the ones who can read, test, and fix what it produces. That's exactly the skill we teach.
For beginners, mostly not — fundamentals come first, like learning arithmetic before using a calculator. As students advance, we bring AI in deliberately: explaining errors, generating tests, reviewing suggestions line by line. Always within your school's rules.
Python, usually — forgiving syntax, used everywhere. But the right first language is the one that keeps the student typing: JavaScript for websites, Java if AP CS A is on the horizon. The concepts transfer.
Yes. Game scripting uses real languages and real concepts: variables, functions, events, state. If a game gets the student writing code, it's a great on-ramp, and we steer it toward general skills as we go.
Almost certainly not. Any laptop from the last decade handles introductory programming fine — and plenty of our best work happens on paper anyway. We'll set up the free tools together in the first session.
Keep exploring
Drag sliders to reshape a parabola, then solve a word problem pencil-first.
Tag the parts of a real paragraph and watch a thesis get revised in three drafts.
Why we teach on paper — and how we teach AI as a tool. Try the "tool or crutch?" quiz.
Next step
A link to the project, a pasted error message, or just "they want to learn to code" — any of these is enough. We'll reply within one business day.