Je wilt ontwikkelaar worden, wat moet je kennen/kunnen?

Geschreven door Dirk Hornstra op zondag februari 21, 2021

Een oud-collega van mij die ook in 2001 afgestudeerd is wil na ongeveer 20 jaar in een ander vakgebied gewerkt te hebben "terug" komen als developer. Daar zit een flinke tijd tussen, wat is er allemaal veranderd? Of zoals je dit ook kunt lezen: als je nu aan de slag wilt gaan, wat moet je kennen/kunnen?

Kennis van source-control

Ik denk dat dit wel het eerste punt is wat je onder de knie moet hebben. Ik mag hopen dat het bedrijf waar je aan de slag wilt gaan hun broncode in een source-control systeem opslaat. In 9 van de 10 gevallen zal dit GIT zijn. De grootste partijen hiervoor zijn gitlab.com en github.com. Zorg dat je weet hoe je code "uit-checkt". Bekijk het systeem als een boom. Je kunt een "branche" maken. Dit is een kopie van de boom. In die branche kun je nieuwe features toevoegen. En als dat allemaal compleet is kun je die versie weer "mergen" naar de master-branche. Het klinkt allemaal simpel, maar als er meerdere personen aan projecten werken, zaken door elkaar heen lopen kun je in complexe situaties belanden. Als je dan weet hoe je zaken goed op kunt lossen, kunt cherry-picken en andere acties door kunt voeren, dan heb je een streepje voor. Check ook podcast 350 van Scott Hanselman waarin wordt verwezen naar meerder locaties waar je informatie kunt vinden: link.

Weten waar je oplossingen kunt vinden

Als je een foutmelding krijgt, kun je op Google zoeken en vaak krijg je dan een hit op een pagina van Stackoverflow: link. In veel gevallen staat daar het probleem en krijg je een aantal oplossingen aangeboden. Dus voordat je zelf 8 uren lang gaat zoeken, kan zo'n zoekactie vaak veel tijd schelen. Google is dus niet alleen voor consumenten maar ook zeker voor developers een life-saver.

Zelf kritisch blijven

De echte developer onderscheidt zich van de huis-tuin-en-keuken ontwikkelaar door kritisch te blijven. Want hoewel een oplossing die je op Stackoverflow gevonden hebt er goed uit kan zien, zorg wel dat je begrijpt wat er gebeurt. En begrijp ook wat het voor mogelijke impact op jouw applicatie kan hebben. Introduceert het een mogelijk beveiligingslek? En hoe zit het met de grensgevallen? Kun je een situatie krijgen waarin er bijvoorbeeld door 0 gedeeld kan worden en je dus een exceptie krijgt? Beschouw wat je krijgt dus altijd als een potentiële fix, maar ook als een mogelijk risico wat zoveel mogelijk ingeperkt moet worden.

Zelf problemen oplossen

Niet alles staat op Stackoverflow, dus je zult ook zelf aan de bak moeten. Als je developer bent en je moet óf wat fixen óf wat nieuws bouwen, vaak loop je tegen problemen aan. Niet altijd is direct aan te wijzen wat de bron van dat probleem is. Je gaat op zoek gaat naar mogelijke oorzaken, maar misschien zijn die er niet (of je kunt ze in ieder geval niet vinden). Zeg dan niet: dat was het, meer kan ik niet vinden. Want wat je vervolgens (of misschien meteen al moet doen) is het uitsluiten van zaken. Dit is het niet geweest, dit kan het niet zijn. En vervolgens ga je zorgen dat door logging e.d. gezorgd wordt dat als het probleem nogmaals voorkomt er wel meer informatie beschikbaar is en er wel een mogelijke oorzaak gevonden kan worden.