Een (verre van complete) lijst boekentips
Ter voorbereiding op een praatje, heb ik de lijst aan softwareboeken die ik de afgelopen jaren heb gelezen eens goed doorgelopen. Het resultaat zou als referentiemateriaal kunnen dienen voor een opleidingstraject van junioren binnen een organisatie, of kan als inspiratie worden gebruikt voor een boekenclub, of als gewoon een lijst goede boeken voor wie zijn kennis over softwareontwikkeling bij wil spijkeren.
Over boeken en boekenclubs (3/3)
Dus: je wil een boekenclub starten, maar je weet niet waar je moet beginnen. Dit is een suggestie: begin eens na te denken over een geschikt boek. Lees verder voor een aantal tips.
Over boeken en boekenclubs (2/3)
Een boekenclub is een investering. Elke minuut die ontwikkelaars besteden aan het lezen en bediscussiëren van ideeën over softwareontwikkeling, is een minuut die ze niet kunnen besteden aan het daadwerkelijk ontwikkelen van software. Dat maakt het belangrijk om steun van je manager te hebben vóórdat je een boekenclub begint.
Over boeken en boekenclubs (1/3)
Het beste werkgerelateerde advies dat ik ooit heb gekregen, kreeg ik van mijn eerste manager. Ik was nog maar net begonnen als softwareontwikkelaar en worstelde met de enorme complexiteit die kwam kijken bij het onderhouden van een legacy codebase. Hij zei (ik parafraseer): “Je hebt de ballen verstand van softwareontwikkeling. Houd de vrijdagen vrij voor zelfstudie, en lees eens een boek.”
Ik vluchtte voor een PI-planning en wat er toen gebeurde zul je niet geloven
Hoe vaak komt het niet voor dat je met je team een besluit neemt – met de twijfelachtige zegening van schoorvoetend instemmende collega’s die het achterste van hun tong zorgvuldig uit zicht houden? Of erger nog: dat jullie unaniem een knoop doorhakken om er een paar dagen, weken of maanden later te moeten constateren dat die knoop massaal de wind in wordt geslagen?
Wat is refactoring (volgens Hannah Arendt)?
Wat kunnen Hannah Arendts filosofische overpeinzingen ons leren over refactoring? Nou, bijvoorbeeld waarom de metafoor van technische schuld een misleidende is. Maar als refactoring niet het afbetalen van technische schuld is, wat is het dan wel? En wat betekent dat voor de rol die refactoring in onze dagelijkse werkzaamheden in mag (of moet?) nemen?
Koppeling buiten code om
Koppeling is: wanneer een wijziging in het ene systeem een wijziging in het andere systeem noodzakelijk maakt. Wanneer softwareontwikkelaars het over koppeling hebben, dan bedoelen we meestal: in code aan elkaar gekoppelde systemen. Maar twee systemen kunnen ook zuiver functioneel aan elkaar gekoppeld zijn, zonder ook maar één regel code te hoeven delen.
De bouwmetafoor gaat niet eens op voor de bouw
De bouw anno nu heeft veel ideeën uit agile en lean geïncorporeerd en heeft daarom tegenwoordig – grappig genoeg – meer weg van softwareontwikkeling dan je zou verwachten. Dus niet alleen softwareontwikkeling is niet als het bouwen van een huis – zelfs het bouwen van een huis blijkt niet als het bouwen van een huis!
Sabotage!
Onlangs volgde ik een training Deep Democracy – en werd ik bewust gemaakt van enkele valkuilen en disfunctionele patronen in samenwerking. Eén van de interessantste inzichten die ik opdeed hadden te maken met sabotage: het ondermijnen van (een deel van) de groep. Dat kan op allerlei manieren gebeuren, van het maken van (sarcastische) grappen tot roddelen tot tegenwerken of zelfs staken. Het zijn allemaal voorbeelden van “ja zeggen maar nee doen.”