At programmere - hvorfor? Hvordan? Og med hvilket formål?

Vi har i denne uge stiftet bekendskab med at programmere. Og til vores store overraskelse var det ikke helt så svært, men faktisk enormt sjovt, kreativt og lærerigt! Vi brugte programmet Scrath, som er et blokprogrammeringsprogram, der gør at programmeringen bliver simpel og visuel. Det er noget, vi sagtens kan se stort potentiale i at bruge i folkeskolen med elever. Men spørgsmålet er med hvilket formål, vi som lærere ville bruge programmet? 

Man snakker om to metadiskurser, der omhandler med hvilket formål, vi bruger teknologi på uddannelsesområdet (Holm et. al 2019). Den ene er den politisk-etiske diskurs og handler om børn og unges dannelse som mennesker og borgere til at kunne arbejde, begå sig, deltage og samarbejde samt være kompetente medskabere af et demokratisk samfund, hvor teknologier har en dominerende rolle. Den anden er den økonomisk-pragmatiske diskurs og handler om, at vi skal uddanne elever indenfor teknologi for at kunne imødekomme den digitale udvikling, så de kan blive nyttig og kompetent arbejdskraft i fremtiden. Dette anbefales at gøres ret tidligt - allerede i folkeskolen. 

Når man arbejder med Scrath får man i første omgang en kompetence i at programmere. Man lærer at sætte en kode op bag et spil, en lille historie mv. Man lærer at fejlfinde og tænke logisk. Dette bakker op om den økonomisk-pragmatiske diskurs. Men disse kompetencer med at tænke logisk, fejlfinde og være kreativ kan måske netop være udgangspunktet for dannelse og dermed kan programmet også ses som en måde at opnå læring indenfor den politisk-etiske diskurs. Man lærer også at være grundig og gå analytisk til værks. Denne måde at arbejde på går væk fra den meget lærerstyrede undervisning hen mod en mere deltagelsesorienterede læring, som bevirker at eleverne kan se det meningsfulde i at arbejde med et projekt. Dette kalder man med Paperts begreb “powerful ideas” (Holm et. al 2019). Eleverne vil med denne fremgangsmåde gå til projektet mere kreativt og kritisk og undersøgende for at finde fejl og dermed udvikle på deres produkt fremfor at søge et “rigtigt” svar hos læreren. Dette kan vi virkelig se potentialet i, da det er med hænderne i mulden, man lærer noget, ifølge os.  

Man kan diskutere, hvor meget læring, man kan få ud af at bruge Scrath. Ole Seier Iversen kritiserer, at programmering er vejen til at lære computationel tænkning, og sammenligner det med at lære sprog udelukkende ved at kunne grammatikken. To nye litteraturstudier kan heller ikke entydigt vise belæg for, at kodning skulle påvirke elevernes intellektuelle udvikling positivt ift. at kunne tænke kritisk, kreativt, abstrakt eller logisk (Holm et. al 2019).

Vi mener heller ikke, at arbejdet med programmering i Scrath kan stå alene, men vi synes dog stadig, at vi fik meget læring ud af det og blev udfordret i at finde fejl, være kreative og løse fejlene. 

Vi har i denne forbindelse udtænkt og skitseret et undervisningsforløb på en uge i 5.klasse i matematik. 

Dobbeltlektion om mandagen: Igangsættelse af projektet: Hvordan tænker en computer? 

1. Denne lektion startes ud med en leg inden for det praktisk musiske felt, som skal vise eleverne, hvor meget information en computer skal have. Her skal man have en ekstra lærer/pædagog til at lege med. Eleverne skal i fællesskab guide læreren til at udføre en bestemt handling  - fx at lave en kop kaffe, stille bøger op på en hylde mv. 

2. Efterfølgende skal eleverne lave et visuelt flowchart samt en pseudokode over, hvordan “hjem-knappen” på en iphone virker. 

Fx “når man står på lås-skærmen og trykker på hjem-knappen, vil skærmen vise at man skal skrive sin adgangskode” “når man man er inde på et program og trykker på hjemknappen, vil skærmen vise hjemmeskærmen” osv. 

Dobbeltlektion om onsdagen: Arbejde med programmering i Scrath - lav et spil! 

1. Eleverne introduceres kort til de mest grundlæggende funktioner i Scrath. 

2. Derefter går eleverne i grupper selv i gang med at lave et simpelt spil. Her er rimelig frie rammer, og der sættes fokus på at eleverne selv skal gennemskue hvor fejlene er, før man kan spørge læreren. Derudover sættes der fokus på, at de godt må ændre kurs undervejs, slette, forbedre - altså skal de have en nysgerrig og kreativ tilgang.

3. Vi har prøvet at lave et spil som kan ligne det, eleverne selv kommer til at lave. Det første vi gjorde var, at få et skelet til at danse ved at gå frem og tilbage og ændre “kostume” imens. Det gjorde, at man kunne bruge alle piletasterne til at flytte skelettet rundt på baggrunden. Dette fik os til at tænke på spillet “pacman”, hvor en figur bliver forfulgt af nogle spøgelser rundt på en labyrint. Vi lavede derfor baggrunden til en labyrint, men vi kom i problemer, da vi ikke kunne finde ud af at programmere nogle bolde til at følge skelettet rundt. Derfor kom vi til at tænke på et andet slags spil, hvor skelettet skal over en bane uden at ramme boldene, som bevæger sig op og ned i forskellige hastigheder ala når man krydser en vej.

Vi ville gerne programmere spillet til at skrive GAME OVER når skelettet ramte en bold. Vi fulgte en youtube-instruktion, men programmet ville ikke som vi ville. Vi brugte en del tid på at fejlsøge, men tiden satte en begrænsning for os, og vi fik ikke programmeret mere. 

Dobbeltleksion om fredagen: Færdiggør spillet, vis det til hinanden og snak om hvad man har fået ud af det. 

1. Det er vigtigt at have en snak med eleverne om, hvad vi kan lære af at arbejde med programmet for, at vi kan blive bevidste om, hvorfor vi har arbejdet med det. Også så eleverne kan blive bevidste om, at denne slags programmering faktisk er bag et hvert spil.