Leestip: The Big Book of Computing Pedagogy

The Big Book of Computing Pedagogy is een publicatie van de Raspberry Pi Foundation, de BCS Academy of Computing en CAS (Computing at School). De publicatie is voor docenten in het Verenigd Koninkrijk gratis op papier te bestellen, daarbuiten kun je de PDF gratis downloaden.
Op YouTube zeggen ze wel eens “ik heb dit en dit gedaan zodat jij het niet meer hoeft te doen”, ik ga niet zeggen “ik heb het gelezen zodat jij het niet meer hoeft toe doen” maar: “ik heb het gelezen zodat jij weet waarom jij dat ook moet doen!”.

Allereerst: het is een lijvig document: 160 pagina’s in het Engels. Dar maakt het niet voor iedereen in het Nederlands onderwijs even toegankelijk. De titel kan je ook op het verkeerde been zetten. In Nederland zullen we het niet snel over “computing” of “computer science” hebben binnen het funderend onderwijs. Lees daar gewoon even doorheen, zie het als een document dat je kan helpen bij het nadenken over de didactische aanpak van onderwijs dat zich richt op computational thinking en programmeren.

 

Het boek start na de inleiding al meteen tamelijk concreet en tastbaar. Dit zijn de 12 didactische uitgangspunten die aan bod komen voor het aanleren van computing:

Het is meteen ook de inhoudsopgave voor de 12 hoofdstukken die daarna volgen.  Die hoofdstukken behandelen dan elk van de twaalf uitgangspunten met een stevige basis vanuit onderzoek.

1. Lead with concept
Het hoofdstuk start vanuit het principe dat het verstandig is om “niet-programmeer” activiteiten te gebruiken om programmeerconcepten uit te leggen. Daarbij wordt het gebruik van concept-maps toegelicht.
In het tweede onderdeel van het hoofdstuk wordt in het verlengde daarvan gesproken over “learning graphs”, flowcharts die door de docent als planningstool gebruikt kunnen worden bij het plannen van lessen en leerdoelen. Wat mij betreft een voorbeeld dat welke indeling je ook kiest het altijd af en toe wringt, want dit onderdeel had ook bij het volgende hoofdstuk gepast.

2. Structure Lessons
In het tweede hoofdstuk gaan we meteen door met ontwerpprincipes voor de lessen: cognitive load theory, PRIMM (predict-run-investigate-modify-make), UDL (universal design for learning), ABC (Arena Blended Connected curriculum design) passeren de revue.
De auteurs gaan er zo te zien vanuit dat leraren in het VK enigszins ervaren ontwerpers van onderwijs zijn.

3. Make Concrete
Dit hoofdstuk start met een onderwerp dat ik in Nederland niet dagelijks hoor (hoewel er zeker wel aandacht voor is): “Culturally Relevant Pedagogy”, het rekening houden met de student/leerling als persoon, met bestaande voorkennis, met een achtergrond en afkomst, diversiteit etc.
Bij programmeren/computing heel relevant als het bv gaat om check op het gebruik van stereotypes in het lesmateriaal, de voorbeelden etc.
Ook in dit hoofdstuk: leren door te maken, met uiteraard een verwijzing naar Piaget en Seymour Papert opnieuw een voorbeeld van hoe het boek ook af en toen van invalshoek wisselt. Hier gaat het namelijk meer om de inzet van computing ten behoeve van het verduidelijken van andere domeinen.  Dat uitstapje wordt in het vervolg van het hoofdstuk dan wel weer duidelijk als via het gebruik van Scratch  binnen rekenen/wiskunde, er aandacht is voor “culturally relevant scratch curriculum” en het laatste onderdeel van het hoofdstuk dat de verbinding maakt tussen het hands-on werken en het beter begrijpen van abstracte concepten. En dan is de verbinding met didactische uitgangspunten weer een stuk helderder.

4. Unplug, unpack, repack
Het vierde hoofstuk zal qua titel voor veel leraren beginnen met een herkenning (“Unplug”) maar of die dan allemaal staat stil bij concepten als LTC (Legitimation Code Theory) of Semantic Waves (zie ook de afbeelding hieronder), dat betwijfel ik wel een beetje. Maar eigenlijk zijn het juist dat soort “dingen waar vast niet elke leraar bij stil staat als ze nu aandacht aan programmeren/computational thinking etc. besteden” die wat mij betreft het boek de moeite van het doorlezen waard maken.

5. Working together
Nog een relevant onderwerp: samenwerken tijdens het leren programmeren, concepten als peer instruction en pair programming (2 leerlingen ontwikkelen samen programma’s) komen aan bod. En ook hier blijft het niet bij een simpele beschrijving in de trant van “laat 2 leerlingen samen een opdracht doen”, er is aandacht voor de verschillende rollen (“Driver” – “Navigator”) die regelmatig afgewisseld moeten worden. Van daaruit wordt de link gelegd naar het samen problemen oplossen, de rol van communicatie daarbij en (alsof het heel vanzelfsprekend is) komt dan ook versie-controle tijdens het ontwikkelen aan bod.

6. Read and explore code first
Als je tegen iemand zegt: leerlingen moeten eerst leren schrijven en dan pas leren lezen, dan wordt je gek aangekeken. Ook bij “gewoon” lezen en schrijven gaat dat qua ontwikkeling deels gelijk op. Toch is dat bij leren programmeren lang niet altijd zo. Daar krijgen leerlingen te horen hoe ze code moeten schrijven zónder dat ze expliciet leren hoe ze code moeten lezen. In hoofdstuk 6 wordt uitgelegd dat het verstandig is om leerlingen eerst bestaande code te laten lezen, te leren begrijpen en daarna te leren hoe ze de code kunnen aanpassen of uiteindelijk zelf nieuwe code schrijven. Het stukje “programmeren in assembly language op de Raspberry Pi” had voor mij hier niet persé bij gehoeven.

7. Foster Program Comprehension
Het zevende hoofdstuk had voor mij ook met hoofdstuk 6 samengevoegd kunnen worden, maar ik neem aan dat ze het uitgangspunt dat het begrijpen van code/programma’s belangrijk is voor leerlingen expliciet wilden benadrukken en dus was het een apart principe en een apart hoofdstuk. Maakt natuurlijk ook niet echt wat uit, maar het bouwt dus door op hoofdstuk 6. Aan bod komen het Block Model (zie hieronder en in deze “quick read“) en het gebruik van zogeheten Parson’s Problems (een taak waarbij leerlingen alle regels code die nodig zijn gegeven krijgen, maar in de verkeerde volgorde, zij moeten de code dan in de juiste volgorde zetten om de beschreven taak te laten uitvoeren). Het debuggen van bestaande code, vergt de vaardigheid om de code te lezen en te begrijpen, sluit naadloos aan bij de stappen Predict-Run-Investigate-Modify uit het PRIMM model.

8. Model Everything
Waar hoofdstuk 1 gebruik maakte van concept-maps om concepten tastbaarder te maken, zo gaat hoofdstuk 8 hier op door voor algoritmes en programma’s. Uitgewerkte voorbeelden (worked examples) die leerlingen laten zien hoe anderen bepaalde problemen aangepakt hebben, kunnen gebruikt worden als “scaffolding” mechanisme waarbij de leerling een steeds groter deel van een traject zelf voor zijn/haar rekening neemt.

Van live coding zijn heel veel voorbeelden op YouTube te vinden. En niet alleen van jonge nerds, Daniel Shiffman heeft meer dan een miljoen abonnees voor zijn The Coding Train kanaal op YouTube waar hij de meest uiteenlopende problemen live oplost en programmeert. Die sessies gaan nooit perfect en dat is ook niet de bedoeling. Hij praat en denkt hardop over hoe hij een probleem denkt aan te pakken en neemt de kijker (regelmatig ook echt in een livestream) mee daarbij.

Dat videos in dit hoofdstuk genoemd worden als hulpmiddel is dan zeker ook niet vreemd. Minder logisch vond ik zelf hier het afsluitende (op zich ook nu weer interessant) stukje over Smelly Code. Maar goed, wellicht hadden ze geen betere plek ervoor.

9. Challenge misconceptions
Aandacht voor onjuiste aannames en veronderstellingen van leerlingen is altijd goed. Ook bij het leren programmeren. Expliciet aandacht ervoor in een boek als dit is dus goed.
Dat het hoofstuk dan door gaat met assessment for learning vond ik wat vreemd, dat gaat immers niet alleen om misconceptions. Het onderdeel What’s in the box gaat dan wel weer over onjuiste veronderstellingen maar wordt gevolgd door een blok over meerkeuzevragen terwijl de afsluiter wél weer over misconcepties gaat. Een beetje rommeltje dus dit hoofdstuk.

10. Create projects
Bij het begrip project based learning (pbl) gaan bij een aantal mensen de nekharen meteen rechtop staan. Maar als je deze blogpost tot hier gelezen hebt dan weet je al dat het boek helemaal niet suggereert dat je kinderen alleen met pbl leert programmeren. Het is een stap die je kunt zetten als de basis er is. Ook in dit hoofdstuk wel weer de nodige nuttige handvatten, zoals de toelichting bij het cyclische fasenmodel van projecten met daarbij meteen de realisatie dat sommige hulpmiddelen geschikter zijn voor bepaalde fasen dan anderen.

Of het werken met design journals, al bevat dat onderdeel dan weer heel erg veel details van het onderzoek naar het gebruik ervan, iets waar bij andere hoofdstukken gekozen is voor het simpelweg verwijzen naar de literatuur als het dat detailniveau was.

11. Get hands-on
In hoofdstuk 11 wordt voortgebouwd op hoofdstuk 3 en gaan we, zoals de titel al zegt, hands-on. En ook hier weer af en toe van die pareltjes, zoals onderstaand overzicht van de verschillende apparaten.

Zoals gezegd: het bouwt voort op hoofdstuk 3 en tussen neus en lippen door gaan ze soms toch heel concreet de diepte in bv als het gaat om ontwerpprincipes voor physical computing:

  1. 1 Integrate tinkering activities in dedicated learning phases in which content knowledge and skills are acquired
  2. Let learners create their own interactive objects
  3. Let learners develop working prototypes
  4. Provide interesting themes and open topics to trigger imagination and creativity
  5. Integrate creative methods
  6. Integrate technical aspects with art/crafting
  7. Provide scaffolds to structure the process of project work, including planning from a user perspective and planning from a developer perspective (non-technical and technical viewpoints)
  8. Choose suitable construction kits and programming environments for the target group (low floors, wide walls, high ceilings)
  9. Provide suitable crafting material and tools for the intended projects
  10. Prepare a joint exhibition of all objects
  11. Present the results to an audience

Met als bron een proefschrift van 295 pagina’s…

12. Add Variety
Variatie van spijs doet eten. Ook bij het leren programmeren. Dus moet je het holistisch aanpakken.

Het model/plaatje hierboven, dat in het hoofdstuk te vinden is, past daar prima bij, de link naar storytelling kan ik ook nog begrijpen (goed ook gewoon dat het in het boek aan bod komt), maar of onderwerpen als RAMP (Read, Act, Model, and Program) of retrieval practice (bv Brain dumps, Take three, Mystery object, Fill in the blanks, Talk to the duck!, Emoji links, Flash cards, … de lijst gaat nog door) niet ook al eerder in het boek aan bod hadden kunnen komen?
Je merkt het: de structuur past niet overal perfect, want in dit hoofdstuk komen ook inclusiviteit, kunst en de relatie programmeren en spelen aan bod.

 

Samenvattend:
Is het een boek dat elke leraar moet lezen? Eigenlijk wel, maar veel zullen als tegenargument hebben dat zij niets doen met programmeren (omdat andere leraren dat moeten doen).
Zou je het zeker moeten lezen als je in je praktijk te maken hebt (of aan de slag wilt) met het leren programmeren van leerlingen of computational thinking? Jazeker!
Is het een perfect boek? Nee, de structuur knelt af en toe, maar inhoudelijk is er echt meer dan genoeg uit te halen.
Zou elke student bij de lerarenopleiding dit moeten lezen? Absoluut. En dan in gesprek met je docenten als je niet alles snapt wat er aan bod komt!