Przejdź do głównej zawartości

Wydajność programisty i "uważność" w kodzie


Podczas biegu, nauczyłem się skupiać swoją uwagę na oddechu, na odpowiednim stawianiu kroków, co w naturalny sposób przekłada się również na moje wyniki. Jeśli wyobrażę sobie ciężkie łańcuchy przyczepione do ciała, zwolnię. Jeśli oczyszczę umysł, moje ciało będzie pracować jak silnik Toyoty. Ludzki umysł nie zastanawia się, czy to co mu serwujesz jest prawdziwe, nie ma tutaj żadnej walidacji. Dlatego sam musisz zadbać o to, jakimi myślami go karmisz.

Zasada pierwsza - podejście do zadania. 

 

 


Jeśli na początek tygodnia dostajesz duże zadanie,  to nie marnuj swojej energii na marudzenie o tym, jak ciężko Ci będzie - bo tak będzie i popłyniesz na parę dni, zanim otrząśniesz się z przeświadczeniem, że zmarnowałeś czas. Zamiast tego skup swoją uwagę na konkretach, weź ciężki młot jakim jest Twoje doświadczenie i uderz nim w ten wielki betonowy blok, niech się rozbije na kawałeczki - wtedy łatwiej Ci będzie unieść każdy z nich - tak jest, dziel zadanie na kawałki! Jesteś doświadczonym programistą, patrząc w przeszłość uświadomisz sobie że z większymi zadaniami radziłeś sobie w łatwy sposób.

Zasada druga - Pan Deadline. 

 



Nic bardziej nie motywuje tak jak "deadline". Niestety ludzie są już tak skonstruowani, że największą wydajność odnotowujemy podczas stresu. Musisz się zaprzyjaźnić z Panem Deadlinem, niech będzie Twoim trenerem stojącym nad Tobą ze stoperem. Jeśli dostajesz zadanie na parę dni, to na początku spróbuj je raz jeszcze oszacować, następnie ustal sobie termin znacznie krótszy - termin tylko dla Ciebie, bardzo optymistyczny i postaraj się go dotrzymać. Jeśli wyrobisz się z zadaniem o dzień wcześniej, będziesz miał więcej czasu np. na refaktoryzację, optymalizację, doszlifujesz kod lub też po prostu nabijesz sobie punktów w zespole pomagając koledze :) 

Możesz pomyśleć, że jeśli skracasz sobie termin, to pewnie kod nie będzie tak doskonały, jak ten który mógłbyś napisać mają więcej luzu? Niestety nie jest to prawdą. Badania dowodzą, że gdy pracownicy skupiają całą swoją energię i czas na wytworzenie jednego "idealnego" produktu, to okazuje się on nie być lepszy od produktu wytworzonego metodą prób i błędów.
Jak myślisz, o ile przedłużyłby się postęp technologiczny, gdyby twórcy pierwszego koła zamiast nad funkcjonalnością której wtedy potrzebowali, skupiali się nad tym aby ich wynalazek miał od razu felgę oraz oponę pneumatyczną?
Po prostu w czasie którym dysponujesz skup się tylko na zadaniu, uwzględniając przy tym dobre praktyki programowania (np. SOLID/GRASP), nie rób nic ponadto - jeśli coś będzie potrzebne w przyszłości, pewnie się o tym dowiesz. Twój kod wyewoluuje, będzie iteracyjnie doskonalony. Tymczasem nie baw się w przepowiadanie przyszłości.

 Zasada trzecia - "uważność" w kodzie. 

 



„Nie błądźmy wśród rozproszonych myśli i tego, co nas otacza"


Nad czym myślisz pisząc kolejną klasę? Rozpisałeś sobie wcześniej algorytm wg którego ma działać Twój mechanizm i posuwasz się stale do przodu, czy może znowu kursor stoi bezczynnie a Ty myślisz o tym co dzisiaj będzie na obiad? Prawda jest taka, że pracodawca może robić wszystko aby podkręcić śrubę pracownikowi, ale to na niewiele się zda, jeśli pracownik sam nie zacznie się dyscyplinować. Musisz być "uważny w kodzie". Pewnie nie raz Ci się zdarzyło wpatrywać bezczynnie w jakiś punkt - wtedy właśnie odleciałeś z myślą z danej chwili. Uważność to nic innego jak bycie świadomym czynności którą obecnie wykonujesz. Ocknij się gdy znowu zaczynasz myśleć o niebieskich migdałach, nakieruj swoją uwagę na cel i dąż do niego.

Pamiętam jak w podstawówce Pani od języka polskiego, kazała dzieciom zapisać na osobnej kartce tematy swoich wypracowań, kartki te miały być cały czas widoczne. Powodowało to, że dzieci trzymały się ustalonego tematu i nie odbiegały od niego. 
Dlatego ważne jest abyś sam tworzył takie punkty zaczepienia - zanim zaczniesz pisać klasę, rozpisz sobie własnymi słowami, co klasa powinna robić. Z doświadczenia wiem, że fazy myślenia o obiedzie przychodzą wtedy, gdy w danym momencie pojawia się blokada - nie wiesz co dalej. W takich momentach wystarczy spojrzeć do swojego scenariusza, do ostatniego punktu zaczepienia. 

Komentarze

Prześlij komentarz

Popularne posty z tego bloga

PHPers Summit 2018. Własne podsumowanie i podstawowy wachlarz programisty

W miniony weekend odbyła się konferencja PHPers Summit 2018. Dla mnie pobyt na tej konferencji był mocno motywujący. Mogłem zobaczyć jak inni programiści i firmy się rozwijają. Skonfrontować czy rzeczy które szerzymy w naszej organizacji są dobre i czy idziemy w dobrą stronę. Postanowiłem wybrać prelekcje z których przewidywałem, że nabyta wiedza może mi się przydać w pracy. Dlatego było dużo z jakości kodu, podejścia do legacy oraz architektury. Wachlarz programisty  Zaczęło się spokojnie, od prezentacji na temat Magento. W jaki sposób ten framework się rozwinął, od zaszłości takich jak obiekt Mage po obecnie dobre rozwiązanie jak Inerceptory - ten wzorzec został przedstawiony jako połączenie Proxy i Dekoratora, dzięki czemu Magento mogło pozwolić sobie na luźne powiązania pomiędzy bibliotekami. Ciekawym przykładem też jest ich guide: " Programming Best Practices ". Myślę, że każda organizacja powinna dążyć do stworzenia takiego miejsca. Sporo było podstaw o któryc