Onlangs schreef ik een artikel over Waarom onze computers te snel worden. Het vertelt dat technologische vooruitgang ook negatieve kanten kan hebben, zoals programmeurs die geen moeite meer doen en daardoor juist technologische achteruitgang inzetten.
In dit artikel wil ik uitleggen hoe je, in mijn ogen, beter kunt omgaan met technologie. Zowel het maken ervan (als je een programmeur bent) als het consumeren ervan.
De vraag is dus: technologie beheerst een steeds groter deel van ons leven, maar tegelijkertijd is de kwaliteit van software steeds lager en weten steeds minder mensen hoe het daadwerkelijk in elkaar steekt. Hoe lossen we dit op?
(Dit is niet een artikel over hoe je het beste “zorgt” voor apparatuur, of hoe je leert om computers te begrijpen, of hoe je jouw printer aan de gang krijgt, of waarom je die update maar niet weg kan klikken. Dat is een heel ander onderwerp. En ook iets wat zeker niet in één artikel past.)
Hoe lossen we dit op?
Het is vrij simpel: hou het simpel.
Dit artikel is geschreven voor iedereen, zowel programmeurs als consumenten van technologie (wat, dezer dagen, iedereen beslaat). Sommige van de stappen hieronder zullen niet op jou van toepassing zijn, maar de meeste wel.
Bovendien wordt het steeds belangrijker dat iedereen iets van computers begrijpt. Op veel scholen is informatica al een (basis)vak en anders hebben ze een programma voor “digitale geletterdheid”. Dus als je niks van computers weet, stel ik voor om er toch een klein beetje energie in te steken en vervolgens anderen erover te leren.
Dit zijn de stappen die ik al jarenlang neem om dit te bereiken:
- Gebruik programma’s die één ding doen en niet meer. Het liefst open source.
- Koop de goedkoopste apparatuur die je kan vinden. (Doe aan single tasken: sluit dingen af die je niet gebruikt, haal dingen uit de oplader als ze opgeladen zijn.)
- Besef dat veel dingen nog steeds het beste analoog kunnen.
- Begin elk project (zoveel mogelijk) met een leeg canvas.
- Schrijf documentatie/opmerkingen en tests (voor anderen en jezelf)
- Leer iedereen niet hoe ze moeten programmeren, maar eerst waarom ze moeten programmeren.
Het Single-Responsibility Principe
Veel programma’s zeggen dingen in hun marketing als “alles-in-één pakket!” en “100+ features!”
Ik snap het niet. Ik snap ook niet waarom het nog steeds lijkt te werken. Je wil helemaal niet dat een programma alles probeert te doen—je wil dat het één ding heel erg goed doet.
Bijvoorbeeld: stel je loopt door een winkel op zoek naar een goede oven. Voor X euro vind je die oven die precies doet wat je wilt. Even later in de schappen vind je een combi (oven en magnetron) voor hetzelfde geld.
Wat is je eerste gedachte? “Zal wel niet zo’n goede kwaliteit zijn dan”
Maar wat is je tweede gedachte? “Tja, misschien heb ik ook wel een magnetron nodig ooit … voor hetzelfde geld … tja, toch maar beter die kopen.” Dat is hoe marketing werkt.
Koop gewoon die oven. Je weet wat je nodig hebt, gebruik hetgene dat precies die wens vervult, laat je niet verleiden door marketing. Het heeft geen zin om te denken “maar misschien heb ik ooit wel dat nodig”, want je kan de toekomst niet voorspellen.
Ik heb op mijn computer tientallen mini-programma’s staan, elk met een specifiek doel. Een programma om direct GIFjes mee op te nemen (voor als ik reclame wil maken voor mijn spellen). Een programma om code te schrijven. Een ander programma dat de code daadwerkelijk omzet in een app die je direct kan uitvoeren.
Al die programma’s samen nemen slechts een minuscuul deel van het geheugen in beslag. Mijn laptop start (na al die jaren) nog steeds snel op en ik kan binnen een minuut al verder met een spel ontwikkelen.
Bovendien is (bijna alles) wat ik gebruik open source. Dat betekent dat het gratis is en de hele code online staat. Waarom is dit belangrijk? Ten eerste: het scheelt geld. Ten tweede: als ik iets niet begrijp, kan ik de code opzoeken en lezen hoe het precies werkt. Ten derde: als ik iets nodig heb, kan ik het zelf programmeren en toevoegen! Ten vierde: dit zijn vaak superkleine programma’s.
Bijvoorbeeld: je hebt een diverse programma’s om spellen mee te ontwikkelen. De grootste daarvan zijn Unity en Unreal, waarmee de allergrootste bedrijven hun succesvolle spellen maken. Deze zijn gratis te downloaden en gebruiken … maar na jaren trouwe dienst heb ik ze toch voorgoed weggedaan.
Waarom? Ze zijn veel te groot en zwaar geworden. Ze namen te veel geheugen in op de computer, het duurde minuten voordat je überhaupt voorbij het laadscherm was, en voor elke instelling moest je langs vier verschillende menu’s omdat er zoveel opties waren.
In plaats daarvan gebruik ik nu veel kleinere “game engines”, zoals Godot. Je mist 10% van de functionaliteit/kracht, maar in ruil daarvoor heb je een programma dat sneller opstart, fijner werkt, en niet crasht.
Koop goedkopere apparatuur
Natuurlijk koop ik goedkope spullen vanwege geldgebrek.
Maar een tweede reden is net zo belangrijk: het dwingt mij om niet lui te zijn (zowel als programmeur als consument).
Ik moet extra moeite doen om mijn spellen te laten werken op mijn mobiel. Maar als mijn spellen werken op dat gebrekkige apparaat, dan moeten ze wel overal werken.
Steeds meer mensen hebben constant tientallen tabbladen openstaan (in hun browser) en tientallen apps (op hun smartphone). Hartstikke slecht natuurlijk! Kost allemaal energie en moeite, terwijl je het helemaal niet gebruikt. Sluit ze af, open iets alleen als je het echt gebruikt.
Sterker nog, haal je mobiel/laptop uit de oplader als hij (bijna helemaal) is opgeladen. Zet je internet uit als je het niet direct nodig hebt.
En als je goedkope apparatuur koopt … dan heb je geen andere keuze! Dan moet je wel deze moeite doen en goede gewoontes aanleren.
Die ene Netflix serie aanzetten terwijl je eigenlijk aan iets anders werkt? Kan helemaal niet! Op je mobiel zitten in het verkeer? Onmogelijk!
(Ik probeer al jaren mensen te vertellen dat multitasken een mythe is en dat ze moeten single tasken. Maar dat is een heel onderwerp op zichzelf, dus ik zal er niet verder over doorgaan hier.)
Analoog werkt ook gewoon
Het lijkt alsof steeds meer dingen digitaal (en online) worden gewoon omdat het kan.
Scholen geven leerlingen een tablet/laptop die ze altijd bij moeten hebben en gebruiken in de les, maar waarom? Sinds wanneer kan men alleen iets leren als het via een beeldscherm komt? Zijn boeken en praktische real-life colleges verbannen? En is men vergeten dat te veel achter een scherm zitten, zeker voor jonge mensen, ongelofelijk slecht is voor de gezondheid?
Als je notities wilt schrijven, zijn er honderden apps en websites te vinden. Maar een pen en papier werkt ook gewoon. Sterker nog, het werkt beter: je hebt meer vrijheid, je kunt het direct gebruiken, je raakt het niet kwijt omdat je het vergeet op te slaan, en de notities blijven beter in je hoofd hangen (want schrijven is beter voor informatieverwerking dan typen).
Probeer je apparaat alleen te gebruiken voor dingen die niet of minder makkelijk analoog kunnen. Want in vrijwel alle gevallen is de analoge variant beter en sneller, en de digitale variant vooral heel erg overbodig.
Een leeg canvas
Elke keer als je een nieuw project begint, elke keer als je een nieuw apparaat hebt, probeer te beginnen vanuit een leeg canvas.
Je zult ontdekken dat je veel dingen helemaal niet (meer) nodig hebt. Of dat sommige dingen sneller, makkelijker of creatiever kunnen.
Dit zijn dingen die je dus niet moet doen:
- Standaard allerlei programma’s installeren (die je ook op je oude apparaat had)
- Bergen met code/bestanden van vorige projecten automatisch kopiëren.
- Programma’s (of je hele apparaat) instellen zodat ze automatisch opstarten.
Ik zal een voorbeeld geven. Ik heb een keer mijn automatische tabbladen en internet uitgezet. Vroeger, als ik mijn laptop opstartte, werd meteen de browser opgestart en enkele standaardwebsites geopend (zoals mail en Facebook). Wat is het gevolg? Je wordt subtiel gedwongen in dat patroon mee te gaan. Het eerste wat je elke dag doet is je mail checken en een beetje over internet browsen, terwijl dat helemaal niet is waarom je de computer had aangezet.
Nu staat alles standaard uit. Als ik iets nodig heb, zet ik het zelf wel binnen vijf seconden aan. Ik ben vele malen productiever, de laptop start sneller op, en ik ben erachter gekomen dat ik veel dingen helemaal niet nodig heb!
Een ander voorbeeld zijn mijn websites (met uitzondering van, ironisch genoeg, dit blog). Ik heb al mijn websites helemaal zelf gebouwd. Ik heb zelfs geen code van vorige projecten verplaatst naar de nieuwe projecten. Waarom? Nou … waarom wel? Ik heb die vorige website zelf gebouwd. Ik weet dus hoe het moet. Als ik ooit iets soortgelijks nodig heb, kan ik het makkelijk opnieuw programmeren.
Door alleen te pakken wat ik nodig heb, en anderzijds vanuit een leeg canvas te beginnen, wordt elk project zo klein en simpel als maar kan.
Documentatie & Tests
Deze is vooral voor de programmeurs onder ons. Tja, hoe zeg ik dit … SCHRIJF DOCUMENTATIE.
Er zijn veel programmeurs die prachtige dingen schrijven. Die gratis (en/of open source) hulpmiddelen maken die, bijvoorbeeld, het ontwikkelen van spellen drastisch versimpelen. Ze brengen dit vervolgens uit, met blije berichten en de hoop dat vele mensen het gebruiken …
Maar ze vergeten altijd documentatie en test cases te schrijven.
En als je dat vergeet, dan kan niemand het gebruiken. Ook jijzelf niet, als het een iets groter project is over langere tijd.
Bijvoorbeeld: ik heb onlangs de game engine uitgeprobeerd genaamd Heaps. Er zijn al een handjevol extreem succesvolle spellen uitgebracht met deze engine, dus ik vond het toch een goed idee om er eens naar te kijken. Maar de documentatie is verschrikkelijk. Bijna niks is uitgelegd en voor veel onderdelen moet je zelf de code induiken. En wat kom je dan tegen? Code die eruitziet alsof ze hebben geprobeerd zo min mogelijk lettergrepen te gebruiken! Ik snap dat programmeurs niet perse goed zijn (of interesse hebben) in schrijven hoe hun systeem werkt, maar het is misschien wel het allerbelangrijkste wat je kan doen voor jouw project.
Als jij geen duidelijke structuur en opmerkingen achterlaat voor jezelf, weet je een paar weken later niet meer wat in vredesnaam de bedoeling was van dit deel van het project.
Tests zijn hiervan eigenlijk een extensie. Enerzijds moeten tests checken of de code werkt (zonder fouten), anderzijds zijn ze ook de specificatie. Jouw lijst aan testen beschrijft wat je code precies moet doen.
Ik zal een voorbeeld geven: stel jij hebt een deel van een programma dat, gegeven een lijst met filmtitels, deze lijst moet ordenen op alfabetische volgorde. Als titels met dezelfde letter beginnen, worden ze verder geordend op basis van hun reviews/rating.
Hoe zorg je ervoor dat je nooit vergeet dat dit de bedoeling is? Hoe zorg je ervoor dat je zeker weet dat het programma precies deze actie uitvoert? Precies, je schrijft een test die alleen slaagt als het programma het bovenstaande effect heeft.
(Je verzint een aantal niet bestaande films, zet die in een lijst, en checkt of de output van je code juist is.)
Door testen te schrijven sla je dus twee vliegen in één klap: je specificeert wat de bedoeling is én je test of dat doel wordt bereikt.
Opmerking: ik moet toegeven dat ik hierin ook nog kan verbeteren. Ik heb in het verleden veel dingen gratis online gegooid met het idee van “misschien heeft iemand er iets aan”, met niets meer dan een paragraafje uitleg wat het deed. Als ik daadwerkelijk mensen wil helpen, of later wil voortborduren op mijn eerdere werk, moet ik ook strakker mijn documentatie doen.
Opmerking: en dit geldt niet alleen voor programmeren, natuurlijk. Elk project moet werken met documentatie en tests. Als ik een verhaal schrijf, bijvoorbeeld, hou ik ook ondertussen een tweede document bij met wat ik precies allemaal heb gezegd en beweerd. En ik schrijf een lijstje met “specificaties” voor mezelf: dit is de stijl van schrijven, dit moet er gebeuren, dit mag nooit gebeuren, als deze twee personages elkaar ontmoeten moet er dit gebeuren. Het lijkt misschien een mechanische manier van schrijven, maar het heeft mij alleen maar voordelen opgeleverd.
Digitale geletterdheid
Als laatste komen we bij een meer abstract en ambitieus punt: de hele maatschappij moet beter worden onderwezen op het vlak van technologie.
Op mijn technische universiteit heb je een verplicht vak programmeren, ongeacht welke studie je doet. (Ik deed in dit geval Wiskunde.) Wat leer je in dat vak? Een heel specifiek programma schrijven zonder al te veel fouten. Je leerde de kernsyntax in één college, daarna was het een stuk of twintig kleine praktische opdrachten.
Driekwart van de studenten haalde een voldoende, maar begreep nog steeds niks van technologie, computers of programmeren.
Al die mensen zullen bij een bedrijf gaan werken, waar ze belangrijke dingen gaan modeleren, simuleren en uitrekenen. Zonder te weten wat er precies gebeurt. Zonder te weten hoe ze iets nieuws kunnen verzinnen, een beter programma kunnen schrijven, een proces kunnen optimalizeren.
En dat is dan een officiële programmeercursus op de universiteit waarvoor je veel studiepunten krijgt.
Ik vind het, eerlijk gezegd, best angstaanjagend. Gevoelige data, essentiële processen in de wereld, zullen binnen afzienbare tijd afhankelijk worden van mensen die eigenlijk niet weten wat ze aan het doen zijn.
Hoe lossen we dit op? Door programmeren niet te zien als een handige hobby, iets waarmee je misschien een flitsende website kan neerzetten, maar als een compleet vakgebied dat inmiddels al teruggaat tot het begin van de twintigste eeuw.
Technologie is niks anders, of zou niks anders moeten zijn, dan alles wat ik inmiddels heb opgenoemd:
- Je hebt een probleem. Een duidelijk, gespecificeerd, praktisch probleem.
- Je begint vanuit het niets: hou het simpel, hou het klein, hou het overzichtelijk.
- Je schrijft zelf code die precies doet wat je wilt, voor precies het probleem dat je wilt oplossen.
- Je schrijft duidelijke documentatie en tests.
- Waar mogelijk geef je juist minder verantwoordelijkheden aan de technologie: een analoge oplossing of meer creatieve oplossing is altijd beter.
- Elke keer als je in het probleem duikt, kijk je of de code nét ietsje schoner kan. Of je het project iets beter kan structureren, kan opruimen, sneller kan laten lopen. Probeer niet eindeloos te bouwen op drijfzand.
Programmeren is problemen oplossen. Technologie is leren communiceren met een 100% logisch apparaat—namelijk, de computer.
Dat hele gedoe met programmeren, de juiste code schrijven, de juiste tekens kennen, is eigenlijk maar bijzaak. Het is de handeling aan de oppervlakte.
De rest van digitale geletterdheid zit in de kern van logisch denken, problemen oplossen, en dit vervolgens communiceren: zowel aan de computer als aan de mens.
Dat zouden ze moeten leren.
Conclusie
Hopelijk heb je uit dit artikel wat dingen meegenomen om beter om te gaan met technologie en ervoor te zorgen dat kwaliteit van software en projecten niet achteruitgaat.
Technologie gaat een steeds grotere rol spelen in deze wereld, dat is niet te ontkennen. Het belangrijkste is dat wij allemaal moeite doen om het te begrijpen en in een positieve richting te sturen, in plaats van dat onze laksheid en onwetendheid uiteindelijk slechts verval betekent.
Doe aan single tasken. Haal alles van je apparaten wat je niet nodig hebt. Sluit je computer/smartphone af wanneer je gaat slapen. Probeer echt te begrijpen hoe dingen werken en wat je doet (en waarom je dat moet doen). Hou alles zo klein en simpel mogelijk.
En bovenal, leer communiceren met de computer, en leer communiceren over de computer met anderen.