Poszukiwanie pracy w nowych projektach / startupach

Cześć,

Ostatno dosc aktywnie poszukuję nowej pracy. Interesuje mnie przede wszystkim praca w fajnym i nowym projekcie, najlepiej w firmie mającej swój produkt, być może startupie. Mam wrażenie ze porejestrowałem sie na wieksozści popularnych portali - i w sumie to co widze to w większości utrzymanie albo zastąpienie odchodzacego developera itd. Nie dziwi mnie to - parę lat w tym siedzę i wiem jak to wygląda. To co obserwuję to na pewno znacznie mniejsza ilość nowych projektów np w .NET, a wieksza np. w Golang Node itp, stąd w tej chwili z perspektywy obecnego doświadczenia jestem nawet gotowy zmienić technologię za mniejsza kasę przez bewien czas, byleby trafić na coś nowego ;-)

Kojarzycie może jakieś portale lub inne miejsca z ofertami typowo nastawione na projekty świeże/ starytujące? Bo mam wrażenie że coś pomijam. Z takimi projektami jest o tyle problem że rzadko kiedy robi je firma do której możan uderzyć z ulicy itd.

Z mojego doświadczenia, to na takim JustJoinIt jest spoko - 50% ofert z fintechów/banków a drugie 50% właśnie ze startupów (bądź firm < 100 osób). Jest też amerykańska stronka https://angel.co/remote

A co to jest nowy projekt: taki co ma miesiąc, rok, 2 lata? To może zacznij swój projekt robić.

@S4t: Najlepiej taki który dopiero startuje ;-)

Swój projekt można zaczynać ale to coś innego - to może byc co najwyżej pet-project, a mi chodzi o coś co ma sens dla klienta :-D Poza tym projekt sam się nie finansuje a work-life balance to coś co sobie cenie na tyle że 16h pracy dziennie to trochę za dużo ;-)

@W2K: Ludzie nie zaczynają projektów z przypadkowymi osobami z internetu. Spróbuj się wkręcić w jakiś środowisko startupowe. Ale w takie projekty cierpią na ciągły niedobór kasy. A projekt bardzo szybko robi się "stary" i tak samo upierdliwy, jak inne.

Nie pojmuję tego strachu przed projektami "starymi".
Wiadomo, że w nowym projekcie łatwiej się powymądrzać i narzucić swoją koncepcję oraz technologię ale to nie prowadzi do prawdziwego rozwoju. Co najwyżej zakończy się to odkrywaniem koła na nowo.
Pracując w dojrzałym projekcie można poznać techniki, tricki i metody na rozwiązywanie zagadnień, których w nowym możesz nie uświadczyć. Także świadomość tego, że w projekcie był przed nami ktoś bardziej doświadczony powinna motywować a nie odstraszać.
W projekcie już istniejącym mamy większą stabilność zatrudnienia, możliwość wyspecjalizowania się w jakiejś konkretnej branży, nauczenia się szerszego spojrzenia na architekturę działającego już systemu.
W nowym to niemal zawsze będzie jakaś improwizacja, która zakończy się koniecznością napisania wersji 2 po tym jak system zderzy się z rzeczywistością... o ile temat nie zostanie zakończony z powodu braku środków na dalszy rozwój.

@katakrowa: strasznie idealizujesz stare projekty. Niechęć do nich to nie musi być strach, jedynie zmęczenie projektami tego typu. W starszych projektach dyskusje o kształcie i kierunkach technologicznych masz już za sobą, musisz niestety mierzyć się z czyimiś decyzjami i świecić oczami za coś, na co nigdy nie miałeś wpływu.

Zdecydowana większość wygrzanych projektów przy których siedziałem była napisana kilka ładnych lat temu przez ludzi, którzy nie do końca rozumieli co robią, a same projekty są obarczone dużym długiem technologicznym. Architektura też nie była niczym ciekawym i zbudowana była raczej na antywzorcach, z których wiele nie wyciągniesz (synchronizacja przez bazę danych, procedury bazodanowe bo akurat specjalista od PL/SQLa był wolny, jakieś własne implementacje kolejek itp. itd.). Oczywiście wiem, że gdzieś tam są duże projekty napisane przez mądrych ludzi, z których można wiele się nauczyć - ale jakoś nie mogę na nie trafić. Zgodzę się natomiast z tym, że pisząc w takim starym bajzlu można szybko nauczyć się biznesu - bo w takich projektach ścieżka pomiędzy zespołem developerskim, a użytkownikami biznesowymi jest bardzo krótka.

Przy czym od razu dodam, że w większości pracowałem przy właśnie starszych projektach.

@wartek01: Ocenianie "starych projektów" z pozycji obecnej sytuacji jest bez sensu, gdyż nie wiesz, dlaczego coś zostało zaimplementowane tak czy inaczej. Coś, co teraz jest antypaternem kiedyś nić nie było. Implementacji własnej kolejki może być wymuszona brakiem wsparcie dla innej technologi itp itd. Stare projekty są stare, bo zarabiają na siebie. Te nowego nigdy mogą nie stać się stare.

wartek01 napisał(a):

@katakrowa: strasznie idealizujesz stare projekty. Niechęć do nich to nie musi być strach, jedynie zmęczenie projektami tego typu. W starszych projektach dyskusje o kształcie i kierunkach technologicznych masz już za sobą, musisz niestety mierzyć się z czyimiś decyzjami i świecić oczami za coś, na co nigdy nie miałeś wpływu.>

Projekty się rozwijają i wówczas dyskusje są jeszcze ciekawsze niż te na początku. Zwykle wymaga to specjalistycznej wiedzy ale to tylko dodaje pikanterii.

Zdecydowana większość wygrzanych projektów przy których siedziałem była napisana kilka ładnych lat temu przez ludzi, którzy nie do końca rozumieli co robią, a same projekty są obarczone dużym długiem technologicznym.
Architektura też nie była niczym ciekawym i zbudowana była raczej na antywzorcach, z których wiele nie wyciągniesz (synchronizacja przez bazę danych, procedury bazodanowe bo akurat specjalista od PL/SQLa był wolny, jakieś własne implementacje kolejek itp. itd.). Oczywiście wiem, że gdzieś tam są duże projekty napisane przez mądrych ludzi, z których można wiele się nauczyć - ale jakoś nie mogę na nie trafić.

No to miałeś pecha. A kto ma pecha ten ma pecha :-)

Zgodzę się natomiast z tym, że pisząc w takim starym bajzlu można szybko nauczyć się biznesu - bo w takich projektach ścieżka pomiędzy zespołem developerskim, a użytkownikami biznesowymi jest bardzo krótka.

Można też pisać w starym solidnie napisanym. Nie każdy stary projekt to bajzel (choć tu ryzyko jest spore). Z drugiej strony każdy nowy też będzie kiedyś takim "bajzlem" a najprawdopodobniej Ty jako rozpoczynający pisanie będziesz jego przyczyną :-) W przyszłości Ciebie nazwą człowiekiem, który nie do końca wiedział co robi (ludzi, którzy nie do końca rozumieli co robią).
Na początku nie wiemy jak projekt się rozwinie i nie ma takiego mądrego co wszystko by ogarnął i przewidział.

@S4t: i tak, i nie. Jeśli widzę w starym projekcie lombokowe combo @Data w encji Hibernate to będę oceniać, mogę oceniać i powinienem oceniać. To z np. procedurami bazodanowymi też wiem z pierwszej ręki - przeniesiono część logiki do bazy danych bo akurat programista PL/SQL nie miał nic do roboty.

Zgadzam się z tym, że świat nie jest czarno-biały, ale nawet w takim świecie zdarzają się rzeczy, które są tylko czarne lub białe.

@katakrowa:

A kto ma pecha ten ma pecha

No i dlatego mam pewną niechęć do takowych projektów. Nie żebym ich unikał (bo to pewnie połowa rynku), ale niechęć jest. I do tego sprowadza się dyskusja - ty być może nie miałeś złych przejść, natomiast u większości moich znajomych "legacy project" to synonim złego kodu.

W przyszłości Ciebie nazwą człowiekiem, który nie do końca wiedział co robi (ludzi, którzy nie do końca rozumieli co robią).

Podałem przykład w odpowiedzi do @S4t. Jak będę leżał na łożu śmierci to nikt mi nie wytknie, że napisałem encję hibernate'ową z wygenerowanym przez Lomboka hashCodem :)

Przez 5 lat w branży mogę powiedzieć, że nowe projekty są obarczone dużym ryzykiem niewypału. Mi się zdarzyło przez 5 lat, wze 4 razy mi projekt nie wypalił. To jest trochę takie ryzyko, w sensie, że jest fajnie, greenfield i tak dalej, a druga sprawa że nagle klient może powiedzieć "tyle" co się bardzo często zdarza. Dodatkowo często w takich projektach są "nadgodziny".

Z drugiej strony masz na rynku fajne projekty bankowe, mocno "wygrzane" gdzie można spokojnie pracować do 70 roku życia w EJB oglądając kreskówki i nie szarpiąc się zbytnio z życiem. Jak to ktoś kiedyś powiedział, życie to sztuka wyborów i kalkulacji. Każdy dostosowywuje wszystko pod siebie.

W2K napisał(a):

Interesuje mnie przede wszystkim praca w fajnym i nowym projekcie, najlepiej w firmie mającej swój produkt, być może startupie.

Oj, trochę wygórowane wymagania, ale powodzenia :)

kevin_sam_w_domu napisał(a):

Przez 5 lat w branży mogę powiedzieć, że nowe projekty są obarczone dużym ryzykiem niewypału. Mi się zdarzyło przez 5 lat, wze 4 razy mi projekt nie wypalił

I we wszystkich tych projektach był @kevin_sam_w_domu, Przypadek? Nie sądzę :)

S4t napisał(a):

@wartek01: Ocenianie "starych projektów" z pozycji obecnej sytuacji jest bez sensu, gdyż nie wiesz, dlaczego coś zostało zaimplementowane tak czy inaczej. Coś, co teraz jest antypaternem kiedyś nić nie było. Implementacji własnej kolejki może być wymuszona brakiem wsparcie dla innej technologi itp itd. Stare projekty są stare, bo zarabiają na siebie. Te nowego nigdy mogą nie stać się stare.

Z jednej strony czasem tak bywa, z drugiej strony zawsze można tak powiedzieć „nie wiesz, dlaczego ktoś tak zrobił”. Mnie się wydaje, ze jest raczej tak:

• programiści piszący słaby kod maja po prostu za słabe umiejętności techniczne do napisania danego projektu. Przy czym zdarzało mi się pracować z programistami, których mógłbym ocenić jako dobrych programistów ogólnie, ale którzy stawiając podwaliny dużego projektu, po prostu sobie nie poradzili z tym wyzwaniem

• Projekty pisane w ileś osób łatwo się rozjeżdżają(a im dłuższy projekt tym więcej osób się przewija, wiec każdy były pracownik dodaje swoje spaghetti)

• niejasne i zmieniające się wymagania dobrze wyglądają w manifeście agile, ale w praktyce ciężko jest pisać w ten sposób i projekty stają się jedna wielka łataniną i widac na nich ślady poprzednich wymagan. Co prawda nie wiem, jak można to rozwiązać(waterfall tez chyba nie jest rozwiązaniem).

Dziękuję (prawie) wszystkim za dyskusję związaną z tematem i wnosząca coś do mojego pytania.

wartek01 napisał(a):

@S4t: i tak, i nie. Jeśli widzę w starym projekcie lombokowe combo @Data w encji Hibernate to będę oceniać, mogę oceniać i powinienem oceniać. To z np. procedurami bazodanowymi też wiem z pierwszej ręki - przeniesiono część logiki do bazy danych bo akurat programista PL/SQL nie miał nic do roboty.

Zgadzam się z tym, że świat nie jest czarno-biały, ale nawet w takim świecie zdarzają się rzeczy, które są tylko czarne lub białe.

A adnotacjach się nie wypowiem, bo w Javie to ostatni raz pisałem z 10 lat temu a z tym, że "akurat programista Pl/SQL był wolny" to po prostu jest anegdota firmowa. Pełno takich w każdej większej firmie.

S4t napisał(a):

akurat programista Pl/SQL był wolny

Nie wiem, dlaczego to ma być gorsza przyczyna niż, że ktoś chciał wpisu do CV z nastym w jednej firmie i w bieżącym roku językiem implementacji mikroserwisu. ;)

Może to troche mało mądre co powiem ale żeby pisać "nowe projekty" tj. od zera warto poznać nowe technologie i wyprzedzać "epokę" w takim sensie że w danych technologiach nie ma wiele softu bo nikt nie zdążył ich zaklepać...

Przykład:
Jak masz np.: branża - e-commerce i stack typu: Python, Django, Jenkins - to sporo softu jest zaklepane w oparciu o te technolgoie wiec prawdopodobienstwo ze w tych technologiach projekt bedzie lekko "starszawy" jest bardzo wysokie

Jak będziesz kombinował z np. w działce np. Security/ML i uderzysz w Pythona, FastAPI, k8s, gitlab-ci itp itd to jest bardzo duża szanse że jednak albo coś nowego to będzie lub w ostateczności jakis refaktor/przepisanie/integracja z Django -> FastAPI lub cos podobnego ale można uczestniczycz w tym i sie duzo nauczyc i obserwowac na zasadzie porownania "stare" i "nowe" co też jest spoko doswiadczeniem. Tak wiem jest ryzyko że ktoś przepisuja i robi sztuke dla sztuki albo projekt jest tak kiepski ze strach go ruszyc - no ale wciaż na zasadzie prawdopobienstwa jest lepiej ;)

Nie znam swiata C# wiec tutaj nic nie "podpowiem". No ale fakt Python ma taka specyfike ze projkty w nim sa male/srednie w C# bedzie na odwrot ;)

wartek01 napisał(a):

@katakrowa: strasznie idealizujesz stare projekty. Niechęć do nich to nie musi być strach, jedynie zmęczenie projektami tego typu. W starszych projektach dyskusje o kształcie i kierunkach technologicznych masz już za sobą, musisz niestety mierzyć się z czyimiś decyzjami i świecić oczami za coś, na co nigdy nie miałeś wpływu.

W nowych projektach też często dyskusje o kształcie i kierunkach technologicznych masz już za sobą. Bo w korpo mogą zajść następujące sytuacje :

• Jest grupa architektów (grupa trzymające władzę), która decyduje w jakiej technologi ma być napisany jaki projekt
• Nie ma grupy architektów, ale grupa managerów żąda żeby wszystkie projekty były pisane w tej samej technologii, bo inaczej nie znajdą programistów do utrzymania tego projektu

Wniosek z tego taki że większość korpo odpada i zostają tylko startupy, i to nie starcze niż dwa lata, bo po dwóch latach projekt staje się stary i archetektura oraz technologia jest już wybrana :(