Newsletter z dnia 2019-03-26

RADOŚĆ Z RZEMIOSŁA

Dlaczego programowanie jest przyjemne? Jakiej nagrody może się spodziewać programista za swoje wysiłki?

Po pierwsze, chodzi o prostą radość z tworzenia. Tak jak dziecko cieszy się z prac w piaskownicy, tak dorosły czerpie przyjemność z tworzenia różnych rzeczy, szczególnie gdy samodzielnie je projektuje. Sądzę, że ta radość musi być odbiciem boskiej radości tworzenia. Radości widocznej w unikalności i niepowtarzalności każdego liścia i płatka śniegu.

Po drugie, mamy radość z tworzenia rzeczy, które będą przydatne dla innych. Wszyscy chcemy, żeby inni ludzie używali wytworów naszej pracy i żeby uznali je za przydatne. W tym zakresie system programistyczny nie różni się za bardzo od przygotowanego przez dziecko glinianego kubeczka na długopisy „dla tatusia do biura”.

Po trzecie, mamy też fascynację związaną ze składaniem skomplikowanych obiektów wykorzystujących współpracujące ze sobą mechanizmy i przyglądaniem się ich pracy w poszczególnych cyklach lub sprawdzaniem konsekwencji wszystkich zasad, które zostały wbudowane od samego początku. Zaprogramowany komputer fascynuje w ten sam sposób jak ekstremalnie skomplikowana maszyna do flipperów albo mechanizm szafy grającej.

Po czwarte, chodzi o radość z uczenia się, która wywodzi się z braku powtarzalności w wykonywanych zadaniach. W ten lub inny sposób każdy problem jest nowy, a rozwiązująca go osoba uczy się czegoś nowego. Czasami czegoś praktycznego, czasami teoretycznego, a czasami i praktycznego, i teoretycznego.

W końcu mamy też radość z pracy z tak nieuchwytnym medium. Programista, podobnie jak poeta, tylko w niewielkim stopniu musi odrywać się od prac czysto umysłowych. Tworzy swoje zamki w powietrzu, budując je z powietrza i do granic możliwości wykorzystując przy tym swoją wyobraźnię. Niewiele jest mediów pozwalających na uzyskanie takiej elastyczności, tak łatwo poddających się polerowaniu i przebudowie, posiadających możliwość tworzenia wielkich struktur konceptualnych. (Jak się później przekonamy, tak wielka elastyczność tworzy własną kategorię problemów).

Mimo to powstały program, w przeciwieństwie do słów poety, jest rzeczywisty, ponieważ działa i wykonuje swoją pracę, generując na wyjściu coś, co jest niezależne od niego samego. Drukuje wyniki obliczeń, rysuje obrazy, generuje dźwięki, porusza ramionami. Magia z mitów i legend w naszych czasach stała się rzeczywistością. Wystarczy wpisać na klawiaturze odpowiednie zaklęcie, a obudzony ekran zaprezentuje nam rzeczy, których nigdy nie było i których właściwie nie powinno być.

To wszystko oznacza, że programowanie sprawia radość, ponieważ nagradza naszą wewnętrzną kreatywność oraz łechce te cechy, które są wspólne dla całej ludzkości.

SMUTKI Z RZEMIOSŁA

Niestety nie wszystko przynosi same radości, a świadomość istnienia pewnych niedogodności pozwala łatwiej je znieść, gdy dają się nam we znaki.

Przede wszystkim musimy działać perfekcyjnie. Pod tym względem komputer przypomina legendarną magię. Jeżeli choć jeden znak, jedna pauza w tworzonej inkantacji będzie odbiegać od założeń, to całe zaklęcie nie zadziała. Ludzie nie są niestety przyzwyczajeni do zachowywania takiej perfekcji, ponieważ niewiele rodzajów ich aktywności tego wymaga. Wydaje mi się, że dostosowanie się do wymogu zachowania perfekcji jest najtrudniejszym elementem nauki programowania.

Poza tym to ktoś inny ustala nasze cele, udostępnia nam zasoby i dostarcza wszystkie informacje. Tylko rzadko możemy mieć wpływ na okoliczności wykonywanej pracy, a nawet na jej cele. Stosując nomenklaturę kadr zarządzających: posiadana władza nie jest równoznaczna z odpowiedzialnością. Wydaje mi się, że w niemal wszystkich dziedzinach, w których praca oznacza realizowanie pewnych zadań, formalna władza nie jest powiązana z odpowiedzialnością. W praktyce rzeczywista (a nie formalna) władza wywodzi się z samego rozpędu realizacji.

Zależność od innych jest szczególnym przypadkiem, który bywa niezwykle nieprzyjemny dla programisty systemowego, gdyż uzależnia go od programów pochodzących od innych osób. Takie programy są często nieprawidłowo zbudowane, źle zaimplementowane, dostarczone w niepełnej postaci (brakujący kod źródłowy lub przypadki testowe) i fatalnie udokumentowane. Zmusza to programistę do poświęcania całych godzin na nauczenie się działania programu lub poprawianie błędów w elementach, które w idealnym świecie byłyby kompletne, dostępne i użyteczne.

Następnym problemem jest to, że projektowanie wielkich koncepcji sprawia wielką radość, ale już wyszukiwanie drobnych błędów jest najzwyklejszą pracą. Z każdym kreatywnym działaniem powiązane są długie godziny żmudnej i trudnej pracy. Programowanie nie stanowi tutaj żadnego wyjątku.

Dodatkowo okazuje się, że debugowanie ma liniową zależność czasową albo i gorszą. Można oczekiwać, że pod koniec krzywa będzie zbliżała się do krzywej kwadratowej. Oznacza to, że testowanie coraz bardziej się przeciąga, a ostatnie kłopotliwe błędy zajmują znacznie więcej czasu niż pierwsze.

Ostatnim problemem, a czasami problemem ostatecznym, jest fakt, że produkt, nad którym tak długo pracowaliśmy, po jego ukończeniu (a czasem i przed końcem prac) okazuje się zupełnie przestarzały. W tym czasie koledzy i konkurencja zajmują się realizacją znacznie nowocześniejszych idei. Pogrzeb własnego „dziecka” jest już nie tylko rozważany, ale ściśle zaplanowany.

To wszystko zawsze wydaje się gorsze, niż jest w rzeczywistości. Ten nowy i lepszy produkt nie został jeszcze udostępniony w momencie ukończenia własnego produktu. Zazwyczaj jedynie się o nim wspomina. On również będzie wymagał całych miesięcy wytężonych prac. Rzeczywisty tygrys nigdy nie dorównuje temu papierowemu, chyba że naprawdę chcemy go wykorzystać, a wtedy satysfakcję można czerpać z istniejącego stanu rzeczy.

Oczywiście baza technologiczna, na której tworzymy nasze programy, jest cały czas rozwijana. Gdy tylko dokonamy zamrożenia projektu, stanie się on przestarzały pod względem użytych w nim koncepcji. Implementowanie rzeczywistego produktu wymaga jednak zastosowania faz i kwantyfikatorów. Określenie poziomu zacofania implementacji możliwe jest jedynie w porównaniu do innych implementacji, ale nie w porównaniu do niezrealizowanych koncepcji. Stojące przed nami wyzwania i misja polegają na znalezieniu rzeczywistych rozwiązań istniejących problemów, z wykorzystaniem odpowiednich harmonogramów i dostępnych zasobów.

To właśnie jest programowanie. Przypomina ono zarówno smolisty dół, w którym zatonęło już wiele projektów, ale stanowi też bardzo kreatywne działanie, z którym wiążą się różne radości i smutki. Dla wielu suma wszystkich radości ma większe znaczenie niż wszystkie smutki.

---

"/" src="http://helion.pl/okladki/legoso.jpg" style="float:left; margin-right: 25px;" border="0">

Ten fragment pochodzi z książki Legendarny osobomiesiąc. Opowieści o inżynierii oprogramowania. Wydanie II". Zdobądź swój egzemplarz! Kup książkę lub eBook z 30% rabatu z kuponem LEGENDARNY (kod ważny do 31.03. włącznie, obniżka liczona jest od ceny detalicznej, rabaty nie łączą się).