Ostatnio miałem trochę przerwy od pisania na blogu. Nie oznacza to jednak, że w tym czasie leżałem do góry brzuchem. Większość mojego czasu pochłaniały przygotowania do przeprowadzenia pierwszego w życiu szkolenia – „Test Driven Development dla Systemów Embedded”.

Zebranie się w sobie

Pomysł na takie szkolenie chodził mi po głowie od bardzo dawna. W pracy od jakiegoś czasu funkcjonuje platforma do tworzenia szkoleń wewnętrznych i od kiedy powstała chciałem spróbować swoich sił jako trener. W okolicach Wielkanocy nawet spisałem sobie na kartkach trochę przemyśleń na ten temat, a na telefonie od dłuższego czasu robiłem listę przykładów z codziennej praktyki. Jednak to wszystko były plany dotyczące bliżej nieokreślonej przyszłości. W zeszłym tygodniu stworzyłem w końcu agendę, zgłosiłem szkolenie do HRów i od tego momentu sprawy mocno przyspieszyły. Miałem tylko tydzień na przygotowanie slajdów, przykładowego kodu i przećwiczenie sobie tego co miałem powiedzieć. Taki napięty grafik podziałał na mnie mobilizująco. Ciężko było się ze wszystkim wyrobić, ale ostatecznie się udało.

Przygotowania

W ramach przygotowań do szkolenia miałem wsparcie od doświadczonych prelegentów. Wspólnie mogliśmy dopracować takie szczegóły jak ilość osób na szkoleniu i kiedy ma wejść pizza, a także dostałem od nich wiele cennych wskazówek. Dowiedziałem się między innymi, żeby nie skupiać się tak mocno na reakcjach publiczności, żeby nie dać się wybić z rytmu. To, że ktoś np. ziewa nie musi wcale oznaczać, że prezentacja jest nudna tylko, że dana osoba po prostu jest zmęczona. A jeśli ktoś wyjdzie zaraz po przedstawieniu agendy to prawdopodobnie nie wiedział wcześniej co dokładnie będzie i po prostu zdecydował, że na szkoleniu nie skorzysta. Poza tym każdy ma swój własny styl prezentacji, w którym czuje się naturalnie i nie ma co na siłę kopiować innych. Nie ma też sensu na siłę zmieniać zaplanowanej agendy na bieżąco pod konkretną grupę.

Od strony merytorycznej byłem już przygotowany wcześniej. Przynajmniej miałem wizję, jak by to miało wyglądać. Musiałem tylko doprecyzować tematy, o których chciałem powiedzieć i przygotować slajdy. I tak zajęło mi to cały weekend. Najbardziej obawiałem się części improwizowanych związanych z interakcją z publicznością i pisaniem kodu na żywo. Opracowanie przykładowego kodu zajęło mi kolejny wieczór. Na przemyślenia dotyczące kodu przeznaczam niżej całą sekcję.

Na dzień przed wystąpieniem zrobiłem sobie próbę. Okazało się, że najciężej jest wystartować. Pierwszy slajd, gdzie miałem tylko się przedstawić i powiedzieć temat prezentacji powtarzałem kilka razy. Na slajdach z  agendą i wprowadzeniem do tematu też się zacinałem. Dopiero po wejściu w szczegóły techniczne słowa same zaczęły się wylewać.

Dużo pewności siebie nabrałem, kiedy uświadomiłem sobie, że mam w temacie kilka lat doświadczenia i mogę przytoczyć wiele ciekawych sytuacji z różnych projektów, w których brałem udział. Dodatkowo dzięki temu nabrałem przekonania, że poradzę sobie z różnymi trudnymi pytaniami zadawanymi przez uczestników. Z resztą nawet jak bym nie wiedział to nie ma tragedii, bo zawsze mogę zrobić research i odpowiedzieć w późniejszym terminie.

Prezentacja

Stres był największy przed szkoleniem. Było to połączenie ekscytacji ze strachem. Kiedy miałem przygotowywać prezentację trochę blokował przed ruszeniem, ale jak już to przełamałem, pozwalał się skoncentrować i długo pracować z dużą wydajnością. W dniu szkolenia ciężko mi było skupić myśli na czym innym. Jednak kiedy już przygotowałem kompa, rzutnik i ruszyłem z pierwszym slajdem, stres zaczął schodzić.  Natomiast kiedy wszedłem bardziej w szczegóły techniczne, już byłem tak nimi pochłonięty, że kompletnie przestałem zwracać uwagę na stres.

Miałem wrażenie, że tempo z jakim omawiałem kolejne slajdy było bardzo duże. Miałem wiele informacji do przekazania i koniecznie chciałem je wszystkie upchnąć w trzech godzinach szkolenia. Możliwe, że lepiej by było trochę zwolnić, przekazać mniej treści i bardziej nastawić się na interakcję. Interesujące publiczność tematy mógłbym potem dodatkowo rozwinąć podczas pytań na końcu. Jednak zastosowane przeze mnie podejście też ma swoje plusy. W końcu udało mi się w ten sposób przedstawić dużo informacji w skondensowany sposób.

Jeżeli chodzi o samą interakcję z publicznością, to jest też coś do czego muszę się przyzwyczaić. Interakcja jest wartościowa, rodzi ciekawe dyskusje i może powodować powstawanie śmiesznych przerywników. Jednak wybijało mnie to trochę z rytmu i potem znowu musiałem się przyzwyczajać do trybu monologu.

Podczas planowania czasu warto przeznaczyć na końcową sesję Q&A od razu jakieś 15 minut. Jeżeli ten czas nie zostanie wykorzystany, po prostu wcześniej skończymy. Poza tym może to być bufor, gdyby inne części trochę się obsunęły. U mnie przedłużyła się część praktyczna, a na końcu miałem jeszcze coś do powiedzenia i niestety musiałem to skrócić. A na Q&A już w ogóle nie starczyło czasu.

Przykładowy kod

Ta część była najtrudniejsza. Obawiałem jej się już podczas przygotowań i w trakcie szkolenia trochę na niej poległem. Przykład miałem przygotowany wcześniej. Kiedy na podstawie sformułowanych wymagań napisałem sobie próbnie implementację, zajęło mi to jakieś 20 minut. Na prezentacji dałem sobie na jego omówienie godzinę. W końcu to trzy razy więcej, powinno chyba starczyć. Otóż nie! Ten czas trzeba by pomnożyć chyba razy dziesięć.

Podczas pisania kodu najpierw muszę się wgryźć problem i po początkowym zastoju zaczynam wypluwać z siebie kolejne linie kodu. Jeżeli podczas pisania muszę jednocześnie tłumaczyć, cały czas się odrywam od pisania i żeby do niego wrócić muszę przestawić mózg z powrotem na odpowiedni tryb, co zajmuje trochę czasu. Potem jak tylko coś napiszę, znowu się odrywam, żeby coś wytłumaczyć. Poza tym przez stres częściej zdażają się literówki, łatwiej zapomnieć o jakimś średniku i ogólnie powstaje więcej głupich błędów, których dodatkowo trzeba na bieżąco szukać.

Skutek był taki, że po 40 minutach dalej byłem na początku przykładu i już wiedziałem, że nie mam szans się wyrobić. Uratował mnie wcześniej przygotowany kod na gicie, gdzie odpowiednimi commitami oznaczyłem poszczególne kroki. Dzięki temu zamiast pisać na żywo, mogłem checkoutować zmiany i tłumaczyć co się zmieniło od ostatniej wersji. Niestety skok pomiędzy commitami był dosyć duży i nie byłem w stanie dobrze odtworzyć toku myślenia podczas powstawania kodu.

Z tej sytuacji wyciągnąłem dwa wnioski. Pierwszy jest taki, że aby pokazać sprawnie przykład najlepiej przygotować sobie wcześniej implementację na gicie z dużą granulacją i wytłumaczeniem dokładnym co się dzieje w commit message. Dzięki temu odpada pisanie na żywo, a poza tym zostaje z tego wartościowy materiał dydaktyczny.

Drugi natomiast jest taki, że aby napisać cały przykład na żywo, trzeba znać kod, który chcemy zaimplementować, na wylot. Poza tym trzeba mieć wcześniej przemyślane co chce się powiedzieć w danym momencie. Najlepiej coś takiego prowadzić jako oddzielne warsztaty, a nie jako godzinna część większej całości. To po prostu zajmuje dużo czasu. Jak wspomniałem wcześniej czas potrzebny na napisanie tego samemu należy przemnożyć przez dziesięć.

Podsumowanie

Kiedy szkolenie się skończyło byłem strasznie wypompowany z energii, ale jednocześnie zadowolony. Poszło mi całkiem dobrze, chociaż jest parę rzeczy do poprawy. W firmie są już chętni na kolejne dwie grupy do tego szkolenia w sierpniu. Poza tym mam zamiar pójść za ciosem i robić kolejne szkolenia będące kontynuacją tego tematu.