Javascript kiddies?

Czy Wy też macie takie wrażenie, że wielu programistów Javascript za bardzo nie ogarnia? Wielu których poznałem okazało się takimi script kiddies, którzy stosując strategię copy-paste from stackoverflow klepią jakieś stronki i nie potrafią nic poza tym wąskim wycinkiem programowania i Informatyki jako całości. Przypominają mi trochę takich 15-letnich koderów PHP sprzed 10 lat, którzy na swojej "stronie firmowej" pisali o sobie w liczbie mnogiej...

Mam podobne wrażenia. Spotkałem takich, którzy mieli etykietkę "JS expert developer" i nie byli w stanie uargumentować dlaczego nie chcą otrzymywać wartości w CSV (tylko jakieś brednie, że parsowanie takich stringów jest trudne), a na myśl o bardziej wyrafinowanych operacjach typu scal dwie struktury danych (np. klienci i uslugi_klientow używając id klienta jako klucza) to zupełnie nie ogarniali. Nie wiem, może nie miałem szczęścia spotkać ludzi, którzy faktycznie znają się na JS.

I pewnie myślisz, że kiedyśc inaczej było?

Pokolenie BASIC kiddies.

Tak, to tragedia. Z rokiem na rok coraz gorzej.

Tylko, że kiedyś JavaScript kiddies ograniczali się do pisania prostych skryptów - znam PHP, a chcę zrobić efekt na stronie w JS - czyli ogólnie byli to tacy webmasterzy, którzy na jakimś momencie potrzebowali coś napisać w JS (a potem wiecznie te same pytania na forach "jak przesłać zmienną z PHP do JS"
https://www.google.pl/search?q=jak+przes%C5%82a%C4%87+zmienn%C4%85+z+PHP+do+JS ). I tacy JS kiddies używali zwykle VanillaJS, jQuery (wraz z wtyczkami), gotowych skryptów z netu czy innych low-endowych tooli.

Natomiast teraz sytuacja jest o tyle gorsza, że ci ludzie już nie piszą prostych skryptów, tylko uczą się całego arsenału - Reacta, Webpacka, Reduxa i masę innych rzeczy. Swoją drogą aż mnie zadziwiają czasem, bo ja się czasem uczę od nich, że istnieje jakaś biblioteka, tool, czy technika. Są czasem bardzo na czasie (bo mają czasem bardzo świeżą wiedzę, prosto z najnowszych tutoriali) . Jednak od wytrawnego programisty różni ich fakt, że nie bardzo wiedzą dlaczego czy po co (np. taki gość potrafi uczyć się jakiejś biblioteki, np. Reduxa, ale w zasadzie nie ma pojęcia dlaczego się uczy, jakiego rodzaju problemy Redux (albo inna popularna biblioteka) rozwiązuje, tylko uczy się, bo coś jest modne.

Podobnie ludzie mający background w C#/Java też od razu wchodzą w TypeScript zanim się nauczą podstaw JavaScriptu (nie mówię, żeby nie używać TypeScriptu, tylko raczej o tym, że tacy ludzie są potem niedoinformowani i nie wiedzą gdzie się kończy JavaScript, a gdzie zaczyna TypeScript. I mają skłonność do przeinżynierowania rozwiązań i pisania ich w TSowy sposób, nawet jeśli czysto JS-owe rozwiązanie byłoby właściwe (chociaż może źle się wyraziłem z tym TS, bo to nie zawsze muszą być rzeczy z TypeScript. Czasem ludzie używają nawet rzeczy, które są w czystym JavaScript (ES6+), jak klasy, dziedziczenie itp. - ale w taki sposób, jakby nie znali niczego innego, oprócz robienia klasy do każdej głupoty).

W sensie - JavaScript kiddies to tacy ludzie, którzy uczą się czegoś, używają jakiejś libki, ale nie wiedzą dlaczego to robią, nigdy nie próbowali pisać w inny sposób.

Przypominają mi trochę takich 15-letnich koderów PHP sprzed 10 lat, którzy na swojej "stronie firmowej" pisali o sobie w liczbie mnogiej...

Toż to kilka dni temu w wątku o swoim portfolio gość używał liczby mnogiej o sobie (co ciekawe tylko w dyskusji forumowej, a samo portfolio zrobił jako osobiste).

Nie powiedziałbym, że ogranicza się to tylko do JS'a. Z jednej strony problem widzę i rozumiem, bo mnie to na co dzień męczy jak czytam kod, którego wolałbym nie czytać. Z drugiej mam częściej wrażenie, że to przesadzanie w drugą stronę, bo niektórzy by chcieli, żeby implementować własną maszynę wirtualną pod każdy projekt.

Nie każdego interesuje programowanie w takim stopniu, żeby poznawać jego zakamarki. Niektórych nawet w ogóle nie interesuje. Jak widać popyt na "script kiddies" jest.

Dużo osób się pcha bo nie wiedzą ile czasu zajmuje nauka .

Jak dobrze, że era javascriptu dobiega końca :)

WeiXiao napisał(a):

Jak dobrze, że era javascriptu dobiega końca :)

Ogólnie to era JSu dobiega końca od - jeśli wierzyć różnym ekspertom - około kilku ładnych lat. Czemu akurat teraz miałyby się te wróżby sprawdzić?

Nie sądzę XD Nawet jeśli taki WebAssembly pozwoli na uruchamianie innych rzeczy (swoją drogą już od paru lat ludzie są w stanie to robić z Emscripten albo dedykowanymi transpilatorami - i jakoś dalej się pisze w JS), to nie sądzę, żeby zastapiło to JavaScript całkowicie. Co najwyżej uzupełnią.

Prędzej uwierzę w to, co już się dzieje - że ludzie będą pisać w TypeScripcie czy innym JSie z ulepszaczami.

To co produkują zwykle jest do usunięcia, bo są one albo fragile
albo testują detale implementacyjne totalnie nie myśląc, co robią.

Przydałoby się Wujka Boba na nich napuścić. Swoją drogą testowanie detali implementacyjnych to albo brak doświadczenia (chcę testować, ale nie wiem jak, więc testuję jak umiem) albo głupota (jeśli ktoś będąc doświadczonym programistą dalej testuje detale implementacyjne*, mimo że widział już ileś razy, że to się rozwali przy pierwszym refaktorze - to raczej nie jest to człowiek, który poddaje refleksji to, co robi).

A myślę, że wiele by się znalazło ludzi, którzy niby początkującymi nie są, mają jakieś doświadczenie, ale dalej piszą testy na zasadzie odzwierciedlania 1:1 implementacji. Czyli test g**no testuje, w zasadzie tylko to, czy się coś zmieniło, bo jak się cokolwiek zmieni, to test nie przejdzie (czyli robią taki snapshot test, tyle, że ręcznie, zamiast z automatu).

*Chociaż z drugiej strony testowanie implementacji czasem może być przydatne, ale trzeba wiedzieć kiedy i wiedzieć, że to są testy "na jeden strzał" i że to one pierwsze pójdą się j... przy refaktorze, dlatego nie można na nich zbytnio polegać i należałoby je traktować jako dodatkowe testy, a nie główne

Chyba mówicie o jakiś juniorkach, albo firmach, które dopiero coś tam zaczynają grzebać w JS i do projektu wskoczył kolega backendowiec. Byłem na rozmowach na stanowiska frontendowe i bez zrozumienia założeń i niuansów JS to bym po 3 minutach wyszedł z płaczem :D. Kumpla ostatnio jacyś Hindusi na Hangouts maglowali z Symbol(), a to raczej awangarda (ale nie chcę się o to spierać :D).

Dzisiaj jest w ogóle taki trend, że ludzie wpisują do CV mnóstwo technologii, a ich poziom się sprowadza do kursu z udemy albo tutoriala na oficjalnej stronie. React, docker, mongo i tak dalej. Większość firm potrafi jednak to wyłapać w procesie rekrutacji. Problemy się zaczynają, gdy trzeba zrobić dobrze projekt, który ma jakieś realne wymagania, te basic tutoriale są zazwyczaj odpięte od rzeczywistości. Moim zdaniem materiałów do poważnych use-casów w JS jest w necie jak na lekarstwo.

Zawsze powtarzam - szukasz dobrego webmastera, programisty, poproś o własne projekty robione w ramach tej pasji.

I zauważyłem ostatnio, że rzeczywiście poważne firmy oferujące poważne pieniądze wymagają takich projektów. I wcale nie mówię o githubie - chodzi o ukończone, działające, używane/sprzedające się produkty. Do tego dopisują często "proven track record of always learning" - czy cuś takiego. Dla mnie to jest super i najskuteczniejsze sito na ludzi bez pojęcia.

Symbol() to akurat przydatna rzecz, bo pozwala na przyczepianie do obiektów unikalnych właściwości. Chociaż, podobnie jak WeakMap, pewnie bardziej się to przydaje przy robieniu bibliotek niż kodu biznesowego.

Ale i tak myślę, że większą korzyść ludzie by mieli z opanowania Symboli, WeakMap, i paru innych rzeczy, które doszły do języka, niż z nauki np. wielokropka do obiektów ... czy innych rzeczy, które wiele nie wnoszą, a są tylko cukrem składniowym.

CV mnóstwo technologii, a ich poziom się sprowadza do kursu z udemy albo tutoriala na oficjalnej stronie.

Bo wiele narzędzi niewiele więcej wymaga do ich używania. Czy np. znajomość Webpacka wymaga czegoś więcej niż tylko przemęczenie się za pierwszym razem (mnie kilka godzin to zajęło na początku, żeby w ogóle odpalić builda)? A potem to z górki. Po prostu wchodzisz na dokumentację Webpacka i kopiujesz aktualny kod do konfiga (które się ciągle zmieniają BTW). Podobnie np. z React Router. Żadna wielka filozofia, wystarczy po prostu znać aktualne API. A niektóre firmy np. piszą w wymaganiach coś w stylu "znajomość React Router". Firmy za bardzo cenią sobie "znajomość technologii", tak jakby technologii nie można było się w biegu nauczyć.

Co innego jeszcze taki React, który jest pozornie łatwy, bo ma łatwe API, ale już trudniej to ogarnąć głębiej, biorąc pod uwagę skalowalność, wydajność itp.

React, docker, mongo i tak dalej.

Moje pierwsze styknięcie z Dockerem, to jak kiedyś wszedłem do projektu, w którym był Docker. Nie znałem go zupełnie, ale przecież jest dokumentacja i kolega mi też pomagał, i dało się zainstalować. Nie jest to wielka filozofia. Takie rzeczy przecież są właśnie po to, żeby było łatwiej coś zainstalować w projekcie, w którym jest sobie ileś osób (bez Dockera byłoby trudniej, bo każdy, kto wchodzi do projektu musiałby wiedzieć, jak zainstalować ręcznie z tuzin innych tooli, które są potrzebne w projekcie, a które Docker sam zainstaluje wg konfiga). Chociaż jak dla mnie ogólnie Docker też utrudnia i spowalnia pracę przez to, że wszystko jest w Dockerze, a nie normalnie, ale to już inna sprawa.

LukeJL napisał(a):

Bo wiele narzędzi niewiele więcej wymaga do ich używania. Czy np. znajomość Webpacka wymaga czegoś więcej niż tylko przemęczenie się za pierwszym razem [...]

Webpack akurat jest dość prosty, ale dla większości ludzi to i tak blackbox - jak się tylko pojawi jakiś błąd w konsoli to google do oporu. Odpalenie
docker-compose up to nie jest "znajomość dockera", jeśli się nie kuma czy lepiej jest mieć zależność X czy Y w osobnym kontenerze czy jednak nie i jaka jest to różnica, o umiejętności deployu i spięcia tego z jakimś CI nie wspomnę. To wszystko wychodzi w trakcie zwyczajnej pogadanki rekrutacyjnej - o ile ktoś wie o co pytać :).

Edit: I masz rację, większość rzeczy to naprawdę nie jest żadna wielka filozofia, założenia są często nawet banalne. Ale znajomość technologii wynika z doświadczenia w jej używaniu w różnych przypadkach, czyli wyjścia poza optymistyczne obiecanki ze strony głównej każdej z nich i napotkanie problemów.

Przykładowo: dzisiaj twórca frameworka Laravel pochwalił się na Twitterze, że ich Query Builder ma genialne helpery do kolumn typu JSON. Dopiero w odpowiedziach mu wytknęli, że to nie działa dla baz innych niż MySQL i że nie działa operator ->>. To jest właśnie znajomość technologii na poziomie interesującym dla każdego, a nie takie entry-level umiem zapisać encję ;).

LukeJL napisał(a):

Firmy za bardzo cenią sobie "znajomość technologii", tak jakby technologii nie można było się w biegu nauczyć.

No tak jest, firmy szukają programistów frameworków i bibliotek, a nie języka, kandydaci odpowiadają na wymagania i uczą się skrótowo, proste zasady działania rynku.

Pewnie tak. Gdyby pisano w wymaganiach "zaawansowana znajomość JavaScriptu, zarówno w wersji ES3, ES5, jak i ES6 i nowszych" oraz wymienienia rzeczy typu "musi wiedzieć, co to closure, prototyp, jak działa this, jak działają klasy ES6, czym różni się let od const od var" to potem ludzie by przywiązywali większą uwagę do JavaScriptu, nie byłoby narzekania, że "kandydaci są tacy nieogarnięci nie znają podstaw JS".

A jeśli w ogłoszeniach jest coś w stylu "React, Webpack, Redux" to mamy potem "programistów Reacta" (którzy są obecną wersją "programistów jQuery", czyli ludzi, którzy wiedzą tylko jak zrobić coś w React, a nie znają języka. Często nawet w React nie umieją pisać i ściągają gotowe komponenty React, które są takim odpowiednikiem "pluginów do jQuery".

Tak samo już na bardziej zaawansowane stanowiska nie szuka się "ludzi z doświadczeniem w JavaScript" ale "ludzi z doświadczeniem w React" (mimo, że taka wiedza frameworkowa się bardzo szybko dezaktualizuje, wraz z kolejną wersją Reacta).

To firmy same wychowują sobie pokolenie script kiddies.