Praca w branży IT na stanowisku developera

Czyli robimy szybko i byle jak. Ważne, że płacą

Spis treści

W swoim życiu z niejednego pieca chleb jadłem. Pracowałem na różnych stanowiskach, w różnych firmach. Czasami była to mała firma gdzie siedziałem z właścicielami face 2 face. Czasami w dużych korporacjach gdzie bez identyfikatora nie można było wejść do toalety. Dzisiaj opowiem wam o pewnej historii, gdy pracowałem dla tzw. software house'

Rzecz się działa w roku 2021 gdzie trochę z nudów, a trochę z potrzeby nowych wyzwań zatrudniłem się jako Senior GO developer. Co trzeba wiedzieć, żeby zostać takim seniorem? Ano mieć trochę praktyki z GO i odnaleźć kilka stron, które mają w tytule “50 najczęściej zadawanych pytań na interview z GO”. Teoria musi być książkowa: wiemy co to jest interface, jakie są zalety GO oraz czym są tuplety.

Interview

Oczywiście programować w GO też trzeba umieć. Nie myślcie sobie, że łatwo zdać takie interview, jeżeli faktycznie po drugiej stronie siedzi ktoś, kto też zna się na rzeczy. Ponieważ moda na GO jest stosunkowa nowa, na rynku jest niewielu dobrych fachowców a jeszcze mniej z faktycznym doświadczeniem w pracy nad projektami.

Jeden ze spektakularnie oblanych przeze mnie interview. Polegał na tym, że dostałem za zadanie zademonstrować w realtime wszystkie fajne funkcje GO - takie jak kanały, funkcję jako parametr oraz oczywiście zastosowanie interface. Generalnie jeżeli ktokolwiek pracuje w GO, to zna te funkcje. Korzysta się z nich często. Niestety - nigdy się tego nie robi na raz, a tym bardziej pod lufą karabinu w postaci technical enginera, który patrzy się na Twoje klawisze.

Drugi, na którym poległem, był mniej spektakularny. Miałem wykonać zadanie i napisać testy. Okazało się, że mój codecoverage nie mieścił w akceptowalnych kryteriach.

Praca

Jak uda nam się pokonać już etap interview - przechodzimy do pracy i orientacji. Orientacja zwykle polega na tym, że dużo ludzi opowiada o różnych tematach, które praktycznie rzadko będą nam potrzebne. Szkolenie BHP (paper cut), zasady raportowania godzin (przerwy na lunch nie wliczamy w godziny pracy), oraz zasady pracy zdalnej (kamera wyłączona i 0 tematów nie związanych z pracą).

Rozpisałem się na temat ogółów, a chciałem ponarzekać na szczegóły. Najpierw trafiłem do projektu, gdzie ktoś posadził 6 deweloperów i kazał im sobie wymyślać zadania. Nigdy nie widziałem tak efektywnego sposobu palenia pieniędzy. Po 2 tygodniach tego typu organizacji zajęć i próbach chodzenia dowiedzenia kto tutaj dowodzi (w jednym miejscu dowiedziałem się, że to pewnie “ja” bo mam największy staż).

Trafiłem na kolejne spotkanie. Na którym przez 2h bezproduktywnego zgadywania co mamy robić na podstawie exceli i próbie przeniesienia tego do Jiry puściły mi nerwy i poszedłem do HR zaczęła się prawdziwa zabawa.

Oczywiście podczas rekrutacji i rozmów wstępnych wszyscy mówią, że zmiany projektów są możliwe, ale prawda jest trochę inna. Zwykle to jeden tłusty klient wykłada kasę, a inne projekty są już obłożone. Więc przeniesienie to nie jest prosta sprawa. Raz usłyszałem - dobrze, ale po 3 miesiącach. Drugi raz usłyszałem, że “nie wolno rzucać papierami w stół” i to bardzo nieprofesjonalne zachowanie. Za karę trafiłem do projektu, który był oczkiem w głowie capo di tutti capi - samego właściciel plantacji bawełny.

Projekt

Tutaj projekt był w trakcie, bardzo prosty temat, który można by było wykonać w ciągu 2 miesięcy nakładem 2 ludzi. Byliśmy na końcu 4 miesiąca, 3.5 developera dalej i jednego PM’a. Końca widać nie było, więc zakasałem rękawy i wziąłem się do klikania.

Klikanie szło sprawnie i szybko, problemy pojawiły się oczywiście w komunikacji z tzw “górą”. PM średnio orientował się w swojej robocie, zorientował się, gdy klient zapytał: kiedy będzie zrobione. Okazało się, że do tego jeszcze daleka droga a wszystko to moja wina. Bo w sumie robię za wolno, a nikt nie zorientował się po kolejnym miesiącu, że albo jest za mało ludzi, albo za dużo roboty, albo coś nie tak z orientacją.

Wtedy właśnie wylądowałem na dywaniku capo di tutti capi i głowa miała być ścięta. Po godzinnej wymianie uprzejmości i plotek głowa moja została na miejscu, poleciała głowa PM’a. W nagrodę dostałem robotę PM’a i miałem dokończyć projekt sam :) Wszystko nabrało tempa, udało się prawie skończyć projekt. Poza jednym kluczowym modułem, którego nikt nie mógł wcześniej przetestować. Tzn. testowaliśmy i okazało się, że nie działa. Dzień przed pójściem live.

Gasimy pożary

Jak się okazało, że nie działa - pojawiło się 10 fachowców z zapytaniem - “kto to tak spierd..”. Niech ktoś mi powie, gdzie oni byli wcześniej?

W międzyczasie pojawiły się problemy z User Experience. 3 osoby spędziły godzinę robiąc wycenę kosztów dla klienta, zamiast 1 osoba (ux designer) spędziła tą godzinę rozwiązując problem klienta. Klient nie zgodził się na zaangażowanie UX’a i zostaliśmy z kulawym interface.

Próbowałem również zgłaszać problemy z architekturą wcześniej (monogodb do mocno relacyjnych danych?) - odpowiedź była prosta: “ta architektura jest dobra jak każda inna” - to mi dało wyraźnie do zrozumienia, że nikt nie orientuje się w swojej robocie.

Kompetencje

Co poszło nie tak? Software house, który miał wielu dobrych inżynierów tracił klientów i projekty, pomimo ogromnych możliwości.

  1. Nad projektem pracowało 5 różnych developerów, każdy po sobie zostawiał coraz większy dług techniczny, którego nie sposób było nadgonić
  2. Architektura rozwiązania była wybrana fatalnie - coś co można było zrobić w PHP z odrobiną vanilla Javascript i MySQL (co jest super prostym i tanim stackiem) było budowane w Go, React i GraphQL i MongoDB.
  3. Niekompetencje PMów - kompletny brak przepływu informacji - PM powinien zgłaszać problemy wcześniej, żeby osoby decyzyjne potrafiły podejmować decyzje. Dorzucić developerów
  4. Scoping - wiele decyzji zostało podjętych przypadkowo, bez przemyślenia konsekwencji
  5. Fascynacja technologią - w trakcie projektu odbyły się wielokrotne zmiany infrastruktury, które powodowały przestoje 2-3 dniowe.

Wnioski

  • nigdy więcej pracy w software house, pieniądze są super, ale zarządzanie do dupy
  • im więcej mądrych ludzi zatrudnisz na początku tym taniej zrobisz potem. Zamiast dorzucać drogich developerów do gaszenia pożarów, wystarczyło zestawić architekturę poprawnie
  • zatrudniaj odpowiedzialnych poganiaczy - PM który nie boi się powiedzieć, że coś idzie nie tak - nie spełnia swojej roli
  • Na (nie)szczęście software house, który zatrudnia 120+ ludzi będzie płynął dalej. Jedni klienci odejdą, drudzy przyjdą…