Uparci programiści

25
  • 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?

( ͡° ͜ʖ ͡°)

1

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

0

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" :]]]]

1

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

7

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.

5

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.

1

Ale incepcja xD

1

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.

0

Pozniej awansuje taki na TL, dajcie spokoj :]

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

1 użytkowników online, w tym zalogowanych: 0, gości: 1