Programowanie z misiem

Czytałem niedawno artykuł Moniki na temat refaktoryzacji. Natrafiłem tam na wzmiankę o programowaniu z misiem i natychmiast pomyślałem, że to jest coś o czym chciałbym napisać.

Być może już słyszałeś o technice programowania z misiem, a może o programowaniu z gumową kaczuszką czy innym „pomocnikiem”, ale na wszelki wypadek wyjaśnię o co chodzi.

Gdy programista (albo ktokolwiek, bo w zasadzie ta technika nie musi ograniczać się do programowania) natrafia na problem, z którym nie potrafi sobie sam poradzić, zamiast zwracać się do kolegów może zgarnąć misia i jemu wytłumaczyć zadanie, z którym aktualnie się męczy. Miś (jak to misie mają w zwyczaju) nie za bardzo zna się na programowaniu i niestety nie udzieli pomocy osobiście, a mimo to technika ta często pomaga!

Wejście misia

Gdy po raz pierwszy usłyszałem o programowaniu z misiem, byłem bardzo rozbawiony (prawdę mówiąc nadal trudno mi zachować powagę gdy o tym piszę) i do tej pory niestety nie widziałem tej techniki w akcji. Natomiast wielokrotnie sam czułem się misiem. Przez kilka lat pracowałem jako analityk, i choć obecnie moje stanowisko się zmieniło, nadal często pośredniczę w precyzowaniu wymagań pomiędzy biznesem a developerami. Czasem jestem proszony o pomoc gdy do podjęcia decyzji technicznej przydatna okazuje się znajomość dziedziny w której działa system. I właśnie w takich przypadkach często czuję się… pluszowy. Programista zaczyna tłumaczyć z czym ma problem, ja słucham, czasem zadaję pytania, czasem spytam też jakie są możliwe rozwiązania, ale przede wszystkim, przytakuję. Regularnie i bardzo sumiennie przytakuję. I na tym mój udział bardzo często się kończy, bo gdy tylko programiście uda się wyjaśnić mi w czym jest rzecz, nagle doznaje olśnienia i mój wkład nie jest już potrzebny.

Nie sugeruję, że moje pytania mają tak zbawienny wpływ, że rozwiązanie znajduje się samo, ani tego, że maestria z jaką przytakuję pobudza szare komórki rozmówcy do działania. Nie mam niestety takich mocy. Moje pytania może trochę pomagają, ale najważniejsze jest to co w trakcie naszej rozmowy robi sam programista.

Rozmawiając ze mną jest zmuszony do precyzyjnego opisania problemu. Do ubrania go w słowa zarazem precyzyjne jak i zrozumiałe dla drugiego człowieka. To zmusza go do ponownej analizy problemu i z jakiegoś powodu ta robiona na szybko analiza okazuje się skuteczniejsza niż ta, z którą wcześniej męczył się przez pół godziny. Dlaczego?

Myślę, że przyczyny mogą być dwie:

We łbie, czyli po łebkach

Pierwsza, to przeprowadzanie analizy problemu tylko w myślach. Brak faktycznego ubrania problemu w słowa. Bardzo często nie widzimy różnicy pomiędzy pomysłami wypowiedzianymi, a tymi które pozostają w naszej głowie, a potrafi być ona ogromna. Możesz uważać, że konieczność zamiany każdej myśli w słowa spowalnia pracę. Często wiesz jak coś ma działać, ale nie potrafisz znaleźć odpowiednio precyzyjnych słów. Analizując w myślach możesz taki fragment problemu po prostu przeskoczyć. Pominąć jako oczywisty. Czasem jednak diabeł tkwił właśnie w tych szczegółach. Często okazuje się, że odpowiednie dobranie słowa było dla ciebie trudne, właśnie dla tego że niedostatecznie rozumiałeś problem, albo w ogóle nie ma jednego słowa, którym można by go było opisać. Gdy później zmuszony sytuacją zaczynasz drążyć szczegóły, nagle odkrywasz cały dodatkowy proces, który wcześniej starałeś się upchać pod jednym słowem.

Od razu wyjaśnię, że nie sugeruję żebyś werbalizował każdą swoją myśl, przeglądając przy tym słownik języka polskiego i encyklopedię, ale gdy napotkasz trudny do rozwiązania problem na pewno zawsze warto go wypowiedzieć lub zapisać, żeby mieć pewność że w myślach czegoś nieświadomie nie „zamiotłeś pod dywan”.

Na piśmie, czyli formalnie

Druga przyczyna jaka przychodzi mi do głowy leży po przeciwnej stronie tego samego spektrum. Jeśli tak jak ja masz w zwyczaju wspierać się słowem pisanym podczas analizy trudniejszych problemów, może również masz skłonności do zbytniego formalizowania tego co piszesz. Trochę mi zajęło zanim zrozumiałem ten błąd, więc może komuś oszczędzę czas dzieląc się tym doświadczeniem: pisząc dla samego siebie nigdy nie staraj się przy tym brzmieć mądrze.

W szkolnych wypracowaniach stosowanie mądrych słów zawsze było nagradzane. Na studiach prace często trzeba było pisać w trzeciej osobie, jakby nie pisali ich studenci, tylko roboty. W pismach urzędowych, a nawet dokumentacji analitycznej nadal standardem jest bezosobowy biznesowy ton. Taki sposób pisania może się komuś wydawać mądrzejszy, bardziej precyzyjny lub po prostu poprawny. Często zabieramy się do opisu problemu właśnie tak jak nas uczono: mądrymi słowami, które trafiają w samo sedno problemu; sprytnymi zdaniami, które wyjaśniają wszystkie niuanse; obszernymi listami, które nie pozostawiają żadnych wątpliwości… a potem gdy chcemy wyjaśnić ten sam problem koledze, pomijamy wszystkie te ładne zdania i tłumaczymy w najprostszy możliwy sposób.

Do misia, czyli normalnie

I tu właśnie zbliżam się do sedna: analizując swój problem traktuj siebie jak zwykłego człowieka, nie pomijaj w analizie tego co wydaje się oczywiste, bo jak każdy człowiek bywasz omylny; ale też nie opisuj swoich problemów językiem który nie jest dla ciebie naturalny. Najlepiej od samego początku podejdź do sprawy tak, jakbyś rozmawiał ze swoim kumplem. Z kimś kto nie czyta w twoich myślach, ale z kim i bez tego świetnie się rozumiesz.

Dobrze byłoby, też żeby ten twój wymyślony rozmówca wiedział trochę mniej od ciebie, żeby jego niewiedza zmuszała cię do drążenia rzeczy, które tobie wydają się oczywiste.

…i żeby był pluszowy,

…albo przynajmniej umiał przytakiwać.