Hakerzy i Malarze

Maj 2003

(Ten esej jest oparty na wykładzie gościnnym na Harvardzie, który zawierał wcześniejszą prelekcję na Northeastern.)

Kiedy skończyłem studia magisterskie z informatyki, poszedłem do szkoły artystycznej, żeby studiować malarstwo. Wielu ludzi było zaskoczonych, że ktoś zainteresowany komputerami interesuje się również malarstwem. Wydawało im się, że hacking i malowanie to bardzo różne rodzaje pracy – że hacking jest zimny, precyzyjny i metodyczny, a malowanie to szaleńcze wyrażanie jakiegoś pierwotnego popędu.

Oba te obrazy są błędne. Hacking i malowanie mają wiele wspólnego. Właściwie, spośród wszystkich typów ludzi, których znałem, hakerzy i malarze są najbardziej do siebie podobni.

To, co łączy hakerów i malarzy, to fakt, że obaj są twórcami. Wraz z kompozytorami, architektami i pisarzami, hakerzy i malarze starają się tworzyć dobre rzeczy. Nie prowadzą badań per se, chociaż jeśli w trakcie tworzenia dobrych rzeczy odkryją jakąś nową technikę, tym lepiej.

Nigdy nie lubiłem terminu „informatyka”. Głównym powodem jest to, że taki termin nie istnieje. Informatyka to zbiór luźno powiązanych dziedzin, połączonych zbiegiem okoliczności historycznych, niczym Jugosławia. Z jednej strony mamy ludzi, którzy są prawdziwymi matematykami, ale nazywają to, co robią, informatyką, żeby dostać granty od DARPA. W środku mamy ludzi pracujących nad czymś w rodzaju historii naturalnej komputerów – badających na przykład zachowanie algorytmów routingu danych w sieciach. A na drugim krańcu mamy hakerów, którzy próbują pisać interesujące oprogramowanie, dla których komputery są tylko medium wyrazu, tak jak beton dla architektów, czy farba dla malarzy. To tak, jakby matematycy, fizycy i architekci musieli być w tym samym dziale.

Czasami to, co robią hakerzy, nazywane jest „inżynierią oprogramowania”, ale ten termin jest równie mylący. Dobrzy projektanci oprogramowania nie są bardziej inżynierami niż architekci. Granica między architekturą a inżynierią nie jest ostro zdefiniowana, ale istnieje. Leży między „co” a „jak”: architekci decydują, co zrobić, a inżynierowie wymyślają, jak to zrobić.

„Co” i „jak” nie powinny być zbyt rozdzielone. Ryzykujesz kłopoty, jeśli próbujesz zdecydować, co zrobić, nie rozumiejąc, jak to zrobić. Ale hacking może być czymś więcej niż tylko decydowaniem, jak zaimplementować jakąś specyfikację. W najlepszym wydaniu jest to tworzenie specyfikacji – chociaż okazuje się, że najlepszym sposobem na to jest jej implementacja.

Może pewnego dnia „informatyka”, podobnie jak Jugosławia, zostanie rozbita na swoje składowe części. To mogłoby być dobre. Zwłaszcza jeśli oznaczałoby to niepodległość dla mojej ojczyzny, hackingu.

Łączenie wszystkich tych różnych rodzajów pracy w jednym dziale może być wygodne administracyjnie, ale jest mylące intelektualnie. To drugi powód, dla którego nie lubię nazwy „informatyka”. Można argumentować, że ludzie w środku robią coś na kształt nauki eksperymentalnej. Ale ludzie na obu krańcach, hakerzy i matematycy, faktycznie nie zajmują się nauką.

Matematycy zdają się tym nie przejmować. Z zapałem zabierają się do dowodzenia twierdzeń, podobnie jak inni matematycy w dziale matematyki, i prawdopodobnie wkrótce przestaną zauważać, że na budynku, w którym pracują, widnieje napis „informatyka”. Ale dla hakerów ta etykieta jest problemem. Jeśli to, co robią, nazywa się nauką, czują, że powinni zachowywać się naukowo. Zamiast więc robić to, czego naprawdę chcą, czyli projektować piękne oprogramowanie, hakerzy na uniwersytetach i w laboratoriach badawczych czują, że powinni pisać prace naukowe.

W najlepszym wypadku prace są tylko formalnością. Hakerzy piszą fajne oprogramowanie, a potem piszą o nim pracę, a praca staje się substytutem osiągnięcia reprezentowanego przez oprogramowanie. Ale często ta rozbieżność powoduje problemy. Łatwo jest odejść od tworzenia pięknych rzeczy w kierunku tworzenia brzydkich rzeczy, które stanowią bardziej odpowiednie tematy do prac naukowych.

Niestety, piękne rzeczy nie zawsze stanowią najlepsze tematy do prac. Po pierwsze, badania muszą być oryginalne – a jak wie każdy, kto pisał pracę doktorską, sposób na pewność, że eksplorujesz dziewiczy teren, to wyznaczenie sobie kawałka ziemi, którego nikt nie chce. Po drugie, badania muszą być obszerne – a niezgrabne systemy dają bardziej treściwe prace, ponieważ można pisać o przeszkodach, które trzeba pokonać, aby coś zrobić. Nic nie daje bardziej treściwych problemów niż zaczynanie od błędnych założeń. Większość AI jest przykładem tej zasady; jeśli założysz, że wiedzę można reprezentować jako listę wyrażeń logiki predykatów, których argumenty reprezentują abstrakcyjne pojęcia, będziesz miał wiele prac do napisania o tym, jak to działa. Jak mawiał Ricky Ricardo: „Lucy, masz dużo do wyjaśniania”.

Sposób tworzenia czegoś pięknego często polega na wprowadzaniu subtelnych poprawek do czegoś, co już istnieje, lub na łączeniu istniejących pomysłów w nieco nowy sposób. Taki rodzaj pracy trudno przekazać w pracy naukowej.

Dlaczego więc uniwersytety i laboratoria badawcze nadal oceniają hakerów na podstawie publikacji? Z tego samego powodu, dla którego „zdolności akademickie” mierzy się prostymi testami standaryzowanymi, lub produktywność programistów mierzy się w liniach kodu. Te testy są łatwe do zastosowania, a nic nie jest tak kuszące jak łatwy test, który jako tako działa.

Mierzenie tego, co hakerzy faktycznie próbują zrobić, czyli projektowanie pięknego oprogramowania, byłoby znacznie trudniejsze. Potrzebne jest dobre poczucie stylu, aby ocenić dobry projekt. I nie ma korelacji, poza być może negatywną, między zdolnością ludzi do rozpoznawania dobrego projektu a ich pewnością, że potrafią.

Jedynym zewnętrznym testem jest czas. Z czasem piękne rzeczy mają tendencję do przetrwania, a brzydkie rzeczy do odrzucenia. Niestety, ilość czasu może być dłuższa niż ludzkie życie. Samuel Johnson powiedział, że potrzeba stu lat, aby reputacja pisarza się ustabilizowała. Trzeba poczekać, aż umrą wpływowi przyjaciele pisarza, a potem wszyscy jego naśladowcy.

Myślę, że hakerzy muszą po prostu pogodzić się z tym, że ich reputacja ma duży losowy składnik. Pod tym względem nie różnią się od innych twórców. W rzeczywistości mają szczęście w porównaniu. Wpływ mody nie jest w hackingu tak wielki, jak w malarstwie.

Są gorsze rzeczy niż to, że ludzie źle rozumieją twoją pracę. Gorszym niebezpieczeństwem jest to, że sam będziesz źle rozumieć swoją pracę. Powiązane dziedziny to miejsca, w których szukasz pomysłów. Jeśli znajdziesz się na wydziale informatyki, istnieje naturalna pokusa, by wierzyć na przykład, że hacking jest zastosowaną wersją tego, czym jest teoria informatyki. Przez cały czas, gdy byłem na studiach, miałem w tyle głowy niepokojące uczucie, że powinienem znać więcej teorii i że jestem bardzo zaniedbany, zapominając tego wszystkiego w ciągu trzech tygodni po egzaminie końcowym.

Teraz zdaję sobie sprawę, że się myliłem. Hakerzy potrzebują rozumieć teorię obliczeń mniej więcej tyle, ile malarze potrzebują rozumieć chemię farb. Trzeba wiedzieć, jak obliczać złożoność czasową i przestrzenną oraz o kompletności Turinga. Można też pamiętać przynajmniej koncepcję automatu skończonego, na wypadek gdyby trzeba było napisać parser lub bibliotekę wyrażeń regularnych. Malarze w rzeczywistości muszą pamiętać znacznie więcej o chemii farb niż tylko to.

Odkryłem, że najlepszymi źródłami pomysłów nie są inne dziedziny, które mają w nazwie słowo „komputer”, ale inne dziedziny zamieszkałe przez twórców. Malarstwo było znacznie bogatszym źródłem pomysłów niż teoria obliczeń.

Na przykład, uczono mnie na studiach, że powinno się całkowicie przemyśleć program na papierze, zanim w ogóle zbliży się do komputera. Odkryłem, że nie programuję w ten sposób. Odkryłem, że lubię programować siedząc przed komputerem, a nie kartką papieru. Co gorsza, zamiast cierpliwie pisać kompletny program i upewniać się, że jest poprawny, miałem tendencję do po prostu wyrzucania kodu, który był beznadziejnie zepsuty, i stopniowego doprowadzania go do porządku. Debugowanie, jak mnie uczono, było rodzajem ostatniego przejścia, w którym wyłapywało się literówki i przeoczenia. W sposób, w jaki pracowałem, wydawało się, że programowanie polega na debugowaniu.

Przez długi czas czułem się z tym źle, tak jak kiedyś czułem się źle, że nie trzymam ołówka tak, jak uczyli mnie w szkole podstawowej. Gdybym tylko spojrzał na innych twórców, malarzy lub architektów, zdałbym sobie sprawę, że to, co robię, ma swoją nazwę: szkicowanie. O ile wiem, sposób, w jaki uczono mnie programować na studiach, był całkowicie błędny. Programy powinno się przemyśliwać podczas ich pisania, tak jak robią to pisarze, malarze i architekci.

Uświadomienie sobie tego ma realne implikacje dla projektowania oprogramowania. Oznacza to, że język programowania powinien być przede wszystkim plastyczny. Język programowania służy do myślenia o programach, a nie do wyrażania programów, które już się pomyślało. Powinien być ołówkiem, a nie długopisem. Statyczne typowanie byłoby dobrym pomysłem, gdyby ludzie faktycznie pisali programy tak, jak uczono mnie na studiach. Ale żaden haker, którego znam, nie pisze programów w ten sposób. Potrzebujemy języka, który pozwala nam bazgrać, rozmazywać i smarować, a nie języka, w którym trzeba siedzieć z filiżanką herbaty typów na kolanach i prowadzić uprzejme rozmówki ze surową, starą ciotką kompilatorem.

Skoro już jesteśmy przy temacie statycznego typowania, identyfikacja z twórcami uchroni nas przed kolejnym problemem, który dotyka nauki: zazdrością matematyczną. Wszyscy w naukach ścisłych potajemnie wierzą, że matematycy są od nich mądrzejsi. Myślę, że matematycy też tak uważają. W każdym razie rezultatem jest to, że naukowcy starają się, aby ich praca wyglądała jak najbardziej matematycznie. W dziedzinie takiej jak fizyka prawdopodobnie nie wyrządza to wielkiej szkody, ale im dalej od nauk przyrodniczych, tym większym problemem się to staje.

Strona z formułami wygląda tak imponująco. (Wskazówka: dla dodatkowego wrażenia używaj greckich zmiennych.) I dlatego istnieje wielka pokusa, by pracować nad problemami, które można traktować formalnie, zamiast nad problemami, które są na przykład ważne.

Gdyby hakerzy identyfikowali się z innymi twórcami, takimi jak pisarze i malarze, nie czuliby pokusy, by to robić. Pisarze i malarze nie cierpią na zazdrość matematyczną. Czują się, jakby robili coś zupełnie innego. Tak samo myślę o hakerach.

Jeśli uniwersytety i laboratoria badawcze powstrzymują hakerów przed robieniem tego, co chcą, być może ich miejscem są firmy. Niestety, większość firm również nie pozwoli hakerom robić tego, czego chcą. Uniwersytety i laboratoria badawcze zmuszają hakerów do bycia naukowcami, a firmy zmuszają ich do bycia inżynierami.

Sam odkryłem to dopiero niedawno. Kiedy Yahoo kupiło Viaweb, zapytali mnie, co chcę robić. Nigdy nie przepadałem za stroną biznesową i powiedziałem, że po prostu chcę hackować. Kiedy trafiłem do Yahoo, okazało się, że hacking oznaczał dla nich implementację oprogramowania, a nie jego projektowanie. Programiści byli postrzegani jako technicy, którzy przekładali wizje (jeśli można to tak nazwać) menedżerów produktu na kod.

To wydaje się być domyślnym planem w dużych firmach. Robią to, ponieważ zmniejsza to odchylenie standardowe wyników. Tylko niewielki procent hakerów potrafi faktycznie projektować oprogramowanie, a osobom zarządzającym firmą trudno jest ich wyłonić. Zamiast więc powierzać przyszłość oprogramowania jednemu genialnemu hakerowi, większość firm organizuje tak, że jest ono projektowane przez komitet, a hakerzy jedynie implementują projekt.

Jeśli chcesz kiedyś zarobić pieniądze, pamiętaj o tym, ponieważ jest to jeden z powodów, dla których startupy wygrywają. Duże firmy chcą zmniejszyć odchylenie standardowe wyników projektowych, ponieważ chcą unikać katastrof. Ale kiedy tłumisz oscylacje, tracisz zarówno punkty wysokie, jak i niskie. Nie jest to problem dla dużych firm, ponieważ nie wygrywają, tworząc świetne produkty. Duże firmy wygrywają, będąc mniej beznadziejnymi niż inne duże firmy.

Więc jeśli uda ci się wymyślić sposób na rozpoczęcie wojny projektowej z firmą na tyle dużą, że jej oprogramowanie jest projektowane przez menedżerów produktu, nigdy nie będą w stanie cię dogonić. Te okazje nie są jednak łatwe do znalezienia. Trudno jest zaangażować dużą firmę w wojnę projektową, tak jak trudno jest zaangażować przeciwnika w zamku do walki wręcz. Na przykład, byłoby bardzo łatwo napisać lepszy procesor tekstu niż Microsoft Word, ale Microsoft, w zamku swojej monopolu na system operacyjny, prawdopodobnie nawet by tego nie zauważył.

Miejscem do prowadzenia wojen projektowych są nowe rynki, gdzie nikt jeszcze nie zdołał umocnić żadnych fortyfikacji. Tam można wygrać dużo, przyjmując odważne podejście do projektowania i mając tych samych ludzi zarówno projektujących, jak i implementujących produkt. Sam Microsoft zrobił to na początku. Podobnie Apple. I Hewlett-Packard. Podejrzewam, że prawie każdy udany startup.

Jednym ze sposobów na tworzenie świetnego oprogramowania jest założenie własnego startupu. Są jednak dwa problemy. Po pierwsze, w startupie trzeba robić tak wiele rzeczy oprócz pisania oprogramowania. W Viaweb uważałem się za szczęśliwego, jeśli udawało mi się hackować przez ćwierć czasu. A rzeczy, które musiałem robić przez pozostałe trzy kwadranse, wahały się od żmudnych po przerażające. Mam dla tego punkt odniesienia, ponieważ kiedyś musiałem opuścić spotkanie zarządu, żeby uzupełnić jakieś ubytki. Pamiętam, jak siedziałem na fotelu dentystycznym, czekając na wiertło, i czułem się, jakbym był na wakacjach.

Drugim problemem startupów jest to, że nie ma dużego pokrycia między rodzajem oprogramowania, które przynosi pieniądze, a tym, które jest interesujące do napisania. Języki programowania są interesujące do pisania, a pierwszym produktem Microsoftu był właśnie taki, ale nikt już nie zapłaci za języki programowania. Jeśli chcesz zarobić pieniądze, zazwyczaj jesteś zmuszony pracować nad problemami, które są zbyt paskudne, aby ktokolwiek rozwiązał je za darmo.

Wszyscy twórcy napotykają ten problem. Ceny są ustalane przez podaż i popyt, a na rzeczy, nad którymi przyjemnie się pracuje, jest po prostu mniejszy popyt niż na rzeczy, które rozwiązują codzienne problemy indywidualnych klientów. Granie w sztukach off-Broadway po prostu nie płaci tyle, co noszenie kostiumu goryla w budce na targach. Pisanie powieści nie płaci tyle, co pisanie tekstów reklamowych dla zmywarek. A hackowanie języków programowania nie płaci tyle, co wymyślanie, jak połączyć starszą bazę danych firmy z jej serwerem WWW.

Myślę, że odpowiedzią na ten problem, w przypadku oprogramowania, jest koncepcja znana prawie wszystkim twórcom: praca codzienna. To powiedzenie pochodzi od muzyków, którzy występują nocą. Bardziej ogólnie, oznacza to, że masz jeden rodzaj pracy, którą wykonujesz dla pieniędzy, a inny dla miłości.

Prawie wszyscy twórcy mają na początku kariery pracę codzienną. Malarze i pisarze robią to notorycznie. Jeśli masz szczęście, możesz dostać pracę codzienną, która jest ściśle związana z twoją właściwą pracą. Muzycy często pracują w sklepach z płytami. Haker pracujący nad jakimś językiem programowania lub systemem operacyjnym mógłby podobnie dostać pracę codzienną, wykorzystując go. [1]

Kiedy mówię, że odpowiedzią jest posiadanie przez hakerów pracy codziennej i praca nad pięknym oprogramowaniem po godzinach, nie proponuję tego jako nowy pomysł. Na tym polega cały open-source hacking. Mówię, że open-source jest prawdopodobnie właściwym modelem, ponieważ został on niezależnie potwierdzony przez wszystkich innych twórców.

Wydaje mi się zaskakujące, że jakikolwiek pracodawca mógłby się wahać przed pozwolenie hakerom na pracę nad projektami open-source. W Viaweb mielibyśmy opory przed zatrudnieniem kogoś, kto tego nie robił. Kiedy przeprowadzaliśmy wywiady z programistami, najważniejsze było dla nas to, jakie oprogramowanie pisali w wolnym czasie. Nie można niczego zrobić naprawdę dobrze, jeśli się tego nie kocha, a jeśli kochasz hackować, nieuchronnie będziesz pracować nad własnymi projektami. [2]

Ponieważ hakerzy są twórcami, a nie naukowcami, właściwym miejscem do szukania metafor nie są nauki ścisłe, ale inne rodzaje twórców. Czego jeszcze malarstwo może nas nauczyć o hackingu?

Jedną z rzeczy, których możemy się nauczyć, lub przynajmniej potwierdzić, z przykładu malarstwa, jest to, jak nauczyć się hackować. Uczysz się malować głównie przez robienie tego. Ditto dla hackingu. Większość hakerów nie uczy się hackować, uczęszczając na kursy programowania. Uczą się hackować, pisząc własne programy w wieku trzynastu lat. Nawet na zajęciach uniwersyteckich uczysz się hackować głównie przez hackowanie. [3]

Ponieważ malarze zostawiają po sobie ślad pracy, można obserwować, jak uczą się przez działanie. Jeśli spojrzysz na pracę malarza w porządku chronologicznym, zauważysz, że każdy obraz opiera się na rzeczach nauczonych w poprzednich. Kiedy w obrazie jest coś, co działa bardzo dobrze, zazwyczaj można znaleźć jego wersję 1 w mniejszej formie w jakimś wcześniejszym obrazie.

Myślę, że większość twórców pracuje w ten sposób. Pisarze i architekci również. Może hakerzy powinni postępować bardziej jak malarze i regularnie zaczynać od nowa, zamiast pracować przez lata nad jednym projektem i próbować włączyć wszystkie późniejsze pomysły jako rewizje.

Fakt, że hakerzy uczą się hackować przez działanie, jest kolejnym znakiem tego, jak bardzo hacking różni się od nauk ścisłych. Naukowcy nie uczą się nauki przez jej uprawianie, ale przez wykonywanie ćwiczeń laboratoryjnych i zadań. Naukowcy zaczynają od pracy, która jest doskonała, w tym sensie, że próbują odtworzyć pracę, którą ktoś inny już dla nich wykonał. Ostatecznie dochodzą do punktu, w którym mogą wykonywać oryginalną pracę. Natomiast hakerzy od początku wykonują oryginalną pracę; jest ona po prostu bardzo słaba. Więc hakerzy zaczynają od oryginalności i stają się dobrzy, a naukowcy zaczynają od bycia dobrymi i stają się oryginalni.

Innym sposobem, w jaki twórcy się uczą, są przykłady. Dla malarza muzeum jest biblioteką referencyjną technik. Przez setki lat tradycyjną edukacją malarzy było kopiowanie dzieł wielkich mistrzów, ponieważ kopiowanie zmusza do uważnego przyjrzenia się sposobowi wykonania obrazu.

Pisarze też to robią. Benjamin Franklin uczył się pisać, podsumowując punkty z esejów Addisona i Steele'a, a następnie próbując je odtworzyć. Raymond Chandler robił to samo z opowiadaniami detektywistycznymi.

Hakerzy podobnie mogą uczyć się programować, patrząc na dobre programy – nie tylko na to, co robią, ale także na kod źródłowy. Jedną z mniej nagłaśnianych korzyści z ruchu open-source jest to, że ułatwił on naukę programowania. Kiedy ja uczyłem się programować, musieliśmy polegać głównie na przykładach w książkach. Jedynym dużym fragmentem kodu dostępnym wtedy był Unix, ale nawet on nie był open source. Większość ludzi, którzy czytali kod źródłowy, czytała go w nielegalnych kserokopiach książki Johna Lionsa, która, choć napisana w 1977 roku, nie mogła być publikowana aż do 1996 roku.

Kolejnym przykładem, który możemy wziąć z malarstwa, jest sposób tworzenia obrazów poprzez stopniowe udoskonalanie. Obrazy zazwyczaj zaczynają się od szkicu. Stopniowo wypełniane są detale. Ale to nie tylko proces wypełniania. Czasami pierwotne plany okazują się błędne. Niezliczone obrazy, gdy spojrzy się na nie w promieniach X, okazują się mieć przesunięte kończyny lub zmienione rysy twarzy.

Oto przypadek, w którym możemy uczyć się od malarstwa. Myślę, że hacking też powinien działać w ten sposób. Jest nierealistyczne oczekiwać, że specyfikacje programu będą doskonałe. Lepiej jest przyznać to od razu i pisać programy w sposób, który pozwala na zmianę specyfikacji w locie.

(Struktura dużych firm utrudnia im to, więc oto kolejne miejsce, w którym startupy mają przewagę.)

Wszyscy już prawdopodobnie wiedzą o niebezpieczeństwie przedwczesnej optymalizacji. Myślę, że powinniśmy być równie zaniepokojeni przedwczesnym projektowaniem – zbyt wczesnym decydowaniem, co program powinien robić.

Właściwe narzędzia mogą pomóc nam uniknąć tego niebezpieczeństwa. Dobry język programowania powinien, podobnie jak farba olejna, ułatwiać zmianę zdania. Dynamiczne typowanie jest tu zaletą, ponieważ nie trzeba z góry określać konkretnych reprezentacji danych. Ale kluczem do elastyczności jest, moim zdaniem, uczynienie języka bardzo abstrakcyjnym. Najłatwiejszy do zmiany program to taki, który jest bardzo krótki.

Brzmi to jak paradoks, ale wielki obraz musi być lepszy, niż musi być. Na przykład, kiedy Leonardo namalował portret Ginevry de Benci w National Gallery, umieścił za jej głową jałowiec. Namalował w nim starannie każdy pojedynczy liść. Wielu malarzy mogłoby pomyśleć: to tylko coś w tle, żeby oprawić jej głowę. Nikt nie będzie się temu tak przyglądał.

Nie Leonardo. Jak ciężko pracował nad częścią obrazu, nie zależało wcale od tego, jak blisko oczekiwał, że ktoś się temu przyjrzy. Był jak Michael Jordan. Nieustępliwy.

Nieustępliwość zwycięża, ponieważ w agregacie niewidoczne szczegóły stają się widoczne. Kiedy ludzie przechodzą obok portretu Ginevry de Benci, ich uwaga jest często natychmiast przyciągana przez niego, jeszcze zanim spojrzą na etykietę i zauważą, że widnieje na niej Leonardo da Vinci. Wszystkie te niewidoczne szczegóły łączą się, tworząc coś oszałamiającego, jak tysiąc ledwo słyszalnych głosów śpiewających w zgodzie.

Wielkie oprogramowanie wymaga podobnie fanatycznego oddania pięknu. Jeśli spojrzysz w głąb dobrego oprogramowania, znajdziesz tam również piękne części, których nikt nigdy nie powinien widzieć. Nie twierdzę, że piszę świetne oprogramowanie, ale wiem, że jeśli chodzi o kod, zachowuję się w sposób, który kwalifikowałby mnie do leków na receptę, gdybym podszedł do codziennego życia w ten sam sposób. Doprowadza mnie do szału widok źle wciętego kodu lub używania brzydkich nazw zmiennych.

Gdyby haker był tylko implementatorem, zamieniającym specyfikację na kod, mógłby po prostu pracować od jednego końca do drugiego, jak ktoś kopiący rów. Ale jeśli haker jest twórcą, musimy wziąć pod uwagę inspirację.

W hackingu, podobnie jak w malarstwie, praca przychodzi cyklami. Czasami ekscytujesz się jakimś nowym projektem i chcesz nad nim pracować szesnaście godzin dziennie. Innym razem nic nie wydaje się interesujące.

Aby wykonać dobrą pracę, musisz brać pod uwagę te cykle, ponieważ wpływa na nie twoja reakcja na nie. Kiedy prowadzisz samochód z manualną skrzynią biegów pod górę, musisz czasem cofnąć sprzęgło, aby uniknąć zgaśnięcia silnika. Cofanie może również zapobiec zgaśnięciu ambicji. Zarówno w malarstwie, jak i w hackingu istnieją zadania przerażająco ambitne i inne, które są pocieszająco rutynowe. Dobrym pomysłem jest zachowanie kilku łatwych zadań na momenty, gdy inaczej byś się zatrzymał.

W hackingu może to dosłownie oznaczać oszczędzanie błędów. Lubię debugowanie: to jedyny moment, kiedy hacking jest tak prosty, jak ludzie myślą. Masz całkowicie ograniczony problem i wszystko, co musisz zrobić, to go rozwiązać. Twój program ma robić x. Zamiast tego robi y. Gdzie jest błąd? Wiesz, że ostatecznie wygrasz. To relaksujące jak malowanie ściany.

Przykład malarstwa może nauczyć nas nie tylko, jak zarządzać własną pracą, ale także jak pracować razem. Wiele wielkich dzieł sztuki z przeszłości to dzieła wielu rąk, chociaż na ścianie obok nich w muzeum może widnieć tylko jedno nazwisko. Leonardo był uczniem w warsztacie Verrocchia i namalował jednego z aniołów w jego Chrzcie Chrystusa. Tego rodzaju praktyka była regułą, a nie wyjątkiem. Michał Anioł był uważany za szczególnie oddanego, nalegając na samodzielne namalowanie wszystkich postaci na suficie Kaplicy Sykstyńskiej.

O ile mi wiadomo, kiedy malarze pracowali razem nad obrazem, nigdy nie pracowali nad tymi samymi częściami. Powszechne było, że mistrz malował główne postacie, a asystenci malowali pozostałe i tło. Ale nigdy nie zdarzało się, żeby jeden facet malował po pracy drugiego.

Myślę, że to jest właściwy model współpracy również w oprogramowaniu. Nie przesadzajmy. Kiedy fragment kodu jest hackowany przez trzy lub cztery różne osoby, z których żadna tak naprawdę go nie posiada, stanie się on jak wspólny pokój. Będzie wydawał się ponury i opuszczony, i będzie gromadził śmieci. Właściwy sposób współpracy, moim zdaniem, polega na dzieleniu projektów na ostro zdefiniowane moduły, z których każdy ma określonego właściciela, a interfejsy między nimi są tak starannie zaprojektowane i, jeśli to możliwe, tak jasno sformułowane jak języki programowania.

Podobnie jak malarstwo, większość oprogramowania jest przeznaczona dla odbiorcy ludzkiego. Dlatego hakerzy, podobnie jak malarze, muszą mieć empatię, aby wykonać naprawdę świetną pracę. Trzeba być w stanie spojrzeć na rzeczy z perspektywy użytkownika.

Kiedy byłem dzieckiem, zawsze mówiono mi, żebym patrzył na rzeczy z czyjejś perspektywy. W praktyce zawsze oznaczało to robienie tego, co chciał ktoś inny, zamiast tego, czego ja chciałem. To oczywiście nadało empatii złą sławę, i postanowiłem jej nie pielęgnować.

Chłopcze, jak bardzo się myliłem. Okazuje się, że patrzenie na rzeczy z perspektywy innych ludzi jest praktycznie sekretem sukcesu. Niekoniecznie oznacza to poświęcanie się. Skądże znowu. Zrozumienie, jak ktoś inny widzi rzeczy, nie oznacza, że będziesz działać w jego interesie; w niektórych sytuacjach – na przykład na wojnie – chcesz zrobić dokładnie odwrotnie. [4]

Większość twórców tworzy rzeczy dla odbiorcy ludzkiego. A aby zaangażować publiczność, trzeba zrozumieć, czego ona potrzebuje. Na przykład, prawie wszystkie największe obrazy to obrazy ludzi, ponieważ ludzie są tym, czym ludzie się interesują.

Empatia jest prawdopodobnie najważniejszą różnicą między dobrym a wielkim hakerem. Niektórzy hakerzy są całkiem inteligentni, ale jeśli chodzi o empatię, są praktycznie solipsystami. Trudno takim ludziom projektować świetne oprogramowanie [5], ponieważ nie potrafią spojrzeć na rzeczy z perspektywy użytkownika.

Jednym ze sposobów, aby ocenić, jak dobrzy ludzie są w empatii, jest obserwowanie, jak wyjaśniają techniczne zagadnienie komuś bez technicznego przygotowania. Prawdopodobnie wszyscy znamy ludzi, którzy, choć w innym wypadku inteligentni, są w tym po prostu komicznie słabi. Jeśli ktoś zapyta ich na przyjęciu, czym jest język programowania, powiedzą coś w stylu: „Ach, język wysokiego poziomu jest tym, czego kompilator używa jako wejścia do generowania kodu obiektowego”. Język wysokiego poziomu? Kompilator? Kod obiektowy? Ktoś, kto nie wie, czym jest język programowania, oczywiście nie wie, czym są te rzeczy.

Częścią tego, co musi robić oprogramowanie, jest wyjaśnianie samego siebie. Aby więc pisać dobre oprogramowanie, trzeba zrozumieć, jak mało użytkownicy rozumieją. Podejdą do oprogramowania bez przygotowania, i lepiej, żeby zrobiło to, co oni zgadują, że zrobi, bo nie będą czytać instrukcji. Najlepszym systemem, jaki kiedykolwiek widziałem pod tym względem, był oryginalny Macintosh w 1985 roku. Robił to, czego oprogramowanie prawie nigdy nie robi: po prostu działało. [6]

Kod źródłowy również powinien wyjaśniać sam siebie. Gdybym mógł sprawić, by ludzie zapamiętali tylko jeden cytat o programowaniu, byłby to ten na początku Structure and Interpretation of Computer Programs.

Programy powinny być pisane dla ludzi, aby je czytali, i tylko okazjonalnie dla maszyn, aby je wykonywały.

Musisz mieć empatię nie tylko dla swoich użytkowników, ale także dla swoich czytelników. To leży w twoim interesie, ponieważ sam będziesz jednym z nich. Wielu hakerów napisało program, tylko po to, by po powrocie do niego sześć miesięcy później stwierdzić, że nie mają pojęcia, jak działa. Znam kilka osób, które po takich doświadczeniach zrezygnowały z Perla. [7]

Brak empatii jest kojarzony z inteligencją, do tego stopnia, że w niektórych miejscach jest nawet pewna moda na nią. Ale nie sądzę, żeby istniała jakakolwiek korelacja. Można odnieść sukces w matematyce i naukach przyrodniczych bez konieczności uczenia się empatii, a ludzie w tych dziedzinach zazwyczaj są inteligentni, więc te dwie cechy zaczęły być kojarzone. Ale jest też wielu głupich ludzi, którzy są słabi w empatii. Wystarczy posłuchać ludzi, którzy dzwonią z pytaniami do programów radiowych. Zadają swoje pytania w tak okrężny sposób, że prowadzący często muszą przeformułować pytanie za nich.

Skoro hacking działa jak malarstwo i pisanie, czy jest równie fajny? W końcu masz tylko jedno życie. Lepiej spędzić je na pracy nad czymś wielkim.

Niestety, na pytanie to trudno odpowiedzieć. Zawsze istnieje duże opóźnienie w prestiżu. To jak światło z odległej gwiazdy. Malarstwo ma teraz prestiż dzięki wielkim dziełom, które ludzie stworzyli pięćset lat temu. W tamtym czasie nikt nie uważał tych obrazów za tak ważne, jak my dzisiaj. Ludziom tamtych czasów wydawałoby się bardzo dziwne, że Federico da Montefeltro, książę Urbino, pewnego dnia będzie znany głównie jako facet ze dziwnym nosem na obrazie Piero della Francesca.

Więc chociaż przyznaję, że hacking nie wydaje się teraz tak fajny jak malarstwo, powinniśmy pamiętać, że samo malarstwo nie wydawało się tak fajne w swoich dniach chwały, jak teraz.

Możemy z pewnym przekonaniem powiedzieć, że są to dni chwały hackingu. W większości dziedzin wielkie dzieła powstają na samym początku. Obrazy z lat 1430-1500 są nadal niezrównane. Szekspir pojawił się właśnie wtedy, gdy rodził się teatr zawodowy, i tak pchnął medium naprzód, że każdy dramatopisarz od tego czasu musiał żyć w jego cieniu. Albrecht Dürer zrobił to samo z grawerstwem, a Jane Austen z powieścią.

Raz po raz widzimy ten sam wzór. Pojawia się nowe medium, a ludzie są nim tak podekscytowani, że eksplorują większość jego możliwości w pierwszych kilku pokoleniach. Hacking wydaje się być w tej fazie teraz.

Malarstwo w czasach Leonarda nie było tak fajne, jak pomogło mu to uczynić jego dzieło. Jak fajny okaże się hacking, zależy od tego, co będziemy mogli zrobić z tym nowym medium.

Przypisy

[1] Największe szkody, jakie fotografia wyrządziła malarstwu, to prawdopodobnie fakt, że zabiła najlepszą pracę codzienną. Większość wielkich malarzy w historii utrzymywała się z malowania portretów.

[2] Powiedziano mi, że Microsoft zniechęca pracowników do wkładu w projekty open-source, nawet w wolnym czasie. Ale tak wielu najlepszych hakerów pracuje teraz nad projektami open-source, że głównym skutkiem tej polityki może być zapewnienie, że nie będą w stanie zatrudnić żadnych pierwszorzędnych programistów.

[3] To, czego uczysz się o programowaniu na studiach, jest bardzo podobne do tego, czego uczysz się o książkach, ubraniach czy randkowaniu: jak zły gust miałeś w liceum.

[4] Oto przykład zastosowanej empatii. W Viaweb, jeśli nie mogliśmy zdecydować się między dwiema alternatywami, pytaliśmy: czego najbardziej nienawidziliby nasi konkurenci? W pewnym momencie konkurent dodał do swojego oprogramowania funkcję, która była zasadniczo bezużyteczna, ale ponieważ była jedną z niewielu, których nie mieliśmy, dużo o niej mówili w prasie branżowej. Moglibyśmy próbować wyjaśnić, że funkcja była bezużyteczna, ale zdecydowaliśmy, że bardziej zirytuje to naszego konkurenta, jeśli sami ją zaimplementujemy, więc tego samego popołudnia stworzyliśmy własną wersję.

[5] Z wyjątkiem edytorów tekstu i kompilatorów. Hakerzy nie potrzebują empatii, aby je projektować, ponieważ sami są typowymi użytkownikami.

[6] Cóż, prawie. Przekroczyli dostępną pamięć RAM, powodując wiele niewygodnych wymian na dysku, ale można to było naprawić w ciągu kilku miesięcy, kupując dodatkowy dysk.

[7] Sposobem na uczynienie programów łatwymi do czytania nie jest zapychać ich komentarzami. Poszedłbym o krok dalej niż cytat Abelsona i Sussmana. Języki programowania powinny być projektowane do wyrażania algorytmów, a tylko okazjonalnie do informowania komputerów, jak je wykonywać. Dobry język programowania powinien być lepszy do wyjaśniania oprogramowania niż angielski. Komentarze powinny być potrzebne tylko wtedy, gdy istnieje jakiś rodzaj obejścia, o którym trzeba ostrzec czytelników, tak jak na drodze strzałki znajdują się tylko na odcinkach z nieoczekiwanie ostrymi zakrętami.

Dzięki Trevorowi Blackwellowi, Robertowi Morrisowi, Danowi Giffinowi i Lisie Randall za przeczytanie wersji roboczych tego tekstu, a Henry'emu Leitnerowi i Larry'emu Finkelsteinowi za zaproszenie mnie do wystąpienia.