Praca w IT

Warto zatrudniać ludzi ciekawych, którzy mają odwagę pytać i eksperymentować

sebastian malaca developer

Co z perspektywy programisty z 13-letnim doświadczeniem jest ważne na rynku pracy? Jakie umiejętności nie tracą na znaczeniu? Na te i na wiele innych pytań odpowiedział Sebastian Malaca, Technical Leader, Software Architect, Trainer, Consultant, Speaker oraz autor newslettera “Let’s talk about Quality”.

“Zbyt mało mówi się o opanowaniu umiejętności i rozwiązań, które są obecnie wykorzystywane”. To zdanie padło przed naszą rozmową, ciekawi mnie jego rozwinięcie.

Nie myślę o jakichś konkretnych umiejętnościach i rozwiązaniach z nazwy, ale o tych, które stosuje się w danym projekcie. Niestety często widzę sytuację, w której developerzy zachwyceni pewnym podejściem (np. CI/CD) wdrażają je, ale nie poświęcają czasu ani na zgłębienie tematu, ani na udoskonalenie procesu czy wyciąganie wniosków w przypadku problemów. Doprowadza to do sytuacji, w której opanowujemy daną umiejętność bardzo pobieżnie i nie staramy się zrozumieć jej ograniczeń, a przez to, gdy napotykamy przeszkody, zrzucamy to na karb wybranego podejścia. Później zespoły wpadają na pomysły przepisania wszystkiego, zmiany narzędzia/podejścia/etc. na lepsze, a przede wszystkim spróbowania kolejnego nowego rozwiązania, dzięki któremu wszystko będzie dobrze. 

Zdaję sobie sprawę, że wszystko co nowe wygląda fajnie i chciałoby się z tym popracować i nabyć doświadczenia. Celem natomiast powinno być tworzenie takich aplikacji, które umożliwiają adaptację nowego w naturalny sposób (wraz z rozwojem i nowymi wymaganiami), a nie dlatego, że trzeba naprawić coś, co sami doprowadziliśmy do fatalnego stanu.

Z drugiej strony, gonienie za nowinkami i byciem “na bieżąco” jest chyba cechą pożądaną przez pracodawców. Trudno zatrudnić osobę, która nie wie co się dzieje w branży. Zgadzasz się z tym stwierdzeniem?

Dobrze jest wiedzieć, co się dzieje w branży, jakie są nowe trendy oraz rozwiązania – dzięki temu Twój wachlarz rozwiązań powiększa się. Czy to jednak oznacza, że wszystkiego powinienem wypróbować i przetestować? Czy powinienem tego oczekiwać od innych? Szczerze mówiąc, wydaje mi się to niewykonalne. Czy jestem w stanie poświęcać w tygodniu kilka godzin na sprawdzanie nowych rzeczy? Myślę, że z różnych powodów, wiele osób jednak tego czasu nie posiada. Załóżmy jednak, że się uda. Czy jestem w stanie w domu, na swoim sprzęcie, doprowadzić do sytuacji, z którymi będę mierzył się na co dzień, gdy aplikacja na produkcji będzie wykorzystywała testowane rozwiązanie? Raczej mało prawdopodobne.

Uważam, że warto zatrudniać ludzi ciekawych, którzy mają odwagę pytać i eksperymentować. Takich, którzy są w stanie znajdować w codziennej pracy zastosowanie dla nowych rozwiązań.

Takie podejście przenosi jednak sporo odpowiedzialności na firmę/managerów/liderów – trzeba budować środowisko pracy, które pozwala na rozwój i równocześnie uczy, jak minimalizować ryzyko wprowadzając nowości.

Jak budować takie środowisko? Czego potrzebuje zespół, by nie bać się pytać i eksperymentować?

Trzeba pokazać, że takie zachowanie jest pożądane. Z racji tego, że pytanie oznacza demonstrację, że się czegoś nie wie, a eksperymentowanie może skończyć się porażką, tym ważniejsze jest, żeby liderzy/seniorzy/etc. sami prezentowali takie zachowania. Zdaję sobie sprawę, że stwierdzenie “lead by example” może wydawać się nieco banalne, ale w tej konkretnej sytuacji jest to naprawdę istotne. 

Łatwo nabyć zachowania, których rezultatem jest sukces. Trudniej jest to zrobić, gdy pokazujemy, że nam nie wyszło, nie udało się, nie wiemy. Stworzenie jednak atmosfery zaufania, gdzie nie boimy się próbować, gdzie nie czekamy z pytaniami, sprawia, że finalnie ludziom pracuje się lepiej, a nasze produkty są stabilniejsze i dostarczane szybciej.

Takie środowisko da się zbudować w każdej organizacji? W startupie, firmie produktowej, software housie czy korporacji?

Na pewno nie w każdym miejscu jest to możliwe, ale raczej nie wydaje mi się, że kwestią determinującą sukces jest typ organizacji. Zależy to mocniej od charakteru i umiejętności osoby/osób, które chcą takie środowisko stworzyć oraz od tego, jak na takie zmiany patrzy organizacja. Często jest to długi i trudny proces. Natomiast zawsze niezmiernie satysfakcjonujący i dostarczający sporo nauki.

Co znajduje się na Twojej liście umiejętności, bez których dziś ciężko o pracę na wysokim stanowisku w działach IT / Product Engineeringu?

Jest kilka takich umiejętności:

  • projektowanie architektur, które umożliwiają rozwój systemów – to jest bardzo szeroki temat i wiele różnych technik można wykorzystać, aby osiągnąć ten cel. Uważam jednak, że osoba na wysokim stanowisku powinna być w stanie poprowadzić zespół ku rozwiązaniom, które będziemy w stanie utrzymywać przez lata,
  • testowanie – jeżeli rozumiesz, czym są dobre testy oraz jesteś w stanie tą wiedzę przekazać to sporo rzeczy (m.in. dobry kod, który można rozwijać) otrzymujesz jako wynik tej praktyki,
  • komunikacja – trzeba umieć słuchać oraz dostosowywać formę wypowiedzi do rozmówcy, tak aby zrozumiał to, co chcemy przekazać,
  • przekazywanie wiedzy – im więcej wiedzą ludzie, z którymi pracujesz, tym więcej jesteście w stanie osiągnąć,
  • ciągłe doskonalenie – szukanie miejsc, gdzie warto zainwestować w poprawę oraz brak strachu przed ewentualną porażką. Niezależnie czy mówimy o systemie, o zespole czy własnej osobie.

Myślisz, że te umiejętności będą kluczowe także za rok, za pięć czy za dziesięć lat?

Dopóki będziemy tworzyć kolejne systemy, utrzymywać obecne oraz otrzymywać wymagania, które nie są idealne – tak, myślę, że będą kluczowe.

Jak te umiejętności rozwijać?

Moją preferowaną “drogą” odnośnie wszystkich wspomnianych umiejętności jest stosowanie poniższych kroków (kolejność przypadkowa):

  • książki/tutoriale/filmy – dzięki temu jestem w stanie zaznajomić się z teorią i dostępnymi narzędziami oraz dowiedzieć się, dlaczego rzeczywiście powinny zadziałać oraz w jakich sytuacjach powinienem czy też nie powinienem z nich korzystać,
  • rozmowy – szukam ludzi, którzy wiedzą dużo i są specjalistami w swojej dziedzinie. Zadaję im pytania i po prostu słucham, 
  • eksperymentowanie – ważne jest znalezienie miejsca, w którym możesz próbować i możesz otrzymać feedback, niezależnie od wyniku. Dzięki temu uczysz się, jak eksperymentować bezpieczniej, a co za tym idzie robisz to częściej, i tym więcej wiesz o korzyściach oraz kosztach danych narzędzi.

Co w Twojej ścieżce kariery dało Tobie największego boosta? Może był projekt, który sprawił, że będąc juniorem poczułeś się, jak mid?

Szczerze mówiąc, miałem (i mam) to szczęście, że zawsze udaje mi się spotkać w projekcie lub firmie kilka osób, które są mnie w stanie sporo nauczyć.

Jeżeli miałbym wskazać jednak jedną rzecz, to decyzja o prowadzeniu szkoleń było jedną z tych, które w perspektywie lat pozwoliły rozwinąć się technicznie, poznać świetnych ludzi i pomóc im radzić sobie z ich problemami. Dało mi to także możliwość nieustannego odnajdywania nowych sposobów patrzenia na stojące przed nami wyzwania oraz nauczyło wiele na temat komunikacji oraz interakcji z innymi. To są naprawdę bezcenne doświadczenia.

Czym dawniej kierowałeś się wybierając dany język programowania do realizacji projektu, a czym kierujesz się dzisiaj?

Na początku kariery kierowałem się przede wszystkim tym, co uważałem w danym momencie za interesujące do nauki. Bardzo szybko dowiedziałem się, że istotniejsze jest to, jak dany język może pomóc (bądź utrudnić) rozwiązywanie danego problemu.

Obecnie tych czynników jest dużo więcej. Dlatego najpierw dowiaduję się, czy jest to odpowiednie narzędzie do problemu. Po drugie, czy mamy w projekcie wiedzę na temat danego języka. Ewentualnie, czy wewnątrz firmy możemy uzyskać pomoc? Jak długo zajmie nam nauka nowego? Jak istotny jest dany element projektu? Czy rzeczywiście inwestycja jest warta zachodu? 

Im więcej lat za mną, tym więcej zadaję sobie i zespołowi nie-stricte-techniczne pytania. Co ważne, na każde z nich trzeba odpowiedzieć, zanim podejmie się decyzję o wyborze technologii.

Od lat piszesz w Javie, prowadzisz też newsletter skupiony na jakości kodu. Dlaczego Twoim zdaniem warto zainteresować się Javą? Czy to przyszłościowy język?

W momencie gdy decydowałem się na Javę, był to z pewnością jeden z najpopularniejszych języków programowania. Stąd mój wybór. Obecnie jednak jestem chyba coraz mniej “związany” z konkretnym językiem. Java, jak każde narzędzie, ma swoje ograniczenia, ale i plusy.

Czy jest to przyszłościowy język? Wydaje mi się, że w najbliższych latach Javowcy raczej mogą spać spokojnie. Przede wszystkim jednak uważam, że paradygmat obiektowy jest przyszłościowy – odpowiednio wykorzystany (przy umiejętnie użytych jego głównych założeniach), pozwala zmniejszyć próg wejścia do projektu i zrozumienia domeny.


Sebastian Malaca. Doświadczony architekt i lider specjalizujący się w programowaniu i projektowaniu obiektowym oraz technikach i praktykach pozwalających tworzyć kod wysokiej jakości. Głównymi obszarami jego zainteresowań jest praktyczne wykorzystanie refaktoryzacji, testowania oraz technik wytwarzania oprogramowania w pracy z istniejącym kodem zarówno na poziomie pojedynczych klas jak i całych aplikacji. Jest również prelegentem (JDD, GeeCon, Confitura, Devoxx, etc.), blogerem (Let’s talk about Java, DZone, JavaCodeGeeks) oraz trenerem i konsultantem.

Redaktor naczelny w Just Geek IT

Od pięciu lat rozwija jeden z największych polskich portali contentowych dot. branży IT. Jest autorem formatu devdebat, w którym zderza opinie kilku ekspertów na temat wybranego zagadnienia. Od 10 lat pracuje zdalnie.

Podobne artykuły

[wpdevart_facebook_comment curent_url="https://geek.justjoin.it/warto-zatrudniac-ludzi-ciekawych/" order_type="social" width="100%" count_of_comments="8" ]