Złudzenie zrozumienia: dlaczego dopiero pisanie pokazuje, co naprawdę wiesz

Myślałem, że rozumiem closure. Używam go codziennie, wytłumaczyłbym go w trzy zdania. Potem usiadłem, żeby napisać o nim post - krok po kroku, bez pomijania trudnych miejsc - i utknąłem na pytaniu, na które nie umiałem odpowiedzieć od ręki: co dokładnie funkcja zabiera ze sobą, gdy ją zwracasz, i kiedy ta referencja powstaje. To nie była wiedza, której nie miałem. To wiedza, którą czułem, że mam.

Okazuje się, że to nie przypadłość początkujących. Psychologowie poznawczy nazwali to złudzeniem głębi wyjaśnienia: z reguły oceniamy swoje rozumienie mechanizmu wyżej, niż wynosi ono naprawdę, i orientujemy się w tym dopiero, gdy próbujemy ten mechanizm odtworzyć. Rozenblit i Keil pokazali to w 2002 roku na zwykłych przedmiotach - poproszeni, żeby ocenić, jak dobrze rozumieją rower albo spłuczkę, ludzie stawiali sobie wysokie noty, a potem nie potrafili wytłumaczyć, jak to właściwie działa, i swoją ocenę obniżali. Z closure jest tak samo, tylko granica leży gdzie indziej: u jednego na tym, jak w ogóle działa, u innego na tym, czemu dokładnie microtask wyprzedza setTimeout. Granica się przesuwa, ale zawsze gdzieś jest. Pytanie nie brzmi, czy ją masz, tylko gdzie u ciebie leży - a najszybciej znajdziesz ją, próbując coś wytłumaczyć.

#Skąd się bierze to złudzenie

Czytanie i oglądanie dają płynność: mózg rozpoznaje znajomy kształt i melduje „rozumiem”, myląc znajomość z rozumieniem. A skoro nic nie stawia oporu, nie zauważasz, że po cichu przeskoczyłeś każdy trudny krok.

#Dlaczego pomaga pisanie

Pomaga jedno: produkować, a nie tylko konsumować. W badaniach nad pamięcią efekt generowania mówi, że informacja, którą sam wytworzysz, zostaje w głowie lepiej niż ta, którą tylko przeczytałeś - nawet przy identycznej treści. Pisanie jest właśnie takim wytwarzaniem. Musisz ułożyć każdy krok w kolejności, a każdy, który wcześniej przeskakiwałeś, robi się widoczny, bo nie da się go zapisać, nie rozumiejąc.

Efekt jest jeszcze silniejszy, gdy piszesz dla kogoś, kto widzi temat pierwszy raz. Sama perspektywa nauczania zmienia to, jak porządkujesz wiedzę: w eksperymencie osoby, którym powiedziano, że będą musiały komuś wytłumaczyć materiał, uczyły się lepiej i układały go porządniej niż te, które przygotowywały się „tylko” do testu - mimo że ostatecznie nikt nikogo nie uczył. Dlatego nie zaczynam posta od tematu, który mam opanowany. Zaczynam od tematu, co do którego mam wrażenie, że go rozumiem, i piszę go dla czytelnika-nowicjusza - bo nic nie weryfikuje tego wrażenia szybciej niż konieczność wyłożenia go komuś z zewnątrz.

#Najpewniejszy test: kod, który działa

Jest jednak test jeszcze bardziej bezwzględny niż samo tłumaczenie: zbudowanie czegoś, co naprawdę działa. Tekst da się naciągnąć - dobrać słowa tak, żeby luka nie rzucała się w oczy. Kodu nie naciągniesz: albo wykonuje się tak, jak twierdzisz, albo nie. Gdy do posta o event loopie budowałem interaktywną kolejkę microtasków i macrotasków, nie było gdzie się schować - musiałem dokładnie zrozumieć, kiedy microtask wchodzi przed setTimeout, bo inaczej animacja pokazałaby to źle. Tak samo przy poście o Big-O, którego uczyłem się niemal od zera: byłem pewny, że „Map ma O(1)”. Dopiero gdy budowałem suwak z prawdziwymi liczbami, zobaczyłem, że Map daje O(1) tylko średnio - w typowym przypadku tak, ale nie z gwarancją w każdym. Czytając, w ogóle bym tego nie zauważył - wyłapałem to dopiero, bo demo musiało być prawdziwe.

Ten nawyk ma skutek uboczny, który wychodzi daleko poza blog: trudniej mi oszukać samego siebie w codziennym kodzie. Kiedy łapię się na myśli „działa, choć nie do końca wiem czemu”, to jest dokładnie ten moment, w którym kiedyś bym sobie odpuścił - a teraz traktuję go jak sygnał, że gdzieś jest dziura, której jeszcze nie nazwałem.

Praktyczny wniosek jest trochę niewygodny: uczucie „wiem to” jest właśnie tym, czemu nie warto ufać, bo to ono zwodzi najskuteczniej.