Jak (nie) rozmawiać o narzędziach

Jak (nie) rozmawiać o narzędziach

Obserwując nasze środowisko w trakcie luźnych rozmów na konferencjach, w mediach społecznościowych czy chociażby w komentarzach pod postami na blogach dochodzę do wniosku, że jednej umiejętności ciągle musimy się uczyć – umiejętności przyznawania, że świat za płotem naszego ogródka może wyglądać nieco inaczej niż u nas. Tyczy się to szczególnie rozmów o narzędziach które rzekomo mają decydować o natychmiastowym sukcesie lub porażce danego projektu. Dzisiaj kilka przykładów argumentów które w teorii mają pomóc przekonać rozmówcę do wybranego narzędzia, ale w moich oczach obracają się przeciwko autorowi danego stwierdzenia.

[Śledź mój kanał na YouTube – klik]

Używam, więc to jest najlepsze rozwiązanie

Zaczynamy prosto i przyjemnie. Zapewne wielokrotnie spotkaliście się z sytuacją w której przekonywano was do danej technologii, narzędzia czy rozwiązania tylko dlatego, że “ktoś tak robił i było okej”.

Problem w tym, że w świecie programowania najlepsze rozwiązania bardzo rzadko powstają tylko i wyłącznie dzięki autorytetowi autora. Pod uwagę bierze się rozmaite kwestie które mają pomóc ocenić rozwiązanie pod różnymi kątami. W efekcie takiej analizy i krytyki danego rozwiązania mamy pewność, że podejmujemy świadome decyzje – znamy mocne strony, znamy ryzyko, jesteśmy mniej więcej przygotowani na prawdopodobne problemy. Tak tak, problemy – problemy będą zawsze…

Być może rozwiązanie w teorii brzmi dobrze, ale jest zupełnie niepraktyczne? Być może rozwiązanie działa, ale jest zbyt kosztowne? Być może rozwiązanie jest praktyczne, ale w naszej firmie nikt nie pozwoli nam spędzić miesiąca na jego wdrożeniu? Być może firma która stoi za rozwiązaniem słynie z podejrzanych praktyk? Być może autor rozwiązania nie jest zainteresowany głosem społeczności przez co możemy zapomnieć na reakcję na zgłaszane przez nas bugi?

To wszystko rzeczywistość z którą musimy się mierzyć każdego dnia. Świadome decyzje… no cóż – świadome decyzje co do wyboru narzędzi które będą napędzać nasze projekty nie powstają ot tak. Tym bardziej nie powinniśmy ich bezpośrednio uzależniać od osób, które za nimi stoją.

Do momentu rozsądnej analizy sytuacji i argumentów innych niż imię i nazwisko autora powinniśmy pomyśleć dwa razy zanim pójdziemy w daną stronę.

Używam A, więc B nie może być dobre

To lekka modyfikacja argumentacji z punktu wcześniejszego. Tutaj nie bronimy technologii której używamy, a zamiast tego opisujemy jak słabe jest narzędzie z podobnej półki z którego nie korzystamy (z różnych powodów). Argument jest prosty – skoro nie korzystamy, no to nie może być dobre. 

A co jeśli… 

Co jeśli to, że nie używasz narzędzia świadczy tylko i wyłącznie o tym, że to TOBIE brakuje informacji na dany temat? Co jeśli przywiązanie do danego narzędzia spowodowało, że wpadłeś w silos – dany dostawca technologii przywiązał cię do swoich rozwiązań tak bardzo, że sam uwierzyłeś w jedno słuszne rozwiązanie? Co jeśli po dogłębnym zapoznaniu się z inną technologią okazałoby się, że jest ona równie dobra – jeśli nie lepsza?

W świecie nie-programistycznym bardzo łatwo przychodzi nam się zgodzić z tym punktem. Jeśli jeździsz Fordem, a narzekasz na Fiata w którym nigdy nie siedziałeś, to raczej nikt nie weźmie cię za eksperta od tej drugiej marki. Ba, nawet tobie samemu będzie głupio się na ten temat wypowiadać (a przynajmniej powinno). W programowaniu… no cóż – tutaj sprawy często wyglądają inaczej.

Projekt się powiódł

Czasami innych do danej technologii przekonujemy też faktem tego, że “projekt się powiódł”. Słysząc taki argument mam zawsze ochotę pociągnąć temat i dopytać o kilka istotnych kwestii:

  • Czy z rozwiązaniem które polecasz żyłeś tylko do daty oddania projektu klientowi, czy też zmagałeś się z utrzymaniem, rozszerzaniem funkcjonalności, naprawą bugów i wdrażaniem nowych pracowników do projektu? Czy wszystkie te kwestie szły równie dobrze? Czy brałeś faktyczną odpowiedzialność za swój kod?
  • Czy pracę nad projektem poprzedziła analiza dzięki której zrozumiałeś mocne i słabe strony wielu konkurujących ze sobą rozwiązań, dzięki czemu wybrałeś ten właśnie kierunek świadomie? Jeśli tak, to jakie to argumenty?
  • Czy projekt powiódł się zarówno jeśli chodzi o jakość wykonania i czas dostarczenia? Czy “powiódł się” nie oznacza tylko, że spędziłeś czas w technologii którą zawsze chciałeś wykorzystać i to jedyne co miało się liczyć? Jaką presję miałeś na sobie w trakcie pracy nad projektem?
  • Czy projekt powiódł się również w oczach osób które wykładają na niego pieniądze, których nie do końca interesuje zastosowana technologia a jedynie czas dostarczenia i wartość którą projekt przynosi?

Zdecydowanie nie chcę tutaj powiedzieć, że wybór technologii nie gra żadnej roli w kontekście dowiezienia danego projektu. Chcę tylko zaznaczyć, że na stwierdzenie “projekt się powiódł” składa się tak wiele kwestii, że bardzo trudno uwierzyć mi, że jedynym tego powodem było postawienie na konkretną technologię.

Netflix tego używa

Argument w którym powołujemy się na dużych graczy na rynku technologii nie jest wcale taki głupi. Jak świat światem młodsi (mniejsi) uczyli się od starszych (większych). Problem polega jedynie na tym, że problemy z którymi zmagają się ci więksi wymagają narzędzi, które w naszym przypadku często przypominają strzelanie z czołgu do muchy (chyba, że robicie drugiego Facebooka albo Google).

Obserwując takie serwisy jak Netflix, Facebook czy Google patrzymy tak naprawdę na liderów branży. Marki, na których skupia się uwaga całego świata generują ruch, jakiego prawdopodobnie nigdy nie doświadczymy w większości projektów w których mamy okazję uczestniczyć (np. pracując w software house’ach). Zmagają się one również z problemami, z którymi (dopóki nie zmienimy pracodawcy) możemy nigdy nie mieć okazji się zmierzyć.

Ślepe kopiowanie praktyk i projektów opisywanych na blogach technologicznych takich kolosów może kończyć się tym, że:

  • narzędzie mówiąc wprost “nie zarobi na siebie” – zanim zacznie przynosić jakąkolwiek wartość, wygeneruje nam mnóstwo problemów
  • narzędzie będzie niemożliwe do utrzymania – narzędzia tworzone w takich fabrykach jak Facebook to również ludzie i zespoły gotowe je utrzymywać i walczyć z problemami na bieżąco – większość z mniejszych firm nie może sobie pozwolić np. na dedykowany zespół zajmujący się utrzymywaniem frameworka
  • marka przesłoni nam racjonalne myślenie, niezbędne do podejmowania odpowiedzialnych decyzji – “no bo skoro Facebook stworzył XYZ, to musi to być dobre” mówione ze łzami w oczach po kolejnym dniu walki z daną technologią

Oczywiście w tym, że dane rozwiązanie stworzyła duża marka – szanowany gracz na rynku IT – nie ma nic złego. Kluczowe jest jednak to, żeby przed wskoczeniem do danego pociągu rozumieć dlaczego jedzie on w taką stronę a nie inną, jakie są plany autorów wobec niego, albo jak wygląda rozwój innych – być może mniej popularnych konkurentów.

Do przetrawienia jest to jeśli taki algorytm stosujemy dla swoich projektów. Gorzej w momencie, kiedy zaczynamy do niego przekonywać innych.

Co w zamian?

Można zapytać – no dobra, przez 5 minut zmuszasz nas do czytania o tym które argumenty są złe. Co w takim razie dajesz w zamian – jak mówić o technologiach i przekonywać do nich innych?

Sęk w tym, że ja osobiście wątpię, że na samym przekonywaniu kogoś do czegoś powinniśmy się w ogóle skupiać mówiąc o technologiach.

Jednym z największych grzechów współczesnych mediów jest przedstawianie opinii w postaci faktów – nie chciałbym, żeby rozmowy o technologiach wyglądały tak samo. Chciałbym, żebyśmy w momencie mówienia o technologiach po pierwsze mieli z tyłu głowy świadomość własnej niewiedzy i ograniczonego punktu widzenia, a po drugie zaznaczali jak ważny jest kontekst. Dobrze byłoby przedstawić własne doświadczenie, i… na tym pozostać. Nie przechodzić do przekonywania, sprzedawania, obiecywania jak łatwo i przyjemnie będzie decydując się na to samo.

Spróbujmy wyobrazić sobie sytuację w której tak obiektywnie jak tylko się da przestawiamy własne stanowisko w danej sprawie nie próbując natychmiast przekonywać innych do swojego punktu widzenia. Spróbujmy nie zapominać o tym, że praca osób z którymi akurat rozmawiamy może wyglądać zupełnie inaczej. Spróbujmy pamiętać o tym, że w naszym programistycznym świecie ten sam problem można rozwiązać na kilkanaście sposobów i każdy może na swój sposób najlepszy.

Najlepsze rozwiązanie pojawi się wtedy, kiedy wypracujemy go po wspólnej dyskusji w której zmierzą się różne spojrzenia i doświadczenia. Wtedy kwestia tego “kto miał rację” będzie mieć drugorzędne znaczenie, a my będziemy bogatsi o inne spojrzenia oraz pewność tego, że decydujemy się na dany krok ŚWIADOMIE – czego sobie i wam życzę 😉

Powiązane

Jak nauczyć się angielskiego? Praktyczne porady.  Angielski, czyli język, który powinien znać każdy programista. W rzeczywistości bywa z nim różnie. Jedni posługują się nim biegle, inni wcale. Sa...
Programista na rynku pracy – wymagane kwalif... Jakie są wymagane kwalifikacje, kompetencje i umiejętności od programistów na rynku pracy? Jakiś czas temu wspominaliśmy o inicjatywie STARTER, któ...
Aplikacje mobilne – jak zacząć Zaczynając naukę programowania stoi przed Tobą wiele wyborów. Ten, który najbardziej wszystkich trapi to wybór języka programowania. Decyzja ta jest m...
Jestem humanistą, czy mogę zostać programistą? Kto to jest humanista? W dawnych czasach humanistami nazywano ludzi o szerokim spojrzeniu na świat, gotowych dyskutować na przeróżne tematy, interesuj...