Workshops
What Happens In A Saturday Coding Class
Families ask us a version of the same question every time a new session opens: what is my kid actually going to do for three hours on a Saturday morning. It is a fair question, and the honest answer is less dramatic than the word coding suggests. A workshop day is mostly setup, small decisions, and a lot of reading error messages out loud. This is what the morning looks like from the door to the last laptop closing, and what the students walk out having built.
Luma Lab · July 18, 2026 · 5 min read
The first hour is not about code
Nothing useful happens until every student has a machine that works, an account they can get back into, and a folder they can find again next week. That sounds trivial and it is the single biggest predictor of whether a beginner comes back. A student who spends week two hunting for the file they made in week one learns that computers are hostile. A student who opens their folder and sees their own work waiting learns that computers keep promises.
So the first stretch of a Saturday is deliberately unglamorous. Laptops get handed out and numbered. Everyone writes their name and their file path on an index card that stays with the machine. Passwords get recorded somewhere a twelve-year-old can actually retrieve them, which in practice means written down and kept by the instructor, not stored in a browser on a shared device. Students pair up, because a beginner who is stuck alone stays stuck and a beginner who is stuck next to someone else asks a question within about ninety seconds.
By the time the room settles, nobody has written a line of code and the morning is already working. The room knows where things live.
How a first project gets chosen
We do not hand out a project. A student who is building a page about a topic an adult picked will abandon it the moment it gets hard, and it always gets hard around the third hour. A student building a page about their own basketball team, their church choir, a game they play, or a cousin's birthday will push through a broken stylesheet to finish it.
The constraint we do impose is scope. A first project is one page, with a heading, two or three paragraphs, one image, and one link. That is enough surface area to meet HTML structure, CSS colour and spacing, and the idea that a browser reads a file top to bottom. It is small enough to finish in a morning, and finishing matters more than ambition on day one.
The second constraint is that it has to be real. If a student says the page is about their little brother, we ask for his actual name and an actual fact about him. Placeholder text teaches students that the work is pretend. Real content teaches them that they are publishing.
Debugging as the real curriculum
The most valuable twenty minutes of any workshop is the first time something breaks. A tag goes unclosed, a stylesheet path points at a file that does not exist, a quotation mark gets typed as a curly quote by a word processor, and the page renders as a wall of unstyled text. Every beginner reads this the same way at first, which is as a verdict on themselves.
Teaching past that reaction is most of the job. We open the browser console in front of the whole room, read the error aloud in plain English, and trace it backwards to the line that caused it. The message is not an insult and it is not noise. It is the most specific help the student is going to get all morning, and learning to read it converts a mysterious failure into a two-word fix.
By the end of a term the strongest signal that a student has actually learned something is not the sophistication of their page. It is that when it breaks, they open the console before they raise their hand.
The four errors that account for most first-day breakage:
- An unclosed tag, which swallows everything after it into the wrong element
- A stylesheet link pointing at a filename that does not match the file on disk, usually a capital letter
- Curly quotation marks pasted in from a word processor instead of straight quotes
- A file saved as .txt instead of .html, so the browser shows the source code rather than the page
What families should bring and expect
Students do not need their own laptop, prior experience, or any software installed at home. Machines and accounts are provided for the session. What helps is arriving on time, because the setup block at the start is genuinely hard to join late, and bringing something to snack on if a three-hour morning is long for your child.
What we ask of families afterwards is smaller than most people expect. You do not need to know how to code to support a student who is learning. Ask them to show you the page on a phone. Ask what broke and how they fixed it. That second question is the one that makes the learning stick, because explaining a fix out loud is how a student finds out whether they actually understood it.
How a Saturday turns into a term
One workshop teaches a student that they can make a browser do something. A term teaches them that they can make it do something again on purpose, which is a different and far more durable skill. The arc across a run of sessions moves from a single static page, to a page with several linked pages, to a page that responds when you click it, and finally to a small project the student scopes themselves.
That last step is where most of the growth happens and where the instruction gets quietest. Students choose a problem, break it into pieces they can build, and discover that the hard part was never the syntax. It was deciding what to make and cutting it down to something that fits the time available. Those are the habits that carry into a job, a degree program, or the next thing they teach themselves, long after the specific tags have gone fuzzy.
It is also why we care about the same students coming back rather than about total headcount. A room of new faces every week produces a good photograph and very little learning. A student on their eighth Saturday, helping the person next to them find an unclosed tag, is the outcome the program is actually built for.
More from the lab
Inclusive Innovation · August 4, 2026
Why DC Needs Inclusive Tech Spaces
The case for physical, staffed, neighbourhood-accessible technology space in a city with one of the densest tech economies in the country.
Read the piece 4 min read