Slow coding

22 z minutami, dzieci śpią, wykończone świątecznymi przygotowaniami (babcia z dziadkiem chyba też). Na słuchawkach High On Fire i Snakes for the Divine (Matt Pike i diabelnie seksowne staccato na początek). Przeglądam pokonferencyjne blogi, męczony przeczuciem, że powinienem zrobić coś konstruktywnego. Nic jednak z tego dziś nie będzie, mam powyżej uszu czytania specyfikacji ECMAScript i zaczynam się zastanawiać po co w pocie czoła co chwilę wywołuje hg push http://bitbucket.org/kcrimson/newjs. Być może sprawia mi to przyjemność. Z natury jestem hedonistą gdyż lubię rzeczy które mi sprawiają przyjemność, a nic nie daje takiego kopa endorfin jak strumień świadomości przelewany w kolejne pliki tekstowe (no jest jeszcze jedna rzecz ale Ci którzy mnie znają nie muszą się domyślać).

I dziś będzie o strumieniu świadomości, rosnącej z wiekiem niechęci do ludzi i ogolnie pojętej higienie pracy.

1999, ubiegłe stulecie, z której strony by na to nie patrzeć. Pierwsza poważna praca jako programista, Java + XSLT. Nie do końca wiedziałem co system miał robić. Nie do końca też wiedziałem jak robić żeby się nie narobić a zarobić. Wypluwałem w XEmacs’ie potoki krwią zbrukanych <xslt:template>, przeładowywałem aplikację, przeklikiwałem się przez sraczkoburaczkowe HTML’e i sprawdzałem czy odpowiednia cyfra pojawiała się w odpowiedniej kolumnie, zgodnie z życzeniem klienta. O TDD nikt wtedy w biurowcu nie słyszał, nie mówiąc też o takich hokus-pokus jak SOLID, DDD, BDD czy też inne xDD. Przynajmniej wśród towarzyszy niedoli zza biurka. Robota była czarna, mrówcza i żmudna. Java cholernie wolna, pojęcie refaktoringu z XEmacsem było równie obce jak moja znajomość podstaw programowania obiektowego w tym czasie. Projekty byłe prowadzone tak “zwinną” metodologią, że obecnie Agile i Lean przyprawiają mnie o regularny ROTFL i spazmatyczne napady histerycznego chichotu. O 9.00 czasu środkowoeuropejskiego nasz szef zespołu mówił co klient na teraz potrzebuje, kilka, czasami kilkanaście godzin później klient przeglądał wyniki i w 99% przypadków zmieniał wymagania. To się chyba nazywa “responding to change”, kilka osób zrobiło z tego manifest i zarobiło na ksiązkach, a myśmy to na własnej skórze odczuli. Kasa z zaskakującą nieregularnością spływała na konto. Co do tzw. benefitów to jedyne co pamiętam do grupowe upijanie się do nieprzytomności. Zapomnijcie o biletach do kina, wejściówkach na baseny i zniżkach do domów publicznych (czego to teraz pracodawcy nie wymyślą). Systemy po pierwszym tygodniu były na ostatniej prostej do “big ball of mud”, projekty niedoestymowane jak nasz krajowy budżet, a zadowolenie klienta wprost proporcjonalne do wartości metryki WTFPM (dla niewtajemniczonych “what the fuck per minute”).

2011, kilka zmian pracy za mną, następna w trakcie. Na skórze wypalone rany z poprzednich bojów, w duszy gra TDD. Nabrałem szacunku dla wzorców “gangu czterech” (choć dalej uważam je za grant bez zawleczki w rękach pijanego). Po moim IDE poruszam się z gracją skrótów klawiszowych, dzielę się z kolegami kodem w ciągu dnia częściej niż chodzę na papierosa. Z wypiekami na twarzy oglądam zielone paski postępu w Eclipse po przywołaniu zaklęcia Shift+Alt+X T.Już nie czekam nerwowo na Matki Boskiej Pieniężnej. Benefitów ogrom, że nie ma czasu kiedy z nich skorzystać. A systemy już nie przypominają “big ball of mud” lecz coraz częściej mają architekturę tzw “czarnej dziury”. Każda wprowadzona zmiana, jak czarna dziura wsysa w swą otchłań młodych dzielnych programistów, pieniądze inwestorów i zdrowie szefów projektów. Estymaty projektów przy zastosowaniu zasady 200% buforu bezpieczeństwa nadal rozpadają się jak zamki z piasku. Jak to kolega ujął próbując zamknąć definicję Agile w jednym zdaniu “klient nadal nie wie co chce, a my dostarczymy co mamy”. Mamy wysyp manifestów, metodyk, renesans języków dynamicznych i funkcyjnych. A bajzel taki sam jak dawniej tylko, że za większą kasę i pod sztandarem “enterprise architecture”, walki o większą świadomość branżową (całym sercem jestem z tzw. “software craftmanship” ale moim zdaniem już zboczyliśmy na manowce, gdzie bije się pianę i leje wodę) oraz wyrównaniu płac tych z Wschodu z przychodami tych z Zachodu. I jak na złość, być może stoimy przed kolejną eksplozją bańki inwestycyjnej, patrz na ostatnie wyceny Facebook’a i innych graczy branży spod znaku “social network”, na których buduje się “social marketing” a na nich powstają “social fortunes”.

Nic się nie nauczyliśmy, zmienialiśmy i zmieniamy metodyki i techniki jak modelki ciuszki na wybiegu. Efekt zawsze jest taki sam, żałosny.

Postawiliśmy znak równości miedzy “wiem” a “potrafię”. W CV wpisujemy Python po napisaniu hello world, albo gdy raz widzieliśmy żywego człowieka piszącego w tym języku. Jesteśmy jak Neo podpięty do Matrix’a. Po wyciągnięciu wtyczki z dumą możemy powiedzieć “I know kung-fu”. Przestało się liczyć doświadczenie, liczy się ilość blogów i artykułów pochłoniętych. Częściej czytamy cudze blogi, niż cudzy kod. Kodujemy w krótkich zrywach, przerywanych długimi spotkaniami. Nie eksperymentujemy, oczekujemy gotowych rozwiązań, które rozwiązują wszystkie znane i jeszcze nieznane problemy.Żałośnie podrygując przed klawiaturą z dumą nazywamy się programistami bo i tak nikt nie rozumie tego co robimy. Żywimy się w “fast food’ach” uprawiając na co dzień “fast coding”. Zapalamy się słysząc “closures” by tydzień później ślinić się nad “monadami” i “curry”. Ogłaszamy koniec programowania obiektowego, wieszcząc erę programowania funkcyjnego. Z radością przyjmując pojedyncze wieści ze świata o pojedynczych przypadkach sukcesów takich systemów. Nadal jednak nie potrafimy napisać porządnego kodu w językach obiektowych. Obiecujemy sobie, że będzie lepiej gdy użyjemy języka dynamicznego w miejsce statycznego. Bez świadomości konsekwencji i potrzeby jeszcze większej autodyscypliny w przypadku tych pierwszych, co nie jest tak proste i przyjemne jak autoerotyzm.

I tutaj dochodzimy do kwestii higieny, higieny naszych synaps. Coś co na własną potrzebę określam “slow coding”. Kultury i higieny informacji. Zacznijmy oszczędniej kodować, bez nadmiernego pospiechu delektujmy się kolejnymi technikami, eksperymentując dowoli w małych grupach, z przyjaciółmi dzieląc się kodem na github czy bitbucket, podglądajmy innych przy pracy. Naśladujmy ich, a jeśli dla nas nie zadziała nie przejmujmy się. Wyrzućmy to co się nauczyliśmy i spróbujmy jeszcze raz. Ja wiem, że to mrzonka ale mam to szczęście, że moje doświadczenie bazuje głównie na podpatrywaniu innych, wyrzucaniu tysięcy linijek śmieciowego kodu, pracy w małych grupach nad jednodniowymi “projektami”, czasami eksperymentami które trwały trwały od porannej kawy do obiadu i kończyły jako rm -rf. To nie podręczniki, teorie i godziny szkoleń przywiodły mnie do tego punktu rozwoju jako programista. To wspólne kodowanie, często podlane kompletnym brakiem sentymentu wyrzucanie kodu i małpowanie lepszych, starszych kolegów po fachu.

I tym sposobem przy rozdzierających głowę dźwiękach “Love Like Blood” Killing Joke doszliśmy do końca tego cynicznie-ironicznego wpisu. Trzymajcie się, i niech wam “wiśnia” w głowach lekką będzie.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: