DEV Community

Marcin Wosinek for Poznaj dev

Posted on • Updated on • Originally published at poznaj.dev

Jak ocenić swoje aktualne miejsce pracy

Jak zapewne wiesz, specjaliści IT mogą teraz przebierać w ofertach, jeśli akurat zdecydują się na zmianę pracy. Niezależnie od podjętej decyzji – pozostanie w tej samej firmie lub szukanie innych możliwości – warto ocenić swoje aktualne miejsce pracy. Poniżej przedstawiam listę, która pomoże Ci sprawdzić, czy dane stanowisko jest dla Ciebie, czy też nie.

Czynnik ludzki

Mimo że wspomniana branża wymaga przesiadywania przed ekranem komputera, interakcje społeczne są bardzo istotnym elementem pracy w IT. To kluczowy czynnik decydujący o tym, czy ludzie zostają w firmie, czy szukają pracy gdzie indziej. Na co powinieneś zwrócić uwagę?

1. Czy Twoi koledzy z pracy są życzliwi i pomocni?

To przykre, że w tej branży tak często spotyka się z niemiłym lub mało pomocnym podejściem do nowych pracowników. Prawda jest taka, że nawet w małych projektach nikt nie będzie w stanie zrobić wszystkiego od A do Z – zaczynając od określenia wymagań, przez stworzenie aplikacji, na wdrożeniu i pomaganiu użytkownikom kończąc. Każda osoba w zespole potrzebuje pozostałych jego członków do skutecznej realizacji swoich obowiązków, więc często najlepsze, co możesz zrobić, to pomóc kolegom z pracy.

2. Czy kierownictwo bardzo naciska na swoich pracowników?

Jest to kolejny istotny czynnik wpływający na jakość Twojego miejsca pracy – czy przełożony chroni Cię przed czynnikami zewnętrznymi, czy raczej przerzuca presję z góry na Ciebie? Nie mogę wypowiadać się w imieniu każdego developera, ale ja jestem szczęśliwszy i bardziej produktywny, kiedy nie muszę walczyć ze stresem – mam tendencję do zbyt mocnego angażowania się i nie potrzebuję forsującego środowiska, które oczekuje, że pracownicy będą realizować wszystkie zadania mimo niemożliwych terminów.

3. Czy masz do dyspozycji dobry sprzęt i dobre narzędzia?

Twoja ocena pracownicza zależy od Twojej produktywności, ta z kolei zależy od komputera, na którym pracujesz, zainstalowanych na nim narzędzi programistycznych i usługodawców zewnętrznych, z których pomocy korzystasz. W większości przypadków czas przeznaczony na programowanie jest droższy niż cena komputerów i narzędzi. Z biznesowego punktu widzenia oczywistym jest, że firma powinna wydać na te narzędzia tyle, ile trzeba, i zagwarantować, że ludzie będą wykorzystywać swój czas jak najproduktywniej. A jeśli tak się nie stanie... ot, masz dobry powód, aby zacząć wątpić w umiejętności przywódcze swojego kierownictwa.

4. Jak bardzo wiedza członków zespołu się pokrywa?

Jeśli nikt Ci nie pomaga, będzie Ci ciężko. Jeśli nikt w zespole nie robi na co dzień rzeczy, którymi Ty się zajmujesz, kiedy tylko coś się zepsuje, a Ciebie nie będzie już na miejscu, będą próbowali się z Tobą skontaktować. Sytuacja może być trudna, jeśli zespół jest zbyt mały, aby zapewnić pokrywanie się wiedzy między jego poszczególnymi członkami, ale nie powinno to sprawić, że zgadzasz się na bycie niezastąpionym.

5. Czy inspekcje kodu są regularnie przeprowadzane?

Inspekcje kodu to minimum potrzebne do zagwarantowania, że wszyscy członkowie zespołu mają aktualne informacje o jego zmianach. Warto omówić kierunek, w którym Twój zespół prowadzi kod źródłowy. W przeciwnym razie w pewnym momencie może się okazać, że jesteś jedynym developerem odpowiedzialnym za konkretny moduł. A to szybka droga do większej presji, jeśli coś z tym modułem trzeba będzie zrobić.

6. Czy w Twoim zespole retrospektywy odbywają się regularnie?

Retrospektywy to świetna okazja na zwiększenie produktywności zespołu i dojście do tego, jak członkowie zespołu mogą sobie pomagać. Jeśli regularnie nie omawiacie w zespole problematycznych kwestii, to nie ma możliwości dostrzeżenia rozwiązań będących na wyciągnięcie ręki. Albo między członkami zespołu kumulują się nierozwiązane problemy, które można byłoby rozwiązać, gdyby znalazło się miejsce na ich konstruktywne omówienie.

Aspekt technologiczny

Nawet w sektorze IT niektóre firmy nie są na bieżąco z aktualnymi praktykami stosowanymi w branży. Niestosowanie ich jest złudnym sposobem na zaoszczędzenie czasu, bo procesy zapewniania jakości nie wychwycą wtedy regresji, które powrócą później jako problem wymagający natychmiastowej uwagi. Poniższe kwestie są niezmiernie ważne i bardzo ułatwią życie każdemu developerowi.

1. Ręczne zapewnianie jakości (QA)

Pierwszą linią obrony przed regresjami i niespełnionymi wymaganiami jest testowanie ręczne. Z punktu widzenia developera mogę powiedzieć, że dobrze mieć „plecy” w postaci kolegi po fachu sprawdzającego aplikację, zanim wprowadzone przeze mnie zmiany pójdą do produkcji. QA to kolejny przykład sytuacji, w której dobro firmy i Twoje są zbieżne – po prostu łatwiej jest znaleźć i naprawić bugi, zanim znajdą się w środowisku produkcyjnym. Dodatkowo oszczędzi to stresu wszystkim developerom zaangażowanym w projekt.

2. Analizy statyczne

Zautomatyzowany proces zapewniania jakości na poziomie podstawowym. Dzięki narzędziom typu eslint i prettier na frontendzie oraz Flake8 i black w Pythonie możesz zapewnić konsekwentny styl kodowania i ochronić się przed wprowadzeniem do swojego kodu źródłowego prostych błędów. Konfiguracja tych narzędzi i wprowadzenie początkowych zmian zajmie trochę czasu, ale najtrudniejsze będzie zaangażowanie wszystkich członków zespołu i dopilnowanie, żeby używali tych narzędzi konsekwentnie – zwłaszcza przed scalaniem zmian w gałęzi głównej.

3. Test jednostkowy

Kolejne zautomatyzowane i szybkie narzędzie do weryfikacji kodu. Testy jednostkowe wyłapują drobne regresje wynikające z refaktoryzacji, aktualizacji bibliotek lub ze zmian kodu wprowadzanych przez osoby nierozumiejące tak naprawdę, jak działa kod. Jeśli w Twoim miejscu pracy brakuje metody QA, całkiem możliwe, że Ty i Twoi koledzy tracicie mnóstwo czasu na naprawianie bugów, które można było wychwyci.

4. Testy end-to-end (E2E), inaczej integracyjne

Testy integracyjne są testami najbardziej wymagającymi pod kątem pisania i utrzymania. Testy jednostkowe testują kod w izolacji – z wykorzystaniem dużej liczby atrap projektu i danych fikcyjnych. Te pierwsze z kolei są przeprowadzane jak najbliżej środowiska produkcyjnego. W przypadku projektów webowych do dyspozycji są narzędzia typu cypress, które umożliwiają przeprowadzanie testów na aplikacji frontendowej, serwerze backendowym i bazie danych. Liczba zmiennych utrudnia konfigurację, ale narzędzie potrafi wyłapać problemy na wszystkich trzech warstwach. Jest jednak pewien haczyk – po znalezieniu problemu będzie potrzeba czasu, aby stwierdzić, która warstwa go powoduje.

5. Ciągła integracja (CI)

Uruchamianie tych wszystkich testów na sprzęcie developerów przed commitem byłoby niepraktyczne. Ale jeśli nie będziesz tego robił regularnie, spadnie jakość kodu źródłowego i dojdzie do nagromadzenia błędów. Rozwiązaniem jest uruchamianie skryptu na zewnętrznej maszynie po każdym commicie lub stworzeniu gałęzi w repozytorium. Dodatkową korzyścią jest to, że dzięki temu będziesz mieć oficjalny log stanu kodu – jeśli więc przedostanie się do niego jakaś zmiana breaking change, łatwo znajdziesz commit, który do tego doprowadził.

6. Dokumentacja

Jedyną rzeczą gorszą od pisania dokumentacji jest jej brak, kiedy jest potrzebna. Każdy niebanalny projekt wymaga opisania, przynajmniej w kilku słowach, jak go uruchomić i jaką ma strukturę. Ja na dokumentację patrzę jak na prezent dla moich kolegów z przyszłości – jest to coś, na czym mogą się oprzeć, próbując zrozumieć moją pracę, kiedy mnie nie ma już w zespole. Albo kiedy jestem na wakacjach i ostatnią rzeczą, której mi potrzeba do szczęścia, jest telefon z pracy.

Myśl przyszłościowo

Pozwolę sobie przywołać tutaj ulubione pytanie z rozmów kwalifikacyjnych: „Gdzie widzisz siebie za 5 lat?” – upewnij się, że firma nie pcha Cię w miejsce, w którym nie chciałbyś się znaleźć.

1. Ile możesz się nauczyć?

Jako developer nigdy nie przestajesz się uczyć, ale w niektórych miejscach będziesz robił to efektywniej niż w innych. Jeśli otaczają Cię ludzie z większym doświadczeniem, którzy na dodatek są chętni do pomocy, mam dobre wieści: jesteś w świetnym miejscu do rozwoju. Jeśli z drugiej strony pracujesz sam lub wykonujesz powtarzalne czynności, Twoja nauka w miejscu pracy w końcu stanie. W takim wypadku możesz się uczyć po godzinach, ale możesz też przygotowywać się do rozmowy kwalifikacyjnej.

2. Czy Twoja pensja spełnia standardy rynkowe?

Nie ma potrzeby pracowania w firmie, która płaci Ci poniżej stawki rynkowej. No chyba że pracujesz dla organizacji charytatywnej z wartościami spójnymi z Twoimi. Aby określić stawkę rynkową, możesz skorzystać z tego rozwiązania, a potem inwestować kilka godzin rocznie, aby mieć pewność, że od razu zauważysz, kiedy dostajesz za mało. W przeciwnym razie część Twojego czasu w pracy będzie wolontariatem dla firmy, która zdecydowanie nie jest NGO.

3. Czy umiejętności, których potrzebuje spółka, są zgodne z Twoimi preferencjami?

Czy spółka jest zdecydowana na migrację do Pythona, a Ty mimo wszystko dalej uwielbiasz stawiać te swoje średniki? Kiepskie procesy zapewniania jakości sprawiają, że jesteś raczej specjalistą ds. wsparcia klienta, a nie developerem? A może w zespole nigdy nie będzie specjalisty DevOps i ktoś będzie się musiał tego nauczyć? We wszystkich tych przypadkach może być tak, że nie pasujesz do przyszłości, którą oferuje Ci firma. A to dobry powód do zastanowienia się, czy chcesz dalej dla niej pracować.

4. Czy spółka trzyma się kurczowo technologii bez przyszłości?

W 2021 roku pracuję na AngularJS, a jednocześnie:

  1. nie polecam swojej firmie migracji do innej platformy programistycznej – byłaby to zbyt duża inwestycja;
  2. nie polecałbym tego stosu aplikacji świeżo upieczonym pracownikom;
  3. sam bym się teraz nie chciał uczyć Angular, a co dopiero AngularJS.

Tak więc w zależności od tego, jak widzisz w branży swoją przyszłość, możesz iść w kierunku bardziej popularnych narzędzi albo czegoś o bardziej świetlanej przyszłości niż stos, który był fajny w 2013.

5. Zespół się rozwija czy kurczy?

Rozwijasz się razem ze swoją firmą czy ze swoim zespołem? To, że zacząłeś wcześnie, sprawia, że będziesz w pewien sposób odpowiedzialny za ludzi dochodzących później. Dzięki temu płynnie przejdziesz od zadań dla programisty średniego szczebla do zadań dla senior developerów i dalej. Ta sama zasada działa w drugą stronę – jeśli liczebność Twojego zespołu topnieje, w pewnym momencie możesz obudzić się bez juniorów, dla których możesz być mentorem, i bez programistów, którymi możesz zarządzać. Podsumowując – niewielki, ale rozwijający się zespół jest idealnym środowiskiem dla osoby skupionej na rozwoju kariery.

6. Dałbyś sobie rękę uciąć za realizowany projekt?

Twój sukces finansowy zależy od stanu zatrudniającej Cię firmy, niezależnie od jej modelu wynagradzania – nawet jeśli zarabiasz czystą gotówkę. Jeśli spółka radzi sobie dobrze i się rozwija, bardzo prawdopodobne, że utrzyma się na poziomie obowiązujących standardów rynkowych, a Twój pasek pracowniczy będzie wskazywał coraz większą sumę, chociaż Ty nie będziesz wnosił w spółkę więcej wkładu niż dotychczas. Jeśli z drugiej strony stan spółki idzie w dół, jej budżet zacznie się zmniejszać, co z kolei może doprowadzić do któregokolwiek z wyżej wymienionych problemów.

Podsumowanie

Dobrze jest od czasu do czasu ocenić firmę, dla której pracujesz. Upewnij się, że nie siedzisz w miejscu, w którym nie powinno Cię już dawno być – nikt inny tego za Ciebie nie zrobi. Daj mi znać w komentarzu, jak radzi sobie Twoja firma i czy Twoim zdaniem istnieją jeszcze inne aspekty, które warto brać pod uwagę, oceniając swoje stanowisko pracy.

Linki

Oryginalnie opublikowane po angielsku.

Top comments (0)