Jak w 1.5 miesiąca wyszkolić juniorów Big Data? Case Study

Jak w 1.5 miesiąca wyszkolić juniorów Big Data? Case Study

Idea jest prosta. Rekrutujesz osoby z podstawową wiedzą. Nie, nie Big Datową. Podstawową wiedzą z IT. Na przykład studentów. Następnie poddajesz ich odpowiedniemu szkoleniu. Po 1.5-2 mies. kursanci zaczynają przygodę w projekcie. Niemożliwe? Możliwe, o ile kilka kroków będzie solidnie zrealizowanych. Takie podejście to prawdziwe wybawienie w obliczu trudnodostępnych fachowców.

Jak pozyskać inżynierów Big Data? Nie pozyskuj – ukształtuj!

Wiele firm inwestuje obecnie w Big Data. I tyleż samo firm doświadcza problemów z pozyskaniem pracownika. Z jednej strony stawki które kandydaci sobie życzą potrafią być zawrotne. Z drugiej strony, po odpowiednim sprawdzeniu często wychodzi, że kandydat mimo pewnego doświadczenia (wyrażonego w stażu pracy), nie dysponuje szczególnie imponującą wiedzą. Mówiąc delikatnie;-). Pytanie stare jak polska polityka: “Jak żyć?”.

Odpowiedź, którą chcę dzisiaj przytoczyć, nie będzie absolutnie pełna. I nie zastąpi to poszukiwania specjalistów na wakat seniora czy mocnego mida. Przykro mi. Chcę jednak zwrócić uwagę na coś, co często umyka wielu firmom, a co może być uzupełnieniem tego trudnego procesu, jakim jest budowa kompetentnego zespołu.

Może zamiast pozyskiwać ludzi, postawić na ich wykształcenie?

W skrócie wygląda to tak, jak napisałem we wstępie. Pierwszy plus: znaleźć kogoś z niezłymi umiejętnościami (o tym jakimi, napiszę jeszcze potem) nie jest ciężko. Kolejny plus: przed projektem naprawdę wiemy, jakie przygotowanie ma pracownik (gdy zatrudniamy, zawsze to pewna niewiadoma). Wreszcie największy plus: nie szukamy idealnego kandydata pod projekt. Możemy go wykształcić w konkretną stronę. Oczywiście szkolenie powinno być przekrojowe i dawać ogólne pojęcie. To jednak jakie technologie będą wykładane, zależy głównie od firmy. To jakby zamiast kupować buty z półki – zamówić uszyte pod konkretny bieg.

Przygotowanie i przeprowadzenie takiego szkolenia ma kilka etapów. Jako, że niedawno zakończyłem jedno z nich, zanurzmy się w kolejne etapy, sprawdzając “jak to się robi” na konkretnym przykładzie.

Faza wstępna – określenie celu i rekrutacja

Zanim cokolwiek się zacznie, trzeba się przygotować. To dość logiczne – bez kursantów szkolenie może przynieść niesatysfakcjonujące efekty. W związku z tym należy zrobić dwie rzeczy:

  1. Określić po co chcemy kursantów
  2. Zrekrutować przyszłych wojowników.

W punkcie pierwszym, mamy do czynienia przede wszystkim z wybraniem projektu, lub paru projektów, w których potrzebujemy solidnych juniorów. Dzięki temu będziemy znali zakres technologiczny. Warto zadać sobie takie pytania jak:

  1. Jakie technologie są wykorzystywane w projekcie? (wypisujemy wszystkie)
  2. Które technologie są używane w jakim stopniu? (z jednych korzysta się czysto użytkowo i doraźnie, inne są rdzeniem projektu)
  3. Jakie języki programowania są w użyciu?
  4. Które z wyżej wymienionych chcemy, aby znali kursanci? Przy tym pytaniu warto się zatrzymać, bowiem korci żeby “napchać ile wlezie”. Lepiej jednak dość dużo obciąć, co przełoży się na lepsze opanowanie materiału.
  5. Czy są inne aspekty technologiczne, które chcemy dodać? Na wszelki wypadek, lub dla uniknięcia zbyt wąskiego wyszkolenia (można dodać tutaj ogólną wiedzę np. z technologii cloudowych).

W punkcie drugim wybieramy konkretne osoby. Co na pewno muszą aplikujący?

  1. Znać podstawy języka – najlepiej ogólnie rzecz biorąc, znać podstawy javy, jako fundamentu Big Data (choć są od tego wyjątki oczywiście).
  2. Mieć opanowane podstawy relacyjnych baz danych
  3. Znać podstawy linuxa oraz sieci. Tu chodzi o naprawdę proste rzeczy, jak połączeni po SSH, posługiwanie się bashem.
  4. Rozumieć o co chodzi w GIT.
  5. Wiedzieć, na co się piszą;-).

W przypadku ostatniego szkolenia, języki to była java i scala (przy czym scalę poznali już na szkoleniu). Dodatkowo kursanci dostali bardzo mocny przekrój technologiczny. Nie chcę wymieniać wszystkiego, natomiast m.in. pojawiły się:

  1. Hadoop + Hive
  2. Spark
  3. Airflow
  4. Ogólne warsztaty ze streamingu
  5. HBase
  6. Jenkins

Tyle wystarczy na dobry początek. Aha! Warto wspomnieć, że tego typu szkolenie raczej nie powinno być masówką. Tutaj były to zaledwie 2 osoby, może to być 3,4, maksymalnie 5 osób (chociaż 5 to już dość dużo). Dodatkowo były to osoby z różnych miejsc w Polsce – całość szkolenia była przeprowadzona on-line.

Czas ruszyć na samo szkolenie!

Szkolenie Big Data, wykład z wprowadzenia do Big Data

Warsztaty

Zasadniczo samo szkolenie składa się z dwóch części. Pierwsza z nich to właśnie warsztaty. Podstawowy cel: poznać technologie. Każdy dzień to fundamenty jednej technologii. No dobrze – niekiedy dwa dni. Wszystko zależy od ilości całego materiału:-).

Warsztaty mają następującą strukturę: rano zaczynamy dzień od wykładu, który wprowadza w temat konkretnej technologii. Następnie kursanci mają cały dzień na wykonywanie ćwiczeń, które zlecił im instruktor. W tym czasie instruktor jest dostępny, ale nie bierze aktywnego udziału w ćwiczeniach. Wieczorem (albo popołudniem – zależy od pory roku;-)) wszyscy spotykają się, żeby przegadać wątpliwości które się pojawiły, omówić ćwiczenia itd. Takie podsumowanie dnia.

Omawiane szkolenie zaczęliśmy od krótkiego wstępu do Big Data. Osobiście jestem fanem przechodzenia od ogółu do szczegółu. No i spoglądania na szerszy kontekst. O ile potem jest czas na zanurzenie się w technikaliach, o tyle warto ciągle mieć świadomość częścią jak wielkiego świata jesteśmy. Znacznie więcej opisywałem tego w ebooku – zachęcam do zajrzenia. Kursanci odsłuchali prezentacji, następnie ustaliliśmy wspólnie kształt całego szkolenia, które przejdą. Przestrzegłem przed kluczowymi rzeczami i… ruszyliśmy do akcji!

Jeszcze pierwszego dnia zrobiliśmy krótki warsztat z gita. Chociaż oboje znali już podstawy, pokazałem jak to się robi w projektach komercyjnych. Po co stosujemy system kontroli wersji i w jaki sposób go używać.

Kolejne 2.5 tygodnia upłynęły na poznawaniu technologii w przyspieszonym tempie. Szczerze przyznam, że poradzili sobie wyśmienicie. To był pierwszy raz, gdy dostawałem od kursantów zrobione prawie wszystkie zadania dzień w dzień. Fakt jest jednak taki, że taki sprint wyczerpuje i nie zawsze wszystko uda się skończyć. Dlatego pod koniec zostawiłem jeden “dzień wolny”. Tym bardziej, że warsztaty z Elastic Searcha postanowiłem połączyć z HDFSem i Sparkiem;-). Naprawdę przekrojowo, ale dali radę wyśmienicie!

Zacny zespół. Nawet bardzo;-).

Projekt

Gdy dokończyliśmy poznawanie fundamentów technologicznych, przyszedł czas na najciekawszy kąsek. W czwartek spotkaliśmy się i zaczęliśmy… projekt. Tak – prawdziwy projekt. Właściwie to taka miniaturka projektu komercyjnego. Z githubem, na klastrze szkoleniowym RDF, z metodyką pracy i – co ważniejsze – konkretnym celem biznesowym.

Infrastruktura szkoleniowa

Sam klaster odgrywał pewną rolę już wcześniej, na etapie warsztatów. Przygotowałem go specjalnie na potrzeby szkoleń. Każdy z kursantów ćwiczy dzięki temu w warunkach ekstremalnie zbliżonych do rzeczywistych. To klaster złożony z dwóch nodów (serwerów), które pracują w chmurze. Jest na nich Hadoop, Spark, Elasticsearch i czego tylko dusza zapragnie (nawet Hue!).

Poniżej możesz obejrzeć wideo, w którym dość szczegółowo opowiadam o tym na czym pracują kursanci RDF i dlaczego akurat tak;-).

Organizacja projektu

Co ważne, kursanci dostają konkretne wymagania biznesowe projektu. To w założeniu ma być system, który mógłby mieć zastosowanie w biznesie czy R&D. Oczywiście niekoniecznie pełny, bardziej PoC, ale grunt że wiemy dokąd dokładnie zmierzamy i dlaczego.

Dodatkowo kursanci pracują w ramach uproszczonego scruma. Mamy swojego boarda z taskami, mamy codzienne spotkania, całość następuje przyrostowo. W ten sposób pierwsze zderzenie z uporządkowanym systemem pracy jest jeszcze przed wejściem do prawdziwego, komercyjnego projektu.

Oczywiście wdrożony jest także cały system pracy z kontrolą wersji. Jest praca z branchami na Git, Są Pull Requesty, code review. Co więcej – zanim code review pójdzie do instruktora (tutaj do mnie), najpierw to kursanci sami sobie sprawdzają swoją pracę.

Duża skala

Mimo, że projekt jest miniaturą – wcale nie jest “niepoważny”. Prawda jest taka, że kursanci mają od pierwszego dnia ogrom pracy do wykonania. W tym przypadku zbudowali 4 moduły pobierające, odpowiednio dużo modułów przetwarzających, do tego indeksacja i kilka komponentów pomocniczych. Dołóżmy jeszcze orkiestrację (przy pomocy airflow) oraz CI/CD (Jenkins) i mamy… naprawdę solidny kawał roboty do przerobienia. Dla dwójki osób. Które dodatkowo nie miały nigdy do czynienia z Big Data.

Na szczęście naszym kursantom całość poszła śpiewająco;-). Nie obyło się bez trudów i wątpliwości, ale o tym już za chwilę.

Chcę jednak podkreślić, że projekt podczas tego typu szkolenia przekrojowego, to naprawdę ogrom pracy i wytężone obroty mózgu. W ten sposób kursanci w praktyce gruntują sobie wyłożoną wcześniej w metodyczny sposób, wiedzę.

Jako że projekt był systemem wspierającym analizę inwestorów, zespół połączył dane finansowe, gieldowe oraz aktywność około-spółkową na Twitterze. Pisząc “okołospółkową” mam na myśli, że często liczy się nie tylko oficjalny profil firmy. Przykładowo – w przypadku PKN Orlen głupotą byłoby zignorowanie profilu Prezesa Daniela Obajtka, który jest bardzo aktywny i zaangażowany. Podobnie należy starać się wyłapywać także to, co mówią inni.

Dane, po szeregu operacji, trafiają do Elasticsearcha, skąd zaciągane są i wizualizowane przy pomocy Kibany. Poniżej można zaobserwować finalny efekt prac – czyli jeden z dashboardów, który wizualizuje część danych.

Nie tylko umiejętności techniczne

Prezentacja

Całość kończyła się prezentacją przed innymi członkami firmy. Pamiętasz jak to wyglądało na studiach? Praca do samego rana, potem szybko klejona prezentacja w tramwaju, wpadanie spoconym na zajęcia i… prezentujemy!

Na szczęście, tutaj ustawiamy sobie deadline wykonania projektu na ok. 2-3 dni przed prezentacją. Raz, że wiadomo, że będą obsuwy. Po drugie – na długo przed punktem kończącym szkolenie, spotykamy się i daję kilka wskazówek. Z doświadczenia wiem, że nie jesteśmy nauczeni prezentacji. Raczej przygotowując takowe zaczynamy od otwarcia Power Pointa, co jest raczej niepokojące. Spotykamy się więc i staram się w kilku zdaniach przedstawić odrobinę inny obraz prezentacji. Nakierowany na słuchacza, a nie na “byle zrobić”. Nie żebym sam świetnie prezentował. Coś tam jednak wiem i to “coś” staram się podpowiedzieć, zawsze odrobina do przodu;-).

Potem kursanci samodzielnie przygotowują i ćwiczą prezentację, aż do punktu dzień przed – gdy prezentują ją mnie. Tak próba generalna. Albo, jak się okazuje, niekoniecznie generalna. Bo po moich poprawkach tym razem kursanci poprosili o jeszcze jedną taką próbę.

Efekt? Sama prezentacja wypadła bardzo dobrze, a kursanci… nawet się nie stresowali. Wiedzieli co mają zrobić, poszli po swoje i wzięli co do nich należało.

Dzięki temu szkolenie przekrojowe nauczyło nie tylko Hadoopa, Sparka i Elasticsearcha. Nauczyło również skutecznie przedstawiać efekt prac. A to czasami – niestety – ważniejsze w kontakcie z klientem.

Współpraca

O ile warsztaty są w miarę indywidualne, o tyle projekt to wspólne dziecko kursantów. I to, że sukces zależeć będzie od ich współpracy, mają wbijane od pierwszego dnia, gdy się zobaczyliśmy. Tu naprawdę jest dużo miejsc, w których coś może pójść “nie tak”. I w związku z tym bardzo dużo punktów zapalnych. Jednym z zadań szkolenia jest zetrzeć ze sobą kursantów w tych momentach w taki sposób, żeby wiedzieli, że stoją w jednym szeregu i że od tego czy pomogę koledze/koleżance, zależy to czy dobrniemy do celu.

Jeśli chodzi o naszych kursantów, nie widziałem żadnych spięć, żadnego obrzucania się winą. I fantastycznie było na to patrzeć. Gdy jedno rozwiązało jakiś szerszy problem, dzieliło się z drugim. Razem wypracowywali koncepcję, struktury, pomysły. Razem sprawdzali sobie kod i dzielili się wątpliwościami. To zżywa. Co ważniejsze natomiast – to pokazuje, że nikt nie jest idealny, uczy pokory i tego, że warto pracować wspólnie, razem, a nie tylko w jednym zespole.

 

Odbiór krytyki

Takie szkolenie uczy poprawnego odbioru krytyki. Oczywiście nie jest to szkolenie z przyjmowania krytyki, ale jakiejś części tego tematu owszem, uczy. I poruszam to, co ciekawe, jeszcze na początku, przy okazji szkolenia z Gita, a potem wielokrotnie w trakcie projektu. Żeby zrozumieć o co chodzi, powiem tylko, że nasz kod to często nasze dziecko. Traktujemy swoją pracę wielokrotnie jak przedłużenie nas samych.

W trakcie pracy następuje natomiast taki moment jak “code review”. Pokazujemy nasze zmiany innym, a inni je komentują. I nie pokazujemy po to, żeby usłyszeć jacy jesteśmy wspaniali, tylko gdzie mamy błędy, gdzie postąpiliśmy definitywnie niezgodnie ze standardami, a gdzie całość można znacząco uprościć.

To nigdy nie jest łatwe, czytać na swój temat szereg uwag. I to wielokrotnie. Dlatego od początku tłumaczę, że kod to nie my. Krytyka kodu, to nie krytyka nas. A uwagi służą temu, żeby zbudować lepszy produkt finalny. I przy okazji, żebyśmy my stali się lepszymi programistami, inżynierami. Ta teoria + wielokrotna praktyka później, ustawia kursantów w odpowiednim punkcie. Nie chodzi o to, żeby krytyką się biczować. Nie chodzi też o to, żeby spływała jak po kaczce. Ona ma być konstruktywna.

Ma to też drugą stronę medalu – sami mamy dawać możliwie konstruktywny feedback. Liczę, że zostanie to potem z kursantami w życiu;-)

Wytrwałość

Ostatnie co należy wspomnieć, to kwestia wytrwałości. Kursanci nie rozwiązują jedynie przykładowych ćwiczeń. Oni mają całe dnie, żeby poradzić sobie z – często – trudnym, złożonym problemem. Takim, który sprawia kłopoty na poziomie pomysłu, konfiguracji, implementacji.

Wiem dobrze, że czasami kursanci wyrywają sobie włosy z głowy. To są normalne problemy, które przyjdą potem w projekcie. Dlatego zderzamy się z nimi już tutaj, w kontrolowanych warunkach.

No właśnie. Tego typu przekrojowe szkolenie z Big Data to dużo potu, wysiłku, presji. Natomiast nie jest to nigdy presja niezdrowa. I to jeden z moich obowiązków, żeby w odpowiednim momencie pomóc, podpowiedzieć, pokrzepić dobrym słowem. Żeby ciągle utrzymywać dobrą atmosferę, bo presja ma wynikać z wewnętrznego poczucia obowiązku, a nie z napięcia między członkami takiego projektu. To bardzo ważne, bo z jednej strony pomaga podejść do komercyjnego projektu. Z drugiej – nie jest wyniszczające i wypalające.

Nasi kursanci byli niezwykle wytrwali. Pracowali ciężko, w sposób zdyscyplinowany. Czy był jakiś brak? Owszem – brak wymówek i migania się od roboty. Oboje ciężko zasuwali, żeby nauczyć się i dopiąć całą robotę. Jestem szczerze przekonany, że świetnie poradzą sobie w najbliższym projekcie i w życiu. Wróżę dużo sukcesu, bo dysponują fantastycznym zestawem cech. A teraz – mam nadzieję – także solidną wiedzą technologiczną;-).

Podsumowanie

Szkolenie przekrojowe może być realizowane w rozmaity sposób. Staram się podczas niego:

  1. Nauczyć podstaw technologii w metodyczny sposób
  2. Ugruntować wiedzę poprzez łączenie elementów w praktycznych zadaniach (jak projekt)
  3. Dorzucić elementy miękkie – komunikację, organizację projektu, umiejetność odpowiedniego podejścia do krytyki.

Jeśli tylko jesteś przedstawicielem firmy, która chciałaby wyszkolić nowych pracowników w podobny sposób, napisz na

kontakt@riotechatafactory.com

Odpowiem tak szybko jak to możliwe. Dogadamy razem szczegóły i ułożymy plan w taki sposób, żeby za jakiś czas Twoje szeregi zasilili wspaniali Inżynierowie Big Data. Moją misją jest pomoc w takich właśnie momentach. Instruktorom z którymi współpracuję, także;-).

Jeśli chcesz mnie lepiej poznać, mam dla Ciebie kilka propozycji:

  1. Zapisz się na newsletter i odbierz darmowego ebooka o Big Data. Prawie 140 stron opisu branży z wielu różnych stron.
  2. Przejrzyj YouTube znajdziesz tam nie tylko materiały techniczne!
  3. Przesłuchaj podcast “Big Data Po Polsku”. Mówię tam o Big Data ludzkim językiem.

 

Loading
Przeszedłem szkolenie Big Data – co dalej, by zostać prawdziwym ekspertem?

Przeszedłem szkolenie Big Data – co dalej, by zostać prawdziwym ekspertem?

Big Data to branża, która rozlewa się na coraz większe obszary. Siłą rzeczy inżynierowie Big Data stają się dla rynku niebywale potrzebni, co generuje coraz większe zapotrzebowanie na szkolenia personelu mające w założeniu wytworzyć wielu ekspertów w przyspieszonym tempie.

Jeśli jesteś jednym z tych szczęśliwców, którzy właśnie stali się świeżo upieczonymi inżynierami Big Data – gratulacje! Witamy w naszej działce;-). Pamiętaj jednak, że to dopiero początek. W artykule zastanowię się chwilę nad tym co zrobić, żeby szkolenie było jedynie świetną podstawą pod dalszy rozwój. Prawdziwy ekspert bowiem to coś znacznie więcej niż “po prostu pracownik”. I – co ważniejsze – prawdziwy ekspert, to ktoś znacznie potrzebniejszy nam wszystkim, niż często myślimy;-). Zatem – kawa w dłoń i ruszamy!

Co tak naprawdę musisz umieć w Big Data? Kilka słów o “T-shape”

Po przekrojowym szkoleniu z Big Data masz podstawy pod działanie i dalszy rozwój. Aby mądrze pokierować swoim rozwojem warto zastanowić się jaki chcielibyśmy osiągnąć “efekt finalny”. Oczywiście mamy tu solidny cudzysłów, bo finału nigdy nie będzie;-). Pytanie jednak czy wchodzić w jedną technologię? A może jedno środowisko, np. konkretną chmurę? A gdyby tak poznać wszystkie kluczowe technologie? Cóż począć… Aby pójść odpowiednią drogą i podejść do sprawy z głową, warto zabrać się do tego metodycznie.

Osobiście uważam że najfajniejszym wzorcem, który może stanowić punkt wyjścia jest T-Shape, czyli po polsku “kształt literki T”. Na czym owa koncepcja polega?

T-Shape to pomysł spopularyzowany przez Davida Guesta już w 1991 roku. Zasadniczo sprawa jest do bólu prosta – litera “T” ma dwa paski. Górny – poziomy – pokazuje szeroki zakres wiedzy, jaki powinniśmy posiąść w wybranej dziedzinie – w tym przypadku Big Data/AI. Kreska pionowa symbolizuje głębokość poznania fachu. Jeśli zespolimy to wszystko w jedną myśl, zobaczymy że powinniśmy poznać szeroki kontekst, “zjeść chleb z niejednego pieca”. Natomiast w zaledwie jednej lub paru rzeczach powinniśmy być bardzo dobrzy, mistrzowscy, stanowić swoistą elitę.

Taka koncepcja podoba mi się niezmiernie, ponieważ daje luksus przeszukiwania nowinek, poznawania branży, próbowania niektórych rzeczy. Z drugiej strony zachęca, aby znaleźć to co najbardziej lubię i zgłębić w sposób ekspercki, w wielu okolicznościach, w różnych konfiguracjach i środowiskach, aby zrealizować niejeden cel. Dzięki temu wiele miejsc możemy “liznąć”, natomiast będziemy też mieli też “swoje terytorium”, gdzie czujemy się komfortowo, pewnie i na którym panujemy.

Taka koncepcja pozwala także wytworzyć eksperta, który ma szerokie spojrzenie, nie zamyka się na jeden wąziutki obszar. Prawdopodobnie będzie miał także nieco pokory, gdyż będzie zdawał sobie sprawę z tego, że “pod spodem” jest ogrom wiedzy której nie widać na pierwszy rzut oka.

Po pierwsze – zdefiniuj swoją drogę

Przeszedłeś już pierwsze szkolenie z Big Data? Znakomicie! Pamiętaj jednak, że to naprawdę dopiero skromny początek. Miej pokorę i wewnętrzny luz – branża nie raz i nie dwa udowodni Ci, że jesteś jeszcze ledwie padawanem. To nie problem! O ile nie masz wygórowanego mniemania o sobie rzecz jasna.

Podejdź do sprawy metodycznie. Otwórz na komputerze dokument tekstowy, nazwij go “mój rozwój w Big Data”. No dobrze, zwykły notes też może być ;-). Przede wszystkim zdefiniuj w jakich rzeczach chcesz się rozwijać. Jak to zrobić? Zacznijmy od przyjemnych rzeczy – wypisz wszystkie technologie oraz dziedziny, które najbardziej Ci się spodobały podczas szkolenia.

Taka lista może wyglądać tak:

  1. Spark
  2. Elasticsearch
  3. HBase
  4. Nifi
  5. Przetwarzanie danych
  6. Bazy danych
  7. Apache Superset
  8. Analiza danych
  9. Machine Learning
  10. Flink

Ok – jedno jest pewne: nie będziesz “wymiatać” w każdym z tych punktów. Technologie się zmieniają, poza tym każda z nich jest na tyle rozbudowana, że można by poświęcić najbliższe pół życia na dokształcanie się. Niemniej nie znaczy to, że lista nie ma sensu, wręcz przeciwnie!

Zacznij od zastanowienia się jaka działka zainteresowała Cię najmocniej. Gdyby ktoś powiedział Ci: “słuchaj, od teraz przez najbliższy rok będziesz robić tylko w tym”, co by to było? Nie chodzi tu o technologie, ale o to w którą stronę pójść. Przechowywanie danych? Przetwarzanie danych? A może analiza?

Załóżmy, że uznałeś, że to w czym chcesz specjalizować się najmocniej, to przetwarzanie danych. Od razu widzisz, że z listy powyżej dobrze będzie poznać Sparka i Flinka. Z tych dwóch najbardziej spodobał Ci się Spark, więc to on wygrywa jako technologia, w której chcesz zostać absolutnym mistrzem. Gratulacje!

Skoro masz już pionową belkę literki “T”, czas na górną, czyli technologie, które znasz “mniej więcej”. Tutaj moim zdaniem warto zbudować taki zestaw technologii, który pozwoli Ci na bycie wszechstronnym. Warto więc poznać nieco narzędzi, które pozwolą przechowywać dane, analizować je, pobierać itd.

Finalnie lista mogłaby wyglądać  tak:

  1. Spark – jako technologia, w której się specjalizujesz.
  2. HBase – jako nierelacyjna baza danych
  3. HDFS – jako naturalne dopełnienie HBase
  4. Postgresql – jako relacyjna baza danych.
  5. Elasticsearch – fulltext search, dzięki któremu będziesz mógł/mogła lepiej udostępniać dane pod zaawansowane przeszukiwanie
  6. Apache Superset – do analizy danych

Brawo! Masz 5 technologii, które musisz poznać czysto użytkowo i jedną, którą będziesz szlifować nawet na posiedzeniach w toalecie. Teraz już wiesz w jakim kierunku zmierzać!

Tu dodam jeszcze, że przy opracowywaniu listy warto kierować się także popularnością, żeby nie zacząć się rozwijać od początku w egzotycznych narzędziach. Jeśli jednak jesteś po przekrojowym szkoleniu, nie ma tutaj najmniejszego problemu, gdyż z całą pewnością technologie zostały dobrane solidnie.

Po drugie – wykorzystaj najlepsze sposoby, aby się rozwijać

Skoro wiesz już w czym się rozwijać, stwórz plan, dzięki któremu w konkrecie będziesz zdobywał wiedzę i umiejętności. Tu jeszcze od siebie dodam jedną rzecz – naprawdę potrzebne są obie rzeczy! To znaczy nie da się bez wiedzy teoretycznej poważnie zrozumieć dużej technologii. Wiem, że gdy podchodzimy do czegoś nowego, to ostatnią rzeczą jaką chcemy zrobić jest czytanie o architekturze i działaniu. “A co tam, przecież robiłem już coś podobnego!”. Cóż – zwykle takie podejście kończy się stworzeniem potworka. Każda technologia ma swoją specyfikę, swoje podejście i zanim siądziemy do kodu – warto o tym poczytać;-).

Co nie zmienia postaci rzeczy, że najważniejsza jest potem praktyka, która stopniowo wykształca w nas umiejętności i doświadczenie. Jak więc taką praktykę zdobyć? Poniżej 10 pomysłów.

  1. Przerabiaj tutoriale, które znajdziesz w internecie – jeśli chcesz coś poznać, żyjemy w czasach, gdzie wiedza jest wystawiona na tacy. Nie musisz już czychać na ostatnie egzemplarze czasopism z fragmentami kodu. Nie musisz chodzić do kawiarenki internetowej, aby ściągać przykłady. Może to niektórych dziwić, ale tak serio kiedyś było;-). Dziś nauka wymaga znacznie mniej determinacji. Niech Cię to nie rozleniwi. Podejdź z taką samą, jaką trzeba było wykazać kiedyś. Tutoriale na temat drobnych, konkretnych rzeczy, to absolutny standard i błogosławieństwo naszych czasów.
  2. Rób mini-kursy na portalach takich jak Data-Camp – Robiąc tam szkolenia otrzymujesz materiały teoretyczne, środowisko do ćwiczeń oraz… certyfikat, który potwierdzi Twoją wiedzę. Co prawda certyfikaty takie same w sobie nie zapewnią Ci złotych gór, ale są pewnego rodzaju wskazówką, że zależy Ci i czujesz głód wiedzy.
  3. Baw się technologią starając się ją “zepsuć” lub wykorzystać w niecodzienny sposób – kojarzysz, jak dzieci podchodzą do zabawek? Daj małemu chłopcu wieżę do spuszczania piłeczek i piłeczkę. Od razu zobaczysz w jak wielu konfiguracjach wieża ta może być zbudowana, oraz że piłeczka bynajmniej nie jest jedyną rzeczą, która może zjeżdżać na sam dół. Zainspiruj się małymi dziećmi – odkryj w sobie ciekawość technologii. Sprawdź jak to naprawdę działa, przetestuj wyjątki i sytuacje brzegowe, zrób coś dowcipnego, wykaż błędy. Takie podejście pozwala w niezwykle trwały sposób poznać tematykę, która na tutorialach pokazana jest jedynie powierzchownie.
  4. Buduj swoje własne projekty – a teraz moje ulubione. Gdy przygotowuję się do rozmów kwalifikacyjnych z potencjalnymi pracownikami, zawsze dostaję przynajmniej trzy rzeczy: CV, wyniki wstępnych etapów oraz… link do repozytorium kandydata. To co tam znajdę powie naprawdę, naprawdę wiele o człowieku, który aplikuje. Robiąc projekt, zdobywasz ogrom wiedzy, której nie zdobędziesz przerabiając przykłady czy dokumentację. Zmierzysz się z problemami, zobaczysz praktyczne wykorzystanie technologii. Dodatkowo wykażesz inicjatywność oraz charakter. Umiejętność wymyślenia, zaprojektowania i zbudowania projektu wynosi Cię do wyższej ligi. Zastanów się dodatkowo, w jaki sposób realizacja takiego projektu mogłaby pomóc Tobie i innym. Ulepsz choć malutki skrawek naszej rzeczywistości. Powodzenia!
  5. Dziel wiedzą ze współpracownikami – Zrobiłeś/aś research technologii? Odkryłeś/aś coś ciekawego? Podziel się ze swoimi współpracownikami. Dzięki temu utrwalasz wiedzę i zaczynasz lepiej rozumieć to co poznajesz. Dodatkowo budujesz w swoim środowisku solidną markę. No i na końcu… cóż, pomagasz koleżankom i kolegom budując dobre miejsce do pracy, a to bezcenne;-).
  6. Bądź aktywny w pracy i wykorzystuj projekty oraz okazje – o ile poprzednie punkty możesz realizować niemal zawsze, ten jest zależny od Ciebie tylko po części. Niejednokrotnie w firmie w której pracujesz będą nadarzały się okazje. Prawdopodobnie trzeba będzie zrobić jakiś research technologiczny, pomóc w przygotowaniu oferty dla klienta lub zrealizować projekt typu PoC (Proof of Concept – czyli prototyp, który ma zbadać jakąś ścieżkę). Być może po prostu pojawi się zapotrzebowanie na projekt. Jeśli te możliwości są zgodne z Twoją ścieżką rozwoju, nie bój się – idź w to! Poświęć dodatkowe godziny pracy. Nie obawiaj się wyjść z projektu, w którym już jest Ci wygodnie i cieplutko. Poznaj coś nowego, popełnij kilka (naście?set?) błędów i zdobądź dodatkową wiedzę oraz umiejętności.
  7. Rozmawiaj z bardziej doświadczonymi – jeśli pracujesz z kolegami, którzy siedzą już kilka lat w Big Data – nie bój się pytać ich o różne rzeczy. Dyskutuj, pytaj co sądzą o tej lub innej koncepcji. Pokazuj swoje projekty, poproś o code review. Obserwuj jak piszą kod i staraj się od nich jak najwięcej nauczyć. W ten sposób dokonasz szybkiego transferu wiedzy od ludzi, którzy musieli najprawdopodobniej przejść dość trudną, ciernistą drogę. Uwaga! Zawsze rób to z należytą pokorą.
  8. Rozwijaj swoją bazę wiedzy – nie myśl, że “masz to w głowie”. Zbuduj swoją bazę wiedzy, w której będziesz zapisywać swoją wiedzę i doświadczenie. Może to być jeden dokument, może to być folder z dokumentami “per technologia”. Oto na jakie aspekty możesz podzielić swoją bazę wiedzy:
    • Esencja wiedzy teoretycznej – zazwyczaj opis wynikający z dokumentacji
    • Obserwacje – tu możesz opisać np. rozwiązania często występujących wyjątków, czy rozwiązania zagwozdek, które Cię trapiły.
    • Odnośniki do ćwiczeń – jeśli masz już rozwiązany jakiś problem w kodzie, napisz tutaj gdzie dokładnie.
    • Materiały – czyli strony, które opisują daną technologię.
  9. Bądź uczestnikiem konferencji Big Data/Data Science – takich konferencji jest naprawdę sporo i przybywa ich z każdym rokiem. Nie dostaniesz tam żadnej precyzyjnej, szczegółowej wiedzy. Dostaniesz natomiast różne podejścia, różne spojrzenia, różne case studies. Warto pochodzić, aby zrozumieć jak działa branża.
  10. Chodź na gruntowne szkolenia – Data Camp i inne tego typu portale to bardzo dobry pomysł. Nie porozmawiasz tam jednak z instruktorem, nie poznasz wiedzy dogłębnie, tak jak na indywidualnych szkoleniach. Jeśli masz jakiś wpływ na to na jakie szkolenia wysyła Cię Twoja firma – zachęcam do naszej oferty;-). Osobiście przeprowadzając szkolenie zawsze stawiam nacisk na zrozumiałe podanie teorii oraz dużą ilość “mięsa”, dzięki czemu praktyka staje się potem jasna, a realizując projekt masz punkt odniesienia. Wejdź w kontakt i daj znać czego potrzebujecie, na pewno jakoś się dogadamy:-).

Po trzecie – koryguj swój kurs;-)

Czas na ostatni krok. Skoro wiesz już w czym i jak się rozwijać… nie bój się zmienić swojego kursu. Głupotą byłoby podejmowanie wiążącej decyzji dotyczącej całej ścieżki zawodowej na samym początku kariery. Poświęć na jej realizację kilka miesięcy, pół roku, ale potem pomyśl, czy nie warto byłoby dokonać rewizji swojego planu.

Być może pomyślisz, że skoro poświęciłeś/aś na coś mnóstwo czasu, to zmiana kursu będzie szarpaniem się między wszystkim i niczym, co w efekcie doprowadzi do tego, że nie będziesz ekspertem w niczym. Nie jest to prawda – w ten sposób budujesz górną belkę literki “T”. Przygotowujesz jednocześnie grunt pod belkę pionową. Pamiętaj jednak, że jeśli wiedzę teoretyczną poprzesz praktyką i podsumujesz w bazie wiedzy – to wiedza ta nie wyparuje. Będzie przy Tobie i będzie wspierać Twoją pracę, nawet jeśli finalnie technologie w których się specjalizujesz, będą inne.

Pamiętaj, dodatkowo, że im więcej się uczysz i ćwiczysz swój mózg, tym łatwiej jest Ci się nauczyć kolejnych rzeczy. Nie bój się zmiany kursu. Nie bój się planowania, ale nie spędzaj też nad nim połowy czasu. Końcem końców liczy się wiedza jaką posiadasz i doświadczenie, jakie masz na karku. Nie zaś perfekcyjnie zaplanowana ścieżka kariery. Tak więc… zaplanuj ją, rozwijaj się metodycznie, ale przede wszystkim – pracuj, pracuj, pracuj. Mądrze, ciężko, uparcie. A na pewno staniesz się wybitym ekspertem, który wpłynie na nasz świat;-). Tego Ci życzę!

Na koniec – zapraszam, zostań na dłużej, dołącz do newslettera i twórz naszą społeczność Big Data.

 

Loading