Opzioni per un programmatore principale che preferisce programmare al comando? [chiuso]

All'inizio di quest'anno sono stato promosso a un ruolo di sviluppatore principale dopo che lo sviluppatore principale del nostro team si è trasferito in un altro reparto. Ho circa 5 anni di esperienza lavorativa e, a causa della disponibilità e delle prestazioni passate, sono stata la scelta principale della direzione per guidare il progetto. Ero un po 'preoccupato, ma ho deciso che era una buona opportunità per avanzare nella carriera ed esperienza, quindi ho accettato.

Ma la mia conclusione finora è che non mi diverto quasi quanto la mia precedente posizione di sviluppatore. Sebbene abbia guidato con successo un team di 5 sviluppatori attraverso diverse versioni, non tocco quasi mai alcun codice. Eseguo invece pianificazione, progettazione e gestione del team, insieme a revisioni del codice. La necessità di tenere traccia di molte altre cose e di pianificare attività in modo che possano essere assegnate alla squadra, mi dà letteralmente mal di testa quasi ogni giorno. Anche se raramente faccio gli straordinari, mi sento quasi esaurito ogni giorno quando lascio il lavoro e non penso di essermi goduto tanto il tempo libero dal lavoro quanto un risultato.

Quindi la mia domanda: come gestiresti o come gestiresti una simile situazione? Per le persone in situazioni simili, hai trovato il modo di gestire meglio la tua squadra, i compiti e il tempo che ti hanno fatto apprezzare il lavoro? O hai trovato il modo di tornare a una posizione più orientata allo sviluppo? So che le posizioni di leader dello sviluppatore pagano quasi sempre uno stipendio più elevato, ma riesco a vedermi arrivare a un punto in cui mi preoccupo meno del denaro e delle promozioni di quanto non faccia del mio godimento del mio attuale lavoro.

Non ne ho discusso con nessuno nel management poiché pensavo che avrei dovuto provare ad adeguarmi per almeno un anno.

La risposta che sto fornendo qui è la mia migliore ipotesi su ciò che potrebbe potenzialmente funzionare, ma non l'ho visto funzionare poiché sto cercando di uscire da una situazione simile in cui ti trovi. Il tutto è ancora un'esperienza di apprendimento per me, ma sto vedendo una tendenza positiva nella mia squadra.

Nella mia azienda sono stato promosso a capo di un team (lo chiamano "lead di progettazione") e, a causa della carenza di persone che conoscono il prodotto e hanno abbastanza esperienza, mi sono offerto volontario per guidare 2 team diversi. Pochi mesi fa "per aiutare con il programma", la direzione ha raddoppiato le dimensioni di queste 2 squadre.

Qualcosa che ho cercato di fare ...

1. Rendere chiaro a tutti (compresa la direzione) che la mia e la posizione di tutti gli altri non è un incarico permanente. Tutti sono invitati a fare un passo in avanti, ad avere una visione più ampia del progetto e partecipare alle decisioni di architettura / design. Avrò l'ultima parola (per ora) se c'è un disaccordo senza risoluzione, ma finora non è mai successo.
2. Concentrati sull'aiutare altre persone a svilupparsi e crescere. Ho avuto discussioni (quasi filosofiche) con diversi sviluppatori in momenti diversi su programmazione e progettazione e approcci diversi al fare le cose. Alcune di queste discussioni sono legate al lavoro reale, altre sono pure esercizi di pensiero. Ho avuto un ragazzo con oltre 20 anni di esperienza, sono tornato alla sua libreria e ho preso un libro in C ++ perché era interessato a cose di basso livello che ho fatto con la meta-programmazione dei template. Queste discussioni sono alquanto contagiose e dopo aver sollevato questi argomenti abbastanza volte, le persone iniziano a pensare a queste cose da sole.
3. Delegare il più possibile sulle altre persone. Anche se osservo molte cose, non partecipo ad ogni singola revisione del codice. Invece faccio revisioni del codice per i nostri ragazzi intermedi e lascio che quei ragazzi facciano revisioni del codice per alcune delle persone più ecologiche. Vedo le revisioni del codice come più di uno strumento di trasferimento delle conoscenze, piuttosto che "assicuriamoci di leggere ogni riga e trovare ogni possibile bug".
4. Una volta definite le interfacce e predisposto il design di base, lascio che anche i ragazzi più recenti abbiano la massima libertà possibile nella codifica interna delle classi. Sì, molto di quel codice è tutt'altro che perfetto, ma viene testato e funziona. Se attraversa un certo confine soggettivo in termini di "odore di codice" e non lo hanno riformattato, suggerirei che alcune classi debbano essere scomposte o riorganizzate. A volte è doloroso, ma quando ricontrollo qualche giorno dopo e ricevo una risposta, "Odio ammetterlo, ma ora questo codice sembra molto meglio", che in realtà mi dà una sensazione calda e confusa.
5. Sfida le persone. Invece di assegnare semplicemente funzionalità da aggiungere al prodotto, chiedi loro di aggiungere quelle funzionalità, ma fallo senza aumentare il numero di funzioni / membri dei dati nelle classi esistenti. Se devi inserire qualcosa di nuovo, devi prendere qualcosa di esistente e prenderti il ​​tempo per capire di cosa si tratta. Tutti conoscono il refactoring, ma senza ulteriore forza all'inizio, sembra che le persone abbiano bisogno di aiuto per fare quel salto per farlo davvero. Come minimo, mi impegno a visitare questo punto durante quasi tutte le revisioni del codice.
6. Tutto riguarda il SALDO. Non puoi essere l'unica persona senior nella squadra a guardare tutti gli altri. Non puoi trascorrere l'intera settimana in riunioni e fare recensioni. Non puoi aspettarti di cogliere ogni errore commesso dalla tua squadra. Alla fine della giornata, devi assegnare il tempo per te stesso come lead, ma devi anche assegnare il tempo per essere uno sviluppatore. Impazzirei se non potessi programmare. Anche con tutto il resto, mi assicuro di avere il tempo di scrivere il codice e non solo il codice, ma alcune cose davvero molto eleganti. Ho appena messo le mani sui libri di meta-programmazione modello e ho iniziato a scavare all'interno di Boost. I ragazzi che hanno inventato quella roba devono essere pazzi (in senso buono). Se la tua direzione inizia a chiederti perché non tutto viene esaminato o perché un noob sta rivedendo un altro codice noobs, devi solo spiegare l'intera cosa dell'equilibrio e che il team semplicemente non ha abbastanza persone con esperienza e alla fine della giornata "è quello che è". Se la tua squadra ha persone anziane, allora è il momento di responsabilizzare e dare loro la libertà di fare i propri progetti / recensioni / aiutare gli altri e non trattarli come semplici generatori di codice. Con l'empowerment arriva la libertà e le persone amano la libertà. Se hai sviluppatori che non si preoccupano della libertà / responsabilizzazione, va bene. Ogni squadra ha ancora bisogno di programmatori puri, assicurati solo di lottare per l'equilibrio. s il tempo di autorizzare allora e dare loro la libertà di fare i propri progetti / recensioni / aiutare gli altri e non trattarli come semplici generatori di codice. Con l'empowerment arriva la libertà e le persone amano la libertà. Se hai sviluppatori che non si preoccupano della libertà / responsabilizzazione, va bene. Ogni squadra ha ancora bisogno di programmatori puri, assicurati solo di lottare per l'equilibrio. s il tempo di autorizzare allora e dare loro la libertà di fare i propri progetti / recensioni / aiutare gli altri e non trattarli come semplici generatori di codice. Con l'empowerment arriva la libertà e le persone amano la libertà. Se hai sviluppatori che non si preoccupano della libertà / responsabilizzazione, va bene. Ogni squadra ha ancora bisogno di programmatori puri, assicurati solo di lottare per l'equilibrio.
7. Il tuo tempo è prezioso. Quindi chiedi al team di inviarti per e-mail tutte le domande critiche non temporali che possono attendere poche ore prima di ottenere una risposta. Quando viene posta la domanda, l'intera squadra deve essere copiata su di essa. Alla fine, quando hai una pausa della giornata, puoi dare un'occhiata al problema e aiutare la persona, ma molte volte, qualcun altro potrebbe averti già battuto alla risposta e non devi fare nulla. Ovviamente come leader, mi metto ancora a disposizione e chiarisco questo fatto perché credo che uno dei miei obiettivi sia quello di assicurarmi che nessuno nella squadra rimanga bloccato per periodi di tempo prolungati senza fare progressi.
8. Assicurati che il tuo team utilizzi il maggior numero possibile di strumenti per rendere le comunicazioni più efficaci. Ad esempio abbiamo un sito wiki e ogni volta che lo stesso problema si presenta più volte, chiedo all'ultimo ragazzo che ho contribuito a creare una pagina wiki.

Non ne ho discusso con nessuno nel management

Penso che tu sappia che questo potrebbe aiutare. Comunicare il proprio disagio con una posizione non significa necessariamente specificare qualcosa di concretamente. Fa sapere al management quali carte sono in possesso e, se è una buona gestione, proveranno a trovare il modo di sfruttare al meglio il tuo potenziale. Non accontentarti di meno.

Al termine del progetto, cerca una posizione più orientata al programmatore nella tua azienda o al di fuori di essa.

Discutere con il management che si desidera meno gestione e "mani" tecniche più tecniche.

Sembra che tu sia in una posizione PM rispetto a uno sviluppatore principale. Considererei uno sviluppatore principale che sta programmando di più.

Prospettiva dei datori di lavoro :

Se ti piace il lavoro attuale e hai una buona storia lì, allora vorrei tenerti attivo e trovare un posto per te, quindi non mi preoccuperei molto di parlare con loro.

Un grande sviluppatore è una cosa preziosa, ma è necessario venderli per cui valga più la pena fare codice e forse progettare di quanto tu sia l'atto giocoleria.

Dai loro un percorso per tirarti indietro impostando un piano di successione. Fondamentalmente trovi qualcuno nella squadra attuale che è interessato a fare le cose che ti fanno venire il mal di testa, nei prossimi 6-9 mesi ti alleni, dandogli i tuoi compiti uno alla volta.

Scegli qualcosa di facile prima, come gli aggiornamenti di stato settimanali:

• Siedili accanto a te quando esegui un aggiornamento dello stato.
• Siediti accanto a loro mentre eseguono il prossimo aggiornamento di stato.
• Lasciatelo fare da soli e rivedilo prima che finisca per la finale.

Quindi assegna loro progressivamente i compiti extra fino a quando non avrai consegnato il godimento delle tue responsabilità aggiuntive.

Il motivo per cui questi lavori meno desiderabili sono pagati di più è perché se non lo fossero nessuno li farebbe, non in modo crudele perché richiedono un livello più alto di abilità ... domanda e offerta.

Per farti pagare più in alto però ... Se fossi in me vorrei sentire che stai in giro, aiuterai questa persona quando richiesto, sarai un mentore per i ragazzi più nuovi, sarà il designer / key brain / esperto di dominio piuttosto che responsabile del progetto. Fondamentalmente questa è una posizione preziosa, qualcun altro può fare il giro e il gioco di giocoleria (ovviamente per pagare di più).

Penso che se dovessi presentare al tuo datore di lavoro un piano di 6-9 mesi che dicesse

• Una buona spiegazione del motivo per cui pensi che sia meglio che torni a concentrarti sulla codifica rispetto alle altre responsabilità.
• A chi iscriversi ... o devono trovare qualcuno ... credo che questo sarà un fattore decisivo.
• Mese di Rach per 6 mesi quali responsabilità vorresti consegnare alla nuova persona
• Quali responsiblites ti terresti alle spalle (come il design, magari seduto sulle recensioni dei codici ecc.).
• Un'idea della riduzione dei salari che saresti disposto a prendere (da qualche parte tra l'originale e ora) sebbene permetta loro di sollevare questo.

Se lo mettessi insieme come un piano per me, come datore di lavoro, sarei più che felice di lavorare con te per realizzarlo.

In bocca al lupo.

Sono stato esattamente nella tua situazione. la risposta si riduce alla relazione che hai con il tuo manager. Nel mio caso è stato molto buono, quindi un giorno l'ho preso da parte e ho detto che non mi piaceva il lavoro, mi sentivo troppo stressato e volevo tornare al codice. Era molto più felice di sentirlo piuttosto che farmi entrare e uscire. Quindi abbiamo elaborato un piano per qualcun altro che assumesse il ruolo di Team Lead e io per tornare alla programmazione.

2 domande che non sono ovvie dal tuo post:

• Sei in una società che guadagna direttamente dal software che scrivi (come Google, Microsoft o Fog Creek) o sei in una funzione sussidiaria (come in una banca o in una società alimentare)?

• Il CEO è un tecnologo o qualcuno che si è alzato attraverso ruoli aziendali?

Se sei una società di software con un CEO tecnologo, non preoccuparti. La leadership aziendale saprà chi sono i preziosi sviluppatori e farà tutto il necessario per mantenerli. Se i dirigenti sono tutte persone che hanno ottenuto la loro "gestione delle persone" o "gestione dei budget", preoccupati. Sii doppiamente preoccupato se sei in un reparto IT interno. In questo caso, devi accettare che un buon equilibrio tra lavoro e vita privata è la ricompensa per rimanere uno sviluppatore.

Un ultimo punto: fai ciò che ti renderà felice. I consigli di tutti gli altri sulle scelte di carriera come questa riguardano ciò che li renderebbe felici - e questo riguarda te.