Pytanie:
Jak radzić sobie ze starszą divą deweloperską, która wydaje się nieświadoma, że ​​jego umiejętności są przestarzałe?
Arseni Mourzenko
2016-10-14 01:47:54 UTC
view on stackexchange narkive permalink

Jestem konsultantem ds. produktywności IT zatrudnionym w małej firmie tworzącej oprogramowanie (dwudziestu pracowników). Problemem jest starszy programista w zespole pięciu programistów, którzy pracują nad wiodącym produktem firmy.

Przez kilka lat założyciel był niezadowolony z umiejętności technicznych pracowników i niedawno zatrudnił starszy programista do podwójnej roli kierownika technicznego i kierownika projektu. Był jedynym, który przeprowadził rozmowę kwalifikacyjną i jedynym, który zdecydował się zatrudnić tę osobę.

Ten starszy programista ma imponujące CV z dwudziestopięcioletnią karierą w IT i wieloma udanymi projektami osiągnięty dla firm, od małych po międzynarodowe korporacje.

Jednak zespół znacznie mniej docenił jego profil w ciągu dwóch miesięcy. Miałem okazję porozmawiać z trzema z pięciu członków tego zespołu i wszyscy podkreślili trzy kwestie:

  • Według nich facet jest palantem i nie ma szacunku dla pozostali członkowie zespołu. Niedawny cytat, jak rozmawiał z młodszym programistą przed zespołem, jest bardzo obrazowy: „Pracowałem w tej branży przez dwadzieścia pięć lat, a ty? Co ty zrobiłeś? Od trzech lat jesteś małpą kodu. Więc zamknij się, kretynie! Nikt nie dba o twoją opinię, ******. ”

    Warto zauważyć, że miałem kilka spotkań z tą osobą i wydawał się bardzo miły i uprzejmy. Nie uwierzyłbym, że to ta sama osoba, która nieustannie obraża swoich kolegów z drużyny, gdybym nie miał zeznań trzech członków zespołu.

  • W przeszłości decyzje były podejmowane przez wszystkich członków zespołu. Kiedy członkowie nie zgadzali się, dyskutowali o wszystkim razem i doszli do porozumienia lub przynajmniej wyjaśnili powody tym, którzy się nie zgodzą.

    Teraz wszystkie ważne decyzje są podejmowane wyłącznie przez główny deweloper. Tych decyzji nie można kwestionować ani dyskutować, nawet jeśli cała piątka członków zespołu uzna, że ​​decyzja nie ma sensu.

  • Umiejętności i praktyki starszego programisty wydają się nieco ... przestarzałe. Kilka przykładów:

    1. Nienawidzi IDE, automatycznego uzupełniania i funkcji, które mają pomóc programistom w szybszym pisaniu kodu i twierdzi, że zespół powinien używać Notepad ++, aby być produktywnym. Chociaż ma to sens w różnych okolicznościach, trudno sobie wyobrazić programistów C # nagle porzucających Visual Studio dla Notepad ++.

    2. Nie refaktoryzuje kodu i nie przejmuje się stylem (co jest niespójne w jego własnym kodzie), ponieważ „troszczy się tylko o rzeczy, które naprawdę mają znaczenie”. Na marginesie, styl był wcześniej sprawdzany przez nocną kompilację, która zaczęła zawodzić od czasu pojawienia się nowego lidera.

    3. Odrzuca pomysł nocnej kompilacji, ponieważ a także testy automatyczne. Według niego „każdy profesjonalny programista i tak testuje swój kod ręcznie, więc nie ma powodu, aby tracić czas na pisanie testów automatycznych”. Według niego nocne kompilowanie to także strata czasu.

    4. Uważa, że ​​kontrola wersji jest w większości bezużyteczna i wydaje się, że źle rozumie, jak jej używać. Prowadzi to do sytuacji, w których samodzielnie rozwija jakąś cechę przez trzy do pięciu dni, a kiedy w końcu wprowadza zmiany, „bierze moje” za wszystkie konflikty. Jeśli inni członkowie zespołu narzekają, że ich kod został skasowany, zaprasza ich do przepisania go. Kilkakrotnie inni członkowie robili to samo, usuwając kod głównego programisty. Wyglądał na zaskoczonego (wygląda na to, że nie wie, jak używać svn log lub diffs) i ponownie wprowadził zmiany, narzekając, że „zostały w tajemniczy sposób zagubione” i obwiniając SVN o spieprzenie. / p>

    5. Wyolbrzymia znaczenie optymalizacji kodu. Jego podejście jest poprawne, tzn. Prowadzi profiler, ustala wąskie gardło i naprawia je; problem polega na tym, że nie ma niefunkcjonalnych wymagań dotyczących wydajności i nie ma elementów wskazujących na to, że użytkownicy mogą uznać aplikację za powolną (i hostowana na maszynach wirtualnych o niskiej jakości, aplikacja jest bardzo responsywna). Z drugiej strony, spędza praktycznie połowę czasu na optymalizacji kodu.

    6. Pisze ręcznie wszystkie SQL i odrzuca ideę ORM. Należy zauważyć, że obecny produkt jest oparty na ORM Entity Framework firmy Microsoft, a dwóch z pięciu programistów nigdy wcześniej nie korzystało z SQL.

    7. Odrzuca frameworki i biblioteki innych firm, biorąc pod uwagę że dużo łatwiej jest pisać rzeczy od zera. Zdecydował się porzucić wszystkie biblioteki i frameworki JavaScript z wyjątkiem jQuery, twierdząc, że kiedy zaczął programować w JavaScript piętnaście lat temu, nie było żadnych frameworków, a życie było dużo łatwiejsze.

    8. Uważa, że ​​urządzenia mobilne (w tym tablety) to tylko hype, więc nie ma powodu, aby tracić cenny czas na zapewnienie kompatybilności strony z tymi urządzeniami i tworzenie responsywnego projektu. Produkt jest publiczną aplikacją internetową, z której nie oczekuje się częstego używania na urządzeniach mobilnych. Jednak projekt responsywny może być bardzo interesujący dla tej aplikacji, ponieważ nawet na komputerach stacjonarnych będzie on wyświetlany zarówno na monitorach 19-calowych, jak i dużych monitorach o wysokiej rozdzielczości.

    9. Prosi zespół o zaprzestanie korzystania z Internetu (zwłaszcza StackOverflow) i poleganie na swoich mózgach, dokumentacji offline (nawet nie wiedziałem, że Microsoft nadal sprzedaje płyty MSDN!) i książkach.

Członkowie zespołu poskarżyli się założycielowi firmy na temat nowego kierownika w tych trzech kwestiach. Założyciel odpowiedział, że przesadzają i że na podstawie swojego CV i wywiadu ma absolutne zaufanie do umiejętności nowego lead'a, dlatego właśnie przypisał tej osobie w pierwszej kolejności rolę głównego programisty. .

Co zespół powinien zrobić, aby:

  • Albo wyrzucić prowadzenie z zespołu, albo z firmy,

  • Albo zmusić go do zmiany nastawienia do zespołu?


W komentarzach zadawano wiele pytań, więc oto dodatkowe informacje.

  • Jaka jest struktura firmy nad nim? Kto jest jego przełożonym?

    Biorąc pod uwagę niewielki rozmiar firmy, konstrukcja jest dość płaska. Na samej górze jest założyciel firmy. Są też pracownicy, którzy podlegają bezpośrednio założycielowi. Z prawnego punktu widzenia nowy lider jest na tym samym poziomie, co pozostałych pięciu członków zespołu. Na przykład nie może zwolnić członka zespołu ani nawet przenieść go do innego zespołu.

  • Niektóre z tego, co mówisz w kulach jako punkty przeciwko niemu są dla niego punktami. Mam na myśli, że ma rację co najmniej w połowie z nich

    Rzeczywiście, w ten sposób starałem się przedstawić temat. Osobiście uważam, że niektóre z tych dziewięciu punktów mają sens, ale nie w kontekście obecnego zespołu. Na przykład moim podstawowym środowiskiem programistycznym jest vi , ale nie będę zmuszać programisty C # do używania vi zamiast Visual Studio, ani też nie będę używał vi ja podczas tworzenia aplikacji C # dla systemu Windows.

  • Naprawdę nie rozumiem, dlaczego ten facet marnuje czas w Twojej małej firmie. Prawdopodobnie mógłby zarobić dużo więcej, pracując gdzie indziej jako „facet, który wciąż wie, jak utrzymywać nasz 25-letni, nieudokumentowany, krytyczny dla biznesu system, napisany w języku programowania, który wciąż rozumieją tylko 3 osoby we wszechświecie. "

    Rzeczywiście, dla mnie też nie jest to zbyt jasne. Powinienem wspomnieć, że zna język COBOL? ...

  • Nie sądzę, aby to było prawdziwe pytanie. Moim zdaniem jest to post przeznaczony do trollingu . W zasadzie wziąłeś wszystkie możliwe złe nawyki, połączyłeś je razem i zapytałeś, co robić.

    Moja rola konsultanta ds. Produktywności IT oznacza, że ​​dzwonię, gdy firmy mają problemy ze swoimi zespołami programistów. Ponad połowa przypadków dotyczy niedoświadczonych i często zdemotywowanych programistów, którzy są zmuszeni pracować nad kiepskim kodem nudnego oprogramowania. Druga część dotyczy jednak sytuacji konfliktowych, silnej polityki, wzajemnych nieporozumień i ogólnego bałaganu. Dlatego rzeczywiście znacznie częściej spotykam się z sytuacjami w stylu TheDailyWTF niż zwykli programiści, ponieważ tak naprawdę moim zadaniem jest być tam, gdzie dzieje się WTF.

    To już się zdarzyło. Opublikowałem pytanie opisujące sytuację WTF i niektórzy ludzie założyli (ich komentarze zostały usunięte), że trolluję. Wyobrażam sobie, że wiele sytuacji, z którymi się spotkałem, byłoby tutaj traktowanych tak samo, co jest zrozumiałe. Nawiasem mówiąc, sytuacja, którą tutaj opisuję, nie należy do najgorszych, jakie widziałem.

    Niestety nie ma sposobu, abym mógł wykazać, że te sytuacje są prawdziwe. Na przykład z oczywistych względów nie mogę podać ani nazwy firmy, ani nazwy divy deweloperskiej w obecnym przypadku, a nawet gdybym mógł, nikt tutaj nie zna tej firmy ani tego dewelopera (chyba że niektórzy z Was pracowali w Francja w sektorze finansowym utrzymującym przestarzałe systemy).

  • Brzmi trochę dziwnie, że dostrzegany problem dotyczy nowego lidera i że nie ma postrzeganego problemu z ludźmi pracując pod nim (takim jak ty). Czy założyciel miał rację, że był niezadowolony z obecnego zespołu? Jeśli nie, dlaczego był?

    Pamiętaj, że nie jestem członkiem zespołu, a jedynie konsultantem.

    Myślę, że założyciel ma całkowitą rację, że jest niezadowolony z obecnego zespołu. Czterej deweloperzy mają ogólnie niewielkie doświadczenie w programowaniu, aw szczególności w języku C #. Piąty jest bardziej doświadczony i jest tym, który pierwotnie nalegał na używanie kontroli wersji, który przygotował nocną kompilację itp. Mimo to ogólny poziom zespołu nie jest tak wysoki, jak trzeba by dobrze zbudować produkt, który tworzą teraz.

    Decyzja o zatrudnieniu kierownika technicznego była doskonałym pomysłem. Jednak byłoby znacznie lepiej, gdyby była to osoba, która uczyłaby obecny zespół zamiast go obwiniać i pracowała z obecnymi członkami, a nie przeciwko nim.

  • Dlaczego ktokolwiek miałby sprzeciwiać się korzystaniu z Internetu w celu uzyskania pomocy dotyczącej problemów z oprogramowaniem?

    Nie znam oficjalnego powodu, ale przypuszczam, że główny programista zawsze robił to w ten sposób i uważa, że ​​jakość StackOverflow jest gorsza od oficjalnej dokumentacji MSDN.

  • Czy kiedykolwiek zdarzyło się, że celem tego faceta jest odejście zespołu ?

    Ciekawy pomysł. Zmuszanie członków zespołu do rezygnacji przyniosłoby ogromne korzyści finansowe małej firmie, której może nie stać na zwolnienie ich. Gdy ci programiści odejdą, firma może zatrudnić bardziej doświadczonych programistów i przenieść divę deweloperską do innego zespołu.

  • Więc nie wiem, jak długo członkowie Twojego zespołu poskarżył się szefowi na temat głównego dewelopera. Ale czy odbyłeś z nimi dobrą rozmowę przy stole?

    Rzeczywiście, były indywidualne skargi, ale nie było rozmowy przy okrągłym stole. Dobra sugestia.

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (http://chat.stackexchange.com/rooms/46800/discussion-on-question-by-mainma-how-to-handle-a-senior-developer-diva-who-wydaje się).Jeśli chcesz trollować OP, jest to nie do przyjęcia.Jeśli chcesz na nie odpowiedzieć, użyj pola „odpowiedź”.Jeśli chcesz porozmawiać o wszystkich innych tematach, na które usunąłem komentarze, takich jak polityka, ulubione strony internetowe lub narzędzia programistyczne, przejdź do podanego linku do czatu.
Nie mogłem pomóc, ale zauważyłem, że Twój profil zawiera prawdopodobnie Twoje własne zdjęcie.Bossman nie będzie zadowolony, jeśli się na nią natknie.Na przykład, gdy współpracownik go daje.
Przypomnienie: to pytanie opiera się na interpretacji przez postera interpretacji przyjaciela w danej sytuacji.To dwie warstwy możliwego nieporozumienia.Możemy odpowiedzieć na to w formie pisemnej, ale istnieje realne ryzyko, że konkretne odpowiedzi nie będą dobrze pasować do tego, co faktycznie się dzieje.Lektor z zastrzeżeniem.
`Czterej deweloperzy mają niewielkie doświadczenie w programowaniu w ogóle, aw szczególności w C #. 'Kto ich zatrudnił i dlaczego?
OP: Czy możesz wyjaśnić, kto zatrudnił Cię do oceny tego zespołu?Czy to założyciel zatrudnił cię do konsultacji w tej sprawie?Jeśli tak, może to być dobry znak, że zdaje sobie sprawę, że mógł popełnić błąd przy wyborze nowego głównego programisty, co miałoby dość znaczący wpływ na poprawną odpowiedź na to pytanie, IMO.
Czy wiesz, czy firma zamierza / spodziewa się zakupu w przyszłości?Element, taki jak kontrola wersji, może mieć wpływ na inwestora wirtualnego lub kupującego.Czy CEO rozumie „biznes”?
Większość odpowiedzi skupia się na argumentach technicznych lub dynamice grup.Chciałbym jednak zwrócić uwagę na ważny szczegół: jest to sytuacja we Francji, we francuskiej firmie.AFAIK Francuski kodeks pracy bardzo utrudnia zwolnienie pracownika.Czy to możliwe, że celem tej konfiguracji jest po prostu zmusić zespół programistów do odejścia, aby nie musieli zostać zwolnieni?
Głosuj na zamknięcie jako poza tematem, ponieważ nie jest jasne, jakie masz stanowisko i jakie masz opcje."Powinien wyrzucić ołów?"TAK, KURS, jeśli jest to opcja, dlaczego w ogóle zadajesz sobie trud, aby to opublikować.Jeśli to nie jest możliwe, wyjaśnij nam, co chcesz zrobić i co możesz zrobić.
A jednak nie mniej niż 10 osób znalazło odpowiedź na pytanie, które prawie 200 osób uznało za dobre pytanie.Zastanawiam się, czy powinien istnieć powód zamknięcia, który mówi: „Mimo że 200 osób to rozumie, ja i 4 inne osoby nie, więc zamykamy”.
Wygląda na to, że starasz się być uczciwy, a nawet przedstawiając wady tego gościa ... jeśli w ten sposób przedstawiasz to założycielowi firmy, nigdy nie zobaczysz żadnych rezultatów.Problemy, które mu wymieniłeś, są nietrywialne i * muszą * zostać rozwiązane.
RE: „Niektóre z tego, co mówisz w kulach, jako punkty przeciwko niemu, są w rzeczywistości punktami dla niego. Mam na myśli, że ma rację przynajmniej w połowie z nich” - uhm, które z nich?Uważam, że każdy z nich jest dość okropny, może z wyjątkiem optymalizatorów kodu ...
Mylące jest mówienie „kolega”, jakbyś pracował w dziale.Powinieneś powiedzieć, że jesteś konsultantem ds. Produktywności, który ma to naprawić, i tak, to jest rzeczywista sytuacja.Ostatecznie nie podejmujesz żadnych decyzji, tylko zalecenia.Nie powiedziałeś nam, jakie są twoje kryteria wyboru między opcjami.(Czy jesteś upoważniony do rozmawiania z facetem i mówienia mu, dlaczego ludzie są z niego niezadowoleni? Skieruj go do psychologa? Czy co?) W każdym razie próbowałem to zmienić, aby to wyjaśnić.Ale ostatecznie nie powiedziałeś nam, jaka ** twoja ** funkcja jest w tej sytuacji, więc to nie jest prawdziwe pytanie.
Kiedy mówisz * „Zmuszanie członków zespołu do rezygnacji przyniosłoby ogromne korzyści finansowe małej firmie, która może nie być w stanie ich zwolnić. Kiedy ci programiści odejdą, firma może zatrudnić bardziej doświadczonych programistów i przenieść divę do innego zespołu.„* brzmi tak, jakbyś trollował lub nonszalancko.Nadal nie wiemy, jaka ** Twoja ** rola w tym jest.Jeśli zadaniem sr devpr jest zniszczenie tego zespołu i zmuszenie młodszych gości do dobrowolnego odejścia, to czego oczekuje szef od ** twojego ** zaangażowania?
Nowy lider zespołu, choć z pewnością toksyczny, to czerwony śledź;prawdziwym problemem jest właściciel, który nie wie, jak zarządzać personelem i musi zatrudnić kogoś (z pomocą z zewnątrz) do wykonywania tych funkcji stat (patrz moja odpowiedź poniżej dla mojego uzasadnienia).
Dziewięć odpowiedzi:
#1
+266
Chris E
2016-10-14 01:56:39 UTC
view on stackexchange narkive permalink

Założyciel odpowiedział, że przesadzają i że w oparciu o swoje CV i rozmowę ma absolutne zaufanie do umiejętności nowego lead'a, dlatego właśnie przypisał tej osobie rolę główny programista w pierwszej kolejności.

Główny człowiek przemówił. To nie jest rząd ani partia polityczna. Nie możesz nikogo wyrzucić ani poprowadzić powstania.

Jeśli nie chcesz sobie z tym poradzić, naprawdę masz jedną opcję. Możesz się zjednoczyć i zagrozić, że odejdziesz, jeśli coś się nie stanie.

Mówię, że tak, nie powinno. Jest niezwykle duża szansa, że ​​to się nie skończy. Zasadniczo starasz się wyprzedzić szefa, który podjął decyzję, a ludzie na stanowiskach kierowniczych nie lubią, gdy są kwestionowani.

Wydaje mi się, że „właściwą” rzeczą jest znalezienie technik zachęć go, aby zobaczył Twój sposób myślenia. Ale ja tego nie zrobię. Jestem 30-letnim starszym programistą i mogę powiedzieć, że w dużej mierze przyzwyczaiłem się do moich podstawowych sposobów. Nie, nie jestem luddystą jak ten facet i tak, przyjmuję sugestie. Doceniam nowe technologie i tak dalej. Ten facet najwyraźniej myli się w wielu sprawach. Mogę jednak powiedzieć, że kiedy jestem na coś nastawiony i jestem przekonany, że podejmuję właściwą decyzję, to trzymam się jej. Nie znoszę groźby, a przymus lub manipulacja są jeszcze gorsze.

Chodzi mi o to, że jest przekonany, że jest „Jezusem Programistą” (co jest smutnym, niefortunnym podejściem) i nigdy go nie zmienisz, nie na tym etapie swojej kariery. Jest przekonany, że ma rację i uważa, że ​​jego doświadczenie go wspiera. Niestety szef też.

Szczerze mówiąc, prawdopodobnie nie jest to warte stresu dla Ciebie i Twojego zespołu. Proponuję każdemu z was zacząć szukać nowej pracy i odejść, gdy już ją znajdziecie. Kiedy ktoś odchodzi, upewnij się, że powie szefowi dlaczego. W końcu może dostać zdjęcie. Nawet wtedy nie ma gwarancji.

URUCHOM Poważnie, nie wiem, dlaczego ktoś miałby chcieć tam być. Zadaj sobie pytanie, czy jest coś w tym, co nam powiedziałeś, co nie oznacza ostatecznej zagłady produktu? Jestem pewien, że o tym wiesz. Kwestionuję podstawową inteligencję założyciela w tej sprawie. Deweloperzy zwykle są kiepskimi kierownikami projektów / programów. To osobny zestaw umiejętności i muszą się wzajemnie równoważyć. To tak, jakby powiedzieć „nie potrzebujemy oddzielnych testerów, testy programistyczne działają świetnie”. Obie są receptami na katastrofę. Powodzenia. Mam to na myśli.

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (http://chat.stackexchange.com/rooms/46881/discussion-on-answer-by-christopher-estep-how-to-handle-a-senior-developer-diva).
Założyciel, który ufa nowemu pracownikowi tak bezwarunkowo, mimo że nie ma możliwości oceny, czy facet jest zdolny, nie jest wart kłótni.Zgadzam się, biegnę przy pierwszej dogodnej okazji.Tam są lepsze miejsca pracy dla programistów.
@Magisch Widziałem, jak dokładnie ten scenariusz rozgrywa się wiele, wiele razy w mojej karierze.Facet z imponującym życiorysem (lub dobry w sprzedaży) zostaje zatrudniony i nie jest „Złotym Chłopcem”.W każdym przypadku GB traci swój blask i trafia również na out.Niestety, zwykle dzieje się to po tym, jak zdziesiątkował swoją drużynę (tak się zakrywa, kiedy po raz pierwszy zaczyna okazywać swoją niekompetencję).
Wyglądasz młodo od 30 lat w IT.
@tuskiomi to zdjęcie ma kilka lat, ale i tak zawsze wyglądałem młodo.Zostałem zakwalifikowany do moich 30 lat.Moja pierwsza praca w IT (wtedy nazywaliśmy ją DP) była w 1986 roku, więc minęło już 30 lat.Szczerze mówiąc, nie wydaje się to możliwe, ale moim pierwszym projektem była instalacja Advanced Netware 2.0a na nowym serwerze Limited (Dell) 386-16 z 2 MB pamięci RAM i 2 pełnowymiarowymi dyskami 70 MB na cienkiej sieci Ethernet.:)
@ChristopherEstep zabawne, że dzisiaj wystarczy kilka sekund (jeśli to), aby pobrać tyle, aby wypełnić cały dysk twardy.
Zdaję sobie sprawę, że pierwotna wersja OP pominęła ważny szczegół: że nie jest pracownikiem, ale konsultantem sprowadzonym do (prawdopodobnie) rozwiązania tego problemu.Mówienie jej, żeby uciekła od problemu, tak naprawdę nie pomaga, przez co wydaje się tym dziwniejsze, że „zaakceptowała” odpowiedź!Oczywiście, nie krytykując twojej odpowiedzi, jest jak zawsze doskonała, po prostu wskazując, co wydało mi się dziwne.
#2
+92
Tony Ennis
2016-10-15 21:04:29 UTC
view on stackexchange narkive permalink

Opis sytuacji w OP jest prawdopodobnie jednostronny. W porządku.

Jestem starzejącym się programistą (~ 54 lata), który został zatrudniony w firmie nie po to, aby rządzić, ale po to, aby zapewnić trochę doświadczenia. (Szef działu IT faktycznie powiedział „siwe włosy”, lol.) Zespół programistów był o wiele bardziej biegły niż jakikolwiek inny zespół, z którym wcześniej pracowałem. Wiele mnie nauczyli, zwłaszcza o pokorze! Ale znaleźliśmy miejsca, w których ich magia technologiczna nie rozwiązała problemów, aw niektórych przypadkach ukryła te problemy, ostatecznie je pogarszając. Właśnie w tym mogłem naprawdę wnieść swój wkład.

Twój trop brzmi bardzo autokratycznie. Wygląda na to, że właściciel dał mu mandat. Właściciel jest niezadowolony z zespołu programistów i sprowadził tego „twardego, rozsądnego, przebojowego faceta”, aby przyspieszyć dostawy.

Najpierw spójrz na swoich pracowników. Masz słabeuszy - deweloperów, którzy nie „widzą Matrixa”? Jeśli tak, znajdź im nowe stanowiska w firmie lub daj im dobre referencje dla pracodawcy, który potrzebuje ich wyjątkowych umiejętności.

Nienawidzi IDE

I znasz kilka, które to robią. To sprawia, że ​​przewracam oczami, ale ostatecznie mnie to nie obchodzi. Jeśli ludzie produkują używając vi , to ok. Uwielbiam moje IDE.

Nie zmienia kodu i nie dba o styl (który jest niespójny w jego własnym kodzie).

Czerwona flaga na pierwszej części. Czy on jest kopiującym paserem? Jestem również winny, że nie dbam o styl, ale to dlatego, że używam mojego IDE do natychmiastowego dostosowania mojego kodu Pythona do PEP8. Ale on nie używa IDE ...

Na marginesie, styl był wcześniej sprawdzany przez nocną kompilację, która zaczęła zawodzić po przybyciu nowego lidera.

Odrzuca pomysł nocnej kompilacji, a także testów automatycznych. Według niego „każdy profesjonalny programista i tak testuje swój kod ręcznie, więc nie ma powodu, aby tracić czas na pisanie testów automatycznych”. Według niego nocne budowanie to także strata czasu.

To również wywołuje czerwoną flagę, ale z innych powodów, niż można by się spodziewać. Zanim ten facet został zatrudniony, ile razy właścicielowi mówiono, że nie może zrobić X (dać demo, użyć systemu itp.), Ponieważ nocna kompilacja się nie powiodła? A jeśli właściciel zauważy, że problemem jest nocna budowa? Jak myślisz, co kazałby przywódcy zrobić?

Ale mam obawy co do postawy lidera; testy automatyczne są niesamowite. Tak jak poprzednio, szef może nie rozumieć wartości testów, ale z pewnością wie, że płaci za nie Y% wypłat pracowników programistów. Kiedy przybyłem do mojej obecnej firmy, "mafia 100% pokrycia testami" przejęła zespół programistów i poniosła koszty. Jedno złe jabłko później i zespół programistów znowu mruczał.

Uważa, że ​​kontrola wersji jest w większości bezużyteczna ...

To jest czerwona flaga najwyższe zamówienie. Myli się tak bardzo, jak to tylko możliwe. Jest nieodpowiedzialny za pieniądze właściciela.

Wyolbrzymia znaczenie optymalizacji kodu.

W przeszłości optymalizacja kodu mogła mieć znaczenie. Teraz maszyny są tak szybkie, że jest to mniej ważne. Zamiast tego musimy teraz martwić się o wydajność bazy danych i przepustowość sieci. Ale jego nawyk „optymalizacji kodu” jest trudny do złamania, zaufaj mi. Muszę się powstrzymać przed optymalizacją wstępną. Przynajmniej jego zachowanie w tym przypadku nie jest destrukcyjne, z wyjątkiem wymaganego czasu. (Czy masz liczby na jego „połowę jego czasu”, czy to jest hiperbola? Jeśli krytykujesz swojego przełożonego, nie można dopuścić do hiperboli. Musisz być patologicznie obiektywny.)

Pisze wszystko SQL ręcznie i odrzuca pomysł ORM.

Winny jak oskarżony! Nie rozumiem, że ludzie boją się SQL. Nie rozumiem zakopywania SQL, które jest bardzo proste, pod warstwami ORM, które zaciemniają. Nie mogę ci w tym pomóc :-D Ale proszę, zrzuć cały swój kod SQL w jedno miejsce - nie rozpowszechniaj całego kodu.

i dwóch z pięciu programistów nigdy wcześniej nie używało SQL.

To niedopuszczalne. To jest 2016 rok. Muszą podnieść swoje umiejętności.

Odrzuca frameworki i biblioteki zewnętrzne, biorąc pod uwagę, że znacznie łatwiej jest pisać rzeczy od zera.

Nie mógł się bardziej mylić. Wątpię, aby Twoja firma była tak wyjątkowa , że narzędzia musiałyby być napisane na miejscu. Mieliśmy kilku programistów, którzy chętnie korzystaliby z narzędzi innych firm - dopóki nie zrobili czegoś, czego deweloper nie lubił. To był pretekst, by wyrzucić narzędzie i napisać własne. To tylko zwiększa obciążenie zespołu programistów, spowalniając go jeszcze bardziej. Ten nieprzydatny kod jest drogi w pisaniu, testowaniu, debugowaniu i utrzymaniu. Wydaliśmy tyle pieniędzy na korzyść zerową. Tych programistów już nie ma.

Zdecydował się porzucić wszystkie biblioteki i frameworki JavaScript z wyjątkiem jQuery, twierdząc, że kiedy zaczął programować w JavaScript piętnaście lat temu, nie było żadnych frameworków, a życie było dużo łatwiejsze.

Ten nie jest tak jednoznaczny. Powodem jest to, że 15 lat temu życie było o wiele łatwiejsze, ponieważ biznes pytał o wiele prostszy. Stąd pochodzi problem. Sieć została wymyślona jako system wsadowy (wypełnij formularz, prześlij go, uzyskaj odpowiedź, powtórz), a teraz próbujemy pisać aplikacje internetowe, które zachowują się jak aplikacje komputerowe. Jego obserwacja jest słuszna, teraz jest ciężko. Ale nie zdaje sobie sprawy, dlaczego. Złożoność narzędzi jest odpowiedzią na bardziej skomplikowane pytanie biznesowe. Dlatego dokonuje złych wyborów.

Używamy AngularJS i wydaje się, że jest przyzwoity. Podobnie jak wszystkie potężne narzędzia, można go użyć w dobrym lub złym celu.

Uważa, że ​​urządzenia mobilne (w tym tablety) to tylko hype, więc nie ma powodu, aby tracić cenny czas, aby zapewnić zgodność witryny z tymi urządzeniami i tworzyć responsywny projekt. Produkt jest publiczną aplikacją internetową, z której nie oczekuje się częstego używania na urządzeniach mobilnych.

Znowu się myli. Oni nie są hype. Są tutaj, aby zostać, ponieważ są przydatni. ALE biznes tego nie potrzebuje. Nie twórz rzeczy, których nie potrzebujesz. Jest drogi.

Jednak projekt responsywny może być bardzo interesujący dla tej aplikacji ...

Czy to takie interesujące, że zapłaciłbyś do rozwoju osobiście? Jeśli to dobry pomysł, powinieneś móc go sprzedać właścicielowi. W przeciwnym razie nie wydawaj na to ani grosza.

Prosi zespół o zaprzestanie korzystania z Internetu (zwłaszcza StackOverflow) i poleganie na swoich mózgach, dokumentacji offline (nawet nie znałem Microsoft nadal sprzedaje płyty CD MSDN!) i książki.

Myli się. Internet jest do tego świetny. Jeśli zespół programistów kopiuje i wkleja ze Stackoverflow bez zrozumienia, jak działa kod, to też się mylą. Czy jest czas na szkolenie i osobiste doskonalenie harmonogramu rozwoju? Trudno nie kopiować i wklejać za pomocą robota, gdy jesteś zawsze pod bronią.


Chociaż mam ograniczone informacje, jest tutaj wiele problemów. Wygląda na to, że właściciel nie zdobył kodu, za który płaci, tak szybko, jak się spodziewał. Wygląda na to, że słyszał wiele wymówek na temat rzeczy, na których nic go nie obchodzi; skupia się na wyniku. Jeśli mam rację, masz ranę zadaną sobie samemu i otworzyłeś ją więcej niż raz. Ten potencjalny klient to rozwiązanie właściciela problemu, który postawił zespół programistów, a biorąc pod uwagę jego ograniczone informacje, jest to zrozumiałe.

Założę się również, że prowadzisz sklep bez zwinności i masz słabą definicję wymagań, która zmienia się wraz z wiatrem. Nie ma warstwy izolacji między pracownikami programisty a właścicielem. Z wyjątkiem tego potencjalnego klienta.

A teraz, co możesz zrobić?

1) Przeszkol kierownika, że ​​najlepszym rozwiązaniem jest stosowanie testów automatycznych i zarządzania kodem. Uzyskanie u niego wiarygodności może zająć trochę czasu - właściciel prawdopodobnie powiedział mu, że personel jest uszkodzony. Sprawdź, czy możesz uniemożliwić mu wydawanie rozległych nakazów, takich jak „usuń wszystkie bezużyteczne testowe bzdury i zmień przeznaczenie serwera SVN”. To da ci czas na pokazanie wartości.

2) Kontynuuj zarządzanie kodem na poziomie osobistym. Przynajmniej wtedy możesz wyleczyć się z własnych błędów. Nie mów mu, że to robisz, ale też go nie okłamuj.

3) Kontynuuj testy automatyczne (testy jednostkowe, jeśli nic więcej) na poziomie osobistym. Tak jak poprzednio, nie wspominaj o tym, ale nie ukrywaj tego.

4) Pracuj z potencjalnym klientem, aby określić, jakie są rzeczywiście postrzegane problemy. Bądź otwarty; Założę się, że są prawdziwe problemy z personelem. Pracuj z potencjalnym klientem, aby rozwiązać problemy, a nie objawy.

5) Omów z kierownikiem różne tematy związane z rozwojem, takie jak korzyści płynące z kaskady i zwinności. Żaden nie jest doskonały. Zadaj mu takie pytania, jak: „W jakich okolicznościach testy automatyczne byłyby warte zachodu”? Jeśli poda wątpliwą odpowiedź, zapytaj go, jak udane firmy, takie jak Google, zdołały mimo to prosperować.

Więc widzisz, że chodzi mi o zaangażowanie lidera i sprawdzenie, na czym polega jego głowa. Budować zaufanie. Zgódź się na problemy i objawy. Nie zawsze jest to łatwe, zwłaszcza gdy czujesz, że jest jak Godzilla i rozrywa twoją pracę.

Jest szansa, że ​​nie może pójść na kompromis. Zmiażdży testy automatyczne. Zarządzanie kodem jest dla nieostrożnych ludzi. Moja droga lub autostrada.

Jeśli jednak doszło do tego punktu, nadszedł czas, abyś odszedł. Praca w sklepie bez narzędzi, a mam na myśli oprogramowanie i narzędzia inżynierii oprogramowania - nie buduje twojego CV. Zaczniesz gnić w ten sam sposób, w jaki zgnił Ołów. W takim razie przejdź dalej.

Jeśli chodzi o optymalizację kodu, to w dużej mierze się z tym zgadzam (choć zdecydowanie są wyjątki).Optymalizacja algorytmu, to inna historia.Generalnie nie obchodzi mnie, czy używam 32-bitowej czy 64-bitowej zmiennej całkowitej do przechowywania pewnej ilości;jeśli uważam, że istnieje ryzyko, że 32 bity nie wystarczą, użyję 64 bitów i więcej o tym nie myślę.Jednak niemożliwe jest, aby oprogramowanie działało dobrze, jeśli używasz algorytmów O (n ^ 3) lub O (n ^ 4) na dużych zbiorach danych, w których można wykonać pracę w O (n ^ 2), a może nawet w O (n log n).Nic, co robisz w implementacji O (n ^ 4), nie może dać ci O (n log n).
Bez ORM napisanie kodu w celu odtworzenia hierarchii, takiej jak zamówienie -> wysyłka -> pozycja, może zająć godziny.W przypadku ORM zajmuje to kilka minut.Po prostu pobierz zamówienia, pobierz przesyłki i przedmioty.
@MichaelKjörling, ale zwykle nie jest to rodzaj optymalizacji, który wykonuje się za pomocą Profiler i „naprawiania” wolnego kodu.Jeśli piszesz algorytm, powinieneś WIEDZIEĆ wydajność i zaimplementować ją w odpowiedni sposób.Profiler pomaga znaleźć powolne części w kodzie innych ludzi (innych programistów, ale zwłaszcza bibliotek zewnętrznych) i błędów.Zwykle problemy te należy rozwiązać, gdy się pojawią.Samo znalezienie „wolnego kodu” i naprawienie go bez żadnego celu związanego z wydajnością jest kosztowne i nie pomoże, jeśli np.procesor twojego serwera i tak jest bezczynny przez 70% czasu.
@Josef Zgadzam się!Poświęcanie czasu na naprawianie rzeczy, które nie są problemami, jest bardzo często stratą czasu.Ale nie zgadzam się z tym, że nie zidentyfikowałbyś tego rodzaju problemów z profilerem.Celem profilera jest identyfikacja segmentów kodu, których wykonanie zajmuje zbyt dużo czasu podczas określonego przepływu pracy.Następnym krokiem jest określenie, czy ten długi czas wykonania jest problemem, a jeśli tak, to dlaczego i co z tym zrobić.Program profilujący dostarcza surowe dane dotyczące czasu wykonania jako dane wejściowe do tego procesu, ale nie ma sensu wprowadzać niewielkich korekt, jeśli algorytm nie działa.
Zawsze lubię, gdy potrafię rozwiązać problemy za pomocą inteligentnego SQL.SQL to bardzo łatwy sposób na uzyskanie tego, czego chcesz, a praca z ramkami ORM nie może być łatwiejsza, imo.
Nie mogę zgodzić się z Twoją opinią na temat surowego SQL.Zgadzam się, że każdy poważny programista powinien znać SQL i być świadomym SQL podczas korzystania z ORM, ale poważnie, jeśli konkretny problem można rozwiązać za pomocą ORM i nie jest to szyja, nie należy go rozwiązywać za pomocą surowego SQL.Nie dlatego, że ORM jest bardziej fantazyjny, absolutnie nie.Jest to o wiele bezpieczniejsze i łatwiejsze może dla mniej doświadczonych ludzi, którzy pracują z tobą, aby przejąć twój kod.Możesz pomyśleć, że to źle, ale tak jest, znałem starszych programistów, którzy nie pamiętali, jak używać grupowania według.Może nam się to podobać lub nie, ale pracujemy razem.
ORMy (używam SQLAlchemy dla Pythona) są również niesamowite podczas konstruowania złożonych zapytań.Wyobraź sobie, że piszesz funkcję, która wyszukuje faktury i ma kilka opcji i parametrów (zakres dat, ograniczenie do konkretnego klienta, uwzględnienie zarchiwizowanych faktur?).Dzięki gołym ciągom SQL łączysz teraz ciągi dla swojej klauzuli WHERE.W przypadku ORM dodajesz wystąpienia ClauseElement do obiektu Query.
@Simon Chwileczkę, nikt nie mówił o konkatenacji nieprzetworzonych łańcuchów SQL!ORM udaje, że relacyjna baza danych jest tak naprawdę obiektową bazą danych - to nie zawsze jest dobra abstrakcja.Osobiście wolę cienkiego klienta relacyjnego ze składnią LINQish nad SQL.Nie trzeba udawać, że relacje są obiektami, a zapytania właściwościami.Chcesz dodać kolejny filtr?Po prostu wykonaj `query.Where (i => i.FirstName ==" Simon ");`.
Jedyne, co przegapiłeś, to „Więc zamknij się, kretynie”.Mam na myśli, że wskazałeś wystarczająco dużo czerwonych flag, aby się go pozbyć, ale to kolejna.Nie powiedziałbyś mi tego dwa razy.Nie powiedziałbyś tego nikomu dwa razy, kiedy jestem w pobliżu i słyszę to.
@gnasher729 Postanawiam wierzyć, że to hiperbola.Ale gdyby tak nie było, drzwi nie uderzyłyby mnie w tyłek, gdybym wychodził.
#3
+51
Peter
2016-10-15 22:39:25 UTC
view on stackexchange narkive permalink

dwadzieścia pięć lat w IT [...] zmień swoje nastawienie

Przepraszamy, nie zadziała.

Twoim prawdziwym problemem nie jest niekompetentny główny programista. Ten problem jest nieistotny w porównaniu z prawdziwym problemem, który opisujesz:

Twój założyciel ufa niekompetentnemu * nieznajomemu bardziej niż swoim obecnym pracownikom.

Potrzebujesz dowiedzieć się, jak zespół stracił zaufanie i jak je odzyskać. Byłoby to łatwiejsze, gdyby zostało to zrobione przed zatrudnieniem nieznajomego. Teraz jest to trudne, ponieważ każda dobra praca zostanie przypisana nowemu kierownikowi zespołu, a każda słaba praca zostanie przypisana wam wszystkim - więc nie można tego naprawić, pracując ciężej.

Są tylko dwie rzeczy, które przychodzą mi do głowy, aby poprawić sytuację w tej pracy:

  1. Znajdź mediatora. Czy jest wielu założycieli lub coś takiego jak członkowie zarządu?
  2. Może problem zaufania jest problemem widoczności. W takim przypadku pomaga ci wszystko, co pomaga w widoczności. Na przykład. uczynić dema sprintów ekscytującymi i interesującymi na tyle, że założyciel faktycznie uczestniczy i dowiaduje się o statusie i postępach zespołu.

* Chociaż większość punktów zebranych przez OP niekoniecznie nieznajomy jest niekompetentny, jego podejście do kontroli wersji i ciągłej integracji w 5-osobowym zespole z pewnością działa.

Nigdzie OP nie mówi „agile” ani „sprint”.Podejrzewam, że to miejsce ma w najlepszym przypadku metodologię ad hoc.
@TonyEnnis Dlatego użyłem „np.”.Powinno istnieć coś porównywalnego do pokazów sprinterskich, jeśli chcesz być widoczny, niezależnie od używanej metodologii.
O, rozumiem.Uzyskanie wymiernych rezultatów przed szefem to dobry pomysł.
#4
+17
MonkeyZeus
2016-10-14 18:14:52 UTC
view on stackexchange narkive permalink

Ta odpowiedź może być nieprzychylna i uważana przez niektórych za prostą, ale ...


Pierwsza czerwona flaga to Przez kilka lat założyciel był niezadowolony z umiejętności technicznych pracowników

Czy pracownicy próbowali naprawić nieszczęście?


Druga czerwona flaga to dwóch z pięciu programistów nigdy wcześniej nie korzystało z SQL

Trudno jest stworzyć wydajny system, jeśli programiści nie są zaznajomieni z podstawowymi technologiami i naprawdę rozumieją, co maskuje ORM.


Trudno to sobie wyobrazić Pracowałem w tej branży 25 lat, a Ty? Co ty zrobiłeś? Od trzech lat jesteś małpą kodu. Więc zamknij się, kretynie! Nikt nie dba o twoją opinię, ******. zostało faktycznie wypowiedziane, ale wezmę to za wartość nominalną i wierzę ci.

Jednak weź pod uwagę pierwszą czerwoną flagę, o której wspomniałem i „nieszczęście”, z którym założyciel musiał się zmagać od lat.

Do tego dodam: wiecie o nieszczęściu założyciela od lat ?!

Jak to było ujawnione informacje?


Jestem skłonny sądzić, że ten facet robi dokładnie to, do czego został zatrudniony; Doprowadzić was do formy.

Poprawa formy nie oznacza przyjęcia złych praktyk nowego faceta, ale wymaga wyrzucenia was ze strefy komfortu, aby uczyć się na głębszym poziomie.

Mogłoby tak być, gdyby nie było pozostałych punktów w pytaniu dotyczącym PO.Brakuje tylko jednego fragmentu - kodu źródłowego - i to jest właśnie to, co naprawdę oddziela tego kierownika zespołu od pełnej katastrofy, jeśli nie wtrącał się już wystarczająco.Albo to jest doskonałe pytanie o trolla, ale co jest prawdziwe, tak?
Flagi, które podkreślasz, to ważne kwestie, które nie zostały poruszone, ale wszystko inne w tym przewodniku dewelopera stanowczo zaprzecza idei „doprowadzenia Cię do formy”, chyba że założyciel również utknął w technikach sprzed ponad 25 lat.
„w dobrej formie” przez porzucenie testowania, stylu, dokumentacji, kontroli wersji, szacunku i komunikacji… tak, racja: / nie jest to jednak najlepszy żart, jaki tu opowiadasz.
@eques Zależy od tego, jak głębokie są motywy.Założyciel osobiście przeprowadził wywiad i zatrudnił tego gościa bez dodatkowego wkładu.Bez znajomości dyskusji za zamkniętymi drzwiami ** NIKT ** nie może teraz dostarczyć niczego więcej niż przypuszczenia.
@DanielJour Przygotowanie zespołu do formy nie oznacza przyjmowania jego złych praktyk.Proszę zobaczyć moją aktualizację.Przepraszam za zamieszanie.
W tej chwili to tylko komentowanie pytania i tak naprawdę nie odpowiada na zadane pytanie, czyli jak poprawić sytuację i poradzić sobie ze złymi praktykami „diwy”.
@MonkeyZeus Dziękuję za wyjaśnienie tego.Chociaż jest to możliwe, jakoś wątpię, czy to jest motywacja do zatrudnienia tego faceta.Nowy facet najprawdopodobniej zmniejszy produktywność do zera.Chociaż, jak już powiedziałem, pozostałe dwie kwestie, które poruszasz (nieszczęście, brak doświadczenia w SQL) są ważne do rozważenia.
@DavidK Przyznałem, że moja odpowiedź może być nieprzychylna.Czasami musisz czytać między wierszami, cofnąć się i zastanowić się, czy to jest problem XY.
@MonkeyZeus Nie mówię, że twoja odpowiedź jest nieprzychylna, mówię, że twoja odpowiedź ** nie odpowiada na pytanie. ** Wnioskuję z tego, że mówisz OP, żeby to wciągnął i zrobił to, co mówi kierownik,ale w ostatniej linijce jest napisane „nie przyjmuj złych praktyk nowego gościa”.W jaki sposób PO robi jedno i drugie?
Chociaż rozsądne byłoby zatrudnienie osoby o określonych umiejętnościach, aby nadać zespołowi formę, jeśli jej umiejętności techniczne są niedostateczne / niezadowalające, jednak biorąc pod uwagę inne aspekty (jeśli są dokładnie opisane), nie może to być bezpośredni przypadek, chyba że a)założyciel ma podobny techniczny sposób myślenia lub b) założyciel całkowicie nie zna umiejętności technicznych i techniki rozwoju.Biorąc pod uwagę, że w PO nie określono, czy założyciel jest założycielem technicznym, całkiem możliwe, że założyciel nie rozpoznaje ograniczeń technicznych swojego nowego pracownika (nie, że są to jedyne problemy)
Mogę wierzyć, że * intencją * kierownictwa było zatrudnienie starszego lidera, aby nadać kształt zespołowi, który osiągał słabe wyniki, z pewnością bardzo to schrzanili.
Żal mi właścicielki.Całkowicie stracił zaufanie do zespołu i żeby ratować sytuację szukał gwiazdy na pozycji „dyktatora”… i dostał złą = /.Myślę, że podsumowanie tej odpowiedzi powinno być wyraźnie napisane: „Nic nie można zrobić, jest już za późno”.Właściciel, który nie ufa pracownikom, musiał polegać na CV, które robi wrażenie i musi mu zaufać.Zaniepokojenie zespołu może jego zdaniem być w rzeczywistości pozytywną reakcją - zły zespół poczuł się nieswojo, więc może się zmienią.Teraz odejdą, a właściciel po kilku latach zorientuje się, że generał jest zły.
Ta odpowiedź miałaby sens, gdyby firma brała udział w jakimś szkoleniu z kodowania reality show.
#5
+9
Old_Lamplighter
2016-10-14 19:07:44 UTC
view on stackexchange narkive permalink

Przez kilka lat założyciel był niezadowolony z umiejętności technicznych pracowników, a ostatnio zatrudnił starszego programistę do podwójnej roli kierownika technicznego i kierownika projektu. Był jedynym, który przeprowadzał wywiad i jedynym, który zdecydował się zatrudnić tę osobę.

Wygląda na to, że założyciel wam nie ufa.

Zespół jednak znacznie mniej docenił jego profil w ciągu dwóch miesięcy. Miałem okazję porozmawiać z trzema z pięciu członków tego zespołu i wszyscy podkreślili trzy kwestie:

  • Według nich facet jest palantem i nie ma szacunku do pozostałych członków zespołu. Niedawny cytat, jak rozmawiał z młodszym programistą przed zespołem, jest bardzo obrazowy: „Pracowałem w tej branży przez dwadzieścia pięć lat, a ty? Co ty zrobiłeś? Od trzech lat jesteś małpą kodu. Więc zamknij się, kretynie! Nikt nie dba o twoją opinię, ******. ”

Wygląda na to, że masz tylko jedną stronę historii. Potrafię sobie wyobrazić kilka sytuacji, w których mógłbym sam spoliczkować młodego, wiedzącego wszystko, i tak się stało. tylko grał tutaj adwokata diabła, ale wygląda na to, że został sprowokowany. Jaka była prowokacja?

  • W przeszłości decyzje podejmowali wszyscy członkowie zespołu. Kiedy członkowie nie zgadzali się, omawiali to wszystko razem i doszli do porozumienia lub przynajmniej wyjaśnili uzasadnienie tym, którzy się nie zgadzają.

najwyraźniej , wcześniejsze praktyki nie przyniosły rezultatów, jakich chciał założyciel.

Teraz wszystkie ważne decyzje podejmuje wyłącznie główny programista. Tych decyzji nie można kwestionować ani omawiać, nawet jeśli cała piątka członków zespołu uzna, że ​​decyzja nie ma sensu.

Znowu brzmi to jak wotum nieufności ze strony założyciela. Nie bez powodu sprowadził tego typu osobę. Wygląda na to, że powodem było doprowadzenie reszty personelu do formy.

  1. Nienawidzi IDE, automatycznego uzupełniania i funkcji, które mają pomóc programistom w szybszym pisaniu kodu i twierdzi, że że zespół powinien używać Notepad ++, aby być produktywnym. Chociaż ma to sens w różnych okolicznościach, trudno sobie wyobrazić programistów C # nagle porzucających Visual Studio dla Notepad ++.

IDE mogą Cię spowolnić, jeśli jesteś szybkim programistą. Notepadd ++ jest lepszy od niektórych, jeśli chodzi o szybkie kodowanie. Chodzi o to, że piszesz kod, a następnie upuszczasz go do IDE w celu szybkiej korekty zamiast ciągłych przerw.

  1. Nie refaktoryzuje kodu i nie dba o styl (który jest niespójny w jego własnym kodzie), ponieważ „dba tylko o to, co naprawdę ma znaczenie”. Na marginesie, styl był wcześniej sprawdzany przez nocną kompilację, która zaczęła zawodzić po pojawieniu się nowego leadu.

Standardy sklepowe są tematem do omówienia z założycielem , zwłaszcza że przeprowadzasz go przez nocną kompilację. Ale znowu, czytając między wierszami, wygląda na to, że założyciel ci nie ufa.

  1. Odrzuca pomysł nocnej kompilacji, a także zautomatyzowanej testy. Według niego „każdy profesjonalny programista i tak testuje swój kod ręcznie, więc nie ma powodu, aby tracić czas na pisanie testów automatycznych”. Według niego nocne kompilowanie to także strata czasu.

Ma rację, automatyczne testy nie uwzględniają geniuszu jakiegoś głupca, który robi coś, czego nigdy nie zamierzał. Osobiście zepsułem kilka programów, które przeszły testy automatyczne.

  1. Uważa, że ​​kontrola wersji jest w większości bezużyteczna i wydaje się, że źle rozumie, jak jej używać. Prowadzi to do sytuacji, w których samodzielnie rozwija jakąś cechę przez trzy do pięciu dni, a kiedy w końcu wprowadza zmiany, „bierze moje” za wszystkie konflikty. Jeśli inni członkowie zespołu narzekają, że ich kod został skasowany, zaprasza ich do przepisania. Kilkakrotnie inni członkowie robili to samo, usuwając kod głównego programisty. Wyglądał na zaskoczonego (wygląda na to, że nie wie, jak używać dziennika svn lub różnic) i ponownie wprowadził zmiany, narzekając, że „zostały w tajemniczy sposób zagubione” i obwiniając SVN o spieprzenie.

Wszyscy tu są winni. Czy nikt nie tworzy kopii zapasowych? Jeśli ma problemy z kontrolą wersji, obowiązkiem zespołu jest pracować jako zespół, a nie tylko utrudniać mu to.

  1. Przesadza znaczenie optymalizacji kodu. Jego podejście jest poprawne, tzn. Prowadzi profiler, ustala wąskie gardło i naprawia je; problem polega na tym, że nie ma niefunkcjonalnych wymagań dotyczących wydajności i nie ma elementów wskazujących na to, że użytkownicy mogą uznać aplikację za powolną (i hostowana na maszynach wirtualnych o niskiej jakości, aplikacja jest bardzo responsywna). Z drugiej strony, spędza praktycznie połowę czasu na optymalizacji kodu.

Nie sposób przecenić wagi optymalizacji kodu. Celem optymalizacji kodu nie jest upewnienie się, że działa on poprawnie dzisiaj , a celem jest zoptymalizowanie go tak, aby po trzech latach nie naprawiać jakiegoś problemu, któremu można było zapobiec dzięki optymalizacji kodu.

Jeśli zależy Ci tylko na tym, aby użytkownicy byli zadowoleni dzisiaj, jutro będziesz walić w Twoje drzwi.

  1. Pisze ręcznie wszystkie SQL i odrzuca ideę ORM. Należy zauważyć, że obecny produkt jest oparty na ORM Entity Framework firmy Microsoft, a dwóch z pięciu programistów nigdy wcześniej nie korzystało z SQL.

Dwóch z pięciu programistów powinno zostać zwolnionych. . Jeśli polegasz na ORM, nigdy nie będziesz w stanie wejść pod maskę i naprawić rzeczy ręcznie. Zaczynam rozumieć, dlaczego z frustracji nazwał kogoś „małpą kodu”. ORMy są dobre i dobre, ale jeśli zamierzasz kiedykolwiek wyjść poza ograniczenia ORMów, musisz rozumieć język SQL.

  1. Odrzuca frameworki i po trzecie -partne biblioteki, biorąc pod uwagę, że znacznie łatwiej jest pisać rzeczy od zera. Zdecydował się porzucić wszystkie biblioteki i frameworki JavaScript z wyjątkiem jQuery, twierdząc, że kiedy zaczął programować w JavaScript piętnaście lat temu, nie było żadnych frameworków, a życie było dużo łatwiejsze.

On ma rację. Struktury i biblioteki innych firm mają ograniczenia, a jeśli nie rozumiesz wystarczająco dużo, aby wejść i naprawić to samodzielnie, nie rozumiesz kodu. Można by argumentować tak czy inaczej. Jeśli jednak nikt w zespole nie może kodować bez użycia frameworków, to masz bardzo słaby zespół.

  1. Uważa, że ​​urządzenia mobilne (w tym tablety) są tylko szumem reklamowym, więc nie ma powodu, aby tracić cenny czas na zapewnienie zgodności strony z tymi urządzeniami i tworzenie responsywnego projektu. Produkt jest publiczną aplikacją internetową, z której nie oczekuje się częstego używania na urządzeniach mobilnych. Jednak projekt responsywny może być bardzo interesujący dla tej aplikacji, ponieważ nawet na komputerach stacjonarnych będzie on wyświetlany zarówno na monitorach 19-calowych, jak i dużych monitorach o wysokiej rozdzielczości.

Ze wszystkiego, co powiedziałeś, wynika, że ​​został sprowadzony do czystego domu. Jeśli urządzenia mobilne nie odgrywają znaczącej roli w przypadku aplikacji, spędzanie zbyt dużej ilości czasu jest stratą. Chociaż „miło mieć” na komputerze stacjonarnym, „dobrze mieć” nie jest koniecznością przy wdrażaniu.

  1. Prosi zespół o przestań używać Internetu (zwłaszcza StackOverflow) i polegaj na ich mózgach, dokumentacji offline (nawet nie wiedziałem, że Microsoft nadal sprzedaje płyty MSDN!) i książkach.

Dobrze Wygląda na to, że chce wiedzieć, kto może samodzielnie odrobić pracę domową, a kto oszukuje.

Członkowie zespołu skarżyli się założycielowi firmy, że ich nowy kierownik w tych trzech kwestiach. Założyciel odpowiedział, że przesadzają i że ma absolutne zaufanie do umiejętności nowego lead'a na podstawie jego CV i wywiadu, dlatego właśnie przypisał tej osobie przede wszystkim rolę głównego developera.

Co zespół powinien zrobić, aby:

  • Wyrzucić prowadzenie z zespołu lub firmy,

  • Albo zmusić go do zmiany nastawienia do zespołu?

Co powiesz na współpracę z nim i nie sabotowanie każdego jego ruchu .?

Szczerze mówiąc, brzmi to jak został wprowadzony do czystego domu, biorąc pod uwagę to, co opublikowałeś, brzmi to bardziej niż uzasadnione.

Właściciel NIE jest zadowolony z twojego występu. Byłoby dobrze, gdybyś skorzystał z rady tego gościa, co jest warte. Mamy trochę doświadczenia i wiemy, czego książki nigdy cię nie nauczą. Jednak zamiast postrzegać to jako okazję do nauki i rozwoju, Twój zespół ma ogromną ochotę.

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (http://chat.stackexchange.com/rooms/46877/discussion-on-answer-by-richard-u-how-to-handle-a-senior-developer-diva-kto się wydaje).
#6
+6
Riley
2016-10-14 15:49:19 UTC
view on stackexchange narkive permalink

Więc nie wiem, do jakiego stopnia członkowie Twojego zespołu skarżyli się szefowi na głównego dewelopera. Ale czy miałeś z nimi dobrą rozmowę przy stole? Wyjaśnij swojemu szefowi problemy, które masz z głównym deweloperem i pozwól mu przedstawić swoją wersję wydarzeń.

Rzucenie palenia powinno być ostatecznością.

Wygląda na to, że wszyscy tutaj założyli, że „wódz przemówił”, ale może tak nie być.Z tego, co przeczytałem, pracownicy i nowy kierownik odbyli tylko indywidualne rozmowy z szefem, a nie wszyscy naraz.Warto spróbować.
Czy możesz rozszerzyć i wyjaśnić więcej?To ważna opinia przeciwna odpowiedzi Chrisa, ale w tej chwili nie ma wystarczająco dużo szczegółów, aby była to dobra odpowiedź.
+1 Za niech diva opowie swoją stronę.Narzekania są tak rażące, że wyglądają na nieprawdziwe.Na pewno jest to klasyczne zderzenie ego, a przynajmniej jeden z twórców jest toksyczną osobą
Jeśli jesteś niezadowolony ze swojej pracy i nie jesteś zainteresowany kupowaniem gówna za próbę naprawienia tego, po co zostać?Jest mnóstwo lepszych miejsc pracy.
#7
+1
BobRodes
2016-10-16 00:21:54 UTC
view on stackexchange narkive permalink

„Zmarszczka”, której jeszcze tu nie widziałem. Często zdarza się, że ludzie z dużym doświadczeniem przyjmują defensywę i nie są na bieżąco z bieżącymi wydarzeniami. Tak samo postępowałem, gdy ludzie rozmawiali o tym, jak okropne było VB6 w stosunku do cudownego .Net, kiedy ci ludzie powtarzali rzeczy, które słyszeli o VB6 i tak naprawdę niewiele o tym wiedzieli.

Jak mówisz, wiele rzeczy, o których mówi lider, jest w porządku. Ale to nie znaczy, że wszyscy są, jak mówisz. Być może Pan 25-letni może otworzyć swój umysł i zsyntetyzować swoje podejście z najlepszym status quo, ale nie, jeśli boi się być mniej niż doskonały i zaprzeczać, że się boi. O ile mi wiadomo, to jest rzeczywisty problem. Juniorzy mogą mieć inne problemy (na przykład defensywne w związku z brakiem wiedzy), ale wydaje się, że jest to podstawowy problem.

Jeśli wszyscy spotykają się i odnoszą się do swoich obaw w otwarty i szczery sposób, powinni zacząć podążać w bardziej pozytywnym kierunku. Nie mogę powiedzieć, że brzmi to na duże prawdopodobieństwo, ale trzeba to zrobić.

#8
+1
bob
2019-04-30 00:48:11 UTC
view on stackexchange narkive permalink

Właściciel musi zatrudnić kierownika ds. personelu

Inne odpowiedzi wskazują na to, ale słoń w pokoju jest taki, że właściciel (co zrozumiałe) wydaje się mieć trudności z pomyślnym wykonywaniem czynności personelu, takich jak zatrudnianie , szkolenie, strzelanie, itp. Przykład: właściciel obsadza zespół, który osiąga słabe wyniki, wytrzymuje z nim lata, a następnie zatrudnia 25-letniego weterana, który naprawia różne rzeczy, a następnie zatrudnia konsultanta, gdy 25-letni weteran nie może tego naprawić. Wygląda na to, że właściciel nie wie, jak prowadzić firmę po stronie personelu. W porządku, są ludzie, którzy zarabiają na życie i dlatego większość organizacji ma menedżerów. Właściciel musi wynająć jedną statystykę. Dzięki temu właściciel będzie mógł skupić się na strategicznej stronie biznesu, więc wygrywa.

Być może OP mógłby pomóc w przeprowadzeniu rozmowy (w końcu właściciel wydaje się potrzebować pomocy w tym zakresie)?

#9
-6
alexk
2016-10-14 17:44:45 UTC
view on stackexchange narkive permalink
  1. Czy cały zespół rozmawiał razem z tym programistą i próbował wyjaśnić korzyści płynące z kontroli wersji i IDE? Może pomóc szczera dyskusja masowa.

  2. Zgadzam się, że obrażanie innych programistów jest nieprofesjonalne i należy mu to zdecydowanie wyjaśnić. Zapytaj go, czy jest szczęśliwy, jeśli inni przyjmują ten sam ton

  3. Zapytaj go, czy przeżywa jakiś stres w domu lub czy ma problemy zdrowotne, takie jak cukrzyca, która powoduje u niego rozdrażnienie

  4. Zapytaj go, czy podoba mu się starzenie się starożytnym i zrzędliwym staruszkiem z atrofią umysłu, gdy nie uczy się niczego nowego.

  5. Jeśli wszystko inne zawiedzie, powiedz, że wszystkie jego błędy zostaną udokumentowane, aby zapisać Twoją własną skórkę, a rozmowy z nim mogą być nagrywane.

Nikt nie zmieni swojego zdania na temat kontroli wersji i IDE po 25 latach.Nie zamierzam zmieniać opinii.Na szczęście dla mnie, moich kolegów i firm, dla których pracuję, jestem wszystkim za kontrolą wersji (nawet w przypadku pracy, którą wykonałem samodzielnie; to uratowało mi tyłek wcześniej) i za używanie IDE (dlaczegona ziemi nikt by nie używał IDE).Ale znowu żadna dyskusja nie zmieni jego zdania.
„Zapytaj go, czy cieszy się, że starzeje się i jest zrzędliwym staruszkiem z atrofią umysłu, gdy nie uczy się niczego nowego” Coś mi mówi, że to nie pójdzie dobrze.
+1 za próbę wyjaśnienia korzyści.-2 za obrażanie go, bez względu na to, jak niegrzeczny jest * on *.
Myślę, że głównym problemem związanym z tą odpowiedzią jest to, że sugeruje ona, iż lider zespołu jest na tym samym poziomie autorytetu co reszta zespołu, co nie jest prawdą.Chociaż lider zespołu nie może nikogo zwolnić, właściciel postawił go na czele, a właściciel z pewnością może zwolnić ludzi, więc nietrudno sobie wyobrazić, że bycie niegrzecznym z powrotem do lidera zespołu może nie skończyć się dobrze dla członków zespołu, mimo żeto może być kuszące.
Podczas interakcji z przełożonymi zawsze mądrze jest posługiwać się taktem.


To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...