Pierwsza zasada programowania: to zawsze Twoja wina

Oryginalny post: The First Rule of Programming: It's Always Your Fault

Autor: Jeff Atwood

Z pewnością znasz to uczucie. Każdemu z nas kiedyś przytrafiło się coś takiego: analizujesz kod od kilku godzin i wciąż nie możesz znaleźć błędu. Ale on tam jest, tylko jakoś nie możesz się go pozbyć. Myślisz sobie, że chyba jednak coś musi być nie tak z komputerem, na którym kodujesz, albo z systemem operacyjnym, albo z bibliotekami bądź narzędziami, których używasz. Coś musi być nie w porządku!

Choćbyś nie wiem jak bardzo był zdesperowany, nie podążaj tą ścieżką. Jedyne co możesz tam znaleźć to programowanie voodoo albo programowanie przez przypadek. W skrócie, szaleństwo.

Ciągłe walenie głową w mur, walka z trudnymi, dziwnymi bugami -- to może być frustrujące. Ale nie pozwól, by desperacja Cię zwiodła. Istotną częścią bycia skromnym programistą jest zdanie sobie sprawy z tego, że jeśli jest jakiś problem z kodem, który napisałeś, to jest to zawsze Twoja wina. Zasada ta została krótko podsumowana w książce Pragmatyczny Programista i ochrzczona nazwą "Select Isn't Broken" ("select nie jest zepsuty").

W większości projektów kod, który przyjdzie Ci debugować, będzie mieszanką kodu aplikacyjnego pisanego przez Ciebie i innych członków Twojego zespołu, produktów z zewnątrz (systemy bazodanowe, biblioteki sieciowe czy graficzne, specjalizowane algorytmy itp.) oraz środowiska (system operacyjny, biblioteki systemowe i kompilatory).

Może się zdarzyć, że w systemie operacyjnym, w kompilatorze albo w zewnętrznym produkcie siedzi jakiś bug -- ale nie taka powinna być Twoja piewsza myśl. Jest dużo bardziej prawdopodobne, że bug znajduje sie w kodzie aplikacyjnym, który właśnie tworzysz. Generalnie, bardziej opłaca się założyć, że to kod aplikacyjny źle korzysta z biblioteki, niż twierdzić, że z samą biblioteką jest coś nie tak. Nawet jeśli rzeczywiście problem tkwi po drugiej stronie, to i tak będziesz musiał wyeliminować możliwość, że to jednak Twój kod jest źródłem problemu, zanim będziesz mógł zgłosić informację o błędzie, np. do autora biblioteki.

Zdarzyło nam się pracować przy projekcie, w którym starszy programista był święcie przekonany, że coś jest nie tak z wywołaniem systemowym select na Solarisie. Żadne metody perswazji ani przedstawianie logicznych argumentów nie były w stanie zmienić jego zdania (fakt, że sto tysięcy innych aplikacji sieciowych działało bez problemu nie miał znaczenia). Spędził długie tygodnie, programując różne obejścia, które z jakiegoś dziwnego powodu nie rozwiązywały problemu. Gdy w końcu zmuszony siadł do dokumentacji selecta, okazało się, że popełnił błąd, którego naprawienie zajęło mu raptem kilka minut. Od tamtej pory używamy wyrażenia "select is broken" ("select jest zepsuty") jako delikatne przypomnienie w sytuacjach, gdy któryś z nas zaczyna obwiniać system o błąd, którego przyczyna leży prawdopodobnie po stronie programisty.

Konsekwencją współwłasności kodu jest odpowiedzialność za kod. Niezależnie od problemu, jaki masz z oprogramowaniem, w którego tworzeniu akurat uczestniczysz -- nawet jeśli nie jesteś pierwotnym autorem -- zawsze zakładaj, że problem leży po stronie Twojego kodu i podejmuj stosowne działania. Jeśli swoje oprogramowanie zamierzasz pokazywać światu, bierz odpowiedzialność za jego błędy. Nawet jeśli, technicznie rzecz biorąc, nie musisz tego robić. W taki właśnie sposób zdobywa się szacunek i wiarygodność. Z pewnością nie uzyskasz tego, jeśli non-stop będziesz zwalał winę za błędy i problemy na innych ludzi, inne firmy czy inne źródła.

Statystyki pokazują, iż niezwykle rzadko zdarza się, żeby bugi czy błędy w Twoim oprogramowaniu nie były spowodowane przez Ciebie. W książce Programista Doskonały (przyp. tłum.: jest już drugie wydanie, ale nie wiem, czy zostało przetłumaczone na język polski) Steve McConnell przedstawia rezultaty dwóch badań, które to potwierdzają:

Dwa badania przeprowadzone w latach 1973 i 1984 wykazały, że spośród wszystkich zgłoszonych błędów około 95% było spowodowanych przez programistów, 2% przez oprogramowanie systemowe (kompilator i system operacyjny), 2% przez inne oprogramowanie oraz 1% przez sprzęt. Oprogramowania systemowego i narzędzi programistycznych używa obecnie znacznie więcej osób, niż w latach 70. i 80. Można więc przypuszczać, że odsetek błędów powodowanych przez programistów byłby teraz jeszcze większy.

Niezależnie od tego, jaki masz problem z oprogramowaniem, które tworzysz, przejmij inicjatywę. Zacznij od analizy własnego kodu i zataczaj coraz większe kręgi, aż będziesz miał stuprocentową pewność, że wiesz, co jest przyczyną. Jeśli problem tkwi w kodzie, nad którym nie masz kontroli, to nie będzie to czas stracony. Nie tylko udoskonalisz swoje zdolności analityczne i diagnostyczne, ale będziesz także dysponował zapisem swoich działań, który w razie potrzeby potwierdzi Twoje spostrzeżenia. Takie podejście wymaga oczywiście o wiele więcej wysiłku niż wzruszenie ramionami i wskazywanie na system operacyjny, narzędzia czy framework -- ale skutkuje ono zwiększeniem zaufania i szacunku, których raczej nie zdobędziesz poprzez wytykanie palcami i wymigiwanie się.

Jeśli naprawdę aspirujesz do miana skromnego programisty, nie powinieneś mieć oporów przed powiedzeniem "hej, to moja wina -- i zrobię wszystko, żeby dowiedzieć się, gdzie tkwi problem".

Czy kompetentni programiści powinni mieć "skłonności matematyczne"?

Oryginalny post: Should Competent Programmers be "Mathematically Inclined"?

Autor: Jeff Atwood

Jeden z bardziej znanych cytatów Edsgera Dijkstry pochodzi z jego wykładu wygłoszonego podczas przyznania mu nagrody Turinga w 1972 roku, How do we tell truths that might hurt?

Oprócz zapału do matematyki, wyjątkowo dobre opanowanie języka ojczystego jest niezbędnym atutem kompetentnego programisty.

Zauważ, że w odróżnieniu od innych powiedział "języka ojczystego", nie angielskiego. W takim razie zastanawiam się, dlaczego większość najważniejszej twórczości Dijkstry powstała w języku angielskim, a nie w jego ojczystym -- holenderskim.

Ale zboczyłem z tematu. Rozważmy pierwszą część cytatu Dijkstry. Czy kompetentni programiści powinni mieć "skłonności matematyczne"? Myślenie o programowaniu jako formie matematyki może być pouczające chociażby z jednego względu: odporność na lokalizację. Chociaż były już próby stworzenia zlokalizowanych języków programowania, to z tego co mi wiadomo nikt nigdy nie starał się zlokalizować π, albo liczby 3. Te symbole są uniwersalne. W tym sensie języki programowania są poniekąd podobne do matematyki. Naucz się symboli raz i używaj ich gdziekolwiek na świecie, niezależnie od tego, jaki jest Twój język ojczysty.

Z drugiej strony, nie doszukałem się w praktyce tego, że programiści muszą mieć skłonności matematyczne, aby zostać doskonałymi programistami. W rzeczywistości jest całkiem na odwrót. Zależy to mocno od rodzaju kodu jaki piszesz, ale znaczna większość kodu, który widziałem, zawiera głównie rodzaj matematyki typu "bilansowanie książeczki czekowej". Nie uświadczysz tam niczego nawet choć trochę podobnego do tego, co można znaleźć w typowym podręczniku do analizy matematycznej.

{ i = j++ / (x + v); }

To nie do końca to, czym operują matematycy.

Nigdy nie rozumiałem chęci formalnego zrównania umiejętności matematycznych z umiejętnościami programistycznymi. O ile bycie kujonem z matmy nie zaszkodzi Ci jako programiście, o tyle trudno jest mi narysować linię pomiędzy "dobrym z matmy" a "dobrym z programowania". Tak jak Rory, uważam, że programowanie wymaga wyraźnej wrażliwości prawej półkuli mózgowej.

Gdy dorastałem, pamiętam jak ludzie mówili: "jeśli lubisz programowanie, to z pewnością pokochasz matmę". Zawsze myślałem, że ci ludzie byli całkowicie stuknięci. O ile jest coś wewnętrznie podobnego w pewnych rodzajach matematyki i programowania, o tyle obie dziedziny różnią się w dużo większej mierze niż są do siebie podobne.

Dzięki matmie, i nie mówię tu o szalonej filozofii teorii liczb typu "Czy liczby w ogóle istnieją?", ale o praktycznych zastosowaniach, otrzymujemy konkretne odpowiedzi. Dostajesz albo poprawny wynik albo nie.

Jeśli chodzi o kodowanie, najlepsze na co możesz mieć nadzieję, to zrobić coś dobrze. Z tak wieloma możliwościami osiągnięcia tego samego efektu określenie, czy osiągnałeś cel, zależy bardzo od wrażliwości prawej półkuli mózgowej, ponieważ nie ma nikogo (poza [kolejnym bardziej doświadczonym programistą]), kto mógłby Ci powiedzieć, czy zrobiłeś coś dobrze czy nie.

Jeśli zignorujesz swoją prawą półkulę mózgową, i mówię tu tylko ogólnie o abstrakcji i estetyce, to możesz naklepać jakiś kod, który może działać, ale piekłem może okazać się jego utrzymanie. Jeśli skupisz się tylko na prawej półkuli, możesz mieć coś, co działa, ale jest całkowicie nieefektywne i specyficzne, i jesteś jedyną osobą na Ziemii, która rozumie ten kod i potrafi go utrzymać.

Odstawiając wszystkie te zastrzeżenia na bok, ludzie nadal popierają ideę, że sama matematyka ma moc zrobienia z Ciebie lepszego programisty. Steve Yegge opracował najlepszą rozprawę, jaką przeczytałem, dla programisty-matematyka, z następującymi pięcioma punktami:

  1. Matematyka jest dużo łatwiejsza do zrozumienia, kiedy wiesz już, jak programować. W rzeczywistości, jeśli choć w połowie jesteś porządnym programistą, będzie to dla Ciebie proste.
  2. W szkole uczą nas matmy źle. Całkiem, CAŁKIEM źle. Jeśli sam nauczysz się jej w dobry sposób, będziesz uczył się szybciej, pamiętał dłużej i będzie ona cenniejsza dla Ciebie jako programisty.
  3. Poznanie choćby małej części odpowiedniego rodzaju matmy, pozwoli pisać Ci całkiem interesujące programy, które w przeciwnym wypadku byłyby za trudne. Innymi słowy, matma jest czymś, czego możesz się uczyć małymi porcjami, gdy tylko masz trochę wolnego czasu.
  4. Nikt nie zna całej matematyki, nawet najlepsi matematycy. Ten obszar nauki cały czas się rozwija, ponieważ ludzie wynajdują nowe formalizmy, aby rozwiązać swoje problemy. Dla dowolnego matematycznego problemu, jak w programowaniu, istnieje więcej niż jeden sposób, w który można go rozwiązać. Możesz wybrać swój ulubiony.
  5. Matma jest... hmmm, proszę nie mów nikomu, że to powiedziałem; już chyba nigdy w życiu nie zostanę zaproszony na żadną imprezę. Ale matma, cóż... lepiej to wyszepczę, więc słuchaj uważnie: (jest całkiem niezłą zabawą.)

Jak dla mnie brzmi to jak obszerna recepta na stanie się intelektualnie ciekawskim i na budowanie umiejętności rozwiązywania abstrakcyjnych problemów. Umiejętności niewątpliwie ważnych w programowaniu, ale do zdobycia nie tylko poprzez studiowanie matematyki. Jeśli matma jest Twoim preferowanym sposobem ostrzenia piły, to tego się trzymaj - ale nie jest to jedyny sposób.

Ostatnio otrzymałem taki e-mail:

Prowadzę małą (cztroosobową) firmę i zauważam, że młodsi programiści nie mieli przyjemności pisania w asemblerze albo bez wykorzystania funkcji bibliotecznych. Zawsze uważałem, że mocne umiejętności matematyczne są jednymi z bardziej użytecznych podczas kodowania. Natomiast jeśli ktoś ma Google i olbrzymią liczbę bibliotek, to nie musi być dobry z matmy, żeby sprawić, by coś działało, dopóki się nie zepsuje, ma warunki brzegowe, albo uwydatnia błędy systemu operacyjnego bądź biblioteki.

Parę prostych przykładów: upraszczanie nietrywialnych równań w celu określenia indeksów w tabeli albo adresowania pamięci; trygonometria w przypadku obliczeń fizycznych; konwersja hex/bin/dec w pamięci; równania logiczne takie jak prawa DeMorgan'a.

Ma rację; jeśli już mamy rozmawiać o matmie, przejdźmy od abstrakcji do szczegółów. Porozmawiajmy o detalach. Przykładach. Co mogłoby być bardziej matematycznego niż to?

Jaki kod osobiście napisałeś, w którym dokładna znajomość matematyki ułatwiła Ci pracę? Przychodzą mi na myśl pewne kategorie. Pisanie gry 3D. Albo symulacja fizyki. Albo niskopoziomowe filtry obrazów. Albo algorytmy kompresji. Lista jest długa. Ale jeśli jesteś w takiej sytuacji, to już to znasz.

Może jestem beznadziejnym optymistą, ale myślę, że większość programistów jest na tyle bystra, żeby nauczyć się jakiejkolwiek matematyki w momencie, gdy taka potrzeba pojawi się podczas rozwiązywania jakiegoś problemu.

Liczba monitorów a produktywność

Oryginalny post: Multiple Monitors and Productivity

Autor: Jeff Atwood

Znalazłem ostatnio interesujący wpis o małym nieoficjalnym badaniu dotyczącym produktywności i pracy na wielu monitorach. Przez ostatni rok, pewna liczba programistów, za moją namową, skłoniła się do pracy na wielu monitorach. Bazując na tym doświadczeniu, szczerze zgadzam się z wynikami badania:

  • Przeciętnie, badani woleliby mieć dwa mniejsze monitory niż jeden duży. Nikt nie odpowiedział, że wolałby jeden monitor zamiat dwóch.
  • Wiele monitorów było najbardziej użytecznymi, gdy aplikacja miała palety, bądź istniała potrzeba pracy z dwoma lub trzema oknami, jak na przykład, podczas programowania/debbugowania.
  • Największą udręką była przestrzeń na biurku, ponieważ wszystkie nasze monitory były CRT (nie LCD).

Dla każdego programisty, który ceni swój czas, to się rozumie samo przez się. Tym bardziej teraz, gdy:

  1. Większość popularnych, niedrogich kart graficznych coraz częściej produkowana jest z dwoma portami VGA (aka "dual head").
  2. Ceny poręczniejszych 17 czy 19 calowych monitorów LCD są już całkiem rozsądne.
  3. Windows XP posiada dojrzałe wsparcie dla obsługi wielu monitorów; jest to standardowa cecha win32 od czasów Windows 98.

Posiadając nowoczesną kartę typu "dual head", dwa monitory to jak plug and play, ale przejście na trzy monitory jest mniej powszechne i wymagające więcej pracy.

Ostatnio przeszedłem z dwóch na trzy panele, i myślę, że warto było podjąć ten wysiłek. Wszystkie "dodatkowe rzeczy", których nie mogłem pomieścić na pierwszym czy drugim panelu, w końcu znalazły swoje miejsce na trzecim. Wzrost nie jest jednak tak zauważalny, jak przy przejściu z jednego monitora. Myślę, że prawo malejących przychodów zaczyna być aktualne dla więcej niż trzech. Zastanawiam się również, czy mógłbym fizycznie widzieć cztery monitory, nie poruszając głową dookoła więcej niż zwykle.

Jeśli zastanawiasz się nad przejściem na trzy monitory, będziesz potrzebował drugiej karty graficznej na PCI w dodatku do swojej pierwszej na AGP. Chociaż zwykle to działa, nie zakładaj, że tak będzie. Posiadanie dwóch różnych sterowników graficznych (od dwóch różnych producentów, na dwóch różnych szynach) może być problematyczne. Polecam odwiedzenie świetnej strony Multiple Monitor Resources -- byli pionierami w tym temacie w, eee, 1999 roku -- i sprawdzenie ich bazy danych kompatybilności. Miałem kartę nVidia 5200 z podwójnym wyjściem, zatem chcąc pozostać przy tym samym chipsecie, zainstalowałem dodatkową kartę nVidia 5200 na PCI. Tym sposobem, musiałem zainstalować tylko jeden sterownik graficzny, i otrzymałem możliwość konfigurowania wszystkich trzech paneli za pomocą jednego apletu właściwości ekranu.

ATI czy nVidia mają dobre wsparcie dla wielu monitorów w domyślnych sterownikach, chociaż wsparcie nVidii jest znacznie lepsze w tym aspekcie. Więc jeśli nie możesz się zdecydować, bądź nie masz preferencji, kupiłbym kartę z chipsetem nVidii, jeśli to możliwe. Jeśli myślisz poważnie o wielu monitorach, to zapewne będziesz chciał mieć użyteczną aplikację RealTimeSoft UltraMon, która posiada wiele naprawdę pomocnych funkcjonalności związanych z obsługą wielu monitorów, oraz jedną całkowicie powalającą:

UltraMon dodaje dodatkowy pasek zadań dla każdego kolejnego monitora, a każdy pasek pokazuje zadania z monitora, na którym się znajduje. To powoduje, że zarządzanie wieloma aplikacjami staje się znacznie prostsze. Aktywując aplikację, wiesz, na którym monitorze się pokaże.

Nie zdawałem sobie sprawy z tego, jak istotna jest ta funkcjonalność, dopóki nie wypróbowałem. Jest potężna! Pasek zadań staje się o wiele bardziej użyteczny, kiedy nie jest zapchany przez dużą ilość okien, które musisz mieć otwarte, i każdy z nich pokazuje tylko okna z konkretnego monitora. Gorąco polecam.

Jak nie zostać programistą-gwiazdorem

Oryginalny post: How Not To Become a Rockstar Programmer

Autor: Jeff Atwood

Krytyka artykułu Mikaela Greya, How to Become a Rock Star Programmer, zaczyna się obiecująco:

Zacznijmy może do tytułu. Nie ma czegoś takiego jak "programista-gwiazdor", więc jeśli chciałbyś takim zostać, to masz już problem, którego wpis na blogu nie jest w stanie rozwiązać. Gwiazdy rocka to seks, narkotyki, imprezy, limuzyny, chwała, randki z supermodelkami i artykuły w Rolling Stone. Dobrzy programiści mogą jedynie liczyć na ... ykhm ... mniejszą liczbę błędów kompilacji. Albo mniej błędów w trakcie uruchomienia, w zależności od języka, którego używasz. Nie udawajmy więc, że pojęcie "programista-gwiazdor" ma więcej sensu niż "lżejszy od powietrza przycisk do papieru" lub "kelner-gwiazdor".

Michael Angelo, guitar shredder

Niestety rada, którą daje Tom, jest tak samo niedorzeczna jak ta lista dziesięciu wskazówek, które krytykuje:

Najlepszym sposobem na doskonalenie się jest czytanie kodu lepszego od twojego. Czytaj kod napisany przez ekspertów, w wielu różnych językach. Studiuj go, aż zrozumiesz, jak działa i co sprawia, że jest dobry. To wszystko. To jest ta jedna rada.

Nie staniesz się lepszym programistą poprzez pasywne studiowanie czyjegoś kodu. Analogicznie, nie zostaniesz w jakiś magiczny sposób lepszym pisarzem poprzez czytanie mnóstwa książek. Lepszym pisarzem stajesz się poprzez ... poczekaj na to ... pisanie.

Rada, by studiować czyjś kod, nie jest zła. Ale zdecydowanie najlepszym sposobem na doskonalenie się jest pisanie własnego, cholernego kodu! Nic nie uczy szybciej niż popełnianie własnych błędów, we własnym tempie, na własnych zasadach.

Studiuj więc "dobry kod*", ile chcesz, ale pisz również tyle własnego kodu, ile zdołasz.

* cokolwiek to jest

Programowanie: kochaj albo rzuć

Oryginalny post: Programming: Love It or Leave It

Autor: Jeff Atwood

W jednym z ostatnich postów na forum Joela, Thinking of Leaving the Industry, pewien programista zastanawia się, czy w świetle dzisiejszej niepewności ekonomicznej kariera w branży tworzenia oprogramowania jest dobrym pomysłem:

Po przeczytaniu tak wielu zniechęcających wypowiedzi ze strony doświadczonych programistów i po nasłuchaniu się na temat outsourcingu i dyskryminacji ze względu na wiek, zastanawiam się, czy nie zrezygnować z pracy w tej branży. Jaki zawód moglibyście polecić, w którym zdolności programistyczne dawałyby mi przewagę?

Joel Spolsky odpowiedział w ten sposób:

Chociaż branża IT nie jest całkowicie odporna na kryzys, to pracy dla programistów nie brakuje. Owszem, jest trochę mniej ofert, ale jednak są (jako dowód zobaczcie moją tablicę ogłoszeń z ofertami pracy). Nie spotkałem do tej pory żadnego dobrego programisty, który byłby bez pracy. W mojej firmie cały czas mam problemy z obsadzeniem wszystkich wakatów.

Nasze płace są znakomite. Nie ma żadnego innego zawodu (poza byciem maklerem na Wall Street), w którym dzieciaki zaraz po szkole dostają $75 000 rocznie, a pensje doświadczonych pracowników, posiadających zaledwie stopień licencjata, często sięgają sześciu cyfr. Nie ma innego takiego zawodu, w którym dzień w dzień dawana jest Ci możliwość wynajdowania, projektowania oraz budowania tego, na czym opierać się będzie przyszłość.

Pomijając okazjonalnych szefów-idiotów oraz miejsca pracy, w których nie pozwolą Ci powiesić sobie na ścianie komiksu z Dilbertem, nie ma innej takiej branży, w której tak dobrze traktuje się pracowników. Jezu, jesteście za bardzo rozpieszczeni. Czy zdajecie sobie sprawę z tego, jak wielu ludzi w Ameryce chodzi do pracy, w której trzeba prosić o pozwolenie na wyjście do toalety?

Przestańcie narzekać. Kariera programisty jest fantastyczna. Większość programistów z przyjemnością kodowałaby, nawet gdyby nie mieli z tego żadnych pieniędzy. Jak wielu ludziom dane jest robić to, co kochają i jednocześnie przy tym zarabiać? 2%? 5%?

Osobiście zgadzam się z tym surowym kazaniem Joela. Zdaje się, że chce on powiedzieć -- ujmując to bardziej poetycko -- coś w tym stylu:

Programowanie: kochaj albo rzuć.

Ameryka: kochaj albo rzuć

Jeśli nie masz na tyle szczęścia, żeby pracować w jednej z topowych firm developerskich, takich jak Google, Microsoft czy Apple, to prawdopodobnie doświadczyłeś już na własnej skórze olbrzymich rozbieżności w umiejętności programowania wśród swoich kolegów-programistów. Idę również o zakład, ze zdarzyło Ci się, pewnie nawet więcej niż raz, zastanawiać, dlaczego niektórzy Twoi współpracownicy tak właściwie to nie potrafią, hmm, programować. Pomimo tego, że wspomina się o tym w opisie ich stanowisk pracy.

W ciągu ostatnich dwudziestu lat pracowałem ze zbyt wieloma programistami, którym nigdy nie powinno było się płacić za bycie programistą. Nie mówię tutaj o zwyczajnych, przeciętnych programistach. Wszyscy jesteśmy ludźmi i zdarza nam się popełniać błędy. Mam raczej na myśli ludzi, których "twórczość" cytowana jest w serwisie Daily WTF. Ludzie, którzy aktywnie przyprawiają zawodowi programisty łatkę, a Ciebie, jako ich współpracownikowi, o nieustanny ból głowy.

Podobnie jak Joel, nie jestem jeszcze skłonny ogłosić nowej bańki dotcomowej, ponieważ nie jest aż tak źle. Chciałbym jednak zauważyć, że poprzednia bańka dotcomowa miała jedną (spośród nielicznych) zaletę -- odsiała ona tych wszystkich ludzi, którzy nie byli prawdziwie zakochani w tworzeniu oprogramowania. Gdy nadzieja na zostanie dotcomowym milionerem w ciągu jednej nocy okazała się złudna, liczba chętnych na studia informatyczne w całym kraju dramatycznie spadła. Jedynymi ludźmi, którzy starali się o pracę jako programiści, zostali prawdziwi szaleńcy i geeki, którzy, no wiesz, naprawdę kochali te klimaty. Typ ludzi, z którymi tak świetnie z początku mi się pracowało. Przynajmniej do czasu, gdy nagle pojawili się karierowicze, poszukiwacze złota, i zaczęli zanieczyszczać nasze miejsca pracy.

Niezależnie od tego, jak bardzo beznadziejna była bańka dotcomowa, ja byłem niezmiernie zadowolony, widząc, jak ci ludzie odchodzą. Zastanawiam się teraz, czy aktualne warunki ekonomiczne nie stanowią akurat dobrej okazji do przeprowadzenia kolejnych porządków.

Nie obrażając nikogo, uważam, że nie każdy powinien być programistą. Jak często zdarza Ci się po cichu mieć nadzieję, że któryś z Twoich współpracowników dozna nagłego objawienia i uzmysłowi sobie, że całe to tworzenie oprogramowania nie jest jednak dla niego? W jaki sposób dać komuś do zrozumienia, że praca, którą wykonują, do niczego się nie nadaje, oraz że nigdy nie będą dobrzy w tym, co teraz robią -- do tego stopnia, że powinni po prostu zrezygnować i spróbować swoich sił w innym zawodzie? Ja chciałem to zrobić wiele razy, ale jakoś nie miałem odwagi.

Joel stwierdził, że dobrzy programiści tak bardzo kochają kodować, że robiliby to nawet za darmo. Według mnie to lekka przesada, ale faktem jest, że najlepsi programiści jakich znam, przez całe swe życie pełni byli pasji w tym, co robią. Lekkie ekonomiczne tąpnięcia nie są w stanie ich od tego odwieść. Nie ma takiej opcji.

Tak więc, jeśli programiście kiedykolwiek chociaż przez myśl przejdzie, żeby wycofać się z branży -- to prawdopodobnie powinien to zrobić. Nie nakłaniam oczywiście nikogo do obrażania innych, ale uważam, że jeśli ktoś ma jakieś wątpliwości odnośnie swojego wyboru kariery jako programisty, to powinno się go zachęcać do rozważenia alternatyw -- w ten sposób zwolni się miejsce dla kogoś, kto bezwarunkowo uwielbia kodować.

Z drugiej strony, możliwe, że nie jestem odpowiednią osobą do wypowiadania się w tej kwestii. Ostatnią Wigilię spędziłem konfigurując serwery. W tej chwili jestem na urlopie, siedzę w pokoju hotelowym w Santa Barbara, i wiecie, co robiłem do samego rana przez ostatnie dwie noce? Siedziałem nad kodem Stack Overflow, by go ulepszyć. Aha, i jeszcze pisałem tego posta.

Tak, zdaje się, że mogę być odrobinę stronniczy.

Osiem Poziomów Programistów

Oryginalny post: The Eight Levels of Programmers

Autor: Jeff Atwood

Czy kiedykolwiek na rozmowie o pracę zadano Ci klasyczne pytanie, "gdzie widzisz siebie za pięć lat?" Gdy jestem o to pytany, cofam się myślami do pewnego teledysku Twisted Sister z 1984 roku.

Chcę abyś mi powiedział -- albo nie, lepiej wstań i powiedz klasie --

co chcesz zrobić ze swoim życiem?

Chcesz wymiatać, rzecz jasna! Albo chociaż być programistą gwiazdorem. Nie jest to pytanie, na które daje się zazwyczaj poważną odpowiedź -- tak jak stare, dobre, wywołujące jęczenie pytanie zadawane na rozmowach kwalifikacyjnych "jaka jest Twoja największa słabość?" To pewnie to, że czasem wymiatasz za bardzo, prawda? Ktoś mógłby ucierpieć.

Ale myślę, że to jest inna, bardziej poważna kategoria pytania. Takie, które zasługuje na prawdziwe rozważenie. Nie dla korzyści przesłuchującego, ale dla własnej.

Pytanie "gdzie widzisz siebie za pięć lat" jest raczej nudne i większość ludzi daje na nie odpowiedź bez zająknięcia. Ale to podnosi głębszą kwestię: jaka jest potencjalna ścieżka kariery dla programisty? Jasne, robimy to, ponieważ to kochamy i jesteśmy bardzo szczęśliwi z tego względu. Ale czy będziesz siedział przed komputerem programując, kiedy będziesz miał 50 lat? A jak będziesz miał 60? Jaki jest możliwie najlepszy kierunek kariery dla programisty, który ma aspiracje, aby być.. no, programistą?

A co jeśli Ci powiem, z przymrużeniem oka, że było też Osiem Poziomów Programistów?

  1. Martwy programista

    Najwyższy poziom. Twój kod przetrwał i prześcignął Twoją śmierć. Jesteś częścią historii komputerów. Inni programiści studiują Twoją pracę oraz twórczość. Mogłeś wygrać Nagrodę Turinga, albo napisać jakieś wpływowe artykuły, albo wynaleźć jakąś część podstawowej technologii, która miała wpływ na kierunek programowania, jaki teraz znamy. Nie tylko posiadasz wpis na swój temat w Wikipedii -- istnieją całe strony internetowe poświęcone Twojemu życiu i pracy.

    Bardzo niewielu programistów kiedykolwiek osiągnie ten poziom podczas swojego życia.

    Przykłady: Dijkstra, Knuth, Kay

  2. Programista odnoszący sukcesy

    Programiści, którzy są dobrze znani i stworzyli firmy -- a być może nawet całe przemysły -- wokół swojego kodu. Ci programiści obrali dla siebie prawdziwą wolność zero: wolność wyboru tego, nad czym chcą pracować. Oraz dzielenie się tą wolnością z kolegami programistami.

    To jest poziom, do którego powinna aspirować większość programistów. Często osiągnięcie tego poziomu bardziej zależy od umiejętności biznesowych niż programistycznych.

    Przykłady: Gates, Carmack, DHH

  3. Znany programista

    To również dobry poziom, ale nie jeśli nie masz stałego dochodu.

    Jesteś sławny w kręgach programistycznych. Ale bycie znanym niekoniecznie świadczy o tym, że możesz zarobić na swoje utrzymanie. Znany jest dobry, ale odnoszący sukcesy jest lepszy. Prawdopodobnie pracujesz dla dużej, dobrze znanej firmy w branży technologicznej, małej wpływowej firmy, bądź jesteś częścią zespołu niewielkiego startup'u. Tak czy siak, inni programiści słyszeli o Tobie i masz pozytywny wpływ na branżę.

  4. Pracujący programista

    Prowadzisz pomyślną karierę programisty. Istnieje popyt na Twoje umiejętności i nie musisz nigdy długo bądź ciężko szukać dobrej pracy. Twoi współpracownicy czują do Ciebie respekt. Każda firma, dla której pracowałeś, jest w pewien sposób usprawniona i wzbogacona przez Twoją obecność.

    Ale dokąd stąd podążysz?

  5. Przeciętny programista

    Na tym poziomie jesteś na tyle dobrym programistą, że potrafisz sobie uzmysłowić, że nie jesteś wspaniałym programistą. I możesz nim nigdy nie zostać.

    Talent ma często niewiele wspólnego z sukcesem. Możesz odnieść wielki sukces, jeśli posiadasz umiejętności interpersonalne i biznesowe. Jeżeli jesteś przeciętnym programistą, ale potrafisz się z tego utrzymać, to jesteś utalentowany, ale niekoniecznie w kodowaniu.

    Nie ignoruj potencjału samoświadomości. To rzadsza cecha niż mogłoby się wydawać. Nie ma nic złego w braku talentu. Bądź śmiały. Dojdź do tego, w czym jesteś dobry i podążaj za tym. Agresywnie.

  6. Programista amator

    Programista amator kocha kodować, co oznacza: mogą być dobrym uczniami bądź stażystami, albo być może wspierają projekty open-source, albo "dla zabawy" tworzą interesujące aplikacje lub strony internetowe w swoim wolnym czasie. Ich kod i pomysły wyglądają obiecująco i są pełne entuzjazmu.

    Dobrze jest być amatorem; z tego poziomu szybko można stać się pracującym programistą.

  7. Nieznany programista

    Przysłowiowy typowy programista. Jan Programista. Kompetentny (zazwyczaj), ale niewyróżniający się. Prawdopodobnie pracuje dla wielkiej, anonimowej MegaKorporacji. To tylko praca, a nie ich całe życie. Nic w tym złego.

  8. Zły programista

    Ludzie, którzy z jakiegoś powodu stają się programistami bez odrobiny zdolności i umiejętności. Czegokolwiek nie dotkną, przemienia się w ból i cierpienie dla kolegów programistów -- za wyjątkiem innych Złych programistów, którzy nie posiadają nawet podstawowych umiejętności, aby stwierdzić, że pracują z innym Złym programistą.

    Co jest, być może, cechą charakterystyczną Złych programistów. Ci ludzie nie mają żadnego interesu w tym, aby pisać kod jakiegokolwiek rodzaju -- ale mimo wszystko to robią.

Powyższe poziomy nie są całkowicie poważne. Nie każdy programista aspiruje do tych samych rzeczy podczas swojej kariery. Ale warto jest rozważyć, co programista mógłby osiągnąć w przeciągu dziesięciu lat, dwudziestu lat, albo trzydziestu lat -- być może nawet w całym życiu. Których znakomitych programistów podziwiasz najbardziej? Co oni osiągnęli, aby zasłużyć na Twój podziw?

W skrócie -- co chcesz zrobić ze swoim życiem?

Dziewczyna, która udowodniła, że P = NP

Oryginalny post: The Girl Who Proved P = NP

Autor: Jeff Atwood

Jeden z moich ulubionych blogowych wpisów przedstawia prawdziwie epicką historię nieudanej randki, którą wieńczy chyba najdziwniejsze odniesienie do problemu P=NP, jakie kiedykolwiek napotkasz.

Joey: Naprawdę skończyłaś informatykę?

Nowa Dziewczyna: Tak, na UBC!

Joey: I uczęszczałaś na kurs "Algorytmy"?

Nowa Dziewczyna: Jasne!

Joey: Zachowałaś wszystkie swoje artykuły?

Nowa Dziewczyna: Tak! Wszystkie! Pokażę Ci je jutro!

Joey: Chętnie zobaczyłbym ten, który na Queen's nazywaliśmy "Diabelskim Artykułem" -- obowiązkowy do napisania na czwartym roku. Wiesz, ten, w którym, trzeba udowodnić, że P = NP?

Nowa Dziewczyna: Napisałam go! Udowodniłam, że P = NP! Byłam jedną z najlepszych w grupie, a profesor pokazywał mój artykuł jako przykład!

Joey: Udowodniłaś, że P = NP?

Nowa Dziewczyna: Tak!

Joey: Mam cię!

Biedny Joey. Umawianie się z szalonymi ludźmi to jedno, ale umawianie się z szalonymi ludźmi, którzy twierdzą, iż udowodnili, że P = NP to całkiem inna sprawa. Wiem, wiem, moje próby podejścia do P = NP bynajmniej nie były lepsze. Ale przynajmniej to nie ze mną się umawiasz, prawda?

NP-zupełność jest jedną z największych tajemnic w historii informatyki; być może najłatwiej będzie to zilustrować za pomocą tego komiksu xkcd:

- Poprosimy przystawki za dokładnie $15.05. - Dokładnie? Eee... - Trzymaj, te artykuły na temat problemu plecakowego powinny ci pomóc. - Słuchajcie, mam jeszcze 6 stolików, które muszę obsłużyć. - Oczywiście najszybciej jak to możliwe. Chcesz coś na temat problemu komiwojażera?

Charakterystyczną cechą problemu NP-zupełnego jest to, że otrzymanie jego optymalnych rozwiązań, korzystając z matematyki i logiki używanych obecnie, jest praktycznie niemożliwe. Oczywiście, można uzyskać rozwiązanie przybliżone, ale rozwiązanie optymalne wymaga tak wielu obliczeń, że jego otrzymanie jest nierealne nawet przy wykorzystaniu superkomputerów pracujących z, powiedzmy ... prędkością światła.

W rzeczywistości, jednym z wyróżniających się problemów informatyki, jest stwierdzenie, czy istnieją pytania, dla których jesteśmy w stanie szybko sprawdzić poprawność rozwiązania, ale które wymagają niesamowicie długich obliczeń, aby jakiekolwiek rozwiązanie uzyskać za pomocą bezpośredniej procedury. Problemy należące do klasy NPC zdają się być właśnie takiego rodzaju, ale jak dotąd nikomu nie udało się udowodnić, że którykolwiek z nich rzeczywiście jest tak trudny, na jaki wygląda, to znaczy, że naprawdę nie istnieje żaden praktyczny sposób generowania odpowiedzi przy użyciu komputera.

Wątpliwe jest, czy komukolwiek uda się kiedyś udowodnić, że P = NP, ale i tak warto umieć rozpoznawać problemy, które są NP-zupełne:

Niestety, dowodzenie wrodzonej niepodatności może być tak samo trudne jak znajdowanie efektywnych algorytmów.

Teoria NP-zupełności dostarcza wielu bezpośrednich technik dowodzenia, że dany problem jest "tak samo trudny" jak sporo innych problemów, o których już wiadomo, że takie są i z którymi eksperci zmagają się od lat. Uzbrojony w te techniki, być może mógłbyś udowodnić, że problem bandersnatcha jest NP-zupełny a następnie wkroczyć do biura swojego szefa i oznajmić:

Nie potarfię znaleźć efektywnego algorytmu, ale żadna z tych sławnych osób też nie potrafi.

Przynajmniej Twój szef zrozumiałby, że nie ma sensu Cię zwalniać i zatrudniać innego eksperta od algorytmów.

Możesz teraz spędzać więcej czasu na szukaniu efektywnych algorytmów dla szczególnych przypadków ogólnego problemu. Możesz poszukać takich algorytmów, które mimo braku gwarancji szybkiego działania, w większości sytuacji sprawują się dobrze. Albo może problem ten da się w jakiś sposób uprościć i znaleźć dla niego szybkie algorytmy, które znajdują rozwiązania spełniające jedynie część specyfikacji. Tak więc głównym zastosowaniem teorii NP-zupełności jest wspomaganie projektantów algorytmów -- kierowanie ich wysiłków w te strony, dla których prawdopodobieństwo uzyskania użytecznego w praktyce algorytmu jest największe.

Jak to często bywa w programowaniu, pierwszym krokiem jest nauczenie się na tyle, by umieć rozpoznawać sytuacje, w których masz naprawdę przechlapane.

Na nieszczęście dla Joeya, ten smutny wniosek z teorii złożoności najwyraźniej stosuje się również do kwestii randkowania.

Jak nie reklamować się w Internecie

Oryginalny post: How Not to Advertise on the Internet

Autor: Jeff Atwood

Gry uruchamiane w przeglądarce internetowej to ostatni krzyk mody i jest to dla mnie całkiem zrozumiałe. Możliwość stworzenia gry dla nawiększego na świecie grona odbiorców, używając do tego darmowych technologii i nie płacąć żadnych opłat licencyjnych jest kusząca. Jedną z takich gier jest Evony, wcześniej znana jako Civony -- przeglądarkowy klon Cywilizacji z mechanizmem kupowania.

Jest również mnóstwo możliwości, aby 'płacić pieniądze'. W końcu Civony to taki sam biznes jak każdy inny. I mówiąc szczerze, prawdopodobnie lepiej jest dać możliwość jakimś ludziom z elit finansować grę dla mas, niż kazać każdemu opłacać abonament bądź oglądać reklamy w trakcie gry. Poza tymi 30 centami za jedną linijkę na globalnym czacie, za pieniądze można przyspieszyć sobie wydobywanie surowców, podbić statystyki, czy też zakupić różne artefakty. Jestem pewien, że są jeszcze inne możliwości wydawania pieniędzy, których jeszcze nie odkryłem. Ale jeśli gdziekolwiek zauważysz zielony plus (+), możesz być pewien, że istnieje jakaś dodatkowa opcja, za którą możesz zapłacić.

Gra jest pozornie bezpłatna, ale wspierana przez niewielką frakcję graczy, płacących za dodatkowe przedmioty (nazywane czasem "freemium"). W związku z tym, aby ten biznes mógł się kręcić, potrzebna jest całkiem spora liczba stałych bywalców. Twórcy gry regularnie wykupują przestrzeń reklamową w Internecie, aby promować swój produkt. Najbardziej interesującą rzeczą w Evony nie jest gra sama w sobie, ale sposób w jaki jest ona reklamowana. Oto jedna z pierwszych reklam.

Całkowicie rozsądna reklama. Zawiera wyraźny przekaz, że akcja toczy się w czasach średniowiecza oraz podkreśla darmowy aspekt gry.

Najwyraźniej reklama ta w oczach zarządu Evony nie spełniała swojego zadania, ponieważ reklamy zaczęły z czasem... hmm, sam się przekonaj. Poniżej przedstawiam je w chronologicznej kolejności, w jakiej pojawiały się w Internecie.

(jeśli ta pani wydaje Ci się skądś znajoma, jest ku temu powód.)

Aby wszystko było jasne, to są prawdziwe reklamy, które ukazały się w Internecie. To nie jest parodia. Aby to udowodnić, oto zrzut ekranu ostatniej reklamy w kontekście, na stronie The Elder Scrolls Nexus.

Mówiłem już kiedyś o odpowiedzialnym reklamowaniu. Gdybym chciał wtedy znaleźć najbardziej jaskrawe przeciwieństwo moich rad, to te reklamy nadawałyby się idealnie. Po raz kolejny, niestety, okazuje się, że doskonała satyra Idiokracja trafia w samo sedno.

Autorzy Idiokracji, przedstawiając antyutopijną przyszłość, przewidzieli nieuchronne sprowadzenie reklamy do najmniejszego wspólnego mianownika razem z takimi arcydziełami marketingu jak Starbucks Exotic Coffee for Men, H.R. Block "Adult" Tax Return (dom rabatu dżentelmenów) oraz kurczak Pollo Loco reklamujący Koszyk Skrzydełek wraz z "ulżeniem sobie".

Evony, dzięki za pokazanie nam, jak wygląda sprowadzenie reklamy w Internecie na totalne dno... następnie wykopanie pod nim piwnicy i kopanie dotąd, aż dotrze się do roztopionego, rozgrzanego do białości jądra Ziemii. Zawsze zastanawiałem się, jak by to mogło wyglądać. Teraz chyba już wiem.

Budujemy prom kosmiczny

Oryginalny post: We're Building the Space Shuttle

Autor: Jeff Atwood

Dzisiejsza dawka YAGNI (ang. You Ain't Gonna Need It - nie będzie ci to potrzebne) pochodzi z ostatniego wywiadu z Andersem Hejlsbergiem:

Gdy poprosisz począktujących programistów, by napisali kontrolkę kalendarza, myślą oni sobie często: "Ha, napiszemy najlepszą na świecie kontrolkę kalendarza! Będzie polimorficzna względem rodzaju kalendarza. Jej wygląd będzie można dostosować, zaimplementujemy konwersję z różnych formatów danych, zrobimy jeszcze to i tamto." Samą aplikację mają dostarczyć w przeciągu dwóch miesięcy. Najpierw całą tę skomplikowaną logikę pakują do kontrolki i na jej podstawie w ciągu dwóch dni budują gównianą aplikację. Myślą sobie: "W następnej wersji aplikacji dołożymy jeszcze mnóstwo ficzerów.".

Gdy jednak zaczynają zastanawiać się, w jaki sposób faktycznie zrealizują założenia swojego abstrakcyjnego projektu, okazuje się, że projekt ten jest całkowicie błędny. Zapędzili się w kozi róg i muszą wszystko wywalić. Taki scenariusz widziałem już wielokrotnie. Osobiście mocno wierzę w minimalizm. Jeśli nie zamierzasz rozwiązywać ogólnego problemu, nie próbuj tworzyć frameworka w celu rozwiązania jednego, konkretnego zadania, ponieważ nie masz pojęcia, jak ten framework miałby wyglądać.

Spotkałem wielu programistów, którzy łudzą się, że budują prom kosmiczny, a tak naprawdę tworzą jedynie kolejną, gównianą aplikacyjkę biznesową.

Niezawodnym sposobem na uczynienie tej Twojej gównianej aplikacyjki biznesowej jeszcze bardziej gównianą jest tworzenie jej w taki sposob, jakbyś budował co najmniej prom kosmiczny. Wiem, co mówię, ponieważ spędziłem zdecydowanie za dużo czasu na refaktoringu tych spektakularnie beznadziejnych projektów do postaci czegoś, co choć trochę przypominałoby łatwą w zarządzaniu aplikację biznesową.

Bądź jak komandos - odstaw myszkę

Oryginalny post: Going Commando - Put Down The Mouse

Autor: Jeff Atwood

Jednym z najszybszych sposobów na zwiększenie swojej produktywności podczas pracy z komputerem jest zaprzestanie używania myszki. Gdy przestaniesz polegać na niej we wszystkim, zostaniesz zmuszony do nauczenia się skrótów klawiaturowych. Jeremy Miller nazywa to pierwszym krokiem do szybszego kodowania. Zgadzam się z nim.

Skróty klawiaturowe prawie zawsze są bardziej efektywne niż klikanie -- ale nie nauczysz sie ich, jeśli non-stop będziesz zaprzęgał swą wierną myszkę do wszystkiego, co robisz na komputerze. Zatrzymaj się na chwilę, oprzyj się naturalnemu odruchowi wybierania najłatwiejszej drogi i zmuś się do nauki co najmniej jednego nowego skrótu dziennie. Owszem, musisz włożyć w to odrobinę dodatkowego wysiłku. Ale wkrótce Ci się to opłaci: zaczniesz spędzać mniej czasu na machaniu myszką, a więcej na doprowadzaniu spraw do końca.

Nie jestem bynajmniej jakimś zagorzałym przeciwnikiem myszek. Pamiętam jeszcze czasy, gdy były one czymś nowym; nigdy bym już nie wrócił do czasów, gdy nie było żadnej alternatywy dla tych oldskulowych, obsługiwanych wyłącznie klawiaturą, interfejsów użytkownika. Ale zauważyłem, że większość ludzi korzysta z komputera prawie wyłącznie za pomocą myszki, co powoduje, że ich efektywność wyraźnie na tym cierpi. Poniżej zamieszczam kilka najprostszych przykładów skrótów klawiaturowych, które mogą ułatwić Ci rutynowe czynności:

  1. Logowanie się za pomocą klawiatury, klawisze Tab i Enter.
  2. Nawigowanie do strony internetowej za pomocą Alt+D i Ctrl+Enter.
  3. Wyszukiwanie za pomocą Ctrl+E i Enter.
  4. Edycja tekstu i sterowanie kursorem korzystając z podstawowych skrótów dostępnych w polu tekstowym.

To tylko wierzchołek góry lodowej. Większość aplikacji udostępnia tony użytecznych skrótów klwiaturowych; musisz jedynie odstawić myszkę na wystarczająco długi czas, by odkryć kilka z nich. Wielka szkoda, że twórcy aplikacji nie starają się, by te skróty dało się łatwiej odkrywać. Chciałbym przynajmniej widzieć coś takiego jak w Office 2007, gdzie po naciśnięciu klawisza Alt wyświetlają się dostępne skróty.

Niestety surfowanie bez gryzonia po stronach WWW jest niemal awykonalne ze względu na zorientowaną na myszkę naturę hipertekstu. Ja przestałem próbować jakiś czas temu. Ale jest to możliwe, jeśli jesteś hardkorem. Zanim jednak zaczniesz, sugeruję zapoznać się z artykułem Jona Gallowaya, w którym omówionych jest kilka alternatyw dla myszki, chyba że kręci Cię wciskanie klawisza Tab gazylion razy.

Aby osiągnąć najlepsze efekty, staraj się wykorzystywać w pełni zarówno myszkę jak i klawiatruę. Jednak by to zrobić, musisz świadomie odstawiać myszkę od czasu do czasu. Na początku będzie to kłopotliwe i bolesne. Twoja wierna myszka będzie Cię kusić, by po nią sięgnąć i mieć już z głowy to, co akurat robisz. Postaw się! Gwarantuję Ci, że wszystko, co możesz chcieć wykonać na komputerze, jest możliwe do zrobienia przy użyciu wyłącznie klawiatury -- w dodatku zrobisz to szybciej.

Inżynieria oprogramowania - martwa?

Oryginalny post: Software Engineering: Dead?

Autor: Jeff Atwood

Po przeczytaniu nowego artykułu (pdf) z IEEE autorstwa Toma DeMarco byłem całkowicie zaskoczony. Sam się przekonaj dlaczego:

Moja wczesna książka o metrykach, Controlling Software Projects: Management, Measurement, and Estimates [1986], odegrała pewną rolę w tym, jak moi koledzy programiści mierzyli swoją pracę oraz planowali swoje projekty. W moim pełnym zadumy nastroju myślę sobie, czy te rady zawarte w książce były wtedy odpowiednie, czy nadal jest aktualna, oraz czy nadal uważam, że metryki są konieczne dla pomyślnego tworzenia oprogramowania? Moje odpowiedzi to: nie, nie i nie.

Powoli dochodzę do wniosku, że inżynieria oprogramowania jest pewną ideą, której czas nadszedł i się skończył.

Tworzenie oprogramowania jest i zawsze będzie poniekąd eksperymentalne. W istocie sama konstrukcja oprogramowania niekoniecznie jest eksperymentalna, ale koncepcje za nim stojące są. I to właśnie na to powinniśmy kierować naszą uwagę. To tam nasza uwaga powinna była być skupiona od zawsze.

Jeśli Twoja głowa właśnie eksplodowała, nie przejmuj się. Moja też. Aby nieco zredukować ten ból głowy, którego możesz teraz doświadczać po przeczytaniu powyższego streszczenia, gorąco polecam przejrzenie całego, dwustronicowego artykułu.

Tom DeMarco jest jednym z bardziej szanowanych autorytetów w przemyśle oprogramowania, będąc współautorem znakomitej i nowatorskiej książki zatytułowanej Peopleware oraz wielu niemal klasycznych książek o zarządzaniu projektami, jak na przykład Waltzing With Bears. Jak na gościa kalibru Toma, jego doświadczenia oraz wpływu, wyjść i wypalić, że inżynieria oprogramowania jest martwa...

... tak jak kiedyś powiedział Keanu Reeves, whoa.

To wielka sprawa, przerażająca.

Ale jest to również pewna ulga. Mnie kamień spadł z serca. Mogę publicznie przyznać to, z czego powoli i stopniowo zacząłem sobie zdawać sprawę przez ostatnie 5 czy 10 lat mojej kariery jako programista: to co robimy to rzemiosło, nie inżynieria. I mogę to powiedzieć z dumą, nie wstydząc się, bez cienia zwątpienia w siebie.

Myślę, że Joel Spolsky, mój partner od interesów, miał podobne objawienie. Napisał o tym w How Hard Could It Be?: The Unproven Path:

Mam całkiem głęboko zakorzenione wizje na temat tego, jak powinno się tworzyć oprogramowanie, ale trzymam je głównie dla siebie. Okazało się to dobrą rzeczą, ponieważ jak tylko organizacja zaczęła nabierać kształtu, wszystkie te zasady zostały porzucone.

Cały czas staram się dojść do tego, co to wszystko ma oznaczać. Porzuciłem siedem długo utrzymywanych zasad dotyczących biznesu oraz inżynierii oprogramowania i nic strasznego się nie stało. Czy byłem kiedyś za bardzo rozważny? Może chciałem być troszkę lekkomyślny, ponieważ to był tylko mój projekt poboczny, a nie mój główny interes. Doświadczenie jest bez wątpienia użytecznym przypominaczem, że dobrze jest być beztroskim, gdy buduje się coś nowego i nie ma się pojęcia, w którą stronę to zmierza.

Pewnie, mógłbym jeszcze wymienić sporo zastrzeżeń odnośnie inżynierii oprogramowania dotyczących szczegółów projektu, nad którym właśnie pracujesz: jego rodzaju (przełomowy, oczywiście), jego rozmiaru (na miarę Google, naturalnie), jego publiczności (miliony użytkowników, w rzeczy samej) i tak dalej.

Ale tego nie zrobię.

To co DeMarco wydawał się mówić -- a przynajmniej to, co ja stanowczo mówię -- to to, że kontrola jest całkowicie iluzoryczna jeśli chodzi o projekty programistyczne. Jeśli chcesz popychać swój projekt do przodu, to jedynym sposobem jest kultywowanie głębokiego poczucia rzemiosła i profesjonalizmu wokół niego.

Faceci i kobiety, którzy dzień w dzień pełni są entuzjazmu odnośnie doskonalenia swojego rzemiosła, którzy z pasją tworzą rzeczy o dużym znaczeniu dla nich, a może nawet w jakiejś części także dla reszty świata -- to są właśnie ci ludzie i te projekty, którzy ostatecznie odniosą sukces.

Cała reszta to tylko zakłócenia.

Related Posts with Thumbnails