Najczęściej popełniane błędy przez młodych programistów

„Błądzić jest rzeczą ludzką”, jak to powiedział Seneka Starszy. Jego słowa można dopełnić stwierdzeniem Edwarda Johna Phelpsa, że tylko ludzie, którzy nic nie robią, nie popełniają błędów. W tym artykule przygotowałem listę najczęściej popełnianych błędów wśród młodych programistów jak i osób dopiero co zaczynających swoją przygodę ze światem programowania. Zatem do sedna! 

Sama teoria nie wystarczy

Podczas swojej, prawie 10 letniej kariery w IT pracowałem z różnymi osobami w kilku różnych firmach. W każdej z nich trafiłem na juniorów, którzy idealnie wpisywali się w kanon programisty teoretyka. Wiedzę teoretyczną mieli taką, że zagięli by nią niejednego seniora. Zdarzało się, że przechodzili rozmowy rekrutacyjne bez zająknięcia, rzucając formułkami jak z rękawa. Problem zaczął się, gdy przyszło do napisania bardziej złożonego fragmentu kodu. Wtedy, niestety ta wiedza im nie pomagała. Mimo iż mieli wykute na blachę formułki to bardzo często zdarzało im się utknąć w martwym punkcie, ponieważ brakowało im praktyki.

Aby zostać programistą, nie wystarczy sama znajomość formułek czy wiedza ilu bitowy jest int w C# czy Javie. Ważniejsze niż wykucie tych formułek na pamięć jest zrozumienie mechanizmów na podstawie, których działa komputer. Formułki można bardzo łatwo i szybko odnaleźć w Internecie np. w dokumentacji danego języka. Natomiast braki związanie z niedoborem praktyki dużo trudniej jest nadrobić. Dlatego też wdrożenie jej już na początkowym etapie nauki jest bardzo ważne.

Według mnie najlepszym i najbardziej optymalnym sposobem nauki programowania jest tak naprawdę samo programowanie. Wiem że to brzmi banalnie, ale to prawda. Najlepiej uczyć się tej tajemnej sztuki, poprzez praktykę! Więc proszę Cię drogi juniorze nie zapominaj o pisaniu projektów i przekuwaniu swojej wiedzy teoretycznej w praktykę!

Przeglądając Internet możesz znaleźć wiele książek, kursów, szkoleń czy bootcampów programistycznych. Nieważne jaką ścieżkę nauki wybierzesz, bez pisania kodu trudno będzie Ci osiągnąć sukces. Nie wystarczy samo przepisywanie kodu pokazanego w materiałach, z których się uczysz. Owszem, jest to dobry punkt wejścia, ale uwierz mi, że dużo lepiej będzie, jeśli spróbujesz ten kod zmienić. Dzięki temu będziesz miał/-a okazję dokładnie zrozumieć co on robi i jak działa.

Niekończenie projektów

Masz pomysł na projekt? Ekstra, to bardzo dobry moment by go zacząć. Na początku Twojej przygody z programowaniem nie musi być on bardzo zaawansowany, ważne aby pozwolił Ci wykorzystać w praktyce to, czego się do tej pory nauczyłeś/-aś. 

Jeśli nie masz pomysłu na oryginalny projekt, nie bój się spróbować odtworzyć czegoś, co już istnieje. Takie podejście pozwoli Ci przetestować swoją wiedzę i ma to też swoje plusy. Pracując przy próbie stworzenia np. sklepu internetowego, możesz sprawdzić jak dane mechanizmy działają na już istniejących platformach, a następnie dostosować je pod swoje wymagania.

Nieważne co wybierzesz, ważne abyś postarał/-a się doprowadzić projekt do końca. Sam często mam z tym problem, ponieważ w trakcie prac, bardzo często pojawia mi się pomysł na kolejny i jeszcze kolejny projekt i zdarza się, że porzucam pracę nad obecnym. Ale końcowa faza projektu pozwala zdobyć kolejne umiejętności związane z wydawaniem i zamykaniem aplikacji. 

Według mnie doprowadzanie projektów do końca podczas nauki programowania jest wręcz kluczowe, ponieważ pozwoli Ci zakończyć pewien etap nauki oraz zobaczyć jak trudne jest zamykanie projektu. Zawsze znajdzie się coś co można poprawić/zrobić lepiej. Wyjdą jakieś bugi, pojawią się pomysły na nowe, kluczowe wręcz funkcje aplikacji.

Pisanie projektów do szuflady

Jeśli uda Ci się napisać coś z czego jesteś dumny/-a, coś co oddaje Twoje programistyczne umiejętności, nie bój się pokazać tego światu! Projekty, które publikujesz najlepiej przedstawią Twój poziom umiejętności. Jako rekruter techniczny, widząc że kandydat/-ka dołączył do CV swoje repozytorium np. na Githubie, sprawdzam to jako jedną z pierwszych rzeczy. Jestem bardzo ciekawy projektów, nad którymi wcześniej pracowali kandydaci - uwierz mi, że te często potrafią mnie bardzo pozytywnie zaskoczyć. Ponadto opublikowane projekty potwierdzają umiejętności oraz doświadczenie kandydata/-ki.

Podsumowując temat własnych projektów i nauki, bardzo ważne jest aby podczas programowania nie zapominać o tym, że najlepiej uczyć się poprzez faktyczną pracę, czyli w przypadku osób które dopiero zaczynają swoją przygodę z IT, podczas pisania swoich projektów. Ważne też abyś starał/-a się je zamykać oraz publikować. Bo kto wie, może to właśnie one przechylą szalę zwycięstwa w trakcie rekrutacji na Twoją stronę? Dobrze zbudowane portfolio wpływa pozytywnie na Twoją markę osobistą. Jeśli chciałbyś/-abyś dowiedzieć się więcej o programistycznym portfolio zapraszam do przeczytania mojego wcześniejszego artykułu: Portfolio programisty – jak nas widzą tak nas piszą?

Ślepe kopiowanie fragmentów kodu bez jego zrozumienia

Kolejną grupą błędów, szczególnie często spotykaną wśród juniorów, jest kopiowanie kodu z rozwiązaniem bez zastanowienia się co on tak naprawdę robi. Nie mam nic przeciwko kopiowaniu kodu. Sam czasami wspomagam się źródłami lub materiałami dostępnymi np. na StackOverflow. Rozwiązania tam umieszczanie często skracają czas potrzebny na rozwiązanie jakiegoś problemu. 

Największym problemem kopiowania ze Stacka wśród osób z mniejszym doświadczeniem jest to, że czasami nie zastanowią się nad tym, co kopiują. Zdarza się, że w ten sposób przemycane są bugi do programu, bo to rozwiązanie nie pasuje w 100% do naszej architektury lub łamane są zasady związane z pisaniem kodu wewnątrz firmy. Drogi juniorze, jeśli decydujesz się na przekopiowanie jakiegoś fragmentu kodu, postaraj się chociaż dostosować go do konwencji używanych w projekcie lub standardów w firmie. Nie ma nic złego w rozsądnym kopiowaniu.

Wiara we wszystko co powie senior

Senior developer to też zwykły człowiek. Ba! Często nawet bardzo zapracowany. W związku z tym, on również może popełniać błędy jak i się mylić. Przytoczę tutaj historię z czasów, kiedy sam byłem dosyć młodym pracownikiem i zaczynałem swoją przygodę w branży w jednej z lokalnych firm w Jeleniej Górze. Byłem chwilę po technikum informatycznym i dopiero stawiałem pierwsze kroki w świecie programowania. 

Jako młodszy programista zostałem przypisany do naprawy bugów i utrzymania jednego z naszych produktów. Pewnego dnia zacząłem pisać fixa i zauważyłem, że mogę dołożyć do programu jeden bardzo prosty mechanizm, który pozwoli mi na dostosowanie konfiguracji programu pod konkretną maszynę (jeśli posiada ona jakieś nietypowe ustawienia).

Po pozytywnie przeprowadzonych testach oraz skończeniu poprawki oddałem kod do procesu CodeReview. Podczas niego jeden ze starszych programistów, którzy również byli przydzieleni do tego projektu, zakwestionował ten kod. Będąc przekonanym, że to rozwiązanie pomoże nam łatwiej i szybciej rozwiązać problemy u klientów z bardzo specyficzną konfiguracją postanowiłem, że spróbuję obronić swoje rozwiązanie, ponieważ po głębszym zastanowieniu nadal uważałem, że jest ono dobre i przydatne. Ponadto byłem w stanie wymyślić rzeczywiste scenariusze jego użycia.

Postanowiłem umówić się z seniorem na spotkanie w celu omówienia mojego rozwiązania. W wyniku tego spotkania ta funkcja została w programie i faktycznie okazała się przydatna. Wniosek z tego taki, że jeśli jesteś pewien tego co napisałeś/-aś, to może warto zorganizować sesję z senior deweloperem, na której omówicie kwestie, które was różnią. Jeśli tylko będziesz miał/-a rozsądną argumentację, senior pewnie przyzna Ci rację.

Nie bój się wierzyć w swoje umiejętności. Jeśli uważasz, że ktoś z większym doświadczeniem myli się w kontekście Twoich zmian to najlepszym rozwiązaniem będzie rozmowa podczas, której spróbujesz wyjaśnić swój punkt widzenia. Może akurat Tobie też uda się obronić swoje rozwiązanie.

Podsumowanie

Uff, trochę tego było! Powyższa lista to według mnie najczęstsze błędy, które popełnia prawie każdy początkujący programista. Większość z nich dotyczy braku praktyki oraz pracy nad swoimi projektami. Mam nadzieję, że po przeczytaniu tego artykułu zwrócisz większą uwagę na praktyczną część nauki oraz trochę bardziej uwierzysz w swoje umiejętności, w momencie gdy jesteś pewien, że zrobiłeś coś dobrze. Nie bój się proponować zmian w kodzie czy nawet w pracy. Jako lider cenię sobie świeże głowy nowych pracowników i rozważam każdy pojawiający się pomysł.

Jeśli jeszcze nie rozpocząłeś swojej kariery w IT, ale masz taki zamiar to zapraszam Cię do sprawdzenia serii artykułów Zostań kotem IT w ramach, której opisuje tematy przydatne podczas rozpoczynania swojej programistycznej przygody. Mam nadzieję, że powyższa lista pomoże Ci unikać ich w przyszłości oraz zaoszczędzi Ci zbędnych nerwów jak i frustracji.

BIO:

Autor: Maciej Kotlarz. Właściciel bloga: Devkot.pl - zostań kotem IT. Tech Lead w Next Technology at Flexdev. Twórca serii artykułów Zostań kotem IT, przeznaczonych dla osób, które mają dopiero zaczynają swoją przygodę ze światem programowania.