Tag software ontwikkelaar (rol)
First time right?
Na afloop van mijn praatje kreeg ik de vraag of ik geloof in het idee van first time right. Mijn antwoord was: “Ik geloof niet dat er zoiets bestaat als first time right. Maar ik geloof wel in first time een stuk beter dan we het nu doen.” Tijd om dat antwoord verder uit te werken, was er op dat moment niet. Maar de vraag bleef wel in mijn achterhoofd spoken. Is het mogelijk om een systeem in één keer goed te bouwen?
Codefluisteren
Een goede codefluisteraar kan in een stuk code werken en hoort dan – aanvankelijk zachtjes, maar met ervaring steeds duidelijker – plots een probleem. Het probleem is niet: de code werkt niet. Het probleem is: ik als ontwikkelaar ben nu harder aan het werk dan de code.
Overpeinzingen (over vakmanschap)
“Ziet u niet hoe vaklieden, hoewel zij tot op zekere hoogte bereid zijn om hun opdrachtgever tegemoet te komen, zich niet kunnen veroorloven af te wijken van de voorschriften van hun vak? Is het niet verbazingwekkend en teleurstellend tegelijk dat bij een architect en een geneesheer de grondbeginselen van hun vak meer gerespecteerd worden dan bij de rede bij de doorsneemens, terwijl het juist de rede is die hij met de goden gemeen heeft?”
De ontdekking van strategische subdomeinen
Ik schreef één keer eerder over Domain-Driven Design - en in die blog gaf ik onmiddellijk toe niks van het onderwerp te weten. Precies daarom nam ik me voor om Learning Domain-Driven Design van Vlad Khononov op te pakken. En met succes, want al meteen in het eerste hoofdstuk leerde ik iets nieuws: het bestaan van strategische subdomeinen.
Enums, switch statements en SOLID - deel 7
Een eeuwigheid geleden - april vorig jaar - schreef ik een reeks blogs over wat logica die rondom een Enum gebouwd was. Bijna een jaar na dato stel ik de vraag: wat probeerde ik nu eigenlijk te bereiken? - Eigenlijk was mijn use case betrekkelijk eenvoudig. Ik wilde wat logica kunnen koppelen aan een Enum-waarde, dat is alles. Sterker nog, die wens is niet alleen eenvoudig, hij is ook ontzettend generiek. Dat is een significante observatie. Gezien de generieke aard van het codeerprobleem, is er eigenlijk geen enkele reden waarom ik code zou moeten schrijven het probleem op te lossen.
Bewuste technische schuld
Is technische schuld erg? Niet per se, zolang de keuze voor technische schuld maar een bewuste is. Als het team duidelijk maakt dat de oplossingsrichting technische schuld met zich meebrengt en afdwingt dat er op middellange termijn tijd wordt vrijgemaakt om die op te ruimen, hoeft die schuld geen probleem op te leveren. Integendeel: dankzij die schuld zijn we in staat om op korte termijn - vóór de deadline - waarde te leveren.
Wie is verantwoordelijk voor jouw ontwikkeling?
Wie zijn vakinhoudelijke ontwikkeling afhankelijk maakt van zijn werkgever, zegt eigenlijk die ontwikkeling zelf niet zo belangrijk te vinden. Maar je persoonlijke ontwikkeling is wel belangrijk. Daarom is het essentieel dat je daar zelf de leiding in neemt. Als jij het niet belangrijk genoeg vindt om er tijd en geld in te steken, hoe kun je dan van je werkgever verwachten dat die dat wel doet?
Mijn loopbaanwending
Onlangs werd ik door Radboud Magazine geïnterviewd voor de rubriek Loopbaanwendingen, waarin alumni van de dezelfde opleiding aan de Radboud Universiteit vertellen over hun carrièrepad. Lees hier het resultaat.
Schrijf PBI's - en doe het goed
Het is niemands favoriete klus: Product Backlog Items (PBI’s) aanmaken om de komende Sprints op te kunnen pakken. En toch, het is een onderdeel van je werk als ontwikkelaar. En een belangrijk onderdeel ook, want zonder goed opgezette PBI’s kan een team helemaal niets.