Dzisiaj chciałbym poruszyć temat, który jest mi bardzo bliski, ale niestety często zaniedbywany. Chodzi o przeładowanie kognitywne w kontekście czytania, analizowania i pisania kodu.

Ile razy przeklinałeś pod nosem, widząc coś w kodzie, co było niezrozumiałe? Ile razy straciłeś mnóstwo cennego czasu, próbując zrozumieć, co autor miał na myśli, pisząc dany fragment kodu, tylko po to, aby ostatecznie dowiedzieć się, że nie działa on tak, jak ostatecznie myślałeś? Ja doświadczyłem tego wiele razy… Zdecydowanie za dużo.

Dlatego chciałbym przedstawić kilka stwierdzeń, które mogą skłonić do refleksji. Być może warto je przedstawić w zespole, aby każdy mógł zastanowić się nad tym co chce zaprogramować przed faktycznym kodowaniem.

Po raz pierwszy…

“Minimize cognitive load for others”

Bardzo cenna heurystyka dotycząca wytwarzania oprogramowania. Powiedziałbym nawet, że jedna z ważniejszych jakie znam. Zawsze powinniśmy podchodzić do tego co robimy w profesjonalny sposób. Powinniśmy doprowadzać do tego, aby wytwarzać kod wysokiej jakości. Wiem, nie zawsze się da. Czasem może się zdarzyć, że mamy zbyt małą wiedzę, aby zakodzić coś w prawidłowy sposób. Jeśli natomiast ją posiądziemy, to przy nadarzającej się okazji powinniśmy po prostu po sobie posprzątać. Głównie w jednym celu. Aby ułatwić innym pracę. I sobie z przyszłości.

Rzadziej piszemy kod niż go czytamy. Powtarzam sobie te słowa jak mantrę, ale taka jest prawda. Poświęcenie większej ilości czasu na napisanie czytelniejszego kodu zwróci nam szybciej niż myślimy. Podejrzewam, że w praktycznie 100% przypadków. Małą gwiazdką mogą być startupy, gdzie wszystko prototypujemy i wszystko jest potrzebne na wczoraj.

Po raz drugi…

“Avoid constant reverse engineering of the model from code each time we have to make change - that is an expensive & human error-prone operation”

To stwierdzenie znalezione w Internecie też dało mi sporo do myślenia. Niestety nie pamiętam jego autora, ale bardzo bym mu podziękował za zmuszenie do rozważań. Wsteczna inżynieria w tym stwierdzeniu, według mnie, odnosi się do sytuacji, w której mleko już się rozlało. Kod jest w tragicznym stanie. Jego “odkodowywanie” jest po prostu czasochłonne, a co za tym idzie - drogie. Każdy z nas może też inaczej zinterpretować kod, który przeczytał. Jak można poprawić tę sytuację? Wracamy do punktu powyżej… myślmy nad tym co piszemy.

I po raz trzeci!

“One of the hardest things in cooperation with other people is adopting other people’s mental models.”

Nikt nie powiedział, że współpraca z ludźmi kiedykolwiek będzie prosta. Przecież “nie po to studiowałem Informatykę, aby rozmawiać z ludźmi”. Jednak projekty są coraz to większe i coraz ciężej o sytuację, w której to nie będziemy kooperować z innymi ludźmi.

Jedną z cięższych rzeczy w komunikacji jest właśnie wejście do głowy innej osoby. Zrozumienie tego jak ona sobie wyobraża daną rzecz. I z drugiej strony, ciężko jest przekazać innym to co my mamy w głowie. Ja na przykład nie wyobrażam sobie nie posiadania skrawka tablicy, gdzie będzie mógł komuś zwizualizować swój punktu widzenia. Jeśli jednak działam online to zawsze mam “pod ręką” Excalidraw, który pozwala mi w łatwy sposób naszkicować omawianą sytuację.

Warto wspomagać się narzędziami. Nawet z nimi sytuacja nie jest prosta. Myślę, że im częściej z kimś rozmawiamy i każdy ma ten sam cel, tym lepiej będzie nam zaadoptować swoje mentalne modele.

Do brzegu

To tyle co chciałem dzisiaj przekazać. Mam nadzieję, że ten wpis zmusi Cię do przemyśleć i być może zainspiruje do działania, aby chociaż jednej osobie z zespołu otworzyć oczy. Liczę na to, że dzięki temu przyjemniej nam się będzie pracowało w naszej ukochanej branży IT.