Hack Day

Monotonność codzienności w pracy może doprowadzić nas programistów do stagnacji, zniechęcenia, cofnięcia się w rozwoju (programistycznym). Wystarczy, że przez kilka tygodni będziemy klepać tylko i wyłącznie banalne strony HTML by już zauważyć u nas uszczerbek na zdrowiu. Nie wspominając o długich wielomiesięcznych projektach które z przyczyn X, Y i Z są wykonywane w przestarzałej technologii – gdzie wszyscy nasi znajomi już piszą aplikację w oparciu o najnowszy framework. Take rzeczy deprymują, dobijają, powodują, że nam się nie chce. Niezależnie od tego, że wiemy o tym że u sąsiada trawa jest bardziej zielona, zaczyna nas to wszystko dobijać. Tłamsić. Czujemy się wyczerpani samym przyjściem do pracy. Po prostu nam się nie chce.

Z drugiej strony wiemy, że tak jest bo to specyfika TEGO konkretnego projektu. Wszystkie pozostałe były inne, bardziej wymagające, w nowszych technologiach itp. itd. Wszędzie i zawsze trafi się projekt lub projekty które są jakie są. Ale ktoś musi je zrobić by potem móc robić te fajniejsze rzeczy ;)

Właśnie w takich sytuacjach (ale i nie tylko) opłaca się zrobić hack day – jeden dzień, raz w miesiącu, w kwartale, który jest całkowicie dla nas. My decydujemy co chcemy pisać, przetestować, dowiedzieć się. Następnie implementujemy nasz plan i przez dzień czerpiemy pełną niepochamowaną radość. Odrywamy się od codzienności i relaksujemy. Ostrzymy piłę programistyczną.

Taki Hack Day nie tylko przynosi nam korzyści ale dobrze przeprowadzony przyniesie korzyści pracodawcy. Nie licząc tego, że naprawdę oszczymy piłę i mamy więcej siły po to by potem usiąść z powrotem do monotonnej pracy, z hack day pracodawca może czerpać dodatkowe korzyści. Jeżeli dobrze doprecyzuje się ogólny cel takiego dnia – na przykład: co możemy wykorzystać już teraz by polepszyć nasze usługi/produkty? – jak i plan działań – co i jak – to wynik można wykorzystać do planowania kolejnych kroków.

Trzeba jednak pamiętać! hack day to hack day. Nie ma zróbmy spotkanie w trakcie, przed lub po. Nie, to jest cały dzień dla programisty. Ma się on bawić i poznawać nowe technologie które mają spełnić cel hack dnia. Ma on nie odpowiadać na maile, telefonów itp. Trzeba to uszanować.

U mnie, po wielu miesiącach starań udało nam się wprowadzić hack day. Dzień w którym każdy programista, bierze na kark jakąś technologię przez siebie wybraną i patrzy na jej możliwości i wykorzystanie. Próbuje zrobić Proof Of Concept. POC miał być czymś co możemy wykorzystać w aktualnych produktach. Jasno postawiony cel powodował z miejsca filtr technologiczny.

Dokładniej wyglądało to u nas to tak:

• Zbieranie na jedną wspólną listę wszystkich pomysłów na wypróbaowanie technologii, języka itp.
• Wybranie z tej całej listy jednej, JEDNEJ rzeczy na hack day per osoba.
• Ta JEDNA rzecz musiała dać możliwość wykorzystania jej już w istniejących produktach.
• Spisujemy spostrzeżenia.
• Jak da się to pokazujemy demo.
• Dajemy werdykt.

Kilka prostych kroków ale dało to nam bardzo dużo. Nie tylko udało się przekreślić technologię jak i wybrać inną do wsparcia supportu (o tym jeszcze pewnie napiszę).

Nie mylił bym tutaj Hack Day z firmowym pet project – bo zarówno cel jak i wykonanie znacznie się różni. Jedno jest sprawdzaniem idei i weryfikacji czy się ona przyjmie. Drugie jest nauką przez eksplorację, na którą można poświęcić znacznie więcej niż jeden dzień.

Gorąco więc zachęcam wszystkich do namówienia pracodawcy lub (jak jesteś pracodawcą) do wdrożenia hack day u siebie. Pamiętajcie tylko by ustalić dobry odgórny cel i się go trzymać. Nawet jeżeli po takim dniu będzie tylko i wyłącznie odpowiedź, że testowanych technologii nie da się wykorzystać do danego celu, to dzień nie jest stracony. A więc przeciwnie. Wiedza o tym, co się nie sprawdzi jest wiedzą równie ważna jak nie ważniejszą od tej która mówi co się sprawdzi.

Mieliście takie dni już u siebie? Co robiliście? Co mieliście określić? Nie mieliście, to co o pomyśle uważacie?