Bij de vijfde editie van de Fronteers Boekenclub lazen we [“The Programmer’s Brain” van Felienne Hermans](https://www.manning.com/books/the-programmers-brain).
Bij de vijfde editie van de Fronteers Boekenclub lazen we “The Programmer’s Brain” van Felienne Hermans.
“What every programmer needs to know about cognition”, zegt de ondertitel. Het is een beperkende titel, want het is een ontzettend interessant boek dat door heel veel meer mensen dan alleen programmeurs gelezen zou moeten worden.
Van ons zevenen was er maar 1 - Marrije - die zich geen programmeur zou willen noemen. Maar we hebben wel allemaal programmeerervaring. Programmeurs zijn net mensen, tenslotte; geen aparte categorie, niet slimmer of beter, niet gekker of eenkenniger.
Over het boek
Felienne - sommigen mogen [Fee-lie-nuh] zeggen - Hermans is hoogleraar vakdidactiek van de informatica aan de VU in Amsterdam en daarnaast 1 dag in de week docent op een middelbare school in Rotterdam. Ze heeft de programmeertaal Hedy ontworpen, om kinderen al jong te leren programmeren.
Ze zei over leren programmeren: “Er zijn een paar redenen waardoor programmeren lastig is. Ten eerste moet je vaak heel veel tegelijk leren: de concepten van programmeren zoals invoer en uitvoer, of condities (de bekende if-then-else), maar ook de juiste schrijfwijze. Programmeertalen worden heel boos als je iets fout typt. Als je in Python een spatie op de verkeerde plek zet krijg je al een fout. Doordat je concepten en code tegelijk moet onthouden krijg je een cognitieve overload en onthoud je wat je leert niet zo goed.”
Het boek bestaat uit vier gedeelten; code lezen, over code denken, betere code schrijven, beter samenwerken. De aandachtige lezer vindt er oefeningen in, om code te lezen, te annoteren en te structureren. En tips. Wil je beter onthouden, gebruik dan flashcards, net als bij het leren van Franse woordjes.
Er staat een heel (goed) hoofdstuk in over hoe je dingen moet noemen. Zoals het spreekwoord zegt: “There are only two hard things in computer science: cache invalidation and naming things”. Welnu, er zijn onderzoeken genoeg gedaan naar wat ‘t beste werkt. Gebruik bijv. geen afkortingen. En liever CamelCase dan snake_case. Niet te lang, niet te kort. Consistentie is beter dan je soms wel, soms niet je aan conventies houden.
En verder lazen we nuttige hoofdstukken over hoe we leren, hoe werkgeheugen, korte-termijngeheugen en langetermijngeheugen samenwerken.
Bekijk een presentatie door Felienne Hermans op YouTube.
Wat we ervan vonden
Nina
Ik zie mezelf als een programmeur die beter wil worden in programmeren. Het is een heel interessant boek, van hoog niveau, als een studieboek. Ik had het liever nog wat toegankelijker gehad. In dit werk vind ik het lastig dat je moet blijven leren. Door de aanmoediging in dit boek wil ik dat gestructureerder doen, met flashcards en herhalingen. Ik denk dat het dan langer blijft kleven. Dit boek leerde me dat oké is als je iets niet begrijpt; je mist gewoon nog kennis of informatie en daar kan iedereen aan werken.
Oordeel: geen sterren, want ik heb het nog niet uit.
Rosita
Ik zie mezelf niet als ‘echte’ programmeur. Maar ik ben het natuurlijk wel, als ik werk met HTML, CSS, JavaScript en PHP. Ik heb het boek nog niet helemaal uit. Ik vond het Engels pittig, het wetenschappelijk jargon in het boek was soms een drempel. Maar wel een heel goed boek, confronterend. Ik heb in mijn opleiding geleerd om veel notities te maken, zodat je het aan anderen door kunt geven. Dat blijkt in werk als programmeur te helpen. Ik leer dagelijks. Ik had een JS cursus gedaan waar ik niks van snapte. Totdat ik een cursus deed die hetzelfde vertelde maar op een visuele manier, met betere handvatten. Toen snapte ik het beter. Dit boek helpt me beter begrijpen hoe mensen leren.
Oordeel: 4 sterren - ook vanwege toegankelijk flink wat tekst, hoge informatiedichtheid
Marrije
Ik ben geen programmeur, echt niet. Mijn vader is programmeur. Ik ken BASIC van toen ik kind was. Verder ben ik projectmanager en informatie-architect. Ik vond dit een heel interessant en pittig boek. Voor mij waren de codevoorbeelden moeilijk toegankelijk. Het is meer een boek over hoe het brein werkt dan een boek over programmeurs. Ze legt heel duidelijk uit wat cognitive overload is; ik vond het geruststellend dat dit voor iedereen geldt. Goed is hoe ze laat zien hoe je code kunt annoteren, voor jezelf en voor anderen. Gewoon met pen en papier schetsen werkt heel goed. Daar leer je heel veel van, net als van flashcards gebruiken. Het is ook gewoon fijn om tactiel te werken. Dat helpt met begrijpen.
Oordeel: 4,5 sterren - moeilijk maar de moeite waard.
Jacqueline
Ik dacht wel dat ik een programmeur was, totdat ik dit boek las. Ik kom echt vanuit een andere hoek, want de voorbeelden zijn erg technisch. Het is echt een studieboek. Wat ik heel leuk vond: het inzicht over hoe je leert. Focus is ook heel belangrijk. En de overload doordat je gestoord wordt. Het is niet gek om daarom bepaalde standaarden uit je hoofd te leren. Dit was een stimulans om toch echt te blijven studeren. Ik ga meer flashcards gebruiken; ik vond eerst dat dit iets voor op school was, maar nu weet ik dat me dit ook in m’n werk kan helpen. Dit boek kost tijd. En het zou interessant zijn om met een team te doen.
Oordeel: 4 sterren - heel interessant, maar voelt wel als een studieboek
Adam
Ik vind mezelf wel een echte programmeur met 10 jaar ervaring in allerlei talen. Ik heb het als luisterboek geluisterd en als programmeur vind ik het echt het beste boek dat ik in tijden las. Beter zelfs dan ‘Clean Code’ van Uncle Bob. Veel geleerd, inspiratie voor de toekomst. Het was een eye-opener om te begrijpen waarom het moeilijk is om te schakelen tussen verschillende talen. En dat het nuttig is om afspraken te maken over conventies binnen een codebase. Het is nu ook helder voor me waarom je niet onmiddellijk een codebase kunt snappen. Commentaar in code is minder nuttig dan ik eerst dacht, dat patronen en namen zo belangrijk waren wist ik niet. Je hebt soms gewoon tijd nodig. Werkgevers die haast hebben, geven me geen goed gevoel. Ik moet het begrijpen. En dat kost tijd.
Oordeel: 5 sterren
Annemiek
Wat is een programmeur? Ik weet het niet, maar als je iets met JavaScript doet ben je een programmeur. Ik ben een startende developer. Als ik niet begrijp in een codebase, dan raakt me dat. Daarom vond ik het nuttig om te lezen over het verschil tussen iets niet kunnen en iets niet weten. En dat je niet tegelijkertijd code kunt lezen en begrijpen. Wat een herkenning, en erkenning, ook dat mensen met taalgevoel betere programmeurs zijn, omdat het meer gaat om lezen dan om logica. Het was nuttig dat ze suggereerde om code eerst op te knippen en lijntjes te trekken. Het is ook goed om meer in teams naar code te kijken. Prima uitleg hoe hoe het brein werkt, met associaties, niet als een mappenstructuur. Goed dat ze zei dat je als je iets moet opzoeken dat je eerst even moet proberen het uit je geheugen kunt halen. Als oefening.
Oordeel: 4,5 sterren - menselijk geschreven
Paul
Ik vrees dat ik al heel lang een programmeur ben, al ontken ik dat graag. Ik ben helemaal niet zo gesteld op logica en abstractie, ik ben een talenmens en klooi graag maar wat aan. Ik verwachtte dat het een saai boek zou zijn, maar het is echt een heel goed en interessant boek. Ik waardeerde heel erg dat Hermans aanstipte dat kunnen lezen belangrijker is dan goed zijn in logica. Het stuk over de diverse type variabelen vond ik ook erg interessant. Al met al ben ik heel blij verrast door dit boek.
Oordeel: 4,5 sterren - ik heb veel geleerd en het boek overtrof mijn verwachtingen
FBC6: dinsdag 11 april
Bij de zesde editie bespreken we 'Weapons Of Math Destruction' door Cathy O'Neill, een boek uit 2016. De omineuze ondertitel luidt: "How Big Data Increases Inequality and Threatens Democracy".
"WMDs, or Weapons of Math Destruction, are mathematical algorithms that supposedly take human traits and quantify them, resulting in damaging effects and the perpetuation of bias against certain groups of people."