Technologia to jedynie narzędzie. Opowieść z nagrodą Nobla w tle

Na początek disclaimer. W tym artykule przeczytasz moją opinię na dany temat. Bazuje ona na doświadczeniu, ale nie są to twarde fakty, a jedynie przemyślenia, więc proszę miej to na uwadze.

Świat IT ewoluuje, a wraz z nim umiejętności i kompetencje, które są niezbędne w tej pracy. Jeszcze parę lat wystarczającym było specjalizowanie się w danej technologii, natomiast obserwując rynek widać, że dzisiaj sama specjalizacja w jednym języku nie sprawi, że będziecie bardzo pożądani na rynku (z małymi wyjątkami).

Swoją karierę w dużej mierze opierałem o bazy i hurtownie danych. Ładnych parę lat temu zostałem zatrudniony jako Senior Oracle Developer. W firmie, w obszarach przetwarzania danych były jeszcze role takie jak: SQL Developer (specjalista od MS SQL Server) oraz ETL Developer – oczywiście na różnych poziomach zaawansowania: Junior, Regular, Senior oraz Technical Lead. I wiecie co? Moim zdaniem coraz mniej takich specjalizacji potrzeba na rynku. A czy tylko takich i skąd to wynika?

Nie potrzebujemy SQL/Java/.NET/Python/… deweloperów?

Tak bym nie powiedział, ale stawiam dolary przeciw orzechom, że coraz mniej będzie potrzeba specjalistów od jednej technologii. Skąd taki wniosek? Moim zdaniem (trochę upraszczając), dana technologia to jest tylko narzędzie – taki trochę bardziej skomplikowany młotek 🙂 Czy potrzebujemy specjalistów od młotków? Pewnie tak, ale raczej w fabryce, która zajmuje się produkcją młotków, a nie na placu budowy. W pracach budowlanych ten młotek jest narzędziem używanym do wykonania pewnych zadań (rozwiązania pewnego problemu). I tak też jest w IT. Język programowania to jest narzędzie, którego specjalista powinien umieć odpowiednio użyć.

To co z tą wąską specjalizacją, o której tyle się mówi?

Oczywiście dalej istnieje, ale zdefiniowałbym to trochę inaczej. Powszechnie (również w IT), taki specjalista w swojej dziedzinie nazywany jest SME (ang. Subject Matter Expert), czyli taki “wymiatacz” w swojej “działce”. Wciąż możemy mieć specjalizację na poziomie danego języka (przykładowego młotka), np. Java, Python, ale częściej będzie to jakiś obszar, np. Big Data lub produkt, np. SAP – potężne, kompleksowe narzędzie typu ERP (ang. Enterprise Resource Planning) do obsługi dużych firm.

Pomoc SME od danej technologii jest nieoceniona, jeżeli w projekcie doszliśmy do ściany i już nawet Wujek Google wymięka. Wtedy taka osoba może wejść na jakiś czas w projekt, wszystko poukładać i dalej wrócić do zgłębiania tajników swojej dziedziny. Często takie osoby kontrybuują w rozwój technologii, na których się znają i dzielą się wiedzą, udzielając się na konferencjach lub innych dedykowanych wydarzeniach.

Skoro znam się na młotkach, to wszędzie widzę gwoździe

Doświadczony SME często potrafi powiedzieć, do czego dana technologia służy, ale (co nawet ważniejsze), jakie ma minusy i do czego się nie nadaje. Niestety czasem mniej doświadczone osoby skupione wokół jednej technologii patrzą na nią przez “różowe okulary” i chcą ją stosować wszędzie jako remedium na wszystkie problemy.

Swego czasu miałem takie wrażenie jeżeli chodzi o blockchain. Skądinąd ciekawa technologia (opowiemy sobie także o niej), to w momencie kiedy było o niej głośno (ze względu na kryptowaluty), każdy wymyślał projekty oparte o blockchain i często niestety nie miało to większego sensu, ponieważ można było zastąpić to zwykłą bazą danych.

Co się zmieniło w rolach, które mamy dzisiaj?

Zanim o rolach, to trochę o oczekiwaniach. W dzisiejszych czasach potrzebujemy kogoś, kto wykona dla nas konkretne zadanie i wykorzysta do tego najbardziej odpowiednie narzędzia. A to nie jest łatwe, głównie ze względu na klęskę urodzaju jeżeli chodzi o technologie. Co więcej – technologie szybko ewoluują, pojawiają się nowe, a stare często odchodzą do lamusa.

Jako przykład, wracając do ról z początku wpisu, zamiast specjalistów od poszczególnych baz danych, dzisiaj potrzebujemy inżynierów danych (ang. Data Engineer), którzy potrafią zaimplementować proces przetwarzania danych nie tylko w oparciu o relacyjne bazy danych, ale z uwzględnieniem danych nierelacyjnych, strumieniowych (ang. streaming data) i całość osadzić np. w chmurze.

Cały czas będąc w świecie danych, coraz bardziej popularna staje się rola Data Scientist (nie słyszałem polskiego odpowiednika), która łączy język(i) programowania z wiedzą domenową o uczeniu maszynowym, co pociąga za sobą wiedzę ze statystyki. Całość wykorzystywana jest do dostarczenia nam wniosków, których sami nie bylibyśmy w stanie z danych wyciągnąć.

Kolejnym przykładem roli interdyscyplinarnej, jest tzw. DevOps Engineer, który łączy ze sobą obszar infrastruktury, dbania o ciągłość pracy, bezpieczeństwa, monitorowania i optymalizacja cyklu wytwarzania oprogramowania i wiele innych.

Teraz coś, co widać – częścej pojawiają się role nazywane Front-End Developer niż związane z konkretną technologią (językiem lub wręcz frameworkiem typu React.js czy Angular).

Na koniec, myślę wisienka na torcie – Full Stack Developer – osoba, która ogarnie nam większość warstw oprogramowania – od wyciągnięcia danych, przez logikę biznesową zaimplementowaną np. przy użyciu mikroserwisów, po ogarnięcie interfejsu użytkownika.

Zauważ, że dalej mamy specjalizację, ale w żadnej z tych ról nie mówimy o konkretnych rozwiązaniach, technologii czy języku programowania. Dobrzy specjaliści powinni umieć dobrać odpowiednie narzędzia do rozwiązania problemu, a to wymaga jego zrozumienia, czyli dodatkowo wymaga wiedzy o domenie (obszarze biznesowym lub naukowym), w której się poruszamy. I tu anegdota…

W poszukiwaniu zależności

Swego czasu uczęszczałem na studia podyplomowe z hurtowni i przetwarzania danych. Mieliśmy zajęcia z eksploracji danych (ang. Data Mining). Tak gwoli przybliżenia, to jest taka dziedzina, której celem jest znalezienie prawidłowości w danych, których nie bylibyśmy w stanie znaleźć “na piechotę”.

Zajęcia bardzo ciekawe, prowadzone przez bardzo kompetentnego profesora z dużym poczuciem humoru (nie podaję nazwiska, bo mógłby sobie tego nie życzyć i dodatkowo wiesz – RODO). No i prowadzący opowiada (z przymrużeniem oka) historię, jak to prawie dostał nagrodę Nobla (pisana z pamięci, więc wersja mocno przybliżona).

Do rzeczy. Ekipa z uczelni dostała do przeanalizowania zanonimizowane dane od kardiochirurgów, w celu poszukania nieoczywistych zależności, które odpowiedziałyby na pytanie dlaczego przy danej operacji u niektórych pacjentów pojawiają się komplikacje, a u innych wszystko przebiega bez problemu.

Idea wydaje się super, bo szukamy tutaj tzw. reguł asocjacji, czyli zależności: jeżeli A to B. Dla przykładu taką regułę można znaleźć przy produktach sklepowych: jeżeli klient kupuje piwo, to kupuje także chipsy. Na tej podstawie ustawiane są produkty w sklepach stacjonarnych lub rekomendowane w sklepach internetowych. O samej eksploracji danych opowiem Ci trochę później, ale na potrzeby opowieści to wystarczy.

Już prawie był Nobel…

No i się zaczęło. Uruchomili maszynkę, mieliła, mieliła i jest! Dostali regułę, która ewidentnie wskazuje na zależność pomiędzy wynikiem danego badania a późniejszymi komplikacjami. I tutaj wg relacji profesora, zwołał cały zespół lekarzy, który z nim współpracował, a w międzyczasie zaczął się zastanawiać, na co wyda okrągłą bańkę zielonych z nagrody Nobla 🙂

Spotkanie się rozpoczyna, profesor z dumą prezentuje wyniki, czeka na zachwyty i oklaski, a tu cisza… Nagle zabiera głos szef zespołu lekarzy i mówi, że owszem, to co zaprezentowali to wszystko prawda, ale taka zależność jest opisana w drugim rozdziale książki do kardiochirurgii dla studentów medycyny (zaraz po wstępie). Kurtyna.

Tak, technologia to jedynie narzędzie, które nie zwalnia nas ze znajomości dziedziny, w której się poruszamy. Oczywiście nie musimy sami być ekspertami w danej dziedzinie, są od tego odpowiednie osoby takie jak: analityk biznesowy, product owner, ale trochę wiedzy (a przynajmniej chęci jej poznania) o dziedzinie, którą analizujemy, nie zaszkodzi. A w ostateczności – warto wiedzieć, że tej wiedzy nam brakuje i brać to pod uwagę przy wnioskach.

Technologia się wciąż zmienia

Wracając do głównego tematu – warto znać jeden język programowania bardzo dobrze, choćby dlatego, aby nabrać doświadczenia i nauczyć się dobrych praktyk, które zdecydowanie przydadzą nam się podczas rozwijania się w innych technologiach. To, co rekomenduję – nie ograniczaj się tylko do tego jednego języka. Używaj go tam, gdzie to jest zasadne, ale bądź otwarty na inne technologie, lepiej pasujące do danego zadania.

Jeżeli jednak wolisz pracować z jedną technologią lub chcesz być specjalistą w wąskiej dziedzinie, to jak najbardziej jest to pomysł na rozwój, ale wtedy pamiętaj – musisz być ekspertem, bo to staje się Twoją domeną, a nie narzędziem. Tak jak pisałem o języku angielskim (w artykule o powszechności SQL-a). Jest stosunkowo niewiele osób zarabiających na życie, korzystając jedynie ze znajomości języka angielskiego, w porównaniu do ogółu ludzi, dla których jest to narzędzie pracy. Niemniej jednak jest to możliwe, o ile jesteśmy w tym naprawdę mistrzami!

Powyższy tekst nie jest receptą na sukces w świecie IT, ale myślę, że warto wziąć to pod uwagę, planując rozwój swojej kariery. Na każde doświadczenie w IT patrz jak na umiejętność, która pozwala Ci rozwiązać konkretny problem, a narzędzia, z których korzystasz to sprawa wtórna. Warto je znać, wiedzieć, do czego się nadają, a do czego nie, ale może się zdarzyć, że zanim poznamy je na poziomie eksperckim, to mogą być już nieaktualne.

Na końcu artykułów będę chciał umieszczać słówko z ITmowy, którego zrozumienie może być potrzebne, aby ogarnąć ten dziwny język używany przez ten świat. Osobiście staram się używać polskich odpowiedników, ale pracując w języku angielskim, czasem nawet mówiąc po polsku, używamy spolszczonych formy niektórych słów.

Słowo na dziś z ITmowy 🙂

release

wdrożenie oprogramowania na produkcję (czyli miejsce, w którym jest używane przez użytkowników końcowych)

Przykłady użycia:

Daj proszę znać czy taki słownik Ci się podoba i ma dla Ciebie wartość.