logo

Lekcje wyniesione z hackathonów, które zmieniły mój sposób pracy

Długość wpisu: 12 min

Od jakiegoś czasu chciałem napisać wpis o hackathonach, bo miały bardzo duży wpływ na to, jak obecnie pracuję. Dały mi umiejętności, które ciężko jest czasem zdobyć w normalnych projektach.

Byłem mocno zdziwiony, gdy zrobiłem sobie listę rzeczy, których nauczyłem się na tego typu wydarzeniach albo które tam podszlifowałem.

Zacznijmy od tego, dlaczego pomyślałem o uczestnictwie w hackathonach i jeśli masz podobne powody do moich, to możesz na nich nieźle skorzystać.

Dlaczego hackathony

Praktycznie w każdym z moich projektów, po pewnym czasie, pojawiała się rutyna, która powodowała, że projekt zaczynał mnie nudzić. Jest to naturalne, bo czasem trzeba po prostu klepać kolejne ficzerki, które niekoniecznie są wyzwaniem.

W takich sytuacjach pojawia się myśl, że fajnie byłoby nauczyć się czegoś nowego, najlepiej w praktyce. Zrobić coś fajnego dla odmiany.

Często w projektach używamy też starych technologii i nie ma za bardzo możliwości wprowadzenia najnowszych zdobyczy w postaci bibliotek czy frameworków, bo z biznesowego punktu widzenia nie mają one sensu i wprowadziłyby tylko zamęt w projekcie.

W takich chwilach można np. wymyślić sobie jakiś projekt na boku. Czasem tak robiłem, ale często nie miało to sensu, bo czułem, że robię go tylko dla siebie, nikt nie będzie go używał, nikomu nie przyniesie wartości, albo nawet nikt nie zobaczy go na oczy.

Czasem też nie chodziło tylko o kod. Czasem chciałem wypróbować jakiegoś nowego podejścia do pracy w projekcie - robić 100% TDD, pracować w Kanbanie zamiast w Scrumie, zrobić jakieś UXowe warsztaty itp.

Lista rzeczy, których chciałbym się nauczyć i wypróbować w praktyce zawsze była długa, a ja nie miałem gdzie tego wypróbować.

Czułem, że to hamuje mój rozwój.

Czułem, że gdy trafię do zespołu, w którym używają Kanbana albo używają jakiejś biblioteki, której ja mógłbym się nauczyć, to będę mocno do tyłu.

Nie wiem jak u Ciebie, ale w moich projektach często miałem kogoś, kto czuwa nad zespołem, bierze odpowiedzialność za pewne obszary projektu i ma nad nimi kontrolę, ustala zasady w tych obszarach. Jest to szef, PM, lider, Scrum Master, PO, klient, you name it.

Gdy na horyzoncie pojawiła się możliwość wzięcia udziału w hackathonie, to od razu w mojej głowie kliknęło, że to jest właśnie okazja, która oddaje mi tę utraconą kontrolę nad tym, jak pracuję, pozwala na poćwiczenie nowych umiejętności, nauczenie się nowych narzędzi i jednocześnie ma jasno zdefiniowany cel, czyli ma po prostu sens.

💡 Note: Gdy zacząłem wchodzić w role liderskie, to zacząłem mieć większą kontrolę. Ale na początku często jej nie było. O kontroli więcej mówiłem tutaj.

Hackathony nie były już zwykłymi projektami na boku, ale czymś, co ma konkretny cel (co jest bardzo ważne) i co wymusza praktyczne zastosowanie rzeczy, których się nauczyłem lub chcę nauczyć.

Z perspektywy czasu widzę, że był to strzał w dziesiątkę, bo nauczyłem się wielu rzeczy, które wykorzystuję w pracy cały czas.

offtop box

Na potrzeby tego wpisu, hackathonem będę określał wydarzenia, w których mamy do rozwiązania szereg zadań, za które zdobywamy punkty i takie, gdzie musimy stworzyć jakiś produkt, MVP, które potem prezentujemy przed komisją lub jury.

Niby są to różne rodzaje imprez, ale jednak mają dużo części wspólnych.

Jest to idealna mieszanka umiejętności twardych i miękkich.

💡 Note: Brałem też udział w hackathonach, gdzie nie było nic do wygrania i które organizowaliśmy sobie samemu, dla funu, ale nie o tym jest ten wpis.

Projekt vs produkt

Jedną z najważnieszych rzeczy, których nauczyłem się na hackathonach, jest myślenie produktowe.

W normalnej pracy często pracujemy wyłącznie w trybie projektowym. Oznacza to, że skupiamy się na projekcie, user storiesach, taskach, retrach, planingach i ogólnie na pisaniu oraz testowaniu kodziku.

Mniej interesuje nas wartość biznesowa, roadmapa produktu, ilość pieniędzy, które klient jeszcze ma w kieszeni, marketing, sprzedaż, rynek, które ficzery zrobić najpierw, a które później, czy użytkownicy to kupią, czy nie, czy wyrobimy się na czas i co jeśli nie.

Mniej interesuje nas, czy ten kawałek kodu, który właśnie piszemy i szlifujemy ósmą godzinę, zwróci się klientowi. Czy pieniądze włożone w zadanie, które tworzymy, przyniosą zysk.

💡 Note: Wiem, że uogólniam, że niektórzy pracują nad produktami i zwracają na to wszystko uwagę. Na potrzeby tego wpisu opisuję trend.

Hackathony, w których musimy dowieźć jakiś produkt, skupiają się właśnie na tych wszystkich rzeczach i te rzeczy są punktowane przez komisję.

Musimy wtedy podejść do pracy w taki sposób, jakbyśmy mieli coś sprzedawać i na tym zarabiać. A w dodatku musimy umieć to zaprezentować.

Takie podejście pozwoliło mi zrozumieć, z jakimi problemami muszą radzić sobie klienci. Zacząłem rozumieć, dlaczego czasem programiści mogą ich irytować swoim oderwanym od rzeczywistości i skupionym tylko na kodzie podejściem.

To doświadczenie łatwo było mi potem przenieść na projekty w pracy. Zobaczyłem, że część projektowych dramatów związanych z kodzikiem nie ma żadnego sensu i sprzeczanie się oraz szlifowanie kodu powoduje, że klient traci pieniądze, a użytkownicy nie dostają produktu, który rozwiązałby ich problemy.

Co ciekawe, część takich hackathonów można wygrać bez pisania nawet jednej linijki kodu. Czasem wygrywa dobrze przygotowana prezentacja i zestaw makiet. Bo to pozwala zweryfikować, czy produkt lub jakiś ficzer ma sens.

Dzięki temu zrozumiałem m.in. dlaczego czasem klienci chcieli, żebym zakodził im coś na kolanie, tylko po to, żeby mogli to zaprezentować innym stakeholderom lub użytkownikom.

It all makes sense

Szybka praca i widoczne efekty

Na hackathonach zawsze wiedziałem, że w pewnym momencie mogę utknąć, czas się może skończyć albo w pewnym momencie po prostu zasnę i przestanę ogarniać.

Projekty w pracy często trwają bardzo długo i mamy złudzenie, że czasu jest nieskończenie wiele. Zwłaszcza na początku.

A jednak w projektach czas też może się skończyć. Przyjdzie koniec sprintu, wskoczy jakiś deadline, przyjdzie nam zrobić niespodziewane demo dla nowego stakeholdera, klient zażyczy sobie czegoś na ASAPie i trzeba będzie zostawić to, nad czym dotychczas pracowaliśmy itp.

Na hackathonach nauczyłem się jak z tym walczyć dzięki dwóm rzeczom.

Pierwsza to bezlitosna priorytetyzacja, która z jednej strony pozwala skupić się na najważniejszych rzeczach na hackathonie, a z drugiej strony ułatwia podejmowanie decyzji dotyczących tego, co jest najważniejsze z punktu widzenia klienta, a co można przerzucić do następnego sprintu.

Druga to pisanie kodu w ten sposób, żeby w miarę każdy komit dowoził wartość. Gdyby czas nagle się skończył, to miałbym coś, co można wrzucić “na produkcję” i co przyniosłoby wartość.

Dzięki tym dwóm rzeczom jestem w stanie dzielić pracę na mniejsze części, które dowożą wartość i gdy zajdzie taka potrzeba, to można nimi żonglować.

Boilerplaty

Presja czasu na hackathonach spowodowała też, że zacząłem dostrzegać, jak mnóstwo czasu marnowane jest na pisanie boilerplate’u i różnego rodzaju konfiguracji. Czasem miałem wrażenie, że minęły wieki, zanim zacząłem pisać kod, który coś faktycznie robi.

Za każdym razem osoby, które miały przygotowane gotowce, radziły sobie znacznie lepiej i miały znacznie lepszy start.

Dostrzegam teraz wartość w takich rzeczach jak snippety, gotowe konfigi, narzędzia do bootstrapowania projektów i boilerplaty.

Gotowce można dopasować do potrzeb i nie trzeba pisać wszystkiego z palca.

Takie podejście świetnie sprawdza się też w komercyjnych projektach. Pozwala szybciej wystartować i szybciej pokazywać wartość klientom. Często robi to też efekt “wow”, bo szybkie pokazywanie efektów nadal nie jest w tej branży standardem.

Deploye na początek

Krótki czas trwania i konieczność zaprezentowania rozwiązania pod koniec hackathonu wymusza na kodzie to, żeby był zdeployowany. Żeby można było go pokazać.

Deploy to jest jedna z tych rzeczy, których często nie doceniamy, a które kontrybuują do efektu wow wspomnianego wyżej.

Ja sam nie doceniałem wartości szybkiego deploya, dopóki nie musiałem zrobić go po raz pierwszy i potem zostawać po godzinach, żeby doprowadzić aplikację do stanu, w którym będzie stabilna.

Deploye niestety zbyt często są traktowane po łebkach i nie doceniamy, jak dużo czasu schodzi na wrzucenie czegoś na produkcję.

Nie raz byłem świadkiem, że o deployu się po prostu zapominało. I to nie tylko na hackathonach.

A pierwszy deploy często po prostu nie działa.

Wielu programistów nie zdaje sobie sprawy, że gdy włączymy aplikację w trybie produkcyjnym, włączymy httpsa, zminifikujemy kodzik i wrzucimy na serwer linuxowy, który zachowuje się inaczej niż everyday Macbook, to apka może zacząć się zachowywać zupełnie inaczej niż dotychczas.

Dlatego zawsze staram się teraz ogarnąć deploy na początku. Najlepiej przez merge do mastera/maina. I pushować ten branch jak najczęściej, żeby w każdej chwili być pewnym, że apka działa.

Wymienialny kod

Bardzo atrakcyjną stroną hackathonów jest to, że można po prostu ponaparzać kodzik. Możesz zostać kowbojem z klawiaturą. Bardzo oczyszczające doświadczenie.

Cowboy Coding

Kowbojskie zagrywki w kodzie, takie jak fixy w ostatniej godzinie, zmiany tylko na produkcji z pominięciem repo są dość powszechne.

W tych krytycznych momentach zdarzało mi się czasem, że musiałem coś zaorać i napisać od nowa. Albo wprowadzić krytyczną, ratującą życie zmianę.

Wtedy takie kowbojskie podejście pokazywało swoją drugą stronę - syf w kodzie powodował, że nie wiedziałem jak się zabrać za refactor, nie niszcząc tego, co wypracowaliśmy dotychczas.

Jak prawdziwy kowboj, nawijałem spaghetti klawiaturą i potem nie wiedziałem, gdzie wprowadzać zmiany i czy przypadkiem nie popsują całkowicie aplikacji.

To był taki moment oświecenia, który pokazał mi, jak bardzo ważne są dobre praktyki tworzenia oprogramowania. Zrozumiałem, o co chodziło Uncle Bobowi w “Czystym Kodzie”, gdy przedstawiał SOLIDa i inne zasady.

Spaghetti kod się po prostu nie opłaca.

Zmiana nadchodzi niespodziewanie i warto się na nią przygotować.

Warto pisać testy

Ci, którzy pomyśleli sobie w poprzednim akapicie, że “jakbyś pisał testy, to byś się nie bał wprowadzać zmian” mieli rację.

Testy i czysty kod to nierozłączna para.

Pamiętam, jak na jednym z hackathonów cieszyliśmy się, bo jako jeden z pierwszych zespołów zaczęliśmy zdobywać szybko punkty, ale po jakimś czasie okazało się, że nasz algorytm wcale nie jest taki fajny i inni zdobywali punkty znacznie szybciej niż my.

Trzeba było wprowadzać zmiany, ale kodzik był napisany na szybko, bez testów.

W dodatku było go dużo - to był nasz gwóźdź do trumny. Nie mieliśmy szans na zmianę algorytmu w krótkim czasie tak, żeby nie stracić punktów i nie zabić aplikacji. Jedyne co nam pozostało, to zostawienie algorytmu w spokoju i nadrobienie punktów w innym zadaniu.

Nie nadrobiliśmy straty i zostało takie smutne poczucie, że z testami byłoby łatwiej.

Wizualizacja i dobre logi to podstawa

Na innym hackathonie mieliśmy do czynienia z wirtualną planszą do gry w statki. Każda drużyna podłączała się do tego samego serwera i w odpowiedzi dostawała strumień logów. Na jego podstawie algorytm, który mieliśmy do napisania, podejmował decyzję, czy się poruszać, czy atakować przeciwną drużynę.

Logi były w formacie tekstowym.

Jedna z drużyn, które poradziły sobie najlepiej w tym wyzwaniu, postanowiła zwizualizować te logi i wyrysowała sobie mapę, która aktualizowała się w czasie rzeczywistym.

My parsowaliśmy logi w głowie, a oni po prostu patrzyli na mapę i widzieli czy ich statek zachowuje się ok.

Wtedy miałem kolejne oświecenie, które pokazało mi, jak bardzo ważny jest monitoring.

Poczynając od postawienia logów w dobrych miejscach i na dobrym poziomie, po analizę i alerting.

Te wszystkie rzeczy mocno uświadamiają, jak zachowują się nasze aplikacje i pokazują, co możemy poprawić. Łatwiej dostrzegać zależności, których bez nich ciężko zobaczyć - np. że niektóre części aplikacji zaczynają rzucać błędami, gdy serwer dostaje zbyt dużą liczbę zapytań, albo że te dziwne zwiechy, których czasem doświadczamy, to powód zbyt małej ilości pamięci.

Dobre logi i monitoring są jak magiczne okulary, które możemy dostać za darmo, jeśli tylko chcemy.

Magic Glasses

Teamwork

Wspominałem na początku, że w projekcie przeważnie mamy kogoś, kto czuwa nad tym, żeby praca szła do przodu, była dobrze podzielona i żeby ogólnie kaszany nie robić.

Podczas hackathonu nie ma takich osób, bo Scrum Masterów, Product Ownerów i liderów rzadko interesują hackathony.

Mamy za to kolegów z zespołu i okazję do poćwiczenia różnych form planowania. Możemy zaplanować roadmapę, wizję produktu, określić user story i porozdzielać je na mniejsze części, przypisać odpowiednim osobom, a nawet zaprojektować wygląd aplikacji i skupić się na UXie.

To już są umiejętności liderskie, których szczególnie na początku nie miałem okazji ćwiczyć w normalnych projektach.

Za to pamiętam jak dziś, że po powrocie z jednego z hackathonów zobaczyłem od razu, co można by poprawić na naszym projektowym boardzie i że na następnym planowaniu było mi znacznie łatwiej podzielić User Story na mniejsze, sensowne części.

Czułem wręcz, że mam jakieś nowe supermoce w tych kwestiach.

Prezentowanie

Na koniec taka wisienka na torcie, czyli umiejętności zaprezentowania swojej pracy.

Przeważnie w takich hackathonach, na samym końcu musimy przedstawić, co zrobiliśmy i często mamy na to bardzo mało czasu.

Ja mam tendencje do przeciągania swoich myśli, więc za każdym razem miałem okazję poćwiczyć umiejętność zwięzłego prezentowania najważniejszych elementów aplikacji.

Mogłem też poćwiczyć trochę bajerę, bo takie aplikacje trzeba pokazać w jak najlepszym świetle i czasem samą gadką można się wyróżnić. To nie jest tylko prezentowanie rozwiązania, ale też prezentowanie nas - twórców.

Te umiejętności przydawały mi się potem podczas prezentowania na demo dla klientów i na rekrutacjach. Bo można być nudnym, zwyczajnym, przeciągać i gadać o wszystkim, a można też skupić się od razu na rzeczach, które przynoszą najwięcej wartości i przekazać je szybko, zwięźle i z polotem. Tak, żeby zaciekawić i po raz kolejny zrobić efekt “wow”.

To jest chyba jedna z moich top 3 umiejętności, które wyciągnąłem z hackathonów, bo prezentowanie jest nieodłącznym elementem naszej pracy.

Podsumowanie

Tym wpisem chciałem Ci pokazać, że warto uczestniczyć w hackathonach albo podobnych wydarzeniach, bo pozwalają zdobyć umiejętności, których często nie da się nauczyć lub poćwiczyć w projekcie.

Ja już nie biorę udziału w hackathonach od jakiegoś czasu, bo czego miałem się nauczyć, to się nauczyłem. Jednak cały czas pamiętam o tym, że jeśli chciałbym podszlifować, którąś z umejętności opisanych wyżej, albo nauczyć się czegoś nowego, to hackathon jest doskonałą opcją.

Na hackathonie jesteś bliżej “klienta” i dzięki temu wyrabiasz sobie pewien sposób empatii i produktowy sposób patrzenia na projekt. To podejście bardzo dobrze sprawdza się w projektach. Wskakujesz dzięki nim na wyższy poziom pracy z zespołem i klientem.

Zauważyłem, że osoby, z którymi jeździłem na te wszystkie hackathony, są zawsze jasnymi punktami w swoich zespołach. Inni widzą w nich wsparcie i naturalnie traktują te osoby jako liderów. To samo robią klienci. Wybierają ich jako osoby pierwszego kontaktu i z automatu zwracają się do nich, gdy trzeba coś załatwić.

A pracodawca to widzi i docenia.

Daj znać, jakie Ty masz doświadczenia z hackathonami i czego jeszcze można się nauczyć, bo wydaje mi się, że trochę rzeczy pominąłem.

Wyszła z tego całkiem fajna lista rzeczy do ogarnięcia, którą ja sam dodałbym do swojej osobistej roadmapy, gdybym był na Twoim miejscu.

No i na koniec warto pamiętać, że hackathony, to po prostu dobra zabawa i warto brać w nich udział dla samego aspektu rozrywkowego.

🖖

Ps. Wspominałem o tym jak ważne jest podzielenie pracy na mniejsze części i że hackathony w tym pomagają. Chciałbym przypomnieć, że w podzieleniu pracy na mniejsze części, pomoże Ci też mój ebook, który jest do podbrania poniżej.

Podziel się:

Instagram, Twitter, YouTube, Facebook, LinkedIn