Lista 10 tekstów, bez których byłbym znacznie głupszy

Wielu ludzi bardzo lubi się chwalić tym, ile wysiłku włożyli w osiągnięcie rzeczy, z których są szczególnie dumni. Przedstawiają oni często życie jako toczoną samodzielnie bitwę z wrogim losem, bitwę rzecz jasna spektakularnie wygraną. Jej efektem ma być wyrwanie ze szponów niesprawiedliwego świata jakiegoś trofeum, materialnego lub nie, za którego posiadanie należą się im wyrazy uznania i splendor.

Nie podzielam tej preferencji. Głęboko wierzę, że zdecydowana większość "osiągnięć" w życiu to w znacznej części kwestia szczęścia. Nie mamy wpływu na to, jaką jego dawkę przepisał nam los. U niektórych jest go niesprawiedliwie dużo, podczas gdy pewnym pechowcom Fortuna serwuje szczęście w mikrodozach, w dodatku aplikowanych rektalnie.

Count your blessings

Różnicę między powyższymi postawami można najkrócej opisać podejściem do wdzięczności. Pierwsza skutkuje jej brakiem: nikomu za nic nie trzeba być wdzięcznym, wszystko osiągnięto wszak samodzielnie. Ta druga jest odwrotna. Pozwala dzięki temu dostrzec, jak wiele zawdzięczamy innym. I jak ubożsi w wiedzę, umiejętności i doświadczenia bylibyśmy bez nich.

Za każdym razem, gdy odczuwam dumę z jakiegoś swojego osiągnięcia, staram się dokonać mentalnej inwentaryzacji tego, komu powinienem za nie podziękować. Zdarza mi się potem wysyłać maila do jakiejś osoby spotkanej lata temu, w którym dziękuję za otrzymaną od nich lekcję. Sam dostałem kilka takich wiadomości. Choć czasem boję się, że brzmię w tych mailach jak creep, wiem ile radości sprawia mi otrzymywanie ich, co łagodzi moje wątpliwości.

Większość swoich dzisiejszych zawodowych umiejętności i opinii technicznych potrafię "wyśledzić" i znaleźć ich źródła (osobowe, tekstowe lub abstrakcyjne). Zaskakująco często wskazują one na któryś z dziesięciu artykułów, bez których bez wątpienia byłbym słabszym fachowcem. Jestem wdzięczny autorom za ich napisanie i losowi za podrzucenie ich w pole mojego krótkowzrocznego widzenia.

Oto one:

Things You Should Never Do, Part I  -- Joel Spolsky, kwiecień 2000

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-p...

Przestroga przed lekkomyślnym przebudowywaniem projektu od zera, radykalnym refactoringiem oraz pozostałymi tendencjami rewolucyjnymi. Podkreślając głęboką prawdę, że łatwiej jest pisać kod niż go czytać, Spolsky zwraca uwagę na to, że często ten "katastrofalny" kod, którego autor jest najwyraźniej "nieziemskim kretynem" wygląda tak dlatego, że jest najeżony bugfiksami, a skoro się w nim ostały, to znaczy że obecna jego postać rozwiązuje problem i zarabia pieniądze.

To bardzo cenna lekcja na temat tego, że techniczna poprawność nie zawsze jest poprawnym rozwiązaniem problemu. Pozwala ona uniknąć żenujących wytłumaczeń w stylu "może i unieruchomiło to gałąź na trzy iteracje, ale za to teraz ma niższą złożoność cyklomatyczną!" i innych z rodziny "prawie gotowe". No i uczy pokory: nikt nie ma powodu podejrzewać o sobie, że pisząc coś od zera, zawsze skończy z efektem lepszym niż na początku.

Sticking with Well-Known and Proven Solutions -- Aaron Margosis, czerwiec 2010

https://docs.microsoft.com/en-us/archive/blogs/fdcc/sticking-with-well...

Ważna obserwacja dotycząca młodocianego pędu do zabezpieczania wszystkiego, tylko dlatego, że "się da". Wieloletni pracownik Microsoftu, wprawiony w kontaktach z klientami, tłumaczy nieunikniony koszt wprowadzania własnych, dodatkowych konfiguracji, na przykładzie Zasad Grupy.

Odnalezienie interesująco brzmiących przełączników i włączenie ich nie z powodu zidentyfikowanego zagrożenia, a z nieukierunkowanej chęci "zwiększenia zabezpieczeń", zmienia stosowany model bezpieczeństwa ze standardowego na znany tylko jednemu administratorowi.

Autor zwraca nam uwagę, że powszechnie wydawane zbiory ustawień fundamentalnych (Microsoft Security Baselines) oraz wytyczne jak DISA STIG istnieją nie bez powodu i jeżeli coś pracuje na ustawieniach domyślnych, nie jest wtedy wcale synonimem niezabezpieczonego. W życiu naprawdę nie zawsze chodzi o to, żeby się napracować. Odczułem to na początku swojej kariery.

Choosing our preferences -- Havoc Pennington, kwiecień 2002

https://ometer.com/preferences.html

Doskonale wytłumaczone powody, dla których projekt GNOME w swojej wersji 2.0 zadecydował o wypowiedzeniu wojny nadmiarowi ustawień i preferencji. Według badań użyteczności, opinii testerów i zgłoszeń błędów (idących w setki), duża liczba ustawień do samodzielnej zmiany przez użytkownika, niemal nigdy nie ma zalet wygrywających nad apokaliptycznie poważnymi problemami, jakie idą w parze z nią.

Pennington słusznie postuluje, by nigdy nie bronić poglądu "skoro ktoś o to poprosił, to znaczy, że to powinno być opcją". Jeżeli użytkownik chce coś zmienić, może po prostu program powinien się zachowywać inaczej? Jak często przecież ktoś wędruje po panelach kontrolnych i dostosowuje ustawienia? Podobnego zdania jest, swoją drogą, Joel Spolsky.

Przy okazji wychodzi tu na jaw kwestia pozornego zaawansowania. Błędnym jest przekonanie, że zaawansowani użytkownicy chcą więcej preferencji i ustawień. Chcą oni, by program po prostu działał, a więc chcą tego samego, co pozostali. Zdobywanie biegłości w zaawansowanych preferencjach danej aplikacji oraz znajomość setek egzotycznych przełączników nie czyni nikogo produktywniejszym ani "lepszym". Może najwyżej pomóc w teleturniejach.

The internet is at the mercy of a handful of people -- Casper Beyer, marzec 2018

https://medium.com/commitlog/the-internet-is-at-the-mercy-of-a-handful...

Bardzo łatwy do błędnego zinterpretowania tekst na temat ryzyka wciągania się w zewnętrzne zależności. Bez szczególnych poszukiwań możemy dziś natknąć się na pogląd brzmiący bardzo podobnie, ujęty zazwyczaj w słowach "a ci młodzi to by tylko gotowce i biblioteki brali, zamiast pisać samodzielnie i program ma potem 320 megabajtów!". Zazwyczaj jednak chodzi w nim o religijny pogląd, że w ogóle każdy PIP, CPAN, NPM, Maven i NuGet to zło i dzieci teraz mają za łatwo.

Beyerowi chodzi tymczasem o coś innego. Posługując się przykładem biblioteki "is-odd", sprawdzającej czy liczba jest nieparzysta, pokazał że wiele osób zawodowo piszących kod nie daje sobie rady z podstawowymi zagadnieniami, a powołując się na liczbę pobrań wykazał, jak rzadka jest świadomość, że każda dependencja spoza dystrybucji to kolejne ogniwo do autoryzacji.

Nie chodzi tu o to, żeby wszystko zawsze robić samemu. To też błąd. W życiu należy robić jak najmniej, a najlepiej w ogóle nic. Dlatego pracując np. w .NET Core, nie ma nic złego w sięgnięciu po NuGet i pobraniu nowego Entity Framework oraz popularnej biblioteki open source do baz danych, zamiast samemu gadać z SQL‑em. Po prostu zawsze należy pamiętać komu ufamy i od kogo jesteśmy zależni.

Monad Manifesto -- Jeffrey Snover, sierpień 2002

https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.b...

Najmilej na świecie ujęte "wszyscy się mylicie, nikt z was nie ma racji". To dokument opisujący powody powstania powłoki Monad Shell, znanej dziś pod nazwą PowerShell. Dosadnie i trafnie opisuje poważne braki w narzędziach administracyjnych Windows, którymi wtedy były albo graficzne przystawki MMC albo skrypty w księżycowym dialekcie Visual Basica.

Przystawki były chorobliwie ciężkie, coraz prędzej rozrastały się do absurdalnych rozmiarów i nie obsługiwały automatyzacji. Z kolei Visual Basic, Scripting Edition owszem był "skryptowy", ale jego funkcje administracyjne polegały na bezpośredniej interakcji z modelem COM, co jest programowaniem, a nie administracją.

W przepiękny (i pozbawiony znanego z "Unix Haters' Book" sarkazmu) sposób ukazuje także poważne braki Uniksa i jego klasycznych powłok. Chodzi tu zarówno o kwestie logiczne, jak kontrola błędów przy wielokrotnym pipe'owaniu, oraz fundamentalne, jak oparcie o strumień bajtów, którym trzeba się zajmować samodzielnie.

Choć PowerShella można nie lubić, Monad Manifesto stanowi doskonały przykład wysoce rzetelnej identyfikacji problemu i zasugerowania rozwiązania precyzyjnie celującego we wszystkie jego punkty. Nie znajdziemy w nim dogmatyzmu: obrywa się zarówno Windowsowi jak i Uniksom. Żaden system nie jest święty.

The Hacker Attitude -- Eric. S Raymond, 2001

http://www.catb.org/~esr/faqs/hacker-howto.html

Zbiór pięciu punktów charakteryzujących pożądane postawy u osób aspirujących do zostania hakerami, będący częścią o wiele większego dokumentu "How To Become A Hacker". Każdy z nich, moim zdaniem, niesie więcej treści niż niejedno opasłe tomisko.

Choć każdy z punktów jest mi bliski, moim ulubionym jest Arogancja nie jest substytutem kompetencji. Na arogancję trzeba sobie zasłużyć. Nie zdobędzie się opinii fachowca wskutek manifestacyjnego przewracania oczami w odpowiedzi na pytania, nie zostanie się uznanym za eksperta, czy będzie się obrażać rozmówców. Rzekome "zmęczenie głupotą", mające na celu udawanie sfrustrowanego nieporadnością geniusza, w oczach ludzi pewnych swego uchodzi za frustrację i bezczelność.

Dlatego nie wdaję się w dyskusję z ludźmi, którzy rzucają hasła "autor nie ma pojęcia o czym mówi", a następnie dokonują (bardzo długiej) prezentacji zgromadzonych triviów, zewnętrznych pozorów kompetencji. Wydaje im się, że moje milczenie oznacza ucieczkę. Tymczasem jest to brak cierpliwości wobec głębokiej niedojrzałości, której dostrzegania uczy Raymond.

Windows Server 2003: The Road To Gold -- Paul Thurrott, styczeń 2003

https://www.itprotoday.com/windows-server/windows-server-2003-road-gol...

To kompletna historia rozwoju NT, serca obecnych Windowsów, skondensowana dla osób, które nie mają siły, czasu lub chęci na przeczytanie książki "Showstopper" Pascala Zachary'ego. Dzieje NT to jednak przede wszystkim dzieje tego, co nie powstało. Opisane przez Thurrotta początki projektu to najpierw próba ratowania skazanego na porażkę OS/2, nieszczęśliwego systemu-ofiary kalendarium wydawniczego.

OS/2 miał być chronionym rozwinięciem MS‑DOS, zorientowanym na wykorzystanie procesora 286. Inwestowanie w 286 było jednak "stratą czasu", był to technologiczny przystanek, ale 32‑bitowy 386 był jeszcze niedostępny. IBM miał do wyboru czekać na sprzęt lub wydać cokolwiek, ale teraz. Zdecydował się wydać system wymagający przepisania dwa lata po powstaniu.

Microsoft nie miał żadnych sentymentów. Ponieważ OS/2 nie odpowiadał na żadne zapotrzebowanie, wymieniono główne API NT z OS/2 na Windows. Skończyło się to emocjonalną reakcją wielu inżynierów, zawodem hobbystów, rozczarowaniem recenzentów i poważnym nadwyrężeniem relacji z IBM. Dziś o OS/2 nikt nie pamięta. Microsoft i NT to dowód na szkodliwość myślenia życzeniowego.

What Happened When I Peeked Into My  Node_Modules Directory -- Jordan Scales, sierpień 2016

https://medium.com/s/silicon-satire/i-peeked-into-my-node-modules-dire...

Stanowiąc tematyczną kontynuację zjawiska opisanego "The internet is at the mercy of a handful of people" (cudzego autorstwa), tekst Scalesa uświadamia nam, że wiele osób doskonale wie, że internet jest fundamentalnie popsuty, programy zbyt złożone, a kompetencje - masowo niewystarczające. Wiedząc to, i będąc wobec owego zjawiska bezradnym, niejeden programista po prostu... zaczyna sobie robić jaja.

Scales przytacza "przykłady": biblioteki frameworku Express.js zawierały logikę like'ującą twitterowy wpis z ogłoszeniem o wprowadzeniu na rynek nowego smaku Hot Pockets. Ember.js podczas inicjalizacji pobiera zawartość Tomu G z księgozbioru Encyclopadia Britannica, aby wyświetlić w polu licencji definicję słowa będącego nazwą biblioteki. Kompilator Babel.js zawiera tablicę, która przechowuje fotografią Guy'a Fieriego w HD.

Tekst ten jest dowcipem. Bardzo dobrze zaprojektowanym: na początku przytacza przykłady tylko trochę głupsze od "is‑odd", by na końcu zasugerować kompletny nonsens. Geniusz owego tekstu objawia się w tym, że po jego pierwszym przeczytaniu nie jesteśmy na 100% pewni, czy to żart. A to powinno być alarmujące.

Powtarzając konkluzję z tekstu Beyera, Scales dodaje jej przy okazji trochę czarnego humoru, bowiem tylko humor może nas uratować w świecie wszechobecnego JavaScriptu. Czas więc na głęboki wdech. Nie warto umierać na krzyżu za JavaScript. Poza tym, ktoś na pewno napisał już do tego framework.

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) -- Joel Spolsky, październik 2003

https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-s...

Ponownie Joel Spolsky, tym razem tłumaczący w niezwykle przystępnych słowach, jak działa Unicode. Starannie prowadzony wykład przedstawia nie tylko zawiłości techniczne samej implementacji różnych trybów UTF, ale także wyjaśnia, nieznaną najwyraźniej, koncepcję kodowania wielobajtowego. Jest to wiedza niezbędna do zrozumienia zarządzania pamięcią w sekcji danych. Niechlujność w jej nauczaniu prowadzi, w mojej opinii, do poważnych braków w świadomości studentów i groźnej nieznajomości metodyki kodowania znaków.

Znaki szerokie i kodowanie wielobajtowe uznałem za przydatne metody tłumaczenia zasad parsowania strumieni w powłoce i przechowywania danych/przesuwania wskaźników moim pierwszorocznym studentom. Przez kilka lat swojej działalności dydaktycznej uparłem się, że nie będę powielał estetycznego schematu "mamo mamo jestem chakerem", polegającego na uczeniu studentów wypisywania stringów w okno cmd bez polskich znaków i zatrzymywania wyjścia przez wołanie PAUSE.EXE.

Ewangelizowanie świata w zakresie szerokości zmiennych kontynuuję po dziś dzień, dobrych kilka lat po (niechętnym) zakończeniu współpracy z uczelnią. Efekty można odnaleźć również w mojej działalności w Redakcji, skutkującej tekstem Ciężki los cyfrowej typografii w erze wektorowych dinozaurów oraz serią "Zawiłości kodowania znaków", którą pragnę przy okazji polecić.

Komentarz #129 -- Linus Torvalds, grudzień 2010

https://bugzilla.redhat.com/show_bug.cgi?id=638477#c129

Popularnym, acz zgranym dowcipem na studiach medycznych jest hasło "nie mam pojęcia, co panu dolega, ale mogę panu narysować Cykl Krebsa". Jest ono świetnym przykładem zaawansowanego merytorycznie przygotowania, które nie ma żadnego znaczenia w prawdziwym świecie i które przegrywa z doraźnym zapotrzebowaniem. W taki to, bardzo "linuksowy" sposób, Projekt Fedora popsuł Flasha 10 lat temu. Dokonano technicznie poprawnej korekty implementacji mechanizmu zarządzania pamięcią.

W efekcie zmian w glibc i jego memcpy(), obsługa dźwięku we wtyczkach Adobe Flash uległa znacznemu pogorszeniu. Żywiący intensywną pogardę wobec zamkniętego oprogramowania programiści Red Hata stwierdzili, że z implementacją jest wszystko w porządku, a Adobe "robi złe oprogramowanie", które nie przestrzega standardów i się psuje.

Dokładnie to myślenie przyczynia się do trzymania Linuksów "pod progiem wyborczym". Widząc nonsens postawy "no ale przecież i tak nikt nas tak na serio nie używa", w wątku omawiającym problem z Flashem odezwał się Linus Torvalds. Stwierdził on, że jeżeli coś raz działało, a zmiana API to popsuła, to system jest wadliwy, bo przestają na nim działać niegdyś sprawne programy. Liczy się rzeczywistość, a nie standardy. "Więc po prostu to naprawcie".

Fin

Nigdy nie miałem okazji zebrać owych tytułów w jednym miejscu. Dotychczas walały się one w czeluściach nieposynchronizowanych folderów z zakładkami w wielu przeglądarkach i gdy zechciałem je cytować, musiałem ich szukać od nowa. Teraz będzie mi łatwiej. Czas podziękować ich autorom.