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


266

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?


26
Uczysz się więcej na błędach niż na sukcesach.
StuperUser

45
Czy możesz podać przykład jednego z problemów, z którymi się nie zgadzacie? Wiem, że jest to raczej pytanie teoretyczne i prawdopodobnie chcesz uniknąć technicznych debat, ale byłoby interesujące usłyszeć, co kończy się brak porozumienia.
Adam Rackis

140
Widzę jedną czerwoną flagę w tym poście. Musiałeś zostać poproszony o zrobienie czegoś trzy razy. Raz powinno wystarczyć. Jeśli nie chcesz czegoś robić, musisz przekonać swojego mentora, że ​​nie jest to konieczne. Jeśli nie możesz tego zrobić, przytrzymaj nos i zrób to, albo znajdź nową pracę.
PeterAllenWebb

6
@peterallenweb, rzeczywiście źle jest pytać 3 razy, niezależnie od jakości porady. Sądzę, że z komentarzy tutaj muszę się wiele nauczyć, jeśli chodzi o pracę w różnych zespołach. :)
learnjourney

33
Oprócz tego, co powiedział Peter: zastanów się nad jego punktem widzenia: prosisz nowego faceta, aby coś zrobił, przeprowadził dyskusję techniczną, nie otrzymywał dalszego sprzeciwu, a następnie - tydzień później okazało się, że po prostu zignorował twoją prośbę. I to nie pierwszy raz, kiedy to się stało. (Nie przejmuj się zbytnio - na pewno nie jesteś pierwszą osobą po studiach, która wpadła w tę pułapkę. Dopóki zdajesz sobie sprawę z tych problemów i pracujesz nad nimi, nic ci nie będzie.)
Martin

Odpowiedzi:


233

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.


47
@Joel Dobra odpowiedź, ale uważaj na obawy związane z „odrzuceniem”. Obawy powinny być zawsze uznawane, nawet jeśli są nieważne, nawet jeśli najlepszą odpowiedzią, jaką masz, jest: „Rozumiem twoje obawy, ale teraz musimy zrobić X z powodu Y”. Sprawne odrzucenie poważnych pomysłów jest zabójcą morale i ostatecznie może zniszczyć nawet najbardziej zdrowe kultury.
Rein Henrichs

42
@Joel: Wiele dobrych punktów, ale to trochę protekcjonalne: „To tyle, ile bycie nastolatkiem pod względem oprogramowania”. Szacunek, jaki senior zarabia od młodszych programistów, zdobywa się poprzez konsekwentne podejmowanie dobrych decyzji - a nie sam fakt wieku czy stażu pracy.
Neil G,

26
Nie jest tak blisko odpowiedzi na pytanie, skąd wiesz, czy starszy programista jest „dobry”, czy nie. Odpowiedź, jak stwierdzono tutaj, wydaje się brzmieć „nie ma znaczenia, po prostu rób to, co mówi”. Nie twierdzę, że to zła rada; Mówię tylko, że to nie odpowiada na pytanie. Jeśli chodzi o to, co jest warte, myślę, że jedyną właściwą odpowiedzią jest to, że będziesz wiedział, czy on jest dobry za 5 lat, kiedy jesteś seniorem.
Kevin

2
@Kevin: Nie mogę się kłócić z tym komentarzem iz pewnością nie mogę polecić młodszemu programistowi żadnej metody ustalenia sposobu odpowiedzi na to pytanie. Często seniorzy nie potrafią odpowiedzieć sobie nawzajem dokładnie. Moja odpowiedź była szczerze nastawiona na inne aspekty pytania PO, które uderzyły mnie bardziej niż to, jak rozpoznać kiepskiego starszego programistę.
Joel Etherton

11
Wygląda na to, że w odpowiedzi brakuje pokory, o której mówisz. Młodzi ludzie często myślą, że wiedzą wszystko, ale czy starsi ludzie nie podzielają tego samego wady? Jest to przesadzone w naszej branży - duża część naszej wiedzy będzie mniej istotna za kilka lat. (przykład z życia - mam mentora w średnim projekcie, który powiedział, że powinniśmy „zrobić kilka przycisków i napisać w nich SQL, aby zaoszczędzić czas”. Był pod dużym wrażeniem, gdy pokazałem mu LINQ Entity i asp.net strona bez kodu )
Kobi

35

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.


29
OP - oboje jesteście profesjonalistami, nawet jeśli macie mniej doświadczenia, więc porozmawiaj z nim o sprawach, które kwestionujesz. Jeśli nie chce rozmawiać o przyczynach swoich instrukcji, nie jest wielkim mentorem.
DaveE

10
+1 za „On bardziej liczy na sukces projektu niż ty”. Jak prawdziwe to jest. Wiem, że wy, młodsi programiści, nie doceniacie tego, jak bardzo macie szczęście, że nie macie na was takiego stresu, ponieważ na pewno nie zrobiłem tego, kiedy byłem młodszym programistą. A teraz zejdź z mojego trawnika!
wałek klonowy

1
Sugeruję również, aby / jeśli zastosujesz się do jego sugestii, zachowaj dokument swoich obaw związanych ze zmianą - jeśli później się zepsuje, możesz być w stanie wskazać na to, aby pokazać, że przewidziałeś błąd.
Daenyth

4
@DaveE: Wygląda na to, że już rozmawiali, a OP po prostu nie miał wystarczającego kontekstu, aby obecnie zrozumieć mądrość seniora. Czasami jest tylko tyle rzeczy, które możesz wyjaśnić, reszta będzie musiała pochodzić z doświadczenia.
Martin York

2
@Niphra: Możliwe. Ale bez dokładniejszych informacji jestem bardziej skłonny uwierzyć, że to tylko naiwny uczeń, który wie mniej, niż myśli. Większość seniorów tak naprawdę wie, co robią (jeśli nie jesteś głupcem, to zamiast tego stajesz się zarządem).
Martin York

24

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ą.


4
+1 za rozmowę. Starszy programista może być lepiej (i odpowiedzialny) w celu zrównoważenia różnych problemów, ale powinien być w stanie wyjaśnić swoje powody. Wyjaśnianie się młodym, aby mogli się uczyć, to duża część bycia seniorem. A jeśli jako junior nie masz ochoty się uczyć, może czas zmienić pracę.
Jaap

+1 za najlepiej zrobione jeden na jednego. Czas na spór jest za zamkniętymi drzwiami. Kiedy drzwi się otworzą i dyskusja dobiegnie końca, nie powinno być sprzeczek, podważania, ani marudzenia. Nie otwieraj drzwi, dopóki nie dojdziesz do tego punktu. Jeśli nadal się nie zgadzasz, powiedz seniorowi, że zamierzasz podnieść to do jego przełożonego.
Michael Riley - AKA Gunny

18

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.


Muszę przyznać, że jestem zszokowany faktem, że mam siedem głosów pozytywnych (jak na razie) i żadnych głosów negatywnych. Myślałbym, że moje nastawienie / pesymistyczny pogląd / ranny ton nie pasowałby do ludzi :)
Wayne Molina

Na Slashdot ogłaszanie, że spodziewałeś się, że zostaniesz zredukowany, było sprawdzoną techniką w dziwkach karmy.
Carson63000,

Będę musiał tego częściej próbować j / k :)
Wayne Molina

11

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.


11

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.


9
Ślepe powiedzenie „potrzebujemy najlepszych praktyk branżowych” może nie być najlepszym sposobem na rozpoczęcie dyskusji. Może istnieć bardzo dobry powód, aby zrobić coś innego niż większość innych.

7
Myślę, że jest to najbliższa jak dotąd odpowiedź. Starszy programista powinien być w stanie przedstawić przekonujące powody, dla których proponowane przez nich metody są uzasadnione. Nie będziesz w stanie poprawić się pod mentorem kogoś, kto nie może. Teraz, jeśli znajdziesz się w swojej trzeciej firmie, a wszyscy starsi deweloperzy w ogóle byli idiotami, być może nadszedł czas, aby spojrzeć mocniej w lustro.
PeterAllenWebb

2
@PeterAllenWebb, „powinno być w stanie”, tak, ale niekoniecznie chcesz dyskutować godzinę po godzinie szczegółowo określając, dlaczego dana praktyka jest dla ciebie zła. Czasami na „dlaczego?” Można odpowiedzieć za pomocą „Ponieważ!”

@ Thorbjørn Ravn Andersen: Zgadzam się, o ile jest to sporadyczne.
PeterAllenWebb

11

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.


Doceniam twoje myślenie, ale obawiam się przyszłości i spekulacji, ponieważ mogą być trudniejsze sytuacje, w których publikowanie na forach może nie pomóc. Więc co powinienem zrobić?
developer123

4
Zagłęb się w książki i ucz się dogłębnie. Internet to nie jedyny sposób na naukę. Dołącz do lokalnej grupy programistów i nawiąż kontakty z osobami starszymi, które możesz dostać do mentora.
HLGEM

to jest dobre.
developer123

9

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ś.


6
Jako młodszy programista ten rodzaj dyktatury doprowadziłby mnie do szaleństwa. Przepraszam, obniżyłem głos.
kizzx2

9

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.

Wielkie dzięki, twoje punkty są naprawdę miłe i przemyślane. Głosuj za ciebie.
programista123

Dzięki, wybrałem twoją odpowiedź, ponieważ łączy ona najlepsze.
programista123,

7

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.


11
@maple_shaft: jakim jesteś zespołem, jeśli kod (i wszyscy go utrzymujący) muszą cierpieć, aby chronić uczucia starszych programistów?
Jaap

1
@Jaap, Przede wszystkim mówię o liderze technologicznym lub projektowym, niekoniecznie musi to być starszy programista. Po drugie, nie chodzi o ich uczucia, chodzi o dążenie do wspólnego celu jako grupy. Dowódca powinien mieć pozory kontroli nad swoją grupą, niezależnie od tego, czy się myli. Główny jest ten, kto bierze odpowiedzialność za wypaczony kod, niekompletne funkcje i niedotrzymanie terminów, więc jeśli jest głupcem, będzie cierpieć. Jeśli firma nie uzna, że ​​jest głupcem, ucierpi.
wałek klonowy

2
Jeśli powiedziano mu już o zmianie, oznacza to, że przegląd kodu nie powiódł się. Próba ponownego przesłania oznacza, że ​​dowie się, że to się już nie udało.
Martin York

2
@darknight, zakładając, że nie jest to drobny problem, zmiana paradygmatów w istniejącej bazie kodów może mieć poważne konsekwencje. Gdy przychodzi mi na myśl tego rodzaju debaty, przychodzi mi na myśl struktura bazy danych. Takie zmiany z pewnością nie zostaną docenione.
Morgan Herlocker

1
Dotyczy to tylko bardzo małych jednostek pracy. Załóżmy, że pracowałeś przez dwa tygodnie, a kod został odrzucony - w jaki sposób otrzymasz fundusze na te dwa tygodnie?

7

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.


7

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.


6

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.


4

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.


3

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?


5
Większość menedżerów nie będzie miała zbytniej cierpliwości dla młodszego twórcy, który rzuca wyzwanie wszystkim. Jeśli tak, idź poświęcić kurczaka na cześć Cthulhu, bo znalazłeś świetnego szefa! W przeciwnym razie przygotuj się na częste zakupy, aż znajdziesz jeden.

2

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.


2

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.


Dzięki tobie, HLGEM i Jarrod za wskazanie pozytywnych stron.
developer123

1

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ę.


1

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.


5
Prawie nigdy nie ma uzasadnionego powodu ignorowania najlepszych praktyk branżowych, z wyjątkiem ignorancji i / lub niechęci do robienia tego dobrze. Z jakiegoś powodu są to „najlepsze” praktyki, a ludzie, którzy je wymyślili, są dziesięć razy mądrzejsi i jeszcze bardziej starsi niż starszy programista, który je ignoruje lub nie zdaje sobie z tego sprawy.
Wayne Molina

@Wayne M: Dobrze powiedziane.
Jim G.

6
@Wayne, nadal musisz zrozumieć, dlaczego są to najlepsze praktyki. Jeśli na ślepo powiesz „to najlepsza praktyka, musimy to zrobić!” nie wiedząc dlaczego, sam nie jesteś lepszy.

Powiedziałbym, że Wayne zostawił wystarczająco dużo miejsca w odpowiedzi na obalenie Andersena.
C Johnson

@ Thorbjørn Ravn Andersen, @learnjourney - Ze wszystkich komentarzy i odpowiedzi komentarz Thorbjørna jest prawdopodobnie najważniejszą i najistotniejszą radą. Musisz zrozumieć problemy, którym dana najlepsza praktyka próbowała zapobiec lub rozwiązać, w przeciwnym razie nigdy nie dowiesz się, czy problemy te nadal występują. Krótko mówiąc, musisz zrozumieć, dlaczego jest to najlepsza praktyka. W ten sposób sugerujesz alternatywy: wyjaśniając problemy, które rozwiązały najlepsze praktyki. Jak powiedział Merowing z Matrycy: „Bez„ Dlaczego ”nie masz nic.
Thomas

1

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.


17
-1: Mam szefa, jeśli chodzi o mnie, cała moja praca polega na tym, aby uszczęśliwić mojego szefa. Nie po to, by zgadywać decyzje podejmowane poza moją kategorią płac. : Nigdy nie będziesz dla mnie pracował. Nie zatrudniam „Yes Men”. Chcę, aby moje bezpośrednie sprawozdania oferowały konstruktywną krytykę, gdy zamierzam podjąć nieoptymalną decyzję. Gdybym nie cenił ich opinii, nie zatrudniłbym ich w pierwszej kolejności.
Jim G.

7
Nie zgadzam się z tym sentymentem. Po pierwsze, jeśli chcesz awansować, powinieneś pokazać, że jesteś zdolny i chętny do podjęcia obowiązków związanych z wyższym stanowiskiem, więc pod tym względem trzymanie głowy w dół nie jest dobre dla twojej długoterminowej kariery. Po drugie, nie wierzę w podejście do pracy „powyżej mojej płacy”. Wszyscy są gotowi odnieść sukces w firmie (jeśli tak nie jest, nie masz już pracy), więc jeśli widzisz lepszy sposób na zrobienie czegokolwiek, powyżej swojej kategorii płac, czy nie, powinieneś to zaznaczyć. Czasami nowy zatrudnienie może dać dobre sugestie, ponieważ mają świeżą perspektywę.
Cercerilla

6
Muszę się zgodzić z @Jim G. Postawa bycia „Smithersem” jest najgorszą rzeczą, jaką możesz zrobić; myślenie, że Twój menedżer ma zawsze rację, jest okropną rzeczą, ponieważ często nie mają racji. Zgadzam się również z @CodeninjaTim - nowy pracownik często ma lepsze sugestie, ponieważ nie mają takiego samego poglądu, jak długoterminowi faceci, więc rzadziej przestrzegają „status quo”
Wayne Molina

4
@Jim G: Wygląda na to, że OP już wyraził obawę „To już trzeci raz w ciągu 2-3 tygodni”. - Nie wyobrażam sobie, że chciałbyś zatrudnić kogoś, kto po wyrażeniu opinii i wyjaśnieniu, że A jest lepszy niż B (nawet jeśli się nie zgadza), nie chce dokonać zmiany. W tym momencie tak naprawdę nie „pracuje dla ciebie”.
Rob P.

3
@Wayne M - Nie opowiadam się za naszym zdaniem, że nasi menedżerowie mają zawsze rację. Zasugerowałem we właściwy sposób wyrazić jego obawy. Ale po otrzymaniu polecenia wykonania 3 razy w ciągu kilku tygodni OP nie radzi sobie z tym poprawnie. Z całą pewnością wyrażaj swoje obawy, ale uświadom sobie, że jesteś ZATRUDNIONY (chyba że nie jesteś - zignoruj ​​to). Zgodziłeś się pracować dla kogoś innego w zamian za pewien poziom odszkodowania. Fakt, że masz szefa, implikuje oczekiwanie, że zrobisz to, co ci każą, w granicach rozsądku. Dobrze, czy źle, na to właśnie zapisałeś się jako pracownik
Rob P.

1

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.


1

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ę.


Poprosiłem o wyjaśnienia, ale odpowiedź, którą zawsze otrzymywałem, brzmi: „to lepsza praktyka” lub coś w tym stylu, zanim wróci, by robić swoje. Moim zdaniem jedną rzeczą jest powiedzieć, że to dobra lub lepsza praktyka, ale chciałem wiedzieć, „dlaczego” jest lepsze, czego nie był w stanie mi wyjaśnić, ale nalegać, jest lepsze, a ponieważ jest starszy , Powinienem mu zaufać. Mimo to źle, że się nie zmieniłem, mimo że zostałem o to zapytany 3 razy.
learnjourney

@learnjourney: Zgadzam się, że istnieje problem, jeśli pytasz dlaczego, a nie otrzymujesz odpowiedzi. Nadal zalecałbym, abyś był świadomy tego, jak może to wyglądać z drugiej strony, ale jeśli ten starszy programista nie może ci pomóc, znajdź inną i postaw problem przed nimi, używając tylko podstawowego „powiedział <powód>, czy możesz wyjaśnić, jak to się tutaj stosuje? ”i bez dyskryminacji. Jeśli to nie zadziała, poszukaj innych odpowiedzi, które mówią o wprowadzeniu zmiany, ale miej pod ręką swoją wersję i powody. Pamiętaj, aby uczyć się od niego w jakikolwiek sposób.
Caleb Huitt - cjhuitt

1

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


1

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.


1

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.


Tak, to jedyna optymistyczna rzecz, jaką widzę w mojej sytuacji.
developer123

1

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.


Dziękuję za odpowiedź i wprowadzenie zarządzania myśleniem i ich punktami widzenia. Głosuj za ciebie.
programista123,

0

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.


1
Re: „Może ktoś nie zgodzi się ze mną w sprawie singletonów w komentarzu” - Nie zgadzam się z tobą; o) Ale
zgódźmy

0

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 .


-1: takie śmieszne. // Sedno twojej „kontrowersyjnej” opinii opiera się na fakcie, że OP znajduje się w drobiazgach lub trywialności. Nie wiesz tego! Weź to pytanie za wartość nominalną.
Jim G.

Programowanie jest najbardziej minut Jim G. A z doświadczenia (jestem starszy programista) istnieje wiele innych BS zaangażowany jest w porządku . Prawie zawsze jest większy obraz. A ludzie wyżej reagują na większy obraz (patrz jego aktualizacja), a nie na „ale mój projekt jest bardziej oddzielony”. Ponieważ PO nie podał przykładu, musiałem skorzystać z niektórych swobód.
Adam Gent

0

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.


5
-1: Po co tracić ponad 2 lata pracując dla starszego n00b?
Jim G.

@Jim - przenoszenie pracy po 6 miesiącach nie wygląda dobrze na twoim CV. Jeśli przeprowadzisz się gdzieś indziej, a senior będzie jeszcze gorzej, wpływ na twoje CV jest wykładniczo zły! Możesz także nauczyć się zdawać sobie sprawę, że nie wszystko, co powiedzieli, było niepoprawne lub przynajmniej był powód, aby zrobić to w ten sposób.
Matt Wilko

1
@ Jim - Chociaż zgadzam się w praktyce, Matt ma rację; ludzie są głupi i ciągłe podskakiwanie do pracy, próba znalezienia odpowiedniego środowiska, może cię zranić (mogę mówić na podstawie tego doświadczenia). Zależy to dokładnie od tego, jaka jest rada, czy nie jest ona po prostu optymalna (np. Nie możemy zrobić TDD lub użyć kontenera IoC), czy jest całkowicie błędna (np. Nie wiem, co to jest interfejs lub dlaczego miałbyś go używać w programowanie). Pierwszy z nich jest w porządku, aby „wystawić to”, drugi to ucieczka krzycząca, ponieważ senior jest idiotą (mam nadzieję, że dobrze zrozumiałem te warunki… zawsze mnie mylą)
Wayne Molina

0

[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ą.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.