Branża frontendowa jest bardzo wymagająca, a obranie dobrej ścieżki może być trudne dla początkujących programistów. Dlatego zapytałem 8 doświadczonych ekspertów: “Jakiej rady udzieliłbyś samemu sobie z przeszłości, by szybciej wejść na poziom eksperta na froncie?”. W tym artykule znajdziesz cenne wskazówki i porady od ludzi, którzy przeszli przez proces nauki i osiągnięcia poziomu eksperta w tworzeniu frontu. To idealny artykuł dla tych, którzy chcą rozwijać swoje umiejętności i karierę w branży frontendowej.
Tomasz Ducin, Ducin.dev i Architektura Na Froncie
Myślę, że nawiązywanie tu do konkretnych technologii jest bez sensu, bo (a) nie ma jednej ścieżki, (b) nie można być expertem w X jednocześnie nie mając naprawdę głębokiego rozumienia wszelkich tematów pokrewnych do X i zahaczających o X.
“sobie z przeszłości”? Zależy na którym etapie się jest, Rada seniorska może być dla juniora bezużyteczna. Jaka jest świadomość, i co kogoś ogranicza, w danym momencie. Czyli nie tylko “gdzie jestem” oraz “gdzie chcę być”, ale także jak się będę poruszał, w jakim kierunku. I regularne weryfikowanie czy ma sens to, co robię, czy aby nie marnuję czasu (technologii zawsze będzie więcej niż da się ogarnąć). No i w tym kontekście zrozumienie własnych ograniczeń: zarówno obecnych (które możemy zmienić) i trwałych (których zmienić się nie da) jest kluczowe, żeby osiągać cele. Jeśli komuś brakuje biegłości w kodzie -> to dużo kodować a także dużo czytać kod źródłowy np. bibliotek. Nie rozumiesz, po co coś jest – drąż, aż się dowiesz/zrozumiesz. Poruszaj się na wielu poziomach. Jeśli słuchasz prezentacji / czytasz książkę o architekturze i nie rozumiesz wielu pojęć – uzupełniaj braki. Z początku to ogromna inwestycja, ale warto. Ekspertyza to milion małych cegiełek, z których wiele może się przydać np. tylko raz 🙂 Idąc dalej, jeśli nikt cię nie zna – to pokaż się, stań się rozpoznawalny. Itp. Ja tak właśnie robiłem 😉 tzn. świadomie zajmowałem się obszarem jedno po drugim.
Zależy, co kto chce osiągnąć… ogólnie, nawet jeśli ktoś się wy-expi w kilku technologiach, ale nie potrafi tego wykorzystać, choć chciał(a)by – to co z tego? Żeby osiągać cele, trzeba podchodzić do nich całościowo, holistycznie (np. kod może być zajebisty ale co z tego, jak jest nikomu niepotrzebny; slajdy mogą być piękne ale delivery położone itp… startup świetny, tylko nikogo on nie interesuje 😉 ). Pytanie: po co chcesz być ekspertem? Dla własnej satysfakcji? Czy żeby zarobić dużo hajsu? Czy żeby ratować z opresji ludzi i projekty? Czy żeby być docenionym? Albo sławnym/rozpoznawalnym? A może wnieść wartość, której póki co nikt inny nie wnosi?… Inne drogi będą prowadziły do tych celów, nie ma jednej odpowiedzi. Parafrazując klasyka, jeśli nie wiesz dokąd zmierzasz (donikąd?) każda droga cię tam zaprowadzi.
Dodatkowo – szukaj konfrontacji idei/pomysłów/rozwiązań. Nie udowadniaj z góry założonych tez, wręcz odwrotnie – szukaj, jak można dobry pomysł zbombardować. Niuansuj. Projekty są osadzone w jakimś kontekście, ten kontekst zmienia dużo. Wszystko :). Najwięcej uczysz się, i najlepiej to potem pamiętasz (z uwagi na towarzyszące emocje), kiedy dopuszczasz myśl, że jednak nie masz racji. Wątp. Poszukuj. Inny klasyk – “I would rather have questions that can’t be answered than answers that can’t be questioned”.
Last but not least, be kind 😉
Tomasz Jakut, Comandeer i WebKrytyk
Zapewne pierwszą rzeczą, którą usłyszałbym ja z przeszłości, byłoby “Przestań być takim perfekcjonistą!”. Nie ma nic złego w próbie napisania idealnego kodu, ale dla kogoś, kto jest dopiero na początku ścieżki, może to być mocno czasochłonne zajęcie – na tyle, że można się zaciąć na jednej rzeczy, spowalniając proces nauki kolejnych. O wiele lepiej pracować w czymś, co nazywam “podejściem eksperymentalnym”: poznaje się nową rzecz → siada się do edytora kodu i próbuje ją wykorzystać w praktyce. Za sukces należy tutaj uznać po prostu fakt, że dane rozwiązanie będzie działać, na jego polerowanie przyjdzie czas. Zwłaszcza, że serwisy pokroju GitHuba pozwalają nam przechowywać całe historie wszystkich projektów i wracać do nich w wolnej, odpowiedniej dla nas chwili. Nic nie stoi na przeszkodzie, by wrócić do jakiegoś projektu nawet po pół roku, gdy będziemy mieli już więcej umiejętności i doświadczenia, i wtedy poprawić kod według naszej obecnej wiedzy. Takie długo rozwijane projekty mogą być fajną historią naszej nauki – od koślawego, ledwo działającego kodu do pełnoprawnej apki z dobrze napisanymi testami, która sama się deployuje do chmury przy każdym commicie do głównego brancha.
Sekret polega na tym, że nauka jest iteracyjna. W danym momencie nie da się przeskoczyć ograniczeń związanych z własną wiedzą i doświadczeniem. A próba zrobienia tego najprawdopodobniej skończy się po prostu frustracją. Dlatego lepiej sobie to rozłożyć na serię mniejszych kroków. Bardzo szybko można spróbować też wejść do społeczności – udzielać się na grupach, discordach, pisać bloga, dawać swój kod do code review, ale też i samemu próbować reviewować kod innych. Dzięki temu zetkniemy się z tym, jak do danych rzeczy podchodzą inni – mogą nam podsunąć nowe pomysły, jakieś tricki z własnego doświadczenia z danym problemem czy wskazać dobre praktyki, które istnieją na dany temat. Owszem, da się tego nauczyć samemu, czytając różne artykuły czy oglądając kursy, ale często zabierze to zdecydowanie więcej czasu.
Społeczność ma jeszcze jedną zaletę: może podpowiedzieć, które materiały do nauki są warte naszego czasu, a które nie. Nie ma sensu tracić czasu na materiały kiepskiej jakości, gdy obok istnieją inne – bardzo dobre i często darmowe. No i warto też nie zamykać się na jedne źródło wiedzy – bo żadne nie jest nieomylne i żadne nie zawiera wszystkiego (nawet MDN!). Warto weryfikować wiedzę, którą zdobywamy (zarówno w innych źródłach, jak i “empirycznie”, po prostu sprawdzając, co faktycznie robi dane API czy kod), a równocześnie grzebać głębiej, żeby a nuż wykopać coś ciekawego.
Podsumowując:
* nauka to proces – nie próbuj od razu pisać perfekcyjnego kodu, poprawiaj go wraz z własnym rozwojem;
* eksperymentuj – poznane nowości próbuj wykorzystać w praktyce;
* korzystaj z istnienia społeczności, bo jest w stanie przyśpieszyć naukę;
* korzystaj z dobrych źródeł wiedzy, ale nawet wówczas – weryfikuj w innych źródłach oraz organoleptycznie.
Tyle ode mnie 🙂 Mam nadzieję, że się komuś przyda.
Maciej Korsan, WTF: Co Ten Frontend i @maciejkorsan
Myślę, że byłyby to dwie rzeczy:
– szybciej zdecydowałbym się na trochę bardziej wąskotorowe patrzenie i nieskakanie po wszystkich nowinkach jak tylko wychodziły
– mocniejsze skupienie się na komunikacji z ludźmi i więcej odwagi w przedstawianiu własnego zdania – wiele razy miałem sytuacje, w których 5 min rozmowy z klientem oszczędzało 2 tygodnie developmentu zbędnych rzeczy
Michał Kuchno, Dry Code
Hmm, bardzo ciekawe pytanie. Gdybym miał sobie coś doradzić to na pewno powiedziałbym, żeby zbytnio nie skupiać się na bibliotekach i frameworkach. Uważam tak, ponieważ nowe biblioteki przychodzą i odchodzą bardzo szybko. Szczególnie na początku nie sposób za nimi nadążyć. Wydaje nam się, że każda biblioteka jest super rewolucyjna i wnosi coś nowego bez czego na pewno się nie obejdziemy, jednak jest to tylko złudzenie. Prawda jest taka, że większość bibliotek działa bardzo podobnie i każda ma swoje zalety, ale również WADY. Zamiast tego radziłbym skupić się na agnostycznych rzeczach takich jak zasady dobrego programowania, wzorce oraz język. Jeśli je dobrze poznamy to bardzo szybko będziemy w stanie nauczyć się nowej biblioteki czy frameworka jeśli zajdzie taka potrzeba. Co więcej, w razie potrzeby o wiele łatwiej będzie nam się nauczyć na przykład backendu lub nawet innych języków.
Drugą radą jakiej bym sobie udzielił jest na pewno to aby uczyć się języka angielskiego. Brzmi to banalnie, ale w dzisiejszych czasach jest to podstawa podstaw. Jeśli chcemy dojść wysoko, pracować z najlepszymi i zarabiać duże pieniądze to naprawdę bez tego się nie obejdzie. Język angielski pomaga nam nie tylko w komunikacji, ale również w rozwoju. Większość dobrych źródeł z których możemy się uczyć jest w języku angielskim, szczególnie tych bardziej zaawansowanych. Kod również piszemy po angielsku. Naukę najlepiej zacząć jak najwcześniej.
Kolejną przydatną rzeczą są na pewno umiejętności miękkie. Bardzo wielu programistą brakuje tych jakże kluczowych kompetencji. Część uważa, że “nie po to studiowałem informatykę, żeby rozmawiać z ludźmi” jednak jest to bardzo błędne myślenie. Po pierwsze umiejętności miękkie pomagają nam komunikować się nie tylko z osobami technicznymi, ale również ludźmi biznesu. Jest to o tyle ważne, że bez nich nie jesteśmy wstanie stworzyć dobrej aplikacji. To od nich wychodzą wymagania, to od nich zależy jak będzie wyglądała architektura naszej aplikacji. Programiści często się na nich denerwują twierdząc, że “klient nie wie czego chce”. Prawda jest taka, że klient wie czego chce, ale to my nie umiemy pozyskać od niego potrzebnych rzeczy, ponieważ nie umiemy się z nimi porozumieć. Biznes o wiele bardziej ceni programistów, którzy umieją się z nimi dogadać, ale są troszke słabsi technicznie, niż programistów którzy są mega mocni ale totalnie nie posiadają umiejętności komunikacyjnych. Z własnego doświadczenia wiem, że rozwój umiejętności miękkich bardzo pomaga w znalezieniu wymażonej pracy lub klienta, wynegocjowaniu lepszych stawek oraz stworzeniu dobrej aplikacji. W rozwijaniu umiejętności miękkich na pewno pomaga prowadzenie kanału na youtube lub pisanie bloga.
Ostatnią radą jest to aby się nie bać 🙂 Każdy z nas kiedyś zaczynał i każdy popełniał błędy. Grunt to nigdy się nie poddawać i z każdej porażki wyciągać lekcje. Jeśli coś nam nie wyjdzie to nie powód do tego, żeby się załamać. Zamiast tego przeanalizujmy dlaczego coś się nie udało, co mogliśmy zrobić lepiej lub czego powinniśmy unikać. Z biegiem czasu każda porażka wyjdzie nam na dobre 🙂
Filip Mamcarczyk, Jak Zacząć Programować
Nie próbuj zrozumieć wszystkiego na raz – przyswajaj wiedzę rzetelnie, krok po kroku.
Olaf Sulich, Frontlive
Jakiej rady bym sobie udzielił? Byłoby ich na pewno mnóstwo… To co bym polecał, to pamiętać o tym, że frontend to z jednej strony twarda logika, a z drugiej tworzenie UI. Podczas nauki frontendu, zapominamy często o jednej z odnóg. Wymasterowanie semantycznego html, dostępności, optymalizacji, pisania “czystego” css, jest tak samo ważne jak zagłębianie się w techniczne zagadnienia JS/TS, frameworków i narzędzi 🙂
Dominik Szczepaniak, Devszczepaniak.pl
Udzieliłbym rady, aby nie popaść w pułapkę oglądania tony kursów, czytania tutoriali i chęci poznania miliona technologii. Zdecydowanie lepiej jest realizować praktyczne projekty i w razie potrzeby wyszukiwać potrzebne rozwiązania (technologie, metody, wzorce itp.). Jeden projekt nauczy Cię prawdopodobnie więcej niż kilka/kilkanaście kursów. Kiedyś przeczytałem, że oglądanie kursów i kucie teorii to nowa prokrastynacja i całkowicie się pod tym podpisuję 🙂
Tomasz Świstak, Świstak.codes
Jakiej rady udzieliłbyś samemu sobie z przeszłości, by szybciej wejść na poziom eksperta na froncie?
Powiedziałbym sobie, żeby nie traktować front-endu po macoszemu, jako coś prostego czy mało ambitnego.
We front-end wchodziłem z potrzeby w firmie, pracując do tej pory jako junior .NET developer, do tego świeżo po studiach, gdzie zaś dużo robiłem w machine learningu. Front-end wydawał się czymś gorszym i tym samym nieco hamowało mnie to w rozwoju na samym początku, bo szukałem ciągle okazji na powrót do back-endu, czy przeskoczenie do ML. Na szczęście z czasem odkryłem, że front-end to nie tylko klepanie HTML-i, CSS-ów i oskryptowanie jakiś powtarzalnych formularzy, ale też potrafią być tu ciekawe zagadnienia. Architektura front-endu jest wcale nie nudniejsza od architektury back-endu. Do tego, front-end może nie słynie z algorytmiki, ale np. ta przy wizualizacji danych jest bardzo ciekawa. A, że w mojej obecnej firmie, z którą jestem związany od dłuższego czasu, czyli Synergy Codes głównie zajmujemy się tym tematem, to nie mogę narzekać na nudę.
Podsumowując, gdybym wcześniej wiedział, że front-end wbrew temu, jak się go przedstawia, wcale nie jest tak prosty i są tu obszary, gdzie osoby lubiące typowe grzebanie w kodzie, też mogą się odnaleźć, pewnie miałbym mniejsze opory przed nauką. W tym tych rzeczy, które mnie odpychały na samym początku, jak chociażby stylowanie.
Podsumowanie
W artykule przedstawiono cenne wskazówki dla początkujących programistów, którzy chcą stać się profesjonalistami w dziedzinie front-endu. Dziękuję każdemu z ekspertów za podzielenie się radą i mam nadzieję, że przydadzą się czytelnikom.
