Ruch i Ogień

Oryginalny post: Fire and Motion

Autor: Joel Spolsky

Czasami po prostu nic nie mogę zrobić.

Jasne, przychodzę do biura, krzątam się, sprawdzam pocztę co dziesięć sekund, czytam artykuły w sieci, czy nawet robię coś tak bezmyślnego, jak płacenie rachunku American Express. Powrót do rytmu w pisaniu kodu jednak się po prostu nie zdarza.

Tetris Te ataki nieproduktywności trwają zwykle dzień lub dwa. Bywało jednak i tak w mojej karierze dewelopera, że tygodniami nie byłem w stanie zrobić kompletnie nic. Jak to mówią, nie jestem w rytmie. W strefie czasowej. Gdziekolwiek.

Każdemu zdarzają się wahania nastrojów; dla niektórych ludzi są one delikatne, dla innych istotniejsze lub nawet paraliżujące. I wygląda na to, że okresy nieproduktywności są jakoś skorelowane z chwilami przygnębienia.

Zmusza mnie to do myślenia nad tymi naukowcami, którzy twierdzą, że ludzie nie mogą kontrolować tego, co jedzą. Wtedy każda próba przejścia na dietę jest skazana na bycie krótkoterminową, a ludzie, którzy próbują ją stosować, wracają do swojej naturalnej wagi. Może jako twórca oprogramowania nie jestem w stanie kontrolować, kiedy jestem produktywny, i po prostu muszę przeżywać moje słabsze i mocniejsze chwile i mieć nadzieję na to, że uśrednią się one do liczby linii kodu wystarczającej na to, żeby opłacało się mnie zatrudnić.

 

 
Poczytaj The Onion przez chwilę.
 
 

To, co doprowadza mnie do szaleństwa to fakt, że odkąd tylko zacząłem swoją pierwszą pracę, uświadomiłem sobie, że jako programista średnio spędzam dwie lub trzy godziny dziennie na produktywne kodowanie. Kiedy byłem na letnich praktykach w Microsoft, kolega praktykant powiedział mi, że w rzeczywistości on przychodził do pracy od 12 do 17 każdego dnia. Pięć godzin, odjąć lunch, a jego zespół go uwielbiał, jako że był w stanie zrobić o wiele więcej niż średnia. Okazało się, że dla mnie to też działa. Czuję się odrobinę winny gdy widzę, jak ciężko pracują inni; miałem 2 lub 3 godziny pracy wysokiej jakości w ciągu dnia, a wciąż byłem jednym z najbardziej produktywnych członków zespołu. To jest prawdopodobnie powód, dla którego Peopleware i XP nalegają na pozbycie się nadgodzin i pracę dokładnie 40 godzin w tygodniu - robią tak wiedząc, że nie zmniejszy to wydajności zespołu.

Ale to nie te dni, w ciągu których "tylko" dwie godziny dziennie są efektywne, martwią mnie. Martwią mnie dni, kiedy nie mogę zrobić nic.

Dużo nad tym myślałem. Próbowałem zapamiętać momenty, w których zrobiłem najwięcej w swojej karierze. To prawdopodobnie wtedy, gdy Microsoft przeniósł mnie do pięknego, luksusowego biura z wielkimi oknami wychodzącymi na piękne, kamienne podwórze pełne kwitnących drzewek wiśniowych. Wszystko grało. Miesiącami pracowałem non-stop płodząc szczegółową specyfikację dla Excel Basic - ogromną stertę papieru zawierającą szczegóły gigantycznego modelu obiektowego i środowiska programistycznego. Dosłownie nigdy nie przestawałem. Gdy jechałem do Bostonu na MacWorld, zabierałem ze sobą laptopa i dokumentowałem klasę Okno siedząc na przyjemnym tarasie w HBS.

Jak już raz złapiesz rytm, to dalej łatwo jest go utrzymać. Wiele z moich dni wygląda tak: (1) przyjście do pracy (2) poczta, prasówka, itp. (3) podjęcie decyzji, że równie dobrze mogę zjeść lunch zanim zajmę się pracą (4) powrót z lunchu (5) poczta, prasówka, itp. (6) zdecydowanie się w końcu, że należy zacząć coś robić (7) poczta, prasówka, itp. (8) zdecydowanie się jeszcze raz, że należy zacząć coś robić (9) uruchomienie tego cholernego edytora (10) pisanie kodu non-stop aż uświadomię sobie, że jest 19:30.

Gdzieś między krokiem 8 i 9 jest jakiś problem, bo nie zawsze udaje mi się przeskoczyć tę przepaść. bike trip Dla mnie zwykłe rozpoczęcie pracy jest tą jedyną trudną rzeczą. Obiekt w spoczynku pozostaje w spoczynku. Jest coś niesamowicie ciężkiego w moim mózgu, coś niesamowicie trudnego do poruszenia, ale jak już tylko się zacznie poruszać z pełną prędkością, pozostaje w ruchu bez żadnego wysiłku. To jak z rowerem, którym masz wyjechać na samodzielną wycieczkę - gdy tylko zaczniesz jechać na tym rowerze, trudno uwierzyć, jak ciężko go zmusić do poruszania się, ale jak tylko się uda - wydaje się być zupełnie łatwym go prowadzić.

Być może to jest właśnie klucz do produktywności: po prostu zacząć. Być może gdy  programowanie w parach działa, to działa dlatego, że zostało umówione z Twoim kolegą, zmuszając was obu do zaczęcia pracy.

Joel in the Army

Gdy byłem izraelskim spadochroniarzem generał zatrzymał się przy nas by wygłosić małą mowę na temat strategii. W walkach piechoty, powiedział, jest tylko jedna strategia: Ogień i Ruch. Poruszać się w kierunku przeciwnika, strzelając ze swojej broni. Ogień zmusza go do schowania się i uniemożliwia strzelanie do Ciebie. (To właśnie żołnierze mają na myśli, gdy mówią: "osłaniaj mnie". Oznacza to "strzelaj do naszego wroga tak, żeby musiał się czołgać i nie mógł strzelać do mnie w czasie, gdy będę przebiegał przez tę ulicę, tu." Działa.) Ruch pozwala Ci zdobywać terytorium i zbliżyć się do wroga na odległość pozwalającą Ci łatwiej trafić w cel. Jeśli się nie poruszasz, wróg zaczyna decydować co się wydarzy, a to nie za dobrze. Jeśli nie strzelasz, to wróg zacznie strzelać, przyszpilając Cię tam, gdzie jesteś.

Pamiętałem to przez długi czas. Zauważyłem, że niemalże każda ze strategii wojskowych, od walk powietrznych do wielkoskalowych manewrów morskich, opiera się na idei Ognia i Ruchu. Zajęło mi kolejne 15 lat uświadomienie sobie, że zasada Ognia i Ruchu to sposób, w jaki załatwiasz sprawy w życiu. Musisz poruszać się do przodu, każdego dnia. Nie ma znaczenia, że Twój kod jest kulawy, pełen błędów i nikt go nie chce. Jeśli poruszasz się do przodu, pisząc kod i poprawiając błędy, czas jest po Twojej stronie. Uważaj, gdy Twoja konkurencja strzela do Ciebie. Czy chcą po prostu zmusić Cię do reagowania na ich salwy, byś nie mógł się poruszać do przodu?

Pomyśl o historii strategii dostępu do danych oferowanych przez Microsoft. ODBC, RDO, DAO, ADO, OLEDB, teraz ADO.NET - Wszystko Nowe! Czy są to technologiczne imperatywy? Wynik pracy niekompetentnej grupy projektantów, którzy muszą wymyślać od nowa sposób dostępu do danych każdego roku? (W rzeczywistości to prawdopodobnie to.) Wynikiem końcowym jest jednak ogień osłoniający. Konkurencja nie ma innego wyjścia, jak tylko portować i nadążać ze zmianami; czas ten mogliby spędzić na pisaniu nowych atrakcji. Spójrz bliżej na krajobraz świata oprogramowania. Firmy, które radzą sobie dobrze to te, które najmniej zależą od dużych firm i nie muszą tracić swojego czasu na aktualizacje, czy wprowadzanie poprawek do błędów, które pojawiają się tylko na Windows XP. Firmy, które potykają się to te, które spędzają zbyt dużo czasu na wróżeniu z fusów w która stronę pójdzie Microsoft w przyszłości. Ludzie martwią się .NETem i decydują się przepisać całą architekturę pod .NET myśląc, że muszą. Microsoft strzela do Ciebie, a to tylko ogień osłaniający - po to, żeby oni mogli pójść do przodu, a Ty nie, bo tak właśnie gra się w tą grę, Józek. Czy zamierzasz wspierać Hailstorm? SOAP? RDF? Wspierasz to ponieważ Twoi klienci tego potrzebują, czy dlatego że ktoś do Ciebie strzela, a Ty czujesz, że musisz odpowiedzieć? Zespoły ds. sprzedaży w dużych firmach rozumieją ogień osłaniający. Idą do swoich klientów i mówią: "OK, nie musisz od nas kupować. Możesz kupić od najlepszego dostawcy. Upewnij się jednak, że dostaniesz produkt wspierający (XML/SOPA/CDE/J2EE), gdyż w przeciwnym przypadku sam Zamknięsz się w Bagażniku". Gdy wtedy małe firmy próbują sprzedać swój produkt w to miejsce, wszystko co słyszą to posłusznych CTO papugujących "Czy macie J2EE?". I marnują cały swój czas na dostosowanie do J2EE nawet jeśli to nie powoduje wzrostu sprzedaży, i nie daje im możliwości odróżnienia się od a siebie samych. To cecha z ptaszkiem - robisz to, ponieważ ptaszek mówi, że to masz, ale nikt nie będzie z tego korzystał czy tego potrzebuje. To jest ogień osłaniający.

Ogień i Ruch, dla małych firm jak moja, oznacza dwie rzeczy. Musisz mieć czas po swojej stronie i musisz poruszać się do przodu każdego dnia. Wcześniej czy później, wygrasz. Wszystko, co zrobiłem wczoraj, to drobna poprawka schematu kolorów w FogBUGZ. To jest OK. Jest coraz lepiej, cały czas. Każdego dnia nasze oprogramowania jest coraz lepsze, a my mamy więcej klientów - i tylko to się liczy. Póki nie jesteśmy firmą rozmiaru Oracle, nie musimy zastanawiać się nad wielkimi strategiami. Musimy po prostu przychodzić co dzień do pracy i jakoś włączyć edytor.

 
Jest coraz lepiej...

Data publikacji oryginału: styczeń 6, 2002

3 komentarze:

Artur pisze...

Świetny artykuł. Mam dokładnie to samo. Ciężko zacząć ale gdy już się to zrobi to jakoś w transie programuje.

Anonimowy pisze...

Dokładnie, no i ta satysfakcja kiedy się już coś skończy... też bardzo pomaga:).

Anonimowy pisze...

Rewelacyjny artykuł, idealnie pasuje do mojej obecnej sytuacji:) a już myślałem, że ze mną coś nie tak:P

Prześlij komentarz

Related Posts with Thumbnails