Voorbeeldarchitectuur
Een collega in een ander team is bezig een oude applicatie te vernieuwen. Hij vroeg een andere senior en ik om zijn opzetje voor een nieuwe structuur te reviewen. Zelf had ik, merkte ik, geen sterke meningen over de code – of liever: de implementatie. Zit er een goed vangnet omheen? Dan geloof ik het wel. Ik had tegen het eind van de sessie één vraag: “Is de complexiteit van de code in verhouding met de complexiteit van het probleem?”
Vijf dynamieken van een goed functionerend team
Uit een onderzoek van Google uit 2015 blijken de volgende vijf dynamieken het meest bij te dragen aan een goed functionerend team: (1) psychologische veiligheid; (2) betrouwbaarheid; (3) structuur en helderheid; (4) betekenis, en (5) impact.
Bug, hoge prio (een retrospectief)
Ze zeggen, elk probleem is ook een communicatieprobleem. Dit is een communicatieprobleem. De ontwikkelaar communiceert niet. De tester communiceert niet. De ops’er communiceert niet. De enige die communiceert is de ontwikkelaar die, vanuit het bevindingenoverleg, trouw de bugs meldt. – Maar: hoe communiceert de teamleider?
Duplicatie en veranderlijkheid
Toen ik met vakantie ging, kreeg onze junior, met hulp van een externe partij, de taak onze infrastructuur te herstructureren naar gestandaardiseerde componenten. Hij deed dat eerst voor onze acceptatieomgeving. Daarna was het tijd voor de productieomgeving. De vraag was nu: dupliceren we de Bicep-bestanden van onze acceptatieomgeving, of parameteriseren we die bestanden zodat ze voor beide omgevingen werken?
Wanneer update je je dependencies?
Jouw code is niet jouw code. Jouw code is een onderdeel van een compleet ecosysteem aan code. Jouw code is afhankelijk van een onbezonnen hoeveelheid third party libraries. Jouw code is waarschijnlijk het kleinste deel van je eigenlijke codebase. Al die andere code moet je ook onderhouden. Niet door er zelf wijzigingen aan door te voeren, maar door deze afhankelijkheden regelmatig te updaten. Wanneer is het beste moment om dat te doen?
Hoe commit messages ons helpen samenwerken
Wie met PR’s werkt, werkt met elk groen vinkje zijn administratie bij: die ontwikkelaar heeft de code geschreven en deze ontwikkelaar heeft die code gereviewd. De rolverdeling wordt automatisch in een systeem vastgelegd. Zoiets hadden wij niet – niet automatisch.
PR's vs. pairs
Je maakt een branch, je wijzigt de code. Je maakt een pull request (PR) aan om deze te integreren in de main branch. Voordat die code toegestaan wordt, moet deze eerst door een collega worden bekeken. Pas als deze zijn zegening heeft gegeven, mag de code worden geïntegreerd. – Vanwaar deze opzet?
Procesbeschrijving pair programming
In mijn team werken we niet met pull requests. Maar hoe werken we dan? Onze security officer vroeg me een procesbeschrijving op te stellen, deels om de auditers mee tevreden te stellen en deels om kennis te delen.
Dertien memes
Voor een sessie over bedrijfscultuur maakte kunstenaarscollectief ’enkele collega’s en ik’ een aantal memes. Deze hadden als doel de lachspieren te trainen en tot discussie te prikkelen. Dit is een virtuele expositie.