Masz za sobą prawdziwe projekty
Nie uczysz się pętli for. Dowoziłeś feature, naprawiałeś produkcję, tłumaczyłeś komuś, czemu "to proste" jednak nie jest proste.
Zaczęło się od jednego dziwnego odkrycia
Przez lata myślałem, że odszedłem od web developmentu. Potem zobaczyłem, że po prostu przeszedłem piętro niżej.
Nie trafiłem tam przez wielki plan.
Najpierw była zwykła praca. Endpointy. SQL. Logi. Deploye robione z lekkim napięciem w brzuchu.
A potem coraz częściej widziałem, że najważniejsze rzeczy dzieją się zanim request dotknie aplikacji.
W danych.
Nie zmieniłem zawodu. Zmieniłem rodzaj awarii, które zacząłem rozumieć.
Jeśli jesteś web developerem, możliwe, że już dotykasz tego świata.
Tylko nikt jeszcze nie pokazał Ci, gdzie prowadzi ta nitka.
Najpierw sprawdźmy, czy to w ogóle o Tobie
Wyobraź sobie zwykły wtorek w projekcie.
Ktoś zgłasza, że liczby w panelu się nie zgadzają. Backend mówi, że API działa. Frontend mówi, że wyświetla to, co dostał. Biznes pyta, komu wierzyć. I nagle okazuje się, że problem nie jest w ekranie.
Znasz ten cichy niepokój
Kolejny framework. Kolejna biblioteka. Kolejny rewrite. Niby rozwój, ale czasem trudno powiedzieć, czy naprawdę idziesz wyżej.
Nie chcesz zostać juniorem po raz drugi
I słusznie. Najciekawsze pytanie brzmi: które elementy Twojej obecnej pracy są już fragmentem pracy z danymi, tylko jeszcze tak o nich nie myślisz?
To wtedy zobaczyłem coś, czego wcześniej kompletnie nie rozumiałem.
Problem rzadko wygląda efektownie
Czasem wszystko działa. Tylko liczby są złe.
A to jest zupełnie inny rodzaj awarii niż czerwony error w konsoli.
- Job przeszedł na zielono, ale w tabeli brakuje części rekordów.
- Raport pokazuje inną sprzedaż niż system transakcyjny.
- Dane z wczoraj mają inny schemat niż dane z poniedziałku.
- Pipeline działał pół roku, aż pewnego dnia zaczął kosztować trzy razy więcej.
Najciekawsze było jednak coś zupełnie innego.
Nie uciekłem z programowania. Zmieniłem miejsce, w którym programowanie robi różnicę.
Aplikacja pokazuje wynik. Ktoś musi jeszcze zadbać, żeby ten wynik miał sens.
Najpierw debugowałem requesty. Potem zacząłem debugować zaufanie do danych.
Nie zaczynałem od pustej kartki. Po prostu zobaczyłem, że moje stare narzędzia pasują do większej układanki.
I właśnie tutaj większość web developerów popełnia błąd.
I wtedy zobaczyłem most
To nie była zmiana branży. To była zmiana miejsca, w którym patrzę na system.
Wiele rzeczy brzmiało znajomo. Tylko nazwy były inne, dane większe, a błędy mniej oczywiste.
Web development
Endpoint, który przyjmuje dane z formularza, waliduje je i odpala proces w tle
Data Engineering
Pipeline, który przyjmuje dane z wielu źródeł, waliduje je i przerabia dalej
Web development
Zapytanie SQL, które nagle robi się wolne, bo ktoś wrzucił milion nowych rekordów
Data Engineering
Job Sparkowy, który nagle robi się drogi, bo dane rozłożyły się inaczej niż myślałeś
Web development
Logi, retry, monitoring i pytanie: "czemu to padło tylko na produkcji?"
Data Engineering
Checkpointy, jakość danych i pytanie: "czemu raport od wczoraj pokazuje bzdury?"
Web development
Myślenie o systemie, nie tylko o pojedynczym komponencie
Data Engineering
Myślenie o przepływie informacji przez całą firmę, nie tylko o jednej aplikacji
To był moment, w którym wszystko zaczęło mieć sens.
Nie musisz dziś niczego deklarować
Na początku wystarczy jedno: przestać zgadywać.
Bo z zewnątrz Data Engineering łatwo pomylić z kilkoma modnymi słowami. Od środka wygląda bardziej konkretnie.
- Co z Twojej obecnej pracy przechodzi dalej prawie bez zmian?
- Które rzeczy trzeba wyrzucić z głowy, bo w danych działają inaczej?
- Jak wygląda dzień pracy, gdy zamiast requestów z przeglądarki obsługujesz miliony zdarzeń?
- Od czego zacząć, żeby nie utknąć w losowych filmach o Pythonie, Sparku i chmurze?
Dlatego nagrałem materiał, który sam chciałbym zobaczyć na początku.
Krótko o autorze
Cześć, jestem Marek. Kiedyś też siedziałem po stronie aplikacji.
Pamiętam ten moment, gdy pierwszy raz zobaczyłem, że najciekawsze problemy nie zawsze są w kodzie endpointu.
Czasem są wcześniej. W danych, które do niego trafiły. W procesie, który je przygotował. W decyzji architektonicznej, której użytkownik nigdy nie zobaczy.
Dziś pracuję jako Data Engineer, współtworzę Akademię Big Data i prowadzę podcast "Big Data Po Polsku". Ten materiał nie ma Cię namawiać do rewolucji. Ma pokazać, czy warto otworzyć tę furtkę.
Chcę zobaczyć mapę tej ścieżkiTa droga nie kończy się na mojej historii
Od kilku lat pomagam innym oswoić świat danych po swojemu.
Jedni przychodzą z web developmentu.
Inni z analityki, testów, administracji albo innych obszarów IT.
Punkt startowy bywa różny. Cel jest zwykle podobny: przestać błądzić, zrozumieć dane i świadomie poukładać dalszy rozwój.
Czego dowiesz się na webinarze?
- dlaczego Data Engineering jest naturalnym kierunkiem dla Web Developera
- które umiejętności możesz wykorzystać od razu
- jak wygląda prawdziwa mapa nauki
- jakich technologii warto uczyć się w pierwszej kolejności
- jak wygląda codzienna praca Data Engineera
★★★★★„Podsumowując, mentoring pod kierunkiem Marka był jedną z najlepszych decyzji w mojej karierze. Dzięki jego wsparciu czuję się pewniej i jestem gotowa na nowe wyzwania w dziedzinie Big Data.”
★★★★★„Świetny kurs. Porównywałem go do Databricks Academy i po kursie Marka umiem więcej. Zdecydowanie polecam.”
★★★★★„Chyba jeden z najlepszych kursów, jakie robiłem. Szczególnie podobała mi się lekcja o rekrutacji, która świetnie uporządkowała wiedzę.”
FAQ
Najkrótsza odpowiedź: możesz sprawdzić to bez ryzyka.
Czy materiał jest darmowy?
Tak.
Czy to jest dla początkujących?
Najbardziej skorzystają osoby, które mają już podstawy programowania lub doświadczenie jako web developer.
Czy muszę znać Big Data?
Nie. Materiał pokazuje od czego zacząć.
Czy od razu dostanę dostęp?
TAK! Po zapisie od razu wysyłamy email z materiałem na twój adres.
Dopiero jeśli temat Cię zaciekawił
Obejrzyj spokojne wprowadzenie
Jeśli jesteś web developerem, ta mapa pomoże Ci zobaczyć, co już masz i czego warto nauczyć się dalej.