Gdzie jest ten mityczny rozwój - wnioski po pracy w korpo

Swego czasu chciałem się wbić w branżę - szukałem okazji w C# lub JAVA, dano mi szansę w C#, no to tak zostało.

W tzw samorozwój włożyłem trochę czasu i pieniędzy - nie chwalę ani nie żalę się, po prostu stwierdzam fakt (nie, nie żaden bootkamp)
Pracuję "od zawsze" w tzw. międzynarodowych korporacjach

Pracę programisty w korpo widzę jako odmóżdżającą pracę biurową - jak każda inna praca biurowa - bierzesz taska, robisz i tak mija dzień za dniem.

przykłady
Pierwsza praca była jaka była, nie ma co wybrzydzać, dali szansę, trzeba korzystać. Przeżyłem w niej w fascynację cpp i nadarzyła się okazja, chcą przepisywać z cpp na mikroserwisy w c#. Idę na rozmowę, bałem się części cpp, ale OK siadło chcą mnie. Cieszę się bardzo bo mam nadzieję, że rozwinę się technicznie.
Wiadomo pierwszy okres w firmie zapoznawanie się z systemem itd, potem rewolucja na górze i już nie robimy serwisów w C#. Wsadzili nas (nie ja jeden przyszedłem w celu przepisywania) w stary cpp. Byłem jednym z ostatnich gości. którzy zmienili pracę, z tych co przyszli w w/w celu, Niby fajnie ale na jakiś czas siłą rzeczy zatrzymany rozwój w technologii, którą sobie wybrałem.
Kolejna, na wstępie było ostre trzepanie ze współbieżności bo niby praca miała być przy systemie, który jest na to nastawiony itp, itd. OK dostałem się, po czym zostałem przydzielony do projektu, gdzie nie ma w ogóle współbieżności, ale nagle pojawili się klienci i trzeb było to dopasować/zintegrować itp itd. Przez cały okres nie napisałem nawet jednego asycn/await.
Inny przykład to już nie mój, a kolegi, jego zadania to było grzebanie w XML-ach za stawkę dev, bo do czasu do czasu grzebanie w XML-ach nie wystarczało, trzeba było coś zmienić w kodzie.
Jeszcze jedno to bazy danych - przez miesiące nie użyłem więcej niż select i to w celu troubleshootingu (czy dobre dane sa pobierane z bazy).

trochę wniosków

• przez forum przewinął się wątek - kolo ma 10 lat doświadczenia i nie umie napisać czegoś od podstaw. Ja się nie dziwię, ja w pracy się nie rozwijam, ja się zwijam. Mam problemy z utrzymaniem dotychczasowej wiedzy. Nic dziwnego, jak się z czegoś nie korzysta na co dzień, to się zapomina, Przez te (już) lata na pewno nie stałem się lepszym programistą. Lepszym pracownikiem korpo i owszem, ale tak sobie myślę, gdyby te lata zainwestować w inny zawód (mechanik, wykończeniowiec, spawacz itd) to pewnie byłbym technicznie sprawniejszym przedstawicielem innej profesji niż teraz jestem dev
• senior od juniora różni się stażem, wiedzą biznesową i znajomością systemu oraz odnajdywaniem się w środowisku pracy - a nie przede wszystkim umiejętnościami technicznymi
• do pracy w zawodzie deva nie trzeba mieć tej mitycznej pasji ani jakiś wrodzonych zdolności, predyspozycji
• mówi się, że szkoła zabija kreatywność - to ja powiem, praca zabija radość z poznawania nowości, przynajmniej u mnie, po co - i tak nie wykorzystam, zapomnę itp
• firmy nauczyły się ładnie mówić, dev chce rozwoju - będzie o nim słyszał i to dużo. U mnie były nawet jakieś badania satysfakcji, workszopy (jak to w korpo) aby koniec końców nic się nie zmieniło
• rozmowa wstępna a codzienne zadania (wymagania a praca) - przepaść, to jakby szukać biełaza do przewozu zgrzewki wody. Panda styknie, nie trzeba niczego więcej. Uważam że generalnie większość da sobie radę. Wątków o rekrutacji było mnóstwo, czy algo potrzebne czy nie, co ma być itp itd - jak ja patrzę na swoje to był to jedyny moment, gdzie w największym procencie korzystałem ze swojej wiedzy
• firmie tak na prawdę nie zależy na rozwoju pracownika, bo wtedy będzie bardziej niezależny, a nie bierny, mierny ale wierny bo nigdzie indziej roboty za tyle nie dostanie. Jak się rozwinie, to albo będzie chciał więcej, albo lepszą robotę, albo odejdzie. W jednej z korp były nawet dni na tzw samorozwój. Jak się zorientowali, że te dni były przeznaczone na przygotowanie do nowej pracy (bo praca w owym korpo to de facto 3 linia wsparcia, ślęczenie nad logami i drobne poprawki w kodzie), to owszem można było je wziąć, ale wcześniej trzeba było się chwycić prawą ręką za prawe ucho ale naokoło głowy

Jeśli ktoś ma inny pogląd, z chęcią poczytam, o ile zechce się podzielić

mussel napisał(a):

trochę wniosków

• przez forum przewinął się wątek - kolo ma 10 lat doświadczenia i nie umie napisać czegoś od podstaw. Ja się nie dziwię, ja w pracy się nie rozwijam, ja się zwijam. Mam problemy z utrzymaniem dotychczasowej wiedzy. Nic dziwnego, jak się z czegoś nie korzysta na co dzień, to się zapomina, Przez te (już) lata na pewno nie stałem się lepszym programistą. Lepszym pracownikiem korpo i owszem, ale tak sobie myślę, gdyby te lata zainwestować w inny zawód (mechanik, wykończeniowiec, spawacz itd) to pewnie byłbym technicznie sprawniejszym przedstawicielem innej profesji niż teraz jestem dev

Zawsze możesz iść na mechanika glazurnika itp. Tak naprawdę w pracy programisty chodzi o lekko zarobiony hajs. i im szybciej do tego dojdziesz, tym szybciej będziesz szczęśliwy.

• senior od juniora różni się stażem, wiedzą biznesową i znajomością systemu oraz odnajdywaniem się w środowisku pracy - a nie przede wszystkim umiejętnościami technicznymi

No tu się nie zgadzam. Senior code klepacz tak. Senior developer to człowiek, który poza umiejętnościami technicznymi (umiejętność pisania kodu to jest mało ważny szczegół) umie również pomóc młodszym kolegom. Umie znaleźć i wyjaśnić, dlaczego coś jest złe, jak zadbać o bezpieczeństwo aplikacji itp. Niestety z moje doświadczenia wynika, że jakieś 90% procent wyrasta na senior klepaczy.

• do pracy w zawodzie deva nie trzeba mieć tej mitycznej pasji ani jakiś wrodzonych zdolności, predyspozycji

Rzemiosło jak każde inne. Można wyryć na pałę. Ale jak chcesz być kim więcej niż klepaczem to już potrzeba trochę pasji i predyspozycji. To jak z szewcem (i każdym innym rzemiosłem) ten bez pasji będzie odwalał robotę beznamiętnie od 8 do 16, a drugie będzie umiał zrobić coś więcej. Np zaprojektować nowe buty, coś usprawnić itp.

• mówi się, że szkoła zabija kreatywność - to ja powiem, praca zabija radość z poznawania nowości, przynajmniej u mnie, po co - i tak nie wykorzystam, zapomnę itp

No to jak ci się nie podoba taka praca to otwórz swoją firmę itp itd. Albo zostań artystą.

• firmy nauczyły się ładnie mówić, dev chce rozwoju - będzie o nim słyszał i to dużo. U mnie były nawet jakieś badania satysfakcji, workszopy (jak to w korpo) aby koniec końców nic się nie zmieniło

Firmy chcą jak najwięcej na tobie zarobić. Większość korpo ma du.. twój rozwój i satysfakcję, bo i tak wiedzą, że w tej baraży za dwa lata będziesz pracował u konkurencji, bo ci da 100 pln więcej.

• rozmowa wstępna a codzienne zadania (wymagania a praca) - przepaść, to jakby szukać biełaza do przewozu zgrzewki wody. Panda styknie, nie trzeba niczego więcej. Uważam że generalnie większość da sobie radę. Wątków o rekrutacji było mnóstwo, czy algo potrzebne czy nie, co ma być itp itd - jak ja patrzę na swoje to był to jedyny moment, gdzie w największym procencie korzystałem ze swojej wiedzy

To jest coś, co próbuję rozwiązać od kilkunastu lat: po co ktoś robi wyj... w kosmos rozmowy, a potem lądujesz w pisaniu crudów.

• firmie tak na prawdę nie zależy na rozwoju pracownika, bo wtedy będzie bardziej niezależny, a nie bierny, mierny ale wierny bo nigdzie indziej roboty za tyle nie dostanie. Jak się rozwinie, to albo będzie chciał więcej, albo lepszą robotę, albo odejdzie. W jednej z korp były nawet dni na tzw samorozwój. Jak się zorientowali, że te dni były przeznaczone na przygotowanie do nowej pracy (bo praca w owym korpo to de facto 3 linia wsparcia, ślęczenie nad logami i drobne poprawki w kodzie), to owszem można było je wziąć, ale wcześniej trzeba było się chwycić prawą ręką za prawe ucho ale naokoło głowy

No ale praca programisty to może z 10% to pisanie nowego kodu. Reszta to debug, analiza, szukanie błędu przez 3 dni, bo zamiast == ktoś napisał = itp itd.

Pracowałem w swojej karierze w 3 firmach. W pierwszej i drugiej było bardzo dużo elementów o których wspominasz - człowiek wręcz się zniechęcał. Rok temu nastąpił czas na zmianę. Priorytetem był właśnie rozwój -> powiedziałem sobie, że nawet jeśli będzie trzeba zejść z pensji to na jakiś czas zejdę. Miałem dość tego, że aby się rozwijać to muszę siedzieć cały czas po godzinach.

Szukałem firmy produktowej takiej w której dba się o jakość i własny produkt a nie trzepie się zlecenie za zleceniem, że nawet nie wiesz jak system który pisałeś sprawuje się na produkcji bo już jesteś w kolejnym - a tak to często w kontraktorniach/software housach wygląda.

Przez ostatni rok miałem bardzo dużo interesujących zadań, rozkmin związanych z projektowaniem systemu czy modelowaniem. Wiele godzin w zespole spędziliśmy nad jakimiś Miro czy innym boardzie dyskutując o rozwiązaniach, które będziemy wdrażać. Wszystkie zmiany są starannie przemyślane, taski w pełni opisane. Mamy mocne code review, wysokie pokrycie testami. Jest czas w każdym sprincie na redukcję długu, usprawnianie procesów. Regularnie upgradujemy nasze serwisy do najnowszych dotnetów. Dlaczego o tym mówię? Bo nareszcie poznałem firmę i styl pracy, który mi odpowiada - nie ma tutaj tylko trzepania tasków a pojawiają się takie klimaty jak analiza biznesowa, wymyślanie nowych funkcjonalności, projektowanie domeny, testowanie A/B, robienie różnych POCów itp.

W zeszłych pracach głównie szukałem błędów przez kilka dni i tak od buga do buga. Aktualnie mogę powiedzieć, że po raz pierwszy spotkałem się, że jakaś firma nie okłamała na rozmowie mówiąc "większość czasu będziesz pracował nad nowymi funkcjonalnościami" bo tak w istocie jest.

Po tych paru latach wniosek mam jeden. Praca programisty != praca innego programisty. Identycznie jak w innych zawodach. Radzę Ci nie zrażać się i szukać tej Tobie pasującej. Tak jak ktoś wspomniał, pracę jest znaleźć bardzo łatwo, ale już dobrą pracę...

Zgadzam sie z OP w 100%.
W korpo z nowymi technologiami jest tak: lepiej cos zrobic i przepraszac niz sie zapytac.
Jesli nie masz na to szansy bo sie nie przebijesz to siedzisz na L3.

mussel napisał(a):

• przez forum przewinął się wątek - kolo ma 10 lat doświadczenia i nie umie napisać czegoś od podstaw. Ja się nie dziwię, ja w pracy się nie rozwijam, ja się zwijam. Mam problemy z utrzymaniem dotychczasowej wiedzy. Nic dziwnego, jak się z czegoś nie korzysta na co dzień, to się zapomina, Przez te (już) lata na pewno nie stałem się lepszym programistą. Lepszym pracownikiem korpo i owszem, ale tak sobie myślę, gdyby te lata zainwestować w inny zawód (mechanik, wykończeniowiec, spawacz itd) to pewnie byłbym technicznie sprawniejszym przedstawicielem innej profesji niż teraz jestem dev

Każdy na to cierpi, wiedza ulatuje, jak się zmienia dziedzinę, to zmieniają się też używane umiejętności i stare zanikają. Wątpię, żeby w innych zawodach było inaczej.

• senior od juniora różni się stażem, wiedzą biznesową i znajomością systemu oraz odnajdywaniem się w środowisku pracy - a nie przede wszystkim umiejętnościami technicznymi

To zależy od definicji "seniora", ale w wielu przypadkach masz rację. Senior inżynierii oprogramowania wcale nie musi być lepszy technicznie, za to pewnie lepiej ogarnia biznes i umie zarządzać ludźmi dookoła na poziomie technicznym. Senior technologii X jednak będzie o prostu lepszy w technologii X (a przynajmniej być powinien).

• do pracy w zawodzie deva nie trzeba mieć tej mitycznej pasji ani jakiś wrodzonych zdolności, predyspozycji

Pewnie, że nie. Programowanie to zwykłe rzemiosło, a programiści wcale nie są jakąś elitą intelektualną. Po prostu stawki są wysokie, bo płaci zagranica, a przez to wiele osób wpada w błąd poznawczy, że ten ich sukces finansowy jest spowodowany jakimiś nadzwyczajnymi umiejętnościami.

• mówi się, że szkoła zabija kreatywność - to ja powiem, praca zabija radość z poznawania nowości, przynajmniej u mnie, po co - i tak nie wykorzystam, zapomnę itp

Ja poznaję dla samej przyjemności poznawania, a potem dzielę się tym (blog, konferencje itp). Dodatkowo możesz pisać projekt na boku, ja mam taki, który rozwijam od ponad pięciu lat, nauczyłem się w nim więcej od niejednego projektu w pracy, daje mi sporo frajdy i widzę, że mogę tam wykorzystywać dużo zdobytej wiedzy. Oczywiście trzeba znaleźć taki fajny projekt i spędzić trochę czasu, ale nawet poświęcając 3 godzinki miesięcznie można mieć dużo radości.

• firmy nauczyły się ładnie mówić, dev chce rozwoju - będzie o nim słyszał i to dużo. U mnie były nawet jakieś badania satysfakcji, workszopy (jak to w korpo) aby koniec końców nic się nie zmieniło

Sporo devów tak naprawdę nie chce rozwoju. Ludzie nie czytają książek, nie chodzą na konferencje (albo chodzą tylko po to, żeby poimprezować i odpocząć od pracy), nie poszerzają warsztatu. Ale firmy mają budżet szkoleniowy i to naprawdę można fajnie wykorzystać, do tego jak się jest aktywnym, to można pisać bloga firmowego (chociaż lepiej własnego), można jeździć na konferencje z firmy (chociaż lepiej samemu), można robić meetupy, jest naprawdę dużo możliwości, tylko trzeba chcieć. Ludzie po prostu nie chcą.

• rozmowa wstępna a codzienne zadania (wymagania a praca) - przepaść, to jakby szukać biełaza do przewozu zgrzewki wody. Panda styknie, nie trzeba niczego więcej. Uważam że generalnie większość da sobie radę. Wątków o rekrutacji było mnóstwo, czy algo potrzebne czy nie, co ma być itp itd - jak ja patrzę na swoje to był to jedyny moment, gdzie w największym procencie korzystałem ze swojej wiedzy

Zgadzam się, niektóre rekrutacje pozwalają na pochwalenie się wiedza, ale w ostatecznym rozrachunku to i tak zazwyczaj ściema. Po prostu umiejętność przechodzenia rozmów rekrutacyjnych jest osobną umiejętnością, ortogonalną do umiejętności potrzebnych w pracy.

• firmie tak na prawdę nie zależy na rozwoju pracownika, bo wtedy będzie bardziej niezależny, a nie bierny, mierny ale wierny bo nigdzie indziej roboty za tyle nie dostanie. Jak się rozwinie, to albo będzie chciał więcej, albo lepszą robotę, albo odejdzie. W jednej z korp były nawet dni na tzw samorozwój. Jak się zorientowali, że te dni były przeznaczone na przygotowanie do nowej pracy (bo praca w owym korpo to de facto 3 linia wsparcia, ślęczenie nad logami i drobne poprawki w kodzie), to owszem można było je wziąć, ale wcześniej trzeba było się chwycić prawą ręką za prawe ucho ale naokoło głowy

No oczywistym jest, że jak pracownik się rozwinie, to będzie chciał więcej, dlatego firma musi mieć ścieżkę awansu i rozwoju. Jeszcze nie byłem w takiej, w której nie byłoby takich możliwości, zawsze rozwój był wspierany i nagradzany. Oczywiście z czasem zarobki na rynku przebiją zarobki w danej firmie i trzeba zmienić, to normalna sprawa, ale i na to są sposoby.

Jeśli ktoś ma inny pogląd, z chęcią poczytam, o ile zechce się podzielić

Moim zdaniem po prostu zderzyłeś się z rzeczywistością i tyle. Ja się nie rozwijam dla firmy, tylko dla siebie, a potem wykorzystuję te umiejętności do rozwoju swojej kariery (czy to przez zmianę pracy, czy to przez działania dodatkowe poza programowaniem), ale jednocześnie szukam możliwości rozwoju w firmie, bo to jest dobre dla obu stron. Próbowałeś zrobić grupę dyskusyjną w firmie? Prowadzić bloga? Zorganizować meetup? Iść na konferencję? Usprawnić jakiś proces w środku? Nie kupuję odpowiedzi "nie da się" — jak się nie chce, to się znajdzie wymówkę, ale jak się chce, to się znajdzie sposób. No a poza tym, to jeżeli rozwijasz się szybciej od innych, to zacznij to wykorzystywać dla własnych korzyści, a nie licz na firmę. Jesteś kowalem swojego losu.

Afish napisał(a):

Pewnie, że nie. Programowanie to zwykłe rzemiosło, a programiści wcale nie są jakąś elitą intelektualną. Po prostu stawki są wysokie, bo płaci zagranica, a przez to wiele osób wpada w błąd poznawczy, że ten ich sukces finansowy jest spowodowany jakimiś nadzwyczajnymi umiejętnościami.

praca programisty prawdziwie wymagająca wiedzy może być gorzej opłaca niż klepanie crudów w korpo

Sporo devów tak naprawdę nie chce rozwoju. Ludzie nie czytają książek, nie chodzą na konferencje (albo chodzą tylko po to, żeby poimprezować i odpocząć od pracy), nie poszerzają warsztatu. Ale firmy mają budżet szkoleniowy i to naprawdę można fajnie wykorzystać, do tego jak się jest aktywnym, to można pisać bloga firmowego (chociaż lepiej własnego), można jeździć na konferencje z firmy (chociaż lepiej samemu), można robić meetupy, jest naprawdę dużo możliwości, tylko trzeba chcieć. Ludzie po prostu nie chcą.

oni chcą wtedy kiedy dostaną jakiś certyfikat ;) bo chodzi o papierek a nie o wiedzę

No oczywistym jest, że jak pracownik się rozwinie, to będzie chciał więcej, dlatego firma musi mieć ścieżkę awansu i rozwoju. Jeszcze nie byłem w takiej, w której nie byłoby takich możliwości, zawsze rozwój był wspierany i nagradzany. Oczywiście z czasem zarobki na rynku przebiją zarobki w danej firmie i trzeba zmienić, to normalna sprawa, ale i na to są sposoby.

ja byłam w firmie gdzie rozwój tylko dla krewnych i znajomych ;)

mussel napisał(a):

• przez forum przewinął się wątek - kolo ma 10 lat doświadczenia i nie umie napisać czegoś od podstaw. Ja się nie dziwię, ja w pracy się nie rozwijam, ja się zwijam. Mam problemy z utrzymaniem dotychczasowej wiedzy. Nic dziwnego, jak się z czegoś nie korzysta na co dzień, to się zapomina, Przez te (już) lata na pewno nie stałem się lepszym programistą.

Bo praca nie jest szkołą programowania. Chcesz się rozwijać w programowaniu, to rób własne projekty w domu. Najprostszy sposób. A w pracy możesz się uczyć pracy w grupie, komunikacji, kreatywnego opieprzania się, przykrywania gówna papierkiem, zwalania winny na innych i innych soft skillsów.

przez forum przewinął się wątek - kolo ma 10 lat doświadczenia i nie umie napisać czegoś od podstaw.

Lata doświadczenia są ogólnie bardzo słabą miarą skillów programistycznych. Ludzie mylnie zakładają, że zależność skilla programistycznego od lat doświadczenia jest liniowa. Im więcej doświadczenia, tym więcej skilla. Tymczasem wydaje mi się, że jest bardziej tak, że ludzie wchodzą do pierwszej pracy, są juniorami, i tutaj faktycznie się rozwijają technicznie, natomiast jak ogarną te podstawy, to osiągają poziom "mida"(lepszego lub gorszego) i zostają w nim już na zawsze, bo jest to poziom wystarczający do tego, żeby pracować i robić taski.

Ogólnie więc w pracy chodzi o kasę, a nie o rozwój:

1. Myśle że warto rozumieć ze praca to nie jest zabawa w rozwijanie programistów. Firma musi na siebie zarabiać i często nowe technologie czy "fajne rzeczy" nie są kompatybilne z "zarabianiem pieniędzy". W praktyce często wrzucenie kilku ifów jako L3 przynosi firmie dużo większy zysk niż pół roku przepisywania systemu z frameworka X na Y. Niestety wielu programistów nie potrafi nawet myśleć w kontekście "systemu" (czyli czegoś co często wykracza poza samo oprogramowanie) a tym bardziej w kontekście "produktu" (czyli co i komu chcemy sprzedać i w ogóle po co).
2. Jeśli chcesz firmę która robi jakieś R&D czy cutting edge to musisz iść do takiej firmy. Musisz zrobić wcześniej rozeznanie i celować w konkretne miejsce. Zatrudniając się w losowym korpo nie dziw się że poprawiasz xmle. Piszesz o tym żeby zostać jakimś mechanikiem - spoko, ale weź pod uwagę że taki mechanik to moze projektować silniki dla ferrari ale może też robić u cytryna i gumiaka betonując przerdzewiałe progi w golfie 2. Sytuacja dokładnie taka sama jak u programistów.
3. Zgadzam się z tym co pisał @Afish, że często ludzie niby gadają o tym "rozwoju", ale jak przyjdzie co do czego to okazuje się ze wcale nie chce im się uczyc czegoś nowego.

W korpo stawia się bardziej na otoczkę biznesową. To czy osiągniesz tam sukces zależy od tego jak się w takiej otoczce poruszasz. Możesz być wymiataczem technologicznym, ale i tak będziesz miał mniejszą wartość niż "architekt" od klikania w confluenca, dla którego wyzwaniem jest napisanie hello worda. Niemniej ma przewagę, że umie rozmawiać z biznesem, rozumie go i się w nim odnajduję (czyt. confluency, ustalenia, miliony niepotrzebnych call itp). Dla firmy taka osoba jest bardziej dochodowa. Kod można napisać lepiej bądź gorzej i nikogo to nie będzie interesować (niestety). A rozmawiać z biznesem nie każdy umie/chce.

Ustalenia rekrutacyjne w korpo bardzo często są stworzone po to, żeby zachęcić potencjalnego kandydata. Stąd obiecuje się buzzwordy a potem wychodzi co wychodzi, czyli nic, Inaczej nikt nie brałby udziału w tych rekrutacjach. Firmy doskonale wiedzą jak działa ten mechanizm i są świadome, że w skali roku cały team może się przesiać bo ludzie odejdą. Nie szkodzi, przyjdą następni i jakoś to będzie. Prowadzenie projektów w korpo (przynajmniej w tych w których pracowałem) było zawsze słabe i pełne sprzeczności. Widocznie komuś się to opłacało.

Jeśli chcesz się rozwijać to jedyną sensowną drogą jest uzupełnianie wiedzy na własne kopyto po godzinach, czyli książki, własne projekty itp. No ale tutaj trzeba chcieć a więc mieć trochę tej mitycznej pasji;)

Kiedyś pisałem, że korpo jest dla wszystkich i nie dla każdego i nadal to podtrzymuje. Jak zrozumiesz, że praca jest od zarabiania pieniędzy a nie od zbawiania świata to nagle praca w takim korpo staję się znośna. Dla nich jesteś tylko zasobem i tak samo proponuje ich traktować. Robisz swoje, bierzesz hajs i do domu. Wszystkie korpo działają pardo podobnie i nie ma co się przyzwyczajać. To tylko biznes ; )

Mam dokładnie odwrotnie.

1. Zauważyłem, że gdy tylko weźmiesz na siebie coś cięższego, wykraczającego ponad codzienne problemy - to zaczynają do ciebie wpływać takie trudniejsze problemy. Wziąłem na siebie odpowiedzialność za optymalizację dosyć skomplikowanego kodu - zaczęły spływać do mnie zadania typu "napisz jakąś dokumentację o tym, jak mamy rozwiązywać takie problemy". Potem, kiedy narysowałem już odpowiednią ilość diagramów - zostałem "namaszczony", żeby ludzie w razie wątpliwości przychodzili z tego typu problemami do mnie. W końcu skończyło się, że klepanie kodu poszło bardzo w odstawkę, a głównie robiłem tylko CRy, diagramy i bywałem na spotkaniach - także stricte technicznych.
2. Tak, z pewnych rzeczy nie korzystałem - ale już w ramach tego, z czego korzystałem to musiałem się mocno wyskillować. Jak wychodziłem z ostatnich trzech projektów to mogę z czystym sumieniem powiedzieć, że nabyłem obycie (piszę "obycie" bo technologii było trochę, a tylko część z nich poznałem w stopniu zaawansowanym) z dwoma odmiennymi stackami przy których wcześniej nie pracowałem.
3. No i dodam jeszcze, że umiejętność pracy w korporacji to bardzo ważna umiejętność. Mam takie wrażenie (mogę się mylić), że w korporacjach bardzo łatwo utknąć na poziomie klepacza.

Rozwoju masz tyle ile sobie sam wyrwiesz. Jeżeli uważasz, że nauczysz się technologii idąc na kurs albo robiąc certyfikat to zapomnij. Weź kartkę, napisz sobie jakie projekty chcesz robić, rozpisz technologie jakie chcesz używać i rekrutuj się do projektów, których stack się pokrywa z tym co chcesz robić za rok, 2 lata, 5 lat.

Ja mam motywację do zrobienia historyjki bo aktywnie uczestniczę w tworzeniu jej specyfikacji i chcę sprawdzić czy dane rozwiązanie się sprawdzi w praktyce. Więc przy okazji uczę się do następnej pracy, ale za pieniądze mojego klienta. Oczywiście to nie jest 100% mojego czasu. W zasadzie jest to może 10%-30% mojego czasu pracy. Pozostała część to jest uczenie innych, jakieś ceremonie i nudne rzeczy. Ale nikt nie robi w pracy 100% tego co się lubi. Chciałeś zostać policjantem i ścigać złodziei, a wystawiasz mandaty za jazdę rowerem po chodniku.

Problem pojawia się wtedy gdy nie robisz nic związanego ze swoją pracą marzeń. Wtedy się tylko oddalasz i możliwe, że musisz podjąć poważną decyzję co do swojej kariery. Żaden manager nie zrobi tego za Ciebie.

Z moich doświadczeń wynika, że większość programistów nie chce się ani uczyć ani rozwijać jak przychodzi co do czego - chcą pracować od ósmej do szesnastej w technologiach ze swojej strefy komfortu, których już wcześniej się nauczyli i chcą za to dużo pieniędzy. Jest też spora część ludzi, którzy sądzą, że nowe technologie == nowa wersja języka lub update wersji frameworka na wyższy.

Poza tym, o najciekawszej i najlepiej płatnej robocie nie zdążysz się dowiedzieć z publicznych ogłoszeń. Do mojej obecnej firmy rekrutował mnie mąż mojej koleżanki z poprzedniej pracy, nie żebym miał łatwiej po prostu dowiedziałem się wcześniej. W moim zespole jest jeszcze jeden gość z mojego byłego korpo, w ogóle ogłoszenia nie było a skądś nagle wzięło się czterech typów i od czterech lat jesteśmy w takim samym składzie ;) Poluję też na miejsce w jednym projekcie w innej firmie gdzie pracuje mój znajomy, ale jak na złość nikt się stamtąd nie zwalnia od trzech lat :D

Wszystko to zależy od technologii i wielu innych czynników. Akurat jak trafiłeś do c++,to to co opisałeś wyżej jest raczej normą. Ta technologia w PL ma wybitnie nieprzyjemny rynek pracy. Gdzieniegdzie jest inaczej. Niektórzy piszą tyle kodu w np webówce w 3 miesiące co w c++ napiszesz przez dwa lata i wtedy codziennie się rozwijasz w programowaniu. Może być na odwrót (w każdym razie ja częściej widuje tamtą tendencje). Natomiast możesz trafić do projektu w którym będziesz się rozwijał na innej płaszczyźnie, np w AI, elektronice, matmie, telekomunikacji, zarządzaniu itd Zależy czego oczekujesz.
Osobiście jeżeli chodzi o korpo to się zgadzam. Regress umiejętności i wiedzy (widziałem to po rozmowach rekrutacyjnych po ucieczce z poprzedniej firmy). Jedynie potrafię się szybciej wdrążyć w syfski kod i struktury nowej firmy. Nie polecam nikomu, ponieważ bardzo niszczy psyche, ale jak się jest nowy w branży to bierze się co się ma.

Niemniej jednak korpo ma jedną zasadniczą cechę. Jak umiesz i mocno wdrążysz się w systemy firmowe to można się opierdzielać xD. Pamiętam niektórych testerów, którzy odpalali skrypty i yolo cały dzień, pogaduchy przy kawce, albo SM-a który siedział w pokoju i oglądal jak ogień się pali w kominku xD. 8h spotkań, gdzie musisz tylko słuchać i jak ktoś jest wyjątkowo bezczelny to sobie odpali nawet gierke i robi co chce. Taski które zrobisz w jeden dzień przy mocnej kawie robisz w tydzień i wszyscy mają wyrąbane na to, bo jesteś tylko malutkim trybikiem w wielkiej machinie. Jakby ktoś się zastanawiał dlaczego niektórzy siedzą w jednej firmie po kilkanaście lat. Idealne miejsce na to, aby zarobić, ale się nie narobić.
Korpo to pewien styl życia, albo go lubisz, albo nienawidzisz xd

Niestety tak samo to postrzegam po 7 latach pracy w IT. Szczególnie w korpo. To jest jakis stan umysłu. Plusem jest dużo wolnego czasu po odklepaniu taska i można w tym czasie się rozwijać samemu. Ja na przykład robie sobie na spokojnie jakies kursy na Udemy. Oczywiscie jezeli task jest przewidziany na cały sprint to najlepiej nie przyznawac sie nigdy ze zrobi sie go wczesniej tylko udawać ze robi sie go do ostatniego dnia. Mnie mówiąc szczerze bardziej męczy odpowiadanie Scrum Masterowi czy PMowi na daily na glupie pytania "jak status?" albo "na kiedy bedzie ready?" niż techniczna praca. Jeżeli task jest zaplanowany na cały sprint i nie zglaszam zadnych blockerów i dependency i mówię 2-ego dnia sprintu ze bedzie zgodnie z planem, to po kiego ch**a na nastepny i nastepny dzien pytaja sie mnie na kiedy bedzie? Jezeli mysla ze dzieki temu zrobie szybciej to sa w bledzie.
A nawet jezeli mialbym jakikolwiek problem techniczny to i tak na takim callu nie rozumie tego problemu technicznie i nawet opowiadanie jak i z kim go rozwiazalem mnie zniesmacza gdy po prostu wiem ze oni nie rozumiaja o czym mowie.

Ostatnio zaczalem nie uczeszczac na daily jezeli nie mam zadnych blockerow a praca innych osob tam obecnych jest niezalezna od mojej, bo mnie to zaczelo irytowac. Dołączam tylko dzien przed koncem sprintu lub gdy mam cos do powiedzenia - blocker, dependency, itd.

Na dodatek jakość tego co robia inne osoby w korpo i poziom techniczny jest mierny, nie ma tam rozwoju i w dodatku ta "atmosfera" scrumowa, gadka, zarzadzanie jira i excel jako najwazniejsza rzecz, poziom innych ludzi sprawia ze osoba niedoswiadczona nie jest w stanie tutaj nic sie nauczyc i ulepszyc jezeli sama cos nie bedzie klepac chociazby hello wordow na udemy.

Dobrze bylo to powiedziane przez kogos wyzej, ze bycie dobrym pracownikiem korpo ma sie nijak do bycia dobrym devem.

Szansa, że bedzie sie pracowac z ogarnięta i ambitna osobą w teamie od ktorej cos sie nauczy w korpo to jakieś 1% według mnie. Reszta to naprawdę MIERNI klepacze, niechcący się rozwijac i uczyc czy wyciagac wniosków - tacy, że wejscie z nimi w jakiekolwiek skomplikowane rozumowanie techniczne czy skomplikowany problem czy nie daj Boże kod refactoring jest horrorem i do niczego zwykle nie prowadzi.

Kiedyś mi się nudziło, więc wzialem fragment kodu "kolezanki" z zespolu, zrefaktorowalem jej fajnie i opisalem ze mozna to zrobic tak i tak i dziala lepiej w dodatku jest przejrzyste i zamiast 100 lini kodu jest 30 i zeby jak chce sobie na to popatrzyla i w przyszlosci warto to stosowac. Kolezanka powiedziala tylko "OK", po czym jej kolejne tego typu fragmenty kodu dalej wygladaja tak samo lipnie. Zwykłe lenistwo.

Na rozmowie technicznej często pytaja o ciekawe rzeczy i trzyma w miare poziom. Przez to wydaje sie ze moze tym razem praca bedzie ciekawa i trafi sie do ciekawego zespołu, ale niestety czar przewaznie pryska po miesiącu.

Niby praca dobrze płatna, w wiekszej czesci dnia bezstresowa (poza głupimi spotkaniami), ale mająca to coś co po prostu zniechęca mnie do właczania komputera z rana...

W pelni się zgadzam z autorem posta. Niestety gdyby nie nauka w domu to nadal bym nic szczególnego nie umiał. Praca niestety daje mi głównie hajs, a po godzinach ucze sie technologii pod mój "dream job". Zobaczymy, koniec końców wazne aby co miesiąc kasa na koncie się zgadzała bo w końcu pracuje aby mieć za co żyć :)

@ledi12:

ledi12 napisał(a):

W korpo stawia się bardziej na otoczkę biznesową. To czy osiągniesz tam sukces zależy od tego jak się w takiej otoczce poruszasz. Możesz być wymiataczem technologicznym, ale i tak będziesz miał mniejszą wartość niż "architekt" od klikania w confluenca, dla którego wyzwaniem jest napisanie hello worda. Niemniej ma przewagę, że umie rozmawiać z biznesem, rozumie go i się w nim odnajduję (czyt. confluency, ustalenia, miliony niepotrzebnych call itp). Dla firmy taka osoba jest bardziej dochodowa. Kod można napisać lepiej bądź gorzej i nikogo to nie będzie interesować (niestety). A rozmawiać z biznesem nie każdy umie/chce.

Ja stałem się takim architektem w korpo. Wcześniej oddałem swoją pańszczyznę developerską optymalizując programy i skrypty w javascripcie (bleh). Nie zgodzę się do końca - poziom absurdów na tych spotkaniach biznesowych, dziwnych pomysłów, niezrozumienia czegokolwiek technicznego od poziomu PM'a, PO, architektów, programistów, managerów jest tak duża i to jest taki poziom kopania z koniem się, że ktoś musi brać na siebie na klatę ten nadmiar bezsensownych spotkań, aby je filtrować i uprościć dla zespołu. Jakoś nie czuję potrzeby klepania hello wordów, zostawmy to wygodnym devom.

Też stoję na stanowisku, że jak chcesz się w pracy rozwijać to często jest taka możliwość. Jeśli tylko czekasz aż jakiś task do Ciebie spłynie to zostajesz klepaczem tasków. Jak potrafisz brać na siebie odpowiedzialność, wyznaczać kierunki i jesteś proaktywny to w wielu organizacjach będziesz dostawał ciekawe rzeczy do robienia. Ja szczerze mówiąc mam problem w drugą stronę - dzięki swojej proaktywności dostaję zadania ponad moje skille i ciągle się muszę uczyć. Relatywnie mało koduję za to robię kupę rzeczy w około.

Problemem jest brak specjalizacji, bycie programista Java czy C# ktory aktualnie jest takim parobkiem od wszystkiego w firmie to nie jest rozwoj, bo zazwyczaj w kazdej firmie będziesz robic nowe rzeczy ktore beda chcieli, np. frontend.

Zrób specjalizacje 3/4 lata w jakiejś waskiej niszy, dziedzinie to zobaczysz co to znaczy być specjalistą a nie kolejnym one-man-army w kontraktornii, któremu można kazać robic wszystko.

Przestań starać sie zbawiać swiat, dla firmy jesteś resourcem ktory dostaje hajs za robotę, tam nic nie ma wiecej. Zacznij myslec w ten sam sposob to lepiej Ci bedzie na glowie.

@kevin_sam_w_domu: ale bycie one-man-army ma sporo sensu, jeśli celujesz w funkcje architekta. Wtedy dobrze ogarniać zarówno frontend jak i backend, rozumieć procesy CI/CD itd. Gorzej jak dasz się wrobić w robienie wszystkiego na poziomie juniora i na przykład klepiesz CSS. Najłatwiej ocenić po wynagrodzeniu czy idziesz w kierunku multidyscyplinarnego specjalisty czy zapchaj dziury.

be the change you want

i guess

a coś zrobił aby to bagno poprawić / opuścić?