Quali sono le cose principali che un programmatore si aspetta dal programmatore senior?


41

Di recente ho letto i seguenti 5 tipi di boss e come affrontarli , che descrivono gli abiti del boss peggiore. Ho appena iniziato a guidare un piccolo team di sviluppatori software.

Vorrei sapere quali sono le cose principali che un programmatore si aspetta dal programmatore senior o quali sono le cose che dovremmo evitare durante la gestione di una squadra.

Inoltre, vorrei sapere come mantenere soddisfatti i programmatori e creare un ambiente produttivo e di completezza per il mio team.


19
joelonsoftware.com Leggi tutto il suo blog come hai tempo.
P.Brian.Mackey,

@ P.Brian.Mackey link fantastico!
Avatar

2
Che il programmatore senior abbia un avatar legato a Miyazaki non è forse un must, ma sicuramente un grande vantaggio :-)
leonbloy,

1
Interessante ... Il mio capo ha segnato un 4 su 5 in quel test ... Dovrei avvisarlo della buona notizia;)
Aeo

Risposte:


79

Cose che sembrano funzionare bene per me:

  • Dare lavoro significativo e incoraggiare la proprietà - anche quando si presenta un problema, non risolverlo, parlarne e fornire alla persona approfondimenti in modo che possano risolverlo da soli.
    • modifica - aggiunta - questo doveva anche includere - mantieni il controllo dei dettagli. Supponi che il tuo personale sia abbastanza esperto per svolgere l'incarico senza microgestione o l'obbligo di effettuare il check-in costante. Costruisci una serie di linee guida per quando dovrebbero effettuare il check-in - che dovrebbe essere solo quando il lavoro è finito o è davvero incasinato che un intervento serio è necessario. Se possibile, evita anche di dover essere in loop su problemi di supporto interteam.
  • Sii onesto - questo ha diversi corollari:
    • Sii onesto con te stesso: "Non avrò tempo fino a martedì", "Non l'ho mai fatto, ecco la mia ipotesi migliore", ecc.
    • Sii onesto sulla squadra e su dove si inseriscono nell'azienda: se conosci qualcosa delle cose aziendali, digli se puoi e dì loro ciò che conosci come fatti semplici.
    • Sii onesto nel dare un feedback - non tritare le parole o il pedale se hai un feedback negativo. È diverso da "brutalmente onesto": puoi ancora provare compassione, ma se qualcosa non va, dillo.
    • Sii onesto quando sai che il lavoro riguarda più redtape che ottenere qualcosa di significativo. Nella vita di tutti, cadrà qualche lavoro insignificante. Non far finta che sia significativo. Chiamalo come è, così puoi concentrarti su come superarlo e passare a qualcosa di utile.
  • Ascolta . Almeno il 50% del tuo lavoro è in ascolto, forse di più. Sei diventato responsabile non solo del lavoro tecnico, ma delle persone che lo fanno. Devi ascoltare non solo i problemi della squadra, ma anche il modo in cui le persone affrontano il problema e quali sono le carenze della squadra come gruppo.
    • Corollario importante: l'ascolto può portare direttamente al punto n. 1, dando un lavoro significativo, gli ingegneri sono bravi a trovare modi per facilitare lo sviluppo. Non puoi approvare tutto, ma dove l'idea è buona, dai l'incarico all'ingegnere e in sostanza ti hanno fatto lavorare per te - hanno creato il lavoro significativo e ti hanno detto di cosa si tratta.
  • Dì "grazie" . Lo so, sembra ovvio. Mentre tutti amiamo il denaro, strumenti migliori, un ambiente di lavoro migliore e promozioni - il modo per arrivare a queste cose è attraverso una serie di buoni sforzi, ognuno dei quali merita un "grazie". "Grazie" è totalmente gratuito, non ti esaurirai mai e sapere che il tuo manager ha visto e apprezzato il tuo duro lavoro è sicuramente motivante.
  • Dedica del tempo al quadro generale , anche se ciò significa sacrificare una parte del lavoro quotidiano che ti ha procurato la posizione. È probabilmente vero che puoi programmare meglio di alcuni dei tuoi dipendenti, ma se non trascorri un discreto set di tempo sul quadro generale: il team, la direzione generale del progetto, lo stato della tua base di codice, l'efficienza dei tuoi processi , l'ambiente del tuo team - quindi non farai il lavoro che hanno bisogno che tu faccia.
  • Impara a essere un buffer per la tua squadra . I team di ingegneri lavorano meglio quando hanno il tempo di fare ... ingegneria. La burocrazia aziendale non è ingegneria. Tutto ciò che puoi fare per prendere le fastidiose riunioni 1 all'anno / mese / settimana con persone esterne è meglio. NOTA: Ciò non significa incontri agili con i portatori di interessi: questo è ingegneria, il tuo team deve essere lì per quello. Intendo l'incontro con le strutture che vogliono mettere un forte pezzo di macchinario vicino al tuo team, o il gruppo di processo che vuole che il tuo team compili i documenti in triplice copia prima che qualsiasi codice venga verificato. Sei il sistema di assorbimento dei fiocchi.
  • Supponiamo che le persone problematiche non siano malvagie , sono persone che vogliono fare del bene ma non hanno ancora capito fino a che punto. Non sarai in grado di riparare tutti, ma spesso i primi alcuni fallimenti completi sono tanto un fattore di comunicazione fallita quanto un'incompetenza o una malizia intenzionale. Se inizi con l'ipotesi che le persone non siano malvagie, hai una discreta speranza di evitare un certo numero di archetipi di boss malvagi della lista sopra.

E probabilmente il più importante ... rispetto . Se onestamente non riesci a rispettare i membri del tuo team, devi lavorare per cambiarlo (sia che si tratti di insegnare alle persone o di cambiare il tuo personale). Rispetta il primo giorno e lo riavrai, tratta le persone con una mancanza di rispetto e non otterrai mai rispetto in cambio.

Presi insieme, se fai la maggior parte di queste cose, la maggior parte delle volte il tuo team ti darà il beneficio del dubbio quando dimostrerai di essere umano e rovinerai completamente qualcosa da solo. :) Ogni capo ha i suoi inconvenienti, e si tratta di elaborare una relazione con il tuo team in cui possono aiutarti a compensare i tuoi punti deboli come li aiuti con i loro.


1
ottima risposta, aggiungerei a questo dare loro la libertà . Niente di peggio che essere micromanaged o dover chiedere il permesso per ogni piccolo dettaglio.
agradl,

3
Veramente fantastico .. Vorrei che StackExchange potesse fornire supporto ai seguenti utenti (una breve nota a Joel e Jeff) :)
PrinceCoder

2
WAAOW !! ... questa è stata una delle migliori risposte che abbia mai incontrato @Stackexchange
explorest

wow e wow. e poiché devo inserire qualche altro carattere per inviare questo commento, wow.
Amir Afghani,

2
@PrinceCoder ogni utente ha il proprio feed, puoi seguirlo in alcuni lettori RSS.
svick,

12

Bene, una delle cose più grandi da imparare è che molto spesso non sarai in grado di renderli felici poiché semplicemente non avrai la possibilità di dare loro quello che vogliono.

I migliori manager per cui ho lavorato sono stati i ragazzi più onesti, che difenderanno la loro squadra da tutte le schifezze che i vertici aziendali provano a lanciare contro di loro, e soprattutto ASCOLTANO la loro squadra.


2
C'è una grande differenza tra un manager e un programmatore senior. Devo ancora incontrare un manager come tu descrivi. Per favore, dimmi dove posso trovarli ;-)
dal

Abbastanza giusto è quello che dice il titolo, ma la domanda continua a parlare di capi. Ho avuto un sacco di buoni manager / lead di sviluppo nella mia carriera.
ozz,

+1 @James qualcuno ha modificato il titolo sembra. Per domande si tratta di lead / manager. La parola "capo" sembra feroce, quindi scelgo la parola programmatore senior.
Avatar

6

Credo fermamente che una delle parti più critiche dell'essere senior o di guida sia la disponibilità per i giovani. Anziani e conduttori hanno spesso compiti che solo loro hanno i diritti da svolgere (non diamo ai giovani diritti di scrittura per la messa in scena e produzioni per esempio). Inoltre, una parte significativa del tuo lavoro è quella di guidare i giovani, il che significa rispondere a domande senza ignorarle. Più sei anziano, più è probabile che sarai interrotto da altri che hanno bisogno di qualcosa da te. Devi rinunciare a quel cartello "non disturbare" e imparare a lavorare con le interruzioni.

L'ascolto è importante.

Per favore e grazie sono importanti e non costano nulla.

Non aspettarti più di quello che sei disposto a dare. Se vuoi che lavori fino alle 3 del mattino, è meglio che tu sia lì anche accanto a me a lavorare. Niente è più scoraggiante che lavorare per qualcuno che parte in orario tutti i giorni immediatamente dopo averti assegnato un compito che deve essere svolto entro le 7 del mattino.

Sii onesto. Non giocare ai preferiti (in particolare non giocare ai preferiti dando alla tua ragazza o ragazzo le cose migliori). Tratta tutti i dipendenti con rispetto (anche le persone che non ti piacciono personalmente).

Sii decisivo. Non lasciare le decisioni in sospeso in modo che nessuno possa progredire o, peggio, cambiarle ogni cinque minuti.

Difendi la tua gente. Non li vincerai tutti, ma la gente camminerà attraverso il fuoco per qualcuno che li sostiene nella catena.

Sii disposto a essere il cattivo quando necessario. Una mela cattiva può distruggere una squadra di sviluppo, non aggrapparti a quella persona perché non vuoi affrontare il loro cattivo comportamento (questo vale di più per i lead e i supervisori ufficiali). Quando hai cattive notizie, dillo alla squadra, non tenerla segreta (alla fine lo scopriranno e poi sono pazzi sia per le cattive notizie che per il segreto). Non sei lì per essere popolare ma per fare il lavoro. Chiunque in una posizione di gestione o di quasi gestione deve essere disposto a essere impopolare.

Impara come vendere idee ai superiori e insegna queste abilità ai tuoi sviluppatori.

Comprendi l'importanza del dominio aziendale e diventa esperto su di esso e sulla programmazione.


3

Le parole chiave qui sono fiducia e responsabilità.

Devi solo fidarti che i membri del tuo team sono competenti e concentrati sul completamento dei loro compiti. Non intromettendoti troppo, stai essenzialmente lasciando loro la "propria" responsabilità per il loro lavoro.

IMHO, questo da solo fa miracoli nel creare un'atmosfera salutare.


2
A condizione che siano abbastanza competenti e motivati. Se il team viene ereditato così com'è, purtroppo non è un dato di fatto. Se hai selezionato tu stesso i membri, è ovviamente una storia diversa.
Péter Török,

1
Bene, a mio avviso, anche quelli che non sono troppo competenti, quando ricevono la piena responsabilità, ovvero la "proprietà" di una parte del progetto, faranno tutto ciò che serve per realizzare il loro lavoro. Non mi importa nemmeno se una parte del codice viene raccolta facendo domande su forum e forum, purché il lavoro venga svolto.
Jas,

sfortunatamente ho incontrato controesempi :-( Nel peggiore dei casi che abbia mai visto, uno sviluppatore non ha prodotto assolutamente nulla quando gli è stata data la libertà e la piena responsabilità per circa due mesi - si è scoperto che non stava nemmeno arrivando sul posto di lavoro. Alcune persone non stanno semplicemente tirando il loro peso in una squadra e se le lasci correre liberamente senza un attento esame, peggiori le cose. Se non ti sbarazzi di queste persone in tempo, possono danneggiare l'intera squadra.
Péter Török,

@ Péter Török - certo, tutti conoscono alcune di queste persone in ogni azienda (in realtà leggendo questo ho pensato che tu conoscessi lo stesso ragazzo di me :). Ma dalla mia esperienza, la maggior parte delle persone si concentra e cerca di fare del proprio meglio.
Jas,

Sono d'accordo, la maggior parte delle persone cerca di fare del proprio meglio. (O dovrei dire che tutti cercano di fare del proprio meglio - solo per alcuni, "il migliore" non raggiunge la soglia della visibilità? :-) Uno dovrebbe essere ancora attento a notare le eccezioni in tempo - perché ci sono eccezioni. Proprio come nel codice di produzione, noi dobbiamo gestire i casi di errore in modo corretto, anche se sono rari in circostanze normali.
Péter Török,

3

Bene, IMO mi aspetto che lo sviluppatore senior / lead / qualunque cosa si schieri dalla parte del team di sviluppo contro cose come scadenze idiote, nessuna risorsa ma ci si aspetta che costruisca Roma, ordini straordinari obbligatori, ecc. Tutto ciò che riduce la produttività e rende infelici le persone.

La cosa principale che l'IMO deve evitare è di essere un "sì-uomo" per i dirigenti e di essere sempre d'accordo, qualunque cosa dica (un baciatore di culo, in altre parole)


+1: giusto. E se ti ritrovi a riferire a un "Sì-uomo", lascia al più presto.
Jim G.

1
Purtroppo, ci sono molti ambienti in cui il programmatore senior / lead / manager non è altro che un Yes-Man (o come preferisco chiamarli "Smithers"), e la parte peggiore è la maggior parte delle volte che non lo saprai fino a dopo aver accettato il lavoro.
Wayne Molina,

3

Abilità delle persone. A volte alle persone viene assegnato il titolo di "Senior" e dimenticano di non essere onniscienti. Ritengono che la promozione sia un commento sulle loro abilità tecniche supreme e genio latente. In realtà ora sono manager di livello super basso. Dovrebbero capire come e chi motivare, chi lasciare, come scendere a compromessi e quando ascoltare.

Proprietà. I peggiori programmatori senior non si appropriano di ciò che erano "senior". Esse ricadono sulla tattica del lavoro, delle evasioni e dei giochi di colpa che hanno portato alla loro promozione (più che probabilmente ballando sulla tomba della persona che hanno gettato sotto l'autobus). Ora hanno bisogno di capire il loro culo nella fionda e che è la loro responsabilità di possedere il design, il piano e gran parte del lavoro.

Esperienza. Mi aspetto che gli sviluppatori senior abbiano visto tutto due volte. Dovrebbero comprendere il dominio e la tecnologia. Dovrebbero attaccare in modo aggressivo i rischi ed essere in grado di individuare il tempo che spreca aringhe rosse.


2

La coerenza è una delle cose più importanti. Se gli sviluppatori possono prevedere come agirai, saranno più felici. Anche se sei costantemente uno strumento totale, è meglio che a volte sia cool e a volte uno strumento. Detto questo, non essere uno strumento.


2

Conoscenza e comunicazione. Conoscere la fonte e molto, molto di più, essere in grado di spiegarla a chiunque, in un modo che possano capire e conservare.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.