Programista nie do zastąpienia

Sporo też zależy od branży, ale jak dla mnie firma sporo traci. Czasem jest tak, że wiedza domenowa jest najcenniejsza. Przyjdzie dobry programista, ale co z tego skoro nie wie jak kod wygląda a całość liczy parę milionów linii - poza tym nie wie jak produkt działa dokładnie, bo jest bardzo złożony. U nas np tej wiedzy domenowej jest cholernie dużo (wynika to z tego, że na każdy rynek musimy wydawać coś innego, bo w każdym kraju są inne obostrzenia prawne) i nawet pracując po kilka lat nie wiesz wszystkiego. Ktoś kto ma pełną wiedzę na temat produktu i rynku jest u nas na wagę złota. Nawet jak stary, który się zwalnia da z siebie wszystko jeśli chodzi o nauczenie innych swojej wiedzy to i tak może nie wystarczyć. Już nie mówiąc o takich, którzy byli przy tworzeniu programu od zera. Taki najwięcej wie. Dokumentacja też nie jest zawsze idealna.

Niemniej jednak siedząc po 10 lat w jednej firmie to też nie jest zdrowe. Gdzieś słyszałem, że powinno się zmieniać tak co 3 lata, aby się dobrze rozwijać. Są i tacy co uważają, że co 8 miesięcy. No, ale to zależy od stacku pewnie.też.

Z jednej strony piszesz z pozycji najlepszego programisty w projekcie, z drugiej strony piszesz, jakbyś rozważał w bliskiej przyszłości, że Cię zwolnią i rozkmniał jak się ochronić, z trzeciej strony piszesz jakbyś był gotowy za-sabotować projekt (pierwszy akapit).

Nie ogarniam :)

Najwięcej niezastąpionych to jest na cmentarzu, a mimo to świat dalej działa.

Przykład sprzed 10 może 12 lat. Jeden kolega zrobił bardzo dużo dla projektu, ale chciał być doceniony $. Firma go wypychała wręcz żeby sobie poszedł.
Na to inny kolega. No i on sobie pójdzie, przyjdzie nowy, nie ogarnie, to będzie po swojemu robił.
Inny przykład. Przenoszono projekt z Francji do Polski. Francuzi patrzyli się na naszych jak na wrogów. Nic nie pomogli. No ale tutaj to francuskie nazwy funkcji i zmiennych nie przeszkodziły ogarniać projektu.
Kolejny, po 23 latach z projektu odchodzi główny architekt. Gość jest od początku, no ale nie pyklo I idzie. Projekt trwa dalej.
Kolejny, kolega mój w jednej firmie przesiedział 16 lat. Mówił że nie chce odejść bo boi się że bez niego sobie nie poradzą. A był taki że jak się coś kwasilo to po objawach potrafił mniej więcej wskazać gdzie szukać w jakiej metodzie nawet. W końcu kasa go przekonała. Zmienił. Firma bez niego też działa

Jeśli wydaje ci się że jesteś niezastąpiony to masz rację
Wydaje ci się.

Nie ma niezastąpionych programistów. W najgorszym wypadku projekt pisze się od nowa - a ten, kto dopuścił do takiej sytuacji ma jedynie nauczkę i pozostaje nadzieja, że podobnych błędów nie popełni przy kolejnych iteracjach systemu. Oczywiście mogą istnieć skrajne przypadki, że ktoś napisał cały ogromy system poza kontrolą "szefostwa" i wszystko robił po swojemu, źle, niezrozumiale itp ... Ale jeśli to "ogromy i ważny" system to jak głupi musiał być "szef"/"właściciel", że nie zadbał o to by się zabezpieczyć. Obecnie w większości sytuacji nawet jeśli ktoś komuś zleci zrobienie systemu "na oślep i bez kontroli" to raczej znaczy, że stać go na jego ponowne napisanie w razie porażki ( jeśli nie, patrz wyżej czyli zleceniodawca jest głupi / naiwny / nie zna się / nie powinien się za to zabierać / jak wtopi to jego wina ).

Dodam jeszcze, że to zwykle tym z niższego szczebla wydaje się, że są niezastąpieni bo niby "szefostwo" sprzedaje ich program. To nie do końca tak jest. Szefostwo sprzedaje pewną ideę, którą może zrealizować także z kimś innym.

Z jednej strony piszesz z pozycji najlepszego programisty w projekcie

Nie jestem najlepszy, nie jestem gwiazda, nie mam gwiazdek na githubie, studiów, typowy zwykły głupek, który czasem spojrzy inaczej. Zawsze mnie dziwiło, dlaczego inni w pracy są tacy pewni siebie, jak to robią, że tak wiele rzeczy potrafią zapamiętać, odtworzyć czy też olać, tzn zachować dystans itp Ja do niektórych problemów potrzebuje czas by wymyśleć dobre podejście, a inni otwierają emacs/vim, trzaskają zadania, pisza, usuwają i gotowe - sęk w tym, że robią to bezmyślnie. Zamiast zastanowić się z czego wynika problem dowalają kolejne akrobacje albo kolejne narzędzia / techniki zwalniające z myślenia.

Oczywiście mam wątpliwości do swojego kodu - nie byłbym sobą, ale do pracy innych osób mam jeszcze większe.

Wątek założyłem, bo mam wrażenie, że gdybym komplikował projekty zgodnie z programistycznymi zwyczajami to wiele bym się nie różniłbym się od osób, które utrudniały mi prowadzenie projektów. Wtedy nie dość, że miałbym więcej luzu to może i byłbym w jakimś stopniu niezastąpiony :D

Skoro jesteś dobry to idź do firmy gdzie szukają wymiataczy i płacą grubą kasę. Albo powiedz obecnemu pracodawcy że na rynku za takiego specialistę płacą x a ty dostajesz y, i zapytaj co możemy z tym zrobić.
Natomiast psucie projektu i czynienie się niezastąpionym to patologiczne praktyki i mam nadzieję że ci teraz wstyd. Nie wiem jak można wpaść na taki pomysł. Wszystko u ciebie w pożądku?

Psułbym zgodnie z normami. Przykładowo jeśli wiem, że w danym przypadku lepiej byłoby mieć niemodyfikowalne wartości, a z jakiejś przyczyny unormowało się używanie mutowalnej to komu podstawiam nogę? Przecież tak było, jest i będzie.

Cały czas piszę o komplikowaniu zgodnie z najlepszymi uznawanymi praktykami w zespole. To, że wiem, że da się lepiej nie znaczy, że mam się produkować i wszystkich do okoła przekonywać i tak mało kto to doceni.

https://www.freecodecamp.org/news/we-fired-our-top-talent-best-decision-we-ever-made-4c0a99728fde/

Zgadzam się w 100% z przedmówcami. Nie ma ludzi nie zastąpionych.

Pracowałem parę ładnych lat w jednej firmie, oj- ile tam było ludzi niezastąpionych, z potężną wiedzą programistyczną i domenową, zwalniali się i... nic wielkiego się nie stało. Oczywiście były jakieś perturbacje na początku, ktoś musiał więcej siedzieć, żeby się czegoś dowiedzieć, ale świat się nie zawalił. Czasem po odejściu takiego kogoś nagle ktoś "wypływał". Okazywało się, że szary człowiek, który niczym się nie wyróżniał nagle wyrastał na ważną osobę, nawet lepszą niż ten, kto odszedł. Po prostu czuł się w jakimś stopniu stłumiony przez starego wyjadacza. Także z punktu widzenia firmy odejście "eksperta" to nie zawsze katafstrofa, czasem to przewietrzenie biura i poprawa atmosfery;) To tak jak np. w piłce nożnej- jeden gwiazdor przyćmi całą drużynę, a jak odchodzi, to się okazuje, że inni to całkiem dobrzy gracze tylko nikt ich nie zauważał, bo wszystko się koncentrowało na jednym człowieku, atmosfera była zła itd. tip.

Techlead zrobił półtora roku temu poradnik na ten temat:

pracowałem w mniejszych i większych firmach
przeżyłem kilka takich odejść herosów nie do zastąpienia
czasem problemy które rozwiązywali odchodziły razem z nimi ;)
i potwierdziła się wszędzie prawda, nie ma ludzi nie do zastąpienia, zawsze ktoś jest za Tobą kto też chce być top of the top, albo nagle się ktoś zjawia z naprawdę łebską głową, albo ten skomplikowany system się zastąpi innym

Co do podwyżek to zależy od firmy, czasem same dbają o pracowników, czasem trzeba pochodzić za swoim, a czasem wyciskają ile się da i biorą nowy narybek, małe szanse żeby ktoś Ci rzucił 3x podwyżkę nawet jak cały team zastąpisz... za bardzo się uzależnią od Ciebie i dopiero będą w plecy ;)

Możesz spróbować być niezastąpiony. Widziałem nawet przypadki gdy komuś to się udawało.
Poradnik:
https://github.com/Droogans/unmaintainable-code

Co może się przydać:
http://www.buildyourownlisp.com/

Co może się nie udać:
https://www.freecodecamp.org/news/we-fired-our-top-talent-best-decision-we-ever-made-4c0a99728fde/

W przypadku z którym ja się spotkałem skończyło się na tym że system był tak przekombinowany że autor jego skomplikowania sam musiał zakasać rękawy bo większość doświadczonych programistów w końcu odeszła. Jeśli chcesz pracować ze z##%^! kodem (nie ważne że przez Ciebie) do końca życia to przepis masz powyżej.

Nie opłaca się być ekspertem stricte projektowym, bo po odejściu z projektu może się okazać, że niewiele się umie. Warto codziennie starać się udoskonalać :)

a ja mogę pisać system, który coraz trudniej będzie pojąć innym osobom.

To chyba tylko jak nie macie tam żadnego code-review.

Moje pytanie brzmi tak, jak ciężko jest zastąpić osobę, która robi WIDOOOCZNĄ różnicę w jira, a i też wie najwięcej o systemie, i ma największy wpływ na kluczowe taski.

Jak splunąć. Im większe korpo tym prościej. Twój wyimaginowany wielki wkład nie ma absolutnie żadnego znaczenia.

Ja wiem, że na moje miejsce przyjdzie inna osoba, ale firma tracąc herosa, mając ciężki kod do zrozumienia i zwłokę z ficzerami też coś straci.

Znów: im większa firma, tym mniejsze to ma znaczenie. Jak firma ma pod korek zleceń/backlogu i 2-3 programistów, to może jeszcze by się ktoś zmartwił, ale jak ludzi jest 20-30 albo 200-300 to nikt nawet nie mrugnie.

W jakich systemach, i okolicznościach najtrudniej jest zwolnić takiego dobrego programistę? To musi być fin-tech czy inne dziedziny też wchodzą w grę? Tu bardziej polecacie java czy scala czy javascript? Nie znam się, ale chyba problem z javascript można wyelminując przepisując front na świeższy więc dużo tu ryzykuję. Może scala? W niej mógłbym wycisnąć wiele ciekawych rzeczy zarówno z OPP, jak i FP.

Przy dobrej architekturze nie da się tak zabetonować kodu. Zawsze da się wymienić moduł / mikroserwis albo obłożyć go adapterem i o nim zapomnieć. Robi się tak przecież od lat! Jest wiele systemów które działają na jakimś kodzie w COBOLu, Fortranie i innych, napisanym 50 lat temu. Ale przed tym kodem stoi jakiś adapter, który kiedyś mapował to na RPC, potem CORBE, potem SOAP, a dziś na jakiś REST.

Czy programista, który robi widoczną różnicę, jest pomocny, robi więcej niż reszta i przede wszystkim dopycha do końca kluczowe zadania, może ugrać 3-krotną podwyżkę?

3-krotną z jakiego pułapu? 3x stawka innego seniora w projekcie? xD Taki programista najwyżej ugra zwolnienie, bo będzie powodował ferment w zespole.

@semicolon co jest twoim celem? Chcesz złapać robotę z której cię nie zwolnią? Są łatwiejsze metody niż takie cyrki które proponujesz. Ot zatrudnij się dla organizacji międzynarodowej (ESA, ESO, CERN, NATO etc.) i dostaniesz wieloletni kontrakt, z którego praktycznie nie da się kogoś zwolnić.

Naprawdę są lepsze sposoby na to, żeby zostać kimś dającym ogromną wartość dla firmy i mieć pozycję do wołania sporej kasy na podwyżkę.
Powiem Ci na swoim przykładzie: wyciągnąłem projekt z bagna, które mogło sprawić, że przestałby istnieć. Złapałem się po prostu za coś, za co nikt nie chciał się łapać i nie wiedział, jak do tego podejść. Zysk dla projektu był ogromny.
I z chęcią dzielę się tą wiedzą dalej, bo jak mnie nie daj Boże tramwaj czy coś przejedzie, to ktoś będzie wiedział chociaż od czego zacząć. A cenny dla projektu jestem czy komuś przekazuje tą wiedzę, czy nie, bo ktoś wie, że można na mnie liczyć i że jak jest zadanie specjalne, to je ogarnę.
Czy to mimo wszystko dało mi efekt w postaci większej wypłaty? Tak. Właśnie dopinam rozmowy o nowej podwyżce z minimum 45% (poprzednia była rok temu, w projekcie jestem prawie 2 lata).

Jeżeli chodzi o webdevelopment to praktycznie nie da się napisać kodu dzięki któremu byłoby się niezastępowalnym. Od dłuższego czasu takie aplikacje pisze się w architekturze mikroserwisowej gdzie każdy komponent jest wymienny. Jeżeli jesteś niewygodny dla zespołu to zostaniesz wyrzucony, a jeżeli Twojego kodu nie da się poprawić to zostanie przepisany na nowo. Nawet jeżeli jesteś super dobry to nikt nie poniesie odpowiedzialności za zwolnienie jednego programisty. Co najwyżej Twój szef wyleci po roku kiedy jego wydajność znacznie spadnie, ale i tak mało kto będzie w stanie zidentyfikować przyczynę. Twój szef znajdzie pracę gdzie indziej i karuzela będzie kręciła się dalej.

Natomiast trzeba przyznać, że istnieją takie projekty do których ciężko się zabrać. Zwykle są to projekty związane z metodami obliczeniowymi, szczególnie jakiś kod w Fortranie gdzie najtrudniejszą rzeczą jest matematyka, tutaj już nie da się nikogo oszukać i bez doktoryzacji projektu nie ruszysz. Ale czy doktorzy w takich projektach piszą taki kod umyślnie czy z powodu niekompetencji w inżynierii oprogramowania? Raczej takie projekty realizują z grantów więc pensję mają ustaloną na stałe i nic na czymś takim nie mogą ugrać.

Napiszę z perspektywy takiej osoby. Połowa pracy wykonana przeze mnie (na 10os zespół), bardzo dużo usprawnień i zmian na lepsze. Dobra znajomość domeny i byłem też zawsze pierwszą osobą do której uderzali z problemami. No i zmieniłem niedawno projekt i.. nic :) Starałem się przeprowadzić KT, stworzyłem kilka stronek confluence z 'FAQ' i jakoś wszyscy ten wózek pchają beze mnie. Zauważyłem też, że jak odszedłem to parę osób które totalnie nic nie robiły nagle zaczęły się więcej uczyć, proponować zmiany itp.

Co do wynagrodzenia dostawałem często duże podwyżki (30-50%). Ale niedawno przy rozmowie z kolegą z zespołu okazało się, że i tak mniej zarabiam. Po prostu ja wynegocjowałem bardzo niską stawkę na starcie więc z dużymi podwyżkami się zbliżyłem do tego co niektórzy wynegocjowali na starcie. Okazuje się, że umiejętności miękkie są bardziej przydatne niż techniczne w takich sytuacjach :)

Najbardziej "zaciemniony" i trudny kod z jakim miałem w życiu do czynienia pochodził od młodych i niedoświadczonych, którzy pisząc program używali wszystkiego o czym słyszeli a do tego w sposób niewłaściwy bo zwyczajnie nie rozumieli istoty rzeczy.
Doświadczony programista ma już wyrobione nawyki przez co z natury nie wymyśli takich kretynizmów, kulfonów i wygibasów składniowych jak początkujący, który jeszcze nie wie co robi a jego celem jest "byle zadziałało". To były fragmenty kodu, które niemal zawsze trzeba było wymienić w całości. Szybciej było napisać na nowo niż zastanawiać się jaką artysta miał wizję.
Przy kodach źródłowych pochodzących od zaawansowanych zawsze udało się zdebugować i rozgryźć koncepcję - nawet jeśli była one przerośniętą abstrakcją.

To czego chcesz(?) próbować nazywa się szantaż i każdy manager jeżeli nie jest warzywem za takie coś cię wywali od ręki. Robiąc takie akcje stajesz się narastającym zagrożeniem dla projektu, więc logiczne jest pozbyć się ciebie jak najszybciej i rozpocząć proces naprawy.

semicolon napisał(a):

W jakich systemach, i okolicznościach najtrudniej jest zwolnić takiego dobrego programistę?

Najtrudniej w takich gdy jego nazwisko ma gwiazdorską wartość rynkową i sam fakt jego odejścia może wpłynąć na wizerunek firmy. Tak jak w sporcie. Wszystko inne nie ma znaczenia.

nie ma ludzi nie do niezastapienia

Nie sądzę żeby Twój sposób pozwolił Ci się gdziekolwiek zabetonować po wsze czasy, za to znalazłeś naprawdę dobry przepis na:

• toksyczną atmosferę
• frustrację i przedwczesne siwienie/łysienie dziesiątek Bogu ducha winnych programistów
• wyrabianie sobie jak najgorszych nawyków, którymi będziesz mógł się pochwalić jak kiedyś przyjdzie Ci jednak zmienić pracę
• architekturę spaghetti / big ball of mud / po trochu z każdego
• robienie wszystkiego by projekt jednak klęknął, bo pułapek i złych rozwiązań będzie zbyt wiele

Tak trzymaj, najlepiej z dala ode mnie :D

Odpowiedź na: https://4programmers.net/Forum/1682562

Dobry materiał i oddaje to co chciałem powiedzieć. Natomiast ze swojej strony chciałbym dodać, że widzę te antywzorce jak pulę o nieograniczonej pojemności. Wszystko to na czym w kodzie się bazuje ma obusieczne znaczenie i np. te punkty do których odniósł się Twój techlead raz są dobre, a raz są złe, wiele zależy od rozpatrywanego przypadku.

**1. Create tons of functions **

co robić w przypadku FP, też źle? kompozycja nie zawsze jest zła. Na video został omówiony przypadek dotyczący testów - być może testują zbyt dużo prywantnych rzeczy, być może podział na tak wiele funkcji wymuszcza pisanie ich w zbyt ogólny sposób. Podobne probemy da się spokojnie odtworzyć w klasach.

**2. Use one liner as much as possible
**

W kodzie częściej spotykam się z odwrotnym przypadkiem. Ktoś robi dużo rzeczy, dużo ifuje, a w praktyce część złożonych warunków z ifów da się wyodrębnić do postaci predykatów, a potem w głównej funkcji składasz te wyrażenia operatorami logicznymi - pisany kod brzmi jak zapis reguły i faktycznie może mieć jedną linię, ale jego czytelność ma zupełnie inny wydźwięk od wyrażeń z operacjami bitowymi.

**3. Use recursion
**

W imperatywnych językach może to robić problem, ale coraz więcej jest języków z mieszanym podejściem. Nie chcę bronić rekurencji, ale przykład jaki podał Twój techlead oznacza symulowanie pętli; co jeśli pętla symuluje rekurencje z własnym stosem, wtedy jest lepiej? Moim zdaniem to też zależy od przypadku.

**4. Good use of comments
**

No, ale np. zwrócenie uwagi na hacki na jakim opiera się kod. Np. jakiś element z javascriptu, gdzie coś zależy od wersji przeglądarki. Ja czasem zostawiam link do strony, która omawia detale związane z tym związane. Oczywiście dostaje upomnienia, że by nie robić komentarzy w kodzie, bo to niezgodne z clean code.

**5. Adding code you may need but never will
**

Nie chcę rozpoczynać tego tematu, ale tego typu rzecz rzecz ciężko nie realizować. Na tym założeniu opiera się mnóstwo praktyk gdzie pracę zaczynasz od wystawienia interfejsu. Być lepej byłoby opóźniać, pisać tak "ograniczony kod" jak to możliwe i w ramach refaktoryzacji uogólniać, ale mało kto tak robi.

**6. Lots of vairables the more the better
**

A lepsze jest mieć jedną zmienną, która na skutek mutacji reprezentuje coś innego? Zależy od przypadku, ja np. gdy widzę kod, który coś parsuje, normalizuje to nowy stan opisuje przez nową zmieną, aby taki kod opisywał przejścia. Czy to źle? Zależy od przypadku.

**7. Start to refactor the code
**

Przykład refaktoryzacji bez uwzględnienia kontekstu biznesowego rzeczywiście może sprawić, że programista zacznie się wstydzić, ale dla przykładu poruszę przykład krolika: jeśli masz w kodzie używasz linked list, ale nie funkcjonuje to jako klasa tylko wskaźniki na węzłych, w kodzie masz porozrzucane różne pętle iterujące - czy taka refaktoryzacja wymaga ustaleń z biznesem, czy biznes w ogóle takie rzeczy interesują? Ten przypadek jest dla mnie pisaniem kodu pod maszynę, a nie człowieka, tego typu rzeczy da się ratować bez kontaktu z biznesem.

@semicolon:

Cóż, mój post faktycznie ma negatywną aurę, ale z drugiej strony spójrz na swoje ręce jak piszesz kod. Zawsze rozwiązujesz zadania dobrze? A jeśli tak, to co to znaczy dobrze?

Nie rozwiązuję dobrze, częściej robię źle niż dobrze i to mimo najlepszych starań. Nawet jak wydaje mi się, że zrobiłem coś dobrze, to po jakimś czasie może się okazać (i nieraz się okazuje), że tylko mi się wydawało i jednak jest źle.

Albo bardzo źle.

Albo może nie jest stricte źle, ale dobrze też nie jest, albo dało się coś zrobić lepiej i prościej.

Zdarza się też, że z premedytacją "muszę" coś ohakować, wcisnąć protezę i wybrać słabe, brzydkie rozwiązanie, bo żeby zrobić coś na porządnie musiałbym ścigać niezastąpione osoby, które już dawno odeszły, analizować przez kolejne 3 lata, później kolejne 3 lata przepisywać pół systemu, potem kolejne 5 lat naprawiać rzeczy, które przy okazji zepsułem... chyba już widzisz, dokąd to zmierza ;)

I też nie masz ambicji, by zarabiać więcej. Myślę, że masz i dlatego na tym podłożu wiele się nie różnisz ode mnie.

Rzecz w tym, że nie próbuję i nie chcę próbować wykorzystywać tego jako karty przetargowej, by się zabetonować i jeszcze stworzyć sobie ciepłe gniazdko z dobrą płacą. Mam ambicję żeby zarabiać więcej, ale zdążyłem sobie ubzdurać, że warto byłoby cokolwiek sobą reprezentować, by móc się upominać o podwyżki.

Wiele osób traktuje pracę jak zwykły zawód, po robocie wracają do żony i dzieci, w kodzie robią śmietnik, ale wszystko jest OK, bo oni robią jedynie tyle ile się od nich wymaga -

Posiadanie rodziny i brak jakiegoś nie wiem, duchowego natchnienia jak się zasiada do kodowania nie usprawiedliwia wykonywania swojej pracy niedbale. Jak hydraulik zrobi byle jaką instalację i zawartość toalety na piętrze zaleje pół domu, to przyjmiesz tłumaczenie że on ma dzieci a w ogóle to nie pasjonuje się rurami?

więc jeśli brzydzisz się mojego podejścia o jakim piszę w wątku. To ja nie wiem jak sobie radzisz i jak postrzegasz pracę z innych ludźmi.

Jak na razie to ja jestem tym, który najczęściej robi dziadostwo i musi po sobie poprawiać, więc radzę sobie próbując robić mniej syfu :D

W firmie i zespole, w którym pracuję używanie takich wspomagaczy, jak code review czy statyczna analiza kodu jest must have, jeśli ktoś (czytaj ja) zaczyna robić śmietnik to PR jest wałkowany do skutku. Jak nie otestujesz tego co napisałeś albo testy niczego nie testują, to też możesz zapomnieć o approvalach. Jak jakiś jeden zespół ma nazwijmy to niższe standardy pracy niż drugi, to ten drugi zaczyna truć, źlamdać i suszyć głowę.

Dla przykładu - w poprzedniej firmie/zespole CR było, testy były, ale wałkowania i statycznej analizy już na przykład nie. Niby się staraliśmy, ale siłą rzeczy bywało różnie i pewnie wiele rzeczy mogliśmy poprawić, często nawet pewnie nie wiedzieliśmy, że robimy coś źle, bo niby skąd mogliśmy wiedzieć, że robimy źle, nie używając odpowiednich narzędzi... A w mojej pierwszej testów nie było, standardów innych niż nawyki kogoś-tam nie było, CR składało się z nader wartościowych komentarzy typu hyhyhy co to jest XDDDD, był jeden master guru który mergował u siebie do mastera, mimo używania VCS było pełno kodu zakomentowanego "na zapas"... no, ale wtedy to była norma, a dziś za odwalenie czegoś takiego chyba bym się sam zgłosił po dyscyplinarkę :D

Trochę temat zaczyna zajeżdżać syndromem oszusta.

To, że pewnych zadań nie da się rozwiązać w jakimś określonym czasie, przy określonym budżecie jeszcze nie czyni z nikogo słabego programisty. Praca jako programista zawsze wiąże ze sobą to ryzyko, że trzeba będzie w którymś momencie poświęcić trochę czasu na dokształcania i management ma to wliczone w koszty. Jeżeli stwierdzasz, że albo zrobisz prostego workarounda (lub napiszesz brzydki kod), albo będziesz siedział nadgodziny za które nikt ci nie zapłaci, żeby zrobić coś dobrze, a później wybierzesz pierwszą opcję to również nie będzie czyniło cię złym programistą. Dług techniczny nie zawsze jest zły. Czasami warto go zaciągnąć, żeby wydać produkt, zrobić demo i ściągnąć pierwszych klientów szybciej.

Jeżeli uważasz, że twoi koledzy piszą słaby kod poniżej ich umiejętności i sam rozważasz pisanie takiego kodu (bo po co się starać) to zadaj sobie następujące pytania:

• czy oni są kompetentni na tyle, żeby pisać lepszy kod?
• czy oni świadomie zaciągają dług techniczny?
• czy zwróciłeś im uwagę podczas code review? Jaka była reakcja?
• czy ich menadżer wie o zaciąganiu tego długu technicznego?
• czy nie zyskasz więcej poprawiając po nich ten kod i pokazując menadżerowi, że jesteś proaktywny?

twoj_stary_pijany napisał(a):

Dług techniczny nie zawsze jest zły. Czasami warto go zaciągnąć, żeby wydać produkt, zrobić demo i ściągnąć pierwszych klientów szybciej.

Scieżka ta jest szybka i jednokierunkowa. Granica jest płynna a entropia ciągle rośnie.

semicolon napisał(a):

Ostatnio moje dyskusje na forum dają mi trochę do myślenia i dochodzę do prostego wniosku: mogę bardzo >
Moje pytanie brzmi tak, jak ciężko jest zastąpić osobę, która robi WIDOOOCZNĄ różnicę w jira, a i też wie najwięcej o systemie, i ma największy wpływ na kluczowe taski.

Jak programista jest nie do zastąpienia, to zwykle jest to antypattern, bo wtedy dany programista idzie na urlop / nie ma czasu itp. i projekt stoi. A jak odejdzie z pracy to też jest problem, jeśli tylko on znał dobrze dany projekt i tylko on go był w stanie pociągnąć.

Ale programowanie tłumowe, polegające na tym, że każdego da się zastąpić i każdy może robić wszystko w zespole, też jest niedobre, bo wtedy burdel jest, jak każdemu się wydaje, że jest full stackiem i jest w stanie zrobić każde zadanie.

Może nie ma ludzi nie do zastąpienia, ale strach przed odejściem takich ogarniających wszystko osób jest. Mi się wydaje, że największą podwyżkę można dostać znajdując inną pracę. Po rozmowie z obecnym przełożonym można przebić stawkę wynegocjowaną w nowej firmie, dalej robić to samo i cieszyć się dużo większymi zarobkami. Jest ryzyko, że to się nie uda, ale bez strat, bo i tak w nowej pracy będą czekać na podpisanie umowy z większą stawką, niż się miało do tej pory. Ale trzeba samemu ocenić, czy zasługuje się na więcej, niż się dostaje i czy firma może sobie na taki wydatek pozwolić. Ameryki pewnie tym wpisem nie odkryłem ;)