Senior przez zasiedzenie

Mam około 3 lata doświadczenia, obecnie jestem zatrudniony jako mid, regular czy po prostu software developer bez prefixu. Zdaje sobie sprawę, że dużo nauki jeszcze przede mną, wiele rzeczy jeszcze nie rozumiem, ale poziom niekompetencji niektórch seniorów z którymi przyszło mi pracować to jest absurd.

Kilka przykładów?

• po czym poznasz kod seniora? Cały feature w 1 klasie, bez znaczenia że jest to na tyle duży feature że klasa ma +1k linii.
• robisz metody private? Zrób public, bo inaczej musisz testować przez refleksje (i zaczyna tłumaczyć co to jest refleksja)
• jutro demo, zakazuje mergować nowych featerów do mastera. Po czym merguje swojego feature bez approve (niestety nie mamy walidacji na to), testy przechodza bo w 95% składają się z konfiguracji mocków, idzie deployment na deva, nie możemy kontynuować testów bo aplikacja nie dziala. Senior jest afk bo "zrobił swoje", reszta teamu szuka błędu i w końcu revertuje ostatnie zmiany.
• generuje sobie klienta, model i integruje frontend z backendem przez niego napisanym i lecą same 500tki bo backend rzuca nullpointery, po godzinie dyskusji że to moja wina, słyszę "No ok faktycznie to backend się wyjebał, ale to dlatego ze Ty nie zrozumiałeś jak ja chcę żeby on działał". Szkoda tylko, że wygenerowałem wszystko ze swaggera którego od niego dostałem.
• bluzga na wszystkich którzy korzystają ze Streamów (jdk8), bo "stary for loop lepszy bo się go da debugować"

No i perełka

• wyślij mi ten kod mailem, bo coś nie moge tego odpalic. Na callu się okazało, że po prostu miał pełno merge conflictów

Czy to normalne? Przez te 3 lata i w sumie 3 rózne teamy w jakich pracowałem spotkałem już 5 takich osob... Jak macie podobne sytuacje to z chęcią poczytam

Zmień pracę.
Takie incydenty/osoby się zdarzają, ale nie jest to norma. Jeżeli w jednej firmie masz x takich osób, to znaczy, że ta firma dawno została w tyle.

Zwolnij go.

Tak niestety tacy ludzie się zdarzają, "senior za wysługę lat" :)

Emdzej93 napisał(a):

Mam około 3 lata doświadczenia, obecnie jestem zatrudniony jako mid, regular czy po prostu software developer bez suffixu. Zdaje sobie sprawę, że dużo nauki jeszcze przede mną, wiele rzeczy jeszcze nie rozumiem, ale poziom niekompetencji niektórch seniorów z którymi przyszło mi pracować to jest absurd.

Ogólnie, wiara, medytacja i mistycyzm bardzo pomagają na pewnym etapie w tej branży. Każdy kiedyś dojdzie do etapu gdzie jego kariera może potoczyć się dwojako:

• wypali się
• dokona skoku wiary a wtedy otworzy się przed nim ocean nieskończonych i nieograniczonych niczym możliwości

Z twojego wpisu wynika że widzisz światełko w tunelu ale zamiast ruszyć naprzód narzekasz jak to było fajnie dopóki do niego wszedłeś. Odwagi - trzeba iść naprzód i przyjąć los na klatę!

Emdzej93 napisał(a):

Czy to normalne? Przez te 3 lata i w sumie 3 rózne teamy w jakich pracowałem spotkałem już 5 takich osob... Jak macie podobne sytuacje to z chęcią poczytam

Owszem, chociażby w software housach to normalne. Wszystkie metody static, klasy po 8 tys linii, ale stopka w Outlooku się zgadza.
Nic nie poradzisz, zmieniaj projekty i pracodawców z nadzieją, że kiedyś trafisz na lepsze środowisko.

Masz dwa wyjścia:

• Albo grasz w gre, zbierasz haki na seniora i próbujesz się go pozbyć
• Albo szukasz nowej pracy gdzie będzie takich kwiatków mniej
• Możesz też zostać i dalej narzekać, ale istnieje niebezpieczeństwo że za 6 lat sam będziesz takim seniorem

Za nadmiar wyjść przepraszam

Możesz pójść na wojnę.

Pozbieraj co ciekawsze przypadki problemów które wynikły ze sposobu w jaki pracuje nielubiany przez ciebie "senior", fragmenty kodu które każdy normalny człowiek uzna za urągające godności człowieka (autorstwa wiadomo kogo) i zaproś pół firmy na spotkanie i prezentację dot. optymalizacji pracy z kodem dbając o to, żeby ten człowiek się tam znalazł.
Przy każdej rozmowie z tym seniorem jeśli ten tylko coś ci zarzuci to nie bój się spytać 4 innych osób z zespołu o zdanie. Zrób spotkanie i prezentację w ramach walki o dobro wspólne czyli jakość kodu.
Jeśli senior zarzuci cię swoimi pomysłami oraz nakazami których nie jesteś w stanie od razu dźwignąć - przemyśl sobie to co ci zaproponował i jeśli widzisz tam problemy których nie ma twoje początkowe rozwiązanie wróć do niego i zasyp go argumentami.
Pogadaj z managementem na temat problemów mogących wyniknąć z takiego postępowania.
Rób seniorowi konkretne review, zrób tak żeby kod musiał zostać zaakceptowany przez co najmniej 2 osoby z zespołu przed mergem

Miałem w pracy taką sytuację, ale ja akurat jestem osobą która nie boi się odezwać i doszło do tego że część osób obraziła się na drugą. Generalnie wyszło jednak na plus.

W razie czego zawsze możesz się zwolnić lub zostać jak napisał @KamilAdam. Tylko pamiętaj że jeśli nic nie zrobisz to nie dość że nic się nie zmieni to jeszcze ty prawdopodobnie nabierzesz złych nawyków i staniesz się trochę podobny

Jest jeszcze jedno wyjście. Składasz wypowiedzenie, jak będziesz miał rozmowę to mówisz, że to jego wina itp. I teraz się okaże kogo zwolnią ciebie czy niego.

@UglyMan: to tak nie działa. Zmiany tego typu to raczej długi proces a nie decyzji podejmowanych nagle pod wpływem jakichś emocji

Swego czasu zacząłem pracować w firmie, która niedawno zatrudniła software managera.

Wcześniej za "managera" robił "senior" developer z USA, który pracował na miejscu w biurze.
Jego kolegą był inny "senior" z zagranicy.

No i zanim tego biednego managera zatrudnili, to mieli sielankę, bo siedzieli i babrali się w błotku, w którym piszą od początku kariery.
No i tak

• git to g**no - tylko tfs - robią co 5 minut check iny i prują się jak są jakieś konflikty
• użyjesz jakiejś funkcjonalności języka, której nie znają? Czyli wszystkie po .NET 2.0 :D - po co tego używasz, niepotrzebnie, blablabla
• code review nie będą robić, bo oni nie będą czytać czyjegoś kodu
  -web formsy are awesome - rest sucks
  -ale oczywiście nie znaju cyklu życia aplikacji i każde odświeżenie strony jawnie/przez update panel, to ciągłe walenie do bazy/autentykacja/autoryzacja itd
  -no dobra - oczywiście logika w ui w event handlerach
  -zawsze, gdy się pomylili gdzieś w kodzie, to atak złości, to wina wszystkich, tylko nie ich, tych co pisali kod
  -tabele bez relacji
  -każdy nowy większy feature, to nowa baza, również bez kluczy. Wszędzie łączenie rekordów z użyciem cross apply/outer apply i ba - i to po łączeniu stringów (łączenie po adresach w stylu ulica/miasto/kod pocztowy xD)
• z nowym kolegą robiliśmy nowy projekt, to manago kazał napisać front react + .net core API.
• mało się nie popłakali, jak się zwolniliśmy, bo oni nie będą pisać w czyimś projekcie, nie powiem cholerną satysfakcję mi to sprawiło, po tym gównonurkowaniu w ich kodzie
• po roku od zwolnienia się, widzę że przepisali serwis na swoje ukochane webformsy, strona się rozjeżdża jest nieresponsywna i powycinali połowę funkcjonalności + komunikaty błędów po angielsku wklejane jako label z web formsów w jakieś randomowe miejsce na stronie :D

To na pewno senior? Bo z opisu to raczej architekt.

nowyworek napisał(a):

To na pewno senior? Bo z opisu to raczej architekt.

Też spotkałem takiego seniora. Firma była zwyczajnie za małą żeby mieć architekta.

Nie mylmy seniora z señorem ;)

Senior to jest pozycja w hierarchii, a nie umiejętności.
Trochę jak politycy - ktoś może być wysoko w hierarchii np. rządzić całym krajem albo jego częścią, ale to nie oznacza, że będzie miał stosowne umiejętności. Może rządzić nieudolnie.

Jednak ktoś ich wybrał (zarówno polityków jak i takich nieudolnych seniorów). Więc patologia leży gdzie indziej. Koleś może być słaby, ale to jego przełożeni odpowiadają za to, że on tam jeszcze pracuje i jest "seniorem". Za każdym słabym seniorem stoi Janusz, który go zatrudnia i utwierdza go w jego własnej zajebistości. Z drugiej strony nawet Janusze mają czasem rację - może taki gość, który się zasiedział, zna dobrze projekt, ma wiedzę dziedzinową, może wdrażać innych, może szybko zaklepać jakieś spaghetti, z jakichś powodów Janusze ich tam trzymają.

Przestałem programować w javie i nie mam już takich problemów

cóż, sam byłem w takich projektach

senior dlatego, że przegrzebał już każdy system w firmie 5 razy i wie co gdzie jest; natomiast jego podejscie, kod i wszystko inne to poziom juniorski.
tacy ludzie dostaja seniora często tylko i wyłączenie przez wiedzę domenową i znajomość kontekstu (co gdzie znaleźć). jakby nie dostali to by sie zwolnili, albo obrazili, kto to wie

tj pisał @somekind, zmieniaj, szukaj, w końcu trafisz na fajny zespół; ze świecą tego szukać, niestety :P

EDIT
a najwieksza beka jest, jak idziesz na rozmowe majac 2-3-4 lata doswiadczenia, wiedzac ze ogarniasz i nie mozesz wynegocjować swojej stawki bo jedynym warunkiem jest "my patrzymy na doswiadczenie. a pan nie ma wystarczajaco na taka stawke. u nas ludzie z 15 latami doswiadczenia dostaja mniej niz pan chce" ehhhhh kończe ten post bo słabo mi sie robi

U nas w firmie jest conajmniej dziesięciu "seniorów" którzy myślą że nie można użyć gita bez IDE, że dodanie 101szsgo ifa do drabinki 100 ifów jest okej, że sleep 100ms jest spoko alternatywą dla zapięcia observera, że 100% coverage to znaczy że klasa jest przetestowana.

Są też tacy seniorzy, którzy robią wsyztskie pola i metody publiczne, "na wszelki wypadek", albo zostawiają w vcs kilka klas które nie są używane.

TomRiddle napisał(a):

Są też tacy seniorzy, którzy robią wsyztskie pola i metody publiczne, "na wszelki wypadek"

No, a teraz szczerze, wysypało się z tego powodu? :)

Przypomnę dawne czasy
Ludzie pisali w JavaScript front, back
Ludzie nie mieli private i żyli (nie mieli TypeScript)
Wiecie co robili? Klikali i testowali

Flame, to wklejam full (ale się nie zaciągam!) :)

z drugiej ciężko jest takich señorów zmotywować do innego stylu, mają wszystko co chcieli, oszczędności, zarabiają sporo, zwolnić ich nie zwolnią, bo znają projekt, więc robią minimum i czas na couter strike :)

A ja stanę w obronie seniorów... po pierwsze juniorzy często mają tendencję do nie uzasadnionego komplikowania prostych rzeczy, nauczy się czegoś nowego i od razu chce to w kodzie przetestować oraz fajnie wygląda to w pull requescie jak narzuca 100 warstw i serwisów i potem praca z takim kodem to godziny zmarnowanego czasu, po drugie jeżeli pracował ktoś lata z systemem to zna go na tyle że nie musi za każdym razem tworzyć pull requesta

daniel1987 napisał(a):

A ja stanę w obronie seniorów... po pierwsze juniorzy często mają tendencję do nie uzasadnionego komplikowania prostych rzeczy, nauczy się czegoś nowego i od razu chce to w kodzie przetestować oraz fajnie wygląda to w pull requescie jak narzuca 100 warstw i serwisów i potem praca z takim kodem to godziny zmarnowanego czasu, po drugie jeżeli pracował ktoś lata z systemem to zna go na tyle że nie musi za każdym razem tworzyć pull requesta

To też. Tym niemniej osoby z dużą wiedzą i z długim stażem w programowaniu też często lubią komplikować proste rzeczy, a KISS i YAGNI są im obce. I nie mogą napisać prostego kodu, który robi rzecz X, ale muszą od razu zrobić kod, który będzie odporny na 100 różnych edge case'ów i który będzie super konfigurowalny i hiper testowalny i będzie robił rzecz X totalnie naokoło, byleby spełnić kryteria bycia profesjonalnym i wrzucić ulubione wzorce.

Przeinżynierowany kod juniora czy seniora taki sam ma efekt - "praca z takim kodem to godziny zmarnowanego czasu, " ;)

Tylko, że junior jeszcze może się nauczyć (myślę, że overengineering to naturalny etap rozwoju), a senior, który pisze przeinżynierowany kod, to może być oznaka zasiedzenia się i braku pomyślunku. Ludzie, którzy mają dużą wiedzę i doświadczenie, ale niewiele refleksji i chęci rozwoju. Po prostu osiedli w tych przeinżynierowanych kodach i już tego nie dostrzegają. A nowa osoba w zespole musi się męczyć, żeby rozwikłać tony abstrakcji i zależności między modułami, które naprodukowali.

Tyle, że wszystko ma swoje granice.
Po co korzystać np z RabbitMq skoro mozna dodać tabelkę do bazy, podpiąć do niej każdą aplikację i zrobić sobie komunikację w ten sposób.
Po co dzielić klasy na odpowiedzialności i ułatwiać zrozumienie tego co się dzieje w kodzie oraz testowanie kiedy można dodać ifa i 2 zmienne do istniejącej już klasy?
Po co usuwać z kontrolerów logikę biznesową? Niech mają po 10k linii, wszystko jest przynajmniej w jednym miejscu. Kontroler ma kontrolować więc niech kontroluje wszystko.
Po co pisać kod generyczny skoro można walnąć ctrl c, ctrl v i mieć 15 kopii tego samego kodu w różnych miejscach?
Po co używać klas i obiektów skoro coś da się zrobić na samych stringach?

W zamian można łatwo powiedzieć że coś się komplikuje, że za dużo tego do wdrażania, zrozumienia i pracy.
Po 5 latach pracy w taki sposób (niektórzy mogą nie wiedzieć że systemy bywają używane bardzo długo) praca z takim oprogramowaniem staje się koszmarem.
Poplątany moloch musi być utrzymywany oraz wciąż rozwijany przez co do puli istniejących już problemów dokładane są wciąż nowe. Ciągle trzeba robić obejścia na jakieś dziwne zachowania wynikające ze zwyczajnego lenistwa.

Mówi się że programista powinien być leniwy. To co odróżnia dobrego programistę od słabego jest to, że ten dobry właśnie z lenistwa poświęci tydzień na zrobienie mechanizmu który nie będzie w przyszłości wymagał zbyt wiele utrzymania jeśli nie zmienią się wymagania biznesowe. Ten słaby zaklepie to w jeden dzień i odhaczy w trackerze - zrobione. Tyle że kiedy po 2 tygodniach okaże się że trzeba ten fragment rozszerzyć to zamiast jednego dnia zajmie to 3. Po 5 latach będzie wymagał przepisania co zajmie 4 miesiące.

Jeśli ktoś pracował z systemem przez długie lata to wcale nie znaczy że jest nieomylny, albo jego kod nie jest zwyczajnie, po ludzku ch***wy.

@LukeJL zgadzam się. Tyle że dla jednych *przeinżynierowaniem *jest tworzenie całego modułu do parsowania kodu pocztowego, dla innych to podzielenie klas względem odpowiedzialności

var napisał(a):

Jeśli ktoś pracował z systemem przez długie lata to wcale nie znaczy że jest nieomylny, albo jego kod nie jest zwyczajnie, po ludzku ch***wy.

Jeśli jakiś system był rozwijany przez długie lata, to jego kod jest zwyczajnie zawsze ch***wy. Zawsze.

To jest tylko i wyłącznie konsekwencja niedbalstwa i braku profesjonalizmu. Nawet jeśli trzeba świadomie zaciągnąć dług technologiczny żeby zrobić coś na wczoraj to obowiązkiem zespołu technicznego jest zorganizowanie sobie czasu na przywrócenie jakości.
Tyle, że z moich doświadczeń wynika że najczęściej można napisać całkiem dobry kod nie poświęcając na to o wiele więcej niż tworząc lubiane przez wszystkich spaghetti. I często okazuje się, że kiedy w czasie testów wyjdzie że spaghetti wymaga poprawek to te zajmują dużo więcej czasu niż napisanie czegoś koszernie z testami jednostkowymi i integracyjnymi.

Płakać się chce jak ci słynni polscy señorzy klepią kod gorszy niż hindus na kacu.

A co najgorsze moim zdaniem, każdy nawet największy błąd nigdy nie jest wyjaśniony brakiem kompetencji. Zawsze znajdzie się jakiś powód czemu Ci "seniorzy" popełnili ten błąd: bo time preasure, bo koniec sprintu, bo zaraz się go poprawi, bo i tak nie jest client facing, bo tak było wcześniej, bo tak robimy od zawsze, bo poprawie go w następnej iteracji, bo to w sumie nie jest bug to feature, etc.

Nigdy nie słyszałem żeby taka osoba powiedziała "nie umiem" / "nie wiem".

To wynika z tego, że (szczególnie młodsi) programiści zakładają iż wszyscy to "entuzjaści" którzy będą klepać super kod po godzinach, tak nie jest, sporo seniorów przychodzi robi swoje i wraca do swojego życia, rodziny, pasji, hobby itp.
Po co robić dodatkową robotę skoro nikt ci za to nie zapłaci? nawet często nie podziękuje (bo przecież i tak już ci dużo płacą, a firma ponosi straty ;) ), oni mają to w dupie, robią swoje i idą do domu.
Będziecie starsi to zrozumiecie.

No ale nie trzeba klepać super kodu po godzinach. Żeby zostać seniorem trzeba kilku lat i najczesciej da sie zorganizować trochę czasu w pracy na dokształcenie się. Wystarczy trochę wewnetrznego napedu do samorozwoju i odrobinę chęci. Oraz otwarta głowa.

Chyba że od początku pracuje się w takich zespołach i samemu nie czuje się potrzeby rozwoju.

Mam już trochę lat i właśnie nie rozumiem. Klient/pracodawca płaci mi jako specjaliście i mam wykonywać zadania profesjonalnie - nie jak pijany Heniek, pomocnik murarza.

W jednej z poprzednich firm miałem nieszczęście uczestniczyć w rekrutacjach na stanowisko seniorskie. Większosci kandydatów można było zaproponować stanowisko juniorskie albo bezpłatne praktyki.

daniel1987 napisał(a):

po drugie jeżeli pracował ktoś lata z systemem to zna go na tyle że nie musi za każdym razem tworzyć pull requesta

Nie, nie, nie i jeszcze raz nie. Wrzuty do mastera bez CR, gdy nad projektem pracują co najmniej dwie osoby to absolutny rak.

Nie ma czegoś takiego jak "zna go na tyle że nie musi". On może i zna - jeśli tak i kod jest dobry, testy trzymają się kupy i build przechodzi, to dostanie szybko approvale bez zbędnych ceregieli i tyle. Inni niekoniecznie znają kod równie dobrze. Ktoś go powinien obejrzeć, choćby pobieżnie (ludzie na ogół i tak sprawdzają PRy ze skrupulatnością odwrotnie proporcjonalną do ilości zmian) i choćby dla samego zapoznania się, jak coś jest niejasne to będzie mógł zapytać itd. Projekt to nie jest prywatne poletko pana seniora który sobie wrzuca kiedy chce i co chce.

Zresztą, co jeśli dwaj tacy seniorzy-znawcy będą chcieli zrobić wrzuty bez PR? Kto zrobi git push -f wygrywa?

var napisał(a):

Tyle, że wszystko ma swoje granice.
Po co korzystać np z RabbitMq skoro mozna dodać tabelkę do bazy, podpiąć do niej każdą aplikację i zrobić sobie komunikację w ten sposób.

Niejeden (i niekoniecznie polski) architekt pryncypał gotów byłby uznać, że to bardzo dobry design - tym chętniej, jeśli sam go zaproponował :D

Mówi się że programista powinien być leniwy. To co odróżnia dobrego programistę od słabego jest to, że ten dobry właśnie z lenistwa poświęci tydzień na zrobienie mechanizmu który nie będzie w przyszłości wymagał zbyt wiele utrzymania jeśli nie zmienią się wymagania biznesowe. Ten słaby zaklepie to w jeden dzień i odhaczy w trackerze - zrobione. Tyle że kiedy po 2 tygodniach okaże się że trzeba ten fragment rozszerzyć to zamiast jednego dnia zajmie to 3. Po 5 latach będzie wymagał przepisania co zajmie 4 miesiące.

Z drugiej strony, jak poświęcisz ten tydzień, pobawisz się w mniej lub bardziej udany future-proofing to prawie na pewno ktoś na CR będzie argumentować, że to rzeźbienie kodu na zapas, kto to będzie chciał utrzymywać, po co pisać coś czego nie potrzebujesz, a w ogóle skąd wiadomo że będziemy to kiedykolwiek rozszerzać i nawet jak sam tego od razu nie zaorasz, to ktoś to w końcu zaora za Ciebie.

Poruszałem ten temat ostatnio na forum. Jak ktoś powiedział - idea no big design upfront została zastąpiona ideą no design at all i tak się już żyje na tej wsi. W końcu jesteśmy edżajl ;)

var napisał(a):

Mam już trochę lat i właśnie nie rozumiem. Klient/pracodawca płaci mi jako specjaliście i mam wykonywać zadania

W praktyce masz wykonać jak najszybciej/najtaniej (szczególnie w początkowych etapach projektów jak nie wiadomo, czy będzie większy budżet/kontynuacja), bardzo rzadko się zdarzają zwroty "macie tyle czasu ile potrzebujecie" to raczej science fiction, potem dług narasta i w zasadzie lepisz co jest, potem przychodzi jakiś midek z zewnątrz i doznaje szoku :)