mmazur.7thguard.net

Przez te kilka lat, które byłem w PLD, raz na jakiś czas zdarzało się, że niektórzy deweloperzy znikali praktycznie z dnia na dzień. Taki Paweł Gołaszewski (aka blues) był swego czasu bardzo aktywny (czasami aż nazbyt, raz za jednym zamachem udało mu się wykasować z repozytorium CVS całe pld 1.0 :), aż pewnego dnia po prostu oznajmił, że przestał mieć czas. I rzeczywiście przestał. Poziom jego aktywności, jeszcze wczoraj całkiem wysoki, następnego dnia spadł do zera.

Wtedy niespecjalnie mieściło mi się to w głowie -- jak to tak można po prostu coś rzucić z dnia na dzień? Jeśli coś lubię robić (tu -- dłubanie w PLD), to tak sobie ustawiam życie, żeby mieć jakieś sensowne ilości czasu na owo coś.

Niestety kilka miesięcy temu przyszło mi zrozumieć o co chodzi. Studia dzienne, praca oraz znacznie większa ilość czasu poświęcana na inne dziedziny życia zaskutkowały tym, że po raz pierwszy ja mam fizycznie mało czasu. Nie mało czasu jak zwykle, kiedy 90% dnia zawsze przeciekało mi przez palce, więc jeśli miałem jedną rzecz do zrobienia, to problemu nie było, bo w końcu się za nią brałem, natomiast w przypadku większej ilości zajęć -- przeważająca ich część zawsze szła w kąt.

O nie. Tym razem ja naprawdę nie mam czasu. Oczywiście, cyborgiem nie jestem, nadal poświęcam ileś tam godzin w tygodniu na ogólnie pojęte obijanie się (choćby oglądanie zaległych odcinków The Daily Show na youtube, czy też czytanie reddita), ale jest to niestety czas bardzo limitowany i albo muszę sobie o jakiejś sensownej porze przerywać (czego nadal się uczę), albo następnego dnia chodzę niewyspany, przez co nie jestem w stanie pracować. Skutek uboczny jest taki, że na zajęcia takie jak PLD, czy 7thguard, ja już po prostu nie mam najmniejszej ochoty.

I poniekąd jest to naturalne. Czytałem kiedyś, że jedną z kluczowych umiejętności przy rozwijaniu własnych zainteresowań jest umiejętność unikania zobowiązań. Pamiętacie moje nagłówki do kernela? One były fajne, gdy były nowe, gdy się uczyłem, gdy mi rósł geek factor ze względu na dłubanie w okolicach kernela. Ale w końcu stał się obowiązkiem. Obciążeniem. Nie chciałem już tego robić, nie chciało mi się, zmuszało mnie tylko to, że wiedziałem, że powinienem i chciałem sobie samemu udowodnić, że jestem się w stanie zmusić. Uwolnienie się od tego było długie i w pewnym sensie mocno problematyczne, acz z obiektywnego punktu widzenia dla mnie było czymś pozytywnym.

W rzeczywistości jest to związane z pewną moją mroczną tajemnicą -- otóż ja nie przepadam za technologią. Technologia mnie nudzi. Znam wiele osób, które technologia, mimo długiego z nią obcowania, nadal interesuje. Oni po prostu lubią dłubać. W pewnym sensie im tego zazdroszczę. Ba, to młode dziewczę jest naprawdę entuzjastycznie nastawione do tych nowych rzeczy, których może się jeszcze nauczyć. Ja tego nie mam już od dawna.

Jesteś programistą? Lubisz kodować? Za każdym razem jesteś w stanie wymyślić jeszcze lepszy sposób na zrobienie czegoś? Jesteś adminem? Na nowe kawałki oprogramowania patrzysz krytycznym okiem, zastanawiasz się jak można je wpasować w twoją istniejącą infrastrukturę, z której jesteś w pewnym sensie dumny? Lubisz, jak ci to co napisałeś/postawiłeś ładnie furkocze i działa?

A ja nie. Jak mam coś napisać/poprawić, to zastanawiam się, czemu ktoś tego nie zrobił już wcześniej za mnie, żebym mógł tylko odpalić i żeby działało. Jak mam uruchomić jakąś usługę, to klnę na czym świat stoi, bo to jest po prostu nty w moim życiu plik konfiguracyjny przez który się muszę przedrzeć, co mnie w żaden sposób nie podnieca.

Nie zrozumcie mnie źle. Mimo wszystko jestem geekiem i mam odpowiednio skonstruowany aparat mentalny, żeby nakręcić się sesją kodowania i nie nudzić się (zbytnio) w trakcie. Ba, będzie mi się to podobało i będę odczuwał satysfakcję, jeśli mój kod w końcu zacznie działać (analogicznie przy postawieniu jakiegoś serwera, czy innej usługi).

Rzecz w tym, że na wyższym poziomie abstrakcji te rzeczy mnie odrzucają. Odbieram je jako stratę czasu. Zazwyczaj muszę się zmuszać, żeby zacząć kodować, czy wykonać jakąś tam pracę administracyjną.

Niektórzy z was być może są w stanie skojarzyć mnie z jakimś konkretnym projektem technicznym, ale nawet jeśli, to zwróćcie uwagę na jedną rzecz -- właśnie czytacie moją prozę, a nie kod. I bynajmniej nie jest to przypadek.

Oczywiście nie mogę powiedzieć, że nie jestem osobą techniczną, bo obiektywnie rzecz biorąc moja wiedza i doświadczenie wcale takie małe nie są, ale prawda jest taka, że specjalistą to ja nie jestem od niczego. Znam Pythona? Znam, ale na poziomie podstawowym, z większą częścią tego języka nigdy nie miałem żadnej styczności. To może RPM? Niezbyt. Znam osoby dobrze w nim zorientowane i naprawdę do nich nie należę. Robiłem nagłówki do kernela, to może znam się na kernelu? Niet, obecnie bez kawałka dokumentacji miałbym zapewne problemy ze zwykłym zbudowaniem działającego kernela. I tak mógłbym wyliczać jeszcze długo.

Jest to bardzo problematyczne z zawodowego punktu widzenia, gdyż po pierwsze, znacznie ogranicza mi dostęp do prac z wyższej półki, tych dobrze płatnych, w firmach, które wiedzą jak traktować inżynierów i nie zatrudniają bezmózgich dronów na stanowiskach kierowniczych. Do takiego googla najprawdopodobniej nie miałbym nawet co startować, bo jestem za cienki w uszach.

Co gorsze jednak, w 99% tych firm ja tak naprawdę nie chciałbym pracować. Choćby nie wiem jak interesujące mogły się wydawać wewnętrzne projekty danej firmy dla przeciętnego informatyka, ja zawsze będę miał z tyłu głowy myśl, że nie ma się czym podniecać, to jest po prostu nieistotny kawałek kodu, o którym za rok nikt już nie będzie pamiętał.

Od tej reguły jest stosunkowo niewiele wyjątków, z których jeden, ten mimo wszystko najbardziej realistyczny, nazywa się PLD. Ze względu na dużą ilość zbiegów okoliczności, ten projekt nadal jest dla mnie atrakcyjny i chciałbym móc się nim zajmować.

Ale o tym dlaczego tak jest i co z tego wynika napiszę następnym razem...

W robocie mam taką sytuację, że klienci domagają się znacznie większej skalowalności, niż obecne oprogramowanie jest w stanie dostarczyć. Rozwiązanie -- przepisać, biorąc pod uwagę to, co już wiemy o różnych bottleneckach w obecnym kodzie. Ale cała operacja zajmie z dwa miesiące co najmniej, a w międzyczasie klient może nas olać. Na szczęście szef po prostu dorzucił kilka maszyn i powiedział, żeby władować tam maksymalną ilość danych, jakie się da. Powinno na te dwa miesiące wystarczyć.

Gdy przez ostatnie lata raz na jakiś czas przyglądałem się infrastrukturze innych dystrybucji, to zazwyczaj jedną z pierwszych reakcji było -- to oprogramowanie jest dla nas nieprzydatne, bo nie przewiduje rozproszonej i podatnej na błędy natury systemów, których używamy (a maszyny PLD są/były rozsiane w sumie po całym globie). Za każdym razem wtedy myślałem, że niezależnie od różnych gwizdków i wodotrysków, jakie mają w swoim sofcie inne dystrybucje, nasz soft jest jednak na tym najbardziej podstawowym poziomie lepszy, ponieważ jest dostosowany do tego, czym może dysponować grupa ludzi bez sporego konta w jakimś banku. Czyli taki typowy projekt open source.

I rzeczywiście, na pewnym poziomie nasze oprogramowanie jest lepsze właśnie, dlatego, że ma takie założenia, a nie inne. Problem polega na tym, że pisanie infrastruktury dla projektu to jest tak naprawdę strata czasu, ponieważ w idealnym świecie nikt nie musiałby pisać owej infrastruktury, a narzędzia potrzebne do optymalnego wykonywania właściwej roboty (czyli robienia dystrybucji, a nie pisania skryptów w pythonie) byłyby już dostępne. Patrząc na różne problemy z obecną infrastrukturą builderową, z których część wynika na przykład z używania zwykłej poczty do komunikacji między builderami (co choćby wymaga zainstalowanego demona pocztowego na wszystkich maszynach hostujących buildery, co nie zawsze jest takie proste do wykonania), przed oczami mam różne potencjalne rozwiązania. To przepisać tak, tamto siak, tutaj dodać parę skryptów na taką ewentualność, etc.

Tyle, że każda taka sesja kodowania, to jest czas, w którym można by zrobić coś innego, coś przydatnego z punktu widzenia użytkowników (którymi deweloperzy są także). W kontekście ostatnich kilku lat, gdybyśmy mieli własną dedykowaną serwerownię, to ilość godzin zaoszczędzonych na klepaniu się z różnymi brakami w funkcjonalności, błędami, czy też zwykłymi awariami pewnie szłaby w setki.

Oczywiście prawda jest taka, że nie mamy i mieć nie będziemy takowej serwerowni, więc skazani jesteśmy na rozwiązania software'owe. I w pewnym sensie jest to też zaleta, bo w końcu dorobimy się porządnej infrastruktury, co pozwoli nam w pewnym stopniu konkurować z dystrybucjami posiadającymi jakiś kapitał, pomimo tego, że sami owego kapitału nie posiadamy (a jeśli kiedyś się dorobimy, to będziemy go mogli wydać na coś ciekawszego z punktu widzenia użytkowników, niż infrastruktura).

(Co nie zmienia faktu, że jest wybitnie irytujące, że tracimy czas na klepanie się z takimi rzeczami, podczas gdy inne dystrybucje zajmują się rzeczywistą robotą.)

Zachciało mi się skórzanych butów do łażenia na co dzień (stare trekingowe się trzymają, bo są z kevlaru, ale gumowa podeszwa niedługo będzie totalnie płaska i w niektórych miejscach przedarta), więc zaszalałem, kupiłem pastę i ładnie wypastowałem. Cała operacja mi się spodobała, więc od razu wypastowałem też buty wyjściowe i kozaki na zimę. Teraz mam trzy pary butów nie-dotykać-bo-sobie-upieprzysz-łapy.

Gdzie można kupić jakiś zmywacz do pasty do butów? :/

Za każdym razem, gdy gdzieś tam pisali o problemach z dodaniem reiserfsa czwórki do jądra, oczywiste dla mnie było, że rację mają jądrowcy. Tak, Hans mógł sobie do woli gadać o tym, że jego filesystem non stop przechodzi miliardy zautomatyzowanych testów, ma super rozszerzalną i super zajebistą architekturę pluginową i wogle wogle cuda wianki, ale prawda jest i była taka, że z punktu widzenia kernelowców najważniejsza jest maintainowalność danego podsystemu. I nie chodzi tu o to, że autor się zaklina, że będzie maintainował, ale że w razie czego sami kernelowcy będą mogli tam jakieś mniejsze i większe poprawki wstawiać. To jest tzw. 'Linus got hit by a bus problem', czyli co robimy, jak maintainera przejedzie autobus.

Szczerze wątpię, żeby to się przyjęło, ale w sumie od teraz powinno się to nazywać "Linus got hit by a bus/Hans got jailed for killing his wife problem".

Poza tym mam nadzieję, że jeśli ktoś do tej pory nie rozumiał dlaczego Linus&friends byli tacy uparci przy mergowaniu reiserfsa4, to ten, fakt faktem mocno ekstremalny przypadek wystarczy za uzasadnienie. Gdyby ten filesystem został mergnięty dłuższy czas temu w stanie, w jakim był, to teraz kernelowcy mieliby na głowie potencjalnie martwy filesystem zawierający sporo różnych interfejsów (własne wbudowane pluginy), o których nikt nic nie wie. Afaik podobny problem jest już teraz z reiserem trójką, bo ilość osób znających się na rzeczy jest bardzo ograniczona, a sam autor stwierdził, że system jest w maintainance mode i żadnych większych zmian robił w nim nie będzie. A jądro się cały czas zmienia i czasami jednak trzeba...

Skoro się już i tak nie wyśpię, to jeszcze coś napiszę. Mianowicie małą uwagę odnośnie zakończonej niedawno Jesieni Linuksowej.

Jeśli jesteś na jakiejś tego typu imprezie i z jakiegoś powodu zaczynasz ze mną rozmawiać, to pamiętaj o jednej bardzo ważnej rzeczy -- nie wiem kim jesteś. Jest całkiem prawdopodobne, że sprawiam wrażenie, jakbym wiedział, z kim rozmawiam, ale sprawianie takiego wrażenia nie jest wcale trudne i jeśli chcesz mi zrobić kawał, to zejdź na tematy, w których fakt, że nie wiem, kim jesteś, wyszedłby od razu. Albo po prostu spytaj, czy wiem, kim jesteś. Jeśli w tym momencie spojrzę na twoją plakietkę z nickiem, to znaczy, że mnie złapałeś. (Możesz nawet zasugerować delikatnie w rozmowie, że jesteś kimś innym, niż jesteś, po czym sprawdzić, czy złapię haczyk.)

I nie, nie ma tu znaczenia, że już się kiedyś widzieliśmy, może nawet nie raz, gadaliśmy dłuższy czas, może nawet sporo razy na jabie/ircu. Jeśli rzeczywiście tak jest, to istnieje bardzo nikła szansa, że rzeczywiście cię rozpoznam na pierwszy rzut oka. A jeśli nie na pierwszy, to po chwili zastanawiania się skojarzę cię jakoś. Ale generalnie nie licz na to. Widywanie się, nawet wielokrotne, raz na rok przez kilka godzin, okraszone dodatkowo omówieniem raz na kilka miesięcy jakiejś sprawy na ircu w żadnej mierze nie wystarcza do tego, żebym cię zapamiętał. Na 90% mi się to nie uda.

Po raz niewiadomojużktóry przeczucia mojego szefa odnośnie źródła problemu okazały się słuszne, natomiast moje tłumaczenia na temat dlaczego system nie działa jak trzeba -- błędne. Obiektywnie rzecz biorąc faktem jest, że w końcu znalazłem oczywisty test case dla niedziałania i tak długo go drążyłem, aż doszedłem do tego co jest nie tak i najprawdopodobniej owo odkrycie okaże się przełomowe, ale i tak niezmiernie wkurwia mnie fakt, że ja wierzyłem, że moje wcześniejsze wytłumaczenie źródła problemu jest słuszne.

Jest to kolejny raz, gdy przejeżdżam się na obiektywności mojej oceny sytuacji. Miałem świadomość, że to nie jest system, którego jestem autorem i że już nie raz moje mniemanie o sposobie jego działania okazywało się błędne. Gdzieś z tyłu głowy kołatała mi się myśl, że ja tak naprawdę nie wiem jak ten system do końca działa i że tu powinienem szukać źródła problemu. Ale znowu z uporem maniaka wybierałem wytłumaczenie bardziej skomplikowane i właściwie rzecz biorąc logicznie nie trzymające się specjalnie kupy. Zaś gdy dokopywałem się do tekstów, które powinny mnie naprowadzić na właściwy tor, to zdecydowanie zbyt szybko uznawałem je za nieaktualne (bo napisane kilka lat temu).

Nie chodzi mi o sam fakt niewidzenia poprawnego rozwiązania problemu, bo to się zdarza każdemu, że można coś przeoczyć. Piję natomiast do tego, że po raz kolejny nie włączył mi się system ostrzegawczy odnośnie faktu, że operują na podstawie niepełnych danych. W takich przypadkach zawsze powinienem dążyć do uzupełnienia białych plam, zanim zacznę podejmować jakieś decyzje, albo wydawać opinie. No dobrze, może przesadzam, w pewnym stopniu ów system ostrzegawczy mi się włączył, gdyż właśnie dzięki temu udało mi się drążyć testcase tak długo, aż doszedłem do prawidłowego rozwiązania, natomiast było to działanie zdecydowanie zbyt mało świadome (tzn. rozważenie możliwych źródeł błędu i obranie na ich podstawie potencjalnych dróg działania), a za bardzo oparte na jakimś bliżej niezidentyfikowanym przeczuciu. Tak być nie powinno.

W ogóle zaczynam dochodzić do wniosku, że w przypadku dużego systemu, nawet jeśli trzeba coś zrobić na wczoraj, zdecydowanie bardziej produktywne będzie przeanalizowanie krok po kroku działania całości w celu wyeliminowania białych plam i dopiero wtedy podejmowania jakiś działań, a nie robienie pierwszej lepszej rzeczy, jaka przyjdzie do głowy i liczenie na to, że testy wypadną pomyślnie. Nie wypadną. Od tego system jest duży i skomplikowany, żeby istniało bardzo dużo (względnie) prostych i błędnych rozwiązań danego problemu.

Nawiasem mówiąc dzięki obecnej pracy moje wyobrażenie na temat wydajności programistów ulega nieustannej zmianie. Ale to już temat na osobny wpis.

Jabber (Psi?) zdecydowanie powinien mieć priorytety przy wysyłaniu wiadomości. Żebym mógł sobie ustawić, że wszystko, co nie ma priorytetu urgent ma mnie w żaden sposób nie monitować i mam w ogóle nie wiedzieć o tego istnieniu.

Ewentualnie będę się musiał zainteresować trybem 'niewidoczny', czy coś. Albo ustawiać sobie jakiś groźnie brzmiący away status. Nie wiem co się w praktyce najlepiej sprawdza.