He has 10 years' experience but can't build anything!

I'd like to share a story of a dev (details I will hide cause he may be reading this).

Once upon a time, there was a dev who had 10 years of experience working in 7 to 8 big companies. He had the most impeccable resume. Worked with a stream of technologies. iOS Native, Angular, CI/CD, Flutter, ASP, AWS, Azure, Java... you name it, he had everything. He was not lying either. HR rang up most of his previous companies and they all spoke well of him.

We hired him and assigned him to a spanking new project. It's any developer's dream. We wanted to make sure the project will be done by the best. We tasked him to set up the initial commits, CICD pipelines, etc.

But surprise!

This guy can't build Sh$T!

He doesn't know how to start at all! 2 weeks pass and he wrote the amount of code of what a college grad would write in 3 days.

Management was furious and he was getting anxious. In his vulnerable moments, he opened up to a coworker. All this while he had only worked in big companies. Every year he would change jobs. His task was updating existing projects, never building anything new. The teams were big and his lack of coding skills was shielded by the scrum i.e. his experience was only in executing tasks and building upon other people's code. Eventually, he left.

Lesson's learned: "A guy can play to most awesome guitar riffs, but never compose a song of his own"
They are 2 different skills
Have you had any experience with someone like this?

Dość ciekawy przypadek i w sumie nie uważam że gość jest z definicji zły, bo nie ma się czasem wpływu do jakich projektów się wpadnie oraz "modern" development - narzędzia, best practices itd. bardzo szybko się zmieniają oraz generalnie maintenance to jest trochę inny skillset

chociaż z drugiej strony 2 tygodnie i nic sensownego?

co somdzicie kamraci

czy aż tak dziwne jest że doświadczeni devowie mają problem ze stworzeniem sensownych fundamentów projektu, czy może jednak jak ktoś trafi na utrzymanie, to może tak się stać?

Nie dziwiłoby mnie to gdyby przez te 10 lat siedział zakopany w starym utrzymaniowym projekcie. Ale skoro on zmieniał co jakiś czas projekty, to kurcze aż dziw bierze, chyba że gość ma taki talent do znajdowania projektów, w których nie musi się wykazać xD

Jestem w stanie wyobrazić sobie że ktoś wskakuje w istniejacy projekt i spokojnie przez lata moze nigdy nie widzieć jak sie setupuje coś od zera, bo nigdy się z tym nie spotkał. Dodatkowo taka osoba może też nie mieć zupełnie pojęcia o tym jak zaprojektować architekturę aplikacji, podzielic to jakis sensownie na serwisy czy dokonać jakichś decyzji "technologicznych", jeśli w poprzednich projektach to wszystko już było zrobione.
Tylko czy to źle? Jak budujesz dom to nie potrzebujesz żeby każdy pracownik to był inzynier projektant architekt, tylko trzeba też ludzi do układania cegieł według wyznaczonego planu.

Bo są różne fazy projektu - stawianie projektów to nie to samo co rozwijanie istniejących.

Jak wynika z tekstu, koleś miał 10 lat doświadczenia, ale w rozwijaniu istniejących projektów, a nie w stawianiu ich od nowa.

Jednak firma potrzebowała właśnie kogoś, kto postawi projekt od nowa. Więc zamiast zatrudnić kogoś, kto ma faktycznie takie skille, to zatrudniła pracownika dlatego, że miał akurat 10 lat doświadczenia i dużo technologii w resume. Geniusze rekrutacji :D

He doesn't know how to start at all! 2 weeks pass and he wrote the amount of code of what a college grad would write in 3 days.

Nie podoba mi się ta argumentacja. Tak jakby ilość kodu definiowało to, ile ktoś zrobił. Koleś pewnie się faktycznie nie nadawał na to stanowisko, tym niemniej sposób, w jaki to argumentują, nie ma wiele sensu. Przez 2 tygodnie można nie napisać wiele kodu, ale i tak poczynić duże postępy, choćby nauczyć się kilku potrzebnych do projektu technologii albo zrobić coś innego, co się nie przełoży na liczbę zacommitowanych linijek kodu.

2 weeks pass
...
Management was furious and he was getting anxious.

Jeśli zaledwie po dwóch tygodniach management już jest "furious", bo ktoś czegoś nie dowiózł, to znaczy, że patrzy bardzo krótkowzrocznie (tylko co będzie w najbliższym/kolejnym sprincie), co źle rokuje. Plus, że musiała być duża skala tej wściekłości, skoro udało im się zastraszyć pracownika ("getting anxious", "In his vulnerable moments").

Czyli koleś może i był słaby (przynajmniej w tym, co od niego wymagali), ale i firma musiała być koszmarna.

Inny zestaw umiejetnosci, utrzymywanie istniejacego kodu, czesto legacy, naprawianei bugow etc. czesto wymaga innych umiejetnosci niz postawienie czegos od nowa w dodatku w swiezych technologiach. Wiec to wcale nie musial byc lack of coding skills. Pytanie czemu na rozmowie nie pogadali o tym co bedzie robil ?

Do tego pisza ogolnie CI/CD -> z kazdym Cloudem pracuje sie inaczej, inaczej sie robie pipeline na Jenkinsie inaczej na Gitlabie, moga byc rozne polityki odnosnie security etc.

Brakuje szczegolow by to ocenic . Nike ma nic o dokumentacji i wymaganiach.

Szczerze mówiąc, to brzmi jak fail po stronie firmy - zatrudniają developera na stanowisko lead devopsa i się dziwią, że nie pykło. Może CTO jest do wymiany, skoro do tego doprowadził? Wielu programistów się brzydzi takimi rzeczami jak CI/CD czy monitoringiem. Większość seniorów by sobie nie poradziła.
Ja mam taką historyjkę, że kiedyś osoba na stanowisku Architekt się przyznała, że ona by nie wiedziała, gdzie zacząć. Więc mnie to nie dziwi.

To jest całkiem normalny przypadek. Po studiach trafiłem do korpo i tam praktycznie nie stawiałem niczego od zera- zastałem projekt i go utrzymywałem i rozwijałem, natomiast nie miałem zielonego pojęcia jak go postawiono i pewnie samemu trochę bym się namęczył żeby coś podobnego zrobić. Dzisiaj słowo programista jest bardzo pojemne (podobnie jak informatyk)- to może być gość w stylu devops, specjalista od jednego języka, który nie ogarnia setup-u projektów itp., ekspert od algorytmów itd. Niby każdy z nich potocznie zwie się programistą, ale jednego drugim nie zastąpisz tak łatwo.

Odwróćmy to w drugą stronę.
Macie pracownika, który też ma 10 lat doświadczenia. 8 firm. W każdej jest herosem od setupu CI/CD, webpacków, wymyśla architekture na już. Są w ogóle firmy, które tyle robią kopiuj wklej softu z dostosowaniem "reszty", że mają po prostu z rękawa wysetupowany projekt, który jedną komendą stawia wszystko i tylko czekasz i lecisz endpointy/podstrony (CRUD)
Albo nawet macie pracownika, który ma 4 lata doświadczenia... ale w jednej firmie jednym projekcie, w której coś tam zaprojektował.

Ale w żadnej z tej firm nie przeszedł calego lifecycle od 1 linijki do proda i wszystko co robi to kupa, bo zwalniał się po roku jak zaczęło się sypać w projekcie z powodu jego decyzji. Albo nawet miało to jakieś ręce i nogi, ale kompletnie nie wie "co się robi dalej" przy wdrożeniu, stabilizacji aplikacji, błędach na produkcji itd.

Dość ciężko znaleźć osobę, która ma w małym palcu projekt od A do Z, jest człowiekiem orkiestrą i zmierzyła się z problemami na każdym etapie tworzenia softu.
A nawet jeśli, to może się przecież zdarzyć, że stworzył 10 aplikacji od A do Z, ale były to na tyle małe, niewymagające aplikacje, że bez znaczenia co zrobił "byle działało", bo wyzwań zbyt wiele nie było i nigdy nie miał potrzeby zastanowić się co zrobił źle :)

Obstawiam, że jeśli ktoś nie trafił na początku do znienawidzonych software house'ów, to z początkiem a na pewno całym cyklem tworzenia oprogramowania na pewno się nie spotkał - czyli zdecydowana większość programistów.

Ja z kolei miałem taki przypadek. Koleś 7 lat doświadczenia zawodowego (praca w IT + licencjat IT). Trafił do nas jak szkielet projektu był już gotowy (z działającymi kilkoma serwisami, testami na których spokojnie mógł "bazować"), architektura/zależności udokumentowane, CI działa, nic tylko kodzić... . Przez kilka dni, codziennie po 2h z nim siedziałem i wszystko tłumaczyłem; następnie za każdym razem jak wyklepał tę parę linijek, zanim otworzył PR, to męczył żebym mu sprawdził czy wszystko OK - oczywiście nie dało się na to patrzeć, bo za każdym razem była to bezpośrednia próba przepisania tego co mówię do kodu, zamiast samodzielnego myślenia :(.

Przestałem się do niego odzywać (na szczęście on pracował zdalnie, więc łatwo to było osiągnąć). Jak rozmawiałem z Delivery Managerem, to przy okazji przyznałem, że release zapewne nam się obsunie, bo ten junior, którego wdrażamy ma spore braki w wiedzy i zmniejsza nasz velocity (wiedziałem, że ma więcej "doświadczenia" ale udałem, że ten fakt mi umknął). I tak udało się go dyplomatycznie "usunąć" :D

ktos dobrze napisal - gosc pracowal 10 lat ale nigdy nie na etapie powstawania produktu od zera tylko dodawania nowych funkcjonalnosci/utrzymywania, wiec sie pogubil. Jescze jak pracowal w korpo, gdzie od kazdego zadania jest dedykowany zespol-devopsowy, bazodanowy, frontentowy, backendowy i gosc siedzial w takiej firmie gdzie jest trybikiem
odpowiedzialnym ze jeden wąski kawalek kodu - tymbardziej sie nie dziwie.

Często rekrutrzy widząc 5-6+ lat doświadczenia myślą że kandydat jest bogiem. Imo po pierwsze źle go sprawdzili na rekrutacji, po drugie ja sam zawsze mówię że np. nie dotykam frontendu i mimo że pracowałem w technologiach x i y to bardziej na to patrzyłem niż tworzyłem, dlatego nie zatrudnił bym się w takiej firmie. Ogólnie jakieś 'miscommunication' poszło.
Podział zespołu na frontend, backend, devops itp. zawsze lepszy i mam wrażenie że jakoś tego coraz mniej.

Chdzk napisał(a):

ktos dobrze napisal - gosc pracowal 10 lat ale nigdy nie na etapie powstawania produktu od zera tylko dodawania nowych funkcjonalnosci/utrzymywania, wiec sie pogubil. Jescze jak pracowal w korpo, gdzie od kazdego zadania jest dedykowany zespol-devopsowy, bazodanowy, frontentowy, backendowy i gosc siedzial w takiej firmie gdzie jest trybikiem
odpowiedzialnym ze jeden wąski kawalek kodu - tymbardziej sie nie dziwie.

Proste - wtedy nie może być seniorem. Senior musi wiedzieć co się składa na cały cykl developmentu, być zainteresowany architekturą, musi chcieć dowiedzieć się jakie praktyki panują w innych teamach, musi wiedzieć o czym ma pogadać z tymi "dedykowanymi" osobami itp.

Jestem ciekawy ilu z seniorów danej technologii ogarnia całe SDLC projektu.
A może jest tak że to pracodawcy karmią nas wizją "zobacz, inni jakoś dają radę pracować na każdym etapie", bo po prostu chcą zaoszczędzić na rekrutacji.

Mam wrażenie że programistom łatwiej jest powiedzieć że ogarniają technologię X jeśli mają małe doświadczenie.
Szczególnie 5-6 letnim seniorom przychodzi to bardzo łatwo.
A managerom, PO, SMom tym łatwiej ocenić że ktoś sobie radzi lub nie-radzi - ignorance is bliss.

Programiści w małych firmach dają sobie wciskać CICD, cloudy, konteneryzację, security, monitoring, testy.
Potem albo zostają w IT, ale stają się nie-programistami albo się wypalają (i zostają np. piekarzami) albo przechodzą załamanie nerwowe (znam przypadek).
Część idzie po prostu do większej firmy gdzie nie trzeba być człowiekiem-orkiestrą.

I uwaga być może dla niektórych zaskakująca: można być seniorem Javy i nie ogarniać Istio, mTLS, optymalizacji query w MongoDB, Kafki, Sparka, Pandas, webpacka, PL/SQL itd.

Ani nic niezwykłego ani tym bardziej nie uznałbym tego czegoś za jakiś wstyd mimo że sam jestem z tych co budują i projektują całe systemy od 0. Jeśli ktoś całą swoją karierę siedział w maintenance albo na 3 linii wsparcia to raczej nie miał okazji brać udział w setupowaniu projektów, budowaniu pajpów, czy definiowaniu głównych wymagań pod elementy system. Czy to oznacza że takie osoby są gorsze? No raczej nie, są wyspecjalizowane po prostu w innej fazie życia systemu. Jeśli ktoś biega od korpo do korpo to niestety ale ma właśnie dużo mniejsze szanse że trafi do projektu który powstaje od 0, a wchodzi na jakiś etap gdzie system funkcjonuje. Z opisu wynika że zawalił proces rekrutacyjny który nie zweryfikował w żaden sposób czy kandydat ma odpowiednie doświadczenie by sprostać oczekiwaniom, a ktoś po prostu podjarał się liczbą lat expa i nazwami firm w CV :).

Jak biznes się rzuca, że nowy człowiek po 2 tygodniach od zatrudnienia nie działa na 100% to trzeba zmienić natychmiast biznes. Przecież w tym czasie nie da się ogarnąć co właściwie trzeba zrobić.

Ja przez 15 lat kariery byłem jeden jedyny raz w projekcie który zaczynał się od zera (pomijając tworzenie mikroserwisów które zakłada się przez copy&paste z poprzedniego). Nie mam zielonego pojęcia od czego teraz zaczyna się stawianie repo. Całe życie rozwijałem (nie utrzymywałem tylko rozwijałem, to są dwie rózne rzeczy) projekty które były rozkręcone na tyle że się budowały na CI. Przy czym nigdy w życiu nie spotkałem się z projektem w którym szkielet projektu i CI były zrobione według dobrych praktyk z dokumentacji gradle, mavena, springboota itd. Każdy jeden projekt był zawsze poklejony taśmą tak żeby pasował do jakichś dziwnych założeń. Najwyraźniej w żadnym przypadku te dobropraktykowe podejścia nia działały z jakiegoś powodu.

Uważam też że nauczenie się jak postawić od zera projekt na springboocie+gradle+CI według dobryk praktyk z tutoriali jest nieporównywalnie łatwiejsze niż wejście w projekt który ma już kilkaset klas i customowy sposób budowania i trzeba to najpierw zrozumieć. Zrobienie gołego projektu według dobrych praktyk to po prostu kopiuj wklej z tutoriala. Ja tego nigdy nie robiłem bo nigdy nie miałem takiej potrzeby więc nie potrafię tego zrobić z głowy, ale potrafię zrozumieć jak działa istniejący build z kilkoma powiązanymi jobami na teamcity i go usprawnić. Podobnie jest ze springbootem gdzie za pomocą konfiguracji można włączyć out of the box milion featurów wbudowanych w bibliotekę tylko trzeba wiedzieć co włączyć. Jakbym miał zrobić konfigurację springboota od zera to pewnie siadłbym na kilka dni i przeczytał dokumentację od A do Z żeby wiedzieć co włączyć. Potem nikt już tego nie tyka na wiele lat.

Nie wiem tylko czy przypadek z pierwszego posta to brak umiejętności tworzenia szkieletu projektu czy brak umiejętności kodowania w ogóle.

Teraz właśnie siedzę nad projektem porzuconym przez jakiegoś Pukesha rok temu z jednym releasem na produkcję, z niedziałającymi buildami na teamcity i próbuję to naprawić tak żeby dało się zreleasować wersję bez dziurawego log4j. Życzę powodzenia komuś kto umie stawiać projekty od zera :D

znam team leadów co znając jakąś konktrną technologię w embeeded TV a ogarniają yocto czy make tylko na tyle żeby edytować takie systemy budowania, albo zatrzymali sie na c++ pre 11. Wiedza domenowa ale fakt reszta kuleje ale zadania są popychane bo człowieczek wie jak je robić. Jak firma zatrudniła jednego gościa do stawiania całego systemu budownaia, CI itp. to są nie poważni, aczkolwiek mnie to nie dizwi. Do tego trzeba parę osób co się zadaniami i spostrzeżeniami będzie wymieniać. Ale wiadomo zapłacili za 10 exp. i oczekiwali one men army są tacy ale to też droga donikąd bo tylko jedna osoba ogarnia system a jak odejdzie amen.

@The Pontiff: https://start.spring.io/ -> i masz projekt w pare minut.

Btw. w wielu technologiach potrafie zmodyfikowac pliki ktore cos robia, badz zrobic nowe przez analogie (np. Terraform, Helm, Ansible) ale np. jakby ktos kazal mi na rozmowie napisac taki plik bez neta czy przykladu to mialbym z tym problem :P

Podzielam zdania niektórych przedmówców że to niekoniecznie źle. Trzeba tylko znać swoje mocne i słabe strony, i nie udawać. Są programiści którzy faktycznie świetnie sobie radzą w podejmowaniu tasków z tablicy i pracy z istniejącym kodem, podążając za ustanowionymi konwencjami i praktykami. Sam mam takich kilka w pracy i wiem że są to świetne osoby którym mogę powierzyć "feature work", podczas kiedy sam mogę się zająć bardziej architektonicznymi zajęciami. I taki model się świetnie sprawdza, bo to win/win dla wszystkich stron.

Czy od każdego należy wymagać aby po N lat doświadczenia był w stanie napisać system od zera? Moim zdaniem zdecydowanie nie. Jedyny problem jaki może być to jeśli taka osoba sama nie zdaje sobie sprawy z ograniczeń swoich umiejętności, lub co gorsza jawnie kłamie.

W cytowanej wypowiedzi nie jest jasne co tak naprawdę się stało- czy pracownik zatrudnił się jako osoba odpowiedzialna za architekturę, rozpoczynanie nowych projektów, czy może wystąpił błąd interpretacji po stronie pracodawcy, pogłębiony (lub też nie) przytakiwaniem lub bierną akceptacją pracownika.

Takie upraszczanie wszystkiego do "hur hur, 10 lat doświadczenia o niczym nie świadczy" jest z tej samej ligii co "hur hur archytekty nic nie umiejo" albo "hur hur, tytuły nic nie znaczo" i jest zwyczajnie prymitywne.

But surprise!

This guy can't build Sh$T!

He doesn't know how to start at all! 2 weeks pass and he wrote the amount of code of what a college grad would write in 3 days.

Management was furious and he was getting anxious. In his vulnerable moments, he opened up to a coworker. All this while he had only worked in big companies. Every year he would change jobs. His task was updating existing projects, never building anything new. The teams were big and his lack of coding skills was shielded by the scrum i.e. his experience was only in executing tasks and building upon other people's code. Eventually, he left.

Ale też dochodzi kolejny aspekt niezrozumienia.

Mianowicie jak sobie spojrzysz na dowolnie duży projekt, nie ważne w jakiej dziedzinie, to zauważysz że większość, 90-95% kosztów tego projektu nie leży w jego początkowej wersji, tylko w jego późniejszym rozwoju. Z tego powodu, doświadczony programista powinien obniżyć koszty rozwoju jak się tylko da; i nie dostarczanie nic-nie-wartego setupu po dwóch tygodniach się zalicza do takich rzeczy. Jaki jest sens dostarczać coś w 3 dni, tylko po to żeby pokazać że coś jest; jeśli po kilku miesiącach nagromadzi to tyle syfu że lepiej by było gdyby tego nie dodawać w ogóle? Lepiej dostarczyć w pół-dobry projekt po trzech miesiącach, niż g**no-warty projekt po tygodniu.

Poza tym, warto zauważyć że to nie ilość kodu jest wyznacznikiem tego czy coś jest dobrze zakodzone czy nie.

he wrote the amount of code of what a college grad would write in 3 days.

Mnie personalcie coś takiego irytuje, najbardziej w pracy komercyjnej, kiedy poświęcam czas żeby zrobić jakąś część kodu reużywalną i loosely-coupled, tak żeby była łatwa do utrzymania; i po miesiącu przychodzi inny programmer, i wykorzystując fakt że ten kodzik jest teraz taki łatwo zmienialny robi feature w 30 minut i management zachwycony "Ale szybko Ci się udało to zrobić", tylko że tym samym pogarasza jakość tego kodu, bo nie posprząta go poprawnie i nie dopisze testów na swoje zmiany (a może jeszcze i wywali moje, bo mu sfailują), także każdy kolejny feature będzie coraz wolniejszy.

Mnie personalcie coś takiego irytuje, najbardziej w pracy komercyjnej, kiedy poświęcam czas żeby zrobić jakąś część kodu reużywalną i loosely-coupled, tak żeby była łatwa do utrzymania; i po miesiącu przychodzi inny programmer, i wykorzystując fakt że ten kodzik jest teraz taki łatwo zmienialny robi feature w 30 minut i management zachwycony "Ale szybko Ci się udało to zrobić", tylko że tym samym pogarasza jakość tego kodu, bo nie posprząta go poprawnie, także każdy kolejny feature będzie coraz wolniejszy.

Ja to miałem w jednej firmie menadżerstwo oceniające projekty(binarki itp) po liczbie commitów tygodniowo, jak im spadły poniżej pewnej kreski w excel to rozpoczynały się programy naprawcze. Pewnie to samo w tym przypadku kreski w excelu się nie zgadzały. Chociaż pewnie prawda leży po środku.

A to projektu nie stawia się inaczej niż wpisanie fancy technologii w lini polecen w jhipster ( ͡° ͜ʖ ͡°) ?

to ja. Nigdy nie zacząłem niczego od nowa, zawsze wpadałem w rozwinięte projekty. Żyje się dalej. Ci z OPa tekstu zrąbali przy rekrutacji, chyba dość łatwo to było wykryć, że nic nowego nie budował?

TerazOdpowiemNaKomcie napisał(a):

to ja. Nigdy nie zacząłem niczego od nowa, zawsze wpadałem w rozwinięte projekty. Żyje się dalej. Ci z OPa tekstu zrąbali przy rekrutacji, chyba dość łatwo to było wykryć, że nic nowego nie budował?

No nie koniecznie. Nie wiemy jaki projekt dostał gość, i czy faktycznie postawienie początkowej wersji powinno zająć dwa tygodnie, mniej czy więcej.

Równie dobrze gość mógł robić wszystko porządnie, tylko management tego nie zrozumiał albo miał niepoprawne założenia; a gość nie umiał wytłumaczyć swoich decyzji. Mogli mu powiedzieć: "napisz mi kompilator TypeScript'a do assemblera", i gość po dwóch tygodniach mówi: "no wie Pan, jeszcze nie mam pierwszej wersji".

W Polsce Java Developer to taki wyrobinik od wszystkiego w wielu firmach. Znałem Java Developerow co po kontraktorniach robili wszystko, np. jeden 2 lata robił tylko infre w AWS (no ale Java Dev), spotkalem sie z gosciem co 7 lat pisal w firmie pluginy do Jiry w Atlassian SDK (no ale Java Dev), spotkałem goscia co się robil 5 lat tylko XML'e w banku (no ale Java Dev), goscia co 3 ostatnie lata robił tylko Angulara (no ale Java Dev), znałem goscia co tylko w Kotlinie robil (no ale Java Developer)

To tylko taki marketing. W rzeczywistości tych ludzi zatrudnia sie na stanowisku Software Engineer/Developer a to oznacza ze mozna im kazac robic wszystko, inaczej wylot, stąd branza IT to dziki zachod bo lata doświadczenia o niczym konkretnym nie mowia, stad tak ciezko zatrudnić kogos odpowiedniego na dane stanowisko.

To nie jest tak jak niszach, co sa specjalistami w wąskich dziedzinach gdzie zazwyczaj pokrywa sie 80 procent prac ktore robi sie w kazdej kolejnej robocie, mowie tutaj np. niszy typu Appian czy Tableau.

Co innego jest jak zatrudniam goscia co ma 5 lat expa jako Oracle Database Administrator (wiem że zatrudniam specjalistę w danej dziedzinie), a co innego gdy zatrudniam Java Developera, bo przez natłok bootcampow, chętnych ludzi, braku szacunku tego zawodu juz nie mozna nazwac specjalizacja jak C Developer, ponieważ Java Developerzy zaczeli się zgadzać po firmach robic wszystko i teraz jest jak jest, że okazuje sie ze ma 10 lat expa, ale nie wie co to Bean, bo wcześniej byl Analitykiem, Devopsem, ekspertem od DDD, Scruma, Portow i Adapterów, a Devem w 5 procentach (oby tylko).

To jest ogólnie dosyć ciekawy problem.

Kiedyś miałem okazję pracować z osobą, która zaraz po studiach trafiła do dużej firmy rozwijającej swój produkt i pracowała tam ~10 lat.
Kompletny brak podstawowych umiejętności - dosłownie nawet nie umiała sobie pobrać bazy danych z serwera, kompletny brak umiejętności korzystania z czegokolwiek czego nie używali u siebie, a jak to w korpo szeregowy klepacz nie ma dostępu do praktycznie niczego. Zupełnie odmienny przypadek od tego tutaj, ale faktycznie praca w dużych firmach upośledza pewne umiejętności. Jak trafi na osobę, która nie ma w sobie tej małej dozy ciekawości aby coś zgłębić samemu to korpo potrafi wyprodukować pracownika, który umie tylko 1-2 rzeczy.

Co do samej opisanej historii to akurat też mnie to nie dziwi. Wielu doświadczonych devów nie ogarnia devops i w sumie to chyba normalne, bo po coś te stanowiska się specjalizuje. Firma potrzebowała jakiegoś multidyscyplinarnego magika, który wie o wszystkim po trochu, a zatrudniła gościa, który pół życia przesiedział w korpo. Prędzej takiego znajdą w jakimś małym SH niz w korpo.

Nawet jak rozpoczynałem projekt od zera to miesiąc zajmowało mi dobranie technologii, pluginów itp. a co dopiero stworzenie calego projektu. i żebybu nie było jestem głupim, podkreślam glupim PHP devem, ale w miesiąc nie byłem w stanie stworzyć core całego projektu z okreslonymi wymogami. Okazywała się że to nie współpracuje z tym. Wymog X nie spełnia wymogu Y itd. Nie wybrażam sobie nawet Javy gdzie jak wszyscy tu piszą X zależy od Y łamane przez Z itd. A ro tylko badanie zależności. Mam wrażenie, że tu mamy do czynienia z krzywą Duninga-Krugera. Moze ktoś kto nie ma doświadczenia w 3 dni stworzy projekt, jednak potem okaze się, ze aby iść dalej trzeba zrobić refactor połowy projektu.

Warto jeszcze podkreślić, że organizacja organizacji nie równa. Oprócz stricte technologii istnieją jeszcze procesy, które potrafią ciągnąć się tygodniami. Pozwolenie na wydanie pozwolenia do wydania accessów, security itp. Szczególnie w banku. Zanim tam dojdzie do jakiegokolwiek planowania czegokolwiek od strony architektonicznej to pierwsze pół roku można się zakisić na g**no spotkaniach.

Trochę patologiczny artykuł. Ten koleś niby miał robić ten projekt jako One Man Army? A co z jakimis architektami, innymi developerami, wspolną kooperacją itd? Poza tym "setupowanie pipelinów" to czesto zadanie dev opsów a nie developerów robiących funkcjonalnosci biznesowe.

Co to za clickbaitowe copypasty z reddita, tu jest poważne forum