Zorganizuj jedno źródło wiedzy o pracy zespołu. Ułatwi to estymację stanu realizacji projektu

Jakie możliwości rozwoju ma Senior Software Engineer? Opcji jest wiele, choć jak powiedział nam Grzegorz Rozdzialik, jego najbardziej zainteresowała ta związana z zarządzaniem zespołem. – Warto pamiętać, że nie jest to naturalna progresja po osiągnięciu tytułu Seniora. Nie trzeba zostawać menadżerem, aby piąć się dalej i rozwijać, chociaż drabinka awansów może być tak skonstruowana w wielu firmach – dodał.

Grzegorz jest Senior Software Engineerem w Splitgraph i zapytaliśmy go m.in. o to, w jaki sposób podnosi swoje kompetencje.

Dlaczego postawiłeś na branżę IT?

Od dawna interesowałem się komputerami i technologią. Można powiedzieć, że to moja pasja. Fascynuje mnie możliwość instruowania komputera, co ma robić, co pozwala tworzyć różnego rodzaju narzędzia i automatyzacje usprawniające życie. Możliwość pracowania w branży i technologii, która mnie dodatkowo interesuje, jest bardzo korzystnym połączeniem. To sprawia, że właściwie w pracy nie wiem czym jest nuda i każdy dzień spędzam na rozwiązywaniu problemów w ciekawy sposób, a także poszerzaniu swojej wiedzy.

Jakie miałeś wyobrażenia o branży na początku swojej drogi, przypuszczam, że “wszystko” zaczęło się w liceum?

Nawet jeszcze wcześniej – w szkole podstawowej. O ile się nie mylę, w 4. klasie podstawówki natrafiłem w Internecie na stronę pokazującą funkcjonalności różnych tagów HTML. Pamiętam, że stworzyłem wtedy stronę-potworka, która zawierała większość tagów HTML (także kultowe blink oraz marquee) ustawionych bez ładu i składu. Mimo to byłem bardzo podekscytowany, że stworzyłem coś własnego w komputerze, co wymagało większej wiedzy niż obsługa Worda.

Niedługo później kupiłem pierwszą książkę związaną z programowaniem – Symfonia C++ Jerzego Grębosza. Patrząc z perspektywy czasu wiem, że C++ nie był najlepszym wyborem do nauki programowania. Mimo to zaciekawiła mnie możliwość pisania logiki (której zabrakło mi w HTMLu). Poznanie tego języka umożliwiło mi później wzięcie udziału w Olimpiadzie Informatycznej Gimnazjalistów. Nie rozumiałem wtedy czym są grafy, nie znałem algorytmów. Ogólnie całe programowanie wydawało mi się bardzo trudne, ale strasznie ciekawe. Nie znając wielu programistów kierowałem się tylko stereotypami i założyłem, że to introwertycy nie kontaktujący się w ogóle ze światem rzeczywistym. Nie zdawałem sobie sprawy z tego, że branża IT to nie tylko samo programowanie, ale też sporo komunikacji, planowania, zarządzania zadaniami i ryzykiem.

Jak wyglądało pierwsze zderzenie z rzeczywistością? Czy pierwsza praca pokazała Tobie, jak naprawdę wygląda ta branża?

Zderzenie z rzeczywistością przyszło po pierwszym roku studiów informatycznych, kiedy poszedłem na praktyki, a później na stałe do firmy stepChangeIT. Moje przypuszczenia z akapitu powyżej właściwie spełniły się – omówiłem z szefem i przełożonym jaką stronę mam zrobić, a później klepałem, klepałem i klepałem. Byłem jednoosobowym zespołem, więc samemu musiałem zarządzać zadaniami, jedynie od czasu do czasu pokazując efekty pracy. Nie było ciśnienia na dowiezienie funkcjonalności, a przynajmniej ja go nie odczuwałem. Generalnie, sporo luzu i możliwości rozwoju, co mi się podobało.

Dopiero na kolejnych stanowiskach w innych firmach zauważyłem jak dużo uwagi należy poświęcić komunikacji w zespole i z klientem, oraz planowaniu zadań. Dowiedziałem się o zależnościach między wynikami pracy jednych osób a potrzebami innych osób. Nauczyłem się, że praca w izolacji na dłuższą metę nie jest najkorzystniejsza. Nie tego się spodziewałem przed wejściem do tej branży, co nie oznacza, że mi to przeszkadza.

Zobacz też

Wywiady W firmie produktowej mam poczucie większej sprawczości. Wywiad z Radkiem Koziełem

Jakie masz podejście do zmiany pracy – kiedy jest dla Ciebie moment na to, żeby zmienić pracodawcę?

W swoim życiu pracę zmieniałem dopiero trzy razy, więc nie mam wypracowanych twardych reguł, kiedy to powinno nastąpić. Składa się na to wiele czynników. Niektórymi z nich są:

• różnica między aktualną pensją a tą oferowaną przez rynek oraz brak perspektyw na zrównanie tych wartości na aktualnym stanowisku,
• różnego typu problemy (komunikacyjne, związane z oczekiwaniami wobec mnie, planowaniem pracy) i brak perspektyw na zmiany.

Przy pojawiających się problemach na pewno warto rozpocząć dialog z pracodawcą i poszukać metod na ich rozwiązanie, szczególnie jeżeli nasz staż w firmie jest mniejszy niż rok.

Splitgraph to wyjątkowa firma, opowiedz proszę o niej i o tym, czym zajmujesz się na stanowisku Senior Software Engineera?

Celem Splitgraph jest stworzenie jednolitej platformy do obsługi danych. Jak GitLab pozwala na obsługę procesu wytwarzania oprogramowania począwszy od zarządzaniem zadaniami, kontroli wersji, code review, CI/CD, monitorowaniem wdrożeń, tak Splitgraph obsługuje przechowywanie danych w postaci tabel PostgreSQL zapisanych w wersjonowanych repozytoriach, łatwego wykonywania zapytań SQL na nich, kontrolą dostępu i dzielenia się nimi, a także odkrywaniem danych dostępnych w danej organizacji. Splitgraph integruje wiele narzędzi do obsługi danych w postaci jednej platformy, dzięki czemu praca z danymi staje się prostsza.

Moją rolą tam jest głównie rozwijanie aplikacji webowej do obsługi platformy, a także procesów pobocznych, ale nadal związanych z frontendem, jak na przykład automatyzacja testów end-to-end. Oprócz pracy technicznej staram się wprowadzać w firmie praktyki, których nauczyłem się na poprzednich stanowiskach, takie jak bardziej skrupulatne zarządzanie zadaniami i planowanie oraz usprawnianie procesu wytwarzania oprogramowania (np. poprzez przyłożenie większej uwagi do code review czy pisaniu RFC).

Oferty pracy z

Zaciekawiło mnie to zdanie dot. skrupulatnego zarządzania zadaniami. Możesz opowiedzieć o nim więcej?

Mam tutaj na myśli przykładanie większej uwagi do tego, aby status, opis i zakres zadań w naszym narzędziu do ich śledzenia były jak najbardziej aktualne i dokładne. Na początku mojej kariery “uzupełnianie JIRY” wydawało mi się zbędnym narzutem czasowym i wysiłkiem. Dopiero później zauważyłem, że dzięki posiadaniu dobrze zorganizowanego jednego źródła wiedzy o pracy mojej czy zespołu jest dużo łatwiej zorientować się jakie są priorytety, jak nam idzie sprint, czy jest ryzyko, że nie dowieziemy tego co zaplanowaliśmy.

Przydaje się to również podczas planowania czy dyskusji o przyszłych zadaniach – zamiast szukać informacji w czacie czy próbować przypomnieć sobie o czym było dane zadanie i jak jest ono powiązane z innymi zadaniami, lubię wszystko to mieć wpisane w system zarządzania zadaniami. Pomaga to również uniknąć niepotrzebnych pytań od członków zespołu czy przełożonych, ponieważ informacje te są dla nich dostępne od razu. Wpisuje się to poniekąd w komunikację asynchroniczną, którą bardzo lubię.

Oczywiście utrzymywanie informacji o zadaniach w stanie aktualnym przynosi największe korzyści jeżeli robi to cały zespół, a nie tylko jedna osoba. Brak konsensusu w tym aspekcie nie jest mimo wszystko przeszkodą, aby samemu dbać o zadania – zazwyczaj właśnie tak robię dołączając do nowego zespołu bez względu na praktyki innych jego członków i w ten sposób staram się pokazać zalety tego podejścia.

Wróćmy do rynku pracy. Aplikujesz na ciekawe stanowiska czy raczej praca znajduje Ciebie?

Właściwie to oba. Podczas mojej ostatniej rekrutacji odpowiedziałem na kilka wiadomości wysłanych do mnie na LinkedIn, ale też samemu aplikowałem na oferty znalezione na HackerNews (posty “Who’s hiring in <miesiąc>?”), NoFluffJobs, GlassDoor, czy JustJoinIT.

Na co zwracasz uwagę zastanawiając się nad przyjęciem oferty rekrutera?

Stworzyłem listę kryteriów, którym przyporządkowałem wagi, a później oceniłem każdą z otrzymanych ofert i obliczyłem dla nich średnią ważoną, która pomogła mi w sposób analityczny wybrać najlepszą ofertę. Te kryteria to:

1. Możliwość pracy zdalnej.
2. Ciekawa tematyka produktu.
3. Wysokość podstawowej pensji.
4. Liczba dni urlopowych.
5. Możliwość wpływu na firmę/produkt.
6. Ogólne subiektywne wrażenie z procesu rekrutacji.
7. Praca w strefie czasowej EU.
8. Wysokość udziałów w firmie.
9. Lokalizacja biura (jeżeli jest wymagana praca w biurze).
10. Oferowane benefity.

Zobacz też

B2B Negocjuj każdy fragment umowy B2B. Moje doświadczenia z outsourcingu

Jakie masz zdanie o pracy za udziały. Przyjąłbyś model niższa pensja, ale z udziałami w spółce?

Jest to ciekawa opcja. Moim zdaniem to zależy od dojrzałości firmy. Jeżeli jest to spółka notowana na giełdzie i ma swoje akcje, które mógłbym spieniężyć, to traktowałbym to jako dodatkowa pensja. Podobnie w przypadku dojrzałych startupów, które niedługo mają szansę na swój exit, chociaż w tym przypadku istnieje (niskie, ale jednak) ryzyko, że ostatecznie udziały się nie spieniężą.

W mniejszych startupach nie przywiązywałbym dużej wagi do otrzymanych udziałów. Statystyki pokazują, że większość startupów upada. Oznacza to, że nasze udziały będą nic nie warte, a my pracowaliśmy za niższą stawkę, przez co efektywnie mamy mniej pieniędzy. W takich sytuacjach wybrałbym wyższą pensję, a niższe udziały. Nie oznacza to, że nie wierzę w sensowność firmy, do której przychodzę, tylko maksymalizuję moje zarobki znając prawdopodobieństwo. Jeżeli nasz startup jest w tych 10%, którym się uda, zysk z udziałów traktuję jako niespodziewany bonus, a nie coś, co oczekiwałem.

Co sprawia, że nie czujesz, że stoisz w miejscu?

Wykonywanie nowych zadań w pracy, takich, których do tej pory się nie podejmowałem albo robienie powtarzalnych zadań podnosząc sobie poprzeczkę jakości mojej pracy. Nie lubię się powtarzać, więc powtarzalne zadania staram się zautomatyzować, co jest dla mnie jednocześnie możliwością na rozwój.

Nawet jeżeli robię w teorii żmudne zadania staram się myśleć, jak mogę je zrobić lepiej i uczynić je ciekawszymi, np. poprzez dodanie do nich testów, czy refactor okolicznych fragmentów kodu.

Poza tym uczę się technologii niezwiązanych bezpośrednio z moją pracą (ostatnio języki Go oraz Rust), co jest odświeżające, a także pozwala poznać inne aspekty programowania.

Jak wyglądało Twoje przejście z Juniora na poziom wyżej? Co przyczyniło się do tego awansu?

Właściwie to w mojej pierwszej pracy zacząłem od razu ze stanowiska Regulara. Prawdopodobnie dlatego, że była to firma z trzema programistami, więc nie było polityki dotyczącej stanowisk. Technicznie byłem wtedy na poziomie Juniora. Później idąc do mojej drugiej pracy (która była korporacją ze ściśle zdefiniowanymi wymaganiami dotyczącymi stanowisk) byłem przyjęty na stanowisko Regulara. Można więc powiedzieć, że awans dostałem zmieniając pracę.

Elementy, które według mnie przyczyniły się do przyznania mi stanowiska Regulara to:

• Zdobycie doświadczenia w wielu aspektach procesu wytwarzania oprogramowania. Pracując samemu byłem odpowiedzialny za zaplanowanie pracy, pisanie kodu, a także jego wdrożenie. Nie byłem w tym ekspertem, ale miałem pojęcie jak to działa, a także poznałem wiele technologii i narzędzi.
• Dużo czasu poświęconego na programowanie i refactoring, zarówno w pracy, jak i poza pracą. Pisząc kod starałem się podnosić sobie poprzeczkę jakości jak najwyżej i z doświadczeniem wypracowywałem techniki, które działają i wyciągałem wnioski.
• Udostępnianie moich projektów publicznie. Większość kodu napisanego na studiach i w wolnym czasie udostępniam na GitHubie, co pomogło pokazać moje umiejętności.
• Sporo pochłoniętej wiedzy branżowej. W wolnym czasie śledziłem nowe wiadomości ze świata frontendu.

W jaki sposób dziś na poziomie Seniora podnosisz swoje kompetencje?

Nadal śledzę nowinki ze świata frontendu czytając newslettery (React Status, Node Weekly, TypeScript Weekly, JavaScript Weekly), a także słucham podcastów (JavaScript Jabber, PodRocket, Syntax, Frontend Happy Hour, HTTP 203, JS Party). To dostarcza mi informacji o wiadomościach z dziedziny mojej pracy. Jeżeli pojawiają się tam biblioteki, narzędzia, frameworki, których chciałbym spróbować, próbuję czynić to w pracy lub w czasie wolnym.

W pracy staram się uczyć nowych rzeczy rozwiązując zadania – nie sięgam po narzędzia, które już znam, ale widać alternatywne rozwiązanie staram się je poznać i ocenić. Szukam nowych problemów, których do tej pory w życiu nie rozwiązałem. Dzięki temu zdobywam nowe doświadczenie techniczne.

Ciekawymi wyzwaniami w pracy są te związane z aspektami miękkimi – komunikacja w zespole, spotkania 1-1 z przełożonymi / członkami zespołu, rozwój pracowników. Tutaj oprócz robienia retrospekcji z tego, co się wydarzyło w ciągu dnia i jak mogłem zachować się lepiej, pomocne są kursy i szkolenia zewnętrzne (np. Akademia Osobistego Przywództwa (nie jestem zrzeszony z EY, po prostu szkolenie przypadło mi do gustu)), a także książki (np. “Turn the Ship Around” L. David Marquet’a lub “Kapelusze myślowe” Edwarda de Bono).

Jaki masz plan na siebie? Chcesz piąć się po szczeblach technicznej ścieżki kariery czy iść w kierunku zarządzania zespołem?

Na ten moment wydaje mi się, że moim celem jest pozycja lidera technicznego. Chciałbym pozostać na ścieżce technicznej, bo widzę jak dużo wartości jestem dostarczyć w ten sposób, ale też lubię uczyć, rozwijać, planować, ogólnie mieć większy wpływ na zespół i produkt, więc chciałbym mieć też elementy miękkie w mojej pracy, ale w dużo mniejszym stopniu niż rzeczy stricte techniczne.

Do tej pory podobały mi się pozycje, na których miałem większość zadań technicznych, ale miałem też 1-1 z osobami z zespołu i pomagałem im w rozwoju. Zauważyłem natomiast, że i tam potrzebuję balansu – jeżeli podczas dnia mam więcej spotkań i komunikacji niż samodzielnej pracy głębokiej, często byłem mniej zadowolony a bardziej zmęczony.

Moja ogólna porada dla osób, które się zastanawiają nad kierunkiem swojej kariery (zazwyczaj spotykałem się z osobami technicznymi rozważającymi zarządzenie zespołem), to spróbować czasowo przejąć na siebie zadania Project Managera i zobaczyć jak to z nimi leży. Moim zdaniem jedynie doświadczenie tego na własnej skórze pozwoli na zdecydowane podjęcie decyzji, czym chcemy się zajmować bardziej w przyszłości. Warto też pamiętać, że zarządzanie zespołem jest zazwyczaj inną ścieżką kariery i nie jest naturalną progresją po osiągnięciu tytułu Seniora. Nie trzeba zostawać menadżerem, aby piąć się dalej i rozwijać, chociaż drabinka awansów może być tak skonstruowana w wielu firmach.

Grzegorz Rozdzialik. Senior Software Engineer w Splitgraph. Pasjonat programowania i technologii, od 2016 roku zawodowo zajmuje się frontendem. Po godzinach entuzjasta języka Rust. Na co dzień przykłada dużo uwagi do code review i wysokiej jakości kodu. Zawsze chętny do pomocy w wyjaśnianiu fragmentów kodu lub zapisania ich w bardziej zwięzły sposób.