Niestety utrzymanie jest regułą podczas pracy w IT, bardzo rzadko pojawiają się nowe projekty, a ludzie są regularnie przenoszeni do innych projektów. I chociaż jakość kodu, który będziesz musiał zachować w swoim życiu zawodowym, będzie bardzo różna, nigdy nie będą pachnieć tak samo jak świeży projekt sprzed 2–6 miesięcy.

Jednak są rzeczy, które możesz może uczynić swoje życie i przyszłość trochę bardziej znośnymi. Zacząłbym od mentalnego rozbicia obecnego projektu na moduły, a następnie poprosiłbym o pozwolenie na ich refaktoryzację lub przepisywanie, jeden po drugim, zgodnie z bardziej rygorystycznymi standardami kodowania. Upewnij się, że napisałeś wiele testów dotyczących wszystkiego, co napiszesz lub ulepszysz.

Powinno to spowodować, że Twoje życie zawodowe polepszy się powoli i stabilnie, ponieważ takie podejście pozwoli lepiej zapoznać się z aplikacją, poprawi czytelność części i sprawić, że błędy będą mniej powszechne.

Sposób sprzedaży tego właścicielowi / liderowi / szefowi będzie się znacznie różnić w zależności od struktury firmy i zaangażowanych osobowości. Ale jeśli naprawdę jest to dla ciebie nie do zniesienia i nie masz możliwości ulepszenia rzeczy, to znalezienie innego rodzaju pracy może być lepsze.

Ogólnie wydaje się, że konsultanci będą generalnie pracować nad więcej najnowszy kod i mają większą elastyczność w przenoszeniu z jednego projektu do drugiego lub skupieniu się głównie na nowych (ish) aplikacjach.

Jednak stary kod zawsze będzie częścią wybranego przez Ciebie zawodu, i będziesz musiał się z tym pogodzić i żyć z tym faktem.

Tak, rozsądnie jest powiedzieć swojemu przełożonemu, że nie sprawia ci to przyjemności i poprosić o coś fajnego.

Rozsądne jest również, aby menedżer poprosił Cię o wytrwanie. Jest praca, która musi być wykonana, a praca nie może być zabawna przez cały czas.

Dobry menedżer zda sobie sprawę, że pali Twoją użyteczność i chęć do pracy dla nich i spróbuje zorganizuj spędzenie czasu nad różnymi projektami, ale to nie gwarantuje! Jeśli jesteś jedynym programistą, który może wykonać tę pracę, możesz po prostu utknąć.

Aby pomóc w tym toku działania, dobrze jest przygotować coś, na co chciałbyś poświęcić swój czas: te projekty, które rozpocząłeś, może jakiś inny projekt lub nawet kurs, aby poprawić swoje umiejętności. Pomoże to przekształcić prośbę w Plan.

Zły menedżer będzie na ciebie urażony, ponieważ „narzeka na głupie rzeczy”, jest to nierozsądne, ale nie byłbyś pierwszy aby otrzymać odpowiedź.

Aby temu zapobiec, przygotuj konkretną listę rzeczy, które sprawiają, że praca jest niefajna: głupie błędy, powtarzające się zgłoszenia, kod bez komentarza. To zmienia skargę w opinię i sprawia, że ​​Twoje pytania brzmią bardziej rozsądnie.

Moje pytanie: czy rozsądnie byłoby poprosić mojego kierownika o przydzielenie mnie do innego projektu, ponieważ naprawdę nie podoba mi się praca, którą muszę teraz wykonać i jak to powiedzieć?

Nie, to nie byłoby rozsądne. Częścią bycia programistą jest utrzymywanie istniejących programów, czy to dodawanie / usuwanie funkcji, czy naprawianie błędów. Miałeś szczęście, że pracowałeś nad kilkoma projektami, które zacząłeś od zera, ale nie możesz oczekiwać, że każdy projekt będzie taki. Czasami przez pewien czas firma nie potrzebuje nowych projektów rozpoczynanych od zera (nie oznacza to, że nigdy więcej nie będzie), a wystarczy, że będą utrzymywać istniejące projekty.

Co należy zrobić przejąć na własność swój obecny projekt. Zapomnij o tym, że ma 6 lat i pracowało nad nim 5 innych programistów. Jeśli jest brudny i pełen błędów, podejmij inicjatywę, aby naprawić projekt. Z pewnością będziesz lepiej wyglądać w oczach swojego menedżera, jeśli z powodzeniem doprowadzisz projekt do stabilnego stanu, zamiast narzekać, że musisz pracować nad tym projektem i próbować zlecić ci inną pracę.

Zawsze możesz zapytać, ale zawsze mogą też odmówić.

Jeśli nie masz w umowie zapisów, że będziesz pracować tylko nad projektami, które lubisz, mogą zlecić Ci projekty, które widzą fit.

Możesz udokumentować zmiany, które chciałbyś wprowadzić (refaktoryzacja, pisanie dokumentacji, ...) i korzyści dla firmy w postaci czasu uzyskanego dzięki mniejszej liczbie błędów.

Lub możesz argumentować za nowym rozwojem produktu z lepszymi praktykami. Ale tak długo, jak stary projekt ma płacących użytkowników, ktoś musi go utrzymywać, a oni wybrali Ciebie Pikachu.

Możesz argumentować, że więcej osób robi to, co robisz (czynnik autobusowy), abyś mógł pracować nad innymi projektami. Jeśli te sprawy staną się ważniejsze niż dotychczasowy projekt, mogą się one skończyć.

Ale znowu: tak długo, jak ludzie będą płacić Twojej firmie i poza tym płacić Twoim szefom pensje za ten projekt, a Twoja firma nie Nie jesteś skłonny do rezygnacji, ktoś będzie musiał naprawić błędy.

W ostateczności możesz rzucić palenie i pracować jako wolny strzelec. Tam naprawdę możesz wybrać projekty, nad którymi pracujesz, ale bądź przygotowany na wykonanie niektórych projektów, których naprawdę nie lubisz, gdy światła są włączone. Tylko najlepsi i najbardziej znani potrafią w pełni określić, co robią.

tl; dr: Bądź uczciwy wobec swojego pracodawcy. Powiedz im, że interesują Cię tylko projekty od podstaw. Pamiętaj jednak, że podjęcie takiej decyzji znacznie ograniczy oferowaną pracę, prawdopodobnie do tego stopnia, że ​​Twoje usługi nie będą już potrzebne.

Jedną z najważniejszych rzeczy w profesjonalnym tworzeniu oprogramowania jest współpraca na współdzielonym kodzie. Jeśli nie jesteś solistą gwiazdy rocka, kod źródłowy będzie zawsze mieć historię ukształtowaną przez dawnych i obecnych kolegów - a być może także Ciebie w przeszłości .

Jak już wspomniałeś, czytanie kodu jest znacznie trudniejsze niż jego pisanie - i właśnie dlatego ta umiejętność jest tak ważna. Potrzeba dużo umiejętności i cierpliwości, aby poznać i zrozumieć zakamarki istniejącego projektu. Programiście łatwiej - i oczywiście przyjemniej - zacząć wszystko od nowa, być może nawet wybierając używane technologie i frameworki.

Oprogramowanie komercyjne zawsze służy celowi biznesowemu . Oznacza to, że - chyba że pracujesz tylko ze startupami lub marketingiem - oprogramowanie powinno mieć rozsądną oczekiwaną długość życia. Deweloperzy, którzy dokładają wszelkich starań, aby zaznajomić się z istniejącymi rozwiązaniami, a zwłaszcza istniejącymi interesami biznesowymi , stają się wartościowi - i często trudni do zastąpienia.

Jak Ty Zwracaliśmy uwagę, stary kod nie zawsze (nigdy?) nie jest łatwy w obsłudze, wolny od błędów lub czysty. Proponuję rozważyć odwrócenie sprawy: każdy niemożliwy fragment makaronu do kopiowania spaghetti jest okazją na świetny refaktor z testami jednostkowymi; każdy raport o błędzie to szansa zaimponowania firmie i użytkownikom końcowym nienaganną obsługą klienta .

Mój zespół obecnie obsługuje dwa produkty, które należały do ​​naszej firmy, kiedy nasza firma wykupiła pierwotnych programistów. Przyczyną tych zakupów było to, że inne firmy nie radziły sobie dobrze finansowo.

Pracuję tylko nad jednym z dwóch produktów. Na początku było to jak wypychacz pracujący przy zabójstwach drogowych. Pierwotny zespół programistów nie powinien już nigdy więcej dotykać komputerów. Mój przełożony jest odpowiedzialny za drugi produkt i jest to również katastrofa.

Główną korzyścią płynącą z pracy przy tych pożarach w śmietnikach jest to, że otrzymujemy solidne i solidne lekcje o tym, jak nie robić różne rzeczy, a nawet po trzech latach w branży uczysz się czegoś takiego z produktów, nad którymi pracujesz.

Więc przestań patrzeć na swoją sytuację jako coś, z czym nie powinieneś mieć do czynienia, i zamiast tego spójrz na to, jak zamierzasz ulepszyć produkt swojej firmy, niż był wcześniej.

Jako łatwy pierwszy krok, za każdym razem, gdy musisz zastanowić się, co robi fragment kodu, umieść komentarze w kod wyjaśniający dokładnie, co robi kod. Może ci to nie pomóc - chociaż uważam, że bardzo mi to pomaga - ale następna osoba, która przyjrzy się kodowi, nie będzie musiała go rozwiązywać.

Już wiele świetnych odpowiedzi, ale dodanie mojego 0,02 funta.

Utrzymanie starszego oprogramowania jest trudniejsze niż tworzenie czegoś nowego, ale samo w sobie jest cenną umiejętnością.

Umiejętność wskoczenie do bazy kodu, która istnieje od lat, ze złą dokumentacją lub bez niej i zawierającą wiele różnych stylów kodowania od wielu programistów, którzy nad tym pracowali, jest czymś, czego wielu pracodawców, szczególnie w świecie przedsiębiorstw, aktywnie szuka.

Jeśli nie ma dokumentacji, napisz ją. Jeśli nie ma testów automatycznych, popracuj nad refaktoryzacją kodu, aby był testowalny i napisz kilka testów. Jeśli style kodowania są wszędzie, zbadaj zalecane style dla języka lub frameworka i popracuj nad refaktoryzacją bazy kodu, aby pasowała do zalecanego stylu kodowania.

Zdobycie reputacji kogoś, kto jest szczęśliwy pracować ze starszym kodem, a kto robi to dobrze, może być tak samo dobry dla Twojej kariery, jak praca nad projektami od podstaw z nowymi i błyszczącymi frameworkami.

W miarę upływu czasu ilość starszego kodu w produkcji jest tylko wzrośnie, a popyt na programistów, którzy mogą się nim opiekować, naprawiać błędy i dodawać nowe funkcje, będzie wzrastał wraz z tym, ponieważ przepisywanie tych aplikacji za pomocą nowej technologii jest ogólnie uważane za zły pomysł dla wielu dobre powody.

Powodzenia!

Utrzymanie starszej wersji buduje pragnienie programisty w zakresie dobrych praktyk

Chcę tylko dodać perspektywę głównego programisty, ponieważ jako programista zgadzam się, że nie chcę utrzymywać starego kodu, ale jako główny programista Nie radzę, aby jakikolwiek programista tego unikał.

Posłużę się praktycznym przykładem, aby przedstawić swoją argumentację. Jako konsultant często jestem wysyłany do firmy / projektu z problemami z jakością kodu, gdzie moim zadaniem jest naprawianie rzeczy. Jak można się domyślać, zły kod prowadzi do wielu prac konserwacyjnych w starszej wersji.

Z mojego doświadczenia wynika, że ​​programiści piszący zły kod znajdują się w jednym z dwóch obozów:

• Ci, którzy nie wiedzieli nic lepszego
• Ci, którzy uważają, że postępują właściwie

Z pierwszą grupą łatwo sobie poradzić, ponieważ natychmiast się poprawią kiedy pokażesz im dobre praktyki. Tę ostatnią grupę znacznie trudniej jednak przekonać, ponieważ nie widzą korzyści płynących z dobrych praktyk, które często wymagają więcej wysiłku w krótkim okresie. Na dłuższą metę to się opłaca, ale ta druga grupa często nie docenia tego punktu.

Prawie każdy deweloper, z którym miałem do czynienia, a który był w tym drugim obozie, był programistą, któremu udało się przeskoczyć z projektu do projektu pomijanie utrzymania własnego kodu . Ponieważ nigdy nie mieli do czynienia z konsekwencjami swoich niedoskonałych decyzji projektowych, nigdy nie byli zachęcani do prób uniknięcia tych problemów przed ich wystąpieniem, gdy aplikacja była początkowo budowana.

Rozwiązanie jest proste: programiści muszą przejąć prawo własności . Jeśli napiszesz błędny kod, poradzisz sobie z wynikającymi z tego błędami. Jeśli nie chcesz spędzać czasu na naprawianiu błędów, to od Ciebie zależy, czy napiszesz kod, który ich nie generuje.
Stwarza to bardzo prostą zachętę dla programistów do doskonalenia się, a nie do tego ich woli i bez ich zrozumienia, dlaczego jest to lepsze podejście.

Chcę, żebyście od tego wzięli, że konserwacja starszej wersji jest niezbędna dla programistów, aby pamiętali, dlaczego potrzebują dobrych praktyk .
Analogicznie, generał, który jest w okopach z jego ludzie podejmą lepsze decyzje (dla żołnierzy) niż generał, który wygodnie siedzi w pałacu na drugim końcu kraju. Deweloper musi zabrudzić sobie ręce, aby kiedy był generałem (= budując nową aplikację), wiedział, jaki jest wpływ ich decyzji projektowych.

Sprzątanie po innych

Nie masz jednak do czynienia z własnymi błędami, ale raczej z tymi, które wystąpiły przed tobą. Obecnie jeżdżę na tej samej łodzi i zgadzam się z Tobą, że nie jest to dająca się oprzeć sytuacja.
Nikt nie lubi starszej konserwacji i wydaje się, że Twój kierownik nie wziął pod uwagę tego, w jaki sposób wykonujesz wyłącznie starszą konserwację wpływają na Twoje morale i rozwój Twojej kariery.

Spędziłem 3 lata zajmując się starszą konserwacją, ale była to wygodna praca z bardzo luźną polityką w domu. Zajęło mi trochę czasu, zanim zrozumiałem, że chociaż równowaga między życiem zawodowym a prywatnym nie była zła, moja kariera utknęła w martwym punkcie, ponieważ nie zdobywałem aktualnej wiedzy w branży. Gdybym został zwolniony z tej pracy po 5 latach, moje umiejętności byłyby tak przestarzałe dla innych firm, że musiałbym walczyć, aby nadrobić stracony czas.

Z drugiej strony ktoś musi wspierać ten projekt. Nie możesz więc po prostu przyjąć podejścia „nie ja”, ponieważ każdy programista będzie reklamować to samo podejście „nie ja”, a wtedy kierownictwo może po prostu wyznaczyć kogoś, kto wyciągnął krótką słomkę (może to być sposób, w jaki skończyłeś na początku tej pozycji).

Rozwiązanie problemu

Skontaktuj się ze swoim menedżerem i wyjaśnij mu, że chociaż rozumiesz, że stary projekt wymaga wsparcia, to szkodzi morale, gdy nie robisz nic oprócz starego kodu. Zapytaj, czy Twój kierownik rozważyłby przydzielenie Cię do innego (innego niż dotychczasowy) projektu w niepełnym wymiarze godzin.

Z mojego doświadczenia wynika, że ​​większość rozsądnych menedżerów to zrozumie (prawdopodobnie zostałeś do tego przydzielony, ponieważ pozostałych 5 programistów, którzy opuścili wszystkich, spierało się o ten sam punkt) i dostrzeże korzyść z utrzymania Ciebie (kogoś, kto już wie starszego projektu) w projekcie w niepełnym wymiarze godzin, w przeciwieństwie do konieczności odejścia i znalezienia nowego programisty, który nie zna starego projektu.

Ale z mojego doświadczenia wynika, że ​​są też firmy, w których morale pracowników jest znacznie niższe na liście priorytetów, gdzie stosują bardziej rygorystyczne podejście „rób to, co każemy”.
Jedyną radą, jaką mogę tu dać, jest pozostawienie tak toksycznego środowiska. Nie pozwól swojej karierze zmarnować pracy, której nienawidzisz, dla firmy, która nie ceni Twojej satysfakcji z pracy (w rozsądnym stopniu).

Jeśli nie podoba ci się to, nad czym pracujesz, odejdź do innej firmy. Programiści są bardzo poszukiwani.

Upewnij się, że wiesz z góry, jakie rodzaje pracy będziesz wykonywać. Nie będę nikogo krytykować za odejście w twojej sytuacji, to brzmi okropnie. Ale gdybyś został zatrudniony, wiedząc, że będziesz pracował nad tego typu projektem, narzekanie na to byłoby w złym guście.

Rzadko kiedy istnieje wiele możliwości zmiany codziennej pracy w ramach firmy, te rzeczy są zwykle długoterminowe i prawie zawsze są gorsze od zwykłego znalezienia innej pracy wykonującej coś, co chcesz robić.

To zależy od firmy. W mojej ostatniej pracy moja firma oferuje rozwiązania informatyczne dla rządu i banków. Więc za każdym razem jest to nowy przetarg i nowy projekt. Należę do zespołu deweloperskiego, który bierze udział w przetargach, projektowaniu i realizacji projektów. Po wydaniu produkcyjnym zespół utrzymania ruchu przejmuje kontrolę i kontaktuje się z nami tylko w przypadku problemów, z którymi nie może sobie poradzić. Więc firma o innym charakterze może być rozwiązaniem.

Możesz jednak spojrzeć na swoją sytuację w innym świetle.

Jeśli oprogramowanie, które utrzymujesz, jest złe, napraw je . Jeśli nie można tego naprawić, wyjaśnij swojemu przełożonemu, dlaczego tak jest, i zaproponuj rozwiązanie.

To, co uważasz za złą sytuację, może być zamiast tego szansą, by pokazać swojemu przełożonemu, do czego jesteś zdolny.

Jeśli Twój przełożony postrzega Cię w pozytywnym świetle, znacznie większa szansa, aby zostać przydzielonym do projektów, które chcesz wykonać, lub przekonać go / ją do zmiany przydziału.

W mojej obecnej dwuletniej pracy kontraktowej utrzymuję złe oprogramowanie, takie jak ty. Pierwotnego producenta już dawno nie ma, a jakość kodu jest zła. Mój przełożony jest niechętny dużym zmianom, ponieważ kultura firmy jest bardzo powściągliwa i nienawidzi ryzyka. Przedstawiłem wady i zalety różnych opcji naprawy części, nad którą pracuję, zajęło mi to dużo wysiłku, ale ostatecznie je zdobyłem. Kilka miesięcy później mój przełożony mówi o zaoferowaniu mi stałego stanowiska.

Bohaterowie powstają z okazji.

Postaw się w innej sytuacji Znasz swojego menedżera, on słucha swojego zespołu? Czy rozsądny menedżer? Chcesz zaspokoić potrzeby programistów? Jest komunikatywny? To jest bardzo ważne, twój menedżer ma swoją rolę ... wykonać zadanie, przedstawić wyniki. I w tym celu ktoś musi zająć się starym projektem.

• Czy ma innego zastępcę?
• Czy ma inny projekt, bardziej atrakcyjny dla Twoich preferencji, który daje Ci motywację, być może 50% Twojego czasu?
• Czy może dać Ci zielone światło na odtworzenie części projektu?

Nie masz pewności ... więc tak, musisz z nim porozmawiać. Nie w wymagający sposób, nie, jeśli lubisz miejsce pracy. Ale trzeba z nim porozmawiać o swoim dyskomforcie, bo odejście pracowników też nie jest dobrym wynikiem,… żadna firma / menedżer nie otrzymuje zasiłku za rezygnację dewelopera. I nie prosisz go o więcej pieniędzy, mniej godzin, pracę zdalną lub coś, co koliduje z polityką / zasobami firmy. Chodzi o próbę reorganizacji alokacji zespołu, jest to bardziej „wykonalne”. I nie zostaniesz zwolniony za powiadomienie go o dyskomforcie. Ale jedyną osobą, która może pomóc rozwiązać twój dyskomfort, jest on, jeśli oczywiście chcesz tam zostać.

Zaproś go na krótkie prywatne spotkanie.
Odpręż się , bez złych emocji, bez wymagających tonów.
To jest rozmowa z członkiem zespołu, która pomoże Ci znaleźć rozwiązanie dyskomfortu.

Nawet jeśli nic dla ciebie nie zrobi i nic nie da się zrobić. To nie jest w twoich rękach, zrobiłeś, co mogłeś, aby zostać przeniesionym. Ponieważ jeśli nic nie powiesz i znajdziesz nową pracę, w momencie, gdy mu powiesz, pierwszą rzeczą, którą ci powiem, jest „Nie wiedziałem, teraz tak się czułeś, moglibyśmy spróbować to rozwiązać” . Kiedy odchodzisz z firmy dla pieniędzy, najpierw prosisz o podwyżkę, to jest to samo, zanim zaczniesz szukać pracy, daj im szansę na znalezienie rozwiązania, które zaspokoi oba zainteresowania . Pomyśl w taki sposób, aby uzyskać motywację, a jednocześnie zapewnić wartość zespołowi / klientowi

Jest duża szansa, że ​​usłyszysz moją historię, więc możesz skorzystać.

Zostałem zatrudniony w mojej firmie do pracy nad jednym konkretnym projektem (częściowo dlatego, że byłem jedynym facetem, z którym rozmawiali, który wiedział w ogóle elektronika, ale okazało się to w dużej mierze nieistotne). Pracując nad tym przez około sześć miesięcy, doszedłem do wniosku, że architektura była całkowitą stratą, mimo że kod źródłowy miał zaledwie półtora roku. Myślałem wtedy, że patrzę na trzyletnią bazę kodów, a firma miała historię złych praktyk kontroli źródła. W rzeczywistości ich kontrola źródła była w miarę ok (poprawiła się), a produkt został wykonany przez produkcję big bang.

Zgłosiłem przez analogię, że fundament jest pęknięty, a podłoże niestabilne. W rzeczywistości konieczne było całkowite przepisanie, ale w tamtym czasie nie było na to stać i wiedziałem o tym. Umówiliśmy się przez analogię, że w razie potrzeby przebiję belki dwuteowe przez fundament, aby służyły jako słupy. Przez następną dekadę, gdy coś się zepsuło lub stało się niemożliwe do utrzymania lub gdy profiler lokalizował hotspoty, wymieniłem prawie całą oryginalną architekturę, do tego stopnia, że ​​pozostało tylko kilkadziesiąt linii. Ale teraz same dwuteowniki pękły i zostały usztywnione, a dachowiec, który stał się wieżowcem, pokazuje swój wiek i znowu staje się ciężki w pracy i boję się uczyć nowych programistów wszystkiego, co jest potrzebne, aby dodać nowe tabele do bazy danych, ponieważ nie jest to dobre przykłady pozostają. Każde wyjaśnienie, jak działają rzeczy, stało się teraz lekcją historii.

Nie pracuję już zbyt wiele nad produktem, ale zawsze, gdy trzeba wprowadzić zmianę, która łamie zasady architektury, robię to nie dlatego, że tylko ja to potrafię, ale dlatego, że znam w zasadzie wszystkie zasady w mojej głowie i dlatego potrafię wybrać najłatwiejszą drogę do utrzymania ich konsekwencji.

Ale dopiero teraz mam doświadczenie, aby właściwie to zrobić i zaprojektować architekturę, która może być utrzymywana przez dwadzieścia lat lub dłużej. Niektóre z problemów to złe decyzje oryginalnej architektury, w których zastąpiłem implementację pracą prawie podobną, zachowującą wiele takich samych decyzji. Niektóre z problemów to moje własne złe decyzje. Branża się zmieniła i chcemy zastąpić architekturę grubego klienta architekturą internetową. Wiesz co, teraz jest czas. Nie mam pełnego zestawu umiejętności związanych z architekturą sieciową, ale mam większość z nich i wiem, gdzie się zwrócić po resztę.

Wybór naprawdę musi należeć do Ciebie, ale możesz mam tutaj miejsce na przeprowadzenie belek dwuteowych przez fundament. Jeśli zdecydujesz się to zrobić, nauczysz się i staniesz silny.

Upewnij się, że znasz siebie, zanim zrobisz cokolwiek drastycznego

Trzy lata to wciąż dość młodszy okres, więc nie zrobiłbym nic drastycznego, jak zmiana pracy lub kariery, dopóki nie upewnisz się, że wiesz, co to jest o utrzymywaniu starego kodu, którego nie lubisz. Na przykład możliwe jest, że musisz nauczyć się nowego narzędzia lub techniki i faktycznie możesz nauczyć się lubić utrzymywanie starego kodu. Jeśli masz mentora, dobrze byłoby z nim porozmawiać. Jeśli nie masz mentora, spróbuj go znaleźć.

Niezadowolenie = słabe wyniki = trafienie w karierę = czas na zmianę

Gdy masz pewność, że to nie ty, to jest praca, a potem zdaj sobie sprawę, że wykonasz najlepszą pracę tylko wtedy, gdy będziesz zadowolony lub przynajmniej zadowolony ze swojej pracy. Jeśli jesteś aktywnie nieszczęśliwy lub nienawidzisz swojej pracy, będzie to widoczne w Twojej pracy. Na dłuższą metę zaszkodzi to twojej karierze. Więc nie robisz sobie żadnych przysług, pozostając w sytuacji, która aktywnie czyni Cię nieszczęśliwym (czasami nie mamy żadnego wyboru, ale jeśli to zrobisz, i przez większość czasu to robimy, musisz dokonać zmiany).

Co powinieneś zrobić?

Powiedz szefowi o swoich preferencjach, a jeśli szef nie może lub nie chce ich uszanować w rozsądnym czasie, znajdź pracę, która może i będzie. Zwróć uwagę, że prawie żadna praca (nawet jeśli jesteś swoim własnym szefem) nie spełnia Twoich preferencji w 100% przypadków; to tylko życie. Ale dobre dopasowanie to takie, które jest dla Ciebie akceptowalne i łączy w sobie zadania, które lubisz, z zadaniami, które przynajmniej możesz tolerować. Ale jeśli okaże się, że nienawidzisz swojej pracy, czas na zmianę.

Ostatnia rzecz

Jeśli pracujesz przez długie godziny lub pracujesz w weekendy bez odpowiednich przerw, możesz doświadczać wypalenia, które może sprawić, że nawet najprzyjemniejsze zadania będą wydawać się nie do zniesienia. Tak więc część podsumowania swojej sytuacji obejmuje upewnienie się, że nienawiść do pracy naprawdę pochodzi z pracy, a nie ze stresu wywołanego wypaleniem. Jeśli okaże się, że problemem jest wypalenie zawodowe, należy zająć się nim inaczej niż wtedy, gdy po prostu nie lubisz swojej pracy.

Oto strategia, której możesz użyć. Ale bądź ostrożny, może to postawić cię w niekorzystnej sytuacji w stosunku do twojego menedżera.

Powiedz im, że niektóre moduły są bzdurne i muszą zostać przepisane od nowa, nie możesz im pomóc. Może znaleźć kogoś innego lub pozwolić Ci napisać ponownie. Jeśli możesz ponownie napisać, to prawie jak nowy projekt, powinieneś być szczęśliwy.

Widziałem obie strony tego. Ponownie napisałem kiepski kod, którego zrozumienie i naprawienie zajęłoby mi więcej czasu niż ponowne napisanie. Widziałem ludzi, którzy przepisywali kod, który moim zdaniem był w porządku i możliwy do utrzymania (i łamał mój budżet).

Długo przez to przechodziłem. Stało się czymś nie do zniesienia.

Niestety, praca pochłania większość czasu w ciągu dnia i bardzo obrzydliwe jest obudzenie się z myślą, że będziesz w pobliżu wielu złych kodów. To złe uczucie.

Uwielbiam tworzyć i wymyślać; dlatego już dawno zostałem programistą. Nie jestem też geniuszem, genialny, ale raczej kreatywny.

Teraz, gdy masz doświadczenie, rzuć pracę i poszukaj takiej, która bardziej zasługuje na Twoje oddanie. Zrobiłem to 2 miesiące temu i teraz nie rozumiem, dlaczego nie zrobiłem tego wcześniej.

Po kilkukrotnym odkryciu, że zaczynam „nienawidzić” jakiejś bazy kodu, zacząłem badać dlaczego.

I odkryłem, że dzieje się tak, ponieważ ma on pewne wady, które nieustannie mnie niepokoją i pozostają nierozwiązane. W ten sposób kłopoty narastają i ...

Zatem sposobem na wyeliminowanie tej „nienawiści” jest zidentyfikowanie i naprawienie rzeczy, które przeszkadzają Ci w tym kodzie!

Co to jest co najważniejsze, już je znasz (ponieważ przeszkadzają), ale nie obchodziło Cię ustalanie priorytetów.

Kilka już wymieniłeś: „nie jest łatwo zrozumieć kod, zwłaszcza jeśli nie ma dokumentacji”. Podczas badania kodu musieli Państwo zidentyfikować, że te i te części są niechlujne i podatne na błędy; tutaj i tutaj nie ma testów, więc nie ma możliwości sprawdzenia, czy kod jest (nadal) poprawny we wszystkich przypadkach itp.