Szeroki stack technologiczny ogranicza organizację. Historia Jacka Kościeszy

Co po piętnastu latach doświadczenia w branży Jacek Kościesza, Principal Software Engineer w Code & Pepper doradza innym? – Bardzo istotne jest poznanie różnych technologii i nie zamykanie się w dogmatycznym myśleniu. Powinno się dużo eksperymentować i wybierać właściwe narzędzie do danego zadania – powiedział w rozmowie z nami. Poznajcie historię Jacka, który dziś w Code & Pepper pełni również rolę Tech Leadera.

Blockchain, AWS, UX i inne możliwości na rozwój

O jakim elemencie pracy programisty Twoim zdaniem mówi się za mało?

Mało się mówi o tym jak dużo trzeba się uczyć, żeby nadążyć za wciąż zmieniającą się technologią. Nowe biblioteki, frameworki, funkcjonalności języka programowania, serwisy w chmurze czy nawet całe działy informatyki jak AI/ML, czy quantum computing. Bycie “na bieżąco” wymaga sporo czasu poświęconego na czytanie postów blogowych, oglądanie konferencji czy własne eksperymenty. Istotne jest, żeby pracodawca rozumiał jak ważny jest rozwój programisty i dawał czas (w ramach pracy) na taką naukę. Programista natomiast musi mieć jakiś plan czego i jak się uczyć oraz jak wykorzystać tę wiedzę w projektach i jak podzielić się tą wiedzą z innymi.

Powiedziałeś, że pracodawca powinien dawać czas w ramach pracy na naukę. Ta informacja często pojawia się w ogłoszeniach, ale jak wygląda w rzeczywistości? Jak będąc programistą zaplanować czas na rozwój?

W Code & Pepper stawiamy na jakość, dlatego wsparcie inżynierów w doskonaleniu swoich umiejętności jest jednym z priorytetów. To wsparcie ma wiele form, poczynając od zapewnienia dostępu do platform edukacyjnych, takich jak PluralSight czy Geekle oraz comiesięcznych firmowych spotkań, gdzie ochotnicy dzielą się wiedzą na dany temat techniczny, aż po właśnie zapewnienie czasu na naukę nowej technologii czy robienia researchu. Przed rozpoczęciem fazy developmentu w projekcie, mamy zwykle fazę preparation oraz UX/UI design. To jest właśnie ten moment, kiedy programiści mają sporo czasu na zrobienie researchu dotyczącego najlepszych rozwiązań oraz technologii czy nauczenia się rzeczy, z którymi nie mieli do czynienia, a będą potrzebne w projekcie.

Zdarza się, że w samym projekcie zakładamy mniejszą wydajność programisty (oczywiście klient ma też odpowiednio zredukowaną stawkę za taką osobę), ponieważ uczy się nowej technologii. Planujemy też zorganizowanie wewnętrznego projektu dotyczącego Blockchain, żeby zdobyć praktyczne doświadczenie z tą technologią. Ważną rzeczą związaną z planowaniem nauki (w pracy) jest ustalenie zakresu i potrzebnego czasu ze swoim przełożonym. Tu nie chodzi tylko o uzyskanie pozwolenia, ale wzajemne uświadomienie sobie korzyści, transparentność, pomoc w znalezieniu mentora, czy takie przeorganizowanie projektu, żeby ten czas znaleźć. Polecam też zarezerwowanie przestrzeni w kalendarzu firmowym (żeby ktoś nie “wrzucił” Ci spotkania w tym czasie), przygotowanie planu nauki, zapisanie się na konferencje (np. Chrome Dev Summit, Microsoft Build) oraz robienie notatek (np. ja ostatnio zrobiłem 60 stron notatek z konferencji AWS re:Invent).

Masz doświadczenie w pracy zarówno w małych i dużych firmach oraz w startupie. Który z tych rodzajów firm poleciłbyś początkującemu programiście?

Wszystkie trzy doświadczenia były bardzo cenne i razem pozwalają nabrać odpowiedniej perspektywy. Wybór pomiędzy startupem a korporacją wymaga pewnej analizy. Co jest dla ciebie najlepsze jest często podyktowane twoim charakterem oraz tym na jakim etapie jesteś w swoim życiu. Szybko się nudzę, więc preferuję szybko zmieniające się środowisko charakterystyczne raczej dla mniejszych firm i startupów. Etap dużych korporacji był natomiast istotny, gdy urodziły się moje dzieci i potrzebowałem spokojniejszego i stabilnego środowiska pracy, gdzie nie jesteś niezastąpiony i możesz spokojnie wziąć np. urlop ojcowski.

Na początek polecałbym raczej wybrać małą firmę lub startup. Takie środowisko bardziej sprzyja szybkiej nauce. Brak biurokracji, możliwość eksperymentowania czy płaska hierarchia z większą odpowiedzialnością spoczywającą na pojedynczej osobie przyspiesza rozwój programisty. U mnie ważnych etapem był też własny startup, który sprawił, że zacząłem się bardzo intensywnie uczyć nowych rzeczy i ta potrzeba zostanie mi już chyba na całe życie. Własny startup polecam założyć, gdy się jeszcze nie ma dzieci i kredytów na mieszkanie, czy dom.

Jak dzisiaj wykorzystujesz doświadczenia uzyskane z pracy nad własnym startupem? Warto było zainwestować czas w swój projekt?

Praca nad własnym startupem to ciężkie, ale równocześnie bezcenne doświadczenie. Przenosi twój stopień dostosowywania się do sytuacji, szybkości nauki oraz organizacji czasu na zupełnie inny poziom. Pozwoliło mi to zrozumieć czym jest MVP (Minimum Viable Product), jak istotne jest szybkie zweryfikowanie pomysłu z prawdziwymi użytkownikami oraz trzymanie w ryzach tysięcy pomysłów na ulepszenia, czy to związane z funkcjonalnością, czy architekturą rozwiązania. Tę wiedzę często wykorzystujemy w C&P przy okazji spotkań i warsztatów z klientami.

Potrafimy szczerze porozmawiać z klientem i zasugerować, że może funkcjonalność X nie jest niezbędna w wersji 1.0, a zamiast niej zróbmy funkcjonalność Y, a X przesuńmy na wersję 2.0. Podobnie jest z architekturą rozwiązania, nie zawsze trzeba od początku przygotowywać swój projekt MVP na ruch podobny do Facebook’a, SLA na poziomie 99.99%, czy rozwiązanie multicloud. Wiemy jak takie rzeczy robić, ale to wszystko kosztuje i zajmuje czas, dlatego tak bardzo ważne jest uświadomienie sobie tych rzeczy i podjęcie świadomej decyzji.

Praca i rozwój programisty okiem lidera technologicznego

Jaka cecha, a może umiejętność jest Twoim zdaniem kluczowa w pracy programisty?

Do bycia programistą trzeba mieć pewne predyspozycje, takie jak umiejętność analitycznego, abstrakcyjnego myślenia czy umiejętność podzielenia złożonego problemu na mniejsze. Kluczową cechą, która wyróżnia bardzo dobrych programistów, moim zdaniem jest ciekawość oraz siła wewnętrznej motywacji, która powoduje, że chcesz więcej. Żeby się doskonalić musisz czuć wewnętrzną potrzebę, aby dogłębnie poznać daną technologię, aby nieustannie zastanawiać się jak coś zrobić lepiej albo chcieć natychmiast spróbować nowej rzeczy, o której właśnie się dowiedziałeś z konferencji.

Mam wrażenie, że niewielu juniorów rozumie potrzebę podejmowania się coraz trudniejszych wyzwań w pracy. Podzielasz to zdanie? Jak myślisz, z czego może wynikać to podejście?

Wydaje mi się, że to kwestia stworzenia odpowiedniego środowiska i kultury pracy. Ważny jest produkt, nad którym się pracuje – trzeba mieć poczucie, że buduje się coś fajnego i że stawiamy na jakość. Ważny jest też sam zespół i organizacja pracy. Potrzebna jest przestrzeń na naukę, research, eksperymenty i dyskusje. Każdy członek zespołu, czy to doświadczony senior, czy początkujący junior powinien być równoprawnym członkiem zespołu. U nas w C & P każdy jest zaangażowany w code review, pisanie testów, zadania researchowe, czy dyskusje i podejmowanie decyzji np. na temat najlepszych praktyk. To wszystko powoduje, że junior uczy się samodzielności przy indywidualnych zadaniach, nie boi się, że utknie, bo zawsze może liczyć na pomoc zespołu. Uczy się również od innych członków zespołu, aby następnym razem móc wykonać bardziej skomplikowane zadania samodzielnie.

W jaki sposób Ty zwiększasz odpowiedzialność w projekcie osobie z mniejszym doświadczeniem od pozostałych członków zespołu?

W C & P bardzo cenimy full stack developerów, dlatego zachęcamy i dajemy możliwość rozwijania się zarówno na backendzie, jak i frontendzie. Trochę ułatwia to fakt, że naszym głównym językiem programowania jest TypeScript, którego używamy na frontendzie (np. z React), backendzie (Node.js), jak i do kodowania infrastruktury w chmurze (np. AWS CDK). Mamy dedykowanego QA’a, który tworzy automatyczne testy E2E (Cypress), ale każdy developer jest odpowiedzialny za pisanie automatycznych unit/integration/component testów. Mamy dedykowanego DevOps’a, ale każdy developer jest odpowiedzialny za podejście IaC (Infrastructure as a Code) związane ze swoją częścią backendu.

Dyskutujemy zespołowo na temat najlepszego podejścia, poruszamy tematy wydajności, bezpieczeństwa, monitorowania infrastruktury czy kosztów użycia danego serwisu w chmurze. Przy okazji startu nowego projektu, często każdy członek zespołu – również juniorzy są zaangażowani w proces decyzyjny dotyczący np. wyboru technologii. Takim przykładem może być ostatnio robiony przez nas szybki research dotyczący wyboru klienta GraphQL – co będzie najlepsze do nowego projektu: Apollo Client, Relay, czy może Amplify.

Zadania Principal Software Engineera

Jakiego rodzaju decyzje podejmujesz dzisiaj?

Najważniejsze to te dotyczące wyboru kierunków technologicznych w C & P. Do tej pory mieliśmy dosyć szeroki stack technologiczny, co nie było zbyt optymalne dla firmy tej wielkości. Ograniczało to możliwości eksperckiego poznania danej technologii, dzielenia się wiedzą, czy szybszego developmentu na bazie poprzednich doświadczeń. Dlatego właśnie podjąłem decyzję o zawężeniu stacku i skupieniu się na React, React Native, TypeScript, Node.js i chmurze AWS. Na poziomie projektów często podejmuję decyzje związane z architekturą. Uczestniczę w procesie rekrutacji nowych inżynierów, więc często podejmuję decyzję, czy od strony technicznej dany kandydat spełnia nasze oczekiwanie, czy też nie.

Co zazwyczaj wpływa na to jaki stack technologiczny będzie użyty w projekcie? Zawsze opierasz się na swoich doświadczeniach, przeczuciach, branżowych predykcjach?

Decyzje najlepiej podejmować na podstawie twardych danych. Przeczucie to zwykle nie jest najlepszy doradca, a żeby dobrze zgadywać, to trzeba mieć dużą wiedzę. Decyzje dotyczące kierunków technologicznych zapadły po gruntownej analizie światowych trendów, a następnie trendów w branży FinTech. Analizowaliśmy np. stack technologiczny popularnych firm FinTech’owych, sprawdzaliśmy ich ogłoszenia o pracę dla developerów. Tutaj istotne jest unikanie pułapki swoich prywatnych preferencji, dlatego tak istotne jest szerokie doświadczenie architektów.

Czasem też konieczne są pewne kompromisy np. jeśli chodzi o technologie mobile podjęliśmy decyzję, że będziemy używali React Native, żeby wykorzystać nasze doświadczenia z React, mimo że np. Flutter jest bardzo kuszącą alternatywą. Generalnie każda technologia ma swoje plusy i minusy, nie ma uniwersalnego dobrego wyboru. Istotnym czynnikiem jest też łatwość znalezienia i zatrudnienia nowych ludzi znających wybraną technologię. Decyzje dotyczące architektury w projektach podejmujemy po wnikliwej analizie wymagań, zwłaszcza nie-funkcjonalnych, takich jak wydajność, bezpieczeństwo, czy niezawodność. Wybór kto dołączy do zespołu C & P podejmujemy na podstawie wielu czynników – poprawność rozwiązania zadania programistycznego, culture fit, komunikacja w języku angielskim, doświadczenie. Zwykle co najmniej trzy osoby rozmawiają z kandydatem i wspólnie podejmujemy decyzję.

Z doświadczenia Code & Pepper

Jakie błędy popełniliście w Code & Pepper w tej kwestii? Z czego wynikały?

Do niedawna mieliśmy zbyt szeroki stack technologiczny. Wynikało to z kilku czynników. Nowe projekty robiliśmy w technologiach, w których mieliśmy największe doświadczenie np. Angular, .NET. Ciągnęły się stare projekty w technologiach, które nie są już na topie np. PHP. Niektórzy klienci mieli swoje preferencje dotyczące technologii, a my byliśmy za mało asertywni. To doprowadziło do mało optymalnej sytuacji z punktu widzenia developmentu. Inny błąd, za który byłem osobiście odpowiedzialny, to np. zbyt lekkomyślne pójście od razu w architekturę mikroserwisów (zamiast np. modularnego monolitu), w projekcie, który nie miał stabilnych i dobrze zdefiniowanych wymagań.

Były też błędy polegające na braku jednoznacznego komunikatu dla klienta, że ma nierealistyczne oczekiwania dotyczące deadline’u i że przy tych wymaganiach nie da się tego zrobić w tym czasie. Moim zdaniem zabrakło też referencyjnego, open source’owego projektu, na którym moglibyśmy zdobyć doświadczenie w obszarach takich jak AI/ML, czy Blockchain. Na szczęście ze wszystkich tych błędów wyciągnęliśmy wnioski i już ich nie popełniamy.

Co dziś uważasz za najtrudniejszy element w pracy na stanowisku Principal Software Engineera?

Trzeba się nauczyć bardzo szybko zmieniać kontekst tego co się robi i dobrze sobie organizować czas. Na co dzień mam bardzo dużo spraw do załatwienia – od np. sprawdzania na bieżąco zadań rekrutacyjnych po przeprowadzanie rozmów rekrutacyjnych (kilka w tygodniu). Jako tech leader podejmuję też decyzje związane z architekturą i przedstawiam je klientowi. Przeprowadzam także rozmowy z potencjalnymi nowymi klientami, doradzam i rozwiązuję bieżące problemy w projektach, robię code review. Gdzieś pomiędzy tym wszystkim i wieloma spotkaniami w ciągu dnia, trzeba znaleźć jeszcze czas, żeby się uczyć nowych rzeczy albo przygotować się do certyfikacji i egzaminu np. z AWS’a.

O pracy doświadczonego programisty i tech leadera – podsumowanie

Co po piętnastu latach zmieniłbyś w swojej ścieżce kariery?

Mam poczucie, że mogłem więcej zrobić w okresie studiów i w pierwszej pracy. Tym co mnie najbardziej interesuje, czyli web developmentem, zająłem się dopiero przy okazji własnego startup’u, czyli jakieś 2,5 roku po studiach. Wcześniej, w pierwszej mojej pracy, zajmowałem się systemami embedded (VoIP phones, embedded Linux itp.). Gdybym wcześniej poznał więcej technologii, może szybciej odkryłbym to co mnie najbardziej interesuje. Żałuję też trochę, że nie wyjechałem na jakąś wymianę studencką za granicę czy nie zacząłem pracować jeszcze w okresie studiów. Trochę też zbyt późno zacząłem dogłębnie uczyć się chmury.

Co te doświadczenia zmieniły w Twoim podejściu do tworzenia oprogramowania? Stare prawdy typu “dbaj o jakość kodu” tracą czy nabierają na znaczeniu?

Zdecydowanie stają się bardzo ważne, bo na własnej skórze odczułem skutki lekceważenia tematów jakości kodu, braku testów, bezpieczeństwa, wydajności, czy nie myślenia o disaster recovery. Bardzo istotne jest poznanie różnych technologii i nie zamykanie się w dogmatycznym myśleniu. Powinno się dużo eksperymentować i wybierać właściwe narzędzie do danego zadania. Przykładem może być tutaj podejście polyglot persistence, które polega na używaniu potencjalnie wielu baz danych w projekcie, w zależności od potrzeb. W AWS’ie jest około 15 różnych baz danych, więc jest z czego wybierać, a każda z tych baz ma swoje wady i zalety.

Każdy czasem podejmuje złe decyzje, sztuką jest je szybko zweryfikować, przyznać przed samym sobą, że to nie jest najlepsza droga i wybrać co innego. Nie należy też zbytnio komplikować rzeczy i trzymać się reguły KISS (Keep It Simple, Stupid) oraz YAGNI (You Aren’t Gonna Need It), ale równocześnie tak zaprojektować np. architekturę, żeby łatwo było ją rozbudować po fazie MVP. Wreszcie tworzenie oprogramowania to nie tylko programowanie. Niezwykle istotny jest sam proces, dobry PO (Product Owner), PM (Project Manager), czy zarządzanie ryzykiem w projekcie. To jest coś czego trzeba doświadczyć, żeby docenić. Jak mawia Andy Jassy – CEO AWS’a, a niedługo całego Amazon’a – “There is no compression algorithm for experience”.

---

Jacek Kościesza. Principal Software Engineer w Code & Pepper. Ekspert technologiczny z około 15-letnim doświadczeniem w branży IT. Doświadczenie zdobywał w małych firmach, dużych korporacjach oraz własnym startupie. Odpowiada za wyznaczanie kierunków technologicznych w firmie. Na co dzień zajmuje się projektowaniem architektury rozwiązań, estymacją projektów, byciem liderem i mentorem w projektach oraz wsparciem przy rozmowach z potencjalnymi klientami. Duża część jego obowiązków to również śledzenie najnowszych trendów, eksperymentowanie z nowymi technologiami oraz przeprowadzanie rozmów kwalifikacyjnych.

Oferty pracy z