Kolejna zmiana pracy. Filtrowanie potencjalnie słabych ogłoszeń.

1

Jakiś czas temu zacząłem nową pracę - na rozmowie wyszedłem w miarę dobrze, ja byłem zadowolony, rekruterzy też. Dowiedziałem się, że mają jakiś tool który w jakimś stopniu zrzuca odpowiedzialność za biznes z programistów. Przyjechałem do biura. Po trzech dniach dostałem dostęp do kodu i jakieś zadanie polegające na wyczyszczeniu czegoś w Storze. Myślałem sobie, no ok - wygląda na proste. Odpalam kod, potem debuggera żeby namierzyć błąd - znalazłem. Zorientowałem się od razu jak wygląda kod i, że nie da się tego zrobić w miarę fajny sposób bez gruntownego refactoru (dość duża część aplikacji z tego korzystała + przez ten tool za bardzo nie można było ruszać miejsca w którym ten błąd był). W międzyczasie znalazłem kilka innych niezbyt fajnych "pomysłów". Po tygodniu postanowiłem, że to nie ma sensu i, że Ja się będę tam męczył, nic nie napiszę i lepiej dla mnie i firmy, żebym poszukał czegoś nowego (na moje usprawiedliwienie mam to, że nie byłem pierwszy który odszedł po tygodniu). Ostatecznie umowę rozwiązaliśmy po 2 tygodniach.

Powysyłałem kilka CV, odezwałem się na LinkedInie do kilku HR'owców, w ciągu dwóch tygodni dostałem 2 propozycje pracy. Przyjąłem jedną z nich, wymagane było NgRx, Microfrontend, Angular 11+. Projekt - przepisanie aplikacji z AngularaJs do Angulara. Miesiąc już minął i widzę, że kolejny niezbyt fajny przypadek. Okazuje się, że dalej trzeba wspierać IE11, w projekcie panuje burdel (jeśli chodzi o kod), korzystanie z zewnętrznych komponentów jest praktycznie niemożliwe, a nawet jeśli by było - to problem jest taki, że i tak ich użyć nie można bo style się nie będą zgadzać w pozostałych miejscach aplikacji. Z Angulara to nawet z RouterModule nie można było korzystać bo AngularJS przeszkadzał (nie ja konfigurowałem routing, tutaj na zmiany raczej nie ma szans bo nikt nie wie jak to dobrze zrobić). Niby jest Typescript, a wygląda to jak zwykły JS bo w wielu miejscach nawet nie ma typu określonego. Zaczynam zadanie, próbuję przepisać jakiś komponent i kończy się tak jak zwykle, że się nie da bo brakuje komponentu. Myślałem nad stworzeniem osobnego modułu i projektu, gdzie byłyby trzymane takie komponenty, ale z tego co się dowiedziałem nie bardzo jest jak. Zacząłem przepisywać brakujący komponent, skończenie go zajmie mi z 3-4 dni, ale brakujących komponentów będzie dość dużo. Dodatkowo logikę + style trzeba pisać pod IE11 - co jest dość męczące. Jeszcze kilka innych dość utrudniających rzeczy by się znalazło.

Znowu myślę nad zmianą pracy / nauką jakiegoś nowego języka, tylko to już będzie drugie odejście w ciągu trzech miesięcy. Czy da się jakoś zminimalizować ryzyko natrafienia na takie firmy w przyszłości? Jeśli tak, to jak? Doświadczenia mam 2 lata, coś tam umiem - bo na 7 rozmów technicznych w ciągu tych 3 miesięcy, dostałem 5 propozycji pracy. Pierwszą pracę zmieniłem po 2 latach, tylko to był dość nowy projekt więc legacy kodu praktycznie nie było (jedyne minusy to potrzeba dostosowania się do wszystkiego i fatalne API), jak odchodziłem - wydaje mi się, że wszystko zostawiłem w dość dobrym stanie i dość dużo rzeczy przemyślałem i zautomatyzowałem, PO i inni programiści byli raczej zadowoleni.

8

Zacząłem przepisywać brakujący komponent, skończenie go zajmie mi z 3-4 dni, ale brakujących komponentów będzie dość dużo.

Płacą ci od zrobionego zadania czy od samego robienia?

Pierwszą pracę zmieniłem po 2 latach, tylko to był dość nowy projekt więc legacy kodu praktycznie nie było

Eh, co frontendowcy tacy dalikatni. Wszyscy by chcieli pracować w greenfieldach. Z drugiej strony jak ma się język bez typowania to nic dziwnego żenikt nie chce dotykać legacy.

Znowu myślę (...) nauką jakiegoś nowego języka

I to jest bardzo dobry pomysł. Tylko tym razem wybierz język który ma typy

1

Byłem kiedyś w podobnym miejscu jak Ty teraz. Generalnie było już na tym forum sporo wątków o tym jak znaleźć dobrą firmę i jak na rozmowie rekrutacyjnej "odpytywać" drugą stronę.

Ja mogę Ci poradzić tylko jedno idź do firmy gdzie jest dość wysoki próg wejścia i moco algorytmiczna rekrutacja, co jak co ale w takich firmach zawsze panuje w kodzie porządek.

Druga droga to szukanie pracy przez znajomych, ale musisz gościom ufać bo 10k (ba teraz to i 15k lub 20k) za polecenie może niejednego "przyjaciela" nakłonić do utęczowienia rzeczywistości. Trust but verify lub nasze PRLowski Kontrola podstawą zaufania :D Niech Ci pokaże kod, i jak będzie OK to aplikuj.

PS. I na koniec nie można mieć wszystkiego, ładny kod to często mniejsza kasa, łajno kod to często lepszy zarobek, tak samo jak SharePoint :P Zawsze możesz to traktować tylko w kategoriach pracy, tak jak np. zbieranie ziemniaków. Trzeba zebrać i koniec, a po 8h możesz robić co chcesz...

8
  1. Sorry Winnetou, ale 90% softu to rozwijanie czegoś co istnieje a nie greenfield i nowy kod
  2. Często ludzie narzekają że projekt słaby, ale jak mają sami od zera coś zaprojektować to nagle okazuje się że w sumie nie wiedzą jak to zrobić żeby miało ręce i nogi
  3. Jak projekt słaby, to trzeba zakasać rękawy i naprawiać.
  4. Zamiast wysyłać CV do losowych miejsc, może zastanów się gdzie chciałbyś pracować? i właśnie tam aplikuj?
6

Ostatnio byłem w podobnej sytuacji… Przyszedłem do firmy, w której kod frontowy jest na bardzo słabym poziomie i początkowo myślałem, żeby wysyłać CV, ale… doszedłem do wniosku, że warto spróbować naprostować, to co jest źle, co prawda mam trochę więcej doświadczenia niż ty i będzie mi pewne zmiany łatwiej przeprocesować, ale jeśli spróbujesz to pokażesz się z solidnej strony i na pewno pozytywnie to wpłynie na Twoje wynagrodzenie / stanowisko.

Pamiętaj, że idealnie nigdy nie będzie, ale małymi kroczkami możesz swój idealny świat wprowadzać odpowiednio argumentując zmiany.

No i na IE11 nie narzekaj aż tak ;) Safari też jest uciążliwe w stylowaniu, a tego tym bardziej nie wykluczysz.

0

ale jeśli spróbujesz to pokażesz się z solidnej strony i na pewno pozytywnie to wpłynie na Twoje wynagrodzenie / stanowisko.

Niekoniecznie, ale dopóki nie spróbujesz to się nie dowiesz.

2

Moze wroc do pierwszej pracy

0

Aplikuj do ciekawszych i wiekszych firm gdzie w razie czego możesz po prostu zmienić dział?

5

Ktoś już tu kiedyś napisał, że każdy nowy projekt w jego firmie zaczyna się z obietnicą "ładnego kodu", nowych narzędzi i technologii, a później przychodzi proza życia, upływające terminy, łatanie w biegu, nieudokumentowane poprawki i stare sprawdzone narzędzia. Takie jest życie i pewnie 80% projektów tak wygląda.

2

Praca jest przede wszystkim od zarabiania. Nie ma idealnego projektu, zwyczajnie trzeba się nauczyć w takim funkcjonować. Jeśli coś nie gra to spróbować to zmienić, ulepszyć.. Ogólnie podjąc próbę działania a nie od razu uciekać. Jak dla mnie problem leży w Twoim podejściu do tematu stąd tak częste zmiany. Źle to będzie wyglądać w cv :P

0

@Shalom:

Sorry Winnetou, ale 90% softu to rozwijanie czegoś co istnieje a nie greenfield i nowy kod

Tak, ale pytanie czy to co istnieje ma 5,10, czy 30 lat. Nowy kod to pojęcie subiektywne.

Jak projekt słaby, to trzeba zakasać rękawy i naprawiać.

Nic nie trzeba.

Zamiast wysyłać CV do losowych miejsc, może zastanów się gdzie chciałbyś pracować? i właśnie tam aplikuj?

Co do samej jakości firmy i projektu to nie jest IMO zawsze takie łatwe, bo najlepiej mieć opinie od ogarniętych, uczciwych znajomych, których czasem brak w każdej firmie, a na gowork itp. ciężko zweryfikować, jaki jest dokładnie obraz, to są opinie od anonimów.

@Aisekai

Czy da się jakoś zminimalizować ryzyko natrafienia na takie firmy w przyszłości?

Rozumiem, że poprzez **takie firmy **, masz na myśli takie gdzie jest burdel w kodzie i technologie które Ci nie pasują? Na następnych rozmowach spróbuj wybadać :

  1. W jaki sposób dbają/dbali o jakość kodu.
  2. Jakie technologie zastaniesz w kodzie i co konkretnie będziesz robił. To może być co innego niż to co napisali w ogłoszeniu w "wymagane/nice to have".

W tym dziale znajdują się wątki z pytaniami do potencjalnego pracodawcy, myślę że warto je przejrzeć jak już się ma pierwsze doświadczenie.

IMO samo ogłoszenie jest ciężko odfiltrować w 100% bez zaangażowania się w proces rekrutacyjny, nie wszystkie informacje podaje HR na pierwszej rozmowie, tylko trzeba popytać technicznego po rozmowie konkretniejszej.

Inna sprawa, to to, że raczej nie ma idealnej firmy/projektu. Z poprzedniej odszedłeś z jakiegoś powodu.

12

screenshot-20210808175616.png

1

Praktycznie 99% ogłoszeń jest słabych i to nie z powodu stanu kodu jaki uzyskasz do utrzymania, ale z powodu: słabych umów, zespołu i zarządzania.

Jeśli firma nie jest nastawiona na sukces to dla mnie z miejsca przegrała. Z tego co widzę największym problemem firmy jest ona sama. Typowa firma to taki tłuścioch, który od czasu do czasu musi wbiec na górkę. Niestety ponosi przy tym ogromny trud i to tylko na własne życzenie (brak zaangażowania/kondycji, niezdrowy rozmiar).

A jeśli firma unika górek, jeśli nie napiera do przodu, jeśli woli o tym wyłącznie gadać to będzie się tylko cofać, przepalać zasoby, unikać problemów jakie rzeczywiście czekają na rozwiązanie.

Jeśli od środka, kierownik zespołu nic konkretnego sobą nie reprezentuje, nie jest dla mnie przykładem lub co gorsza jest tylko poganiaczem to klapa. W takim miejscu stracisz wyłącznie czas, entuzjazm i chęć do rozwoju, bycia lepszym. Wtedy włącza się hibernacja, chęć odczekania do 17, a potem nawet nie próbujesz nawet zrozumieć co się stało, bo to nie Twój problem.

Po paru próbach mnie to już nie dziwi, finalnie:

  • Oprogramowanie stanowi środek do poszerzenia istniejących wpływów lub ograniczenia wydatków, samo w sobie oprogramownie nie jest źródłem kasy, to bardziej automatyzacją/optymalizacją już wcześniej podjętych działań. Jesteśmy wydatkiem bardziej z konieczności niż z zamiarem na osiąganie wielkich rzeczy. Generujemy koszty i niczym się nie różnimy od księgowych czy grafików :-(
  • Firmy utrzymujące soft wolą mierzyć jak słabe i przewidywalne są ich rezultaty zamiast odpowiadać na to co ma znaczenie.
  • Pracownicy chcą mieć święty spokój, oni przychodzą do pracy w głównej mierze odpocząć i odklikać swoje. Zasuwać to może ten kto nie wierzy w siebie, a im bardziej kompetenty gość tym bardziej szanuje swój czas, tym większy dystans ma do tego co dzieje się w firmie. Siłą rzeczy ciężej jest się uczyć od lepszych ludzi skoro oni przez większą część pracy robią uniki lub odpowiadają na problemy, które bardziej im leżą.
  • Brak ryzyka i czucia efektów. Sukces firmy nie jest sukcesem pracownika, podobnie jak porażka. Koder nie ma odniesienia, które mogłoby mu powiedzieć czy to co robi ma jakąkolwiek wartość. W efekcie te ambitniejsze dyskusje programistyczne odnoszą się do tego co jest bardziej poprawne niż to co ma większe znacznie, czego efektem jest to, że komplikujemy zamiast upraszczać.
  • Będąc w środku takiej firmy czuję jakbym na start otrzymał (w tych ciut lepszych firmach) wygrawerowaną na łopacie nazwę technologi, jakby to samo z siebie miało sprawić, że będę kopał głębiej, dalej i dłużej. Inny typ firmy jaki spotkałem to coś na kształt rutyny niczym barista, gdzie co dzień w sumie serwuje to samo tyle, że w innej kolejności.

1 użytkowników online, w tym zalogowanych: 0, gości: 1