TL; DR Ciężką i systematyczną pracą - nie ma innej drogi.
Dlaczego ciężką pracą? Dlatego, że nie ma możliwości, abyś ucząc się czegokolwiek nowego rozumiał każde zagadnienie po przeczytaniu teorii czy obejrzeniu kursu na dany temat. Dlaczego ma to być praca systematyczna? Dlatego, że ucząc się choćby jednego języka musisz poznać wiele zagadnień. Tego się nie da opanować w miesiąc. Ważne jest, byś był systematyczny. Lepiej uczyć się przez rok, ale po godzinie dziennie niż przez miesiąc po 10 godzin dziennie. To trochę wynika z tego, że mózg sobie musi posklejać wiele zagadnień w całość. Przeładowany nowymi informacjami nie zrobi tego wydajnie.
Co powinno zawierać portfolio programisty?
Swoje portfolio rozbudowuję na githubie. Czasem przeglądam inne najpopularniejsze projekty i w ten sposób mogę sobie wyrobić zdanie, na co zwracać uwagę. Przykładowo wiedziałem, że trzeba umieścić plik README. To takie naturalne, że użytkownik chciałby wiedzieć, co dany program robi. W przeszłości jak miałem potrzebę skompilować jakieś programy ze źródeł, to sięgałem do README. Oczywistym było więc dla mnie to, żeby tworzyć je w języku angielskim. Ale uważałem, że to za mało. Najlepsze projekty na githubie miały często do README dołączone grafiki lub nawet gify, które wyjaśniały, jak dany program działa bez potrzeby jego pobierania. Podpatrzyłem tego typu podejście i wdrożyłem je do swoich projektów.
Innym przykładem jest to, że wszystkie popularne projekty posiadały również w swojej strukturze testy. Zacząłem je również umieszczać w swoich projektach. Po czasie zauważyłem, że pod projekty podłączone jest narzędzie Travis-CI, które po wypchaniu commitów automatycznie sprawdza testy. Takie podejście wymaga zdefiniowania pliku w formacie yaml i daje już podstawową wiedzę, czym w ogóle jest continuous integration i po co to jest.
Po dłuższym zastoju powróciłem do jednego z projektów. Okazało się, że po tym czasie zmieniły się wersje oprogramowania, na których Travis-CI uruchamiał testy. Pisałem kod na Linuxie w Pythonie 3.6, ale chciałem, by działa również na wersjach 3.5 i 3.7. W tym przypadku wysyp dotyczył wersji 3.5. Oczywiście mogłem robić tak, by pushować zmiany np. na gałęzi develop i czytać logi z failami z serwisu Travis, aby dojść do tego, co jest źle. Poszedłem jednak w inną stronę i zainstalowałem Dockera. Dzięki temu wygenerowałem sobie 3 obrazy Ubuntu i na każdym z nich skompilowałem ze źródeł inną wersję Pythona. To pozwoliło mi lokalnie poprawiać kod, by nie zaśmiecać repozytorium zbędnymi commitami. Ponieważ wiedziałem, że nie będę pamiętał tych wszystkich komend Dockera, wrzuciłem sobie na repozytorium plik Dockerfile.
Kolejnym przykładem jest umieszczenie pliku CHANGELOG do śledzenia zmian pomiędzy wersjami. Jak taki plik powinien wyglądać i dlaczego on jest ważny opisano tutaj. Te wszystkie powyższe drobiazgi sprawiają, że techniczny rekturer od razu wyłapie, iż projekt jest dojrzały, jest przyjazny dla użytkowników i deweloperów. To na pewno nie pozostawi go obojętnym.
Jakie projekty wykonać do portfolio?
Aby przyciągnąć uwagę użytkowników lub rekruterów masz do wyboru dwie opcje:
- oryginalne
- takie, których brakuje
Pod pojęciem oryginalne mam na myśli takie, które się wyróżniają lub są dedykowane wąskiemu gronu, bo są wyspecjalizowane i wymagają wiedzy domenowej. Przy czym w obu przypadkach powinieneś je opisać w README tak, by większość osób zaglądających na github była w stanie zrozumieć, po co dany projekt jest i jaką niesie wartość. Czyli tradycyjnie robienie kolejnej listy TODO może nie być najlepszym pomysłem. Ale już na przykład jakiś framework do tworzenia prostych blogów z możliwością manualnej zmiany layoutu, czcionki, czy wgraniem grafiki na tło będzie czymś, co może wykorzystać osoba, która nie umie programować. Innym przykładem jest np. interfejs w języku wysokiego poziomu nałożony na systemy wbudowane np. by można było sobie wyświetlić GUI do mikrokontrolera.
W przypadku drugim najprościej jest samemu używać różnych programów, aby przy okazji wyłapać, jakie mają ograniczenia, czego w nich brakuje, czy co można ulepszyć. Ja tak raz miałem, że programowi typu OSS brakowało jednego feature. Sprawdziłem issue na githubie i okazało się, że nie tylko ja chciałem, aby było to poprawione. Ludzie podawali różne obejścia tego problemu, ale nadal to nie było to, czego oczekiwałem. Przygotowałem swój podprogram, który robił, to co sobie założyłem. Wydałem go na wolnej licencji i poinformowałem użytkowników, żeby z niego korzystali.
Chyba w oparciu o takie zasady najlepiej budować portfolio:
- rób to, co przynosi wartość innym
- rób to, co chcesz, a nie to co musisz
- utrzymuj projekt poprzez choćby aktualizację najnowszych wersji zależności (swoją drogą, to też się da zautomatyzować)
- poprawiaj, refaktoryzuj, projekt nigdy nie będzie skończony od A do Z, im będzie lepszy, tym więcej będziesz chciał w nim zrobić
- opisz dobrze projekt, by był zrozumiały dla jego użytkowników/odbiorców (nie deweloperów)
