Van rader in het geheel naar bron van talent
Hoe ziet een bedrijf haar personeel? Een hint van een antwoord zit ‘m in de daaraan toegewijde afdeling: human resource management. Personeel is een resource, een hulpbron - net als het IT-systeem, maar dan menselijk - die gemanaged moet worden. Die metafoor heeft enkele interessante consequenties, die inderdaad regelmatig haar uitwerking vinden in de praktijk: medewerkers zijn raderen in het geheel, ze moeten op hun prestaties beoordeeld worden en kunnen eenvoudig vervangen worden wanneer ze een negatieve impact hebben op dat geheel. Die zienswijze is hopeloos achterhaald, betoogt Rob van den Berg in Futureproof talentmanagement.
Hoe ziet een leercultuur eruit?
Mijn zelfstudietijd - dat is de tijd waarin ik mijn ervaringen over softwareontwikkeling uitwerk in blogs als deze - is mij heilig. De afgelopen jaren heb ik gemerkt dat als je structureel de tijd neemt om je kennis te verbreden en te verdiepen (en te documenteren!), dit zich met rente terugbetaalt in je productiviteit als ontwikkelaar. Dat inzicht is een cadeau dat ik mijn collega’s van harte gun. Nieuwe dingen leren en - net zo belangrijk! - die kennis met je collega’s delen is iets wat helaas nog veel te weinig gebeurt op onze afdeling.
Een presentje voor presenters
Lieve collega’s, bedankt voor alle toffe presentaties die jullie (met een beetje druk van mijn kant) hebben willen verzorgen het afgelopen jaar, ik kan niet in woorden uitdrukken hoe zeer ik jullie waardeer! Ik hoop dat dit wijntje iets van die dankbaarheid over kan brengen. De volgende keer zal die blijk van waarderig een stuk minder lang op zich laten wachten, beloofd!
Test het systeem, niet de class
Het is belangrijk om vast te stellen dat er een bug in het systeem was geslopen, ondanks dat de functionaliteit die de bug veroorzaakte ogenschijnlijk gedekt was door tests. Waarom “ogenschijnlijk”? De class die de serialisatie voor zijn rekening nam, werd wel getest, maar alleen in isolatie en niet in de context van het systeem. - Vraag je af wat de implicatie daarvan is. Het betekent dat onze tests bewezen dat een class naar behoren werkt. Of het systeem als geheel naar behoren werkt, dat kunnen we op basis van de tests niet concluderen. Terwijl dat juist is waar het om gaat!
Nog zes dingen die ik leerde op Techorama
Een tijd geleden bezocht ik softwareconferentie Techorama in Utrecht. Vandaag pen ik kort neer welke inzichten ik de tweede dag opdeed.
Wat is een unit?
Een tijd geleden presenteerde ik enkele ideeën over testen aan mijn collega’s. Toen ik aankwam bij het gedeelte waarin ik stelde je het best via de voordeur kunt testen, stelde een collega apodictisch: “Een unittest test een openbare method op een class. Elke afhankelijkheid op die class moet je mocken.” Dat is een manier om er naar te kijken, zeker. Het is de zogenaamde mockist strategie, ook wel bekend als de Londense school van unittesten. De vraag waar ik me op wil richten is: waar komt de aantrekkingskracht van deze strategie dan vandaan? Ik geloof dat deze voortkomt een bepaalde interpretatie van wat een unittest is of moet zijn. Meer specifiek: wat de unit in unittest is of moet zijn.
Zes dingen die ik leerde op Techorama
Een tijd geleden bezocht ik softwareconferentie Techorama in Utrecht. Ik hoorde een boel nieuwe ideeën, werd gesterkt in enkele van mijn al bestaande overtuigingen, en uitgedaagd sommige ingesleten gewoonten te herzien. Uit mijn stapel aantekeningen destilleer ik zes inzichten die ik alleen al de eerste dag opdeed.
Waarom zijn zoveel programmeurs bètanerds?
Als filosoof kan ik een titel als How do our ideas about coding affect the software we create? natuurlijk moeilijk weerstaan - en ik heb dan ook met veel plezier naar het gelijknamige praatje van Christin Gorman gekeken. Gorman begint vanuit een probleem: de softwareontwikkelpopulatie (3x woordwaarde) is weinig divers. Ze bestaat, gechargeerd gezegd, voor het grootste gedeelte uit nerds met interesses in de hoek van de bètawetenschappen. Hoe komt dat?
Het Single-Responsiblity Principe en mijn keukenkastjes
Ik vind er wat van dat ik twee verschillende keukenkastjes moet openen voor iets wat in feite één handeling is. Ga maar na: wanneer pak je een koffiekopje? Als je koffie gaat zetten. En wanneer pak je een koffiepad? Als je koffie gaat zetten. Het pakken van een koffiekop gaat altijd gepaard met het pakken van een koffiepad. Het is een atomaire handeling.
De fix die productie om zeep hielp
“De fix staat op productie,” meldden we trots. “Het bleek te liggen aan wat validatielogica die in dit specifieke scenario wat te streng bleek - enfin, een technisch verhaal, dat hoef je niet te weten. Het enige wat je hoeft te weten is: we hebben weer eens geweldig werk geleverd, bedankjes worden gewaardeerd maar zijn niet noodzakelijk.” En we leefden nog lang en gelukkig. Een halfuur lang. Want toen kregen we een berichtje: “Help! Ik kan nu geen enkel item meer inzien!”