Diventare uno "sviluppatore di manutenzione" [duplicato]

Puoi guardarlo come un tempo nel limbo; oppure puoi trasformarlo in un'opportunità per crescere.

L'idea principale di essere uno sviluppatore di manutenzione è di mettersi fuori da un lavoro . Ogni volta che devi aggiustare qualcosa; prenditi il tempo necessario per comprendere il problema abbastanza bene in modo che la tua soluzione (che potrebbe arrivare alcune settimane dopo aver spento il fuoco) significhi che tu (e nessun'altra anima vivente) dovrai mai risolvere il problema di nuovo.

Poiché si tratta di un sistema legacy che stai supportando, solitamente puoi ottenere un modo con alcune soluzioni che non sarebbero "ok" per i prodotti mainline; puoi usare cron per riavviare periodicamente i servizi buggy; È possibile eseguire una logica eccezionale per determinati clienti poiché il numero di clienti che utilizzano quel prodotto non aumenterà.

Un'altra parte di essa sta estraendo conoscenze utili dal sistema; Probabilmente non vuoi farlo, non è molto divertente; ma documentando ciò che fa il sistema di lavoro (anche se è sbagliato), puoi rendere più semplice il compito di mantenere quella parte dell'applicazione di un ordine di grandezza (dieci minuti per leggere due paragrafi che spiegano un modulo, invece di tre giorni leggendo il codice del modulo). Meglio ancora, questa stessa documentazione può essere utilizzata per implementare la funzionalità nel prodotto principale, così puoi smettere di supportare il sistema legacy del tutto (almeno per quella caratteristica).

Se sei il "go to guy" per un progetto, anche se si tratta di manutenzione legacy, probabilmente (o almeno, dovresti) avere una notevole libertà di approccio ai problemi a modo tuo. Ciò potrebbe significare riscrivere le sezioni nella tua lingua o piattaforma preferita, suggerendo soluzioni alternative anziché soluzioni, o semplicemente rispondendo a problemi con "non aggiustare, utilizzare prodotti supportati".

Modifica: potresti interpretare erroneamente l'intenzione del tuo capo; La manutenzione richiede un diverso insieme di competenze da altre parti del ciclo di sviluppo; Potrebbe metterti a fare un lavoro perché pensa che, tra tutte le persone che ha a disposizione, tu sei il migliore per questo ruolo; non perché pensa che tu non sia abbastanza abile per qualcos'altro.

La manutenzione richiede un focus sul codice che legge , più di ogni altro ruolo che potresti avere. Se sei bravo a leggere, sarai bravo in manutenzione. Ci sono molti sviluppatori, anche di molti anni di esperienza, che non hanno il talento per leggere il codice di altre persone (o peggio, il loro), anche se sono brillanti in altre cose .

Quando ti metti fuori dal lavoro di manutenzione, non stai 'convincendo il management che saresti abbastanza bravo da fare qualcosa di più importante', stai letteralmente prendendo il lavoro di manutenzione lontano dai vivi. Quando smetti di fare quel lavoro, è perché non c'è niente da fare. Tutti i problemi sono risolti, sia perché sono stati migrati fuori dall'applicazione legacy, perché le attività manuali sono ora automatizzate, o hai convinto il cliente che non vogliono o hanno bisogno e non lo faranno mai. Se il tuo capo lo interpreta come "è bravo in questo, meglio tenerlo qui", non fare nulla, quindi è un pazzo.

Essere uno sviluppatore di manutenzione! = essere lasciato in panchina. Il lavoro di manutenzione dev può essere uno dei lavori più frustranti, dolorosi e fastidiosi del mondo mentre risolvi i problemi bizzarri che lo sviluppatore originale ha mancato.

Può anche essere uno dei più gratificanti, sia personalmente che professionalmente, e il lavoro educativo che puoi fare. Se riesci a eliminare un bug che esiste nel sistema per 6 mesi + e ha un impatto diretto sul 10% della base clienti che i tuoi capi ti ameranno, il 10% della base clienti ti amerà. Migliorando il software in modo incrementale e correggendo bug che impiegano una settimana per rintracciare efficacemente, aumenterai le tue conoscenze non solo di quel sistema, ma quali bug puoi potenzialmente vedere in condizioni specifiche, e poi lo prendi a bordo e diventi un migliore sviluppatore.

Mi piace creare nuovi sistemi, ma la maggior parte dei trucchi nella mia borsa di programmazione derivava dal fare lavori di manutenzione e mi è tornata utile più volte di quanto pensassi.

Non bussare. Ho fatto un sacco di tempo come programmatore di manutenzione. Se il prodotto è interessante e gli altri sviluppatori non lo sono, potresti imparare qualcosa. E se sono cattivi, imparerai cosa rende il codice non mantenibile e puoi usare quell'esperienza mentre scrivi il tuo codice. E dopo un po ', sarai il tipo a cui si rivolgeranno quando avranno bisogno di sapere qualcosa sul codice, perché lo saprai tutto, non solo il piccolo silo di qualcuno.

E dopo aver imparato a conoscere il codice, saprai quali parti necessitano di refactoring e in grado di proporre progetti per farlo, che ovviamente sarai perfettamente pronto a condurre.

Vale la pena notare che il ruolo di manutentore non è uno, in un'organizzazione intelligente, dato a qualcuno perché non è abbastanza buono per qualcos'altro ... è dato a loro perché sono abbastanza buoni per gestire il particolare ruolo. Mantenere attivo e funzionante il sistema esistente è un ruolo estremamente importante e, a seconda della compagnia, molti milioni di dollari possono bilanciarsi sulla punta di detti ingegneri che fanno bene il loro lavoro.

Detto questo, mentre la maggior parte dei manager comprenderà intuitivamente che il ruolo ha bisogno di un individuo esperto per gestirlo, la maggior parte non riconosce i risultati di tali programmatori e può essere difficile ottenere il riconoscimento per il proprio lavoro. È del tutto troppo facile essere messi nel ruolo perché sei abile, e loro se ne sono dimenticati dato che i rilanci e le promozioni vengono distribuiti più tardi ... perché il segno di te che fai un ottimo lavoro nel tuo ruolo è che nessuno si accorge che sei fare un ottimo lavoro nel tuo ruolo.

È possibile combattere per il riconoscimento che pensi di meritare per aver adempiuto al ruolo, ma non sono del tutto sicuro che valga la pena di compiere il grande sforzo. Invece, consiglierei di discutere con il tuo manager il concetto di (come altri hanno già detto) ruotando il ruolo attraverso i vari sviluppatori disponibili per questo. Se possibile, avere almeno una persona nel ruolo a tempo pieno e una persona a tempo parziale. Il timer parziale può conoscere i sistemi e le implicazioni per mantenerli dal timer completo. Quando è il momento di ruotare, il part time può subentrare come timer completo e una nuova persona entra come timer parziale (e impara dal timer completo).

Se ti fa sentire meglio, le persone in Operazioni sono nella stessa posizione ... il segno di una grande persona degli Ops è che nessuno nota quanto bene facciano il loro lavoro. Solo, per una persona Ops, non possono davvero ruotare perché è il loro ruolo principale. Sono un grande fan di elogiare sempre le persone Ops con cui lavoro, pubblicamente e vocalmente, perché dev è uno dei pochi gruppi in grado di vedere quanto migliorino la vita di tutti gli altri.

Quella tangente a parte ... se fai ruotare la posizione di manutenzione, la prossima volta che entri nel ruolo assicurati di dare alle persone davanti a te le loro costolette se vedi che hanno fatto cose che ti semplificano la vita ora che sei di nuovo nel ruolo ... fallo pubblicamente e vocalmente.

L'approccio costruttivo raccomandato dagli altri commentatori è molto buono. Come ha sottolineato Token, hai molto margine di manovra in quel tipo di posizione fintanto che i problemi si risolvono e non rompi nulla.

Se trovi che puoi automatizzare soluzioni comuni, o prevenirle, puoi comprarti un sacco di tempo libero - e se le aspettative dei padroni delle richieste sul tuo tempo non vengono rispettate da questo - fare altri tipi di lavoro che ti diverti di più o che pensi sia più produttivo per l'azienda. Il mio primo lavoro di "programmazione" si è rivelato essere un lavoro di immissione dei dati, ma ho scoperto rapidamente che molta della voce di dati era scrivibile e, successivamente, che poteva essere generata. Ho liberato circa 7/8 del mio tempo, e l'ho usato per riscrivere il sistema di inserimento dati da zero, includendo in esso tutti gli script e i generatori e le interfacce utente più efficienti. Era comunque un lavoro del governo senza sbocchi, ma l'esperienza si è rivelata preziosa.

Parla con il tuo manager degli sviluppatori rotanti nella posizione (per esempio su un ciclo mensile o qualcosa del genere). Se tutti sanno che fa schifo, tutti capiranno perché il lavoro viene distribuito a tutto il team. Forse parlando con il tuo manager scoprirai che questo è già il caso e ti sei appena attivato.

Devi chiederti perché sei stato messo in un ruolo che tutti pensano che faccia schifo. Se il tuo manager ha mezzo cervello, saprà che a nessuno piace e se pensasse che ci sono quelli che lo fanno, potrebbe almeno chiedere. Scopri quanto tempo durerà questa situazione e se ci sono opportunità di tornare al nuovo sviluppo. Non si sa mai, si può entrare in ufficio il giorno successivo e ricevere un nuovo progetto. Sono successe cose più strane.