Two projects can look equally unfinished while failing for completely different reasons. One student has confused x and y. Another has a collision rule running only once. A third understands both but is attempting a feature too large for the remaining time. Coding support depends on seeing the difference.
Projects are not identical worksheets
Once students make choices, projects diverge. Sprites have different sizes, maps have different boundaries, and students organize scripts differently. A generic instruction such as 'check your movement' may be too broad to help.
In a small group, the instructor can ask the student to predict one key, inspect the relevant coordinate, and compare the result. The help stays attached to the student's actual work.
Waiting time matters
Getting stuck is valuable when the student has time to think and a path toward evidence. It becomes unproductive when a student waits too long without knowing what to inspect. Small groups reduce the delay between a precise question and useful guidance.
They also let the instructor notice students who do not ask. A quiet student may be carefully testing, or may have stopped making progress ten minutes ago. Those situations need different responses.
Advanced students need attention too
A student who finishes the core quickly should not receive a random pile of extra features. The next challenge should deepen the same idea: handle a boundary, make state explicit, compare two algorithms, or explain why one implementation is more reliable.
Small-group teaching makes it easier to select meaningful difficulty without turning the class into separate private lessons. Students can share a topic while working at different project depths.
Collaboration stays accountable
Students can help one another after trying independently. Explaining a condition or reading a test aloud can strengthen both students. The instructor can also see when collaboration becomes one student taking over another's keyboard.
School of Code is designed around small groups, but a final published maximum has not been set. The principle comes first: the instructor should be able to understand the actual project, not only deliver the front-of-room explanation.
What the instructor is watching
The important signals are often quiet. A student may repeatedly press run without reading the result, avoid testing a loss state, change three scripts at once, or understand the concept but struggle to name it. In a small group, the instructor can notice the pattern and ask one relevant question instead of delivering the same rescue to everyone.
Small groups also make demonstrations possible. Students can show a checkpoint, compare two solutions, and help a peer after first trying independently. The instructor can distinguish useful collaboration from one student taking over another's keyboard. This does not guarantee a fixed published group size; that operating detail is still being finalized. It explains why the school is designed around a human-sized group rather than maximum seat count.
The aim is not constant adult attention. It is timely attention that helps students return to independent work. A well-placed checkpoint can prevent twenty minutes of random changes; a patient pause can let the student discover that the variable never reset. Both decisions require seeing the learner and the system together.