Tag Communicatie
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?
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.
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.”
Refactoring als communicatiemiddel
We refactoren niet alleen om het makkelijker te maken de code te wijzigen, we refactoren ook om de code zo helder mogelijk te laten communiceren. En code die helder communiceert is op zijn beurt weer makkelijker om te wijzigen.
Wat zegt deze test?
“Wat zegt deze test?” – Het meest voor de hand liggende antwoord is natuurlijk: wat de code doet. Maar dat is slechts wat een test expliciet zegt, de informatie die een test inhoudelijk overbrengt. Dat is niet het enige wat het zegt – verre van.
Wat zegt deze code?
De namen in onze code – van variabelen, velden, methoden, parameters – beschrijven wat de code doet. De naam van een class beschrijft haar wezen: integer, Url, ResourceHelper. Anders dan bij mensen gaat de existentie van code niet vooraf aan haar essentie. Code is bepaald, bepaald door haar functie. Wat die functie is, weet een goede programmeur in een naam te vangen.
De edele kunst van het pull request
Veel ontwikkelaars zien code reviews als een hinderlijke onderbreking van hun werkzaamheden. Maar het goed kunnen beoordelen van een codewijziging is essentieel om de kwaliteit van een codebase op peil te houden. Gelukkig hoeft dit proces niet pijnlijk te zijn. Aan het eind van deze sessie weet je welke vragen je moet stellen voor een geslaagde code review – en hoe je deze informatie zo effectief mogelijk overbrengt in je PR.
Formuleer je kernwaarden
Hoe ziet softwareontwikkeling er – volgens jou – idealiter uit? Hoe functioneert een ontwikkelteam op de toppen van z’n kunnen? Wat is de verhouding tot hun stakeholders en collega’s? Hoe ondersteunt het management daarin? – Als je dat plaatje eenmaal scherp hebt, wat kun je dan concluderen over de kernwaarden van waaruit je software ontwikkelt?
Mijn eerste code review
De tijd maakt alles kapot – maar nu ben ik nog jong genoeg om me mijn eerste code review te herinneren. Althans, ik herinner me een gevoel – want de inhoud van het pull request ben ik natuurlijk allang kwijt. Het gevoel laat zich denk ik het best omschrijven als een vorm van hulpeloosheid – gevolgd door ongemak.
De verplichte ChatGPT-blog
Met hulp van ChatGPT wist ik in een uurtje het functionele equivalent te leveren van code waar ik eerder dagen op heb zitten zwoegen. De tijdwinst is onomstotelijk. En op het vlak van informatieoverdracht is ChatGPT een ons “echte” ontwikkelaars mijlenver vooruit.