Cóż, nienawidzę rozbijać twojej bańki, ale jeśli to już trzeci raz, to prawie wyklucza “to nie ty, to oni”. Twój tytuł mówi, że zostałeś zwolniony za bycie “nieodzownym”, ale poza tym, że byłeś oksymoronem, to też nie to, co się stało. Zostałeś zwolniony za pisanie kodu, którego twoi koledzy nie potrafią zrozumieć, co jest krytycznym problemem dla programisty.

Dobry kod to kod czytelny , czyli taki, który jest łatwo zrozumiały, nawet dla nowicjuszy. Sytuacje, w których potrzebujesz skomplikowanego i ciasno napisanego kodu, który powinien być napisany i utrzymywany przez prawdziwych ekspertów, są w dzisiejszych czasach bardzo rzadkie i najwyraźniej nie pracowałeś dla tego typu firm. To, co opisujesz, brzmi bardziej jak “fantazyjny” kod, który jest zazwyczaj zbyt skomplikowany, pełen ezoterycznych sztuczek programistycznych i zajmuje wieki, aby go zrozumieć i debugować. Jest to częste niepowodzenie dla ludzi, którzy byli klasycznie szkoleni i zazwyczaj niegrzecznie budzą się po wejściu do środowiska produkcyjnego.

It’s not a żart, I could not stand to have this happen a fourth time, it’s impacting me mentally.

This line is important, because it shows that you feel it is time to change. Pokazuje, że rozpoznajesz to jako wzór, i chciałbyś, aby wzór się zatrzymał. To pragnienie jest prawdopodobnie najważniejszą częścią rozwiązania. Naprawianie tego typu sytuacji często wiąże się ze zmianą sposobu myślenia. Ktoś nie jest w stanie tego zrobić dla Ciebie, więc Twoje pragnienie zmiany będzie jedyną rzeczą, która sprawia, że zmiana się dokonuje.

W pewnym kontekście, byłem już wcześniej w podobnych sytuacjach “zbyt dobry w kodowaniu dla mojej pracy”, choć nigdy w stopniu, który opisujesz. Mógłbym leczyć raka za pomocą metaprogramowania szablonów w C++, ale wielu z nich, z którymi pracuję, ledwo zna podstawy projektowania zorientowanego na obiekty. Napisałem kod, który nadużywał SFINAE i podepchnął się pod dokładne brzmienie specyfikacji C++, kiedy wiele projektów, nad którymi pracowałem, nadal używało przestarzałych i buggy wersji gcc. Moje podejście polegało po prostu na pokazaniu im, jak niesamowite są te narzędzia i wszystkie problemy, które mogły rozwiązać. Uwielbiałem wyjaśniać ludziom małe wskazówki dotyczące programowania i bardzo im się to podobało.

Czy to brzmi znajomo?

“Tak, ale trzeba mieć dobry poziom zrozumienia [kodu Mik'a], ponieważ komponenty są inteligentnie odsprzężone”

Rozważ to stwierdzenie z perspektywy ryzyka. Twój szef musi dbać o to, by wszystko się działo, bez względu na wszystko. Jeśli wyjdziesz na poszukiwanie jakiejś niesamowitej okazji do pracy, Twój szef nadal musi się upewnić, że kod zostanie utrzymany. Twój współpracownik właśnie powiedział, że jeśli będzie musiał cię zastąpić, będzie musiał znaleźć bardzo wykwalifikowanego programistę, ponieważ każdy, kto nie jest tak dobry, nie będzie w stanie go utrzymać. To jest ryzyko. Co jeśli nie mogą znaleźć wystarczająco dobrego programisty, albo nie mogą sobie pozwolić na zapłacenie im wystarczająco dużo?

Być może stworzyłeś coś, co nazwałbyś “dobrym kodem”, ale definicja “dobrego kodu” jest very bardzo zależna od kontekstu. Co to jest “dobry kod” w Google, z ich nowatorskimi sposobami myślenia, może być bardzo złym kodem dla kogoś, kto pracuje w FAA, która zajmuje się głównie niezawodnością, a nie nadążaniem za najnowszymi rozwiązaniami. Definicja twojego szefa jako “dobry kod” obejmuje możliwość utrzymania go w różnych sytuacjach, również bez ciebie. Jeśli twoi współpracownicy nie czują się komfortowo z utrzymaniem kodu, to nagle stajesz się odpowiedzialny dla firmy, ponieważ produkujesz produkt, którego nie mogą utrzymać, jeśli zdecydujesz się pójść gdzie indziej.

Z tej perspektywy można argumentować, że zmuszasz ich do zaakceptowania twojej definicji “dobrego kodu”. Instynktownie może się to wydawać dobre, ale jest to trudne, jak na przykład ten ryzykowny sposób myślenia, o którym być może nie myślałeś.

Mamy sformułowanie: “postawienie wozu przed koniem”. Jednym z wielu znaczeń z nim związanych jest przedkładanie treści, na których Ci najbardziej zależy (umiejętność korzystania z zaawansowanych technik), nad siły, które powinny go ciągnąć do przodu (zrozumienie tych technik przez współpracownika). Napisałeś kod w tym zaawansowanym stylu, a następnie zachęciłeś innych programistów do “dogonienia” tego stylu. Może to być skuteczne, ale jeśli cokolwiek Ci się stanie zanim “dogonią”, firma jest nagle zagrożona, ponieważ nikt nie jest w stanie utrzymać kodu.

Jak mogę tego uniknąć w przyszłości?

Naprawa tego może być strasznie trudna do zrobienia, ponieważ wiąże się z podejściem do problemu w inny sposób, niż jest to zazwyczaj wygodne. Zamiast najpierw pisać kod w tym zaawansowanym stylu, a następnie uczyć współpracowników jak myśleć w ten sposób, powinieneś go odwrócić. Naucz swoich współpracowników lubić ten styl kodowania, a następnie zacznij pisać kod w tym stylu. Może się wydawać, że jest wsteczny, ale jest znacznie bardziej stabilny. Z perspektywy szefa, nie ma większego ryzyka, że zespół nauczy się lepiej kodować. Kiedy już kodują lepiej, styl, w którym chcesz się rozwijać jest nagle mniej ryzykowny.

W międzyczasie, będziesz musiał napisać kod, który według twoich standardów jest “mniej dobry”, ale to jest w porządku. Twój kod nie jest twoim jedynym produktem tutaj. Twój drugi produkt pomaga uczyć innych programistów, a jego wartość może łatwo przekroczyć wartość pisania “doskonałego kodu”.

Oczywiście, trudno jest stwierdzić, kiedy bezpiecznie jest pisać kod w stylu, który chcesz napisać. Gdyby było to łatwe do rozpoznania, na pewno już byś to zrozumiał! Jedną z potężnych technik, których możesz użyć jest pozwalanie innym na naciskanie na zaawansowane style kodowania, a nie naciskanie na to samemu. Jedną rzeczą jest nauczyć kogoś różnicy między dziedziczeniem a kompozycją. Zupełnie inną rzeczą jest nauczenie ich na tyle dobrze, że opowiadają się za zmianą istniejącej bazy kodowej, aby była ona bardziej przejrzysta w momencie jej używania. Ten ostatni przypadek naprawdę daje ci do zrozumienia, że nie tylko oni dostają pojęcie, ale prawdziwie go ogarnąć.

Ideałem do nauczania takich koncepcji jest nie uczyć niczego. Pozwól uczniom coś odkryć, a następnie wskażesz im kierunek, w którym odkrycie może iść. Może jeden z nich odkryje coś schludnego w dziedzictwie, a Ty skierujesz ich w stronę wzorca projektowego Visitora opartego na tym, co odkryli. Nie dawaj im tylko Gościa, ale daj im poczucie kierunku, aby sami mogli wyjść i znaleźć Gościa.

To znacznie trudniejsze podejście i z pewnością będziesz chciał znaleźć szczęśliwy środek pomiędzy tym a Twoim obecnym podejściem, ale może być bardzo satysfakcjonujące. Co ważniejsze dla Twojej odpowiedzi, może zapewnić wartość dodaną dla firmy bez ryzyka. Jeśli zapewniasz wartość firmie, a nie narażasz jej na ryzyko, to praktycznie nigdy nie zostaniesz zwolniony. A w kilku przypadkach, w których nadal możesz zostać zwolniony, kierownictwo poda powód (np. spowolnienie gospodarcze lub zmiana kierunku rozwoju firmy). Jeśli zrobisz to bardzo dobrze, zauważysz, że kierownictwo zamiast tego zacznie kształtować twoją ścieżkę, tak jak kształcisz swoich współpracowników, i znajdziesz ciekawą tendencję do uczenia się just odpowiedniej umiejętności just, kiedy najbardziej jej potrzebują.

Zawsze są ku temu powody.

Poprzedni pracodawca zrobił to z moim współpracownikiem. Jego poziom umiejętności znacznie przekraczał nasze możliwości. Więc, został zwolniony.

Dlaczego to ma sens?

1. Tylko on mógł utrzymać swój kod
2. On nie współpracował
3. Nie stosował się do standardów sklepowych
4. Dostarczał więcej niż trzeba, ale to nie było dobre
5. Proste, potrzebne były rozwiązania zamiast skomplikowanych.

Tak często mówi się, że jest to niemal banał, ale trzeba być “dobrze dopasowanym” do zespołu.

Kodowanie to tylko część równania. Musisz być osobą, komunikatywny, do pewnego stopnia skromny, arogancki, gdy jest to potrzebne, trzymać się standardów sklepowych, dogadywać się ze współpracownikami, być przystępny i szybko pomagać, gdy jest to potrzebne.

Wszystkie te umiejętności miękkie są ważne, a nie** posiadanie ich sprawi Ci kłopoty.

Dobry kod jest łatwy do zrozumienia, nawet dla biednych inżynierów. Jedna z rad, które często otrzymywałem, to “program jak gdyby osoba, która będzie utrzymywać twój kod, była mierną programistką i niebezpiecznym psychopatą, który wie, gdzie mieszkasz”.

I to jest prawda. Zbyt sprytne programowanie jest złe, ponieważ konserwacja jest dłuższa wtedy nie znasz kodu. W konserwacji często masz wszędzie pożar, tysiące klientów jest zablokowanych, a sprytniejsze i bardziej efektywne rozwiązanie może sprawić, że opiekun utknie dłużej niż głupi kod podobny do skryptu pełnego powtórzeń.

Oczywiście, całkowicie głupi kod też jest zły. Trzeba znaleźć równowagę pomiędzy głupimi i geniuszami: wydajny i wciąż czytelny. Jest to bardziej sztuka niż nauka. Dlatego właśnie mądre koncepcje, takie jak wielokrotne dziedziczenie zazwyczaj nie są zalecane . Nawet jeśli są rockowe.

Trzeba wziąć pod uwagę kontekst. Jeśli pracujesz w małej firmie, która zatrudnia tylko najlepszych, prawdopodobnie stać cię na jakieś egzotyczne, genialne rzeczy. Jeśli pracujesz we francuskim banku, który opiera się tylko na konsultantach o, errrm, przypadkowej jakości (czasami mają szczęście, czasami nie), i gdzie każdy konsultant ma domenę milionów LOC do utrzymania, to na wszelki wypadek sprawić, aby było to wystarczająco proste dla przeciętnego, aby zrozumieć to na pierwszy rzut oka. Żadnych wskazówek, żadnego wielokrotnego dziedziczenia, żadnych sprytnych sztuczek, itp…

To mało prawdopodobne, że zostaniesz zwolniony, bo jesteś zbyt dobry. To chyba tylko wymówka.

Bardziej prawdopodobne, że to kwestia zachowania, albo szef po prostu cię nie lubi z powodów, których nie może ci powiedzieć bez stworzenia podstaw do pozwu. Możliwe też, że jesteś najdroższy i wierzą w EPC (tzn. każdy pracownik jest taki sam).

Jeśli naprawdę jesteś taki dobry, możesz stać się niezastąpiony w dobry sposób:

• Mentor młodszych programistów. Opowiedz o zaletach i wadach różnych podejść i pozwól im popełniać błędy, zamiast mówić im, które podejście zastosować.
• Napisz dobry kod, który jest łatwy do utrzymania przez innych ludzi.
• Propaguj najlepsze praktyki w sposób zwiększający produktywność, w przeciwieństwie do kultu cargo najlepszych praktyk, które brzmią dobrze na papierze, ale zabijają produktywność.

Zatrudnianie niezbędnych ludzi to w rzeczywistości rozsądna strategia zarządzania. Kiedy Twoja firma polega na tym, że jedna osoba nadal wykonuje swoją pracę, a nikt inny w firmie nie ma ich wiedzy i/lub umiejętności, tworzy to ogromną odpowiedzialność: co zrobić, jeśli ta osoba zostanie potrącona przez autobus i umrze (stąd określenie “czynnik autobusowy”) lub po prostu zdecyduje się opuścić firmę, aby podjąć nowe wyzwanie? Teraz Twoja firma utknęła w strasznej sytuacji, ponieważ nikt nie może od razu zastąpić niezbędnego pracownika, a Ty nie masz kontroli nad czasem!

Aby zapobiec tej sytuacji, firma ma dwie opcje. Albo mogą próbować rozpowszechniać wiedzę i/lub zwiększać umiejętności współpracowników niezbędnej osoby, albo za jednym zamachem zwolnić niezbędną osobę w momencie, gdy jest ona do tego przygotowana.

Ponieważ nie zawsze praktyczne jest wypełnienie dużej luki w wiedzy, a zwłaszcza w umiejętnościach, zwolnienie ich może być bardziej logicznym wyborem.

Jako pracownik, powinieneś zawsze próbować zapobiegać staniu się niezbędnym. Podziel się swoją wiedzą z kolegami i upewnij się, że są ludzie, którzy mogą wykonywać Twoją pracę, kiedy Cię nie ma. Upewnij się, że Twoje praktyki są odpowiednie dla pracowników o średnim poziomie umiejętności w Twojej firmie. Jeśli uważasz, że średni poziom jest zbyt niski, współpracuj z kierownictwem, aby spróbować zwiększyć ten poziom. Upewnij się, że wszystko co tworzysz jest dobrze udokumentowane i że ta dokumentacja jest na tyle wysoka, że każdy z twoich kolegów może ją wykorzystać do kontynuowania pracy.

Jeśli jedyną wspólną cechą tych trzech sytuacji jesteś Ty, to musisz uznać, że coś, co robisz, stanowi problem.

Czy rozmawiałeś z byłymi współpracownikami i poprosiłeś ich o krytykę? Nie twój kodeks, ale twoje zachowanie w biurze. Sposób, w jaki komunikujesz się ze swoimi współpracownikami, sposób, w jaki komunikujesz się ze swoim szefem, sposób, w jaki sporządzasz dokumentację, jak zachowujesz się na spotkaniach, itp.

Czy postawiłeś się na stanowisku swojego przełożonego? Naprawdę zastanawiałeś się nad tym, co musi robić, jakie są jego obowiązki, co sprawia, że czuje się dobrze, gdy wyłącza światło w biurze i wraca do domu? Jest wiele, wiele przykładów, gdzie ktoś pisze niesamowity kod _ z perspektywy innych inżynierów oprogramowania_, ale firma zawodzi.

Spojrzałem na twój profil, napisano w nim “twój kod powinien być czystszy od ciebie”. Również z twoich komentarzy wynika, że “spędziłeś dużo czasu na wyjaśnianiu koncepcji” i “krytykowanie jest częścią mojej pracy jako inżyniera”… Myślę, że chętnie udzielasz rad, a twoje rady po prostu nie są doceniane przez kolegów z zespołu.

Może to być spowodowane tym, co mówisz, lub sposobem, w jaki to mówisz, prawdopodobnie niektóre z obu.

Pisanie produktywnego i łatwego w utrzymaniu kodu nie spowoduje, że zostaniesz zwolniony. Zostaniesz zwolniony, jeśli nie będziesz mógł współpracować z zespołem. To jest twój problem, a nie (jak sobie wyobrażasz) twój kod jest zbyt dobry. Twój kod może być naprawdę dobry - ale MUCH bardziej prawdopodobne jest, że jest to problem zderzenia osobowości.

Moja rada dla Ciebie, nie jest to ogon, który próbuje postawić psa. Trzymaj głowę nisko, przestań mówić ludziom, jak kodować, podążaj za wskazówkami, pracuj dobrze z innymi, pisz kod, który można utrzymać. I wtedy nie zostaniesz zwolniony.

Z zainteresowaniem odnotowuję również ten wymowny komentarz twojego menedżera:

“Ale czy to jest naprawdę dobre, jak on udaje?”

To co ci mówi to to, że wasz menedżer nie ufa ci, twój menedżer myśli, że jesteś nieautentyczny i uważa, że jesteś arogancki i/lub masz większy szacunek dla swoich własnych zdolności niż w rzeczywistości. Relacje zależą od zaufania, aby przetrwać. Zwróć uwagę, że twój problem jest nie problemem technicznym. Twój problem ma bardzo niewiele wspólnego z jakością Twojego kodu. To, co masz, to problem ze sposobem, w jaki odnosisz się do swoich kolegów i menedżera.

Ludzie nie są często zwalniani za bycie nieodzownymi dlaczego ludzie są zwalniani ); To niedorzeczne twierdzenie. Artykuł, do którego się odwołujesz wyraźnie kwalifikuje, że “ogień” nie musi oznaczać zwolnienia, ale raczej, że nie jest niezbędny (poprzez przenoszenie ich, zmuszanie do nie angażowania się w konkretny projekt, etc.)

Podczas gdy osoby z wyższymi kwalifikacjami czasami nie dają się zatrudnić - rzadko też dają się zwolnić. Dobrzy pracownicy są bardzo trudni do znalezienia; żadna rozsądna firma nie pozbędzie się jednego z nich, ponieważ są zbyt dobrzy (chyba, że pracujesz tylko dla kretyna - wtedy robią ci przysługę).

Ludzie zostają zwolnieni, ponieważ MYŚLą, że są niezbędni i lepsi od swoich rówieśników i dlatego odmawiają dokonania zmian, które muszą być dokonane w człowieku w lustrze, aby dobrze funkcjonować w zespole. zwolniony za złe nastawienie )

Jeśli budujesz most z bandą tubylców i wyciągasz laptopa, podczas gdy reszta wiąże linę - możesz być mądrzejszy lub bardziej wykształcony, ale stałeś się szkodliwy dla zespołu i problemem jest TY.

Jeśli jesteś naprawdę tak świetny, jak się wydajesz, byłbyś na tyle inteligentny, aby dostosować swoje własne działania, aby uczynić możliwie najbardziej produktywnym ZESPÓŁ vs. dogmatycznie popychając własny plan działania (co prawdopodobnie robisz). Gdybyś to robił, prawdopodobnie miałbyś pracę przez bardzo długi czas.

Jako ktoś, kto regularnie bierze udział w procesie zatrudniania, każdego dnia będę brał kogoś, kto jest dobry i kompetentny ponad kogoś, kto jest świetny i może mieć raka.

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.

Czytałem o tym, że od pierwszego dnia w pracy byłeś przeznaczony na to leczenie. Powiedziałeś, że zostałeś zatrudniony, ponieważ posiadasz umiejętności, których nikt inny w organizacji nie posiada (TypeScript, Node). A teraz, gdy masz do czynienia z eleganckim, fachowo wykonanym, złożonym rozwiązaniem wszystko sam, nikt nie rozumie, co zrobiłeś, i dlatego jesteś postrzegany jako zobowiązanie przez kierownictwo.

Jeśli to wszystko jest prawdą, to naprawdę nie ma innego sposobu, aby to mogło się okazać.

Moim zdaniem problem ma charakter strukturalny, a nie osobisty, dlatego też wina leży po stronie sytuacji i procesu, a nie osoby:

• Organizacja zatrudniła jedną osobę o zupełnie innych umiejętnościach niż wszyscy inni, i to na zaawansowanym poziomie tych umiejętności, do pełnienia funkcji krytycznej. Gwarantuje to, że jeśli dobrze wykonasz swoją pracę, będziesz jedyną osobą, która rozumie kod, który jest krytyczny dla misji organizacji. (Zupełnie nierozsądne jest oczekiwanie, że zasoby na wyższym poziomie będą tworzyć kod, który od razu ma sens dla ludzi, którzy nie znają używanego języka)
• Organizacja nie poddawała cię regularnie procesowi przeglądu kodu. Gdyby tak było, Twój kod zostałby odrzucony, dopóki nie dostosowałbyś go do standardów jego czytelności. Ponieważ jesteś jedynym twórcą kodu, z własnym stylem i przy użyciu innego stosu technologii, jest praktycznie gwarantowane, że z czasem kod stanie się coraz mniej zrozumiały dla innych. Jedynym sposobem, aby temu zapobiec, jest poproszenie innych o recenzję kodeksu poza procesem, stale, być może wyciągając oskarżenia o marnowanie cudzego czasu. Brak procesu recenzji kodu ustawia Cię w ten sposób na niepowodzenie.

Mam podobne doświadczenia w moim otoczeniu. Zostałem kiedyś zatrudniony, aby wypełnić lukę w umiejętnościach. Nikt inny w firmie nie miał umiejętności, których nagle potrzebował. Dobrze wykonywałem swoją pracę i po kilku miesiącach rozpoczął się konflikt. Byłam jedyną osobą, która mogła pracować z określonymi elementami aplikacji. Stałem się wąskim gardłem, ponieważ praca spiętrzała się tak, że tylko ja mogłem ją wykonywać. Pewnego dnia zostałem odsunięty na bok, ponieważ firma zdecydowała się zastąpić wszystko, co wyprodukowałem, zupełnie nowym kodem, zrobionym po swojemu. Moja duma została wtedy zraniona, ale z perspektywy czasu, była to właściwa decyzja dla firmy. Po jakimś czasie nadszedł czas, żebym ruszył dalej, i to zrobiłem.

Jeśli to brzmi znajomo, to może czas, żebyś ruszył dalej. Może kierownictwo nawet przekwalifikuje Cię do czegoś innego, jeśli nadal będzie doceniać Twoje umiejętności. Albo, jeśli potrafisz to przełamać, może pomożesz przepisać wszystko, co zrobiłeś w korporacyjnym stosie standardowych technologii. Jeśli to nie jest możliwe, po prostu odejdź. Tak czy inaczej, twój kod jest prawdopodobnie w drodze do śmietnika. Jeśli nikt inny tego nie zrozumie, to pewnie tak należy zrobić. W każdym razie jest to naturalna konsekwencja ich wyborów.

Upewnij się, że w Twojej następnej pracy inni w Twoim zespole stosują zasadniczo te same umiejętności co Ty, a zwłaszcza, że mają proces weryfikacji kodu. Kiedy poproszą Cię o zmianę kodu w określony sposób, zrób to. Nie uważaj, że kod został dostarczony, dopóki nie przejdzie recenzji kodu, a twoi rówieśnicy nie powiedzą kierownictwu (jeśli zostaniesz o to poproszony), tak, kod jest dobry. Wtedy nie ma żadnego problemu. To całkowicie OK zadawać pytania o takie rzeczy w wywiadzie technicznym; robiłem to już wiele razy. Miejmy nadzieję, że ten drugi programista, który studiował twój kod, da ci dobre referencje.

Jako przypis, jeśli jesteś przynajmniej częściowo odpowiedzialny za swoje okoliczności pracy w pojedynkę, bez wykupu od innych członków zespołu, to zasługujesz na przynajmniej część odpowiedzialności za wynik. (Czy naciskałeś na używanie TypeScript / Node, kiedy inni chcieli użyć czegoś innego? Czy korzystałeś z najnowszej, najfajniejszej biblioteki lub techniki, nawet jeśli coś bardziej podstawowego by się udało? Raz czy dwa razy też byłem temu winny). Jeśli tak, upewnij się, że wyciągnąłeś wnioski z tego wyniku. Ale jeśli nie, weź to doświadczenie na swoją następną pozycję z głową wysoko.

Większość odpowiedzi traktowała Twój post z punktu widzenia tego, czy Twój kod jest czytelny, czy też nie, lub czy jest tak dobry, jak mówisz. Ale ta sytuacja może i zdarza się we wszystkich dziedzinach życia. Podjąłem pracę w Las Vegas Strip jako 21 dealer i floorman. Moje techniki i tempo wyprzedzały tak bardzo resztę ich personelu, że ludzie przydzieleni do obserwacji mnie nie mogli nadążyć. Innymi słowy, nie mogli nadążać za moimi decyzjami. Ponieważ w ciągu kilku minut dokonywano transakcji na duże sumy pieniędzy, często czuli się zdezorientowani i zgłaszali mnie swojemu przełożonemu, twierdząc, że popełniłem błąd. Zawsze mściłem się przed tą osobą, ale postawa nieufności wobec mnie pogłębiała się.

Moje ego i podejrzewam, że twoje nie widziało znaków ostrzegawczych i rzeczywiście objawiłem się w swojej wyższości, wylewając ją na mnie, że tak powiem. Zostałam zlikwidowana i straciłam bardzo dobrą pozycję płatniczą.

Lekcja jest prosta, musisz manekinować do poziomu pozostałych. Jeśli dostaną tylko 15 rąk na godzinę, a ty dostaniesz 100, to nie będzie to dla ciebie inspiracją do pochwał. Inspirujesz zazdrość, a nawet nienawiść. Jeśli twoja duma nie może tego zrobić, musisz znaleźć jakiś inny sposób na zarabianie na życie, ponieważ wszystkie miejsca są w zasadzie takie same. Ludzie są ludźmi, nie możesz ich zmienić. W końcu osiedliłem się w innych dziedzinach pracy, gdzie też byłem mierny i przez to nie wyróżniałem się. Mam nadzieję, że uda ci się to załatwić na swoją korzyść.

Zdecydowałem się uaktualnić mój komentarz do odpowiedzi:

Dokumentuj swój kod bardzo dobrze.

Właściwa dokumentacja kodu zamienia złe doświadczenia, gdy junior dev walnie głową w niezrozumiałą ścianę przez wiele godzin w potencjalne doświadczenia edukacyjne.

Możliwe, że po prostu nie jesteście tak dobrzy, jak wam się wydaje, ale ze względu na grzeczność założę, że wiecie, jak napisać odpowiednią ilość skomplikowanego kodu, aby zredukować złożoność i wymagania czasowe całej bazy kodowej o rząd wielkości. Fakt, że jest to nawet możliwe, jest zaskoczeniem dla wielu idiotów. Uważają oni, że to niesamowita propozycja, a jedynym sposobem, aby ich przekonać, jest pokazanie im.

Ale to wymaga finezji, odwagi i samokontroli. Musisz skupić się na trzech rzeczach przed wszystkimi innymi: udowodnić, że nie jesteś zagrożeniem, sprawić, by ci idioci wyglądali na mądrych i nigdy nie pozwolić, by jeden idiota zorientował się, że wiesz, że jest idiotą. Jeśli nie będziesz w stanie zmusić się do zrobienia tych trzech rzeczy, zawiedziesz i to będzie twoja wina. Pragmatyzm jest koniecznością i nie ma miejsca na dumę.

Choć nie mogę polecić takiego podejścia każdemu, to co zawsze mi się udawało, to czasami ignorować to, co mówią mi wrogie idiotki. Zamiast tego znajduję sposoby na to, co chcę zrobić, produkować najlepsze oprogramowanie, na jakie wielu z nich kiedykolwiek widziało ten kod w bardzo krótkim czasie, i przedstawiam je w taki sposób, że ich szefowie nagradzają je świecącymi pochwałami. Nawet jeśli nie odegrali żadnej roli w jego tworzeniu. Nawet gdy aktywnie się temu przeciwstawiali.

Czy to prawda? Czy nie powinienem otrzymać pełnego uznania za swoją pracę? Czy naprawdę powinienem musieć tańczyć wokół uczuć wszystkich? Nieistotne. To jest rzeczywistość. Jeśli się do niej nie przystosuję, to ja jestem idiotką.

Jest wielu wielu inteligentnych ludzi , którzy uważają, że wysoko wykwalifikowani programiści są niezastąpieni i dlatego ty do ich chcesz. Ale widziałeś już inne odpowiedzi na swoje pytanie - większość menadżerów nie chce zajmować się problemami zespołu o bardzo zróżnicowanym poziomie umiejętności i nie ma opcji, aby przejść na czysto wysokie umiejętności. Oni też niekoniecznie się mylą, problemy są realne, a korzyści płynące z wysokiej jakości kodu, który wykracza poza możliwości większości ludzi, których są w stanie zatrudnić, są znacznie mniejsze.

Jeśli jesteś nawet w przybliżeniu tak dobry, jak mówisz, to jesteś niedopasowany do swojej pracy. Wygląda na to, że powinieneś starać się pracować w miejscu, w którym możesz uczyć się od swoich współpracowników, a współpracownicy mogą zrozumieć Twój kod.

Jeśli straciłeś kilka stanowisk z tego powodu, będziesz wyglądał dość źle dla HR, rekruterów i menedżerów. Miejmy nadzieję, że uda Ci się nawiązać współpracę, spotykając deweloperów o podobnym poziomie umiejętności, którzy mogą poręczyć, że problem polega na tym, że Twój poziom umiejętności jest zbyt wysoki.

Na koniec muszę dodać, że powinieneś zrobić wszystko, co w Twojej mocy, aby uczciwie ocenić, czy Twój poziom umiejętności jest naprawdę tak wysoki. Brzmi jakby istniały dowody na to, że tak jest, ale większość ludzi uważa, że są lepsi niż są. Również wielu programistów przechodzi przez etap, w którym są bardzo dobrzy w jednym podejściu, ale jeszcze nie zawsze składają wszystko razem w optymalne rozwiązanie globalne i wciąż brakuje im elastyczności. Na przykład, czasami najlepszym rozwiązaniem może być zastosowanie gorszego rozwiązania, które znasz ludzi, których możesz utrzymać, jeśli wiesz, że nie są w stanie utrzymać bardziej wyszukanego rozwiązania i prawdopodobnie nie zatrudnią nikogo innego, kto potrafi.

Aby odpowiedzieć na to pytanie konkretnie,

Jak mogę tego uniknąć w przyszłości?

• Znajdź lokalny oddział Toastmasterów, weź aktywny udział i zdobądź osiągnięcia. Coś, co wydaje się tak oczywiste jak informacja zwrotna, miejmy nadzieję, że zostanie docenione i wyostrzone w jedną z Twoich najbardziej cenionych umiejętności.

• Praktyka bycia studentem zamiast ekspertem. Czy widziałeś ten Jon Skeet mówiący o podstawach ? Czy możesz sobie wyobrazić, jak wiele więcej zrozumienia można osiągnąć, gdybyśmy wszyscy tworzyli taką dokumentację, przyniosłoby to korzyści wszystkim, na wszystkich poziomach zespołu!

• Zespół nie jest jedną osobą. Twój zespół będzie się rozwijał i doskonalił zbiorowo. Musisz pomóc. To nie jest zespół, jeśli każdy członek jest komórką podążającą w różnych kierunkach (np. ty wyższy, a najnowszy członek stagnacją). 2 godzinne spotkania to dobry początek. Dodałbym do tego rotację parowania na N-day. To jest 1:1 raz, kiedy ty gift do kolegów z drużyny i oni gift do ciebie. W twoim przypadku, pochyl się do roli nawigatora, i pozwól swojemu partnerowi prowadzić. Ćwicz nie pisanie kodu, jak dziwnie to brzmi.

• Ochotnik na lokalnym Meetupie i Hack-a-thons. To może zmusić cię do destylacji kodu, ponieważ celem jest współpraca, a nie budowanie odpornej na błędy sieci energetycznej, prawda?

• W każdym z tych ćwiczeń, spróbuj tej koncepcji: przywództwo przez służbę. Jak możesz wykonać zadanie lub coś osiągnąć, aby pomóc innym członkom zespołu?

• Jak zaznaczono, przyczyniaj się do projektów open source, aby uzyskać więcej punktów widzenia na swój kod. Mogą one potwierdzić, że jesteś genialny, ale również wzmocnić sugestie, które słyszysz od swojego obecnego szefa. W najlepszym wypadku, niektóre recenzje dadzą ci nowy pomysł.

• Znajdź inżyniera, który jest lepszy od ciebie. To nie jest doskonalenie się, aby być najmądrzejszym facetem w tym pokoju. Istnieje cytat (mój googling jest podzielony na Olgivy/Ford/Sorkin) parafrazujący: “Nie możesz się więcej nauczyć, jeśli otaczasz się złym talentem”.

Zakładam, że twój opis sytuacji jest taki, jak mówisz. Nie mogę powiedzieć, że miałem takie doświadczenie, ale są pewne aspekty, które są mi znane.

Mówisz, że to jest “duża” firma. Nie wiem, jak to jest we Francji, ale często większe firmy nie cenią sobie wewnętrznych umiejętności programistycznych, zwłaszcza jeśli nie są firmami zorientowanymi na technologię. Przypisuję to głównie temu, że menedżerowie w takich firmach często nie są z zaplecza technicznego lub odchodzą od rozwoju, ponieważ nigdy nie byli w tym tak dobrzy.

Istnieje również historyczny aspekt sprzedawania narzędzi, które mają wyeliminować zapotrzebowanie na utalentowanych programistów. Nawet jeśli Twój zespół nie używa jednej z tych strasznych rzeczy, istnieje szansa, że kierownictwo firmy zostało indoktrynowane w antyintelektualnym pojęciu zespołów programistycznych. Właściwie miałem menedżera, który powiedział mi prosto w twarz, że byłem na tyle inteligentny, aby zbudować dane rozwiązanie, ale wtedy nikt inny nie byłby w stanie go utrzymać, więc musieliśmy coś kupić (półki.) Więc wierzę, że tak może się stać.

Być może trzeba będzie poszukać innego rodzaju firmy. Takiej, która ceni sobie wysoko wykwalifikowanych programistów. Być może jednak będziesz musiał zmierzyć się z tym, że nie jesteś tam najlepszym programistą. Gdybyś był aspirującym szefem kuchni, prawdopodobnie byłbyś nieszczęśliwy pracując w McDonald’s. Nie potrzebują szefów kuchni. Potrzebują ludzi do przestrzegania przepisu. Możesz być szefem kuchni, a ta firma (i inni to lubią) jest McDonald’s. Pytanie, które musisz sobie zadać, to dlaczego jeszcze tego nie zrobiłeś.

How can I avoid this in the future?

Don’t work with anyone unless you are reasonably ensured that their coding standard match yourrs. Which means refuse any job if none of the following apply:

• They ask you programming questions during their interview process
• They have peer programming exercises
• They ask for a code sample and are ok with it
• You can see some of the code they have produced

How can I avoid this in the present?

This has been covered by other answers.

If you are just that better, get to their level and slowly teach them to be better programmers. Pierwszym razem, kiedy musiałem zarządzać stażystą, prawie wymazałem cały kod, który on stworzył. Byłem dosłownie wściekły, kiedy zobaczyłem, co zostało popełnione (na szczęście nie miałem żadnego świadka :P ).

Musisz zachęcić rówieśników do programowania, recenzji kodu. Usiądź z innym programistą i spróbuj kodować razem przez 2 lub 3 godziny. Zrzuć koncepcje, które mogą być zbyt trudne do wyjaśnienia (np. nowe zaawansowane funkcje Java 8), i wyjaśnij te, które są łatwiejsze (dziedziczenie).

Czasami, kiedy rozmawiasz z innymi, musisz go “wygłupiać”, żeby nie obrazić ludzi. Zwłaszcza jeśli jesteś znacznie wyżej niż inni, z którymi pracujesz, prawdopodobnie obrażają się, kiedy mówisz o wskazówkach i faktach, które prawdopodobnie powinni znać, ale tego nie zrobili.

Powiedziałbym, aby skomentować twoją pracę naprawdę dobrze, tak aby ludzie sprawdzający ją mogli ją zrozumieć. Być może będziesz musiał nawet “uzasadnić”, dlaczego wybrałeś tę metodę kodowania zamiast innej metody wewnątrz swoich komentarzy. Możesz być najlepszym programistą, ale jeśli jesteś w zespole, musisz pracować w zespole.

Jeśli praca w zespole oznacza pracę z jedną ręką za plecami, (przez to rozumiem podążanie za ich preferencjami dotyczącymi kodowania), to zrób to. Przynajmniej wtedy będą mogli to przeczytać, zrozumieć, a sam zespół będzie lepiej (nawet jeśli oznacza to, że krzyczysz w środku).

Prawie wszędzie tam, gdzie jesteś częścią zespołu, będziesz miał wytyczne dotyczące tego, jak mają być kodowane - i musisz ich przestrzegać.

We can’t depend on him in a long-term

That’s the major problem. Nie chcą być zależni od Ciebie, ale zostaliście zatrudnieni, ponieważ tak naprawdę są od Ciebie zależni.

Możesz albo uspokoić kierownictwo za pomocą:

• I tak nie myślisz, że pójdziesz gdzie indziej, więc mogą na Ciebie liczyć na dłuższą metę.

Myślę, że mam problemy, które sprawiają, że moje umiejętności są wykorzystywane, więc myślę, że w końcu znajdę miejsce pracy, które będzie mi się podobało przez długi czas

• Jesteś gotów przeprowadzić szkolenie dla innych członków zespołu, aby zapewnić dodatkową wartość dla zespołu.

Zauważyłem, że kod innych nie jest tak naprawdę na bieżąco z najnowszymi technikami tworzenia oprogramowania, to nie jest problem, mogę całkowicie przestać korzystać z tych technik, jednak korzystne byłoby, gdyby wszyscy zaczęli korzystać z tych technik stopniowo, aby poprawić wydajność zespołu. Mogę w tym pomóc.

• Zostałeś poproszony o implementację funkcji XY, havin że funkcje dostarczone w czasie wymagały twoich umiejętności, rzeczy mogły być zrobione na różne sposoby, ale w znacznie większym czasie i z ryzykiem dodatkowych błędów.

Czy mogę mieć trochę więcej czasu na ukończenie kolejnych funkcji? Naprawdę ciężko pracowałem, aby wszystko było zrobione poprawnie, udało mi się to osiągnąć, ale obawiam się, że nie każdy może to zrozumieć, Zamiast tego chcę poświęcić trochę czasu, aby wszystko było zrozumiałe dla innych.

Bądź szczery, jeśli jakieś stwierdzenie nie ma zastosowania (nie mam teraz na myśli tego, nad czym pracowałeś), nie kłam, nigdy. Tak czy inaczej, co najmniej 2 osoby w zespole rozumieją twoją pracę: Ty i twój współpracownik. I jest szansa, że więcej ludzi będzie w stanie to zrozumieć w przyszłości. W zasadzie nie jesteś wąskim gardłem w swoim zespole, boją się, że możesz nim później zostać. Powinni i tak zainwestować trochę czasu w trening.

Przeczytaj * The Wagon, the Blackbird, and the Saab **. Powinno to z tobą rezonować.

W przeszłości miałem podobne problemy. Nauczyłem się kilku rzeczy o tym, jak radzić sobie z gliniarzami, ale oboje używaliśmy mopa i wiadra, żeby spróbować oczyścić wyjście węża pożarowego.

Nie sugeruję tutaj, żebyś zasłużył na diagnozę zdrowia psychicznego DSM-V, ale sugeruję, żebyś znalazł dobrego doradcę i pracował nad niegroźnymi zachowaniami i umiejętnościami społecznymi. Możesz również przeczytać * Theory of alien minds **.