Een nieuwe functie in de techniek beginnen kan nerveus makend zijn, maar een van onze nieuwste medewerkers heeft wat advies over hoe je je kunt aanpassen aan je nieuwe omgeving.
Wanneer je begint bij een nieuw bedrijf, is het gebruikelijk dat een nieuwe werknemer een beetje cultuurshock ervaart. De verschillende kantoren, mensen, processen, enz. kunnen allemaal schokkend zijn. Ingenieurs zullen vaak worden blootgesteld aan een aanvullend type shock tijdens hun onboarding. Ik noem dit de codecultuurshock.
Codecultuurshock is specifiek voor het werken in een nieuwe codebase waarin dingen misschien helemaal anders zijn dan wat een ingenieur gewend is - dingen zoals mappenstructuren, gebruikte patronen, testopstellingen, gebruikte bibliotheken, CI/CD-processen, enz. Zelfs kleine verschillen zoals lintregels en formatteringsconfiguraties kunnen als een schok komen.
Voeg daar de verschillen in persoonlijke voorkeuren van teamleden aan toe en het kan allemaal best schokkend zijn. Er is echter een positieve kant aan deze schok. Het leidt tot een unieke situatie waar zowel nieuwe ingenieurs als bestaande teamleden volledig gebruik van moeten maken.
Maximale feedbackpotentieel
Nadat de eerste schok is weggeëbd, is er een klein venster van tijd waarin het potentieel voor eerlijke, onpartijdige feedback op zijn hoogst is - voordat het perspectief verschuift van een buitenstaander in de technologie naar een medeteamlid.
Dit ideale moment doet zich kort voor nadat een ingenieur gewend is geraakt aan de codebase, maar voordat ze hebben geaccepteerd wat ze zien als “zoals het nu eenmaal gaat.” Het is tijdens dit venster dat ze de kans hebben om dit potentieel te benutten en unieke inzichten aan te bieden aan zowel het team als de grotere organisatie.
Er zijn een paar belangrijke manieren om van dit gevoel als nieuwe ingenieur te profiteren:
💪️ Verwerp de bedrieger
Je hebt het interview doorstaan, het aanbod geaccepteerd en nu ben je klaar om de baan te doen, maar er is dit knagende gevoel dat je misschien toch te veel hooi op je vork hebt genomen. De codebase en processen zijn vreemd voor jou. Je was een expert bij je vorige baan en kende de systemen van binnen en van buiten, maar nu ben je verloren en vraag je jezelf af.
Ontspan, het komt goed! Je bent aangenomen voor je potentieel om te leren en bij te dragen. Niemand verwacht dat je een expert bent na slechts een paar weken. Imposter-syndroom is echt. Erken het, maar zet die gevoelens opzij en duik in je nieuwe rol.
☀️ Zet vooroordelen opzij
Breng je kennis, ervaring en frisse blik mee en laat eventuele vooroordelen achter. Je zult verschillen in de codebase opmerken van wat je gewend bent - het is tenslotte allemaal nieuw voor jou - maar wees voorzichtig met het gelijkstellen van "anders" met "fout".
"Hoe ik het zou hebben gedaan" is niet hetzelfde als "hoe het zou moeten worden gedaan." Dat is de schoonheid van code: er kunnen meerdere oplossingen voor een probleem zijn. Erken dat terwijl soms jouw manier beter zou zijn geweest, het vaak gewoon anders is.
🛠️ Breek dingen
Er is een reden dat we niet in productie ontwikkelen en er is geen betere manier om een nieuwe codebase te leren dan om je handen vuil te maken. Verander iets en kijk wat er gebeurt. Zie je ruimte voor verbetering? Ga ervoor.
De kans is groot dat je werkbelasting waarschijnlijk nog licht genoeg is zodat je de tijd hebt om te experimenteren met nieuwe ideeën. Maak je geen zorgen als wijzigingen niet goed uitpakken. Je zult nog steeds wegkomen met een dieper begrip van de code waarin je gaat leven.
📓 Documenteer alles
Catalogiseer alles wat vreemd of anders lijkt en schrijf de vragen op die zich voordoen. Het is niet ongebruikelijk om jezelf af te vragen waarom hebben ze het op deze manier gedaan? Veronderstel niet dat de code die je ziet perfect is zoals hij is. Je kent de geschiedenis van waarom dingen zijn zoals ze zijn nog niet.
Het kan zijn dat het stukje dat je bekijkt snel is uitgegeven en dat er hoeken zijn afgesneden, met de bedoeling dat het op een later tijdstip wordt herzien. Patronen en bibliotheken veranderen snel en code veroudert eerder dan je denkt. Het is prima, zo niet verwacht, dat je op deze dingen wijst. Vergeet niet, als de code perfect was, zou je niet zijn aangenomen om eraan te werken.
🤝 Delen is geven
Als je je op je gemak voelt, neem dan contact op met je team of manager en deel je feedback. Ze realiseren zich dat je in de unieke positie bent om frisse gedachten en ideeën te bieden en verwelkomen dit.
Iedereen werkt naar hetzelfde doel om het beste product voor onze klanten te maken. De manier waarop we dit doen, is door naar elkaar te luisteren en van elkaar te leren.
Wil je altijd het geweldige advies in deze post onthouden? Maak je geen zorgen, we hebben alles in een Guru-kaart gezet!
Wanneer je begint bij een nieuw bedrijf, is het gebruikelijk dat een nieuwe werknemer een beetje cultuurshock ervaart. De verschillende kantoren, mensen, processen, enz. kunnen allemaal schokkend zijn. Ingenieurs zullen vaak worden blootgesteld aan een aanvullend type shock tijdens hun onboarding. Ik noem dit de codecultuurshock.
Codecultuurshock is specifiek voor het werken in een nieuwe codebase waarin dingen misschien helemaal anders zijn dan wat een ingenieur gewend is - dingen zoals mappenstructuren, gebruikte patronen, testopstellingen, gebruikte bibliotheken, CI/CD-processen, enz. Zelfs kleine verschillen zoals lintregels en formatteringsconfiguraties kunnen als een schok komen.
Voeg daar de verschillen in persoonlijke voorkeuren van teamleden aan toe en het kan allemaal best schokkend zijn. Er is echter een positieve kant aan deze schok. Het leidt tot een unieke situatie waar zowel nieuwe ingenieurs als bestaande teamleden volledig gebruik van moeten maken.
Maximale feedbackpotentieel
Nadat de eerste schok is weggeëbd, is er een klein venster van tijd waarin het potentieel voor eerlijke, onpartijdige feedback op zijn hoogst is - voordat het perspectief verschuift van een buitenstaander in de technologie naar een medeteamlid.
Dit ideale moment doet zich kort voor nadat een ingenieur gewend is geraakt aan de codebase, maar voordat ze hebben geaccepteerd wat ze zien als “zoals het nu eenmaal gaat.” Het is tijdens dit venster dat ze de kans hebben om dit potentieel te benutten en unieke inzichten aan te bieden aan zowel het team als de grotere organisatie.
Er zijn een paar belangrijke manieren om van dit gevoel als nieuwe ingenieur te profiteren:
💪️ Verwerp de bedrieger
Je hebt het interview doorstaan, het aanbod geaccepteerd en nu ben je klaar om de baan te doen, maar er is dit knagende gevoel dat je misschien toch te veel hooi op je vork hebt genomen. De codebase en processen zijn vreemd voor jou. Je was een expert bij je vorige baan en kende de systemen van binnen en van buiten, maar nu ben je verloren en vraag je jezelf af.
Ontspan, het komt goed! Je bent aangenomen voor je potentieel om te leren en bij te dragen. Niemand verwacht dat je een expert bent na slechts een paar weken. Imposter-syndroom is echt. Erken het, maar zet die gevoelens opzij en duik in je nieuwe rol.
☀️ Zet vooroordelen opzij
Breng je kennis, ervaring en frisse blik mee en laat eventuele vooroordelen achter. Je zult verschillen in de codebase opmerken van wat je gewend bent - het is tenslotte allemaal nieuw voor jou - maar wees voorzichtig met het gelijkstellen van "anders" met "fout".
"Hoe ik het zou hebben gedaan" is niet hetzelfde als "hoe het zou moeten worden gedaan." Dat is de schoonheid van code: er kunnen meerdere oplossingen voor een probleem zijn. Erken dat terwijl soms jouw manier beter zou zijn geweest, het vaak gewoon anders is.
🛠️ Breek dingen
Er is een reden dat we niet in productie ontwikkelen en er is geen betere manier om een nieuwe codebase te leren dan om je handen vuil te maken. Verander iets en kijk wat er gebeurt. Zie je ruimte voor verbetering? Ga ervoor.
De kans is groot dat je werkbelasting waarschijnlijk nog licht genoeg is zodat je de tijd hebt om te experimenteren met nieuwe ideeën. Maak je geen zorgen als wijzigingen niet goed uitpakken. Je zult nog steeds wegkomen met een dieper begrip van de code waarin je gaat leven.
📓 Documenteer alles
Catalogiseer alles wat vreemd of anders lijkt en schrijf de vragen op die zich voordoen. Het is niet ongebruikelijk om jezelf af te vragen waarom hebben ze het op deze manier gedaan? Veronderstel niet dat de code die je ziet perfect is zoals hij is. Je kent de geschiedenis van waarom dingen zijn zoals ze zijn nog niet.
Het kan zijn dat het stukje dat je bekijkt snel is uitgegeven en dat er hoeken zijn afgesneden, met de bedoeling dat het op een later tijdstip wordt herzien. Patronen en bibliotheken veranderen snel en code veroudert eerder dan je denkt. Het is prima, zo niet verwacht, dat je op deze dingen wijst. Vergeet niet, als de code perfect was, zou je niet zijn aangenomen om eraan te werken.
🤝 Delen is geven
Als je je op je gemak voelt, neem dan contact op met je team of manager en deel je feedback. Ze realiseren zich dat je in de unieke positie bent om frisse gedachten en ideeën te bieden en verwelkomen dit.
Iedereen werkt naar hetzelfde doel om het beste product voor onze klanten te maken. De manier waarop we dit doen, is door naar elkaar te luisteren en van elkaar te leren.
Wil je altijd het geweldige advies in deze post onthouden? Maak je geen zorgen, we hebben alles in een Guru-kaart gezet!
Ervaar de kracht van het Guru-platform uit de eerste hand - maak onze interactieve producttour
