Alldeles nyss hade jag en mycket bra lektion; samtliga elever satt lugnt och jobbade. Det pratades, men i ganska låg tonart och mest om ämnet. Jag började fundera på vad det kunde bero på att i stort sett samma elever ibland är helt omöjliga, ibland hur lugna som helst.
…av glädje bygger man kod.
(Och ja, jag vet att det inte passar så bra med melodin. Kom igen, jag är inte musiklärare direkt…)
Det verkar finnas ett “matematikparadigm” inom programmeringsdidaktiken. Tanken är, om jag förstått saken rätt, att programmering “egentligen” är matematik, eller åtminstone logik. Det har som följd att de allra flesta programmeringslärare jag talat med mestadels använder sig av uppgifter med matematikanknytning. Ekvationslösningar, algoritmer fibonnaccisekvenser och primtal.
De flesta programmeringslärare är överens om att programmering inte är att skriva kod. Kodskrivandet är egentligen bara de där sista procenten av det egentliga arbetet. Det här är något många elever missar, och jag är inte förvånad – traditionell programmeringsundervisning har fokuserat på koder och formalia, att lära sig rätt funktioner i programmeringsspråken. Man lägger ofta in problemlösning som ett kriterie för högre betyg, men vad jag sett skapas sällan förutsättningar för inlärning av just problemlösning. Detta trots att lärarna är rörande överens om att just problemlösning, att kunna dela upp ett stort problem i mindre delar, är det som är centralt för ämnet. Är MVG-kriterierna något eleven måste kunna uppnå helt själv? Ha med sig från början? Jag har svårt för den tanken. I min värld kan alla få MVG, men då måste de ges utrymme och möjligheter för att träna i och utveckla MVG-kompetenserna. De kan inte få vara något som bara spontant uppstår.
Det här lektionsupplägget är tänkt att vara en utgångspunkt för en bredare diskussion med eleverna om vad programmering egentligen är och vad som menas med “problemlösning”.
En sak jag börjat fundera på är vad vi egentligen har programmeringsämnet till. Vad är det eleverna ska lära sig? Är det att programmera CNC-maskiner? Skapa appar? Bygga spel? Lära sig lösa algoritmer?
I mina ögon är allt det här samma sak. Det är samma grundläggande logik oavsett tillämpning. Med det följer då att det sätt man lär sig programmera spelar mindre roll än att man lär sig programmera. Och då följer att det lämpligaste sättet att lära sig programmera i gymnasiet borde vara det som skapar mest intresse, ger mest mersmak, och ger eleverna mest intresse för programmering.
En kompis till mig brukar skriva att alla lagstiftare borde vara spelmakare. Med det menar han att om man ska skapa lagar, så bör man ha förmågan att göra en konsekvensanalys och ha koll på incitamentstrukturer.
Incita-vaddå?
Ett incitament är alltså något som uppmuntrar någon att göra något; som belönar ett visst beteende. En incitamentstruktur är då en struktur av incitament.
Inom skolan finns det massvis av incitamentstrukturer. Jag brukar roa mig med att analysera dem.
Jag ska snart byta arbetsplats. Visserligen till en skola jag jobbat på förut, men jag känner ändå den där allmänna osäkerheten kring hur saker och ting kommer att fungera. Jag har märkt att det finns ett antal saker man ganska snabbt bör se till att få reda på när man börjar jobba på ett nytt ställe.