Juniorzy od brudnej roboty?

Cześć.

Jak było u was jak zaczynaliście pracę jako junior developer? Trafialiście od razu do utrzymywania brudnej roboty i dopisywania setnego "if" w "if", bo przecież junior to junior czy mieliście okazję naprawdę pracować w ciekawych projektach i rzeczywiście sporo się uczyć zanim awansowaliście na mid?

Zastanawia mnie bo nie wiem czy naprawdę mam pecha w pracy, czy juniorów traktuje się po prostu jako takie osoby od gaszenia pożaru?

Do pierwszej roboty poszedłem na studiach.
Główny dev powiedział do mnie "jeszcze pożałujesz że tu pracujesz " co trochę mnie zdziwiło. Jak się potem okazało najwięcej nauczyłem się jak w ramach stażu kazali mi wymyślić samemu jakieś WebAPI.
Rzucili mnie po tym do głównego projektu - typowe spaghetti:

• wrzucanie na master kodu który się nie kompiluje
• kategoryczny zakaz jakichkolwiek testów,
• brak jakiegokolwiek CI/CD + setki konfliktów i zamieszanie w zespole
• totalny brak frameworków, pisanie jakiś dziwacznych pseudo raw-sql rodem z najgorszych wykładów studenckich
  Można by tak wymieniać jeszcze dziesiątki linijek koszmarów, generalnie wracałem zażenowany i zapłakany z podejściem "ciesz się że masz pracę" i uczyłem się po godzinach, bo firma cofała mnie w rozwoju.

W nowym miejscu pracy aplikacje są profesjonalnie prowadzone: testy, dokumentacja, architektura wszystko dopięte na ostatni guzik.
Miałem sporo tasków, nauczyłem się naprawdę dużo i robiłem super postępy.
Po jakimś czasie jednak wiadomość z dnia na dzień, że mam się zajmować utrzymaniówką jakiś starych gruchotów, gdzie nikt nie ma pojęcia tak naprawdę jak to działa, więc wróciły koszmary z poprzedniej firmy. Zszokowała mnie ta decyzja, bo nie ustępuję w niczym innym juniorom w zespole i mam mega zapał do nauki. Niby rozumiem, że ktoś musi utrzymać stare próchno i zajrzeć do tego, z drugiej nie rozumiem czemu tak losowo niczym rzut kostką padło tylko na jedną osobę zamiast pokazać temat kilku juniorom żeby ogarniali co się dzieje w firmie. Przynajmniej każdy miałby równo wydzielone zadania, a nie że jedna osoba sprząta śmietnik, a reszta się bawi w najlepsze w najnowszych frameworkach. Średnio to znoszę psychicznie, bo mam wrażenie że znowu wróciłem do stanu z poprzedniego januszexu, gdzie po 8 godzinach rycia mózgu muszę uczyć się na własną rękę i siedzieć po nocach, podczas gdy inni robią kolosalne postępy przy projektach. Zdecydowanie wolałbym mieć życie prywatne niż przez jakieś dziwne zarządzanie w firmie siedzieć po nocach nad kodem, którego powinienem nauczyć się w pracy.

A jak było u was? Czy naprawdę zakuwaliście po nocach jako juniorzy i zanim znaleźliście normalną pracę to trafialiście od januszexu do januszexu?

Średnio to znoszę psychicznie, bo mam wrażenie że znowu wróciłem do stanu z poprzedniego januszexu, gdzie po 8 godzinach rycia mózgu muszę uczyć się na własną rękę i siedzieć po nocach

Ucz się w czasie pracy. Jak to turbo legacy to przecież nikt nie skontroluje tego co robiłeś

Rzucili mnie po tym do głównego projektu - typowe spaghetti:

Może to być dlatego, że gówniane firmy zatrudniają juniorów, bo im się to opłaca. Do konkretnej roboty najlepsi są seniorzy. Junior jest dobry jak:

• projekt jest gówniany i mało na siebie zarabia. Zatrudnianie kogoś bardziej opłacalnego po prostu się nie kalkuluje
• jest napisany w starych technologiach. Senior jest przydatny jak zna narzędzia, jak to jest jakieś turbo legacy to przepaść pomiędzy seniorem a juniorem jest mniejsza, bo obaj muszą się tego nauczyć
• legacy projekt. Ogarnięcie czegoś na logikę nie działa, może junior wolniej się nauczy jak to wszystko działa, ale jest dużo tańszy
• junior zazwyczaj ma większy zapał do pracy więc bardziej angażuje się do pływania w szambie.

JunDev napisał(a):

kategoryczny zakaz jakichkolwiek testów,

Nie rozumiem. Tzn. rozumiem brak testów projekcie. Rozumiem też skupienie się na klepaniu ficzerów i lekceważenie pisania testów. Ale kategoryczny zakaz jakichkolwiek testów? WTF trochę. Naprawdę aż tak mocno było, czy trochę przejaskrawiłeś? Tj. jak napisałeś testy, to ktoś się przypier*alał, że napisałeś testy?

JunDev napisał(a):

Niby rozumiem, że ktoś musi utrzymać stare próchno i zajrzeć do tego, z drugiej nie rozumiem czemu tak losowo niczym rzut kostką padło tylko na jedną osobę zamiast pokazać temat kilku juniorom żeby ogarniali co się dzieje w firmie. Przynajmniej każdy miałby równo wydzielone zadania,

Po co mieliby wdraża kilka osób zamiast jednej? To nie ma sensu, wszystkie muszą przejść ta sama drogę.

aa nie że jedna osoba sprząta śmietnik, a reszta się bawi w najlepsze w najnowszych frameworkach. Średnio to znoszę psychicznie, bo mam wrażenie że znowu wróciłem do stanu z poprzedniego januszexu, gdzie po 8 godzinach rycia mózgu muszę uczyć się na własną rękę i siedzieć po nocach, podczas gdy inni robią kolosalne postępy przy projektach.

A potem po tych kolosalnych postępach przychodzicie na forum i płaczecie jak dostaniecie w nowej pracy jako mid node 21 zamiast 22. Daj spokój, praca w legacy nie uwstecznia tylko ma inną specyfikę i cię nie ominie w tej branży.

Zdecydowanie wolałbym mieć życie prywatne niż przez jakieś dziwne zarządzanie w firmie siedzieć po nocach nad kodem, którego powinienem nauczyć się w pracy.

Tu masz przykład tego, że twoje interesy nie są zbieżne z interesami twojego pracodawcy. Ty chcesz zwiększyć swoją wartość na rynku pracy poprzez ekspozycję na nowe technologie. Oni potrzebują taniego ale w miarę ogarniętego deva do utrzymywania próchna.

Nie traktuj tego osobiście - oni nie robią tego, aby ci dokuczyć. Business i business. Myślę, że doskonale wiesz, jakie masz alternatywy, i wiesz też, jak wygląda rynek.

LukeJL napisał(a):

JunDev napisał(a):

kategoryczny zakaz jakichkolwiek testów,

Nie rozumiem. Tzn. rozumiem brak testów projekcie. Rozumiem też skupienie się na klepaniu ficzerów i lekceważenie pisania testów. Ale kategoryczny zakaz jakichkolwiek testów? WTF trochę. Naprawdę aż tak mocno było, czy trochę przejaskrawiłeś? Tj. jak napisałeś testy, to ktoś się przypier*alał, że napisałeś testy?

W zasadzie jak już doszukałem się do tego "ficzera" i dołożyłem kolejne 20 if-ów to push - wgraj na serwer i wszyscy zadowoleni. Dwa strzały z postmana czy API odpowie, jak odpowie to super, jak nie to trochę lipa.
Na testy był zakaz w firmie pod pretekstem "po co je pisać, klient zadzwoni że coś zepsuliśmy", w projektach nie było ani jednego testu jednostkowego/integracyjnego i nie wolno mi było utworzyć sobie w solucji projektu w xUnit na testy dobra beka . Nawet jak miałem czas i chciałem to przetestować to argumentem było "nie bo nie"
Coraz bardziej rozumiem posty że faktycznie zatrudnienie juniora po prostu się opłaca, bo doświadczony programista by to rzucił i poszedł do normalnej firmy

JunDev napisał(a):

"po co je pisać, klient zadzwoni że coś zepsuliśmy",

Spotkałem się z czymś podobnym, z tą różnicą, że nie czekało się na klienta tylko na QA. Programiści nie przejmowali się ani testami ani bugami (nawet jeśli zobaczyli gdzieś buga, to olewali), tylko czekali aż QA to zgłosi i założy im ticket.

Pomijając już skutek (zabugowane aplikacje, podwójna robota - skoro programista widział buga i nic z tym nie zrobił), to myślę, że takie podejście jest po prostu nieodpowiedzialne. Robić bezmyślnie coś i nie martwić się o to, co się wrzuca na produkcję (bo "klient zadzwoni")? A jeśli byłby to soft do sterowania lotniskami? Takie podejście mogłoby skończyć się globalną awarią. Ej, wróć, już tak było przecież niedawno xD

Obawiam się, że to, o czym Wujek Bob mówił, może się spełnić. Że programiści mający wyje*ane na jakość (bo przecież nie moja odpowiedzialność, ja tylko wykonuję polecenia) sami zaszkodzą temu zawodowi. Bo wcześniej czy później mogą powstać państwowe regulacje na temat tego, jak można pisać, jak nie. A programistów nikt nie będzie pytał o zdanie, skoro sami zachowują się jak dzieciaczki i nieodpowiedzialni robole, których trzeba pilnować na każdym kroku.

Problemem jest też to, że wiele programistów nie ma w sobie asertywności i ma mentalność robola, który musi robić to, co mu każą, żeby go nie zwolnili.

LukeJL napisał(a):

JunDev napisał(a):

"po co je pisać, klient zadzwoni że coś zepsuliśmy",

Spotkałem się z czymś podobnym, z tą różnicą, że nie czekało się na klienta tylko na QA. Programiści nie przejmowali się ani testami ani bugami (nawet jeśli zobaczyli gdzieś buga, to olewali), tylko czekali aż QA to zgłosi i założy im ticket.

Pomijając już skutek (zabugowane aplikacje, podwójna robota - skoro programista widział buga i nic z tym nie zrobił), to myślę, że takie podejście jest po prostu nieodpowiedzialne. Robić bezmyślnie coś i nie martwić się o to, co się wrzuca na produkcję (bo "klient zadzwoni")? A jeśli byłby to soft do sterowania lotniskami? Takie podejście mogłoby skończyć się globalną awarią. Ej, wróć, już tak było przecież niedawno xD

Obawiam się, że to, o czym Wujek Bob mówił, może się spełnić. Że programiści mający wyje*ane na jakość (bo przecież nie moja odpowiedzialność, ja tylko wykonuję polecenia) sami zaszkodzą temu zawodowi. Bo wcześniej czy później mogą powstać państwowe regulacje na temat tego, jak można pisać, jak nie. A programistów nikt nie będzie pytał o zdanie, skoro sami zachowują się jak dzieciaczki i nieodpowiedzialni robole, których trzeba pilnować na każdym kroku.

Problemem jest też to, że wiele programistów nie ma w sobie asertywności i ma mentalność robola, który musi robić to, co mu każą, żeby go nie zwolnili.

No właśnie to jest śmieszne, bo naprawdę takie podejście "byle coś wysłać" jest mega nieopłacalne. Ja osobiście ogromną wagę przykładam do jakości kodu, do tego żeby był on czytelny, wydajny no i przede wszystkim przetestowany. Doszło do takiego paradoksu, że początkujący gość (czytaj ja ) zaczął się upominać, gdzie są testy/sprawdzenie jakości/dokumentacja (co powinno być raczej egzekwowane przez doświadczonych programistów i opiekuna projektu), no ale zaraz mnie uciszyli, że tutaj tak już jest i tyle .

Mi się właśnie wydaje całkiem na serio, że teraz mamy pokolenie naprawdę ambitnych stażystów/juniorów, którzy chcą iść po jakość, wiedzę i umiejętności.
Praktycznie wszyscy moi znajomi (nawet jeśli zarabiają spoko kasę) to chcą zmieniać pracę w momencie, gdy firma totalnie olewa swoje projekty i nie widzi w tym żadnego problemu, bo klient i tak jakiś przelew zrobi, najwyżej kiedyś mu się wyda łatkę. Nawet jak mają chęć do nauki to w sumie i tak nikt nie chce wykorzystać ich potencjału.

Jak najbardziej rozumiem sytuację, gdy zatrudniają juniora i mówią uczciwie "słuchaj jest tutaj stary projekt, no niestety musisz zajrzeć, trochę się pomęczyć, ale trzeba o to zadbać", ale z drugiej strony to naprawdę dziwne jak firma tworzy jakieś nowe aplikacje i świadomie mają wywalone w jakość i nawet nie próbują się z tym kryć. Przecież to się nawet finansowo nie opłaca.

Słyszałem od kumpli o takich kwiatkach, że przykładowo masz luźniejsze dni w pracy nad aplikacją, to chcą na przykład zrobić refactor, dodać jakieś testy, sprawdzić wydajność i poprawić np. jakieś zapytania z bazy to dostają odpowiedź że w sumie po co, lepiej iść na kawkę, pogadać, pokręcić się na krześle, wypłata i tak będzie. Może zżerają mnie młodzieńcze ambicje, ale dziwnie się tego słucha.

JunDev napisał(a):

chcą na przykład zrobić refactor, dodać jakieś testy, sprawdzić wydajność i poprawić np. jakieś zapytania z bazy to dostają odpowiedź że w sumie po co, lepiej iść na kawkę, pogadać, pokręcić się na krześle, wypłata i tak będzie.

Mentalność kogoś zasiedzianego w jednej firmie. Problem w tym, że jak ktoś będzie chciał (albo musiał) zmienić firmę, to potem od razu ileś firm im odpada. Bo jednak w wielu firmach chociaż próbuje się wcielać dobre praktyki w życie. Nie mówiąc już o tym, że z takim mentalem ktoś pewnie nawet zwykłych frameworków nie ogarnia, bo po co.

I to są ci seniorzy z wiedzą juniora.

firma tworzy jakieś nowe aplikacje i świadomie mają wywalone w jakość i nawet nie próbują się z tym kryć. Przecież to się nawet finansowo nie opłaca.

citation needed

to dostają odpowiedź że w sumie po co, lepiej iść na kawkę

No bo jest lepiej iść na kawkę, dla tych ludzi w ich sytuacji życiowej w tym projekcie. Skoro wypłata i tak będzie, to czemu robić ponad miarę? Musisz zrozumieć ich punkt widzenia, on jest drastycznie różny od twojego. Jak już zrozumiesz ich punkt widzenia, to będziesz mógł odnieść to do twojego punktu widzenia. Jesteś ambitny, chcesz się uczyć, kasa nie jest dla ciebie najważniejsza, chcesz być dumny ze swojego kodu. Oni są dumni z tego, że cośtam nababrzą i będzie z czego zapłacić ratę hipoteki.

Jak dla mnie, wasze podejście do programowania jest nie do pogodzenia i jedynym wyjściem jest zmiana projektu albo firmy. Alternatywą jest wieczna frustracja.

Moje początki wyglądały dokładnie tak samo, dopiero po paru latach trafiłem do miejsca gdy liczyła się tylko jakość i team, ale ten okres nauczył mnie ogromnej samodzielności i tego ze każdy nawet najgorszy temat DOBRY dev potrafi wyprostować i pociągnąć. Przemęcz się, nie tylko ty robiłeś g**no w robocie zeby po pracy robić to co jest w twojej ocenie ciekawsze. Nie każda firma da ci dostęp do ciekawych projektów, a nawet jeśli każda to nie każdy projekt musi być ciekawy akurat dla ciebie. Gdyby nie przeszedł przez takie szambo uważam że nie byłbym dziś tak dobrym devem jak jestem.

Wyciągaj z takich firm jak najwięcej tj. ucz się złych i dobrych prakty, staraj się to przekładać na swój rozwój, reszta przyjdzie z czasem bo im lepiej poznasz złe środowisko tym lepsze wybierzesz następnym razem lub je stworzysz.

Próbowano mnie kiedyś wrzucić w takie bagno, bardzo szybko się zwinąłem.

Moja linia rozumowania była taka:

• Choć tam dobrze płacili i nie było stresu to jednak nie mógłbym tam zdobyć cennego doswiadczenia (wiadmo na rynku królowały wtedy AngularJS, NodeJS i MongoDB).
• Jest duże prawdopodobnieństwo że kolejna praca to było by takie samo G (bo już w tym pracowałeś)
• Nauczył bym się złych wzorców i nawyków (a wiadomo że oduczyć się jest trudniej niż się nauczyć)
• Ludzie byli jacyś tacy bez życia, szarzy...

Junior generalnie na początek dostatnie nędzne zadania, ale brak CI, klepanie raw SQL, brak procesu testowania (choćby manualnego a i ten jest mocno passe) to są czerwone flagi.
Jako Junior niewiele tam zmienisz, gdybyś był Team Leadem lub Architect'em to można brać taki projekt żeby zaprowadzić tam porządek.

Niemniej bądź świadom obecnej systuacji na rynku pracy. Nie rzucaj papierami zanim nie będziesz miał nowej roboty. A jakby ciężko ją było znaleźć, to lepiej siedzieć w ziemiance na bagnie niż umierać z głodu...

Nigdy sie nie spotkalem z zakazem testow, usprawnienia czegos itp.
A co do utrzymaniowki IMHO takie ogarniecie legacy, inwestygacja niektorych bugow, poprawienie wielkiej kupy itp. Nie dosc ze duzo uczy to jeszcze sprawia satysfakcje.
Juz nie mowiac, ze czesto w karierze bralem na siebie obszary ktorych nikt inny nie chcial. I po ogarnieciu tematu okazywalo sie ze to jest super, bo po nabyciu ekspertyzy, zrobieniu automatyzacji itp. mamy swoja spokojna nisze, ktora ogarniamy bez wiekszego wysilku umyslowego i zostaje sporo czasu na wybieranie co ciekawszych zadan, doszkalanie sie itp.

Mój pierwszy projekt za czasów juniorskich to hiper-duper wielki projekt rządowy z setką mikroserwisów do którego pozwolili mi commitować dopiero po 3msc wdrożenia xd a potem i tak wyrzucali kod na śmieci XD

Juniorzy są głównie od brudnej roboty, z racji swoich umiejętności (myślenie analityczne + prosty syntax języka), a dodatkowo seniorom nie chce się rozkminiać po raz kolejny drabinki if/elsów, nacisk kładą tam, gdzie junior nie da rady, bo nie jest jeszcze świadomy problemów, które są do ogarnięcia.

Mój pierwszy projekt to był olbrzymi monolit, gdzie uczyłem się podstaw Javy, JSa, SVNa(!), CI, SQLa.
Fajnie się wspomina po latach, wyciskaj jak najwięcej możesz, jednak jak poczujesz, że robisz w kółko to samo, to staraj się to zmienić.
Powodzenia!

Tak jak wcześniej ktoś wspomniał - ucz się w trakcie pracy. Wrzuć ciekawy projekt na git'a i poświęcaj mu 2h czasu w robocie po czym push i np w weekend możesz w chacie coś dopisać. Legacy projekt, nikt się nim nie zajmuje i nikt nie wie tak naprawdę ile czasu ci zajmuje inne zadanie. Legacy projekt to możesz wymyśleć czemu tak długo ci to zajmuje, ale raczej nawet nikt nie będzie pytał.