Byłbym bardzo niechętny do wykonywania pracy, która polegałaby głównie na konserwacji. Oto dlaczego:

1. To jest szkodliwe dla kariery (wewnętrznej). Heroiczne wysiłki, by oprogramowanie działało, prawie nigdy nie są rozpoznawane, ponieważ ludzie widzą tylko status quo. Ktoś, kto nie spał całą noc, aby ukończyć nową funkcję, otrzyma wiele pochwał. Ktoś, kto zrobił to, aby zapobiec awarii oprogramowania? Nikt nawet nie wie, że to zrobili. W mojej niewątpliwie krótkiej karierze nigdy nie widziałem pochwały za dobrą pracę konserwacyjną. Słyszałem, że wielu ludzi zajmujących się konserwacją / IT narzeka na to, że są niedoceniani iw większości tak właśnie jest. Zapytaj siebie, co myśli kierownictwo wyższego szczebla o programistach wsparcia? Czy wiedzą dużo o programistach wsparcia? Kto został pochwalony?

2. To źle wpływa na karierę (zewnętrzną). Mój przyjaciel jest bardzo doświadczonym programistą i przez dwa lata zajmował się głównie podanie. W przyszłych wywiadach był stale pytany, dlaczego tylko poprawiał, a nie budował. Wielu ludzi uważa, że ​​konserwacja nie jest inżynierią. Widzisz to również w wielu dziedzinach poza inżynierią. Kiedy aplikowałem na uniwersytet, modną rzeczą było założenie organizacji charytatywnej i zbudowanie szkoły. Dlaczego nie dołączyć i nie zbudować istniejącego? Nie dostałbyś za to uznania, ponieważ nawet gdyby osiągnęli taki sam rezultat, jak bez „przywództwa” czy „inicjatywy”. Ludzie, którzy coś budują, cieszą się znacznie większym szacunkiem niż ci, którzy pracują, nawet jeśli jest to trudniejsze.

3. To źle wpływa na karierę (technologia). Projekty konserwacyjne są częściej tworzone przy użyciu starszej technologii. Problem w tym, że technologia ma krótkie życie w tworzeniu oprogramowania. Jeśli pracujesz nad projektem z JQuery zamiast React lub takim, który używa Ant zamiast Maven, Ruby zamiast JS, twoja wartość rynkowa więdnie. Jeśli używasz AngularJS, Bootstrap 3, wersji Java mniej niż 8, Objective C itp., Twoje opcje stają się coraz bardziej ograniczone z każdym dniem, ponieważ niewiele nowych prac rozwojowych jest wykonywanych w tych językach.

4. Jest to trudniejsze. Dzisiaj rozwiązałem błąd, dodając czek i usuwając tabelę w bazie danych. Mój projekt jest od podstaw, który jeszcze nie trafił do produkcji, więc nie musimy zachowywać kompatybilności wstecznej ani zachowywać istniejących danych. Naprawienie tego błędu przy jednoczesnym zachowaniu danych wymagałoby albo uruchomienia skryptu w celu usunięcia niektórych wierszy, albo zmodyfikowania interfejsu API w celu wybrania właściwego.

5. Zawsze jesteś centrum kosztów. Jedną z zalet projektu od podstaw jest to, że pozwala on menedżerom na zaangażowanie się i sprawia, że ​​cenią oni projekt bardziej . Spotkałem tych dwóch programistów mobilnych na konferencji, którzy opracowali i utrzymywali aplikację w Xamarinie w celu zapewnienia wzajemnej zgodności. Następnie mówiono o cięciu kosztów i outsourcingu utrzymania aplikacji do Indii (mieszkam w Kanadzie, więc koszt jest zasadniczo inny) i oszczędzeniu dwóch pensji programistów. Wiesz, jak się uratowali? Omówienie „problemów ze zgodnością” i przekonanie kierownictwa, aby przepisali aplikację od podstaw w React Native. To uratowało ich miejsca pracy i zapewniło im podwyżki. Jeśli będą sprytne, będzie więcej „problemów ze zgodnością” i potrzeba przepisania we Flutterze.

Praca programisty powinna być połączeniem zarówno utrzymania, jak i pracy nad nowym projektem. Robię to od ponad 35 lat. Jest to powszechne i bardzo chybione.

Ten rodzaj rotacji jest problemem organizacyjnym. Wszyscy programiści powinni mieć połączenie zabawnej, ekscytującej pracy nad projektem (nowsze rzeczy) i prac konserwacyjnych (włącz światła).

Na moim obecnym stanowisku szukamy podziału 60/40 między pracą projektową a pracą wspierającą. Może to (oczywiście) zmieniać się w zależności od projektu i kwoty wsparcia.

Firmy, które nie nagradzają pracy wsparcia w takim samym stopniu, jak nowe rzeczy mają zwykle problemy. Kiedy doświadczeni ludzie zostawią bogactwo wiedzy biznesowej wraz z wiedzą systemową (czynnik autobusowy).

Czas na wyzwanie związane z ramą: ten problem nie jest dla programistów nienawiścią do konserwacji; problem polega na tym, że nienawidzą pracy dla Twojej firmy.

Nie sądzę, żebyś zdawał sobie sprawę z tego, jak szalony jest Twój wskaźnik obrotów. Średni obrót IT wynosi 13,2% rocznie - a ta statystyka jest sformułowana jako „Święta krowa, 13,2% to wysoki!” Przez jakiś czas pracowałem dla firmy PoS, a jej obroty wynosiły nieco ponad 20% - i osobiście postrzegam to jako fabrykę rezygnacji. Jaki jest więc wskaźnik rotacji IT Twojej firmy? Około 80%! To sześć razy więcej niż wskaźnik „Święta krowa, obrót IT jest wysoki” i prawie czterokrotnie wyższy niż wskaźnik „odchodów fabryki”. (Prawie chcę skopiować i wkleić cały ten akapit po raz drugi, tylko po to, aby podkreślić, jak dysfunkcyjny jest ten wskaźnik obrotów).

Więc chcę, żebyś postawił się w sytuacji programisty, który ma dołączył do Twojej firmy - i prawdopodobnie nienawidzi swojej nowej pracy. Już chcą wyjść ... ale mają dylemat: czy wyskakują ze statku już po 2 miesiącach w pracy? Choć zrozumiałe, nadal byłoby to trochę ostrzeżeniem w ich CV, którego woleliby uniknąć. Ale obecnie pracują nad projektem. Może dobrym rozwiązaniem jest po prostu trzymanie go jeszcze kilka miesięcy do zakończenia projektu, a następnie umieszczenie go w CV? Ponadto ukończenie projektu służy jako świetna „podpórka do książki” - zamknięcie, które mentalnie zaznacza ich czas spędzony w firmie. Istnieje bardzo duża szansa, że ​​po wydaniu projektu otrzymujesz masowe exodusy, a nie dlatego, że wszyscy spontanicznie chcieli odejść w tym samym czasie - po to, że chcieli rzucić przed tym punktem i po prostu czekali na zakończenie projektu .

Patrząc na twoje pytanie, myślę, że zrobiłeś krok, którego nie powinieneś: że odchodzą specjalnie z powodu konserwacji. Czy zapytałeś ludzi, którzy odeszli? Czy poprosiłeś obecnych konserwatorów o anonimową opinię? Czy przejrzałeś recenzje Glassdoor?

Nie zrozum mnie źle: rzeczywiście mogliby uciekać, ponieważ nienawidzą konserwacji. Ale mogą istnieć inne powody - powody, które tracisz z powodu pośpiesznego założenia.

Mogę mówić tylko za siebie, ale powody, dla których czasami jestem kontrprzykładem, mogą być pouczające.

Utrzymanie projektu obciążonego ogromnym długiem technicznym może być trudne, ale może też być niezwykle satysfakcjonujące. Dziedziczenie katastrofalnie nieudanych projektów Androida i ASP.NET nauczyło mnie więcej rzeczy, niż mogę zliczyć na temat tego, czego nie robić w tych frameworkach. Zastosowałem te lekcje w moich własnych projektach od podstaw. Zdobyłem również umiejętności w zakresie refaktoryzacji, co jest bardzo cenne w tej branży, ponieważ istnieje tak wiele projektów, które upadają pod wpływem długu technicznego. I jest to emocjonalnie satysfakcjonujące, ponieważ naprawianie błędów czyni cię bohaterem dla użytkowników.

Było to możliwe, ponieważ kierownictwo, a przynajmniej moi bezpośredni przełożeni, zauważyli, że mam do czynienia z długiem technicznym i dali mi list marki, żeby to spłacić. Poczucie się jak bohater staje się zachętą, gdy programiści wiedzą lub mają jakiś rodzaj zaangażowania z użytkownikami. Zbudowałem bardzo udaną karierę na sprzątaniu bałaganu innych ludzi i mogę szczerze powiedzieć, że mi się to podoba. Ale widzę, że obroty stają się problemem, jeśli te warunki nie zostałyby spełnione.

Ogólnie nie wiem, ale mogę odpowiedzieć samodzielnie.

(W dowolnej kolejności)

1. Projekty są postrzegane jako bardziej "ekscytujące ”, w tym sensie, że oferują większe wyzwanie. Greenfield (i) szczególnie projekty, ponieważ technologia jest niezmiennie nowa (er) i oferuje więcej możliwości nauki. Konserwacja jest taka sama stara, ta sama stara.

2. Projekty zwykle mają ustalony koniec lub są wykonywane etapami. Konserwacja jest postrzegana jako niekończąca się lista. Za miesiąc będzie inaczej.

3. Często praca nad projektem może wyglądać lepiej w CV. "Dlaczego wyszedłeś?" - „Koniec projektu” brzmi lepiej niż „Znudziłem się po 2 latach tego samego materiału”. Najemca zauważy „łatwo się nudzić”.

4. Koszt / czas. Twoje „niestandardowe rozwiązania” będą wiązały się z kosztami lub ograniczeniami czasowymi, które zmuszają programistów do „po prostu wykonania tego”, zamiast wymyślać eleganckie rozwiązanie. To samo dotyczy projektów, ale ponieważ są one znacznie większe, jest to mniej oczywisty problem (jest to również ryzyko projektu, ale to inna odpowiedź).

5. Pieniądze - praca pomocnicza płaci dużo mniej.

6. Jest to bardzo specyficzne dla firmy

(i) Projekt od podstaw to taki, który zupełnie nowy. Termin pochodzi z branży budowlanej; zanim będziesz miał budynek, jest tylko puste pole. Brownfield to miejsce, w którym wcześniej mógł znajdować się budynek, a stare rzeczy są ponownie wykorzystywane.

Zastrzeżenie: Jestem wykonawcą i wykonałem wiele obu rodzajów prac. Obecnie przeprowadzam konserwację.

Zmień pytanie. Zamiast tego zapytaj, dlaczego autorzy wolą pisać nowe książki zamiast redagować książki innych ludzi? Jeśli spojrzysz na to w ten sposób, powód, dla którego programiści preferują nowe projekty, powinien być oczywisty. Programiści są z natury twórcami.

Ale chcę tu poruszyć mniejsze wyzwanie związane z ramkami, ponieważ widzę dość dużą czerwoną flagę. Jeśli twoi programiści zostają z tobą tylko 4-9 miesięcy, masz poważny problem, który wykracza poza zwykły nowy kod vs. konserwację. Czy na pewno w środowisku nie ma toksycznego pierwiastka? A może kod jest tak niedbale łączony, że opiekunowie nie chcą brać za to odpowiedzialności? Czy zarządzanie Twoim projektem jest nieprzyjemne i przesuwa nieracjonalne terminy? 4-9 miesięcy to niezwykle krótki, przeciętny staż, nawet w tym zawodzie.

Jedną z rzeczy, na które warto zwrócić uwagę, jest pozbycie się pomysłu posiadania grupy „nowy programista” i „konserwująca”. Programiści tworzący „nowe” oprogramowanie powinni je utrzymywać. W ten sposób rozwijają się programiści - otrzymują informacje zwrotne na temat wykonanej pracy i mają szansę ją ulepszyć i uczyć się na tym doświadczeniu. Wszyscy programiści powinni być zaangażowani zarówno w nowy rozwój, jak i utrzymanie swojej poprzedniej pracy.

Odpowiedź Mateusza już omówiła większość problemów związanych z pracami konserwacyjnymi, chociaż przyszli pracodawcy nazwałbym niektóre rzeczy nieco krótkowzrocznymi. Dobry programista Java 7 może z łatwością nauczyć się nowszych standardów. Jest jednak jeden aspekt, który powstrzymywałby mnie od czystej pracy związanej z konserwacją: To może być niesamowicie frustrujące i masz wrażenie, że nic nie da się zrobić

Jesteśmy tylko małym zespołem i dlatego każdy zajmuje się zarówno konserwacją, jak i rozwojem. Jednak każde oprogramowanie ma części, które „po prostu pracowały” przez wieczność, napisane przez ludzi, którzy odeszli lata temu. Niektóre z tych części poprzedzają wiele naszych ulepszeń jakości. Nie ma odpowiedniej dokumentacji (lub takiej, którą można znaleźć). Nie ma pokrycia testowego. Kod w tych częściach może być nieuporządkowany i „zoptymalizowany” w dziwny sposób, co powoduje, że wiele niewidocznych granic zostaje przekroczonych, gdy próbujesz coś zmienić.

Gdy tylko jedna z tych części przestaje działać, Czuję się jak archeolog analizujący każdy prawdopodobnie nieistotny szczegół, który może mieć znaczenie. W tych systemach zawężenie problemu może być trudne, ponieważ trudno je oddzielić od ich zależności. W końcu mogłeś spędzić 2 dni i na poprawkę składającą się z jednej linii kodu.

A najgorsze jest to, że nie możesz tego naprawić naprawdę, ponieważ gdy projekt lub wersja produktu jest w trakcie konserwacji tryb, nie dostaniesz zasobów na większe przepisanie. Jeśli w ogóle możliwa jest zmiana całościowego obrazu

Co więcej, nawet utrzymanie własnego kodu może być prawdziwym problemem. Gdy pojawi się na wolności, debugowanie jest znacznie trudniejsze. Zamiast dołączać debugger, czytasz dzienniki i masz nadzieję, że wybrałeś odpowiedni poziom instrumentacji. Wiele problemów w środowisku naturalnym zależy od działań użytkownika lub, co gorsza, od danych. Powielanie takich wydań wymaga dużo współpracy z klientami, co nie jest zbyt zabawne.

Dodawanie do @Matthew Gaiser

Stworzenie produktu, który można konserwować, jest trudne. Stworzenie produktu wymagającego niewielkiej konserwacji jest jeszcze trudniejsze.

Biorąc pod uwagę wybór, programiści nie robią tego (a większość z nich i tak nie jest w stanie). Są opłacani, promowani i chwaleni za dodawanie funkcji i stale dodają funkcje i stają się dobrzy w dodawaniu funkcji. Przypadki narożne, obsługa błędów lub lepiej, wybory projektowe wymagające intensywnego myślenia pozostają w tyle.

I albo całkiem dobrze wiedzą, co zrobili (jeśli są uczciwi wobec siebie), albo stawiają czoła prawdzie w raczej nieprzyjemny sposób kiedy projekt zostanie wdrożony.

Witaj w piekle konserwacji.

--- edit:

Utrzymanie jest bardzo podobne do rozwoju. Sprawiasz, że wszystko działa. Z wyjątkiem ...

1. Presja ze strony ludzi używających produktu i potrzebujących, aby działał teraz. Sposób, w jaki zostali wyszkoleni lub do czego są przyzwyczajeni.

2. Odpowiedzialność. To ty zostaniesz zwolniony za utratę królewskich danych, a nie programista „gwiazda rocka”, który nigdy nie widzi danych użytkowników.

3. Ograniczenie złych wyborów projektowych tych osób. gwiazdy rocka ”, które to napisały (jest jeszcze gorzej, jeśli to ty jesteś gwiazdą rocka).

4. Złożone wskaźniki sukcesu: ... cóż, to skomplikowane. Masz dużo winy. Zobacz inne odpowiedzi.

5. Ogólnie mniej kompetentni i mniej zmotywowani ludzie zajmujący się konserwacją (lub pracujący z tymi osobami, jeśli pozostajesz w utrzymaniu).

Inne odpowiedzi mówiły o tym, jak wiele radości daje praca nad projektem od podstaw, ale są też dobre i złe sposoby zarządzania projektami konserwacyjnymi. Dobry sposób zapewnia wiele możliwości ulepszeń inicjowanych przez programistów i myślę, że większość programistów uważa to za prawie równie satysfakcjonujące. Zły sposób to ciągłe marnowanie czasu na to, co powinno być prostymi poprawkami, a następnie wyrzucanie go za każdym razem, gdy sugerujesz ulepszenia, które mogą przyspieszyć, takie jak refaktory lub automatyzacja testów i wdrożeń.

Jest to oparte na opiniach, ale tworzenie bałaganu jest fajniejsze niż jego sprzątanie.

Konserwacja

Ogólnie naprawiasz rzeczy, które nie zostały wykonane poprawnie. Często nie jest to Twoja wina. To może być prawdziwy błąd, przeoczenie, inni programiści są leniwi lub niedoświadczeni, dziwaczna luneta, przestarzała technologia itp ...

Odpowiadasz za to, że coś nie działa, nawet jeśli to nie była twoja wina . To stresujące i poniżające.

(niektórzy programiści uwielbiają znajdować i naprawiać problemy, inni nienawidzą tego)

Rozwijanie

Ty ponownie twórca. Otrzymujesz pochwały za to, że wszystko idzie dobrze. Kiedy później wykrywane są problemy, jest to problem z konserwacją.

Możliwe rozwiązania

Być może Twój problem dotyczy bardziej kultury i procesów. Upewnij się, że programiści budują rzeczy zgodnie z wysokim standardem, z jasno określonymi specyfikacjami i procesami.

Przed zakończeniem projektu zorganizuj spotkanie, aby zaplanować kolejny projekt, dając im coś, na co mogą oczekiwać , dzieląc swój czas między konserwację i nowy projekt.

Programiści chcą rozwijać (tworzyć), nie umieszczać nikogo w grupie zajmującej się wyłącznie konserwacją (kozłem ofiarnym).

Powtórzę zdanie GrandmasterB, mówiąc, że jeśli twoi programiści zostają tylko na 4-9 miesięcy, to problemem nie jest fakt, że ci programiści są poddawani konserwacji. Masz większy problem, a ludzie, którzy odchodzą z Twojej firmy i mówią Ci, że to z powodu prac konserwacyjnych, po prostu próbują pokryć prawdziwy problem. Chociaż nie mogę mówić w imieniu innych, jednym z powodów, dla których mógłbym zrobić coś takiego, byłoby to, że czuję, że gdybym poruszył prawdziwy problem, nie zostałbym wysłuchany. Może coś takiego jak toksyczny menedżer, który jest w firmie od lat i kierownictwo go kocha, ale wszyscy jego bezpośredni podwładni narzekają na niego, ale HR nigdy nic nie robi, ponieważ uważają, że jest świetny i przynosi wyniki. Czy znasz kogoś, kto mógłby pasować do tego opisu w Twojej organizacji? (wskazówka: jeśli nie, to możesz być ty). Możesz przeszukać swoją firmę w Glassdoor i zobaczyć, co ludzie mówią o Twojej firmie; ludzie są bardziej uczciwi, gdy są anonimowi, i możesz znaleźć prawdziwy powód. Przeglądając recenzje Glassdoor, ważne jest, aby zrozumieć, że większość ludzi nie próbuje cię oczerniać, udzielają prawdziwych rad opartych na ich prawdziwych doświadczeniach, a wiele firm przyjmuje obronę, gdy mówi się, że mają problem, podczas gdy powinieneś być introspekcyjny i spróbuj rozwiązać problem.

Oto kolejne pytanie, które może wyjaśnić, w jaki sposób Twoja firma może być prowadzona na poziomie makro: Załóżmy, że dołączam do Twojej firmy. Przekazałeś mnie do projektu na pierwsze 6 miesięcy, potem kończę projekt i zlecasz mi utrzymanie na resztę mojej kadencji w firmie. Następnie chcesz rozpocząć nowy projekt, więc zatrudniasz kogoś innego. Następnie przechodzą na konserwację. Następnie zaczynasz nowy projekt, zatrudniasz kogoś innego i tak dalej. W międzyczasie ja i drugi facet nadal jesteśmy w firmie, jesteśmy zdolnymi programistami, którzy mogliby wykonać projekt, a ty nie wykorzystujesz nas do spełnienia swoich potrzeb projektowych. Pomijając fakt, że sprawia to, że czujemy się bezużyteczni, ponieważ nie wykonujemy „interesującej” pracy nad projektem, oznacza to również, że baza kodu jest bałaganem, ponieważ za każdym razem, gdy robisz nowy projekt, zatrudniasz nowych ludzi, którzy przychodzą do firmy z własnymi standardami, doświadczeniami i stylami. Zwiększa to koszt utrzymania Twojej usługi jako całości, ponieważ oprócz regularnych czynności konserwacyjnych, takich jak jakość danych i selekcja błędów, my (konserwatorzy) musimy również zrozumieć potencjalnie dziesiątki lub setki różnych stylów kodowania od różnych osób, niektóre z nich którzy mogli opuścić firmę po przesłaniu swojego kodu.

Realistycznie nie powinno być „zespołu projektowego” i „zespołu konserwacyjnego”. Powinieneś podzielić swój zespół według obowiązków lub domen, a wtedy każdy programista w każdym zespole jest odpowiedzialny zarówno za nowy rozwój, jak i utrzymanie tego, co jest w jego domenie. Następnie masz liderów zespołów lub menedżerów technicznych, którzy dzielą te zadania między członków swojego zespołu, aby każdy miał przyzwoity udział zarówno w nowych zadaniach związanych z rozwojem, jak i konserwacją.

Kolejną czerwoną flagą dotyczącą Twojej firmy jest to, że w ogóle czujesz potrzebę posiadania „zespołu konserwacyjnego”, tj. zespołu programistów, którzy pełnią służbę konserwacyjną w pełnym wymiarze godzin. To wiele mówi o jakości kodu aplikacji. Błędy na pewno się zdarzają, ale jeśli masz tak wiele błędów, że masz zespół, którego podstawową odpowiedzialnością jest latanie od jednego błędu do drugiego, aby gasić pożary, warto rozważyć przepisanie aplikacji, ponieważ nie jest to przypuszczalne wydarzyć się. Wynika to z zatrudniania złych programistów, a źli programiści to także ludzie, którzy mogą odejść w ciągu 4-9 miesięcy, na przykład „oto mój kiepski kod, teraz to twój problem, do zobaczenia” (nie żeby dobrzy programiści nie mają powodów, , ale źli programiści mają więcej powodów, aby szybko odchodzić). Prawdopodobnie powinieneś również przyjrzeć się pakietowi wynagrodzeń dla swoich pracowników i porównać go ze stawkami rynkowymi, aby sprawdzić, czy może nie przyciągasz talentów. Talent przyciąga więcej talentów; Chciałbym pracować z ludźmi, którzy są mądrzejsi ode mnie, ale jeśli wszyscy inni są mniej wykwalifikowani ode mnie, to nie mam prawdziwego powodu, aby zostać, ponieważ nie uczę się ani nie robię nic ciekawego i ciągle muszę naprawiać innych ludzie to zły kod, ponieważ nikt nie pisze kodu tak dobrego jak mój.

Krótko mówiąc:

1) Prawdopodobnie masz problem w swojej organizacji w postaci kogoś toksycznego w zarządzaniu. Dowiedz się, kto to jest i pozbądź się ich.

2) Prawdopodobnie powinieneś podzielić swoje zespoły na domeny projektowe, a nie utrzymanie kontra projekt, i mieć kierowników zespołów, którzy dzielą zadania związane z projektami i konserwacją, aby utrzymać programiści są zadowoleni.

3) Prawdopodobnie powinieneś podnieść stawki wynagrodzenia, aby przyciągnąć talenty, które potrafią tworzyć lepszy kod, więc musisz wykonywać mniej czynności konserwacyjnych. Możesz także zechcieć porzucić obecną aplikację i całkowicie ją przebudować, gdy będziesz mieć na pokładzie dobry talent, aby zmniejszyć koszty utrzymania.

Podoba mi się odpowiedź Matta, ale chcę dodać przykład, jeśli nie został jeszcze udostępniony. Załóżmy, że ktoś zbudował dom i teraz ta sama osoba chodzi po nim, konserwując go. Byłoby to dość nudne, głównie dlatego, że znajdziesz typowe przedmioty, które się psują, a są szanse, że wszystko inne jest głównie nieporozumieniem co do tego, jak coś działa. Spędzisz więcej czasu nie robiąc nic, niż coś robiąc. Pewnie, że pojawiają się nowe projekty, które mogą pojawiać się tu i ówdzie i być może w pewnym momencie mogą pojawić się rozszerzenia domu, ale ogólnie rzecz biorąc, Twój czas jest spędzany na zwykłych pracach konserwacyjnych i awariach.

Myślę, że większość programistów chce czegoś trudniejszego niż robienie prostych czynności konserwacyjnych, zwłaszcza jeśli technologia jest stara, bez prawie nic nowego do nauczenia, żadnego nowego języka / frameworka / itp. Więc utkniesz w czymś, co do niczego nie doprowadzi, czego nie możesz wykorzystać później w swojej karierze, jeśli zmienisz pracę. Uważam też, że jest to nudne, mało pracochłonne, mało inspirujące

Jestem programistą i nie lubię też konserwacji, rzeczywiście można to porównać do prac porządkowych. Najlepszą rzeczą w mojej pracy jest kreatywność i tworzenie rzeczy od podstaw. Ale kiedy robisz konserwację:

1. Tracisz dużo czasu na rozumienie cudzego kodu, który często jest nieuporządkowany
2. Nie wykorzystujesz swojej kreatywności, tylko modyfikujesz coś, co już istnieje i musisz dostosować się do już istniejącej struktury
3. Co najważniejsze: już istniejący kod może stanowić nieprzejrzystą warstwę między technologią, której próbujesz się nauczyć, a Tobą . Kod będący własnością firmy jest często bezwartościowy poza firmą, podczas gdy ogólne technologie i frameworki (np. Nauka Django) mogą być bardzo przydatne i cenione poza firmą, a także bardzo interesujące.
4. Wraz z rozwojem bazy kodu złożoność rośnie, a wprowadzanie małych zmian staje się bardzo złożone, co może być demotywujące

Powód 2 i 3 mogą zabijać motywację. Ostatnią rzeczą, którą chciałbym usłyszeć jako młodszy programista, jest to, że ktoś z większym doświadczeniem niż ja stworzył coś, czego powinienem użyć, ponieważ nie mam wystarczających umiejętności, aby coś stworzyć. Drugi powód może być prawdziwy lub fałszywy, ale chcę się czegoś nauczyć. Poleganie na czyimś kodzie to tak, jakby zamiast nauczyć się prowadzić samochód, ktoś stworzy dla Ciebie interfejs, który ostatecznie (1) uniemożliwia Ci naukę prowadzenia samochodu, co jest interesujące i wartościowe, oraz (2) zapobiega przejęciu kontroli nad samochodem. Bo jakie to może być trudne, ostatnią rzeczą, którą chcesz usłyszeć, jest to, że nie uczysz się tego robić samemu.

Obawiam się, że jako junior nie mam wystarczającego doświadczenia, aby podać konkretną listę działań, które okazały się skuteczne. Ale wszystko, co mogę powiedzieć, to to, że deweloper (jeśli jest pasjonatem) postrzega firmę jako okazję do nauki, a nie tylko jako źródło pieniędzy. To, co możesz zrobić, aby zachęcić programistę zajmującego się konserwacją, to pozwolić mu na kreatywność, na przykład pozwalając mu na przepisywanie części aplikacji przy użyciu nowych technologii i umieszczanie w niej swojej kreatywności.