Eerste 90 dagen: stapsgewijs stappenplan voor software-engineurs
Je hebt in de frontlinie gestaan.
Je hebt je cv opgepoetst tot het glom. Je hebt je vaardigheden en certificeringen uitgebreid.
Je hebt je GitHub bijgewerkt, systeemontwerpvragen bestudeerd tot ze in elkaar overvloeiden en vaker op ‘solliciteren’ geklikt dan je wilt toegeven.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Je hebt de interviewmarathon doorstaan — whiteboards, opdrachten voor thuis, ongemakkelijke stiltes en alles wat daarbij komt kijken. Je hebt je vaardigheden naar een hoger niveau getild en je hoofd koel gehouden.
En toen… kwam de aanbiedingsbrief. Je hebt de baan binnengehaald! Nu begint het echte werk.
Want hoewel personeel werven moeilijk is, is effectief inwerken nog moeilijker. Dit is het moment waarop je de overstap maakt van kandidaat naar medewerker en waarop eerste indrukken blijvende indrukken worden. De eerste 90 dagen leggen de basis voor alles wat daarna komt.
In dit draaiboek laat ik je zien hoe je als nieuwe software-engineer voortvarend van start gaat, met praktisch advies van twee ervaren professionals uit de technologiesector die dit zelf hebben meegemaakt, weten wat werkt en de weg kennen. Maar eerst bekijken we nuchter wat het vandaag de dag daadwerkelijk betekent om software-engineer te zijn.
Wat is een software-engineer?
Jeetje, waar beginnen we? Serieus, je zou een boek over dit onderwerp kunnen schrijven, deels omdat de term soms wordt gebruikt als verzamelnaam voor meerdere mogelijke functies die alle fasen van de levenscyclus van softwareontwikkeling omvatten. Daarom kunnen ook andere functietitels hier relevant zijn, zoals ontwikkelaar of programmeur. Wij gebruiken ‘software-engineer’ als overkoepelende term.
Hier is een beknopte definitie van software-engineering, afkomstig van de Michigan Technological University, om ons op koers te houden: “Software-engineering is het onderdeel van de computerwetenschappen dat zich bezighoudt met het ontwerp, de ontwikkeling, het testen en het onderhoud van softwaretoepassingen. Software-engineers passen technische principes en kennis van programmeertalen toe om softwareoplossingen te bouwen voor eindgebruikers.”
Als je dat terugbrengt tot de eenvoudigst mogelijke bewoordingen, klinkt het ongeveer zo: software-engineers bouwen digitale dingen die mensen en machines kunnen gebruiken. In plaats van een hamer en spijkers gebruiken ze code, samen met allerlei hulpmiddelen zoals Git en andere componenten.
We moeten ook een van de redenen noemen waarom veel mensen überhaupt als software-engineer willen werken: de baan kan goed betalen. De carrièresite Glassdoor schat het mediane totale salaris voor software-engineers op $147,000 per jaar (laatst gecontroleerd: 28 april 2025), hoewel de werkelijke bedragen variëren afhankelijk van factoren zoals ervaring, locatie en sector.
Laten we nu enkele concrete tips en ideeën bespreken om voortvarend van start te gaan.
De eerste 30 dagen
In ons begeleidende artikel over carrières in cybersecurity merkten we op dat de eerste 30 dagen uiteindelijk draaien om leren. Dat betekent alles, van codebases en hulpmiddelen tot nieuwe gezichten en nieuwe plekken. En dat geldt hier nog steeds, zij het met enkele aanpassingen.
Tip #1: Niet elke technologiestack is hetzelfde
Je weg vinden in je nieuwe functie moet net zo goed draaien om het leren kennen van mensen en processen als om het leren kennen van de codebasis of technologiestack.
“Uit mijn ervaring bij grote bedrijven is het belangrijker om de mensen [en] processen te begrijpen dan de architectuur van de code,” zegt Justin Garrison, hoofd productontwikkeling bij Sidero Labs. Voor zijn huidige functie werkte Justin als senior belangenbehartiger voor ontwikkelaars bij AWS en in meerdere technische functies bij Disney, waaronder die van senior software-engineer.
Tip #2: Begrijp hoe het bedrijf omzet genereert
Om jouw waarde te maximaliseren, moet je begrijpen hoe de organisatie haar waarde genereert.
“Naast het leren kennen van de technische stack en vereisten, moeten software-engineers uitzoeken hoe het bedrijf waarde creëert en betaald krijgt,” vertelt Chris Carter, senior productmanager bij NetApp Instaclustr, ons. Voordat hij zijn huidige functie op zich nam, begon Chris bij het bedrijf als senior ontwikkelingsingenieur en teamleider engineering. Hij vervolgt:
“Directe abonnementen? Een buitendienstteam en maatwerkdeals? Oogballen en advertenties? Zoek uit hoe het bedrijf zichzelf meet en hoe het van code naar KPI gaat.”
Bouw dat inzicht vroeg op. Software-engineers die de verbanden kunnen leggen tussen hun code en de financiële resultaten van hun bedrijf zullen waarschijnlijk nooit uit de mode raken.
“Door te begrijpen hoe het bedrijf zelf zijn succes meet, kun je jezelf positioneren om deel uit te maken van het creëren van dat succes en bij te dragen aan het bedrijfsresultaat,” zegt Chris.
Tip 3: Kloon de repository, maar haast je niet met de commit
Je staat natuurlijk te popelen om die eerste PR te maken. Maar behandel de codebase als een levend organisme: observeer de patronen, begrijp de anatomie en stel vragen voordat je ingrijpt. Gebruik de codenavigatiefuncties van je IDE, grep-opdrachten of de repositoryzoekfunctie om te volgen hoe gegevens en logica door het systeem stromen.
En als je vastloopt? Probeer het gedrag lokaal te reproduceren en volg het vervolgens stap voor stap. Debuggers worden onderschat, en praten tegen een rubberen eend werkt nog steeds.
Pro-tip: Bekijk recent gemergede PR's om inzicht te krijgen in de codestijl, de reviewcultuur en hoe “klaar” er in werkelijkheid uitziet.
De eerste 60 dagen
Een van de beste manieren om snel op gang te komen, is nieuwsgierig te zijn, niet alleen naar wat de code doet, maar ook naar waarom die het op die manier doet.
Tip 4: Vraag: “Waarom is dit op deze manier gebouwd?”
Verouderde code kan eruitzien als spaghetti, maar vaak zit er vlees in de saus. Beperkingen van een inmiddels uitgefaseerde dienst, een afweging op het gebied van prestaties, een zakelijke vereiste van een uitgefaseerde productfunctie—aan deze keuzes gaat een geschiedenis vooraf. Als je die geschiedenis leert kennen, voorkom je dat je iets voorstelt wat al eens is geprobeerd (en mislukt), en bouw je geloofwaardigheid op.
Begin met interne documentatie (zelfs als die verouderd is). Vraag daarna een teamgenoot om je iets verwarrends uit te leggen en behandel diegene als medeauteur van het verhaal van het systeem.
“Welke beslissingen zijn in deze code vastgelegd?” is een betere vraag dan “Waarom is deze code zo slecht?”
Tip 5: Identificeer de “ongeschreven regels” van je team
Elke technische organisatie heeft ze. Misschien geeft het team de voorkeur aan RFC's in Notion boven Jira-tickets, implementeert iedereen op donderdag, of zijn unittests optioneel—maar zijn e2e-tests heilig.
Deze normen staan niet altijd in een handboek, maar ze bepalen je succes net zo goed als je programmeervaardigheden. Let op patronen in Slack, bestudeer Git-commitberichten en vraag teamgenoten wat zij hadden willen weten toen ze bij het team kwamen.
Tip 6: Blijf mensen ontmoeten en van hen leren
Justin van Sidero Labs stelt dat ontmoetingen engineers helpen begrijpen hoe systemen buiten de code om samenwerken: “Aan het einde van die ontmoetingen was het veel gemakkelijker om te begrijpen waarom systemen eruitzien zoals ze eruitzien.”
Dat heeft allerlei gunstige neveneffecten, waaronder een lagere bloeddruk wanneer je code leest die in eerste instantie nergens op lijkt te slaan. Als een mens het heeft geschreven, had die persoon daar waarschijnlijk een reden voor, en die redenen kunnen organisatorische factoren, tijdsdruk enzovoort omvatten.
Dit soort holistisch inzicht helpt op het gebied van teamcultuur en communicatie, maar ook bij empathie en diplomatie wanneer het moment aanbreekt om verbeteringen te zoeken en voor te stellen.
De eerste 90 dagen
Je bent helemaal ingewerkt: “Na 90 dagen zou je je draai moeten hebben gevonden en hopelijk in staat moeten zijn om grotere taken op je te nemen,” zegt Chris van NetApp Instaclustr.
Deze laatste fase draait vooral om plannen en beginnen met uitvoeren. Waar kun je
beginnen om echt impact te maken?
Tip 7: Begin doelgericht te optimaliseren en impact te maken
Na 90 dagen ben je niet langer alleen de “nieuwe engineer”—je begint bij te dragen. Dat betekent dat het tijd is om mogelijkheden te zoeken om dingen te verbeteren. Maar er zit een addertje onder het gras: niet elke verbetering is de moeite waard om na te streven en niet elke bug is het waard om op te lossen.
“Het gaat er niet om een waslijst te maken van dingen die kapot zijn,” zegt Chris. “Het gaat erom het bedrijf, de klant en de context te begrijpen—en die kennis vervolgens te gebruiken om zinvolle manieren om te verbeteren te identificeren.”
Zo benaderen Chris en zijn team die mindset:
- Denk stroomopwaarts: Spring niet meteen naar oplossingen—begin met het schrijven van duidelijke tickets waarin je het probleem beschrijft.
- Stel verstandig prioriteiten: Leer hoe je team impact, inspanning en urgentie tegen elkaar afweegt. Een triviale gebruikersinterfacebug op een verouderd scherm? Waarschijnlijk geen spoedgeval.
- Een klantgerichte mindset: Vraag jezelf altijd af: “Is dit belangrijk voor een echte gebruiker?” Zo niet, archiveer het dan en ga verder.
Nadat je de systemen en cultuur hebt leren kennen, ga je op zoek naar taken met een grotere hefboomwerking—dingen die wrijving verminderen, de oplevering verbeteren of de klantervaring versterken.
“Door consequent werk te leveren dat bedrijfsdoelstellingen vooruithelpt, word je snel gezien als iemand die ‘het begrijpt’—en aan wie grotere verantwoordelijkheden kunnen worden toevertrouwd,” zegt Chris.
Tip #8: Lever iets op. Om het even wat. Maar neem er verantwoordelijkheid voor.
Na dag 90 hoef je geen kerndienst te hebben herschreven of in je eentje een nieuwe functie te hebben gelanceerd. Maar je zou wel naar één ding moeten kunnen wijzen, hoe klein ook, dat je van begin tot eind hebt opgeleverd en waarvoor je verantwoordelijkheid hebt genomen.
Dat kan bijvoorbeeld zijn:
- Een bugfix die problemen voor gebruikers verminderde
- Een aanpassing aan de CI/CD-pijplijn die builds versnelde
- Een grondige herziening van het README-bestand die de volgende nieuwe medewerker hielp
- Een optimalisatie van de back-end die 50 ms afhaalde van een veelgebruikte query
Het hoeft niet spectaculair te zijn—het moet nuttig zijn. Impact draait niet om uiterlijk vertoon; het draait om functionaliteit.
Het motto van de engineer: “Heb ik het leven van het team deze week 1% beter gemaakt?”
Tip #9: Stel een persoonlijke leerachterstand op
Je zult de volledige codebase, infrastructuur en bedrijfslogica niet in 90 dagen beheersen. Dat is prima. Wat telt, is wat je daarna doet.
Maak een persoonlijke “achterstand” van vaardigheden en kennishiaten. Noteer:
- Gebieden van het systeem die je nog steeds niet begrijpt
- Tools of frameworks waarin je je verder wilt verdiepen (bijv. Kubernetes, gRPC, Terraform)
- Technische schuld of eigenaardigheden die je opnieuw wilt bekijken
Geef vervolgens per sprint prioriteit aan één ding en vink het af. Je leert niet alleen het systeem kennen—je ontwerpt ook je routekaart voor groei.
Abonneer je op de nieuwsbrief van The CTO Club voor meer draaiboeken voor je eerste 90 dagen in elke technische functie!
