Założyciel odpowiedział, że przesadzają i że ma absolutne zaufanie do umiejętności nowego lidera, opierając się na jego CV i rozmowie kwalifikacyjnej, dlatego właśnie przypisał tej osobie przede wszystkim rolę głównego programisty.

The head guy has spoken. To nie jest rząd ani partia polityczna. Nie możesz nikogo wyrzucić ani poprowadzić powstania.

Jeśli nie chcesz sobie z tym poradzić, masz naprawdę jedną opcję. Możesz połączyć siły i grozić, że odejdziesz, chyba że coś się stanie.

Mówię, że możesz, a nie powinieneś. Jest niezwykle duża szansa, że to się nie skończy dobrze. Zasadniczo starasz się wyprzedzić szefa, który podjął decyzję, a ludzie odpowiedzialni nie lubią, gdy się ich kwestionuje.

Przypuszczam, że “właściwą” rzeczą, którą powinieneś powiedzieć, jest znalezienie technik, które zachęcą go do tego, by zobaczył twój sposób myślenia. Ale ja nie zamierzam tego robić. Jestem 30 letnim starszym deweloperem i mogę powiedzieć, że w dużej mierze stałem się nastawiony na moje podstawowe sposoby myślenia. Nie, nie jestem luddytą jak ten facet i tak, przyjmuję sugestie. Przyjmuję nowe technologie i tak dalej. Ten facet najwyraźniej myli się w wielu sprawach. Mogę ci jednak powiedzieć, że kiedy jestem na czymś nastawiony i jestem przekonany, że podejmuję właściwą decyzję, trzymam się jej. Nie podchodzę dobrze do gróźb, a przymus lub manipulacja jest jeszcze gorsza.

Chodzi mi o to, że jest przekonany, że jest “programistą Jezusem” (co jest smutną, niefortunną postawą) i nigdy go nie zmienisz, nie na tym etapie jego kariery. Jest on przekonany, że ma rację i uważa, że jego doświadczenie go wspiera. Niestety, szef też.

Szczerze mówiąc, to prawdopodobnie nie jest warte stresu ciebie i twojego zespołu. Sugeruję, aby każdy z was zaczął szukać nowej pracy i odszedł, gdy już ją znajdzie. Kiedy ktoś wyjdzie, upewnijcie się, że powiedzą szefowi dlaczego. W końcu może dostać obraz. Ale nawet wtedy, to nie jest żadna gwarancja. Zadaj sobie pytanie, czy w tym, co nam powiedziałeś, jest coś, co nie oznacza ewentualnej zguby produktu? Jestem pewna, że to wiesz. Kwestionuję podstawową inteligencję założyciela w tej sprawie. Deweloperzy zazwyczaj są bardzo kiepskimi kierownikami projektów/programów. To osobny zestaw umiejętności i muszą się zrównoważyć. To jak powiedzenie: “Nie potrzebujemy oddzielnych testerów, testy deweloperskie działają świetnie”. Oba są receptami na katastrofę. Powodzenia. Mówię poważnie.

Opis sytuacji w PO jest prawdopodobnie jednostronny. To jest ok.

Jestem starzejącym się deweloperem (~54 yo) wprowadzonym do firmy, aby nie rządzić, ale dostarczyć trochę doświadczenia. (Szef IT rzeczywiście powiedział “siwe włosy”, lol.) Personel dev był far bardziej adeptem, na bilansie, niż jakikolwiek zespół, z którym pracowałem wcześniej. Dużo mnie nauczyli, szczególnie o pokorze! Ale znaleźliśmy miejsca, w których ich technologiczne czarodziejstwo nie rozwiązywało problemów, a w niektórych przypadkach ukrywało te problemy, ostatecznie je pogarszając. To właśnie tam mogłem się naprawdę przyczynić.

Twoja główna rola brzmi poważnie autokratycznie. Wygląda na to, że otrzymał on mandat od właściciela. Właściciel jest niezadowolony z personelu Deva i sprowadził tego “twardonosego, bezsensownego go-gettera”, aby poprawić szybkość dostaw.

Po pierwsze, spójrz na swój personel. Czy macie słabe strony - 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 unikalnych umiejętności.

On nienawidzi IDE

Znam kilku, którzy to robią. Sprawia, że przewracam oczami, ale ostatecznie mnie to nie obchodzi. Jeśli ludzie produkują używając vi, to ok. I love my IDEs.

He doesn’t refactor the code, and doesn’t care about style (which is inconsistent across his own code)

Red flag on the first part. Czy on jest copy-pasterem? Jestem również winny, że nie dbam o styl, ale to dlatego, że używam mojego IDE, aby natychmiast uczynić mój kod Pythona zgodnym z PEP8. Ale on nie używa IDE…

As a side note, style was previously checked by a nightly build, which began to fail since the arrival of the new lead.

He rejects the idea of a nightly build, as well as automated tests. Według niego “każdy profesjonalny programista i tak testuje swój kod ręcznie, więc nie ma powodu, by tracić czas na pisanie testów automatycznych”. Również nocna budowa jest według niego stratą czasu.

To również uruchamia czerwoną flagę, ale z innych powodów niż można by się spodziewać. Zanim ten facet został zatrudniony, ile razy właściciel powiedział, że nie może zrobić X (dać demo, użyć systemu, itp.), ponieważ nocna budowla zawiodła? Co jeśli właściciel zauważy, że problem stanowi nocna budowla? Jak myślisz, co by powiedział Ołowowi, żeby zrobił?

Ale mam obawy co do postawy Ołowianego; zautomatyzowane testy są niesamowite. Tak jak poprzednio, szef może nie rozumieć wartości testów, ale na pewno wie, że Y% pracowników dev płaci za nie. Kiedy przybyłem do mojej obecnej firmy, “mafia 100% pokrycia testowego” przejęła personel dev i poniosła koszty. Jedno złe jabłko później i personel dev znowu mruczał.

On myśli, że kontrola wersji jest w większości bezużyteczna…

Jest to czerwona flaga najwyższego rzędu. On jest tak zły, jak to tylko możliwe. Jest nieodpowiedzialny za pieniądze właściciela.

Wyolbrzymia znaczenie optymalizacji kodu.

W dzisiejszych czasach optymalizacja kodu może coś zmienić. Teraz maszyny są tak szybkie, że jest to mniej ważne. Zamiast tego, musimy teraz martwić się o wydajność baz danych i przepustowość sieci. Ale jego nawyk “optymalizacji kodu” jest trudny do przełamania, zaufaj mi. Muszę sprawić, że nie będę się wstępnie optymalizował. Przynajmniej jego zachowanie w tym przypadku nie jest destrukcyjne, z wyjątkiem czasu. (Masz numery dla jego “połowy czasu”, czy to hiperbola?) Jeśli krytykujesz swojego przełożonego, nie można pozwolić na hiperbolę. Musisz być patologicznie obiektywny.)

On pisze cały SQL ręcznie, i odrzuca pomysł ORM.

Winny jak oskarżony! Nie rozumiem strachu ludzi przed SQL-em. Nie rozumiem zakopywania SQL'a, który jest prosty jak drop-dead, pod warstwami ORM'a, które zatykają. Nic na to nie poradzę :-D Ale proszę, wyrzuć cały swój SQL w jedno miejsce - nie rozpowszechniaj całego kodu.

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

To niedopuszczalne. Jest rok 2016.

He rejects frameworks and third libraries, considering that it’s much easier to write stuff from scratch.

He could not be more wrong. Wątpię, żeby twoja firma była tak wyjątkowa, że twoje narzędzia muszą być napisane we własnym zakresie. Mieliśmy kilku programistów, którzy zajmowaliby się narzędziami innych firm - dopóki nie zrobiliby czegoś w sposób, który nie spodobałby się devowi. To była wymówka, by wyrzucić narzędzie i napisać własne. To tylko zwiększa obciążenie personelu deva, spowalniając go dalej. Ten nieprzydatny kod jest drogi w pisaniu, testowaniu, debugowaniu i utrzymaniu. Wydaliśmy tak dużo pieniędzy na -zerową - korzyść. Tych programistów już nie ma.

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

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

Używamy AngularJS i wydaje się on być przyzwoity. Jak wszystkie potężne narzędzia, może być używany dla dobra lub zła.

On myśli, że urządzenia mobilne (w tym tablety) są tylko hype, więc nie ma powodu, aby marnować cenny czas na zapewnienie kompatybilności strony z tymi urządzeniami i zrobić responsive design. Produkt jest publiczną aplikacją internetową, która nie powinna być często używana z urządzeń mobilnych.

Znowu się myli. Oni nie są hype. Są tu po to, żeby zostać, bo są użyteczne. Ale biznes tego nie potrzebuje. Nie rozwijaj rzeczy, których nie potrzebujesz. To jest drogie.

Responsive design, however, could be very interesting to have for this app,…

Is it so interesting you’d pay for the development personally? Jeśli to jest dobry pomysł, to powinieneś być w stanie sprzedać go właścicielowi. W przeciwnym razie nie wydawaj na niego ani grosza.

Prosi zespół, aby przestał korzystać z internetu (szczególnie StackOverflow) i polegał na ich mózgach, dokumentacji offline (nawet nie wiedziałem, że Microsoft nadal sprzedaje płyty MSDN!) i książkach.

Myli się. Internet jest do tego świetny. Jeśli personel Deva kopiuje z Stackoverflow nie rozumiejąc jak działa kod, to oni też się mylą. Czy jest czas na szkolenia i osobiste udoskonalenia w harmonogramie rozwoju? Ciężko jest nie kopiować-wklejać robotycznie, kiedy zawsze jesteś pod bronią.

• *

Podczas gdy ja mam ograniczone informacje, jest tu wiele problemów. Wygląda na to, że właściciel nie dostał kodu, za który płaci tak szybko, jak się spodziewa. Brzmi to tak, jakby słyszał wiele wymówek na temat rzeczy, na których mu nic nie zależy; jest skupiony na wyniku. Jeśli mam rację, masz ranę zadaną sobie samemu i otworzyłeś ją więcej niż raz. Ten ołów jest rozwiązaniem dla właściciela problemu, który postawił personel Deva, a biorąc pod uwagę jego ograniczone informacje, jest to zrozumiałe.

Założę się również, że prowadzisz sklep nieagile i masz słabą definicję wymagań, która zmienia się wraz z wiatrem. Nie ma warstwy izolacji pomiędzy personelem dev a właścicielem. Z wyjątkiem tego ołowiu.

Co możesz teraz zrobić?

1) Pociągnij ołów, że korzystanie z automatycznego testowania i zarządzania kodem jest drogą do celu. Zdobycie z nim wiarygodności może zająć trochę czasu - właściciel prawdopodobnie powiedział mu, że personel jest wadliwy. Zobacz, czy możesz uniemożliwić mu wykonywanie mandatów wymiatających, takich jak “usuń wszystkie te 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 będziesz mógł odzyskać swoje własne błędy. Nie mów mu, że to robisz, ale też go nie okłamuj.

3) Kontynuuj automatyczne testy (testy jednostkowe, jeśli nic innego) na poziomie osobistym. Tak jak poprzednio, nie wspominaj o tym, choć nie ukrywaj tego.

4) Pracuj z liderem, aby określić, jakie są rzeczywiste postrzegane problemy. Bądź otwarty, założę się, że istnieją rzeczywiste problemy z personelem. Pracuj z Ołowiem, aby zająć się problemami, a nie objawami.

5) Przedyskutuj z Ołowiem różne tematy rozwojowe, takie jak korzyści płynące z wodospadu i zwinności. Żaden z nich nie jest doskonały. Zadawaj mu pytania, takie jak: “W jakich okolicznościach zautomatyzowane testy byłyby warte zachodu”? Jeśli udzieli wątpliwej odpowiedzi, zapytaj go, jak udane firmy, takie jak Google, zdołały się mimo to rozwijać.

Tak więc widzisz, że chodzi mi o zaangażowanie Lid'a i zobaczenie, gdzie jest jego głowa. Zbuduj zaufanie. Zgodzić się na kwestie kontra objawy. Nie zawsze jest to łatwe, zwłaszcza gdy czujesz, że jest jak Godzilla i rozrywa Twoją pracę na strzępy.

Jest szansa, że nie może iść na kompromis. On zmiażdży zautomatyzowane testy. Zarządzanie kodeksem jest dla nieostrożnych ludzi. My Way or the Highway.

Jeśli jednak dojdzie do tego punktu, nadejdzie 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ł Lead. W takim razie ruszajcie dalej.

25 lat w IT […] zmień jego nastawienie

Nie uda się, przepraszam.

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

Twój założyciel ufa niekompetentnemu* obcemu człowiekowi bardziej niż jego dotychczasowym pracownikom.

Musisz dowiedzieć się, jak zespół stracił zaufanie i jak je odzyskać. Byłoby łatwiej, gdyby zrobiono to przed zatrudnieniem tego obcego. Teraz jest to trudne, ponieważ każda dobra praca będzie przypisana do nowego kierownika zespołu, a każda zła praca będzie przypisana do was wszystkich - więc nie możecie tego naprawić, pracując ciężej.

Są tylko dwie rzeczy, które mogę wymyślić, aby poprawić sytuację w tej pracy:

1. Znajdźcie mediatora. Czy jest wielu założycieli, czy coś w rodzaju członków zarządu?
2. Być może problem zaufania jest kwestią widoczności. W takim przypadku pomoże Ci wszystko, co pomoże Ci zwiększyć widoczność. Np. zróbmy sprintowe dema na tyle ekscytujące i interesujące, że założyciel faktycznie w nich uczestniczy i dowiaduje się o statusie i postępach zespołu.

• *

** Chociaż większość punktów zgłoszonych przez OP niekoniecznie czyni nieznajomego niekompetentnym, jego podejście do kontroli wersji i ciągłej integracji w 5-osobowym zespole na pewno tak.

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

• *

Pierwsza czerwona flaga to For a few years, the founder was unhappy about the technical skills of the employees

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

• *

Druga czerwona flaga to two of the five developers never used SQL before

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

• *

Trudno sobie wyobrazić, że I worked for twenty-five years in this industry, and you? What have you done? You've been a code monkey for three years. So shut up, you, moron! Nobody cares about your opinion, a ******. zostało rzeczywiście wypowiedziane, ale wezmę to na poważnie i uwierzę Ci.

Jednak czy uważasz, że pierwsza czerwona flaga, o której wspomniałem i “nieszczęście”, z którym założyciel miał do czynienia od lat?

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

Jak ta informacja została wam przekazana?

• *

Jestem skłonny myśleć, że ten facet robi dokładnie to, do czego został zatrudniony.

Getting you into shape does not refer to adopting the new guy’s bad practices but it does involve throwing you out of your comfort zone to learn at a deeper level.

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

Brzmi jakby założyciel nie ufał żuchwom.

Zespół w ciągu dwóch miesięcy stał się jednak o wiele mniej doceniany przez jego profil. Miałem okazję rozmawiać z trzema z pięciu członków tego zespołu, a oni wszyscy podkreślali trzy kwestie:

• Według nich facet jest palantem i nie ma szacunku dla innych członków zespołu. Jeden z ostatnich cytatów z jego rozmowy z młodszym programistą przed zespołem jest bardzo obrazowy: “Pracowałem w tej branży przez dwadzieścia pięć lat, a ty? Co pan zrobił? Przez trzy lata byłeś kodową małpą. Więc zamknij się, ty kretynie! Nikogo nie obchodzi twoja opinia.”

Wygląda na to, że masz tylko jedną stronę historii. Mogę sobie wyobrazić kilka sytuacji, w których będę musiał sam spoliczkować młodego człowieka i tak się stało. tylko grając tu adwokata diabła, ale brzmi to tak, jakby został sprowokowany. Co to była za prowokacja?

• W przeszłości decyzje podejmowali wszyscy członkowie zespołu. Kiedy członkowie nie chcieli się zgodzić, omawiali to wszystko razem i dochodzili do porozumienia, a przynajmniej wyjaśniali tok rozumowania tym, którzy się nie zgodzą.

Najwyraźniej dotychczasowe praktyki nie przyniosły takich rezultatów, jakich chciał założyciel.

• Teraz wszystkie ważne decyzje są podejmowane wyłącznie przez głównego programistę. Te decyzje nie mogą być kwestionowane ani omawiane, nawet jeśli wszyscy pięcioro członków zespołu uzna, że dana decyzja nie ma sensu.

Ponownie, brzmi to jak wotum nieufności założyciela. Nie bez powodu sprowadził on tego typu osobę. Brzmi, jakby powodem było biczowanie reszty personelu.

1. Nienawidzi IDE, automatycznego uzupełniania i funkcji, które mają pomóc programistom szybciej pisać kod, i twierdzi, że zespół powinien używać Notatnika++, aby być produktywnym. Choć ma to sens w różnych okolicznościach, trudno sobie wyobrazić, żeby programiści C# nagle porzucili Visual Studio dla Notepada++.

IDE może spowolnić pracę, jeśli jesteś szybkim programistą. Notepadd ++ jest lepszy od niektórych, jeśli chodzi o szybkie kodowanie. Idea jest taka, że piszesz swój kod, a następnie wrzucasz go do IDE w celu szybkiej korekty, a nie ciągłego przerywania.

1. Nie przerabia kodu i nie dba o styl (który jest niespójny w jego własnym kodzie), ponieważ “dba tylko o rzeczy, które naprawdę mają znaczenie”. Na marginesie, styl był wcześniej sprawdzany przez nocną budowlę, która zaczęła zawodzić od czasu pojawienia się nowego leadu.

Standardy sklepu są czymś, co warto przedyskutować z założycielem, zwłaszcza, że prowadzisz go przez nocną budowlę. Ale ponownie, czytając między wierszami, wygląda na to, że założyciel nie ufa Ci.

1. Odrzuca pomysł nocnej budowy, jak również automatycznych testów. Według niego, “każdy profesjonalny programista i tak testuje swój kod ręcznie, więc nie ma powodu, by tracić czas na pisanie testów automatycznych”. Również nocna budowa jest według niego stratą czasu.

Ma rację, że zautomatyzowane testy nie odpowiadają za sam geniusz jakiegoś głupca, który robi coś, czego nigdy nie zamierzał. Osobiście złamałem kilka programów, które przeszły testowanie automatyczne.

1. On uważa, że kontrola wersji jest w większości bezużyteczna i wydaje się źle rozumieć, jak jej używać. Prowadzi to do sytuacji, w której sam rozwija daną funkcję przez trzy do pięciu dni, a kiedy w końcu wprowadza swoje zmiany, robi “weź moje” za wszystkie konflikty. Jeśli inni członkowie zespołu skarżą się, że ich kod został wymazany, zachęca ich do jego przepisania. Kilkakrotnie inni członkowie zespołu robili to samo, kasując kod głównego dewelopera. Wyglądał na zaskoczonego (wygląda na to, że nie wie, jak używać svn logu czy diffów), i zrobił swoje zmiany ponownie, narzekając, że “tajemniczo się zgubili” i obwiniając SVN za spieprzenie.

Wszyscy są tu winni. Czy nikt nie robi kopii zapasowych? Jeśli ma problemy z kontrolą wersji, to do jego obowiązków należy praca zespołowa, a nie tylko sprawiać mu trudności.

1. Przecenia znaczenie optymalizacji kodu. Jego podejście jest poprawne, tzn. prowadzi profiler, określa 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 hostowaną na maszynach wirtualnych niskiej klasy, aplikacja czuje się bardzo responsywna). Z drugiej strony, praktycznie połowę czasu poświęca na optymalizację kodu.

Nie sposób przecenić znaczenia optymalizacji kodu. Celem optymalizacji kodu nie jest upewnienie się, że działa prawidłowo today celem jest zoptymalizowanie go tak, aby Nie naprawiasz jakiegoś problemu trzy lata później, któremu można było zapobiec dzięki optymalizacji kodu.

Jeśli zależy Ci tylko na tym, aby użytkownicy byli dziś szczęśliwi, jutro będziesz miał ich na oku.

1. Pisze cały SQL ręcznie i odrzuca pomysł ORM. Należy zauważyć, że obecny produkt jest oparty na Microsoft'owym ORM Entity Framework, 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ć wtedy zwolnionych. Jeśli opierasz się na ORM-ie, nigdy nie będziesz w stanie dostać się pod maskę i ręcznie naprawiać rzeczy. Zaczynam rozumieć dlaczego we frustracji nazwał kogoś “małpą kodu”. ORMy są w porządku i dobre, ale musisz zrozumieć SQL, jeśli kiedykolwiek zamierzasz wyjść poza ograniczenia ORM.

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

Ma rację. Ramy i biblioteki innych firm mają ograniczenia, a jeśli nie rozumiesz wystarczająco dużo, żeby wejść i samemu je naprawić, nie rozumiesz kodu. Argument może być postawiony tak czy inaczej. Jeśli jednak nikt z zespołu nie potrafi kodować bez użycia frameworków, to masz bardzo słaby zespół.

1. Uważa, że urządzenia mobilne (w tym tablety) to tylko hype, więc nie ma powodu, aby marnować cenny czas na zapewnienie kompatybilności strony z tymi urządzeniami i stworzenie responsywnego projektu. Produkt jest publiczną aplikacją sieciową, która nie powinna być często używana z urządzeń mobilnych. Responsive design może być jednak bardzo interesujący dla tej aplikacji, ponieważ nawet na komputerach stacjonarnych będzie ona wyświetlana zarówno na 19-calowych monitorach, jak i na dużych monitorach wysokiej rozdzielczości.

Ze wszystkiego, co powiedziałeś, brzmi to tak, jakby został sprowadzony do czystego domu. Jeśli urządzenia mobilne nie są głównym odtwarzaczem dla aplikacji, spędzanie zbyt wiele czasu jest stratą. O ile “fajnie mieć” na pulpicie, o tyle “fajnie mieć” nie jest koniecznością przy rolloucie.

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

Dobre dla niego. Wygląda na to, że chce wiedzieć, kto może odrobić swoją własną pracę domową, a kto oszukuje.

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

What should the team do:

• Either throw the lead out of the team or the company,

• Or force him to change his attitude towards the team?

A może pracować _z nim i nie sabotować jego każdego ruchu?

Szczerze mówiąc, brzmi to tak, jakby został przyprowadzony do czystego domu, biorąc pod uwagę to, co umieściłeś, brzmi to bardziej niż uzasadnione.

Właściciel nie jest zadowolony z Twojego występu. Byłoby wspaniale, gdybyś skorzystał z jego rady, za to 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 ogromny atut syczenia.

Więc nie wiem, na ile członkowie twojego zespołu skarżyli się szefowi na głównego deva. Ale czy miałeś z nimi dobrą rozmowę przy stole? Wyjaśnij swojemu szefowi problemy, które masz z Devem i pozwól mu mieć jego stronę.

Rezygnacja powinna być ostatnią deską ratunku.

Właściciel musi zatrudnić kierownika personelu

Inne odpowiedzi na to wskazywały, ale słoń w pokoju jest taki, że właściciel (co zrozumiałe) wydaje się mieć trudności z pomyślnym wykonywaniem funkcji personalnych, takich jak zatrudnianie, szkolenie, zwalnianie, itp. Przypadek w tym miejscu: właściciel zatrudnia personel w trakcie wykonywania zespołu, znosi je przez lata, następnie zatrudnia 25-letniego weterana, aby naprawić rzeczy, a następnie zatrudnia konsultanta, gdy 25-letni weteran nie może naprawić rzeczy. Wydaje się, że właściciel nie wie, jak prowadzić stronę personalną firmy. W porządku, są ludzie, którzy robią to na co dzień i dlatego większość organizacji ma menedżerów personalnych. Właściciel musi zatrudnić jednego pracownika. To uwolni właściciela od konieczności skupienia się na strategicznej stronie biznesu, więc jest to wygrana.

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

“Zmarszczka”, której jeszcze tu nie widziałem. Dość często zdarza się, że ludzie z dużym doświadczeniem bronią się, że nie nadążają za aktualnymi wydarzeniami. Kiedyś tak samo postępowałem z ludźmi, którzy mówili o tym, jak straszny jest VB6 w stosunku do cudownej .Net, kiedy ci ludzie tylko powtarzali rzeczy, które słyszeli o VB6 i tak naprawdę niewiele o nim wiedzieli.

Jak mówisz, wiele rzeczy, które mówi lider jest na rzeczy. Ale to nie znaczy, że wszystkie one są, jak mówisz. Być może Pan 25 lat 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. Jeśli chodzi o mnie, to jest to prawdziwy problem. Mogą być inne problemy z juniorami (np. w obronie przed brakiem wiedzy), ale wydaje się, że to właśnie jest podstawowy problem.

Jeśli wszyscy spotykają się i zajmują się swoimi obawami w otwarty i uczciwy sposób, to powinni zacząć iść w bardziej pozytywnym kierunku. Nie mogę powiedzieć, że brzmi to jak wysokie prawdopodobieństwo, ale to jest to, co trzeba zrobić.

1. Czy cały zespół rozmawiał z tym programistą i próbował wyjaśnić korzyści płynące z takich rzeczy jak kontrola wersji i IDE? Szczera dyskusja en masse może pomóc

2. Zgadzam się, że obrażanie innych programistów jest nieprofesjonalne i to powinno być mu wyjaśnione na siłę. Zapytaj go, czy jest szczęśliwy, jeśli inni przyjmą ten sam ton

3. Zapytaj go, czy przechodzi jakikolwiek stres w kraju lub ma problem zdrowotny, taki jak cukrzyca, który powoduje, że jest drażliwy

4. Zapytaj go, czy jest szczęśliwy, że jest starożytny i zrzędliwy stary git z zanikiem umysłu, gdy uczy się niczego nowego.

5. Jeśli wszystko inne nie powie, że wszystkie jego błędy zostaną udokumentowane, aby zapisać własną skórę i rozmowy z nim mogą być rejestrowane