Skąd w branży tylu słabych midów/seniorów?

solar napisał(a):

Pewnie żart, ale serio w programowaniu mam wrażenie że w Polsce ludzi na granicy introwertyka a aspergera jest nadreprezentacja.

Bo programowanie jest jednym z mniej stresujących zajęć (zarobkowych) dla introwertyka czy AS, a w dodatku jak ktoś woli nerdzić w piwnicy, niż chodzić na imprezki, to programowanie jest jedną z czynności, którymi można się zająć nie ruszając tyłka sprzed komputera lub ograniczając wychodzenie z domu do minimum. To aż się prosi o nadreprezentację :v

Zresztą, to widać po zespole - dopóki normalnie pracujemy, pogaduchy przy kawie w kuchni czy przy czyimś biurku są elementem codziennej scenerii. A wystarczy kilka spotkań jednego dnia czy długaśny planning z retrospekcją i wszyscy wyglądamy, jakby ktoś z nas spuścił powietrze, a i na pogaduszki nie ma się zbytnio ochoty :I

Największym szacunkiem za to byli zawsze darzeni ludzie, którzy znali obszar, czyli posiadali wiedzę na
temat tego co było przedmiotem programowania, oraz proces - czyli jak przepływają dane, co zachodzi na jakim etapie,
co z czym się komunikuje, itp. Ci, których pogardliwie uważacie za pseudo-seniorów,
którzy swój stopień otrzymali za wysługę lat, mogą w rzeczywistości dysponować ogromną
i dużo istotniejszą wiedzą niż znajomość technologii, tyle że ze swojej perspektywy nie dostrzegacie tego,
skupieni na technicznych szczegółach. I słusznie, bo nieznajomość technikaliów może (choć wcale nie musi)
zaowocować słabym (mało optymalnym, nieeleganckim) rozwiązaniem, ale nieznajomość obszaru i procesu nie zaowocuje niczym.

Samo posiadanie wiedzy nie wystarczy.

W tym jest własnie problem, że pseudo-seniorzy to ludzie, którzy może i dysponują jakąś wiedzą, ale nie umieją jej nikomu przekazać. Ani poprzez swój spaghetti kod, ani przez dokumentację (której nie ma, albo jest niejasna), ani nie da się z nimi dogadać, bo nie umieją tłumaczyć, przekazywać wiedzy (i stąd myślę, że wynika spaghetti kod - ludzie, którzy nie umieją jasno się komunikować i wyrażać myśli w sposób klarowny, będą tworzyć zwykle brzydki, nieprzemyślany kod, ponieważ kod jest pewną formą wyrażania myśli).

Gdyby chociaż mieli super miękkie skille i potrafili o każdym kawałku spaghetti kodu coś powiedzieć, i jakby potrafili mentorować juniorów w trybie ekspresowym, i jakby potrafili z każdy w zespole się dogadać... to byłaby inna rozmowa. Wtedy nawet jeśli kod byłby zły, to jakoś można byłoby sobie poradzić. Ale mam wrażenie, że jak programista pisze słaby kod, to tej umiejętności komunikacji też brakuje (i odwrotnie - ci lepsi technicznie programiści zwykle też lepiej się komunikują).

Czyli ile jest wart taki senior, który ma potężną wiedzę dziedzinową, ale nie umie jej nikomu przekazać, bo jego umiejętności komunikacyjne są zerowe, a technicznie też jest słaby i pisze spaghetti kod?

Wg mnie tacy ludzie są szkodliwi dla firm, bo powodują, że cały projekt wisi na włosku, i jest zależny od jakiegoś tam "seniora", co ma całą wiedzę i nikomu jej nie umie przekazać.

Miałem półtora roku doświadczenia komercyjnego, rok udokumentowany na pełnym etacie.
Pisałem pracę magisterską z mało mainstreamowego tematu w którym firma poszukiwała programisty.

Dostałem już po etapie technicznym feedback, co się rzadko zdarza, w feedbacku "zaskoczył nas Pan swoją wiedzą". Co w tym dziwnego jak pół roku pod okiem upierdliwego promotora tylko przegryzałem się przez takie tematy.
Ostateczna decyzja klienta negatywna. Wymagamy 3 lata doświadczenia komercyjnego, minimum 2. Brakuje panu pół roku.

Gdybym klepał pół roku dłużej formatki a z domeny był zielony to byłbym OK. Pół roku brakowało do do korporacyjnego sztywno ustawionego kryterium odpadam pod ostatecznej decyzji klienta.

Później feedback razy dwa prywatny i z rekrutacji, szukają dalej, za pół roku rekrutacja zgłasza się z pytaniem czy nie chcę jeszcze raz przejść całego etapu bo już mam wymagane 2 lata doświadczenia.

Korporacyjny beton

LukeJL napisał(a):

Samo posiadanie wiedzy nie wystarczy.

W tym jest własnie problem, że pseudo-seniorzy to ludzie, którzy może i dysponują jakąś wiedzą, ale nie umieją jej nikomu przekazać.

Widzisz.., problem polega na tym, że to jest 4-ta strona dyskusji, a dopiero teraz ktoś napisał pierwsze zdanie definicji tego kto to jest słaby senior! Wcześniej wszyscy tylko przyklaskiwali OP i sobie nawzajem, że tak, że słabi, że nie mają pasji, że to wina pierwszych bootkampów, i takie tam. To z czym wy się w zasadzie zgadzaliście? O czym była ta dyskusja, skoro dla każdego słaby senior może oznaczać coś innego? Ja z tej fali narzekań wyłowiłem, że może wam chodzić właśnie o poziom techniczny tychże seniorów, bo pisaliście o jakości kodu i znajomości technologii. Teraz, gdy podjąłem tą kwestię, okazuje się, że @LukeJL chodzi nie o wiedzę, a bardziej o zdolność jej przekazywania, umiejętności miękkie.

Jak dla mnie ten temat to w sumie jeden wielki Bait. Ktoś rzucił hasło, nie wyjaśnił o co mu chodzi, ale wszyscy się zgadzają, bo każdy ma jakąś ukrytą zadrę do jakiegoś seniora, albo do systemu, który ich wyniósł na swoje pozycje. W sumie w ten sam sposób politycy wodzą za nos tłum - "Polska w ruinie!" krzyczą, i wielu się zgadza, bo widzieli, że gdzieś tam cegła spadła.

Tak że, uważajcie, bo działanie na ślepo przed zastanowieniem się "po co robię", "co chcę osiągnąć", "czy rozwiązuję właściwy problem" - to są również cechy słabych seniorów.

Rzygać się chce od trolli z bootcampami...

Odnośnie tematu. Dlaczego midowie/seniorzy są słabi? Bo w pracy wymagana jest jedna, dwie technologie więc osoby nie uczą się nowych rzeczy (bo i po co). Prawdziwie dobrymi seniorami są pasjonaci, którzy często po godzinach klepią swoje projekty w różnych językach, spotykają się z wieloma innymi problemami, takimi, które w pracy przydarzają się niezwykle rzadko.

A że programujących rzemieślników (w tym ja) jest więcej niż osób z pasją programowania, to już inna kwestia.

Jest jeszcze jedna bardzo ważna rzecz, o której wielu z was zapomina tutaj. Umiejętności miękkie. Do pracy wolałbym przyjąć przeciętnego seniora, niż mega senior higher level który nie potrafiłby się dogadać z zespołem.

Garnek Bigosu napisał(a):

Miałem półtora roku doświadczenia komercyjnego, rok udokumentowany na pełnym etacie.
Pisałem pracę magisterską z mało mainstreamowego tematu w którym firma poszukiwała programisty.

Dostałem już po etapie technicznym feedback, co się rzadko zdarza, w feedbacku "zaskoczył nas Pan swoją wiedzą". Co w tym dziwnego jak pół roku pod okiem upierdliwego promotora tylko przegryzałem się przez takie tematy.
Ostateczna decyzja klienta negatywna. Wymagamy 3 lata doświadczenia komercyjnego, minimum 2. Brakuje panu pół roku.

Gdybym klepał pół roku dłużej formatki a z domeny był zielony to byłbym OK. Pół roku brakowało do do korporacyjnego sztywno ustawionego kryterium odpadam pod ostatecznej decyzji klienta.

Później feedback razy dwa prywatny i z rekrutacji, szukają dalej, za pół roku rekrutacja zgłasza się z pytaniem czy nie chcę jeszcze raz przejść całego etapu bo już mam wymagane 2 lata doświadczenia.

Korporacyjny beton

3 lata doświadczenia wymaganego a ty masz 1.5 roku. Może szukali po prostu kogoś wyexpionego a może kogoś kto umie czytać

@GutekSan: zakładając ten temat miałem w głowie obraz midów/seniorów posiadających małą wiedzę i umiejętności.
kilka rzeczy, które mi się przypominają:

• mieli problem z wzorcami. Jak już znali jakiś to stosowali go bez zrozumienia. Według mnie mid/senior widząc kawałek kodu powinien umieć rozpoznać jaki wzorzec został w nim użyty, a pisząc własny kod powinien wiedzieć dlaczego stosuje w nim dany wzorzec, a nie na siłę pchać wszędzie wzorce.
• duży brak wiedzy o optymalizacji
• nieprzyjmowanie innych(lepszych) rozwiązań - ich kod zawsze jest najlepszy, to inni nie wiedzą jak programować
• gubienie sie jeśli postawić takiego przed jakimś nowym zadaniem (tu wychodzi tak na prawdę niewielkie doświadczenie z róznymi projektami, znają tylko jedną ścieżkę i każde odstępstwo jest dla nich bolesne)
• zero samokrytyki
• w skrajnych przypadkach problem z obsługą systemu operacyjnego (pewien senior z Krakowa)

Pracowałem w różnych firmach, jedne miały swój produkt, który rozwijały od dawna inne firmy robiły krótkotrwałe zlecenia klientów, Braki wiedzy szczególnie były widoczne wtych długotrwałych projektach w których pracowąło wiele osób. Szczerze móiąc wolę pracować w zespole z ogarniętymi juniorami niż z seniorami czy z zmanierowanymi regularami. Sam mam kilka lat doświadczenia ale nigdy bym nie pomyślał zeby nazwac siebie seniorem, uwazam siebie raczej za doswiadczonego samodzielnego programistę.

Co do dzielenia się wiedzą, to w pierwszym poście nie poruszałem tego tematu, ale według mnie, ktoś, kto nie chce dzielić się wiedzą (nieważne czy potrafi to robić czy nie) nie zasługuje na tytuł seniora, Ale to jest chyba temat na osobną dyskusję.

Innym problemem jest "bucowatość" niektórych "seniorów". Przez sytuację na rynku mają napompowane ego do granic możliwości uwazajac sie za alfe i omege w kazdej dziedzinie. Niestety umiejętności interpersonalne wśród programistów wiadomo jak wyglądają. Nie chodzi mi tu o bycie ekstrawertykiem, bo i programiści ekstrawertycy potrafią być bucami (ale to już zupełnie nie temat tej dyskusji).

@Mały Ogórek

1. Wielu ludzi pisze poprawny kod mimo że nie wiedzą że taka czy inna konstrukcja jest "nazwanym wzorcem". Robią to "naturalnie". Wolę takie osoby niż juniora co umie mi wymienić wszystkie wzorce świata, a jak przyjdzie co do czego to nie potrafi zauważyć gdzie taki wzorzec pasuje a gdzie nie
2. Nie każdy musi się znać na wszystkim, a biorąc pod uwagę ile jest "mitów o optymalizacji" to nie wiem czy nawet nie wolałbym żeby ktoś nawet nie próbował, jeśli faktycznie sie na tym nie zna ;) Zresztą niewielki % softu to jakieś low-latency które wymaga specjalnych optymalizacji.
3. A moze faktycznie tak jest? ;) Nie raz widziałem zadufanych juniorów którym się wydawało ze "wiedzą lepiej", albo przeczytali post na blogu/posłuchali talka na konferencji i nagle chcą zmieniać świat i przepisywać system zgodnie z hype driven development. Są rzeczy których nie da sie "nauczyć" inaczej niż przed doświadczenie.
4. Pytanie czy to kwestia "gubienia" się czy wręcz przeciwnie? Taki junior to dopiero zna tylko jedną technologię i jedną drogę, a senior to jednak może mieć dylemat jak rozwiązać jakiś problem.
5. Obawiam się ze to nie kwestia mida czy seniora tylko podejścia.
6. Jak w punkcie 2 -> programista nie musi być ekspertem w dziedzinie IT support, devopsach czy adminowaniu :)

Prawdziwie dobrymi seniorami są pasjonaci, którzy często po godzinach klepią swoje projekty w różnych językach,

przy tzw normalnym zyciu i normalnej pracy (8h + 1h dojazd) wygospodarowanie 1h dziennie i utrzymanie tego na poziomie 60-70% (czyli uda się wygospodarować 6,7 h na 10 dni) to jest dużo
a ile zrobisz przez godzinę?
no i gdzie czas na inne rzeczy, chociażby uczestnistwo w tzw życiu społecznym, kulturalnym, duchowym (co kto lubi i woli)

wychodzi na to, że prawdziwy senior to robi bez opamiętania całe zycie, w pracy i po pracy, potem umiera, a w życiu miał tyle satysfakcji, że był prawdziwym seniorem i wszystko.

Niski poziom seniorów wynika z faktu, że nie byli na bootcampach.
Kiedyś tego nie było więc mają teraz braki u podstaw!

Powinny być bootcampy dla seniorów: Seniorze! Zostań prawdziwym seniorem!

@Shalom:

1. To prawda sam tak mam. Tez wolę kogoś kto potrafi więcej niż wymienić wszystkie wzorce z pamięci :) Ale chodzi mi o sytuację gdy koleś z kilkuletnim doświadczeniem próbuje wszędzie wcisnąć wzorzec, nieważne czy należy to zrobić, czy nie. A inny wręcz przeciwnie, tam gdzie by pasowało zastosować jakiś wzorzec to tego nie zauważają.

2. Źle się wyraziłem :) Miałem na myśli pisanie kodu bez jakis udziwnien i "potworków" gdzie na pierwszy rzut oka już widać ze to będzie mało wydajne.

3. Z mojego doświadczenia wynika ze jednak nie przyjmowali lepszych propozycji :) A co do zadufanych junioró to masz rację. JAk dla mnie to takich powinno sie od razu sprowadzac na ziemie albo wrecz pozbywac sie z zespołu.

4. Doświadczony programista postawiony przed jakimś nowym wyzwaniem będzie lepiej lub gorzej wgryzał się w problem. Taki zagubiony nawet jak w nowym zadaniu można wykorzystać rzeczy, któe robił 100 razy w swoim ulubionym projekcie to nie potrafi tego zrobić.

5. Masz rację, programistom brakuje samokrytyki

6. Nie musi, ale zrobienie paru podstawowych rzeczy w swoim laptopie nie powinno sprawiać mu problemu :)

Nie chce wyjsć na zrzede, bo trafiłem w swoim zyciu tez na dobrych specjalistów ale są oni w zdecydowanej mniejszości, niestety :( Z mojego doświadczenia wychodzi, że Kraków wiedzie niechlubny prym, w Warszawie czy Wrocławiu było lepiej. W Poznaniu pracowałem tylko w 1 firmie, więc nie mogę się za bardzo wypowiedzieć.

Ja mam trochę inny przypadek, chociaż trochę pokrywa się z tym co mówi @jarekr000000 w komentarzach na mikroblogu.

Chodzi o to, że nie pierwszy raz, gdy spotykam w pracy człowieka, ktory jest lepszy (tak z 2-3 razy) ode mnie w pracy (ba.. on jest najlepszy w firmie). W sensie ma więcej doświadczenia, szersze pole widzenia (np. poza programowaniem jest dobrym adminem), szybko wymyśla rozwiązania, do tego lepiej kuma biznes, reprezentuje firmę na spotkaniach, i często pół żartem pół serio jego słowa są święte.

A w rezultacie:

1. często task jaki ta osoba programuje to JEDNA funkcja, która ma 3-6 pętli które współdzielą 5-10 zmianych, a przede wszystkim dominuje ifologia
2. kodu nie dzieli na funkcje, chyba, że gdzieś się powtarza, ale to powtórzenie musi mieć z conajmniej 10 linii inaczej sam tego nie widzi
3. ale jeśli się powtarza to częściej woli zrobić klasę i rozszerzać to dziedziczeniem
4. klasa u niego nic nie ma wspólnego z programowaniem obiektowym, to po prostu namespace / worek na funkcje powiązane z jednym zadaniem
5. najwięcej logiki osadza w kontrolerach
6. kod jest nietestowalny, chyba, że testujemy w oparciu o wystawione endpointy
7. gdy poproszę o code review w punkcie 1. to mamy nieporozumienie, bo jego zdaniem kod który mieści się na jednym ekranie jest proszy do zrozumienia, i edycji
8. ciężko go przekonać do innych decyzji, bo cały czas czymś argumentuje (jak mówiłem gościu jest numerem jeden), np. że tak łatwiej gadać z bazą i co więcej gościu jest dumny z tego co robi (czyli dla niego to nie jest nawet dług techniczny)
9. ze względu, że jest coraz bardziej nietykalny dyskusje z nim naprawdę nie mają sensu
10. gdy zwalniałem się z firmy, ten sam gościu kod z moich ostatnich zadań przerabiał na swoją wersję (czyli wszystko spakowane do jednej funkcji)

Myślałem, że to wodrębniony przypadek, ale taka osoba to powtarzalne zjawisko, bo już 3 takie osoby spotkałem i każda w innej firmie.

Pierw myślałem, że ze mną jest coś nie tak, że może czegoś o programowaniu nie wiem, może zbyt arogancko do tego podchodzę, może to po prostu to wszystko wymaga czasu itp ale to niczym nie skutkowało.

Najchętniej wraz z wiadomością, że taka osoba wkracza do zespołu natychmiast chciałbym się zwolnić, ale ileż można? Dwa razy tak zrobiłem i moje CV wygląda gorzej.

Finalnie właśnie dzięki takim osobom rzygam kodem w pracy, przez co:

• mam większy dystans i obojętny stosunek do tego co robi firma
• jeśli można zrobić coś gorzej to robię gorzej
• jak można to pracuje zdalnie
• a po pracy mam więcej parcia do realizowania własnych pomysłów

Klapki na oczach, słuchawki na uszach i robota wre. Jak ludzie nie rozmawiają ze sobą, nie wymieniają opinii i doświadczeń, to jak mają się rozwijać.
Do rozwoju swojego i innych trzeba jakiejś inicjatywy, albo pytać jak coś zrozumieć/zrobić lepiej/inaczej albo pytać czy coś wytłumaczyć, podpowiedzieć.

yarel napisał(a):

Klapki na oczach, słuchawki na uszach i robota wre. Jak ludzie nie rozmawiają ze sobą, nie wymieniają opinii i doświadczeń, to jak mają się rozwijać.

A to jest ciekawy aspekt kulturowy. Praktycznie w kazdej firmie w polsce, gdzie pracowalem, pokoj programistow to permanentna dyskusja, przeklinanie. Dyskusje o dupie jak najbardziej, ale i dużo rzeczowych. Przy takim podejšciu ani daily standup ani retro nie jest potrzebne. Wiadomo co się dzieje.

Dla odmiany, w pewnych landach czasem aż się dusiłem. Miedzy 9 a 17tą jedyny tekst to: gdzie idziemy na lunch? Na lunchu troche sie gada, ale oderwane od kodu to już nie to.

Prawo popytu i podaży wszystko Wam tu wytłumaczy.
20 lat temu strony internetowe były toporne. W wielu firmach nie było komputerów bo po prostu nie były do niczego tak na dobrą sprawę potrzebne. Był mały popyt na programistów i informatyków bo nie byli potrzebni. Nie było wifi, nie było smartfonów, nie było chyba nawet laptopów. Nie było też komputerów bo ludzi nie było na nie zwyczajnie nie stać. Za dzieciaka na mojej klatce schodowej z 15 mieszkaniami był tylko jeden komputer. W dodatku bez internetu. Było to około 98 roku.
Technika poszła naprzód, komputery potaniały bo były zastępowane przez coraz to nowsze modele. Coraz więcej ludzi miało komputery, weszła neostrada i tak dalej.
Więcej ludzi w internecie= więcej potencjalnych klientów. No to wszystkie niemal firmy od kancelari prawniczych po lokalne zakłady fryzjerskie czy pizzerie zaczęły nagle potrzebować stron, banki nagle odkryły bankowosc internetową i zaczęły zgłaszać zapotrzebowanie na programy ją obsługujące. Dalej doszła oszczędnosc papieru podkręcona ekologią. Frirmie x w Gda bardziej opłacało sie wysłać maila ze sprawozdaniem do siedziby w Warszawie niż wysyłać je w formie papierowej kurierem. Potem doszły pierwsze telefony z kolorowym wyświetlaczem i internetem. No to mamy kolejny kanał dystrybucji reklam do odbiorcy. Potem weszły smartfony. No i nagle połowa firemek zaczęła potrzebować aplikacji.
Pojawiło się olbrzymie zapotrzebowanie na rynku skutkujące znacznym wzrostem zarobków, i to zapotrzebowanie wciąż wzrasta.

Dlaczego słabi midzi i seniorzy? Popyt i podaż.
Juz kiedyś szef Comarchu narzekał. na to że pracownik moze w połowie projektu rzucić wszystko bo mu konkurencja dała 500 złotych więcej na miesiąc.. Otóż jak ma się pracownika rozchwytywanego wszędzie to trzeba zrobić wszystko by go pozyskać i utrzymać. Bo kto inny go weźmie. Pracodawcy to wiedza, pracownicy to wiedzą. Jak sie robi projekt i widzi się że gdzieś ludzie z tymi samymi kompetencjami dostają więcej, to po prostu się pracownika awansuje, by nie dał dyla do konkurencji. Znajoma po 1,5 roku jest już mid testerem. Są branże gdzie po półtorej roku dopiero oferują UoP.

Ktoś tu wspominał o pasji do kodowania.
Na kij komu pasja do kodowania? Chyba jedynie pracownikom rosyjskich instytucji naukowych kodującym za około 1000 złotych na miesiąc w przerwie między prowadzeniem zajeć.. Pasja jest atutem gdy się oferuje gówniane warunki. Znacie ludzi pracujących dla pasji? Ja znam. Sektor kulturalny. Zarządzanie projektami kosztującymi setki tysięcy za jakieś 2500 netto. Muzealnictwo. Zarobki tak wysokie że trzeba dorabiać na kolejny etat jako publicysta/wykładowca/przewodnik. Nauczyciel, adiunkt. To są prace w których pasja jest atutem bo oczekuje się ze to pasja sprawi że będzie się dajmy na to jeździło na sympozja dotyczące danego tematu za własne pieniądze, zamiast powiedzmy pojechać na wakacje.
Dla wielu firm pasja nie jest atutem.
Lepszy niepasjonata co spokojnie będzie robił CRUDy niż pasjonata który może w każdej chwili znaleźć jakiś bardziej pasjonujący projekt. Bo pasjonata dający dyla= przestój projektu, dodatkowa rekrutacja, opcjonalne zawalenie terminu= straty, straty i jeszcze raz straty.
Myślicie że korpo które szuka programiste Javy będzie zależało na tym by ten po godzinach siedział i uczył się kodować mikroprocesory? Nie. Nie bardziej niż by doceniło naukę Japońskiego czy pszczelarstwo albo czytanie rosyjskich klasyków. Bo w tym korpo programować procesorów nie będzie. Za to wzrasta ryzyko że zostanie on podebrany przez np. Intela.

Wydaje mi się, że to jest problem szerszy niż IT, a mianowicie nieumiejętność konstruktywnej krytyki, oraz co gorsze, nieumiejętność przyjmowania krytyki. Mam wrażenie, że niektórzy ludzie nawet nie chcą dać się przekonać, że inne rozwiązanie może być lepsze niż ich i atak na ich rozwiązanie traktują jak atak na ich osobę

danek napisał(a):

a mianowicie nieumiejętność konstruktywnej krytyki, oraz co gorsze, nieumiejętność przyjmowania krytyki.

Tak jest, ja np. wiem, że jestem słaby, to chociaż staram się być sympatyczny :)

Ja usłyszałem "od wszystkich" w pracy, że żaden klient nie płaci za czysty kod, wzorce tylko za efekt końcowy jakim jest działanie danych funkcjonalności w wystarczającym czasie i nie ważne czy doprowadził do tego szlak z gówna czy ze złota. Refaktoryzacja, wzorce wprowadzane w wolnych chwilach są tylko po to by "nam" było łatwiej kiedyś zmieścić się w czasie z rozszerzeniem, dodaniem nowych funkcjonalności. Taką logikę wprowadza biznes, który woli mieć czasem coś działającego za 100% X w przedziale 100% A czasu jak super kod ułatwiający później rozbudowę ale za 150% X w przedziale 200% A czasu. Zgodzicie się?

Ja usłyszałem "od wszystkich" w pracy, że żaden klient nie płaci za czysty kod, wzorce tylko za efekt końcowy jakim jest działanie danych funkcjonalności w wystarczającym czasie i nie ważne czy doprowadził do tego szlak z gówna czy ze złota. Refaktoryzacja, wzorce wprowadzane w wolnych chwilach są tylko po to by "nam" było łatwiej kiedyś zmieścić się w czasie z rozszerzeniem, dodaniem nowych funkcjonalności. Taką logikę wprowadza biznes, który woli mieć czasem coś działającego za 100% X w przedziale 100% A czasu jak super kod ułatwiający później rozbudowę ale za 150% X w przedziale 200% A czasu. Zgodzicie się?

Jest jeden malutki problem z takim podejściem. Ciężko się zmieścić w czasie (i często budżecie) jeśli nikt przy projekcie pracować nie chce...

posłuchaj mnie uważnie, jutro o 19:45 masz samolot do meksyku.
Bilet wyśle Ci zaraz na e mail. Gdy wyjdziesz z lotniska pod czerwoną budką telefoniczną jest skrytka,
otwórz ją tajnym hasłem : hajduszoboszlo. W niej znajdziesz nowy dowód osobisty,
3000 pesos i kluczyki do mieszkania na przeciwko. Od dziś nazywasz się
Juan Pablo Fernandez Maria FC Barcelona Janusz Sergio Vasilii Szewczenko i jesteś rosyjskim imigrantem z Rumuni.
Pracujesz w zakładzie fryzjerskim 2 km od lotniska. Powodzenia,
zapomnij o swoim poprzednim życiu i pod żadnym pozorem się nie wychylaj,
zerwij wszystkie kontakty, nawet z obsługą klienta z polsatu.

Nawet jak ktoś będzie przy tym pracował, to taki zapuszczony projekt z czasem będzie generował coraz większe koszty i czas.

Dzisiaj team leader poprosił mnie o sprawdzenie kodu jednego kandydata. Kod nie trzyma się konwencji, logika biznesowa w kontrolerze API, UI zlepione na kolanie. Spytałem czy to na stanowisko juniora, okazało się że aplikuje facet z 20 letnim doświadczeniem...

bo często nazwa stanowiska oznacza przejście na inny poziom zarobków, zgodnie ze standardami firmy

Mały Ogórek
mieli problem z wzorcami. Jak już znali jakiś to stosowali go bez zrozumienia.
...
na siłę pchać wszędzie wzorce.

To akurat dobra taktyka. Ale dla juniora*. I niekoniecznie na produkcyjnym kodzie, lepiej jak takie rzeczy robi się w projektach do szuflady. Czyli popada się w obsesję i stosuje się wszędzie i na różne sposoby dany wzorzec, celem ćwiczenia, nauki, zbadania jego możliwości i ograniczeń. Wydaje mi się, że nie ma w tym nic niewłaściwego z perspektywy nauki.

Jednak fakt, że ludzie traktują produkcyjny kod jak swoją piaskownicę (to takie typowe: uczyć się na produkcji) już jest trochę niepokojący. Ludzie po prostu za wcześnie wchodzą w programowanie komercyjne, zanim opanują podstawy. I uczą się wszystkiego już na produkcji i w trakcie pracy (zamiast w domu).

Tak więc następnym razem jak zobaczysz taki kod, gdzie ktoś pcha na siłę wzorce, to będziesz wiedzieć, że ktoś po prostu uczył się na produkcyjnym kodzie. To trochę jak pisanie "k*rwa" na produkcji...

**przy czym uważam, że każdy jest czasem juniorem, nawet jakby miał 150 lat doświadczenia. Przez słowo junior mam na myśli fakt, że ktoś się uczy dopiero danej, nieznanej sobie, techniki *

Według mnie mid/senior widząc kawałek kodu powinien umieć rozpoznać jaki wzorzec został w nim użyty,

Czasem odpowiedź na to pytanie nie jest jednoznaczna. To trochę jak z interpretacją poezji. Poza tym, jak @Shalom napisał, takie rzeczy robi się często intuicyjnie, nawet bez wiedzy o tym, że ktoś taki wzorzec ktoś określił mianem "Bumbozytora Atencji" czy "Fuzyjnym Kodziwem".

duży brak wiedzy o optymalizacji

Za duża wiedza o optymalizacji to też błąd. Np. zakładanie pewnych rzeczy bez sprawdzenia. Np. "użyję techniki X, bo jest szybka" albo "nie użyję Y, bo jest wolne". Zamiast po prostu zrobić benchmark i zmierzyć czy coś naprawdę jest wolne/szybkie. I jak coś zamula, to się sprawdza, co dokładnie zamula. A ludzie nawet profilera nie użyją, tylko będą zgadywać, bo gdzieś przeczytali, że coś jest szybkie/wolne. Tylko na wszystko mają jedną odpowiedź np. "aplikacja webowa wolno działa? Użyję Reacta"

Jest tylu kiepskich, bo może być - ssanie na niektóre specjalizacje jest takie, że można być kiepskim a i tak da się znaleźć pracę bez specjalnego wysiłku.
Spora część rynku to software house gdzie liczy się, że działa. Godziny mają się zmieścić w wynegocjowanym budżecie koniec - testy, code review, refaktoring i inne takie fanaberie nie istnieją, bo to kosztuje a w krótkim czasie nie przynosi zysku. Problem w tym, że nic tak nie rozwija umiejętności jak code review robione przez doświadczonych kolegów, a zarząd jest zainteresowany marżą.
W PL stosunkowo trudno o ciekawe projekty (są, ale nie ma ich dużo) jeżeli się przez 10 lat pisze CRUD'y w tym samym frameworku, to o jakim doświadczeniu mowa?
Bańka na rynku pracy powoduje, że "seniorem" zostaje się po 3-5 latach pracy zawodowej, a firmy rozdają pagony chętnie, bo daje to złudzenie postępu i jest tańsze niż podwyżka.

Na pocieszenie - to nie tylko polska specjalność - senior z za wielkiej wody, spojrzenie w kod i "o, pierwszy servlet jaki widzę od 10 lat", "o, odwołuje się do singletona" i "o, ten singleton może mieć wiele instancji". Jak w każdym zawodzie są ludzie wybitni, są też tacy mniej wybitni. Z definicji tych drugich jest większość.

Słabi są dlatego allegro wróciło z Kotlina do Javy, a wykop z Ruby do PHP.
allegro.tech/2018/05/From-Java-to-Kotlin-and-Back-Again.html

@jarek wiem, że jesteś fanbojem kotlina, ale jawnie tam pisze, że w swoim głównym projekcie wrócili z pokorą do javy 10.

Wklejanie tego artykułu z allegro o tym że Java > Kotlin jest tak samo modne jak wklejanie Szeligi...

GutekSan napisał(a):

A ja na przekór wszystkim powiem, że wcale nie widzę żeby było tylu słabych midów/seniorów - wręcz przeciwnie. Może mam szczęście pracować ze zdolnymi ludźmi, a może tak naprawdę dokonujecie niesprawiedliwej oceny, kto jest dobry a kto słaby.

Możliwych wyjaśnień jest znacznie więcej. Chociażby - możesz tak uważać, bo np. możesz nie mieć właściwej skali porównawczej.

Wszyscy myśląc "dobry programista" mają od razu na myśli dobry kod, pisany z regułą sztuki, znają wiele technologii, mają całą dokumentację języka w głowie. Z mojego doświadczenia to wszystko są drugorzędne cechy. Kod w firmie jest zazwyczaj jedną wielką wypadkową - wystarczy zrobić git blame i okazuje się, że co druga linijka pochodzi od innej osoby, a efekt jest pisany na przestrzeni lat, podczas których zmieniały się oczekiwania. W kodzie końcowym, jaki by nie był, stosunkowo mało jest indywidualnych rozwiązań.

A czemu miałyby być indywidualne rozwiązania? Kod rozwijany przez ludzi dobrych, nawet jeśli ma wielu autorów, będzie trzymał poziom.

Największym szacunkiem za to byli zawsze darzeni ludzie, którzy znali obszar, czyli posiadali wiedzę na temat tego co było przedmiotem programowania, oraz proces - czyli jak przepływają dane, co zachodzi na jakim etapie, co z czym się komunikuje, itp.

Znajomość biznesu to jest jedna z kilku składowych, równie ważna jak znajomość technologii, umiejętność przekazywania wiedzy czy zdolność rozwiązywania problemów.

Ci, których pogardliwie uważacie za pseudo-seniorów, którzy swój stopień otrzymali za wysługę lat, mogą w rzeczywistości dysponować ogromną i dużo istotniejszą wiedzą niż znajomość technologii, tyle że ze swojej perspektywy nie dostrzegacie tego, skupieni na technicznych szczegółach.

Owszem mogą. Ale z dużo większym prawdopodobieństwem są "seniorami jednego projektu", którzy znają jedną technologię i jeden framework (najczęściej "firmowy"), a tak ogólnie, to nie daliby sobie rady z samodzielnym stworzeniem małego projektu od podstaw czy też przejściem rekrutacji do firmy, w której pisze się normalny kod.

Mjuzik napisał(a):

Prawdziwie dobrymi seniorami są pasjonaci, którzy często po godzinach klepią swoje projekty w różnych językach, spotykają się z wieloma innymi problemami, takimi, które w pracy przydarzają się niezwykle rzadko.

Żeby być solidnym seniorem wcale nie trzeba siedzieć po godzinach ani być jakimś tam pasjonatem, ci są odrębną grupą ludzi. Senior to nie jest ktoś, kto ma 20 własnych bibliotek open source, tylko umie właściwie wykorzystać dostępne narzędzia w celu realizacji zadań. Do tego wystarczy myśleć i skupiać się w pracy.

Mały Ogórek napisał(a):

Pracowałem w różnych firmach, jedne miały swój produkt, który rozwijały od dawna inne firmy robiły krótkotrwałe zlecenia klientów, Braki wiedzy szczególnie były widoczne wtych długotrwałych projektach w których pracowąło wiele osób. Szczerze móiąc wolę pracować w zespole z ogarniętymi juniorami niż z seniorami czy z zmanierowanymi regularami.

Właśnie tak! Praca z juniorami jest lepsza, bo ich można jeszcze nauczyć pisać porządny kod. Z seniorami się to nie uda.

Shalom napisał(a):

1. Wielu ludzi pisze poprawny kod mimo że nie wiedzą że taka czy inna konstrukcja jest "nazwanym wzorcem". Robią to "naturalnie".

Tak może robić bystry junior, który przypadkiem wynajdzie koło na nowo. Nie ma szans, aby tak robił senior - bo to by znaczyło, że żadnej książki ani artykułu z branży nie przeczytał.

2. Nie każdy musi się znać na wszystkim, a biorąc pod uwagę ile jest "mitów o optymalizacji" to nie wiem czy nawet nie wolałbym żeby ktoś nawet nie próbował, jeśli faktycznie sie na tym nie zna ;) Zresztą niewielki % softu to jakieś low-latency które wymaga specjalnych optymalizacji.

Nie trzeba pisać low-latency, żeby móc zabić wydajność. Nawet w tzw. prostych CRUDach istnieje szeroki zakres zbrodni, których można się dopuścić:

• encja (razem z całą bazą) i n+1 na twarz;
• ciągłe odpytywanie o niezmienne dane (które można spokojnie skeszować);
• tworzenie identycznych instancji obiektów w pętli zamiast wyniesienie ich przed pętlę (to potrafi kosztować gigabajty pamięci);
• deadlocki na asynchronicznym kodzie;
• transakcje z tablockiem wywoływane z wielu wątków na jednej tabeli;
• usuwanie zduplikowanych itemów czy naiwne przeszukiwanie listy zamiast użycia odpowiedniej struktury danych (tak, wielu programistów nie zna innej struktury niż lista tablicowa).

3. A moze faktycznie tak jest? ;) Nie raz widziałem zadufanych juniorów którym się wydawało ze "wiedzą lepiej", albo przeczytali post na blogu/posłuchali talka na konferencji i nagle chcą zmieniać świat i przepisywać system zgodnie z hype driven development. Są rzeczy których nie da sie "nauczyć" inaczej niż przed doświadczenie.

Tylko, że trzyletni senior nie ma wystarczająco dużo doświadczenia by odróżnić hype od sensownego rozwiązania.

4. Pytanie czy to kwestia "gubienia" się czy wręcz przeciwnie? Taki junior to dopiero zna tylko jedną technologię i jedną drogę, a senior to jednak może mieć dylemat jak rozwiązać jakiś problem.

Trzyletni senior może mieć co najwyżej dylemat którą skarpetkę założyć na którą nogę.

leksykonkieszonkowy napisał(a):

Ja usłyszałem "od wszystkich" w pracy, że żaden klient nie płaci za czysty kod, wzorce tylko za efekt końcowy jakim jest działanie danych funkcjonalności w wystarczającym czasie i nie ważne czy doprowadził do tego szlak z gówna czy ze złota. Refaktoryzacja, wzorce wprowadzane w wolnych chwilach są tylko po to by "nam" było łatwiej kiedyś zmieścić się w czasie z rozszerzeniem, dodaniem nowych funkcjonalności. Taką logikę wprowadza biznes, który woli mieć czasem coś działającego za 100% X w przedziale 100% A czasu jak super kod ułatwiający później rozbudowę ale za 150% X w przedziale 200% A czasu. Zgodzicie się?

Ja tam wolę 100% funkcjonalności dostarczyć w 70% czasu. Ale do tego trzeba pisać od początku porządnie, bo zaciągając dług technologiczny mieszczenie się w terminach udaje się tylko przez pierwszy kwartał.

Aventus napisał(a):

Dzisiaj team leader poprosił mnie o sprawdzenie kodu jednego kandydata. Kod nie trzyma się konwencji, logika biznesowa w kontrolerze API, UI zlepione na kolanie. Spytałem czy to na stanowisko juniora, okazało się że aplikuje facet z 20 letnim doświadczeniem...

No tak się 20 lat temu programowało, więc o co chodzi?