Z juniorami-debilami można jeszcze pracować; bo mimo że mają debilne pomysły to można i powiedzieć że się mylą; i wskazać dobrą drogę, pomóc coś. Jak junior debil zrobi sobie logowanie i trzymanie hasła na froncie; to owszem jest debilem, ale łatwo mu pomóc.
Z seniorem-debilem sprawa jest o tyle gorsza; że z reguły Ci seniorzy mają staż i wysoką opinię o swoim skillu. Jeśli senior podejmie jakąś głupią decyzję; to nawet posiadając merytoryczne argumenty ciężko coś działać.
Señor wykształcony idiota
Co tam senior, gorzej jak trafisz w duzym korpo na architekta, ktory musi sie czyms wykazac i nakazuje rozwiazanie problemu poprzez strzelanie do muchy z armaty
Starego konia nowych sztuczek nie nauczysz atakuj argumentami, moze sie uda. Naswietlaj jego dziwne odpowiedzi, dopytuj innych czy sie zgadzaja z nim. Kombinuj Tomasch :P
p_agon napisał(a):
Starego konia nowych sztuczek nie nauczyszatakuj argumentami, moze sie uda. Naswietlaj jego dziwne odpowiedzi, dopytuj innych czy sie zgadzaja z nim. Kombinuj Tomasch :P
Doesn't work w tym zespole. Dobrze że tylko na miesiąc mnie tu przydzielili, bo bym zwariował. Pięknie byłoby myśleć że ludzie reagują na argumenty; ale nie wszędzie tak jest. Pora zmienić teamik.
Nie zapominajmy o midach. Ludzie, którzy mają już pewne doświadczenie, nie są ani nie czują się seniorami, ale jednak czują się profesjonalistami w każdym calu. I to też jest niebezpieczne.
tj. tak:
natomiast mid-debil jest hiperprofesjonalny (tj. profesjonalny na siłę). Więc będzie się stosował do wszystkich świętych zasad i "dobrych praktyk". Ludzie, którzy zamiast rozwiązać dany problem, to będą się starać za wszelką cenę robić to hiperprofesjonalnie. Więc jak wyczyta, że wzorce są dobre, to będzie wrzucał je wszędzie. Jak poczyta o testach, to będzie wszystko testować, nawet szczegóły implementacji. Przeczyta o OOP, to będzie wszystko robił obiektowo.
Z drugiej strony zamiast słowa mid-debil można być bardziej pozytywnym i taką osobę określić "mocnym juniorem". Wtedy mamy te same zachowania, jednak traktujemy je nie jako przykrą cechę mida, tylko jako naturalny etap rozwoju juniora. Ot ktoś odkrył wzorce i wrzuca je wszędzie z gorliwością neofity. Jest szansa, że taka osoba później zobaczy, że nie tędy droga. Gorzej jeśli komuś zostaje ten cargo cult na długie lata.
Pracowałem z taką osoba, może nie senior ale 4 lata skilla i w projekcie był długo, jego błędy powodowały to że czasem trzeba było poświęcić kilka tygodni na naprawę i często to były podstawowe błędy, nie wspomnę że kodu się nie dało testować a architektury były pomieszane. Też nie dało się go przekonać, tylko mówił "tak też jest dobrze, ja wolę tak".Pamietam jak wrzucił mi w mr komentarz do poprawy, zmarnowałem dwie godziny bo nie dało się zrobić tego w sposób w który sugerował, dałem sobie spokój i odszedłem po kilku miesiącach.
Senior debil nie jest seniorem, tylko ktoś, z niezrozumiałych dla nikogo powodów go posadził na stołku.
Możliwe, ze to kwestia stosowania innej skali, bo jakoś nie nadążam za tymi wszystkimi tytułami typu principal senior ninja developer, ale dla mnie najbardziej upierdliwi wydawali się właśnie tacy mid developerzy. Coś jak kierowcy w okolicach 3-go roku posiadania prawa jazdy. Wybuchowa mieszanka skromnej wiedzy, rozbudowanego, ale kruchego ego i arogancji. Już coś (wszystko?) wiedzą, a w praktyce jeszcze nawet nie spotkali w życiu poważnych problemów (albo spotkali, ale ich nie zauważyli). Jak ktoś się szczególnie wolno rozwija, to może dostać "stażowego seniora" i wtedy robi się strasznie, bo przemądrzałego juniora można zignorować, mida wyśmiać, a w przypadku takich zahartowanych osobników często po 5 minutach rozmowy widać, że ma się do czynienia z idiotą, a po kolejnych 5 nabiera pewności, że on tego dość oczywistego dla wszystkich innych faktu nigdy nie przyswoi.
Raczej należy uciekać z takiego projektu, a jak się nie da, to bardzo uważać, żeby nie zostać kozłem ofiarnym, bo często mają łatwość utożsamiania się z sukcesem, ale porażki są zawsze winą kogoś innego.
Senior, mid, junior... Jak ktoś nie widzi dalej niż czubek własnego nosa i ma problem z konstruktywną krytyką to zawsze praca z takim osobnikiem będzie jak robienie sobie harakiri łyżką do rosołu. Jest jeszcze inny typ ludzi - refaktorzy :D Jak sama nazwa wskazuję, wszystko by refaktorowali, nawet mimo braku takiej potrzeby. Tacy hipsterzy "aj ti".
Typ seniora o którym jest wątek to bardzo częsta przypadłość w korpo. Zasiedzi się taki i za sam staż dostanie rangę.
Mnie i tak nic bardziej nie denerwuje niż nawiedzeni architekci enterprise.
Wszystko musi być uniwersalne, reuzywalne, miliony paczek na FE i BE w środowisku mikroserwisowym i potem kładą wszystkie serwisy jak pobierzesz nową wersję z błędem.
Miałem raz takiego, co każdemu programiście się na CR dopierdzielal o nazwy wszystkich zmiennych i kończyliśmy z jakimiś idiotyzmami, zrozumiałymi tylko dla niego.
Ja tez jestem senior w programowaniu, ciekawy temat. Jestem tak zwany Senior PM :) i nie zawsze co dzien szybki scrum 2 minuty albo mniej. A jak trzeba podjac wazna decyzje np czy piszemy zmienne jakas_zmienna czy jakasZmienna to sie tego trzymamy i potem jak jest CR to niekt nie ma pretensji ze komus puscilismy zwrotke do poprawy. Nawet nie raz wybieramy jakies rozwiazanie wspolnie. Pozwala mi to uniknac powiedzenia ze MYLILEM SIE ale zgadzam sie ze niektore Devy nawet u mnie, niechetnie robia cos co zaproponowal mid czy junior i na co przystalismy bo oni widza to inaczej i moze lepiej by bylo zastosowac ich sposob.
Jest takie powiedzenie "Zwróć uwagę głupcowi - to Cię znienawidzi. Zwróć uwagę mędrcowi - to będzie Ci wdzięczny. W ten sposób ich rozróżnisz"
Najlepsze jest to, że często takie osoby nie mają argumentów czemu ich rozwiązanie jest lepsze.
Często takie osoby nie mają konkretnej odpowiedzi i mówią "według mojego doświadczenia to będzie się spisywać lepiej"
To jest generalna cecha - czy ktoś jest refleksyjny i uważny wobec siebie, czy nie. Nie dotyczy to tylko seniorów w firmie programistycznej, gdzie z samej racji tego jaka to branża, trzeba się cały czas uczyć, szczególnie przy różnorodnych projektach.
Prawda!
Do dziś wspominam walki z takim seniorem, że leniwe inicjalizowanie dependecji nie do końca jest najlepszym sposobem na rozwiązanie cyklicznych zależności, opróćz tego można czasami, na drodze wyjątku, nazwać funkcję inaczej niż handle, a sleep w teście na 15 minut, ze względu na używanie bezwzględnego now() jest conajmniej irytujący.
Nie pomagały argumenty techniczne, ani autorytet seniorszych seniorów, ani głaskanie po plecach (żeby nie czuł się urażony). Pomogła - jedynie zmiana pracy =P
sztadii napisał(a):
Najlepsze jest to, że często takie osoby nie mają argumentów czemu ich rozwiązanie jest lepsze.
Często takie osoby nie mają konkretnej odpowiedzi i mówią "według mojego doświadczenia to będzie się spisywać lepiej"
Ja jak proponuję rozwiązania, to potrafię je uargumentować - np. zróbmy tak i tak, to będzie lepsze separation of concerns (a jakie korzyści płyną z "lepszego SoC", też mógłbym odpowiednio uargumentować oczywiście).
Jednak często jest tak, że widzę jakieś istniejące rozwiązanie i czuję, że to je*nie. Nie mam 100% pewności, tylko raczej wynika to właśnie z doświadczenia - albo widziałem podobne rozwiązania, które okazywały się słabe, albo sam kiedyś robiłem dane rozwiązanie. Czyli na podstawie albo czyichś błędów albo swoich widzę, że dane rozwiązanie mi się nie podoba. I w teorii może ono ładnie wyglądać (niczym program wyborczy niektórych partii), ale w praktyce widziałem podobne i okazywały się one pomyłką.
LukeJL napisał(a):
Jednak często jest tak, że widzę jakieś istniejące rozwiązanie i czuję, że to je*nie. Nie mam 100% pewności, tylko raczej wynika to właśnie z doświadczenia - albo widziałem podobne rozwiązania, które okazywały się słabe, albo sam kiedyś robiłem dane rozwiązanie. Czyli na podstawie albo czyichś błędów albo swoich widzę, że dane rozwiązanie mi się nie podoba. I w teorii może ono ładnie wyglądać (niczym program wyborczy niektórych partii), ale w praktyce widziałem podobne i okazywały się one pomyłką.
No to jest twardy orzech do zgryzienia.
Bo pytanie czy faktycznie masz rację, że to jest gorsze rozwiązanie i nie potrafisz tego ubrać w słowa (często tak mam); czy po prostu to niemerytoryczny argument, i powinieneś zostać przeargumentowany.
Ciężka sprawa.
sztadii napisał(a):
Najlepsze jest to, że często takie osoby nie mają argumentów czemu ich rozwiązanie jest lepsze.
Często takie osoby nie mają konkretnej odpowiedzi i mówią "według mojego doświadczenia to będzie się spisywać lepiej"
No ale "porządni" seniorzy używają tego samego rozumowania, na samym 4p tematy zazwyczaj kończą się przepychanką argumentami "robiłem tak fafnaście lat temu, jak byłem u Niemca w projekcie, na szczęście wyrosłem z tego" albo "ludzie w technologii X już dorośli do tego, że to zły pomysł, ale najwyraźniej w technologii Y jeszcze chwilę im to zajmie". Do tego trochę dowodów przez oczywistość i jakiś niszowy filmik z YT pod tytułem "X ssie, więc najlepiej zmień język na funkcyjny Y i użyj Z". Mechanizm jest ten sam, po prostu jak się zgadzasz z argumentami, to nazywasz kogoś "porządnym seniorem", a jak się nie zgadzasz, to "seniorem debilem", ale aspekt merytoryczny ma niewielkie znaczenie.
@Afish: tak trochę z boku - w szeroko rozumianym procesie wytwarzania programowania jest dużo pomysłów, które na papierze wyglądają świetnie (a więc nie da się ich storpedować w dyskusji), ale w prawdziwym świecie już się nie sprawdzają - i właśnie wtedy doświadczenie pomaga. Np. kiedy widzę dowolne, cudowne rozwiązanie klasy enterprise, które "w łatwy sposób pozwoli każdemu użytkownikowi biznesowemu wyklepać interesujący go proces" to mogę widzieć twarde dowody w postaci prezentacji - a i tak wiem, że gdzieś tam pod spodem jest szambo, które wybije po kilku miesiącach.
@wartek01: Zgadzam się, tylko odnośnie czego to jest? Przecież 10 lat temu wszyscy "dobrzy seniorzy" propagowali Springa czy JEE, które teraz jest mocno krytykowane na tym forum i który pewnie nazywasz "szambem, które wybije po kilku miesiącach". To jest po prostu trend, jeżeli senior jest w tym samym trendzie, co Ty jesteś, to będziesz go traktował jako dobrego specjalistę, a jeżeli on jest w innym trendzie (niezależnie od tego, czy to jest trend z przeszłości, czy może właśnie coś, co dopiero za dwa lata chwyci), to będziesz go krytykował.
Owszem, nie ma nic gorszego.
Jest jedna rzecz bardziej denerwująca, PM-debil.
Niestety, kazdy PM to debil.
renderme napisał(a):
Owszem, nie ma nic gorszego.
Jest jedna rzecz bardziej denerwująca, PM-debil.
Niestety, kazdy PM to debil.
Co innego być debilem, a czymś innym jest być nietechnicznym.
renderme napisał(a):
Owszem, nie ma nic gorszego.
Jest jedna rzecz bardziej denerwująca, PM-debil.
Niestety, kazdy PM to debil.
Niestety taka rola poganiacza - poganiać. Dlatego będąc pm / sm czy innym tworem, można zapomnieć o posiadaniu kolegów w pracy :D
U mnie w jednym zespole był Senior z kraju słynnego z outsourcingu, nic nie szło do niego przetłumaczyć, potrafiłem mu coś tłumaczyć pół dnia, odpowiadał "yes", "yes", a i tak zrobił po swojemu. Potem już nie miałem siły mu nic tłumaczyć. Mimo 15 lat expa z programowania wolałbym właśnie robić z jakimś Juniorkiem po Bootcampie, bo przynajmniej rozpisalbym mu co i zrobił review. Temu Seniorowi właśnie z racji stażu nawet uwagi nie mogłem zwrócić. No masakra była powiem Wam. Najgorsze było to że nietechniczny PM uważał że ten Senior ma rację xd to że w międzyczasie 2 ludzi się zwolniło i przyszło to nie brał pod uwagę że to przez tego gościa. Review ciągnęły się tygodniami, metody po 100 linii kodu, wszystko w jednej klasie.
Od tej pory jak tylko słyszę że mam pracować z tego typu ludźmi to zapala mi się pomarańczowa lampka w głowie i mruga pulsacyjnie.
dajcie spokój, już chyba za starzy jesteście żeby wierzyć w zbawienie świata(kompletny refactoring, twórcze spotkania w kuchni itd.). W życiu bywa różnie nie ma co sie rozwodzić nad problemami interepersonalnymi.
revcorey napisał(a):
dajcie spokój, już chyba za starzy jesteście żeby wierzyć w zbawienie świata(kompletny refactoring, twórcze spotkania w kuchni itd.).
No ale u mnie tak się dzieje że czasem cały projekt przechodzi metamorfozę. Z tymi twórzczymy spotkaniami to jednak różnie bywa ;D
@wartek01: Jeżeli wiesz, że gdzieś pod spodem jakiegoś rozwiązania jest szambo, to powinieneś być w stanie przełożyć to na argumenty. Nie tylko, żeby przekonać zespół, ale też, żeby przekonać siebie. Wiadomo, że na prezentacjach wszystko wygląda fajnie, a z drugiej strony każdy kiedyś się wpakował a jakąś świetną technologię, która później tworzyła więcej problemów niż rozwiązywała. Tylko wtedy trzeba pomyśleć, jakie pytania należało sobie zadać wdrażając tę technologię. Z drugiej strony, nowe trendy pokazują się dlatego, że poprzednie podejście miało jakieś wady, albo nie było w stanie przeskoczyć jakiegoś progu.
Ostatecznie mamy masę różnych technologii, które wydawały się dziwaczne i działające jedynie na papierze:
W każdym z tych przypadków, pewnie większość programistów "miała przeczucie", że cos nie ma prawa działać, ale znaleźli się też tacy, którzy dostrzegli korzyści, przeanalizowali swoje wątpliwości i wygrali na tych zmianach.
Jeżeli ktoś robi jako ten senior, architekt, to zwyczajnie musi zderzać swoje pomysły z krytyką. Przykładowo, obejrzałem sobie prezentację o lambdach, serverless itd. Jestem na endorfinowym haju i widzę same pozytywy tej sytuacji, to gadam ze znajomymi, zespołem co o tym sądzą i zaczynają się pokazywać pytania typu "niby fajne, ale czy to naprawdę działa?", "jak zapanujemy nad kodem", "skąd się dowiemy, która funkcja ma błąd", "jak to będziemy testować", "co właściwie w naszym przypadku wniesie takie podejście" i albo jestem w stanie na te argumenty odpowiedzieć, albo nie.
Dyskusja na poziomie argumentów "obejrzałem prezentację i jest dobrze", "obejrzałem filmik na YT i tam jakiś masta ninja mówił, że to syf" nie ma sensu, bo czyjeś zdanie nie ma znaczenia dla faktów. W jaki sposób można dyskutować z argumentem "coś tu śmierdzi"? Przeprowadzić badania węchu?
Wątek z innej dziedziny, ale pasujący do tematu. Teoria Ewolucji - jej założenia były kompletną zmianą dotychczasowego postrzegania problemu, pojawiła się masa głosów "to musi być bzdura", ale pojawiła się też konstruktywna krytyka i udało się na nie odpowiedzieć, dlatego dzisiejszym konsensusem naukowym jest uznawanie hipotezy o wspólnym przodku za prawdziwą. Identycznie było z innymi przełomami, typu Teoria Względności, Heliocentryzm.
revcorey napisał(a):
Myślisz że ktoś w produkcie który jedną noga jest w maitanance zezwoli ci na miesiąc pracy byle to przepisać poczym od zera trzeba to przetestować? Wolą już to robić na nowszym produkcie. takie życie.
No oczywiście, że nie możesz zniknąć z projektu na miesiąc, żeby zrobić refaktor. Nie dlatego że nikt Ci nie pozwoli, tylko dlatego że to nie ma sensu.
Poza tym przepisać poczym od zera trzeba to przetestować, to też jest niepoprawne, bo nie możesz zacząć refaktoru jeśli nie masz testów na tym co refaktorujesz. Jak wprowadzasz refaktor bez testów, to ryzykujesz dużo bugów, nieodpowiedzialne.
Powinieneś najpierw otestować tą klasę; a kiedy masz już testy to wtedy refaktor jest łatwy, i nie powinien zająć miesiąca.
Ja bym prawodpodobnie spędził 30 minut dziennie, dodając codziennie 1-5 testów do takiej klasy. Jak już mam tam testy, to codzinennie spędziłbym 30 minut wprowadzając refaktory i boy scout rule.
Small test, small refactor, small test, small refactor, small test, small refactor, ad. infinitum.
I żaden PM-debil nie może Ci wtedy powiedzieć: "weź olej te testy, szkoda czasu". Możesz mu wtedy powiedzieć żeby się chędożył. Ty jesteś techniczny, on nie, więc Ty wiesz lepiej jak utrzymać projekt żeby nie był kosztowny.
@TomRiddle:
Odnośnie tech leadów. To jest osoba która powinna panować nad projektem, mieć wiedzę techniczną o nim i co więcej ustalającą z zespołem w jakim kierunku idziemy(bilbiotek itd.) ale nie być strict architektem. Bo później to się kończy tym że kod jest pisany kompletnie inaczej przez różne osoby, dokumentowany inaczej(o ile w ogóle) itd. Nikt nad tym nie panuje. Bez obrazy ale jak okręt nie ma sternika to później wychodzi bagno. Widziałem takowe projekty też poza IT. Nikt nad niczym nie panował a pojedyńczy inżynierowie niby wiedzieli najlepiej ale później się okazało że jednak nie.
No oczywiście, że nie możesz zniknąć z projektu na miesiąc, żeby zrobić refaktor. Nie dlatego że nikt Ci nie pozwoli, tylko dlatego że to nie ma sensu.
No i widzisz sam sobie odpowiedziałeś. Takich systemów w których nie ma to sensu na rynku c++ nie brakuje. Czasami niektóre moduły przechodzą zmiany i tyle.
Poza tym przepisać poczym od zera trzeba to przetestować, to też jest niepoprawne, bo nie możesz zacząć refaktoru jeśli nie masz testów na tym co refaktorujesz. Jak wprowadzasz refaktor bez testów, to ryzykujesz dużo bugów, nieodpowiedzialne.
Ja mówię o testach produktu przez testera a później grupę testerską. Bo raz że testy(ut itp.) nie wyłapią ci wszystkich błędów to dwa zwyczjanie firmy sie boją takich zmian ze względu na stary dobry sprawdzony slogan "Działa? To po co zmieniać", zaryzykujesz o setek tysięcy(milionów klientów) danej firmy że coś nagle przestanie działać?. Z reszta w projektach c++ to często najwyżej są UT(albo i nie) a testy wyższych rzędów to już bywa abastrakacja.
Powinieneś najpierw otestować tą klasę; a kiedy masz już testy to wtedy refaktor jest łatwy, i nie powinien zająć miesiąca.
mas rację otestowanie klasy z 5-8 tysiącami lini która nie nadaje sie do testowania i spięcie jej z resztą systemu to takie "just like that". Zrób testy refaktor będzie łatwy. A teraz bardziej na poważnie. Takie systemy wymygają niczego innego jak kompletnego przepisania, dyskusji i nadawania pewnego tonu prze tech leada.
Właśnie brak w temie tego fryzjea leade powoduje taki bajzel bo cugle puszczone i każdy sobie sterem.
Ja bym prawodpodobnie spędził 30 minut dziennie, dodając codziennie 1-5 testów do takiej klasy. Jak już mam tam testy, to codzinennie spędziłbym 30 minut wprowadzając refaktory i boy scout rule.
fajna historia w klasie która nie nadaje się do testowania bo to zwyczjanie nie możliwe. Dopiero jej rozbicie na mniejsze mniej zalezne/niezależne elementy da efekt(a już nie raz widizałem tak duże klasy z przyspwanymi do siebie elementami). My tu nie mówimy o paru klaskach z 4 publicznymi funkcjami których nie otestowano. A wielkim kleksie który zajmuje się wieloma zadaniami. I nadaje się tylko do przepisania co wpłynąć może też na resztę systemu.
Robi się ewolucję, a nie rewolucję.
Nie wszędzie się da nie robić ewolucję. podejście powinno być indywidualne do problemu.
I żaden PM-debil nie może Ci wtedy powiedzieć: "weź olej te testy, szkoda czasu". Możesz mu wtedy powiedzieć żeby się chędożył. Ty jesteś techniczny, on nie, więc Ty wiesz lepiej jak utrzymać projekt żeby nie był kosztowny.
Najprosciej, tym rządzi pieniądz nie developer. Ja już przpeychałem zmiany z klientmai na które później dawano 1-2 dni. I na tym kończono "bo wazniejszy bug operacyjny", i nie mówimy o produktach co mają rok tylko 20 lat. Świat nie jest czanro biały. Bez obrazy ale my mówimy często o kodzie który jest szambem a nie proejtkem który wystarczy po kawałku zmieniać i będzie ok.