Doświadczenie w korpo projektach

0

Tak się ostatnio zastanawiałem ile jest warte doświadczenie w projektach, w których siedzi się kilka lat i więcej. Np. w takiej javie większość projektów to opasłe korpo utrzymania. W tych projektach stos technologiczny nie jest najnowszy a czasami wręcz stary. Nawet jak jest jakaś migracja na nową wersję javy to większość kodu i tak jest napisana w starych wersjach. Dodatkowo jak nie było np. Angulara to już go prawdopodobnie nigdy nie będzie.
Wiadomo można się rozwijać i poznawać nowości po pracy ale nie każdy ma na to dużo czasu lub chęci. Osoba, która na co dzień w projekcie ma nowości i siedzi w pracy po 8h prawdopodobnie będzie w nich lepsza od kogoś kto spędza po pracy np. 1h dłubiąc sobie coś na boku.
Jak później taka osoba ma zostać oceniona na rozmowie w przypadku zmiany pracy? Czy z seniora nagle nie zostanie mediumem a z mediuma juniorem w oczach nowego pracodawcy bo na rozmowie technicznej nie znał odp. z nowych technologii wykorzystywanych u tego pracodawcy?
Z drugiej strony technologie i tak się zmieniają a ogólne zasady dobrego kodowania, logicznego myślenia, projektowania są od tych technologii niezależne. Technologia to i tak tylko narzędzie. A osoba obyta nawet ze starszymi technologiami powinna sobie w jakimś rozsądnym okresie czasu poradzić i się wdrożyć. Pytanie na ile pracodawcy dadzą możliwość i czas poznania tych innych narzędzi/technologii.
Co o tym myślicie?

0

Nie jestem pewny czy chciałbym pracować w firmie gdzie na rozmowie pytają o technologie których używają. Poza tym, imho to nie technologie są ważne, a wyzwania techniczne z jakimi się mierzysz. Jak nie ma wyzwań to bym uciekał. Zresztą, jeżeli firma korzysta ze starych technologii to prawdopodobnie jest z nią coś nie tak i też bym uciekał. :D

0

Nie każda projekt Javowy to "korpo technologia". U mnie co drugi projekt był w korpo i poprawiałem starocie a reszta to "stard-upy" i pisanie nowych rzeczy. Ale moje doświadczenie jest takie, że im starsza technologia javowa tym więcej płacą, bo nikt nie chce w tym robić.
A na rozmowach rekrutacyjnych i tak najszczęściej pytają o podstawy, "nowości" Javy 8 i Springa.

1

Pracowałem zarówno w korpo, jak i firmach, gdzie projekty były pisane od zera w najnowszych na dany moment technologiach. W jednym i drugim miejscu można się sporo nauczyć. IMO, dobry programista powinien umieć się odnaleźć w każdych warunkach i dostosować do sytuacji. Co za różnica, czy będziesz musiał się nauczyć jakichś super-nowych technologii do nowego projektu, czy opanować jakieś wewnętrzne technologie korpo, których nikt poza tym korpo nie zna? Jedna i druga sytuacja wymaga od Ciebie umiejętności uczenia się i wdrożenia w projekt. W takim korpo może być nawet trochę trudniej, bo części rozwiązań nie wygooglasz jak w przypadku jakichś znanych frameworków itp. Jak pójdziesz do nowej firmy, gdzie używają czego innego, to się tego możesz nauczyć. Dodatkowo, w takich firmach często jest pole do usprawnień, refaktoringu, czas na pisanie porządnych testów itd.

3

Osoba, która siedzi 8 godz. z "nowościami" spotyka się też z takimi sytuacjami:

  • Ten framework nie współpracuje z X
  • Wsparcie dla Y przewidujemy za 2 lata
  • Google: podana fraza "twój mega skomplikowany problem w technologii X" nie została odnaleziona
  • Backup? Po co ci backup naszej bazy? Nasza baza nigdy nie ulegnie awarii!
  • O, jest forum gdzie też mają ten błąd co ja! wait... jest po chińsku
  • Blokowanie danych podczas modyfikacji? Tak, słyszeliśmy coś o sekcji krytycznej, ale od 5 lat nie mieliśmy czasu tego zaimplementować w naszym magicznym systemie Y. ... Naprawdę jest to problem znany od lat 60-tych XXw? NIEMOŻLIWE!

itd.
Pęd za nowością jest czymś czego do końca nie rozumiem. Ciągłe taplanie się w niedojrzałym środowisku, w którym mnóstwo rzeczy trzeba dorabiać samemu albo tworzyć jakieś protezy. Nie jest to efektywne i właściwie nie wiadomo czemu ma służyć, chyba tylko samozadowoleniu dewelopera.
Wiadomo, że język taki czy inny czy jakieś środowisko ma swoje ograniczenia i czasem trzeba je zmienić, żeby pójść do przodu. Ale stabilność środowiska, w którym tworzysz aplikację ma nieocenione zalety, których nie napotkasz w dziesiątym w tym roku frameworku, rozwijanym przez 3 osoby w czasie wolnym.

2

Jeżeli projekt trwa kilka lat i cały czas jest rozwijany, to jest duża szansa, że jest skomplikowany/złożony. Jeżeli ktoś siedział w nim od jego początku, to pewnie napotkał 10 razy więcej różnych, nawet "egzotycznych" problemów, przez co uzbierał dużo doświadczenia, którego nie załapiesz pisząc piąty pół roczny projekt ze zmianami typu vue na angulara, angulara na reacta itd.

Zresztą uważam, że kodzenie to zazwyczaj prostsza rzeczy niż wszystko to, co się dzieje wokół:

od wyciągnięcia od klienta wszystkiego co trzeba, dokumentacji, dogadania się, planowania, testowania, wdrożenia, zabezpieczenia, utrzymania itd.

0

Ja tylko dodam, że nie bardzo wiem skąd wy bierzecie te wszystkie "nowości". Nawet JS sie nie zmienia tak szybko jak niektórzy to przedstawiają. Większość firm którymi sie interesowalem od lat klepie w React i tyle, nikt nie zmienia frameworka co pol roku. Poza tym, nie chodzi o to, żeby korzystać z wszystkich nowinek jakie wychodzą, tylko jak już projekt jest w Javie to niech będzie co najmniej w tej ósemce, jak jest spring to niech będzie 4/5, bez klepania w xml itp. itd. Nie chodzi o to zeby ciągle zmieniać frameworki czy języki na inne, tylko żeby robić na bieżąco ugrade do najnowszej wersji. Myślałem, ze to standardowa praktyka, ale wygląda na to ze ludzie przesadzają w obie strony. :D

0

Wszystko zalezy od projektu. Nie kazde korpo jest z natury złe.

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