Zawód-team leader. Mój najważniejszy obowiązek. Przykłady z życia.

Tak jak napisałem w poprzednim poście: termin terminem, ale dzień w jedną czy w drugą stronę nikogo nie zbawi. A może mieć nieocenione efekty jeżeli chodzi o stosunek programistów do pracy, o zadowolenie z wykonywanych zadań, o zaangażowanie w projekt.

Dzisiaj – obiecane “real life” przykłady. Mam takowe póki co trzy, ale w sumie jak na kwartał pracy daje to całkiem niezłą “średnią innowacyjności”. Od razu pytanie: jak taka “średnia” wygląda u Was w firmie?

I do rzeczy…

Na jednym ze środowych cotygodniowych spotkań okazało się, że jeśli aktualnie rozpracowywany moduł zakończymy w 8 dni (do następnego piątku) to będzie całkiem nieźle. Tutaj zauważyłem swoją pierwszą szansę na przetestowanie jak moja “wolna ręka” do prowadzenia zespołu faktycznie sprawdzi się w praktyce – czy mi ktoś jej przypadkiem nie urąbie przy samych kolanach. Umówiłem się z zespołem, że jeśli wyrobimy się z pracą w 7 dni to ten nadrobiony piątek poświęcimy na przesiadkę z TFSa na Gita. Jak się okazało – zapał i chęci do spróbowania czegoś tak odmiennego (i zarazem tak przemegazajebistego:) ), i to w ramach normalnej pracy, spowodował, że pod koniec czwartku wszystkie zadania były skończone. W umówiony piątek przez pół dnia w “conf-roomie” opowiadałem o Gicie, pokazywałem jego zastosowania. Kolejne pół dnia każdy mógł się bawić Gitem już w kontekście naszego projektu, próbując realizować jakieś banalne zadanka, przestawiając się na nowy tryb wersjonowania kodu. Od tamtej pory jedziemy już na Gicie na stałe – przyjemne z pożytecznym. A wolnej ręki – jak się na szczęście okazało – nikt mi nie wyrwał z korzeniami.

Kiedy indziej w projekcie pojawiła się konieczność zastosowania dodatkowego źródła danych. Ot, jakaś tam poboczna mini-bazka z jedną tabelą do trzymania nieważne-czego. Śmiem mniemać, że standardowe podejście wyglądałoby tak: “naskrob datareaderów w ADO, bo to ci zajmie najmniej czasu, przemęcz się z tym, i zapomnij o całej sprawie”. Postanowiłem wykorzystać okazję do zrobienia z tak tępego zadania czegoś ciekawszego i zasugerowałem wykorzystanie Simple.Data. Byłem pewny, że jest to rozwiązanie nowe/nieznane dla zespołu (w końcu ilu programistów w Polsce zna tą bibliotekę?). A wiedziałem, że zabawa z tym jest przednia. Co najważniejsze: wiedziałem też z własnego doświadczenia, że to faktycznie DZIAŁA (innym ważnym obowiązkiem team leadera jest orientowanie się w najnowszych trendach/ciekawostkach, ale o tym nie teraz).

Trzeba jednak pamiętać, że jednym z najciekawszych aspektów pracy programisty jest samodzielne poznawanie i rozgrywanie nowości. Jaka frajda byłaby z całego tego zamieszania, jeśli bym od razu napisał swoje rekomendacje, best-practices, guidelines, podesłał kawałki swojego kodu etc…? Pewnie raczej średnia – bo skończyłoby się na pracy odtwórczej. Ograniczyłem się więc do podania linka do repozytorium na Githubie i zarezerwowałem programiście wystarczająco dużo czasu na ogarnięcie tematu, poczytanie bloga autora, ściągnięcie źródeł, poprzeglądanie sampli… Cała funkcjonalność na pewno zajęła trochę dłużej niż gdyby  namachał on ręcznie datareadera, ale… gdzie tu jakiekolwiek wyzwanie? Gdzie fun? Moim zdaniem frajda wynikająca z poszerzania horyzontów warta jest te kilka godzin w skali wielomiesięcznego projektu.

Tym bardziej, że zaraz doszły kolejne wymagania, z którymi dzięki Simple.Data uporaliśmy się w chwilę – a datareadery wymagałyby takiego samego obleśnego dłubania jak na początku, niosącego ze sobą zero wartości edukacyjnych oraz tonę irytacji i znużenia. Z moich obserwacji wynika, że taki skok w bok, zejście z wydeptanej ścieżki, programowanie przez eksplorację, ZAWSZE jest na dłuższą metę opłacalne.

Innym razem jeden z programistów nadspodziewanie sprawnie skończył zaplanowaną robotę – czy to poimplementował funkcjonalność, czy ponaprawiał bugi, czy coś tam jeszcze… Miałem dwa wyjścia: albo wysypać na niego nowy wór tasków, albo jakoś ciekawie wykorzystać ten nadrobiony czas. Wybrałem bramkę nr 2 – inaczej bym o tej sytuacji tutaj nie pisał.

Od samego początku w firmie ogromny nacisk kładę na tworzenie testów jednostkowych. Nawet działającą funkcjonalność, niepokrytą testami, zwykle odsyłam jako niezaakceptowaną z komentarzem “brak testów”. Po prostu – nie ma zmiłuj. Testy mają być i koniec.

Testy pisane są różnie. Ja sam praktykuję TDD, ale aktualnie nie wcinam się programistom w ich tryb pracy, nie narzucam kolejności pisania kodu – co za dużo naraz to niezdrowo. Na to jeszcze przyjdzie czas:).

W tej sytuacji pomyślałem jednak, że dobrze by było zrobić chociaż jakieś preludium do TDD – czyli docelowego, jedynego sposobu kodowania, do którego będę wszystkich ciągnął. Dorzuciłem programiście jedno nieskomplikowane zadanie, które w normalnej sytuacji zajęłoby pewnie maksymalnie pół dnia, i dałem na nie X czasu z zaznaczeniem “nie spiesz się, masz masę czasu – poeksperymentuj z TDD, Luke, odkryj Siłę Mocy!”. Kilka artykułów, kilka postów, kilka testów później – i na pewno dev o wiele lepiej “czuje” testy niż wcześniej. W tym projekcie to się być może nie przyda, ale w niedalekiej przyszłości – na pewno tak.

To tyle jeśli chodzi o przykłady zrealizowane. Mam w głowie dalsze pomysły na podobne urozmaicanie pracy, ale – wszystko trzeba dozować z umiarem, w końcu efektem pracy ma być działający, skończony projekt, a nie tylko banan od ucha do ucha na naszych informatycznych twarzach.

I tutaj właśnie mała uwaga: nie zachęcam bynajmniej do rzucania się w nieznane na oślep, do wybierania “ciekawszej” drogi za każdym razem gdy nadarzy się okazja. Trzeba znać umiar i wyznaczenie granicy w odpowiednim miejscu jest nie lada sztuką. Każdą sytuację z osobna należy racjonalnie ocenić. Nie można dać się ponieść “fali świeżości” i ignorując wszystkie okoliczności nieustannie brać się za coś nowego. To się dobrze nie skończy. Ale z drugiej strony – nie można też zapomnieć dlaczego zostaliśmy programistami. Co jest w programowaniu pociągające i ekscytujące? Co sprawia, że nie zazdrościmy znajomym ich profesji? Dzięki czemu możemy przyjść do biura i oddać się swojemu hobby? Gdy o tym wszystkim zapomnimy i pozwolimy prostemu rzemieślnikowi-koderowi ukraść naszą pasję to… przegraliśmy.

A team leader nie może pozwolić na przegraną swojego zespołu.

Wydaje mi się, że dość obszernie udało mi się opisać swoją wizję “teamleaderstwa” i jego główne, według mnie, zadanie. Wiem, że to jest coś, na co ja sam miałem naiwną nadzieję przez lata nieudanych poszukiwań “pracy idealnej”. Teraz los rzucił mi możliwość zrealizowania swoich niespełnionych wyobrażeń z trochę innej pozycji niż początkowo zamierzałem. Mogę tylko się starać i mieć nadzieję, że inni także patrzą na zawód-programisty w taki sam sposób jak ja.

Na koniec pytanie do team leaderów: co o tym wszystkim sądzicie? Czy też tak postępujecie?

I do “tych nad team leaderami”: jak byście zareagowali na takie działania team leadera? Jeśli byście oponowali i wyjechali z durnym tekstem “dość zabawy, mamy terminy!!!” to zaprawdę powiadam wam, pójdźcie po rozum do głowy. Rozchodzony, rozwijający się, zmotywowany, szukający alternatywnych rozwiązań i zadowolony ze swojej pracy programista jest wart o wiele więcej niż niewolnik z klawiaturą przypiętą kajdanami do nadgarstków, nad którym przez 8 godzin dziennie wisi ręka Pana Ciemności i chlasta go po ryju gdy tylko VS straci focus. Ogarnijcie się, goddammit!