Jak rozpoznać, czy porady starszego programisty są złe? [Zamknięte]

Niedawno zacząłem swoją pierwszą pracę jako młodszy programista i mam starszego programistę odpowiedzialnego za mentoring w tej małej firmie. Jest jednak kilka razy, gdy udzielał mi porad na temat rzeczy, z którymi po prostu nie mogłem się zgodzić (jest to sprzeczne z tym, czego nauczyłem się w kilku dobrych książkach na ten temat napisanych przez ekspertów, pytania, które zadałem na niektórych stronach z pytaniami i odpowiedziami również są zgodne. ze mną) i biorąc pod uwagę nasz napięty harmonogram, prawdopodobnie nie mamy czasu na długie debaty.

Do tej pory starałem się uniknąć tego problemu, słuchając go, podnosząc kontrapunkt w oparciu o to, czego nauczyłem się jako aktualne dobre praktyki. Ponownie podnosi swój pierwotny punkt (przez większość czasu będzie mówił o najlepszej praktyce, łatwiejszej do utrzymania, ale po prostu nie poszedł dalej), odnotowuję (ponieważ nie podniósł nowego punktu, aby odeprzeć mój kontrapunkt), pomyśl o i badaj w domu, ale nie wprowadzaj żadnych zmian (wciąż nie jestem przekonany). Ale ostatnio znów się do mnie zbliżył, zobaczył mój kod i zapytał, dlaczego nie zmieniłem go na jego sugestię. To trzeci raz w ciągu 2-3 tygodni.

Jako młodszy programista wiem, że powinienem go szanować, ale jednocześnie nie mogę zgodzić się z niektórymi jego radami. Jednak jestem pod presją wprowadzenia zmian, które moim zdaniem pogorszą projekt. Oczywiście jako niedoświadczony programista mogę się mylić, a jego sposób może być lepszy, może to być jeden z tych wyjątków.

Moje pytanie brzmi: co mogę zrobić, aby lepiej ocenić, czy rada starszego programisty jest dobra, zła, czy może jest dobra, ale nieaktualna w dzisiejszym kontekście? A jeśli jest źle / nieaktualne, jakich taktyk mogę użyć, aby nie wdrożyć go po swojemu, pomimo jego „presji”, zachowując przy tym fakt, że szanuję go jako starszego?

Po pierwsze, jako starszy programista oczekuję, że juniorzy, których prowadzę w projektach, przedstawią mi swoje obawy w bezpośredni i bezpośredni sposób. Jeśli się nie zgadzają, nie mam nic przeciwko. W niektórych przypadkach podejmę działania w związku z ich obawami. W większości przypadków ich obawy są odrzucane na bok wraz z krótkim wyjaśnieniem uzasadnienia , nie z braku szacunku dla samego dewelopera, ale z innego powodu, takiego jak:

1. Junior nie ma wszystkich dostępnych informacji, aby zrozumieć decyzję w momencie jej podjęcia. W niektórych przypadkach małe wyjaśnienie może pomóc deweloperowi w rozwiązaniu problemu i poradzeniu sobie z wyjątkową sytuacją.
2. Junior ma złe informacje. Nie zapominaj, że w rzeczywistości jesteś młodszy. Pod względem oprogramowania jest to ekwiwalent bycia nastolatkiem. Jestem pewien, że masz wiele świetnych pomysłów, ale możliwe, że nie wiesz wszystkiego. Uważam, że najbardziej odporni młodsi programiści to ci, którzy mocno wierzą, że wiedzą, co jest najlepsze dla kodu, firmy i świata. Ci programiści lepiej służą zdobywaniu pokory.
3. Decyzja o zrobieniu czegoś w szczególny sposób zapadła nad głową seniora. W końcu senior nadal pracuje dla kogoś innego. Może istnieć lepszy sposób na zrobienie czegoś, bardziej efektywny sposób na napisanie czegoś lub lepsze oprogramowanie / sprzęt, które pomogą wykonać to zadanie. Jednak firma wciąż kieruje decyzjami. Menedżerowie, dyrektorzy, wiceprezesi itp. Często podejmują decyzje wpływające na proces rozwoju. Są to poza kontrolą seniora, a gdy juniorzy narzekają na to, wszystko, co robią, to zwiększają stres seniora.
4. Po prostu mieszkaniec senior nie ma czasu, aby wziąć to pod uwagę. Istnieją terminy, a czasem zmiana wzorców, praktyk i zachowań w środkowej fazie jest kosztowna do tego terminu. Ponieważ jest to jego szyja na bloku do krojenia, często ważniejsze jest, aby produkt był funkcjonalny i terminowy niż „perfekcyjnie napisany”.

To tylko rzeczy, o których mogę myśleć z góry. Istnieje mnóstwo powodów, dla których pomysł, praktyka, koncepcja może zostać odrzucona lub odrzucona przez kogoś wyżej niż ty. Wiele z nich jest nieprzyjemnych, ale wszystkie sprowadzają się do faktu, że wszyscy jesteśmy ludźmi i wszyscy mamy opinie. W tej chwili jego opinia jest po prostu lepsza od twojej.

Pamiętając o tych koncepcjach, powinieneś nadal przedstawiać swoje obawy starszemu programistowi. Znajdź innego starszego programistę, który może wypełnić puste pola. Wielu starszych programistów jest tam, gdzie są, ponieważ są lepsi z oprogramowaniem niż z ludźmi. Niektóre są tam, gdzie są, ponieważ wiedzieli, czyje tyłki pocałować, gdy byli stażystami. Znajdź osobę, która faktycznie rozumie, co to znaczy mentorować kogoś i uzyskać jego uczciwą opinię. Mogą się z tobą nie zgadzać i wypełnić puste pola, których nie masz. Mogą się z tobą zgodzić i pomóc zjednoczyć twoją sprawę lub poprawić twoją sytuację.

W żadnym momencie nie powinieneś organizować żadnego powstania. Nawet jeśli wierzysz w swoim sercu, że twoja droga jest słuszna, otrzymałeś instrukcję postępowania i powinieneś go przestrzegać (chyba że jest to oczywiście nielegalne). Jeśli masz problemy z przestrzeganiem tych instrukcji, możesz spróbować wyjaśnić, dlaczego, ponieważ odkryjesz, że ten sposób zachowania jest bardzo rozpowszechniony w bardzo wielu firmach produkujących wszelkiego rodzaju oprogramowanie.

Najlepszą opcją jest kontynuowanie pracy w sposób etyczny i profesjonalny. Zdobądź oprogramowanie, którego wykonanie jest wymagane, w wzorowy sposób i uniknij sytuacji, awansując z niego. Jeśli promocje nie nadejdą, będziesz mieć mnóstwo referencji i doświadczenia, aby wykorzystać możliwości w innych działach lub firmach.

Szanuj starszego programistę. Jest bardziej gotowy na sukces projektu niż ty. Ponieważ ponosi odpowiedzialność, zyskuje także władzę. Jeśli mówi coś zmienić, zrób to.

Biorąc to pod uwagę, nie wahaj się przedstawić swoich obaw, gdy napotkasz problem, który już masz.

Na koniec usiądź z nim i wyjaśnij mu to samo pytanie, które tu zadałeś. Może brakuje ci czegoś dużego, może otworzy się bardziej na twoje sugestie, tak czy inaczej, nie trzymaj go w ciemności, jeśli uważasz, że jego porady są słabe.

Gdy tak się stanie, musisz porozmawiać z głównym deweloperem . Być może wie coś, czego nie wiesz o kodzie lub wymaganiach technicznych / biznesowych. Jeśli tak, powinieneś się tego nauczyć.

Rób to prywatnie. Może to być postrzegane jako trudny autorytet, a takie rzeczy najlepiej robić jeden na jednego. Okazuj gotowość do pójścia na kompromis i współpracę, uznając i szanując jego starszeństwo, ale bądź wytrwały w otrzymywaniu odpowiedzi na pytania. Podejdź do sytuacji z perspektywy współpracy, a nie walki. Możesz rozważyć poproszenie go o mentora.

Pod koniec dnia musisz zrównoważyć własne pomysły (które, mówiąc uczciwie, są stosunkowo nowe i niesprawdzone) z jego pomysłami. Być może masz rację, ale powinieneś starać się uczyć od bardziej doświadczonych ludzi, abyś mógł podjąć bardziej świadomą decyzję. Dobry starszy programista z zadowoleniem przyjmuje możliwość współpracy, mentorowania i uczenia się, nawet z młodszymi programistami, i z zadowoleniem przyjmuje konstruktywne kwestionowanie swoich pomysłów, ponieważ oni również wiedzą, że czasem się mylą.

Sposób, w jaki często mówisz, polega na zdroworozsądkowym podejściu. Pamiętaj, że starszy programista może wiedzieć więcej o projekcie, ale może nie wiedzieć więcej o właściwym sposobie robienia rzeczy. Musisz ocenić, co ci każe zrobić - daje ci złą radę, jeśli to, co mówi, jest sprzeczne z tym, co twierdzą jego lepsi (np. Ludzie starsi od niego; niekoniecznie w twoim towarzystwie ... Mówię o znani programiści „sławni”, którzy często publikują lub piszą książki na temat właściwego sposobu tworzenia oprogramowania lub przynajmniej najlepszych praktyk przyjętych w branży).

Oto przykład „złej porady” od starszego programisty (lub dowolnego programisty): jeśli są całkowicie nieświadomi tego, co to jest luźne sprzężenie i dlaczego jest to dobre, a ty masz napisać cały kod, powiedzmy, kod -poza plikiem ASPX oczywiste jest, że starszy programista nie ma pojęcia i nie należy słuchać jego rad.

Z drugiej strony, jeśli mówi ci, jak działa określony moduł w systemie, często najlepiej jest słuchać tak długo, jak to możliwe, ale to, co mówi, nie pluje w obliczu właściwych zasad rozwoju.

Oto moja ogólna zasada: starszy programista w firmie może być po prostu deweloperem o najdłuższym okresie zatrudnienia; może nie mieć żadnych prawdziwych umiejętności. Czy mówi rzeczy, które są sprzeczne z tym, co mówią niektórzy najbardziej szanowani programiści w Twojej dziedzinie (ludzie z dużo większym doświadczeniem niż on i którzy są o wiele bardziej kompetentni i szanowani)? Jeśli tak, są szanse, że jego rada jest zła, chyba że zachodzą bardzo ekstremalne okoliczności.

Całkowicie spodziewam się głosów negatywnych / nieporozumień dla wyjątkowo stronniczego punktu widzenia.

Może być trudno zrozumieć punkt widzenia starszego programisty i tak, może on poprowadzić sprawy złą ścieżką, jednak w przypadku dużych projektów spójność jest ważniejsza.

Posiadanie 50 niektórych programistów stosujących własne style kodowania, standardy, metodologie i wzorce projektowe byłoby kompletnym chaosem. Jeśli coś jest robione źle, zawsze lepiej jest być konsekwentnie złym niż wiele różnych rodzajów zła i niektórych rzeczy, które zostały zrobione dobrze.

Kiedy przychodzi czas na konserwację, dodanie funkcji lub naprawienie „złego”, wtedy o wiele łatwiej jest, jeśli problemy z istniejącym projektem są znane z góry.

Dobrze jest z szacunkiem się z tym nie zgadzać, ale ostatecznie najlepiej jest się trzymać w szeregu. Nikt z drużyny, który popadnie w nieuczciwość, nie jest postrzegany jako gracz zespołowy.

Jeśli senior nie może podać dobrych powodów, dla których ignoruje najlepsze praktyki branżowe, nie marnuj tam swojego czasu. Nigdy nie awansujesz, ponieważ jesteś zbyt groźny, a zresztą czy chcesz spędzić czas na utrzymywaniu stosu złego kodu?

Większość programistów przestaje czytać po ukończeniu studiów. Nie masz, więc jesteś już w pierwszej 10%. Obecnie jest wiele okazji. Jeśli w twoim mieście nie ma rynku pracy, poszukaj lepszego miasta.

Wow, to wspaniała okazja, abyś mógł zabłysnąć i pokazać swoje umiejętności. Na początku mojej kariery miałem kogoś, kto był moim przełożonym, który nie był w stanie podjąć żadnej decyzji, więc skorzystałem z okazji, aby nauczyć się, jak wykonywać pracę na wyższym poziomie. To mnie awansowało. Powinieneś zrobić to samo.

Jako starszy programista ten rodzaj pasywnego agresywnego wybierania nitów doprowadziłby mnie do szaleństwa, a po konfrontacji doprowadziłby mnie do złej recenzji. Idealnym rozwiązaniem jest to, z którym zespół może żyć razem.

Jeśli chodzi o styl, powinno to być podyktowane przez przewodnik po stylu i najlepsze praktyki określone przez twoje pochodzenie. Jeśli jesteś pasjonatem, kłóć się o to, ale kiedy decyzja zostanie podjęta na żywo i pracuj w granicach zespołu, w którym jesteś.

Jesteś w niezbyt dobrej sytuacji, ale jak zauważył HLGEM, możesz zmienić te pozycje w przebłagalne błogosławieństwa. Twoje pytanie jest wieloaspektowe, więc podchodzę do niego w częściach.

Podejrzewam, że on nie wie. Jednocześnie próbuje mi pokazać, że może być arogancja, abym nie pojawiał się przed nim zbyt często, by zadawać pytania.

To może być prawda. Istnieje duża liczba programistów, którzy działają w branży od dziesięcioleci i nie są zdolnymi liderami oprogramowania - z punktu widzenia rozwoju lub mentoringu (jest różnica). Doświadczenie pochodzi ze stawiania czoła nowym wyzwaniom, wypróbowywania nowych pomysłów i uczenia się nowych umiejętności, ale większość programistów spędza życie w skrzydle Biura Korporacyjnego, pracując nad aplikacją Payroll za pomocą swoich wiernych narzędzi Visual Basic i Java, nigdy nie widząc światowych wyścigów przez ich zimne, szare biuro.

Nie ma w tym nic złego . Dla wielu programistów to wszystko, czego kiedykolwiek chcieli i są całkowicie zadowoleni z sytuacji - nie jest to jednak idealna sytuacja dla wspierania przyszłej generacji programistów, nie mówiąc już o prowadzeniu programistów.

Brawura i arogancja mogą być mechanizmem obronnym, próbującym ukryć niedociągnięcia. Jak sobie z tym radzisz? Nie konfrontuj się z nim od razu - jeśli Twoja przewaga jest niekompetentna, a szef nie chce naprawić sytuacji , będziesz musiał z tym żyć . Nie oznacza to, że przewrócisz się i zginiesz, ale nie możesz zmusić kogoś do dobrego prowadzenia.

Jednak tylko przegląda mój kod, a większość jego komentarzy jest związana z wytycznymi dotyczącymi kodowania

Właśnie dlatego myślę, że masz rację, ponieważ może on nie być dobrym programistą. Nie oznacza to, że nie jest on w tej chwili lepszym programistą niż ty (przynajmniej będzie miał więcej doświadczenia i eksponowania dzięki tak długiej pracy w branży), ale znowu nie oznacza to, że jest skuteczny ołów. Wytyczne są dobre i dobre, ale są drugim po funkcji, skuteczności i wydajności kodu.

Co powinienem zrobić w takiej sytuacji?

Poinformowałem mojego menedżera o tej sytuacji i poprosiłem go o zmianę stanowiska, chociaż za każdym razem mówi „tak”, ale nie podejmuje żadnych poważnych działań.

Czy wyliczyłeś wszystkie te konkretne punkty menedżerowi i podałeś konkretne przykłady na jego poparcie? Jeśli po prostu poszedłeś do niego i powiedziałeś: „Potrzebuję nowego tropu”, nie potraktuje cię poważnie i nie postrzega go jako „problem interpersonalny”, a nie problem techniczny. Reakcja wielu szefów w tej sytuacji polega na zignorowaniu go w nadziei, że „sam się wypracuje”.

Oto kilka sugestii.

1. Nie ocieraj się o swoją sytuację - próba ognia, choć nie jest zabawna, nauczy cię kilku kluczowych umiejętności badawczych na później w karierze.
2. Zacznij naciskać na prowadzenie, aby być bardziej zaangażowanym. Rób to ostrożnie iz szacunkiem . Kontynuuj naciskanie i bądź wytrwały, dopóki się nie poddaje (tak naprawdę działa w wielu sytuacjach życiowych).
3. Jeśli Twój dowódca się nie zaangażuje, sprawdź, czy są inni, którzy mogliby ci pomóc. O ile nie pracujesz w sklepie z potami, który zajmuje się tylko godzinami dojenia, Twoja firma nie będzie miała nic przeciwko innemu deweloperowi z większym doświadczeniem w pokazywaniu lin i sprawdzaniu kodu.
4. Zacznij pilnować nowej pracy. Nie powiedziałbym, że jesteś w „musi opuścić” sytuacji, ale nie zaszkodzi swoją karierę, aby być w miejscu, które ma swój rozwój jako programista bardziej poważnie.

Jeśli masz lepszy sposób na rozwiązanie konkretnego problemu, po prostu ZRÓB TO .

Niech Twój kod / rozwiązanie będzie najlepszym argumentem. W przeciwnym razie trzymaj się tego, co ci powiedziano.

Przykładem

gdy byłem młodszy, miałem sytuację, w której określona sekcja kodu nie była najlepsza, jaką mogła być. Zamiast po prostu dyskutować o tym, ja po prostu poprawił to WTEDY pokazały wyniki na mój starszy. Zaakceptował to, ponieważ kod jest zawsze królem.

Oczywiście, jako niedoświadczony programista, mogę się mylić, a jego sposób postępowania może być lepszy, więc moje pytanie brzmi, w jaki sposób mogę lepiej ocenić, czy porady starszego programisty są dobre, czy złe / nieaktualne.

Możesz zostać doświadczonym programistą. Dopóki tego nie zrobisz, będziesz słabo przygotowany do oceny, czy Twoja intuicja jako juniora była właściwa, a wtedy nie będzie to miało znaczenia.

W międzyczasie przeczytaj odpowiedź Joela Ethertona.

Zdecydowanie sugerowałbym, aby nie próbować „nie wdrażać go po swojemu”.

Jak dotąd brzmi to tak, jakbyś zrobił dobrze. Byłeś pokorny i wychowałeś kontrapunkt. Nie mogę powiedzieć z twojego pytania, czy po prostu nie zgadzasz się z jego metodą, czy też nie i przedstawiłeś alternatywę. Podsumowując, zawsze oferuj jasną i przemyślaną alternatywę, gdy próbujesz zestrzelić czyjeś podejście . Jak może to zobaczyć, masz dobry pomysł, który może zadziałać, a on ma pomysł, który działa.

W każdej pozycji jesteśmy zmuszeni przez cały czas robić rzeczy nieoptymalne. Jeśli naprawdę ci się nie podoba, możesz zrobić to, co zrobiłeś i wychować. Potem droga szefa lub autostrada. Z drugiej strony, jesteś młodszy w izolacji od większego ryzyka złych decyzji.

Wybierz bitwy. Jeśli mówisz o godzinie pracy, będziesz musiał czasami zmieniać kod, aż dojdziesz do siebie. Następnym razem, gdy dostaniesz duży projekt, z wyprzedzeniem zapytaj o szansę przedstawienia swoich pomysłów przed rozpoczęciem. Poświęć trochę czasu i stwórz niesamowite demo lub prototyp.

Szokująco wystarczy, że przestałem pytać. Kiedy dostaję inną opcję, po prostu dygresję i robię to po swojemu, ale dodaję do tego swój własny talent. Wykorzystaj to jako doświadczenie edukacyjne, aby rozwinąć swoje umiejętności, a jednocześnie uspokoić jego potrzebę utrzymywania starej szkoły.

W końcu nie każdy starszy programista zwraca uwagę na nowe sposoby robienia rzeczy. Czasami mają oldschoolowe sposoby, które były świetne dla języka, w którym zaczęli 20 lat temu, ale są uważane za zuchwałe lub „mają nieprzyjemny zapach” w dzisiejszym świecie.

To może brzmieć jak okropny sposób na kontynuację i tak jest. Ale wiele się nauczyłem od moich seniorów. Ale to naprawdę tylko moja opinia. W końcu musisz być szczęśliwy w pracy i utrzymywać rozproszenie i napięcie na niskim poziomie. I nie sprzeciwiając się rzeczom, zobaczysz, że stres spada.

Nie ufaj osobom starszym ze względu na staż pracy. Rzuć wyzwanie organowi tak często, jak to możliwe. Właściwy organ powinien być w stanie przekonująco odpowiedzieć na każde pytanie. To właśnie czyni go autorytetem, prawda?

Ponieważ ktoś ma przesądne przekonania przez całe życie, nie oznacza to, że ma rację. Pamiętajcie, w średniowieczu ludzie wierzyli, że ziemia jest płaska, a niektóre z tych samolubnych osłów uważały nawet za uzasadnione zabicie wątpiących. Okazało się, że wątpiący mieli rację. Tyle za złe recenzje.

Nigdy nie bój się złej recenzji. Czy zaufałbyś ślepemu, oceniając kolor?

dobre odpowiedzi powyżej dodałyby, że odpowiedź taka jak „najlepsze praktyki” lub „łatwiejsza w utrzymaniu” jest okazją do nauczenia się czegoś . Mówisz: „Czy możesz podać mi przykład, dlaczego taki sposób jest najlepszy, abym mógł zrozumieć różnicę?” lub „W jakich sytuacjach ten sposób byłby łatwiejszy w utrzymaniu niż w inny sposób, dzięki czemu mogę nauczyć się planować w ten sposób?”

Jeśli senior ma rację, podanie przykładu będzie łatwe. Jeśli jest papugą ... daj mu krakersa, aby powstrzymał skrzeczącego, i rób to, co uważasz za najlepsze. Do czasu wydania polecenia inaczej.

Jeśli rolą seniora jest mentor, wyjaśni, kiedy zostanie o to poproszony.

Jak powiedzieli wcześniej HLGEM i Jarrod, jest to naprawdę błogosławieństwo w przebraniu. Obie odpowiedzi są świetne i chcę dodać kilka punktów.

Ponieważ Twój potencjalny klient nie znajduje się w Twojej domenie, możesz podjąć niektóre ważne decyzje dotyczące swojej części aplikacji, ponieważ Twój potencjalny klient niewiele wie o oprogramowaniu pośrednim. Masz również kontakt ze swoim menedżerem na temat tego, jak powinna wyglądać aplikacja, czego chcą użytkownicy produktu i jak menedżer chciałby poradzić sobie z sytuacją przedstawioną mu przez zespół produktu. Powiedz mi, ile osób uzyska taką wiedzę na temat aplikacji.

Kiedy jesteś w dużym zespole, na pewno będziesz mieć pomoc od swoich kolegów z zespołu i / lub swojego lidera, ale nie będziesz miał wiedzy na temat tego, jak myśli twój menedżer ani zespół produktu, ponieważ takie rzeczy zazwyczaj przechodzą przez twoją szansę i mogą być kilku starszych deweloperów w zespole. Zgadzam się, że projekty jednoosobowe są dość trudne do przeprowadzenia, ale jeśli druga strona monety jest tak wspaniała, to nie przegap szansy. Dowiedz się, czego możesz się nauczyć, ciesz się, póki możesz, a jeśli będzie to zbyt trudne, przekonaj swojego kierownika, jak powiedział Jarrod, lub znajdź nową pracę / projekt w zależności od sytuacji.

Będziesz miał do czynienia z takimi ludźmi przez całą swoją karierę. I będzie wielu, z którymi nie zgodzisz się co do najlepszego podejścia do każdego problemu z kodowaniem. Myślę, że najlepszą rzeczą, która działała dla mnie przez lata, jest to, że jeśli nadal naciskają na jakiś problem, bądźcie z nimi szczęśliwi i powiedzcie im, że rozważaliście ich rozwiązanie spośród różnych możliwych rozwiązań i że czuliście, że rozwiązanie zdecydowałem się na to, co według ciebie było najlepszym podejściem w tej sytuacji.

Teraz, jeśli wybierzesz wbrew ich radom za każdym razem, od czasu do czasu może być konieczne poddanie się i skorzystanie z ich „rad” od czasu do czasu, aby wygładzić kilka potarganych piór. Dopóki nie czują, że odrzucasz ich wkład za każdym razem, będzie to miało długą drogę do utrzymania pokoju między tobą.

Weź również pod uwagę, że są starszymi programistami i pracują w tym środowisku dłużej niż ty. Kodowanie w prawdziwym życiu często nie łączy się z najlepszymi praktykami lub standardami przyjętymi przez społeczność. Może istnieć powód, dla którego zalecili zrobienie czegoś w określony sposób, który nie jest w stanie w pełni wyrazić. Tak więc, nawet jeśli się z nimi nie zgadzasz, upewnij się, że nie odrzucisz ich porady z ręki wyłącznie na podstawie tego, że uważasz, że twoje rozwiązanie jest lepsze.

Chodzi o równowagę. I nie tylko kodowanie równowagi, ale równowaga zespołu. Wiele projektów zakończyło się niepowodzeniem nie dlatego, że programiści nie byli w stanie tego zrobić, ale dlatego, że nie mogli znaleźć sposobów na polubowną współpracę.

Chciałbym przedstawić kilka rzeczy z mojego osobistego doświadczenia, które należy uznać za dodatkową odpowiedź na jedną opublikowaną tutaj przez jzd ...

1. Zapytaj innego starszego programistę,
2. Wykonuj badania we własnym zakresie.

Na jednym profesjonalnym spotkaniu miał mnie mentorować ktoś starszy. Znał pewne rzeczy, ale szczerze mówiąc nie za dużo, niestety nie wiedział o tym, więc był bardzo pewny swoich odpowiedzi. W jakiś sposób czułem, że to, co powiedział, było złe. Miałem pewne dowody, gdy rzeczy, które zrobił, były sprzeczne z najlepszymi praktykami wymienionymi w certyfikacie MS, które wziąłem :-). Potem zacząłem pytać inne osoby pracujące w innych firmach (wtedy Stackexchange już nie działał) i zacząłem czytać blogi, by porównać odpowiedzi.

Byłoby wspaniale, gdybym się mylił, bo po prostu zmieniłem swoje zachowanie, ale tak nie było.

Zauważyłem coś w ciągu ostatnich kilku lat, prawie każda firma, w której pracuję, przy prawie każdym projekcie, nad którym pracuję, przy prawie każdym nowym zatrudnieniu (niezależnie od poziomu umiejętności / doświadczenia) chce zrobić coś „innego”.

Mogą to być standardy kodowania lub ogólna architektura, język lub metodologia. Ale to zawsze coś. Wiele razy po prostu mówi oczywiste: „Czy nie powinno być lepiej udokumentowane dla naszych użytkowników końcowych?”

Moja rada dla ciebie to nie bądź tym facetem .

Pewnego dnia będziesz facetem na wysokim poziomie, który jest zatrudniony i opłacany za podejmowanie tych decyzji. Kiedy nadejdzie ten dzień, idź do niego! Do tego dnia uświadom sobie, jaka jest twoja pozycja. Mam szefa, jeśli o mnie chodzi, cała moja praca polega na tym, aby uszczęśliwić mojego szefa. Nie po to, by zgadywać decyzje podejmowane poza moją kategorią płac. Jeśli naprawdę nie jesteś pewien, porozmawiaj z szefem / przełożonym i dowiedz się.

Ogólnie rzecz biorąc, zdecydowanie lepiej jest mieć wszystkich na pokładzie z przestarzałym podejściem, niż połowa zespołu według przestarzałego podejścia, 1/4 zespołu według nowego podejścia i 1/4 zespołu próbująca opracować najnowocześniejsze , zupełnie nowe podejście.

W tych wszystkich przypadkach jest podtekst, który moim zdaniem powinien zostać wyjaśniony: nie bądź wojowniczy . Zachowaj swoje relacje z nim. Wspaniale jest posłuchać jego rady z odrobiną soli i zweryfikować ją w książkach i na takich stronach, ale nie atakuj go. Jeśli jest starszym programistą i miał wiele projektów, to nie jest idiotą i można się od niego wiele nauczyć. Wygląda na to, że już to zrobiłeś, wyrażając chęć zrozumienia jego punktu widzenia. Nawet jeśli jesteś pewien, że się myli i masz rację, zaakceptuj możliwość odwrotną (wydaje się, że już to rozumiesz). Spróbuj wyjaśnić, że kłócisz się, ponieważ chcesz lepiej zrozumieć jego punkt widzenia, a nie dlatego, że próbujesz udowodnić, że się myli.

Jeśli nie skontaktuje się z tobą od razu, gdy zadasz mu pytanie, lub jeśli jego odpowiedź jest niejasna i / lub nieprzydatna, nie zakładaj, że cię zdmuchuje. Jak już tu wspomniano, może być zajęty i / lub zestresowany.

Wspaniale jest też być cierpliwym. Zachowaj w głowie listę rzeczy, które Twoim zdaniem powinny być wykonane inaczej, i przedstaw je we właściwym czasie. Upewnij się, że masz uzasadnienie dla tej sugestii oprócz „to najlepsza praktyka”. I bądź ostrożny, aby robić wszystko dobrze i nie popełniać błędów, abyś miał wiarygodność, gdy będziesz argumentował później.

Do tej pory starałem się uniknąć tego problemu, słuchając go, podnosząc kontrapunkt, ponownie podnosi swój pierwotny punkt (przez większość czasu będzie mówił o najlepszej praktyce, łatwiejszej do utrzymania, ale po prostu nie poszedł dalej), I. .. pomyśl o tym w domu, ale ... wciąż nie jestem przekonany. Ale ostatnio ... zobaczył mój kod i zapytał, dlaczego nie zmieniłem go na jego sugestię. To trzeci raz w ciągu 2-3 tygodni.

(Nieznacznie zredagowany dla akcji.)

Ta część mnie dotyczy. Jednym ze sposobów sprawdzenia, czy masz rację, czy nie, jest zrozumienie tego, co mówi. To, co czytam (z moją własną historią, inne mogą być inne), to młodszy programista, który nie rozumie, co mówi mentor, i nie prosi o wyjaśnienia. Jednym ze sposobów, aby to rozgryźć, jest poproszenie go o wyjaśnienie: w jaki sposób jest to lepsza praktyka niż to? Lub Dlaczego jest to łatwiejsze do utrzymania niż dla naszego kodu? Jeśli nie znasz jego odpowiedzi na to pytanie, naprawdę nie wiesz, czy udziela dobrych rad, czy nie.

Tym, co naprawdę mnie martwi, jest to, że prosił cię o wielokrotną zmianę, a ty tego nie zrobiłeś. Oto jeden ze sposobów, w jaki może to wyglądać z jego strony: prosi o dokonanie zmiany, pytasz dlaczego, daje ci (ważny, jego zdaniem) powód, a ty odmawiasz dokonania zmiany. Nie pytasz o wyjaśnienia, więc zakłada, że ​​rozumiesz przyczynę, i albo jesteś zbyt leniwy, albo zbyt uparty, aby to zmienić - ani jeden dobry pomysł dla starszego programisty, aby o tobie myśleć. Zaufaj mi, o wiele lepiej zadawać pytania niż w ten sposób zyskać reputację.

Kilka myśli:

1 / Czy to działa? Czy jego sposób działa, czy nie? Czy jest jakiś obiektywny powód, dla którego jego droga byłaby gorsza?

Przez obiektywny powód rozumiem coś, co można zmierzyć bez dwuznaczności (wydajność, błędy, długość kodu ...) Jeśli jego rozwiązania działają i nie ma obiektywnych wskaźników wskazujących, że jest to złe rozwiązanie, zrób to po swojemu. Jego droga jest lepsza ... ponieważ jest prawdopodobnie bardziej spójna z resztą bazy kodu i ponieważ łatwiej będzie mu użyć / ponownie wykorzystać twoją pracę. Może ci się to nie podobać, ale nie o to chodzi, prawda?

Jeśli to nie działa lub osiąga gorsze wyniki w przypadku ważnych metryk, zaimplementuj je, porównaj jego rozwiązanie z rozwiązaniem, a następnie powiedz mu, że wypróbowałeś jego sposób, ale nie możesz uzyskać dobrej wydajności (podaj metryki) i zapytaj go jeśli popełniłeś błąd przy wdrażaniu lub jeśli istnieje wymóg, o którym nie wiedziałeś

Programiści 2 / Star mówią ... Po co to cholera? Znajdziesz sławnych programistów, którzy są ze sobą w sprzeczności w wielu podstawowych kwestiach, takich jak planowanie, projektowanie, OOP kontra procedury, testowanie jednostkowe, obsługa wyjątków, kontrola źródła, włączanie i wyłączanie.

Jeśli jedyną różnicą w wykonalności między dwoma rozwiązaniami jest to, kto preferuje, pomiń to. Możesz skorzystać z treningu umysłowego wymaganego przez pracę w paradygmacie, który ci się nie podoba

Opierając się na pomyśle, że powinieneś brać porady tylko od osób, którymi chcesz się stać, odpowiedź jest taka, że ​​rada seniora jest dobra, jeśli chcesz stać się taki jak on / ona.

Większość moich problemów uporządkowałem, zamieszczając posty na forach i otrzymując odpowiedzi od innych. Przeżyłem tak przez około 1 rok.

Co powinienem zrobić w takiej sytuacji?

Szczerze mówiąc, tak wygląda wiele prac technicznych. Musisz być samowystarczalny, który może samodzielnie rozwiązać trudne problemy (z pomocą, jeśli internet i jego mieszkańcy), jeśli musisz.

Z punktu widzenia uzyskiwania recenzji kodu i uzyskiwania pomocy w projektach architektonicznych, nawet gdy miałem dobrych menedżerów, nigdy nie miałem dużo recenzji kodu poza „zmiennymi statycznymi należy poprzedzić s_”.

Skorzystaj z okazji, aby się uczyć i uczyć się; będą to umiejętności, które możesz wykorzystać w przyszłości.

Jeśli przez chwilę myślisz, że kierownictwo nie rozumie, jak NAPRAWDĘ jesteś w stanie wykonać zadanie, to prawdopodobnie się mylisz. Kierownictwo prawdopodobnie również rozumie, że twój przywódca byłby teraz całkowicie bezużyteczny, gdyby zastąpił cię i przejął twoją pracę.

PRAWDZIWYMI powodami, dla których nie przeprowadzili się, jesteś, ponieważ pomimo wszystkich swoich wyzwań, które im stawiasz, nadal jesteś najlepszą osobą do pracy. Najwyraźniej zbyt cenią twoją pracę, aby zaryzykować przekazanie jej komukolwiek innemu.

Nie lekceważ inteligencji kierownictwa ...

Są o wiele mądrzejsi niż większość programistów im przypisuje. Nie zrozumiałem tego, dopóki nie zacząłem zarządzać. Prawdopodobnie zdają sobie również sprawę z tego, jak bardzo bezużyteczny jest twój trop, ale prawdopodobnie nie są w stanie rozwiązać tego problemu.

Pozwól, że pomaluję dla ciebie zdjęcie, ołów A z 5-letnim doświadczeniem w firmie jest niekompetentny. Menedżer wie o tym, zaleca swojemu kierownikowi, aby zwolnił Lead A. Górny menedżer pyta, dlaczego nie miał do czynienia z laty temu, jeśli jest tak niekompetentny. Menedżer wygląda teraz źle, zwłaszcza że Lead A ma rozdętą pensję, która była wypłacana bez żadnego świadczenia ...

Oto kolejny potencjalny scenariusz, Lead A jest bliskim przyjacielem z kimś ważnym. Jest zbyt gorący politycznie, aby się z nim zmierzyć,

Tak czy inaczej, przy tak długim błędzie łatwiej jest dużym organizacjom zamiatać niekompetentnych ludzi pod dywan, dać im pracowitą pracę i fałszywą moc, która jest odpowiednia do ich wieloletniego „doświadczenia”, w którym nie mogą ZBYT DUŻO szkód . Niestety wiele organizacji wolałoby to zrobić, niż rozwiązać problemy.

Oczywiście powodem tego jest to, że menedżerowi w tego rodzaju organizacji zawsze lepiej jest krótkoterminowo radzić sobie ze złymi talentami w ten sposób, niż rozwiązywać długoterminowe problemy, które tego rodzaju ludzie mogą wnieść do organizacji.

Więc choć jest krótkowzroczny i potencjalnie nieetyczny, musisz przyznać, że jest trochę mądrzejszy niż wielu programistów faktycznie na to zasługuje.

uhh ahhh. To pytanie przypomina mi wiele rzeczy. Po pierwsze powiem, że nie mogłem dogadać się z jednym z menedżerów w moim ostatnim miejscu pracy. To nie był problem osobowości. To był problem z komunikacją. Powiedziałem, że XYZ i ten konkretny menedżer przerwałby to, co mówiłem jako ABC. Nie byłbym w stanie dobrze się komunikować, chyba że pracowałbym z tym menedżerem przez ponad rok.

W ostatni weekend. Facet kłócił się ze mną o singletony. Powiedziałem, że nie są dobre i NIGDY nie powinny być używane i absolutnie nie ma powodu, aby z nich korzystać. Podłączyłem go do http://www.gmannickg.com/?p=24 i do bardziej szczegółowego artykułu, do którego prowadzikilka dni po kłótni. Dzień innego programisty (DudeB) wspomina, że ​​używa singletonów tylko wtedy, gdy jest to właściwe (do którego dodałem „nigdy”). DudeB nie powiedział o tym nic, ale DudeB powiedział, że DudeB był w projekcie, który miał problem z pamięcią, ponieważ wszystkie wątki miały dostęp do singletonu. Po tym, jak o tym wspomniałem, pokazując artykuł i wspominając spór o pamięć, facet, z którym się sprzeczałem, powiedział, że będziemy musieli się zgodzić, z czym się zgodziłem, ponieważ nie lubię mówić o singletonach (ale piszę o tym)

Chodzi o to. Czasami możesz się mylić tak jak ten facet (może ktoś nie zgodzi się ze mną w sprawie singletonów w komentarzu). W mojej sytuacji z moim menadżerem, który był moim starszym programistą, po prostu zrobiłem to, o co mnie wyraźnie poproszono i nigdy więcej nie potraktowałem jakości w tym miejscu pracy. Zrobiłem to, co wolę robić, gdy jest to dozwolone, ale zawsze robiłem to, o co mnie poproszono, ale jeśli się nie zgadzam, przywołam to przynajmniej raz.

Mam w tej sprawie zupełnie inne / kontrowersyjne zdanie.

Często ludzie tracą świadomość celu końcowego, który dla większości branż polega na maksymalizacji zysków i minimalizacji strat. Wiem, że to brzmi bez serca (stąd negatywne punkty), ale doświadczenie i mądrość mają niewielkie znaczenie, jeśli nie zamierzacie przynosić rezultatów.

Ludzie mogą zostać przyłapani na bardzo drobiazgowych drobiazgach, z którymi można się spierać, które mają bardzo niewielki wpływ na bezpośrednie wyniki firmy.

Jeśli uważasz, że masz rację co do czegoś, najlepszym rozwiązaniem jest pokazanie, w jaki sposób zapewni to wymierne rezultaty .

Na początku postaram się to utrzymać, pod koniec dnia opór wobec seniorów prawdopodobnie będzie daremny, przynajmniej dopóki nie zdobędziesz więcej doświadczenia i szacunku. Wykorzystaj to jako doświadczenie edukacyjne i za ponad 2 lata, jeśli nadal czujesz to samo - przejdź do innej firmy. Wtedy możesz zastosować kombinację dobrych i starszych pomysłów, aby zaimponować nowemu pracodawcy. Oczywiście możesz zacząć zdawać sobie sprawę z niektórych przyczyn, które wcześniej postrzegałeś jako złe decyzje, a w pewnym momencie możesz pracować dla Ciebie jako młodszy programista.

[Repost: ponieważ jakoś utworzyłem tutaj drugie konto]

Ale ostatnio znów się do mnie zbliżył, zobaczył mój kod i zapytał, dlaczego nie zmieniłem go na jego sugestię .

Powinieneś jasno określić, czy są to sugestie, zamówienia, instrukcje / dyrektywy / cokolwiek innego.

Sugestia = Myślę, że lepiej to zrobić w ten sposób; ale to twój wybór.

Zamów / etc. = Chcę to zrobić w ten sposób; i to jest mój wybór.

Jeśli jest to naprawdę sugestia, rób, co chcesz i pozwól, aby Twój kod się utrzymał. Jeśli jest to rozkaz (a ten mentor ma nad tobą władzę w ten sposób) - rób, co mówią.