Najlepsze szkolenia programistyczne

Co roku nieprzebrane bogactwa pompowane są w rozwój programistów. Czy faktycznie szkolenia warte są tyle, ile się za nie płaci? Na pewno nie wszystkie. Dzisiaj podzielę się z Wami refleksjami o Szkoleniu Idealnym – wartym swojej ceny.

Ponad cztery lata minęły od publikacji tekstu o wdzięcznym tytule “Szkolenia programistyczne, czyli maszyna ssąco-uciszająca“. Ależ wtedy sobie ulżyłem. Nadszedł czas na refleksje trochę z drugiej strony: skupię się na zaletach szkolenia-sukcesu, a nie wadach szkolenia-porażki. Szklanka jest w połowie pełna, nie? ;)

Wtrącenie:
Zachęcam do zapoznania się z moją ofertą szkoleń na devstyle.pl/szkolenia. Znajdziesz tam agendę kilku proponowanych tematów (testy, SOLID, CQRS, mikroserwisy) oraz informacje o szkoleniach otwartych.
Każdy program można pobrać jako ładny PDF i podesłać osobom odpowiedzialnym za organizację szkoleń Twojej w firmie. Do zobaczenia? ;)

Praktyka > teoria

Programista to taki zwierz, który z internetu korzystać umie jak mało kto. Logiczne, prawda? Jaki jest więc sens sadzania go w ławce i recytowania do jego uszu informacji, które odnajdzie w ciągu 5 minut obcowania z Google? Ano wydaje mi się, że… średni.

Przy okazji CraftConf 2015 wraz z Robertem uczestniczyliśmy w całodniowym warsztacie na temat mikroserwisów. Realizujemy projekt w tej “architekturze”, więc chcieliśmy przekonać się, ile jeszcze o tym nie wiemy. Prowadzący sroce spod ogona nie wypadł, bo był to koleś z Thoughtworks. Okazało się niestety, że przez bite 7 godzin nawet nie trzeba było otworzyć swoich laptopów. Ot, pooglądaliśmy slajdy, posłuchaliśmy i wyszliśmy. Bardzo, bardzo średnio. Wyszła z tego “jednoosobowa mikrokonferencja” o mikroserwisach, a nie szkolenie czy warsztat.

Szkolenie powinno obfitować w ćwiczenia praktyczne. Takie, które zaangażują zerojedynkowego dev-ducha. Moim zdaniem szkolenia w postaci warsztatów są o wiele bardziej wartościowe niż czysto teoretyczne wykłady. Oczywiście podstawy teoretyczne także muszą się pojawić, ale programista powinien robić głównie to, co lubi najbardziej, czyli: kombinować, zmagać się z wyzwaniami i rozwiązywać problemy za pomocą kodu! Od razu zastosować w praktyce wszystko to, o czym jest mowa. Teoria to tylko odpowiedni wstęp, podkładka.

W tym kontekście bardzo, ale to bardzo podoba mi się poniższy cytat:

Tell me and I forget. Teach me and I remember. Involve me and I learn.

(Benjamin Franklin)

Dobrze skonstruowane, ciekawe zadania mają jeszcze jedną zaletę: już dzień po szkoleniu programista może wziąć zdobytą wiedzę i zastosować ją w praktyce! Jeżeli jednym z ćwiczeń będzie, na przykład, odpowiednia konfiguracja kontenera Dependency Injection w aplikacji webowej i pokrycie tej konfiguracji testami, to co zrobi uczestnik szkolenia gdy następnym razem będzie musiał taką czynność wykonać? Wróci do materiałów szkoleniowych, przypomni sobie jak zostało to zrealizowane i DLACZEGO, a następnie świadomie zrealizuje część swojej codziennej pracy. Wiedząc dlaczego działa tak a nie inaczej, bez copy/paste ze StackOverflow.

Ale przecież każdy problem programistyczny można rozwiązać na wiele sposobów. Nie ma jednego idealnego złotego środka!

Jak najbardziej, dlatego też potrzebny jest:

Czas na dyskusje

Szkolenie, w przeciwieństwie do prezentacji na konferencji, to komunikacja w obie strony. A nawet w “trzy strony”: trener -> uczestnicy, uczestnicy -> trener oraz uczestnicy <-> uczestnicy! Komunikacji powinno być jak najwięcej. Pytania, dywagacje, wymyślanie dodatkowych scenariuszy i najlepszych sposobów na uporanie się z przedstawianym problemem – to wtedy tak naprawdę powstaje faktycznie pożądana agenda szkolenia. Każdy w sali powinien mieć okazję do wypowiedzenia się, podzielenia swoimi refleksjami i doświadczeniami. Zabierając głos nie chciałbym usłyszeć: “cicho, bo nie wyrobimy się z materiałem”.

Często te dwa czy trzy dni szkolenia to najlepszy czas na szczerą komunikację nawet w samym zespole, wśród uczestników! Być może na co dzień pracują w innych projektach i widują się przelotnie na kawie w kuchni, a może i to nie. Podczas szkolenia sami mogą lepiej się poznać i wspólnie wpaść na pomysł rozwiązania problemu dręczącego ich w codziennej pracy. Szkolenie to nie tylko “flow trenerskiej wiedzy”, ale również “team building”, jakkolwiek tego wyrażenia nie znoszę :). Jego charakter często jest nie tylko edukacyjny, ale i – w rozsądnych granicach – rozrywkowy.

Ja wolałbym skończyć szkolenie chwilę przed czasem (w razie braku dyskusji), niż siedzieć godzinę dłużej z pękającą głową, bez oddechu i możliwości wyrażenia swojego zdania, czekając tylko na koniec bo “kotlety w domu ubite, kartofli kipio, żonka zła, a ja jeszcze w robocie”.

Ważne jest również jednak do kogo się “swoje zdanie wypowiada”. Tutaj kluczowe okazuje się być:

Doświadczenie

Znam niestety przypadki szkoleń, podczas których jedyna różnica w wiedzy pomiędzy trenerem a uczestnikami jest taka, że trener ma jakiegoś “training kita”, czy jak to się nazywa. Czyta z książki po kolei co ma do przeczytania, a jeśli w książce nie ma na jakiś temat informacji, to po pojawieniu się trudniejszego pytania na sali słychać tylko… skowyt świerszczy ;).

Często wynika to z bardzo prostej przyczyny: brak doświadczenia praktycznego. Nie da się przygotować dobrego szkolenia z tematu, nad którym sam się człowiek nie natrudził, nie nagarbił, nie namęczył. Nawet podczas prezentacji wiedzy z książki, artykułu czy “encyklopedii”, osobiste doświadczenia szkoleniowca dają o sobie znać, przepuszczając wszystkie podane informacje przez bardzo wartościowy filtr: “ja WIEM jak to się sprawdza”.

Trener mówiący o testach powinien pisać testy. Trener mówiący o wdrożeniach powinien realizować wdrożenia. Wreszcie: trener mówiący o <TFU TFU przez lewe ramię, i prawe też na wszelki wypadek> SharePoincie, powinien w tym SharePoincie siedzieć po uszy! W przeciwnym wypadku: od razu widać braki. Widać, gdzie się zmyśla informacje na bieżąco. Kiedy się WIE, a kiedy się “gdyba”. I takie gdybanie, jeśli ma kamuflować brak doświadczenia, wygląda dość kuriozalnie. A nawet żałośnie.

Ale czy niezbędna jest alfa i omega? W praktyce: zdrowo jest zdawać sobie sprawę z tego, że nikt nie wie “wszystkiego” o “wszystkim”. Ba, nikt nie wie “wszystkiego” o “czymkolwiek”! Choćby nawet wydawało się inaczej. Zamiast tego co powiecie na to:

Trener członkiem zespołu

Takim jak wszyscy inni. Ze swoją wizją, bogatym doświadczeniem, rozległą wiedzą na eksperckim poziomie w prezentowanym obszarze, ale jednak… omylnym? Nie ma wszechwiedzących guru. Nie w “realu”, poza internetem :).

Miałem doświadczenia ze szkoleniowcami broniącymi niedających się obronić teorii. Ignorujących sensowne argumenty. Zamykających oczy na rzeczywistość inną niż ta przez nich kreowana. Puszczających mimo uszu niewygodne pytania. Bo przecież “trenerowi nie wypada się przyznać do błędu”. Lub “nieprzewidzenia wszystkich możliwych scenariuszy”. Tak? A no nie! Takie podejście nie zachęca bynajmniej do dalszych dyskusji. Ile zespołów – tyle problemów. I to niejednokrotnie tak pokręconych, że po prostu nie da się ich przewidzieć podczas przygotowywania materiału szkolenia.

W swojej “trenerskiej karierze” miałem już historię, kiedy to musiałem zmienić program szkolenia, bo jeden z zespołów uznał, że prezentowane przeze mnie podejście jest… dalekie od ideału. Podczas kilkuminutowej dyskusji uargumentowali to na tyle dobrze, że po prostu przyznałem rację. Nie jest to proste, gdyż materiał szkoleniowy powstaje przez naprawdę bardzo długi czas, dojrzewa i jest szlifowany, wydaje się być dopracowany w najmniejszych szczegółach… Czasami jednak spojrzenie kolejnych oczu z innej perspektywy burzy ten słodki obrazek i wychwytuje niedoskonałości. I to dobrze gdy tak się dzieje! W omawianym przypadku wspólnie wypracowaliśmy najlepszą alternatywę, pośmialiśmy się, i od razu po powrocie do domu poprawiłem materiał zgodnie z ich sugestiami. Kolejna edycja tego szkolenia będzie więc lepsza niż wszystkie poprzednie.

To buduje zdrową relację. Atmosferę dialogu. Zachęca do poszanowania wzajemnych – różnych przecież! – doświadczeń. Szkoleniowiec nie dostarcza wyrytych w skale przykazań, na pytania odpowiadając “BO TAK!”. Nie jest “jedynym mądrym w sali pełnej debili”. To by było strasznie smutne.

Skoro tak, to szkoda byłoby spędzić te wspólne chwile na przeciąganiu kontrolek po designerze, czyż nie?

Bez marnowania czasu

Niedawno rozmawiałem z firmą, która podczas zamawiania szkolenia upewniała się: “czy nie będzie tak, że połowę czasu spędzimy na konfigurowaniu środowiska i zadaniach pobocznych?”. Ano właśnie…

Czy programiści są w stanie w trakcie jednego szkolenia napisać cały skomplikowany system? Prawdopodobnie nie. Dlatego do każdego ćwiczenia, skupiającego się na wybranym elemencie zagadnienia, powinno być stworzone odpowiednio skonfigurowane środowisko. Czy to kawałki już napisanego kodu: wymaganego, a niemającego związku z zadaniem. Czy to gotowy skrypt instalujący potrzebne narzędzia/rozszerzenia. Czy to, w najbardziej rozbudowanych przypadkach, nawet cała maszyna wirtualna!

Nie oszukujmy się: nawet małpa byłaby w stanie wziąć myszkę w dłoń i poprzeciągać kontrolki z toolbara na designer. I czułem się właśnie jak małpa na szkoleniu, w trakcie którego na podobne – powtarzalne, nudne, banalne – zadania przewidziana była godzina.

Nienawidzę marnowania czasu: “ani swojego, ani bliźniego”. Zadania podczas szkolenia powinny mieć cel. Każde powinno wnosić coś nowego. Wymagać skupienia, uwagi i zaangażowania, ale nagradzać satysfakcjonującymi rezultatami.

A do tego wszystkiego, na koniec – okrasa:

Pasja i inspiracja

Bardzo pożądaną cechą u szkoleniowca jest to, aby prezentował coś więcej niż “tylko” materiał aktualnego szkolenia. Owszem, odpowiednie przygotowanie tych kilku(nastu) godzin jest niezmiernie ważne, ale co jeśli dodatkowo w trakcie spotkań da się… zmienić podejście do zawodu programisty?

Będąc smutasem, “odbębniającym te kilka godzin dziennie w dev-kopalni i do domu”, którego na chwilę wygonili z “cubicle” na szkolenie żeby wymusić przedłużenie lojalki, wbrew pozorom największą korzyść mogę wynieść nie z zawartości sladjów czy ćwiczeń, a z… rozmowy. W przerwach, przy obiedzie czy przy poszkoleniowym browarze. Z rozmowy z kimś, kto z zawodu programisty czerpie pełnymi garściami: jeździ na konferencje, uczestniczy w życiu lokalnych grup pasjonackich, potrafi wskazać drzwi do dev-społeczności i nazwiska warte poznania. Z kimś, kto może pokazać, ilu świetnych rzeczy związanych z programowaniem nie widać z tego “cubicle”. Z kimś, kto może na długo zmienić stosunek do wykonywanej pracy, otworzyć oczy na “dev-świat”. Wszędzie da się znaleźć możliwości rozwoju oraz zwiększenia satysfakcji z “roboty”, tylko trzeba wiedzieć gdzie tego szukać. Bywało już tak, że między jednym a drugim dniem szkolenia umawiałem się na występ na lokalnej grupie pasjonackiej. I gorąco zachęcałem cały zespół, aby wybrali się tam ze mną. Szczególnie jeśli byłby to ich pierwszy raz.

I co dalej?

Z wystąpieniami publicznymi przetestowałem pewien proces. Najpierw zdefiniowałem taką prezentację, jaką sam bym chciał oglądać. Prezentację “dobrą”, która nie jest marnowaniem czasu widza. A następnie zacząłem takie właśnie prelekcje przygotowywać i z nimi jeździć po konferencjach oraz grupach pasjonackich. Efekt? Blisko 100 prezentacji! Niektóre można obejrzeć tutaj: Video. A co najważniejsze z mojego punktu widzenia: podobają się publiczności!

Podobnie postąpiłem i tym razem. Kiedyś wylałem swoje żale odnośnie szkoleń – no i dobra, ale nic z tego nie wynikło, poza poklepaniem się po plecach z innymi programistami. Potem zastanowiłem się (dość długo) nad przyczynami niezadowolenia i pomyślałem jak można to wyeliminować. W końcu wraz z firmą Bottega zrealizowałem garść szkoleń według “swoich” reguł. Niejednokrotnie podczas przygotowywania materiału myślałem sobie: “ale to będzie fajne, sam bym chętnie w takim warsztacie uczestniczył!”. A to jest zdecydowanie tak zwany “precondition” udanego szkolenia. Czy faktycznie są one idealne? Zapewne nie, bo przecież zawsze coś można zrobić lepiej. Nie śmiem także twierdzić, że są najlepsze. Ale do tego dążę, a droga do celu jest opisana w powyższych akapitach. Sporo zależy od nastawienia i doświadczeń uczestników. Póki co okazuje się, że uczestnicy są zadowoleni. Na tyle, że niektórzy klienci od razu zamawiają kolejne tematy, bądź kolejne terminy. No i…? No i super, czyli to działa!