Cześć,
Od jakiegoś czasu zastanawiam się, czy rzucić moja aktualną pracę. Jestem teraz na mgr. Około rok pracuje jako... hmm... nie wiem kto.
w utrzymaniu i rozwoju systemow. Do moich zadan należy głównie: analiza kodu, logów, grzebanie w bazie, naprawianie błędów, pisanie skryptów replikujących błedy itp. Jest to moja pierwsza praca. Z jednej strony szkoda mi jej rzucić bo fajnie mieć $. Z drugiej wiem, że się nie rozwijam. Mógłbym spróbować coś kodzić, ale niestety zadania do poprawy są bardzo trudne, a wsparcie jest bardzo słabe, a kolejna sprawa testy... Z jakiś powodów przez wiele lat ich nie poprawili. System ogromny, a patrzac na kod pisany przez studentów, takich jak ja. Gdybym wiedział, że ktoś moją zmianę rzetelnie przetestuje nie byłoby to tak stresujące, a tak napisze coś, nie przetestuje i będzie awaria. Nie wiem co robić. Czy tak wyglada kazda pierwsza praca? Czy ja za dużo oczekuje? Czuje, ze się uwsteczniłem z programowaniem przez ten okres.
napisze coś, nie przetestuje i będzie awaria
No jakbyś testował i sprawdzał czy coś działa to na pewno nie byłoby to tak stresujące, lepiej oddać trochę później ale sprawdzone niż oddać całe zabugowane
Prace rzucasz dopiero wtedy jak masz podpisaną umowę (list intencyjny nic nie daje) z nowym pracodawcą.
Moim zdaniem, powinieneś zmienić pracę jak najszybciej, ucz się po godzinach. 2-3 próbne rozmowy rekrutacyjne do przypadkowych firm a później do firmy do której chcesz się dostać.
No to zrób jak ja w pierwszej pracy, rzuć sobie wyzwanie aby zreformować projekt i zminimalizować skalę zniszczeń. Poczytaj o refaktorach, ratunkach projektów itp. Masz pewnie dużą swobodę twórczą - tego w korporacji, będąc trybikiem, nie masz. Poza tym jak nauczysz się poruszać w słabych projektach to nic Cię nie zaskoczy w przyszłości. Poza tym jest recesja i trzymałbym się stołka.
Takie wzywania chyba źle się kończą. Projektu i tak nie uratuje, w czasie pracy tego pewnie robić nie może bo są inne rzeczy ważniejsze, a takie grzebanie w kodzie po roku pracy dużo więcej może zepsuć niż naprawić. I musiałby robić to po godzinach, gdzie lepiej chyba żeby robił coś bardziej na czasie ;) Jeśli projekt jest mniejszy to można się bawić, ale przy takich ogromnych systemach i nie znaniu zależności, ciężko za coś takiego się wziąć. Jak przyszedłem do obecnej pracy to miałem wielkie plany, zacząłem przepisywać różne rzeczy. Czasem coś popsułem, czasem naprawiłem, ale tego jest multum. Teraz po prostu poprawiam to nad czym pracuje, bo jak się wziałem za jeden formularz to ponad 100h bo przepisywałem, a dla uzytkownika czy tam nawet dla innych wartość tego jest nikła, bo trzeba trzymać się chorych zależności i by trzeba było tam wjechać walcem na co nie ma ani zgody, ani chęci bo w takim przypadku lepiej napisać system od nowa.
Do moich zadan należy głównie: analiza kodu, logów, grzebanie w bazie, naprawianie błędów, pisanie skryptów replikujących błedy
To się nazywa utrzymanie ;) i przypuszczam ze pracuje tak większość programistów. Bo jasne że fajnie klepie sie nowe systemy i nowe ficzery, ale wreszcie ktoś ten system kupi, zacznie używać i trzeba to utrzymywać, często przez wiele lat.
Nie ma specjalnie na to rady, trzeba dorobić testy, a dopiero potem próbować coś "naprawić".
Rozpatrujesz swoją sytuacje z jednej perspektywy - pływania w gnojówie.
Ale co ciekawe, to nie jest najgorsza sytuacja jaka możesz mieć.
Wydaje mi się, że nawet jakbyś trafił do rozwojowego projektu, a jednoczesnie każdego dnia czuł się jak wyciskana cytryna to nie byłoby Ci o wiele lepiej.
Równie dobrze możesz trafić na janusza, który zrobi z Ciebie admino-backendowego-frontendowca i będzie Ci płacił jak stażyście, a przy tym budził w nocy jak serwer padnie.
Także dopóki nie masz expa to będziesz prawdopodobnie rozbijał się o dziadowe firmy. Odpuść sobie ten moment, bo tu nie masz od kogo się uczyć.
Teraz jak masz utrzymanie to przede wszystkim wyluzuj, bo to co robisz to nie jest Twój produkt, to nie jest Twoje zarządzanie, Ty tylko pomagasz więc luz. Doceń tą sytuacje (zwróc uwagę, że nie masz tak palących terminów jak małe firmy, które obiecują gruszki na wierzbie). Możesz o 17 zamknąć laptop i działać nad swoimi rzeczami, nawet jeśli padnie produkcja. Zrozum to już są niezłe warunki do rozwoju, kto Ci broni kształcić się we własnym zakresie?
Dobry rozwój wymaga spokoju (przynajmniej ja tego wymagam od siebie, gdy chcę coś nowego poznać), a na utrzymaniówce jest nudno, ale tam nie musisz się produkować, stawać na głowie czy robić innych akrobacji - najwyżej zwróć uwagę innym osobom, że jesteś junior i nie wiesz.
W typowych firmach głównie dowiesz się jak nie pisać kodu, jest to pewna wartość, ale taka rzecz nie jest warta dodatkowego stresu, jałowych dyskusji z pozycji, która wiele nie wnosi.
A jeśli chcesz się rozwijać to po prostu w domu warto podpatrywać lepszych, przeczytaj dobrą książkę, warto próbować robić ciekawe projekty (niekoniecznie webowe), które pozwolą Ci progresować.
elo_elo_elo napisał(a):
Około rok pracuje jako... hmm... nie wiem kto.
w utrzymaniu i rozwoju systemow. Do moich zadan należy głównie: analiza kodu, logów, grzebanie w bazie, naprawianie błędów, pisanie skryptów replikujących błedy itp
Brawo, pracujesz jako programista. Większość programistów nie tworzy nowych systemów tylko rozwija istniejące. Trzeba się nieźle naszukać żeby pracować w nowym systemie pisanym od początku. A ponieważ sporo programistów chce pracować przy takich systemach to stawki są tam zwykle niższe (Opinia nie poparta żadnymi badaniami)
@KamilAdam: ja bym dodał, że wielu programistów ma za mało doświadczenia w utrzymaniu zanim bierze sie za pisanie nowych rzeczy i potem właśnie produkują takie potworki których nie da się utrzymać, nawet nie zdając sobie z tego sprawy ;)
Jesteś devopsem, kolego.
Dostaniesz nagrodę, będziesz doceniony gdy fragment zrefaktorujesz? Nie.
Co się stanie gdy biorąc się za pracę która nie jest konieczna coś schrzanisz w innym miejscu patchwork-systemu? Bęcki.
Dlatego nikt z poprzedników nie brał się za poprawianie tego co nie jest absolutnie niezbędne żeby nie wysypało się "na mojej zmianie".
Robota w stajniach Firmy Augiasz sp. z o. o. jest do zniesienie pod warunkiem, że nie zaczniesz brać się za wiosenne porządki.
Her Kulesa od razu przepraszam, pan da sobie radę. Frau Kules pochwali pana w domu.
Z jakiś powodów przez wiele lat ich nie poprawili
Jest taka złota zasada jak działa, to nie ruszaj ;) Zauważ że klient płaci za to zeby działało i guzik go obchodzi czy są testy albo czy kod dobrze wygląda. Klient płaci ewentualnie za nowe funkcje w systemie, ale często w utrzymaniówce od dawna nowych rzeczy juz się nie robi. W efekcie nie ma sensu bawić się w ulepszanie czegoś, bo jest szansa ze zepsujesz, a nawet jakbyś coś poprawił, to nikt tego nie doceni bo nikt za to nie płaci. To domena projektów których się już nie rozwija.
Jak system jest rozwijany to jest trochę inaczej, bo wtedy dochodzi też kwestia kosztu modyfikacji i ryzyka że coś się zepsuje i wtedy jednak jest szansa na refaktoring czy pisanie testów.
Tutaj dorzucam:
bardzo lubię pracować w utrzymaniu systemów.
Pod warunkiem, że
a) te systemy generują dużo kasy
b) te systemy generują dużo kasy
c) te systemy generują dużo kasy
Wtedy jest czas na testy, porządny kod, refaktoring (mimo, że często na starcie jest legendarny syf). Oczywiście okazjonalnie zdarzają się klienci wariaci, którzy latami robią quick and dirty, ale natura ich eliminuje.
Ok fajnie jak jeszczete systemy są pod relatywnie dużym obciążeniem i ledwo dyszą - można się dużo nauczyć.
jarekr000000 napisał(a):
Oczywiście okazjonalnie zdarzają się klienci wariaci, którzy latami robią quick and dirty
Tacy zarobiliby z ich szczęściem fortunę w kasynach bez męczenia się z prowadzeniem biznesu.
IMO pływanie w gnoju daje 100x lepszego skilla niż klepanie 100 systemu ankietowego. Przynajmniej będziesz ogarniał wszystkie dziwne pytania na rozmowach bo trafisz w pracy na wiekszosc edge casów i w nocy o północy będziesz mógł je recytować.
To tak jak Inzynier Serwisu - Elektryk Wysokich Napiec.
Potem bedziesz sie chwalic, co to nie robiles i tych od nie-utrzymania ruchu (kodu) zaginac - jak Pan ponizej :)
Kiedy Twój pracodawca zapisze się na szkolenie. 
Ja poczatkiem marca zmieniłem branze na IT. I czar prysł. Duże korpo, ERP,80% logiki po stronie serwera. Wdrożenie prawie zerowe, nikt nie ma czasu i praca zdalna.
Kespa napisał(a):
80% logiki po stronie serwera.
To nie jest źle. W starych systemach korporacyjnych to ponad 50% logiki jest po stronie bazy danych w procedurach składowanych, a aplikacja w Javie jest tak naprawdę wydmuszką do wywoływania tych procedur.
BTW gdzie według Ciebie powinna być logika jak nie po stronie serwera?
KamilAdam napisał(a):
BTW gdzie według Ciebie powinna być logika jak nie po stronie serwera?
Przedtem: w założeniach. Teraz: w /dev/null.
Prace zmieniasz jak Ci nie pasuje - nie wazne czy dlatego ze nie umiesz / nie lubisz czegos robic czy tez dlatego ze uzywaja slabego IDE czy tez biuro jest w slabej lokalizacji.
Tkwienie w nieoptymalnym miejscu grodzi wyrwaniem wlosow i bolem ...plecow.