• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

Frontend - nadrobienie zaległości i przejście z Juniora na Professionala/Regulara

VPS Starter Arubacloud
+4 głosów
742 wizyt
pytanie zadane 17 grudnia 2018 w Rozwój zawodowy, nauka, praca przez ScriptyChris Mędrzec (190,190 p.)

Cześć. Na wstępie zaznaczę, że choć moje pytanie wydaje się podobne do innych typu „co dalej?”, „jak zacząć?”, to myślę, że moja sytuacja jest nieco inna i nie jestem pewien jak skutecznie z niej wyjść.

 

Od 2.5 roku pracuję jako Junior Frontend Developer. Mam jednocześnie to szczęście (tak myślałem na krótką metę) i tego pecha (to dostrzegłem po przewinięciu się przez kilka projektów), że w projektach nie miałem okazji uczestniczyć w fazach dobierania technologii, konfiguracji projektu ani budowania aplikacji od zera. Za każdym razem dołączałem do zespołu, gdy projekt miał już tą początkową fazę za sobą, albo ktoś bardziej doświadczony zajmował się konfiguracją, a ja po prostu zaczynałem kodzić jakieś funkcjonalności. Z tego powodu nie mam doświadczenia w posługiwaniu się, obecnie praktycznie nieodzownymi, narzędziami typu: module bundlery, task runnery, package managery. To zawsze w projektach było już zrobione - ja tylko „uruchamiałem gotowca” – i, jako początkujący, jakoś bałem się w tym grzebać. Wolałem skupić się na szlifowaniu czystego JavaScriptu i nauce Angulara (zatrzymałem się na wersji 4).

 

W aktualnym projekcie tkwię od roku. Delikatnie mówiąc - nie należy do wymarzonych. Chcę go zmienić. Przy okazji zamierzam też przejść z Juniora na Professionala/Regulara, lecz obawiam się, że przez tą (myślę, że dość znaczącą) lukę w postaci braku doświadczenia w posługiwaniu się wspomnianymi narzędziami nie będę miał takiej możliwości bez nadrobienia zaległości, z czego zdaję sobie sprawę.

 

Projekt, w którym się zasiedziałem jest dosyć archaiczny i skomplikowany (należy do tych „korpo legacy”). Mimo, że stos technologiczny frontu jest dość prosty: ES5, Handlebars, SCSS, Gulp, WebSocket (komunikacja frontu z Javą, nie z NodeJS); to zastosowanie customowego frameworka (praktycznie brak dokumentacji) i nietypowe środowisko docelowe utrudniają wykonywanie pracy stricte frontendowej, jeśli nie jest się Full Stackiem (takim z naciskiem na znajomość Javy i SQL).

 

Przechodząc do sedna. Mam następujące pytania:

  1. Ile czasu według Was (zwłaszcza tych bardziej doświadczonych) może zająć ogarnięcie aktualnie stosowanych narzędzi, frameworków (przy założeniu, że wcześniej korzystałem z AngularJS i Angular2/4), technik (PWA, SSR itd.)? Wiem, że na to pytanie odpowiedź najpewniej brzmi „zależy”, ale przyjmując, że ma się solidne podstawy i doświadczenie w komercyjnych projektach, jest to lepsza sytuacja, niż nauka wszystkiego kompletnie od zera. Obecnie skupiam się na nauce wzorców projektowych, następnie na testach jednostkowych (tych jakoś też nie musiałem pisać w projektach).
  2. Czy rozsądną opcją jest, jako stan przejściowy, zredukować etat do np. połowy, po to aby mieć więcej czasu na naukę i tym samym szybciej nadrobić zaległości? Może czasami warto zrobić jeden krok w tył, żeby móc zrobić dwa do przodu…

 

Jeśli ktoś był lub jest w podobnej sytuacji, to chętnie skorzystam z przebytych doświadczeń i pomysłów na "odrdzewienie".

 

Dziękuję za wszelkie rady. :)

3 odpowiedzi

+5 głosów
odpowiedź 17 grudnia 2018 przez imklau Nałogowiec (42,090 p.)

1. Wydaje mi się, że dałeś zbyt ogólne pytanie.
Idąc do pierwszej pracy, jako Junior miałam za sobą korzystanie z czegoś takiego, jak: Gulp, Sass, npm, ES6, Handlebars, Webpack. Uważałam to za podstawę, coś co muszę znać "na start". Ale w pracy i tak wykorzystujemy własny boilerplate, bo jednak mijałoby się z celem stawianie wszystkiego od zera przy każdym projekcie.

Więc jeśli chodzi Ci o ogarnięcie tego, żeby tworzyć sobie jakiś projekt od zera to myślę, że dużo czasu na to nie jest potrzeba. Poświęć miesiąc i zobaczysz efekty :)

Ile czasu według Was może zająć ogarnięcie aktualnie stosowanych narzędzi, frameworków...

Ty planujesz uczyć się wszystkich frameworków, czy jak? Bo tak można wywnioskować z tego pytania.

Piszesz w Angularze, prawda? Nie musisz znać Vue, Reacta i Angulara do tego, by nazywać siebie "Regularem".

2. Zdecydowanie nie nazwałabym tego rozsądną opcją :) Niczego nie redukuj. Robisz coś jeszcze poza pracą, co zajmuje Ci dużo godzin? Bo jeśli nie to warto sobie uświadomić, ile godzin tygodniowo nam zostaje.

Masz ich 168 na start.
Odliczając spanie, pracę i dojazdy, jakieś robienie zakupów, ogarnianie się z rana/wieczorem itp to i tak zostanie Ci w tyg "wolnych" ile? 40h? Wiadomo relaksik musi być, ale myślę, że spokojnie znalazłbyś nawet 20h tygodniowo na dodatkową naukę, co nie jest wcale tak mało.

Ach i tak tylko zaznaczę, żebyś nie przejmował się zbyt mocno tymi określeniami "Junior", "Regular", "Senior". Bo prawda jest taka, że każda firma wymaga czegoś innego i dla niektórych na pewno już nie jesteś Juniorem :D

komentarz 17 grudnia 2018 przez ScriptyChris Mędrzec (190,190 p.)

Idąc do pierwszej pracy, jako Junior miałam za sobą korzystanie z czegoś takiego, jak: Gulp, Sass, npm, ES6, Handlebars, Webpack. Uważałam to za podstawę, coś co muszę znać "na start".

Nie wiem, kiedy Ty zaczynałaś pierwszą pracę - może później niż ja i przez ten czas próg wejścia się podniósł. Albo ja miałem wtedy szczęście.

Ja akurat od początku nauki i, w sumie, aż do teraz skupiałem się na samych językach + Angular, bo akurat w tym były projekty. Na rozmowie rekrutacyjnej miałem tylko pytanie w stylu, czy kojarzę te narzędzia - odpowiedziałem, że wiem mniej więcej do czego służą, ale nie korzystałem.

Ty planujesz uczyć się wszystkich frameworków, czy jak? Bo tak można wywnioskować z tego pytania.

Nie. Myślę, żeby po prostu odświeżyć wiedzę z Angulara (zatrzymałem się na wersji 4, a już jest 7, TypeScript przy okazji też dostał aktualizacje), a Reacta i Vue sobie na tyle ogarnąć, żeby umieć cokolwiek sensownego w nich napisać i wiedzieć jak działają.

 Zdecydowanie nie nazwałabym tego rozsądną opcją :) Niczego nie redukuj. Robisz coś jeszcze poza pracą, co zajmuje Ci dużo godzin? Bo jeśli nie to warto sobie uświadomić, ile godzin tygodniowo nam zostaje.

Zgadzam się z tymi wyliczeniami. Chociaż alternatywą jest wzięcie dłuższego urlopu. :)

komentarz 19 grudnia 2018 przez imklau Nałogowiec (42,090 p.)

Hmm no właściwie to ja zaczynałam pracę rok temu, więc nie wiem, czy ten próg wejścia się podniósł wtedy :P może i tak.

Nie. Myślę, żeby po prostu odświeżyć wiedzę z Angulara (zatrzymałem się na wersji 4, a już jest 7, TypeScript przy okazji też dostał aktualizacje), a Reacta i Vue sobie na tyle ogarnąć, żeby umieć cokolwiek sensownego w nich napisać i wiedzieć jak działają.

Okej, jeśli chodzi Ci o coś takiego to jak najbardziej mądry pomysł!

Ale kurde przecież widać po forum, jaki Ty masz poziom wiedzy i wiem, że wykraczasz poza przeciętnego Juniora. Tak, jak napisałeś gdzieś tutaj wcześniej:

Tyle, że frontend to nie tylko sam JavaScript. :)

Ale jeśli JS dobrze ogarnąłeś to już dalej masz naprawdę z górki :P

Tomek też dobrze Ci wspomniał o testach. Sama mam to w planach ogarnąć po nowym roku, bo wiadomo, że kiedyś, kieeedyś będę chciała być traktowana jako Regular, a testowanie według mnie to takie "must have" :)

A to jest u Ciebie tak, że jesteś w obecnym projekcie i chcesz się poduczyć, żeby przejść do takiego, który bardziej będzie Cię satysfakcjonował? Nie możesz przejść do innego na tym etapie, na którym jesteś? Czy w ogóle myślisz o zmianie pracy?

Zgadzam się z tymi wyliczeniami. Chociaż alternatywą jest wzięcie dłuższego urlopu. :)

Aj no jeśli masz możliwość wziąć taki urlop to...zazdroszczę :D Na pewno to też byłaby fajna sprawa.

komentarz 19 grudnia 2018 przez ScriptyChris Mędrzec (190,190 p.)

A to jest u Ciebie tak, że jesteś w obecnym projekcie i chcesz się poduczyć, żeby przejść do takiego, który bardziej będzie Cię satysfakcjonował? Nie możesz przejść do innego na tym etapie, na którym jesteś? Czy w ogóle myślisz o zmianie pracy?

Priorytetem dla mnie jest nadrobienie zaległości, bo chcę wejść poziom wyżej (nie tylko w oczach tej, czy innej firmy, ale też dla samego siebie), i dobrze żeby to jakoś zgrać z opuszczeniem projektu - a szukanie zastępcy i wdrożenie go, z tego co wiem, trochę trwa. Co do reszty, to jeszcze nie jestem pewien. :)

+2 głosów
odpowiedź 17 grudnia 2018 przez Tomek Sochacki Ekspert (227,510 p.)
Pewnie ile osób tyle opinii... ja uważam, że regular to osoba, która przede wszystkim umie sprawnie pisać dobre testy unit i choćby proste e2e, testy to podstawa i to zarówno proste przypadki jak i async, mokowanie zależności itp. Bez sprawnego pisania testow wg mnie nie ma co myśleć o przejsciu granicy juniora.

Druga sprawa to umiejętność patrzenia na kod przez pryzmat optymalizacji i testów. Na przyklad regular nie napisze wg mnie funkcji na 50 linii sprawdzajacej tysiąc warunków bo wie, że otestowanie tego to masakra i zrobi dobra strukture małych metod, obiektow, klas itp.

Trzeci warunek to choćby podstawowa znajomość narzedzi pobocznych, umiejętność pracy np. z  JIRA, bamboo czy innym builderem, czymś do analizy statystyk apki np. kibana, newrelic itp.

No i oczywiscie git... regular powiniem wiedziec czym jest rebase, jak wycofac szybko zmiany z commita z przed tygodnia bo się okazuje, że jest problem na produkcji itp. itd.

No i ostatni punkt... umiesz czytać dojumentacje, nie obce Ci jest szukanie info na so czy gh issues itp.
komentarz 17 grudnia 2018 przez ScriptyChris Mędrzec (190,190 p.)

Bez sprawnego pisania testow wg mnie nie ma co myśleć o przejsciu granicy juniora.

Ta umiejętność, jak się domyślam, istotna jest nie tylko we froncie?

Trzeci warunek to choćby podstawowa znajomość narzedzi pobocznych, umiejętność pracy np. z  JIRA, bamboo czy innym builderem, czymś do analizy statystyk apki np. kibana, newrelic itp.

Z JIRy/Redmine lub innego serwisu do analizy i zarządzania taskami itd. z tego co zauważyłem korzysta w sumie każdy w projekcie (nawet Tester, czy Analityk Biznesowy). Czy narzędziami typu Jenkins bardziej szczegółowo nie powinni zajmować się DevOpsi?

No i ostatni punkt... umiesz czytać dojumentacje, nie obce Ci jest szukanie info na so czy gh issues itp.

Moim zdaniem to powinien umieć Junior, a może i nawet Stażysta. :) Tak samo jak język angielski.

3
komentarz 17 grudnia 2018 przez Tomek Sochacki Ekspert (227,510 p.)

Moim zdaniem to powinien umieć Junior, a może i nawet Stażysta. :) Tak samo jak język angielski.

ojojoj... świat nie jest taki piękny :)

Ta umiejętność, jak się domyślam, istotna jest nie tylko we froncie?

zgadza się, ale zdziwiłbyś się jak wiele osób chwali się projektami w CV, jakimiś bajerami, animacjami itp. a nie potrafi napisać prostego testu, ba, nawet zapytani co to jasmine/jest/mocha itp. itd. nie wiedzą o co kaman :)

Z JIRy/Redmine lub innego serwisu do analizy i zarządzania taskami itd. z tego co zauważyłem korzysta w sumie każdy w projekcie (nawet Tester, czy Analityk Biznesowy).

Zgadza się, przynajmniej powinni, ale znam osoby, które potrafią ponad rok pracować niby jako programiści a nie znają takich narzędzi i nawet nie znają dobrze gita... smutne, ale niestety prawdziwe...

Co do narzędzi do buildów itp. to już zależy w sumie od człowieka... Ja wychodzę z założenia, że mimo, iż jestem generalnie frontem to nie spadnie mi czapka z głowy jak wejdę w bamboo i sprawdzę dlaczego mój build wywalił czy coś dokonfiguruję jak trzeba, tak samo ze statami, można mówić, że to głównie back-end ale czy stanie Ci się krzywda jak wejdziesz np. w kibanę i sprawdzić skąd timeouty na jakieś mikrousłudze czy jak wejdziesz w back-end żeby poprawić jakąś pierdołę... 

Moim zdaniem to własnie wyróżnia regulara i seniora, że nie patrzy na programowanie przez pryzmat swojego, małego światka np. JS/Angular i nic więcej, tylko potrafi odnaleźć się w różnych sytuacjach, problemach itp.

 

Ale czytając Twojego posta i teraz odpowiedź wydaje mi się, że jesteś na dobrej drodze aby uderzać w stanowiska regular... Spróbuj może zrobić sobie jakiś projekcik prywatny gdzie jest nieco więcej konfigu.. hmm np. jak jesteś w Angular to machnij prostego bloga czy cokolwiek np. z server side renderingiem w node + PWA na froncie + dodaj sobie np. na bitbucket czy gdziekolwiek jakieś CI i pomyśl nad automatyzacją builda, albo chociażby napisz sobie skrypt odpalany na serwerze do podciągnięcia aktulanego mastera i developmentu apki.

Uwierz mi, spędzisz więcej czasu na docs i SO niż na pisaniu :) ale nauczysz się konfigurować apkę od początku. Nie chodzi o samą apkę, to akurat nie istotne - spróbuj od zera sobie to zrobić, czyli nie bierz gotowca angular universal tylko goły projekt angular i dodawa SSR, PWA itp. krok po kroku.

Do tego spróbuj sobie zrobić jakąś malutką apkę w vanillaJS i skonfiguruj samodzielnie webpacka z babelem, sass, build chunks itp.

Na rozmowie o pracę będziesz wtedy wiedział o czym mówisz :)

I powodzenia!

komentarz 17 grudnia 2018 przez ScriptyChris Mędrzec (190,190 p.)

Ja wychodzę z założenia, że mimo, iż jestem generalnie frontem to nie spadnie mi czapka z głowy jak wejdę w bamboo i sprawdzę dlaczego mój build wywalił czy coś dokonfiguruję jak trzeba (...)

Zapewne moje podejście jest błędne, ale backend "nie NodeJS-owy" wolę póki co omijać szerokim łukiem (nigdy jakoś go nie lubiłem). Chcę najpierw dobrze poznać swoją działkę, a dopiero potem ewentualnie poszerzać horyzonty. I tak, zdaję sobie sprawę, że wraz ze wzrostem poziomu w hierarchii zespołu (Junior -> Regular -> Senior -> Leader itd.) rośnie poziom odpowiedzialności (w tym obowiązków) i wypada (nie wiem, czy to właściwe określenie) ogarniać więcej w projekcie. Ale mam taką, możliwe że złudną, nadzieję, że wraz z rozwojem technologii, architektury i technik zarządzania projektami rozdzielenie ról (frontend, backend, devops itd.) będzie bardziej klarowne i pozwoli na to, że osoby, które wolą specjalizować się w swojej dziedzinie nie będą musiały dotykać (lub w ograniczonym stopniu) innych części aplikacji/systemu.

Ale czytając Twojego posta i teraz odpowiedź wydaje mi się, że jesteś na dobrej drodze aby uderzać w stanowiska regular...

Ja odnoszę inne wrażenie. :) Coraz bardziej widzę, że w mojej nauce zabrakło balansu - za dużo w głąb jednego, za mało w szerz całej reszty.

Spróbuj może zrobić sobie jakiś projekcik prywatny gdzie jest nieco więcej konfigu

 +

Do tego spróbuj sobie zrobić jakąś malutką apkę w vanillaJS i skonfiguruj samodzielnie webpacka z babelem, sass, build chunks itp.

Dzięki. Przydatne pomysły. :)

Uwierz mi, spędzisz więcej czasu na docs i SO niż na pisaniu :) ale nauczysz się konfigurować apkę od początku.

W to nie wątpię. Nie raz dłużej czytałem jak coś działa i jak to uruchomić zanim zacząłem się tym znośnie posługiwać.

0 głosów
odpowiedź 17 grudnia 2018 przez ShiroUmizake Nałogowiec (46,300 p.)
Woah! Masz większą wiedzę, niż ja z JS (rozwiązując moje niecodzienne problemy), spokojnie wal na Regulara :). Co do stawiania projektów, jeśli wasza firma ceni was czas pracy to ma gotowe boilerplate. Patrząc na wasz stos architektoniczny to dosyć przestarzały, gulp został wyparty, większość tych narzędzi zamieniliśmy na webpack plus swoje ficzery ;). Wszystko zaczytywane z autorskiego static servera gdzie są wrzucane paczuszki npm..

PS: Nie macie czasu na rozwój, na takie rzeczy?

 Według mnie, jak znasz zasady działań frameworka to spokojnie już teraz możesz zacząć z nimi pracować, nie ma sensu się zakopywać książkach czy przeglądać jądra bibliotek.
komentarz 17 grudnia 2018 przez ScriptyChris Mędrzec (190,190 p.)

Woah! Masz większą wiedzę, niż ja z JS (rozwiązując moje niecodzienne problemy), spokojnie wal na Regulara :)

Tyle, że frontend to nie tylko sam JavaScript. :)

Patrząc na wasz stos architektoniczny to dosyć przestarzały, gulp został wyparty, większość tych narzędzi zamieniliśmy na webpack plus swoje ficzery ;)

Stary stos technologiczny to jedno. Bardziej frustrujące są archaiczność, szczątkowa dokumentacja (customowy framework) i działanie w nietypowym środowisku, gdzie nie ma jednoznacznego podziału na frontend i backend.

PS: Nie macie czasu na rozwój, na takie rzeczy?

Masz na myśli, że np. przez kilka godzin jednego dnia w tygodniu można sobie dłubać coś swojego? Nie mamy czegoś takiego.

komentarz 17 grudnia 2018 przez ShiroUmizake Nałogowiec (46,300 p.)

Masz na myśli, że np. przez kilka godzin jednego dnia w tygodniu można sobie dłubać coś swojego? Nie mamy czegoś takiego.

W naszej firmie, tworzymy tym czasie jakieś rzeczy do optymalizujące bądż narzędzia dla innych działów ;)

 Stary stos technologiczny to jedno. Bardziej frustrujące są archaiczność, szczątkowa dokumentacja (customowy framework) i działanie w nietypowym środowisku, gdzie nie ma jednoznacznego podziału na frontend i backend.

I co nie ma jakieś zgody na tych wyższych stanowiskach ( Lider Technologiczny/ Senior), że wytwarzanie takim środowisku jest trudne i złożone oraz czasochłodne. Nam się udało przekonać biznes, od roku budujemy nowy core, nowe funkcjonalnośći dostarczone są 4-5 razy szybciej no i da się to rozwiązania powielić.

komentarz 17 grudnia 2018 przez ScriptyChris Mędrzec (190,190 p.)
Problemem jest niedostatek developerów i duża skala (chyba właściwe określenie) - projekt jest międzynarodowy, w kilku wersjach i wielu konfiguracjach.
komentarz 18 grudnia 2018 przez ShiroUmizake Nałogowiec (46,300 p.)
Mówiąc okrutnie gonicie sprint za sprintem xp

Podobne pytania

0 głosów
0 odpowiedzi 205 wizyt
0 głosów
1 odpowiedź 267 wizyt
+1 głos
2 odpowiedzi 446 wizyt

92,851 zapytań

141,792 odpowiedzi

320,879 komentarzy

62,183 pasjonatów

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj.

Wprowadzenie do ITsec, tom 2

Można już zamawiać tom 2 książki "Wprowadzenie do bezpieczeństwa IT" - będzie to około 650 stron wiedzy o ITsec (17 rozdziałów, 14 autorów, kolorowy druk).

Planowana premiera: 30.09.2024, zaś planowana wysyłka nastąpi w drugim tygodniu października 2024.

Warto preorderować, tym bardziej, iż mamy dla Was kod: pasja (użyjcie go w koszyku), dzięki któremu uzyskamy dodatkowe 15% zniżki! Dziękujemy zaprzyjaźnionej ekipie Sekuraka za kod dla naszej Społeczności!

...