Zmiany technologii vs trzymanie się jednego stacka

2

Pytanie skierowane przede wszystkim do ludzi, którzy odsiedzieli już swoje przed monitorem i zdążyli już swoją filozofię życiową zweryfikować ;) Pewnych spraw nie rozumiem, a przynajmniej wydaje mi się, że widzę pewien jakby konflikt interesów.

Co na dłuższą metę jest korzystniejsze dla programisty, jeśli chodzi o całokształt (rozwój osobisty, zawodowy, unikanie wypalenia, nudy, poszerzanie horyzontów itd) - trzymanie się w miarę możliwości jednego stacka lub przynajmniej "ekosystemu" danego języka/języków, czy mniejsza lub większa zmiana co np. rok / trzy / pięć / siedem?

  • Z jednej strony zmiana to zawsze jakiś powiew świeżości w zatęchłej piwnicy, człowiek się dowie czegoś nowego, zobaczy że w języku X rozwiązuje kwestię A lepiej niż język Y, ale z kolei B i C są w nim irytujące, no ale za to wsparcie dla D ma zupełnie jak język Z. No i jak już tych X, Y, Z się nazbiera, to poznanie kolejnej "literki" sprowadza się do zrobienia w głowie diffa z tym, co się już zna, zamiast uczyć się połowy od nowa... ale z drugiej strony, jak to pogodzić z rozwojem zawodowym, skoro w ogłoszeniach często gęsto wymaga się doświadczenia w konkretnej technologii/frameworku, częściej niż doświadczenia ogólnie jako np. backend developer?

  • Z drugiej strony - niby technologie to tylko narzędzia pracy, a człowiek jak już pozna kilka na w miarę przyzwoitym poziomie, to do kolejnego jest w stanie błyskawicznie się wdrożyć zamiast żmudnie przebijać się przez tutoriale jak na pierwszym roku studiów, a jednak często gęsto wymagana jest znajomość konkretnego poparta kilkuletnim doświadczeniem. Nawet, jeśli firma i tak będzie Cię potem przerzucać między projektami w zależności od potrzeb, a nie od tego w czym są robione. Tak naprawdę można sobie nawet radośnie utknąć na poziomie wiecznego stażysty, bo niby doświadczenie leci, ale projekty się zmieniają, każdy robiony w czym innym... i niby masz już przepracowane ten rok, półtora czy nawet więcej, efekt gromadzenia literek działa i jak wrzucą Cię z tygodnia na tydzień do nowego projektu w nowych technologiach to nie jest to problemem, ale jak przyjdzie co do czego to... no, pani z HR dostała jasne wymogi, Pan to to nawet na juniora nie spełnia.

Co tu robić, jak żyć? Jest jakiś złoty środek?

0

Zależy od sytuacji. Z doświadczenia: trzymam się php i laravela a z drugiej strony w js migruje co chwila na coś innego i jest to normalne.

0

Ja tam rozdzielam swój warsztat na

  1. stack, który mnie utrzymuje

  2. stacki, które lubie bardziej na dzień dzisiejszy i są ciekawsze.

  3. nadrabiam na bieżąco, nowinki z języka, biblioteki, frameworki i 'in depth knowledge'.

  4. to oderwanie od rzeczywistości i poszerzanie horyzontów, bez spiny, bez wgryzania się w szczegóły jeśli mnie to nie ciekawi.

Jeśli chodzi o karierę, Jestem zdania, że zbytnia generalizacja jest zła.
Wolę dobrać po jednym rozwiązaniu z FE, BE, DevOps I umieć je po prostu dobrze, tak żeby móc coś zrobić całościowo. Co prawda, jeszcze nie do końca mi to wychodzi tak jak bym chciał, ale nadrabiam.

Plan na nowy rok, połączyć 1) z 2)

3

Trzymanie się kurczowo jednego stacka jest złe. Programista powinien ogarniać przynajmniej podstawy kilku technologii. Smuci mnie, że wielu programistów nie wie co to są funkcje lambda, programowanie asynchroniczne, strumienie albo BLoC itd.

0

Hej,
niby doświadczenia komercyjnego nie mam, ale moje doświadczenie w kodowaniu małe nie jest. Myślę, że warto trzymać się jakiegoś forum (to jest naprawdę niezłe) i przyglądać się występującym trendom. Oprócz głównego nurtu programowania pojawiają się różne Trendy (mniejsze lub większe), i warto przyglądać się jak się rozwijają. Jednym (bardzo ważnym) Nurtem są pojawiające się jak grzyby po deszczu Technologie Big Data i technologie z tym związane (Amazon, Google Platform, Azure, Cloudera, w R też można się dobrać do Sparka na przykład, Tensor Flow: ciekawa, nieznana mi sprawa jeszcze). Drugim nurtem są pojawiające się języki, które mogą w przyszłości być ważne: Scala, Kotlin, Rust, być może Swift, więc warto trzymać rękę na pulsie :)

0

A czy można się już utrzymać pisząc tylko w jednym z tych nowoczesnych języków programowania jak Kotlin, Swift, Rust, Scala?

1

Można. Najsłabiej na ten moment stoi Rust ale może się to zmieni.

2

Jak dla mnie to warto liznąć wszystkiego, chociaż niekoniecznie zajmować się na codzień wszystkim, bo specjalizacja się opłaca - pytanie też jaka specjalizacja.

Czy specjalizacja pod kątem języka programowania, czy pod kątem dziedziny biznesu, czy pod kątem frameworka (niby frameworki ciągle się zmieniają, ale z drugiej strony dużo frameworków jest modne co najmniej kilka lat, więc można się specjalizować np. w React... do czasu, kiedy przestanie być modny), czy specjalizacja pod kątem rodzajów aplikacji (mobilki, gry, sklepy internetowe, CRM itp.).

Specjalizacja pozwala na to, żeby programowanie stało się łatwe - bo jeśli robiłeś coś kilkadziesiąt czy kilkaset razy to potem kolejny raz przyjdzie łatwiej. I masz też o wiele większą wiedzę od osoby, która dopiero wchodzi w temat.

Z drugiej strony zbytnia specjalizacja kończy się krótkowzrocznością i zacofaniem, bo człowiek zamiast myśleć szeroko i się edukować w zakresie szerokopojętego programowania, to myśli tylko w ciasnych rameczkach. I potem proste problemy rozwiązuje w skomplikowany sposób, bo nie jest w stanie wyjść poza ramki. Trochę jakby był dwuwymiarową postacią w świecie 3D i nie potrafiłby pojąć tego, że istnieje trzeci wymiar.

Tak więc myślę, że jednak dla własnego rozwoju należy czasem wychodzić poza specjalizację, nawet jeśli przez większość czasu się w niej siedzi.

0

Bardzo mi się podobają te trzy języki Rust, Swift i Kotlin. Ciekawe dlaczego gry nie przechodzą jeszcze na Rust, czy w ogóle ktoś już pisze w nim jakiś silnik graficzny, bibliotekę GUI?

2

Bo jak ludzie pisali w C, to gamdev dalej stał na assemblerze

0

@Trzeźwy Pies:
http://arewegameyet.com/#eco
http://arewegameyet.com/#games

Co z ciebie za programista rusta, społeczeństwo jakoś radzi sobie.

0

Wesoły żulu miałem namyśli jakieś poważne zajawki na porządny silnik graficzny, a nie takie popierdółki. Liczyłem na coś co w przyszłości może być konkurencją dla Unity, Unreal, CryEngine.
Wchodzę w kod tych gier i wyskakuje mi ciągle różowa głowa jednorożca..
https ://github.com/ucarion/gaia/tree/master/assetgen

0

Biały Jeleniu,

Silnik jest efektem ubocznym tworzenia gier, to taka gra w grze.
Powtarzasz ciągle te same czynności, aż je wyodrębnisz i w pewnym stopniu zautomatyzujesz.

Reszta to GUI żeby laiki myślały, że to poważny silnik gier.

0
Trzeźwy Pies napisał(a):

Bardzo mi się podobają te trzy języki Rust, Swift i Kotlin. Ciekawe dlaczego gry nie przechodzą jeszcze na Rust, czy w ogóle ktoś już pisze w nim jakiś silnik graficzny, bibliotekę GUI?

Podejrzewam, że dopóki w grę (nomen omen) nie wchodzą jakieś mikrotransakcje, o które gracze mogli by się już wypluć gdyby coś poszło nie tak (albo firma stracić gdyby dało się jakimś śmiesznym hackiem omijać zakup), to gamedev jest w stanie przymknąć oko na jakieś małe wyścigi itd w imię dodatkowych paru klatek czy szybszej odpowiedzi serwera gry dzięki wywaleniu synchronizacji czy locków tu i tam. A to się chyba troszeczkę gryzie z filozofią Rusta ;)

A sądząc po różnych dziwnych bugach i glitchach, które nieraz można znaleźć w grach, nie byłoby nic dziwnego gdyby gamedev naprawdę podążał za tą filozofią. Gracz i tak nie zauważy większości z nich, dopóki go przez któryś z nich tyłek nie zapiecze.

0

A Swift jest wystarczająco szybki, aby powstał w nim silnik graficzny? Na youtube znawcy gadają, że to najbardziej nowoczesny i najlepiej przemyślany język programowania na 2018 rok. Jest nawet filmik jak na konferencji Swift wyśmiewany jest język Kotlin i wytykane są jego wady.

1 użytkowników online, w tym zalogowanych: 0, gości: 1