Programmering for den uerfarne

Me er to røynde matematikklærarar, med til saman nærare 40 års erfaring frå undervising i matematikk i grunnskule og lærarutdanning, men likevel nærare null praktisk erfaring med programmering. I vårt arbeid med undervising i matematikk har me opp gjennom åra møtt på mange nye tekniske trendar og nyvinningar som matematikkfaget i skulen har hatt behov for å forhalda seg til, som til dømes vitskaplege kalkulatorar, smarttavler, programvare av typen Excel eller GeoGebra, og no sist programmering.

Når ei slik nyvinning kjem, uansett kva det er, korleis det vert argumentert for at dette skal eller bør inn i undervisinga i skulen, eller kven som legg fram argumentasjonen, vert me som underviser, utfordra på å kritisk vurdera om dette har ein plass i undervisinga, og eventuelt korleis nyvinninga kan betre læringsutbyttet for elevane. Då er det vår plikt å gjera denne vurderinga og å gjera ho grundig nok til å ta ei avgjersle. 

Mange gonger endar vurderinga med å avvisa nyvinninga, og når dette vert gjort etter ei kritisk vurdering, er det sjølvsagt greitt. Det er til dømes mange kommersielle aktørar som ønskjer å få sine produkt inn i skulen, og det må dei sjølvsagt stå fritt til å kunna forsøkja, men når nye element vert tatt inn i læreplanen, er det derimot ei litt anna sak. Ja, på lik line med reint kommersielle tilbod er det er lett å bli skeptisk og avventande, men når det er kome inn i læreplanen, er det ikkje opp til oss som undervisarar åleine å avgjera om det nye elementet skal bli del av undervisinga. Det har nokon med meir mynde knytt til prioriteringar i skulen fastslått at det skal. Og no gjeld det altså programmering.

Utfordringa med å møta noko nytt å læra seg, som ein kanskje ikkje forstår rekkevidda av eller moglegheitene med, er som alltid stor. Ein kjenner seg kanskje som ein slags Sisyfos-figur, for bortsett frå at ein forstår at ein skal læra seg dette, ser ein ikkje heilt at eigenverdien er til stades, eller ein kjenner seg kanskje som ein fotsoldat som skal utføra noko ein ikkje treng å vita betydninga av fordi bidraget ein kan gi, berre er ei lita brikke i ein større plan. Slik har me det òg, men i vårt forsøk på å møta utfordringa med å ikkje forstå nytten med kvifor me skal læra oss programmering, har me tenkt på tre aspekt som har fungert som ei drivkraft for oss i det vidare arbeidet med å byggja programmeringskompetanse:

1. Kompetansegrunnlag

Dersom me i våre yrke som lærarar og lærarutdannarar skal kunna forstå programmering og kva programmering inneber for matematikkfaget, må me nesten begynna med å skaffa oss eit fundamentalt kompetansegrunnlag knytt til dette sjølv, slik at me etter kvart kan leggja til rette for at andre skal kunna læra seg programmering og å finna verdi i dette.

2. Vidareutvikling av kompetanse

Elevane som no går i grunnskulen, har som hovudregel ennå ikkje hatt mykje programmering. Men etter kvart vil omfanget og læringskurva strekkja seg lenger og høgare for desse. Dermed vil ein 8.-klassing om åtte år frå no ha meir erfaring med programmering enn ein 8.-klassing har i dag. Det inneber at tida er overmoden for å læra seg nok programmering til at me i noko grad kan arbeida saman med elevar eller studentar i utforsking og vidareutvikling av denne kompetansen. Og så vil tida visa i kva grad vår kompetanse knytt til programmering etter kvart blir såpass god at me kan begynna å nytta programmering i utforsking av matematiske samanhengar saman med elevar som lærer seg programmering i grunnskulen, og å arbeida med didaktiske tematikkar knytte til programmering saman med lærarstudentar. Me treng altså at elevar, lærarar, lærarstudentar og lærarutdannarar i den tidslomma me no er i (kanskje meir enn elles), gjer kvarandre gode.

3. Noko kjem til å koma

Grunnskulelærarstudentane me underviser og rettleiar, skal arbeida i skulen i mange år framover. Det fyrste me kan bidra til, er at dei er kompetente og sertifiserte til å arbeida som matematikklærarar. Det inneber mellom anna at dei får møte eit matematikkfag i lærarutdanninga som er relevant for den skulen dei skal arbeida i. Me som lærarutdannarar må difor gjera vårt for å leggja til rette for at studentane får utvikla ein endrings- og utviklingskompetanse. For medan dei arbeider i skulen, kjem det noko nytt å forhalda seg til, veit du.

Ei stor oppgåve

Den nærast banale erkjenninga av desse tre aspekta ved programmering er at det er lagt ei stor bør på våre skuldrer. Dette fører oss inn i ei form for tungsinn knytt til utfordringa me står overfor. «Utfordringa vert for stor! Det kan ikkje vera å venta at me skal kunna klara dette! Me veit jo ikkje eingong kor me skal starta!». Men kva gjer ein når ein står overfor eit problem og ikkje veit kva ein skal gjera? Frå mellom anna landevegssyklisten si verd hentar me den fyrste gneisten, gjennom mantraet «Ta deg saman!». Denne klare beskjeden til oss sjølv for å kveikja prosessen me skal inn i, har nok mest grad av personleg misnøye med eige mismot, når det gjeld å koma ut av tungsinnet som skuggar for vilje, kreativitet og handlekraft, når ingen andre indre motivasjonsfaktorar gjer seg gjeldande. Men han fører oss òg over til det som har meir innverknad når ein står overfor eit matematisk problem, nemleg val av strategi for å løysa problemet.

Her er det mykje å velja mellom, og det fyrste me erkjenner, er at heilt blanke er me ikkje, då me har ein del kjennskap til forskingslitteratur knytt til undervising i programmering på barnetrinnet (Holo mfl., 2022). Samstundes har me forstått at teoretisk kunnskap ikkje kan kompensera for manglande praktisk innsikt i programmering. Programmering som aktivitet er, slik me opplever det, ikkje noko ein berre kan lesa seg til, på same måte som ein ikkje kan læra seg å bruka ei smarttavle eller GeoGebra berre ved å lesa om det. I dette spesielle, praktiske problemløysingstilfellet finn me det lurt å ta utgangspunkt i ein av Utdanningsdirektoratet sine støttefunksjonar knytt til innføringa av programmering i skulen: «Den algoritmiske tenkaren» (Utdanningsdirektoratet, 2019).

«Den algoritmiske tenkaren» framhevar nøkkelomgrep og arbeidsmåtar som er relevante når ein driv med programmering, og det er arbeidsmåtane (høgre sida i figur 1) me finn inspirasjon hjå denne gongen: Fikla, Skapa, Feilsøka, Halda ut, Samarbeida. For det er tydeleg at me undervisarar må prøva oss fram med alt frå programmeringsspråk og oppbygging av algoritme på datamaskin til å bruka diverse utstyr for å gjennomføra øvingar knytte til programmering, dersom me skal greia å koma i kapp med det fyrste og deretter dei andre to aspekta i motivasjonspunkta våre ovanfor.

Så kva gjorde me?

Me valde altså ei «prøva og feila»-tilnærming som strategi i det me starta vår utforsking av programmering som aktivitet. I tråd med arbeidsmåtane som vert framheva hjå «Den algoritmiske tenkaren», vart ønsket om å samarbeida om å skapa forsøkt oppfylt gjennom felles utforsking og god gammaldags fikling. Vidare laga me til nokre krav til kva me meinte var viktig å fokusera på i utforskinga vår, og kva som bør vera i fokus når me skal velja ein aktivitet for å prøva ut vår fyrste tur inn i programmeringsverda. Desse vala gjorde me med utgangspunkt i funn frå forsking på undervising i programmering i barneskulen (Holo mfl., 2022):

· Blokkprogrammering verkar til å vera meir som ein motorveg til å koma i gang med programmering på barnetrinnet, og mellom anna har super:bit-prosjektet (Vitensenterforeningen mfl., u.å.) utvikla eit lærarkurs som er knytt til blokkprogrammering med micro:bit (Microsoft, u.å.). Dette er eit kurs som særs mange lærarar i norsk skule anten har gjennomført eller fått tilbod om å gjennomføra. Me valde difor å gjera all utprøving innanfor rammene dette kurset har.

• Eit anna poeng frå litteraturen er at artefaktar vert nytta for å fremja både interesse, motivasjon og læring knytt til programmering. Artefaktar kan gjerne vera robotar eller anna utstyr som får programmeringsaktiviteten til å bli noko meir enn berre kodar på ein dataskjerm. I vårt tilfelle valde me difor å nytta utstyr frå super:bit-pakka (Skolehuset.no, u.å.).
• Eit tredje poeng litteraturen trekkjer fram som verdifullt, er å driva såkalla parprogrammering, altså at to personar arbeider saman på ei datamaskin under arbeidet.
• Ein aktivitet som høvde godt til desse kriteria, fann me i super:bit-prosjektet: oppdraget «Køyra ein bil rundt heile super:bit-byen». Dette oppdraget dreier seg om å få ein bil (BitBot) til å køyra ein veg oppteikna i svart, rundt på ei golvmatte som viser «Smartby» (sjå figur 3). Dette er ei utfordring som krev kjennskap til micro:bit, utstyr kopla til ein micro:bit, og programmering på datamaskin som må koplast til micro:biten som skal sitja på BitBoten (sjå figur 2).

Erfaringar med å køyra bil i super:bit-byen

Når ein ser utover bordet der det ligg ein umontert BitBot-bil, ein micro:bit, nokre leidningar, ein USB-kabel, og det blenkjer svakt i datamaskina som viser startsida på makecode.microbit.org/, er det nok mange som kanskje vil tenkja at «Ja, dere … det er en fin dag for programmering… », for å skeivsitera fotballkommentatoren Arne Scheie. Det gjorde slettes ikkje me. Sjølvtilliten fekk seg brått ein knekk då me oppdaga kor lite som skulle til før me hadde mista kontakten med det me ville gjera, nemleg å programmera, fordi mange praktiske detaljar kravde merksemd.

For ein som er ukjend med slikt utstyr, er det mange spørsmål ein stiller seg når ein fyrst skal setja fingrane i ein micro:bit. Kan ein til dømes setja fingrane kor som helst på micro:biten utan å øydeleggja han? Kva med alle kretsane og små punkt på BitBoten? Kan ein setja fingrane kor som helst på BitBoten utan å øydeleggja noko? Korleis får me denne bilen til å fungera? Kva veg skal micro:biten stå i bilen? Korleis får me kopla det som skjer på datamaskina, til bilen? Og så vidare. Me opplevde at det tårna seg opp spørsmål av heilt elementær art, og ein kunne nærast merka kjensla av avmakt og frustrasjon koma snikande.

Heilt mørkt vart det likevel ikkje, for Internett byr på mange moglegheiter for hjelp, og etter litt studering av sjølve bilen fann me etter kvart ein av/på-knapp(!) (ja, du flirer kanskje, du!?). YouTube er éin ting, men tilgang til vitskapssentera sitt lærarkurs i super:bit var som å finna både gull og grøne skogar (Vitensenterforeningen, 2021). Her fann me ei trinnvis innføring i korleis desse praktiske detaljane skulle handterast, og me kunne gå i gang med å arbeida med problemet med å programmera bilen. Å søkja etter informasjon erstatta altså mykje unødig fikling for å koma fram til det me såg for oss at me skulle fikla med.

Det fyrste oppdraget i aktiviteten me valde, var å få BitBoten til å køyra ein meter fram, snu 180°, og køyra attende til start. Etter mykje utforsking ved å laga eit program som greidde dette, såg me at same kor mykje me korrigerte våre parameterar for fart og tid, køyrde stadig BitBoten ut av kurs. Kva gjer ein då? Dette medførte nye spørsmål, og nokre refleksjonar kring korleis dette kan handterast i ein klasseromsituasjon. Anten kan ein

a. slå seg til ro med at dette er små robotar som neppe kan vera så nøyaktige, så unøyaktigheiter må elevane berre godt.

b. fikla og leita etter moglegheiter for å korrigera desse unøyaktigheitene, kanskje i lag med elevar (som veit betre?)

c. få hjelp (av nokon som veit meir)

Uansett kokar desse refleksjonane ned til spørsmål om kor mykje «utanom oppgåva»-fikling ein skal ta seg tid til i ein stressande klasseromsituasjon. Og om ein ikkje tek seg tid til å korrigera unøyaktigheitene, kor lang tid vil det då ta før elevane vert indignerte og etter kvart likegyldige til øvingsmomentet, når BitBoten ikkje går dit dei har planlagt og programmert, same kor mykje dei justerer?

Fikling tar elles uansett tid, mykje tid, noko den eldste av oss fekk merke då den yngste fann fleire interessante avsporingar som brått fekk meir merksemd enn å justera drivkrafta på kvart av hjula på BitBoten. Plutseleg vart det særs interessant å «pynta» på programmet for køyring av BitBoten, gjennom å leggja til krydder i form av lys og musikk. Nysgjerrigheita vart for stor, og den indre motivasjonen for å fikla med og utforska moglegheiter som ligg i dei ulike funksjonane i programmet, tok overhand då anna framdrift blei bremsa av BitBoten si lite synkroniserte drivkraft på høgre og venstre bakhjul. Drivkraftjusteringa blei for vår del løyst gjennom punkt c) over. Me fekk hjelp av nokon som hadde vore med på dette før.

I sjølve programmeringsarbeidet oppdaga me fort at her er det bokstavleg tala fleire vegar som fører fram for BitBoten. Kurssidene me fann, hjelpte oss litt, men mest fekk me att for å diskutera kva me skulle gjera. Skulle me til dømes bruka ei lykkje der, eller kanskje me heller skulle laga ein funksjon som inneheldt den algoritmen, for så å køyra han to gonger? Og så prøvde me ut det me diskuterte. Underleg med den BitBoten, forresten … Han gjorde som me skreiv i programmet, og ikkje som me hadde diskutert oss fram til. Hmmm … Slike feilsøkjarerfaringar innebar justeringar og nye utprøvingar. Og trur du ikkje at bilen hadde fullført køyreturen, meir eller mindre perfekt, etter om lag ein time med diskusjon, fikling, programmering, utprøving og justering!? Til spontan jubel frå to «gutungar» då BitBoten parkerte etter fullført byrunde!

Godkjensla då programmet fungerte, var enorm, og vog opp for all tid med frustrasjon, gjetting, fikling, prøving, feilsøking og feiling – for det var nettopp det som vart utgangspunktet då me sette i gang. Til dømes vart fart justert som x % av maksimal hastigheit, men kor mykje er 100 prosent? Og avstand vert i programvara presentert som kor mange millisekund BitBoten skal køyra, men kor langt kjem bilen på eitt millisekund gitt x % hastigheit, og kor lang tid er eigentleg eit millisekund? Dette er storleikar som ein best finn ut av ved å berre begynna ein stad, for så å justera. Gjetting. Prøving og feiling. Fikling. Halda ut.

Habit of mind

For meir enn tjue år sidan reiste Cuoco mfl. (1996: s. 375) spørsmål om kva som er relevante, matematiske emne å undervisa for framtida, når nye læreplanar skal utarbeidast, gitt den raskt skiftande tida me lever i: «Burde det vektleggjast grafteori eller stereometri? Analytisk geometri eller fraktalgeometri? Modellering med algebra eller modellering med rekneark?» Slike typar spørsmål var nok relevante òg i utarbeidinga av LK20, men Cuoco mfl. (1996) konkluderte med at «dette er feil spørsmål å stilla, og å utarbeida ein læreplan knytt til svar på slike spørsmål er ein dårleg idé». Deira poeng var at det viktigaste ein kan gi elevar moglegheit til å læra, er det dei omtala som eit «habit of mind». Dette er eit tankesett dei hevdar er føremålstenleg når ein skal gjera matematikk, og inneber mellom anna å sjå på matematikk som eit fag der ein i hovudsak arbeider med å løysa problem. I dette ligg det at for å kunna løysa problem bør elevar venja seg til å vera «mønsterjegerar», utforskarar som tør å «fikla» med matematikken, oppfinnarar og hypoteseframleggjarar, vera gode på å visualisera problem og gissa på aktuelle løysingar, og ikkje minst kunna sjå eit problem frå fleire perspektiv.

Dette er ikkje mindre aktuelle tankar i dag, heller meir aktuelle. Gjennom å arbeida med problemløysing og med programmering vil ein nettopp nytta seg av fleire av punkta i eit slikt tankesett. Det kan no faktisk sjå ut som at den tradisjonelle skulematematikken i noko grad vert nytta som eit middel for å læra seg programmering eller programvare som til dømes GeoGebra, heller enn å vera eit mål i seg sjølv. Slik sett må ein i ei ny tid gjerne tenkja på matematikken i skulen på nye måtar.

Å verta gode problemløysarar, ved mellom anna å dyrka utvikling av nøkkelomgrep og arbeidsmåtar som «Den algoritmiske tenkaren» representerer, er blant eigenskapar og dugleikar som utdanningsforsking og samfunnsanalysar trekkjer fram behov for i notida og framtida (sjå til dømes Thomson, 2011). Å driva med nettopp programmering kan vera ein av vegane til slik framtidsretta kompetanse.

Kva no?

Etter å ha «tatt oss saman», og gjort øvinga med BitBoten med fasar av framdrift, frustrasjon og ekstase, ser me i etterkant at det i tillegg til elementa frå «Den algoritmiske tenkaren» ligg mykje praktisk matematikk i eit slikt arbeid. I vårt tilfelle møtte me til dømes omgjeringar mellom einingar, bruk av prosent, og samanhengen mellom veg, fart og tid. Kanskje er dette òg ein god måte å gi matematikken ein relevant kontekst på, samstundes som ein har endå ei prioritering i matematikkfaget i skulen som kan føra eleven nærare arbeidsmåtar som matematikarar «der ute» faktisk nyttar, slik Cuoco mfl. (1996) påpeikar? Ein takknemleg bieffekt me i tillegg merka oss, er at ein òg vil dra med seg ei tilnærming til problemløysing som er overførbar til meir enn berre matematiske problem. I så måte er det programmering som vert meir som eit middel enn eit mål i seg sjølv, eit middel for å oppnå eit habit of mind.

Og korleis gjekk det med oss to som var fyrstereis i programmeringsverda? Me kom oss i alle fall i gang og har gjort oss nokre viktige erfaringar. I tillegg til å få ei begynnande bukt med vår skepsis og vankunne kring programmering har me òg fått utvida vår matematiske horisont. Me ser at det er mykje matematikkfagleg og matematikkdidaktisk kompetanse å trekkja vekslar på i det vidare programmeringsarbeidet saman med elevar og studentar, og at dersom ein tek seg tid til å utforska dette, kan vinninga vera stor for alle partar. Kor vegen går vidare no, bør ikkje vera noka overrasking. Han går inn i klasserommet.

litteratur

Cuoco, A., Paul Goldenberg, E. & Mark, J. (1996). Habits of mind: An organizing principle for mathematics curricula. The Journal of Mathematical Behavior, 15(4), 375–402. https://doi.org/10.1016/S0732-3123(96)90023-1

Holo, O.E., Kveim, E.N., Lysne, M.S., Taraldsen, L.H. & Haara, F.O. (2022). A review of research on teaching of computer programming in primary school mathematics: moving towards sustainable classroom action. Education Inquiry, 1–16. https://doi.org/10.1080/20004508.2022.2072575

Microsoft. (u.å.). makecode.microbit.org. https://makecode.microbit.org/

Skolehuset.no. (u.å.). Super:bit Education Kit ‑ Klassesett (Microbit V2). https://www.skolehuset.no/products/super-bit-individuell-startpakke

Thomson, P. (2011). Creative school and system change. I: J. Sefton-Green, P. Thomson, K. Jones, & L. Bresler (Eds.), The Routledge International Handbook of Creative Learning (s. 333–336). Routledge.

Utdanningsdirektoratet. (2019). Algoritmisk tenkning. https://www.udir.no/kvalitet-og-kompetanse/profesjonsfaglig-digital-kompetanse/algoritmisk-tenkning/

Vitensenterforeningen. (2021). For super:bit-lærere. https://www.vitensenter.no/superbit/laerer/

Vitensenterforeningen, Lær kidsa koding, & NRK-Super. (u.å.). Hva er super:bit? https://www.superbit.no/hva-er-superbit/

Om forfatterane

Odd-Eivind Holo er lektor med tilleggsutdanning, tilsett i delt stilling mellom Kvåle skule (Sogndal kommune) og grunnskulelærarutdanninga ved Høgskulen på Vestlandet (Campus Sogndal) . Han har ein mastergrad i læring og undervising frå Høgskulen på Vestlandet, med fordjuping i matematikk, og har brei erfaring frå arbeid i grunnskulen. Spesielle interessefelt er mellom anna kva som skal til for å skape djupnelæring i matematikk.

Frode Olav Haara, ph.d., er førsteamanuensis i matematikkdidaktikk ved institutt for språk, litteratur, matematikk og tolking ved Høgskulen på Vestlandet (Campus Sogndal). Han har bakgrunn som lærar i grunnskule og vidaregåande skule. Han arbeider med matematikkdidaktiske problemstillingar knytt til utdanning av grunnskulelærarar.