#2 Rola wizualizacji w pracy inżyniera oprogramowania

A więc podsumowując to co zyskujemy:

• szybki sposób przyswajania i pozyskiwania wiedzy,
• dogłębna analiza pozwalająca szczegółowo poznać zagadnienia,
• budowanie potencjału optymalizacyjnego,
• pobudzanie kreatywności,
• szybka weryfikacja błędów,
• porządkowanie, systematyzacja informacji,
• jeżeli robimy ją zespołowo to propagujemy wiedzę na wiele osób oraz pracujemy nad spójnym zrozumieniem zagadnień,
• efekt jest zmaterializowany i do takiego obrazu można, w każdej chwili wrócić.

Jeżeli mamy jeszcze jakieś wątpliwości do zasadności wizualizowania to może rozszerzenie wątku o kreatywności trochę pomoże.

Praca inżyniera oprogramowania to również wiele decyzji. Wybór frameworków, narzędzi, ich łączenia oraz niezliczona ilość sposobów rozwiązywania problemów. To bardzo często praca przy nowych produktach, których rynek jeszcze nie widział, bądź rozwój istniejących rozwiązań zgodnie z nowymi bardzo często innowacyjnymi potrzebami biznesowymi. Musimy w takich działaniach wykazywać się kreatywnością. Nawet jeżeli pojawia się nierealny deadline to właśnie pobudzenie kreatywności może pomóc nam wymyślić coś co pozwoli nam termin dotrzymać. 

A jakie są sposoby na pobudzanie kreatywności? 

Z pomocą przychodzi tu autorytet w dziedzinie. Clayton Christensen, który twierdzi, że kreatywności możemy się uczyć poprzez: 

• kojarzenie – szukanie powiązań między problemami bądź pomysłami z odrębnych dziedzin, 
• zadawanie pytań – kwestionujących powszechną mądrość, 
• obserwacje – badanie zachowań innych, doświadczonych aby zidentyfikować nowe sposoby działania,
• networking – spotkania z ludźmi o różnych pomysłach i perspektywach,
• eksperymentowanie – konstruowanie interaktywnych doświadczeń i prowokowanie niekonwencjonalnych odpowiedzi. 

Nie da się ukryć, że większość tych działań zapewniają nam narzędzia wizualizacji opisane wyżej. Przykładowo realizacja mind mappingu w zespole, który chce rozpocząć refaktoryzację obecnego systemu stwarza przestrzeń na zadawanie pytań i szukanie odpowiedzi, które nie są proste a czasami wręcz musimy szukać ich poza zespołem. Pozwala na spotkanie specjalistów z różnym doświadczeniem, wieloma perspektywami i szerokim doświadczeniem. W końcu pozwala również, określić obszary w jakich możemy eksperymentować, bądź takie eksperymentowanie dzieje się już podczas tworzenia mapy. Może to prowadzić do wielu skojarzeń i wypracowania alternatywnych ścieżek. Wizualizacja staje się tu esencją pobudzania kreatywności. 

To jak to wygląda w rzeczywistości? Czy standardowo programista uważa wizualizację za coś naturalnego i wartościowego we własnym warsztacie pracy? Z mojej perspektywy wygląda to tak. Kilkanaście lat komercyjnego programowania, dziesiątki spotkanych na tej drodze programistów, architektów oprogramowania, liderów, wiele zespołów, wiele projektów i wiele wymienionych opinii w temacie jasno pokazuje, że wizualizacja to proces szczególnie zaniedbany i niedoceniony. Nie zawsze jesteśmy w stanie określić jakie wartości mogą z szerokiego kontekstu wizualizacji płynąć a dodatkowo nie potrafimy skutecznie dobrać odpowiedniego narzędzia do charakterystyki problemu. Jest za to kilka ciekawych sytuacji, kiedy wizualizacja pojawia się szerzej.

Junior vs Architekt w kontekście wizualizacji?!

Rozpoczynając naukę programowania dużo łatwiej jest nam przyswajać informację np. o podstawach programowania obiektowego używając notacji UML (swoją drogą wyrabia ona złe nawyki programistyczne, ale o tym innym razem), którą poznajemy dość wcześnie. Bardzo często staramy się również używać jednego z pierwszych sposobów tworzenia diagramów w IT czyli Box-and-Line Diagramów (krechy i kwadraty ale jakie skuteczne). Po prostu staramy się zobaczyć coś co jest dla nas trudne. Robimy tego dużo, bo i zagadnień jest sporo a to, że często są bardzo abstrakcyjne nie ułatwia sprawy. Poznajemy również schematy blokowe, na których możemy przeprocesować i zobaczyć algorytmy, różnego rodzaju warunki, pętle czy ścieżki decyzyjne. I zazwyczaj bardzo nam to pomaga!

Warto w tym miejscu zwrócić uwagę, że nauka programowania to tylko na początku składnia języka, algorytmy i paradygmaty. Kolejnym etapem jest wykorzystanie umiejętności technicznych do rozwiązywania realnych problemów naszych klientów. Nie da się tego zrobić bez poznania konkretnych dziedzinach biznesowych. Bardzo często różnych w zależności od projektu jaki realizujemy. Wczoraj zajmowaliśmy się branżą medyczną, dziś robimy e-commerce a za kilka miesięcy… zapewne coś innowacyjnego! Szybko też okazuje się, że pisania samego kodu jest niewiele. Więc gdzie trafia większość naszej energii? 

A.Brandolini twórca metody Event Storming dość odważnie zaznacza, że kod jaki powstaje w software developmencie to tylko efekt uboczny. Efekt uboczny procesu nauki. 

“Software Development is a learning process, Working code is a side effect”

Bardziej doświadczonym inżynierom oprogramowania na pewno trudno się z tym nie zgodzić.

Opisując wątek związany z nauką programowania i wizualizacją nie da się pominąć serii książek Head First, które znakomicie uczą kodowania w wielu językach. Jeżeli nawet programujesz już długo i jesteś osobą doświadczoną, ale do tej pory nie miałeś jeszcze okazji poznać założeń tych pozycji to po prostu musisz to zrobić!

Ale dlaczego to jest takie ważne? 

Ze względu na zastosowane w książce techniki, które mają pomóc nam w dwóch rzeczach:

• skutecznie nauczyć się opisywanych zagadnień oraz
• nauczyć się metod efektywnego uczenia się (metapoznanie)

I to właśnie ten drugi element stanowi olbrzymią przewagę nad innymi podobnymi pozycjami. Autorzy doskonale i to od samego początku pokazują jakimi mechanizmami będą się posługiwać, aby ich odbiorca mógł osiągnąć najwyższą efektywność nauki. Czasami wydaje się to dość dziecinne, przerysowane, kolorowe i komiksowe ale oni wiedzą co robią 🙂 . I aby w kontekście Head First mówić o wizualizacji trzeba wspomnieć o procesie.

Czytelnik nie dostaje suchych grafik czy schematów, ale również zapoznaje się z szerokim kontekstem w jakim obraz jest osadzony. Pobudzane są przy tym również emocje i występują elementy zaskoczenia. Bardzo często omawiana jest cała ścieżka rozpoczynająca się od intencji autorów (co musi zostać przekazane), poprzez proces tworzenia (jesteśmy wciągani w sposób myślenia o problemie, możemy obserwować jak powoli wyłania się końcowy obraz, jak nabiera sensu) aż po efekt, czyli sam obraz (obraz, który dostarcza informacje zgodne z intencjami i pasujący do określonego kontekstu). Wizualizacja użyta jest również do wzmocnienia innych obecnych w tej serii książek technik, ale te poznasz, czytając którąś z pozycji.

I jeszcze jedna drobna uwaga. Jeżeli nie czujesz potencjału wizualizacji oraz alternatywnych technik przyswajania wiedzy to może to być dla Ciebie trudna przeprawa. Ja właśnie tak miałem. Za pierwszym razem nie doceniłem potencjału. Wręcz stwierdziłem, że to raczej nie są książki dla przyszłego profesjonalisty. Nie skupiałem się znacząca na grafikach. Dzisiaj wiem jak bardzo się myliłem. Bez zrozumienia jak ważne jest pojęcie metapoznania, (uczenie o tym jak się uczyć) w którym to wizualizacja odgrywa olbrzymią rolę ciężko odejść od standardu “prawdziwych” podręczników do nauki programowania na rzecz “kolorowych książeczek” 🙂 Ale zapewniam! Warto!

Ta część staje się również świetnym miejscem, aby wprowadzić, trochę dodatkowej teorii. A właściwie kilka linijek wyżej już ją opisałem, ale teraz sobie posprzątajmy.

A więc wizualizacja to proces przekształcaniu dowolnej informacja do postaci graficznej skupiający się na: