VS Code Live Share
One file, two cursors — we type in the same editor at the same time.
// how_a_python_session_works
Anatomy of a Python session.
One shared editor, two cursors, your hands on the keyboard. This is what an hour of 1-on-1 Python tutoring actually looks like — including the part where the code breaks, because that part is where you learn to debug.
- subject: python
- format: code_along
- editor: shared
- repo: yours_to_keep
Your first session is free. No card.
// tracebacks_read_together
The error message is the lesson.
Most tutoring hides the breakage. A Python session runs toward it: we run your code first, read the traceback bottom-up out loud, and fix the line you actually hit — so next time, you can do it without me.
- You write the code, not me. We open one private repo in VS Code Live Share and you drive the keyboard while I steer — refactoring functions, fixing the traceback line you actually hit, and committing as we go.
- Real errors, read together. When something breaks we read the stack trace from the last line up, name the exception, and trace it to the exact statement — debugging as a teachable skill, not a magic fix.
- You keep the repo. Every snippet, helper and comment we write stays in your GitHub afterwards — a growing reference you own, not slides you forget.
debug.py
// the_60_minute_hour
What a real python hour looks like.
The same deliberate rhythm as every session — tuned to how python is actually learned.
0:00
Name the hour’s target
A failing script, an assignment that won’t pass its tests, a concept like decorators that refuses to stick, an interview on Friday. The hour is built backwards from that one thing — not from chapter 4 of a syllabus.
one target, set in 2 min0:05
Run your code, watch it break
We run what you already have, exactly as it is. The traceback — or the wrong output — tells us precisely where your mental model and Python’s disagree. That’s the gap we spend the hour closing.
the traceback finds the gap0:15
Live build, your keyboard
The core of the hour in VS Code Live Share: you type, I steer. We fix the bug, then refactor so you understand why the fix works — renaming, extracting a function, adding the test that would have caught it.
you drive, I steer0:40
Solo rep
You take a sibling problem — the same bug-shape in a different function — and fix it alone while I watch quietly. If the method didn’t transfer, we loop back now, not next week.
proof it stuck0:52
Commit & recap
We commit the final state, restate what changed in your understanding, and I note one or two things to practise. The written summary follows by email; the repo stays yours.
committed + summarised
// the_toolkit
Four tools. Nothing to install.
Everything runs in the browser, and everything we make stays yours afterwards.
Private GitHub repo
Everything we write lands in a repo that stays yours after the session.
Python in the browser
Zero install for your first session — we add local tooling only when you need it.
Written summary
What we covered, the takeaways, what to practise — after every hour.
// honest_answers
Python questions, answered straight.
The things people actually ask before their first python session.
Do I need Python installed before my first session?
No. We can run Python live in the browser, so your first session needs nothing but a laptop, a microphone and a modern browser. When your goals call for a proper local setup — Python, VS Code, virtual environments — we do that installation together in a session, because setting up an environment correctly is a lesson in itself.
I’m a complete beginner — is live coding intimidating?
It’s designed not to be. You type at your own speed, nothing happens on a screen you can’t touch, and we start with programs small enough to hold in your head. Most beginners find that writing three lines themselves beats watching someone else write thirty.
Can we work on my real project or my course assignment?
Yes — your real code is better session material than any toy example. For graded coursework there’s one honest rule: I teach you the method and debug alongside you, but I don’t write your submission for you. You leave able to explain and reproduce every line, because you wrote them.
What Python topics can a session cover?
Anything from first principles to working-engineer practice: fundamentals and data structures, functions and OOP, scripting and automation, working with files and APIs, pandas for data tasks, debugging and testing habits, and interview-style problem solving. The Python tutoring page lists the level ladder in detail.
What happens to the code after the session?
It stays in your private GitHub repo, with the commits we made together, and the written summary references it. Over multiple sessions the repo becomes your personal reference library — searchable, runnable, and written in your own style.
// start_here
Bring a real python problem.
The fastest way to understand a session is to have one. Pick the thing you’re actually stuck on and we’ll work it together — no slides, no script.
Your first session is free. No card. Cancel any time.