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.
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.
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.
- 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ł.
- 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).
- 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.
- 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ę.
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ł.