Ik haat het om je zeepbel te laten barsten, maar als dit de derde keer is dat dit gebeurt, sluit dat bijna uit dat “jij het niet bent, maar zij het”. Je titel zegt dat je ontslagen bent omdat je “onmisbaar” bent, maar afgezien van het feit dat het een oxymoron is, is het ook niet wat er gebeurd is. U bent ontslagen omdat u code schreef die uw collega’s niet kunnen begrijpen, wat voor een programmeur een kritisch prestatieprobleem is.

Goedige code is leesbare code , dat wil zeggen code die gemakkelijk te begrijpen is, _ zelfs voor beginnelingen_. De situaties waarin je complexe en strak geschreven code nodig hebt die door echte experts moet worden geschreven en onderhouden zijn tegenwoordig zeer zeldzaam en je werkte blijkbaar niet voor dat soort bedrijven. Wat u beschrijft klinkt meer als “fancy” code die typisch te complex is, vol met esoterische programmeertrucjes en die eeuwen nodig heeft om uit te zoeken en te debuggen. Het is een veel voorkomende tekortkoming voor mensen die klassiek geschoold zijn en ze zijn meestal in voor een onbeleefd ontwaken als ze eenmaal in een productieve omgeving komen.

Het is geen grapje, ik kon er niet tegen om dit een vierde keer te laten gebeuren, het beïnvloedt me mentaal.

Deze lijn is belangrijk, omdat het laat zien dat je het gevoel hebt dat het tijd is om te veranderen. Het laat zien dat je dit herkent als een patroon, en dat je wilt dat het patroon stopt. Die wens is waarschijnlijk het belangrijkste onderdeel van de oplossing. Bij het oplossen van dit soort situaties gaat het vaak om het veranderen van de manier waarop je zelf denkt. Het is onmogelijk voor iemand om dat voor je te doen, dus je verlangen om te veranderen zal het enige zijn dat de verandering laat gebeuren.

Voor sommige achtergrond heb ik al eerder in vergelijkbare “te goed in codering voor mijn werk” situaties gezeten, hoewel nooit in de mate die je beschrijft. Ik zou kanker kunnen genezen met sjabloonmetaprogrammering in C++, maar velen met wie ik werk zijn nauwelijks vertrouwd met de basisprincipes van Object Oriented Design. Ik schreef code die misbruik maakte van SFINAE en die tegen de exacte bewoordingen van de C++ specificaties in ging, toen veel projecten waar ik aan werkte nog steeds verouderde en buggy-versies van gcc gebruikten. Mijn aanpak was gewoon om ze te laten zien hoe geweldig deze tools zijn, en alle problemen die het kon oplossen. Ik vond het heerlijk om kleine programmeertips uit te leggen aan mensen, en ze genoten er grotendeels van.

Klinkt dat bekend?

“Ja, maar men zou een goed niveau moeten hebben om [Mik’s code] te begrijpen omdat componenten intelligent ontkoppeld zijn.”

Beschouw deze uitspraak vanuit een risico-gebaseerd perspectief. Je baas moet de dingen gaande houden, wat er ook gebeurt. Als je weggaat om achter een of andere geweldige baan aan te gaan, moet je baas er nog steeds voor zorgen dat de code wordt onderhouden. Wat je collega net zei was dat, als ze je moeten vervangen, ze noodzakelijk een zeer bekwame codeur moeten vinden, omdat iedereen die niet zo goed is, niet in staat zal zijn om het te onderhouden. Dit is een risico. Wat als ze geen goed genoeg ontwikkelaar kunnen vinden, of ze niet genoeg kunnen betalen?

Je hebt misschien wat je zou noemen “goede code” geproduceerd, maar de definitie van “goede code” is zeer afhankelijk van de context. Wat “goede code” is bij Google, met hun geavanceerde manieren van denken, kan zeer slechte code zijn voor iemand die bij de FAA werkt, en die zich voornamelijk bezighoudt met betrouwbaarheid in plaats van het bijbenen van de geavanceerde technologie. De definitie van “goede code” van je baas omvat de mogelijkheid om deze te onderhouden in allerlei situaties, ook zonder jou. Als uw medewerkers zich niet comfortabel voelen bij het onderhouden van uw code, dan bent u ineens een aansprakelijkheid voor het bedrijf, omdat u producten produceert die zij niet kunnen onderhouden als u besluit elders te gaan werken.

Vanuit dit perspectief kan men beargumenteren dat u hen dwingt uw definitie van “goede code” te accepteren. Instinctief lijkt dit misschien een goede zaak, maar het is moeilijk, zoals deze op risico gebaseerde manier van denken waar je misschien niet aan gedacht hebt.

We hebben een zinsnede, “het paard achter de wagen spannen”. Een van de vele betekenissen die eraan verbonden zijn, is dat je de inhoud die je het meest belangrijk vindt (het kunnen gebruiken van je geavanceerde technieken) over de krachten die het naar voren zouden moeten trekken (het begrip van je collega’s van deze technieken). Je hebt de code in deze geavanceerde stijl geschreven en vervolgens de andere ontwikkelaars aangemoedigd om deze stijl “in te halen”. Dit kan effectief zijn, maar als er iets met je gebeurt voordat ze “inhalen”, loopt het bedrijf plotseling gevaar omdat niemand de code kan onderhouden.

Hoe kan ik dit in de toekomst vermijden?

Dit kan een vreselijk moeilijke zaak zijn omdat het gaat om het benaderen van het probleem op een andere manier dan je normaal gesproken gewend bent. In plaats van eerst code te schrijven in deze geavanceerde stijl, en dan je collega’s te leren hoe ze op die manier moeten denken, zou je het moeten omdraaien. Leer uw collega’s die stijl van coderen leuk te vinden en begin dan met het schrijven van code in die stijl. Het lijkt misschien achterstevoren, maar het is veel stabieler. Vanuit het perspectief van de baas is er weinig tot geen risico dat het team beter leert coderen. Als ze eenmaal beter coderen, is de stijl die je wilt ontwikkelen plotseling minder riskant.

In de tussentijd zul je code moeten schrijven die, naar jouw maatstaven, “minder goed” is, maar dat is oké. Uw code is hier niet uw enige product. Je andere product helpt de andere ontwikkelaars te leren, en de waarde daarvan kan gemakkelijk de waarde van het schrijven van “perfecte code” overstijgen.

Natuurlijk kan het moeilijk zijn om te zien wanneer het veilig is om code te schrijven in de stijl waarin je wilt schrijven. Als het makkelijk te zeggen was, had je het nu zeker al uitgedokterd! Een krachtige techniek die je kunt gebruiken is om anderen te laten pushen voor de geavanceerde codeerstijlen, in plaats van er zelf voor te pushen. Het is één ding om iemand het verschil te leren tussen erfenis en compositie. Het is een heel ander ding om ze goed genoeg te leren dat ze pleiten voor het veranderen van uw bestaande codebase om duidelijker te zijn in wanneer ze gebruikt worden. Het laatste geval laat je echt weten dat ze niet alleen het concept krijgen, maar omhels het echt.

Een ideaal voor het onderwijzen van zulke concepten is om niets te leren. Laat de leerlingen iets ontdekken, en dan wijs je ze een richting aan die ontdekking kan gaan. Misschien ontdekt een van hen wel iets netjes over overerving en kun je hen wijzen in de richting van het Visitor design patroon op basis van wat ze ontdekt hebben. Geef ze niet alleen Visitor, maar geef ze ook een gevoel van richting, zodat ze zelf op zoek kunnen gaan naar Visitor.

Het is een veel moeilijkere aanpak, en je zult zeker een gelukkig medium willen vinden tussen dat en je huidige aanpak, maar het kan zeer de moeite waard zijn. Nog belangrijker voor je antwoord is dat het waarde kan bieden aan het bedrijf zonder het risico te lopen. Als u waarde levert aan een bedrijf, en het bedrijf niet in gevaar brengt, dan wordt u vrijwel altijd ontslagen. En in de weinige gevallen waarin u nog ontslagen kunt worden, zal het management daar een reden voor geven (zoals een terugval in de economie, of een verschuiving in de richting van het bedrijf). Als u het heel goed doet, zult u merken dat het management in plaats daarvan uw pad gaat bepalen, net zoals u uw collega’s vormgeeft, en u zult een merkwaardige neiging vinden om gewoon de juiste vaardigheid gewoon te hebben geleerd wanneer ze die het hardst nodig hebben.

Er zijn altijd redenen.

Een vorige werkgever deed dit met een collega van mij. Zijn vaardigheidsgraad was veel hoger dan die van ons. Dus, hij werd losgelaten.

Waarom heeft dit zin?

1. Hij was de enige die zijn code 2 kon behouden. Hij was niet collaboratief
2. Hij hield zich niet aan de winkelnormen
3. Terwijl hij meer leverde dan nodig was, was dit geen goede zaak
4. Eenvoudig, er waren oplossingen nodig in plaats van complexe.

Er wordt zo vaak gezegd dat het bijna een cliché is, maar je moet een “good fit” zijn voor het team.

Codering is slechts een deel van de vergelijking. Je moet persoonlijk zijn, communicatief, tot op zekere hoogte nederig, arrogant wanneer dat nodig is, je moet je aan de winkelnormen houden, met je collega’s kunnen opschieten, benaderbaar zijn en snel helpen wanneer dat nodig is.

Al deze soft skills zijn belangrijk, en niet het hebben ervan zal problemen voor je opleveren.

Goede code is gemakkelijk te begrijpen, zelfs voor arme ingenieurs. Een advies dat ik vaak kreeg is “programma als of de persoon die je code zal onderhouden een middelmatige programmeur is, en een gevaarlijke psychopaat die weet waar je woont”.

En het is waar. Te slim programmeren is slecht, want het onderhoud is langer als je de code niet kent. Bij onderhoud heb je vaak overal brand, duizenden klanten geblokkeerd, en een slimmere en efficiëntere oplossing houdt de onderhouder misschien wel langer vast dan een domme scriptachtige code vol met herhalingen.

Natuurlijk is totaal domme code ook slecht. Er is een goede balans te vinden tussen dom en geniaal: efficiënt, en toch leesbaar. Het is meer een kunst dan een wetenschap. Daarom worden slimme concepten als meervoudige erfenis worden meestal niet geadviseerd . Zelfs als ze rocken.

Je moet rekening houden met de context. Als je in een klein randfirma werkt die alleen de beste mensen inhuurt, kun je je waarschijnlijk wat exotische, briljante dingen veroorloven. Als je werkt voor een Franse bank die alleen maar vertrouwt op consultants van, soms met geluk, soms niet, en waar elke consultant een domein van miljoenen LOC’s te onderhouden heeft, dan maak je het op het eerste gezicht eenvoudig genoeg voor een middelmatig iemand om het te begrijpen. Geen aanwijzingen, geen meervoudige erfenis, geen slimme trucjes, etc…

Het is onwaarschijnlijk dat je ontslagen wordt omdat je te goed bent. Ik denk dat dat gewoon een excuus is.

Het is veel waarschijnlijker dat het een gedragsprobleem is, of de baas houdt gewoon niet van je om redenen die hij je niet kan vertellen zonder een reden voor een rechtszaak te creëren. Het is ook mogelijk dat je de duurste bent en ze geloven in FTE’s (d.w.z. elke werknemer is hetzelfde).

Als je echt zo goed bent, kun je jezelf op een goede manier onmisbaar maken:

• Mentor de junior programmeurs. Vertel de voor- en nadelen van verschillende benaderingen en laat ze hun fouten maken in plaats van ze te vertellen welke aanpak ze moeten volgen.
• Schrijf goede code die gemakkelijk te onderhouden is door andere mensen.
• Bevorder best practices op manieren die de productiviteit verhogen, in tegenstelling tot cargo cult best practices, die goed klinken op papier, maar de productiviteit doden.

Het ontslaan van onmisbare mensen is eigenlijk een goede managementstrategie. Wanneer uw bedrijf erop vertrouwt dat één persoon zijn werk blijft doen en niemand anders in het bedrijf zijn kennis en/of kunde heeft, creëert dit een enorme aansprakelijkheid: wat als die persoon door een bus wordt geraakt en overlijdt (vandaar de term ‘busfactor’) of er gewoon voor kiest om het bedrijf te verlaten voor een nieuwe uitdaging? Nu zit uw bedrijf vast in een verschrikkelijke situatie omdat niemand de onmisbare werknemer onmiddellijk kan vervangen en u geen controle had over de timing!

Om deze situatie te voorkomen, heeft het bedrijf twee opties. Of ze kunnen proberen de kennis te verspreiden en/of het vermogen van de onmisbare medewerker te vergroten, of ze kunnen in één keer de pleister weghalen door de onmisbare medewerker te ontslaan op een moment dat ze deze kiezen en herstellen van het verlies van die medewerker als ze voorbereid zijn op dat proces.

Aangezien het niet altijd praktisch is om een groot gat in kennis en vooral in vermogen te dichten, kan ontslaan de meest logische keuze zijn.

Als medewerker moet u altijd proberen _voorkomen dat hij/zij onmisbaar wordt. Deel je kennis met je collega’s en zorg ervoor dat er mensen zijn die je werk kunnen doen als je er niet bent. Zorg ervoor dat je praktijken geschikt zijn voor de werknemers met het gemiddelde vaardigheidsniveau in je bedrijf. Als u vindt dat het gemiddelde niveau te laag is, werk dan samen met het management om te proberen dat niveau te verhogen. Zorg ervoor dat alles wat je creëert goed gedocumenteerd is en dat deze documentatie van een hoog genoeg niveau is dat een van je collega’s het kan gebruiken om je werk voort te zetten.

Als het enige wat de drie situaties met elkaar gemeen hebben, dan moet je er rekening mee houden dat iets wat je doet een probleem is.

Heb je met je voormalige collega’s gepraat en hen gevraagd om je te bekritiseren? Niet je code, maar je gedrag op kantoor. De manier waarop je communiceert met je collega’s, de manier waarop je communiceert met je baas, de manier waarop je documentatie doet, hoe je je gedraagt in vergaderingen, etc.

Heb je jezelf in de positie van je leidinggevende geplaatst? Heb je echt nagedacht over wat ze moeten doen, wat hun verantwoordelijkheden zijn, wat hen een goed gevoel geeft als ze het kantoorlicht uitdoen en naar huis gaan? Er zijn vele, vele voorbeelden waar iemand geweldige code schrijft _ vanuit het perspectief van andere software engineers_, maar het bedrijf faalt.

Ik heb naar je profiel gekeken, er staat “je code moet schoner zijn dan jezelf”. Ook uit uw opmerkingen dat u “veel tijd besteedde aan het uitleggen van concepten”, en “kritiek is onderdeel van mijn werk als ingenieur”… Ik denk dat je graag advies geeft en je advies wordt gewoon niet gewaardeerd door je teamgenoten.

Dit kan te wijten zijn aan wat je zegt, of de manier waarop je het zegt, waarschijnlijk een aantal van beide.

Het schrijven van productieve en onderhoudbare code zal er niet toe leiden dat je ontslagen wordt. Je zult ontslagen worden als je niet kunt opschieten met het team. Dit is jouw probleem, niet (zoals je je voorstelt) je code is te goed. Je code is misschien wel heel goed - maar het is waarschijnlijker dat dit een persoonlijkheidsconflict is.

Mijn advies aan jou, is niet de staart die de hond probeert te kwispelen. Houd je hoofd naar beneden, stop met mensen te vertellen hoe ze moeten coderen, volg de richting, werk goed samen met anderen, schrijf onderhoudswaardige code. En dan word je niet ontslagen.

Ik neem ook met belangstelling kennis van deze veelzeggende opmerking van je manager:

“Maar is het echt goed zoals hij doet alsof?”

Wat dit je vertelt is dat je manager je niet vertrouwt, je manager denkt dat je niet authentiek bent en denkt dat je arrogant bent en/of een hoger aanzien hebt voor je eigen kunnen dan je eigenlijk hebt. Relaties zijn afhankelijk van vertrouwen om te overleven. Let op: uw probleem is niet een technisch probleem. Je probleem heeft weinig te maken met de kwaliteit van je code. Wat je hebt is een probleem met de manier waarop je omgaat met je collega’s en je manager.

Mensen worden niet vaak ontslagen omdat ze onmisbaar zijn waarom mensen worden ontslagen ); Dat is een belachelijke bewering. Het artikel waarnaar je verwijst kwalificeert duidelijk dat “brand” niet noodzakelijkerwijs betekent dat je ze laat gaan, maar dat je ze niet onmisbaar maakt (door ze te verplaatsen, ze te dwingen niet betrokken te zijn bij een bepaald project, etc…)

Terwijl overgekwalificeerde mensen je soms niet in dienst krijgen - het zorgt er ook zelden voor dat je ontslagen wordt. Goede medewerkers zijn erg moeilijk te vinden; geen enkel redelijk bedrijf gaat er vandoor omdat ze te goed zijn (tenzij je gewoon voor een idioot werkt - dan doen ze je een plezier).

Mensen worden wel ontslagen omdat ze denken dat ze onmisbaar zijn en beter zijn dan hun collega’s en daarom weigeren ze de veranderingen te maken die moeten worden aangebracht aan de man in de spiegel om goed te kunnen functioneren in een team. Als je een brug bouwt met een stel inboorlingen en een laptop uittrekt terwijl de rest het touw vastbindt, ben je misschien slimmer of beter opgeleid, maar je bent een nadeel voor het team geworden en het probleem is JIJ.

Als je echt zo goed bent als je je voordoet, zou je slim genoeg zijn om je eigen acties aan te passen om het meest productieve TEAM mogelijk te maken vs. dogmatisch je eigen agenda te duwen (wat je waarschijnlijk aan het doen bent). Als je dat zou doen, zou je waarschijnlijk een baan hebben voor een zeer lange tijd.

Als iemand die regelmatig betrokken is bij het aannameproces, neem ik iemand die goed en persoonlijk is over iemand die geweldig is en een potentiële kanker heeft elke dag.

Elk programma is een communicatie met twee doelgroepen: een compiler of een tolk die het zal uitvoeren, en sommige mensen die het gelezen en begrepen hebben. Het kan zijn dat je extreem goed communiceert met de compiler, en nog steeds slechte code schrijft omdat het niet gemakkelijk te begrijpen is voor de andere betrokken mensen.

Typisch voor een programmeerteam is dat het een set van talen, frameworks, technieken etc. heeft die bekend zijn bij iedereen in het team. Nieuwe medewerkers die een aantal van die stukken missen, nemen ze snel op omdat iedereen in het team ze kan uitleggen.

Het gebruik van iets buiten die set brengt kosten met zich mee voor de werkgever. Bijvoorbeeld, stel dat je de enige programmeur in de groep bent die bekend is met raamwerk X, en iedereen is bekend met een ouder raamwerk Y dat gebruikt wordt voor sommige bestaande code en bijna net zo goed is als X.

Het gebruik van raamwerk X zou een vergissing zijn, tenzij het zo veel beter is dan Y dat het management het ermee eens is dat de technische voordelen van het gebruik ervan voldoende zijn om de trainingsinspanning te rechtvaardigen om iedereen vertrouwd te maken met X.

Een techniek die je zou kunnen gebruiken is om je code te laten beoordelen door enkele van de minst ervaren mensen die het moeten kunnen lezen. Kijk wat ze te vragen hebben, en bedenk hoe je die stukken zou kunnen herschrijven om ze duidelijker te maken. Hoe meer u het niet begrijpen van uw code behandelt als een defect in de code, niet in de lezers, hoe beter de feedback die u krijgt.

Mijn lezing hierover is dat je bestemd was voor deze behandeling vanaf de eerste dag op het werk. Je zei dat je werd ingehuurd omdat je vaardigheden hebt die niemand anders in de organisatie heeft (TypeScript, Node). En nu je hebt gezwoegd om een elegante, vakkundige, complexe oplossing allemaal alleen te produceren, begrijpt niemand wat je hebt gedaan, en daarom wordt je door het management gezien als een aansprakelijkheid.

Als dit alles waar is, dan is er echt geen andere manier waarop dit had kunnen uitpakken.

In mijn ogen is het probleem structureel, niet persoonlijk, en daarom ligt de schuld bij de situatie en het proces, niet bij de persoon:

• De organisatie heeft een enkele persoon ingehuurd met een compleet andere vaardigheden dan ieder ander, en op een geavanceerd niveau van die vaardigheden, om een kritische functie uit te voeren. Dit garandeert dat, als je goed presteert, je de enige bent die code begrijpt die cruciaal is voor de missie van de organisatie. (Het is volstrekt onredelijk om te verwachten dat een senior-level resource code produceert die direct zinvol is voor mensen die de gebruikte taal niet kennen.)
• De organisatie heeft je niet regelmatig onderworpen aan het code review proces. Als dat wel het geval was, zou uw code zijn afgewezen totdat u deze in overeenstemming met hun leesbaarheidsstandaarden had gebracht. Aangezien u de enige bijdrager bent aan de code, met uw eigen stijl en met behulp van een andere tech-stack, is het vrijwel zeker dat de code na verloop van tijd steeds minder begrijpelijk zal worden voor anderen. De enige manier voor u om dit te voorkomen zou zijn om anderen te vragen de code buiten het proces om te beoordelen, voortdurend, mogelijk met beschuldigingen van het verspillen van de tijd van anderen. Een gebrek aan code review proces zet je dus op een mislukking.

Ik heb soortgelijke ervaringen op mijn achtergrond. Ik ben ooit ingehuurd om een vaardigheidsgat op te vullen. Niemand anders in het bedrijf had een vaardigheid die ze ineens nodig hadden. Ik deed mijn werk goed en na een paar maanden begon het conflict. Ik was de enige die met bepaalde onderdelen van de applicatie kon werken. Ik werd een knelpunt toen het werk zich opstapelde dat alleen ik kon doen. Op een dag werd ik buitenspel gezet toen het bedrijf besloot om alles wat ik had geproduceerd te vervangen door compleet nieuwe code, op hun manier gedaan. Mijn trots was toen gekwetst, maar achteraf gezien was het de juiste beslissing voor het bedrijf. Na een tijdje was het tijd voor mij om verder te gaan, en dat heb ik gedaan.

Als dit bekend klinkt, is het misschien tijd voor jou om verder te gaan. Misschien dat het management je zelfs opnieuw aan iets anders toewijst als ze je vaardigheden blijven waarderen. Of als je het kunt verdragen, kun je misschien helpen met het herschrijven van alles wat je hebt gedaan in de standaard technologiestapel van het bedrijf. Als dat niet mogelijk is, ga dan gewoon weg. Hoe dan ook, uw code is waarschijnlijk op weg naar de vuilnisbak. Dat is waarschijnlijk het juiste ding voor hen om te doen, als niemand anders het begrijpt. En hoe dan ook, het is het natuurlijke gevolg van hun keuzes.

Zorg ervoor dat in je volgende baan, anderen in je team in principe dezelfde vaardigheden toepassen als jij, en vooral dat ze een code review proces hebben. Als ze je vragen om je code op bepaalde manieren te veranderen, doe het dan. Overweeg geen code die wordt geleverd totdat deze door de codebeoordeling is gekomen en je collega’s het management (indien gevraagd) zullen vertellen, ja, de code is goed. Dan is er geen probleem. Het is perfect OK om vragen te stellen over dit soort zaken in een technisch interview; dat heb ik al zo vaak gedaan. Hopelijk geeft deze andere ontwikkelaar die je code heeft bestudeerd je een goede referentie.

Als voetnoot, als je tenminste gedeeltelijk verantwoordelijk bent voor je omstandigheden om helemaal alleen te werken, zonder buy-in van andere teamleden, dan verdien je op zijn minst ook een deel van de verantwoordelijkheid voor het resultaat. (Heb je aangedrongen op het gebruik van TypeScript / Node wanneer anderen iets anders wilden gebruiken? Heb je de nieuwste, coolste bibliotheek of techniek gebruikt, ook al zou iets meer basaals het prima hebben gedaan? Ik heb me hier ook een of twee keer schuldig aan gemaakt). Als dat zo is, zorg er dan voor dat je een lesje leert uit dit resultaat. Maar zo niet, neem dan deze ervaring mee naar je volgende positie met je hoofd hoog.

Het merendeel van de antwoorden behandelde uw post vanuit het oogpunt van de vraag of uw code al dan niet leesbaar was of zo goed als u zegt dat het is. Maar deze situatie kan in alle lagen van de bevolking voorkomen. Ik nam een baan op de Las Vegas Strip als een 21-dealer en floorman. Mijn technieken en snelheid waren zo ver vooruit op de rest van hun personeel dat de mensen die mij toegewezen waren om op te letten mij niet konden bijbenen. Met andere woorden, ze konden mijn beslissingen niet volgen. Omdat grote hoeveelheden geld binnen enkele minuten werden afgehandeld, voelden ze zich vaak verward en meldden ze me aan hun superieur met de bewering dat ik een fout had gemaakt. Ik zou mijn acties altijd aan die persoon verantwoorden maar de houding van wantrouwen ten opzichte van mij verdiepte zich.

Mijn ego en ik vermoeden dat het jouwe de waarschuwingstekens niet zag en ik zwelgde inderdaad in mijn superioriteit en stortte het als het ware in. Ik werd beëindigd en verloor een extreem goede betalende positie.

De les is eenvoudig, je moet dummy tot op het niveau van de anderen. Als ze maar 15 handen per uur krijgen en je krijgt er 100 uit, dan ben je niet inspirerend genoeg. Je inspireert jaloezie en zelfs haat. Als je trots dit niet kan doen, moet je een andere manier vinden om de kost te verdienen, want alle plaatsen zijn in wezen hetzelfde. Mensen zijn mensen, je kunt ze niet veranderen. Ik heb me uiteindelijk ook in andere werkvormen gevestigd waar ik middelmatig was en dus niet opviel. Ik hoop dat je dit in je voordeel kunt oplossen.

Besloten om mijn commentaar te upgraden naar een antwoord:

Documenteer je code zeer goed.

Juiste code documentatie zet slechte ervaringen waarbij een junior zijn hoofd urenlang tegen een onbegrijpelijke muur slaat om in potentiële leerervaringen.

Het is mogelijk dat u gewoonweg niet zo goed bent als u denkt dat u bent, maar uit beleefdheidsoogpunt ga ik ervan uit dat u weet hoe u de juiste hoeveelheid complexe code kunt schrijven om de complexiteit en de tijdsvereisten van de hele codebase te verminderen met een orde van grootte. Het feit dat dit zelfs mogelijk is, verbaast veel idioten. Ze vinden het een ongelovige stelling, en de enige manier om ze te overtuigen is ze te laten zien.

Maar daar is finesse, moed en zelfbeheersing voor nodig. Je moet je op drie dingen concentreren voor alle anderen: bewijzen dat je geen bedreiging bent, de idioten er slim uit laten zien, en nooit één enkele idioot laten beseffen dat hij een idioot is. Als je jezelf er niet toe kan brengen deze drie dingen te doen, zal je falen, en zal het jouw schuld zijn. Pragmatisme is een must, en er is geen ruimte voor trots.

Hoewel ik deze aanpak niet voor iedereen kan aanbevelen, is wat voor mij altijd heeft gewerkt, het soms negeren van wat vijandige idioten me zeggen te doen. In plaats daarvan vind ik manieren om te doen wat ik wil doen, de beste software te produceren waar velen van hen ooit de code voor hebben gezien in een zeer korte tijd, en ik presenteer het op zo'n manier dat hun bazen hen belonen met gloeiende lof. Ook al hebben ze geen rol gespeeld bij het maken ervan. Zelfs als ze zich er actief tegen verzetten.

Klopt het? Moet ik niet de volledige eer krijgen voor mijn werk? Moet ik echt om ieders gevoelens heen dansen? Niet relevant. Dit is de realiteit. Als ik me er niet aan pas, dan ben ik de idioot.

Er zijn veel slimme mensen die denken dat hoogopgeleide ontwikkelaars onvervangbaar zijn en dat is waarom u do ze wilt. Maar je hebt de andere antwoorden op je vraag gezien - de meeste managers willen niet omgaan met de problemen van een team met zeer uiteenlopende vaardigheidsniveaus, en hebben niet de optie om puur hooggekwalificeerd te gaan. Ze hebben ook niet noodzakelijkerwijs ongelijk, de problemen zijn echt, en de voordelen van hoge kwaliteitscode die buiten de mogelijkheden valt van de meeste mensen die ze in dienst kunnen nemen, zijn sterk verminderd.

Als je zelfs ruwweg zo goed bent als je zegt dat je bent, dan ben je mismatch met je baan. Het klinkt alsof je hard moet proberen te werken op een plek waar je kunt leren van je collega’s en je collega’s je code kunnen begrijpen.

Als je hierdoor een paar banen bent kwijtgeraakt dan ga je er vrij slecht uitzien voor HR, recruiters en managers. Hopelijk kun je netwerken in een baan door ontwikkelaars met een vergelijkbaar vaardigheidsniveau te ontmoeten die kunnen garanderen dat het probleem echt is dat je vaardigheidsniveau te hoog is.

Tot slot moet ik toevoegen dat je je best moet doen om eerlijk te evalueren of je vaardigheidsniveau echt zo hoog is. Het klinkt alsof er bewijs is dat het zo is, maar de meeste mensen geloven dat ze beter zijn dan ze zijn. Ook gaan veel ontwikkelaars door een fase waarin ze erg goed zijn in één aanpak, maar nog niet altijd alles samenvoegen tot een globaal optimale oplossing, en nog steeds geen flexibiliteit hebben. Soms is het bijvoorbeeld het beste om te gaan met een inferieure oplossing die je weet dat de mensen die je hebt kunnen onderhouden, als je weet dat ze niet een meer geavanceerde oplossing kunnen managen, en het is niet waarschijnlijk dat ze iemand anders in dienst nemen die dat wel kan.

Om specifiek op de vraag in te gaan,

Hoe kan ik dit in de toekomst vermijden?

• Zoek een lokaal hoofdstuk van Toastmasters, neem actief deel, en verdien de prestaties. Iets wat zo vanzelfsprekend lijkt als feedback, wordt hopelijk gewaardeerd en aangescherpt tot een van je meest gewaardeerde vaardigheden.

• Oefenen als de student in plaats van de expert. Heb je deze Jon Skeet talk on the basics gezien? Kun je je voorstellen hoe veel meer begrip kan worden bereikt als we allemaal zo'n documentatie maken, het zou iedereen ten goede komen, op alle niveaus van een team!

• Een team is niet één individu. Je team zal groeien en collectief verbeteren. U moet helpen. Het is geen team als elk lid een cel is die in verschillende richtingen gaat (bijvoorbeeld, je bent hoger, en het nieuwste lid stagneert). 2 uur durende vergaderingen is een goed begin. Ik zou daar nog aan toevoegen, de N-dagelijkse roulatie. Dit is 1:1 keer dat je gift aan je teamgenoten en ze gift aan jou. In uw geval, leun naar de navigator rol, en laat uw partner rijden. Oefen het niet schrijven van de code, hoe raar dat ook klinkt.

• Vrijwilliger bij een lokale Meetup en Hack-a-thons. Het kan je dwingen om je code te distilleren omdat het doel is om samen te werken, en niet om een fouttolerant energienet op te bouwen, toch?

• Probeer in elk van deze oefeningen dit concept: leiderschap door te dienen. Hoe kun je een taak uitvoeren of iets bereiken om de behoeften van een ander teamlid te helpen?

• Zoals aangegeven, bijdragen aan open source projecten om meer invalshoeken te krijgen over je code. Ze kunnen bevestigen dat je briljant bent, maar ze kunnen ook de suggesties versterken die je van je huidige baas hoort. In het beste geval geeft een recensie je een nieuw idee.

• Zoek een ingenieur die beter is dan jij. Het is niet beter om de slimste man in de kamer te zijn. Er is een citaat (mijn googling is verdeeld tussen Olgivy/Ford/Sorkin) dat gaat als “Je kunt niet meer leren als je jezelf omringt met slecht talent”.

Ik ga ervan uit dat uw beschrijving van de situatie is zoals u zegt dat het is. Ik kan niet zeggen dat ik deze exacte ervaring heb gehad, maar er zijn aspecten die me bekend zijn.

Je zegt dat dit een ‘groot’ bedrijf is. Ik weet niet hoe het in Frankrijk is, maar vaak stellen grotere bedrijven interne ontwikkelaarsvaardigheden niet op prijs, zeker niet als het geen technologiegerichte bedrijven zijn. Ik schrijf dit vooral toe aan het feit dat managers in dergelijke bedrijven vaak niet van technische achtergronden zijn of van ontwikkeling afstappen omdat ze er nooit zo goed in waren.

Er is ook een historisch aspect van verkopers die tools verkopen die de behoefte aan getalenteerde ontwikkelaars moeten wegnemen. Zelfs als uw team geen gebruik maakt van een van deze vreselijke dingen, is er een kans dat het management van het bedrijf is geïndoctrineerd in een anti-intellectuele notie van ontwikkelingsteams. Ik heb eigenlijk een manager mij laten vertellen dat ik slim genoeg was om een bepaalde oplossing te bouwen, maar dan zou niemand anders in staat zijn om het te onderhouden, dus we moesten iets kopen (shelfware.) Dus ik geloof dat dit kan gebeuren.

Je moet misschien op zoek gaan naar een ander soort bedrijf. Een bedrijf dat waarde hecht aan hooggekwalificeerde ontwikkelaars. Maar misschien heb je wel te maken met het feit dat je niet de beste ontwikkelaar bent. Als je een aspirant-chef zou zijn, zou je waarschijnlijk ongelukkig zijn om bij McDonald’s te werken. Ze hebben geen koks nodig. Ze hebben mensen nodig om een recept te volgen. Je mag dan wel chef materiaal zijn en dit bedrijf (en anderen vinden het leuk) is McDonald’s. De vraag die je jezelf moet stellen is waarom je dit nog niet gedaan hebt.

Hoe kan ik dit in de toekomst vermijden?

Werk met niemand tenzij je er redelijk zeker van bent dat hun codering standaard overeenkomt met de jouwe. Wat betekent dat je elke baan weigert als niet van het volgende van toepassing is:

• Ze stellen je programmeervragen tijdens hun interviewproces
• Ze hebben peer-programmeeroefeningen
• Ze vragen om een codevoorbeeld en zijn er oké mee
• Je kunt een deel van de code zien die ze hebben geproduceerd

Hoe kan ik dit in het heden vermijden?

Dit is behandeld in andere antwoorden.

Als je net dat beter bent, ga dan naar hun niveau en leer ze langzaam aan om betere programmeurs te worden. De eerste keer dat ik een stagiair moest managen heb ik bijna de hele code die hij produceerde weggevaagd. Ik was letterlijk woedend toen ik zag wat er werd vastgelegd (gelukkig had ik geen getuige :P ).

Je moet peer programming, code reviews aanmoedigen. Ga met een andere programmeur zitten en probeer 2 of 3 uur lang samen te coderen. Laat concepten vallen die misschien te moeilijk uit te leggen zijn (nieuwe geavanceerde Java 8 functies bijvoorbeeld), en leg die uit die makkelijker zijn (overerving).

Soms, als je met anderen praat, moet je het “dom” maken, zodat je de mensen niet beledigt. Vooral als je ver boven de anderen staat waarmee je werkt, zijn ze waarschijnlijk beledigd als je praat over tips en feiten die ze waarschijnlijk wel zouden moeten weten, maar niet.

Ik zou zeggen om je werk heel goed te becommentariëren, zodat mensen die het controleren het kunnen begrijpen. Misschien moet je zelfs “verantwoorden” waarom je die coderingsmethode kiest boven een andere in je commentaar. Je bent misschien wel de beste codeur, maar als je in een team zit, moet je als een team werken.

Als werken als een team betekent dat je met één hand achter je rug werkt, (hiermee bedoel ik het volgen van hun codeervoorkeur), doe het dan. Dan kunnen ze het tenminste lezen, begrijpen, en is het team zelf beter af (zelfs als dat betekent dat je binnenin schreeuwt).

Bijna overal waar je gaat waar je deel uitmaakt van een team, heb je richtlijnen over hoe ze willen dat er gecodeerd wordt - en je moet deze richtlijnen volgen.

We kunnen niet op hem rekenen in een lange termijn

Dat is het grote probleem. Ze willen niet afhankelijk zijn van jou, maar je bent aangenomen omdat ze eigenlijk afhankelijk zijn van jou.

Je kunt het management tot rust brengen met:

• Je denkt er toch niet aan om ergens anders heen te gaan, zodat ze op lange termijn op je kunnen rekenen.

Ik denk dat ik uitgedaagd word met problemen die mijn vaardigheid gebruikt houdt, dus ik denk dat ik eindelijk een werkplek vind waar ik lang van kan genieten

• Je bent bereid om training te geven aan andere teamleden om het team verdere waarde te geven.

Ik heb gemerkt dat andermans code niet echt up-to-date is met de nieuwste software ontwikkelingstecnieken, het is geen probleem, ik kan helemaal stoppen met het gebruik van die tecnieken, maar het zou goed zijn als iedereen die tecnieken geleidelijk aan gaat gebruiken om de prestaties van het team te verbeteren. Ik kan daarmee helpen.

• Je werd gevraagd om functies XY te implementeren, havin dat functies verzonden binnen de tijd die nodig is uw vaardigheid, dingen hadden kunnen worden gedaan op verschillende manieren, maar in veel meer tijd en met het risico van extra bugs.

Mag ik wat extra tijd om volgende functies af te ronden? Ik heb echt hard gewerkt om dingen goed gedaan te krijgen, ik heb dat bereikt, maar ik ben bang dat niet iedereen dat kan begrijpen, in plaats daarvan wil ik wat tijd nemen om dingen begrijpelijk te maken voor anderen.

Wees eerlijk, als een of andere verklaring niet van toepassing is (ik doe nu niet aan wat je hebt gewerkt), lieg dan niet, ooit.

Als ze je gaan ontslaan, dan zijn ze niet echt afhankelijk van je voor het echt. Hoe dan ook, ten minste 2 mensen in het team begrijpen je werk: Jij en je collega. En de kans is groot dat meer mensen het in de toekomst zullen begrijpen. In principe ben je geen bottleneck in je team, ze zijn bang dat je het later wel kunt worden. Ze zouden sowieso wat tijd moeten investeren in training.

Lees * The Wagon, the Blackbird, and the Saab **. Ik heb in het verleden soortgelijke problemen gehad; ik heb wat dingen geleerd over hoe je moet omgaan, maar we hebben allebei mop en emmer gebruikt om te proberen de uitgang van een brandslang op te ruimen.

Ik suggereer hier niet dat je een DSM-V mentale gezondheidsdiagnose verdient, maar ik suggereer wel dat je een goede counselor moet vinden en moet werken aan niet-bedreigend gedrag en sociale vaardigheden. Je zou ook kunnen lezen * Theorie van buitenaardse geesten **.