Tag bedrijfscultuur
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.
Leiden zonder romantiek
Wat maakt een goede leider? Daar zijn bibliotheken over volgeschreven. Leiders zijn aanvoerders: moedig gaan ze voor de troepen uit. Ze maken groei mogelijk. Verheven zijn ze, een voorbeeld voor de rest. Maar ze zijn ook je maatje. Vaak bedienen we ons van dit soort romantische beelden als we het over leiders hebben. De praktijk, merkt veranderkundige Joost Kampen op in Destructief leiderschap, is vaak weerbarstiger.
Leren leren op het werk
De mens is een lerend wezen. Wie zijn ogen ervoor openhoudt, ziet dat we haast elke dag wel een nieuw inzicht opdoen. Maar zodra men aan het werk gaat, lijkt een groot deel van de mensen die lerende houding thuis te laten. Sterker nog, goedbedoelde leerinitiatieven worden van tijd tot tijd zelfs met vijandigheid begroet. Waarom? Zijn we toch niet zo lerend als je op voorhand zou denken?
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.
Succesvol falen
Van fouten kun je leren, zegt men. Daaruit volgt: hoe meer fouten je maakt, hoe meer leerkansen je creëert. Eigenlijk zou je het maken van fouten dus moeten vieren. Hoe meer er mis gaat, hoe meer je leert – en hoe meer je leert, hoe minder er mis zal gaan. Toch is dat niet hoe het in veel organisaties werkt. Daar wordt er hard gewerkt om fouten te voorkomen. Erger nog, medewerkers die de mist in gaan, worden afgerekend op hun misstappen. Dat maakt hen voorzichtig, conservatief. En daardoor staan ze hun eigen groei – en die van de organisatie – in de weg.
Gedachten naar aanleiding van een PI-planning
Ik had onlangs het geluk aanwezig te mogen zijn bij een Program Increment-planning - kortweg: PI-planning. Het was de tweede die mijn werkgever ooit organiseerde, en de eerste waar ontwikkelaars bij aanschoven. Het was een hele ervaring. En ik zal in wat volgt kort reflecteren op die ervaring.
Eindgebruikers horen
De snelste weg naar tevreden gebruikers, is door goede software te bouwen die doet wat het moet doen. Dat klinkt makkelijk en dat is het niet. Waarom niet? Omdat software bouwen niet een kwestie van bouwen alleen is. Als dat zo zou zijn, dan zou de beste softwareontwikkelaar een mensenschuwe programmeur zijn, iemand die je het best met rust kunt laten, terwijl ‘ie als een razende specificaties omzet in code.
Blog #100!
Een minimijlpaal: dit is mijn honderste blog! In krap een jaar heb ik 80.168 woorden over softwareontwikkeling geschreven, gecategoriseerd onder 112 tags. Het leek me een mooi moment voor een knap staaltje navelstaren, met hier en daar een snuifje zelfpijperij. Bij dezen: tien blogs waar ik met iets van plezier op terugkijk.
De rol van user stories
Wie The Art of Agile Development van James Shore doorbladert, doet heel nieuwe opzichten op. Zijn hoofdstuk over stories (ook wel bekend als user stories) deed me wel opveren, in elk geval. Shores stelling - mening? inzicht? - is provocatief: een story moet op een index card passen. de volledige story zou dus uit niet meer dan een zin of een kreet hoeven bestaan.
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.