'Profesjonalny programista' by Uncle Bob

Zgadzacie sie z poznizszym tekstem Uncle Boba? Juz kiedys to czytalem ale dzisiaj sie nadtknalem ponownie na kogos blogu.

Z wiekszoscia sie ogolnie zgadzam ale niektore rzeczy mozna nadinterpretowac. To porownanie do prawnikow i lekarzy rowniez wydaje mi sie bzdurne.

Ta nauka we wlasnym zakresie... W polskich realiach pachnie mi to patologia w stylu " nie umiesz JS? To sie doucz w domu, skoro umiesz jave"

Poza tym nauka we wlasnym zakresie ma sie nijak do praktyki.

Tekst:
"Jeśli jesteś profesjonalistą znaczy to, że to Ty jesteś odpowiedzialny za swoją karierę. Jesteś odpowiedzialny za czytanie i uczenie się. Jesteś odpowiedzialny za bycie na bieżąco z branżą i technologią. Wielu programistów uważa, że doszkalanie to obowiązek ich pracodawców. To jest kompletna bzdura. Sądzisz, że lekarze zachowują się w ten sposób? Sądzisz, że prawnicy robią podobnie? Nie, sami szkolą się we własnym czasie i za własne pieniądze. Spędzają sporą ilość czasu po godzinach na czytaniu magazynów i orzeczeń sądów. Są na bieżąco. My także musimy tak robić. Związek pomiędzy Tobą a Twoim pracodawcą jest nakreślony w twoim kontrakcie. W skrócie: pracodawca obiecuje Ci płacić a Ty obiecujesz robić dobrą robotę."

https://michalkulinski.blogspot.com/2017/05/profesjonalny-programista.html?m=1

Ps. Ja to interpretuje raczej tak, ze jak mam prace w ktorej sie rozwijam to zostaje. A jak nie to odchodze. W koncu to 'moja kariera'

Są programiści z pasją, którzy kodują i rozwijają się w temacie po godzinach, a są też programiści, którzy są w tym zawodzie bo jest dobrze płatny i robią robotę na 'odwal się'. Z drugiej strony nie przypominam sobie, by jakiś pracodawca mi kiedyś kazał uczyć się czegoś w domu - prędzej jest ciśnienie, by zrobić coś szybko ale kiepsko niż by poświęcać czas wolny, by zrobić zadanie dobrze. Natomiast samo programowanie to ciągłe uczenie się - gdy dostaję zadanie to bardzo często muszę się czegoś douczyć. Szukając odpowiedzi na StackOverflow i adaptując odpowiedzi też się uczę.

Poza tym nauka we wlasnym zakresie ma sie nijak do praktyki.
Ps. Ja to interpretuje raczej tak, ze jak mam prace w ktorej sie rozwijam to zostaje. A jak nie to odchodze. W koncu to 'moja kariera'

Zależy jak łatwo znaleźć pracę, w której będziesz się czuł, że się rozwijasz. Jeśli łatwo ci znaleźć idealną pracę to ją znajdź. W innym przypadku trzeba dokonać zmian w obecnej pracy. Zmian typu usprawnienia w infrastrukturze czy stosie technologicznym. Myślę, że sytuacja w której firma miałaby dać ci czas na eksperymentowanie w czasie pracy z technologią z którą dopiero zaczynasz, a która tylko tobie się podoba byłaby dość kuriozalna. Pracodawca płaci za działający dostarczony produkt, a nie eksperymenty. Stąd trzeba najpierw coś porzeźbić w danym narzędziu po godzinach, potem zareklamować zespołowi, wdrożyć na produkcję i zyskać w tym komercyjne doświadczenie.

W skrócie: wszystko zależy od tego jak sobie wyobrażasz w jaki sposób firma miałaby pomóc ci w rozwoju.

to też zależy w jakim zakresie to douczanie, jeśli klepiesz front i nie umiesz jakiś klas w css i pracodawca ci powie weź się doucz to luz, ale jak klepiesz w Java i janusz ci powie doucz się C# czy PHP to jak dla mnie bez sensu :)
a być na bieżąco z jakąś wersją frameworka czy zasadami bezpieczeństwa to jak najbardziej prawilne wiadomo, po części za to masz również płacone (zwykle więcej od standardowego klepacza)
warto też użyć swojego mózgu i nie dać się wykorzystywać, prawidłowo oceniać taski do swoich umiejętności, zarobku, stanowiska, a nie iść ślepo za tłumem, bo inni klepią w J-sofcie za 3k to ja też muszę, bo nie wypada się wyłamać
w ostateczności zawsze można jeb... to wszystko i wyjść z firmy ;)

W sumie zle to wszystko przedstawilem.
Bardziej mi chodzilo o to, ze dajmy taki tekst do przeczytania jakims managerom w korpo to zacznie sie 'januszowanie level master'. ;)

Ja bardzo chetnie ucze sie we wlasnym zakresie. Najlepiej gdy to czego ucze sie w domu jest w tej samej linii co w pracy. Ale w pracy tez przychodzi czas robienia czegos starego i nieprzydatnego poza ta firma. Takich rzeczy na pewno nie chce sie uczyc. Poza praca poucze sie takich rzeczy, ktore pomagaja mi byc 'konkurencyjnym i zatrudnialnym' lub sprawiaja mi fun.

Ale tez zalozmy, ze pracuje w SH i robir backend w c#. Ale trafia sie nowy projekt w python i django. Spoko, chetnie sie poucze. Ale oczekuje, ze w pracy bede mogl chociaz przerobic jakis tutorial czy zrobic mala appke, czy szkolenie - ale wole sam. A nie, ze bedzie ktos z dnia na dzien oczekiwal, ze wszystko ogarne.

stary ale przecież to jest logiczne i o tym pisałem, jeśli jesteś zatrudniony i testowany na jednym języku to nikt przy zdrowych zmysłach nie będzie wymagał nagle znajomości innego, bo nawet jeśli opanujesz to z tutoriala "Python w 24 godziny" to będziesz produkował goowno-kod dla goowno-firmy

co innego douczanie nowych bibliotek, fw, innych w znanym języku, a co innego w całkowicie nowym, przecież nikt nie jest tak naiwny aby douczać się nocami nowego języka, aby w dzień klepać w nim progsy ku chwale janusza który musi przyoszczędzić :)

Albo dajmy na to mikroserwisy i nauka w domu. Lekki absurd. Zrobienie paru appek w domu, ktore beda ze soba gadac raczej nie przyniesie sensownego doswiadczenia. Na cos takiego musi wylozyc kase firma.

Albo uzycie Cassandry bez zrobienia prawdziwego POC i duzej ilosci danych, zeby sprawdzic czy technologia sie nadaje w projekcie. Koncept teoretyczny warto znac ale 'bawic sie w domu' raczej nie ma sensu. W praktyce wyjdzie inaczej.

W domu zazwyczaj wszystko jest proste, czesto widzac tylko 'happy path' i czesto nic to nie daje. Na pewno nie wpisalbym sobie czegos takiego do CV ;)

czysteskarpety napisał(a):

stary ale przecież to jest logiczne i o tym pisałem, jeśli jesteś zatrudniony i testowany na jednym języku to nikt przy zdrowych zmysłach nie będzie wymagał nagle znajomości innego, bo nawet jeśli opanujesz to z tutoriala "Python w 24 godziny" to będziesz produkował goowno-kod dla goowno-firmy

co innego douczanie nowych bibliotek, fw, innych w znanym języku, a co innego w całkowicie nowym, przecież nikt nie jest tak naiwny aby douczać się nocami nowego języka, aby w dzień klepać w nim progsy ku chwale janusza który musi przyoszczędzić :)

Dla nas logiczne. Ale pokazałbyś taki tekst gdzieś wyżej to byłoby to szkodliwe dla wszystkich ;)

A co do nauki bibliotek. Wiele razy spotkałem się z wiedzą powierzchowną frameworków.
Często widziałem coś takiego:

• czemu to zostało tak zrobione?
• bo ten framework nie pozwala na zrobienie takich 'customowych' rzeczy, więc dospawaliśmy swoje rozwiązanie.
• aha

Osobiście nie wierzę, że tak często zdarza się, że twórcy frameworka o czymś nie pomyśleli. Może czasem lepiej poznać coś bardziej dogłębnie.

Dlatego, uważam, że:

• jeśli mamy wiedzę o danym frameworku w zespole - ok
• ale jak nie mamy - bo jest specyficzny do naszych potrzeb, to według mnie warto najpierw zainwestować w naukę zamiast klepać byle klepać - i dobrze jak odbywa się to w pracy

Trudno być profesjonalistą, bo ma to swoją cenę a klienci często chcą tanio i szybko. Więc trójkąt jakości daje nam wynik w postaci jakiegoś studenciaka co naklepie g**no kod za 2k netto.

Miałem zabawną rozmowę z jednym korpo - dostałem pytanie "Budzisz się, przychodzisz do pracy i klient mówi, że za 2 tygodnie ma być aplikacja bo reklamy kupione, bo social ninje na FB już robią kampanie. Co robisz?"

Ja odpowiedziałem, że zaglądam do swojej umowy jak są regulowane godziny nadgodzin. Jeśli nic nie ma, to siedzę po 8 godzin i idę do domu. Nie jestem jakimś niewolnikiem, a jeśli klient tak traktuje sprawę wytwarzania oprogramowania, to po prostu jest niepoważny i nie warto z takim współpracować.

Inna sprawa, też byłem na rozmowie w jakimś softwarehousie. Mówię o swoich wymaganiach - pull requesty, unit testy, statyczna analiza kodu, wypełniona jira taskami, niska ilość zewnętrznych bibliotek, kontrakty o pisaniu klas i nazewnictwie zmiennych w projekcie. Powiedziałem swoją stawkę i dostałem informacje, że jestem za drogi.

Także profesjonalizm gdzieś tam istnieje, ale z święcą go szukać. Takie teksty to po prostu idealistyczny obraz programisty którego coraz będzie trudniej znaleźć.

Ja się jednocześnie zgadzam i nie zgadzam z tym stwierdzeniem.

Z jednej strony zgadzam się o tyle, że np. jeśli chcesz być frontendowcem, to sam musisz podjąć jakieś kroki i się uczyć JavaScriptu czy popularnych frameworków w domu. Ty musisz na wstępie coś wiedzieć już, a nie przyjść z ulicy.

Ale nie zawsze wszystkiego zdążysz się nauczyć. W pracy też się człowiek masy rzeczy uczy i to jest normalne i nikt raczej nie robi z tego problemów. Znam HTML/CSS/JS, ale nie znam każdego frameworka, jaki się pojawił, więc jeśli firma korzysta z mniej popularnego frameworka, to oczekuję, że będę miał czas w pracy na naukę. Frameworki można ogarnąć w dość krótkim czasie na tyle, żeby w nich klepać.

Ale też nie do końca, ponieważ:

A co do nauki bibliotek. Wiele razy spotkałem się z wiedzą powierzchowną frameworków.

W kilka dni można opanować framework na poziomie Hello World (np. umieć w nim zrobić ToDo Application), ale już do głębszego poznania trzeba zrobić więcej projektów, rozwiązać więcej problemów...

A tego moim zdaniem łatwiej jest się nauczyć w domu robiąc coraz to nowe projekty niż klepiąc to samo dzień w dzień w pracy, która cię nie rozwija.

To jest argument za nauką w domu. Po prostu jest szybsza.

Z drugiej strony pewnych rzeczy nie nauczysz się w domu. Nie nauczysz się przede wszystkim samego projektu - projekty komercyjne są zwykle tajne, z zamkniętym kodem, podpisujesz NDA itp.

I tutaj nie mogę się zgodzić z Wujkiem Bobem:

"Jeśli jesteś profesjonalistą znaczy to, że to Ty jesteś odpowiedzialny za swoją karierę. Jesteś odpowiedzialny za czytanie i uczenie się. Jesteś odpowiedzialny za bycie na bieżąco z branżą i technologią. Wielu programistów uważa, że doszkalanie to obowiązek ich pracodawców. To jest kompletna bzdura.

Uważam, że to właśnie firma jest odpowiedzialna za wdrożenie nowicjuszy w swoje prywatne-niespotkane-nigdzie-indziej rozwiązania czy przeprowadzenie szkolenia. Nawet jeśli firma korzysta z jakiegoś rozwiązania open source, które jest mało popularne (albo udostępi swój własny kod open source) - to też raczej nie powinna oczekiwać jego dogłębnej znajomości przez randomowego programistę i też raczej powinna dać mu czas na wdrożenie się.

No i taka dygresja na koniec:

Osobiście nie wierzę, że tak często zdarza się, że twórcy frameworka o czymś nie pomyśleli

Oj bardzo często się tak zdarza przecież. Może jakiś dojrzały framework typu Django albo RoR ma wszystko obcykane, ale pamiętam, że w takim AngularJS ciągle trzeba było jakieś haki robić (i robiły je osoby bardziej doświadczone ode mnie, więc nie mogło być to wynikiem tylko mojej niekompetencji).

Mialem na mysli np. Framework Spring w javie, ktory jest gigantyczny i potrzeba czasu na jego poznanie jak i czasu na umiejetnosc jego konfiguracji.

Jak ktos tworzy potworka i napisal cos customowego zamiast uzyc czegos co jest wewnatrz frameworka bez jakis twardych dowodow,ze tego tam nie ma tomu raczej nie uwierze ;)

Ja uwazam, ze Uncle Bob wniosl bardzo duzo, ale nie wszystko co mowi jest uniwersalne i sprawdzi sie w kazdych warunkach. Poza tym niestety, pewne jego pomysly mozna roznie interpretowac.

Uncle Bob vs. realizm i życie w Polsce hehe :)

Uncle Bob czasami bardzo rozmija się z tym jaka jest moja praktyka, ale akurat w tym względzie się z nim zgadzam.

Spotkałem się z kilkoma rodzajami ludzi w trakcie kariery:
a) "byle do pierwszego" - nauczyli się używać narzędzi tak aby nikt się do nich nie czepiał, zostaną na tym samym stanowisku i 20 lat jeśli nikt ich nie wypierniczy (czy się uczą sami śmiem wątpić)

b) spece od wykorzystywanych narzędzi. Idziesz do nich np. jeśli masz problem z Mavenem. Odpowiadają na pytania z marszu bez czytania dokumentacji. W pracy zfokusowani na pracy. Gdy rozmawiasz z nimi o technologiach spoza pracy uśmiechają się żartobliwie albo robią oczy jak pięć złotych. Po pięciu minutach zapominają o temacie i wracają do obowiązków. Po pracy rodzina, grill, spacery. Jeśli zmienią pracę to na taką samą gdzie indziej.

c) ludzie którzy się całe życie uczą, technologii z pracy i spoza pracy. Mają zainteresowania związane z kompami i nie tylko. Konferencje, książki, kursy.

d) geniusze / geeki. Mają taką wiedzę że masz wrażenie że wyssali ją z mlekiem matki. Nie widzisz ich uczących się. Jeżdżą na konkursy i olimpiady. Wiedza niekoniecznie praktyczna, ale za to bardzo ciekawa. Pracują w NASA lub Google.

Oczywiście ta skala nie jest dyskretna i ludzie mogą należeć do kilku kategorii po trochu. Moim zdaniem warto się uczyć (np. ciekawa zasada: jeden język w ciągu roku), ale rozumiem też tych którym wystarcza przejście rozmowy rekrutacyjnej (b). Natomiast nie polecam pracy z kategorią (a). W zasadzie to u takich osób możesz się spodziewać kwiatka każdego rodzaju.

Ja się dużo uczę poza pracą, ale żeby mi się to nie znudziło to nigdy nie ma to związku z tym, co aktualnie w pracy robię. Raz dostałem pytanie od pracodawcy, czy po godzinach bym się nie pouczył JavaScript, bo byłoby miło żebym zaczął kiedyś pisać front to powiedziałem, że nie ma opcji i po temacie, problemów nie miałem.

Lokalny Rolnik :D napisał(a):

Ja się dużo uczę poza pracą, ale żeby mi się to nie znudziło to nigdy nie ma to związku z tym, co aktualnie w pracy robię. Raz dostałem pytanie od pracodawcy, czy po godzinach bym się nie pouczył JavaScript, bo byłoby miło żebym zaczął kiedyś pisać front to powiedziałem, że nie ma opcji i po temacie, problemów nie miałem.

A nie mogłeś zaproponować pośredniego rozwiązania czy może nie chciałeś? Jakaś część czasu pracy na naukę pod okiem kogoś z doświadczeniem w JS?

@vpiotr ja też się zgadzam, pod warunkiem 'zdrowego' pojmowania tego a nie wypaczenia... bo najlepszą ideę można wypaczyć. Agile też nie jest jakiś zły... ale to co biznesowo się z tym się z tym stało to trochę inna para butów.

taka anegdotka:
kiedys dolaczylam do zespolu .netowcow tworzacych nowa appke, zastepujaca stary, juz ledwo uzywany bieda-gui w javie.
w starej appce przy starcie pojawiala sie seria komunikatow 'exception ...' w odstepach kilku-kilkunastosekundowych.
jako ze codziennie musialam to wlaczac to spytalam kolegow czemu tak sie dzieje i czy mozna to jakos naprawic, a ci 'nie przejmuj sie to java (hehehe), od jakiegos czasu tak sie dzieje, ale musimy z tym zyc bo nie ma sensu zatrudniac javowca'.
problemem byly nulle w tabeli z konfiguracja, 15 minut do znalezienia i zalatania, poprawilam to w 2 tygodniu pracy. gdy moj kierownik dostal za to pochwale, skromnie odpowiedzial biznesowi ze samo sie naprawilo :)
ci sami ludzie narzekali na brak szkolen, rozwoju, zbyt male i rzadkie podwyzki. grozili rychlym odejsciem do konkurencji, wiekszosc siedzi tam do dzis i pewnie nadal poucza juniorow zeby nie tworzyli interfejsow bo po co tworzyc nowy plik w ktorym nie ma logiki biznesowej :)

@katelx:
Myslalem, ze na koncu powiesz 'i tak stalam sie senior java dev w firmie' ;)
Nie mam problemu zanurzyc sie w nieznana technologie na chwile. Gorzej z dnia na dzien ze springowca zostac dot.netowcem na fulltime i oczekiwac cudow ;)

Według mnie to trochę zależy. Jeśli np. pracodawca zatrudnia jakiś super fullstackowców od wszystkiego, z zespołu nikt nie umiera Reacta i nagle okazuje się że trzeba w nim pisac to trochę słabo i powinienć coś zorganizować.
Ja samemu się ucze tylko rzeczy które są albo tylko for fun, albo są ogólnie przydatne, np. znajomość Javy bardzo dobra, różne narzędzia do niej jak IDE, Maven/gradle i popularne biblioteki, zwłaszcza że tak naprawdę nie ucze się tylko Javy wtedy ale ogólnie programowania. Nauczę się jakiś nowych języków programowania takich jak Clojure czy Scala żeby poznać lepiej inne paradygmaty np. pogramowanie fukcyjne. Nauczę się lepiej korzystać z Linuxa bo to dla mnie fun ale też przydatne. Będe experymentował z architekturą, podziałem na kompenenty, kontenerami IoC, wzorcami projektowymi bo to jest "ogólna umiejętność". Ale jakby ktoś stwierdził "o tutaj skorzystamy z nowego frameworka którego nikt nie zna, masz w weekend się nauczyć" to bym powiedział merytoryczn spie...

EDIT:
Spring jest bardzo duży, ale sama corowa część to nie jest nie wiadomo ile, a jak już się ją umie to douczyć się nowych modułów nie jest tak trudno zwłaszcza że jest dobra dokumentacja

@scibi92: chodzilo mi o zaawansowana znajomosc springa. Albo np. Jpa i hibernate czy spring security.

Sporo rzeczy zrobione jak w spring guides co sie okazuje czesto powinny nie wychodzic poza tutorial bo sa tam omawiane podstawy podstaw i to jest ok... Jak na tutorial.

A poogladac Kubrynskiego, poczytac baeldunga czy vlad mihalcea i sie okazuje, ze wcale tak duzo nie umiemy ;)

Zaawansowaną znajomość Springa robi się pisząc kod. Trzeba napisać samemu jakiś projekt, nie musi być sam w sobie skomplikowany, albo w pracy podczas kodowania, na szczęście jest bardzo dobra dokumentacja do niego :)

scibi92 napisał(a):

Zaawansowaną znajomość Springa robi się pisząc kod. Trzeba napisać samemu jakiś projekt, nie musi być sam w sobie skomplikowany, albo w pracy podczas kodowania, na szczęście jest bardzo dobra dokumentacja do niego :)

Osobiscie zmeczylem sie w springu na przyklad tym, ze w jakies wersji dzialalo cos w pewien sposob, gdy w kolejnej dzialalo inaczej a wiekszosc rozwiazan na stackoverflow dotyczylo starej wersji. ;)

I spring sie wydaje easy dopoki robi sie proste CRUDy. ;)
Doglebna wiedze maja nieliczny a reszta wymysla jakies workaroundy ;)

swoja droga akurat januszowe podejscie 'wez se poczytaj i zrob to we wrogiej technologii' nie jest zle bo mozna sie w godzinach pracy pouczyc czegos nowego i ewentualne porazki wytlumaczyc brakiem doswiadczenia :)
2 tygodnie robiac cos innego to takze mile oderwanie od codziennosci. ok - jak sie takie cos przeciaga i nas to juz dluzej nie jara to moze to byc triggerem do zmiany pracy (kolejna zaleta!)

Czarny napisał(a):

scibi92 napisał(a):

Zaawansowaną znajomość Springa robi się pisząc kod. Trzeba napisać samemu jakiś projekt, nie musi być sam w sobie skomplikowany, albo w pracy podczas kodowania, na szczęście jest bardzo dobra dokumentacja do niego :)

Osobiscie zmeczylem sie w springu na przyklad tym, ze w jakies wersji dzialalo cos w pewien sposob, gdy w kolejnej dzialalo inaczej a wiekszosc rozwiazan na stackoverflow dotyczylo starej wersji. ;)

I spring sie wydaje easy dopoki robi sie proste CRUDy. ;)
Doglebna wiedze maja nieliczny a reszta wymysla jakies workaroundy ;)

Podaj jakiś przykład :)

Doglebna wiedze maja nieliczny a reszta wymysla jakies workaroundy

Osoby z dogłębną wiedzą na temat jakiegoś frameworka często same wpływają na jego kształt, zgłaszając na Githubie jakimś problem twórcom frameworka - czy nawet sami rozwijają framework. Frameworki nie są rzeczą raz a dobrze ustaloną, a czymś co się rozwija stopniowo (a to, że twórcy frameworków "o czymś nie pomyśleli. " bardzo często się zdarza. Jeśli wersja 4.0 jakiegoś tam frameworka działa dobrze to raczej dlatego, że we wszystkich poprzednich wersjach to zwykli użytkownicy (niekoniecznie z dogłębną wiedzą, czasem zwykli ludzie z ulicy) zgłaszali jakiś problem twórcom frameworka, a nie dlatego, że twórcy frameworków sami z siebie tacy mądrzy byli. Przynajmniej z tego co obserwuję. Sam zresztą robię wtyczkę do Atoma i mnóstwo ficzerów i pozytywnych zmian było spowodowane tym, że ktoś mi coś napisał na Githubie, że coś powinno się znaleźć we wtyczce, o czym w ogóle nie pomyslałem).

Workaroundy wynikają często wtedy, kiedy twórca frameworka nie reaguje na zgłoszenia userów (też czasem nie reaguję, i też ludzie robią workaroundy. Np. moja wtyczka ma skonfliktowane skróty klawiszowe i ludzie to sobie obchodzą/wyłączają je/zmieniają).

@scibi92:no widziałem pewne dziwności w spring security

@LukeJL Czyli jak uslyszysz tekst od kogoś " w tym frameworku tak sie nie da, więc napisałem coś swojego... bo ja wiem lepiej" to nie zapali Ci się czerwona lampka w głowie ? ;)

@LukeJL Czyli jak uslyszysz tekst od kogoś " w tym frameworku tak sie nie da, więc napisałem coś swojego... bo ja wiem lepiej"
to nie zapali Ci się czerwona lampka w głowie ? ;)

To zależy. Myślę, że w wielu sytuacjach jest dokładnie tak jak mówisz i ludzie piszą coś naokoło, bo nie wiedzą, że coś się da frameworku prościej.

Z drugiej strony jest wiele sytuacji, kiedy faktycznie dane narzędzie jest ograniczone i ludzie piszą coś swojego lepiej, własny framework, tool (czasem robią coś całkowicie od zera, czasem robią forka i tylko lekko przerabiają istniejące rozwiązanie, a czasem robią to na zasadzie dodatku/pluginu zachowując kompatybilność).

Szczególnie we frontendzie tak jest, że ciągle ktoś robi własny framework/bibliotekę/narzędzie, które jest podobne, ale inne, i potem to rozwiązanie zastępuje rozwiązanie wcześniejsze, np.
Tracer --> Babel
Flux --> Redux
Browserify --> Webpack
AngularJS --> React --> ???
Mootools --> jQuery
Atom --> VSCode
JavaScript --> TypeScript (mam nadzieję, że całkiem nie zastąpi, bo sam jestem zwolennikiem JSa, ale widzę taki trend, że ludzie zamiast pisać w JS wolą pisać w TS).

Myślę, że podejście "ja wiem lepiej" może być bardzo pozytywne, bo dzięki temu rodzą się innowacje (które nie zawsze są dobre - wiele z innowacji frontendowych skończyło na śmietniku historii - tym niemniej lepiej eksperymentować nawet jeśli wiele z tego nadaje się do wyrzucenia niż nie eksperymentować w ogóle i trzymać się kurczowo istniejących rozwiązań).

Zgadzam się w 100% z tą opinią Wujka Boba. Nie trzeba (i nie da się) umieć wszystkiego, ale trzeba profesjonalnie podchodzić do swojej pracy.
Nie przeszkadza mi też, że się ktoś nie doucza po godzinach pod warunkiem, że dobrze wykonuje swoje bieżące obowiązki. Jak sobie z nimi wyraźnie nie radzi, to powinien się doszkolić po pracy. Lepsze to, niż wylanie kogoś z pracy ;). Natomiast jeśli mamy sytuację, że mam zrobić coś czego nigdy nie robiłem, bo wymaga tego projekt bądź bieżące zadanie, to risercz robię w ramach swojej pracy i otwarcie o tym mówię. Mogę sobie napisać jakieś proof of concepty, poczytać dokumentację, porobić testy eksploracyjne, jest to odnotowane w ramach zadania na dżirze i po sprawie.

wiciu napisał(a):

Zgadzam się w 100% z tą opinią Wujka Boba. Nie trzeba (i nie da się) umieć wszystkiego, ale trzeba profesjonalnie podchodzić do swojej pracy.
Nie przeszkadza mi też, że się ktoś nie doucza po godzinach pod warunkiem, że dobrze wykonuje swoje bieżące obowiązki. Jak sobie z nimi wyraźnie nie radzi, to powinien się doszkolić po pracy. Lepsze to, niż wylanie kogoś z pracy ;). Natomiast jeśli mamy sytuację, że mam zrobić coś czego nigdy nie robiłem, bo wymaga tego projekt bądź bieżące zadanie, to risercz robię w ramach swojej pracy i otwarcie o tym mówię. Mogę sobie napisać jakieś proof of concepty, poczytać dokumentację, porobić testy eksploracyjne, jest to odnotowane w ramach zadania na dżirze i po sprawie.

Tak jak to przedstawiles to nie sposob sie nie zgodzic.
Ale jak widac Ty w swojej pracy masz przestrzen do tego. Co jest dobre.