Tracisz czas na portfolio

Tracisz czas na portfolio? – vlog19

Czy warto poświęcać czas na tworzenie portfolio? Jak zrobić dobre portfolio? Co powinno zawierać dobre portfolio programisty? Na te i inne pytania odpowiadam w kolejnym vlogu. Opowiadam także o tym, jakie projekty wybrać do portfolio i jakich błędów unikać przy tworzeniu portfolio programisty.

Poniżej znajdziesz link do playlisty z vlogiem:

Mateusz Dąbrowski vlog

 

Zapraszam także do moich warsztatów o architekturze warstwowej i architekturze heksagonalnej

I do kursu Hibernate i JPA

 

Vlog w wersji Audio:

Inne platformy podcastowe:

https://open.spotify.com/show/5HQFAJg0N4o9mDEze8WVvi?si=cc72277bbd834760

https://podcasts.apple.com/us/podcast/vlog-programistyczny/id1606703834

https://podcastsmanager.google.com/show?hl=pl&show=show:f0FRKrpSJZuEP1UQgm73vw

https://castbox.fm/channel/Vlog-Programistyczny-id4743197?country=us

https://podcastaddict.com/podcast/3783474

 

Transkrypcja

Dzisiaj będzie o tym czy warto robić portfolio projektowe? Albo mówiąc inaczej, jak robić portfolio, żeby miało to sens.
Bo jeśli robisz portfolio projektowe bez zastanowienia się nad tym co dzięki temu chcesz osiągnąć, to takie portfolio będzie tylko stratą czasu.

Cześć witam Cię w kolejnym vlogu na moim kanale. Ja nazywam się Mateusz Dąbrowski, a dzisiaj zajmiemy się tematem portfolio projektowego.

Jeśli dopiero zaczynasz naukę, czy jesteś już juniorem, czy też midem to podobno warto takie portfolio mieć, warto takie portfolio zrobić. Mówię ”podobno” warto mieć, bo dla mnie wcale to nie jest takie oczywiste i nawet powiedziałbym, że portfolio nie jest konieczne, jeśli chodzi o zdobycie nowej pracy.

Pierwsza rzecz jak przychodzi mi zawsze do głowy jeśli ktoś pyta “co powinien mieć w portfolio projektowym”, to pytane, po co ci to portfolio jest potrzebne. I jeśli pada odpowiedź, szukam pracy, szukam pierwszej pracy, to od razu pojawia się kolejne skojarzenie, przecież większość rekruterów nie ma czasu oglądać twojego portfolio i potwierdzają to osoby, które do mnie piszą, osoby, które już zdobyły swoja pierwszą pracę, miały portfolio i rzeczywiście, nikt nie chciał tego portfolio oglądać. Nie chciał albo nie miał czasu oglądać.

Trzeba pamiętać, że rekruterzy, to programiści, którzy na co dzień przede wszystkim programują, a dodatkowo prowadzą rekrutację. Często dostają czyjeś CV do ręki, mają 5 minut na zapoznanie się z nim i idą na rozmowę, gdzie mają przygotowany jakiś zestaw standardowych pytań i po prostu przepytują kogoś. I u mnie tak to mniej więcej wyglądało, chociaż ja zwykle nie zajmowałem się rekrutacjami, to kilka razy zdarzyło się, że prowadziłem rekrutację i niestety nie miałem za wiele czasu, żeby nawet zapoznać się z czyimś CV.

Więc skoro rekruterzy nie mają czasu, na przeglądanie projektów, to czy warto poświęcać w ogóle czas na portfolio?
Oczywiście warto.

Ale celem nie powinno być tutaj pokazanie swojego kodu komuś, a raczej nauczenie się pewnych rzeczy i przy okazji, być może ktoś będzie kiedyś chciał obejrzeć twoje portfolio.

Później jeszcze powiem o pewnym sposobie, dzięki, któremu będziesz mógł w pewnym sensie wymusić na rekruterze, żeby jednak twoje portfolio obejrzał, ale to za chwilę…

Więc pierwszym powodem, dlaczego robisz portfolio, powinna być nauka. Nauka nowych rzeczy, obycie z kodem i tworzeniem nowych funkcjonalności.

Teraz jaki projekt wybrać do portfolio?
Projekt nie projekty. To, że będziesz mieć 3, 5, czy 10 projektów w portfolio to nie ma znaczenia, jeśli te projekty będą bardzo mało.

Przejrzałem bardzo dużo projektów na Githubie, takich projektów właśnie z portfolio i większość projektów jest bardzo podobna do siebie. I większość to bardzo małe projekt. 10-20 klas, to nie jest duży projekt, mimo że tobie może wydawać się, że to jest dużo, to tak nie jest. Duży projekt to setki tysięcy linii kodu i setki albo tysiące klas. I do portfolio takich projektów się nie robić.

I większość projektów, które przejrzałem, nie pokazuje umiejętności, nie pokazuje wiedzy autora tego kodu. Pokazuje, że ktoś potrafi przepisać jakiś tutaorial lub tutoriale. I rekruterzy nie chcą tracić czasu na oglądanie przepisanych tutoriali, tak to niestety wygląda.

Wiec warto wybrać jakiś temat np. zrobienie prostego CRM Customer Relationship Management, czyli aplikacji do zarządzania relacjami z klientem. I w takiej aplikacji znajdziesz naprawdę wiele zagadnień, które nauczą Cię pisania prawdziwych aplikacji, Bo będziesz musiał stworzyć obsługę klientów, wystawianie im faktur, raportowanie sprzedaży, wykresy dla tej sprzedaży, jest naprawdę bardzo wiele ciekawych funkcjonalności, które można stworzyć w takiej aplikacji.

Kolejny pomysł na aplikację to np. prosty sklep internetowy, w takiej aplikacji jest tak samo dużo elementów, które mogą Cię nauczyć bardzo wiele nowych ciekawy rzeczy.

W takiej aplikacji będziesz mieć i proste funkcjonalności CRUD, np, zarządzanie produktami, ale także proces sprzedażowy, składanie zamówień i ich obsługa w panelu administracyjnym

Kolejny typ projektu to, np. CMS, czyli Content Managment System, czyli system do zarządzania treściami na stronie. I tutaj będziesz mieć podobnie jak w aplikacji sklepu, część widoczną dla klientów i cześć administracyjną, gdzie można tymi treściami zarządzać.

Więc jeśli chcesz robić portfolio, to warto wybrać aplikację, która da Ci szanse nauczyć się jak najwięcej i być może, będziesz mieć problemy z realizacją takie aplikacji, ale w nauce programowania w dużej mierze chodzi o to, żeby rozwiązywać problemy, które pojawiają się w projekcie. I im wcześniejsze zaczniesz się uczyć, rozwiązywać te problemy, tym łatwiej będzie Ci później w pracy,

Jak już wybrałeś projekt, jak zacząłeś go już realizować to, nie kończ swojego projektu!

Nie powinieneś myśleć o projektach w twoim portfolio, że są skończone. Wiele projetów w IT nie ma końca, a rozwój większości projektów, trwa min. 2 lat, intensywnego developmentu, zwykle prowadzonego przez kilku osobowy zespół. I im dłużej będziesz rozwijać swój projekt tym, bardziej skomplikowane problemy, będziesz napotykać, a rozwiązywanie tych problemów, będziesz sprawiać, że będziesz się rozwijać. Więc nie kończ swoich projektów, bo one wcale nie muszą być skończone. I wcale nie musisz zaczynać kolejnych, projektów. Bo jeśli będziesz mieć 5 projektów i wszystkie one będą rozwinięte na tym samym początkowym poziomie, to nie wiele się z nauczyć w ten sposób.

[Readme – jak opisać projekt?]
Kolejna rzecz to jeśli trzymasz swój projekt na GitHubei, a zakładam, że tak jest, bo gdzieś ten projekt trzeba trzymać. I większość trzyma projekty na Githumie. To warto do projektu zrobić plik README, który będzie zawierał jak najwięcej informacji o projekcie.

Plik readme to pierwsza rzecz, którą widzi osoba, która wchodzi na Githuba twojego projektu. Co powinien zawierać taki plik readme. Powinien zawierać takie informacje jak:
– Jaka jest motywacja do powstania tego projektu
– Jaki problem rozwiązuje dany projekt, jeśli jakiś rozwiązuje?
– Jakie technologie zostały użyte do realizacji tego projektu i dlaczego? Jeśli używasz jakichś technologi tylko dlatego, bo chcesz się ich nauczyć, to też warto to podkreślić, że używacie ich z powodów edukacyjnych. Dla kogoś, kto ogląda twój projekt, może być niezrozumiałe, dlaczego używasz takich, a nie innych technologii i warto napisać, że używasz np Kafki tylko dlatego, bo chcesz się jej nauczyć.
– Kolejny punkt to: Jak uruchomić projekt, jeśli używasz Spring Boot to tutaj wystarczy jedna komenda. Jeśli projekt uruchamia się w specyficzny sposób, to trzeba to opisać.
– Warto umieścić także projekt na jakimś darmowych hostingu aplikacji np. Heroku, tak żeby można było jednym kliknięciem odpalić ten projekt. I uwaga projekt powinien przede wszystkim działać. I kolejna sprawa w miarę dobrze wyglądać.
– Warto też gdzieś na końcu tego readme umieści changelog, czyli opis zmian, które wprowadziłeś w czasie tworzenia projektu, nie musi być to jakiś super dokładny opis, ale warto, żeby jednak jakich log zmian był zawarty w tym readme, dzięki temu będzie to wyglądało bardziej profesjonalnie.
– Kolejna rzecz, to jeśli twoja aplikacja ma jakiś frontend to warto zamieścić screeny, z tego jak ona wygląda, a nawet można pokusić się o nagranie krótkiego filmu, prezentacji aplikacji. Bo w takim filmie możesz pokazać, jak ta aplikacja faktycznie działa i możesz pokazać to co chcesz pokazać w tej aplikacji. Jak już ktoś zajrzy do twojego projektu, to warto, zaprezentować ten projekt jak najlepiej, bo jednak w ten sposób najłatwiej zachęcić kogoś do przejrzenia projektu. Jeśli nie masz w aplikacji frontendu, a jest to aplikacja api to warto dodać swaggera tak, żeby łatwo można było przeglądać usługi.

[Kod]
Jak już mamy zrobione readme to warto, też podczas tworzenia projektu zadbać o jakość kodu.

Dzisiaj w każdym projekcie już standardem są testy jednostkowe, wiec warto takie testy mieć, warto je pisać, warto dbać o to, żeby kod w takim projekcie nie tylko był rozbudowany, ale także, żeby był dobrze, schludnie napisany. I żeby sobie trochę z tym pomóc to warto poprosić np. na grupach o Review takiego kodu.

[Review]
I prosząc o review warto napisać, co projekt zawiera, co robi, dlaczego tak jest zrobiony itd.

Bardzo istotna rzecz jeśli chodzi o code review, to żeby review miało sens, to warto je robić co jakiś czas, jak dodasz nowe funkcjonalności. I oczywiście jak prosisz kolejny raz o review to koniecznie napisz co zmieniłeś, co zostało dodane do projektu, tak żeby inni łatwo mogli się zorientować, co zostało zmienione. Ewentualnie możesz też podesłać link do konkretnego commita, w którym zostały zawarte zmiany. To bardzo pomaga w robieniu review i dzięki temu dostaniesz po prostu lepszy feedback. A o to w tym właśnie chodzi.

Jakich błędów unika przy tworzeniu portfolio?
Myślę, że w portfolio nie warto umieszczać projektów z kursów darmowych i też płatnych. Bo daje to taki efekt, że wiele osób ma te same, tak samo wyglądające projekty w portfolio. To dodatkowo sprawia, że rekruterzy są jeszcze bardziej zniechęceni do przeglądania takich portfolio. Nikt nie chce przeglądać projektów, które są przepisane z kursów. Zwłaszcza jeśli widzi je kolejny raz.

Możesz na podstawie projektu z kursu i zdobytej wiedzy stworzyć coś własnego coś oryginalnego coś, co Cię wyróżni na tle innych. I wtedy to ma jakiś sens.

Kolejny bardzo częsty błąd to za dużo projektów. Czasem wystarczy jeden, albo dwa projekty w portfolio, jeśli macie co pokazać w sensie objętości kodu, to ten kod może być zawarty w jednym projekcie. Jeśli chcecie stworzyć więcej projektów, to warto robić zupełnie różne projekty, tak, żeby, np. nie robić CRMa i CMSa, bo będą to tak naprawdę dosyć podobne projekty.

Kolejny błąd to zbyt małe projekty. Z tym błędem spotykam się najczęściej. Bardzo małe, bardzo standardowe projekty CRUD. Gdzie właściwie ciężko powiedzieć cokolwiek o takim projekcie, poza tym, że jest mały. Jeśli masz 5 kontrolerów, 5 serwisów i 5 repozytoriów, i we wszystkich tych klasach kod wygląda bardzo podobnie, to trudno nawet zrobić review dla takiego kodu, bo niewiele się tam dzieje. I jak ktoś wchodzi na taki projekt, to po chwili zaraz go opuszcza, bo od razu widać, że niewiele się tu dzieje.

Kolejny problem, to używanie narzędzie, technologi, których nie rozumiesz, albo używanie ich do celów, dla których nie zostały przeznaczone. Dzisiaj przyjęło się, że próg wejścia na juniora jest bardzo wysoki, więc wiele osób, stosuje wielu różnych skomplikowanych, technologii, nie rozumiejąc ich i nie rozumiejąc, po co te technologie są.

Wiec lepiej ich nie stosować jeśli ich nie rozumiesz, bo może to prowadzić do sytuacji, w której ktoś zapyta Cię, dlaczego i po co to tutaj jest. Takie rzeczy działają na rekruterów trochę tak jak płachta na byka, więc warto nie prowokować takich sytuacji, bo być może będzie Ci ciężko później z takiej sytuacji wybrnąć.

I na koniec jak sprawić, żeby rekruterzy zajrzeli do twojego portfolio?
Oczywiście jak ktoś nie ma czasu, to nie da się go zmusić do zrobienia tego, ale jak już udało Ci się dostać na jakąś rozmowę kwalifikacyjną, to rekruter ma zarezerwowany czas tylko dla Ciebie i na takiej rozmowie zwykle ktoś prosi Cię, żebyś opowiedział coś o sobie. I to jest czas, gdzie możesz zaprezentować siebie i swoją wiedzę.

I na taką rozmowę możesz zabrać laptop i po prostu powiedzieć, że chciałbyś pokazać swój projekt i opowiedzieć o nim. I myślę, że większość będzie chciała zerknąć i posłuchać jak opowiadasz o tym projekcie, bo rekruterzy to przede wszystkim programiści i trzeba z nimi rozmawiać jak z programistami. Ale przede wszystkim musisz mieć co pokazać i przygotować się do takiej prezentacji, ale myślę, że jeśli lubisz programowanie, to na pewnie nie będzie z tym problemu.

I to już wszytko w tym odcinku jeśli jeszcze nie subskrybujesz mojego kanału, to zachęcam do subskrypcji, zostawienia łapki w górę i podzielenia się swoją opinią w komentarzach. Dzięki i do zobaczenia w następnym materiale.

Mateusz Dąbrowski

Cześć jestem Mateusz, zajmuję się programowaniem już ponad 12 lat z czego ponad 8 programuję w Javie. Zapraszam Cię do lektury mojego bloga. Możesz przeczytać więcej o mnie >>TUTAJ<<