Czy dedykowane prace konserwacyjne utrudniają karierę programisty? [Zamknięte]

Większość moich prac w ciągu ostatnich trzech lat dotyczyła głównie utrzymywania starszych systemów, które wymagały łatania lub sporadycznych przeróbek, zanim znów zostaną sprzedane.

Rozumiem kluczową rolę, jaką specjaliści od konserwacji muszą odgrywać w firmach z dużą liczbą projektów i ograniczoną liczbą programistów.

Ale kiedy oceniam mój obecny rozwój kariery i patrzę na moich rówieśników; zarówno wykonawcy, jak i deweloperzy korporacyjni; Czuję się, jakbym pozostawał daleko w tyle, ponieważ zyskałem dużą szerokość pod względem obszarów, których dotknąłem, ale nie za dużo głębi. Zacząłem zajmować się tym, zakładając bloga, pracując nad własnymi małymi projektami git-hub i zmieniając harmonogram życia, aby mieć czas na osobiste kodowanie po pracy.

Wydaje mi się, że gdybym przeprowadził wywiad w innych firmach w celu uniknięcia prac konserwacyjnych, musiałbym reprezentować siebie jako osobę o niższych umiejętnościach, ponieważ nie posiadałbym głębokości wiedzy wymaganej od osoby z trzyletnim doświadczeniem skoncentrowanej na konkretnym ścieżka rozwoju funkcji. Tak więc połowa mojego obecnego doświadczenia zawodowego byłaby bezużyteczna na dłuższą metę.

Ale to prowadzi mnie do moich głównych pytań, przepraszam, jeśli wydaje mi się to zbyt skoncentrowane wokół mojego osobistego dylematu:

Czy dedykowane role w programowaniu konserwacji kończą się na początku kariery? Czy inni programiści mają prawo unikać takich ról? Czy wykonywanie tej linii pracy blokuje cię w wykonywaniu podobnych zadań, chyba że jesteś przygotowany na rozpoczęcie od nowa jako junior?

Czy dedykowane role w programowaniu konserwacji kończą się na początku kariery? Czy inni programiści mają prawo unikać takich ról? Czy wykonywanie tej linii pracy blokuje cię w wykonywaniu podobnych zadań, chyba że jesteś przygotowany na rozpoczęcie od nowa jako junior?

Po pierwsze, powinieneś wiedzieć, że przez dłuższy czas jesteś uważany za młodszego. Możesz dostać arbitralne promocje, ponieważ jesteś dobry i jest to jedyny sposób, aby zapewnić ci przyzwoitą wypłatę, ale nadal będziesz uważany za młodszego, gdy przejdziesz do następnej pracy.

Po drugie, jeśli zatrudniam kogoś z 2-4-letnim doświadczeniem, tak naprawdę nie dbam o to, czy ich praca była czysto konserwacyjna. Jeśli spędziłeś 10 lat na utrzymaniu, a ja zatrudniam do projektu typu greenfields, mogę mieć pytania, ale przez pierwsze kilka lat naprawdę tego oczekuję.

Z drugiej strony, jeśli zatrudnię kogoś, kto NIGDY nie pracował w zakresie konserwacji, będę bardziej podejrzliwy. Miałem wielu kandydatów do pracy, którzy spędzili pierwsze 4 lata na przechodzeniu od jednej „dobrej” pracy do drugiej i każdy z nich nie nauczył się niczego, co stanowi o kodzie, który można utrzymać. I nie pomylcie się, jeśli zatrudniam projekt Greenfields, z którym zamierzam się trzymać, nie dbam o to, czy macie zamiar zachować kod, zależy mi na tym, abyście wiedzieli, jak zachować go dla przyszłych programistów.

Ci inni programiści, o których wspominasz, którzy unikają takich miejsc pracy, na ogół unikają ich, ponieważ są mniej zabawni, a nie dlatego, że utrudniają ich karierę.

Na koniec powinieneś wiedzieć, że bardzo duży odsetek (domyślnie sądzę, że około 80%) zadań programistycznych to ponad 50% konserwacji.

Tak więc, aby przejść przez to wszystko i odpowiedzieć na twoje pytanie: Nie, nie sądzę, że to utrudni twoją karierę. Chyba że zostaniesz tam zbyt długo. Powszechnie stosowana zasada brzmi: „gdy zaczniesz czuć, że każdego roku masz ten sam rok doświadczenia, nadszedł czas, aby odejść”. Jeśli czujesz, że każdego roku jesteś lepszym programistą niż w zeszłym roku, nic ci nie jest (i to dotyczy mnie przez 20 lat mojej kariery, tak samo jak ty).

W każdej pracy zdobywane doświadczenie jest specyficzne dla tego, co robisz, co ogranicza Twój zakres możliwości podczas ubiegania się o inne prace oparte na tym doświadczeniu. Nie dotyczy to konserwacji. Myślę, że inne pytania są ważniejsze niż to, czy coś jest konserwacją czy rozwojem nowego oprogramowania:

• Jak rozpowszechnione są konkretne technologie, z którymi pracujesz? Jeśli utrzymujesz coś, co jest przestarzałe i rzadko używane gdzie indziej, to ograniczyłoby twoje przyszłe możliwości kariery (ale tak samo by opracowało nowe oprogramowanie dla systemu / platformy / technologii, które nie jest powszechnie używane).
• W jaki sposób Twoja obecna praca przygotowuje Cię do pracy, którą chcesz wykonywać w przyszłości? Jak zauważyłeś, prace konserwacyjne są ważne i zawsze będą w pobliżu. Nie ma nic złego w karierze skoncentrowanej na tego rodzaju programowaniu; opiekunowie systemu zawsze będą mieli wiele możliwości. Ale może to nie jest to, co ty chcesz zrobić. Niepokoi Cię to, że Twoja obecna praca nie przygotowuje Cię na to, co Cię interesuje.

Nie martwiłbym się jednak zbytnio. Mówisz tylko:

Zyskałem dużo przestrzeni pod względem obszarów, których dotknąłem, ale niewiele głębi.

Nie traktuj tego jako problemu, ponieważ można go wykorzystać na swoją korzyść. Bogate doświadczenie oznacza, że ​​istnieje szeroki zakres rzeczy, na które można powiedzieć „tak, zrobiłem to”. Wiele miejsc pracy wymaga doświadczenia w kilku różnych technologiach i zadaniach. Prawdopodobnie miałbyś przewagę nad programistą, który ma bardzo duże doświadczenie w jednej technologii.

Ponadto wiele miejsc pracy wymaga połączenia konserwacji i nowych rozwiązań. Jeśli chcesz zrobić więcej nowych prac rozwojowych, możesz wykorzystać swoje dotychczasowe doświadczenie w zakresie konserwacji, aby przejść do mieszanej roli, która zapewni ci więcej doświadczenia w programowaniu.

Podsumowując, twoje CV jest prawdopodobnie lepsze niż ci się wydaje. Wiele z tego sprowadza się do tego, jak dobrze analizujesz mocne strony swojego doświadczenia, a następnie przekazujesz te mocne strony w procesie składania wniosku i rozmowy kwalifikacyjnej.

Czy dedykowane role w programowaniu konserwacji kończą się na początku kariery?

Częściej niż nie - TAK, przy założeniu:

• ta kariera tutaj oznacza znajomość wielu różnych umiejętności technicznych.
• że spędzasz tam więcej niż X lat, gdzie X wystarcza, by „ustalić” sposób myślenia.
• że nic nie robisz na bok.
• ten „dedykowany opiekun” (patrz EDYCJA, poniżej) oznacza, że ​​nie kodujesz w celu utrzymania, a także kodujesz nowe rzeczy, ale że prawie zawsze kodujesz w celu utrzymania lub nawet pracy nad projektem w trybie konserwacji - brak nowych funkcji, wymagane minimum zmiany w kodzie, aby naprawić błąd.

Nie oznacza to, że zawsze tak jest.

Osoby utrzymujące oprogramowanie rzadko są zachęcane (patrz EDYCJA, poniżej) do prowadzenia badań, rzadko mogą podłączyć nową bibliotekę lub bazę danych i spędzić kilka dni na sprawdzaniu, jak to działa. Jest to (zwykle) stałe zadanie, które wymaga minimalnych zmian w istniejącej bazie kodu, a tym samym „kształtuje” sposób, w jaki podchodzisz do problemów później. Mogę wymienić wiele firm, które mają zasady utrzymywania oprogramowania, które wyraźnie stwierdzają „mniej zmian w kodzie = lepiej”, pomimo złych rzeczy, które może to przynieść.

Czy inni programiści mają prawo unikać takich ról?

Znam bardzo dobrych opiekunów, którzy lubią swoją pracę i nie chcieliby ubiegać się o coś innego, ponieważ jest tam wygodnie. Nie każdy lubi uczyć się nowych rzeczy od czasu do czasu. Więc - unikaj lub szukaj w zależności od twoich preferencji.

Czy wykonywanie tej linii pracy blokuje cię w wykonywaniu podobnych zadań, chyba że jesteś przygotowany na rozpoczęcie od nowa jako junior?

Częściej niż nie - TAK. Ponieważ masz już takie doświadczenie, ponieważ „znasz liny” itp. Ale zmiana jest zdecydowanie możliwa i może się zdarzyć bez ubiegania się o stanowisko młodszego pokolenia. Już zacząłeś robić rzeczy na bok, trzymaj się tego! To jest naprawdę bardzo opłacalne i może zmniejszyć zauważoną przez ciebie „lukę umiejętności”.

EDYCJA: Dan zwrócił uwagę (bardzo słusznie), że zadania konserwacyjne często można wykonać ZA POMOCĄ badań. To prawda. Zmieniłem powyższą odpowiedź w dwóch miejscach, aby lepiej rozwiązać ten problem.

Takie zadania na pewno MOGĄ być wykonane w ten sposób, a jeśli są - świetnie! Jednak większość DEDYKOWANYCH opiekunów systemów LEGACY AFAIK ma zasady lub oczekiwania kierownictwa i terminy, które - częściej niż nie - zmuszają ich do rozwiązania problemu przy możliwie najmniejszych zmianach. Często presja jest na tyle wysoka, że ​​nawet jeśli możesz to zrobić w ten sposób, możesz tego nie chcieć. Zwłaszcza jeśli nie jest to TWÓJ kod: bez teorii (jak na Ryle'a i Naura) ryzykujesz bardziej uszkodzenie niż naprawisz.

Niemniej jednak należy zauważyć: nie mam twardych danych globalnych, mówię z własnego doświadczenia - pracowałem jako OP, rekrutowałem ludzi z 4-10-letnim doświadczeniem jako opiekunów, rozmawiałem z wieloma opiekunami i ja znać osoby pracujące jako oddani opiekunowie . Nie tylko ludzie, którzy kodują nowe rzeczy, ale także kodują utrzymanie projektu - dedykowani opiekunowie, których jedynym zadaniem jest poprawianie błędów i łatek, a nawet nie jedna nowa funkcja, ponieważ jest to stary projekt i teraz jest on tylko w „trybie konserwacji”.

Musiałbym przedstawić się jako młodszy na poziomie umiejętności, ponieważ nie posiadałbym tak dużej wiedzy wymaganej od osoby z trzyletnim doświadczeniem skoncentrowanej na konkretnej ścieżce rozwoju funkcji

Poprawny. Nie byłby w stanie powiedzieć „3 lata doświadczenia projektowania systemów od podstaw za pomocą X, Y i Z”, trzeba powiedzieć „3 lata doświadczenia OBSŁUGA systemy od podstaw za pomocą X, Y i Z”, o ile chcesz po prostu połóż się na swoim CV.

Wydaje mi się, że gdybym przeprowadził wywiad w innych firmach w celu uniknięcia prac konserwacyjnych, musiałbym reprezentować siebie jako osobę o niższych umiejętnościach, ponieważ nie posiadałbym tak dużej wiedzy wymaganej od osoby z trzyletnim doświadczeniem skoncentrowanej na konkretnym ścieżka rozwoju funkcji

Jeśli chcesz powiedzieć „projektuję i buduję systemy od zera”, to tak, musiałbyś zaklasyfikować się jako młodszy.

To, co jest dość powszechne w IT (i nie mówię, że to właśnie robisz) polega na tym, że ludzie zakładają, że ponieważ pracują od X lat, mają X-letnie doświadczenie i po {nieokreślonej liczbie lat} należy uznać za starszego programistę {Widget}.

Nie zrozumcie mnie źle, nie ma nic złego w pracach konserwacyjnych, wszyscy muszą to zrobić w tym czy innym czasie, ale zdaliście sobie sprawę, że zbyt długie utknięcie w tym może utrudniać odejdź od tej roli w przyszłości. Często towarzyszy temu „utknięcie” w nauce nowych technologii / narzędzi / metod.

Idealnie, potrzebujesz mieszanki „nowej” pracy systemowej i pracy starszej generacji.

Mówiąc pozytywnie, prawdopodobnie widziałeś wiele różnych architektur (dobrych i złych), różnych podejść, w jaki sposób złe decyzje mogą sprawić, że starsze programiści będą pracować znacznie ciężej. Wszystkie są pozytywne, niż można zaakcentować.

Powodzenia!

Patrząc na to z innej perspektywy, uważam, że sprzedaż siebie jako eksperta w dziedzinie konserwacji jest szansą na sprzedaż.

Jako właściciel firmy programistycznej, która ma wiele projektów w ruchu, jednym z największych zagrożeń, które muszę zminimalizować, są programiści, którzy skaczą na statek, a następnie utrzymanie ich kodu.

Więc zakładając, że jesteś zdolny do rosnącej pasji do prac konserwacyjnych (co, jak sądzę, jest tak, ponieważ jesteś gotowy na blogowanie o swoich doświadczeniach), jeśli przyszedłeś do mnie, oferując swoje usługi jako guru konserwacji - gwarantując polerowanie wszystkich z różnych projektów moich programistów poprzez refaktoryzację, optymalizację i dokumentację ich kodu w celu zapewnienia długoterminowej konserwacji - a ty miałeś doświadczenie w tworzeniu kopii zapasowej gwarancji, zatrudnię cię błyskawicznie.

Radzę spróbować tego. Ustaw się jako ekspert ds. Konserwacji i pielęgnuj swojego bloga. Możesz być na czymś.