Vraag:
Ontslagen omdat uw vaardigheden te ver boven uw collega's uitstijgen
Mik378
2016-11-18 20:19:22 UTC
view on stackexchange narkive permalink

Ik werk nu vijf maanden voor een groot Frans bedrijf dat geweldige dingen bouwt, een goed product met trendmethodologieën.

Ik heb net geleerd van een interne collega (technisch expert) dat ik waarschijnlijk laten gaan omdat er een te grote kloof is tussen mij en andere ontwikkelaars in termen van programmeerkennis / praktijk.

Hij onthult me ​​dat de teammanager hem vaak vroeg:

"Is de code van Mik gemakkelijk leesbaar en begrijpelijk?"

Hij antwoordde:

"Ja, maar je moet een goed niveau hebben om te begrijpen omdat componenten intelligent zijn ontkoppeld. "

Reactie teammanager:

" Maar is het echt goed zoals hij doet alsof? "

Hij antwoordde:

"Met vriendelijke groet, Ja, ik las vroeger zijn code om TypeScript / Node.js thuis te leren."

Reactie teammanager:

"Maar het is echt een probleem als het team zijn code niet begrijpt ... zelfs als de thee m heeft minder kennis. We kunnen op de lange termijn niet op hem vertrouwen ".

Ik ben van streek.

Ik twijfelde aan deze reden, maar ik vond dit artikel.

Het is de derde keer dat ik deze situatie tegenkom; wanneer je echt goede code produceert, en je wordt ontslagen zonder enige reden.

Het is geen grap , Ik kon het niet uitstaan ​​om dit een vierde keer te laten gebeuren, en het heeft mentale gevolgen voor mij.

Hoe kan ik dit in de toekomst vermijden?

Arrogant zijn is niet mijn aard. Ik deel graag mijn kennis.

Update

Veel antwoorden gaan over het feit dat ik zou moeten proberen voor het team te werken, en niet alleen voor mij.

Ik wijs er alleen op dat er niet van mij werd verwacht dat ik met het team zou werken.

In mijn contract moest ik ALLEEN werken om alleen complete software te bouwen, met mijn eigen programmeerprincipes.

Ik ben aangeworven OMDAT het team helemaal geen vaardigheden heeft op de veeleisende gebieden.

Het team bekeek de code (uit nieuwsgierigheid) één dag gedurende niet meer dan 5 minuten, en sprak direct met mijn manager.

Echt 5 minuten, voor ongeveer 10.000 regels code na 4 maanden werk.

Ja, de bedrijven waren vergelijkbaar in de zin dat er van mij werd verwacht dat ik het vaardigheidsniveau zou verminderen om bij mijn team te passen en dat wil ik absoluut niet. Ik geniet van het IT-veld omdat het een uitdaging is voor de hersenen. Ik heb uitdagingen nodig.

Drie keer zijn genoeg om te bevestigen dat ik me veel beter voel bij gepassioneerde mensen die me uitdagen dan standaardmedewerkers die niet verwachten zichzelf te verbeteren. Ik merk gewoon dat hun manier van doen niet succesvol is, dus waarom zou ik van gedachten veranderen om bij die van hen te passen, om trouwens niet succesvol te zijn? Die typische grote bedrijven waarvan de IT niet de belangrijkste reden van bestaan ​​is, zijn niets voor mij.

Opmerkingen zijn niet voor uitgebreide discussie;dit gesprek is [verplaatst naar chat] (http://chat.stackexchange.com/rooms/48767/discussion-on-question-by-mik378-fired-because-your-skills-are-too-far-above-u).
Nadat de reacties waren verplaatst naar de chat, werden er * 33 extra reacties * geplaatst.Die kunnen niet automatisch aan de chatroom worden toegevoegd en de uitgebreide discussie in die commentaren hoort hier zeker niet thuis, dus zijn ze nu weg.Als je dit bericht wilt bespreken, gebruik dan de chatroom.Reacties zijn bedoeld om opheldering te vragen of verbeteringen aan de post voor te stellen, niet om ... te chatten.
Met betrekking tot de update zei u dat dit meerdere keren is gebeurd.Maar je zei ook dat je werd gerekruteerd omdat het team geen vaardigheden in het veld had.Is dat de andere keren gebeurd?Of alleen de meest recente?
Kun je bijvoorbeeld 20-30 regels posten?En wat is de programmeertaal?
Hallo @RobertHarvey,, in tegenstelling tot Stack Overflow, kunnen opmerkingen op Workplace SE gemakkelijk leiden tot uitgebreide discussies en heen en weer, iets wat we willen ontmoedigen op een Q & A-site.Om de uitgebreide discussie te onderdrukken, verplaatsen we ze meestal om te chatten en moedigen we mensen aan om iets waardevols als antwoord te posten.Wanneer materiaal als antwoord wordt gepost, kan erop worden gestemd, door zoekmachines worden gezocht en kan het worden gerangschikt op basis van stemmen.Zie de post van Robert Cartaino, [Wat "commentaren" niet ...] (http://meta.workplace.stackexchange.com/q/72/98), voor meer details.Ik hoop dat dit helpt.
Het kan handig zijn om het land te taggen waarin u * werkt *. U merkt op dat u voor een Frans bedrijf werkt, maar bent u * in * Frankrijk of werkt u in het buitenland?
Is er een reden waarom u niet werkt in een omgeving die geavanceerde technologie promoot?De academische wereld zou bijvoorbeeld iemand kunnen gebruiken die nieuwe geavanceerde technologieën en praktijken uitprobeert, maar in een zakelijke omgeving is dit vaak nadelig, en daarom wordt u ontslagen.
@Mik378 als er informatie is waarvan u wilt dat mensen deze weten, [bewerk] deze dan in uw vraag.Zet het niet in opmerkingen.
Je moet deze man vinden: http://workplace.stackexchange.com/questions/22559/how-to-deal-with-a-manager-who-believes-the-more-difficult-solution-is-always-th
Mogelijk duplicaat van [Hoe ga ik om met huurreserveringen wanneer cv wordt beïnvloed door IQ-discriminatie?] (Http://workplace.stackexchange.com/questions/13593/how-do-i-deal-with-hiring-reservations-when-hervatten-wordt-beïnvloed door-iq-discriminat)
Er worden zoveel aannames gedaan in de antwoorden op uw vraag, het is enigszins lachwekkend.Cort heeft een goed antwoord dat dingen uitlegt vanuit het oogpunt van de manager.Maar ik vermoed dat je een ander soort bedrijf moet vinden om voor te werken.Ik heb voor organisaties gewerkt als een in-house "enterprise" ontwikkelaar, en voor productproducerende bedrijven waar goede "engineering" echt was.Er lijkt een * enorme * vaardigheidskloof te zijn tussen de soorten ontwikkelaars die in beide soorten van deze bedrijven werken, en ik vermoed dat je het in de laatste veel beter zou doen.
Elke update van jou?
23 antwoorden:
#1
+234
Lilienthal
2016-11-18 20:56:28 UTC
view on stackexchange narkive permalink

Nou, ik haat het om je bubbel te laten barsten, maar als dit de derde keer is dat dit gebeurt, sluit het bijna uit "jij bent het niet, zij zijn het". Uw titel zegt dat u werd ontslagen omdat u "onmisbaar" was, maar behalve dat het een oxymoron was, is het ook niet wat er is gebeurd. Je bent ontslagen omdat je code hebt geschreven die je collega's niet kunnen begrijpen, wat een kritisch prestatieprobleem is voor een programmeur.

Goede code is leesbare code , dat wil zeggen code die gemakkelijk te begrijpen is, zelfs voor beginners . De situaties waarin u complexe en strak geschreven code nodig hebt die moet worden geschreven en onderhouden door echte experts, zijn tegenwoordig zeer zeldzaam en u werkte blijkbaar niet voor dat soort bedrijven. Wat je beschrijft, klinkt meer als "chique" code, die doorgaans te complex is, vol met esoterische programmeertrucs en het kost heel veel tijd om erachter te komen en fouten op te sporen. Het is een veel voorkomende mislukking voor mensen die klassiek zijn opgeleid en ze worden meestal ruw wakker geschud zodra ze een productieve omgeving betreden.

Goede code is leesbare code, maar niet als de kloof te groot is.Ze wisten bijvoorbeeld niet wat het verschil is tussen overerving en samenstelling.Je kunt dit diepe gebrek aan kennis niet bestrijden in een kwestie van weken / maanden. Ze zijn gewend om alleen if / else te gebruiken, overal in de code met veel DROOG breken.
@Mik378 Klopt, maar ik heb mijn antwoord gebaseerd op het feit dat je dit al twee keer eerder hebt meegemaakt en dat het onwaarschijnlijk maakt dat er helemaal geen problemen zijn met je codeerstijl, zelfs als dit laatste ontslag voornamelijk te wijten was aan incompetentecollega's.Het is ook het enige aspect van uw vraag dat echt kan worden beantwoord, aangezien we niet echt kunnen bepalen of u gewoon bij de verkeerde bedrijven solliciteert.
@Mik378, alle up-gestemde antwoorden zijn rond hetzelfde thema.Dit is vergelijkbaar met mijn antwoord, misschien zelfs beter, zoals efficiënter gezegd.Je moet jezelf afvragen wat je verkeerd doet.De meeste commentaren wijzen op hetzelfde, vooral de up-gestemde.
@Mik378: Heeft u overwogen uw collega's op te leiden?Als je ze begeleidt (bijvoorbeeld door middel van code reviews), dan kunnen ze niet alleen up-to-speed komen, maar bovendien voelt je code hen niet langer vreemd aan.
Ja, ik heb veel tijd besteed aan het uitleggen van concepten, het oefenen van code Kata met hen, enz., Hen helpen in hun eigen code terwijl ik elk van mijn stappen om tot een oplossing te komen gedetailleerd heb beschreven.
@Mik378: De compiler is niet je publiek, je teamgenoten wel.Als je je schrijven niet aan je publiek kunt aanpassen, communiceer je niet.Dat dit meer dan eens is gebeurd, lijkt erop te wijzen dat u niet in staat bent om naar uw publiek te schrijven.
"Ontslagen omdat hij onmisbaar is" is zeker geen oxymoron.Weinbergs klassieke boek "The psychology of computer programming" (gepubliceerd in 1972!) Had al het uitstekende managementadvies: "Als iemand in uw team onmisbaar is, zou uw eerste prioriteit moeten zijn om ze zo snel mogelijk kwijt te raken".Natuurlijk is het * soms * een goede manier om dat elders in het bedrijf te herinzetten - zolang je niet zomaar een andere teamleider hetzelfde probleem voorlegt.
@alephzero Ik zou zeggen dat het zeker een inherente tegenstrijdigheid is en dat het citaat eigenlijk moet eindigen met "meer van hen krijgen of mensen opleiden, dus dat is niet langer het geval".Het is niet zo kernachtig, maar het zou ook niet zo onzinnig zijn als dat advies.Wanneer u wordt geconfronteerd met een busfactor van 1, is het terugbrengen naar 0 niet de juiste reactie.
"Goede code is ... gemakkelijk te begrijpen, zelfs voor beginners" - dat is gewoon niet waar.In feite is het hilarisch verkeerd en devalueert dit antwoord aanzienlijk.Een goed geschreven paper over kwantumstatistische mechanica zal wartaal zijn voor een beginner zonder enige achtergrond in het veld.Hetzelfde geldt voor code die een complex systeem beschrijft.Ik weet niet zeker welk doel wordt gediend door te doen alsof dit niet waar is (helaas lijkt het de laatste tijd een veel voorkomende misvatting te zijn).
Bovendien, als iemand die al 25 jaar IT doet, is de gemiddelde vaardigheid van het team naar beneden gegaan.In sommige bedrijven tot een compisch niveau - senior ontwikkelaars die 15 jaar geleden zouden zijn ontslagen als stagiaires.Dit probleem is wellicht een cultureel probleem.
@KonradRudolph Heb je de rest van het antwoord gelezen?Ik verwijs naar dat soort omgevingen in de tweede alinea.Of je het nu leuk vindt of niet, dat soort programmering is tegenwoordig zeer zeldzaam en uit de beschrijving van OP blijkt duidelijk dat dit niet het soort werk is dat hij verwacht te doen.En hoewel dit niet de plaats is voor een technische discussie, zou ik ook zeggen dat het perfect mogelijk is om een model te maken voor een complex systeem dat gemakkelijk te begrijpen en te lezen is.
Zou het beter zijn om iets te zeggen als: "Goede code is ... geschreven om gemakkelijk te worden begrepen door je collega's (in het bedrijf, in het veld waarin je werkt)."Dit zou waar moeten zijn, of de collega's nu experts zijn of niet, aangezien je die code als team onderhoudt.
@Mik378 Overerving en samenstelling zijn twee redelijk vergelijkbare concepten. Is het echt nodig dat een ontwikkelaar het verschil kent om aan de zakelijke behoeften te voldoen?Als het 10% meer kost om een ontwikkelaar in dienst te nemen die dit weet, krijgt het bedrijf dan een rendement op die investering in vergelijking met het schrijven van software die misbruik maakt van taalfuncties maar voldoet aan het zakelijke doel?
@thelem Echt?Ik zou zeggen dat het niet kennen van deze basisconcepten op de lange termijn meer problemen zal veroorzaken.We hebben het niet over een esoterische taalfunctie, maar over basisconcepten die deel zouden moeten uitmaken van de kennis van elke ontwikkelaar (tenminste ontwikkelaars die zich richten op OO-talen).
Goede code is leesbaar voor degenen die de basisprincipes begrijpen.Het lijkt erop dat hij de juiste objectgeoriënteerde code probeert te schrijven voor dinosauriërs die alleen procedurele code kennen.Als het niet zo fundamenteel is, wordt hij waarschijnlijk te schattig.
@Mik378, "Je kunt dit diepe gebrek aan kennis niet bestrijden" - ja, dat kan niet.Zoek een betere baan of start je eigen bedrijf.
De waarheid ligt ergens in het midden van de "extreme" interpretaties van zowel Lilienthal als Konrad's opmerkingen.Ik heb met veel mensen gewerkt die dachten dat ze goede ontwikkelaars waren die een talent hebben voor het schrijven van complexe software.Het probleem is tenslotte complex.Ik ben nooit onder de indruk geweest van die mensen.De meest indrukwekkende ontwikkelaars zijn degenen die het complexe, eenvoudige maken.Ik vermoed dat het OP eerder in de eerste groep valt dan in de laatste.IMO, die blindelings de huidige best practice "softwareprincipes" volgt, zal bijna altijd resulteren in het creëren van complexe code.Misschien is dit het probleem van het OP.
"Overerving en samenstelling zijn twee redelijk vergelijkbare concepten, is het echt nodig dat een ontwikkelaar het verschil kent om aan de zakelijke behoeften te voldoen? Als het 10% meer kost om een ontwikkelaar in dienst te nemen die dit weet ... - thelem" Dit iszo'n basiskennis, dat een programmeur die het verschil niet kent, een vreselijke productiviteit zal hebben.Het kost al gauw meer dan 10% meer om deze programmeur in dienst te nemen, aangezien ze geen idee hebben wat ze doen.
@KonradRudolph Twee woorden voor jou "Feynman Lectures".
@Aron Heb je echt een inleidende expositie gecombineerd met een onderzoeksartikel?
@KonradRudolph: Goede code is zo gemakkelijk mogelijk te begrijpen.Ik zal je een voorbeeld geven: ik las een beschrijving van lineaire programmering in een leerboek over lineaire algebra en begreep er niets van.Ik las het boek van Dantzig vanaf het begin en hij slaagde erin alles op een voor de hand liggende manier te beschrijven.George Dantzig = held.Onbekende auteur van het leerboek = nul.Een complex probleem nemen en het zo rangschikken dat je een eenvoudige en voor de hand liggende oplossing krijgt, dat is wat een goede programmeur maakt.
Softwareproblemen die inherent moeilijk zijn, zijn buitengewoon zeldzaam.Softwareproblemen die eenvoudig maar enorm zijn, zijn niet ongewoon.Je lost ze op door code te schrijven die _simple_ is.
@industry7 het kan ook het geval zijn als een programmeur weet hoe hij het concept moet toepassen, maar niet bekend is met de specifieke terminologie.
#2
+148
Cort Ammon
2016-11-19 02:26:16 UTC
view on stackexchange narkive permalink

Het is geen grap, ik kon het niet uitstaan ​​om dit een vierde keer te laten gebeuren, het beïnvloedt me mentaal.

Deze zin is belangrijk, omdat het laat zien dat je het is tijd om te veranderen. Het laat zien dat u dit als een patroon herkent en wilt dat het patroon stopt. Dat verlangen is waarschijnlijk het belangrijkste onderdeel van de oplossing. Het oplossen van dit soort situaties houdt vaak in dat u de manier waarop u zelf denkt, moet veranderen. Het is onmogelijk voor iemand om dat voor u te doen, dus uw verlangen om te veranderen zal het enige zijn dat de verandering tot stand brengt.

Voor de een of andere achtergrond ben ik in hetzelfde soort "te goed in coderen voor mijn job-situaties eerder, maar nooit in de mate die u beschrijft. Ik zou kanker kunnen genezen met sjabloon-metaprogrammering in C ++, maar velen met wie ik werk, zijn nauwelijks thuis in de basisprincipes van Object Oriented Design. Ik heb code geschreven die misbruik maakte van SFINAE en recht tegen de exacte bewoordingen van de C ++ -specificaties in ging, terwijl veel projecten waaraan ik 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 zou kunnen oplossen. Ik hield ervan om mensen kleine programmeertips uit te leggen, en ze genoten er grotendeels van.

Klinkt dat bekend?

"Ja, maar je moet een goed niveau hebben om [ Mik's code] omdat componenten intelligent zijn ontkoppeld. "

Beschouw deze verklaring vanuit een risicogebaseerd perspectief. Je baas moet alles draaiende houden, wat er ook gebeurt. Als je weggaat om een ​​geweldige baan te zoeken, moet je baas er nog steeds voor zorgen dat de code behouden blijft. Wat uw collega zojuist zei, was dat als ze u moeten vervangen, ze een zeer bekwame coder nodig hebben , want wie niet zo goed is, kan die niet onderhouden. Dit is een risico. Wat als ze geen ontwikkelaar kunnen vinden die goed genoeg is, of ze niet genoeg kunnen betalen?

Misschien heb je wat je zou noemen "goede code" geproduceerd, maar de definitie van "goede code" is zeer sterk afhankelijk van de context. Wat bij Google "goede code" is, met hun geavanceerde denkwijzen, kan een zeer slechte code zijn voor iemand die bij de FAA werkt, die zich voornamelijk bezighoudt met betrouwbaarheid in plaats van bij te blijven. De definitie van uw baas van "goede code" omvat de mogelijkheid om deze in allerlei situaties te onderhouden, ook zonder u. Als uw collega's het niet prettig vinden om uw code te onderhouden, bent u plotseling aansprakelijk jegens het bedrijf, omdat u een product produceert dat zij niet kunnen onderhouden als u besluit ergens anders heen te gaan.

Van vanuit dit perspectief zou je kunnen beweren dat je ze dwingt om je definitie van "goede code" te accepteren. Instinctief lijkt dit misschien een goede zaak, maar het is vol moeilijkheden, zoals deze op risico gebaseerde manier van denken waar je misschien niet aan hebt gedacht.

We hebben een zin: " wagen voor het paard. " Een van de vele betekenissen die eraan verbonden zijn, is de inhoud die u het belangrijkst vindt (uw geavanceerde technieken te kunnen gebruiken) boven de krachten die het naar voren zouden moeten trekken (het begrip van uw collega 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 de "inhaalslag" maken, loopt het bedrijf plotseling gevaar omdat niemand de code kan onderhouden.

Hoe kan ik dit in de toekomst vermijden?

Dit kan heel moeilijk zijn om dit op te lossen, omdat je het probleem op een andere manier moet benaderen dan je normaal gesproken prettig vindt. In plaats van eerst code in deze geavanceerde stijl te schrijven en vervolgens uw collega's te leren hoe ze op die manier moeten denken, moet u het omdraaien. Leer uw collega's die stijl van coderen leuk te vinden en begin vervolgens met het schrijven van code in die stijl. Het lijkt misschien achterwaarts, maar het is veel stabieler. Vanuit het perspectief van een baas is er weinig tot geen risico als het team beter leert coderen. Als ze eenmaal beter coderen, is de stijl waarin je je wilt ontwikkelen ineens 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. Uw andere product helpt de andere ontwikkelaars te onderwijzen, en de waarde daarvan kan gemakkelijk de waarde van het schrijven van "perfecte code" overstijgen.

Natuurlijk kan het moeilijk zijn om te zeggen wanneer het veilig is om code in te schrijven de stijl waarin je wilt schrijven. Als het gemakkelijk was te zien, zou je het nu zeker al bedacht hebben! Een krachtige techniek die u kunt gebruiken, is anderen te laten pushen voor de geavanceerde coderingsstijlen, in plaats van er zelf voor te zorgen. Iemand het verschil leren tussen overerving en compositie is één ding. Het is iets heel anders om ze goed genoeg te leren dat ze ervoor pleiten om uw bestaande codebase te wijzigen om duidelijker te zijn wanneer deze deze gebruikt. Het laatste geval laat je echt weten dat ze het concept niet alleen begrijpen, maar het ook echt omarmen.

Een ideale manier om zulke concepten te onderwijzen, is niets te leren. Laat de leerlingen iets ontdekken, en dan wijs je ze in een richting die ontdekking kan gaan. Misschien ontdekt een van hen iets leuks over overerving en kun je ze op het ontwerppatroon van de bezoeker wijzen op basis van wat ze hebben ontdekt. Geef ze niet alleen Bezoeker, maar geef ze een gevoel van richting zodat ze zelf Bezoeker kunnen gaan zoeken.

Het is een veel moeilijkere aanpak, en je zult zeker een gelukkig medium willen vinden tussen dat en je huidige aanpak, maar het kan erg lonend zijn. Wat nog belangrijker is voor uw antwoord, is dat het zonder risico waarde kan toevoegen aan het bedrijf. Als u waarde toevoegt aan een bedrijf en het bedrijf niet in gevaar brengt, zult u vrijwel nooit worden ontslagen. En in de weinige gevallen waarin u toch kunt worden ontslagen, zal het management daar een reden voor geven (zoals een neergang van de economie of een verschuiving in de richting van het bedrijf). Als je het heel goed doet, zul je merken dat het management in plaats daarvan je pad gaat bepalen, net zoals je je collega's vormgeeft, en je zult een merkwaardige neiging ontdekken om precies het goede te hebben geleerd vaardigheid alleen wanneer ze die het meest nodig hebben.

Ik vind het erg leuk om je antwoord te lezen.Aan de ene kant heb ik tijd besteed aan het lezen van code van echt bekwame mensen over de hele wereld.Mijn wens is om constant te proberen om op hen te lijken, mezelf elke dag te verbeteren, om concepten te verwerven door het snel te oefenen.Het is moeilijk om deze constante race om te zoeken naar de "perfecte manier van coderen" te stoppen (met behoud van pragmatisme), terwijl je achteruitgaat om je aan te passen aan niet-gepassioneerde (überhaupt) collega's.Ik heb een extreme ambitie.
@Mik378 Ik heb nog nooit in mijn leven iemand meer een codereview zien nodig.Kijk, een codereview gaat niet alleen over goedkeuring (het zou eigenlijk niet over goedkeuring moeten gaan).Het is een kans om te zien hoe mensen uw code lezen en erover praten.Het maakt deel uit van een gesocialiseerde programmeur worden.Als je echt ver wilt gaan met programmeren, programmeer dan niet alleen.Ga zitten met deze jongens en codeer samen.Het heet koppelen.Wellicht leert u ook iets van hen.
Wie zei dat ik nooit intensief in pair-programmering heb geprogrammeerd?niet ik
@Mik378 Het * leek * dat je niet hebt geprobeerd om op de werkplek te programmeren, waardoor je problemen kreeg.Als u dat deed, waarom zou iemand uw code dan moeilijk te begrijpen vinden?
Uw zin mist een woord nee?
Dus je contactpersoon zegt dat je alleen moest werken, maar je was bezig met uitgebreide paarprogrammering?
@Mik378 Nooit deze ervaring gehad, maar ik ben het eens met dit antwoord, want: je hebt geen controle over het perspectief van de manager.U kunt slechts uw helft van de vergelijking bezitten.(Dit geldt nog steeds, zelfs als het management het bij het verkeerde eind heeft.) Aantonen dat je een teamspeler bent, is een duidelijke overwinning voor het management (in het algemeen).Dit zou kunnen betekenen dat solliciteren naar banen met alleen-ontwikkelaarsprojecten (met uw combinatie van geografie, vaardigheden en vaardigheidsniveau, enz.) Gewoon * te riskant voor u * is op korte tot middellange termijn.
Heeft iemand de hypothese bedacht dat mijn collega's de code gewoon niet kunnen lezen?Dat mijn collega's de manager bedriegen over hun fictieve vaardigheden?Geloof me, als ik de best leesbare code van de wereld zou schrijven, zou mijn eigen moeder die nog steeds niet kunnen lezen, omdat ze nooit heeft geleerd hoe ze code moet lezen.Die collega's missen een enorme kennis op het gebied van programmeren.Bijvoorbeeld, HashMap in Java, ze wisten strikt genomen niet waar het voor was ... (ze hebben 6 jaar "ervaring").Ik wil niet vechten tegen deze realiteit.
@Mik378: Dat is heel goed mogelijk.Er zijn teams van "ervaren" ontwikkelaars die zeer beperkte vaardigheden hebben en zichzelf niet willen pushen, en het zijn moeilijke werkplekken voor iemand die meer wil dan dat.Misschien ervaar je daar wat van.Maar je kunt nog steeds leren werken met dit soort ontwikkelaars en er zelfs iets mee winnen.Als het frustrerend is, zoek dan een of twee nuttige tips uit deze antwoorden, zodat u de baan kunt behouden totdat ** u ** klaar bent om verder te gaan voor iets uitdagender in puur technische zin.
Ik zou hieraan willen toevoegen dat er ook winkels zijn die zo goedkoop codeapen willen als ze maar kunnen krijgen.Ik was een van de eersten en laatste die tegen marktconforme tarieven werden aangenomen.Bijna alle anderen werden gerekruteerd als stagiair en vervolgens fulltime aangenomen na het afstuderen.Als dit het doel van de winkel is om de goedkoopste ontwikkelaars te hebben, kun je niet verwachten dat ze de geavanceerde code begrijpen.Ik probeer ze gewoon betere werkwijzen voor onderhoudbaarheid aan te leren en hoop dat ze het verlangen hebben om te leren.
@Mik378 - Je hypothese dat je collega's geen code kunnen lezen, zou meer kloppen als dit niet de "4e keer" was dat het is gebeurd.Eerlijk gezegd (en ik zeg dit als een werkende manager van een ontwikkelingsteam), schreeuwen uw opmerkingen en reacties hier een houding van "Ik ben een god onder ontwikkelaars. Ik schrijf geweldige geavanceerde code. Niemand anders begrijpt het omdat ze dom zijn en /of lui. "Dat is wat mij overkomt in 10 minuten na het lezen van uw vraag en uw reacties op daaropvolgende antwoorden / opmerkingen.
@Mik378 als uw code complex is, en u bent de _alleen_geschoolde programmeur in het bedrijf, dan zou ik sterk aanbevelen om een baan te zoeken waar andere programmeurs zijn die slimmer / vaardiger zijn dan u.Dan kun je van hen leren (je zegt dat je graag wilt verbeteren) en ze kunnen je complexe code begrijpen.
@JohnP Ik herkende Miks naam van eerdere berichten die hij op de werkplekbeurs had geplaatst.Uw hypothese kan correct zijn, zoals blijkt uit fragmenten als * "Hoe moet ik chefs (niet-programmeurs) overtuigen dat om met echt goede software te eindigen alle methodologieën vereist zijn die ik heb geprobeerd op te leggen en goede ontwikkelaars (ik durf niet te onthullenvoor hen mijn gedachten over de slechte vaardigheden van de andere ontwikkelaars)? "*
@JohnP Je hebt gelijk.De waarschuwingsborden zijn vrij sterk zichtbaar.Omdat ik echter zijn code niet heb gezien en zijn collega's niet heb ontmoet, neig ik naar oplossingen die in alle gevallen werken.Als hij echt zo goed is als hij beweert, dan zal deze aanpak hem helpen het bedrijf vooruit te helpen.Als je instincten juist zijn, dan zal deze aanpak hem helpen te volgen.Beide worden bereikt door te luisteren en te proberen de verlangens van andere collega's te begrijpen.Zo kunnen we een pad voorwaarts vinden dat goed is, ongeacht iemands perceptie van zijn vaardigheid (inclusief die van hem, die van jou en die van mij).
"Als ze je moeten vervangen, moeten ze een zeer bekwame coder vinden, want wie niet zo goed is, zal het niet kunnen onderhouden."Dat is niet hoe het werkt.Code geschreven door een ervaren coder is gemakkelijker te onderhouden voor zowel ervaren als ongeschoolde codeerders.Code geschreven door een ongeschoolde coder is moeilijker te onderhouden voor zowel ervaren als ongeschoolde codeerders.
@Mik378 Je hebt hier een heel mooi antwoord, dus ik wil geen nieuwe maken.Ik ga er gewoon iets aan toevoegen.Ik heb gewerkt voor een van de grootste sociale netwerken in Tsjechië en we hadden ook een ontwikkelaar die op een hoger niveau zat dan wij.Hij schreef het grootste deel van de back-end met zijn eigen technologieën (mono, c) zonder het management te raadplegen.En toen hij wegging (zonder enige logische reden) ging het naar de hel omdat we niet konden achterhalen hoe het platform was gebouwd.Nu denk ik dat jij hetzelfde doet.Werk ALTIJD samen met minstens 1 ontwikkelaar, die het werk kan oppakken.
Ik denk dat ik deze les heb :) Bedankt voor je punt @Marakoss
@TheMerryMisanthrope: Er is "bekwame" coder en "slimme" coder.Ik herinner me dat ik naar een C ++ code keek die was geschreven door een "slimme" coder en alleen maar zei "WTF is dit", het liet zien aan een andere zeer bekwame coder die ernaar keek en precies zei wat ik net had gezegd.Omdat we zeer bekwaam waren, hadden we allemaal precies hetzelfde probleem gemakkelijk kunnen oplossen zonder iets 'slim' te doen waardoor het moeilijk te begrijpen was.
@gnasher729 Precies.Clever is zelden echt vaardig.
#3
+134
Old_Lamplighter
2016-11-18 20:54:26 UTC
view on stackexchange narkive permalink

Er zijn altijd redenen.

Een vorige werkgever deed dit met een collega van mij. Zijn vaardigheidsniveau was ver buiten onze vaardigheid. Dus hij werd losgelaten.

Waarom is dit logisch?

  1. Hij was de enige die zijn code kon onderhouden
  2. Hij werkte niet samen
  3. Hij volgde de winkelnormen niet
  4. Hoewel hij meer leverde dan nodig was, was dit geen goede zaak.
  5. Er waren eenvoudige oplossingen nodig in plaats van complexe.

Er wordt zo vaak gezegd dat het bijna een cliché, maar je moet wel goed passen bij het team.

Codering is slechts een deel van de vergelijking. Je moet persoonlijk, communicatief, tot op zekere hoogte bescheiden, arrogant zijn als dat nodig is, winkelnormen volgen, goed overweg kunnen met je collega's, benaderbaar zijn en snel helpen als dat nodig is.

Al deze zachte vaardigheden zijn belangrijk, en als u ze niet heeft, zal dit problemen voor u veroorzaken.

Opmerkingen zijn niet voor uitgebreide discussie;dit gesprek is [verplaatst naar chat] (http://chat.stackexchange.com/rooms/48768/discussion-on-answer-by-richard-u-fired-because-your-skills-are-too-far-hierboven).
#4
+67
gazzz0x2z
2016-11-18 20:41:17 UTC
view on stackexchange narkive permalink

Goede code is gemakkelijk te begrijpen, zelfs voor slechte ingenieurs. Een advies dat ik vaak kreeg, is "programmeer alsof de persoon die je code onderhoudt een middelmatige programmeur is en een gevaarlijke psychopaat die weet waar je woont".

En het is waar. Te slim programmeren is slecht, omdat het onderhoud langer duurt als je de code niet weet . Bij onderhoud heb je vaak overal brand, duizenden klanten geblokkeerd, en een slimmer en efficiëntere oplossing kan de beheerder heel goed langer vast houden dan een domme scriptachtige code vol herhalingen.

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

Je moet rekening houden met de context. Als je in een klein bedrijf werkt dat alleen de beste mensen inhuurt, kun je je waarschijnlijk een aantal exotische, briljante dingen veroorloven. Als u voor een Franse bank werkt die alleen vertrouwt op consultants van, eh, willekeurige kwaliteit (soms hebben ze geluk, soms niet), en waar elke consultant een domein van miljoenen LOC moet onderhouden, maak het dan in elk geval eenvoudig genoeg voor een middelmatig om het op het eerste gezicht te begrijpen. Geen aanwijzingen, geen meervoudige overerving, geen slimme trucs, enz ...

Opmerkingen zijn niet voor uitgebreide discussie;dit gesprek is [verplaatst naar chat] (http://chat.stackexchange.com/rooms/48769/discussion-on-answer-by-gazzz0x2z-fired-because-your-skills-are-too-far-above-yo).
"Goede code is gemakkelijk te begrijpen, zelfs voor arme ingenieurs."Ik denk niet dat de werkplaats een geweldige plek is om over software engineering te praten.Ik zie steeds dit soort naïeve opmerkingen, en dat is niet het hele verhaal.Het is een vage generalisatie die geweldig klinkt in een geluidsbyte voor een TED-talk of zoiets, maar in het echte leven geen steek houdt.
@Cypher: de context is een "groot Frans bedrijf".Ik ken die een beetje.Het meeste werk in dergelijke bedrijven wordt gedaan, maar consultants van, errrrrrm, willekeurige kwaliteit.Daarom is leesbaarheid zo belangrijk.Wat je ook doet in zo'n context, het moet begrijpelijk zijn voor de volgende clueless man die binnen niet meer dan 3 jaar plaatsneemt. Andere contexten kunnen andere regels hebben.Ik heb het over de context van het OP.(en ja, IT in grote Franse bedrijven is gemiddeld erg slecht - hun praktijk om nooit consultants aan te nemen en altijd te gebruiken is catastrofaal - maar het is de realiteit).
#5
+39
Peter
2016-11-18 20:47:02 UTC
view on stackexchange narkive permalink

Het is onwaarschijnlijk dat u wordt ontslagen omdat u te goed bent. Ik denk dat dat maar een excuus is.

Het is veel waarschijnlijker dat het een gedragsprobleem is, of dat de baas je gewoon niet mag om redenen die hij je niet kan vertellen zonder redenen voor een rechtszaak. Het is ook mogelijk dat u de duurste bent en dat zij geloven in FTE's (dwz elke werknemer is hetzelfde).

Als u echt zo goed bent, kunt u uzelf 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 hen te vertellen welke aanpak ze moeten volgen.
  • Schrijf goede code die gemakkelijk door andere mensen kan worden onderhouden.
  • Advocate best practices op manieren die de productiviteit verhogen, in tegenstelling tot de best practices van vrachtcultus, die op papier goed klinken maar de productiviteit teniet doen.
Heb je het artikel gelezen dat ik in mijn OP heb gelinkt?Het lijkt erop dat het een soort .. "gewoonte" is voor bepaalde managers ...
Zoals ik hierboven al zei, plande ik 8 bijeenkomsten van elk ongeveer 2 uur, om ze wat goede code-oefening bij te brengen.Geen effect.
@Mik378 Mentoring en lesgeven in collegeslots van 2 uur zijn heel verschillende dingen.Wat betreft het artikel, dit is eigenlijk een voorbeeld van vrachtcultus - er zijn zeer goede redenen om iemand te ontslaan die zichzelf onmisbaar maakt, maar dat is heel anders dan iemand ontslaan die gewoon een hoger vaardigheidsniveau heeft
Wat is "FTE"?"Fulltime werknemer" heeft geen zin in die zin.
@EsotericScreenName Het staat voor Full Time Employee, maar de term wordt gebruikt om werkdruk (of soms betalen) te beschrijven.Als het wordt gebruikt, wordt ervan uitgegaan dat elke werknemer hetzelfde is.Bij softwareontwikkeling is die aanname meestal onzin.
@Peter Ik geloof dat in de context waarin je het gebruikt, het "Fulltime * Equivalent *" is - dat wil zeggen, als je iemand hebt die alleen op maandag en dinsdag werkt, en iemand anders die alleen van woensdag tot vrijdag werkt, maken ze samen 1 FTE.Het is echter een slechte organisatie die dezelfde prestaties verwacht van twee van dergelijke ontwikkelaars als een fulltime ontwikkelaar, en dat is het punt dat u maakt.
#6
+32
Cronax
2016-11-18 21:43:06 UTC
view on stackexchange narkive permalink

Onmisbare mensen ontslaan is eigenlijk een goede managementstrategie. Wanneer uw bedrijf erop vertrouwt dat één persoon zijn werk blijft doen en niemand anders in het bedrijf heeft zijn kennis en / of kunde, dan ontstaat er een enorme aansprakelijkheid: wat als die persoon wordt aangereden door een bus en overlijdt (vandaar de term 'bus factor ') of kiest u er gewoon voor om het bedrijf te verlaten voor een nieuwe uitdaging? Nu zit uw bedrijf vast in een vreselijke situatie omdat niemand de onmisbare medewerker 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 om de kennis te verspreiden en / of de bekwaamheid van de medewerkers van de onmisbare persoon te vergroten, of ze kunnen het pleister in één keer losmaken door de onmisbare persoon te ontslaan op een moment van hun kiezen en herstellen van het verlies van de werknemer wanneer ze op dat proces zijn voorbereid.

Omdat het niet altijd praktisch is om een ​​grote kloof in kennis en vooral in bekwaamheid te dichten, kan het ontslaan van hen de meer logische keuze zijn .

Als werknemer moet u altijd proberen voorkomen dat u onmisbaar wordt. Deel uw kennis met uw collega's en zorg ervoor dat er mensen zijn die uw werk kunnen doen als u er niet bent. Zorg ervoor dat uw praktijken geschikt zijn voor de werknemers met het gemiddelde vaardigheidsniveau van uw bedrijf. Als u vindt dat het gemiddelde niveau te laag is, werk dan samen met het management om dat niveau te verhogen. Zorg ervoor dat alles wat u maakt, goed gedocumenteerd is en dat de genoemde documentatie van voldoende hoog niveau is zodat al uw collega's het kunnen gebruiken om uw werk voort te zetten.

Zinvol antwoord
+1 Kennis bezitten, opzettelijk presteren boven uw collega's, veroorzaakt alleen problemen."Wees niet onvervangbaar, als je niet kan worden vervangen, kun je geen promotie krijgen"
Nee, iemand ontslaan omdat hij onmisbaar is, is geen goede strategie.Werkelijk?Zou u een werknemer kwijtraken omdat hij / of zij het werk te goed heeft gedaan?Het bevorderen of verplaatsen van hen naar andere uitdagingen, waardoor anderen de kans krijgen om de leemte op te vullen en de afhankelijkheid van het individu te verminderen (waarnaar het artikel verwijst) is een goede strategie.Het omgekeerde, iemand behouden die ontslagen zou moeten worden omdat hij of zij onmisbaar lijkt, is het echte probleem.
Dit kwam ook naar voren in een opmerking en ik moet de geestelijke gezondheid van de mensen die denken dat dit goed management is, in twijfel trekken.Wat zou je in vredesnaam kunnen doen denken dat het een geweldig plan is om 'het uit de weg te ruimen' en mensen bij te laten die per definitie cruciaal zijn voor de doelstellingen van het bedrijf?Mensen die vrijwel zeker uitstekende en waardevolle medewerkers zullen zijn.Afgezien van het onzinnige idee dat "controle over de timing" op de een of andere manier een goede zaak is, laat staan de afweging waard is, wat voor bericht zou u dan naar de rest van uw personeel sturen?
Ja, u moet eraan werken om lage busfactoren te voorkomen.Ja, je moet ervoor zorgen dat mensen die onmisbaar zijn geworden hun kennis en vaardigheden delen.Wat u suggereert, lijkt op het afhakken van uw arm, omdat een kras op uw hand geïnfecteerd kan raken.
Als er een 'onmisbare coder' is, ontsla de manager.Niemand ontslaat arbeiders van hoge kwaliteit omdat ze goed genoeg zijn om onmisbaar te worden.
@SteveJ Omwille van het antwoord nam ik duidelijk een aantal snelkoppelingen.Als iemand in de echte wereld onmisbaar is geworden, heeft het management al lang daarvoor gefaald.De truc is dat de meeste mensen * onmisbaar * worden, vaak is door kennis op te hamsteren en barrières op te werpen om te voorkomen dat hun collega's hun werk begrijpen.Dit is duidelijk ongewenst gedrag en dient actief te worden ontmoedigd.Wat betreft de boodschap die dit naar uw personeel stuurt, het toont aan dat ze zich niet zomaar kunnen verdoezelen in werkzekerheid.
#7
+21
John Feltz
2016-11-18 20:30:25 UTC
view on stackexchange narkive permalink

Als u het enige gemeenschappelijke tussen de drie situaties bent, moet u bedenken dat iets wat u doet een probleem is.

Heeft u met uw voormalige collega's gesproken en hen gevraagd om u bekritiseren? Niet uw code, maar uw gedrag op kantoor. De manier waarop u met uw collega's communiceert, de manier waarop u met uw baas communiceert, de manier waarop u documentatie verstrekt, hoe u zich gedraagt ​​tijdens vergaderingen, enz.

Heeft u zich in de positie van uw supervisor geplaatst? Echt nagedacht over wat ze moeten doen, wat hun verantwoordelijkheden zijn, waardoor ze zich goed voelen als ze het licht op kantoor uitdoen en naar huis gaan? Er zijn heel veel voorbeelden waarbij iemand geweldige code schrijft vanuit het perspectief van andere software-ingenieurs , maar het bedrijf faalt.

Ik ben inderdaad gewend om vaak strategieën voor te stellen, om bestaande slechte strategieën beleefd te bekritiseren.Misschien interpreteren ze dat als "arrogant" of "Lessengever".Maar kritiek maken hoort bij mijn werk als ingenieur.
De hiërarchie wil die kritiek niet altijd horen.U zegt "we zouden X moeten doen in plaats van Y";wat de baas hoort is "Je bent stom omdat je in het verleden besloten hebt Y te doen. Als ik hier op dat moment was geweest, hadden we X gekozen".Het maakt niet uit hoe beleefd het is geformuleerd.
Kritiek maakt relaties kapot.Periode.
Gebrek aan * constructieve * kritiek doodt bedrijven.
#8
+20
Brad Thomas
2016-11-19 12:54:55 UTC
view on stackexchange narkive permalink

Ik heb naar je profiel gekeken, er staat "je code moet schoner zijn dan jijzelf". Ook uit uw opmerkingen dat u "veel tijd besteedde aan het uitleggen van concepten", en "bekritiseren hoort bij mijn werk als ingenieur" ... Ik denk dat u graag advies wilt geven en uw advies wordt gewoon niet gewaardeerd door uw teamgenoten.

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

Het schrijven van productieve en onderhoudbare code leidt niet tot je wordt ontslagen. Je wordt ontslagen als je niet met het team overweg kunt. Dit is uw probleem, niet (zoals u zich het voorstelt) uw code is te goed. Je code is misschien heel goed - maar VEEL waarschijnlijker is dat dit een persoonlijkheidsconflict is.

Mijn advies aan jou is: wees niet de staart die met de hond probeert te kwispelen. Houd uw hoofd gebogen, stop met mensen te vertellen hoe ze moeten coderen , volg de richting, werk goed samen met anderen, schrijf onderhoudbare 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?"

Dit zegt je dat je manager je niet vertrouwt , je manager denkt dat je niet authentiek bent en denkt dat je arrogant bent en / of meer respect hebt voor uw eigen kunnen dan u werkelijk heeft. Relaties zijn afhankelijk van vertrouwen om te overleven. Houd er rekening mee dat uw probleem niet een technisch probleem is. Uw probleem heeft weinig te maken met de kwaliteit van uw code. Wat je hebt, is een probleem met de manier waarop je omgaat met je collega's en je manager.

#9
+20
SteveJ
2016-11-19 00:12:04 UTC
view on stackexchange narkive permalink

Mensen worden niet vaak ontslagen omdat ze onmisbaar zijn ( waarom mensen worden ontslagen); Dat is een belachelijke bewering. Het artikel waarnaar u verwijst, geeft duidelijk aan dat 'vuur' niet noodzakelijk betekent dat u ze moet laten gaan, maar dat u ze niet onmisbaar moet maken (door ze te verplaatsen, ze te dwingen niet betrokken te zijn bij een bepaald project, enz.).

Hoewel overgekwalificeerd u soms niet zal aannemen, wordt u ook zelden ontslagen. Goede medewerkers zijn moeilijk te vinden; Geen redelijke bedrijf gaat zich te ontdoen van een, omdat ze te goed (tenzij je gewoon werken voor een idioot - dan zijn ze je een gunst).

Mensen worden WEL ontslagen omdat ze DENKEN dat ze onmisbaar en beter zijn dan hun leeftijdsgenoten en daarom weigeren ze de veranderingen aan te brengen die moeten worden aangebracht aan de man in de spiegel om goed te functioneren in een team. ( ontslagen wegens slechte houding)

Als je een brug bouwt met een stel inboorlingen en een laptop tevoorschijn haalt terwijl de rest aan het touw is, ben je misschien slimmer of beter opgeleid maar je bent een nadeel voor het team geworden en jij bent het probleem.

Als je echt zo goed bent als je zelf doet, zou je slim genoeg zijn om je eigen acties aan te passen om een ​​zo productief TEAM mogelijk te maken versus dogmatisch je eigen agenda te pushen (wat je waarschijnlijk bent aan het doen). Als je dat deed, zou je waarschijnlijk heel lang een baan hebben.

Als iemand die regelmatig betrokken is bij het inhuren van proces, ik zal iemand die goed en knap meer dan iemand die groot is en een potentiële kanker elke dag in te nemen.

#10
+18
Patricia Shanahan
2016-11-18 20:51:33 UTC
view on stackexchange narkive permalink

Elk programma is een communicatie met twee doelgroepen: een compiler of tolk die het zal laten uitvoeren en sommige mensen die het hebben gelezen en begrijpen. U communiceert misschien buitengewoon goed met de compiler en schrijft nog steeds slechte code omdat deze niet gemakkelijk kan worden begrepen door de andere betrokken mensen.

Typisch, een programmeerteam heeft een reeks talen, frameworks, technieken enz. die bij iedereen in het team bekend zijn. Nieuwe medewerkers die een aantal van die stukjes 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. Stel dat u de enige programmeur in de groep bent die bekend is met framework X, en alle anderen zijn bekend met een ouder framework Y dat wordt gebruikt voor een aantal bestaande code en bijna net zo goed is als X.

Het gebruik van framework X zou een vergissing zijn, tenzij het zoveel 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.

Eén techniek die u kan gebruiken is om uw code te laten beoordelen door enkele van de minst ervaren mensen die deze moeten kunnen lezen. Kijk wat ze te vragen hebben en bedenk hoe u die stukken kunt herschrijven om ze duidelijker te maken. Hoe vaker u het niet begrijpen van uw code beschouwt als een defect in de code, niet in de lezers, hoe beter de feedback die u krijgt.

Ik denk niet dat je het ver genoeg gaat - ik stel voor dat mensen een programma beschouwen als een gesprek tussen een groep codeerders dat toevallig door een machine kan worden uitgevoerd.Het vermogen van de machine om het uit te voeren komt ondergeschikt aan het vermogen om de code te onderhouden - of je zou zelfs kunnen zeggen dat onderhoudbare code met fouten kan worden opgelost terwijl "perfecte" code die niet door het team kan worden begrepen / onderhouden uiteindelijk moet worden vervangen.Merk op dat verschillende situaties verschillende vereisten hebben - de oorspronkelijke architectuur van Twitter was doodlopend, maar het gaf hen het marktaandeel en de tijd om volledig te herschrijven, succes!
Voor mij is dit een unieke invalshoek die ik waardeer.Ik heb feedback gekregen met het effect "is reflectie niet traag" of "het is beter om native structuren te gebruiken".Waarop mijn ideale antwoord zou zijn "laten we het in assemblage schrijven", want als hun kritiek echt gaat over efficiëntie en prestaties, dan moeten we gewoon stoppen met het meten van "schoenmaten" en het zo dicht mogelijk bij het metaal schrijven.
Tegenwoordig wordt voor het meeste ontwikkelingswerk, met uitzondering van big data, optimalisatie voor prestaties overschat.Onderhoudbaarheid en leesbaarheid zijn veel belangrijker.
#11
+14
Ethan The Brave
2016-11-18 22:00:01 UTC
view on stackexchange narkive permalink

Besloten om mijn opmerking te upgraden naar een antwoord:

Documenteer je code heel goed.

Juiste codedocumentatie verandert slechte ervaringen waar een junior ontwikkelaar beukt met hun hoofd tegen een onbegrijpelijke muur urenlang naar potentiële leerervaringen.

Onthoud dat goede code zichzelf zou moeten documenteren :)
BDD / Unit-tests met betekenisvolle namen zijn de beste documentatie ooit.
@Mik378 Dat veronderstelt dat uw collega's daadwerkelijk gaan vertrekken, de unit-tests lezen en ze begrijpen - van wat ik begrijp, is dat niet het geval.Goede code * is * zelfdocumenterend, maar dat veronderstelt een zekere bekendheid met de gebruikte conventies.U moet zich altijd afvragen "zullen mijn collega's deze code begrijpen?".Als dit niet het geval is, geef er dan commentaar op totdat ze het doen.En om u af te snijden, "wel, dat zouden ze doen als ze ..." het snijdt het niet.U documenteert het voor uw huidige collega's - zoals ze momenteel bestaan - niet voor sommige hypothetische collega's met ideaal gedrag en ideale kennis.
@Mik378: ga er niet vanuit dat het genoeg is.Je moet natuurlijk streven naar een code die geen commentaar nodig heeft.En toch commentaar geven.En voor een code die geen documentatie nodig heeft.En toch documenteren.Dat is het leesbaarheidsniveau dat in zo'n winkel vereist is.
Zelfdocumentatie kent zijn grenzen.Het is erg belangrijk om de regels voor interfaces tussen modules te documenteren.Ik moest ooit ongeveer 7 lagen van oproephiërarchie doorlopen om erachter te komen of een nulargument was toegestaan of niet.
@Mik378: Als iemand met veel ervaring die in een omgeving werkte, stond de vorige ingenieur erop dat de BDD-tests * de documentatie waren, dus dat is alles wat we hadden, ik kan je vertellen dat dit gewoon niet het geval is.Het is gewoon wishful thinking dat de tests net zo nuttig zijn als documentatie.Het probleem is er een van organisatie en focus - tests vertellen de interface niet op een toegankelijke manier om van te leren, en ze leggen niet uit * waarom * dingen op een bepaalde manier werken.
Beste antwoord.Uitgebreide opmerkingen zouden het grootste deel van het probleem oplossen.Schrijf commentaar als verhaal.Stel je voor dat je naast een nieuwe medewerker zit en die persoon door je code leidt.Of stel je voor dat je je eigen code leest met een grote kater en weinig slaap.Geef bovenaan een algemeen overzicht met een samenvatting van het gegeven probleem en uw strategie.Gebruik een gemoedelijke toon terwijl u elke gedachte en elke stap geleidelijk behandelt.Gebruik "wij" en "onze": "We sorteren de wombats in hun biologische categorieën, zoals gedefinieerd door Dr. Adèle Mercier."& "We hebben ArrayList verkozen boven LinkedList omdat onze collectie bevroren is, niet gewijzigd."
@Peter Ik moet nog een praktisch voorbeeld zien van zelfdocumenterende code.
@RichardU Maar ik weet zeker dat je praktische voorbeelden hebt gezien waarin de documentatie minder nuttig was dan het ontbreken van documentatie.;)
@Peter touché.Een recente nachtmerrie van mij is een goed voorbeeld.4 amateur-codeerders waarvan ik aanneem dat ze elk naar een programmeerboek hebben gekeken, of in ieder geval de omslag hebben gelezen, hebben dit wangedrocht gecreëerd dat de afgelopen maanden de vloek van mijn bestaan is geweest.
#12
+14
bobbym
2016-11-20 13:51:15 UTC
view on stackexchange narkive permalink

Bij de meeste antwoorden werd je bericht behandeld vanuit het oogpunt of je code al dan niet leesbaar was of zo goed als je zegt dat het is. Maar deze situatie kan en zal in alle lagen van de bevolking voorkomen. Ik nam een ​​baan op de Las Vegas Strip als 21 dealer en floorman. Mijn technieken en snelheid liepen zo ver voor op de rest van hun personeel dat de mensen die op mij moesten letten niet bij konden blijven. Met andere woorden, ze konden mijn beslissingen niet volgen. Omdat er binnen enkele minuten grote hoeveelheden geld werden afgehandeld, voelden ze zich vaak in de war en rapporteerden ze me aan hun chef en beweerden dat ik een fout had gemaakt. Ik zou altijd mijn daden aan die persoon rechtvaardigen, maar de houding van wantrouwen jegens mij werd verdiept.

Mijn ego en ik vermoed dat die van jou de waarschuwingssignalen niet hebben gezien en inderdaad genoot ik van mijn superioriteit en goot het zo uit naar spreken. Ik werd ontslagen en verloor een buitengewoon goed betalende positie.

De les is eenvoudig, je moet naar het niveau van de anderen kijken. Als ze slechts 15 handen per uur krijgen en jij krijgt er 100, dan ben je geen inspirerende complimenten. Je wekt jaloezie en zelfs haat op. Als je trots dit niet kan, 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 ging uiteindelijk over op andere werkterreinen, waar ik ook middelmatig was en dus niet opviel. Ik hoop dat je dit in je voordeel kunt oplossen.

Uitstekend advies.Ik heb dit zelf op de harde manier geleerd.Een kleine waarschuwing.Je hoeft dingen niet altijd dom te maken, maar je moet wel goed passen.
Een goede pasvorm, dat vind ik leuk.Ik moest de regels volgen.Ik had het gevoel dat de regels waren ingevoerd zodat ze middelmatige mensen konden inhuren om naar andere middelmatige mensen te kijken.Het leek erop dat het qwerty-toetsenbord oorspronkelijk was geïmplementeerd om te voorkomen dat mensen te snel typen voor de machine.
Jouw ervaring is erg interessant.Je vermeldt niet hoe je hebt gepresteerd in termen van de bezuiniging van het huis.Heb je meer of minder verdiend dan gemiddeld?Een casino is een bedrijf en elke beslissing zou sterk zijn beïnvloed door de inkomstenstatistieken.
@bobbym maar de regels waren opgesteld voor medicore om naar medicore te kijken.Het is duur om de beste en beter dan de beste superwise in te huren.
@ joojaa, waar genoeg.Maar als een bovengemiddelde kerel per ongeluk op zo'n plek valt, moeten ze hem koesteren en niet ontslaan. @ CyberFonic, er werd niet in huis geknipt.Ik werkte voor het minimumloon als een agent van het casino.De dealers in 21 moeten het spel spelen volgens een vaste set regels.
@bobbym misschien, maar pragmatisch gezien is deze vaardigheid niet per se beter vanuit een zakelijk perspectief.We verwarren technische finesse vaak met beter, maar de omzetting van die finesse in tastbaar voordeel voor het bedrijfsleven is niet per se groot.Dus vanuit een zakelijk perspectief ben je niet per se beter.
@bobbym minimumloon of goedbetaalde baan?Ik heb het gevoel dat deze zelden gelijk zijn.Hoe dan ook, ja, dit zijn de regels van blackjack, maar het punt van cyberfonic is nog steeds geldig.Als u, gemiddeld, in een uur, uw snelheid ervoor zorgt dat u meer geld verliest dan hun 'middelmatige werknemers' (of minder wint. Casino's verliezen meestal niet vaak geld, hoewel aan managementinkomsten die u niet had, potentieel als verloren geld wordt beschouwd)uw superieure techniek telt voor niets.Als je superieure techniek ervoor zorgt dat je met een goede marge MEER geld verdient, zou het me verbazen dat ze je ontslaan.
@Patrice: Ik was ook verrast.Natuurlijk levert meer werk voor hen meer winst op, wiskundige verwachting garandeert dat.Als het management daar iets van had kunnen begrijpen, zouden ze niet middelmatig zijn geweest.Ja, het minimumloon is en was laag, maar de fooien die we maakten waren dat niet.
#13
+13
wberry
2016-11-21 06:54:41 UTC
view on stackexchange narkive permalink

Ik heb hierover gelezen dat je vanaf de eerste dag van je werk voorbestemd was voor deze behandeling. Je zei dat je was aangenomen omdat je vaardigheden hebt die niemand anders in de organisatie heeft (TypeScript, Node). En nu je hebt gezwoegd om een ​​elegante, vakkundig vervaardigde, complexe oplossing helemaal alleen te produceren, begrijpt niemand wat je hebt gedaan, en daarom wordt je door het management als een aansprakelijkheid gezien.

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

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

  • De organisatie nam één persoon in dienst met een totaal andere vaardigheid dan alle anderen, en met een gevorderd niveau van die vaardigheden, om een ​​kritieke functie uit te voeren. Dit garandeert dat, als u goed presteert , u de enige bent die de code begrijpt die cruciaal is voor de missie van de organisatie. (Het is volkomen onredelijk om te verwachten dat een resource op hoog niveau code produceert die direct begrijpelijk is voor mensen die de gebruikte taal niet kennen.)
  • De organisatie heeft u niet regelmatig aan het codebeoordelingsproces onderworpen. Als dat het geval was, zou uw code zijn afgewezen totdat u deze in overeenstemming bracht met hun leesbaarheidsnormen. Aangezien u de enige bijdraagt ​​aan de code, met uw eigen stijl en met een andere technische stack, is het vrijwel gegarandeerd dat de code na verloop van tijd steeds minder begrijpelijk zal worden voor anderen. De enige manier waarop u dit kunt voorkomen, is door anderen te vragen de code voortdurend buiten het proces te beoordelen, mogelijk met beschuldigingen van tijdverspilling van anderen. Een gebrek aan codebeoordelingsproces maakt u dus klaar voor mislukking.

Ik heb soortgelijke ervaringen op mijn achtergrond. Ik ben ooit aangenomen om een ​​vaardigheidsgat te dichten. Niemand anders in het bedrijf had een vaardigheid die ze opeens nodig hadden. Ik deed mijn werk goed en na een paar maanden begon het conflict. Ik was de enige die kon werken met bepaalde componenten van de applicatie. Ik werd een bottleneck 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 volledig nieuwe code, op hun manier. Mijn trots was destijds 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 deed ik.

Als dit bekend klinkt, is het misschien tijd voor jou om verder te gaan. Misschien zal het management u zelfs opnieuw aan iets anders toewijzen als ze uw vaardigheden blijven waarderen. Of als u het kunt verdragen, kunt u misschien helpen om alles wat u hebt gedaan opnieuw te schrijven in de standaard technologiestack van het bedrijf. Als dat niet mogelijk is, ga dan gewoon weg. Hoe dan ook, uw code is waarschijnlijk onderweg naar de vuilnisbak. Dat is waarschijnlijk het juiste 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 anderen in je team in je volgende baan in wezen dezelfde vaardigheden toepassen als jij, en vooral dat ze een codebeoordelingsproces hebben. Als ze u vragen om uw code op bepaalde manieren te wijzigen, doe dat dan. Beschouw code niet als geleverd totdat deze de codebeoordeling heeft doorstaan ​​en uw collega's zullen het management vertellen (indien gevraagd), ja, de code is goed. Dan is er geen probleem. Het is prima om vragen te stellen over dit soort dingen in een technisch interview; Ik heb het zo vaak gedaan. Hopelijk geeft deze andere ontwikkelaar die uw code heeft bestudeerd, u een goede referentie.

Als een voetnoot, als je op zijn minst gedeeltelijk verantwoordelijk bent voor je omstandigheden waarin je helemaal alleen werkt, zonder buy-in van andere teamleden, dan verdien je in ieder geval ook een deel van de verantwoordelijkheid voor het resultaat. (Heb je aangedrongen op het gebruik van TypeScript / Node terwijl anderen iets anders wilden gebruiken? Heb je de nieuwste, coolste bibliotheek of techniek gebruikt, ook al zou iets meer basaals prima werken? Ik heb me hier ook een of twee keer schuldig aan gemaakt. ) Als dat het geval is, trek dan een les uit deze uitkomst. Maar als dat niet het geval is, breng deze ervaring dan met opgeheven hoofd naar uw volgende positie.

Wat een antwoord!Het is volledig in fase met de realiteit, geweldig!
#14
+10
psr
2016-11-18 23:29:11 UTC
view on stackexchange narkive permalink

Er zijn veel slimme mensen die denken dat zeer bekwame ontwikkelaars onvervangbaar zijn en daarom wil ze. Maar je hebt de andere antwoorden op je vraag gezien - de meeste managers willen niet omgaan met de problemen van een team met sterk verschillende vaardigheidsniveaus, en hebben niet de mogelijkheid om puur hoge vaardigheden te behalen. Ze hoeven ook niet per se ongelijk te hebben, de problemen zijn reëel en de voordelen van code van hoge kwaliteit die de capaciteiten van de meeste mensen die ze kunnen aannemen te boven gaan, worden aanzienlijk verminderd.

Als u zelfs maar ongeveer zo goed bent als u zegt, dan past u niet bij uw baan. Het klinkt alsof u uw best moet doen om op een plek te werken waar u kunt leren van uw collega's en uw collega's uw code kunnen begrijpen.

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

Ten slotte moet ik eraan toevoegen dat je je best moet doen om Evalueer eerlijk of uw vaardigheidsniveau echt zo hoog is. Het klinkt alsof er aanwijzingen zijn dat dit het geval is, maar de meeste mensen geloven dat ze beter zijn dan ze zijn. Ook gaan veel ontwikkelaars door een fase waarin ze erg goed worden in één aanpak, maar nog niet altijd alles samenbrengen tot een globaal optimale oplossing, en nog steeds gebrek aan flexibiliteit hebben. Soms is het bijvoorbeeld misschien het beste om voor een inferieure oplossing te kiezen waarvan u weet dat de mensen die u heeft, kunnen onderhouden, als u weet dat ze geen meer geavanceerde oplossing kunnen onderhouden en het is niet waarschijnlijk dat ze iemand anders inhuren die dat wel kan. / p>

De problemen waarmee een team met zeer verschillende vaardigheidsniveaus wordt geconfronteerd, zijn bijna volledig interpersoonlijk en emotioneel in plaats van technisch.
#15
+10
Daniel
2016-11-19 04:33:26 UTC
view on stackexchange narkive permalink

Het is mogelijk dat u gewoon niet zo goed bent als u denkt, maar omwille van beleefdheid ga ik ervan uit dat u weet hoe u de juiste hoeveelheid complexe code moet schrijven om de complexiteit en tijdsvereisten van de hele codebase in een orde van grootte. Het feit dat dit zelfs mogelijk is, verrast veel idioten. Ze vinden het een ongelooflijke stelling, en de enige manier om ze te overtuigen is door ze te laten zien.

Maar daarvoor is finesse, moed en zelfbeheersing nodig. Je moet je eerst op drie dingen concentreren: bewijzen dat je geen bedreiging bent, de idioten er slim uit laten zien en nooit een enkele idioot laten beseffen dat je weet dat hij een idioot is. Als je jezelf er niet toe kunt brengen om deze drie dingen te doen, zul 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, heeft het altijd voor mij gewerkt om soms te negeren wat vijandige idioten me zeggen te doen. In plaats daarvan vind ik manieren om wat ik wil doen, de beste software produceren waarvoor velen van hen ooit de code hebben gezien in een zeer korte tijd, en ik presenteer het op zo'n manier dat hun bazen hen belonen met lovende recensies. Ook al speelden ze geen rol bij het maken ervan. Zelfs als ze er actief tegen waren.

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

Code die vijf mensen kunnen begrijpen en onderhouden, is beter dan code die alleen één kan onderhouden.(Ervan uitgaande dat het aan de vereisten voldoet.)
Daniel, het lijkt erop dat je twee accounts hebt.U kunt de link "contact met ons opnemen" onder aan de pagina gebruiken om te vragen dat ze worden samengevoegd, zodat alle activiteit op één account plaatsvindt.
#16
+8
杜興怡
2016-11-19 03:48:03 UTC
view on stackexchange narkive permalink

Om de vraag specifiek te behandelen:

Hoe kan ik dit in de toekomst vermijden?

  • Zoek een lokaal hoofdstuk van Toastmasters, neem actief deel en verdien de prestaties. Iets dat zo voor de hand ligt als feedback, zal hopelijk gewaardeerd worden en aangescherpt worden tot een van je meest gewaardeerde vaardigheden.

  • Oefen om de student te zijn in plaats van de expert. Heb je deze Jon Skeet-lezing over de basis gezien? Kun je je voorstellen hoeveel meer begrip er kan worden bereikt als we allemaal dergelijke documentatie zouden maken, het zou iedereen ten goede komen, op alle niveaus van een team!

  • Een team is niet één individueel. Je team zal gezamenlijk groeien en verbeteren. Je moet helpen. Het is geen team als elk lid een cel is die in verschillende richtingen gaat (bijvoorbeeld jij hoger en het nieuwste lid stagneert). 2 uur vergaderen is een goed begin. Ik zou daar bovenop de N-dagen-koppelingsrotatie willen toevoegen. Dit is 1: 1 keer dat u cadeau aan uw teamgenoten EN zij cadeau aan u. Leun in jouw geval naar de rol van navigator en laat je partner rijden. Oefen het niet-schrijven van de code, hoe raar dat ook klinkt.

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

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

  • Zoals gezegd, draag bij aan open source-projecten om meer inzicht te krijgen in je code. Ze kunnen bevestigen dat u briljant bent, maar ze kunnen ook de suggesties versterken die u van uw huidige baas hoort. Een recensie geeft je hoogstens een nieuw idee.

  • Zoek een ingenieur die beter is dan jij. Het verbetert jezelf niet om de slimste man van de kamer te zijn. Er is een citaat (mijn googelen is opgesplitst in Olgivy / Ford / Sorkin) parafraseren gaat als "Je kunt niet meer leren als je jezelf omringt met slecht talent".

Ik heb mijn OP bijgewerkt.
Denk je dat hetzelfde kan worden bereikt door patches naar een groter FLOSS-project te sturen?
Toastmasters passen beter in de menigte dan wat dan ook.Voor mensen die dat niet nastreven, zou het niet het beste idee kunnen zijn.Ik kwam er ook niet achter dat de feedback altijd eerlijk was, bijv.ze behandelen het met te veel diplomatie en kinderhandschoenen naar mijn smaak.
@Nemo Ik wou dat ik het me herinnerde, ja!Bijdragen aan projecten in de open lucht die meer ogen zullen krijgen om te beoordelen, super idee om me te helpen mijn code te verbeteren.
@RuiFRibeiro Dit is waar.Het is ook belangrijk om feedback te leren filteren.Het is geen klein punt.Er is een boek "Bedankt voor de feedback" Stone & Heen waar ik aan heb gewerkt om hieraan te werken.Mijn aanbeveling is om te oefenen, of het nu in een veilige omgeving is zoals TM of op een andere manier, kom alsjeblieft in je praktijk.
#17
+5
JimmyJames
2016-11-19 04:19:41 UTC
view on stackexchange narkive permalink

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

U zegt dat dit een 'groot' bedrijf is. Ik weet niet hoe het is in Frankrijk, maar vaak hechten grotere bedrijven geen waarde aan interne ontwikkelaarsvaardigheden, vooral als het geen technologiegerichte bedrijven zijn. Ik schrijf dit vooral toe aan het feit dat managers in dergelijke bedrijven vaak geen technische achtergrond hebben of afstand nemen van ontwikkeling omdat ze er nooit zo goed in waren.

Er is ook een historisch aspect van verkopers die tools verkopen die verondersteld om de behoefte aan getalenteerde ontwikkelaars weg te nemen. Zelfs als uw team een ​​van deze vreselijke dingen niet gebruikt, bestaat de kans dat het management van het bedrijf geïndoctrineerd is in een anti-intellectueel idee van ontwikkelingsteams. Ik heb eigenlijk een manager gehad die me in mijn gezicht vertelde dat ik slim genoeg was om een ​​bepaalde oplossing te bouwen, maar dat niemand anders het zou kunnen onderhouden, dus moesten we iets kopen (plankgoed). Dus ik geloof dat dit kan gebeuren .

Mogelijk moet u op zoek naar een ander soort bedrijf. Een die zeer bekwame ontwikkelaars waardeert. Misschien moet je er echter mee worstelen dat je daar niet de beste ontwikkelaar bent. Als je een aspirant-chef was, zou je waarschijnlijk ongelukkig zijn bij McDonald's. Ze hebben geen koks nodig. Ze hebben mensen nodig die een recept volgen. Je bent misschien chef-kok en dit bedrijf (en anderen vinden het leuk) is McDonald's. De vraag die je jezelf moet stellen, is waarom je dit nog niet hebt gedaan.

Nice chef / McD analogie - ja, of "te veel koks bederven de bouillon"
uw hypothese over de "grands comptes" van Frankrijk (grote vissen, vooral banken) is absoluut waar.Ik heb daar alleen "slimme" code gemaakt als ik geen keus had.In de meeste gevallen was doen zoals anderen deden, gewoon schoner, genoeg om het werk te doen - en om leesbaar te zijn.En ik had niet verwacht dat mijn weinige slimme programma's door iemand anders kunnen worden onderhouden.
#18
+5
user45019
2016-11-19 05:48:47 UTC
view on stackexchange narkive permalink

TL; DR: vind een geschiktere werkplek en wees eerlijk over de vaardigheden die je nog moet leren.

Je klinkt voor mij als de "softwarevakmanschap" -stijl van ontwikkelaar - geïnteresseerd in best practices, en altijd goede manieren vinden en volgen om dingen in code te doen. Misschien zou je gelukkiger zijn in een omgeving waar andere ontwikkelaars meer geïnteresseerd zijn in dat soort dingen - en er zijn genoeg van dergelijke werkplekken.

Sommige dingen die je hebt gezegd, wekken echter de indruk dat je soms denkt dat er één 'beste manier' is om dingen in code te doen die altijd gevolgd moeten worden. Misschien heb ik het daar niet bij, maar als ik gelijk heb, dan moet je misschien wat leren als het gaat om het onderzoeken van de voor- en nadelen van alternatieve keuzes en het vinden van de manier die de beste balans voor het bedrijf biedt. In feite zal ik zeggen dat je daar zeker moet verbeteren - omdat we allemaal doen!

#19
+3
anon
2016-11-19 09:53:49 UTC
view on stackexchange narkive permalink

Soms, als je met anderen praat, moet je het "dom" houden zodat je mensen niet beledigt. Vooral als je ver boven de anderen staat met wie je werkt, zullen ze waarschijnlijk beledigd zijn als je praat over tips en feiten die ze waarschijnlijk zouden moeten weten, maar niet.

Ik zou zeggen om heel goed commentaar te geven op je werk, zodat mensen die het controleren het kunnen begrijpen. Mogelijk moet u zelfs "rechtvaardigen" waarom u die coderingsmethode kiest in plaats van een andere in uw opmerkingen. Je bent misschien wel de beste coder, maar als je in een team zit, moet je als een team werken.

Als werken als team betekent dat je met één hand achter je rug moet werken (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 van binnen schreeuwt).

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

#20
+3
UmNyobe
2016-11-21 23:05:12 UTC
view on stackexchange narkive permalink

Hoe kan ik dit in de toekomst vermijden?

Werk met niemand samen tenzij je redelijkerwijs zeker weet dat hun coderingsstandaard overeenkomt met die van jou. Dat betekent elke baan weigeren als geen van de volgende zaken van toepassing is:

  • Ze stellen je programmeervragen tijdens hun sollicitatieproces
  • Ze hebben oefeningen voor peer-programmeren
  • Ze vragen om een ​​codevoorbeeld en vinden het goed
  • Je kunt een deel van de code zien die ze hebben geproduceerd

Hoe kan ik voorkomen dit in het heden?

Dit is behandeld door andere antwoorden.

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

Je moet peer-programmeren en codereview aanmoedigen. Ga bij een andere programmeur zitten en probeer 2 of 3 uur samen te coderen. Schrap concepten die misschien te moeilijk uit te leggen zijn (nieuwe geavanceerde Java 8-functies bijvoorbeeld), en leg de eenvoudiger uit (overerving).

Ja, het punt is dat ik deze allemaal heb voorgesteld.Antwoord was: "we hebben geen tijd om te leren".
dan komen hun cultuur en die van jou niet overeen.Op andere plaatsen is zeggen "Ik heb geen tijd om te leren" een goede manier om beëindigd te worden.
Mee eens :) Ik vertrek aanstaande vrijdag.
#21
+1
user8365
2016-11-19 00:16:35 UTC
view on stackexchange narkive permalink

Je klinkt alsof je een programmeur bent die goed genoeg is om je aan veel situaties aan te passen. Kijk hoe anderen coderen en dienovereenkomstig handelen. Vraag af en toe of je verschillende manieren kunt proberen en zorg ervoor dat het niet te veel verder gaat dan wat anderen kunnen begrijpen.

Normaal gesproken zou ik dit advies niet geven, maar dit probleem lijkt je overal te volgen ga, dus stop met vechten totdat je een baan kunt vinden waar dit geen probleem is. Je zou kunnen overwegen om betrokken te raken bij een project waar er een klein aantal andere ontwikkelaars is die je zou kunnen helpen meenemen, zodat het niet lijkt alsof jij alleen zo "abnormaal" programmeert.

Het is jammer anderen waarderen uw werk niet of willen ervan leren als dat het geval is. Stop met je hoofd tegen de muur te slaan. Wie weet komt er een project / taak naar voren waarvan jij de enige hoop bent om het te laten werken. Het zal niemand schelen hoe ingewikkeld uw code op de lange termijn is als u hem gewoon laat werken terwijl niemand anders dat kan.

We waren 3 ontwikkelaars in het team.
Elke dag leg ik ze enkele programmeertips uit, en ze genoten er grotendeels van.Het probleem is dat terwijl ze blij waren om me erover te horen praten, in hun geest een soort minderwaardigheidscomplex was geïnstalleerd.Dat was het begin van de reactie van mijn manager.
@Mik378 Elke dag is veel, veel te vaak.Kies een simpele verandering die een grote uitbetaling zou opleveren.Laat het verschil zien tussen de code die op de gebruikelijke manier van het team is geschreven en uw voorstel.Laat dat een tijdje inzinken, voordat je iets anders probeert.
"en ze genoten er grotendeels van" - weet je dat zeker?misschien zijn ze gewoon beleefd.Hoe kan iemand die zich minderwaardig voelt, "er grotendeels van genieten".Uw verklaring is niet consistent.
@Mik378 als u niets anders van deze vraag oppikt, moet u de opmerking van Brad Thomas geloven - het is waarschijnlijk de sleutel tot uw situatie.
#22
-2
CoffeDeveloper
2016-11-23 18:59:24 UTC
view on stackexchange narkive permalink

We kunnen op lange termijn niet op hem vertrouwen

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

U kunt ofwel het management kalmeren met:

  • U overweegt sowieso niet ergens anders heen te gaan, zodat zij op de lange termijn op u kunnen rekenen.

Ik denk dat ik word uitgedaagd met problemen waardoor mijn vaardigheid wordt aangewend, dus ik denk dat ik eindelijk een werkplek vind waar ik nog lang van kan genieten

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

Ik heb gemerkt dat de code van anderen niet echt up-to-date is met geavanceerde softwareontwikkelingstechnieken , het is geen probleem, ik kan helemaal stoppen met het gebruik van die technieken, maar het zou goed zijn als iedereen die technieken geleidelijk gaat gebruiken om de prestaties van het team te verbeteren. Ik kan daarbij helpen.

  • Je werd gevraagd om features XY te implementeren, aangezien features die binnen de tijd verscheept werden je vaardigheid nodig had, had je dingen op verschillende manieren kunnen doen, maar op veel meer tijd en met het risico van extra bugs.

Mag ik wat extra tijd hebben om de volgende functies af te werken? Ik heb echt hard gewerkt om dingen goed voor elkaar 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 bewering niet van toepassing is (ik weet nu niet wat je hebt gedaan), lieg dan nooit.

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

#23
-2
Christos Hayward
2016-11-26 23:15:51 UTC
view on stackexchange narkive permalink

Lees The Wagon, the Blackbird en de Saab . Het zou met je moeten resoneren.

Ik heb in het verleden soortgelijke problemen gehad; Ik heb een aantal dingen geleerd over hoe je moet omgaan, maar we hebben allebei een dweil en een emmer gebruikt om te proberen de output van een brandslang op te ruimen.

Ik suggereer hier niet dat je een DSM verdient. V diagnose van de geestelijke gezondheid, maar ik suggereer dat u er misschien goed aan doet om een ​​goede raadgever te zoeken en te werken aan niet-bedreigend gedrag en sociale vaardigheden. U kunt ook Theory of alien minds lezen.



Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...