Profesjonalny programista

Opublikowane zostało nowe tłumaczenie z cyklu 97 rzeczy, o których każdy programista wiedzieć powinien:

Zapraszamy do lektury!
Zespół devMedia.pl

Kiedy wielcy myśliciele analizują problemy

Oryginalny post: Don’t Let Architecture Astronauts Scare You

Autor: Joel Spolsky

Kiedy wielcy myśliciele analizują problemy, zaczynają dostrzegać wzory. Spoglądają na problem ludzi wysyłających sobie pliki edytora tekstów, potem patrzą na problem osób wysyłających do siebie arkusze kalkulacyjne i zdają sobie sprawę, że jest do tego przypisany ogólny wzór – wysyłanie plików. To już jest jeden poziom abstrakcji. Potem przenoszą się o jeden poziom wyżej: ludzie wysyłają pliki, ale przeglądarki internetowe również „wysyłają” zapotrzebowanie na strony www. I kiedy się nad tym zastanowisz, wywołanie metody na obiekcie jest niczym wysyłanie wiadomości do obiektu! To znowu jest to samo. Wszystko to są operacje wysyłania, więc nasz mądry myśliciel wynajduje nową, wyższą, szerszą abstrakcję zwaną wiadomościami, ale teraz zaczyna się to robić naprawdę niejasne i nikt tak naprawdę już nie wie o czym mowa. Eh.

Kiedy wzniesiesz się za wysoko, abstrakcyjnie myśląc, w końcu zabraknie ci tlenu. Czasem mądrzy myśliciele po prostu nie wiedzą kiedy przestać, i tworzą te absurdalne, w pełni wyczerpujące problem, wysokopoziomowe obrazy świata, które są wszystkie poprawne i trudno im coś zarzucić, ale tak naprawdę w rzeczywistości niczego nie zmieniają, nic nie znaczą.

Takich właśnie ludzi nazywam Astronautami Platform. Bardzo ciężko zmusić ich do napisania kodu lub projektowania programów, ponieważ nie potrafią przestać myśleć o systemie. Są astronautami, ponieważ unoszą się wysoko, powyżej poziomu tlenu, sam nie mam pojęcia czym oddychają. Mają zwyczaj pracować dla naprawdę dużych firm, które mogą sobie pozwolić na zatrudnianie całej masy bezproduktywnych ludzi mających naprawdę wysokie wykształcenie, którzy nie mają kontaktu z rzeczywistością.

Ilustruje to ostatni przykład. Typowy Astronauta Platform zaakceptuje fakt, że “Napster jest usługą peer-to-peer do pobierania muzyki” i zignoruje wszystko poza kwestią modelu komunikacji, myśląc, że jedyne co jest tu interesujące to model P2P. Kompletnie pominą przy tym samo sedno, czyli że jest to interesujący program, ponieważ umożliwia wpisanie nazwy utworu muzycznego i przesłuchanie go od zaraz.

Wszystko, o czym będą rozmawiać, to działanie metody P2P tu, tam i w innych rzeczach. Nagle mamy konferencje poświęcone peer-to-peer, przedsiębiorstwa peer-to-peer i nawet peer-to-peer z głupimi dziennikarzami biznesowymi skaczącymi z radości kiedy kopiują między sobą teksty: ”Peer to peer jest martwe!”.

Astronauci Platform będą powtarzali rzeczy w stylu: ”Czy możesz sobie wyobrazić taki program jak Napster, w którym możesz pobrać cokolwiek, a nie tylko muzykę?”. Potem stworzą aplikacje w stylu Groove, które według nich będą bardziej ogólne niż Napster, ale które wydają się zaniedbywać tę małą, lecz istotną funkcję, która pozwala wpisać nazwę piosenki i jej wysłuchać – funkcję, na której przecież zależy nam najbardziej. Chodzi o zatracenie sensu. Jeżeli Napster nie byłby programem peer-to-peer, ale umożliwiałby wpisanie nazwy utworu i odsłuchanie go, byłby równie popularny.

Inną powszechną rzeczą, którą Astronauci Platform lubią robić, jest tworzenie nowych platform i zarzekanie się, że coś rozwiązują. Java, XML, Soap, XmlRpc, Hailstorm, .NET, Jini, o Boże sam już za tym nie nadążam. I to tylko w ostatnim czasie.

Nie mówię, że jest coś nie tak z tymi platformami, oczywiście, że nie. Są całkiem niezłe. Co mnie męczy to zadziwiająca ilość hałasu, który im towarzyszy. Pamiętacie reklamę Microsoft Dot Net?

Następna generacja desktopowej platformy Windows, Windows.NET wspiera produktywność, kreatywność, zarządzanie, rozrywkę i wiele innych oraz jest tak zaprojektowana, by dać użytkownikom kontrolę nad ich cyfrowym życiem.

Dziewięć miesięcy później otrzymaliśmy platformę Microsoft Hailstorm. Reklama oznajmiała:

Ludzie nie mają kontroli nad technologią, która ich otacza. HailStorm sprawia, że technologia w twoim życiu pracuje dla Ciebie i jest pod twoją kontrolą.

No dobrze, więc teraz nowoczesna lampa halogenowa w moim mieszkaniu przestanie mrugać co jakiś czas.

Microsoft nie jest sam. Oto cytat z reklamy Sun Jini:

Te trzy fakty (jesteś nowym administratorem systemu, komputerów nie ma nigdzie, jest jeden komputer wszędzie) powinny się łączyć, by ulepszać świat przez korzystanie z komputerów jako komputerów, przez sprawianie, by granice dla komputerów zniknęły, by komputery były wszędzie i poprzez uczynienie szczegółów pracy z komputerami tak prostymi, jak wkładanie DVD do kieszeni kina domowego.

I nawet nie przypominaj mi tekstu, który George Gilder rozprzestrzenił o Javie:

Fundamentalny przełom w historii informatyki…

To jeden pewny sposób by poznać, że jesteś atakowany przez Astronautę Systemowego: niesamowita pompatyczność, heroiczna, utopijna chełpliwość w połączeniu z oderwaniem od rzeczywistości. A ludzie to kupują. Prasa biznesowa szaleje! Wyobraźcie sobie, jak w ten sposób reklamowałaby się - , Warszawa, Kraków są nareszcie w twoim zasięgu, nawet bez własnego samochodu. Nie ważne, że istnieje coś takiego, jak transport publiczny, autobusy, pociągi czy samoloty, a praktycznie każdy z nas posiada własny pojazd. Na ludzi to działa.

Czemu do licha tyle osób jest pod takim wrażeniem nowych nudnych platform, które często wnoszą niewiele więcej niż zmieniony format plików lub nową wirtualną maszynę? To mogą być dobre platformy, z pewnością przyniosą korzyści programistom, którzy będą z nich korzystali, ale nie są, powtarzam, nie są żadnym substytutem do nadejścia mesjasza, czy nastania pokoju na świecie. Nie, Microsoft, komputery nie zaczną nagle czytać w naszych myślach, ani robić to, co chcemy automatycznie. Nie, Sun, analiza danych sprzedażowych wielkiej korporacji nie będzie równie prosta jak „włożenie DVD do stacji kina domowego”.

Pamiętajcie, że ludzie od platform rozwiązują problemy, które wydaje im się, że mogą rozwiązać, nie problemy, które przyniosą korzyści po ich rozwiązaniu. Soap + WSDL może być Gorącą Nowością, ale tak naprawdę nie pozwoli ci zrobić nic, czego nie mógłbyś zrobić za pomocą innych środków – jeżeli miałbyś ku temu powód. Cała ta Nirwana Usług Rozproszonych, o której paplają Astronauci Platform, była nam obiecana w przeszłości, jeżeli używaliśmy DCOM, JavaBeans, OSF DCE czy CORBA.

To miło, że XML ma zastosowanie w sieci. Super. Ale to jest dla mnie równie interesujące jak informacja, że mój supermarket używa ciężarówek, żeby przywieźć rzeczy z magazynu. Ziewać się chce. To dopiero interesujące. Powiedzcie mi o czymś nowym, co mogę zrobić teraz, a nie mogłem wcześniej, o Astronauci, lub zostańcie tam w kosmosie i nie marnujcie więcej mojego czasu.

Data publikacji oryginału: 21 kwietnia 2001

Pamiętajcie, praca powinna być zabawą

Oryginalny post: Remember, This Stuff Is Supposed To Be Fun

Autor: Jeff Atwood

Dokładnie pamiętam problemy, z jakimi musiał zmierzyć się mój ojciec podczas swojej kariery. Pracował ciężko by zdobyć tytuł MBA w prestiżowej szkole biznesu. Otworzyło to przed nim wiele możliwości, ale nie sądzę, by kiedykolwiek znalazł dokładnie to, czego szukał. W czasie mojego dzieciństwa często się przeprowadzaliśmy, podróżując od pracy do pracy, nigdy nie zostając w jednym miejscu dłużej niż rok. Nie jestem pewny, czy do dzisiaj udało mu się znaleźć pracę, która dawała mu satysfakcję. Kopie poradnika dla szukających pracy Jakiego Koloru jest Twój Spadochron stale leżały w naszym domu.

Dojście do tego, czego oczekujesz od swojego życia zawodowego, może zająć dużo czasu.

Tak jak mój ojciec, ja też spędziłem wiele lat po studiach fruwając od pracy do pracy. Nie miałem na co narzekać. Prowadziłem świetne życie. Nigdy nie czekałem długo na nowe oferty. Lubiłem swoją pracę. Ale nie wybierałem ścieżki kariery. Pozwalałem, by przypadek wybrał kim byłem, i kim miałem zostać.

Nadchodzi jednak taki moment w karierze, kiedy trzeba przestać unosić się przez życie jak symboliczne piórko w filmie Forrest Gump.

Niestety, nie sądzę, by mój ojciec kiedykolwiek zorientował się, co kochał robić najbardziej. Nigdy nie określił koloru swojego spadochronu. Ale mi sie poszczęściło. Kilka lat temu zdałem sobie sprawę, że to co kocham robić, to co naprawdę kocham robić bardziej niż cokolwiek innego, to pisać programy i mieć do czynienia z komputerami. Wiem, że wydaje się to oczywiste, ale macie tę przewagę, że nie jesteście mną. Samoświadomość jest rzeczą szczególnie kłopotliwą, patrząc na siebie od wewnątrz.

Życie jest za krótkie, by marnować je w pracy, w której nie robisz rzeczy, które chcesz robić, z której nie czerpiesz przyjemności. Nie ważne, czy piszesz programy, uczysz w szkole, czy tworzysz . I tak oto ja, beznadziejnie zakochany w komputerach i programach, pracowałem w firmie, gdzie oprogramowanie było postrzegane jako produkt uboczny, źródło kosztów, konieczne zło:

Mój bliski przyjaciel pracuje w firmie, która doświadczyła masowej ucieczki programistów. Pierwsi odeszli najlepsi, pozostali poszli za nimi. Ci, którzy zostali, to ludzie, którzy siedzą za biurkiem od 9 do 17 dla wypłaty i nie mają żadnej satysfakcji z tego, co robią. Firma ma teraz to, o co prosiła: zespół niskopoziomowych programistów z przymusu. Ludzie z inicjatywą, energią i pasją odeszli.

Firmy, które postrzegają programistów jako “narzędzia i niskiej jakości rzemieślników” są skazane w najlepszym przypadku na przeciętnych pracowników.

Żeby być szczerym, nie było akurat wielu ofert pracy. Praca była ciekawa, ale było oczywiste, że oprogramowanie nie stanowiło siły napędowej tej organizacji. Outsourcing wisiał w powietrzu. Mimo, że moi współpracownicy byli kompetentni, nikt nie miał aż takiej obsesji na punkcie programowania, jak ja. Moja pasja w tym temacie i wszystkim z nim związanym, najwyraźniej nie była podzielana.

Wyruszyłem by to zmienić. Nie chciałem więcej być wybierany przez firmy z listy kandydatów. W zamian, to ja postanowiłem wybierać interesujące mnie firmy. Takie, do których miałem szacunek, które podzielały moją pasję do oprogramowania. Uzbrojony w trzydzieści lat doświadczenia, nie miałem zamiaru pozwalać, by losowe sploty okoliczności decydowały o mojej ścieżce zawodowej. Ja wybiorę, gdzie chcę pracować.

W swoim ostatnim artykule, Joel Spolsky opisuje główną filozofię swojej firmy programistycznej:

Szczerze mówiąc, głównym powodem, dla którego otworzyłem tę firmę była chęć czerpania przyjemności z pracy. Praca w Fog Creek jest celowo zaprojektowana tak, by być przyjemną. Uruchomiliśmy nasz biznes, ponieważ chcieliśmy świetnego miejsca do pracy, do spędzania naszych dziennych godzin. I mamy niepokojący zwyczaj, by robić wiele rzeczy samemu, szczególnie, jeśli ma temu towarzyszyć przyjemność i zabawa lub jeżeli uważamy, że możemy to zrobić lepiej. Zajmuje to trochę więcej czasu, ale zdałem sobie sprawę, że to odbyta podróż jest nagrodą.

Dokładnie dlatego ja wybrałem pracę w Vertigo Software. Dzielimy tę samą filozofię. W Vertigo jestem otoczony niezwykle utalentowanymi programistami, którzy wszyscy są pasjonatami oprogramowania. I do licha, dobrze się bawimy.

Jeżeli kochasz programowanie tak bardzo jak ja, zasługujesz na pracę w firmie, w której ludzie przychodzą do pracy nie po to, by odsiedzieć swoje, ale dlatego, że też kochają programowanie. Zasługujesz na firmę, gdzie inżynieria oprogramowania jest szanowana. Zasługujesz na pracę, w której pracownicy spotykają się, by czerpać przyjemność ze wspólnego tworzenia oprogramowania*.

Jesteśmy w środku wielkiego technologicznego ożywienia. Niektórzy mogą to nawet nazwać kolejną bańką. Możliwości jest mnóstwo.

Wybierajcie mądrze. I pamiętajcie, praca powinna być zabawą.

Data publikacji oryginału: 15 października 2007

Mózg, Komputer, Plecy, Pośladki - Priorytety Programisty

Oryginalny post: Brain, Bytes, Back, Buns - The Programmer's Priorities

Autor: Scott Hanselman

Moje miejsce pracy, z którego jestem zadowolony

Ostatnio powiedziałem coś, co było przekazywane od osoby do osoby na Twitterze:

"Jeśli jesteś programistą, to musisz wydać pieniądze na znakomity komputer, wspaniały monitor, fantastyczne krzesło i dobre łóżko" - Scott Hanselman

Ta zaledwie 140-to znakowa wiadomość mogła być, jak sądzę, źle zinterpretowana - jakbym twierdził, że dobry programista musi wydać pieniądze na drogi sprzęt. To nie jest to, co miałem na myśli. Chciałem powiedzieć, że musisz zainwestować w swoje narzędzia.

Pośladki

Słuchałem znajomego projektanta dręczącego się myślami, czy kupić krzesło za 700 dolarów. Zdaję sobie sprawę, że każdy zarabia inne sumy pieniędzy w zależności od tego, gdzie mieszka, ale poczekajcie chwilkę. Ten projektant spędził miesiące, starając się zdecydować, czy to krzesło jest dobrym pomysłem. "To takie drogie! Czy rzeczywiście powinienem wydać tak dużo pieniędzy?"

Zaraz, nie mówimy tutaj o biżuterii, grach video czy modnych spodniach. Mówimy tutaj o krześle, na którym będziesz siedział(a) podczas pracy przez kilka godzin dziennie przez co najmniej kilka lat. Biorąc 50 tygodni w roku przez 3 lata (co najmniej) i po 5 godzin dziennie (co daje okrągłe liczby), to co najmniej 1250 godzin w pierwszym roku (a prawdopodobnie więcej) i 3750 godzin jeśli trwać to będzie 3 lata. To 19 centów na godzinę za komfortowe siedzenie. Zainwestuj w swój własny tyłek.

Nie żałuję ani trochę kupna krzesła Herman Miller Aeron. Najlepsze jest to, że kupiłem je sam dla siebie, za swoje własne pieniądze, ponad 5 lat temu. Każdego dnia sprawia mi ono radość, a koszt jego używania codziennie maleje.

Plecy

Wydałem całkiem słuszną ilość pieniędzy na bardzo dobry materac ponieważ mam Plecy Programisty. Jestem zdziwiony za każdym razem, gdy rozmawiam z programistami mającymi tanie (czytaj: niskiej jakości) materace i tanie krzesła, a narzekają na bóle pleców. Programista cierpiący, to nędzny programista. Cytując Wu Tang Clan - chroń swój kark. Nie żałuj pieniędzy na swoje miejsce do spania.

Kupno fizycznych przedmiotów to jedno, ale kluczowe jest również inwestowanie w swoje plecy poprzez jogę, rozciąganie się i regularne ćwiczenia. Jeśli używasz czegoś przez osiem godzin dziennie tydzień za tygodniem, zrób rozeznanie i zainwestuj w tę rzecz. Leżysz na swoich plecach nieświadomy(a) przez jedną trzecią swojego życia. Zadbaj należycie o ten czas i zrób coś dobrego dla swojego ciała. Jedną z najważniejszych rzeczy jest wysokiej jakości łóżko. Lubię inwestować w nowy komputer, ale ostatnio zdałem sobie sprawę, że zakup czegoś funkcjonalnego jak dobry materac jest tak samo wartościowe i podnoszące jakość życia.

Mam także biurko z regulowaną wysokością (Steelcase Series 7), które uwielbiam. Sam nie pomyślałbym o kupnie takiego biurka, ale po odpowiedniej ilości wizyt u kręgarza takie decyzje przychodzą łatwiej. Biurko jest zmotoryzowane, ma predefiniowane ustawienia, dlatego bardzo łatwo jest zmienić ustawienie z siedzącej na stojącą pozycję. Jeśli uważasz, że przydałoby Ci się takie biurko, porozmawiaj ze swoim działem HR. Samo zapytanie się - nie zaboli, ale gwarantuję Ci, że jeśli nie zapytasz - będzie bolało.

Komputer

Z pewnością zrozumiesz, Drogi Czytelniku, że nienawidzę patrzyć na ludzi, którzy cierpią z powodu beznadziejnego sprzętu. Przeprowadziłem całą dyskusję na Twitterze z pewnym dżentelmenem posiadającym 4-6 letniego Maca, który zrozumiał, jakbym próbował implikować, że trzeba mieć niesamowicie dobry sprzęt, żeby być dobrym programistą. Nie to było moją intencją, miałem inną, oto ona. Jeśli czekasz na swój komputer, marnujesz czas. Zapomnij o swoich religijnych argumentach, nie obchodzi mnie, czy to jest Twój system operacyjny, edytor tekstu albo ten kręcący się kawałek rdzy, który nazywasz twardym dyskiem. Jeśli każe Ci czekać, wymień go.

Zacznij od kupna SSD. Ten kolega z Twittera z lekko starszym sprzętem miał SSD w komputerze. Każdy może używać SSD. Jest tak dużo podnoszących jakość życia zakupów sprzętu. Zrób sobie przyjemność. Mówię o pamięci, SSD, monitorze. Nieważne, jaki masz system operacyjny - miej przynajmniej 4GB RAMu. W dzisiejszych czasach możesz dostać mały dysk SSD za mniej niż 100 dolarów i takie o sensownych rozmiarach za 200 dolarów. Zaryzykowałem kupno 256-gigowego OCZ Vertexa i nawet jeśli pożyje tylko rok, to daje 2 dolary na dzień za cichą przyjemność, którą może dać tylko wydajna szyna PCI. Z każdym dniem po roku jego używania (a prawdopodobnie będzie żył kilka lat) posiadanie go będzie coraz tańsze.

Spraw sobie taką wielkość i ilość monitorów, z którą będziesz szczęśliwy. Ja lubię trzy monitory. Do notebook'ów preferuję monitory 15-to calowe. Niektórzy nieźle radzą sobie na 13-to calowych LCD, ale inni wolą coś większego. Prawda jest taka, że jeśli NIENAWIDZISZ swojej sytuacji z monitorami - zmień ją. Jesteś tego warty i uczyni Cię to bardziej produktywnym.

I, jak zawsze, jeśli masz Ręce Programisty, zastanów się nad swoją klawiaturą i myszką. I mimo, że zdaję sobie sprawę, że wielu z Was nalega i nadal używa standardowej, prostej klawiatury do pisania, mimo oczywistej anatomii, to najważniejszą rzeczą jest słuchać swego ciała. Jeśli Twoje miejsce pracy jest dla Ciebie dobre - wspaniale. Jeśli nie - przearanżuj je tak, aby jak najlepiej wspierało sposób, w jaki pracujesz.

Mózg

Książki, wykłady, doświadczenie i wyzwania poruszają Twój mózg. Często opowiadam historię starszego programisty, który ma 20 lat doświadczenia. Problem w tym, że to ten sam rok doświadczenia powtórzony 20 razy. W pewnym momencie, w piątym roku albo czternastym ten programista zauważyłby to i przerwał. Co chcę powiedzieć to, że jako programista(tka), powinieneś(nnaś) słuchać nie tylko swojego ciała, ale także swojego umysłu. Jeśli to narzędzie jest tępe, zobacz, co możesz zrobić, aby naostrzyć piłę.

Kiedy występuję na spotkaniach użytkowników lub regionalnych konferencjach czy obozach kodowania, zawsze mówię swoim słuchaczom coś w tym stylu:

"Już jesteście w najwyższej warstwie programistów tylko poprzez pokazanie się tutaj wieczorem. Nie wiem, jak bardzo jesteście utalentowani, jak dużo macie doświadczenia, ale pojawiliście się dzisiaj. Znajdujecie się w tej topowej grupie, bo dbacie o to, żeby stale się rozwijać. Dziękuję za te chęci."

Powinieneś(nnaś) być zadowolony(a) z samego bycia świadomym(ą). Nie - świadomym(ą) jak "żyjąca istota", ale jak "przywiązujący(a) wagę do swojej podróży". Jeśli jesteś świadomy(a), jesteś na czele grupy. Wpadamy w kłopoty, jeśli przestajemy być czujni. Czas mija i pewnego dnia budzisz się po kilku latach bez żadnego nowego doświadczenia, bez żadnej nowej wiedzy, zawieszony(a) w przestrzeni bez żadnej inercji. Czasami po prostu obudzenie się i bycie czujnym jest katalizatorem, którego trzeba, aby coś zmienić. Każdy dzień jest okazją, żeby odwrócić to. Nie bój się pójść na te warsztaty, kupić tę książkę czy znaleźć sobie technicznego mentora. Po prostu weź to wszystko i włóż sobie do głowy - będą Twoje na zawsze.

Jest taka wspaniała historia, którą opowiadał komik Paul Reiser Marcowi Maronowi na podcast'ie Marca. Paul spotyka aktora Petera Falka i pyta się go, czy jest jakiś sekret napisania scenariusza filmowego. Peter Falk mówi: "weź trochę papieru, włóż go do maszyny do pisania, napisz FADE IN...i pisz."

Zaskakujące jest, jak ta odpowiedź pasuje również w momencie, gdy ktoś pyta mnie, jak odnieść sukces w programowaniu. Bądź świadomy, dbaj o siebie, inwestuj w swoje narzędzia i programuj.

Data publikacji oryginału: 5 października, 2011

Ucieczka z Wyspy Gilligana

Oryginalny post: Escaping From Gilligan’s Island

Autor: Jeff Atwood

Uważam, że warto odświeżyć listę klasycznych błędów procesu tworzenia aplikacji stworzoną przez Steve’a McConnella, oraz towarzyszące jej studium przypadku, przynajmniej raz do roku. Zastopujcie mnie, jeżeli słyszeliście to już wczesniej:

“Spójrz Mike” powiedział Tomas. “Mogę przekazać mój kod dzisiaj i nazwać go ukończonym, ale prawdopodobnie będę potrzebował jeszcze trzech tygodni na uporządkowanie go, jeśli go teraz oddam.” Mike zapytał, co Tomas miał na myśli przez „uporządkowanie”. „Nie dostałem logo firmy żeby umieścić na każdej stronie i nie dostałem nazwiska i numeru telefonu agenta do umieszczenia w stopce każdej strony. Drobiazgi w tym stylu. Wszystkie ważne funkcje działają dobrze. Praca jest ukończona w 99 procentach.”

Jak głosi stare przysłowie programistów, pierwsze dziewięćdziesiąt procent zadania zajmuje dziewięćdziesiąt procent czasu, a ostatnie dziesięć procent zadania zajmuje kolejne dziewięćdziesiąt procent czasu.

Klasyczne Studium przypadku błędu czyta się z pewnym niepokojem. Być może przesadzone, ale jest to dziwnie dokładne streszczenie wszystkich patologicznych projektów programistycznych, w których brałem udział, czyli w praktyce prawie wszystkich, z jakimi miałem do czynienia.

To zjawisko McConnell przyrównuje do mechanizmu znanego z Wyspy Gilligana. Co tydzień pojawia się tam jakiś nowy, szalony plan ucieczki z wyspy, ale na koniec odcinka rozbitkowie zawsze zostają uziemieni na wyspie co najmniej na kolejny tydzień.

Obsada Wyspy Gilligana

Jeżeli na pierwszy rzut oka nie widzisz powiązań z procesem tworzeniem oprogramowania, pozwól mi przypomnieć długą i ponurą historię błędów w projektach programistycznych. Klasyczne błędy są klasycznymi, ponieważ są tak kuszące. Musisz aktywnie rozpoznawać kiedy wpadasz w jedną z tych pułapek. Jak powiedział kiedyś Steve w jednym z wywiadów:

Właściwie to sukces w tworzeniu oprogramowania zależy nie tyle od niepopełniania kilku błędów, co od dążenia do robienia większości rzeczy prawidłowo.

Oczywiście niezbędne do tego jest doświadczenie zdobyte w poprzednich projektach oraz wiedza zdobywana poprzez odpowiednie projektem programistycznym jest procesem w pewnym zakresie powtarzalnym. Właśnie dlatego powinniście od teraz mieć w pamięci każdy z poniższych 36 klasycznych błędów podkreślonych w książce McConnela Rapid Development:

Błędy ludzkie Błędy procesu Błędy produktu Błędy technologiczne
  1. Podważona motywacja
  2. Słabi ludzie
  3. Niekontrolowani problematyczni pracownicy
  4. Bohaterstwo
  5. Dodawanie ludzi do spóźnionego projektu
  6. Głośne, zatłoczone biura
  7. Tarcia pomiędzy twórcami a klientami
  8. Nierealistyczne oczekiwania
  9. Brak efektywnego sponsoringu projektów
  10. Brak zainteresowanych stron
  11. Brak zdania użytkownika
  12. Polityka ponad istotą sprawy
  13. Pobożne życzenia
  1. Zbyt optymistyczne planowanie czasu
  2. Niedostateczne zarządzanie ryzykiem
  3. Błędy wykonawców
  4. Niewystarczające planowanie
  5. Rezygnacja z planowania pod presją
  6. Strata czasu na rozmyty początek
  7. Niewystarczające aktywności początkowe
  8. Nieodpowiednie projektowanie
  9. Niewystarczające zapewnianie jakości
  10. Niewystarczająca kontrola zarządzania
  11. Przedwczesna lub zbyt częsta zbieżność
  12. Planowanie nadrobienia później
  13. Tworzenie kodu rodem z piekła
  1. Zbytnie precyzowanie wymagań
  2. Zbytnie dodawanie funkcjonalności
  3. Zbytni perfekcjonizm programistów
  4. Przepychanki w negocjacjach
  5. Programowanie sterowane badaniami
  1. Szybkie rozwiązywanie kłopotliwych spraw
  2. Przeszacowane oszczędności z tytułu użycia nowych narzędzi lub metod
  3. Zmiana narzędzi podczas trwania projektu
  4. Brak automatycznej kontroli wersji

Zacząłem coraz mocnej wierzyć, że jedyną różnicą pomiędzy doświadczonymi, a niedoświadczonymi programistami jest to, że ci doświadczeni mają świadomość popełnianych błędów. Ta sama reguła odnosi się do projektów programistycznych i menadżerów projektów. Jeżeli nie przeglądasz aktywnie Klasycznych Błędów Rozwoju Programowania podczas prac nad projektem, nie masz nawet pojęcia, jak duże jest prawdopodobieństwo, że właśnie robisz jeden z tych błędów.

Popełnianie błędów jest nieuchronne, ale powtarzanie tych samych w kółko już niekoniecznie. Powinieneś postarać się, by popełniać całkowicie nowe, spektakularne, nigdy nie widziane przedtem błędy. Na koniec, Steve McConnell podkreślił kilka nowych klasycznych błędów na swoim blogu, które chce dodać do kanonu 10 lat później:

  • Mylenie oszacowań z celami
  • Nadmierna wielozadaniowość
  • Założenie, że całościowy development ma niewielki wpływ na łączne wysiłki
  • Niejasna wizja projektu
  • Zaufanie do mapy większe niż do terenu
  • Outsourcing jako zmniejszenie kosztów
  • Pozwolenie by ludzie pracowali w oddzieleniu od siebie (zastępując poprzednie “braki w zarządzaniu”)

Steve szuka też naszej opinii. Wydał Ankietę odnośnie Klasycznych Błędów i zaprosił każdego do udziału. Jeżeli macie jakiekolwiek doświadczenie w tworzeniu oprogramowania, proszę, przyłączcie się.

To prawda, wszystko przemawia przeciwko wam. Ale to dobry pomysł, by okresowo przypominać sobie, że może, tylko może – jeżeli będziecie w stanie unikać popełniania tych samych klasycznych błędów, które popełniono w tak wielu poprzednich projektach przed Tobą - moglibyście któregoś dnia wydostać się z wyspy.

Data publikacji oryginału: 18 czerwca 2007

Wampiry (Programiści) kontra wilkołaki (Administratorzy Systemów)

Oryginalny post: Vampires (Programmers) versus Werewolves (Sysadmins)

Autor: Jeff Atwood

Kyle Brandt, administrator systemów, pyta Czy programiści powinni mieć dostęp do swojego dzieła?

Pytanie, które ciągle i ciągle powraca w firmach zajmujących się tworzeniem aplikacji sieciowych.

“Czy twórcy powinni mieć dostęp do środowiska stworzonych programów, a jeżeli tak, to w jakim stopniu?”

Moim zdaniem, ogólnie rzecz ujmując programiści powinni mieć ograniczony dostęp do ukończonych programów. Mała uwaga zanim spróbuję wytłumaczyć ten punkt widzenia - moje stanowisko nie wynika w żadnym wypadku z obserwowanej jakości pracy i postawy twórców – więc proszę nie odbierać tego w ten sposób.

Jest to dla mnie trudne pytanie, ponieważ, nie da się ukryć, jestem programistą. Dokładniej, jestem jednym z programistów, których Kyle ma na myśli. Skąd o tym wiem? Ponieważ Kyle pracuje dla naszej firmy, Stack Overflow Internet Services Incorporated©®™. I Kyle jest świetnym administratorem systemów. Skąd o tym wiem? Z dwóch powodów:

  1. Jest on jednym z czołowych użytkowników Server Fault.
  2. Ma odwagę pisać na ten temat na blogu Server Fault.

Z mojego punktu widzenia, firmie chodzi o rozmowę na temat naszych działań. Załatwianie spraw jest oczywiście ważne, ale musimy się od czasu do czasu zatrzymać, żeby napisać o tym, co robimy, jak to robimy i nawet, a może przede wszystkim, dlaczego to robimy, uwzględniając tu nasze wątpliwości i obawy. Jeśli to pominiemy, będziemy oszukiwać samych siebie i was. Oczywiście, pisanie o tym co robimy i wyjaśnianie tego społeczności pomaga nam się skupić. Pozwala także naszym partnerom przekazać nam swoje opinie. Jednak przede wszystkim, pozwala każdemu mieć szansę uczyć się na naszych wielu, wielu błędach… a kto wie, może także na okazjonalnych sukcesach.

To w zasadzie również cała filozofia naszej sieci Stack Exchange Q&A. Zacznijmy wszyscy o tym rozmawiać publicznie, tak byśmy mogli uczyć się od siebie nawzajem jak być lepszymi w tym co przecież kochamy robić.

(Czasami mam wrażenie, że pomysł ten denerwuje mojego wspólnika, co nieustannie staram się zrozumieć. Jeżeli nie spróbujemy iść tą drogą, po co w ogóle to robimy? Ale przepraszam za tę dygresję.)

Saga Administratorzy Systemów kontra Programiści nie jest niczym nowym. Nie wydaje mi się, żebym kiedykolwiek pracował w jakiejś firmie, w której te dwie frakcje nie toczyły ze sobą ciągłych wojen. Zresztą łatwo wyobrazić sobie inne grupy zawodowe, w których pojawia się rozdźwięk pomiędzy twórcami projektów oraz osobami wcielającymi je w życie. Przykładem niech będzie i firma budowlana, gdzie w podobnej sytuacji znajdują są architekci i budowlańcy. To są naprawdę epickie zmagania, ale żeby je pojąć, trzeba zrozumieć, że zarówno Administratorzy Systemów jak i Programiści mają różne, być może uzupełniające się, ponadnaturalne zdolności.

Programiści są niczym wampiry. Często są na nogach przez całą noc, bladsi niż sama śmierć i na ogół boją się wystawiać swoje ciało na światło dzienne. A właśnie, mają także tendencje do postrzegania sobie (lub przynajmniej swojego kodu) przez pryzmat nieśmiertelności.

Bela-lugosi-dracula

Z drugiej strony Administratorzy Systemów przypominają wilkołaki. Z zewnątrz mogą wyglądać na normalnych ludzi, są jednak wyjątkowo silni, niezwykle odporni na rzeczy, które mogłyby okazać się zabójcze dla przeciętnego człowieka. Mają także skłonności do dziwnych przemian podczas „przerwy w funkcjonowaniu” księżyca.

Wolfman

Chciałbym, aby było jasne, że podobnie jak Kyle szanuje programistów, ja mam głęboki szacunek do administratorów systemów:

Mimo pewnych bezsprzecznych cech wspólnych, jesteśmy przekonani, że społeczności programistów oraz administratorów to różne od siebie gatunki. Sam fakt bycia programistą na topie nie oznacza jeszcze opanowania tajników zagadnień sieciowych i konfiguracji serwerów. A poznałem kilku administratorów, którzy byli w stanie pisać skrypty na bazie mojego kodu. To dlatego Server Fault dostał własną domenę, profil użytkownika i system reputacji.

Naprawdę są to odmienne „bestie”.

W każdym razie, jeżeli szukacie jednej odpowiedzi na wszystkie pytania dotyczące problemu, jak duży dostęp powinni mieć programiści do środowiska stworzonych przez siebie programów, przykro mi, ale nie jestem w stanie wam go udzielić. Każda firma jest inna, każdy zespół jest inny. Wiem, że to słaba odpowiedź, ale to zależy.

Jednak, jak każdy, kto oglądał ostatni sezon serialu Czysta Krew (lub, nie daj Boże, film Zmierzch: Zaćmienie) może zaświadczyć, że istnieją sposoby aby wampiry i wilkołaki współpracowały razem. W zdrowym zespole każdy czuje, że jego umiejętności są wykorzystywane i się nie marnują.

W naszym zespole wszyscy jesteśmy dosyć zaawansowanymi w kwestii administracji systemów. Ale są przecież miliony rzeczy do zrobienia i obecność profesjonalnego admina oznacza dla nas możliwość skupienia się tylko na programowaniu. Jesteśmy naprawdę zadowoleni z możliwości skoncentrowania naszych wysiłków na tym, w czym przecież jesteśmy ekspertami. Mimo to nie chcemy przekazywać całego dostępu do stworzonych przez nas serwerów. W pewnym szczęśliwym momencie nasz dostęp do nich zaczyna jednak być sporadyczny i zanika z biegiem czasu, za wyjątkiem, miejmy nadzieję rzadkich sytuacji awaryjnych wymagających wszystkich rąk do pomocy.

Sztuka zarządzania wampirami i wilkołakami polega według mnie na upewnianiu się, że zamiast spędzać czas na wzajemnej walce, wykorzystują one swoje ponadnaturalne moce razem, by osiągnąć wspólny cel, do którego nie da się dojść w inny sposób. Jak wynika z mojego doświadczenia, programiści i admini zwalczają się nawzajem zazwyczaj wtedy, kiedy się nudzą. Po prostu nie otrzymali wystarczająco trudnego zadania, które wymagałoby wspólnego wykorzystania w pełni ich ponadnaturalnych umiejętności.

Trzeba pamiętać, że nie chodzi o wampiry kontra wilkołaki. Cel to wampiry oraz wilkołaki.

Related Posts with Thumbnails