I lavori di manutenzione dedicati ostacolano la carriera di un programmatore? [chiuso]

La maggior parte del mio lavoro negli ultimi tre anni ha riguardato in gran parte il mantenimento di sistemi legacy che necessitavano di patch o il rinnovo occasionale prima di essere venduti di nuovo.

Comprendo il ruolo fondamentale che i programmatori di manutenzione dedicati devono svolgere nelle aziende con un gran numero di progetti e sviluppatori limitati a portata di mano.

Ma mentre giudico i miei progressi in carriera e guardo i miei colleghi; appaltatori e sviluppatori aziendali simili; Mi sento in ritardo rispetto a quando ho guadagnato molta ampiezza in termini di aree che ho toccato ma non molto in profondità. Ho iniziato a risolvere questo problema avviando un blog, lavorando sui miei piccoli progetti git-hub e riprogrammando la mia vita per avere il tempo di scrivere codice personale dopo il lavoro su base regolare.

Sento che se dovessi intervistare altre aziende per sfuggire ai lavori di manutenzione, dovrei rappresentare me stesso come un livello di abilità piuttosto giovane poiché non avrei la profondità del livello di conoscenza richiesto a una persona con tre anni di esperienza focalizzata su un particolare percorso nello sviluppo di funzionalità sarebbe. Quindi, a lungo termine, metà della mia attuale esperienza lavorativa sarebbe nulla.

Ma questo mi porta alle mie domande principali, mi scuso se questo sembra troppo centrato sul mio dilemma personale:

I ruoli di programmazione di manutenzione dedicati finiscono per essere dannosi per una carriera iniziale? Altri programmatori hanno ragione a evitare ruoli come questi? Fare questa linea di lavoro ti blocca nel fare compiti simili a meno che tu non sia pronto a ricominciare da capo?

I ruoli di programmazione di manutenzione dedicati finiscono per essere dannosi per una carriera iniziale? Altri programmatori hanno ragione a evitare ruoli come questi? Fare questa linea di lavoro ti blocca nel fare compiti simili a meno che tu non sia pronto a ricominciare da capo?

Prima di tutto, dovresti sapere che sei considerato un giovane per un bel po '. Potresti ottenere promozioni arbitrarie perché sei bravo e questo è l'unico modo per darti un guadagno decente, ma sarai comunque considerato un giovane mentre vai al tuo prossimo lavoro.

In secondo luogo, se sto assumendo qualcuno con 2-4 anni di esperienza, non mi interessa davvero se il loro lavoro fosse puramente manutenzione. Se hai trascorso 10 anni in manutenzione e sto assumendo per un progetto greenfields, potrei avere delle domande ma, per i primi anni, onestamente mi aspetto che me lo aspetti.

D'altra parte, se sto assumendo qualcuno che non ha MAI lavorato nella manutenzione, sarò più sospettoso. Ho avuto molti candidati per lavori che hanno trascorso i loro primi 4 anni saltando da un lavoro "buono" a un altro e ognuno non ha imparato nulla su ciò che rende il codice gestibile. E, non commettere errori, se sto assumendo per un progetto greenfields con cui intendo attenermi, non mi interessa se manterrai il codice, mi importa che tu sappia come lasciarlo mantenibile per i futuri sviluppatori.

Questi altri programmatori che menzioni, che evitano lavori come questi, generalmente li evitano perché sono meno divertenti, non perché ostacolano la loro carriera.

Infine, dovresti sapere che una percentuale molto grande (immagino prudentemente di circa l'80%) dei lavori di sviluppo software ha una manutenzione superiore al 50%.

Quindi, per tagliare tutto questo e rispondere alla tua domanda: No, non penso che ostacolerà la tua carriera. A meno che tu non ci resti troppo a lungo. La regola empirica comune è "una volta che inizi a sentirti come se avessi lo stesso anno di esperienza ogni anno, è ora di andare". Se ti senti, ogni anno, come se fossi uno sviluppatore migliore di quello dell'anno scorso, stai bene (e questo vale per me, 20 anni nella mia carriera, tanto quanto te).

In qualsiasi lavoro, l'esperienza che ottieni è specifica per quello che stai facendo, il che limita la tua gamma di possibilità quando ti candidi per altri lavori basati su quell'esperienza. Non è specifico per la manutenzione. Penso che altre domande siano più rilevanti del fatto che si tratti di manutenzione o sviluppo di nuovi software:

• Quanto sono diffuse le tecnologie specifiche con cui stai lavorando? Se stai mantenendo qualcosa che è obsoleto e usato raramente altrove, ciò limiterebbe le tue future opportunità di carriera (ma lo stesso farebbe lo sviluppo di nuovo software per un sistema / piattaforma / tecnologia che non è ampiamente utilizzato).
• In che modo il tuo lavoro attuale ti equipaggia per il lavoro che vorresti fare in futuro? I lavori di manutenzione, come hai sottolineato, sono importanti e saranno sempre disponibili. Non c'è nulla di sbagliato nell'avere una carriera focalizzata su questo tipo di programmazione; ci saranno sempre molte possibilità per i manutentori del sistema. Ma forse non è quello che vuoi fare. È preoccupante se il tuo lavoro attuale non ti sta preparando per quello che ti interessa.

Tuttavia, non sarei troppo preoccupato. Una cosa che dici è:

Ho guadagnato molta ampiezza in termini di aree che ho toccato, ma non molto in profondità.

Non pensare a questo come un problema, perché può essere usato a tuo vantaggio. Avere una vasta esperienza significa che c'è una vasta gamma di cose a cui puoi dire "sì, l'ho fatto". Molti lavori richiedono esperienza in diverse tecnologie e attività. Avresti probabilmente un vantaggio rispetto a uno sviluppatore che ha un'esperienza molto profonda in una tecnologia.

Inoltre, molti lavori comportano un mix di manutenzione e nuovi sviluppi. Se si desidera effettuare ulteriori nuovi sviluppi, è possibile utilizzare l'esperienza di manutenzione esistente per passare a un ruolo misto che offrirà una maggiore esperienza di sviluppo.

In conclusione, il tuo curriculum è probabilmente migliore di quanto pensi. Gran parte di ciò dipenderà dal modo in cui analizzi i punti di forza della tua esperienza e poi comunichi tali punti di forza nel processo di domanda e colloquio.

I ruoli di programmazione di manutenzione dedicati finiscono per essere dannosi per una carriera iniziale?

Più spesso che no - SÌ, supponendo:

• quella carriera qui significa competenza in molte diverse abilità tecniche.
• che trascorri più di X anni lì, dove X è sufficiente per "impostare" il tuo modo di pensare.
• che non fai nulla da parte.
• quel "manutentore dedicato" (vedi EDIT, di seguito) significa che non devi programmare per mantenere così come programmare nuove cose, ma che quasi sempre codifichi per mantenere o persino lavorare su un progetto in modalità manutenzione - non sono necessarie nuove funzionalità modifiche nel codice per correggere il bug.

Questo non significa che sia sempre così.

Le persone che gestiscono il software raramente sono incoraggiate (vedi EDIT, di seguito) a fare ricerche, raramente possono collegare nuove librerie o DB e passare qualche giorno a scoprire come funziona. È (di solito) un lavoro stabile che richiede minime modifiche alla base di codice esistente e quindi "modella" il modo in cui affronti i problemi in seguito. Posso nominare un bel po 'di aziende che hanno una politica per la manutenzione del software che afferma esplicitamente "meno cambiamenti nel codice = migliore", nonostante le cose cattive che ciò può portare.

Altri programmatori hanno ragione a evitare ruoli come questi?

Conosco manutentori molto bravi a cui piace il loro lavoro e non vorrebbero fare domanda per qualcos'altro proprio perché è comodo dove si trovano. Non a tutti piace imparare cose nuove di tanto in tanto. Quindi - evita o cercalo a seconda delle tue preferenze.

Fare questa linea di lavoro ti blocca nel fare compiti simili a meno che tu non sia pronto a ricominciare da capo?

Più spesso che no - SÌ. Perché hai già esperienza nel farlo, perché già "conosci le corde" ecc. Ma il cambiamento è sicuramente possibile e può avvenire senza richiedere una posizione junior. Hai già iniziato a fare le cose da parte, continua così! In realtà è molto utile e può ridurre il "gap di abilità" che hai notato.

EDIT: Dan ha sottolineato (giustamente) che le attività di manutenzione possono spesso essere eseguite CON la ricerca. Questo è vero. Ho modificato la risposta sopra in due punti per affrontare meglio questo.

Sicuramente tali compiti POTREBBE essere svolti in questo modo e se lo sono - grandiosi! Tuttavia, i manutentori più DEDICATI di AFAIK dei sistemi LEGACY hanno politiche o aspettative di gestione e scadenze che - ancora una volta, il più delle volte - li costringono a risolvere il problema con il minimo cambiamento possibile. Spesso la pressione è abbastanza elevata che anche se puoi farlo in questo modo, potresti non volerlo. Soprattutto se non è il TUO codice: senza la teoria (secondo Ryle e Naur) si rischia di danneggiare più di quanto si risolva.

Tuttavia, va notato: non ho dati globali concreti, parlo per esperienza personale - ho lavorato in una situazione come OP, ho reclutato persone con 4 - 10 anni di esperienza come manutentori, ho parlato con molti manutentori e io conoscere persone che lavorano come manutentori dedicati . Non solo persone che codificano cose nuove, ma anche codice per mantenere un progetto - manutentori dedicati, il cui unico compito è fare bug e patch e nemmeno una nuova funzionalità, perché è un vecchio progetto ed è ora solo in "modalità di manutenzione".

Dovrei rappresentare me stesso come piuttosto giovane nel livello di abilità poiché non avrei la profondità del livello di conoscenza richiesto di una persona con tre anni di esperienza focalizzata su un particolare percorso nello sviluppo delle caratteristiche

Corretta. Non saresti in grado di dire "3 anni di esperienza nella progettazione di sistemi da zero usando X, Y e Z", dovresti dire "3 anni di esperienza nella MANUTENZIONE di sistemi da zero con X, Y e Z" a meno che tu non voglia bugia giusta sul tuo CV.

Sento che se dovessi intervistare altre aziende per sfuggire ai lavori di manutenzione, dovrei rappresentare me stesso come un livello di abilità piuttosto giovane poiché non avrei la profondità del livello di conoscenza richiesto a una persona con tre anni di esperienza focalizzata su un particolare percorso nello sviluppo di funzionalità sarebbe

Se vuoi dire "Progetto e costruisco sistemi da zero", allora sì, dovresti classificarti come junior.

Ciò che è abbastanza comune nell'IT (e non sto dicendo che questo è ciò che stai facendo) è che le persone presumano che, poiché hanno lavorato per X anni, hanno X anni di esperienza e dopo {numero indeterminato di anni} hanno dovrebbe essere considerato uno sviluppatore senior {Widget}.

Ora, non fraintendetemi, non c'è niente di sbagliato nel lavoro di manutenzione, tutti devono farlo in un momento o nell'altro, ma quello che avete capito è che rimanere bloccati per troppo tempo probabilmente vi renderà difficile allontanarsi da quel ruolo in futuro. Questo spesso va di pari passo con l'essere "bloccato" senza apprendere nuove tecnologie / strumenti / metodi.

Idealmente, vuoi un mix di "nuovo" lavoro di sistema e lavoro legacy.

Sul versante positivo, presumibilmente avete visto molte architetture diverse (buone e cattive), approcci diversi, come decisioni sbagliate possono far lavorare i programmatori legacy molto più duramente in futuro. Questi sono tutti aspetti positivi che possono essere accentuati.

In bocca al lupo!

Guardando questo da una prospettiva diversa, penso che venderti come esperto di manutenzione sia un'opportunità commerciabile.

Come proprietario di una società di software che ha più progetti in movimento, uno dei maggiori rischi che devo minimizzare sono gli sviluppatori che saltano la nave e il successivo mantenimento del loro codice.

Quindi supponendo che tu sia in grado di crescere appassionato di lavori di manutenzione (cosa che immagino essere il caso poiché sei pronto a blog sulla tua esperienza), se sei venuto da me offrendo i tuoi servizi come guru della manutenzione - garantendo di lucidare tutto dei vari progetti dei miei sviluppatori con il refactoring, l'ottimizzazione e la documentazione del loro codice per la manutenibilità a lungo termine - e tu avevi un track record a sostegno della tua garanzia, ti assumerei in un lampo.

Il mio consiglio sarebbe di provarlo. Posizionati come esperto di manutenzione e coltiva il tuo blog. Potresti essere su qualcosa.