Getting your learners writing code with nothing installed

The quarter hour lost at the start of every session

Across a training day, installing a development environment rarely costs less than twenty minutes. Above all it costs attention: while you help three people, the others wait, and the group scatters before a single line has been written.

The problem repeats every session, and it gets worse in three very common situations:

• Locked-down machines. In a training centre or a company, learners are not administrators of their own computer. No installation is possible without going through an IT department.
• Mixed hardware. Three versions of Windows, two Macs, one Linux laptop: the same procedure never works everywhere.
• Short courses. Over half a day, twenty minutes of installation is close to a tenth of the total time.

An editor that lives in the browser removes that step: the learner opens a link, or scans a code, and writes.

What runs in a browser, and what does not

Be clear about the scope, because that is where disappointment starts. A browser runs the fundamentals of a language very well, and nothing that touches the system.

What works covers the essentials of an introduction: output, keyboard input, conditions, loops, functions, lists and dictionaries, error handling, and the first notions of objects. In practice, the whole programme of the first three or four days of a Python course.

What does not work comes down to anything outside the sandbox: graphical interfaces, reading and writing files, network calls, and external libraries that would need installing. A program that draws a window or reads a CSV file needs an installed environment.

That limit is not a flaw in the tool: it is what guarantees that a learner's program touches nothing beyond their own page.

Demonstrate, then let them work

A good coding session alternates two phases, and the second arrives earlier than you think. As long as the trainer types alone, the group disengages: learners copy without thinking, or wait until the end to start.

The arrangement that works best gives both at once: everyone has their own editor and works in it, while seeing yours alongside, live. You write an example, it appears on their screen; they borrow from it, adapt it, get it wrong, start again — without having to choose between watching and doing.

Three habits make this setup more effective:

• Write the example in front of them, typos included. Watching a trainer fix an indentation mistake is worth more than perfect code appearing all at once.
• Let them hide your screen when they want to concentrate. The goal is not that they watch you, it is that they write.
• Take the room back for key moments. A button that puts everyone in read-only beats asking for quiet three times.

The endless loop, and the other beginner traps

The first badly written while always turns up, often within the first quarter hour. On a normal machine it freezes everything, the learner panics, and you lose the thread of the session for three minutes.

An environment built for learning stops those programs on its own after a few seconds, with a message explaining what happened. Tell your learners at the start: knowing they cannot break anything makes them markedly bolder, and boldness is exactly what you want at this stage.

The other classic traps are matters of teaching more than tooling:

• The error message nobody reads. Take the time to read one error aloud, in full, the first time. The habit sticks quickly.
• Confusing printing with returning. It deserves an exercise of its own, early in the progression.
• Copy-paste without understanding. This is the strongest argument for giving everyone their own editor: you copy less readily when you have to run your own program.

Collecting everyone's work

A coding session produces nothing lasting if the work disappears when the tab closes. Yet that is what happens with most online sandboxes, where the code lives in the browser and nowhere else.

Two uses alone justify collecting the files. First, marking later: reading what each person produced, calmly, tells you more about what the group absorbed than a tour of the room. Second, continuity: picking up next week where the learner stopped, rather than starting over.

In practice, every participant should be able to download their file with the right extension, and the trainer to collect the whole group at once. It is a small usage detail that changes the relationship to the work produced: what you can take away counts.

What this approach does not replace

An online editor is a classroom tool, not a working environment. It would be dishonest to suggest it is enough to train a developer.

As the course progresses, your learners must learn to install an environment, use a terminal, manage dependencies and a version control system. Those skills are part of the job, and putting them off too long makes the transition brutal.

So the right place for the online editor is at the beginning and in collective moments: the first sessions, demonstrations, short exercises, groups on locked-down machines. The rest of the time, installation becomes a learning objective in its own right — at a chosen moment, not one forced on you at 9:15 on a Monday.