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

23

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-roomieopowiadał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!

Share.

About Author

Programista, trener, prelegent, pasjonat, blogger. Autor podcasta programistycznego: DevTalk.pl. Jeden z liderów Białostockiej Grupy .NET i współorganizator konferencji Programistok. Od 2008 Microsoft MVP w kategorii .NET. Więcej informacji znajdziesz na stronie O autorze. Napisz do mnie ze strony Kontakt. Dodatkowo: Twitter, Facebook, YouTube.

23 Comments

  1. Marcin Goł on

    Ogólnie to co napisałeś jest ok – ale ostatni akapit jest przerażający i to pod wieloma względami.

  2. Marcin Goł,
    Co znaczy "przerażający", i pod jakimi względami? Rozwinięcie mile widziane:).

  3. Marcin Goł on

    W skrócie (bo nie mam czasu):

    1) nie rób z ludzi "potworów" – uwierz że zarówno w warstwie TL jak i nad-TL są ludzie bardziej i mniej świadomi
    2) nie wiem z kim pracujesz jako nad-TL ale opis tego jak ich postrzegasz jest … ciekawy
    3) pracując jako TL fajnie się wrzuca ludziom "nową bibliotekę" – ale być może pracując jako nad-TL nagle spojrzałbyś na to że nie jest to jedyne rozwiązanie u Was, czy zespół obok również jej używa, co ze stabilnością tej biblioteki – czy za 3 lata dalej będzie można jej używać; czy za chwilę nie będziesz miał 100 rozwiązań i każde mocno inne w zależności od gustu TL’a ? Czyli zaczniesz myśleć dalej niż najbliższy kwartał :)

    Jakkolwiek to brzmi – pkt widzenia się zmienia wraz z pkt siedzenia – i często jako TL, po prostu NIE rozumiesz pobudek kierujących nad-TL (choć fakt czasem są one po prostu nie najlepsze;p). I wiem to sam po sobie.

  4. Marcin Goł,
    Potwora z nikogo nie robię, piszę na podstawie tego co widzę i słyszę. Wiem że tu jest lepiej, tam gorzej, jeszcze gdzie indziej jeszcze inaczej.
    A co do myślenia dalej niż najbliższy kwartał – zdecydowanie robię to już teraz.
    Decyzji ludzi "nad-TL" może i czasami nie rozumiem (słysząc opowieści z różnych źródeł), ale taki właśnie TL powinien je rozumieć, tzn ktoś powinien je wytłumaczyć. A nie "tak bo tak".

  5. Marcin, Maciek dobrze pisze. Ujmując to inaczej:
    Jeśli nie dajesz programistom pewnej wolności, możliwości poznania nowych ciekawych rzeczy. Jeśli tylko z czysto biznesowego ("bezpiecznego") powodu narzucasz im mało ciekawe rozwiązania, to znaczy, że jesteś krótkowidzem :)
    Taki model może zadziałać całkiem w porządku ale krótkoterminowo, później może być bardzo różnie. Po pierwsze zatrzymujesz zespół w epoce, która była wczoraj, po drugie dość szybko zaczniesz tracić najzdolnieszych programistów, pasjonatów, którzy stanowią największą wartość w zespole, po prostu przy pierwszej lepszej okazji wybiorą inne miejsce gdzie w końcu będą mogli się realizować. Ostatecznie zostaniesz ze słabym zespołem, który nawet przy wyborze "najbezpieczniejszego" rozwiązania będzie przyparzał wielu kłopotów.

  6. A ja i tak Wam wszystkim powiem, ze wszystko to zalezy od struktury i organizacji firmy. Jezeli firma jest zepsuta od samej gory, to zadne dobre intencje Team Leadera, PM’a i innych "pionkow na szachownicy" sa krotkotrwale. "Krol" ma juz swoj punkt widzenia i to doprowadzilo go do tego, ze ma duza firme i zatrudnia.

    Znam osobiscie kilka przypadkow, ze inteligentni ludzie zmieniali prace, bo nie mieli wsparcia psychicznego z "gory". Nikt nie pytal:"Jak sie masz? Jak idzie? Jak minal weekend?" i to bylo glownym czynnikiem, ktory zawazyl na zmianie pracy.

    Madrych ludzi nie trzeba ksztalcic, tak jak dla dobregu (zlozonego z doswiadczonych programistow) zespolu TL nie musi swiecic jak choinka. Dobrzy ludzie i zespoly kieruja sie same i same dojda do tego, ze np. mozna uzyc "Simple.Data".

    Swiecenie przykladem i ciagle pokazywanie nowych pomyslow jest dobre, gdy uczy sie swiezakow. Mlode osoby(0-4 lata doswiadczenia) absorbuja wiedze z automatu. Sam wyznaje mantre:"Jezeli dopada cie marazm w pracy i czujesz ze sie nie rozwijasz -> Zmien prace. Natychmiast!". To jest proste.

    Wg. mnie najwiekszym wyzwaniem jest stworzenie madrych ludzi i madrego zespolu, ktory bedzie tworzyl dobre oprogramowanie przez dluzszy czas, ale jest to temat na inna rozmowe.

  7. Hm, czy to jest "wolna ręka"? Zależy jak na to spojrzeć. W żadnym razie nie chcę Ci ujmować zasług ;), ale osobiście wolną rękę widziałbym jako możliwość podejmowania decyzji, typu lecimy normalnie, ale po tych 8 dniach, będzie dzień przerwy i robimy TFS-a. A tak de facto i sam programista mógłby się wyrobić szybciej ze swoimi zadaniami, niczego nie powiedzieć i coś tam sobie w ramach "ostrzenia piły" podziałać. Tak naprawdę, wystarczyłoby, żeby nikt nad Tobą nie wiedział, że już skończyliście i też miałbyś "wolną rękę". Ale ok, nie będę uprawiał czarnowidztwa, oby tylko nie okazało się, że ktoś doda dwa do dwóch i stwierdzi, że przestrzelacie się w szacunkach i zacznie je kwestionować. Pożyjemy, zobaczymy. Mam nadzieję, że będzie wyłącznie pozytywnie ;).

  8. PaSkol,
    Tak, moim zdaniem to jest wolna ręka.
    Te 8 dni, o których napisałem, nie było terminem narzuconym "z góry", a przeze mnie.
    Programista oczywiście może zrobić coś szybciej a potem "się uczyć", ale równie dobrze może robić potem inne zadnia. Albo nic.
    A co do "kogoś nade mną" – wielokrotnie już podkreślałem, że nie mam nadzoru typu który mógłby "dodać dwa do dwóch", jak to piszesz.

  9. Jak dla mnie (z punktu widzenia programisty) dobrze jest jak przełożony (PM, TL czy jak go tam nazywamy) proponuje zespołowi jakieś niestandardowe wyzwania, w stylu małego skoku w bok, aby poznać coś nowego. Rzeczywiście sprawia to zapalonym developerom przyjemność, zwłaszcza gdy nie jest to "Hello World!", a jest używane w rzeczywistym projekcie.
    Popieram taką postawę.

  10. Grzesiek on

    "nie mam nadzoru typu który mógłby "dodać dwa do dwóch"(…)"
    Aż tak nisko oceniasz inteligencje swoich przełożonych? :)
    Czy oni czytają Twojego bloga?

  11. Grzesiek,
    To co napisałeś to mega-nadinterpretacja:). Chodzi mi o to, że nikt mnie w ten sposób nie nadzoruje, a nie że ludzie są głupi. Swoją satysfakcję z aktualnej sytuacji wyrażałem na blogu wielokrotnie – a ta nie byłaby możliwa gdyby ktokolwiek choć w niewielkim stopniu był idiotą.
    I tak, czytają bloga, nawet komentują na fejsie niekiedy lajkują:).

  12. Ciekawy tekst. Z pewnością zawód team leadera to nie jest najłatwiejszy kawałek chleba. Znajomy ma podobne stanowisko więc często słyszę jego opinie, które pokrywają się mniej więcej z opiniami autora bloga. Pozdrawiam i życzę sukcesów.

  13. Mnie się podoba Twoje podejście. Ambitni pracownicy mieli motywację, żeby uporać się z zadaniami szybciej, bo wtedy będą mogli w pracy pod Twoim okiem zdobyć nowe doświadczenie, poznać nowe rzeczy, które sprawią, że późniejsza praca będzie szybsza i łatwiejsza. Obie strony mają sytuację win-win.

  14. Tak się w międzyczasie zastanawiałem nad tymi "marchewkami", którymi raczysz zespół i skonstatowałem, że to nie jedyne marchewki, które taki zespół chciałby skonsumować. Bo przecież (co pisałeś w innym wpisie) to Ty masz _decydujące_ zdanie o końcowym kształcie kodu. A dla niektórych programistów zespołu marchewką może być to, że w pewnym zakresie wchodzą Ci w kompetencje, czyli proponują alternatywne rozwiązanie. A to np., że część logiki interfejsu dla wzorca MVVM wsadzamy do CodeBehind, bo z punktu widzenia tego konkretnego, specyficznego widoku nie ma sensu wrzucać tego gdzie indziej. To niekoniecznie musi się zgadzać z obraną przez Ciebie linią rozwoju projektu. To również może rodzić konflikty. Przykładów takiej różnicy zdań może być wiele (czemu MVVM, może lepiej widok – mediator – model; czemu muszę używać jawnie definiowanych delegatów, zamiast Func<…> – albo na odwrót czemu Func<…>, a nie delegatów) a argumenty mogą po obu stronach być wystarczająco silne.

    I co teraz? Ustąpić w celu zaaplikowania marchewki, choć wg Ciebie tworzy to wyłom w przyjętej strategi prowadzenia projektu, czy samemu marchewkę skonsumować, a wygłodniałemu kazać przełknąć ślinę ;). Decyzje, decyzje, decyzje … (http://www.garfield.com/comics/vault.html?yr=1991&addr=910923) ;).

  15. PaSkol,
    Decydujące zdanie rozstrzygające spory musi mieć jedna osoba – inaczej zrobi się burdel. Tutaj, przy moim projekcie, tą osobą jestem ja. Ale oczywiście wszelkie sugestie czy propozycje usprawnień są mile widziane. Ba, są wymagane – to obowiązek programisty, to część pracy – identyfikować problematyczne kawałki kodu i wymyślać sposób ich rozwiązania. Przykład: w projekcie zaniedbaliśmy trochę sposób otwierania popupów w aplikacji i generowało to trochę powtarzalnego kodu. Programista zidentyfikował problem, zgłosił, zrobiliśmy task "refactoring otwierania popupów" i gdy nadszedł czas – dev zajął się tym w skali całej aplikacji wedle własnego uznania.

    Zaś co do kwestii Func<> czy delegaty, string czy String… to ja nie widzę mocnych argumentów po żadnej ze stron (ale też zbytnio się nad tym teraz nie zastanawiałem). Po prostu ktoś musi podjąć decyzję "jak", i tyle.

  16. Chodziło o "równie mocne" argumenty, czyli równoważące się, co prowadzi do impasu. Oczywiście wtedy – starym sprawdzony sposobem – głos decydujący ma przewodniczący (rym zamierzony ;) ). Ale to nie zmienia faktu, że wnioskujący jest zawiedziony i sfrustrowany. Nie ma marchewki.

    Wiem (z bloga oczywiście), że rodzinę założyłeś niedawno, więc potomstwa jeszcze brak ;), ale przykład, który podaję, trochę przypomina przepychanki z dziećmi. Możesz im powiedzieć: "nie bo to jest niedobre/niebezpieczne/nieopłacalne", ale w ich reprezentacji świata, są to nic nie znaczące informacje, bo one nie mają ich do czego odnieść (brak doświadczeń). Z dorosłymi jest łatwiej, bo można przekonać odpowiednim zestawieniem argumentów za i przeciw (i mają jakieś doświadczenia, więc skorzystają z analogii), ale jeśli jest impas, wówczas w pewnym sensie – korzystając z siły swojej decyzyjności – uniemożliwiasz programiście rozwój. Dlaczego? Bo brak jest odpowiedniego doświadczenia i dla niego może to pozostać złą decyzją prowadzącego zespół. Nigdy się nie dowie, czy rzeczywiście.

    Oczywiście nie mówię tutaj o tego typu sprawach jak wprowadzanie zupełnie innego narzędzia/metodyki/cokolwiek, w momencie, gdy projekt ma ściśle określone czego używa. Ale mówię o pewnych niuansach, które nie uderzają obuchem w projekt, choć w jakimś sensie zakrzywiają jego czasoprzestrzeń ;). I niekoniecznie wszystkie przykłady, które wcześniej podałem są trafione.

    Nie mam na takie coś gotowych rozwiązań, ale w takich przypadkach dobrym rozwiązaniem wydaje mi się, aby programista, który się [u]uparł[/u] ;), spróbował zrealizować swój pomysł po godzinach (skoro tak mu na tym [u]zależy[/u]) – jako alternatywę. Jeśli podejmie wyzwanie, to zyska i on i Ty, bo być może przy tej okazji coś się wykluje, tj. pojawi się dodatkowy argument, który przeważy szalę, na jedną lub drugą stronę. Wszyscy się nauczą.

    W przypadkach typu: Func<> czy delegaty dobrym argumentem prowadzącego jest mniej więcej: postaw się w moim, czy będąc TL i mając ściśle określone warunki brzegowe (ot choćby czas, zasoby ludzkie) rzeczywiście uważasz, że jest sens dokonywać tego typu ruchu. Oczywiście nie gwarantuje to sukcesu, ale bywa skuteczne, bo przy okazji jest zagrywką psychologiczną :).

  17. PaSkol,
    Wszystko to prawda. Każdy przypadek jest inny, staram się mieć argument za każdą swoją decyzją. Był do tej pory chyba jeden przypadek w którym musiałem powiedzieć "bo ja tak chcę". Przypadek ten to "string" vs "String". Jeden z programistów używał System.String, a nie aliasa c#. Musiałem zwrócić uwagę, bo tego nie lubię… ale to tyle. Nie ma korzyści z wydajności, zysk czytelności też jest dyskusyjny, wszystko to głównie kwestia preferencji.
    Wymyśl coś sensownego na ten temat:).

  18. Sensownego? Proszę bardzo – konwencja. Jeżeli zespół używa konwencji, wg której stosowane są aliasy, to odstępstwa są niedopuszczalne, albo są dopuszczalne wg ustalonych dla tej konwencji wyjątków.

    Gwoli podsumowania dyskusji. Chciałem zwrócić uwagę, że Twój [u]najważniejszy obowiązek[/u], ma więcej aspektów, niż poruszyłeś we wpisie. Że nie wystarczy jedynie rozdawać marchewki, ale i dostrzegać, kiedy takie marchewki członkowie zespołu mogą sobie zafundować sami.

    Mam nadzieję, że nie jestem zbyt uciążliwym czytelnikiem ;).

  19. PaSkol,
    Ano okej, to to był właśnie mój argument. Konwencja w zespole, którą ja narzuciłem, "bo tak":).

    Co do uciążliwości to zdecydowanie nie, dobre komentarze to największa nagroda dla bloggera:).

  20. Największa nagroda dla blogera są zadowoleni czytelnicy pytający o poradę drogą mailową, lub piszący dobre sensowne komentarze… a jak dopadną cie spam boty z komentarzem typu "Dzięki! super" i tak pod każdym wpisem to już kiepska nagroda z tego :)

  21. No to ja coś dodam z perspektywy byłego TL i obecnego nad-TL. Po pierwsze dla mnie TL jest takim samym devem jak dla niego jego ludzie. W końcu to też programista, tylko może trochę lepszy, z większym doświadczeniem i zdolnościami przywódczymi (kolejność od najmniej ważnej cechy do najbardziej). Jeśli mam ich powiedzmy 5 to w rezultacie sam jestem TL dla tego takiego zespołu. I mogę mieć z nim takie same problemy, szczególnie jeśli coś tam jeszcze wiem/pamiętam i rozumiem z ich pracy.

    Swego czasu miałem np. problem z nadużywaniem (moim zdaniem) var. I to między innymi właśnie przez TL (bardzo dobry programista). No i dylemat czy uprzeć się czy dać mu wolną rękę, jeśli zespół też to akceptuje. Dyskutowałem i tłumaczyłem dlaczego to nie jest dobre, ale w końcu odpuściłem.

    A z drugiej strony musiałem kiedyś powiedzieć wprost, że to ja decyduję co jest dobre a co nie. W końcu programista czy nawet TL to tylko ludzie i mogą popełniać błędy (z mojego punktu widzenia) i pewnych rzeczy po prostu nie przyjmować do wiadomości. Czasami jesteśmy głusi i ślepi na argumentację.

  22. Wydaję mi się, że od podejścia team leadera dużo zależy, a na pewno praca jego zespołu. Nikt chyba nie lubi działać pod presją, a praca w zestresowanym zespole to mała przyjemność.