Wat moet ik op mijn cv zetten als ik promotie heb gekregen omdat ik de kwaliteit van de code heb laten zakken om deadlines te halen?
Ik had een contract van 12 maanden (ik woon in een land waar dit niet gebruikelijk is voor nieuwe ontwikkelaars) tot een paar weken geleden, toen het management van mijn bedrijf me een aanbod deed en me opslag gaf om een vaste medewerker voor hen te worden. Ik wil mijn cv altijd up to date houden (vooral gezien COVID) dus ik heb wat rond gegoogled over het vermelden ervan op mijn cv.
Het advies dat ik vond was dat ik in het algemeen moest vermelden welke prestatie de aanleiding was voor de aanstelling. Dat is redelijk.
Het probleem is dat de prestatie altijd het leveren van strakke deadlines aan de klant was en eerlijk gezegd, deed ik dat door te besluiten dat de engineering in bepaalde gevallen minder dan uitstekend kon zijn (waarmee het management instemde).
Ik'ben een relatief junior dev in een team van 6 ontwikkelaars. Ik ben echter snel uitgegroeid tot een van de ontwikkelaars die het management het meest vertrouwt om dingen te leveren wanneer ik zeg dat ik het zal leveren en hen op de hoogte te houden van de relatieve afwegingen om daar te komen. In mijn toegegeven korte tijd hier, ben ik altijd in staat geweest om iets te leveren wanneer ik heb gezegd dat ik het kan leveren.
Ik heb een paar van dit soort gevallen gehad, maar dit is het geval vlak voordat ik de vaste baan kreeg aangeboden. Een van onze producten is een batch API die eenmaal per dag wordt aangeroepen door een enkele klant. Het hoeft niets terug te sturen, behalve een CSV van mislukte invoer via e-mail. Zij wilden een nieuwe functie toegevoegd hebben en de verkoper had contractueel afgesproken om het voor hen te hebben tegen het einde van de maand. Om verschillende redenen kwam die aanvraag pas op maandag van de laatste week van de maand bij ons binnen.
Senior ontwikkelaar vertelde de manager dat de ontwikkeling niet goed kon worden gedaan en om de klant te vertellen dat het niet kon worden gedaan. Ik spreek de senior devs niet tegen in sprint planning meetings, maar misschien was het duidelijk dat ik het niet eens was met senior man. Zoals, niet oneens, maar een optie bestond met bepaalde trade offs. De andere devs zijn ook vrij passief, dus niemand anders sprak hem ook tegen. Manager was hier niet blij mee, omdat de klant al boos op ons is omdat we niet leveren terwijl we dat wel beloven. Manager ontbood me vervolgens naar zijn kantoor na de vergadering om te vragen of ik een alternatief zag. Ik vertelde hem dat ik wel iets aan de praat kon krijgen, maar dat het waarschijnlijk de verwerkingstijd van de API zou verdubbelen (wat 4 minuten extra zou kosten) aangezien ik geen specialistische SQL vaardigheden heb. De manager ging akkoord en blijkbaar heeft de klant het niet eens gemerkt.
Ik weet niet zeker wat de gevolgen van het missen van de deadline zouden zijn geweest, maar ze waren steil genoeg dat de CEO van ons 1000 personen tellende bedrijf me een bedankmailtje stuurde voor het leveren van het.
Een ander geval trok niet zo veel aandacht, maar er was een proces dat we moesten uitvoeren op een database. De juiste manier om het te doen zou zijn geweest om een goed batch proces te schrijven in het mega Java systeem dat we gebruiken, het door alle reguliere QA processen te sturen, en het er twee weken later uit te laten knallen. Ik bood de manager een Python script aan dat handmatig zou moeten worden uitgevoerd en afschuwelijk inefficiënt zou zijn (het moest 's nachts worden uitgevoerd), maar als het eenmaal per maand zou worden uitgevoerd, zou het probleem op afstand worden gehouden totdat er een permanente oplossing zou zijn. Dit was een productie probleem, dus stemde hij daarmee in als noodoplossing. Dit was in feite gewoon een goedkope for-lus die rijen controleerde op een bepaald type foutieve gegevens en ze opnieuw formatteerde.
Is er een manier om dit soort dingen op mijn CV te zetten, zodat ik er niet uitzie als een hack-programmeur die senior devs ondermijnt? Ik geef toe dat mijn oplossingen technisch niet goed zijn, maar ze waren goed voor de behoeften van het bedrijf op dat moment en de inefficiëntie was in de meeste gevallen niet van belang.
Je hebt verschillende effectieve (niet efficiënte) manieren gevonden om problemen op te lossen zonder ze te over-engineeren en "Done is better than perfect"
Een oplossing vinden die net goed genoeg is, is een belangrijke vaardigheid voor een ingenieur, omdat je anders veel tijd zou besteden aan het optimaliseren van iets dat het optimaliseren niet waard is. Als iets niet vaak gebruikt wordt, is het vaak niet de moeite waard om het te optimaliseren. Er is een leuke XKCD-Comic met een tabel die je vertelt hoeveel tijd je in iets zou moeten investeren.
Een oplossing is alleen iets waard als het gebruikt (kan) worden, dus met een hack heb je de klant in staat gesteld om door te werken tot je een oplossing hebt.
Er is geen reden om iemand te vertellen dat je het niet eens was met je leidinggevende. Ga gewoon voor iets als "In staat om effectieve oplossingen te produceren onder tijdsdruk".
Je had één taak: "vind een oplossing die binnen de tijdslimieten werkt en die de taak oplost". En dat is precies wat u deed.
Ik heb het gevoel dat alleen het management hier antwoorden heeft gegeven, want er was niets dan lof voor het vasthouden aan onredelijke deadlines.
Er is nog een ander gezichtspunt. Je moet de sociale verstoringen die je binnen het ontwikkelingsteam ontketent niet onderschatten als het management de bocht om gaat en de mening van senior ontwikkelaars negeert. Er is een gezegde dat ongeveer zo gaat:
Het is één ding als je een keer/twee keer de hachelijke weg inslaat omdat je gedwongen wordt om dit te doen, maar een heel andere als het de norm krijgt. En uit uw beschrijving lijkt het me dat het management zich behoorlijk op zijn gemak voelt met het gebruik van u om de bochten te spannen. U zou serieus moeten overwegen om dit onderwerp aan te kaarten bij uw management en senior medewerkers om zo een gezonde werkomgeving te behouden. Een bedrijf is een balans tussen dev en management en niet alleen maar een top-down structuur. Er is een reden waarom het woord "nee" bestaat en u zou het moeten gebruiken.
Dit is echter nog steeds meer een zaak van het management dan van u. Er is dus geen reden om dit op de een of andere manier in uw cv te vermelden. Dus ik zou me erbij aansluiten:
Zoals het gezegde luidt: "Perfect is de vijand van goed" - technische compromissen sluiten om aan zakelijke behoeften te voldoen is zo goed als onvermijdelijk. De goede ontwikkelaars/programmeurs/ingenieurs zijn degenen die de aanvaardbare compromissen kunnen identificeren die kunnen worden gemaakt.
In uw API voorbeeld was de klant duidelijk meer bereid om een vertraging van 4 minuten in de verwerking te aanvaarden voor iets dat werkte en op tijd werd geleverd.
Idealiter zou je moeten kijken naar het minimaliseren van technische schuld bij het maken van deze compromissen - maar dat's all part and parcel van ervaring en weten waar je kunt tijd scheren en wanneer je nodig hebt om ervoor te zorgen dat iets wordt gedaan "right" om meer tijd te besparen op de lange termijn.
Als het over je CV gaat is het niet nodig om in de details van je oplossing te treden - je kunt gewoon zeggen dat je een goede staat van dienst hebt in het leveren binnen deadlines op tijdgevoelige projecten en de voorbeelden noemen zonder details over de eigenlijke implementatie.
Wat jij doet is NIET "hacken", het is "oplossingen vinden".
Ik werk nu al 20 jaar als ontwikkelaar en consultant, en dit is waar werkgevers naar zoeken: Laat het niet weg uit je cv, maar benadruk juist dat: Je probeert oplossingen te vinden, zelfs als dat betekent dat je "unusual" paden moet bewandelen.
Schrijf niet dat je dat achter de rug van senior ontwikkelaars doet, maar dat je dat doet wanneer je om oplossingen wordt gevraagd, zelfs als meer ervaren jongens het er niet mee eens zijn / zeggen dat het niet mogelijk is.
Er is een geweldig citaat dat van Albert Einstein afkomstig zou zijn en dat precies jouw situatie beschrijft:
Iedereen wist dat het onmogelijk was, totdat een dwaas die het niet wist langs kwam en het deed.
Ik heb met veel ontwikkelaars samengewerkt en ik ken elk facet hiervan:
Ik werkte met een ontwikkelaar die bij de top 1% van JavaScript-experts op stackoverflow hoort. Hij is een genie en ik heb echt bewondering voor elke regel code die hij schrijft. Maar heel vaak maakte hij zijn projecten niet af: Hij maakte liever iets niet af dan dat hij het afmaakte als hij niet tevreden was met de schoonheid van de code.
En ik heb gewerkt met ontwikkelaars die uiterst efficiënt waren, maar daardoor veel shortcuts namen die de oplossingen bijna ononderhoudbaar maakten (hardcoded paden, magische getallen, enz.).
En ik verkoos altijd "done" boven "beautiful" en uiteindelijk deden mijn klanten dat ook: Zij'hebben liever "iets" als de deadline daar is dan "niets maar zal over wat meer tijd X" mooi zijn;
Slechts een ding: Workarounds / shortcuts / "hacks" moeten begrijpelijk, gedocumenteerd en onderhoudbaar zijn, dan is er niets tegen oplossingen zoals jij
Dus je hebt wat software gemaakt die vier minuten duurde om te draaien (omdat je code niet erg goed was). Als het me 12 uur kost om het werk met de hand te doen, bespaart je software me 11 uur en 56 minuten. Als je betere code hebt geschreven die in 1 seconde draait, bespaart het me 11 uur, 59 minuten en 59 seconden. Als de betere code een week later werd afgeleverd en ik het werk dus vijf keer met de hand moest doen, zullen de extra 3 minuten 59 seconden nooit de tijd compenseren die ik verloren heb.
Of maak het extremer. De software moet in 24 uur draaien. Je code is slecht, dus we hebben een $5.000 computer nodig om het in 24 uur uit te voeren. Met een betere code, kan een $2.000 computer het in 24 uur uitvoeren. $3.000 besparing. Als je er twee weken over doet om de code sneller te maken, is het een algemeen verlies.
In staat zijn om te leveren wanneer het nodig is, is een zeer, zeer goede zaak. Bovendien kan een zeer goede ontwikkelaar slechte code op een bepaalde manier schrijven, zodat deze later gemakkelijk kan worden verbeterd. Slechte ontwikkelaars schrijven slechte code die een pijn is om te refactoren in een goede vorm, goede ontwikkelaars onder tijdsdruk schrijven slechte code die gemakkelijk te verbeteren is.