Radzenie sobie z Fanboyami [zamknięte]

Prawdopodobnie wszyscy spotkaliśmy kogoś takiego, tego programistę, który po prostu wie, że jego język jest jedynym prawdziwym językiem i nie chce się o tym zamykać. Jak sobie radzisz z kimś takim? Nie chcę nikogo obrażać (zwłaszcza, że ​​fanboyem w moim miejscu pracy jest starszy programista). Ale chcę mieć możliwość wyboru własnego języka skryptowego, gdy muszę napisać jednorazowy skrypt, który nigdy nie dotrze do repozytorium i nikt inny nie musi wiedzieć, że istnieje.

Myśli, z którymi miałem do czynienia:

1. Śmiej się - „Haha, może język X jest trochę łatwiejszy, myślę, że jestem masochistą!”
2. Idź z tym - naprawdę wolałbym tego uniknąć, ponieważ nie stać mnie na spadek produktywności związany z wybraniem nowego języka.
3. Ukryj mój język - zostań programistą i ukryj mój monitor za każdym razem, gdy coś piszę lub automatyzuję.

Co zasugerowałbyś w tej sytuacji?

Niewiele rzeczy wyskakuje z pytania.

• Czy to naprawdę scenariusz jednorazowy? Jeśli tak, to dziwne, że się dyskutuje.
• Czy jesteś pewien, że skrypty pozostaną bez zmian? Wiele produkcji było kiedyś scenariuszem jednorazowym.
• Czy zamierzasz przepisać skrypt, jeśli jest promowany i wymaga integracji z systemem?
• Czy wybór języka jest czysto syntaktyczny, czy jest to język z innej sfery?

Rozumiem część fanów-fanów, ponieważ z jednej strony czasami zachowuję się trochę jak fan-boy, jednocześnie chroniąc moje wybrane języki. Miałem też do czynienia z innymi fanami, którzy próbują wprowadzić nowe rzeczy.

Mój pogląd na tę sytuację wygląda następująco:

• Jeśli jest to nowy język, należy do kosza na śmieci.
• Jeśli jest to język sprawdzony w branży, można go użyć, jeśli jest wyspecjalizowany do tego zadania.
• Jeśli jest to bardzo niepopularny język, należy do kosza na śmieci, nawet jeśli jest super fajny i super szybki.

Dzieje się tak, ponieważ nikt nie wie, jak pisać bezpieczne i szybkie oprogramowanie w nieznanym języku i ma to wszystko, czego muszą nauczyć się programiści. Głupi skrypt będzie musiał być obsługiwany przez 20 lat lub przepisany. W ciągu 20 lat co najmniej 50 programistów zmienia się w przeciętnym sklepie. Jeśli każdy napisze kilka fantazyjnych skryptów w nowym języku, potrzebujesz 50 środowisk uruchomieniowych języka, 50 różnych ekspertyz w zespole, a baza kodów zawiera błędny kod w 50 językach. Niektóre języki nie są już obsługiwane w systemie Windows ani Linux. I potrzebuje tego niepakowanego 10-letniego niestandardowego serwera, bez części zamiennych, 24/7.

Ponadto nikt tak naprawdę nie chce obsługiwać martwych języków, takich jak VB, Silverlight, D itp., Kiedy baza kodu prawdopodobnie przeżyje sam język.

Czy decyduje, z czego korzystasz na podstawie zasad firmy? Odwołaj się do niego od swojej sprawy; jeśli nadal zdecyduje się tego nie robić, zamknij się i wykonuj pracę za pomocą narzędzi, o których szef powiedział, że powinieneś użyć.

Ci pracować tam, a nie tam grać. Ostatecznie to nie jest w twoich rękach.

Nawet jeśli nie jest twoim szefem, rozważyłbym wszystkie punkty widzenia. Chciałbyś, gdyby znał Fortran i pewnego dnia odziedziczyłeś cały jego kod. Będziesz musiał nauczyć się nowego języka od zera w locie , to jest strasznie stresujące. Teraz wyobraź sobie jego stronę, możesz pisać swoje skrypty używając Cobola, a on może nie znać Cobola.

Użyj czegoś, co wie większość twojego zespołu.

„2. Idź z tym”

To jedyna rozsądna odpowiedź. Masz tutaj świetną okazję.

• Skorzystaj z komentarzy starszego programisty, aby zachęcić firmę do zapłaty za czas i / lub kurs i / lub certyfikat na naukę nowego języka. Najgorszy scenariusz: zarówno certyfikat, jak i język poprawią twoje CV, możesz uzyskać dobrą rekomendację dla bycia graczem zespołowym i możesz śmiać się aż do lepszej pracy gdzie indziej.

• Zdobyłem cenne informacje na temat programowania z każdego języka, którego się nauczyłem. Nawet najmniej praktyczny język ( kaszel XSLT kaszel ) miał swoją sweet spot i był klin pełne ciekawych możliwości uczenia się (i opłacone rachunki za kilka lat). Ciągłe uczenie się jest jedną z wielkich zalet bycia programistą.

• Wszystkie fajne projekty prawdopodobnie wykorzystują ulubiony język starszego programisty. Znajomość tego języka stawia cię w puli talentów, którzy mogą pracować nad tymi projektami.

• Ktoś prawdopodobnie płaci ci za wykonanie określonej pracy w określony sposób. Każda inna reakcja jest prawdopodobnie niesubordynacją i prawdopodobnie źle się skończy.

Starszy programista / architekt zazwyczaj wybiera podstawowy język używany w sklepie i zapewnia, że ​​wszyscy używają tego języka. W ten sposób firma buduje bazę wiedzy na temat niektórych technologii, aby jeden pracownik (ty) mógł wziąć urlop, a ktoś inny mógł odebrać kod i naprawić go, gdy cię nie będzie. Firma może również zaangażować odpowiednich pracowników szkoleniowych, a dział HR będzie wiedział, jakich modnych słów szukać w CV.

Ucząc się jego języka i wykorzystując go do pracy, gromadzisz kapitał polityczny, którego potrzebujesz, aby skutecznie głosić swój ulubiony język. Wiele firm ma oficjalny język infrastruktury i oficjalny język skryptowy dla raportów. Przygotuj listę zalet i wad, pokazując, gdzie jego język przoduje, a gdzie twój, a także gdzie każdy z nich jest niedoskonały. Tę listę należy przechowywać w kontekście określonej aplikacji, takiej jak pisane raporty. Zaplanuj z nim czas, aby prywatnie iz szacunkiem pokazać mu listę i przedyskutować z nim. Zapisz swoje zastrzeżenia, zbadaj je po spotkaniu, a jeśli masz dobre argumenty, zaplanuj kolejne spotkanie.

Powodzenia!

Pokaż, że w określonym kontekście inny język jest bardziej pragmatycznym wyborem.

Jeśli osoba pasjonuje się C ++ i pracujesz nad projektem aplikacji internetowej, nie byłoby to zbyt trudne. W ten sam sposób niektóre konteksty są bardzo skłonne do programowania funkcjonalnego, a używanie niefunkcjonalnego języka nie byłoby zbyt mądre.

Uwagi:

• Unikaj sytuacji, w których zarówno twój, jak i jego preferowany język są bardzo podobne.

  Na przykład nie wyobrażam sobie kontekstu, w którym Java byłaby „lepsza” niż C # lub C #, „lepsza” niż Java.

• Pamiętaj, że wybór języka jest bardzo często subiektywny i tłumaczy go raczej wcześniejsze doświadczenie dewelopera niż niektóre elementy oparte na dowodach.

  Na przykład, jeśli zostanę poproszony o zrobienie aplikacji związanej z sektorem finansowym, nadal używałbym C # zamiast Haskell, nawet jeśli uważam, że Haskell jest bardziej odpowiedni i naprawdę ekscytujący. Powodem tego wyboru jest to, że mam wieloletnie doświadczenie z C #, ale jeśli chodzi o Haskell, przeczytałem tylko kilka samouczków i nigdy nie użyłem go profesjonalnie.

Odpowiedź brzmi 2) Idź z tym.

1. Jedynym sposobem na zamknięcie fanboya jest płynna (do pewnego stopnia) znajomość wybranego przez niego języka.
2. Utrata wydajności nie stanowi problemu. Robisz tak, jak wymaga tego twój senior, więc zmiany produktywności muszą być uwzględnione w projekcie.
3. Nauka nowego języka poprawi funkcjonowanie mózgu.
4. Nauka otwartości na temat uczenia się nowych języków przyniesie jeszcze więcej korzyści.

Jest wygrana wygrana wygrana wygrana. Cieszyć się!

Odpowiedź brzmi: nie radzisz sobie z tym. Kłócenie się z nimi po prostu sprowadza kłótnię na poziom (gdzie pokonali cię doświadczeniem) i jest ostatecznie niekonstruktywne, ponieważ są blisko umysłu.

Zignoruj ​​wszelkie argumenty za lub przeciw swojemu językowi i zdecyduj o tym. Skorzystaj ze zwykłych technik, takich jak unikanie kontaktu wzrokowego, odpowiadanie monosylabiczne i przechodzenie na nowy temat, gdy zapewni cisza. Zamiast tego wytrenuj ich, aby drażnić osobę obok ciebie.

Wyzwanie polega na tym, że chłopiec-fan kojarzy język z jego tożsamością, a wszelkie negatywne skojarzenia z tym językiem są osobiste. Nie atakuj ani nie broń. Po prostu zignoruj.

Bardzo niewiele rzeczy w pracy to naprawdę wyrzucane skrypty. Kończę umieszczanie wielu takich rzeczy na wiki lub w repozytorium, na wypadek, gdyby były potrzebne.

Nawet rzeczy, które moim zdaniem są poniżej poziomu udostępniania, moi koledzy z drużyny często czują się inaczej. Na przykład mam alias rgrep w moim .profile. To po prostu instrukcja find z parametrem, ponieważ nie mam dostępu do prawdziwego rgrep na tym serwerze. Kolega z drużyny miał wiatr i chciał tego na wiki. Tak, oświadczenie w jednym wierszu. Oczywiście nie mieliśmy debaty na temat języka implementacji - musiał to być UNIX. Podkreśla jednak potrzebę robienia rzeczy, które inni członkowie zespołu mogą zrozumieć.

Kolejną zaletą jest możliwość, że starszy programista ma powód, dla którego nie wiesz o używaniu tego języka. Czy pytałeś?

Być może spróbuj raz napisać ten sam skrypt w obu językach, aby pokazać, dlaczego twój jest lepszy.

Powinieneś spróbować zamglić . Oznacza to, że zgadzasz się ze wszystkim, co mówi fanboy (w części lub w całości), ale rób swoje, o ile wyraźnie nie zalecono inaczej.

Opcje pasywno-agresywne 1,3 prowadzą do większego stresu emocjonalnego, więc daj mi 2) weź go na podbródek.

Kilka ogólnych rad na drodze: 4) Jeśli nie sprytniej słuchasz swojego seniora, przeprowadź własne studia w zakresie projektowania języka / kompilatora. Wybierz język i dowiedz się, jakie myśli się w nim znalazły Jaki jest kompromis między funkcjami, wydajnością i mocą ekspresji. Jakie są inne opcje. Już samo to zapewni ci nieludzkie supermoce programowania. Naucz się nawet NBL , będzie ogromnie.

Zapewnianie siebie poprzez wypowiadanie się na temat innych hamuje produktywność i komunikację. Ludzie mogą myśleć, że rezygnacja z emocjonalnego popędu jest pomocna, ale jest to zwykła pomoc zespołu w ich niepewności.

Bycie pokornym i życzliwym z radą i doskonalenie się czyni cuda, aby wyrazić swoje przeczucia na poziomie technicznym. Poczujesz się lepiej i zobaczysz rzeczy takimi, jakie są, ponieważ będziesz w stanie rozumować. Trudno się wściec, gdy uzewnętrznisz krytykę w kontekście technicznym.