Udostępniając artykuł pomożesz mi rozwinąć blog. Weź w tym udział!

..ale nie wieszaj się na tym! To wieszanie się to jest rzecz, która najczęściej zdarza się młodym programistom jako wpadka – nie to, że coś zrobi się źle, albo że można było prościej i wygodniej, nie. To w sumie normalne. Ale to, że zamiast robić, wisisz, że zamiast pracować, czytasz tutki, z których nic nie rozumiesz, że pytasz o zbyt wiele i niepotrzebnie. Bardzo trudno jest tutaj wyważyć jak długo szukać, a kiedy już prosić o pomoc. Przez długi czas mi to wyważenie nie wychodziło.

Są dwa sposoby rozwiązywania problemów programistycznych:

1. nauczyć się danej dziedziny i rozwiązać problem na podstawie zdobytej wiedzy
2. poprosić o pomoc kogoś, kto taki problem już rozwiązał i zastosować jego rozwiązanie w sposób magiczny (kopia czyjegoś rozwiązania z netu też tutaj się łapie)

Co to jest sposób magiczny?

To mniej więcej: „Jakoś działa.” Ewentualnie: „skopiowałam i działa” albo „on tak miał”. Jeśli nie umiesz odpowiedzieć na pytanie „Dlaczego?”, to jesteś magikiem programistą! Taki magik działa szybko i sprawnie. Jak czegoś zaczarować nie potrafi, to mówi, że się nie da, albo że do tego potrzeba dużo więcej magików. O dziwo, często ma rację 🙂

Czasem ktoś mówi, że można zastąpić programistów maszynami. Może to właśnie o tę część automagiczną chodzi? Bo to by się dało zrobić maszynowo..

Czy zawsze warto się uczyć?

O, i to jest pytanie! Jestem pasjonatką wiedzy i umiejętności, więc trudno mi powiedzieć… ale nie. Nie zawsze warto. A przynajmniej nie zawsze warto od razu! Powiem Ci, co ja robię:

Kiedy mam do wykonania zadanie w pracy, to moim priorytetem jest je wykonać dobrze i w zgodzie ze standardami. Pomijam tutaj zadania oczywiste, które wymagają przejścia pewnej sekwencji czynności, które są standardowe i wszystkim znane. Nie. Mam tutaj na myśli zadania bardziej wymagające, nieoczywiste. Przynajmniej dla mnie nieoczywiste. Co robię po kolei?

• zastanawiam się, gdzie szukać rozwiązania, na czym bazować, co jest do dosprawdzania
• pytam zespół albo kogoś bardziej doświadczonego, co oni myślą
• w wersji optymistycznej dostaję odpowiedź: „nie, to jest banalne, zobacz: tak, tak i już” i mam po kłopocie
• w wersji bardziej życiowej dostaję informację gdzie szukać i doczytuję
• często nie rozumiem zbyt wiele z tego, co czytam i tylko przeklejam kody, i trochę na ślepo intuicyjnie staram się je zaadaptować do swojego problemu
• jednocześnie wypisuję sobie do nozbe (czy gdziekolwiek indziej), co powinnam doczytać i jakich pojęć nie rozumiem
• jak jest czas doczytuję podstawy teorii danej dziedziny / zagadnienia
• w przypadku braku postępów w ukończeniu zadania i zbyt długiego kręcenia się w kółko, mimo doczytanych podstaw teorii, idę z moją niedziałającą próbą do mądrzejszych
• po pracy / w spokojniejszym czasie / w czasie przewidzianym przez pracodawcę na samorozwój – sprawdzam notatki z placu boju i douczam się. Często dopiero wtedy zaczynam rozumieć co wtedy zrobiłam i dlaczego tak. Kod niejednokrotnie jest już na produkcji
• duma

Trudności

Duma rozpierająca po wykonaniu trudnego zadania jest super nagrodą za cały wysiłek i łatwo wtedy zapomnieć o Bożym świecie. Pierwsza trudność właśnie na tym polega: już zrobiłam, to po co jeszcze mam o tym czytać? TRZEBA. Zawsze trzeba kontynuować naukę. Masz już doświadczenia zmagania się z tematem i jakąś rozsypaną zwykle i nieuporządkowaną, tymczasową wiedzę. Trzeba sięgnąć do książki, tutoriala czy dokumentacji i uchwycić tą wiedzę. Uporządkować. Złapać te rozbiegane kotki i wtedy mieć wielki powód do dumny: „teraz już wiem”. Prawdziwy programista w momencie wgrania swojego kodu na produkcję albo może tydzień potem, mówi: „teraz zrobiłbym to lepiej / szybciej”. O, i to jest ten rozwój i ten pęd do wiedzy, który warto w sobie pielęgnować.

Udostępniając artykuł pomożesz mi rozwinąć blog. Weź w tym udział!