Ile tak naprawdę pracuje się przy nowych projektach, dużych featureach ?

0

Cześć,

W sumie to dopadła mnie skrajna demotywacja. Podczas ostatniej reorganizacji zostałem wrzucony do maintenance teamu przy aplikacji naszego klienta. W zasadzie po prezentacji jaka jest wizja pracy tego teamu pożegnałem cały entuzjazm który miałem zmieniając stosunkowo niedawno pracę. Słowem utrzymanie aplikacji, ciągła praca przy releasie (i odpowiedzialność za nie) , 0 nowych funkcjonalności (za to odpowiada inny team). Wcześnniej (zarówno w obecnej jak i w innych firmach) było to w miarę wyrównane, trochę naprawy śmierdzących bugów, ale też nowe fajne funkcje. Tutaj brak perspektyw na to. Prawdę mówiąc odchciało mi się bo o ile od czasu do czasu można porobić przy maintenance to pełen etat jest dla mnie nie do wyrtzymania. Aplikacja nie jest jakaś bardzo stara czy zapuszczona ale w sumie to czuję że ucieka mi to przez to cała satysfakcja z pracy. Zaraz po wyjściu ze spotkania w sumie pierwsze co zrobiłem to przeglądanie linkedina. Mam swój proejkt który robię po godzinach ale to nie to samo. Boje się że po prostu wypalę się dość szybo. Lubię tą robotę, ale wtedy gdy jest równowaga..

Moje pytanie do Was: Jaki czas tak naprawdę zajmuje Wam praca przy nowych featurach (nawet niekoniecznie w nowej świeżutkiej i pachnącej aplikacji) a ile to maintenance i naprawa bugów. Pytam bo zastanawiam się na ile moja demotywacja jest uzasadniona, a na ile to narzekanie.

.NET Backend, > 3.5lat doświadczenia.

10

Ja lubię bugi :-) To najlepiej zdefiniowane wymagania.
Najfajniejsze są heisenbugi produkcyjne typu: raz w miesiącu ktoś reportuje, że widzi dane z zeszłego roku i tak prezez 5 minut, a potem problem znika.
Albo, że klęka produkcja: 8 serwerów ma CPU na 10%, bazy danych nic nie robią, a z aplikacji prawie nie da się korzystać.

Bywa niefajnie, jak firma żyje w epoce infrastruktury lizanej i logi przeglądać trzeba notatnikiem(!), ściągając zipy z 30 serwerów, na każdym po 15 plików (miałem taki przypadek).

Żeby nie zapomnieć jak się robi ficzery - czasem zgłaszam się do nowych rzeczy - tak było w poprzednich firmach. Ale fakt, że aktualnie od pół roku siędze prawie tylko przy nowych projektach i ficzerach i odczuwam mocno brak grzebania w kupach produkcyjnych. Czuje, że się cofam.

0

Ja nie twierdzę że szukanie bugów to coś czego nie lubię. Też postrzegam to jako dobry sposób na samorozwoj. Tak naprawdę no SQLa nauczyłem się głównie przez takie szukanie heisenbugow. Nie uciekam przed tym. To co mnie martwi to perspektywa bycia zaszyfladkowanym tylko do takiej roboty bez perspektyw na coś nowego od czasu do czasu a w tej sytuacji dokładnie na to się zanosi.

2

W zasadzie Cie rozumiem, bo pamiętam takie obawy u siebie.
Z perspektywy czasu:
Bugi dużo uczą, ale jeśli są różnorodne.
Te niby nowe systemy i ficzery to często straszne kompromisy, bo musisz wpasować się w:

  • istniejącą architekturę,
  • ograniczenia współpracowników
  • kiepską wyobraźnię biznesu.
    Rypanie CRUDów w nieśmiertelnej architekturze dwa prostokąty i cylinder jest mało rozwijające.

architecture

Póty robisz coś na czyjeś zlecenie - to będzie to czasami nudne, biznes bywa nudny. W firmach gdzie pracowałem, zwykle to zgłaszałem i co jakiś czas (raz/dwa w roku na 1-2 miesiące) dostawałem ciekawy projekt na odskocznię (research). (W Polsce też). Czasem, te ciekawe projekty wcale nie były takie fajne :-)

Koncepcję teamu maintenance widziałem w dwóch firmach i była końcu ubita... - za dużo konfliktów to rodzi (wychodzi, że jest team naprawiaczy i psujów, przy czym z perspektywy każdego teamu psujami są ci drudzy). Przerabialiśmy to dzieląc się domenami /ficzerami.

Najbardziej polecam własne projekty, robione w eksperymentalnych technologiach i metodykach. Fajnie, jak Ci się uda kogoś dobrać do współpracy.

1

@jarekr000000, napisałeś

Bywa niefajnie, jak firma żyje w epoce infrastruktury lizanej i logi przeglądać trzeba notatnikiem(!), ściągając zipy z 30 serwerów, na każdym po 15 plików (miałem taki przypadek).

to jak wyglądają logi 21 wieku? Pytam, bo u mnie w firmie też przeglądamy logi- może nie notatnikiem, ale też edytorem.
Możesz napisać jak to można usprawnić?

1

To też zależy, co nazwiesz nowym ficzerem.

U mnie zdarza się, że grzebię w cholernie starym kodzie spaghetti, ale moim zadaniem jest go przepisać/usprawnić/etc. Więc mimo, że stary kod, to jednak nowy.
Teraz też wpadł mi task migracji z bowera do npm w jednym projekcie. Okazało się, że większość bibliotek była dość stara, więc jeszcze doszły do tasku upgrade'y. Też nie nowy ficzer w sumie, ale jednak coś sie dzieje.
Zdarzają się też bugi, ale często przy analizie buga można wpaść na jakieś ulepszenia, czasem nawet uda się jakiś kawałek architektury poprawić, więc też jest fajnie.

1

U mnie identycznie. Maintenance wielkiego produktu. Przez ostatni rok napisałem może z 80 linii kodu. Poza tym ciągle tropienie bugów, gdzie główną zmianą jest przestawienie tokena/define z 0 na 1 i odwrotnie.
Na codzien release za releasem.
Pomimo dobrej forsy niedługo się zwalniam

0
jarekr000000 napisał(a):

Ja lubię bugi :-) To najlepiej zdefiniowane wymagania.

Coś w tym jest. Bug: "w sytuacji X nie działa rzecz Y. Napraw to". Jak naprawisz to jest zrobione. A zwykłe zadanie to coś jak
"bla, bla, bla, bla, bla, bla, bla" i trzeba dopiero wyłuskiwać z tego, o co może chodzić.

a jak zrobisz, to się okaże, że nie tak jak trzeba, i że trzeba zrobić poprawki. Albo w ogóle, że problem był źle zdefiniowany i trzeba wszystko zaorać. A bugi to jednak bugi. Nie działa, napraw.

Żeby nie zapomnieć jak się robi ficzery - czasem zgłaszam się do nowych rzeczy - tak było w poprzednich firmach.
Ale fakt, że aktualnie od pół roku siędze prawie tylko przy nowych projektach i ficzerach
i odczuwam mocno brak grzebania w kupach produkcyjnych. Czuje, że się cofam.

A nie jest tak, że nowe ficzery w greenfieldzie umie wrzucić każdy (byle junior) i nie trzeba wiele myśleć (w zasadzie przydałoby się, ale i tak wszyscy wolą bezmyślnie klepać), natomiast prawdziwe wyzwania są związane z rozbudową istniejącego kodu?

Zresztą myślę, że w projektach, które są robione przez jakiś czas w ogóle już nie ma czegoś takiego jak "nowe ficzery", bo i tak cokolwiek się robi, to trzeba przy okazji poznawać istniejące codebase, dokonywać refaktoringu, naprawiać bugi, które się przez przypadek odkryło... Zanim się cokolwiek zrobi, co ma wartość "biznesową", trzeba i tak się natrudzić na walczeniu z samym projektem... czyli robić właśnie to słynne "maintenance".

0
W2K napisał(a):

.NET Backend, > 3.5lat doświadczenia.

Java i .NET to gównie utrzymanie, więc może zmień technologie ? np. na RoR, Android, JS itp.

2
LukeJL napisał(a):

A nie jest tak, że nowe ficzery w greenfieldzie umie wrzucić każdy (byle junior) i nie trzeba wiele myśleć (w zasadzie przydałoby się, ale i tak wszyscy wolą bezmyślnie klepać), natomiast prawdziwe wyzwania są związane z rozbudową istniejącego kodu?

Kilka lat temu odkryłem, (ku memu zaskoczeniu) że pierwsza część tego zdania nie jest prawdziwa. Może byle junior umie, ale banda architektów i analityków z doświadczeniem potrafi rozwalić nawet naprawdę prostego greenfielda. Im mniejszy system i większy budżet (luz) tym większa pokusa na przeinżynierowanie. I można tak przesadzić, że potem ciężko już odkręcić i doprowadzić projekt do działania.

0
jarekr000000 napisał(a):

Bywa niefajnie, jak firma żyje w epoce infrastruktury lizanej i logi przeglądać trzeba notatnikiem(!), ściągając zipy z 30 serwerów, na każdym po 15 plików (miałem taki przypadek).

Notatnikiem? A grep, less -N itp? :/ To było za czasów jak zabraniali mieć własną instalację jakiegoś UNIX?

0
LukeJL napisał(a):

A nie jest tak, że nowe ficzery w greenfieldzie umie wrzucić każdy (byle junior) i nie trzeba wiele myśleć (w zasadzie przydałoby się, ale i tak wszyscy wolą bezmyślnie klepać), natomiast prawdziwe wyzwania są związane z rozbudową istniejącego kodu?

Tak może twierdzić szef albo dobrze sczelendżowany pracownik mejtenansu :-)

2

E.... nieprawda. Maintenance zwykle ma kasę. Jak gdzieś da się robić powoli i dobrze to właśnie tam. Zwykle management już wie co to techniczny dług i ogólnie jest bardziej technicznie niż politycznie. Greenfieldy tylko w startupach. W korpach greenfieldy to ultraszambo. Co gorsza wcale nie są takie green. Od razu banda architektów wrzuca zajebiste korpoframeworki i standardy.
Ogólnie dlatego pcham sie w maintenance.

0

Zasiedź się w jednej firmie na dłużej, a w końcu trafisz na jakiś nowy projekt po akceptacji wyceny. Zazwyczaj jednak jest to maintenance.

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