Hoe lang hoort een Sprint Review te duren?
Soms sluit ik wel eens aan bij de Sprint Reviews van collega-teams. Wat me daarbij opvalt, is dat er een behoorlijke diversiteit in tijdsduur is tussen de Reviews van de verschillende teams. De onze zijn getimeboxt op een uur en ’n kwartier, al duren ze in de praktijk meestal ongeveer een uur. Maar ik woon ook Reviews bij van een halfuurtje. Wat is er aan de hand?
Waarom ik twee keer per week blog
Een collega vroeg me eens: “Twee keer per week bloggen, is dat niet heel erg veel?” Mijn antwoord was: “Het is uitdagend.” Nu ik erop reflecteer, besef ik dat je zijn vraag op twee manieren op kan vatten. De eerste, en volgens mij meest voor de hand liggende: zitten er wel genoeg uren in de week om goed en wel twee blogs te kunnen schrijven? Maar de tweede is even gegrond: heb je wel genoeg materiaal om twee keer per week over te schrijven?
Hoe leer je eigenlijk programmeren?
Hoe leert iemand programmeren? Felienne Harmans stelt deze vraag naar aanleiding van een persoonlijke anekdote over de tijd dat ze jonge kinderen lesgaf over het onderwerp. Ze geeft ruiterlijk toe, als onbewust onbekwame leraar, in eerste instantie terug te vallen op de manier waarop ze zelf leerde programmeren: door het te doen. Maar is ontdekkend leren de beste manier om te leren programmeren? Te oordelen naar het succes van haar leerlingen, concludeert Hermans: nee, bepaald niet.
Code reviews als leermiddel
Toen ik begon als softwareontwikkelaar, was ik eerlijk gezegd een beetje bang voor code reviews. Inmiddels zijn de rollen omgedraaid, en zijn mijn collega’s banger voor mijn code reviews dan ik voor die van hen. Feit is dat ik een stuk scheutiger ben met mijn opmerkingen dan mijn collega’s. Toch denk ik dat er in mijn commentaar maar weinig is om bang voor te zijn. Ik zie code reviews namelijk niet als middel en moment om kritiek te geven op andermans code. Of liever: niet alleen als middel en moment om kritiek te geven.
Vakantie vs. enigszins vakantie
Er zijn twee soorten activiteiten in het leven: activiteiten die je energie kosten en activiteiten die je energie opleveren. De truc is een balans te vinden. Om manieren te zoeken om de balans tussen de eerste en de tweede soort activiteit in het voordeel - hoe licht ook - van de eerste te beslechten. Deze vakantie heb ik enigszins bewust het besluit genomen me zo min mogelijk met softwareontwikkeling bezig te houden. Ik was van mening dat het tijd was om de energiebalans met andere activiteiten aan te vullen.
Over het hek van Chesterton
Ik ben niet vies van het refactoren van code die ik onduidelijk vind, of zelfs van weggooien van (meestal dode) code. Dat is een goede eigenschap wanneer je het met beleid doet en een slechte als het uit louter enthousiasme voorkomt. De eerste resulteert in helderder en eenvoudiger code, de tweede in buggy software. Waar zit hem precies het onderscheid in? Het antwoord vond ik in Software Engineering at Google in het hoofdstuk over kennisdeling.
Twee sonnetten over software ontwikkelen
Stakeholder, u stijgt pas echt in achting / Als u - prijs de Heer voor dit geluk! - / Inziet wanneer niet de code de bug / Herbergt, maar uw eigen verwachting.
De blog die ik nooit schreef
Op 23 augustus maakte ik uitgebreide aantekeningen voor een blog - en in de maanden daarna deed ik mijn uiterste best die aantekeningen vooral niet uit te werken. Sindsdien vervuilt deze pseudoblog de broncode van deze website eigenlijk alleen maar. Ik zou ’m natuurlijk weg kunnen gooien, maar aan de andere kant: ik zou het ook niet kunnen doen. Dit is een deconstructie van de blog die ik nooit schreef.
Drie tips voor beginnende bloggers
Ik ben de laatste die zal beweren dat ‘ie een expert is op het gebied van bloggen. Maar aan de andere kant: ik blog wel al een maandje of wat twee keer per week. Dus ik geloof dat ik met minimale autoriteit over het onderwerp mag spreken - oftewel: met evenveel autoriteit als over elk onderwerp dat op deze blog voorbijkomt. Bij dezen: dit zijn drie tips die ik softwareontwikkelaars mee zou willen geven die een blog over hun vakgebied zouden willen beginnen.
Dertig seconden winst in twee commits
Eén enkele commit was voldoende om de latency van een cruciale call naar onze back-end te verlengen van minder dan één seconde naar twintig tot dertig (!) seconden. Wat was er in hemelsnaam gebeurd?