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

Related Posts with Thumbnails