Oderwanie od rzeczywistości, romantyczny kod i dramat programisty.

O

Tym razem chciałbym poruszyć temat dbałości o jakość kodu, nadmiernej dbałości. Myślę, że nie raz spotkaliście się z tym zjawiskiem lub sami byliście jego przyczyną (ja niestety byłem). Nie oszukujmy się, my programiści, czerpiemy przyjemność z pisania kodu, tworzenia czegoś z niczego i dopieszczania swoich rozwiazań do granic możliwości. Do tego okazujemy się super „zdolniachami” kiedy przychodzi do argumentacji dlaczego praca trwa dłużej niż powinna, a może bardziej usprawiedliwień. Prawda?
Bo przecież to rozwiązanie jest…

  • …piękne!
  • …najbardziej czytelne z czytelnych!
  • …gotowe na wszystko! (chyba był taki serial)
  • …odporne na widzimisie klienta!
  • …realizacją funkcjonalności o której klient jeszcze nie pomyślał, ale już jesteśmy na to gotowi!

No właśnie. Skąd to się bierze? Gdzie leży przyczyna?

 

Oderwanie od rzeczywistości

Pozwolę sobie, na łamach tego postu, ukuć tezę, że przyczyna leży w oderwaniu programisty od produktu i klienta, a także braku komunikacji z ludźmi. Już tłumaczę co autor (to chyba będę ja) ma na myśli.

Wyobraźcie sobie, że jesteście artystami. Malarzami. Tworzycie obrazy na zamówienie. Tak jak programista, tworzycie „coś z niczego”, a kiedy Wasze dzieło jest skończone, nadchodzi czas prezentacji przed klientem. I jak to wygląda? Otóż stoicie wraz z klentem przed obrazem i go kontemplujecie. Reakcje klenta mogą być różne, ale JAKIEŚ SĄ! Widzicie czy ktoś jest zadowolony z efektu pracy, czy nie. Widzicie emocje na twarzy. Mimikę, mowę ciała tej osoby, słyszycie intonację głosu. W prosty, naturalny dla Waszego mózgu sposób, dostajecie ogromny ładunek informacji nt. Waszej pracy i jej efektów.

Jak analogiczna sytuacja wygląda w przypadku programisty?

 

I tu jest pies pogrzebany

 

Tak naprawdę niewielu z nas ma okazję widzieć reakcję klienta, kiedy ten widzi naszą pracę po raz pierwszy. Nawet jeśli ktoś już ma kontakt z klientem bezpośrednio, to często obywa się on po czasie, kiedy emocje opadły i następuje „sucha” wymiana zdań i poglądów. Jeśli już ktoś ma okazję zobaczyć reakcję klienta na nasze „dzieło” to i tak jest to branża, gdzie stopień zadowolenia z efektu pracy zmienia sie w czasie, w miarę używania danego rozwiązania.

Tyle się teraz mówi o zmianie na rynku i o tym, że teraz nie kreuje się produktu i potrzeby. Teraz powinno się słuchać klenta, słuchać odbiorcy i pytać go czego pragnie i jak rozwiązać jego problem. To ja się pytam. Jak mam to robić jeśli na oczy go nie widziałem, a jedyne co wiem to informacje przekazane mi przez głuchy telefon, poprzez poszczególne stopnie drabinki kadry zarządzającej?

 

Dramat programisty

Utarło się, że programista to osoba mocno techniczna, nie tylko jeśli chodzi o zakres umiejętności, ale również w aspekcie charakteru, predyspozycji. Trend ten się na szczęście zmienia i coraz mniej ważne są umiejętności techniczne, a coraz bardziej te miękkie (tak, nielubiane słowo 😉 ). Niestety w większości przypadków jesteśmy traktowani jak osoby z którymi nie da się porozumieć, a przynajmniej nie ludzkim językiem. Oczywiście dużo w tym też naszej winy. Jendnakże w wielu firmach sytuacja wygląda tak, że programista to jest ten który realizuje czyjąś wizję. On służy tylko do przelania jakiejś ideii do repozytorium w postaci kodu.

Odbywa się to ze stratą, zarówno dla programisty – z przyczyn oczywistych – jak i dla firmy dla której pracuje. Przecież „używając” programisty do pisania kodu tylko i wyłącznie, korzysta się tylko z „połowy człowieka”. Ta druga połowa, zdolna do komunikacji pomysłów, do wyrażania swojego zdania, często bardzo trafnego w kontekście produktu, nie jest wykorzystana. I właśnie ta druga połowa człowieka objawia się w sposób najbardziej naturalny. Przelewamy swoje pomysły i przewidywania do repozytorium. Tak, tak właśnie!

 

Niech pierwszy podniesie kamień ten, który nie napisał kodu „na przyszłość”.

 

Jaki to ma wpływ na pisanie kodu, upiększanie go ponad rozsądną miarę i ogólnie z pojęciem overengineering? Moim skromnym zdaniem ma całkiem spory.

 

Romantyczny kod

Jak każda osoba pracująca, chcemy być zadowoleni z efektów swojej pracy. Osiągamy ten stan na różne sposoby, widząc zadowolenie szefa, jeśli nie szefa to klienta, jeśli nie klienta i nie szefa to… no właśnie, szukamy radości z pracy gdzieś indziej. Nasza twórczość nie kończy się na czytelnym i łatwo-zarządzalnym kodzie. Zaczynamy realizować własne miniambicje poprzez kod. Pomijam sytuacje kiedy chemy wypróbować nowe rozwiązalnie, framework, czy inny nowy magiczny sposób programowania. Mam na myśli sytuację, kiedy mając już gotowe rozwiązanie, spełniające wymagania, posiadające najważniejsze cechy dobrego kodu (Tak, wiem. Różne dla każdego z nas), silimy się na przekraczanie granic, oczekiwań co do rezultatu. Tworzymy prawdziwie romantyczny kod i nie chodzi mi tu o code poetry.

Czy naprwdę, przy implementacji przycisku i zapisu w bazie, potrzeba tworzyć siedem warstw aplikacji i używać każdego możliwego wzorca, tylko dlatego, że WYDAJE NAM SIĘ, że dzięki temu produkt będzie lepszy? Oczywiście przesadzam, ale rozumiecie o co mi chodzi, prawda?

Uważam, że gdyby zwykły szeregowy programista posiadał wiedzę nt. potrzeb klienta, nt. jego wizji – oczywiście, że nie wszystkich, tylko konkretnie w kontekście który akurat „jest na tapecie” – pracowałby bardziej powściągliwie. Tworzyłby mechanizm rozwiązujący problem lub realizujący jakąś funkcjonalność, wedle potrzeb.

 

Apel

Jeśli pomyślałeś/pomyślałaś coś w rodzaju – „Tak! To ja robię wszystko w tej firmie! Gdyby nie ja to reszta nie miała by co robić! Ci ślepcy tego nie widzą!” – to przykro mi, ale nie ma dla Ciebie ratunku.

 

Celebryci – to w telewizji…

 

Natomiast jeśli Twoja myśl to coś w rodzaju – „No tak, faktycznie. Czasem przesadzam, ale to dlatego, że chcę dobrze!” – jest dla Ciebie nadzieja. Droga będzie długa i kręta, ale opłacalna. To od nas, tak naprawdę, zależy jak będziemy postrzegani „na zewnątrz”, czy reszta świata będzie się z nami komunikować, i będzie zabiegać o naszą opinię. To od nas zależy czy staniemy się cenną wartością dodaną w firmie, czy zwykłymi wyrobnikami których zdanie się nie liczy.

Dlatego, jeśli jeszcze tego nie zrobiłeś/zrobiłaś, wyjdź poza monitor, wyraź swoje zdanie, nie bój się, komunikuj. Jeśli trzeba, szkol się w tym zakresie. Pokaż że tobie również zależy, że nie jesteś tylko od klepania po klawiaturze. Pamiętajcie, że Wasz warsztat to nie tylko języki programowania, frameworki i narzędzia. Pokuszę się o stwierdzenie że Wasz warsztat to Wy.

 

Bądź artystą w swoim fachu! Niech Cię usłyszą!

 

Bądź tym programistą w firmie, do którego przychodzą rozwiązać problem, a nie po to by podrzucić task czy bug.

 

 

Napiszcie czy się zgadzacie.

Napiszcie czy macie jakieś inne spostrzeżenia w tej kwestii.

Czołem!

 



About the author

6 komentarzy

  • Hej.
    Zgadzam się z tym co napisałeś. Według mnie obecnie programiści są za bardzo oderwani od klienta i jest to duży problem. Z drugiej strony, widziałem również takich purystów kodu, którzy mogliby ten przysłowiowy button pisać tydzień, bo znaleźli coś, co jest minimalnie lepsze i trzeba teraz już przepisać całą aplikację. We wszystkim należy mieć umiar.
    Bardzo dobry artykuł, będę tutaj wpadał częściej 🙂

    • Cześć. Dzięki! To takie moje luźne przemyślenia w tym temacie. To dobrze, że ktoś, choć po części, się ze mną zgadza. To oznacza, że nie wyssałem tego z palca i mi się nie ubzdurało :-).

      Co do tych purystów kodu – lubią się nazywać perfekcjonistami, choć i tacy też są.

  • Aktualnie pracuję jako programista, rozwijając oprogramowanie dla firmy, dla której pracuję.
    W mojej firmie jest świadomość, że pracujemy po to, żeby automatyzować procesy w firmie, porządkować je i robić to dla użytkowników, którzy korzystają z systemu. Jesteśmy dość blisko tzw. biznesu. Mamy szereg spotkań, gdzie dyskutujemy pomysły i propozycje rozwiązań. Czasem przychodzi produkt owner z jakimś pomysłem i ja jako developer mówię, że ten sam efekt można osiągnąć używając gotowej funkcjonalności i tylko odpowiednio konfigurując, tym samym oszczędzając czas i pieniądze, znajomość systemu jest istotna.
    Generalnie takie podejście jest naprawdę fajne, bo to co robimy, robimy dla kogoś i ma to realną wartość dla firmy.

    Ma to też swoje minusy, dużo spotkań, czasem presja na szybką realizację kluczowej w danej chwili zmiany. Dlatego to też trzeba odpowiednio wyważyć.

    Oczywiście w firmie nie każdy programista ma takie podejście jak ja, są tacy co by chcieli tylko programować, a czego dotyczy funkcjonalność czy czego chcą odbiorcy, ich nie obchodzi (mówią to wprost). I generalnie widzę, że tacy programiści nieraz są mocni technicznie i tworzą dobry kod, ale często coś temu rozwiązaniu brakuje, przez to, że programiści są oderwani od rzeczywistości a rzeczywistość jest inna od idealnych rozwiązań (użytkownicy inaczej korzystają z funkcjonalności niż my zakładamy, dane w bazie są niekompletne itp). Rozwiązania powinny być projektowane z myślą o potrzebach i realiach w jakich działa system.

    Niemniej rynek nie ceni, na stanowisku developera, umiejętności szybkiego merytorycznego ogarniania systemu, analizy tego co się robi czy ma to sens i nie wpływa na n innych rzeczy itp. Są to wartości niepoliczalne. Stąd też nie dziwię się, że co mądrzejsi myślą o sobie i swoim rozwoju umiejętności technicznych zamiast o tym, by to co robią miało sens.

    • Przyznam, że trochę Ci zazdroszczę miejsca pracy :). Wszystko zależy od dojrzałości/dorosłości firmy (nie mówię o „wieku”). Co do ostatniego akapitu, uważam, że najbliższe lata zweryfikują to podejście. Na zachodzie widać trend odwrotny, rozwój AI, BigData, Cloud Computing’u sprawia, że najcenniejsi są ci którzy rozumieją dziedzinę (domenę). Programowania można się nauczyć raz-dwa. Dodatkowym argumentem za odwrotem tego trendu, jest wdrażanie przez organizacje modelu Turkusowego (tu odsyłam do podcastu Krzyśka Kempińskiego – https://porozmawiajmyoit.pl/poit-025-organizacje-turkusowe-i-self-management/)

  • Myślę, że ten tekst to tak naprawdę prztyczek w nos i „wake-up call” dla obu stron: dev teamu i tzw. biznesu.
    Tylko właśnie, czy to są dwie strony, czy przypadkiem nie powinien to być jeden wspólny front? 🙂

    Rozpisywali się na ten temat ludzie dużo mądrzejsi ode mnie, rozpoznawani w branży, nowość to to nie jest, ale jak widać temat wiecznie żywy 🙂 Z jednej strony Spolsky i jego koncepcja warstwy abstrakcji między programistami a klientami, a z drugiej Cagan, który twierdzi, że dev powinien być jak najbliżej użytkownika, a „wykorzystywanie” programistów tylko do kodowania to korzystanie z zaledwie połowy ich potencjału, bo jako eksperci od danego systemu, aplikacji, potrafią dać duży wkład w kierunek ich rozwoju. Co jest też moim osobistym przekonaniem 🙂

    Wydawać by się mogło, że w dobie agile’a i leana w każdym domu i zagrodzie, hype’u na Management 3.0 i „turkusowość”, to już są dylematy, które powinniśmy mieć dawno za sobą, ale posty i komentarze takie jak powyżej pokazują tylko, jak młoda jest „kultura” IT w Polsce i jak wciąż mało zwraca się uwagę na odpowiedni mindset i umiejętności miękkie, takie jak praca zespołowa, nastawienie na rozwiązywanie problemów, empatyzowanie z użytkownikiem itp. Wciąż jest deficyt programistów na rynku, więc patrzy się głównie na skille techniczne. Podczas gdy na świecie standardem staje się bazowanie na tzw. culture fit, bo firmy zdają sobie sprawę, że sposób myślenia trudniej zmienić, niż doszkolić kogoś technicznie.

    Jeśli chodzi „stronę” dev teamu, to dość jasne jest, że kod jako taki nie stanowi wartości dla użytkownika (poza baaaardzo specyficznymi przykładami, gdy to kod sam w sobie jest produktem), a produkt nie jest zbiorem ficzerów tylko rozwiązań problemów odpowiadających na potrzeby, braki i bolączki (i ew. zachcianki ;)) prawdziwych osób. Piękny kod, który nie będzie używany, nie jest nikomu potrzebny. Perfekcjonizm przydaje się w zespole – dobrze mieć taką perspektywę na podorędziu – ale nie odklejenie od rzeczywistości, czy to z własnego wyboru czy takie, na które jest się skazanym. Patrząc w ten sposób, product manager/owner, który uważa się za alfę i omegę i nie korzysta z wiedzy swojego zespołu tylko zleca im robotę, jest równie odklejony od rzeczywistości, co taki programista-Mickiewicz. To jest recepta na produkt mijający się z rzeczywistością, wiele rozczarowań i szukania winnych. To jest coś, co sensowny zespół powinien zdiagnozować sam u siebie zawczasu, jeśli ma choć odrobinę motywacji (to jest zupełnie inna dyskusja) – dev team powinien wyraźnie sygnalizować, że jeśli jest odcinany od informacji, to pisze coś dla wszystkich i dla nikogo, że robi dużo zbędnych założeń, że estymaty są na granicy sensowności (guesstimates :)) – jest po prostu nieefektywny. Product manager/owner powinien wciąż walidować swoje założenia dot. problemów, jakie produkt ma rozwiązywać (bo tak – to są niemal zawsze założenia, prawdy absolutnej nikt nie posiadł, trzeba empirycznie do tego podejść :)) i pozwolić dev teamowi proponować rozwiązania, a nie siedzieć jak w manufakturze i implementować ficzery od sztancy.

    Ficzer factory i projektoza, to wciąż żywe choroby software house’ów, nawet tych co chwalą się, jak bardzo są zwinne. Ale już za dużo gadam, mogę to pociągnąć w osobnym komentarzu 🙂

    Fajny post, daje do myślenia. Miło się czytało. Sukcesów w nowym roku!

    • Powiem tak, czytałem kilka razy aby zrozumieć i przyjąć Twój punkt widzenia. Widać, że rownież masz sprawę przemyślaną, ale co najważniejsze doświadczenie w tej kwestii. Tak się teraz zastanawiam… wychodzi na to, że TO jest po prostu trudne.
      To jest trudne rekrutować odpowiednich ludzi, biorąc pod uwagę nie tylko technical skill.
      To jest trudne wymagać od innych szerszej perspektywy, lub chęci ogarnięcia tej szerszej perspektywy, spojrzenia dalej niż czubek nosa. Zwłaszcza, że nie każdy chce.
      To wymaga czasu i cierpliwości, a efekty będą po latach. Niestety nie każdy widzi w tym wartość. Również jakość pracy, czy produktu nie u każdego stoi na podium.
      Jakby nie było, firmy ze sobą konkurują, niektóre jakością, inne ceną, jeszcze inne tempem dostarczania zmian. Wszystko ma swój koszt.
      Fajnie, że napisałaś. Zmuszasz do refleksji :-). Zaglądaj częściej!

By Patryk

Autor serwisu

Patryk

Społecznościowe

Instagram

Newsletter



Historycznie

Tagi