Własna aplikacja w portfolio juniora – czy to ma sens? Starasz się o pierwszą pracę albo masz zamiar zacząć poszukiwania? Mam dla Ciebie kilka wskazówek, jak napisać swoją pierwszą aplikację, aby stała się Twoją wizytówką i przepustką w procesach rekrutacyjnych.
Artykuł powstał na podstawie mojej prezentacji, z którą wystąpiłam na meet-upach “Programuj, dziewczyno!” i “Hello Roman & Friends” w listopadzie i grudniu 2019. Początkowo chciałam wrzucić treść prelekcji w formie Stories na Instagramie, ale uznałam, że łatwiej będzie się czytało (i pisało) artykuł. Miłej lektury!
Pokaż swój kod
Branża IT zmienia się nieprzerwanie. Rynek junior developerów również. Kilka lat temu (podobno) można było zostać junior front-end developerem jedynie ze znajomością podstaw HTML i CSS. Dzisiaj już trzeba pochwalić się dobrą znajomością JavaScriptu podczas procesu rekrutacyjnego. A nic tak nie pokazuje umiejętności pisania kodu, jak… kod!
Świetnym sposobem na zwrócenie uwagi rekrutera na naszą kandydaturę jest umieszczenie w CV linku do repozytorium np. na GitHubie i opisanie projektu lub projektów, nad którymi pracowaliśmy. To nie muszą być wielkie aplikacje. Nawet mały projekt pokaże, że umiemy zaplanować prace, napisać i sprawdzić kod, a potem coś zaprezentować. Własna aplikacja to także sposób na naukę i utrwalenie nowo zdobytych umiejętności.
Tu odsyłam do całej serii wpisów Własna aplikacja krok po kroku, gdzie możecie prześledzić proces powstawania mojej aplikacji i znaleźć informacje, czego się dzięki temu nauczyłam.
Nie skupiaj się na oryginalnym pomyśle!
Jeśli na hasło “własna aplikacja” zaczęliście gorączkowo zastanawiać się, co takiego oryginalnego można napisać, od razu Was zastopuję. Nie chodzi tutaj zupełnie o oryginalne pomysły, ale o to, by zaprezentować umiejętność pisania kodu i nauczyć się czegoś nowego. Pewnie, dużo fajniej się pisze, gdy “czujemy” pomysł i wierzymy w ideę, która stoi za projektem. Jednak nie zawsze mamy tyle szczęścia, by wpaść na super pomysł na aplikację.
Brak oryginalnego pomysłu nie powinien nas hamować przed pisaniem kodu. Najprostszym sposobem na znalezienie pomysłu na projekt jest wyszukanie go w Google. Istnieje wiele artykułów, w których znajdziemy pomysły na aplikacje w danej technologii. Chociażby w tym wpisie znajdziecie 15 pomysłów na frontednowe aplikacje.
Jaką technologię wybrać?
Przed nami ważna decyzja! Wybranie odpowiedniej technologii może być kolejną pułapką. Łatwo wpaść w godziny analizowania, sprawdzania i czytania, zamiast usiąść do kodu. Ja zachęcam do wykorzystania technologii, którą znacie albo której się uczycie. Czyli zwyczajnie napiszcie aplikację w tym, w czym chcecie być lepsi.
Drugim sposobem na dobór technologii do aplikacji jest sprawdzenie, czego oczekuje firma, do której chcecie aplikować. Jeżeli wiecie mniej więcej, do jakich firm chcecie składać w CV, zobaczcie, jakie technologie znajdują się w ich portfolio. Wiele software house’ów ma takie informacje na swoich stronach internetowych.
Pamiętajcie jednak, że nie chodzi tutaj o to, by pisać tylko w tym, co znamy. Własna aplikacja ma być okazją do nauczenia się nowych rzeczy. Nie bójmy się eksperymentować. Nie musimy poznać technologii w 100%, aby wykorzystać ją w naszym projekcie. Nie bójmy się także o tym informować podczas procesu rekrutacyjnego. O wiele lepiej przyznać, że testowaliśmy dopiero jakąś technologię, niż udawać, że się ją bardzo dobrze zna. To, że wykorzystujemy w projekcie coś nowego pokazuje, że umiemy się uczyć i korzystać z dokumentacji (a to super ważne!).
Stwórz plan (i się go trzymaj)
Praca nad aplikacją, szczególnie w pojedynkę, może być frustrująca. Łatwo się poddać, gdy działamy spontanicznie i bez planu. W takim przypadku pierwszy, trudniejszy błąd może nas zniechęcić do dalszej pracy. Dlatego zachęcam do stworzenia planu działania. U mnie świetnie się sprawdzają różnego typu wyzwania. Aktualnie robię wyzwanie #100DaysofCode, podczas którego koduję codziennie przez sto dni (o moich wrażeniach na półmetku poczytacie w tym wpisie).
U każdego sprawdza się coś innego – może dla Was lepsze będzie np. kodowanie trzy godziny dwa razy w tygodniu. Starajcie się dobrać plan do siebie i do aktualnej sytuacji. Warto także rozpisać, co chcecie mieć w swojej aplikacji. Fajnie tutaj sprawdzi się np. tablica na Trello. Gdy mamy coś spisane, trudniej jest z tego zrezygnować. A wierzcie mi, przy pracy w pojedynkę łatwo się odpuszcza jakieś funkcje aplikacji, gdy musimy się zmierzyć z większymi problemami.
Kilka słów o kontroli wersji
Pisząc własną aplikację warto zadbać o jak największą symulację prawdziwej pracy. A każdy programista pracuje z systemiem kontroli wersji. Niech Git będzie Waszym przyjacielem! Nie wrzucajcie kodu całej aplikacji jednym commitem, zadbajcie też o wiadomości commitów. Dobrze, by coś mówiły nie tylko Wam.
Możecie również napisać kilka testów jednostkowych, aby pokazać, że wiecie na czym polega testowanie. Takie małe rzeczy pokażą, że nie jest Wam obca praca z projektem.
Nie czekaj na ideał!
To normalne, że gdy pracujemy nad własną aplikacją, chcemy, by była jak najlepsza. Niestety, na to potrzeba czasu i często dopieszczamy aplikację bez końca. Tymczasem – ona nigdy nie będzie idealna. Nie warto czekać na moment, aż uznacie, że teraz to już na pewno nic w tej aplikacji nie trzeba zmienić. Spoiler – taki moment pewnie nigdy nie nadejdzie. Aplikacje, z których korzystacie na co dzień także są cały czas zmienianie.
Jeśli spełnicie swoje początkowe założenia – zatrzymajcie się i zacznijcie aplikować o pracę. Już o tym wspominałam w tym artykule – jedynie udział w procesie rekrutacyjnym da Wam informacje, czy jesteście gotowi, aby zacząć pierwszą pracę. Pamiętajcie, że mówimy tutaj o stanowisku juniora, a junior to osoba, która z założenia będzie się uczyć. Nikt nie oczekuje, że Wasza aplikacja będzie skończona i bezbłędna.
To tyle na dziś! Owocnej pracy nad aplikacjami!
Chcesz się ze mną czymś podzielić? Napisz komentarz pod postem albo maila na joanna@wakeupandcode.pl. Zajrzyj też na moje konto na IG.
Dobre podsumowanie – “Nie czekaj na ideał!” Ja osobiście własnie zawsze czekałem aż wszytko będzie dopięte na ostatni guzik… ale wtedy czas ucieka strasznie. Wiele osób tak polecało nie robić 10x projektów tylko jeden ale dobry. Wiec wydaje mi się że fajnie mieć kilka projektów nawet tych pierwszych słabych bo pokażą ze uczyliśmy się sukcesywnie z każdym nowym projektem.
Zgadzam się z tym, że lepiej mieć kilka projektów, niż jeden super idealny. Więcej się nauczymy podczas robienia kilku rzeczy, a właśnie pracując nad jednym projektem łatwo wpaść w dopracowywanie szczegółów bez końca.
Szkoda, że nie trafiłem na taki artykuł 10 lat temu kiedy zaczynałem swoją przygodę z szeroko pojętym IT… oj przydałoby się 🙂 Podstawowy błąd jaki popełniłem to 1 max 2 projekty super dobre zamiast kilku różnych, może trochę słabszych ale za to bardziej zróżnicowanych.
Cześć!
Widzę, że to nie tylko jeden przypadek ale cała plaga programistów perfekcjonistów 🙂 Mam podobne doświadczenia, gdy na 1 roku studiów spędzało się masę czasu na tym, by program, który oddajesz na zaliczenie, był produktem “gotowym na produkcję” 😀
Odnośnie GIT’a – czym szybciej tym lepiej. Polecam nawet samemu pobawić się w sytuację typu: mamy master’a -> zrobię jakąś gałąź (nie zamykamy jej), otwieramy inną, pracujemy nad innym fragmentem, dokańczamy obie i merg’ujemy. A jeszcze zabawniej będzie, gdy pojawi się konflikt 😉