Przemyślenia praktykanta #3

Witam!

Moje praktyki trwają już ponad miesiąc (pozostały jeszcze dwa) i był to wspaniały okres, który oprócz ogromnej porcji wiedzy, doświadczenia i przyjemnej pracy dostarczył mi wiele powodów do zatrzymania się i porządnego zastanowienia (o czym można już było przeczytać już tutaj i tutaj). Sądzę, że jest to najlepszy moment na podzielenie się kolejną porcją przemyśleń. A więc do dzieła :)

10) Nie bójmy się porażek - stare przysłowie mówi: "Kto nie gra, ten nie wygra" i uważam, że idealnie pasuje ono do okresu praktykowania. Jeżeli nie będziemy próbowali sparaliżowani perspektywą porażki lub (co jest niedorzecznością w trakcie praktyk, ale i później także w dużym stopniu) ośmieszenia się przed resztą zespołu to nigdy nie dowiemy się, czy nasz pomysł jest dobry, czy zły, nie będziemy wiedzieli wiedzieli w przyszłości, czy tego typu rozwiązań powinno się unikać, jakie niosą za sobą konsekwencje etc. Nie wierzmy na słowo, sprawdzajmy swoje pomysły, bawmy się przy metodzie prób i błędów.

11) Nie bójmy się zmian - po jakichś 3 tygodniach pracy nad projektem, który przydzielono mi na samym początku praktyk odbyłem bardzo długą rozmowę z opiekunem praktyk, każdy z nas podzielił się z drugim wrażeniami odnośnie wykonywanego projektu, jego szans, moich dotychczasowych umiejętności, priorytetów firmy i wielu, wielu innych spraw. Jaki był skutek tej rozmowy? Postanowiliśmy zarzucić obecnie wykonywany projekt i przejść w trochę inny rodzaj, w dodatku już w trakcie tworzenia przez pewną grupę. Z początku było mi ciężko dopisywać ostatnie linijki kodu do starego projektu (ustaliliśmy, że nie zostawiamy nieskończonych task'ów i że przejdę dopiero po wykonaniu wszystkich zadań jakie mi opiekun wcześniej wyznaczył), ale potem doszło do mnie, że ta zmiana może okazać się dużą szansą - i tak faktycznie było! Mam okazję na co dzień współpracować z grupą (małą, ale dzięki temu nie czuję się przytłoczony) doświadczonych developerów i podpatrywać ich w akcji :)

12) Nie jesteśmy robotami - Tamtego dnia, gdy postanowiliśmy ze Sławkiem, że kończymy pracę nad jednym projektem, a zaczynami nad drugim, nasza rozmowa była najdłuższą czynnością jaką wykonałem, ale okazała się najbogatsza w wiedzę, możliwość spojrzenia na projekt okiem kogoś, kto nim zarządza. Do czego zmierzam? Do tego, że nikt nie oczekuje, iż będziemy siedzieli przed komputerem pełne 8 godzin od 9 do 17, nie wytykając nosa poza box poza krótką przerwą na drugie śniadanie. Czasem krótki czas spędzony daleko od biurka może przynieść więcej korzyści, niż kilka godzin siedzenia na tyłku męcząc się z jakimś zagadnieniem. Dla mnie takim miejscem odsapnięcia jest kuchnia (z uwagi na ekspres do kawy ;) ) i muszę przyznać, że rozmowy tam (a także ich brak, gdy nikogo w kuchni nie ma) potrafiły przybliżyć mnie do rozwiązania problemu bardziej niż siedzenie z tym problem tête à tête przez pół dnia.

13) You Ain't Gonna Need It - czyli w skrócie YAGNI, jest zasadą mówiącą, że powinniśmy dodawać do projektu nową funkcjonalność dopiero w momencie, gdy ta funkcjonalność jest niezbędna. Dzięki temu unikamy nadmiernego rozrostu projektu i koncentrujemy się (a co za tym idzie lepiej wykonujemy) na tym, co najważniejsze. Osobiście miałem ten problem przy swoim pierwszym samodzielnym projekcie na praktykach - zacząłem dodawać nowe funkcjonalności nie pokrywając dostatecznie testami już stworzonych i po niedługim czasie mój system był dziurawy jak ser szwajcarski, duży, ale z małą ilością prawdziwej funkcjonalności. Na całe szczęście mam opiekuna, który w każdej chwili jest gotów ściągnąć mnie na ziemię i wskazać najodpowiedniejszy kierunek działań :) Jest to bardzo dobre, póki jeszcze sami nie jesteśmy w stanie dostrzegać i wykonywać najistotniejszych zadań w pierwszej kolejności. Wydaje się, że stoi to w sprzeczności z podchodzeniem do pracy z postawą eksperymentatora i metodą prób i błędów? Nie będę sam wynajdywał koła i powołam się na artykuł kogoś, kto umie to wytłumaczyć znacznie lepiej ode mnie - mówię tu o artykule "Bo w życiu trzeba... być Agile:)" Sławomira Sobótki.

14) Nie taka dokumentacja zła jak ją malują - w obecnych czasach podobno zaledwie kilka firm na świecie przyznaje się do tego, że nie jest "zwinna", raptem jedna indyjska firma oficjalnie ogłosiła, że nie jest firmą pracującą w oparciu o zwinne metodyki. A z czym ludziom kojarzy się zwinna firma? Z brakiem dokumentacji, z końcem biurokracji itp. Ale czy naprawdę dokumentacja jest takim złem? Kiedy w zeszłym tygodniu zmieniłem projekt, za zadanie miałem (i nadal mam) uzupełnienie i aktualizacja dokumentacji tegoż projektu. Z początku bardzo mi się to nie spodobało, ale po kilku godzinach badania projektu zdałem sobie sprawę, że jest to idealna okazja na dogłębne poznanie obszaru, nad którym mam pracować. Daje mi to też możliwość zadawać trudne pytania autorom konkretnych fragmentów kodu, jeżeli jakieś zachowanie jest niejasne lub zwyczajnie nie działa tak jak do tej pory było to opisane. Po dwóch dniach spędzonych nad dokumentacją dostałem do wykonania proste zadanie poprawy drobnego kawałka kodu i dzięki zdobytej wiedzy rozwiązanie problemu zajęło (dosłownie!) 5 minut wraz z przetestowaniem.

Na razie to wszystko. Pozdrawiam i do następnego razu! :)