Een programma in je hoofd houden | undefined

Augustus 2007

Een goede programmeur die intensief aan zijn eigen code werkt, kan die in zijn hoofd houden op de manier waarop een wiskundige een probleem dat hij onderzoekt, vasthoudt. Wiskundigen beantwoorden vragen niet door ze op papier uit te werken zoals schoolkinderen leren. Ze doen meer in hun hoofd: ze proberen een probleemruimte goed genoeg te begrijpen dat ze eromheen kunnen lopen zoals je rond het huis kunt lopen waarin je bent opgegroeid. Op zijn best is programmeren hetzelfde. Je houdt het hele programma in je hoofd en je kunt het naar believen manipuleren.

Dat is vooral waardevol aan het begin van een project, omdat aanvankelijk het belangrijkste is om te kunnen veranderen wat je doet. Niet alleen om het probleem op een andere manier op te lossen, maar om het probleem dat je oplost te veranderen.

Je code is je begrip van het probleem dat je onderzoekt. Dus pas als je je code in je hoofd hebt, begrijp je het probleem echt.

Het is niet gemakkelijk om een programma in je hoofd te krijgen. Als je een project een paar maanden laat liggen, kan het dagen duren om het weer echt te begrijpen als je eraan terugkeert. Zelfs als je actief aan een programma werkt, kan het een half uur duren om het elke dag in je hoofd te laden als je begint te werken. En dat is in het beste geval. Gewone programmeurs die onder typische kantooromstandigheden werken, komen nooit in deze modus. Of om het dramatischer te zeggen, gewone programmeurs die onder typische kantooromstandigheden werken, begrijpen de problemen die ze oplossen nooit echt.

Zelfs de beste programmeurs hebben niet altijd het hele programma waar ze aan werken in hun hoofd geladen. Maar er zijn dingen die je kunt doen om te helpen:

Vermijd afleidingen. Afleidingen zijn slecht voor veel soorten werk, maar vooral slecht voor programmeren, omdat programmeurs de neiging hebben te opereren op de grens van de details die ze kunnen hanteren.

Het gevaar van een afleiding hangt niet af van hoe lang deze duurt, maar van hoe erg het je hersenen ontregelt. Een programmeur kan het kantoor verlaten en een broodje gaan halen zonder de code in zijn hoofd te verliezen. Maar het verkeerde soort onderbreking kan je hersenen in 30 seconden wissen.

Vreemd genoeg kunnen geplande afleidingen erger zijn dan ongeplande. Als je weet dat je over een uur een vergadering hebt, begin je niet eens aan iets moeilijks.

Werk in lange sessies. Aangezien er elke keer dat je aan een programma begint te werken een vaste kost is, is het efficiënter om in een paar lange sessies te werken dan in vele korte. Er komt natuurlijk een punt waarop je dom wordt omdat je moe bent. Dit verschilt van persoon tot persoon. Ik heb gehoord van mensen die 36 uur achter elkaar hacken, maar het meeste dat ik ooit heb kunnen beheren is ongeveer 18, en ik werk het beste in blokken van niet meer dan 12.

Het optimum is niet de limiet die je fysiek kunt verdragen. Er is zowel een voordeel als een kostprijs verbonden aan het onderbreken van een project. Soms, als je na een rustpauze terugkeert naar een probleem, vind je dat je onbewuste geest een antwoord voor je heeft klaarliggen.

Gebruik beknopte talen. Meer krachtige programmeertalen maken programma's korter. En programmeurs lijken programma's tenminste gedeeltelijk te denken in de taal waarin ze ze schrijven. Hoe beknopter de taal, hoe korter het programma, en hoe gemakkelijker het is om het in je hoofd te laden en te houden.

Je kunt het effect van een krachtige taal vergroten door een stijl te gebruiken die bottom-up programmeren wordt genoemd, waarbij je programma's in meerdere lagen schrijft, waarbij de lagere lagen fungeren als programmeertalen voor de lagen erboven. Als je dit goed doet, hoef je alleen de bovenste laag in je hoofd te houden.

Herschrijf je programma continu. Het herschrijven van een programma levert vaak een schoner ontwerp op. Maar het zou voordelen hebben, zelfs als dat niet zo was: je moet een programma volledig begrijpen om het te herschrijven, dus er is geen betere manier om het in je hoofd te krijgen.
Schrijf leesbare code. Alle programmeurs weten dat het goed is om leesbare code te schrijven. Maar jij bent zelf de belangrijkste lezer. Vooral in het begin; een prototype is een gesprek met jezelf. En als je voor jezelf schrijft, heb je andere prioriteiten. Als je voor andere mensen schrijft, wil je code misschien niet te dicht maken. Sommige delen van een programma zijn misschien het gemakkelijkst te lezen als je dingen uitspreidt, zoals een inleidend leerboek. Terwijl als je code schrijft om deze gemakkelijk in je hoofd te herladen, het misschien het beste is om voor beknoptheid te gaan.
Werk in kleine groepen. Wanneer je een programma in je hoofd manipuleert, stopt je zicht meestal aan de rand van de code die je bezit. Andere delen begrijp je minder goed, en belangrijker nog, je kunt er geen vrijheden mee nemen. Dus hoe kleiner het aantal programmeurs, hoe vollediger een project kan muteren. Als er maar één programmeur is, zoals er in het begin vaak is, kun je allesomvattende herontwerpen uitvoeren.
Laat niet meerdere mensen aan hetzelfde stuk code werken. Je begrijpt de code van anderen nooit zo goed als je eigen code. Hoe grondig je het ook hebt gelezen, je hebt het alleen gelezen, niet geschreven. Dus als een stuk code door meerdere auteurs is geschreven, begrijpt geen van hen het zo goed als een enkele auteur dat zou doen.

En natuurlijk kun je niet veilig iets herontwerpen waar anderen aan werken. Het is niet alleen dat je toestemming zou moeten vragen. Je laat jezelf niet eens aan zulke dingen denken. Het herontwerpen van code met meerdere auteurs is als het veranderen van wetten; het herontwerpen van code die je alleen beheert, is als het zien van de andere interpretatie van een dubbelzinnig beeld.

Als je meerdere mensen aan een project wilt laten werken, verdeel het dan in componenten en geef elk aan één persoon.

Begin klein. Een programma wordt gemakkelijker in je hoofd te houden naarmate je er meer vertrouwd mee raakt. Je kunt delen als black boxes gaan behandelen zodra je je zeker voelt dat je ze volledig hebt onderzocht. Maar als je voor het eerst aan een project begint te werken, word je gedwongen alles te zien. Als je met een te groot probleem begint, kun je het misschien nooit helemaal bevatten. Dus als je een groot, complex programma moet schrijven, is de beste manier om te beginnen misschien niet om er een specificatie voor te schrijven, maar om een prototype te schrijven dat een deel van het probleem oplost. Wat de voordelen van planning ook mogen zijn, ze worden vaak overschaduwd door de voordelen van het kunnen houden van een programma in je hoofd.

Het is opvallend hoe vaak programmeurs per ongeluk alle acht punten raken. Iemand heeft een idee voor een nieuw project, maar omdat het niet officieel is goedgekeurd, moet hij het in zijn vrije uren doen - wat productiever blijkt te zijn omdat er geen afleidingen zijn. Gedreven door zijn enthousiasme voor het nieuwe project werkt hij er vele uren achter elkaar aan. Omdat het aanvankelijk slechts een experiment is, gebruikt hij in plaats van een "productie"-taal slechts een "scripting"-taal - die in feite veel krachtiger is. Hij herschrijft het programma meerdere keren; dat zou voor een officieel project niet te rechtvaardigen zijn, maar dit is liefdewerk en hij wil dat het perfect is. En omdat niemand het anders dan hijzelf zal zien, laat hij alle opmerkingen weg, behalve die van het type notitie-aan-zelf. Hij werkt per se in een kleine groep, omdat hij het idee nog aan niemand anders heeft verteld, of het lijkt zo veelbelovend dat niemand anders eraan mag werken. Zelfs als er een groep is, konden ze niet meerdere mensen aan dezelfde code laten werken, omdat deze te snel verandert om dat mogelijk te maken. En het project begint klein omdat het idee in het begin klein is; hij heeft gewoon een coole hack die hij wil proberen.

Nog opvallender is het aantal officieel goedgekeurde projecten dat alle acht dingen verkeerd doet. Sterker nog, als je kijkt naar de manier waarop software in de meeste organisaties wordt geschreven, is het bijna alsof ze bewust proberen dingen verkeerd te doen. In zekere zin doen ze dat ook. Een van de bepalende kwaliteiten van organisaties sinds er zoiets bestaat, is het behandelen van individuen als uitwisselbare onderdelen. Dit werkt goed voor meer paralleliseerbare taken, zoals oorlog voeren. Voor het grootste deel van de geschiedenis kon een goed getraind leger van professionele soldaten een leger van individuele krijgers verslaan, hoe moedig ook. Maar ideeën hebben is niet erg paralleliseerbaar. En dat zijn programma's: ideeën.

Het is niet alleen waar dat organisaties een hekel hebben aan de afhankelijkheid van individuele genialiteit, het is een tautologie. Het maakt deel uit van de definitie van een organisatie om dat niet te doen. Althans, van ons huidige concept van een organisatie.

Misschien zouden we een nieuw soort organisatie kunnen definiëren die de inspanningen van individuen combineert zonder dat ze uitwisselbaar hoeven te zijn. Een markt is ongetwijfeld zo'n vorm van organisatie, hoewel het nauwkeuriger kan zijn om een markt te beschrijven als een gedegenereerd geval - als wat je standaard krijgt als organisatie niet mogelijk is.

Waarschijnlijk is het beste wat we kunnen doen een soort hack, zoals het anders laten werken van de programmeeronderdelen van een organisatie dan de rest. Misschien is de optimale oplossing voor grote bedrijven om ideeën niet eens in-huis te ontwikkelen, maar ze simpelweg te kopen. Maar ongeacht wat de oplossing blijkt te zijn, de eerste stap is beseffen dat er een probleem is. Er zit een tegenstrijdigheid in de uitdrukking "softwarebedrijf". De twee woorden trekken in tegengestelde richtingen. Elke goede programmeur in een grote organisatie zal er in conflict mee komen, omdat organisaties zijn ontworpen om te voorkomen wat programmeurs nastreven.

Goede programmeurs slagen er toch in veel te bereiken. Maar vaak vereist het praktisch een daad van rebellie tegen de organisaties die hen in dienst hebben. Misschien helpt het als meer mensen begrijpen dat de manier waarop programmeurs zich gedragen wordt gedreven door de eisen van het werk dat ze doen. Het is niet omdat ze onverantwoordelijk zijn dat ze in lange sessies werken waarin ze alle andere verplichtingen afzeggen, rechtstreeks in programmeren duiken in plaats van eerst specificaties te schrijven, en code herschrijven die al werkt. Het is niet omdat ze onvriendelijk zijn dat ze liever alleen werken, of grommen naar mensen die hun hoofd om de deur steken om hallo te zeggen. Deze schijnbaar willekeurige verzameling vervelende gewoonten heeft één enkele verklaring: de kracht van het houden van een programma in je hoofd.

Of het begrijpen hiervan grote organisaties kan helpen of niet, het kan zeker hun concurrenten helpen. Het zwakste punt van grote bedrijven is dat ze individuele programmeurs geen geweldig werk laten doen. Dus als je een kleine startup bent, is dit de plek om ze aan te vallen. Pak de soort problemen aan die in één groot brein moeten worden opgelost.

Dank aan Sam Altman, David Greenspan, Aaron Iba, Jessica Livingston, Robert Morris, Peter Norvig, Lisa Randall, Emmett Shear, Sergei Tsarev en Stephen Wolfram voor het lezen van concepten hiervan.