Uparci programiści

• Nie refaktorowanie rzeczy, które tego wymagają, a dług techniczny rośnie
• Zero designu, wszystko robione jakimiś hackami po linii najmniejszego oporu, byleby sie skompilowało i pora na CSa
• Wrzucanie na CR sugestii, które nie mają prawa zadziałać i nie biorą pod uwagę reszty systemu/corner casów

Mieliście do czynienia z takimi osobnikami? Niestety w obecnym projekcie mam takiego programistę. Ciągle próby "przyspieszenia pracy" oraz ułatwienia sobie życia poprzez ciągłe hacki i triki - Dla samej zasady, żeby tylko nie użyć konkretnej technologii gdzie sytuacja tego wymaga. Do tego strasznie nakręcony na dynamiczne rozwiązania, połowa codebase generowana z jakichś magicznych konfiguracji, byleby tylko nie zduplikować jednej linijki.

Praca z takim człowiekiem jest wyjątkowo męcząca. Utrudnia on pracę i wprowadza dziwne/złe nawyki do projektu. Niestety jakakolwiek argumentacja nie działa, bo on wie lepiej.

Czy zmiana projektu to jedyny sposób na takiego gagatka?

( ͡° ͜ʖ ͡°)

Ja raz miałem "przyjemność" z kimś takim pracować. Nie bardzo dało się cokolwiek z tym zrobić bo był leadem naszego zespołu.

Jak już chcesz robić jakieś wycieczki w moją stronę, to tylko dodam, że nie jest to moja opinia a całego zespołu. W tym "Seniorów" :]]]]

Zmień pracę, kraj, nazwisko. Ogarnij czy Elon nie wprowadził już przeprowadzek międzyplanetarnych.

Mialem styczność z takimi ludźmi o ktorych piszesz. Zazwyczaj niespelnione marzenia, ambicje, presja rodziny, brak ojca w rodzinie.
Później dochodzi zaangażowanie emocjonalne w projekcie, patrzenie na pryzmat zespolu przez wlasne "ja". Brak profesjonalizmu. Jak jeszcze zaczynaja traktować pracę jak drugie życie, robią wiecej niż 8h to już wiedz że trafiłeś na toksycznego typka. Praca z takimi ludźmi niszczy Ciebie i zycie prywatne, cos jak wampir energetyczny. Pogadaj z HRami o tym, jezeli nie zapropojuja Ci zmiany projektu to najlepiej jest się oddalić od takich osobnikow.

Spotkałem się z takimi osobami. Raz miałem mało doświadczenia i myślałem, że jestem głupi, więc nie ogarniam "kunsztu" takiego programisty, ale w praktyce był to over-engineering i kult cargo. Potem ta osoba poszła do innego projektu i za nią przyszedł inny, bardziej ogarnięty gość, który wywalił ok. 50% tego przekombinowanego kodu, a wszystko dalej działało i dało się łatwiej nawigować po projekcie.
Innym razem, chciałem napisać czysty kod zgodny z dobrymi praktykami wykorzystując nowe ficzery języka, to programista tego nie tolerował i zamiast mi w review napisać uwagi, to wklejał mi na czacie jakieś swoje code snippety i mówił, że mam tego użyć, bo tak.

Nie wiem, co z tym można zrobić. Jest to kwestia osobowości i braku otwartości na krytykę. Chyba najlepiej podawać na code review logiczne argumenty, że warto coś rozwiązać inaczej. Na planowaniu/refinemencie też można podać propozycje usprawnień. Gdybym był znowu w takiej sytuacji i moje logiczne argumenty, konstruktywna krytyka i propozycje usprawnień byłyby notorycznie ignorowane, to pewnie bym podziękował za współpracę. Chyba, że jakieś ciężkie siano bym za to dostawał i trudno byłoby podobne warunki uzyskać gdzie indziej, to może bym zacisnął zęby na jakiś czas : P. Niemniej jednak, podejrzewam, że jeśli ktoś nam płaci spory hajs, to wtedy oczekuje większej inicjatywy i propozycji usprawnień, a nie żeby siedzieć cicho w kącie, więc pozostaje dyskusja, logiczne argumenty lub zmiana roboty.

Ale incepcja xD

Na refactor nie ma czasu, bo biznes narzuca terminy, a designowanie rzeczy nie ma sensu, bo cały codebase to i tak hack na hacku hackiem poganiany.

Pozniej awansuje taki na TL, dajcie spokoj :]

Shalom napisał(a):

Czy zmiana projektu to jedyny sposób na takiego gagatka?

( ͡° ͜ʖ ͡°)

To zależy czy masz dużą siłę przebicia (masz już reputację kogoś, kto dowozi) i zespół, który się z Tobą zgadza (tzn nikt o problemie jawnie nie mówi, ale widać że ich osobnik męczy).
Jeśli obie odpowiedzi są na TAK, to czas na odważną decyzję - stwierdzić, że "gagatek" jest zagrożeniem dla projektu (lub morale/produktywności zespołu) i odsunąć od zespołu - to spowoduje, że pozostałym osobom z teamu urosną jaja i się zgodzą.
Jeśli choć jedna odpowiedź jest na NIE, to celem oszczędzenia sobie stresu lepiej zmienić projekt.

Na Twoją decyzję może też wpłynąć jak widzisz obecny projekt (czy jest sensowny/ciekawy) i czy potencjalne inne projekty nie będą bagnem.

@Shalom: W Twoim przypadku proponuję śmierć i zaczęcie wszystkiego od początku.

Shalom napisał(a):

• Nie refaktorowanie rzeczy, które tego wymagają, a dług techniczny rośnie
• Zero designu, wszystko robione jakimiś hackami po linii najmniejszego oporu, byleby sie skompilowało i pora na CSa
• Wrzucanie na CR sugestii, które nie mają prawa zadziałać i nie biorą pod uwagę reszty systemu/corner casów

Oj żeby tylko tyle.

Mieliście do czynienia z takimi osobnikami? Niestety w obecnym projekcie mam takiego programistę. Ciągle próby "przyspieszenia pracy" oraz ułatwienia sobie życia poprzez ciągłe hacki i triki - Dla samej zasady, żeby tylko nie użyć konkretnej technologii gdzie sytuacja tego wymaga. Do tego strasznie nakręcony na dynamiczne rozwiązania, połowa codebase generowana z jakichś magicznych konfiguracji, byleby tylko nie zduplikować jednej linijki.

A ten gość czasem dostaję do poprawy swoje rzeczy? Czy nic nie robi tylko dokłada nowe rzeczy; taki chory Open/Close? Bo może gdyby mu przyszło poutrzymywać swoje własne dzieło przez jakiś czas to by mu się odwidziało? :D

Praca z takim człowiekiem jest wyjątkowo męcząca. Utrudnia on pracę i wprowadza dziwne/złe nawyki do projektu. Niestety jakakolwiek argumentacja nie działa, bo on wie lepiej.

Czy zmiana projektu to jedyny sposób na takiego gagatka?

( ͡° ͜ʖ ͡°)

Kurczebele, ciężka sprawa. Może powiedz mu co o nim myślisz :D

Najlepsi sa mistrzowie ktorzy mowie ze robia POC ficzera wiec zeby POCa zrobic to robia go "szybko" tworzac nowy katalog kopiujac wszystko co im sie moze jako tako przydac tam if tam else tu cos sie usunie tam usunie tu if potem nie chce im sie czegos skopiowac wiec zminiaja dla calego projetu tam if tu ifa.... potem sprzedaje sie na demo ficzer dla PO/PM i taki PO/PM podchwywuje ze ficzer dziala i jest DONE wiec go sprzedaje wyzej na DONE i sie go merguje i tworzy sie taska "Tech debt".... ktorego nigdy nikt nie podejmie...
i takie cos wchodzi do kodu kilka takich ficzerow i pozdro600 na rejonie... ofc taki wojowniik kodu po kilka ficzerach zmienia projekt.... :D

pierwsze słysze

jak się kompiluje, to musi być dobrze

Pytanie czy ta osoba, którą opisujesz jest jakimś leadem lub jakąs rodziną leada / managera czy to zwykly dev na rownoleglym stanowisku? Jesli zwykly dev to ja takich ignoruje (wlasciwie ignorowałem w przeszlosci, bo w obecnym projekcie niestety poziom techniczny jest uposledzony i nie ma czegos takiego jak CR). Jesli team lead to uciekac proponuje. Tylko te czeste ucieczki sa męczące i z kazdym kolejnym razem sie juz odniechciewa.

Dlatego dobrze gdy projekt ma Tech leada z decydujacym głosem. Bo wtedy Tech lead moze latwo ukrócic takiego osobnika. Chyba, że on jest Tech Leadem, no to tylko zmiana projektu pomoże :)

Dlatego powinnismy wprowadzic nowa praktyke do extreme programming

spuszczanie wpie***lu :D

Wg. mnie to jest kwestia czy pewne rzeczy robi sie swiadomie - np. idzie na skroty, kiedy sytuacja tego wymaga. Kiedys wymyslilem poziomy dojrzalosci programisty w kotekscie zarzadzania dlugiem:

1. Produkuje dlug techniczny, bo nie umie zrobic dobrze.
2. Boi sie dlugu jak ognia - wszystko musi byc zawsze zrobione „zgodnie ze sztuka” (najlepiej DDD), nie godzi sie na szpachle. Nigdy.
3. Swiadomie zarzadza dlugiem, umie odpowiednio rozlozyc akcenty. Wie, że jakosc i czas to trade-off, nie kazdy komponent musi miec kosmiczna architekture, nie zawsze wszystko musi byc zrobione najlepiej na swiecie (np. kiedy eksperymentujemy lub robimy jednorazową akcję).

A zatem - prawda jest jak zwykle po srodku. Dlug techniczny zawsze jakiś jest i trzeba nim zarządzać, aby dowozić, ale i nie zatonąć. Na koniec dnia wygrywa ten, kto szybciej dowiezie i bedzie w stanie sie utrzymac :)

Po prostu programisci to święte krowy ktore niewiele musza, nie raz developer experience jest wazniejszy od uzytkownika koncowego bo czasem trudno znalezc kogokolwiek do pracy + ogolna rozrzutnosc w IT i jeszcze olaboga zdenerwuje sie i odejdzie

Gdyby nie bylo tak latwo to by od nas wiecej wymagano

@Charles_Ray:

Swiadomie zarzadza dlugiem, umie odpowiednio rozlozyc akcenty. Wie, że jakosc i czas to trade-off, nie kazdy komponent musi miec kosmiczna architekture, nie zawsze wszystko musi byc zrobione najlepiej na swiecie (np. kiedy eksperymentujemy lub robimy jednorazową akcję).

sugerujesz że w software engineering chodzi m.in o engineering?

"Po prostu programisci to święte krowy ktore niewiele musza" a ja mam wrazenie ze jednak programisci nie sa inteligentni w tym kraju.

Sytuacja A: Jak lekarz w tym kraju konczy studia, ma lata praktyki, dochodzi do konflitkow -> rzuca etatem szanuje siebie i swoj prestizowy zawod idzie dalej lub do swojego prywatnego gabinetu.
Sytuacja B: Programista: niby czlowiek po studiach w Polsce... wyksztalcony, znajac tyle technologii a daje soba pomiatac jakiemus typowi ktory pewnie ma uklady z szefem level + 1 bo pija wodke razem lub inne atrakcje i jest ogolne przyzwolenie na takie sytuacje. Jakie to znowu miasto ""wielkie" w Polsce gdzie odbywaja sie te praktyki? Korpo Kolchoz czy SH, itp.?

Konkluzja: Trzeba byc asertywnym. Cos Cie denerwuje? To zmien to! Powiedz ze jestes super zajebisty i nie zamierzasz tego wysluchiwac bo typie nie masz racji po prostu i koniec. Jesli nie pomoze zmien ta prace lub miasto jesli przypadek sie powtarza. Szkoda zycia na takich pajacow.

Jak masz w miarę normalny zespół, to dość uniwersalną radą na problemy jest sprawiać, żeby były widoczne. Walisz z mostu, że coś jest napisane źle, komentarze do CR olane, czy co tam stanowi konkretny problem. Ważne, żeby nie skupiać się na osobie, a na problemie i sposobach jego rozwiązania, używać sensownych argumentów i zdawać sobie sprawę, że ktoś z innymi doświadczeniami ma prawo mieć inne zdanie. Jeżeli zespół ma na to wywalone, to uciekaj (albo zmień zespół).

Zacząłbym mu sikać do herbaty albo zmienił firmę

Branża programowania w Polsce, szczególnie Java to taki odpowiednik budowlanki, tylko tyle że w IT.