Et didaktisk projekt der undersøger, hvordan man kan undervise i it-faglige begreber — algoritmer, datastrukturer, netværk og programmering — uden brug af computere eller skærme.
Tech uden Tech — forståelse først#
Jeg bad mine studerende sætte en Javaklasse sammen fra papirstumper på et bord.
De havde i frustration sagt, at de ikke kunne huske noget syntaks og ikke forstod kode. Ti minutter senere kravlede de rundt og ledte efter et semikolon der var faldet på gulvet, fordi deres kode ikke kunne “kompilere” uden det.
Det er Tech uden Tech.
Hvad er det?#
Tech uden Tech — TuT — er en didaktisk metodologi hvor studerende møder programmerings- og datalogi-koncepter gennem fysiske, analoge aktiviteter inden de åbner en computer.
Selvom det gerne må være sjovt, er det ikke ment som en leg. Aktiviteterne er nøje planlagt til at give de studerende en mental model af det, der senere skal foregå digitalt i computeren. De skal have en dybdeforståelse. Derfor tvinger jeg dem ned i tempo og fjerner værktøjer som enten gør for meget af deres arbejde eller viser dem forvirrende fejlmeddelelser. De skal have ro og tid til at tænke sig om uden at bekymre sig om syntaks og en sur compiler. Dermed tvinger jeg dem også til at vise mig — og sig selv — at de faktisk forstår komplicerede koncepter.
Hvorfor?#
Fordi en computer går for hurtigt.
Når en studerende kører et program tager metodekald et splitsekund. De ser ikke hvad der sker. De ser resultatet. Med en blyant og et stykke papir er de nødt til at følge hvert eneste trin. De sidder ikke længere passivt og ser programmet køre på skærmen. De må aktivt følge flowet gennem kodelinjerne.
En af mine studerende sagde det præcist, da hans “udprint” stemte overens med hvad programmet bagefter udskrev: “Yes! Computeren skriver det samme som mig. Jeg ER computeren.”
Det er Wing’s computational thinking. Den studerende forstod hvordan kode opfører sig. Han tænkte som computeren. Og han gjorde det det uden at compileren råbte af ham fordi han glemte et semikolon. Bagefter var han mere tryg ved at sætte sig til tastaturen, fordi han vidste, at han havde forstået kode. Det føltes mindre farligt med røde streger og fejlbeskeder, når grundforståelsen beviseligt var der.
Hvad sker der uden computeren?#
Studerende der normalt sidder passive begynder at tale. De siger “skal vi bruge static? Nej, for…” Og den sætning — nej, for — er alt. Det er ikke “nej, fordi IntelliJ siger det er forkert.” Det er “nej, fordi vi har forstået hvad static betyder.”
De studerende bliver mindre bange for at fejle. Hvis en papirstump ligger forkert, så kan vi bare flytte den. Hvis vi skrev forkert, kan vi strege det ud eller tage et nyt stykke papir. De forstår hvad der sker, modsat når IntelliJ viser fejl, som de ikke kan gennemskue.
Uden compileren forsvinder også en anden fælde, nemlig compile-driven development. Man skriver, compileren klager, man retter det compileren siger, det kompilerer, man fortsætter. Forståelse er ikke nødvendig for at komme videre. Med AI er det endnu værre, da AI kan omskrive hele blokke og den studerende trykker accept uden at vide hvad der ændrede sig eller hvorfor.
AI’s techsonomi#
AI har brudt Blooms taksonomi og der er nærmest tale om en helt ny techsonomi hvor studerende kan anvende og skabe uden at have været igennem forståelse, analyse, evaluering. De kan generere kode de ikke forstår. De kan producere uden fundament.
TuT er svaret på det. Ikke ved at forbyde AI, men ved at bygge det fundament der gør AI brugbart frem for farligt. For at bruge AI godt skal man kunne læse kode. For at læse kode skal man forstå hvad der sker. For at forstå hvad der sker skal man have mærket det.
Den langsomme form og de mentale modeller tvinger de studerende ned i taksonomisk niveau og konsoliderer viden og forståelse, samt giver ro til analyse og evaluering.
Det handler ikke om at danse#
Mange aktive læringsmetoder kræver mod. Man skal rejse sig, spille en rolle, stå foran klassen. Det er vigtigt, at TuT kræver ikke mod. TuT er ikke underholdning eller brainbreak eller sjove lege. TuT skal skabe psykologisk tryghed og rum til at fejle, så det må aldrig udstille nogen.
Derfor er TuT aktiviteter noget alle kan gøre. Flyt en tallerken. Sid på en stol. Placer en dronning på et skakbræt. Giv byttepenge tilbage. Fortæl hvornår du har fødselsdag. Du kan ikke svare forkert på hvornår du er født.
Jeg har set en studerende der kæmpede med syntaks placere fire dronninger på et 4x4 skakbræt uden at vakle. Han løste backtracking-problemet intuitivt og præcist. Det var vel at mærke en studerende, som ikke mente han kunne kode fordi han kæmpede med syntaksen.
I en time tegnede jeg mig selv på tavlen og tilføjede mine interfaces: Mom, Teacher, Friend, Daughter. Og jeg forklarede at de som studerende ikke kan kalde makeLunch() på mig. Ikke fordi metoden ikke eksisterer, men fordi deres reference er af typen Teacher.
Bagefter tegnede de selv. Og de begyndte at stå og forklare hinanden: “Ja, men dine søskende ser dig som Bror, men vi ser dig som Ven og…” De opfandt forklaringen selv. Selv de svageste studerende var med. Alle grinede. De som endnu ikke kunne kode et interface kunne alligevel forklare for hinanden hvad det er.
Hvad kræver det af underviseren?#
Jeg kan ikke lave en TuT-aktivitet om noget jeg halvt forstår. Den fysiske analogi holder eller den gør ikke. En skæv analogi er værre end ingen analogi, fordi den bygger en mental model der skal rives ned igen senere.
Det tvinger mig til at spørge: hvorfor eksisterer denne datastruktur? Hvad er den egentlige pointe? Det er ikke nok, at jeg forstår syntaksen. Jeg skal forstå grundlaget.
Tech uden Tech. Forståelse først.
Eksempler på aktiviteter#
Kodeflow
Backtracking
Interfaces
Grådige algoritmer
Javaklasser
Joins i SQL
Big O
Pull Requests
