Rynek pracy .NET w 2025 roku

dev123 napisał(a):

Teraz jest mniej takich ofert niż kiedyś, faktycznie. Ale nie masz gwarancji, że rekrutując się do zespołu X, faktycznie tam trafisz. Zanim zaczniesz pracę tam może minąć 2 miesiące, jeśli masz miesiąc wypowiedzienia a rekrutujesz się na początku miesiąca. Do tego może im się nie chcieć wystawiać 2 ogłoszeń jeśli szukają do 2 projektów. Wystawią jedno ogłoszenie na ten lepszy projekt, a te drugą osobę, którą przyjmią, rzucą do tego drugiego projektu.

No ok, w dużym SH można trafić do innego projektu niż się człowiek rekrutował.
Ale skąd oni nagle wytrzasną ten projekt sprzed 2 dekad, to nie wiem. :P Teraz ciężko o cokolwiek w klasycznym frameworku, nawet WCFa, bo już chyba wszystko zostało przepisane na core.

Ale to przy założeniu, że jesteś rekrutowany w celu naprawienia tego bagna. Na ogół w starym systemie trzeba równolegle obsługiwać zgłoszenia i dorzucać drobne rzeczy, a na większe zmiany trzeba mieć zgodę kogoś wyżej, bo za to, żeby developer zrobił refactor wielkiego systemu, ktoś musi zapłacić. Jeśli chodzi o takie refactory drobne przy okazji naprawiania bugów/dorzucana nowych ficzerów, to raczej średnio to wychodzi, bo łatwo coś zepsuć, nikt tego nie doceni, a do tego ktoś jeszcze może mieć pretensje, czemu przy okazji naprawiania buga został wprowadzony bug w innym miejscu.

Jeśli uznaję, że naprawa buga wymaga poprawienia czegoś, to to robię. Płacą mi przecież i tak.
To, że nikt nie doceni, nie jest ważne - następnym razem ja będę miał mniej roboty.

No wezmy jQuery vs Angular/React. Te drugie dają możliwość separacji stanu od warstwy prezentacji i podziału UI na komponenty. Te rzeczy są konieczne w jakimkolwiek projekcie z choć trochę bardziej złożonym UI. Owszem, można to też osiągnąć w jQuery, ale kto tak robi i ile kodu więcej na to potrzeba?

Ja mówię o dotnecie, jeśli frontendowcy mają problemy ze swoimi frameworkami to niech zrobią to, co zawsze - następny framework.

Zasady pisania się nie zmieniły przez 20 lat, i tak jak wielu ludzie nie stosowało ich 20 lat temu, tak nie stosują teraz.

somekind napisał(a):

Ale skąd oni nagle wytrzasną ten projekt sprzed 2 dekad, to nie wiem. :P Teraz ciężko o cokolwiek w klasycznym frameworku, nawet WCFa, bo już chyba wszystko zostało przepisane na core.

W dużych kontraktorniach/SH co miesiąc ktoś rzuca papierami. Przyczyna to na ogół albo pieniądze, albo beznadziejny projekt. Do tych beznadziejnych projektów trzeba kogoś znaleźć. Piszę z mojej perspektywy. 20-letni desktop przytrafił mi się dwukrotnie, pomimo zupełnie innych zapewnień na rekrutacji. Może to ja miałem pecha i wszyscy inni dostają projekty w .NET Core - tego nie wiem.

Jeśli uznaję, że naprawa buga wymaga poprawienia czegoś, to to robię. Płacą mi przecież i tak.

A jeśli bug jest w procedurze SQL na 1k linii? Przepisanie jej na C#, z dorobieniem dokładnych testów, zajmie jakiś miesiąc.

Ja mówię o dotnecie, jeśli frontendowcy mają problemy ze swoimi frameworkami to niech zrobią to, co zawsze - następny framework.

Moja teza jest taka, że jeśli technologia ułatwia robienie rzeczy uznawanych za dobre, to jest większa szansa, że ludzie te rzeczy będą robić, a co za tym idzie jakość projektu będzie statystycznie lepsza w nowej technologii. A nawet jeśli będzie słaba, to będzie łatwiej ten projekt naprawiać. Skoro WinFormsy były takie fajne, to dlaczego MS zrobił WPFa? Dalej, skoro WPF był taki fajny, to po co MS zrobił Blazor Hybrid?

dev123 napisał(a):

W dużych kontraktorniach/SH co miesiąc ktoś rzuca papierami. Przyczyna to na ogół albo pieniądze, albo beznadziejny projekt. Do tych beznadziejnych projektów trzeba kogoś znaleźć. Piszę z mojej perspektywy. 20-letni desktop przytrafił mi się dwukrotnie, pomimo zupełnie innych zapewnień na rekrutacji.

To chyba w takim razie duży argument przeciwko dużym SH, nieprawdaż?

A jeśli bug jest w procedurze SQL na 1k linii? Przepisanie jej na C#, z dorobieniem dokładnych testów, zajmie jakiś miesiąc.

Jeśli bug jest w procedurze SQL, to go naprawię.
Ale jeśli w ciągu dwóch tygodni w tej samej procedurze znajdzie się 5 błędów, to będzie już dobry powód, zarówno techniczny jak i biznesowy, żeby coś z tym zrobić.

Moja teza jest taka, że jeśli technologia ułatwia robienie rzeczy uznawanych za dobre, to jest większa szansa, że ludzie te rzeczy będą robić, a co za tym idzie jakość projektu będzie statystycznie lepsza w nowej technologii. A nawet jeśli będzie słaba, to będzie łatwiej ten projekt naprawiać.

No, taka teoria. W praktyce, gdy niektórym ludziom jest zbyt łatwo w czymś tworzyć, to zawsze znajdą sposób, żeby sobie utrudnić. Dlatego nie wiązałbym jakości z technologią, ale z ludźmi.
Czy łatwiej naprawiać w nowszych technologiach? Też niekoniecznie, dobrego spaghetti nie da się w ogóle naprawić, niezależnie od technologii.

Skoro WinFormsy były takie fajne, to dlaczego MS zrobił WPFa?

WPF powstał po to, aby ułatwić tworzenie zaawansowanego GUI, a nie po to, aby jakość kodu wzrosła. Wokół WPFa powstała przecież masa frameworków ułatwiających oddzielenie prezentacji od logiki, bo sam WPF niezbyt sobie z tym radził.