#2 Rola wizualizacji w pracy inżyniera oprogramowania

Wszystkiego w głowie nie zmieszczę?!

To, że w ciągu ostatnich 20 lat rola programisty została znacząco przedefiniowana i rozszerzona wspominałem już w poście  #1 Manifest Agile?!… Obecnie samo pisanie kodu to tylko niewielka część kontekstu działań inżyniera oprogramowania i to wcale nie ta najtrudniejsza. Skoro w zespołach realizujących projekty programistyczne mamy i ciągle będziemy mieć do realizacji:

  • poznawanie dziedzin biznesowych,
  • zbieranie wymagań bądź ich redefiniowanie przy ścisłej współpracy z klientem,
  • projektowanie części bądź całych systemów lub aplikacji,
  • pracę z priorytetami, poziomem jakości oraz przy tym wszystkim próba zarządzania czasem,
  • szacowanie złożoności rozwiązań,
  • określanie celów natury rozwojowej i projektowej,
  • programowanie i to nie tylko w swoim „wiodącym” języku, ale też innym najlepiej spełniającym potrzeby rozwiązania, które realizujemy,
  • wdrażanie nowych członków zespołu w stack technologiczny, domenę biznesową, procesy,
  • testowanie, refaktoryzowanie,
  • oraz bardzo często wiele innych tematów, które mają złożony charakter analizy, procesowania oraz realizacji,

to nawet jeśli wszystkiego nie robi, każdy członek zespołu to warto zadać sobie pytanie – jak przy tej złożoności i ilości działań być efektywnym profesjonalistą? Tego wszystkiego w głowie nie zmieścisz! 🙂 

Jeżeli dogłębnie przeanalizujemy powyższe punkty to możemy dojść do wniosku, że w tym przypadku praca nad efektywnością jest ściśle związana z:

  • szybkością nauki,
  • jakością analizowania,
  • umiejętnością projektowania,
  • umiejętnością planowania,
i to w kontekście indywidualnym oraz zespołowym.

Skoro eksperci z MIT, twierdzą, że 90% informacji trafia do naszego mózgu w formie wizualnej to jest to niezły punkt wyjścia do określenia jak efektywność podnosić. A dlaczego to jest ważne z perspektywy inżyniera oprogramowania? 
Bo przecież w takiej roli musimy przyswajać i przetwarzać wiele informacji, a obraz jest najbardziej efektywnym sposobem dotarcia do naszego mózgu to czy nie jest to dobry kierunek….? 🙂 I nawet jeżeli 90% nie jest idealnie dokładną liczbą to z dużą dozą prawdopodobieństwa możemy stwierdzić, że jest to sposób w jaki przyswajamy najwięcej informacji. Wiedziały o tym nawet prehistoryczne ludy posługujące się pismem piktograficznym 😉


Jeżeli do powyższego dodamy jeszcze umiejętność tworzenia obrazów na podstawie informacji, które są kierowane do konkretnej grupy odbiorców i robione, aby osiągnąć założony cel to mamy już prawie pełną definicję – wizualizacji! 

Wizualizacja, która jest podstawą wielu technik szybkiego uczenia się, metod kreatywnych, projektowania i planowania. Pobudza też znaczącą mózg angażując ośrodki odpowiedzialne za myślenie logiczne, ale też abstrakcyjne. I zdecydowanie powinna być jednym z głównych narzędzi w pracy zespołów developerskich! Ale dlaczego i czy tak jest? 

Czy proces wizualizacji jest dla nas codziennością? 

A jeśli nie to #coztymIT?! Przecież może przynieść tyle dobrego! 

Spójrzmy więc na to co warto w codziennej pracy inżyniera oprogramowania wizualizować, jakie mamy z tego wartości oraz jakimi przykładowo narzędziami możemy się posłużyć:

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 proce
sie.

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: 


Jak ta definicja ma się do kontekstu naszego wyżej omówionego początkującego dewelopera?

Ucząc się np. programowania obiektowego już od samego początku zderzamy się z dość dużą złożonością. Poziomy abstrakcji, dziedziczenie, polimorfizm to zagadnienia, które są tłumaczone przez autorów książek i kursów na bardzo wczesnym poziomie w postaci wizualnej UML, schematów blokowych czy Box-and-Line Diagramów. Celem takiego działania jest oczywiście ułatwienie zrozumienia zagadnień. Bardzo często podejmujemy ćwiczenia, które angażują nas w przygotowanie diagramu tak aby był on dla nas na końcu zrozumiały. Wymienione narzędzia stają się dla nas naturalne i oczywiście ułatwiają one poruszanie się w świecie obiektowym. Ten proces to nic innego jak przejście po 3 krokach wizualizacji. Intencją (Krok 1) jest tu ułatwienie przyswajania wiedzy. Kreacja, obserwacja i nadawanie sensu (Krok 2) to ćwiczenia, podczas których sami tworzymy obraz. Końcowe zrozumienie i przyswojenie wiedzy (Krok 3) staje się naturalną konsekwencją tego procesu. Pisanie kodu wtedy staje się łatwiejsze, bo znamy też reprezentację graficzną problemu. Zdiagnozowaliśmy potencjalne trudności oraz określiliśmy czy rozwiązanie jest optymalne. Tak też działamy przez jakiś czas i jest to dla nas w miarę naturalne.

To co warto mocno zaznaczyć, podkreślić i uczulić, bo z doświadczenia wiem jak często o tym zapominamy to kwestia odbiorcy. Musimy wiedzieć dla kogo, graf, diagram czy model robimy!

Grupa docelowa jest dość problematyczna, kiedy to wchodzimy na wyższy poziom wizualizacji skierowany np. do osób z biznesu. Nie zawsze pamiętamy, że to odbiorca jest tu najważniejszy i niekoniecznie jakakolwiek notacja techniczna będzie dobra do zobrazowania np. właśnie omawianego przypadku biznesowego.

Ale co dalej? I dlaczego niby o wizualizacji zapominamy? Dlaczego nie używamy jej do optymalizacji innych działań, jak np. planowanie własnego rozwoju?

Według mnie dzieje się tak ponieważ, kiedy nabieramy doświadczenia, stajemy się coraz lepszymi programistami, popełniamy coraz mniej błędów, to aktywna forma wizualizacji choć bardzo efektywna idzie w zapomnienie.

Czujemy, że jesteśmy już na tyle dobrzy, że złożoność problemów nam nie straszna, że potrafimy ułożyć w głowie i wyobrazić sobie wiele relacji, warunków, warstw abstrakcji itd. I tym oto sposobem ćwiczona dość długo umiejętność powoli zanika. 

Czasami wręcz możemy być przekonani, że to wstyd spróbować narysować coś co inni mogą uznać za proste. No nie wypada! Ale po co?

Zapominamy przy tym o dobrodziejstwach procesu wizualizacji. Oczywiście na co dzień biernie korzystamy z diagramów, schematów i modeli zamieszczonych na najróżniejszych stronach, w dokumentacjach, książkach czy blogach. Potrafimy je nawet nieźle czytać i interpretować, ale o samym aktywnym procesie wizualizacji z wielu powodów zapominamy.

Z wielu powodów już jej nie robimy!

Ale czy o wizualizacji zapominamy już zawsze?

No nie! To, kiedy dochodzimy do wniosku, że to dobry moment, aby pozwolić sobie na powrót w szerokim stopniu do takich działań? A no kiedy mamy role / mandat na to, że robimy skomplikowane rzeczy. Kiedy projektujemy, kiedy zajmujemy się szerszym zakresem projektu, kiedy to poważna sprawa – tak poważna, że można ją nazwać architekturą i tak poważna, że robić może to tylko poważny architekt, projektant, a czasem nawet senior 😉

Ale tu się pojawiają kolejne problemy. Przez zaniedbania zapewne wieloletnie (nazwijmy je sobie programistyczną dziurą wizualizacji, rysunek poniżej) w doskonaleniu własnego warsztatu związanego z wizualizacją okazuje się, że musimy się tego uczyć na nowo, musimy przypomnieć bądź poznać techniki, narzędzia i poświęcić na to wiele czasu. Nawet jeżeli jesteśmy świadomi, że w zespole musi pojawić się jakieś działanie opatrzone procesem wizualizacji – możemy nie mieć wystarczająco dużo doświadczenia, aby w tym zakresie podjąć jakieś działania.

Krótka uwaga do powyższego wykresu. 

To co warto zaznaczyć, a to to, że nasza wspomniana dziura może rozkładać się na bardzo długi okres doświadczenia programisty. Zakładając, że kończymy aktywnie wykorzystywać wizualizację po pierwszym roku doświadczenia komercyjnego a intensywnie wracamy do niej w roli seniora czy architekta to może zdarzyć się, że minie jakieś 5-8 lat (oczywiście obiektywnie na to patrząc). Kawał czasu! Konsekwencje mogą być dość bolesne.

Ale czy to zawsze tak jest, że jesteśmy na bakier z tą wizualizacją i zapominamy jaka to ona jest fajna. No nie jest to reguła a trendy, metodyki (jeżeli stosujesz takie nieoszukane zwinne) i moda pomagają, aby sytuację odwrócić. Mowa tu o trendach związane z technikami, gdzie wizualizacja jest mocno wykorzystywana.

Uważam, że lista kategorii oraz sposobów wizualizacji opisana na początku tego posta może być dobrym punktem wyjścia, aby odpowiedzieć sobie na pytanie:

  • gdzie ja jestem jeżeli chodzi o wizualizację oraz
  • czy jej potrzebuję.

W temacie pojawia się też kilka mitów więc spróbujmy je przejrzeć.

MIT #1. Na wizualizację nie mam czasu! Muszę lecieć z kodem!

Masz czas! Każdy ma! Jak tylko zaczniesz ją traktować priorytetowo to wręcz zauważysz, ile czasu możesz zaoszczędzić poprzez przemyślane i ułożone działania. Eliminowanie błędów na wczesnym etapie realizacji, lepsze projektowanie oraz dyskutowanie i zadawanie bardziej celowanych pytań. To musi przyspieszać i podnosić jakość Twojej pracy!

Podobnie jak z pair programming’iem dopóki nie zaczniesz robić możesz mieć wrażenie, że to samo zadanie robią 2 osoby więc to strata czasu. Jeżeli nie weźmiesz pod uwagę oszczędności na code review, mniejszej ilości błędów (czyli mniej zaangażowania innych w proces dostarczenia) oraz wyższej jakości samego rozwiązania (mniej błędów na produkcji / architektura umożliwiająca elastyczną modyfikację) to właśnie w takim przekonaniu możesz tkwić. To błędne założenie!

Szeroki kontekst stosowanych metod i długofalowe z nich wartości powinny być kryteriami wyboru działań jakie traktujemy priorytetowo!

MIT #2. Jestem doświadczony więc wizualizacja jest mi zbędna!

Wydaje się, że opisane wyżej zalety, kategorie i narzędzia jasno pokazują jak istotne jest to zagadnienie, na każdym etapie pracy inżyniera oprogramowania. Nieważne czy uczysz się nowego języka, poznajesz nowe narzędzie, refaktoryzujesz aplikację, którą znasz na wylot czy może analizujesz wymagania, aby oszacować i zaprojektować nowy system w architekturze mikrousługowej. Wizualizacja podniesie efektywność, każdego uczestnika i na każdym poziomie wiedzy, kompetencji i umiejętności!



MIT #3. Nauka na błędach w wizualizacji to dobry pomysł!

Zdarza się czasami, że wygodniej jest nam zrobić jakąś reprezentację graficzną, która ma pokazać progres. Zaczynamy od błędów, problemów, niejasności a następnie kolejnymi formami graficznymi, próbujemy pokazać jak być powinno. Przykładem może tu być zarys architektury systemu, który refaktoryzujemy i kolejne jego wersje aż do postaci docelowej. Naturalne i prawidłowe prawda? To podejście może mieć jednak pewne pułapki. I o tym trochę niżej.

Podobną sytuację mamy, kiedy to po prostu prezentujemy grafikę właśnie po to aby na jej podstawie opisać lub omówić błędy. Jakiś czas temu spotkałem takie podejście w jednej z książek opisującej strategiczną część domain driven design. W ramach map kontekstu i wprowadzenia do tematu prezentowana była domena biznesowa, która standardowo zawiera domenę główną, subdomeny generyczne i wspierające, ale co ważniejsze również konteksty ograniczone. Te ostatnie są dość specyficzne i przyjęło się mówić, że trudne w zrozumieniu (dlaczego o tym w kolejnych postach). Oczywiście i tu podejście do przekazu graficznego nie było do końca trafne.

Ale dlaczego?
W obu przypadkach liczy się kontekst w jakim obraz został umieszczony oraz możliwość jego szybkiej interpretacji. Ważne, aby na pierwszy rzut oka było widać, że to nie jest prawidłowe rozwiązanie i służy tylko do dalszego procesowania. Patrząc na naszą przykładową reprezentację graficzną architektury do refaktoryzacji oraz model domeny biznesowej, na której są nieprawidłowo zarysowane granice kontekstów (co okazało się 20 dość ciężki w zrozumieniu stron dalej) możemy błędnie stwierdzić, że takie rozwiązania są jednak prawidłowe. Co gorsza na ich podstawie wyrabiamy sobie zdanie i nieświadomie możemy propagować dalej. Źle zrozumiana intencja twórcy / twórców grafiki może stać się przyczyną popularyzacji nieprawdy. A wiadomo kłamstwo powtarzane 1000 razy… 😉

Krążą wręcz legendy, że właśnie w taki sposób zostało rozpowszechnione użycie Waterfall. Lenistwo, czyli w tym przypadku pominięcie mało przychylnego opisu metody a skupienie jedynie na przystępnej i prostej grafice pomogło ponoć podjąć decyzję o użyciu metody kaskadowej w armii amerykańskiej. Ponoć!

Choć wymaga to energii musimy poznawać szerokie konteksty grafik, które analizujemy. Musimy też ten kontekst sami nadawać.

jeżeli jeszcze tego nie robisz zacznij notować np. w postaci mindmappingu – zobaczysz jak szybko zauważysz zalety wizualnych form porządkowania, kategoryzowania oraz przyswajania informacji.

spróbuj się zastanowić w jakich przypadkach i jak często tworzysz obrazy, grafy, diagramy, modele. Czy podczas ostatniego trudniejszego wyzwania taki proces miał miejsce? A czy nie uważasz, że mógłby pomóc?  

postaraj się podczas kolejnego podejmowanego zadania określić kategorię zadania oraz dobrać i wykorzystać jedną z zaproponowanych form wizualizacji. 

określaj priorytety podejmowanych działań. Pamiętaj nie zrobisz wszystkiego a warto wybierać te, które mają dla Ciebie największą wartość.

staraj się wizualizować własny rozwój np. przy pomocy mind mappingu, który pozwoli Ci wyrzucić z głowy i zobaczyć, ile tematów chciałbyś realizować. Wybieraj te priorytetowe.

staraj się do różnych form wizualizacji zapraszać innych. Przyspieszy to znacząco propagowanie wiedzy, wyłapywanie błędów i obieranie prawidłowych kierunków.

propaguj w zespole działania w oparciu o wizualizację.

czytaj #coztymIT?! tu powinny pojawić się opisy ww. metod wizualizacji w kontekście pracy inżyniera oprogramowania. Mam nadzieję, że to pomoże Ci podnosić własną efektywność. 

Znaczącą rolę wizualizacji w pracy inżyniera oprogramowania w tym wpisie chciałem jedynie zaznaczyć. Zrobić wstęp do tematu. Niektórym przypomnieć, że warto szukać czasu na takie działania. Z doświadczenia wiem jak wiele dobrego mogą przynieść.

Oczywiście, każdy z obszarów oraz techniki wymaga szczegółowego omówienia co dla wybranych postaram się zrobić w kolejnych wpisach. Pamiętajmy również, że nie ma idealnych narzędzi, do każdego typu problemu. Każdy też powinien znaleźć takie, które to dla niego będzie odpowiednie.

Starałem się zwrócić uwagę na kwestie indywidualnego użycia wizualizacji, bo to w tym obszarze wygląda najsłabiej. Na poziomie zespołów i w oparciu o metodyki takich działań pojawia się więcej lecz, z mojej perspektywy nadal za mało.

Zaczynając od nauki samego programowania, organizacji pracy, priorytetów, planowania aż po projektowanie wielkich systemów wizualizacja powinna nam towarzyszyć, aby podnosić efektywność oraz jakość. Nie możemy zapominać, że ludzki mózg ma swoje ograniczenia. Nasze zdolność myślenia abstrakcyjnego, przestrzennego, algorytmicznego, logicznego mogą być rozwijane, ale mają też swoje granice. Granice, które warto umieć przełamać!

A w kolejnych wpisach dalsze rozwinięcie tematów z VAR (Visualisation, Automation, Realization) w software developmencie. 

Zapraszam!

1 komentarz do “#2 Rola wizualizacji w pracy inżyniera oprogramowania

  1. Pingback: Projekt #coztymIT?! startuje a ja zachęcam Cię do wzięcia w nim udziału! - #coztymIT?!

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.