Programista nie może utykać na jednym zagadnieniu zbyt długo.
Zacznijmy od przykładu
Wyobraźmy sobie, że nauczyciel ceramiki ogłosił w dniu otwarcia nowego roku szkolnego, że dzieli klasę na dwie grupy. Powiedział, że wszyscy po lewej stronie będą oceniani wyłącznie na podstawie ilości wykonanej pracy (tj. wyprodukowanych doniczek), a ci po prawej stronie wyłącznie na podstawie jakości. Jego procedura była prosta: każdego ostatniego dnia zajęć przynosił wagę łazienkową i ważył pracę grupy „ilościowej”: pięćdziesiąt kilogramów garnków ocenianych na „szóstkę”, czterdzieści kilogramów na „piątkę” i tak dalej. Osoby oceniane na podstawie „jakości” musiały jednak wyprodukować tylko jedną doniczkę – aczkolwiek idealną – aby uzyskać „szóstkę”. Jak myślisz, jak ta historia się kończy?
Intuicja podpowiada, że grupa skupiona na jakości stworzyła lepszą doniczkę, a grupa skupiona na ilości stworzyła więcej doniczek. Ale tak nie było. Grupa ilościowa przewyższała grupę jakościową zarówno pod względem jakości, jak i ilości. Przynajmniej tak było w tej historii, opisanej przez Teda Orlando w Art & Fear: Observations On the Perils (and Rewards) of Artmaking.
Ilość często prowadzi do jakości za to koncentracja wyłącznie na jakości prowadzi na manowce
Kiedy zaczynamy uczyć się kodowania, często układamy plan nauki. Wierzymy, że potrzebujemy dokładnej mapy - w końcu nie możesz nigdzie dojść, jeśli nie znasz ścieżki. Czytamy więc dziesiątki artykułów na temat rozwoju oprogramowania i robimy skrupulatne notatki. Lubimy być produktywni więc zakładamy określone ramy czasowe dla każdej z tych zaplanowanych rzeczy i… porzucamy plan po tygodniu, miesiącu albo dwóch.
Okazuje się, że plan musi być zmieniany bo na przykład niektóre rzeczy zabierały więcej czasu niż się spodziewaliśmy. A czemu tak się dzieje? Czemu wszystko tak dokładnie planujemy? Bo boimy się rozpocząć naukę. Zmiana kolejności i harmonogramu to praca, która daje satysfakcję – ale donikąd nie prowadzi. Jesteśmy czasem jak ci uczniowie z grupy jakości, którzy tak bardzo myśleli o stworzeniu czegoś doskonałego, że nie mieli czasu na stworzenie czegokolwiek.
Perfekcjonizm to synonim prokrastynacji?
Podczas nauki kodowania ten perfekcjonizm może przybierać różne formy. Może to być przesadne planowanie, ale może też być przesadne przygotowywanie się. Wiadomo, że najlepszym sposobem (lub jedynym sposobem) na nauczenie się nowego języka programowania lub frameworka jest jego użycie. Potrafimy przyswoić dużo wiedzy teoretycznej, ale ta szybko zniknie, jeśli nie wykorzystamy jej w rzeczywistych projektach. Z drugiej strony nie możemy wykonywać żadnych projektów bez wcześniejszej wiedzy teoretycznej. Więc co zwykle robimy? Rozpoczynamy kurs z technologii, której chcemy się nauczyć. Po kursie czujemy się szczęśliwi i pełni energii — dużo się nauczyliśmy. Czas zacząć z niego korzystać. Ale… Zwykle nie czujemy się gotowi. Jeden kurs nie wydaje się wystarczający, aby zrozumieć złożone rzeczy. Więc zaczynamy kolejny kurs. I następny.
Ten rodzaj nadmiernego przygotowania jest powszechny wśród osób samodzielnie uczących się kodowania. Prawda jest tymczasem okrutna: nigdy nie będziemy całkowicie przygotowani. Jak wszystko w życiu, musisz zacząć, zanim będziesz gotowy. To jedyna droga. Strach przed porażką znacznie częściej zabija nasze marzenia niż robienie rzeczy niedoskonałych.
Jak walczyć z perfekcjonizmem
Nie komplikuj zbytnio swoich planów. Stwórz jedynie ogólny zarys rzeczy, których chcesz się nauczyć. Daj sobie dzień lub dwa na planowanie i zakończ, gdy minie czas. Każdy plan się zmienia, więc nie ma sensu go doskonalić.
Kiedy zaczniesz realizować plan, daj sobie trochę luzu. Podejmij pierwszą próbę tego, co robisz i załóż, że będzie to przeciętne. Jest to technika, której używają pisarze i nazywa się to „myśleniem w szkicach”. Pierwszy szkic powieści nigdy nie jest dobry. Nawet drugi lub trzeci. Pisanie to proces ciągłego doskonalenia, tworzenia szkic po szkicu.
Zrób to samo ze swoim kodowaniem. Pozbądź się presji bycia doskonałym; zamień ją na pragnienie stawania się coraz lepszym. Szybko napisz pierwszą wersję roboczą. Odkryjesz kilka opcji i sprawdzisz, czy jesteś na dobrej drodze. Szybkie kodowanie oznacza szybką informację zwrotną, a szybka informacja zwrotna to najlepsza informacja zwrotna.
