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

8 komentarze:

batman pisze...

Fajny tekst. Chociaż nie do końca mogę się z nim zgodzić. Klepanie kodu w pracy również rozwija. Na pewno znacznie mniej niż świadome ćwiczenia, ale rozwija. Ja mam to szczęście, że w swojej pracy co kilka projektów trafia się taki, który wymaga ode mnie nauczenia się czegoś nowego lub zgłębienia tematu, który kiedyś tylko liznąłem.

Odnośnie ostatnich dwóch rad. Pod pierwszą mogę podpisać się obiema rękoma i nogami. Bloga prowadzę niewiele ponad rok i rzeczywiście to pomaga.

pawlos pisze...

Bardzo fajny artykuł, ale sądzę, że większość osób, która traktuje programowanie jako pasję, część (jeśli nie większość) z tych rzeczy robi mimowolnie. Przynajmniej ja tak mam. Jeśli natomiast ktoś traktuje programowanie tylko jako zawód (nie mam nic przeciwko) to żadne posty na zmianę tej osoby nie wpłyną.

Pozdrawiam,
Paweł

MichalBe pisze...

to kata ktore tam jest na rysunku to Enpi z karate Shotokan, pozdrawiam:)

rafek pisze...

@MichalBe: Jeśli już, to Empi, ale ++ za spostrzegawczość :D

Tomasz Kowalczyk pisze...

Ja i tak jak natrafię na jakiś problem, to czytam absolutnie wszystko związane z tą tematyką oraz próbuję znaleźć co najmniej kilka równoważnych rozwiązań, także teoria + praktyka za każdym razem. Nie raz spędziłem długie godziny szukając "idealnego" rozwiązania, żeby potem napisać kilka linijek kodu.

Anonimowy pisze...

@rafek: Dobrze napisał, w japońskim "n" jest wymawiane jako "m", jeśli jest przed "p" albo "b".

Anonimowy pisze...

W punkcie 3 (w pierszej liście) najlepiej zrobić link do http://en.wikipedia.org/wiki/List_of_pioneers_in_computer_science bo na stronie Computer science nic o ludziach już nie ma.

Marek Stój pisze...

@Anonim: dzięki, poprawiłem ten link.

Prześlij komentarz

Related Posts with Thumbnails