Ik werk ondertussen al heel wat jaren als developer. Eerst vooral zelf achter het toetsenbord, later ook als team lead en project manager.
Als ik terugkijk naar mijn eerste jaren als developer, zijn het niet de technische dingen die ik anders zou aanpakken. Ik zou niet vroeger een bepaald framework geleerd hebben of meer design patterns uit het hoofd gestudeerd hebben.
Het zijn vooral een aantal principes rond hoe je werkt die ik graag vroeger had begrepen.
Dit is het advies dat ik vandaag aan jonge developers zou geven.
Neem verantwoordelijkheid
Het boek the Clean Coder van Robert C. Martin heeft me dit geleerd, zeker een aanrader!
Een van de grootste verschillen tussen school en professioneel werken is verantwoordelijkheid.
Als je zegt dat je iets gaat doen, rekenen andere mensen daarop. Een collega plant zijn werk misschien verder op basis van jouw taak. Een projectmanager communiceert naar een klant. Een klant verwacht dat iets beschikbaar zal zijn.
Dat betekent niet dat je overal "ja" op moet zeggen.
Je mag zeggen dat iets niet haalbaar is. Je mag aangeven dat je meer tijd nodig hebt. Je mag zeggen dat je iets nog niet begrijpt of dat je hulp nodig hebt.
Maar als je "ja" zegt, neem daar dan ook verantwoordelijkheid voor.
En merk je onderweg dat het toch niet lukt? Communiceer dat zo snel mogelijk. Niet op het moment dat het eigenlijk al klaar had moeten zijn.
Betrouwbaarheid is minstens even belangrijk als technische kennis.
Quality over Quantity
Als junior developer wil je vaak bewijzen dat je snel bent. Ticket gekregen. Code schrijven. Klaar. Volgende. Dat voelt productief. Vijf tickets afwerken lijkt beter dan drie tickets afwerken. Maar dat is alleen zo als die vijf tickets ook echt volledig afgewerkt zijn.
Als iemand achteraf bugs moet oplossen, code moet herschrijven of ontbrekende stukken moet toevoegen, ben je niet sneller geweest. Je hebt het werk gewoon doorgeschoven naar iemand anders.
Daarom Quality over Quantity.
Ik heb veel liever dat een developer iets langer over een taak doet en degelijk werk aflevert, dan dat een taak snel naar "done" verhuist en daarna drie keer terugkomt.
Snelheid is uiteraard niet onbelangrijk. We werken binnen budgetten en deadlines. Maar snelheid komt met ervaring.
Eerst correct. Dan consistent. Dan snel.
Werk je werk af
Dit sluit daar rechtstreeks bij aan.
Op school kon je een opdracht indienen die voor 70% werkte en daar misschien nog een voldoende cijfer voor krijgen. In productie werkt dat anders. Een formulier dat meestal werkt, is niet af. Een feature die werkt zolang de gebruiker exact doet wat jij verwacht, is niet af. Een pagina die functioneel klaar is maar waarvan foutmeldingen ontbreken, is niet af. Als developer moet je leren denken voorbij "de happy flow werkt".
Wat gebeurt er als er geen data is? Wat als iemand verkeerde input geeft? Wat als een externe API niet antwoordt? Wat als de gebruiker geen toegang heeft? Wat als er duizenden records zijn in plaats van tien?
Een feature bouwen is vaak relatief eenvoudig. Een feature écht afwerken is het moeilijke deel.
Test je eigen werk
Dus! Stuur code niet door zodra ze één keer gewerkt heeft op jouw machine. Probeer ze kapot te krijgen. Gebruik verkeerde input. Test grensgevallen. Herlaad op vreemde momenten. Test verschillende gebruikersrollen. Kijk wat er gebeurt als data ontbreekt.
En waar het zinvol is: automatiseer die tests.
Automatische tests kosten tijd om te schrijven (en vooral te onderhouden maar met AI mag dit eigenlijk geen excuus meer zijn), maar ze maken toekomstige wijzigingen veel veiliger. Zeker wanneer een applicatie groter wordt en meerdere developers eraan werken.
Tests zijn bovendien niet alleen bedoeld om bugs te vinden. Ze dwingen je na te denken over hoe je code zich hoort te gedragen.
Een bug die jij tijdens development vindt, kost meestal weinig tijd. Een bug die een klant vindt, brengt communicatie, onderzoek, context switching, debugging, testen en opnieuw deployen met zich mee.
Je maakt dus vooral je eigen leven makkelijker door goed te testen.
Pragmatism over Over Engineering
Als developer is het verleidelijk om technisch interessante oplossingen te bouwen.
Een extra abstractielaag. Een generiek systeem dat misschien ooit vijf andere use cases kan ondersteunen. Een design pattern omdat het mooi past. Een nieuwe package omdat die het probleem elegant oplost.
Maar code is niet het eindproduct. De applicatie is het eindproduct.
De klant betaalt uiteindelijk niet voor een indrukwekkende architectuur. Die betaalt voor software die een probleem oplost en betrouwbaar werkt.
Daarom: Pragmatism over Over Engineering.
Dat betekent niet dat architectuur onbelangrijk is. Een applicatie moet onderhoudbaar, robuust en voldoende schaalbaar zijn. Snel iets in elkaar steken waar je zes maanden later spijt van hebt, is ook niet pragmatisch. De kunst zit net in het evenwicht. Bouw een goede oplossing voor het probleem dat je vandaag kent, met voldoende ruimte om morgen verder te kunnen. Niet voor alle problemen die misschien ooit zouden kunnen bestaan.
Consistency is key
Als junior developer kijk je vaak naar een feature als een geïsoleerde opdracht. Je krijgt een ticket en probeert daarvoor de beste oplossing te bouwen. Maar je werkt bijna nooit in isolatie. Er bestaat al een applicatie. Er zijn andere schermen. Andere modules. Andere developers. Er zijn bestaande componenten, patterns en afspraken. Kijk daar eerst naar.
Hoe lossen we dit probleem elders op? Bestaat er al een component voor? Hoe zien vergelijkbare schermen eruit? Hoe worden errors afgehandeld? Hoe noemen we dit soort classes? Hoe werken vergelijkbare features in onze andere applicaties?
Consistency is key.
Jouw oplossing kan technisch gezien beter zijn, maar toch de verkeerde oplossing zijn wanneer ze compleet anders werkt dan de rest van de applicatie. Een gebruiker zou niet telkens opnieuw moeten ontdekken hoe een scherm werkt. En een developer zou niet voor iedere module opnieuw moeten ontdekken hoe de code in elkaar zit.
Soms is consistent zijn met een bestaande, niet-perfecte oplossing beter dan op één plaats de perfecte oplossing bouwen.
Het einddoel is zelfstandigheid
Als junior developer krijg je taken. Dat is normaal. Je moet de applicatie, codebase, klanten en manier van werken nog leren kennen. Maar het einddoel mag niet zijn dat je steeds beter wordt in het uitvoeren van tickets.
Het einddoel is independence & pro-activeness.
Je moet uiteindelijk verder leren kijken dan de taak die voor je ligt. Als je gevraagd wordt om een veld toe te voegen, kijk dan niet alleen waar je dat veld in de database moet zetten. Denk ook na over validatie, permissions, bestaande data, exports, filters en andere plaatsen waar die informatie gebruikt wordt.
Zie je iets dat niet klopt? Kaart het aan. Merk je dat een requirement ontbreekt? Vraag ernaar. Denk je dat een andere oplossing eenvoudiger is? Stel ze voor. Zie je dat een volgende stap nodig zal zijn? Wacht niet noodzakelijk tot iemand daar een apart ticket voor schrijft. Hoe meer ervaring je krijgt, hoe minder iemand anders je werk volledig zou moeten voorkauwen.
Dat betekent niet dat je zomaar zelf beslist wat er gebouwd moet worden. Het betekent dat je verantwoordelijkheid neemt voor het grotere geheel.
Je job is niet code schrijven
Dat brengt me misschien bij de belangrijkste les. Als developer word je betaald om problemen op te lossen. Code is daar één van de middelen voor.
Soms is de beste oplossing twintig regels code. Soms is het een bestaande functie hergebruiken. Soms moet je eerst vijf vragen stellen omdat de oorspronkelijke vraag eigenlijk het verkeerde probleem probeert op te lossen.
Een sterke developer vraagt daarom niet alleen: "Hoe kan ik dit bouwen?"
Maar ook: "Waarom bouwen we dit?", "Voor wie?", "Wat proberen we hiermee op te lossen?", "Bestaat er al iets dat dit doet?", "Kan het eenvoudiger?"
Technische kennis maakt je een betere programmeur. Begrijpen welk probleem je aan het oplossen bent, maakt je een betere developer.
Tot slot
Junior zijn betekent niet dat er minder van je verwacht mag worden. Het betekent vooral dat niemand verwacht dat je alles al weet. Je mag vragen stellen. Je mag fouten maken. Je mag iets verkeerd inschatten. Je mag hulp nodig hebben. Maar probeer vanaf het begin de juiste gewoontes op te bouwen.
Quality over Quantity.
Pragmatism over Over Engineering.
Consistency is key.
En werk stap voor stap naar independence & pro-activeness.
Frameworks veranderen. Programmeertalen veranderen. De manier waarop we software schrijven verandert. Zeker nu AI steeds meer van het pure schrijfwerk kan overnemen.
Maar verantwoordelijkheid nemen, problemen begrijpen en degelijk werk afleveren blijven waardevolle vaardigheden. Misschien zelfs meer dan ooit.
