Co ma wpływ na skuteczność naszego programowania na co dzień? Jest sporo czynników – wiedza, umiejętności techniczne, doświadczenie, motywacja, zaangażowanie, chęć do uczenia się. Innym ważnym czynnikiem jest organizacja pracy. Co prawda każdy ma swój sposób na pracę i wie kiedy dobrze mu się pracuje, jednak zauważyłem, że są pewne nawyki, które pomagają osiągnąć więcej podczas programowania.

W tym poście chce pokazać 7 przydatnych nawyków pracy, które osobiście stosuje, każdego dnia. Do niektórych można stosować narzędzia jednak większość to po prostu zmiana sposobu myślenia.

Dodatkowo na końcu zamieściłem wszystkie narzędzia jakie stosuje do organizacji swoj pracy w pracy jak i w życiu prywatnym. Zapraszam!

 

Nawyk 1 – Rozpocznij pracę o stałej porze.

Na początku nie byłem to tego przekonany. Jednak po miesiącu starania się o rozpoczęcie mojej  pracy dokładnie o 9:00 zauważyłem, że moje myśli  chwilę przed 9 zaczynają kierować się w stronę problemu i jego rozwiązywania. Innym plusem jest to, że nie trzeba marnować czasu na organizację pracy każdego dnia. Stały rozkład czynności do wykonania pozwala zwiększyć koncentrację.

 

Nawyk 2 – Planuj swój dzień

O planowaniu dnia może pisać całe stosy książek i cytować mądre eseje. Jednak tak naprawdę wystarczy po prostu dobrze przemyśleć co ma się dziś do zrobienia i najważniejsze, trzymać się planu i wykonać go. Jeśli ktoś z Was uważa, że nie potrzebuje planowania, wystarczy zrobić prosty eksperyment. W ciągu typowego dnia pracy należy zapisywać wszystko co się robi w ciągu dnia. Po całym dniu powinna wyjść lista rzeczy, które się zrobiło. Następnie należy procentowo wyliczyć czas spędzony na programowaniu. Wynik powinien Cię mocno zaskoczyć.

Planowanie dnia wykonuje przy pomocy kartki papieru. Piszę co mam zrobić i to robię. Na końcu dnia sprawdzam jak mi poszło i czy zrobiłem to co miałem zrobić. Polecam każdemu, ponieważ zadziwiająco mało osób planuje swój dzień w pracy.

 

Nawyk 3 – Opracuj rozwiązanie przed programowaniem

Na początku pracy zawodowej jako programista, robota paliła mi się w rękach i jak tylko dostałem zadanie od razu klikałem File -> New  -> Project itd. Takie programowanie na podstawie impulsu często (choć nie zawsze) kończyło się pytaniem jaki to ma sens?

Problemy, które się spotyka podczas takiej pracy są rozwiązywane na kolanie.  Później ujawnia się błędy projektowe, które powodują, że trzeba całe rozwiązanie przeprogramować. Takie przeprogramowanie zabiera mnóstwo sił i energii. Więc, nigdy nie zabieram się do pracy jeśli nie znam dokładnie rozwiązania.

Zauważyłem, że często jest tak, że wyceniam zmianę trochę w ciemno przykładowo na 20 dni pracy i mam stresa, że nie zdążę jak się nie zabiorę do kodowania od razu. Jednak, gdy najpierw opracowuje rozwiązanie to potem okazuje się, że sama implementacja jest już prostsza i szybsza. Dla przykładu mogę podać, że właśnie dla takiej 20 dniowej zmiany samo myślenie o rozwiązaniu zajęło mi 10 dni. Dopiero po 10 dniach pisałem pierwszy kod i o dziwo skończyłem szybciej niż myślałem.

Jednym z patentów, które stosuje to TTD. Napisanie paru testów (, które się nie kompilują oczywiście) jest bardzo pomocne w zrozumieniu zmiany, którą należy wykonać. Pomaga mi to, gdy mam ochotę kodować a nie mam jeszcze jasnej sytuacji o tym jak dane rozwiązanie ma wyglądać.

Jeśli coś można przetestować to znaczy, że podejście jest elastyczne.

 

Nawyk 4 – Szacuj zadania

Ten nawyk, pozwala na sensowne ocenianie swojej pracy i szybkości implementacji rozwiązania. Aby dobrze szacować pracę należy stosować prosty algorytm. Jeśli nie robiliśmy podobnej implementacji wcześniej, zapytajmy kogoś kto może już robił coś podobnego. Jeśli nie ma kogoś takiego oszacujmy ten czas na „czuja”. Po skończonym projekcie musimy zaktualizować swoje przewidywania. Po kilku zadaniach, będziemy prawdziwymi ekspertami w szacowaniu czasu na kodowanie. Taka wiedza pozwala zaoszczędzić wiele stresu podczas wielu projektów.

 

Nawyk 5 – Odłącz się od internetu

Należę do osób ciekawskich i często podczas kodowania gdy zapoznawałem się z jakąś metodą w API w dokumentacji szybko przeskakiwałem do innej metody i tak koniec końców zamiast szybko sprawdzić co i jak w metodzie to łapałem się na tym, że od godziny studiuje całą dokumentacje i poznaje dogłębnie każdy szczegół biblioteki . Podobnym pokusom ulegam czasem na stack overflow. Czytam o rozwiązaniu jakiegoś problemu, który mam w kodzie i klikam linki do kolejnych artykułów aż w końcu jestem zupełnie gdzieś indziej.

Polecam odłączyć się od internetu. TAK jest to możliwe, można kodować bez internetu. Oczywiście nie chodzi mi o całkowitą rezygnację z internetu chodzi raczej o to aby wykonać prosty algorytm:

• Zaplanować swój dzień.
• Opracować rozwiązanie przed jego właściwą implementacją.
• Zdobyć potrzebne informację, które są wymagane do wykonania zadania.
• Odłączyć się do internetu. Nie korzystać z niego. I programować przez 1,5 do 2 godzin.
• Na końcu należy sobie zrobić przerwę i przeanalizować co się udało a co nie.

Początki są trudne ale po miesiącu miałem sporo efektów. Koncentracja stała się ostrzejsza. A umiejętności planowania stały się efektywniejsze. Zdecydowanie polecam.

 

Nawyk 6 – Szukaj błędów w swoim kodzie.

Mimo, że nie robię wielu błędów w kodzie to, gdy słyszę, że jest problem o razu zaglądam do swojego kodu i analizuje czy to mój kawałek kodu mógł spowodować błąd. Tam gdzie można stosuje metodę pisania testu jednostkowego, który ma udowodnić, że w moim kodzie nie ma takiego błędu. Mimo, że z doświadczenia w obecnej pracy często zdarza się, że to nie mój kod stanowił problemu to jednak nawyk taki pozwala wykształcić u siebie pewną skuteczną metodę analizowania.

 

Nawyk 7 – Zapisuj rozwiązania błędów

Zapisywanie błędów i utrzymywanie listy top 10 najczęstszych błędów, które zdarzą się w danym środowisku pracy pomaga z szybkiej analizie przyczyn powstania błędów. Gdy pracuje z jakimś teamie programistycznym i słyszę, że jest problem to monitoruje to jak się udało ten problem rozwiązać. Gdy już znam rozwiązanie zapisuje to do listy top 10 błędów. Gdy znów pojawia się problem od razu lecę po liście i sprawdzam wszystkie pozycje w odniesieniu do powstałego błędu.

Dzięki takiemu podejściu można przede wszystkim zachować trzeźwość umysłu. Czasem jak się zafiksujemy w poszukiwaniu odpowiedzi przyczyny błędu to inne rozwiązania ulatują i tracimy nie potrzebne godziny na wymyślaniu przyczyn.

Prostym przykładem jest błąd w adresach do web  serwisów lub błędach w connection stringach. Adresy i connection stringi są w plikach *.config i często są modyfikowane przez administratorów. Sprawdzenie czy te wartości są dobre pozwala zaoszczędzić wiele pracy w analizie błędów.

 

Dobre rady zawsze w cenie

• Należy planować dzień w 80%, pozostałe 20% należy zarezerwować na nagłe kłopociki.
• Należy utrzymać porządek na swoim stanowisku pracy.
• Należy uczyć się na błędach innych. Zawsze pytam się jak ktoś rozwiązał swój problem i zapisuje to rozwiązanie. Czasem się przydaje.
• Odpoczynek jest równie ważny jak praca.
• Należy ufać sobie. Często zdarza mi się, ze wymyśle jakiś szalony pomysł ale czy to koledzy czy ja sam stwierdzam, ze to nie mozliwe. Na końcu okazuje się, że miałem racje i trzeba było robić tak od razu. Należy działać intuicyjnie i ufać sobie.

 

Narzędzia, które organizują moją pracę

• https://feedly.com – przeglądanie całych stron w poszukiwaniu nowych informacji jest za długie.
• http://doit.im/ – Getting Things Done – zdecydowanie polecam do pracy jak i do domu. Metodyka prosta jak budowa cepa. Narzędzie spełnia oczekiwania do tego stopnia, ze opłacam abonament 60zł per rok. Wersja mobilna i przeglądarkowa pokrywa całkowicie moje potrzeby.
• https://kanbanflow.com/ – metodyka angile wraz z licznikiem pomodoro http://en.wikipedia.org/wiki/Pomodoro_Technique. Jeśli ktoś nie zna polecam, pierwsze efekty miałem po miesiącu. Do tego można monitorować swój dzień w pracy pod kątem czynników, które nas rozpraszają.