Druga praca, czyli pierwsza zmiana w IT plus szok

Cześć,

temat prawdopodobnie dla znakomitej większości okażę się bdzurą, ale dla mnie to pierwsza sytuacja tego typu i po prostu chciałbym przeczytać, jak to wygląda z perspektywy bardziej doświadczonych osób.

Po dwóch latach pracy w poprzedniej firmie przyszly zwolnienia - z dnia na dzień poleciał cały zespół. Mimo dobrej oceny rocznej i korzystnej opiniii w firmie, zwolnienie mnie nie oszczędziło. Nową pracę udało się ogarnać w mniej niż tydzień, poprosiłem tylko o start za 2 tygodnie, chciałem chwilę odetchnąć, jako że nie udało się pojechać na planowany urlop i ogarnać narzędzia do nowej pracy.

W nowej pracy trochę szok. Projekt jest dość spory, zespół niewielki (wcześniej firma ~~300 osób i greenfield), kod to istne spaghetti - hook na hooku, okropny bałagan, mnóstwo gotowych komponentów z nieznanej biblioteki, do tego biblioteka do ui z liczbą kilkuset pobrań... Po prostu masakra. Mam cholerne obawy, że tego nie ogarnę. To dopiero 3 dzień, co prawda w ramach treningu zrobiłem kilka komponentów, ogarnąłem kilka rzeczy, ale brak porządnej dokumentacji, niespójne praktyki, dziwaczne rozwiązania sprawiają, że mam po prostu obawy, że tego nie ogarnę. Kumpel mi powiedział, że tak jest zawsze, no ale... no nie wiem. Nie chcę iść w stronę przesady - jeżeli ktoś to napisał, jest to rozwijane i działa - to znaczy, że jest w tym sens, jest to ok i może ja nie rozumiem. Nie uważam, że wchodze do zespołu i będę wszystko wiedział lepiej od wszystkich. Po prostu obawy i nieogarnianie tematu, kłopoty, że rozgryzienie tego zajmie mi miesiące. Z drugiej strony widzę, że komponenty renderują się dziesiątki razy, pewne niepotrzebne operacje są w useEffect (dodawanie do tablicy), jest wiele contextów bez memo...

No po prostu po ludzku mam stracha przed nieznanym.

Witamy w rzeczywistości :)

Witamy w królestwie :)

Kurde chciałbym mieć takie banały w pracy do robienia :)
A tak serio to czy te useEffecty są teraz z nami w pokoju?

I teraz radosna tworczosc greenfielda spotyka sie z rzeczywistoscia i weryfikacja po latach rozwoju :D
Tak wyglada normalna praca. Bedziesz mial dobre doswiadczenie i nie dramatyzuj bo nie ma o co

Hello world :)

Ciesz się, że kod tej biblioteki ui nie zawiera własnych zmian przez co nie da się w żaden sposób zainstalować paczek spoza świętego zipa.

_false napisał(a):

Nie uważam, że wchodze do zespołu i będę wszystko wiedział lepiej od wszystkich.

Możesz zrobić eksperyment i pogadać o tym z jakimś ogarniętym programistą z twojego zespołu, który już długo tam pracuje. Czy w ogóle dostrzega problem. Oraz czy ma jakieś pomysły na to, żeby wprowadzić jakieś standardy.

Kod może być zły, ale jeśli programiści zdają sobie z tego sprawę i przywiązują wagę do polepszania jakości, to pół biedy. Trochę jakbyś przechodził przez bagno z kimś ogarniętym. Przynajmniej sobie pogadasz i powymieniasz poglądy na temat programowania albo czegoś się nauczysz od kogoś.

Gorzej, jeśli programiści mają w dupie jakość, bo np. nie ma czasu. Albo sami są słabymi programistami i nie umieją, nie dostrzegają. To trochę jakbyś przechodził przez bagno z kimś, kto wypił pół litra i trzeba go podnosić co chwila.

• jeżeli ktoś to napisał, jest to rozwijane i działa - to znaczy, że jest w tym sens

Może być sens biznesowy, ale niekoniecznie programistyczny.
np. kiedyś widziałem taki mniej więcej kod

foo[0] = bar.get(0);
foo[1] = bar.get(1);
foo[2] = bar.get(2);
foo[3] = bar.get(3);
foo[4] = bar.get(4);
foo[5] = bar.get(5);
foo[6] = bar.get(6);
foo[7] = bar.get(7);
foo[8] = bar.get(8);
foo[9] = bar.get(9);
// i tak do 20

w zasadzie w uproszczeniu, bo linijki były dłuższe i nie pamiętam, co dokładnie tam było, ale temat był taki, że było jakieś użycie kolejnych liczb w ten sam sposób.

Ten kod coś tam robił biznesowego, więc miało to sens, tylko że zmieniłem te 20 linijek na coś takiego:

for (let i = 0; i <= 20; i++) {
   foo[i] = bar.get(i);
}

i działało tak samo.

Biznesowo nie było żadnej korzyści krótkofalowo, ale jednak taki kod łatwiej utrzymywać i szybciej można będzie wprowadzać zmiany w przyszłości. Więc jest to spłacanie długu technicznego. Oczywiście należy to robić regularnie i w wielu miejscach. Niestety wiele programistów/zespołów nie dostrzega takiej potrzeby i wolą klepać. Optymalizują tylko pod bieżący sprint, żeby się wyrobić z taskami, a nie myślą o tym, co będzie w perspektywie miesięcy czy dłużej.

Tak powstaje spaghetti. To problem nie tylko techniczny, ale i mentalny, związany z podejściem programistów czy sposobem zarządzania projektem.

Pytanie więc, czy chcesz w takim projekcie pracować? Myślę, że fajnie jest wejść do takiego projektu, bo można się nauczyć masy rzeczy na temat tego, jak nie pisać kodu i jak nie prowadzić projektu, a to też cenna wiedza. Tyle, że to jest frustrujące, nawet jeśli jest to cenna lekcja.

To szukaj lepszej firmy, sama się nie znajdzie xD

_false napisał(a):

W nowej pracy trochę szok. Projekt jest dość spory, zespół niewielki (wcześniej firma ~~300 osób i greenfield), kod to istne spaghetti - hook na hooku, okropny bałagan, mnóstwo gotowych komponentów z nieznanej biblioteki, do tego biblioteka do ui z liczbą kilkuset pobrań..

Pytanie jakie mi się nasuwa: dlaczego użyto mało popularnej biblioteki, czy istnieje jakaś sensowna potrzeba? Bo może istnieje (np. tylko w tej bibliotece były odpowiednie ficzery).

Ale jeśli jest sensowna potrzeba, to czy czy zespół wziął odpowiedzialność za bibliotekę?
(odpowiedzialność to znaczy, że np. jeśli coś nie działa w bibliotece, to programista z firmy nie będzie bezradny, ale jest w stanie naprawić buga w danej bibliotece i zrobić do niej pull request. Albo że zespół aktywnie rozwija daną niszową bibliotekę open source albo jej forka).

Z drugiej strony być może wybór biblioteki był dość randomowy, a zespół nie bierze odpowiedzialności, a jedynie konsumuje jakieś niszowe biblioteki i rozkłada ręce, jak im coś w nich nie działa. Wtedy to pachnie klęską.

Potwierdzam i pozdrawiam - sam przez pierwsze 3 miesiace w nowej robocie (drugiej mojej i obecnej, prosto po wyjsciu z SH) nie ogarnialem nic z racji domeny projektu - normalne i minie, chyba ze wyjatkowo jest "stworzone" to sam bedziesz patrzyl zeby zmienic na cos nowego znowu :D

Niestety tak wygląda rzeczywistość w 95% przypadków. Ja tam lubię debugować takie potworki :D po tygodniu debugowania euforia jaka towarzyszy jak znajdziesz błąd jest niesamowita :)

_false napisał(a):

W nowej pracy trochę szok. Projekt jest dość spory, zespół niewielki (wcześniej firma ~~300 osób i greenfield), kod to istne spaghetti - hook na hooku, okropny bałagan, mnóstwo gotowych komponentów z nieznanej biblioteki, do tego biblioteka do ui z liczbą kilkuset pobrań... Po prostu masakra. Mam cholerne obawy, że tego nie ogarnę. To dopiero 3 dzień, co prawda w ramach treningu zrobiłem kilka komponentów, ogarnąłem kilka rzeczy, ale brak porządnej dokumentacji, niespójne praktyki, dziwaczne rozwiązania sprawiają, że mam po prostu obawy, że tego nie ogarnę. Kumpel mi powiedział, że tak jest zawsze, no ale... no nie wiem. Nie chcę iść w stronę przesady - jeżeli ktoś to napisał, jest to rozwijane i działa - to znaczy, że jest w tym sens, jest to ok i może ja nie rozumiem. Nie uważam, że wchodze do zespołu i będę wszystko wiedział lepiej od wszystkich. Po prostu obawy i nieogarnianie tematu, kłopoty, że rozgryzienie tego zajmie mi miesiące. Z drugiej strony widzę, że komponenty renderują się dziesiątki razy, pewne niepotrzebne operacje są w useEffect (dodawanie do tablicy), jest wiele contextów bez memo...

No po prostu po ludzku mam stracha przed nieznanym.

Jeżeli to duży system to raczej nie ogarniesz wszystkiego w miesiąc, dwa czy pół roku. Może być tak, że po kilku miesiącach będziesz przyzwoicie ogarniać jakiś wycinek a kolega będzie ogarniał inny kawałek systemu. No i jakimś cudem będziecie się uzupełniać. A żeby ogarniać całość to by potrzeba pewnie z dwóch, trzech lat pracy w projekcie.
Pracowałem w projekcie, który był tak duży, że nikt nie był w stanie ogarnąć więcej niż dwa, trzy moduliki z systemu. A modułów było pewnie ponad sto.
Ja po pewnej zmianie pracy trafiłem do projektu, gdzie cały okres próbny na UoP czekałem na dostępy, bo nikt nie wiedział jakie powinienem mieć dostępy, do czego, i w ogóle kto te dostępy powinien nadawać :-D

_false napisał(a):

kod to istne spaghetti - hook na hooku, okropny bałagan, mnóstwo gotowych komponentów z nieznanej biblioteki, do tego biblioteka do ui z liczbą kilkuset pobrań... Po prostu masakra. Mam cholerne obawy, że tego nie ogarnę. To dopiero 3 dzień, co prawda w ramach treningu zrobiłem kilka komponentów, ogarnąłem kilka rzeczy, ale brak porządnej dokumentacji, niespójne praktyki, dziwaczne rozwiązania sprawiają, że mam po prostu obawy, że tego nie ogarnę. Kumpel mi powiedział, że tak jest zawsze, no ale... no nie wiem. Nie chcę iść w stronę przesady - jeżeli ktoś to napisał, jest to rozwijane i działa - to znaczy, że jest w tym sens, jest to ok i może ja nie rozumiem. Nie uważam, że wchodze do zespołu i będę wszystko wiedział lepiej od wszystkich. Po prostu obawy i nieogarnianie tematu, kłopoty, że rozgryzienie tego zajmie mi miesiące. Z drugiej strony widzę, że komponenty renderują się dziesiątki razy, pewne niepotrzebne operacje są w useEffect (dodawanie do tablicy), jest wiele contextów bez memo...

jak to prawda, to nikt poza turbo senior legacy ninja wymiataczami nie ogarnie czegoś takiego nawet w parę miesięcy. Czy Cię wywalą to wątpię, pewnie firma jest nastawiona że próg wejścia jest wysoki w nadziei że ktoś zostanie parę lat i zacznie to ogarniać. Zastanów się czy taka wizja Ci odpowiada, czy też nie rozglądać się za czymś innym.

To posłuchaj tego ;)

Kwiecień 2022
Od tej pory przez 8 miesięcy pracowałem w projekcie B, który miał być rzekomo super-hiper-zayepisty. Jak się okazało - to nie był nawet średni. Soft dla małej firmy, ale serwowany przez duża firmę, w teamie był tylko jeden backend (zw dalej master-dev), PM/tester , no i mnie dorzucili. Myślałem, spoko, może coś z tego wyjdzie, zależy jakie będzie tempo, wymagania itp itd. Jednocześnie była to już czerwona lampka, że jeden techniczny gościu trzyma w ryzach cały projekt. Ale skoro dorzucili i mnie - to myślałem sobie "pewnie master-dev) sam już nie wyrabia i potrzebna pomoc". Był jeszcze PM, który jednocześnie robił za testera manualnego... no cóż... mały klient, może jakoś się uda....

Stan zastany: 0 testów, zero wzorców (nie, nie mówię tu o tym, by na siłę pchać jakiekolwiek), ogólnie to śmietnik w kodzie.
Od samego początku stawiałem na jakość i powiedziałem że przy takim projekcie (związany był z "pieniążkami" :D) musimy mieć testy.
No to zacząłem pisać, a po 3 miesiącach info od klienta:

"No Panie... za te testy to tylko płacimy, a błędy w systemie jak były tak są".

Mój pracodawca stwierdził "Spoko, pisz te testy dalej, bo to ma sens, tylko nie będziemy tego komunikować otwarcie klientowi, bo on kodu i tak nie widzi"

Maj 2022
Mając już świadomość co w projekcie piszczy, sporządzam raport w którym punktuje wszystko aktualne i potencjalne problemy. M.in problemem jest wyliczanie cen, a dokładnie problem z zaokrągleniami. PM pod wrażeniem, management zdumiony, że przyszedł jakiś kolo i od razu sypie jak z rękawa potencjalnymi bugami [*1]

Czerwiec 2022
Sporo rzeczy w projekcie śmierdzi, więc chcę poznać genezę projektu. Okazuje się, że projekt został odziedziczony po jakiejś firmie krzak, dlaczego?

"Bo poprzednia firma, strasznie duzo bledow robila, musieli to dlugo naprawiac i ogolnie to duzo piniedzy chcieli"

Pytam zatem : jak wyglądało przekazanie projektu od strony technicznej?

No to tutaj wyebalo null pointer expcetiona dla managmentu - bo przekazanie projektu, to bylo tylko przekazanie repo na gicie. Zero analizy, zero dokumentacji. Po prostu firma przejela klienta i "zobaczymy co z tego wyjdzie"

Lipiec 2022
Klient zgłasza problem, o którego istnieniu informowałem w [*1] - o dziwo, klient przyznaje się, że problem istniał od samego początku, ale zawsze pracownicy firmy spędzali długie godziny na manualnym fixowaniu kwot, wiec zaplusowałem, bo była szansa na pozbycie się tego problemu.

Wrzesień 2022
Po 5 miesiącach:

• intensywnego refaktoru,
• wdrażaniu wzorców,
• automatyzacji pewnych procesów,
• napisaniu setek testów,

z dwuosobowego zespołu odchodzi master-dev .... a ja zostaję sam. Było ciężko, bo nie dość, że trzeba dowozić nowe ficzery, to trzeba naprawiać istniejące bugi.

Listopad 2022
Resztkami sił, przygotowuje dla PM/testera scenariusze testowe (mimo, że to nie moja rola), ale chcę zeby projekt hulał jak należy. Są to 4 strony A4 z rozpisanymi wariantami akcji, jakie należy podjąć, aby przetestować poprawne działanie systemu. Proszę PM'a/testera, aby dał mi pisemne potwierdzenie efektów jego testów, w szczególności, aby przedstawił wyniki tych testów dla poszczególnych scenariuszy.

Grudzień 2022
PM/Tester daje mi znać, że on przetestował wszystko po swojemu, bo zawsze tak testował i przeklikał kilka miejsc jego zdaniem "najbardziej newralgicznych" i że nie będzie tracił czasu na pisanie jakiegoś raportu.....

Przez te 8 miesięcy napisałem ponad 500 testów (unity i funkcjonalne). Pokrycie kodu w tym momencie to około 60%. Wtedy dowiaduje się, że wypadam z projektu, a na moje miejsce wraca ten pierwotny master-dev :P

No to przekazuje mu projekt, mówię co i jak, tłumaczę, żeby pisał testy, bo to ważne.

Styczeń 2023
Mija miesiąc (jest to końcówka stycznia). Z racji tego że nadal mam dostęp do repo, pomyślałem, że z ciekawości zobaczę co tam słychać.
Odpalam testy - około 30% na czerwono :)

Luty 2023
Dowiaduje się, że ten master-dev dostaje nowego pomagiera , a ja dostaje w gratisie prośbę, aby mu potlumaczyć jak działa projekt :), tlumacze mu, ze pierwsze co powinien zrobic to naprawic to co wywala testy, a jesli jakaś logika mocno się zmienila, to odpowiednio zmodyfikowac testy.

Lipiec 2023
Znowu z ciekawości sprawdzam repo.
45% testów na czerwono.
Pokrycie kodu spadło z 60% na około 20~25 %.
Ilość testów nie uległa zmianie, dwóch kolesi od stycznia nie napisało ani jednego testu, nie naprawili ani jednego, dorzucili tylko masę g**no-kodu.

Sierpień 2023
Tracę dostęp do repo, mój trud skończon :)

PS.1 Tak, ogólnie lubię się grzebać w legacy code
PS.2 Tak, nadal robię w tej samej firmie (w projekcie X)
PS.3 master-dev na czas tej nieobecności był w projekcie X, dlaczego wrocił do projektu B? Bo jak się dowiedziałem od ekipy X, gościu twierdził, że ten kod jest dla niego za trudny.

Kurtyna, oklaski....

axelbest napisał(a):

To posłuchaj tego ;)

Kwiecień 2022
Od tej pory przez 8 miesięcy pracowałem w projekcie B, który miał być rzekomo super-hiper-zayepisty. Jak się okazało - to nie był nawet średni. Soft dla małej firmy, ale serwowany przez duża firmę, w teamie był tylko jeden backend (zw dalej master-dev), PM/tester , no i mnie dorzucili.

Firmy powinny pokazywać jakąś demówkę projektu przed zatrudnieniem.

• jeśli projekt jest niedostępny publicznie, to jakieś screeny, filmiki i mockupy projektu
• ogólny schemat architektury rozrysowany gdzieś
• przykład (np. 200 linijek) dobrego kodu z projektu
• przykład (również z 200 linijek) złego kodu, który został zrefaktoryzowany do dobrego (bo rozumiem, że po prostu złego kodu firma nie będzie chciała pokazać, ale niech pokaże przynajmniej przed i po).
• taśmy prawdy: 2 minutowy fragment randomowej dyskusji z ostatniego daily
• 3 jakieś randomowe taski sprzed kilku tygodni (choćby to jak zostały opisane) plus wyjaśnienie kontekstu, o co w nich chodziło
• szczegółowy spis technologii (czyli lista np. kilkudziesięciu różnych tooli, które używają)

Ogólnie coś, co nie ujawniłoby tajemnic projektu na tyle, żeby firma na tym ucierpiała (chociaż to banie się też jest przesadzone, z większości firm można wynieść co najwyżej antywzorce i spaghetti kod), ale jednak pozwoliło by się rozeznać w projekcie lepiej niż słuchanie na rozmowach rekrutacyjnych ogólnikowych historii. Pewnie, big picture też jest ważny, ale fajnie byłoby móc powiedzieć sprawdzam.

Tylko, że to i tak za mało, żeby ocenić. W zasadzie powinni by wpuścić kogoś na tydzień do projektu, żeby sobie zobaczył (płacąc mu np. połowę stawki przez ten tydzień), a potem by ktoś mógł zdecydować, czy chce tam pracować. Firmy sprawdzają kompetencje kandydatów, to dlaczego kandydat nie może sprawdzić projektu?

LukeJL napisał(a):

Firmy powinny pokazywać jakąś demówkę projektu przed zatrudnieniem.
(...)
Firmy sprawdzają kompetencje kandydatów, to dlaczego kandydat nie może sprawdzić projektu?

Zabawa w odnajdywanie szczegółów - czym się różnią dwa poniższe obrazki?