Prostota

Oryginalny post: Simplicity

Autor: Joel Spolsky

Donald Norman stwierdza, że prostota jest przereklamowana: "Ale kiedy przyszedł moment, aby dziennikarze zrecenzowali 'proste' produkty, wszyscy narzekali na brak kluczowych wg nich funkcjonalności. Co więc ludzie mają na myśli, kiedy chcą prostoty? Operacje wywoływane pojedynczym przyciskiem -- oczywiście -- ale wraz ze wszystkimi swoimi ulubionymi funkcjonalnościami".

Dawno temu pisałem: "Wielu programistów zostało zwiedzionych starą zasadą 80/20. Na pierwszy rzut oka zdaje się to mieć sporo sensu: 80% użytkowników wykorzystuje 20% dostępnych funkcjonalności. Więc przekonujesz samego siebie, że wystarczy zaimplementować tylko 20% funkcjonalności i sprzedawać 80% kopii programu.

Niestety, to nigdy nie jest te same 20%. Każdy używa innych funkcji. Przez ostatnie 10 lat słyszałem o dziesiątkach firm zdeterminowanych, aby nie uczyć się od pozostałych. Próbowali wypuścić 'lekki' edytor tekstu, który implementowałby 20% funkcjonalności. To historia stara jak PC. W większości przypadków dawali swój program do recenzji dziennikarzowi, a on do napisania recenzji wykorzystywał ten nowy edytor. Kiedy dziennikarz próbował znaleźć funkcję do policzenia słów w tekście - której potrzebował, bo większość dziennikarzy ma narzucony limit słów - orientował się, że takiej funkcji nie ma, że jest w tych 80%, których nikt nie używa. Ostatecznie dziennikarz pisał artykuł i stwierdzał, że 'lekkie' programy są dobre, przeciążanie funkcjonalnością jest złe, i że nie może używać tego cholerstwa, "bo nie policzy moich słów".

Tworzenie prostych, 20%-owych produktów jest doskonałą strategią na wystartowanie. Możesz stworzyć je przy ograniczonych zasobach i zdobyć klientów. To strategia Judo - wykorzystanie słabości jako siły, tak jak w Blair Witch Project. Dzieciaki nakręciły film bez żadnych pieniędzy, ręczną kamerą. Fabuła była skonstruowana w ten sposób, że było to zaletą. Sprzedajesz więc 'prostotę', jakby było to coś wspaniałego, a niejako przypadkowo jest to jedyna rzecz jaką ze swoimi środkami możesz wyprodukować. Cóż za szczęśliwy zbieg okoliczności, to doprawdy cudowne!

Ale to co działa dla startupu, moim zdaniem, nie zadziała już jako strategia długookresowa. Nie ma możliwości powstrzymania kolejnego dwuosobowego startupu przed sklonowaniem twojej prostej aplikacji, no i nie możesz walczyć z ludzką naturą: "ludzie chcą tych funkcjonalności", mówi Norman. To że ręczna kamera była idealna dla Blair Witch, to jeszcze nie znaczy, że każdy hollywoodzki szlagier będzie ją wykorzystywał.

Apple iPod Wyznawcy prostoty przywołają 37signals oraz iPod Apple'a jako dowody na to, że prostota się sprzedaje. Uważam że w obu tych przypadkach sukces jest wynikiem połączenia wielu rzeczy: wykreowania grupy odbiorców, ewangelizacji, przejrzystego designu, zaangażowania emocjonalnego, estetyki, szybkiego reagowania, bezpośredniego feedbacku od użytkowników. Model oprogramowania dopasowany do modelu użytkowników daje w rezultacie łatwość w użytkowaniu i kontrolę osobom korzystającym z programu. Są to funkcjonalności (cechy) tego samego rodzaju, w tym sensie, że użytkownicy lubią i chcą za nie płacić, ale żadna z nich tak naprawdę nie może być nazwana 'prostą'. Przykładowo, iPod ma cechę bycia ładnym, której nie ma Creative Zen Ultra Nomad Jukebox, więc poproszę iPoda. W przypadku iPoda bierze się to z przejrzystego i prostego designu, ale nie musi tak być. Hummer jest estetycznie pociągający dokładnie dlatego, że jest brzydki i skomplikowany.

Mówienie, że iPod odniósł sukces, ponieważ ma mało funkcji jest moim zdaniem nieporozumieniem. Jeśli zaczniesz w to wierzyć, będziesz wierzył, że aby zwiększyć sukces swojego produktu, powinieneś usuwać z niego funkcjonalności. Z sześcioletniego doświadczenia w prowadzeniu własnej firmy programistycznej mogę Ci powiedzieć, że w Fog Creek nic nigdy nie zwiększyło naszych dochodów bardziej niż wypuszczenie nowej wersji programu z większą liczbą funkcji. Nic. Wpływ nowych wersji z nowymi funkcjami na nasze zyski jest absolutnie niepodważalny. To jak grawitacja. Kiedy testowaliśmy reklamy Google, kiedy realizowaliśmy różne programy partnerskie, albo kiedy pojawiał się artykuł o naszym produkcie (FogBugz) w prasie, ledwo dostrzegaliśmy wpływ na zyski. Natomiast kiedy wychodziła nowa wersja z nowymi funkcjami, widzieliśmy niezaprzeczalny, znaczny i stały wzrost dochodów.

Jeśli używasz terminu 'prostota' w odniesieniu do produktu, w którym model użytkownika koresponduje z modelem programu, tak, że produkt jest łatwy w użyciu, super, plus dla Ciebie. Jeśli używasz terminu 'prostota' w odniesieniu do produktu z oszczędnym i czystym wyglądem, jakby termin nie znaczył nic innego ponad opisywanie wrażeń estetycznych, super, plus dla Ciebie. Minimalistyczna estetyka jest dziś czymś ekstra. Ale jeśli myślisz, że prostota znaczy "niezbyt dużo funkcji" albo "robi jedną rzecz a dobrze", wtedy pochwalę Twoją szczerość, ale nie zajedziesz daleko z produktem, który celowo został okrojony z funkcjonalności. Nawet iPod ma darmową grę Solitaire. Nawet Ta-da List wspiera RSS.

Tymczasem, lecę... czas najwyższy wymienić moją komórkę na taką, która ma szybki dostęp do internetu, e-maila, podcastów i odtwarzacz MP3.

Data publikacji oryginału: 9 grudnia, 2006

Karta Praw Programisty

Oryginalny post: The Programmer's Bill of Rights

Autor: Jeff Atwood

To niewiarygodne, że firma jest w stanie płacić programiście $60-$100k rocznie, a przy tym upośledzać go okropnymi warunkami pracy oraz obdartym sprzętem z drugiej ręki. Nie ma w tym żadnego biznesowego sensu. A jednak dostrzegam to przez cały czas. Szokujące jest to, jak wiele przedsiębiorstw wciąż nie dostarcza programistom niezbędnych rzeczy do osiągnięcia celu.

Proponuję abyśmy przyjęli Kartę Praw Programisty, by chronić ich praw poprzez uniemożliwianie firmom zabraniania im podstaw potrzebnych do skutecznej pracy.

  1. Każdy programista powinien mieć dwa monitory

    W obliczu spadających cen paneli LCD oraz wszechobecnych kart video z podwójnymi wyjściami, musiałbyś być głupcem, by ograniczać swoich programistów do jednego ekranu. Korzyści płynące z podwojenia swojego pulpitu są teraz dobrze udokumentowane. Jeśli chcesz zmaksymalizować efektywność programisty, upewnij się, że każdy z nich ma dwa monitory.

  2. Każdy programista powinien mieć szybki komputer

    Programiści muszą mieć uruchomionych wiele aplikacji, aby wykonywać swoją pracę: środowiska programistyczne, silniki bazodanowe, serwery webowe, wirtualne maszyny, itd. Aby to wszystko działało potrzebny jest szybki komputer z dużą ilością pamięci. Im szybszy komputer programisty tym krótszy czas kompilacji. Nierozsądnym by było, gdybyś płacił olbrzymie kwoty za najwydajniejszy sprzęt -- ale zawsze upewnij się, że kupujesz sprzęt z prawie najwyższej półki. Wyposaż swoich programistów w szybkie komputery z dużą ilością pamięci. Czas spędzony na gapieniu się w pasek postępu to zmarnowany czas.

  3. Każdy programista powinien mieć możliwość wyboru myszy oraz klawiatury

    Na studiach prowadziłem firmę malarską. Każdy malarz, którego zatrudniałem, musiał kupić własne pędzle. To była jedna z pierwszych rzeczy, których się nauczyłem. Zaopatrywanie malarzy w standardowy pędzel nie zdawało egzaminu. "Firmowe" pędzle były szybko zaniedbywane i zużywane do stanu, w którym wymagały naprawy. Ale malarze, którzy sami kupowali swoje pędzle, dbali o nie. Malarze, którzy sami kupowali swoje pędzle, nauczyli się doceniać różnice pomiędzy ich pędzlem za $20 a tanimi jednorazowymi pędzlami. Posiadanie swojego własnego pędzla wywoływało trwałą odpowiedzialność i kunszt. Programiści powinni być w takich samych stosunkach ze swoją klawiaturą i myszką -- to najbardziej istotne narzędzia w naszej codziennej pracy, których używamy, aby uprawiać swoje rzemiosło.

  4. Każdy programista powinien mieć wygodne krzesło

    Spójrzmy prawdzie w oczy. Zarabiamy na życie siedząc 8 godzin dziennie na swoich tyłkach. Czemu by nie spędzać tych 8 godzin na wygodnym, dobrze zaprojektowanym krześle? Daj programistom krzesła, na których siedzenie przez 8 godzin nie jest tylko znośne, ale jest przyjemne. Oczywiście, zatrudniasz programistów przede wszystkim dla ich umysłów, ale nie zapominaj o innych wartościowych rzeczach programisty.

  5. Każdy programista powinien mieć szybki dostęp do Internetu

    Dobrzy programiści nigdy nie piszą czegoś, co mogą ukraść. A Internet jest najlepszym kanałem dla kradzionych rzeczy jaki kiedykolwiek wynaleziono. Jak najbardziej jestem za książkami, ale ciężko jest sobie wyobrazić wykonaną robotę bez szybkich przeszukań Internetu, które są na wyciągnięcie ręki.

  6. Każdy programista powinien mieć ciche środowisko pracy

    Programowanie wymaga umysłowej koncentracji. Programiści nie mogą pracować efektywnie w środowisku pełnym zakłóceń. Upewnij się, że Twoje środowisko pracy chroni stan skupienia programistów, w przeciwnym razie będą tracić oni mnóstwo czasu na powracanie do tego stanu po zaburzeniu.

Te kilka praw, o które prosimy, są łatwe. To nie są ekstrawaganckie wymagania. Są one podstawą jakości miejsca pracy programisty. Przestrzeganie tych praw nie jest ani kosztowne ani trudne -- jeśli firma, dla której pracujesz tego nie robi. Domagaj się swoich praw jako programista! I pamiętaj: możesz albo zmienić swoją firmę, albo zmienić swoją firmę.

Data publikacji oryginału: 24 sierpnia, 2006

Inwestowanie w dobrej jakości krzesło do programowania

Oryginalny post: Investing in a Quality Programming Chair

Autor: Jeff Atwood

W Drugiej najważniejszej rzeczy programisty opisałem, jak zakup dobrego jakościowo krzesła może być jedną z najmądrzejszych inwestycji, jaką możesz zrobić, będąc programistą.

W rzeczywistości, po poszukiwaniach krzeseł przez ostatnich kilka lat mojej kariery, doszedłem do jednego wniosku: nie możesz oczekiwać, że uda Ci się dostać porządne krzesło za mniej niż $500. Jeśli zamierzasz wydać mniej niż tyle na siedzenie -- chyba, że robisz interes życia na aukcjach po bankrutujących dot-comowych firmach -- prawdopodobnie popełniasz błąd.

Nadal uważam, że to prawda i nalegam, aby każdy programista, który to czyta, poważnie rozważył wartość tego, na czym siedzi podczas gdy pracuje. W naszej profesji miejsce do siedzenia ma znaczenie:

  • Krzesła są podstawową częścią doznań podczas programowania. Osiem godzin dziennie, każdego dnia, przez resztę Twojego zawodowego życia -- siedzisz na jednym z nich. Czy Ci się to podoba czy nie, bez względu na to na czym siedzisz, ma to wymierny wpływ na Twoje doznania podczas pracy.
  • Tanie krzesła są do bani. Może stałem się nieco zepsuty, ale nie miałem jeszcze okazji siedzieć na dobrym, tanim krześle. W moim doświadczeniu różnica pomiędzy naprawdę świetnymi krzesłami a tanimi jest ogromna. Dobre jakościowo krzesło jest tak wygodne i niedające o sobie znać, że możesz skupić się na swojej pracy. Nędzne, tanie krzesło przypomina Ci bez przerwy, jak wiele godzin pracy jeszcze Ci zostało.
  • Krzesła są trwałe. W momencie gdy to piszę, nadal siedzę w swoim oryginalnym krześle Aeron, które kupiłem w 1998 roku. Nie przypominam sobie o jakimkolwiek innym sprzęcie, którego używam w mojej pracy, i który przetrwał przez dziesięć pełnych lat i więcej. Podczas gdy początkowy szok cenowy dobrego jakościowo krzesła może Cię odrzucić, spróbuj w myśli zamortyzować ten koszt na następne dziesięć lub więcej lat.

Problem wyboru siedzenia jest nieodłącznie związany z branżą tworzenia oprogramowania, w przeciwieństwie do wszystkich innych aspektów, które podlegają nieustannym zmianom. Krzesła są długoterminową inwestycją. Dlaczego by nie wybierać krzesła z taką samą troską i rozważaniami, z którymi podejmujesz inne strategiczne decyzje, które będą trwać do końca Twojej kariery? Skąpienie na krześle po prostu nie ma sensu.

Mimo iż byłem całkiem zadowolony ze swojego krzesła Herman Miller Aeron przez ostatnie 10 lat, to zawsze byłem odrobinę rozczarowany sposobem, w jaki został on skojarzony z dot-comową przesadą.

W latach 90-tych Aeron stał się emblematem bańki dot-comowej; symbolizował mobilność, szybkość, efektywność i tygodnie pracy po 24 godziny dziennie. Aeron był czymś, co każdy gorący startup musiał mieć, ponieważ nie wyglądał on jak mebel biurowy: był bardziej jak kawałek maszyny albo surowej techniki. Czarna siatka Pellide była wytrzymała i skrywała wszystkie plamy po Joltcie czy Red Bullu. Napięta przez aluminiową ramę siatka, pozwalała powietrzu cyrkulować i utrzymywać Twoje ciało schłodzone. Co więcej, krzesło wyszło w trzech rozmiarach, niczym spersonalizowane narzędzie. Wyposażone w gałki i dźwignie pozwalało Ci na dostosowanie wysokości siedzenia, siły nachylenia, obszaru nachylenia, nachylenia do przodu, wysokości ramion, szerokości ramion, rozstawu ramion, głębokości lędźwi i ich wysokości. Aeron był zaawansowany technologicznie, ale jednocześnie sexy -- jak to postrzegali dot-commersi.

Ale młodzi prezesi nie czuli sympatii do Aerona tylko za to, jak wyglądał. Aeron był wizualną ekspresją antykorporacyjnego ducha czasu, niehierarchicznej filozofii miejsca pracy. Biuro pełne Aeronów niejawnie odrzucało ranking Fortune 500, garnitury oraz tradycyjny model firmy, w którym szef siedział na przesadnie drogim i wielkim, skórzanym dinozaurze, podczas gdy jego sekretarka balansowała na stołku z Office Max robiąc notatki.

Ostatnio, gdy byłem w podróży, miałem okazję siedzieć na nowszym krześle Herman Miller Mirra i byłem zaskoczony, o ile wygodniej było mi w nim niż w moim klasycznym Aeronie.

Krzesło Mirra było także świetną leżanką. Byłem zawiedziony tym, jak słabo pochyla się Aeron. Właściwie to złamałem raz gałkę do pochylania w moim Aeronie i musiałem ją sam wymienić. Zatem nauczyłem się już nie pochylać, co jest niezręczne jako, iż z natury lubię leżakować.

To wszystko spowodowało, iż zacząłem się zastanawiać nad wysłaniem mojego Aerona na emeryturę, a samemu sprawić sobie coś lepszego. Podobało mi się krzesło Mirra, ale komentarze do mojego oryginalnego wpisu o krzesłach zawierały wiele innych sugestii co do siedzeń. Poniżej przedstawiam zdjęcia i odnośniki do krzeseł, które były najczęściej wymieniane jako konkurencyjne jako dodatek do pokazanych wcześniej Mirry i Aerona:

Steelcase Think Chair

Steelcase Leap Chair

Ergohuman Mesh Chair

HumanScale Freedom Chair

HumanScale Liberty Chair

Było również parę mniej znanych rekomendacji takich, jak krzesła Haworth Zody, Nightingale CXO, BodyBilt ergo, Hag kneeling, NeutralPosture ergo, Chadwick Chair od projektanta Aerona oraz coś co się nazywało The Swooper.

Dopasowanie krzesła jest oczywiście sprawą subiektywną. Jeśli inwestujesz $500 bądź więcej w krzesło, rzeczą zrozumiałą byłoby, iż chciałbyś być pewien, że jest to "to jedyne". Rzeczą jaką należy zrobić, jest znalezienie lokalnego sklepu, który sprzedaje wszystkie te krzesła i wszystkie je wypróbować. Cóż, powodzenia z tym życzę. Nawet nie próbuj z Twoim lokalnym sieciowym supermarketem. Najlepszym wyborem wydają się być specjalne sklepy z krzesłami, gdyż mają one zazwyczaj na stanie bardziej egzotyczne krzesła. Najwyraźniej mają oni klientów, którzy są w stanie zapłacić za komfort.

Recenzje pojedynczych krzeseł są względnie łatwe do znalezienia, ale nie są pomocne, gdy nie ma porównania. To czego potrzebujemy, to zbiorowy przegląd krzeseł. Jedyny godny uwagi przegląd jaki znam, to przegląd Slate'a z końca 2005 roku Sit Happens: The Search for the Best Desk Chair. Nie jest on tak wszechstronny, jak bym chciał, ale zawiera większość głównych kandydatów. Zwycięzcą Slate'a było krzesło HumanScale Liberty.

Oto kilka innych pomocnych źródeł, które znalazłem zarówno w komentarzach do tego wpisu jak i gdzie indziej:

Jeśli to trochę za dużo meblowej pornografii jak na Wasz gust, to rozumiem. Jeśli chodzi o mnie, to skierowałem się do lokalnego, zaprzyjaźnionego sklepu, by dojść do tego, które z tych krzeseł najlepiej zastąpi mojego starzejącego się Aearona. Według moich kalkulacji, Aeron kosztował mnie około $7 miesięcznie przez dziesięć lat jego życia; myślę, że moje trwające zdrowie i komfort podczas programowania jest warte conajmniej tyle.

Aktualizacja: Jako iż ludzie mnie wypytują, ostatecznie zdecydowałem się, że osobiście najbardziej pasuje mi krzesło Herman Miller Mirra. W porównaniu do mojego dziesięcioletniego Aerona to duże ulepszenie. Jest jakby o trzy bądź cztery poprawki lepszy. Na przykład, przednia część siedzenia jest regulowana, co rozwiązuje problem, który miałem z moim Aeronem -- poodbnie jak lepsze pochylanie, o którym wcześniej wspominałem. Jedyną nieprzewidzianą wadą jest to, że plastikowe oparcie jest nieco szorstkie dla skóry, jeśli siedzisz, yy.. bez koszulki. Mimo iż jestem bardzo zadowolony z mojego nowego krzesła Mirra z żółtym oparciem (pic), namawiam Cię do wypróbowania krzeseł przed podjęciem decyzji.

Data publikacji oryginału: lipiec 4, 2008

Postępowanie z zakałami projektu

Oryginalny post: Dealing With Bad Apples

Autor: Jeff Atwood

Robert Miesen przysłał mi następującą historię o patologii projektu:

Byłem częścią zespołu, który pisał internetowy system do aplikowania o pracę i klasyfikowania kandydatów (klient nazywał to kioskiem pracy). Razem z zespołem i klientem uzgodniliśmy, że do zaimplementowania tego kiosku użyjemy Windowsa, Apache'a, PHP5 oraz ZendFrameworka -- wszyscy się na to zgodzili oprócz jednego członka zespołu, którego będę nazywał "Joe". Przez całą fazę ustalania technologii Joe zalecał użycie JavaScriptu mimo, iż klient całkiem jasno określił oczekiwania, że większość kiosku, wraz z całą walidacją, ma być zaimplementowana z użyciem technologii po stronie serwera.

Fakt, iż klient to zatwierdził, jakkolwiek, nie powstrzymał Joe od dalszego zachęcania do JavaScriptu -- o zgrozo. Za każdym razem, gdy nasz projekt napotykał na przeszkody, Joe rozpoczynał tyradę o tym, o ile prostsze byłoby nasze życie, jeżeli tylko pisalibyśmy ten kiosk z użyciem JavaScriptu. Joe ciągle sprzeczał się o to, że wszystko co robimy jest źle, ponieważ nie robimy tego za pomocą JavaScriptu. Nie pofatygował się nawet nauczyć technologii, których używaliśmy, a kiedykolwiek jakiś kolega z zespołu próbował grzecznie przywrócić go do porządku (zazwyczaj używając poczty elektronicznej), Joe po prostu obrażał biedaka. W swoim najgorszym momencie pro-JavaScriptowego fanatyzmu Joe regularnie rzucałby komentarzami w stylu: "Cóż, jeśli tylko robilibyśmy to za pomocą JavaScriptu,", do tego stopnia, że zespół lepiej by na tym wyszedł, gdyby Joe odszedł (albo został przeniesiony bądź zwolniony).

Po przeczytaniu tej historii, musiałem powstrzymać się od chęci pochylenia się do przodu, podparcia brody w zamyśleniu, zmarszczenia czoła i zapytania -- czy próbowaliście JavaScriptu?

Robert myślał, że to była ostrzegawcza historia na temat uzależnienia od technologii, ale ja dostrzegam co innego: problematyczny członek zespołu, typowa zakała.

Jestem pewien, że "Joe" miał najlepsze intencje, ale w momencie, gdy aktywnie agitujesz przeciwko projektowi i postępujesz wbrew woli kolegów z zespołu -- jesteś obciążeniem dla projektu.

Koszt problematycznego personelu w projekcie jest poważny, jak jest to opisane w rozdziale 12 książki McConnella Rapid Development: Taming Wild Software Schedules.

Jeśli tolerujesz choć jednego programistę, którego reszta uważa za problem, ranisz morale dobrych programistów. Dajesz do zrozumienia, że nie tylko oczekujesz tego, aby pracownicy dawali z siebie wszystko; oczekujesz od nich, aby to robili, kiedy inni współpracownicy pracują przeciwko nim.

W przeglądzie 32 zespołów zarządzających, Larson i LaFasto zauważyli, iż najczęstsze skargi od członków zespołu dotyczyły tego, że ich kierownicy byli niechętni do konfrontacji i rozwiązywania problemów związanych z kiepską wydajnością, spowodowaną indywidualnymi członkami zespołu. (Larson i LaFasto 1989). Donoszą, iż "bardziej niż przez jakikolwiek inny aspekt przywództwa, wydajność pracowników jest zaburzona przez kierowników, którzy są niechętni do bezpośredniego i efektywnego radzenia sobie z egoistycznymi oraz nieprzykładającymi się współpracownikami." Dalej dochodzą do tego, iż jest to kluczowy problem, którego nie dostrzega kadra zarządzająca, ponieważ menedżerowie zawsze uważają, że ich zespoły lepiej sobie radzą, niż członkowie tych zespołów.

Jak identyfikujemy problem z personelem? To nie takie trudne jakby mogło się wydawać. Kiedyś jeden z moich przyjaciół określił kogoś w swoim zespole -- i to jest dosłowny cytat -- mianem "raka". W momencie kiedy Ty bądź ktokolwiek inny z zespołu używacie słów typu rak do opisania kolegi, macie doczynienia z poważną patologią projektu. Nie musicie się przyjaźnić z każdym członkiem projektu, niemniej jednak to pomaga, ale pewien podstawowy poziom osobistego i profesjonalnego szacunku jest konieczny w każdym zespole, by normalnie funkcjonować.

Steve przedstawia kilka znaków ostrzegawczych mówiących o tym, że macie do czynienia z zakałą w zespole:

  1. Ukrywają swoją niewiedzę zamiast uczyć się od współpracowników. "Nie wiem jak wyjaśnić mój projekt; Po prostu wiem, że działa." albo "Mój kod jest zbyt skomplikowany, by go testować." (Oba stwierdzenia są prawdziwymi cytatami.)
  2. Posiadają nadmierną potrzebę prywatności. "Nie potrzebuję, aby ktokolwiek przeglądał mój kod."
  3. Są terytorialni. "Nikt poza mną nie może poprawiać błędów w moim kodzie. Teraz jestem zbyt zajęty, by je poprawić, ale zrobię to w następnym tygodniu."
  4. Narzekają na decyzje zespołu i powracają do starych dyskusji długo po tym, jak zespół ruszył dalej. "Wciąż uważam, iż powinniśmy się cofnąć i przeprojektować to, o czym rozmawialiśmy w zeszłym miesiącu. To, na co się zdecydowaliśmy nie będzie działało."
  5. Zespół dowcipkuje bądź narzeka regularnie na tę samą osobę. Programiści często nie narzekają bezpośrednio, więc musisz popytać, czy jest jakiś problem, gdy słyszysz wiele żartobliwych komentarzy.
  6. Nie udzielają się w aktywnościach zespołu. W jednym z projektów, w których pracowałem, na dwa dni przed ostatecznym terminem, programista poprosił o dzień urlopu. Powód? Chciał spędzić dzień na wyprzedaży odzieży męskiej w pobliskim mieście -- wyraźny znak, że nie zintegrował się z zespołem.

Pozwól, że wyrażę się jasno na ten temat: jeśli Twój team leader bądź menedżer nie radzi sobie z zakałami w Twoim projekcie, to nie wykonuje on swojej pracy.

Nigdy nie powinieneś obawiać się usunięcia -- albo nawet zwolnienia -- ludzi, w których interesie nie leży dobro zespołu. Możesz rozwinąć umiejętność, ale nie możesz rozwinąć pozytywnego nastawienia. Im dłużej te zakłócające spokój osobistości są uwikłane w projekt, tym gorszy tego efekt. Będą powoli rozsiewać truciznę w Twoim projekcie, w formie kodu, stosunków oraz kontaktów.

Usuwanie kogoś z zespołu jest bolesne; dla nikogo nie jest zabawne. Ale zdanie sobie sprawy z tego, że powinno się usunąć kogoś sześć miesięcy temu, jest o wiele bardziej bolesne.

Data publikacji oryginału: kwiecień 17, 2008

Biały znak: cichy zabójca

Oryginalny post: Whitespace: The Silent Killer

Autor: Jeff Atwood

Zdarzyło Ci się kiedyś mieć taki dzień, w którym wszystko, co wysyłałeś do systemu kontroli wersji, było złe?

Tak w ogóle, to czym dokładnie taki dzień różni się od każdego innego? Ale bądźmy poważni.

Kod, który jest widoczny to kod, który może być niepoprawny. Nie powinno to być zaskoczeniem. Ale czy wiesz, że nawet kod, którego nie widać, również może być zły?

Są to pytania, które doprowadzają młodych programistów do szaleństwa. Spójrzmy na przykład na ten zupełnie niewinny kawałek kodu.

Kod źródłowy - białe znaki niewidoczne

Wygląda w porządku, prawda? Ale poczekaj. Przyjrzyjmy mu się raz jeszcze, trochę dokładniej.

Kod źródłowy - białe znaki widoczne

O. MÓJ. BOŻE!

Jeśli nie jesteś programistą, możesz patrzeć na te dwa obrazki i zastanawiać się, o co chodzi. W porządku. Ale muszę skromnie stwierdzić, że, cóż, nie jesteś jednym z nas. Nie jesteś w stanie docenić, ani nawet wyobrazić sobie, jak to jest spędzać każdą cholerną minutę każdego cholernego dnia na męczeniu się na nad każdym, nawet najdrobniejszym szczegółem programu, który właśnie piszesz. Nie dlatego, że tego chcemy, w żadnym wypadku. Ale dlatego, że świat eksploduje, jeśli tego nie będziemy robić.

Mówię tutaj dosłownie. Cóż, prawie. Jeśli choć jeden średnik znajduje się w złym miejscu, wszystko zaczyna iść nie tak, jak byś chciał. Tak właśnie jest w świecie programowania. I to jest fajne! Czasami! Przyrzekam!

Pakujemy się w tę branżę ponieważ, mówiąc szczerze, jesteśmy maniakami kontrolowania. Tacy właśnie jesteśmy. To właśnie robimy. Wyobraź sobie teraz te wszystkie głupie, bezużyteczne białe znaki, które, na nasze nieszczęście, wiszą sobie na końcach naszych wierszy. One tam są, ale nie możemy ich zobaczyć. Cóż, to są właśnie koszmary, na podstawie których kręci się horrory dla osób z zaburzeniami obsesyjno-kompulsyjnymi. Samo gadanie o tym sprawia, że całe ciało mnie swędzi.

W zależności od tego, jak głęboko w króliczą norę chcesz zajrzeć, jest kilka rzeczy, które możesz zrobić:

  • napisz skrypt, korzystający z wyrażenia regularnego w rodzaju \s*?$, który po każdym buildzie będzie usuwał nadmiarowe białe znaki przed wysłaniem kodu do systemu kontroli wersji,
  • uruchom makro, które usuwa białe znaki z końca wierszy,
  • stwórz regułę, która podświetla dodatkowe białe znaki,
  • używaj swojego IDE z włączoną opcją pokazywania białych znaków albo włączaj ją od czasu do czasu.

OK, w porządku, być może świat nie eksploduje, jeśli w moim kodzie będzie trochę nadmiarowych białych znaków.

Mimo to myślę, że w przyszłości dwa razy upewnię się, że te irytujące białe znaki nie będę akumulowały się w moim kodzie, gdy nie będę patrzył. To że ich nie widzę, nie oznacza, że ich tam nie ma i że nie czekają na okazję, by mnie dopaść.

Data publikacji oryginału: listopad 9, 2009


Zachęcamy do wzięcia udziału w sondzie, jak również do podzielenia się w komentarzach własnymi doświadczeniami związanymi z tematyką dzisiejszego posta.

Kto jest Twoim kumplem do kodowania?

Oryginalny post: Who's Your Coding Buddy?

Autor: Jeff Atwood

Zdumiewa mnie, jak bardzo mój kod zyskuje po tym jak zostanie przejrzany przez kogoś innego. Nie mam tu na myśli formalnej recenzji kodu, wysyłania go do publicznej oceny w Internecie lub uciążliwego reżimu programowania w parach. Jedna szybka próba wyjaśnienia i pokazania mojego kodu koledze/koleżance z zespołu -- to zazwyczaj wystarcza, by wyłapać błędy.

To oczywiście nie jest nic nowego. Doskonała książka autorstwa Karla Wiegersa Peer Reviews in Software: A Practical Guide opublikowana w roku 2002 jest kompletnym przewodnikiem na ten temat.

Peer Reviews in Software: a Practical Guide

Nie sądzę, by ktokolwiek podważał wartość spojrzenia innej osoby na twój kod, ale istnieją przeszkody, które zapobiegają praktykowaniu takich działań we wszystkich firmach. W rozdziale zatytułowanym A Little Help from Your Friends (pdf), Karl wyjaśnia:

Pracownicy czasami niechętnie poświęcają swój czas na sprawdzenie pracy kolegów. Możesz nie mieć zaufania do współpracownika, który prosi Cię o ocenę swojego kodu. Czy brakuje mu pewności siebie? Czy chce byś myślał za niego? "Każdemu, kto potrzebuje weryfikacji swojego kodu, nie powinno się płacić za bycie programistą", szydzą przeciwnicy recenzowania kodu.

W zdrowej kulturze programistycznej, członkowie zespołu angażują swoich współpracowników do poprawy jakości swojej pracy i poprawy wydajności. Rozumieją, że czas poświęcony nad oceną pracy kolegi zwraca się, kiedy inni członkowie zespołu oceniają rezultaty swojej pracy. Najlepsi programiści, których znam aktywnie poszukuja recenzentów swojej pracy . Istotnie, informacje zwrotne od wielu recenzentów w trakcie ich kariery były częścią tego, co sprawiło, że stali się najlepszymi.

Oprócz wymienionego wyżej rozdziału, możesz pobrać część rozdziału trzeciego (pdf) dzięki uprzejmości autora na stronie Process Impact. To nie jest wzięte z kosmosu. Za tym stoją rzeczywiste dane. Badania pokazują, że inspekcje kodu są zaskakująco efektywne.

Średni poziom wykrywania błędów wynosi tylko 25 procent dla testów jednostkowych, 35 procent dla testów funkcjonalnych i 45 procent dla testów regresyjnych. Średnia efektywność projektowania i inspekcji kodu to 55 i 66 procent..

Tak więc dlaczego nie wykonujesz recenzji kodu? Może dlatego, że nie wybrałeś jeszcze swojego kumpla do kodowania.

Pamiętasz te szkolne wycieczki, gdzie wszyscy byli upominani, by wybrali kolegę i trzymali się go? Miało to na celu zarówno uchronić nas od kłopotów jak i zapewnić nam bezpieczeństwo. Te same zasady mają również zastosowanie w budowaniu oprogramowania. Zanim wyślesz kod do repozytorium, daj go do sprawdzenia swojemu kumplowi. Czy umiesz wytłumaczyć ten kod? Może jest coś o czym zapomniałeś?

Jestem teraz zobowiązany przez prawo, by podać link do tego komiksu.

the only valid measurement of code quality: WTFs per minute

Jedyna poprawna miara jakości kodu: liczba słów WTF na minutę. Inspekcja kodu. Dobry kod: WTF, WTF. Zły kod: WTF, WTF, to jest do niczego, kolego WTF, WTF, WTF, WTF ...

Dziękuję Ci, spędzę tutaj cały tydzień.

Ten komiks ilustruje jak może wyglądać inspekcja, której potrzebujemy. Nie musi być skomplikowana, by była efektywna. Wartość WTF/minutę jest doskonale akceptowalną jednostką pomiarową, której możesz używać w pracy z twoim kumplem do kodowania. Społeczność XP (przyp. tłum. Extreme Programming) promuje programowanie w parach od lat, ale uważam, że posiadanie kumpla do kodowania jest dużo bardziej praktyczną drogą do osiągnięcia tych samych wyników.

Poza tym, kto nie chciałby być częścią wspaniałego programistycznego duetu?

Batman and Robin

To o wiele bardziej ekscytujące, niż perspektywa bycia przykutym do jednego komputera z drugą osobą. Pomyśl o wszystkich innych dynamicznych duetach jakie istnieją:

Jednostki mogą dokonać wielkich rzeczy, ale mogą osiągnąć jeszcze więcej, kiedy będą pracować razem. Na pewno jest przynajmniej jeden programista z którym pracujesz, którego podziwiasz lub przynajmniej darzysz szacunkiem wystarczającym, by został twoim kumplem do kodowania. Jeśli nie, rozważ zmianę firmy.

Jedną z uciech programowania jest to, że nie robisz tego sam. Tak więc kto jest twoim kumplem do kodowania?

Data publikacji oryginału: luty 25, 2009

Programowanie gier, analizowanie gier

Oryginalny post: Programming Games, Analyzing Games

Autor: Jeff Atwood

Dla wielu programistów wstępem do programowania był ich ojciec zmuszający do pisania własnych gier. Zamiast nowej, lśniącej konsoli Atari 2600, którą chciałem, dostałem komputer Texas Instruments TI-99/4a. Oczywiście nie o to mi wtedy chodziło, ale ta nieodwracalna decyzja zapoczątkowała karierę, która trwa już trzydzieści lat.

Najwyraźniej nie jestem sam. Mike Lee miał podobne przeżycia:

Urodziłem się w 1976, w tym samym roku co Apple, tak więć mój ojciec był w odpowiednim wieku, aby zainteresować się wczesnymi wynikami sceny homebrew. Jednym z moich wspomnień z wczesnego dzieciństwa jest on wracający do domu z Sinclairem 2000 i książką o grach. Godzinami przesiadywał wklepując kod od Space Invaders, a następnie graliśmy w nią może przez 30 minut przed wyłączeniem maszyny i anulowaniem całej jego pracy.

Tak jak Shawn Oster:

Tworzę oprogramowanie od 25 lat, poczynając od ósmego roku życia, zaczynałem z książką o nazwie "Twój pierwszy program w BASICu", którą kupił mi mój ojciec, ponieważ posiadaliśmy PC wtedy, gdy wszyscy moi znajomi grali w StarBlazers na ich Apple II. Mówił mi, że jeśli chcę grać w gry, to mógłbym je sobie sam napisać. W tamtej chwili byłem trochę rozczarowany (OK, załamany), ale teraz.. cóż, tato, dziękuję.

Dlatego własnie fascynujące jest powracanie do najwcześniejszych gier komputerowych. Przemysł komputerów osobistych dorastał razem z nami. Uczyliśmy się jak programować poprzez wpisywanie tych prostych gier z magazynów i książek. Przyjrzyj się uważnie, a zauważysz, że te stare gry są prymitywnymi początkami większości programistów, są niczym pień mózgu, który istnieje w głowie każdego z nas.

Nawet skromna, prosta, mała gierka jak Saper ma głębokie korzenie sięgające czasów kart perforowanych:

Początki Sapera sięgają najwcześniejszych gier mainframe'owych w latach 60 i 70. Wikipedia podaje Kostkę Davida Ahl'a za najwcześniejszego przodka Sapera. Ale mimo iż Kostka zawiera "miny", ciężko przyjąć ją za poprzednika Sapera. W Kostce miny są rozłożone losowo i jedynym sposobem na ich odkrycie jest zakończenie gry. Wchodzisz na minę i umierasz; nie możesz uniknąć miny bądź odgadnąć gdzie ona jest bez uprzedniej próby wejścia na nią.

W każdym bądź razie, istnieje bardzo dużo wczesnych gier typu "ukryj i szukaj", w których zadaniem jest znalezienie ukrytych miejsc na siatce. Na przykład w Hurkle Boba Albrechta musisz znaleźć potwora kryjącego się na siatce dziesięć na dziesięć. Po każdej próbie odgadnięcia dostajesz podpowiedź, w którym ogólnie kierunku znajduje się Hurkle. Depth Charge Dany Noftle'a jest tym samym tylko w trzech wymiarach. Mugwump Buda Valentiego ma wiele ukrytych celów, a po każdej próbie odgadnięcia otrzymujesz przybliżoną odległość do każdego z nich. W przeciwieństwie do Kostki, te gry bardziej przypominają Sapera: zrób losowy ruch by rozpocząć, potem używaj dostarczonych informacji, aby odkryć ukryte elementy. Oczywiście inaczej niż w Saperze (czy Kostce), nie było niebezpieczeństwa "wybuchu", jedynym ograniczeniem było odnalezienie ukrytych lokalizacji w skończonej liczbe ruchów.

Najbliższym przodkiem Sapera jest prawdopodobnie Hunt the Wumpus Gregorego Yoba.

Mimo iż Wumpus bazował na niekonwencjonalnej siatce (oryginalna gra używała wierzchołków dwunastościannu foremnego, a późniejsza wersja używała Wstęgi Möbiusa i innych nieprawdopodobnych kształtów), to ewoluował od swoich poprzedników w wielu różnych kierunkach.

Byłem zaintrygowany nowo odkrytym połączeniem między Saperem a Hunt the Wumpus, ponieważ Wumpus jest moim wewnętrznym zwierzęciem.

Większość wczesnych gier nie była nawet tak zabawna. Analizowanie kodu gry było prawie tak samo przyjemne jak granie w nią; sama czynność wpisywania i zrozumienia programu była wystarczającą "grą" dla wielu z nas. Ale niektóre z tych wczesnych gier ewoluowały i przetrwały po dziś dzień, tak jak Saper -- który stał się tak zakorzeniony w społecznej świadomości, że jest teraz przedmiotem zabawnych filmów parodiujących. Pomimo prostoty Sapera (i jego popularności), jest to zaskakująco głęboka gra logiczna, tak jak jest to opisane na Wikipedii:

Saper jest wciąż popularny wśród programistów; Automine, na przykład, jest programem napisanym w Javie, który automatycznie gra w Sapera czytając z ekranu i manipulując myszką.

Artykuł o Saperze jest częścią niesamowitej serii Beyond Tetris na GameSetWatch, w której klasyczne gry łamigłówkowe są analizowane z punktu widzenia projektanta i programisty gier. Gorąco polecam. Uczciwe ostrzeżenie: nie przeklikuj się przez to, dopóki nie masz mnóstwa wolnego czasu. Dla programisty, analizowanie gier jest prawie taką samą zabawą jak granie w nie.

Data publikacji oryginału: sierpień 22, 2007

Related Posts with Thumbnails