Jak efektywnie realizować zadania, kiedy jesteś tylko szeregowym programistą

Oryginalny post: Getting Things Done When You're Only a Grunt

Autor: Joel Spolsky

Ta strona poświęcona jest głównie zarządzaniu projektami programistycznymi. Jednak czasem nie masz na tyle władzy, aby w swojej firmie dokonywać przemian za pomocą dekretów. Oczywiście, jeśli jesteś tylko szeregowym programistą, na samym dole hierarchii, nie możesz tak po prostu nakazać ludziom, aby tworzyli harmonogramy czy korzystali z systemu zarządzania bugami. W rzeczywistości, nawet jeśli jesteś kierownikiem projektu, prawdopodobnie odkryłeś, że zarządzanie programistami jest bardzo podobne do hodowania kotów, tylko nie tak zabawne. Nie wystarczy, że powiesz "sprawcie, żeby tak było", żeby tak było.

Praca w firmie, która ma kiepski wynik w Teście Joela, może być frustrująca. Nieważne jak dobry kod piszesz, Twoi współpracownicy piszą kod tak mierny, że wstydzisz się w ogóle przyznać do swojego udziału w projekcie. Albo być może decyzje zarządu odnośnie tego, jaki kod pisać, są nietrafione i jesteś zmuszony marnować swój talent na debugowanie na systemie AS/400 gry w planowanie emerytury dla dzieci.

Zawsze możesz zrezygnować, tak sądzę. Ale załóżmy, że jest jakiś powód, dla którego tam utknąłeś. Nie możesz jeszcze sprzedać przyznanych Ci akcji firmy, nie ma lepszego miejsca pracy w Wygwizdowie a może Twój szef wziął za zakładnika kogoś, kogo kochasz. W każdym bądź razie, życie w takim kiepskim zespole jest w stanie doprowadzić do wściekłości. Istnieją jednak pewne strategie, dzięki którym możesz popracować nad swoim zespołem od podstaw, a ja chciałbym teraz kilkoma z nich się z Toba podzielić.

Strategia 1. Po prostu to zrób

Wiele da się zrobić w celu poprawienia sytuacji w projekcie, jeśli po prostu jedna osoba będzie to robić. Nie macie serwera do codziennych buildów? Stwórz taki. Zrób to na swoim komputerze — skonfiguruj go tak, żeby w nocy uruchumiał builda i rozsyłał maile z wynikami. Build wymaga za dużo kroków? Napisz plik makefile. Nikt nie robi testów interfejsu użytkownika pod kątem używalności? Sam przeprowadzaj takie testy korytarzowe z przypadkowymi ludźmi, używając w tym celu kartki papieru albo prototypu napisanego w VB.

Strategia 2. Wykorzystaj potęgę marketingu wirusowego

Wiele ze strategii z Testu Joela jest w stanie wdrożyć nawet jedna osoba w niezbyt zorganizowanych zespołach. Niektóre z nich, jeśli zrobi się to odpowiednio, rozprzestrzenią się w całym zespole.

Przykładowo, załóżmy, że nikt w Twoim zespole nie daje się przekonać do korzystania z systemu zarządzania bugami. Nie pozwól, żeby Cię to zniechęciło. Po prostu sam z takiego systemu korzystaj. Wprowadzaj do niego bugi, które znajdujesz w swoim kodzie. Jeśli znajdziesz buga, którego ktoś inny naprawdę powinien poprawić, przypisz tego buga do nich w systemie. Jeśli masz dobry system zarządzania bugami, zostanie wysłany do nich e-mail. Ale na początek wystarczy, że będziesz im stale przypominał drogą mailową, że jeszcze nie poprawili tego buga. W końcu zauważą wartość takiego systemu śledzenia bugów i sami zaczną z niego korzystać w prawidłowy sposób. Jeśli zespół QA nie che wprowadzać bugów poprzez system, po prostu odmawiaj przyjmowania zgłoszeń o błędach innymi kanałami. Gdzieś koło trzytysięcznego razu, gdy mówisz ludziom, "Słuchaj, chętnie bym to naprawił, ale na pewno o tym zapomnę. Czy możesz wprowadzić informację o błędzie do systemu?", zaczną tego systemu używać.

Nikt z Twojego zespołu nie chce korzystać z systemu kontroli wersji? Załóż swoje własne repozytorium, nawet na swoim własnym dysku, jeśli nie ma innej możliwości. Nawet bez współpracy ze strony innych członków zespołu możesz wrzucać swój kod do repozytorium, niezależnie od innych. I gdy napotkają na jakiś problem, który system kontroli wersji mógłby rozwiązać (ktoś przez przypadek wpisze rm * ~ zamiast rm *~), przyjdą po pomoc do Ciebie. W końcu ludzie uświadomią sobie, że równie dobrze sami mogliby korzystać z takiego systemu.

Strategia 3. Zgromadź wokół siebie kapitał doskonałości

Zespół nie chce robić harmonogramów? Albo specyfikacji? Zrób swoje. Nikt nie będzie marudził, jeśli poświęcisz dzień lub dwa na napisanie minimalnej specyfikacji bądź harmonogramu dla prac, które zamierzasz wykonać.

Sprowadź lepszych ludzi do swojego zespołu. Zaangażuj się w rekrutację i bierz udział w rozmowach z kandydatami, żeby tych dobrych ściągnąć do swojego zespołu.

Poszukaj ludzi, którzy są zainteresowani rozwijaniem się i są do tego zdolni oraz przeciągnij ich na swoją stronę. Nawet w słabych zespołach prawdopodobnie znajdziesz ludzi, którzy po prostu jeszcze nie mają na tyle doświadczenia, żeby tworzyć znakomity kod. Pomóż im. Zachęć ich do nauki. Rób przeglądy ich kodu. Jeśli zrobią coś głupiego, nie pisz do nich pogardliwych maili, w których wytykasz głupotę w ich kodzie. To ich jedynie rozzłości i przyjmą postawę defensywną. Zamiast tego, delikatnie daj im znać o bugu spowodowanym przez ich kod. Pozwól im samym dojść do tego, co jest przyczyną błędu. Kiedy sami poradzą sobie z bugiem, zapamiętają tę lekcję o wiele lepiej.

Strategia 4. Zneutralizuj przygłupów

Nawet w najlepszych zespołach zdarza się jedna bądź dwie osoby, które, delikatnie mówiąc, nie są zbyt rozgarnięte. W sytuacjach, gdy masz do czynienia z kiepskimi programistami, są dwie główne przyczyny frustracji — kiedy ich kiepski kod psuje Twój dobry kod albo gdy dobrzy programiści muszą marnować czas na sprzątanie po tych słabszych.

Jako szeregowy programista powinieneś dążyć do minimalizacji i powstrzymywania zniszczeń. Prędzej czy później jeden z tych geniuszy spędzi całe dwa tygodnie na wyprodukowaniu kodu tak niewiarygodnie złego, że nigdy nie będzie działać poprawnie. Może Cię kusić, żeby poświęcić piętnaście minut na poprawne napisanie tego od nowa. Powstrzymaj się. Stajesz właśnie przed doskonałą okazją na neutralizację tego kretyna na dobrych kilka miesięcy. Po prostu nie przestawaj zgłaszać bugów w jego kodzie. Nie będzie dla niego innego wyjścia, jak miesiącami siedzieć przy tym kodzie i go poprawiać aż Ty nie będziesz już w stanie znaleźć nowych błędów. W ciągu tego czasu nie będą mogli narobić szkód w innym miejscu.

Strategia 5. Unikaj rozpraszaczy uwagi

Wszystkie przyjazne środowiska pracy są do siebie podobne (prywatne biura, cisza, doskonałe narzędzia, niewiele rozpraszaczy uwagi i jeszcze mniej długich spotkań). Wszystkie nieprzyjazne środowiska są nieprzyjazne na swój sposób.

Złe wiadomości są takie, że zmiana środowiska pracy jest prawie niemożliwa w praktycznie każdej firmie. Długotrwałe umowy najmu moga oznaczać, że nawet CEO nie jest w stanie nic z tym zrobić. To właśnie dlatego tak niewielu programistów ma prywatne biura. Dla firm jest to szkodliwe z co najmniej dwóch powodów. Po pierwsze, trudniej jest takiej firmie pozyskać programistów z najwyższej półki, którzy wybiorą pracodawcę oferującego wygodniejsze warunki pracy (przy założeniu, że inne aspekty są na podobnym poziomie). Po drugie, duża liczba rozpraszaczy może dramatycznie obniżyć produktywność programistów, którzy w takich warunkach nie są w stanie "wejść w strefę" i pozostać w niej tak długo, jak tego potrzebują.

Rozglądnij się za sposobami na ucieczkę z takiego środowiska. Zabierz ze sobą laptopa do firmowej kawiarni, gdzie przez większą część dnia jest pusto (i nikt nie może Cię znaleźć). Zarezerwuj pokój konferencyjny na cały dzień i tam pisz kod. Jednocześnie pokaż za pomocą liczby checkinów, o ile więcej jesteś w stanie zrobić, gdy masz cały pokój tylko dla siebie. Następnym razem, gdy atmosfera zrobi się gorąca ze względu na zbliżający się deadline i Twój kierownik zapyta, czego potrzebujesz, żeby To Zrobić Na Jutro, wiesz co odpowiedzieć. Z pewnością znajdą Ci jakieś biuro na cały dzień. I niedługo zaczną się zastanawiać, co mogliby zrobić, żeby utrzymać tak wysoki poziom produktywności przez cały rok.

Zjawiaj się w pracy poźno i wychodź późno. Te godziny po tym, gdy reszta firmy wybrała się już do domów, mogą być tymi najbardziej produktywnymi. A jeśli większość Twojego zespołu przychodzi do pracy późno, Ty przychodź o 9. W ciągu tych dwóch godzin, które masz do dyspozycji, zanim pozostali zaczną się schodzić i przeszkadzać, zrobisz więcej niż przez resztę dnia.

Nie zostawiaj swojego klienta poczty ani komunikatora włączonych przez cały czas. Jeśli chcesz, sprawdzaj pocztę nawet co godzinę, ale nie zostawiaj klienta włączonego.

Strategia 6. Stań się nieoceniony

Żadna z tych strategii nie zadziała, jeśli sam nie wnosisz dużej wartości. Jeśli nie piszesz dobrego kodu, i to sporo dobrego kodu, ludzie będą mieć do Ciebie pretensje, że dłubiesz sobie przy systemie zarządzania błędami, podczas gdy "powinieneś" pisać kod. Nie ma nic bardziej zabójczego dla Twojej kariery zawodowej niż posiadanie reputacji kogoś, kto bardziej przejmuje się procesem niż tym, żeby cokolwiek ukończyć.

Kiedyś, gdy zaczynałem pracę w pewnej firmie jako szeregowy programista, odkryłem, że ta firma osiągała około 2 punktów w Teście Joela i byłem zdeterminowany, żeby to zmienić. Wiedziałem jednak również, że pierwsze wrażenie jest bardzo ważne. Postanowiłem więc przeznaczyć pierwsze siedem godzin każdego dnia na pisanie kodu, tak jak się tego ode mnie oczekiwało. Nic lepiej nie poprawi Twojego wizerunku w zespole, jak zalew checkinami. Natomiast ostatnią godzinę przed pójściem do domu zarezerowałem sobie na ulepszanie procesu. Wykorzystywałem ten czas na naprawianie rzeczy, które utrudniały debugowanie naszego projektu. Skonfigurowałem dzienne buildy i system zarządzania bugami. Naprawiłem wszystko to, co od długiego czasu stanowiło dla zespołu udrękę i spowalniało cały proces. Pisałem specyfikacje dla pracy, którą miałem danego dnia wykonać. Przygotowałem dokument, w którym opisałem, jak od podstaw przygotować maszynę dla developera w naszej firmie. Gruntownie udokumentowałem ważny, wewnętrzny język, którego nikt wcześniej nie opisał. Powoli proces stawał się coraz lepszy. Nikt poza mną (i moim zespołem, któremu później przewodziłem) nie tworzył harmonogramów ani specyfikacji, ale poza tym osiągnęliśmy 10 punktów w Teście Joela.

Jesteś w stanie wiele poprawić, nawet jeśli to nie Ty rządzisz, ale musisz być jak żona Cezara: poza wszelkimi podejrzeniami. W przeciwnym razie będziesz tylko zdobywał nowych wrogów.

Data publikacji oryginału: grudzień 25, 2001

Ostateczne programistyczne kata

Oryginalny post: The Ultimate Code Kata

Autor: Jeff Atwood

Gdy przeglądałem ostatnio obszerne zasoby opublikowane przez Steve'a Yegge, moją szczególną uwagę przykuł wpis z 2005 roku traktujący o ćwiczeniu programowania:

W przeciwieństwie do tego, co możesz sobie myśleć, zwyczajne wykonywanie swojej pracy dzień w dzień nie zalicza się do prawdziwego treningu. Uczestnictwo w spotkaniach nie poprawi Twoich zdolności interpersonalnych, a odpowiadanie na maile nie jest ćwiczeniem pisania na klawiaturze. Jeśli chcesz być w czymś lepszy, musisz wygospodarować trochę czasu na systematyczne i świadome ćwiczenia.

Znam wielu wspaniałych inżynierów — jest to jedna z najwiekszych zalet pracowania w Amazonie — i jeśli przyjrzeć im się z bliska, okazuje się, że oni nieustannie trenują. Nieważne jak dobrzy są w danym momencie, wciąż ćwiczą. Robią to na wiele różnych sposobów, z których kilka przedstawię w niniejszym tekście.

Znakomici inżynierowie, których znam, dlatego są znakomici, ponieważ trenują nieustannie. Osoby o doskonałej kondycji pracują na nią systematycznie, w przeciwnym razie ją utracą. To samo tyczy się programowania i inżynierii.

Trzeba jednak zwrócić uwagę na pewną różnicę. Mogę codziennie jeździć samochodem do pracy, ale daleko mi do zawodowego kierowcy. Analogicznie, programowanie dzień w dzień może nie być wystarczające, aby zostać profesjonalnym programistą. Zatem cóż takiego może przekształcić kogoś w zawodowego kierowcę lub programistę? Co Ty robisz, aby się rozwijać?

Odpowiedź znajduje się w artykule The Expert Mind opublikowanym w Scientific American:

Ericsson twierdzi, że to nie doświadczenie jako takie ma największe znaczenie, ale "świadome, ukierunkowane uczenie się", które obejmuje nieustanne podejmowanie wyzwań leżących poza zasięgiem aktualnych kompetencji. Właśnie dlatego możliwe są sytuacje, gdy entuzjaści spędzają dziesiątki tysięcy godzin, grając w szachy, golfa lub na instrumencie i nigdy nie wychodzą poza poziom amatorski a odpowiednio wyszkolona osoba może przewyższyć ich umiejętnościami we względnie krótkim czasie. Interesująca jest również obserwacja, że sam czas poświęcony na granie w szachy, nawet w turniejach, wydaje się mieć dużo mniejszy wpływ od właściwego uczenia się na postępy gracza; główną zaletą takich gier jest to, że pozwalają zauważyć swoje słabości, które później można eliminować w procesie doskonalenia się.

Ukierunkowane i wymagające wysiłku uczenie się oznacza nieustanne rozwiązywanie problemów leżących na samej granicy Twoich zdolności. Problemów, dla których prawdopodobieństwo porażki jest wysokie. Jeśli w ogóle nie ponosisz porażek, prawdopodobnie nie rozwijasz się zawodowo. Musisz szukać tego typu wyzwań i nie bać się wykraczać poza strefę komfortu.

Takie wyzwania można czasem znaleźć w pracy, ale nie zawsze. Odseparowanie treningu od zawodu jest często nazywane programistycznym kata.

Ilustracja Kata

Koncepcja kata, czyli choreograficznego układu wyćwiczonych ruchów, zapożyczona została ze sztuk walki.

Jeśli szukasz jakichś przykładów programistycznego kata — sposobów na ukierunkowane i wymagające wysiłku trenowanie programistycznych umiejętności — artykuł Steve'a zawiera trochę doskonałych pomysłów, od których mógłbyś zacząć. Steve mówi o nich jak o musztrze:

  1. Napisz swoje CV. Wymień w nim wszystkie istotne umiejętności a następnie zanotuj, które z nich będą potrzebne za 100 lat. Oceń każdą ze swoich zdolności w skali od 1 do 10.
  2. Zrób listę programistów, których podziwiasz. Spróbuj uwzględnić również tych, z którymi aktualnie pracujesz, ponieważ do niektórych ćwiczeń będziesz ich potrzebował. Wymień po jednej, dwóch rzeczach, w których są oni dobrzy — takich, w których sam chciałbyś się podszkolić.
  3. Wybierz jedną osobę z listy "czołowych pionierów informatyki" i poczytaj o niej. Podążaj stamtąd za każdym odnośnikiem, który wyda Ci się interesujący.
  4. Poczytaj czyjś kod przez 20 minut. W tym ćwiczeniu powinieneś czytać na zmianę znakomity i kiepski kod; każdy z nich może Cię czegoś nauczyć. Jeśli nie jesteś pewien, na czym polega różnica, poproś jakiegoś programistę, którego szanujesz, żeby pokazał Ci przykłady kodu jednego i drugiego typu. Pokaż komuś kod, który czytasz i dowiedz się, co inni o nim myślą.
  5. Zrób listę 10 swoich ulubionych narzędzi programistycznych: takich, których używasz najczęściej, bez których praktycznie nie mógłbyś żyć. Poświęć godzinę na przeczytanie dokumentacji do jednego z tych narzędzi, wybranego losowo. Podczas tej godziny postaraj się nauczyć czegoś nowego o tym narzędziu, poznaj nowe funkcjonalności albo zastanów się nad nowymi sposobami jego wykorzystania.
  6. Wybierz coś, w czym jesteś dobry, ale co nie ma nic wspólnego z programowaniem. Zastanów się, w jaki sposób trenują zawodowcy lub wielcy mistrzowie tej dyscypliny. Czego możesz się od nich nauczyć i przenieść na grunt programowania?
  7. Zbierz trochę życiorysów zawodowych i grupę osób w jednym pokoju na godzinę. Upewnij się, że każde CV zostało obejrzane przez przynajmniej 3 osoby, które powinny zapisać swoje inicjały oraz ocenę (1-3). Przedyskutujcie te CV, dla których uzyskaliście dużą rozbieżność ocen.
  8. Przysłuchaj się telefonicznej rozmowie z kandydatem na stanowisko programisty. Zapisuj swoje przemyślenia, oceń kandydata a następnie porozmawiaj z osobą przeprowadzającą rozmowę, żeby dowiedzieć się, czy doszliście do takich samych wniosków.
  9. Przeprowadź techniczną rozmowę z kandydatem, który jest ekspertem w swojej dziedzinie, a o której Ty za wiele nie wiesz. Poproś go o tłumaczenie zagadnień od samych podstaw, zakładając Twój brak jakiejkolwiek wiedzy na ten temat. Mocno się postaraj nadążać za tym, co mówi, w razie potrzeby zadając dodatkowe pytania.
  10. Postaraj się o możliwość uczestnictwa w czyjejś rozmowie rekrutacyjnej. Słuchaj i ucz się. Próbuj w głowie rozwiązywać zadania stawiane kandydatowi, podczas gdy on sam pracuje nad ich rozwiązaniem.
  11. Znajdź kogoś, z kim będziesz mógł wymieniać się pytaniami ćwiczebnymi. Zadawajcie sobie pytania programistyczne na zmianę, co tydzień. Poświęcajcie od 10 do 15 minut na próby rozwiązania problemu i 10 do 15 minut na dyskusję (niezależnie od tego, czy rozwiązanie zostało znalezione).
  12. Gdy usłyszysz jakieś rekrutacyjne zadanie programistyczne, którego jeszcze sam nie rozwiązywałeś, wróć do biurka i wyślij sobie to zadanie na maila jako przypomnienie. Rozwiąż to zadanie w wolnej chwili w tym samym tygodniu, używając swojego ulubionego języka programowania.

Lista Steve'a podoba mi się, ponieważ jest do pewnego stopnia holistyczna. Niektórzy programiści, gdy słyszą termin "trening", nie są w stanie wyjść ponad programistyczne puzzle. Natomiast dla mnie w programowaniu bardziej chodzi o ludzi, nie kod, tak więc jest pewna granica rozwoju, której nie przekroczysz, rozwiązując nawet najbardziej zawiły na tej planecie problem programistyczny z rozmowy rekrutacyjnej.

Podobają mi się również ogólne wskazówki Petera Norviga na temat ukierunkowanego uczenia się, które zawarł w artykule Naucz się programowania w 10 lat.

  1. Rozmawiaj z innymi programistami. Czytaj cudzy kod. Jest to ważniejsze niż jakakolwiek książka czy kurs.
  2. Programuj! Najlepszy sposób uczenia się polega na nauce poprzez robienie.
  3. Uczęszczaj na zajęcia z programowania na poziomie licencjackim bądź uniwersyteckim.
  4. Poszukuj i pracuj nad projektami zespołowymi. Przekonaj się, jak to jest być zarówno najlepszym, jak i najgorszym programistą w zespole.
  5. Pracuj nad projektami po tym, jak ich oryginalni autorzy zaprzestali się nimi zajmować. Naucz się, jak utrzymywać kod nienapisany przez Ciebie. Naucz się pisać kod, który ludzie po Tobie będą w stanie efektywnie utrzymywać.
  6. Naucz się różnych języków programowania. Wybierz języki, których modele programowania są odmienne od tego, czego używasz na co dzień.
  7. Dowiedz się, jak sprzęt wpływa na to, co robisz. Jak długo zajmuje Twojemu komputerowi wykonanie pojedynczej instrukcji, pobranie słowa z pamięci (z cachem i bez), przesłanie danych przez kabel ethernetowy (lub przez Internet), przeczytanie następujących po sobie słów z dysku albo przeskoczenie do nowego miejsca na dysku?

Inspiracji możesz również poszukać, czytając Dave'a 21 pragmatycznych kata programistycznych, a może chciałbyś przyłączyć się do Programistycznego Dojo w Twojej okolicy.

Ja sam nie mam tak długiej listy ćwiczeń jak Steve, Peter czy Dave. Jestem zbyt niecierpliwy na coś takiego. Właściwie to w mojej książce o programistycznym kata znajdują się dwie pozycje:

  1. Prowadź bloga. Ja sam zacząłem pisać tego bloga na początku 2004 roku właśnie jako formę ćwiczenia. Zaczynając skromnie, później okazało się, że jest to jedna z najbardziej znaczących rzeczy, które zrobiłem w swojej zawodowej karierze. Ty również powinieneś prowadzić bloga. To właśnie ludzie, którzy potrafią pisać i efektywnie się komunikować, są często tymi, których się słucha. To oni mogą dyktować warunki debaty.
  2. Aktywnie udzielaj się w jakimś znanym projekcie open-source'owym albo trzech. Całe to gadanie bla bla bla jest super, ale czy jesteś gawędziarzem czy człowiekiem czynu? Jest to bardzo ważne, ponieważ rozliczany będziesz ze swoich czynów, nie słów. Postaraj się zostawiać za sobą ślad konkretnych, publicznych i użytecznych rzeczy, na które możesz wskazać i powiedzieć: pomogłem to zbudować.

Gdy już potrafisz pisać genialny kod i genialną prozę, za pomocą której ten kod objaśniasz światu — cóż, wydaje mi się, że to jest właśnie ostateczne programistyczne kata.

Data publikacji oryginału: czerwiec 22, 2008

Dupkowatość

Oryginalny post: Douchebaggery

Autor: Jeff Atwood

David Heinemeier Hansson ma problem z systemem Windows jako platformą do programowania.

O ile naturalnie potrafię zrozumieć powody, dla których niektórzy wybierają Linuxa, to w ogóle nie potrafię zrozumieć programistów, którzy świadomie wybierają Windowsa jako swoją platformę. Znam kilku, którzy ciągle tkwią w rutynie z różnych powodów — żaden z nich tego nie pragnie.

Miałbym trudność w wyobrażeniu sobie, iż zatrudniam do 37signals kogoś, kto tkwi na platformie Windows. Jeśli wystarczająco nie dbasz o to, aby wykorzystywać najlepsze narzędzia, udowodnienie postawionej przez Ciebie tezy staje się o wiele trudniejsze.

Tak więc jeśli jeszcze się nie przekonwertowałeś, przestań prokrastynować. Przebolej to. Jeśli pragniesz pracować dla coraz bardziej znaczących firm, które budują swój biznes w oparciu o technologie open source'owe, to nie chcesz ciągnąć za sobą takiego piętna w życiorysie. Bycie tym, który przekonwertował się w 2005 roku jest wystarczająco złe.

Mocna inwektywa, ale taki jest styla David'a. Aby być uczciwym, jego najważniejszy argument — że jeśli cenisz sobie programowanie aplikacji open source'owych, to będziesz używał platformy przyjaznej oprogramowaniu open source'owemu — jest dość przekonujący, choć oczekiwałbym, iż zatwardziali kolesie od OSS będą chcieli Wolności 0 zarówno w swoich systemach operacyjnych jak i w oprogramowaniu, które tworzą. Jeśli miałbym aż tak silne przekonania co do OSS, to szczerze powiedziawszy postrzegałbym ludzi tkwiących na platformie OS X z lekkim podejrzeniem.

Ale czy konieczne jest takie uogólnianie? Sugerować, że programiści używający Windows'a "nie dbają dostatecznie o to, aby używać najlepszych narzędzi"? Po tysiącach religinych wojen, w których uczestniczyłem, uodporniłem się na krytykę, więc ta nie porusza mnie za bardzo. Nie zgodzę się z problemem David'a, ponieważ jeśli chodzi o komputery i systemy operacyjne, to nie ma czegoś takiego jak "najlepszy". Moja opinia jest taka, że wszystkie są beznadziejne. Oczywiście, są pewne kompromisy, zalety i wady, mocne i słabe punkty. Ale obiektywnie najlepszy? Wszystko jest względne.

Zanim wszyscy naskoczycie na David'a, przeczytajcie jego wpisy kontynuujące myśl (pierwszy, drugi) na grupach dyskusyjnych Ruby, które tłumaczą jego stanowisko w bardziej spójny i mniej burzący sposób. Argument za tym, że 37signals nie zatrudniłoby programisty operującego na systemie Windows ma tyle wspólnego z kulturą, co nic innego. To tak, jakby pokazać się na przesłuchaniu w sprawie pracy w firmie Coca-Cola siorbiąc sobie Pepsi. Na nieszczęście, David poczuł potrzebę przeobrażenia tego wymagania w kwestię gustu. Ogłosił, iż Coca-Cola jest moralnie i estetycznie lepszym wyborem, aniżeli zwykłą preferencją na konkretny rodzaj słodzonego napoju, którym tak naprawdę jest.

Ten wpis został napisany w marcu 2005 roku, ale David wyraził te same uczucia we fragmencie z i-Technology Predictions for 2007.

Apple będzie beształo każdego za jego preferowaną platformę. Piętno bycia programistą webowym używającym platformy Windows będzie narastać.

To jest to, czego nie rozumiem w tego typu stwierdzeniach. Mają zupełnie odwrotny skutek, niż ten zakładany przez mówcę. Są dwie możliwe reakcje:

  1. Wow, David ma rację. Dokonałem złego wyboru w mojej karierze. Najwyższy czas, aby przyjrzeć się platformie OS X oraz programowaniu w Rails. To brzmi świetnie!
  2. P****************ol się.

Zgadnij, która reakcja jest bardziej powszechna? W zasadzie, to nie trzeba zgadywać jako, iż zapewniam Cię, że każdy programista platformy Windows, który to czyta, myśli teraz o punkcie #2. Jako ewangelista chcący zwiększyć popularność swojej platformy, używa wybitnie kiepskiej strategii. Czy przymuszanie ludzi do tego, aby się z Tobą zgodzili kiedykolwiek skutkowało?

Oczywiście, tak jak David mówił wiele, wiele razy, nie obchodzi go, czy się z nim zgadzamy czy nie. Cóż, może nie w tylu słowach, ale rozumiesz przesłankę:

David Hainemeier Hansson: Fuck You

Prawdę mówiąc doceniam to uczucie, ponieważ widziałem zbyt wielu ludzi, którzy dali się pochłonąć przez to, że inni ludzie myśleli o nich, że nie potrafią potwierdzić swojej początkowej opinii na temat czegokolwiek. Ale jeśli zaakceptujesz przesłankę, że takie stwierdzenie nie jest w stanie zmienić niczyjego zdania i ostatecznie jest nieefektywne — a nawet przynoszące efekt odwrotny do zamierzonego — z czym pozostajemy? Jaką intencję niesie za sobą wyrażenie "piętno bycia programistą na platformę Windows"? Mnie przychodzi do głowy tylko jedna: mówienie o innych źle sprawia Davidowi przyjemność.

A to, czyni z niego pewnego rodzaju dupka.

Co również oznacza, że jeśli używasz Rails'ów oraz OS X, to używasz platformy z wyboru dla dupków.

Samurai Shodown 2 character select screen

Byłem kiedyś zapalonym graczem Samurai Shodown II. Grałem jako Earthquake, niesamowicie gruby, niesamowicie teksański ninja. Stałem się tak dobry w graniu postacią Earthquake, że byłem w stanie pokonać każdego, kto przybył na Colorado arcade do Boulder, gdzie często bywałem. Przyczyniło się to do komentarza jednego sfrustrowanego gracza:

Jesteś do kitu! Dokopujesz nam za pomocą najgorszej postaci w grze!

W rzeczy samej. Nie ma nic bardziej satysfakcjonującego, niż skopanie komuś tyłka za pomocą najgorszej postaci w grze. Po jakimś czasie grania w tę nadzwyczaj zbalansowaną bijatykę, uzmysłowiłem sobie, iż każda możliwa postać ma swoje wady i zalety. Opanowanie gry oznacza zrozumienie postaci oraz maksymalizowanie działania swoich mocy przy jednoczesnym wykorzystywaniu słabości przeciwnika. Jeśli byłeś wystarczająco mądry i cierpliwy, mógłbyś pokonać dowolną postać za pomocą każdej innej. To była umiejętność.

Nie trać czasu na kłótnię o ekranie wyboru postaci. Wyniki mówią wyraźnie. Pokaż światu, co potrafisz w wybranym przez siebie środowisku programistycznym.

Data publikacji oryginału: 26 lutego, 2008

Related Posts with Thumbnails