Wielcy Hakerzy | undefined | Eseje Paula Grahama

Chcesz założyć startup? Zdobądź finansowanie od Y Combinator.

Lipiec 2004

(Ten esej pochodzi z wykładu na Oscon 2004.)

A kilka miesięcy temu ukończyłem nową książkę, a w recenzjach ciągle pojawiają się słowa takie jak „prowokująca” i „kontrowersyjna”. Nie wspominając już o „idiotyczna”.

Nie miałem zamiaru uczynić książki kontrowersyjną. Starałem się uczynić ją efektywną. Nie chciałem marnować czasu ludzi, mówiąc im rzeczy, które już wiedzieli. Jest bardziej efektywne po prostu podać im różnice. Ale przypuszczam, że to musi prowadzić do alarmującej książki.

Edisoni

Nie ma kontrowersji co do tego, która idea jest najbardziej kontrowersyjna: sugestia, że różnica w bogactwie może nie być tak dużym problemem, jak nam się wydaje.

Nie napisałem w książce, że różnica w bogactwie jest sama w sobie dobrą rzeczą. Napisałem, że w niektórych sytuacjach może być oznaką dobrych rzeczy. Pulsujący ból głowy nie jest dobrą rzeczą, ale może być oznaką dobrej rzeczy – na przykład tego, że odzyskujesz przytomność po uderzeniu w głowę.

Różnica w bogactwie może być oznaką różnicy w produktywności. (W społeczeństwie składającym się z jednej osoby są one identyczne.) A to jest prawie na pewno dobra rzecz: jeśli twoje społeczeństwo nie ma różnic w produktywności, to prawdopodobnie nie dlatego, że wszyscy są Thomasem Edisonem. Prawdopodobnie dlatego, że nie masz żadnych Thomasów Edisonów.

W społeczeństwie nisko technologicznie nie widać dużej różnicy w produktywności. Jeśli masz plemię nomadów zbierających patyki na ognisko, o ile bardziej produktywny będzie najlepszy zbieracz patyków od najgorszego? Dwa razy? Natomiast gdy dajesz ludziom skomplikowane narzędzie, takie jak komputer, różnica w tym, co mogą z nim zrobić, jest ogromna.

To nie jest nowa idea. Fred Brooks pisał o tym w 1974 roku, a badanie, które cytował, zostało opublikowane w 1968 roku. Ale myślę, że nie docenił różnicy między programistami. Pisał o produktywności w liniach kodu: najlepsi programiści potrafią rozwiązać dany problem w dziesięciokrotnie krótszym czasie. Ale co, jeśli problem nie jest dany? W programowaniu, podobnie jak w wielu dziedzinach, najtrudniejsza jest nie rozwiązywanie problemów, ale decydowanie, jakie problemy rozwiązać. Wyobraźnię trudno zmierzyć, ale w praktyce dominuje ona nad rodzajem produktywności mierzonej w liniach kodu.

Produktywność różni się w każdej dziedzinie, ale jest niewiele takich, w których różni się tak bardzo. Różnica między programistami jest tak duża, że staje się różnicą w rodzaju. Nie sądzę jednak, aby było to coś wewnętrznego dla programowania. W każdej dziedzinie technologia potęguje różnice w produktywności. Myślę, że to, co dzieje się w programowaniu, to po prostu to, że mamy dużą dźwignię technologiczną. Ale w każdej dziedzinie dźwignia staje się dłuższa, więc różnica, którą widzimy, jest czymś, czego coraz więcej dziedzin będzie doświadczać w miarę upływu czasu. A sukces firm i krajów będzie coraz bardziej zależał od tego, jak sobie z nią poradzą.

Jeśli różnica w produktywności wzrasta wraz z technologią, to wkład najbardziej produktywnych jednostek będzie nie tylko nieproporcjonalnie duży, ale faktycznie będzie rósł w czasie. Kiedy osiągniesz punkt, w którym 90% produkcji grupy jest tworzone przez 1% jej członków, dużo tracisz, jeśli coś (czy to najazdy Wikingów, czy centralne planowanie) obniży ich produktywność do średniej.

Jeśli chcemy w pełni wykorzystać ich potencjał, musimy zrozumieć tych szczególnie produktywnych ludzi. Co ich motywuje? Czego potrzebują, aby wykonywać swoją pracę? Jak ich rozpoznać? Jak ich do siebie ściągnąć? A potem, oczywiście, pojawia się pytanie, jak samemu się takim stać?

Więcej niż pieniądze

Znam garstkę super-hakerów, więc usiadłem i zastanowiłem się, co ich łączy. Ich cechą definiującą jest prawdopodobnie to, że naprawdę kochają programować. Zwykli programiści piszą kod, żeby zarobić na życie. Wielcy hakerzy uważają to za coś, co robią dla zabawy, i są zachwyceni, że ludzie chcą im za to płacić.

Czasami mówi się, że wielcy programiści są obojętni na pieniądze. To nie do końca prawda. Prawdą jest, że jedyne, na czym naprawdę im zależy, to robienie interesujących rzeczy. Ale jeśli zarobisz wystarczająco dużo pieniędzy, możesz pracować nad czymkolwiek chcesz, i z tego powodu hakerzy są przyciągani przez ideę zarabiania naprawdę dużych pieniędzy. Ale dopóki muszą codziennie przychodzić do pracy, bardziej zależy im na tym, co tam robią, niż na tym, ile za to dostają.

Ekonomicznie jest to fakt o największym znaczeniu, ponieważ oznacza to, że nie musisz płacić wielkim hakerom nawet zbliżonej kwoty do tego, ile są warci. Wielki programista może być dziesięć lub sto razy bardziej produktywny niż zwykły, ale będzie uważał się za szczęściarza, jeśli dostanie zapłatę trzy razy wyższą. Jak wyjaśnię później, jest to częściowo dlatego, że wielcy hakerzy nie wiedzą, jak dobrzy są. Ale także dlatego, że pieniądze nie są tym, czego pragną najbardziej.

Czego pragną hakerzy? Jak wszyscy rzemieślnicy, hakerzy lubią dobre narzędzia. Właściwie to niedopowiedzenie. Dobrzy hakerzy uważają za nie do zniesienia używanie złych narzędzi. Po prostu odmówią pracy nad projektami z niewłaściwą infrastrukturą.

W startupie, dla którego kiedyś pracowałem, jedną z rzeczy przypiętych do naszej tablicy ogłoszeń było ogłoszenie od IBM. Było to zdjęcie AS400, a nagłówek brzmiał, o ile pamiętam, „hakerzy nim gardzą”. [1]

Kiedy decydujesz, jakiej infrastruktury użyć do projektu, nie podejmujesz tylko decyzji technicznej. Podejmujesz również decyzję społeczną, a ta może być ważniejsza z tych dwóch. Na przykład, jeśli twoja firma chce napisać jakieś oprogramowanie, rozsądnym wyborem może być napisanie go w Javie. Ale kiedy wybierasz język, wybierasz również społeczność. Programiści, których będziesz w stanie zatrudnić do pracy nad projektem w Javie, nie będą tak zdolni jak ci, których mógłbyś zdobyć do pracy nad projektem napisanym w Pythonie. A jakość twoich hakerów prawdopodobnie ma większe znaczenie niż wybrany język. Chociaż szczerze mówiąc, fakt, że dobrzy hakerzy wolą Pythona od Javy, powinien coś powiedzieć o względnych zaletach tych języków.

Ludzie biznesu preferują najpopularniejsze języki, ponieważ postrzegają języki jako standardy. Nie chcą ryzykować firmą na Betamax. Rzecz w językach jednak polega na tym, że nie są one tylko standardami. Jeśli musisz przesyłać bity przez sieć, używaj śmiało TCP/IP. Ale język programowania to nie tylko format. Język programowania to medium ekspresji.

Czytałem, że Java właśnie wyprzedziła Cobol jako najpopularniejszy język. Jako standard, nie można sobie życzyć więcej. Ale jako medium ekspresji, można by zrobić znacznie lepiej. Spośród wszystkich wielkich programistów, których znam, znam tylko jednego, który dobrowolnie programowałby w Javie. A spośród wszystkich wielkich programistów, których znam, a którzy nie pracują dla Sun, nad Javą, nie znam ani jednego.

Wielcy hakerzy generalnie nalegają również na używanie oprogramowania open source. Nie tylko dlatego, że jest lepsze, ale dlatego, że daje im to większą kontrolę. Dobrzy hakerzy nalegają na kontrolę. To część tego, co czyni ich dobrymi hakerami: kiedy coś jest zepsute, muszą to naprawić. Chcesz, żeby tak samo czuli się w stosunku do oprogramowania, które dla ciebie piszą. Nie powinieneś się dziwić, gdy czują to samo w stosunku do systemu operacyjnego.

Kilka lat temu znajomy inwestor venture capital opowiedział mi o nowym startupie, w który był zaangażowany. Brzmiało obiecująco. Ale następnym razem, gdy z nim rozmawiałem, powiedział, że zdecydowali się zbudować swoje oprogramowanie na Windows NT i właśnie zatrudnili bardzo doświadczonego dewelopera NT na stanowisko głównego dyrektora technicznego. Kiedy to usłyszałem, pomyślałem, ci ludzie są zgubieni. Po pierwsze, CTO nie mógł być hakerem pierwszej klasy, ponieważ aby zostać wybitnym deweloperem NT, musiałby dobrowolnie używać NT wielokrotnie, a ja nie mogłem sobie wyobrazić, żeby wielki haker to zrobił; po drugie, nawet jeśli był dobry, miałby trudności z zatrudnieniem kogoś dobrego do pracy dla niego, gdyby projekt musiał być zbudowany na NT. [2]

Ostatnia granica

Po oprogramowaniu, najważniejszym narzędziem dla hakera jest prawdopodobnie jego biuro. Duże firmy uważają, że funkcją przestrzeni biurowej jest wyrażanie rangi. Ale hakerzy używają swoich biur do czegoś więcej: używają ich jako miejsca do myślenia. A jeśli jesteś firmą technologiczną, ich myśli są twoim produktem. Więc sprawianie, że hakerzy pracują w hałaśliwym, rozpraszającym środowisku, jest jak posiadanie fabryki farb, w której powietrze jest pełne sadzy.

Pasek komiksowy Dilbert ma wiele do powiedzenia o kabinach, i to z dobrych powodów. Wszyscy hakerzy, których znam, nimi gardzą. Sama groźba przerwania może powstrzymać hakerów przed pracą nad trudnymi problemami. Jeśli chcesz wykonać prawdziwą pracę w biurze z kabinami, masz dwie opcje: pracować w domu, albo przychodzić wcześniej lub później, lub w weekend, kiedy nikogo innego nie ma. Czy firmy nie zdają sobie sprawy, że to znak, że coś jest nie tak? Środowisko biurowe powinno być czymś, co pomaga ci pracować, a nie czymś, wbrew czemu pracujesz.

Firmy takie jak Cisco są dumne z tego, że wszyscy tam mają kabiny, nawet CEO. Ale nie są tak zaawansowane, jak myślą; oczywiście nadal postrzegają przestrzeń biurową jako odznakę rangi. Zauważ też, że Cisco słynie z tego, że bardzo mało rozwoju produktu wykonuje we własnym zakresie. Nową technologię zdobywają, kupując startupy, które ją stworzyły – gdzie przypuszczalnie hakerzy mieli gdzieś cicho pracować.

Jedna duża firma, która rozumie, czego potrzebują hakerzy, to Microsoft. Kiedyś widziałem reklamę rekrutacyjną Microsoftu z dużym zdjęciem drzwi. Pracuj dla nas, głosiła przesłanka, a damy ci miejsce do pracy, w którym faktycznie możesz wykonać pracę. I wiecie, Microsoft jest niezwykły wśród dużych firm pod tym względem, że są w stanie rozwijać oprogramowanie we własnym zakresie. Może nie dobrze, ale wystarczająco dobrze.

Jeśli firmy chcą, aby hakerzy byli produktywni, powinny przyjrzeć się temu, co robią w domu. W domu hakerzy mogą sami wszystko zorganizować, aby osiągnąć jak najwięcej. A kiedy pracują w domu, hakerzy nie pracują w hałaśliwych, otwartych przestrzeniach; pracują w pokojach z drzwiami. Pracują w przytulnych, sąsiedzkich miejscach z ludźmi wokół i gdzieś, gdzie można spacerować, kiedy trzeba coś przemyśleć, zamiast w szklanych pudełkach na akrach parkingów. Mają sofę, na której mogą się zdrzemnąć, gdy poczują się zmęczeni, zamiast siedzieć w letargu przy biurku, udając, że pracują. Nie ma ekipy ludzi z odkurzaczami, która ryczy co wieczór w godzinach szczytu hakowania. Nie ma spotkań ani, broń Boże, firmowych wyjazdów czy ćwiczeń integracyjnych. A kiedy spojrzysz na to, co robią na tym komputerze, zobaczysz, że potwierdza to, co powiedziałem wcześniej o narzędziach. Mogą musieć używać Javy i Windows w pracy, ale w domu, gdzie mogą sami wybierać, częściej znajdziesz ich używających Perla i Linuksa.

Rzeczywiście, te statystyki dotyczące Cobola lub Javy jako najpopularniejszego języka mogą być mylące. To, na co powinniśmy patrzeć, jeśli chcemy wiedzieć, jakie narzędzia są najlepsze, to to, co hakerzy wybierają, gdy mogą wybierać swobodnie – to znaczy, w swoich własnych projektach. Kiedy zadajesz to pytanie, okazuje się, że systemy operacyjne open source mają już dominujący udział w rynku, a językiem numer jeden jest prawdopodobnie Perl.

Ciekawe

Oprócz dobrych narzędzi, hakerzy pragną interesujących projektów. Co sprawia, że projekt jest interesujący? Cóż, oczywiście jawnie seksowne aplikacje, takie jak samoloty stealth czy oprogramowanie do efektów specjalnych, byłyby interesujące do pracy. Ale każda aplikacja może być interesująca, jeśli stawia nowe wyzwania techniczne. Trudno więc przewidzieć, jakie problemy polubią hakerzy, ponieważ niektóre stają się interesujące dopiero wtedy, gdy ludzie nad nimi pracujący odkryją nowy rodzaj rozwiązania. Przed ITA (którzy napisali oprogramowanie dla Orbitz), ludzie pracujący nad wyszukiwaniem cen biletów lotniczych prawdopodobnie uważali to za jedno z najbardziej nudnych zastosowań, jakie można sobie wyobrazić. Ale ITA uczyniło to interesującym, przez redefinicję problemu w bardziej ambitny sposób.

Myślę, że to samo stało się w Google. Kiedy powstało Google, konwencjonalna mądrość wśród tak zwanych portali była taka, że wyszukiwanie jest nudne i nieistotne. Ale ludzie z Google nie uważali wyszukiwania za nudne, i dlatego robią to tak dobrze.

To obszar, w którym menedżerowie mogą coś zmienić. Podobnie jak rodzic mówiący dziecku: „Założę się, że nie posprzątasz całego pokoju w dziesięć minut”, dobry menedżer może czasem zdefiniować problem na nowo jako bardziej interesujący. Steve Jobs wydaje się być w tym szczególnie dobry, po części po prostu przez wysokie wymagania. Było wiele małych, niedrogich komputerów przed Macem. On zdefiniował problem na nowo jako: stwórz piękny. I to prawdopodobnie napędzało deweloperów bardziej niż jakakolwiek marchewka czy kij.

Z pewnością dostarczyli. Kiedy pojawił się Mac, nie trzeba było go nawet włączać, żeby wiedzieć, że będzie dobry; można było to poznać po obudowie. Kilka tygodni temu szedłem ulicą w Cambridge i w czyichś śmieciach zobaczyłem coś, co wyglądało na futerał do Maca. Zajrzałem do środka i tam był Mac SE. Zaniosłem go do domu i podłączyłem, i się uruchomił. Uśmiechnięta twarz Macintosha, a potem finder. Mój Boże, to było takie proste. To było jak... Google.

Hakerzy lubią pracować dla ludzi z wysokimi wymaganiami. Ale nie wystarczy być wymagającym. Trzeba nalegać na właściwe rzeczy. Co zazwyczaj oznacza, że samemu trzeba być hakerem. Widziałem okazjonalne artykuły o tym, jak zarządzać programistami. Naprawdę powinny być dwa artykuły: jeden o tym, co robić, jeśli samemu jest się programistą, i jeden o tym, co robić, jeśli nim nie jest. A ten drugi prawdopodobnie można by streścić w dwóch słowach: poddać się.

Problem nie polega tyle na codziennym zarządzaniu. Naprawdę dobrzy hakerzy są praktycznie samowystarczalni. Problem w tym, że jeśli nie jesteś hakerem, nie potrafisz rozpoznać dobrych hakerów. Podobny problem wyjaśnia, dlaczego amerykańskie samochody są tak brzydkie. Nazywam to paradoksem projektowania. Można by pomyśleć, że można by uczynić swoje produkty pięknymi, po prostu zatrudniając świetnego projektanta do ich zaprojektowania. Ale jeśli sam nie masz dobrego gustu, jak rozpoznasz dobrego projektanta? Z definicji nie możesz tego stwierdzić na podstawie jego portfolio. I nie możesz kierować się nagrodami, które zdobył, ani pracami, które wykonywał, ponieważ w projektowaniu, podobnie jak w większości dziedzin, są one napędzane modą i schlebianiem, a rzeczywiste umiejętności są na trzecim miejscu. Nie ma na to rady: nie możesz zarządzać procesem mającym na celu produkcję pięknych rzeczy, nie wiedząc, co jest piękne. Amerykańskie samochody są brzydkie, ponieważ amerykańskimi firmami samochodowymi zarządzają ludzie o złym guście.

Wielu ludzi w tym kraju uważa gust za coś ulotnego, a nawet trywialnego. Nie jest ani jednym, ani drugim. Aby kierować projektowaniem, menedżer musi być najbardziej wymagającym użytkownikiem produktów firmy. A jeśli masz naprawdę dobry gust, możesz, tak jak Steve Jobs, uczynić zadowolenie ciebie rodzajem problemu, nad którym dobrzy ludzie lubią pracować.

Nieznośne małe problemy

Jest dość łatwo powiedzieć, jakie rodzaje problemów nie są interesujące: te, w których zamiast rozwiązywać kilka dużych, jasnych problemów, trzeba rozwiązać wiele nieznośnych małych. Jednym z najgorszych rodzajów projektów jest pisanie interfejsu do fragmentu oprogramowania, który jest pełen błędów. Innym jest sytuacja, gdy trzeba coś dostosować do złożonych i niejasno zdefiniowanych potrzeb indywidualnego klienta. Dla hakerów tego rodzaju projekty to śmierć przez tysiąc cięć.

Cechą charakterystyczną nieznośnych małych problemów jest to, że niczego się z nich nie uczy. Pisanie kompilatora jest interesujące, ponieważ uczy, czym jest kompilator. Ale pisanie interfejsu do wadliwego oprogramowania niczego nie uczy, ponieważ błędy są losowe. [3] Więc to nie tylko wybredność sprawia, że dobrzy hakerzy unikają nieznośnych małych problemów. To bardziej kwestia samozachowawczości. Praca nad nieznośnymi małymi problemami czyni cię głupim. Dobrzy hakerzy unikają tego z tego samego powodu, dla którego modelki unikają cheeseburgerów.

Oczywiście niektóre problemy mają z natury taki charakter. A ze względu na podaż i popyt, płacą za nie szczególnie dobrze. Więc firma, która znalazłaby sposób na skłonienie wielkich hakerów do pracy nad żmudnymi problemami, odniosłaby wielki sukces. Jak by to zrobili?

Jedno z miejsc, gdzie to się dzieje, to startupy. W naszym startupie Robert Morris pracował jako administrator systemu. To jak mieć Rolling Stones grających na bar micwie. Nie można zatrudnić takiego talentu. Ale ludzie wykonają każdą ilość harówki dla firm, których są założycielami. [4]

Większe firmy rozwiązują problem, dzieląc firmę. Przyciągają do siebie mądrych ludzi, tworząc oddzielny dział badawczo-rozwojowy, w którym pracownicy nie muszą pracować bezpośrednio nad nieznośnymi małymi problemami klientów. [5] W tym modelu dział badawczy funkcjonuje jak kopalnia. Produkują nowe pomysły; być może reszta firmy będzie mogła z nich skorzystać.

Może nie musisz iść na takie ekstrema. Programowanie od dołu sugeruje inny sposób podziału firmy: niech mądrzy ludzie pracują jako twórcy narzędzi. Jeśli twoja firma tworzy oprogramowanie do robienia x, niech jedna grupa tworzy narzędzia do pisania oprogramowania tego typu, a druga używa tych narzędzi do pisania aplikacji. W ten sposób możesz być w stanie skłonić mądrych ludzi do napisania 99% twojego kodu, ale nadal trzymać ich prawie tak samo odizolowanych od użytkowników, jak byliby w tradycyjnym dziale badawczym. Twórcy narzędzi mieliby użytkowników, ale byliby to tylko własni deweloperzy firmy. [6]

Gdyby Microsoft zastosował to podejście, ich oprogramowanie nie byłoby tak pełne luk bezpieczeństwa, ponieważ mniej inteligentni ludzie piszący faktyczne aplikacje nie zajmowaliby się niskopoziomowymi rzeczami, takimi jak alokacja pamięci. Zamiast pisać Worda bezpośrednio w C, składaliby duże klocki Lego języka Word. (Duplo, jak sądzę, to termin techniczny).

Grupowanie się

Oprócz interesujących problemów, dobrzy hakerzy lubią innych dobrych hakerów. Wielcy hakerzy mają tendencję do grupowania się – czasami spektakularnie, jak w Xerox Parc. Więc nie przyciągniesz dobrych hakerów w proporcji liniowej do tego, jak dobre środowisko dla nich stworzysz. Tendencja do grupowania się oznacza, że jest to bardziej jak kwadrat środowiska. Więc wygrywa ten, kto bierze wszystko. W danym momencie jest tylko około dziesięciu lub dwudziestu miejsc, w których hakerzy najbardziej chcą pracować, a jeśli nie jesteś jednym z nich, nie będziesz miał tylko mniej wielkich hakerów, będziesz miał zero.

Posiadanie wielkich hakerów samo w sobie nie wystarczy, aby firma odniosła sukces. Dobrze działa dla Google i ITA, które są obecnie dwoma gorącymi miejscami, ale nie pomogło to Thinking Machines ani Xerox. Sun przez jakiś czas dobrze sobie radził, ale ich model biznesowy to winda w dół. W takiej sytuacji nawet najlepsi hakerzy nie mogą cię uratować.

Myślę jednak, że przy równych pozostałych warunkach, firma, która potrafi przyciągnąć wielkich hakerów, będzie miała ogromną przewagę. Są ludzie, którzy by się z tym nie zgodzili. Kiedy w latach 90. odwiedzaliśmy firmy venture capital, kilka z nich powiedziało nam, że firmy programistyczne wygrywają nie dzięki pisaniu świetnego oprogramowania, ale dzięki marce, dominacji w kanałach dystrybucji i zawieraniu właściwych umów.

Naprawdę wydawali się w to wierzyć, i myślę, że wiem dlaczego. Myślę, że wielu VC szuka, przynajmniej nieświadomie, następnego Microsoftu. I oczywiście, jeśli Microsoft jest twoim modelem, nie powinieneś szukać firm, które mają nadzieję wygrać, pisząc świetne oprogramowanie. Ale VC mylą się, szukając następnego Microsoftu, ponieważ żaden startup nie może być następnym Microsoftem, chyba że inna firma jest gotowa ugiąć się w odpowiednim momencie i być następnym IBM.

Błędem jest używanie Microsoftu jako modelu, ponieważ cała ich kultura wywodzi się z tego jednego szczęśliwego przełomu. Microsoft to zły punkt danych. Jeśli ich wyrzucimy, okaże się, że dobre produkty faktycznie wygrywają na rynku. VC powinni szukać następnego Apple lub następnego Google.

Myślę, że Bill Gates o tym wie. To, co go martwi w Google, to nie siła ich marki, ale fakt, że mają lepszych hakerów. [7]

Rozpoznanie

Kim więc są wielcy hakerzy? Skąd wiesz, kiedy ich spotkasz? Okazuje się, że to bardzo trudne. Nawet hakerzy nie potrafią tego powiedzieć. Jestem teraz całkiem pewien, że mój przyjaciel Trevor Blackwell jest wielkim hakerem. Być może czytałeś na Slashdot, jak zrobił swój własny Segway. Niezwykłe w tym projekcie było to, że napisał całe oprogramowanie w jeden dzień (nawiasem mówiąc, w Pythonie).

Dla Trevora to norma. Ale kiedy pierwszy raz go spotkałem, uważałem go za kompletnego idiotę. Stał w biurze Roberta Morrisa, mamrocząc do niego o czymś, i pamiętam, jak stałem za nim, robiąc Robertowi gorączkowe gesty, żeby pozbył się tego szaleńca z biura, żebyśmy mogli pójść na lunch. Robert mówi, że też początkowo źle ocenił Trevora. Podobno, kiedy Robert pierwszy raz go spotkał, Trevor właśnie rozpoczął nowy projekt, który polegał na zapisywaniu wszystkiego o każdym aspekcie swojego życia na stosie kart indeksowych, które nosił wszędzie ze sobą. Przyjechał też właśnie z Kanady, miał silny kanadyjski akcent i fryzurę typu mullet.

Problem potęguje fakt, że hakerzy, pomimo reputacji społecznie nieświadomych, czasami wkładają sporo wysiłku w to, by wydawać się mądrymi. Kiedy byłem na studiach podyplomowych, czasami kręciłem się po MIT AI Lab. Na początku było to trochę onieśmielające. Wszyscy tam mówili tak szybko. Ale po jakimś czasie nauczyłem się sztuczki szybkiego mówienia. Nie trzeba myśleć szybciej; wystarczy użyć dwa razy więcej słów, żeby wszystko powiedzieć.

Przy takiej ilości szumu w sygnale trudno jest rozpoznać dobrych hakerów, gdy się ich spotyka. Nawet teraz nie potrafię tego powiedzieć. Nie można tego też wywnioskować z ich CV. Wydaje się, że jedynym sposobem oceny hakera jest praca z nim nad czymś.

I to jest powód, dla którego obszary high-tech powstają tylko wokół uniwersytetów. Aktywnym składnikiem nie są tu tyle profesorowie, co studenci. Startupy rozwijają się wokół uniwersytetów, ponieważ uniwersytety gromadzą obiecujących młodych ludzi i zmuszają ich do pracy nad tymi samymi projektami. Ci mądrzy uczą się, kim są inni mądrzy ludzie, i razem wymyślają nowe własne projekty.

Ponieważ nie można rozpoznać wielkiego hakera inaczej niż przez pracę z nim, sami hakerzy nie wiedzą, jak dobrzy są. To w pewnym stopniu prawda w większości dziedzin. Odkryłem, że ludzie, którzy są w czymś świetni, nie są tak bardzo przekonani o swojej wielkości, jak zaintrygowani tym, dlaczego wszyscy inni wydają się tak niekompetentni.

Ale hakerom jest szczególnie trudno wiedzieć, jak dobrzy są, ponieważ trudno porównać ich pracę. Jest to łatwiejsze w większości innych dziedzin. Na sto metrów w dziesięć sekund wiesz, kto jest najszybszy. Nawet w matematyce wydaje się istnieć ogólny konsensus co do tego, które problemy są trudne do rozwiązania i co stanowi dobre rozwiązanie. Ale hakowanie jest jak pisanie. Kto potrafi powiedzieć, które z dwóch powieści jest lepsze? Na pewno nie autorzy.

Przynajmniej w przypadku hakerów, inni hakerzy potrafią to powiedzieć. Dzieje się tak dlatego, że w przeciwieństwie do powieściopisarzy, hakerzy współpracują przy projektach. Kiedy możesz uderzyć w kilka trudnych problemów przez sieć na kogoś, szybko uczysz się, jak mocno oni uderzają z powrotem. Ale hakerzy nie mogą obserwować siebie przy pracy. Więc jeśli zapytasz wielkiego hakera, jak dobry jest, prawie na pewno odpowie: „Nie wiem”. On nie tylko jest skromny. On naprawdę nie wie.

A żaden z nas nie wie, z wyjątkiem osób, z którymi faktycznie pracowaliśmy. Co stawia nas w dziwnej sytuacji: nie wiemy, kim powinni być nasi bohaterowie. Hakerzy, którzy stają się sławni, stają się sławni dzięki przypadkowym wypadkom PR. Czasami muszę podać przykład wielkiego hakera i nigdy nie wiem, kogo użyć. Pierwsze nazwiska, które przychodzą mi na myśl, zawsze skłaniają się ku ludziom, których znam osobiście, ale wydaje się to słabe, żeby ich użyć. Więc myślę, może powinienem powiedzieć Richard Stallman, albo Linus Torvalds, albo Alan Kay, albo ktoś sławny. Ale nie mam pojęcia, czy ci faceci są wielkimi hakerami. Nigdy z nimi nad niczym nie pracowałem.

Jeśli istnieje Michael Jordan hakowania, nikt o tym nie wie, łącznie z nim.

Kultywacja

Na koniec pytanie, o którym wszyscy hakerzy się zastanawiali: jak zostać wielkim hakerem? Nie wiem, czy można się takim stać. Ale z pewnością można robić rzeczy, które czynią cię głupim, a jeśli możesz uczynić siebie głupim, prawdopodobnie możesz też uczynić siebie mądrym.

Kluczem do bycia dobrym hakerem może być praca nad tym, co lubisz. Kiedy myślę o wielkich hakerach, których znam, jedną z rzeczy, które ich łączą, jest ekstremalna trudność w zmuszeniu ich do pracy nad czymkolwiek, czego nie chcą. Nie wiem, czy to przyczyna, czy skutek; może być jedno i drugie.

Aby coś dobrze zrobić, trzeba to kochać. Więc w takim stopniu, w jakim możesz zachować hakowanie jako coś, co kochasz, prawdopodobnie będziesz to robić dobrze. Staraj się zachować poczucie cudu, jakie miałeś w programowaniu w wieku 14 lat. Jeśli martwisz się, że twoja obecna praca niszczy ci mózg, prawdopodobnie tak jest.

Najlepsi hakerzy zazwyczaj są mądrzy, oczywiście, ale to prawda w wielu dziedzinach. Czy istnieje jakaś cecha, która jest unikalna dla hakerów? Zapytałem kilku przyjaciół, a najczęściej wymienianą rzeczą była ciekawość. Zawsze zakładałem, że wszyscy mądrzy ludzie są ciekawi – że ciekawość jest po prostu pierwszą pochodną wiedzy. Ale najwyraźniej hakerzy są szczególnie ciekawi, zwłaszcza tego, jak rzeczy działają. To ma sens, ponieważ programy są w efekcie gigantycznymi opisami tego, jak rzeczy działają.

Kilku przyjaciół wspomniało o zdolności hakerów do koncentracji – ich zdolności, jak to ujął jeden z nich, do „wyłączania wszystkiego poza własnymi głowami”. Z pewnością to zauważyłem. I słyszałem, jak kilku hakerów mówiło, że po wypiciu nawet pół piwa nie potrafią w ogóle programować. Więc może hakowanie wymaga jakiejś szczególnej zdolności skupienia. Być może wielcy hakerzy potrafią załadować dużą ilość kontekstu do swojej głowy, tak że kiedy patrzą na linię kodu, widzą nie tylko tę linię, ale cały program wokół niej. John McPhee pisał, że sukces Billa Bradleya jako koszykarza wynikał częściowo z jego niezwykłej wizji peryferyjnej. „Idealne” widzenie oznacza około 47 stopni widzenia peryferyjnego w pionie. Bill Bradley miał 70; potrafił widzieć kosz, patrząc na podłogę. Być może wielcy hakerzy mają jakąś podobną wrodzoną zdolność. (Ja oszukuję, używając bardzo gęstego języka, który zmniejsza boisko).

To mogłoby wyjaśnić rozbieżność w kwestii kabin. Być może osoby odpowiedzialne za wyposażenie, nie mając niczego, co można by zburzyć, nie mają pojęcia, że praca w kabinie dla hakera jest jak posiadanie mózgu w blenderze. (Podczas gdy Bill, jeśli pogłoski o autyzmie są prawdziwe, wie to aż za dobrze).

Jedną z różnic, którą zauważyłem między wielkimi hakerami a mądrymi ludźmi w ogóle, jest to, że hakerzy są bardziej politycznie niepoprawni. W takim stopniu, w jakim istnieje tajny uścisk dłoni wśród dobrych hakerów, jest to, gdy znają się wystarczająco dobrze, aby wyrażać opinie, które publiczność publicznie by ich ukamienowała. I widzę, dlaczego niepoprawność polityczna byłaby użyteczną cechą w programowaniu. Programy są bardzo złożone i, przynajmniej w rękach dobrych programistów, bardzo płynne. W takich sytuacjach pomocne jest posiadanie nawyku kwestionowania założeń.

Czy możesz kultywować te cechy? Nie wiem. Ale możesz przynajmniej nie tłumić ich. Oto więc moja najlepsza próba przepisu. Jeśli można się stać wielkim hakerem, sposób może polegać na zawarciu z sobą następującej umowy: nigdy nie musisz pracować nad nudnymi projektami (chyba że twoja rodzina będzie głodować inaczej), a w zamian nigdy nie pozwolisz sobie na fuszerkę. Wszyscy wielcy hakerzy, których znam, wydają się zawrzeć tę umowę, chociaż być może żaden z nich nie miał wyboru.

Przypisy

[1] Będąc sprawiedliwym, muszę powiedzieć, że IBM produkuje przyzwoity sprzęt. Pisałem to na laptopie IBM.

[2] Okazało się, że byli zgubieni. Zamknęli firmę kilka miesięcy później.

[3] Myślę, że to właśnie ludzie mają na myśli, mówiąc o „sensie życia”. Na pierwszy rzut oka wydaje się to dziwnym pomysłem. Życie nie jest ekspresją; skąd miałoby mieć sens? Ale może mieć jakość, która przypomina sens. W projekcie takim jak kompilator trzeba rozwiązać wiele problemów, ale wszystkie problemy układają się w pewien wzór, jak w sygnale. Natomiast gdy problemy, które trzeba rozwiązać, są losowe, wydają się być szumem.

[4] Einstein w pewnym momencie pracował nad projektowaniem lodówek. (Miał udziały.)

[5] Trudno dokładnie powiedzieć, co stanowi badania w świecie komputerów, ale jako pierwsze przybliżenie, jest to oprogramowanie, które nie ma użytkowników.

Nie sądzę, aby publikacja była tym, co sprawia, że najlepsi hakerzy chcą pracować w działach badawczych. Myślę, że głównie chodzi o to, że nie muszą mieć trzygodzinnego spotkania z menedżerem produktu na temat problemów z integracją koreańskiej wersji Worda 13.27 z gadającym spinaczem.

[6] Coś podobnego dzieje się od dawna w branży budowlanej. Kiedy sto lat temu budowano dom, lokalni budowniczy budowali wszystko w nim. Ale coraz częściej budowniczy składają komponenty zaprojektowane i wyprodukowane przez kogoś innego. To, podobnie jak pojawienie się publikacji elektronicznych, dało ludziom swobodę eksperymentowania w katastrofalny sposób, ale jest to z pewnością bardziej efektywne.

[7] Google jest znacznie groźniejszy dla Microsoftu niż Netscape. Prawdopodobnie groźniejszy niż jakakolwiek firma kiedykolwiek była. Między innymi dlatego, że są zdeterminowani walczyć. Na swojej stronie z ofertami pracy mówią, że jedną z ich „podstawowych wartości” jest „Nie bądź zły”. Z firmy sprzedającej olej sojowy lub sprzęt górniczy takie stwierdzenie byłoby jedynie ekscentryczne. Ale myślę, że wszyscy w świecie komputerów rozpoznajemy, komu jest to deklaracja wojny.

Podziękowania dla Jessiki Livingston, Roberta Morrisa i Sary Harlin za przeczytanie wcześniejszych wersji tego wykładu.