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?
Waarheid boven schoonheid
Anders dan Aristoteles, Kant en Wittgenstein, hebben we als softwareontwikkelaars de luxe ons niet bezig te hoeven houden met de metafysische grondstructuur van de werkelijkheid. Dat vereenvoudigt het ontwikkelen van onze applicaties aanzienlijk. Maar dezelfde hang naar schoonheid die ik bij filosofen zo amusant vind, duikt bij tijden ongemerkt in mijn eigen werk op.
Meer dan een zwarte doos
De basis van een programmeren kost je misschien een weekendje, maar een goed programma leren schrijven, dat is een proces van jaren. Waarom? Het besef dat een goed programma meer is dan een werkend programma, daalt pas na veel vallen en opstaan in. Studenten en beginnend programmeurs die meer uit hun strubbelingen willen halen, doen er daarom goed aan Perdita Stevens' How to Write Good Programs aandachtig te lezen.
Droger tests met factory methods
Ga eens voor jezelf na: hoe instantieer je objecten in je unit tests? Introduceer je veel codeduplicatie over tests heen? Wat zegt dit over je houding tegenover testcode? Is die houding hetzelfde als die tegenover productiecode?
Stapje voor stapje data migreren
Als er één constante is in softwareontwikkelland, dan is het wel dat software constant verandert. Nieuwe inzichten noodzaken ontwikkelaars om hun code aan te passen om bepaalde use cases (beter) te kunnen ondersteunen. Soms betekent dat dat er een aanpassing moet plaatsvinden in je model. Hoe ga daarbij om met data die nog is opgeslagen volgens het verouderd model?
Hoe technische schuld te monitoren én prioriteren
Software ontwikkelen is mensenwerk. Hoe goed de tooling tegenwoordig ook is, ze is niet meer dan een hulpmiddel voor ontwikkelaars om grip te krijgen op een codebase. De beste manier om technische schuld in beeld te krijgen, is dan ook niet door allerhande tools op je code los te laten, maar door erover te praten met je collega’s.
Wat er gebeurt wanneer je op 'save' klikt
De theorie achter relationele databases en een goede beheersing van SQL is essentieel voor softwareontwikkelaars vandaag de dag. Studenten en professionals die hun kennis willen opfrissen, kunnen voor een toegankelijke inleiding in dit onderwerp terecht bij Relationele databases en SQL van Leo Wiegerink, Jeanot Bijpost en Marco de Groot. Dit relatief lijvige boekwerk (520 pagina’s) maakt de lezer in een aangenaam tempo bekend met de basis van de onderwerpen in de titel.
Moet je dit willen testen?
“Code is a liability, not an asset.” Van alle zinnen in Vladimir Khorikovs Unit Testing: Principles, Practices, and Patterns is deze me het meest bijgebleven. Ironisch, want op het eerste gezicht is het geen zin die iets te doen heeft met unit testing. Maar ook testcode kan een een blok aan het been zijn. Bijvoorbeeld wanneer je de code eigenlijk niet zou moeten willen unittesten.
Laatste overwegingen bij het uitzoeken van een thema
Mijn eerste pull requests zijn goedgekeurd! Een historische gebeurtenis! Van volslagen insignificant niveau, weliswaar, maar toch. Dit lijkt me een mooie gelegenheid om mijn overwegingen bij het uitzoeken van een thema af te ronden. Of toch in elk geval: voorlopig af te ronden.
Check op permissies, niet op rollen
Op een gegeven moment begon onze autorisatiecode uit de hand te lopen. De code in onze front-end was haast onleesbaar geworden van alle rollenchecks die de logica vervuilde. Erop terugkijkend, hadden we twee fouten gemaakt in onze oorspronkelijke implementatie. Ten eerste hadden we gebruikers de mogelijkheid gegeven meerdere rollen te hebben, en ten tweede bevonden onze checks zich op een te grof niveau.