Jak postępuje profesjonalny programista?

W tym artykule zostały opisane niektóre z głównych zasad, do których osoba uważająca się za profesjonalistę powinna się stosować. Przedstawiona tu wiedza jest dość skondensowana, by nie wydłużać tego tekstu, więc po obszerniejsze opisy odsyłam książki w bibliografii. Artykuł jest kierowany głównie do osób średnio zaawansowanych i bardziej doświadczonych początkujących.

Kim jest profesjonalista?

Po pierwsze jest to osoba odpowiedzialna. Nie szkodzi ona innym, a w przypadku, gdy coś się jej nie uda, to nie ucieka, a ponosi konsekwencje swoich błędów i naprawia wyrządzone szkody nawet wtedy, gdyby były ogromne. By zminimalizować prawdopodobieństwo popełnienia błędów, profesjonalista testuje swój kod.
Po drugie jest to osoba, która zachowuje etykę pracy. Oznacza to, że zna ona swoje otoczenie. Wie, co potrafi i czego się podejmuje. Jest ona pokorna i świadoma tego, że nie zawsze ma rację, że może się mylić w pewnych kwestiach, więc powinna liczyć się także ze zdaniem innych.
Po trzecie jest to osoba świadoma tego, że rynek IT rozwija się bardzo dynamicznie, więc by pozostać wartościowym programistą ciągle się uczy, ćwiczy i doskonali.

Prośby innych

Profesjonalista rozdziela dwie sytuacje – gdy jest proszony o drobną pomoc przez członka zespołu przy jego problemie oraz gdy sam jest pytany o to, czy może zrobić coś więcej albo szybciej przez jedną z osób zarządzających projektem. W pierwszym przypadku profesjonalista powinien się zgodzić jeśli jest w stanie pomóc, bowiem zespół istnieje nie tylko po to, by rozłożyć pracę na wielu pracowników, ale także po to, by razem planować i rozwiązywać problemy. Nie jest ważne to, by profesjonalista wykonał swoją część pracy jak najszybciej nie zważając na nic innego, a o to, by cały zespół zrealizował projekt w miarę możliwości wcześnie nie zapominając również o jego jakości.
Drugi przypadek jest bardziej złożony, gdy profesjonalista jest pytany o skrócenie deadline’u albo o dopisanie kilku nowych funkcjonalności. Wtedy przede wszystkim powinien zachować się odpowiedzialnie. Musi on bowiem wiedzieć, czy jest w stanie dokonać wszystkiego o co jest proszony w podanym terminie.

Zrób albo nie rób. Nie ma próbowania.
Yoda

Może odpowiedzieć albo „Tak”, albo „Nie”. Jeśli odpowiedź będzie brzmieć „Tak”, to profesjonalista zobowiązuje się wykonania podjętego zadania. Przy podejmowaniu takiej decyzji profesjonalista nie myśli o sobie, ale o dobru zespołu. Jeśli on wie, że jest w stanie wykonać dane zadanie, to zgodzi się. Natomiast w przeciwnej sytuacji, gdy profesjonalista ma wątpliwości albo jest pewien, że nie uda mu się wykonać danego zadania w określonym terminie, to mimo nalegań odmawia i stara się znaleźć rozwiązanie najlepsze dla zespołu, np. gdy postęp w rozwoju aplikacji ma być wkrótce pokazany klientowi, to ustala, które funkcjonalności programu powinny do tego czasu zostać ukończone, a które można tymczasowo pominąć.
Bardzo ważnym aspektem jest śledzenie swoich postępów pracy nad aktualnym zadaniem i jak najwcześniejsze zgłoszenie kierownikom zespołu informacji o możliwym problemie, jeśli profesjonalista zauważy, że może nie zdążyć z realizacją celu. Jest to odpowiedzialne zachowanie na rzecz dobra zespołu, bowiem im dłużej osoba ukrywa problem, tym większe szkody może ona wyrządzić.

Programowanie

Ważniejsze aspekty odnośnie samego procesu programowania:

  1. Profesjonalista nie tworzy, gdy jest zmęczony, zmartwiony czymś albo rozproszony, bowiem pracuje nieefektywnie i istnieje spora szansa, że tak powstały kod będzie trzeba zrefaktoryzować.
  2. Stan przepływu, tzw. flow ma negatywny wpływ na pracę. Osoba w takim stanie wprawdzie czuje się doskonale i szybko tworzy, jednakże zwiększa także ilość popełnianych błędów, na których poprawę będzie trzeba przeznaczyć dodatkowy czas.
  3. Profesjonalista jest uprzejmy wobec zespołu i z chęcią pomaga innym członkom. Potrafi także ich prosić o pomoc, gdy sam jej potrzebuje.
  4. W momentach, gdy nie jest produktywnym, często wspomaga się programowaniem w parach.
  5. Profesjonalista wie, że TDD (ang. Test Driven Development – rozwój sterowany testami) jest lepsze od debugowania, bowiem na dłuższą metę oszczędza się sporo czasu (a więc i pieniędzy!).
  6. Profesjonalista wyznacza sobie rytm pracy. Nie śpieszy się, bowiem to zmniejsza wydajność ani, jeśli to nie jest ostateczność, nie pracuje w nadgodzinach, bowiem jest się wtedy mniej produktywnym. Wie także, kiedy powinien odejść od programowania – zrobić sobie przerwę czy też zakończyć pracę na dany dzień.
  7. Kreatywność rodzi kreatywność. Dobra książka, film, muzyka czy inne dzieło potrafi zwiększyć produktywność.

Ciągłe doskonalenie się

Cytując wstęp do tego artykułu, profesjonalista

jest to osoba świadoma tego, że rynek IT rozwija się bardzo dynamicznie, więc by pozostać wartościowym programistą ciągle się uczy, ćwiczy i doskonali.

Profesjonalista powinien poświęcić około 20 godzin tygodniowo w tym celu. Częstym jednakże argumentem przeciw temu jest brak czasu na inne zajęcia. Tydzień ma 168 godzin, z czego 40 godzin to praca. Po odjęciu 20 godzin na doskonalenie się pozostaje 108 godzin. Zakładając 8-godzinny sen, czyli sumarycznie 56 godzin w ciągu tygodnia, to na inne zajęcia pozostaje 52 godziny. To jest brak czasu? Jeśli jesteś jeszcze studentem albo uczniem radzę sobie rozpisać w ten sposób dostępny czas i określić, ile jest się w stanie poświęcić na ćwiczenia.
Gdy już znajdzie się czas, powinno się ustalić w jaki sposób powinno się doskonalić. Po pierwsze – profesjonalista robi to dla siebie w swoim wolnym czasie, a nie dla zysku – pracuje on za darmo. Po drugie dba on o to, by miał szeroki zakres wiedzy. Nie uczy się więc czegoś, co już zna doskonale albo czym posługuje się w pracy, a coś nowego zwiększając sporo swoje kwalifikacje i wartość. Przykładowo jeśli profesjonalista w pracy wykorzystuje Javę, to w domu nauczy się C#, jeśli jeszcze tego języka nie zna w dobrym stopniu. Ważnym aspektem doskonalenia się są codziennie ćwiczenia. Tak jak biegacz codziennie biega czy piosenkarka śpiewa, tak i programista powinien codziennie ćwiczyć. Nie powinno to się ograniczać tylko do czytania tutoriali czy dokumentacji, bo samo to wiele nie da, ale powinien on także rozwiązywać proste problemy próbując swoich sił w nowych językach i frameworkach/bibliotekach.

Testowanie

Profesjonalista jest świadom tego, że lepiej jest wykorzystać TDD aniżeli później debugować kod. Testy jednostkowe są pisane przez programistów dla programistów, by mieć pewność, że napisany kod działa zgodnie z intencją ich twórców. Pokrycie kodu testami powinno być jak największe – teoretycznie powinno ono wynosić 100%. Kod, który nie jest testowany, tak naprawdę nie wiadomo co robi.

Trzy prawa TDD:

  1. Nie wolno napisać Ci nawet wiersza produktywnego kodu, jeżeli wcześniej nie napiszesz pasującego testu jednostkowego, który nie zostanie zaliczony.
  2. Nie wolno Ci napisać więcej testu jednostkowego, niż jest koniecznie, żeby test nie został zaliczony. Nieudana kompilacja też powoduje, że test nie jest zaliczany.
  3. Nie wolno Ci napisać więcej produktywnego kodu, niż potrzeba, żeby aktualnie oblany test został zaliczony.

Źródło: bibliografia [1]

Profesjonalista rozróżnia więcej rodzajów testów, aniżeli tylko jednostkowe. Warte uwagi są testy akceptacyjne. W przeciwieństwie do testów jednostkowych, te testy są pisane przez nie-programistów dla nie-programistów. Testy akceptacyjne mają być prostymi testami z niewielkim pokryciem kodu, bowiem ich zadaniem jest określenie wszystkich funkcjonalności jakich klient sobie życzy w gotowym oprogramowaniu.
Nie można zapomnieć, że testy powinny być zautomatyzowane. W przeciwnym wypadku będą one kosztować sporo czasu, pracy i pieniędzy. Testy powinny być także tak pisane, by później kontrola jakości nie znalazła żadnych błędów we wstępnie gotowym produkcie.

Zarządzanie czasem

Czas profesjonalisty jest cenny i dla dobra zespołu mądrze on nim zarządza. Spotkania przy pracy zespołowej są niezbędne, bowiem bez wspólnego planowania, omawiania problemów i podsumowywania projekt prawdopodobnie nie zostałby nigdy ukończony. Niemniej jednak nierozsądnie prowadzone spotkania mogą być marnotrawstwem czasu. Zatem jeśli na danym spotkaniu nie jest wymaga obecność danej osoby oraz nie uważa ona poruszanego na tym spotkaniu tematu za przydatny – odmówi ona udziału. Także w trakcie spotkania, jeśli zmieni ono swój cel – taka osoba wyjdzie albo poprosi o przywrócenie pierwotnego planu spotkania.
Dobrym pomysłem są spotkania na stojąco, podczas którego każdy z uczestników odpowiada na trzy pytania, przeznaczając 20 sekund na każde z nich:

  1. Co dzisiaj zrobiłem?
  2. Co mam zrobić jutro?
  3. Co mi przeszkadza?

Pozwoli to na przeprowadzenie szybkiego podsumowania oraz wyłapanie istotnych dystraktorów spowalniających pracę.
Profesjonalista nie brnie w „bagna” i „bałagan”. Gdy widzi, że dany kod mógłby być lepszy, albowiem aktualnie sprawia chociażby lekkie problemy, przepisuje go na czysto. Jest on bowiem świadom tego, że prędzej czy później będzie zmuszony do uczynienia tego, jednakże im dłużej będzie zwlekać, tym więcej pracy sobie nadłoży, a możliwe, że także innym.
Kolejnym aspektem jest praca w blokach krystalicznego skupienia (pisałem już o tym wcześniej). Warto jest pracować w blokach 30-50 minutowych z 10-15 minutowymi przerwami. Gdy ktoś będzie czegoś chciał, to prosi się taką osobę, aby przyszła wtedy, gdy wypada przerwa w pracy. W tym czasie powinno także odciąć się od wszelkich innych dystraktorów, takich jak przykładowo komunikatory czy portale społecznościowe. Ten czas ma być czasem maksymalnej koncentracji. Odpowiednie spędzanie przerw także jest istotne – jeśli istnieje taka możliwość to warto odejść od komputera i wyjść na świeże powietrze. Dzięki temu programista będzie dużo bardziej produktywny.

Presja

Presja zmniejsza produktywność, dlatego profesjonaliści jej unikają. W tym celu nie podejmują zbędnych zobowiązań, by nie dokładać sobie niepotrzebnych zmartwień, utrzymują czysty kod, by nie martwić się, jak go dalej rozwijać oraz w trakcie kryzysu nie zmieniają swojego podejścia do pracy, bowiem taka zmiana oznaczałaby, iż to nowe podejście jest lepsze od standardowego, co implikuje, że wcześniej ta osoba nie pracowała najlepiej jak tylko potrafiła, co świadczy tylko o braku profesjonalizmu.
Jeśli presja już nadejdzie, to profesjonalista nie panikuje. Informuje swój zespół i przełożonego o problemie i nadal polega na swoich sprawdzonych, standardowych metodach pracy. Czasem dobrym pomysłem jest także programowanie w parach, bowiem zmniejsza to prawdopodobieństwo popełnienia błędu oraz gdy jedna z osób nie jest w stanie pracować, to druga przejmuje inicjatywę.

Bibliografia

Jeśli ktoś byłby zainteresowany, to zamieszczam tutaj swoje notatki z tej książki. Nie tworzyłem ich z myślą o publikacji, więc od razu informuję, iż nie wszystkim one wiele dadzą. Niemniej jednak jest tam więcej informacji, więc zaciekawionych odsyłam do nich. Mimo wszystko polecam przeczytanie całej tej książki, bowiem można z niej wynieść naprawdę sporo. Jest ona napisana na podstawie ponad czterdziestu lat doświadczeń programisty zwanego popularnie Uncle Bob i całkiem ciekawie się ją czyta.

Co sądzicie o tym poście i jego bardzo skondensowanej formie? Albo może jakieś uwagi albo przemyślenia odnośnie treści? Dajcie znać w komentarzach!

6 myśli nt. „Jak postępuje profesjonalny programista?

  1. Sądzę, że wypowiadanie się o tym jak postępuje profesjonalny programista tonem ewangelisty mając 17 lat jest najlepszą drogą do zostania dostawcą beki reszcie internetu.

    Przy okazji, jak już piszesz coś co aspiruje do bycia biblią to weź chociaż stosuj się do zasad stylistyki języka polskiego 😀

    „Kod który nie jest testowany, tak naprawdę nie wiadomo co robi.”

    • Dziękuję za zgłoszenie tego błędu. Przed publikacją tekstu zawsze go czytam w całości co najmniej jeden raz i poprawiam błędy, które mi umknęły podczas pisania, niemniej jednak jestem tylko człowiekiem 🙂

      Sądzę, że wypowiadanie się o tym jak postępuje profesjonalny programista tonem ewangelisty mając 17 lat jest najlepszą drogą do zostania dostawcą beki reszcie internetu.

      We wstępie zaznaczyłem, że ten tekst jest kierowany głównie do osób średnio-zaawansowanych oraz początkujących. Nie jestem jeszcze profesjonalistą, to prawda, dlatego oparłem się na doświadczeniu Roberta C. Martina i jeśli mnie pamięć nie myli, to w tekście powyżej nie opisywałem nic więcej. Co Cię w nim bawi? Chętnie się dowiem. W końcu ludzie uczą się na własnych błędach 🙂 . Na Facebooku spotkałem się z pozytywnym feedbackiem, więc z niego wiele się nie nauczyłem.

      PS w trakcie pisania tego artykułu miałem więcej ukończonych lat 😉

    • Można mieć takie wrażenie, jednakże tekst ten ma raczej formę notatki z książki R. Martina, niż „własnych przemyśleń” autora.

      Mi się wpis podoba, bo zastanawiałem się na kupieniem tej książki, i teraz już wiem o czym mniej więcej jest.

      • Widzę, że ktoś ściągnął i przeglądnął moje notatki – bardzo się z tego cieszę 🙂 .

        Tak, ten tekst to w większości rady wyciągnięte ze wspomnianej książki. Stwierdziłem, że zawiera ona wiele ciekawych informacji, i że warto się częścią z nich podzielić.

  2. „Stan przepływu, tzw. flow ma negatywny wpływ na pracę. Osoba w takim stanie wprawdzie czuje się doskonale i szybko tworzy, jednakże zwiększa także ilość popełnianych błędów, na których poprawę będzie trzeba przeznaczyć dodatkowy czas.”

    Nie jestem do końca pewien czy dobrze rozumiem czym jest ten „flow”, ale jeśli chodzi o sytuację, kiedy programista ma wenę twórczą i napływ energii do pracy, to zamiast marnować ten potencjał, mówiąc „Nic nie rób, bo działasz pod wpływem emocji” powiedziałbym raczej „prototypuj!”

    Po prostu poświęć ten czas na tworzenie kodu, który może i będzie miał błędy, ale ma na celu wyłącznie przetestowanie nowych pomysłów, a do gotowego produktu nigdy nie trafi.

    Odsyłam chociażby do artykułu:
    http://gamasutra.com/view/feature/179501/rapid_prototyping_tips_for_.php

    Zresztą podobną filozofię promuje system wersjonowania Git. Zalecają tworzyć liczne gałęzie, w których testujemy różnorakie pomysły – nie każda gałąź musi trafić do mastera.

Dodaj komentarz