Voor de derde keer ontslagen uit een softwareontwikkelingsopdracht. Wat moet ik doen?

Ik heb veel tijd besteed aan het opnieuw opbouwen en proberen de technische schuld weg te werken. Ik kreeg een mondelinge waarschuwing voor onderpresteren voordat ik op vakantie ging.

Het lijkt erop dat je hier aan iets werkte waar niet om gevraagd werd. Dit is over het algemeen erg slecht, en kan leiden tot beëindiging. Als u denkt dat het project opnieuw moet worden opgebouwd, en ik vertrouw erop dat u dat heeft gedaan, dan moet u het aan het management verkopen voordat u het kunt doen. Als u dat had gedaan, denk ik dat het management anders zou hebben gehandeld.

U hebt misschien tegen uzelf gezegd dat u uw taak niet kunt voltooien zonder de code om schoon te zijn. De waarheid is dat de code van de meeste bedrijven dat niet is. Ze werken met legacy, ze proberen verder te gaan met wat ze hebben…

Ik werd geplaatst om te werken met een technologie die niets te maken heeft met wat ik heb getekend voor

…en bijna allemaal zullen ze de legacy verbergen achter meer aantrekkelijke nieuwe technologieën bij het interviewen.

Ik denk niet dat dit op zich een signaal is dat je van carrière moet veranderen. Ik zou denken dat je geen afkeer hebt van software engineering als het goed gedaan wordt. Maar engineering in een bedrijf is altijd een kwestie van het omgaan met software die verkeerd is gedaan, met het management vooruit te helpen. Als je het in een bedrijf wilt volhouden, moet je bereid zijn dit te accepteren.

• *

Update : Aangezien je je vraag hebt bewerkt met meer relevante details over hoe en waarom je bent ontslagen, moet ik een bijgewerkt antwoord geven.

In zowel geval 2 als 3 hadden je werkgevers hoge verwachtingen van je vermogen om je aan te passen aan nieuwe dingen op basis van je ervaring. Overal waar ik werkte zou dit veel te weinig zijn om iemand te motiveren om te ontslaan, maar ik ben bereid om toe te geven dat in sommige bedrijfsculturen menselijk kapitaal niet veel wordt gewaardeerd. Dit is een schande en een strategische fout; maar dit is een ander verhaal.

Ik veronderstel dat je andere antwoorden moet lezen aangezien ze je nu meerdere creatieve uitwegen bieden. Hier is wat ik als waardevol advies beschouw :

1. Introspect
2. 2. Herstel van het vertrouwen
3. Als u ervoor kiest om weer als ontwikkelaar te werken, kies dan verstandig uw management. Verwacht je salaris als je er absoluut zeker van bent.

Ik geef persoonlijk de voorkeur aan kleine bedrijven, hun management heeft de neiging om meer menselijk te zijn.

Vandaag ben ik ontslagen bij een softwarebedrijf… voor de 3e keer in 1,5 jaar. Onnodig te zeggen dat ik het gevoel heb dat ik de bodem heb bereikt en dat het onmogelijk is om eruit te komen zonder van carrière te veranderen. Moet ik van carrière veranderen? Is het zelfs mogelijk om nu een baan te vinden?

Yup, dat is vrij slecht. Maar vergeet niet dat je er niet zeker van was dat iemand je zou aannemen nadat je ontslagen was - toch eindigde je met deze derde baan.

Ik denk dat je naar binnen moet kijken en zelf moet bepalen waarom dit gebeurt.

Geef niet de schuld aan “slecht management” hier. Er is iets aan de hand in elk geval dat resulteerde in slechte prestaties van jouw kant. In andere vragen zei u dat u ontslagen bent omdat u niet genoeg vragen stelde en omdat u geen werk op hoog niveau verrichtte. Hopelijk zijn er dingen die je van dat alles kunt leren.

Het kan zijn dat je slecht kiest voor banen en/of managers. Het kan zijn dat je niet hebt geleerd hoe je hard moet werken, je moet focussen op wat belangrijk is en goed moet presteren ondanks problemen op het werk. Het kan zijn dat je voor een te hoge functie schiet en dat je meer geschikt bent voor junior werk. Of het kan gewoon zijn dat je helemaal niet geschikt bent voor dit soort werk.

Besteed wat tijd aan introspectie. Probeer tot een conclusie te komen voordat je gaat acteren. Je kunt het je waarschijnlijk niet veroorloven om dezelfde fout opnieuw te maken.

Je zou kunnen overwegen om een steekje te wagen in het uitzendwerk. Dat is misschien makkelijker om in je situatie te komen. Misschien kun je jezelf motiveren om goed te presteren als de projecten klein en tijdgebonden zijn. Je ervaring uit het verleden lijkt te suggereren dat je dat zou kunnen.

Ik ben in mijn 30er jaren zonder uitwijkplaats, geen familie in de buurt en niet veel vrienden.

Dat is iets waar je onafhankelijk van je werk aan zult willen werken. We hebben allemaal vrienden nodig. En een goede supportgroep zou helpen als je werk problemen hebt.

Blijf proberen om vriendelijk te zijn en meer vrienden te maken. Word lid van een club. Ga om met mensen van het werk. Probeer het tenminste.

Begrijp waarom je ontslagen wordt

Je hebt het zelf gezegd. Je concentreert je op het herschrijven, terwijl dat niet de bedoeling is. Je hebt een reëel slecht geval van Not Invented Here syndroom. Wat het management betreft, lijkt het probleem te gaan over de vraag of u bereid bent om te doen wat uw manager u zegt en uw werk gedaan te krijgen, of dat u gaat spelen met dingen die u denkt te willen doen. En als je voor een nieuwe uitdaging staat, lijkt het alsof je wegloopt.

Als je hier overheen komt, dan ben je inzetbaar. Tot die tijd breng je eerlijk gezegd alleen maar schade toe aan je werkgevers en aan je eigen reputatie. Je werkgevers kunnen dit meestal wel overleven, maar dat doe je niet.

Laten we eens kijken naar je cv…

Case 1: ontslagen bij een fintech bedrijf op de 2e maand voor het niet presteren… gebrek aan motivatie.

Als je wist dat dit niet iets was waar je je op kon focussen, waarom heb je dan de baan aangenomen? En als je het niet wist, waarom nam je dan geen ontslag met waardigheid in plaats van ieders tijd te verspillen? Dit is degene die mij echt aangaat.

Case 2: ontslagen bij een webplatform bedrijf voor het niet uitvoeren van… technologie die niets te maken heeft met waar ik voor getekend heb…

De aard van een technische baan is dat er altijd dingen zullen zijn waar je nog niet eerder aan gewerkt hebt. Als je die technologie niet eerder lijkt te hebben gebruikt, geef dan toe, en zorg ervoor dat de schattingen worden aangepast.

Maar “niet presteren” betekent meestal niet dat je de deadlines hebt gemist, het betekent meestal dat je bent betrapt op verslapping in plaats van dat je werkt. In een technische baan zou ik verwachten dat iemand enthousiast is over het aanleren van nieuwe vaardigheden, of er op zijn minst ijverig over is. Als je gaat weglopen voor iets wat je nog niet weet, zoek dan een nieuwe carrière.

Case 3: … bracht veel tijd door met het opnieuw opbouwen en proberen te verwijderen van technische schulden… De neiging hebben om rommelige code op te ruimen, te refactoren en ervoor te zorgen dat dingen goed getest worden…

En dit is waar we je zien spelen met dingen die je niet hoeft te doen. Je noemt het “rommelige code”. De rest van het bedrijf noemt het “werkende code”. Ik kom uit een veiligheidsgerelateerde technische achtergrond. In dit soort werk, kunnen mensen gedisciplineerd zijn voor het repareren van bugs. Serieus. Het probleem met het “repareren” van een bug is dat je moet bewijzen dat er niets anders kapot is gegaan. In de context van het hertesten van een volledige automotor en -transmissie, is een kleine bug die misschien een 1% fout veroorzaakt bij het tanken voor één verwerkingsteken na een uur draaien waarschijnlijk volledig aanvaardbaar, maar de kosten in geld en tijd van een volledige hertest van het hele systeem is dat waarschijnlijk niet. Dat is voordat we zelfs maar “rommelige” code gaan repareren, waarbij je vermeende niet-functionele veranderingen bijwerkingen kunnen hebben als gevolg van een gemiste komma of iets even doms.

Kortom, je wordt ingehuurd om een professionele klus te klaren. Tot nu toe heb je aangetoond dat je niet in staat bent om professioneel te zijn. Als je in een interview kunt gaan en die mislukkingen kunt presenteren als leerervaringen die je hebben geholpen je mentaliteit om te buigen, dan ben je klaar om te gaan. Kun je dat…?

Ik heb de neiging om rommelige code op te ruimen, te refactoren en ervoor te zorgen dat de dingen goed getest worden - iets wat door velen gezien kan worden als traag presterend.

Ik ga er op uit met een ledemaat en neem aan dat dit meer is dan de gebruikelijke padvinderij. Dus:

Ik heb de neiging om kiesbaar te maken voor rommelige code, refactor en ervoor te zorgen dat de dingen goed getest worden, wanneer ze “aanpalend” zijn aan iets wat ik schrijf, en om dit te prioriteren boven de verzending, ongeacht wat mij is opgedragen.

Tests en refactoring zijn geweldig, maar het is nooit 100% één persoon’s roeping op hoeveel nadruk ze krijgen. De code is een middel om een doel te bereiken – het is er niet alleen voor uw plezier, het is er om zakelijke behoeften te dienen, en de mensen die dichter bij die behoeften werken (het management) zijn in een betere positie om prioriteiten te stellen. Plus alles wat je verandert is iets dat je potentieel zou kunnen breken, testen of geen testen – om nog maar te zwijgen van de extra beoordelingslast.

Met betrekking tot een carrièreverandering, denk ik dat er twee dingen zijn om te overwegen. Het eerste is dat als je consequent ongehoorzaam bent, het niet uitmaakt in welke carrière je zit. Lijnkoks die recepten “verbeteren” worden ook ontslagen. Met andere woorden, je wordt mogelijk ontslagen omdat je je niet concentreert. Uw impulsiviteit kan u gemakkelijk volgen in een nieuwe carrière, dus het schakelen zal alleen lonen als u zich eerst richt op uw focus. Het tweede is wat je zei over het gebrek aan motivatie. Wat een gebrek aan focus zou kunnen veroorzaken is als je misschien don’t like codering buiten het opruimen van bestaande dingen, wat volkomen begrijpelijk is. Maar als het waar is, dan betekent het dat een vierde taak van de ontwikkelaar gewoon zou zijn om zich in te schrijven voor meer marteling (in de veronderstelling dat het werkt in een team & op een bestaande codebasis).

Maar ik zou doen wat je zegt dat je gaat doen je topprioriteit maken, en van daaruit verder gaan. Goed gedaan, dit betekent ook dat je geen verplichtingen op je neemt waarvan je denkt dat je ze niet kunt nakomen. Wie weet, misschien ontdek je wel dat je liever brood bakt. (Het is maar een voorbeeld, maar ik denk dat het een goede is - het is een ambacht, het gaat om het oplossen van problemen, het beloont perfectionisme, en je doet het over het algemeen zelf van begin tot eind.)

Hoe dan ook, het belangrijkste is dat als je gevraagd wordt om een klus te klaren, en je accepteert het, dan doe je het. Later, als blijkt dat het niet voor jou is, dan buig je sierlijk en probeer je iets anders. Maar dat “iets anders” doen op iemand anders zijn geld, terwijl ze denken dat je doet wat ze van je vragen, is gewoon mensen boos maken, in elke lijn van het werk.

**Je hebt me niet nodig om je te vertellen dat dit niet goed is, dus ik ga het punt niet belabberen, maar het is de moeite waard om even te kijken naar de drie ontslagen:

Case 1: ontslagen door een fintech bedrijf op de 2e maand voor het niet presteren. Dit was correct omdat ik een gebrek aan motivatie had.

Niets te zeggen hier - je weet dat je het verknald hebt. Iets zegt me dat een gebrek aan motivatie nu geen probleem voor je zal zijn!

Case 2: Ontslagen door een webplatform bedrijf voor het niet presteren. Ik werd geplaatst om te werken met een technologie die niets te maken heeft met waar ik voor getekend heb, dus dit lijkt me een slecht beheer van mijn kant.

Hoewel het niet ideaal is voor het management om nieuwe werknemers in dienst te nemen, zijn ze ongebruikt. Ik zou op mijn hoede zijn om dit allemaal de schuld te geven - er zijn er twee nodig om te tango zoals het gezegde luidt en ik zou verbaasd zijn als je niet meer had kunnen doen om dit te voorkomen als een schietpartij, maar laten we het 80-20 hun schuld noemen.

Case 3: Ontslagen op de 6e maand voor slechte prestaties. Tijdens de proeftijd kreeg ik positieve feedback. Daarna ben ik van project veranderd en heb ik veel tijd besteed aan het refactureren en proberen de technische schuld weg te werken. Ik kreeg een mondelinge waarschuwing voor onderpresteren voordat ik op vakantie ging. In de 4 dagen die ik had heb ik geprobeerd om dat te verhelpen door overuren te maken en al het werk af te maken. Toen ik echter terugkwam van vakantie ontving ik een opzeggingsbrief.

Sorry, maar deze is helemaal van jou - refactoring as you go is niet slecht op zich, en het kan een zeer efficiënte manier zijn om een code basis op te schonen zonder de ontwikkeling volledig te stoppen voor een aantal maanden. Maar het is geen goed idee om het te doen als je geen regie of tenminste goedkeuring hebt om dit te doen (inclusief de extra tijd die het kost). Vanuit het perspectief van de werkgever lijkt het er erg op dat je hebt gewerkt om door de proeftijd heen te komen en dat je daarna bent gestopt (ik realiseer me dat dat niet is wat je hebt gedaan - maar dat is wat het ziet zo).

Over het algemeen is het probleem zoals ik het zie, dat ik de neiging heb om rommelige code op te schonen, te refactoren en ervoor te zorgen dat dingen goed getest worden - iets wat door velen gezien kan worden als traag presterend.

Je hebt de waarschijnlijke oorzaak van de “slechte prestatie” zienswijzen geïdentificeerd, maar lijkt er niet helemaal in te zijn geslaagd om te beseffen dat dit eigenlijk is slechte prestatie is. Het consequent nalaten om schattingen te maken (aangenomen dat die schattingen realistisch zijn) wordt niet alleen “gezien” als traag presterend, maar is dat wel, in elke definitie van de term traag presterend! Als een gebruikersverhaal/ticket/waar dan ook een schatting heeft van 6 uur om te voltooien en het kost je 12 uur omdat je een extra 6 uur hebt besteed aan het doen van activiteit X dan maakt het niet echt uit wat activiteit X is, of je nu refactoring of het bekijken van kattenvideo’s op je buis het kostte je nog steeds 6 uur langer om je toegewezen taak te doen dan werd verwacht.

Het goede nieuws is dat je in principe de vaardigheden en het talent hebt die je nodig hebt om te slagen in het coderen - je hoeft alleen maar een paar dingen te ondersteunen in je aanpak. Ziet u iets dat baat zou hebben bij een refactor als u aan een taak werkt? Geweldig! Die vaardigheid kan worden ingezet voor uw voordeel in plaats van een doorn in het oog - u hoeft alleen maar te praten met uw manager/teamleider of degene die de planning en de toewijzing van middelen beheert en te zeggen wat u hebt gevonden, welke voordelen u denkt dat het kan opleveren voor het bedrijf en hoe lang u denkt dat het u zal kosten om het te doen.

Als ze het erover eens zijn dat het de tijdsinvestering waard is die ze voor de extra tijd kunnen verantwoorden, ga je niet over de schreef, en zie je eruit als een rockster voor het proactief helpen van het bedrijf.

I liefhebben met codeurs die aan mij rapporteren die dat doen!

Echter…

Je moet accepteren dat ze soms “Nee” of “Niet nu” gaan zeggen tegen deze verzoeken - dat komt omdat ze de termijnen voor het voltooien van de oorspronkelijke taak nu waardevoller vinden, en zoals ik al zei, je moet dat antwoord accepteren omdat er niets mis is met hen die dat telefoontje plegen, want daar krijgen ze voor betaald.

Tenzij je er 110% zeker van bent dat het niet onmiddellijk uitvoeren van je voorgestelde refactoring ernstige gevolgen zal hebben voor het bedrijf, dan duw je niet terug, je maakt geen ruzie. Je doet waarvoor je betaald wordt, als het bedrijf later opgeblazen wordt, dan is het eerlijk gezegd de verantwoordelijkheid van de persoon die besloten heeft het niet te doen - ook dit is waar ze voor betaald worden!

** Dus waar ga je vanaf hier naartoe? **

Ik denk niet dat je nu van carrière hoeft te veranderen - zoals ik al zei, het klinkt alsof je de vaardigheden hebt en terwijl je recente werkverleden, om bot te zijn, behoorlijk vervloekt is, is het niet onherstelbaar en met wat hard werken en een beetje geluk kun je het schip weer in orde krijgen en weer op koers komen alsof het nooit is gebeurd.

Dit is wat ik zou doen als ik jou was:

• Ga contracteren (dit zou mijn aanbeveling zijn) - werkgeschiedenis doet er minder toe dan het hebben van de vaardigheden in het contract woord, en mensen zijn meer geneigd om een punt te zetten opiemand voor een contract dan zijn ze voor een perm positie omdat het makkelijker is om ze te laten vallen en iemand anders te krijgen als ze een slechte beslissing nemen om in te huren. Je hebt een fantastische besparingsbuffer die je de tijd geeft om het te proberen - stel jezelf een deadline: als je een contract niet kunt vinden (en succesvol bent) in 3 maanden dan kun je je zoekopdracht uitbreiden met perm posities. Ik heb er tot nu toe niet meer dan drie weken over gedaan om een contractpositie te bemachtigen, en ik ben appalling bij interviews, dus je kunt dit doen! Een goed contract van 6 maanden en heel weinig mensen zullen zich zorgen maken over je laatste drie perm functies! En zelfs als je moet kijken naar de onderkant van de markt in termen van dagtarief voor je eerste paar contracten zul je waarschijnlijk heel goed geld verdienen in reële termen.

of als contracteren echt niet iets is wat je wilt doen:

• Blijf perm - neem een stapje lager op de salarisladder

Op dit moment is het krijgen van een goede werkgeschiedenis onder je gordel belangrijker dan het maximaliseren van de lonen. Werk het laagste realistische bedrag uit dat je nodig hebt om te leven en ga solliciteren naar banen in die categorie. Er zijn altijd bedrijven waarvan de aanstellingsambitie het budget overstijgt, en ze zijn vaak minder kieskeurig. Zelfs als je een £5k afgesneden van je potentieel neemt, zul je in staat zijn om dat terug te verdienen op de lange termijn door het gewoon uit te steken voor ~2 jaar en goed te presteren. Ik zeg niet dat het leuk zou zijn, of gemakkelijk, maar het zou zeer effectief zijn.

*Geef niet op - je kunt dit doen! *

Ik realiseer me dat er hier al 16 antwoorden zijn, vele daarvan zijn uitstekend, maar ze lijken niet te hebben aangesproken dat er een kleine mogelijkheid is dat er andere redenen zijn om ontslagen te worden.

Het kan gewoon zijn dat dit handige excuses zijn geweest voor je ontslag. Het is nooit leuk om hier op te wijzen, maar het is de moeite waard om te onderzoeken of je er op persoonlijk vlak bij past.

Ik heb (van) een paar mensen gekend die in korte tijd verschillende banen hebben meegemaakt en ze zien niet in waarom. Voor mij (en anderen) is het duidelijk geweest - ze hebben een gewoonte of eigenschap die op de mensen om hen heen roostert. Voor een van de jongens was dit een gewoonte om de hele tijd luidkeels zijn keel op te ruimen, gekoppeld aan het niet nemen van de hint wanneer mensen een gesprek wilden beëindigen. Ik werkte in hetzelfde kantoor als hij en ik kan je vertellen, de sfeer na zijn vertrek was zo veel mooier. Een andere kerel, het was een hygiëneprobleem. Ze werden allebei ontslagen voor wat redelijk klonk, maar je wist in je achterhoofd dat deze andere eigenschappen er zeker in meespeelden.

Ik zeg niet dat je een van deze kenmerken hebt, het zou zelfs een culturele botsing kunnen zijn, niet iets wat zelfs jouw schuld is, maar zoals andere antwoorden suggereren, is een periode van introspectie hier zeer waardevol. Ik zou dat willen uitbreiden om te kijken naar zaken als persoonlijke gewoontes en eigenschappen om na te gaan of ze de verborgen oorzaak kunnen zijn.

Ik denk dat het niet luisteren een belangrijk probleem is. Niet alleen het horen van woorden, maar ook het begrijpen en ter harte nemen ervan.

Dit springt op me in:

Over het algemeen is het probleem zoals ik het zie, dat ik de neiging heb om rommelige code op te ruimen, te refactoren en ervoor te zorgen dat dingen goed getest worden - iets wat door velen gezien kan worden als traag presterend.

“Dat kan door velen gezien worden als traag presterend” is niet het belangrijkste onderdeel. Uw bedrijf vertelde u dat het langzaam presteert , omdat ze u hebben ontslagen. Als je baas zegt dat je iets moet doen, doe je het. Als je baas zegt iets niet te doen, doe je het niet. Als je het niet zeker weet, vraag het dan aan je baas en doe wat ze zegt.

Als groentje in de zakenwereld is het niet aan jou om te beslissen wat het bedrijf moet doen. Als je zelf besluit om de code op te ruimen, vertel je het bedrijf dat je het beter weet dan zij. Doe dat niet.

Als ontwikkelaar voor 32 jaar weet ik dat het frustrerend kan zijn om technische schulden achter te laten, om rommelige of ongedocumenteerde code achter te laten. Maar als dat is wat het bedrijf wil dat je doet, doe het dan.

Je zou altijd les kunnen geven in computergebruik op de middelbare school als je denkt dat je carrièrepad in de industrie beperkt is. Er zijn ook andere dingen die je kunt doen zoals projectmanagement.

Maar als je wel solliciteert naar een andere functie, leg dan je ontslag niet uit als managementprobleem. Zelfs als de manager volledig verantwoordelijk was voor wat er gebeurde, zal je de indruk wekken dat je niet in staat bent om je eigen fouten en zwakheden in te schatten.

Schrijf een korte sollicitatiebrief met je nieuwe sollicitaties en leg uit wat er gebeurde. Neem de verantwoordelijkheid ervoor, ongeacht de redenen. Leg uit waarom het anders zal zijn.

Je zult misschien een tijdje contracten moeten afsluiten. Geloof me, ik heb veel aannemers zien komen en gaan.

Als je eenmaal hersteld bent, kun je beginnen met het opbouwen van je carrière als een succesvolle werknemer.

Denk NOOIT dat je opties beperkt zijn omdat dit je opties alleen maar zal beperken. Het is geklikt, maar je moet wel een positieve instelling behouden.

Ik ken het gevoel dat ik veel tijd wil besteden aan het verbeteren van de kwaliteit van de code om de snelheid van de ontwikkeling te verhogen. Ze kunnen absoluut veel tijd besparen, tot en met het in de eerste plaats uitvoerbaar maken van complexe projecten. Ik zou echter voorzichtig zijn om deze langzaam te introduceren bij het starten van een nieuwe baan.

Verwacht dat het maanden duurt om genoeg context op te bouwen (van ontwikkelaars, gebruikers en managers evenveel als van code) om te leren waar de grootste (niet alleen de grote) pijnpunten liggen. Als je er eenmaal een goed begrip van hebt, moet je in staat zijn om een case te presenteren aan je manager voor het werken aan een van hen voor een korte periode om een of ander aspect van de code massaal te verbeteren. En als u een van deze punten vastpakt, laat u echt zien waarom ze u moeten houden. Je hoeft geen fantastische ontwikkelaar te zijn om dit te doen - iedereen met een beetje ervaring heeft vaardigheden die de rest van het team niet heeft.

Voor dat alles zou ik me echter concentreren op de dagelijkse gang van zaken. Ik heb gewerkt op plaatsen waar de kwaliteitsborging van de ontwikkelaars zo slecht was dat we bijna al onze tijd doorbrachten met het blussen van branden. Het is niet leuk, maar ongeacht je het geld kunt laten rollen in faster management zal niet geïnteresseerd zijn in het opruimen van dingen.

Als laatste opmerking heb ik een aantal slechte banen gehad als software ontwikkelaar, maar andere zijn erg leuk geweest. Persoonlijk zou ik onderzoeksinstellingen en kleinere bedrijven aanraden, omdat ze in mijn ervaring flexibel zijn in hoe ze werken en in ieder geval een beetje geïnteresseerd zijn in QA.

Ik ga het volledig oneens zijn met de andere antwoorden hier

Dus, ik kwam hier om alle antwoorden te vinden die je vertellen om je te gedragen, je hoofd laag te houden, de kritiek te accepteren, te werken aan toegewezen taken en de communicatie te verbeteren.

Ten eerste - je moet absoluut moet je communicatievaardigheden verbeteren. Het is iets waar je kan aan werken en verbeteren en ik zou dat overwegen als ik jou was.

Toen zag ik je GitHub profiel

Dit deed me van gedachten veranderen. Je code is daar inderdaad ver boven het gemiddelde en geeft aan dat je zeer kieskeurig wordt. Om duidelijk te zijn - je profiel is niet geweldig, maar het plaatst je zeker boven de gemiddelde ontwikkelaar die komt interviewen als ik kandidaten in mijn boek interview.

Je hoeft _niet te verantwoorden dat je 3 keer bent ontslagen

De software-industrie is in een plaats waar het hebben van een GitHub profiel als dit je sollicitatiegesprekken en aanbiedingen oplevert, zelfs als je 3 keer bent ontslagen.

Je kunt zeggen dat de plaatsen waar je hebt gewerkt slecht cultureel passen omdat ze niet zoveel waarde hechten aan technische uitmuntendheid als jij (wat waar is) en interviewen op plaatsen die do technische uitmuntendheid waarderen.

Veel ontwikkelaars kunnen zich dit niet veroorloven - maar jij kunt het je absoluut wel veroorloven.

Idealiter zou je werken aan wat je baas je vertelde wat een goede zaak is, maar het is heel goed mogelijk voor je om een plaats te vinden met waarden die op één lijn liggen met de jouwe.

Zoek uit wat je eigenlijk wilt

Het klinkt alsof de laatste 3 plaatsen allemaal slecht passen voor beide kanten. Aangezien je kieskeurig wordt zou ik op zoek gaan naar een plaats die:

• Werkt met nieuwe en moderne technologieën die jou prikkelen - Heeft een waardencultuur die jou interesseert
• Lost problemen op die je interessant vindt

Eerder dan te focussen op hoe je moet uitleggen waarom je ontslagen bent - focus op wat je eigenlijk wil bereiken in je job.

Programmeren prikkelt je genoeg om het in je vrije tijd te doen - hoe zit het met het prikkelt je?

Vind een plek die goed past

Ik ken een paar programmeurs in jouw situaties (die 3-4 keer in een jaar ontslagen werden) totdat ze een plek vonden die in staat was om ze in te dammen. Ze zijn behoorlijk eigenwijs, wat luidruchtig en geven echt veel om het gebruik van moderne standaarden en het doen van dingen de juiste manier.

Ze zijn nu allemaal gelukkig in dienst op plaatsen die ze kunnen bevatten.

Veel van wat ik normaal gesproken zou zeggen is al gezegd. Maar er is ten minste één pad voor je open dat ik denk dat nog niemand als antwoord heeft gegeven.

Consider contracting / self-employment.

Veel van de andere antwoorden zijn gericht op hoe je jezelf kunt verkopen aan je volgende werkgever, hoe je je korte verblijf in je laatste drie rollen kunt uitleggen, en wat je anders zou kunnen doen om je volgende baan te behouden. Dat is allemaal waar, maar een andere werkgever vinden hoeft niet de enige optie te zijn. Wat als je volgende werkgever… jij was?

Pro’s:

• Je hoeft niets uit te leggen of te verantwoorden wat er met iemand anders is gebeurd.
• Als je echt goed bent in wat je kunt doen, zullen je vaardigheden gevraagd worden, tegen een lonende prijs.
• Je hebt al zes maanden spaargeld - dat is lang genoeg om klanten te vinden en aan de slag te gaan.
• Als je eenmaal een paar klanten hebt, kun je kiezen waar je aan wilt werken (d.w.z. welke klanten je wilt aannemen), in plaats van wat je werkgever je opdraagt om aan te werken.

Nadelen:

• Je zult je eigen bedrijf moeten runnen en je eigen belastingen moeten regelen, evenals het ontwikkelen van software.
• Als je niet zo goed bent als je denkt - of als je geen motivatie kunt vinden om te doen wat de klanten willen - of als je al je tijd verspilt aan het maken van nette code zonder technische schuld wanneer de klant alleen maar werkende software wil - dan zou je al je spaargeld kunnen verbranden en precies terugkomen waar je nu bent, behalve dat je spaargeld weg is. Dit is een reëel risico. U zult een lange, harde blik in de spiegel moeten werpen voordat u deze weg inslaat. Maar ik vermoed dat je dat hoe dan ook moet doen.

Hou vol. Veel mensen bereiken hun 30s en vinden dat het niet is gelukt zoals ze hadden verwacht. Het is nog niet te laat.

Het lijkt me dat jouw probleem is dat je de dingen op je eigen manier doet. Je hebt dit gedragspatroon waarbij de manier waarop je de dingen doet “de juiste manier” is en alles wat erop wijst dat je dat moet veranderen stuitert. Gelukkig is je manier eigenlijk best goed, je hebt een sterke werkethiek, goede manieren van werken en je hebt het niet mis dat het de juiste manier is. Het probleem is wanneer dit botst met de prioriteiten van je werkgever.

• *

Je eerste ontslag was door je eigen toedoen een gebrek aan motivatie, FinTech is vrij droog materiaal, ik kan het je zeker niet kwalijk nemen dat je je interesse erin verliest, ik ben er zeker van dat het de mijne niet zou houden. Ik zal niet vragen waarom je er überhaupt mee bezig was, ik solliciteerde bij FinTech toen ik op mijn huidige werkplek solliciteerde, een baan is een baan.

Noem het een slechte pasvorm en geleerde les.

• *

Je tweede ontslag kwam er op neer dat je gevraagd werd om dingen te doen waarvoor je oorspronkelijk niet was ingehuurd (althans door je begrip van je contract) en dat je daar ongelukkig mee was.
Dit is niet ongewoon, ik heb te maken gehad met banen waar een groot deel van mijn tijd niet werd besteed aan het materiaal waar ik getraind en bekwaam in ben, dit is zeker wanbeheer. Maar als je een nieuwe skillset of toolset moet leren op het werk, dat is een deel van het werk.

Ik weet zeker dat ik je niet hoef te vertellen dat de software-industrie constant aan het schommelen is en het bijhouden van de laatste dingen is van vitaal belang voor het succes. Alleen al dit jaar heb ik Web Development vanaf het begin moeten leren en Vue.js, JQuery en Bootstrap vanaf het begin opgepakt, vorig jaar heb ik Xamarin geleerd en ben ik App Developer geworden. Daarvoor bouwde ik mobiele en Facebook games in Unity3d en Flash. Ik heb gewerkt in Agile en Scrum, zelfstandig en waterval model teams. Wat ik nodig heb, leer ik. Als je dat op dit moment niet kunt, moet je leren om je aan te passen als je wilt slagen in de software industrie.

• *

Je derde ontslag is degene waar je het meest over schrijft, het probleem is daar veel duidelijker. Je wist dat de juiste manier om code te schrijven was om het de eerste keer goed te doen, de tijd op voorhand door te brengen en het zal later tijd en geld besparen. Je hebt het helemaal niet mis. Goed werk op dat gebied.

Maar je kreeg (neem ik aan) een duidelijke opdracht en omdat je tijd buiten de opdracht om besteedde, slaagde je er niet in om consequent het werk te leveren dat je gevraagd werd om te doen.

Buiten de opdracht om gerelateerde code te repareren is iets wat ik de hele tijd doe, maar het is cruciaal om niet te verdwalen in het konijnenhol. Vergeet niet dat de laatste 10% van een probleem 90% van de tijd in beslag neemt. Open de probleemcode, patch het deel dat het probleem veroorzaakt, voeg een //TODO toe om het goed op te lossen, schrijf ergens een notitie dat het later meer aandacht nodig heeft en verplaats op. Meestal is 90% goed genoeg.

Uw #1 taak is altijd om het materiaal aan te leveren dat u werd opgedragen, en als nieuwkomer heeft u veel minder eenzijdige autoriteit dan u misschien zou willen. Ik ben zelf in de problemen gekomen voor ditzelfde onderwerp en het is soms moeilijk om door de hoepels te gaan om het gedaan te krijgen volgens het boekje.

Dit is waarschijnlijk je grootste probleem. Je moet de dingen doen zoals je werkgever wil dat je ze doet. Als je het gevoel hebt dat je werkgever onderschat hoe belangrijk iets is, leg het dan uit in termen van tijd en geld en als ze het nog niet eens zijn. Accepteer het. De werkgever is uw klant, en zoals het pittige gezegde luidt, de klant heeft altijd gelijk.

• *

Tot slot, geef niet op. Je hebt duidelijk de vaardigheden en het vermogen om een geweldige programmeur te zijn, je hoeft alleen maar een baan te vinden die je interesseert en beter te worden in het trippen van problemen, terwijl je aandacht besteedt aan de prioriteiten van je team.

Tegenwoordig is tewerkstelling in de technische wereld een soort van spel.

Ik ga er van uit dat uw bedrijf de AGILE-methodologie volgt.

De sleutel is niet om te doen wat u wilt, maar om te doen wat u is toegewezen.

En wees niet verlegen om op te komen voor meer punten, en te vragen om meer tijd.

Het is MUCH beter om meer tijd te vragen en meer punten te krijgen voor je taken OP DE BEGINNING dan om uit te glijden.

Management heeft 0 aanwijzingen over de moeilijkheidsgraad van je taken… ze gaan gewoon door de eerste schattingen.

als je niet vecht voor punten op voorhand… je bent genaaid.

Geen antwoord tot nu toe lijkt de mogelijkheid te overwegen dat je veel pech hebt gehad en 3 vreselijke banen op een rij hebt gekregen. Er zijn zeker een aantal echt vreselijke banen en onredelijke managers die er zijn. Ik heb er meerdere gehad, maar niet zoveel op een rij. Soms zijn ze erg moeilijk te herkennen tijdens het interview; in sommige gevallen zijn de functiebeschrijvingen en de dingen die in de interviews worden gezegd totaal onnauwkeurig en misleidend. Het is dus MOGELIJK dat dit niet jouw fout is; maar alleen jij hebt genoeg informatie om dit te kunnen beoordelen.

Uiteindelijk heb je waarschijnlijk wel een slechte baan om mee te beginnen (vervelend, slecht management, laag salaris). Je moet het gewoon een paar jaar tolereren, dus denk goed na over wat je bereid bent te accepteren in een baan, en verlaag misschien je verwachtingen.

Het lijkt me dat je enige probleem is dat je niet in staat bent om de taken te doen die je hebt gekregen. In al uw banen waar u van ontslagen bent, geeft u aan dat u de taak die u is gegeven niet heeft uitgevoerd en dat u zich heeft gericht op iets anders (refactoring, enz.). Tenzij je deze dingen naar voren brengt voor je op het punt komt dat je deadlines zou missen, zou ik het niet doen.

Onthoud dat mensen altijd het ergste denken in elke negatieve situatie. Dus als je de deadline mist, en je hebt meerdere bestanden veranderd (ook al duurt het minder dan dat), zullen ze er niets goeds van denken. Zorg ervoor dat je problemen die je ziet, communiceert en krijg toestemming om iets anders te doen van je manager voordat je het zelfs maar doet. Begin niet zomaar met een andere taak.

Ik denk dat als je dat advies opvolgt, je een succesvolle carrière zou hebben. Op een gegeven moment zou iedereen vertrouwen hebben in jouw expertise en zich richten op het verbeteren van de code. Maar als de nieuwe man, die niemand weet over het niet doen van een eenvoudige taak en het opnieuw maken van ongerelateerde code, zal dat gewoon niet werken.

Ik weet dat er al veel te veel antwoorden op deze vraag zijn, maar ik wilde gewoon mijn ervaring delen op basis van de suggestie van Joe Strazzere u overweeg uitzend/contractwerk.

U zei dat u gevestigd bent in het Verenigd Koninkrijk, de aannemersmarkt is daar op dit moment booming. In Londen kun je ongeveer 500 pond per dag verdienen. Het mooie hiervan is dat je nooit moe wordt van de plek waar je werkt en dat je elke 3-6 maanden een nieuw contract moet vinden.

Dit is misschien een oplossing, maar je bent misschien ook niet geschikt voor het snelle tempo van het aannemerswerk. Persoonlijk heb ik er echt van genoten en na mijn eerste 6 maanden contracteren voor de BBC had ik genoeg spaargeld om volledig freelance te gaan en thuis te werken.

Het doel dat je moet nastreven is om een aantal goede klanten te krijgen en op afstand te werken. Dan heb je volledige vrijheid om je code te refactoren, zolang je projecten maar op tijd aflevert. Persoonlijk was ik nog nooit zo gemotiveerd als toen ik mijn eigen bedrijf runde. Ik zou 12 uur per dag, 6 dagen per week werken.

** Maar ik krijg ook het gevoel dat je niet 100% tevreden bent met je carrière, misschien is het tijd om een pauze in te lassen? **

Je hebt besparingen, waarom ga je niet op reis en denk je 3-6 maanden na over je volgende stap? Een geweldige manier om te reizen is door gebruik te maken van workaway, ik heb me als vrijwilliger aangemeld in Spanje en Japan. Je zult veel mensen ontmoeten. https://www.workaway.info/299958546294-en.html ](https://www.workaway.info/299958546294-en.html)

Je hebt problemen met het behouden van focus en motivatie bij het omgaan met andermans code.

Ik sympathiseer hiermee - Het is moeilijk om nieuwe functies de deur uit te blijven schuiven zonder het huis schoon te maken en toch het gevoel te hebben dat je bijdraagt aan iets waar je trots op kunt zijn.

Maar, helaas, dat zal gelden voor de overgrote meerderheid van de organisaties die je zullen inhuren om code te schrijven. Ik ga je niet vertellen dat je ‘er overheen moet komen’ - ik stel me voor dat, tenzij je diepgaand slecht bent in zelfreflectie, deze optie al bij je opgekomen is.

In plaats daarvan stel ik voor dat je overweegt je technische kennis te gebruiken voor een carrière in softwareontwikkeling waarbij het schrijven van applicatiecode niet centraal staat.

Je zult misschien meer plezier, voldoening en een makkelijkere tijd vinden om je te concentreren als een QA Engineer en/of een DIT. Je krijgt nog steeds de kans om code te schrijven en veel van dezelfde soort boeiende puzzels op te lossen, maar je CORE focus en verantwoordelijkheid is het verbeteren van de kwaliteit van het product. Dat lijkt meer in lijn met het initiatief dat je hier hebt laten zien.

Het is mijn ervaring dat je in dit soort rollen meestal een kleiner team hebt, een kleiner deel van de codebase waar je verantwoordelijk voor bent, en daardoor veel meer ruimte om agressief te refactoren. Bovendien, als je je werk goed doet, schrijf je niet alleen code waar je blij mee kunt zijn, je helpt ook meetbaar de kwaliteit te verbeteren van wat daadwerkelijk de productie raakt.

Het is ook relatief eenvoudig om die overgang te verkopen aan een potentiële werkgever in die termen - Je had moeite als software ontwikkelaar omdat je te veel tijd besteedde aan wat in essentie neerkomt op kwaliteitscontrole, dus je besloot om over te stappen op het doen van alleen maar kwaliteitscontrole.

Ik zou adviseren om een pauze in te lassen en aan jezelf te werken. Vooral het ontbreken van een positieve vriendenkring en een inactief sociaal leven lijkt een enorme bijdrage te leveren aan je leven. Voel je je uitgebrand of eenzaam? Heeft u geprobeerd een therapeut of een mentor te bereiken om te controleren of u lijdt aan enige vorm van depressie of ADD? Voelt u zich op uw gemak bij het werken onder gezag? Heeft u erover nagedacht om freelance of parttime te werken? Veel mensen zijn in de jaren ‘30 of '40 op een plateau terechtgekomen. En codering kan soms een zielsverwoestende job zijn. Probeer je hobby’s of een aanverwant vakgebied te verkennen dat dicht bij je domeinexpertise ligt.

Het probleem lijkt wel relevanter voor je persoonlijkheid dan je vakgebied. Ik raad je ten zeerste aan om een pauze in te lassen en te gaan zoeken totdat je de motivatie vindt om deel uit te maken van een ander team.

Als een ontwikkelaar die ook waarde hecht aan schone, goed geteste code, en die een hekel heeft aan codeschuld, kan ik uw standpunt begrijpen. Echter, u wordt betaald om de toegewezen taken te voltooien. Werk gaat niet over het doen van wat je wilt doen, maar over het doen van wat je werkgever van je verwacht. Het is een bonus als je plezier kunt vinden in het doen van de dingen waarvoor je betaald wordt. Het hebben van een goede werkethiek vereist de ontwikkeling van zelfdiscipline om je te concentreren op de toegewezen taak en deze naar tevredenheid van je werkgever uit te voeren, of je het nu leuk vindt om het te doen of niet, of je er nu voldoening in vindt om het te doen of niet. De beloningen die je hieruit kunt halen zijn (1) betaald krijgen, (2) een zekere mate van zekerheid hebben dat je in dienst blijft, (3) misschien iets nieuws en nuttigs leren, (4) het opbouwen van respect in de organisatie dat je misschien kunt gebruiken om uiteindelijk dingen meer naar wens en/of tevredenheid te doen.

Als je denkt dat belangrijke taken niet worden uitgevoerd (refactoring, het verminderen van de codeschuld, het verbeteren van de testdekking), zeg het dan met alle middelen tegen je begeleider. Als het kan worden gedaan in de loop van het voltooien van een toegewezen taak zonder de voltooiing van de toegewezen werkzaamheden te vertragen, geweldig. Als het alleen kan worden gedaan ten koste van de toegewezen taak, laat het dan.

Iets anders om te overwegen: zakelijke beslissingen worden genomen op basis van de vraag of ze verhogen de inkomsten of verlagen de kosten, en hebben over het algemeen een korte horizon. Het is niet ongewoon dat bedrijven zich richten op de resultaten voor het huidige of volgende kwartaal. Veel investeringsgeld wordt verplaatst op basis van de kwartaalresultaten; dit is wat de bedrijfsbeslissingen stuurt. De verbeteringen die je gemotiveerd voelt om aan de codebasis te maken, zijn een investering op langere termijn zonder een kwantificeerbaar voordeel. We weten allebei dat het een goede zaak is, en voor een bedrijf dat voor de lange termijn zaken doet, is het juiste ding. Echter, bedrijven maken geen beslissingen op basis van wat juist of het beste is op de lange termijn, ze dienen hun meesters - de investeerders.

Als u besluit door te gaan als ontwikkelaar, en ik voel dat u dat doet, omdat u trots bent op uw prestaties buiten deze drie banen, neem dan concrete stappen om uw beperkingen aan te pakken, zodat uw sterke punten eindelijk beginnen te schitteren voor uw werkgevers.

Mag ik eerst suggereren dat uw gebrek aan focus wordt veroorzaakt door een gebrek aan dagelijkse organisatie? Zorg er bij je volgende job voor dat je te allen tijde weet wat de drie belangrijkste prioriteiten zijn die je baas je heeft toegekend (en hun relatieve belang). Schrijf aan het begin van elke werkdag je huidige prioriteiten op, en vat aan het einde ervan samen wat je tegen hen hebt bereikt. Wees niet te ver doortastend, maak elke prioriteit en prestatiebeschrijving zo kort en bondig mogelijk met slechts het minimaal vereiste detail. Zoiets als…

Begin van de dag

1. Implementeer de nieuwe functie A
2. 2. Schrijf de eenheidstests voor A
3. Bouw nieuwe A release met documentatie voor testers.

Einde van de dag

1. Geïmplementeerd A
2. 2. Schrijf unit tests voor A, en repareer bugs zodat het alle tests doorstaat.

3. Bouw een nieuwe versie met documentatie voor testers. 3. Was niet in staat om A vrij te geven, omdat ik twee uur heb besteed aan het ondersteunen van de verkoop bij een prioritair klantenprobleem met product.

4. En de volgende dag zou uw eerste prioriteit waarschijnlijk

1 zijn. Bouw release A en schrijf documentatie voor testers. 2. …

Doe elke maandagochtend iets soortgelijks voor de week. Schrijf eerst je geplande doelen/prioriteiten voor de week op, en verwijs er dan elke ochtend naar bij het schrijven van de dagelijkse prioriteiten zodat ze in overeenstemming zijn met je wekelijkse verplichtingen.

Ook recapituleren en samenvatten wat je de vorige week hebt bereikt, met behulp van je aantekeningen aan het einde van de dag. Stuur het dan naar je baas als je wekelijkse doelstellingen/verwezenlijkingen, zodat ze weten wat je hebt gedaan en van plan bent te doen. Op deze manier kunnen ze je cursuscorrecties aanbieden als je het mis hebt of als je prioriteiten zijn veranderd. En als je voor het eerst aan je nieuwe baan begint, kun je de eerste weken zelfs je dagelijkse ochtendprioriteiten met de recapitulatie van gisteren naar je baas sturen om hun vertrouwen in jou nog sneller op te bouwen.

Zorg er gewoon voor dat je de wekelijkse doelen niet te agressief maakt, je wilt niet voortdurend verplichtingen missen die je baas ziet, zelfs als het kunstmatige doelen zijn die je voor jezelf hebt gesteld. Breek ze in “Verbintenissen” die je met veel vertrouwen aangaat, en “Stretch Goals” die je communiceert als de week goed verloopt.

Door jezelf op deze manier te organiseren, helpt het je een aantal belangrijke dingen te bereiken.

1. Het begin van elke dag zal je opnieuw focussen op je toegewezen prioriteiten en verplichtingen, waardoor het makkelijker wordt om je te verzetten tegen het heropbouwen en het doen van ander niet-toegewezen werk.
2. 2. Door jezelf te dwingen om aan het einde van elke dag prestaties te recupereren, wordt het heel duidelijk wanneer je een terugval hebt, wat je weer helpt om je te heroriënteren op de aan jou toegewezen prioriteiten.
3. 3. Het delen met je baas helpt hen om je te zien als een betrouwbaar en voorspelbaar teamlid waardoor ze er goed uitzien voor hun baas en helpt hen hun eigen doelen te bereiken.

Ik doe eigenlijk elke week zelf het wekelijkse rapport voor mijn baas, en hij vindt het geweldig. Het is eigenlijk de hoeveelheid communicatie die we nodig hebben verminderd omdat hij veel vertrouwen heeft ontwikkeld dat hij weet wat ik doe en me gemakkelijk kan bijsturen als de prioriteiten veranderen.

Ik doe niet de dagelijkse werkdag planning/recapitulatie, maar ik raad het aan omdat ik me na het lezen van je bericht realiseer dat we het allebei nodig hebben. Net als jij heb ik de neiging om me te laten verleiden tot het refactoren van code en het oplossen van problemen die niet noodzakelijkerwijs hoge prioriteiten hebben voor het bedrijf. En een week is een lange tijd, het is gemakkelijk om halverwege de week een aantal belangrijke doelen te vergeten en alleen te beseffen dat ze werden gemist bij het recappen van de week op maandag. Dus toen ik dit aan u schreef, heb ik mezelf ook toegewezen om dagelijkse herinneringen te herhalen om beide te doen.

Tot slot, als mijn aanbevelingen niet lijken te werken om u elke dag op de juiste prioriteiten te concentreren, is dat oké. Maar zorg ervoor dat je een ander systeem vindt dat dat wel doet. Zelfs als je naar een ander vakgebied verhuist, is het elke dag focussen op de verwachtingen van je baas en je bedrijf een belangrijke factor om te slagen in welk carrièrepad je ook kiest.

Wanneer je in je volgende interviews moet uitleggen waarom je niet geslaagd bent in je vorige functies, is een goed antwoord dat ik een perfectionist ben die moeite had om op de juiste prioriteiten gefocust te blijven, dus ik heb mezelf toegewijd om die zwakte om te zetten in een kracht door mezelf rigoureus te organiseren, en dit is hoe ik het nu doe en het voor jou zal doen.

Tot slot, je gaat slagen! Je hebt al laten zien dat je hebt wat er nodig is door de zelfanalyse te doen die je ertoe bracht dit bericht te schrijven. Je hebt de wens, je hebt het vermogen, je hoeft alleen maar de focus en de organisatie toe te voegen. Het probleem wordt je duidelijk en je hebt het vermogen om het op te lossen. Ik kijk uit naar uw toekomstige succes en hoop dat u updates plaatst zodat we er allemaal in kunnen delen.

Beste wensen,

Randy

Edit: Vergeet nooit dat Steve Jobs ontslagen is bij Apple en dat de lessen die hem dat heeft geleerd hem de tweede keer een veel betere CEO hebben gemaakt. Edison werd ontslagen bij Western Union en faalde duizend keer voordat hij zijn gloeilamp perfectioneerde. Walt Disney werd ontslagen door de KC Star omdat hij niet “creatief genoeg” was, dus begon hij zijn eigen bedrijf en ging failliet. Je bent nog erg jong, neem de lessen die je hebt geleerd en gebruik ze om je succes te behalen.

Oké, dus we zijn het erover eens dat je de bodem van je carrière hebt bereikt. En dan? Er is maar één richting die je kunt inslaan, en dat is omhoog!

Of je in je huidige carrièrekeuze doorgaat of niet hangt er volledig van af of je het daadwerkelijk ENJOYED hebt.

Als je er NIET van genoten hebt: Ik raad je aan om niet door te gaan met dit carrièrepad. Je zou elders een kleine baan moeten nemen (zelfs een dreigende) om fondsen op te bouwen om iets na te streven dat je meer interesseert.

Als je echt plezier hebt in je werk: Je staat aan de “onderkant”, toch? Dus druk op reset! Begin opnieuw van onderaf, en doe het deze keer goed. Begin te solliciteren voor software banen als een Jr. level ontwikkelaar (of zelfs een stagiair, als het moet) bij welk software bedrijf dan ook. Werk deze keer heel hard om je reputatie & cv op te bouwen, en maak ook indruk op je nieuwe werkgevers.

In beide gevallen - ik raad je aan om die eerdere softwarejobs niet eens op je cv te vermelden - doen ze je geen plezier. Een harde reset is hier het beste! En het is geen schande om het opnieuw te proberen en er hard aan te werken!

Er zijn hier een heleboel echt geweldige antwoorden, maar ik heb wel aanvullende inzichten die je misschien in gedachten wilt houden bij het vinden/houden van de volgende baan.

Ten eerste, geef nooit je dromen op. Je hebt veel tijd geïnvesteerd, en ik neem aan dat het geld om op dit carrièrepad te komen; stoppen op dit moment is niet het juiste om te doen.

Het beste wat je nu kunt doen is dit allemaal bijschrijven om te ervaren, en het de volgende keer beter te doen. Een gemeenschappelijke overtuiging onder beginnende ontwikkelaars is dat hun programmeervaardigheden superieur zijn aan hun voorgangers. Dit mag waar zijn in sommige gevallen, maar zelfs als dat waar was, dan nog zijn andere senior programmeurs erg trots op wat ze hebben gemaakt, en raken ze beledigd als een of andere nieuwe man binnenkomt en hun programma’s gaat vernielen.

In de bedrijfswereld wordt softwareontwikkeling zeer serieus genomen, en zijn er echte gevolgen verbonden aan het uitbrengen van een slecht product. Bedrijven zijn afhankelijk van de betrouwbaarheid van hun producten, en één klein defect zou kunnen ontstaan, waardoor er stroomafwaarts enorme problemen zouden kunnen ontstaan. Je wilt niet die kerel zijn. In de financiële wereld kan een kleine fout miljoenen kosten en zelfs een bedrijf failliet laten gaan. Dus… bedrijfseigenaren zijn meestal erg beschermend over hun code, en ze willen niet dat iemand aan iets sleutelt wat ze niet mogen aanraken.

Probeer je gewoon te concentreren op de specifieke taken die voor handen zijn en heb een duidelijk begrip van de verwachtingen. Probeer niet verder te gaan dan wat er van je verwacht wordt, in ieder geval tot de proeftijd voorbij is. Kom gewoon elke dag op tijd opdagen, doe je werk zonder anderen te beïnvloeden, en heb een goede verstandhouding met je collega’s, en je zult niet ontslagen worden. Vergeet niet dat je niet alleen wordt ingehuurd voor je programmeervaardigheden, dat haalt je alleen maar binnen. Als je wilt slagen, dan moet je ook werken aan je soft skills. Je succes hangt af van het hebben van een goede houding, en het opschieten met anderen.

Geef niet op!

Om toe te voegen aan wat anderen hebben gesuggereerd: Stel je voor dat je X jaar bij een bedrijf werkte en dat er een nieuwe medewerker kwam opdagen en begon aan te geven (door middel van woorden en daden) dat het bestaande werk (waar jij en je collega’s al jaren aan werkten) “slordig”/“waardeloos”/“moest veranderen zodat de nieuwe medewerker zich comfortabel voelde”, hoe denk je dat je (en je collega’s) zou reageren als je door de managers werd gevraagd om je feedback over de nieuwe medewerker? Ik kan me niet voorstellen dat iemand reageert: “Ja, ik hou ervan om met hem te werken, en hij weet zeker wat hij doet.” Ik kan me voorstellen dat de feedback meer is: “Arrogant, know-it-all, lijkt niet in staat om te integreren met het team”

Ik ben altijd ineengezakt als ik een nieuwe medewerker iets hoor zeggen in de trant van: “Je bestaande code/product/proces is crap/bad/wrong. Mijn ideeën/methodes zijn beter. Ik weet goed van kwaad, maar jij niet. Ik kan het goed doen, waar jij het niet kan”. Ik heb altijd het gevoel dat een nieuwe medewerker het niet gaat halen na een proefperiode (& ik heb het zelden fout gehad).

Er zijn vele redenen voor het feit dat de code is zoals hij is, inclusief het meenemen van legacy werk, tijdsbeperkingen, slordige programmeurs, het aanpassen aan veranderende specificaties, het werken met legacy HW/SW/systemen, etc. De code is echter het product van die groep/bedrijf en ze zullen enige trots hebben op hun eigendom en waarschijnlijk zelfs enig empirisch bewijs dat het “goed genoeg” werkt om ze $ te verdienen. Je zou zelfs de inspanningen van andere leden van de groep (of zelfs de manager) kunnen verwerpen. Het kan zelfs zo zijn dat u zich in uw evaluatie niet meer kunt onderscheiden, maar dat kan totaal irrelevant zijn. Programmeren in perm-functies gaat ook over samenwerken als een groep (en die groep omvat ook je manager).

Als je wilt werken als perm in vergelijkbare groepen, bedenk dan wat je kunt veranderen (in de kern mentaal) zodat de andere leden van de groep je manager feedback geven die hun beslissing om jou aan te nemen bevestigt, en aangeeft dat je de groep beter zal maken met minder vermijdbare onaangename verrassingen (voor zowel je manager als voor het bedrijf).

Dit is een breed antwoord met veel suggesties:

1. Probeer je verwachtingen te verlagen, er moet een juiste functie voor je zijn in de IT.
2. 2. Misschien moet je je eerste keer vragen stellen over de verantwoordelijkheden. 3. Communiceer wanneer er blokkades zijn. 4. Spreek je mening uit terwijl je professioneel blijft.

3. Wanneer u niet gemotiveerd genoeg bent, is dit over het algemeen uw probleem, dus probeer korte vacatures aan te vragen die verspreid zijn over het jaar, in plaats van een paar lange vacatures (dit kan helpen, of niet).

4. U kunt parttime banen proberen in de wetenschap dat u tot 6 maanden bespaart, dan kan het worden uitgebreid naar meer! met behoud van de competitieve geest, en een bijgewerkte cv.

5. Verandering van rol, in grote bedrijven is soms makkelijker, als het een mogelijk geval zou zijn voor u, kan dit zeer motiverend zijn.

6. Ik ken uw achtergrond en profiel niet, maar er zijn missies in IT die minder techniek omhullen, zoals het promoten van IT producten, het organiseren van bewustmakingssessies over nieuwe technologieën voor andere hogescholen, het schrijven van documentatie, het opschonen van oude code (voor ontwikkelaars), het opzetten van nieuwe proof of concepts, projectideeën, het deelnemen aan uitdagingen en het proberen om bovenaan te staan voor de naam van uw groep. … etc, zie dat er veel dingen zijn die een ontwikkelaar bijvoorbeeld kan doen in de IT.

Dit is een lijst van meer vrijheidsopties die ik me voor nu kan voorstellen.

1. Je realiseerde je dat de code slecht was.
2. 2. Je hebt er naar gehandeld om de code te verbeteren.
3. De managers waardeerden dit niet.

Nou, op sommige plaatsen wordt je echte hulp gewoon niet gewaardeerd en ze willen gewoon dat je verzonnen problemen oplost, alleen maar om hun gevoel van voldoening te voeden. Dit kan een van deze situaties zijn - ik weet het niet zeker. Als dat het geval is, dan is er niet veel dat je kunt doen. Je realiseert je dat het een verzonnen mumbo-jumbo is en je kiest ervoor om te proberen je best te doen wat je kunt en dat zou het bedrijf ten goede kunnen komen.

Ik zou zeggen blijf erbij. Totdat je een plek vindt waar dat gewaardeerd wordt. Zulke plaatsen bestaan wel degelijk.

Je lijkt de neiging te hebben om geen richting te volgen, en/of te verzanden in details die er niet toe doen, om te doen wat je liever doet. Dat resulteert in een gebrek aan teamwork en slecht tijdmanagement.

Ik had vroeger een collega die werd ingehuurd voor een functie die hij niet wilde. Ik kon in het interviewproces zien dat hij een afkeer had van bepaalde legacy technologieën en standaard platformen waar hij aan zou werken. Hij was sterk bevooroordeeld. Zelfs zijn CV gaf aan dat hij van de ene plaats naar de andere stuiterde. Het management luisterde niet naar mij. We namen hem toch in dienst.

Hij wilde niet alleen niet de hem toegewezen taken uitvoeren waarvoor hij niet bereid was om ze te leren, maar hij probeerde ook andere technologieën en codebases te vinden om te vervangen wat wij hadden, of soms zelfs te proberen de taken van andere mensen over te nemen.

Hij wilde ieders code “repareren” en ons vertellen hoe het “zou moeten” gebeuren. Hij wilde ieders tijd verspillen met code-reviews over projecten die al in productie zijn, zodat hij ons de juiste codering en schone syntaxis (of het gebrek daaraan) kon laten zien. Hij was te perfectionistisch en verspilde daardoor zijn tijd.

Misschien zijn deze kenmerken niet op jou van toepassing. Misschien hou je er gewoonweg niet van om te doen waar je mee belast bent, en heb je een verandering nodig. Maar als je je kunt identificeren met deze punten, zal je het nergens lang uithouden.

Ironisch genoeg kreeg mijn voormalige collega eigenlijk een betere baan als gevolg van de ervaring die hij had met het werken aan de technologie/het platform dat hij haatte. Dus soms moet je jezelf dwingen om het werk te doen waar je geen zin in hebt.

Sommige bedrijven hebben zeer hoge omloopsnelheden, waarbij meer dan de helft van de mensen elk jaar verandert. Wanneer sommige bedrijven zouden proberen om aan het probleem te werken, de redenen te begrijpen, iets te veranderen aan hun eigen kant, kunnen anderen direct na het spotten van zelfs zwakke tekenen van iets dat ze beleid niet te tolereren.

Helaas huren deze “high throughput” bedrijven ook het meest, zelfs als ze niet groeien - om de grootte van het team te behouden. Ze laten nooit de berichtenborden in populaire vacatureportalen achter. Als je niet kijkt waar je naartoe gaat, zijn er redelijke kansen om ze steeds weer te raken, zelfs als ze niet de meerderheid maken.

Probeer het bedrijf te vinden dat opvalt maar niet zo actief is met vaste aanwerving. Begrijp de redenen om ontslagen te worden (zelfs als ze er nogal zwak uitzien). Vermijd gelijkaardig gedrag dat een voorgeprogrammeerde reactie kan uitlokken zodra het wordt herkend.