Noget af det første studerende møder, når de skal lære at programmere, er fejlmeddelelser. Mange og uforståelige. Et glemt semikolon, og alt holder op med at virke. Kompileren er som en dansklærer som nægter at læse opgaven, hvis kommatering ikke er fejlfri. AI kan løse problemet og omskrive hele blokke, og den studerende trykker accept uden at vide hvad der ændrede sig, eller hvorfor.
Der er også de studerende, der ikke retter noget som helst, fordi de ikke tør begynde før de er sikre. Jeg har mødt studerende, der sad med et tomt dokument i lang tid og bare kiggede. Ikke fordi de ikke vidste hvad de ville skrive, men fordi de ikke ville skrive noget forkert. Fejlfriheden var vigtigere end forsøget. Det ligner den studerende, der blev væk fra undervisningen fordi han var kommet en uge bagud (se Psykologisk tryghed er en biologisk nødvendighed). Forskellig strategi, samme angst. Fejl føles farlige og det burde de ikke.
Derfor arbejder jeg med Tech uden Tech, hvor de studerende møder programmeringskoncepter gennem fysiske, analoge aktiviteter uden at åbne en computer. Når computeren og de mærkelige fejlbeskeder er væk, ændrer fejl karakter. Udfaldsrummet er langt større end i et IDE, og omkostningen ved at fejle er næsten nul. Det betyder ikke at studerende ikke må fejle, for pointen er, at det skal de. Men der er ikke meget på spil når de gør det. At tegne forkert eller tabe en papirstump er ikke pinligt på samme måde som at sige noget forkert højt foran klassen.
Formålet med TuT er at den studerende får bekræftet sin tro på at han eller hun faktisk forstår komplekse begreber. Hvis troen på egne kompetencer er tilstede, så bliver koden og kompileren mindre skræmmende og syntaksen bliver et middel og ikke en forhindring.
Faglige og personlige risici#
Det er vigtigt at understrege at Tech uden Tech ikke er gamification eller dramaøvelser. Ingen skal danse en algoritme eller fortælle hvilket dyr de føler sig om i dag. Aktiviteterne er fagligt seriøse og nøje planlagt til at give studerende en præcis mental model af det, der siden skal foregå digitalt. Aktiviteten er et medie, ikke et mål. Den skal være så usynlig, at det faglige indhold kan træde frem. Ligesom med værktøjerne må aktiviteterne ikke støje så meget at de overdøver det der skal læres.
Aktiviteterne må derfor ikke kræve noget, der er irrelevant for læringen. Der må ikke være krav om kreativitet, fysisk kunnen eller mod til at optræde. Det essentielt, at fejl er lavrisiko. Hvis vi erstatter kravet om faglig kunnen med et krav om mod til at udstille krop eller personlighed, har vi ikke vundet noget. Derfor laver jeg aktiviteter hvor indsatsen er lav. Alle kan stå i en række. Alle kan sortere ti tal i hånden. Det svære skal komme fra de faglige koncepter og ikke fra formatet. Aktiviteterne er designet så ingen føler sig udstillet.
Jeg trækker her på egen erfaring. Jeg har stået i rundkreds på et kursus og lyttet til en underviser med en blomst i munden og jeg er blevet bedt om at “svømme” frem og tilbage foran et zoomkamera. Jeg har som scrum master set kolleger fylde retrospektiver og sprint reviews med isbrydere og energizers i den tro at det skaber psykologisk tryghed. Det gør det ikke nødvendigvis. Langt fra alle udviklere synes det er sjovt at lege på den måde. Mange lukker ned på præcis samme måde som den studerende, der gemmer sig eller helt bliver væk fra undervisningen.
Psykologisk tryghed handler i en professionel kontekst om, at man tør tage faglige risici. At sige “jeg forstår det ikke”, at foreslå en løsning man ikke er sikker på, at påpege en fejl i en kollegas kode. Det er interpersonelle risici med et fagligt indhold. Selskabslege og zoom-svømning adresserer noget helt andet, nemlig den personlige og sociale eksponering. For mange mennesker - særligt dem der i forvejen er forsigtige med at eksponere sig - er det præcis den forkerte slags ubehag. Det lukker ikke op. Det lukker i.
Dermed ikke sagt, at vi ikke må have det sjovt med TuT. Hvis vi kan nå dertil hvor de studerende tør tage faglige risici og griner af fejl, så har vi nået målet.